Web Pages Not Loading - ip tcp adjust-mss of No Effect

[alex.brown]

I've been having a serious challenge getting certain web pages to load on windows clients behind a Cisco 1811 router.

Regardless of the browser, whenever I try to go to certain sites, travel sites like expedia.com or www.flightcentre.ca, when I enter the flight information and click the Search button, the page just sits there, acting like it's looking for the information.  If I click the Back button and then click the Forward button, the data that I was searching for appears.

I've run run the ping tests as well as the mturoute.exe tool and they both indicate that the mtu is 1500, however, that doesn't work.

C:\>ping -f -l 1472 www.dslreports.com

Pinging www.dslreports.com [209.123.109.175] with 1472 bytes of data:

Request timed out.

Reply from 209.123.109.175: bytes=1472 time=57ms TTL=52

Reply from 209.123.109.175: bytes=1472 time=101ms TTL=52

Reply from 209.123.109.175: bytes=1472 time=216ms TTL=52

Ping statistics for 209.123.109.175:

    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),

Approximate round trip times in milli-seconds:

    Minimum = 57ms, Maximum = 216ms, Average = 124ms

C:\>ping -f -l 1472 www.dslreports.com

C:\>mturoute -m 1500 www.expedia.ca

* ICMP Fragmentation is not permitted. *

* Speed optimization is enabled. *

* Maximum payload is 1500 bytes. *

+ ICMP payload of 1472 bytes succeeded.

- ICMP payload of 1473 bytes is too big.

Path MTU: 1500 bytes.

C:\>

I've tried setting the MSS to every recommended size, such as 1300, 536, and many, many, many others.  Nothing is working.

Here's a copy of the relevant parts of the config:

!

ip name-server 208.67.222.222

ip name-server 208.67.220.220

ip ssh time-out 60

ip ssh authentication-retries 2

!

!

!

interface FastEthernet0

ip address dhcp

shutdown

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

no ip mroute-cache

duplex auto

speed auto

no cdp enable

!

interface FastEthernet1

ip address dhcp

ip nat outside

ip virtual-reassembly

no ip mroute-cache

duplex auto

speed auto

no cdp enable

!

interface FastEthernet2

!

interface FastEthernet3

!

interface FastEthernet4

!

interface FastEthernet5

!

interface FastEthernet6

!

interface FastEthernet7

!

interface FastEthernet8

!

interface FastEthernet9

!

interface Vlan1

description $ETH-SW-LAUNCH$$INTF-INFO-FE 2$$ES_LAN$

ip address 192.168.112.1 255.255.255.0

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1452

!

no ip forward-protocol nd

ip route 10.5.117.0 255.255.255.0 192.168.112.2

ip route 0.0.0.0 0.0.0.0 dhcp

!

!

ip nat translation timeout 2

ip nat translation tcp-timeout 2

ip nat translation udp-timeout 2

ip nat translation icmp-timeout 2

ip nat inside source route-map primary interface FastEthernet0 overload

ip nat inside source route-map secondary interface FastEthernet1 overload

!

route-map primary permit 10

match ip address 110

match interface FastEthernet0

!

route-map secondary permit 10

match ip address 110

match interface FastEthernet1

!

!

I would be tremendously grateful if someone could help me resolve this issue and so would the users.

[Peter Paluch]

Hi Alex,

Let's try to find out the real MTU using the router's own methods.

Use the extended ping as indicated in this example:

Router# ping

Protocol [ip]:

Target IP address: 87.197.31.42

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: yes

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: v

Loose, Strict, Record, Timestamp, Verbose[V]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1450

Sweep max size [18024]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 51, [1450..1500]-byte ICMP Echos to 87.197.31.42, timeout is 2 seconds:

Packet sent with the DF bit set

Reply to request 0 (75 ms) (size 1450)

Reply to request 1 (76 ms) (size 1451)

Reply to request 2 (75 ms) (size 1452)

Reply to request 3 (76 ms) (size 1453)

Reply to request 4 (75 ms) (size 1454)

Reply to request 5 (84 ms) (size 1455)

Reply to request 6 (67 ms) (size 1456)

Reply to request 7 (84 ms) (size 1457)

Reply to request 8 (76 ms) (size 1458)

Reply to request 9 (75 ms) (size 1459)

Reply to request 10 (76 ms) (size 1460)

Reply to request 11 (75 ms) (size 1461)

Reply to request 12 (76 ms) (size 1462)

Reply to request 13 (67 ms) (size 1463)

Reply to request 14 (76 ms) (size 1464)

Reply to request 15 (67 ms) (size 1465)

Reply to request 16 (75 ms) (size 1466)

Reply to request 17 (76 ms) (size 1467)

Reply to request 18 (75 ms) (size 1468)

Reply to request 19 (76 ms) (size 1469)

Reply to request 20 (84 ms) (size 1470)

Reply to request 21 (75 ms) (size 1471)

Reply to request 22 (84 ms) (size 1472)

Reply to request 23 (76 ms) (size 1473)

Reply to request 24 (75 ms) (size 1474)

Reply to request 25 (76 ms) (size 1475)

Reply to request 26 (75 ms) (size 1476)

Reply to request 27 (76 ms) (size 1477)

Reply to request 28 (75 ms) (size 1478)

Reply to request 29 (76 ms) (size 1479)

Reply to request 30 (75 ms) (size 1480)

Reply to request 31 (84 ms) (size 1481)

Reply to request 32 (67 ms) (size 1482)

Reply to request 33 (76 ms) (size 1483)

Reply to request 34 (84 ms) (size 1484)

Reply to request 35 (75 ms) (size 1485)

Reply to request 36 (76 ms) (size 1486)

Reply to request 37 (75 ms) (size 1487)

Reply to request 38 (76 ms) (size 1488)

Reply to request 39 (75 ms) (size 1489)

Reply to request 40 (75 ms) (size 1490)

Reply to request 41 (76 ms) (size 1491)

Reply to request 42 (75 ms) (size 1492)

Request 43 timed out (size 1493)

Request 44 timed out (size 1494)

Request 45 timed out (size 1495)

Request 46 timed out (size 1496)

Request 47 timed out (size 1497)

Request 48 timed out (size 1498)

Request 49 timed out (size 1499)

Request 50 timed out (size 1500)

Success rate is 84 percent (43/51), round-trip min/avg/max = 67/75/84 ms

In this example, it is visible that the packet size becomes problematic after 1492B.

When performing this test, try using an external IP address which should be available with a normal MTU of 1500B. You may use the IP address 158.193.138.40 (a server of mine).

Please let us know the results! It is also possible we will have to modify the IP MTU on the egress interface Fa1.

Best regards,

Peter

[alex.brown]

Hi Peter,

Thanks for your reply.

This is the output I received from the router:

Router#ping

Protocol [ip]:

Target IP address: 184.31.252.137 <---- this is www.expedia.com

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface:

Type of service [0]:

Set DF bit in IP header? [no]: yes

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]: v

Loose, Strict, Record, Timestamp, Verbose[V]:

Sweep range of sizes [n]: y

Sweep min size [36]: 1450

Sweep max size [18024]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 51, [1450..1500]-byte ICMP Echos to 184.31.252.137, timeout is 2 seconds:

Packet sent with the DF bit set

Reply to request 0 (92 ms) (size 1450)

Reply to request 1 (88 ms) (size 1451)

Reply to request 2 (88 ms) (size 1452)

Reply to request 3 (88 ms) (size 1453)

Reply to request 4 (88 ms) (size 1454)

Reply to request 5 (84 ms) (size 1455)

Reply to request 6 (88 ms) (size 1456)

Reply to request 7 (88 ms) (size 1457)

Reply to request 8 (92 ms) (size 1458)

Reply to request 9 (88 ms) (size 1459)

Reply to request 10 (92 ms) (size 1460)

Reply to request 11 (88 ms) (size 1461)

Reply to request 12 (88 ms) (size 1462)

Reply to request 13 (88 ms) (size 1463)

Reply to request 14 (92 ms) (size 1464)

Reply to request 15 (88 ms) (size 1465)

Reply to request 16 (92 ms) (size 1466)

Reply to request 17 (88 ms) (size 1467)

Reply to request 18 (88 ms) (size 1468)

Reply to request 19 (88 ms) (size 1469)

Reply to request 20 (88 ms) (size 1470)

Reply to request 21 (88 ms) (size 1471)

Reply to request 22 (88 ms) (size 1472)

Reply to request 23 (88 ms) (size 1473)

Reply to request 24 (88 ms) (size 1474)

Reply to request 25 (92 ms) (size 1475)

Reply to request 26 (88 ms) (size 1476)

Reply to request 27 (88 ms) (size 1477)

Reply to request 28 (88 ms) (size 1478)

Reply to request 29 (92 ms) (size 1479)

Reply to request 30 (88 ms) (size 1480)

Reply to request 31 (88 ms) (size 1481)

Reply to request 32 (88 ms) (size 1482)

Reply to request 33 (88 ms) (size 1483)

Request 34 timed out (size 1484)

Reply to request 35 (88 ms) (size 1485)

Reply to request 36 (88 ms) (size 1486)

Reply to request 37 (88 ms) (size 1487)

Reply to request 38 (88 ms) (size 1488)

Reply to request 39 (88 ms) (size 1489)

Reply to request 40 (92 ms) (size 1490)

Reply to request 41 (88 ms) (size 1491)

Reply to request 42 (92 ms) (size 1492)

Reply to request 43 (88 ms) (size 1493)

Reply to request 44 (88 ms) (size 1494)

Reply to request 45 (92 ms) (size 1495)

Reply to request 46 (88 ms) (size 1496)

Request 47 timed out (size 1497)

Reply to request 48 (88 ms) (size 1498)

Reply to request 49 (88 ms) (size 1499)

Reply to request 50 (88 ms) (size 1500)

Success rate is 96 percent (49/51), round-trip min/avg/max = 84/88/92 ms

So, looks like the same result.

Regards,

Alex

[lgijssel]

Hi Alex,

Looks like MTU size is not the issue here. Expl:

You are able to ping with a payload of 1472 bytes with DF set.

Add 20 bytes of IP header and 8 bytes of ICMP header to this and you are at 1500 bytes.

More will not be possible.

Perhaps you can verify the browser settings, especially the security-related ones.

Other optins: Try with a different browser or make a capture of the traffic with WireShark and post it for analysis.

regards,

Leo

[alex.brown]

Thanks for your reply, Leo,

This happens with all three major browsers, IE, firefox, and Chrome, on various clients such as Mac, Windows XP, Vista, and 7.  The Windows XP machine I'm using as a test doesn't have this issue outside of this location.

I will work on getting a Wireshark capture.

Regards,

Alex

[Peter Paluch]

Leo,

Regarding the 1472B you have indicated - just to make sure: the size argument for Cisco's ping command specifies the total IP packet length including its IP header, ICMP header and ICMP body. Specifying a ping with the size argument of 1472B produces an 1472B IP packet with 20B IP header, 8B ICMP header and 1444B ICMP body.

This behavior changes wildly between different operating systems. Under Linux, the ping command does not consider the ICMP+IP header sizes when specifying the length of the packet, and the produced packet is 28B longer than what is specified. On IOS and presumably Windows, the behavior is to produce a packet whose total size is identical to the specified argument.

Considering the output Alex provided, however, it seems that the MTU is indeed not the problem here.

Best regards,

Peter

[alex.brown]

Leo,

Here's a capture of me going searching for a flight on www.flightcentre.ca.  The results page never loads.

When a Linksys router is used to replace the Cisco router, these issues do not occur.

*Note:  The capture contains the real IP address(es) of the laptop/subnet which I had changed in the config I originally posted. 

Regards,

Alex

[Peter Paluch · Accepted solution]

Alex,

To me, the TCP connection simply stalls. There are no lost packets indicated, retransmissions, anything.

I noticed you are using pretty aggressive NAT timeouts. In theory, they could result in the NAT entries being aged out prematurely, and replies unable to be forwarded back to your PC. Can you remove all of them for now and re-test your config?

Best regards,

Peter

[alex.brown]

THAT DID IT!!!  I thought I had removed those settings in the past.  I didn't set this router up originally.

Peter, thank you very much!!  Leo, thank you very much for your insight as well!  You all make a great team!! 

Thank you, thank you, thank you!

Alex