Cannot pass application data

Unanswered Question
Jul 5th, 2007

We recently added a 2851 router to our network. It connects to a 3750 switch via a MOE circuit. The link is up just fine (interface up, line protocol up), we can ping or telnet to anywhere in our network from the 2851, but we cannot pass any higher level application traffic (web, Outlook, DICOM, etc) from the 2851 "side" of the network over the link. I do not detect any types of errors. Note that a VPN is not being utilized.

Please advise.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
sundar.palaniappan Thu, 07/05/2007 - 11:39

What's the max MTU supported across the link. From the router do an extended ping to the 3750 and check whether you can successfully send 1500 byte packets.

HTH

Sundar

pdriscoll Thu, 07/05/2007 - 12:44

Thank you both for your replies.

Sandar - you were right. Extended ping reveals an MTU of 1496. All pings over that size fail. Other routers that I reviewed all allowed an MTU of 1500.

When I reviewed the "ip tcp adjust-mss xxx" command on Cisco, it suggested a mss value set to 1452, along with an adjustment of the MTU to 1492. I am guessing that your mss value of 1433 is the result of experience in the field, the best teacher of all. Would you be willing to elaborate on why you suggest using mss set to 1433 rather than 1452?

Thank you both for your helpful insight.

sundar.palaniappan Thu, 07/05/2007 - 12:53

I feel that any value less than 1496 should resolve the MTU problem that you are facing. You don't need to worry about the lowering the MTU values to around 1440 bytes since you aren't doing IPSEC. IPSEC can add overhead of up to 64 bytes if you are doing GRE with IPSEC which could warrant the need to lower the MTU to 1436 bytes.

HTH

Sundar

I generally run into problems when I am passing traffic over GRE tunnels. The GRE header winds up taking about 60 bytes(that's a ball park number. I haven't looked at it in a while). So we discovered that we needed to drop the MSS size a bit lower to ensure that applications worked properly.

You may not need to lower it that far.

pdriscoll Thu, 07/05/2007 - 13:41

Update: Since we do not and will not be passing any IPSec or GRE traffic over the interface, I chose to go with the mss set to 1452, mtu set to 1492. (I have not tested sending traffic over this yet). However, when I do a SH INT, it still shows MTU set to 1500:

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

What am I to conclude from this? Is the MTU set to 1492, or did the command not work as I anticipated? Thanks again.

sundar.palaniappan Thu, 07/05/2007 - 13:48

The inteface MTU value will change only if you set 'ip mtu (value)'. 'ip tcp adjust-mss (value)' would only affect the TCP traffic that's passing through the router as the router would tweak the value set when the TCP client/server negotiate the MTU size.

If it was indeed an MTU problem then the TCP applications that failed before should work now. Can you test and let us know the status.

HTH

Sundar

pdriscoll Fri, 07/06/2007 - 06:30

Update: within the WAN, the applications seem to be working now with ip tcp adjust-mss 1452. However, we need to pass some of this traffic out our firewall (non-Cisco) to a server in a DMZ, and that server reports an error on the traffic that originates behind and passes through this 2851. All other similar traffic that originates elsewhere in the WAN passes through the firewall and reaches the server just fine.

I realize this issue is outside of a Cisco forum now, but I will post an answer to this when we solve it, as others may encounter a similar situation.

Thanks to all who posted assistance on this.

srimural Thu, 07/05/2007 - 13:18

Hi,

You can check the fragment size with ping of different sizes with the DF bit set.

This can give you a fair idea of what is the path MTU.

Thanks and Regards,

Srinath.M

Cable&Wireless

Actions

This Discussion