06-27-2012 05:50 PM - edited 03-04-2019 04:49 PM
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
Solved! Go to Solution.
06-27-2012 10:58 PM
Just try to ping from your pc:
ping -t
ping -t
ping -t
ping -t
.
.
.
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.
06-27-2012 10:58 PM
Just try to ping from your pc:
ping -t
ping -t
ping -t
ping -t
.
.
.
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.
06-28-2012 10:18 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide