Cannot pass application data

Unanswered Question
Jul 5th, 2007
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
sundar.palaniappan Thu, 07/05/2007 - 11:39
User Badges:
  • Green, 3000 points or more

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

bgibson@ryanbeck.com Thu, 07/05/2007 - 12:23
User Badges:

You might need to adjust the mss size inside the configuration.


the command is ip tcp adjust-mss 1433.


Sometimes applications don't play well when the MTUs go below 1500. Do the tests that Sandar suggested and then try and then try this command to see if that "fixes" the problem.

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

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
User Badges:
  • Green, 3000 points or more

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

bgibson@ryanbeck.com Thu, 07/05/2007 - 12:53
User Badges:

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
User Badges:

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
User Badges:
  • Green, 3000 points or more

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
User Badges:

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
User Badges:

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