TCP 3 Way Handshake

You seem to have thought about this a decent bit so I have too. Here is a brain splurge.

I presume this is over the internet with no VPN.

It's not a fragmentation or packet order issue since the initial packets are very small and are sent one at a time.

By the way: The DF bit test it not a guarantee that you are not getting fragmentation since some equipment can be configured to ignore the bit. You need to check the actual packets with say tcpdump. The test is probably valid though and as stated this cannot be a fragmentation issue.

You are saying that ping between the hosts in question works but TCP does not.

Here are some thinks to consider - Some kind of firewall on the client. ## - Can the client make ANY tcp conenction? To itself or other hosts? - That you do not have a duplicate IP address run sniffer and look for ARPs. - RUn tcpdump on the Client to check for received unreachables. - Worry about NAT - don't know what exactly but check it out. - Perhaps you have two internet connections and load balancing and two NATters? - Bad client - use an indepdent sniffer to check for the "lost" packets. - A "deny tcp src dst established" ACL on the path from server to client would block this exact traffic. - run a lot of pings to check that link loss rate is not too high.

Be aware that some debugs do not work with non-process-switched traffic.

"deb ip packet" is one of them.

"no ip route-cache" on interfaces turns of fast swithing but router capacity is reduced by about x 10 (factor of 10) on non hardwre platforms (not 4500/6500) and I would guess MORE on hardware based platforms if indeed it did turn off hardware switching.

Good debug practise if you are worried about CPU no logg con ! should just be off anyway really. no logg mon no logg trap logg buffered logg buffered 100000 ! or whatever value you like best or have memory for.

STILL worry about CPU

On a busy or not so busy router some debugs will kill it - DEAD.

One reasonably CPU friendly way of looking for packets is to create an ACL that PERMITS the traffic that you want to look for and checking the counters on the ACLs.

ip access-l 100 permit tcp 1.1.1.1 2.2.2.2 established ip access-l 100 permit tcp 1.1.1.1 2.2.2.2 ip access-l 100 permit ip any any

ip access-group .....

sh ip access-l 100

ACL lets ALL tarffic through but the first line lets you see if packets match it.

I think this should be reliable on non hardware switched platforms (not 4500 6500)

Good luck.

Hi Bod,

Thanks for this, you have given me a few things here to try / consider, really appreciate the help.

No, this is private ADSL into an MPLS core. When the traffic reaches the Central site (the HQ) there are Ethernet links onwards to the Co-Lo. The Co-LO has a path out to the Internet when clients require breakout.

Good point. I have before had to configure routers to reset the df-bit, old fragmentation problem for another client. Not used tcpdump before I will take a look but I think this is similar to Ethereal which I am familiar with.

Yes.

I asked the Sys Admin at the customer whether IPTables on the Linux machine(s) we blocking connection. He says not. BTW a connection from his Central Office over Ethernet WAN circuits to the Co-Lo works fine.

Don't think so, there are only a handful of hosts in the Co-Lo. I asked him to check connectivity from other machines at site to a number of Co-Lo servers, various ports, nothing worked. I also asked him to try from another site, various ports and that never worked either.

Hmmmm, the router where the server sits does some NATing for some of the Co-Lo hosts. The server concerned though is not subject to NAT. I'll double check may facts but I am sure that there is no translation for this device.

Nice one, I'll do that.

I am glad you mentioned that, I had forgot.

What's weird is that when I had previously enabled ip inspect and and outside ACL on the remote router and saw that I was receiving hits on this ACL. NB I had the entry in there as the client was trying to telnet on port 80 and ip inspect was dropping the session (ip inspect had entries for tcp, udp and icmp only not HTTP). I therefore reckoned application inspection was dropping the traffic as it didn't recongise this as true HTTP traffic hence my outside ACL entry to allow it in.

Point being that I saw the counter increment but no data would flow. Client then tried a wget and same result.

Again thanks. I will see what the ACL's / debugs turn up.

Regards

Darren

You have a firewall or ACL issue. Fragmentation is not an issue because all of the three-way handshake packets are only 40 bytes. You NEVER run packet debugs on production routers or switches, that is what sniffers are for. Do a traceroute and check the configs on every single device to verify that ACL's are not your problem, then check them again, and then a third time. Sometimes you can't see the forest because of the trees, so yes check them three times. Check the logs on any firewall that also may be in the path.for packets to the destination. If they don't have logging of dropped packets, have them check the ruleset. If all else fails, setup captures at points along the path to track down where the packets are being dropped. Tedious, but probably the only way to find the offending device.