cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3178
Views
0
Helpful
2
Replies

MTU Problem

Ed Willson
Level 1
Level 1

So last week I installed a new DSL/VPN connection from a small branch to our MPLS cloud.  The modem and router are provided and managed by the ISP. 

We got the tunnel up everything was looking okay - until the next day when several internal websites wouldn't load or would load slowly or erratically.

After many, many hours and days on the phone with the provider they proved that http traffic was working normally and called the site turned-up.

This left me with a branch that had shoddy connections to internal http sites and no access to their edge equipment.  After another couple days of troubleshooting my network I managed to "gain access" to the edge router at the site. 

Here's the Interface I have a question about:

interface Vlan1

description Internal vlan connecting Switchports and embedded AP together

ip address 10.110.30.2 255.255.0.0

ip verify unicast reverse-path

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1452

I was at my wits end and started adjusting the adjust-mss down...low and behold websites started coming up one by one.  So at this point all the sites I've checked are working, that was the important part, but looking at wireshark there is a ton of fragmentation when browsing those sites.  This branch is a one-off, so I have nothing to really compare to.  The router out there is an 861, with an actiontec modem...

How should I go about determining the proper settings to minimize fragmentation?

Thanks,

   Ed 

1 Accepted Solution

Accepted Solutions

Sandeep Choudhary
VIP Alumni
VIP Alumni

Just try to ping  from your pc:

ping -t -f -l 1400

ping -t -f -l 1300

ping -t -f -l 1276

ping -t -f -l 1272

.

.

.

or

You may want to verify the MTU from the remote site, through the GRE, through the provider network. The MTU may be smaller than you expect. Test this with ping using large packets and don't fragment set example: "ping -l 1472 -f 10.10.10.5" The IP address substitute yours. The 1472 is the larges IP packet allowed on standard ethernet, anything larger and it should reject it saying can't fragment. Keep moving lower until a few packet fly through just fine.

You can set the MTU at the the router or also simply have the router adjust the MSS to a smaller value. The MSS is smaller than the MTU by 20 Bytes.

Here is more information on the subject

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ft_admss.html

.

try this you will find your mtu size which you can normally transfer.

Regards

Please rate if it helps.

View solution in original post

2 Replies 2

Sandeep Choudhary
VIP Alumni
VIP Alumni

Just try to ping  from your pc:

ping -t -f -l 1400

ping -t -f -l 1300

ping -t -f -l 1276

ping -t -f -l 1272

.

.

.

or

You may want to verify the MTU from the remote site, through the GRE, through the provider network. The MTU may be smaller than you expect. Test this with ping using large packets and don't fragment set example: "ping -l 1472 -f 10.10.10.5" The IP address substitute yours. The 1472 is the larges IP packet allowed on standard ethernet, anything larger and it should reject it saying can't fragment. Keep moving lower until a few packet fly through just fine.

You can set the MTU at the the router or also simply have the router adjust the MSS to a smaller value. The MSS is smaller than the MTU by 20 Bytes.

Here is more information on the subject

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t4/feature/guide/ft_admss.html

.

try this you will find your mtu size which you can normally transfer.

Regards

Please rate if it helps.

Sandeep,

    Thanks - I was able to dial it in pretty quick.  One thing I noticed is that the remote site can ping out with a rather large MTU, but pings sent to the remote site need a much smaller size.  Can you explain that?

Thanks,

   Ed