×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Large packets getting lost; changing MTU works *sometimes*

Unanswered Question
Dec 15th, 2005
User Badges:

I have a BSNL DataOne Broadband connection in India and I have it working without any problems on my Ubuntu Linux running on AMD64 (the OS is 32-bit). I have no problems whatsoever connecting to any site on the internet. My ADSL modem is a Huawei MT882.


My company allows people to connect to office from home on a Cisco VPN client (Ver. 4.6.00). I downloaded the Linux version of the client from an internal site, compiled, etc, and am able to connect to my office through VPN. So far so good.


However, when I telnet to my office machine, it invariably hangs when I do even an "ls -al". However, "ls" on a directory with one or two files succeeds. When I tried to connect using the Citrix ICA client, all I get is a blank screen (or sometimes a blob of what should be the login prompt), and there's no way I can connect.


I read on the net that this might be a problem with my MTU setting, and increased the MTU to 2000 using "sudo ifconfig eth0 mtu 2000". SOMETIMES THIS WORKS. I get the ICA client (and telnet too) working, and I can connect to office and work as long as I wish (well, sometimes it disconnects after a couple of hours or so - even the modem's ADSL Link LED stops glowing).


The funny thing is - the success because of changing the MTU is NOT AT ALL REPEATABLE. If it works once, it doesn't mean it'll work again either in 10 mintues or tomorrow. I've tried MTU's all the way from 1100 to 2000, and no value seems to make it work always. Another thing I've observed is - it's *harder* to get it working during the day, and easier early in the morning and late in the evenings. Please note that there's always a "probability" that it connects!


Ubuntu comes with ipv6 enabled by default; I disabled that acting on somebody's advice. That changed NOTHING.


Please help. I've knocked on every door known to man before I came here!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
4gshute Thu, 12/15/2005 - 18:56
User Badges:

Which Cisco device are you using to host the VPN connection?


Could this be a fragmentation issue. Are you able to adjust the mms size of the packets?



kiranbr_cisco Fri, 12/16/2005 - 08:47
User Badges:

I don't know which device is being used to host the VPN connection (I just run the VPN client at home).


I also think that this is a fragmentation issue, and that is why I tried increasing the MTU. (Was that not the right thing to do?)


> Are you able to adjust the mms size of the packets?


How do I do that? How does that help?

mheusinger Sun, 12/18/2005 - 03:40
User Badges:
  • Green, 3000 points or more

Hi,


increasing the MTU will more likely increase the problems. MTU problems usually arise from the fact that one side is using DF bits in IP header, hits an interface where fragemntation would be needed. The resulting ICMP message (fragmentation needed but DF bit set) never gets back to the sender because of NAT or firewall. So path MTU discovery does not work.


A MTU of 1300 on your VPN client machine should work well in all cases - from your side! Still the servers in the HQ might run into the same issue, so contact your IT department.


You can try to analyze the TCP session setup with a packet analyzer like etherreal, which could telly you what is going wrong - look for packet sizes and TCP max segment size.


What also could be is that you have an overloaded internet connection and packet loss there is giving this result.


Hope this helps


Martin

4gshute Sun, 12/18/2005 - 23:59
User Badges:

You can test the maximum size of MTU using ping if you have the opition on the ping command to set the DF bit. Then just increase your ping packet size until it does not get through.


With a windows IP stack you can use the -f option. Not sure about Linux.



Graham

Actions

This Discussion