«

We have several remote sites connecting to a central location. Each remote site has its own file and print server hosted at the central location as virtual machines. Recently, we've been having problems pulling data from one of these servers (e.g., getting directory listing containing large amounts of files and folders), but only from machines at the central site. Users atthe remote site who have been assigned this particular server have not reported any problems. All other servers have been behaving fine, and I can't see how this one server is different from the others.

Captures near the server show normal behavior until it comes time to actually send the directory contents, then there are repeated attempts to transmit the data, followed by a [RST,ACK]. Captures near the machine browsing thedirectory show just the [RST, ACK]. I've done captures in various points in the intervening network and I think I've found the spot where it's not sending data any further, even though all other connectivity to this machine is fine (I'm using my workstation for testing).

The last spot the retransmitted packets get to, the source and destination ips seem correct, and layer 2 info shows the source as being the switch at the remote site the packet came from, and the destination seems to be the MAC address associated with the vlan that the browsing machine is a part of.Packets seem to be dropped somewhere around this point. Captures at the interface where the packets should leave to head to the browsing machine showeverything but the retransmitted packets. Again, the machine doing the browsing has normal connectivity for all other things.

How can I find out why the packets are getting dropped?

Bit of clarification to my post...The server is a VM at the central site that normally users at the remote site access, and they're accessing it with no problems. When we try to access it from the central site, that's when the problems happen.

The central and remote sites are all connected via Opt-E-Man, a switched metro ethernet service from AT&T.

Steve Pfister <> wrote:
> How can I find out why the packets are getting dropped?

What kind of devices are dropping the packets? Switch? Router? Firewall?

Are you doing "ip inspect" or similar? Turn it off.

On Fri, 8 Feb 2013 08:08:14 -0800 (PST), Steve Pfister
<> wrote:

>Bit of clarification to my post...The server is a VM at the central site that normally users at the remote site access, and they're accessing it with no problems. When we try to access it from the central site, that's when the problems happen.
>
>The central and remote sites are all connected via Opt-E-Man, a switched metro ethernet service from AT&T.

It sounds like you have something blocking IP, or a routing /
visibility issue so you dont have a clean traffic path in both
directions

Addressing issue, or routing via a firewall, or a router which doesnt
like having 2 subnets overlaid on the same wire?

does it work for other TCP oriented protocols such as FTP - maybe an
MTU issue somewhere?

Try pings to see which way the packets flow, from both the server and
the clients

Try FTP from both ends, and look at the frame sizes the session uses
and any hesitations + negotiation.
--
Regards

- replace xyz with ntl

I have more definite information about where packets get dropped. Packets get to the remote side (which is a 4506e switch) and come back to the central side (in and out the same interface). Packets seem to go through fine if they're < 1514 bytes, but as soon as a 1514 byte packet is sent to the remote side, nothing comes back.