I can ping external IPs but cannot browse websites on Cisco 897VA

[jrscedano]

I have a cisco 897va router which I am using for a lab. I have very basic config and am able to ping websites but for some reason cannot browse any of them while connected to this router. The way it's currently setup is port Gigabit 8 (WAN port) is connected to one of the switchports on my linksys router (connected to cable modem) and I have a computer connected to the switchport Gigabit 0 on the Ccisco 897VA router. Interface Vlan 1 is configured as my default gateway with ip address of 192.168.1.1/24. I have a dhcp pool with the network 192.168.1.0/24 set up from which clients are getting ip configuration.  I would appreciate any advise someone here may provide. Below is my config. I have removed interfaces with default (no) configurations in them for ease of reading:

C897VA#show run

Building configuration...

Current configuration : 1985 bytes

!

! Last configuration change at 19:14:01 EST Sun Dec 1 2013

! NVRAM config last updated at 19:14:06 EST Sun Dec 1 2013

! NVRAM config last updated at 19:14:06 EST Sun Dec 1 2013

version 15.2

service tcp-keepalives-in

service tcp-keepalives-out

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

service sequence-numbers

!

hostname C897VA

!

boot-start-marker

boot-end-marker

!

!

!

no aaa new-model

clock timezone EST -5 0

crypto pki token default removal timeout 0

!

!

no ip source-route

ip auth-proxy max-login-attempts 5

ip admission max-login-attempts 5

!

!

!

ip dhcp excluded-address 192.168.1.0 192.168.1.5

!

ip dhcp pool INTERNAL

import all

network 192.168.1.0 255.255.255.0

default-router 192.168.1.1

domain-name cedanolab.com

dns-server 8.8.8.8 4.2.2.2 4.2.2.3

!

!

ip name-server 8.8.8.8

ip cef

!

!

license udi pid C897VA-M-K9 sn *********

!

!

!

controller VDSL 0

!

!

!

interface ATM0

no ip address

no atm ilmi-keepalive

!

interface Ethernet0

no ip address

!

interface GigabitEthernet0

no ip address

!

!

interface GigabitEthernet8

ip address dhcp

ip nat outside

ip virtual-reassembly in

duplex auto

speed auto

!

interface Vlan1

ip address 192.168.1.1 255.255.255.0

no ip redirects

no ip proxy-arp

ip nat inside

ip virtual-reassembly in

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

ip nat inside source list 1 interface GigabitEthernet8 overload

!

access-list 1 permit 192.168.1.0 0.0.0.255

!

!

line con 0

logging synchronous

line aux 0

line vty 0 4

login

transport input all

!

scheduler allocate 20000 1000

!

end

C897VA#

Thank you in advanced.

[Seb Rupik]

Hi Jeremias,

Are you pinging the external IPs from the router or form a host connected to Gi0 ?

What routes do you have configured on the equipment (Comcast router?) upstream of the 897?

cheers,

Seb.

[jrscedano]

Hello Seb,

Thank you for your reply. I am pinging external IPs from a computer connected to Gi0 on the Cisco 897 router and from within the router itself. I can also resolve names to IPs from the computer that's connected to the Cisco 897 router. I have not configured any routes manually. The Linksys routers has its dynamic routes which are configured automatically when connected to the modem. Computers connected to the Linksys router work with no issues. on the Cisco 897 router, I am acquiring an IP address via DHCP and therefore the default route is automatically being set to the ip address of the linksys router. I have tried statically setting the IP address and the default route on the Cisco 897 router and I get the same results.

Thanks again,

Jeremias

[jrscedano]

I am still experiencing this issue. Does anyone have any suggestions?

Thanks,

Jeremias

[Peter Paluch · Accepted solution]

Jeremias,

If I understand you correctly, the PC connected to the Cisco router can resolve names to IP addresses and is able to ping outside destinations but you can not browse the internet. Is that correct?

I am thinking of an MTU issue. Although your Cisco router connects to Ethernet segments only, there may be an additional encapsulation somewhere along the path, adding additional overhead to your packets and possibly causing them to become oversized. Can you try adding the ip tcp adjust-mss 1360 to your interface Vlan1 please, and test the connectivity again?

Also, what exact IP address are you receiving via DHCP on your GigabitEthernet8 interface? Ideally, can you please post the output of show ip route and show ip cef from your Cisco router? Also please include the output from show ip cef 8.8.8.8 detail commands.

Best regards,

Peter

[jrscedano]

Hello Peter,

Thank you for your reply. Yes, you do understand me correctly.  Adding ip tcp adjust-mss 1360 did resolve my issue indeed. I find this very interesting, as I don't understand what exactly could be adding the additional encapsulation to the packets. The MTU for interface vlan 1 was previously set to 1500 by default. I would think that this it would work with no issues. Would you mind giving me an example of what could be adding the additional data to the packet headers? I will research the topic on my own but I would appreciate a quick example.

Thank you very much,

Jeremias

[Peter Paluch]

Hi Jeremias,

I am so glad that we at least found a workaround.

Regarding the additional overhead: I do not know for sure what technology is used behind your cable modem to connect to your Internet Service Provider. There can be several technologies - PPPoE, L2TP, VLANs, MPLS to name just a few.

Please note that we have not actually changed the MTU of the interface Vlan1. Instead, we have configured the router to modify all TCP sessions so that neither endpoint generates a TCP segment body (the Maximum Segment Size, or MSS) greater than 1360 bytes, so with additional 20B of TCP header and 20B of IPv4 header, the total IP packet size generated by any endpoint in a TCP session is at most 1400 bytes. This modification does not affect non-TCP types of traffic.

I suggest one more experiment, this time done from the Cisco router. I would like to perform a test to check the maximum usable MTU of your internet connection. Please enter the ping command in the router's CLI without any arguments, and then fill in the answers as follows here:

Router# ping

Protocol [ip]:

Target IP address: 158.193.152.2

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]: y

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]: 1400

Sweep max size [18024]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 101, [1400..1500]-byte ICMP Echos to 158.193.152.2, timeout is 2 seconds:

Packet sent with the DF bit set

Reply to request 0 (33 ms) (size 1400)

Reply to request 1 (34 ms) (size 1401)

Reply to request 2 (33 ms) (size 1402)

...

What this test does is send a series of ping packets with Don't Fragment bit set, starting at the total size of 1400 bytes and increasing each subsequent ping by 1 byte, ending with the size of 1500 bytes. I hope to find out the maximum packet size that can get through without being fragmented, and find the cutoff value after which the packets get lost. In a well-behaved network, with the DF bit set, the gateway that would need to fragment the packet because of the additional overhead should discard it and send back an ICMP message indicating the maximum packet length that can pass without fragmentation. Unfortunately, many firewalls simply block all ICMP messages, preventing this so-called Path MTU Discovery from working, and sometimes providers even override the DF flag settings.

Would you mind performing the test as shown above, and posting the complete results? Thank you!

Best regards,

Peter

[jrscedano]

Sure thing. Following is the output I got:

Router#ping

Protocol [ip]:

Target IP address: 158.193.152.2

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]: y

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]: 1400

Sweep max size [18024]: 1500

Sweep interval [1]:

Type escape sequence to abort.

Sending 101, [1400..1500]-byte ICMP Echos to 158.193.152.2, timeout is 2 seconds:

Packet sent with the DF bit set

Reply to request 0 (140 ms) (size 1400)

Reply to request 1 (136 ms) (size 1401)

Reply to request 2 (140 ms) (size 1402)

Reply to request 3 (140 ms) (size 1403)

Reply to request 4 (136 ms) (size 1404)

Reply to request 5 (136 ms) (size 1405)

Reply to request 6 (140 ms) (size 1406)

Reply to request 7 (136 ms) (size 1407)

Reply to request 8 (140 ms) (size 1408)

Reply to request 9 (144 ms) (size 1409)

Reply to request 10 (136 ms) (size 1410)

Reply to request 11 (140 ms) (size 1411)

Reply to request 12 (136 ms) (size 1412)

Reply to request 13 (140 ms) (size 1413)

Reply to request 14 (136 ms) (size 1414)

Reply to request 15 (140 ms) (size 1415)

Reply to request 16 (136 ms) (size 1416)

Reply to request 17 (140 ms) (size 1417)

Reply to request 18 (140 ms) (size 1418)

Reply to request 19 (136 ms) (size 1419)

Reply to request 20 (140 ms) (size 1420)

Reply to request 21 (136 ms) (size 1421)

Reply to request 22 (140 ms) (size 1422)

Reply to request 23 (136 ms) (size 1423)

Reply to request 24 (136 ms) (size 1424)

Reply to request 25 (140 ms) (size 1425)

Reply to request 26 (136 ms) (size 1426)

Reply to request 27 (136 ms) (size 1427)

Reply to request 28 (136 ms) (size 1428)

Reply to request 29 (136 ms) (size 1429)

Reply to request 30 (136 ms) (size 1430)

Reply to request 31 (136 ms) (size 1431)

Reply to request 32 (140 ms) (size 1432)

Reply to request 33 (136 ms) (size 1433)

Reply to request 34 (136 ms) (size 1434)

Reply to request 35 (144 ms) (size 1435)

Reply to request 36 (136 ms) (size 1436)

Reply to request 37 (136 ms) (size 1437)

Reply to request 38 (140 ms) (size 1438)

Reply to request 39 (136 ms) (size 1439)

Reply to request 40 (136 ms) (size 1440)

Reply to request 41 (140 ms) (size 1441)

Reply to request 42 (136 ms) (size 1442)

Reply to request 43 (136 ms) (size 1443)

Reply to request 44 (136 ms) (size 1444)

Reply to request 45 (136 ms) (size 1445)

Reply to request 46 (140 ms) (size 1446)

Reply to request 47 (148 ms) (size 1447)

Reply to request 48 (136 ms) (size 1448)

Reply to request 49 (140 ms) (size 1449)

Reply to request 50 (144 ms) (size 1450)

Reply to request 51 (136 ms) (size 1451)

Reply to request 52 (148 ms) (size 1452)

Reply to request 53 (136 ms) (size 1453)

Reply to request 54 (136 ms) (size 1454)

Reply to request 55 (136 ms) (size 1455)

Reply to request 56 (136 ms) (size 1456)

Reply to request 57 (140 ms) (size 1457)

Reply to request 58 (136 ms) (size 1458)

Reply to request 59 (140 ms) (size 1459)

Reply to request 60 (136 ms) (size 1460)

Reply to request 61 (144 ms) (size 1461)

Reply to request 62 (140 ms) (size 1462)

Reply to request 63 (136 ms) (size 1463)

Reply to request 64 (136 ms) (size 1464)

Reply to request 65 (136 ms) (size 1465)

Reply to request 66 (136 ms) (size 1466)

Reply to request 67 (136 ms) (size 1467)

Reply to request 68 (136 ms) (size 1468)

Reply to request 69 (136 ms) (size 1469)

Reply to request 70 (136 ms) (size 1470)

Reply to request 71 (140 ms) (size 1471)

Reply to request 72 (136 ms) (size 1472)

Reply to request 73 (140 ms) (size 1473)

Reply to request 74 (140 ms) (size 1474)

Reply to request 75 (140 ms) (size 1475)

Reply to request 76 (148 ms) (size 1476)

Reply to request 77 (136 ms) (size 1477)

Reply to request 78 (144 ms) (size 1478)

Reply to request 79 (140 ms) (size 1479)

Reply to request 80 (136 ms) (size 1480)

Reply to request 81 (140 ms) (size 1481)

Reply to request 82 (136 ms) (size 1482)

Reply to request 83 (140 ms) (size 1483)

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

Reply to request 85 (140 ms) (size 1485)

Reply to request 86 (136 ms) (size 1486)

Reply to request 87 (136 ms) (size 1487)

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

Reply to request 89 (136 ms) (size 1489)

Reply to request 90 (136 ms) (size 1490)

Reply to request 91 (140 ms) (size 1491)

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

Reply to request 93 (136 ms) (size 1493)

Reply to request 94 (136 ms) (size 1494)

Reply to request 95 (136 ms) (size 1495)

Reply to request 96 (140 ms) (size 1496)

Reply to request 97 (144 ms) (size 1497)

Reply to request 98 (144 ms) (size 1498)

Reply to request 99 (136 ms) (size 1499)

Reply to request 100 (140 ms) (size 1500)

Success rate is 100 percent (101/101), round-trip min/avg/max = 136/138/148 ms

Router#

Router#

[Peter Paluch]

Hi Jeremias,

Thank you! Hmm, this is not what I expected, to be honest. I expected some packets to get lost. Strange.

Let's do one more test, and if that does not tell us anything more specific then let's just stick with the workaround about the TCP MSS. Please add the following ACL to your configuration:

access-list 100 permit ip any host 158.193.152.2

access-list 100 permit ip host 158.193.152.2 any

Then start debugging IP packets as follows:

debug ip packet 100

Then ping the 158.193.152.2 as follows:

ping 158.193.152.2 repeat 1 df-bit size 1500

Only 1 ping packet will be sent out and the reply expected. Please capture the debug output shown on the console and post it here. I am trying to find out if the reply comes in multiple fragments, suggesting that some device along the path overrides your DF bit settings.

Don't forget to use undebug all afterwards and remove the ACL 100.

Best regards,

Peter

[jrscedano]

Here you go:

Router(config)#access-list 100 permit ip any host 158.193.152.2

Router(config)#access-list 100 permit ip host 158.193.152.2 any

Router(config)#exit

Router#deb

Dec 14 20:06:26.272: %SYS-5-CONFIG_I: Configured from console by console

Router#debug ip pack

Router#debug ip packet 100

IP packet debugging is on for access list 100

Router#ping 158.193.152.2 repeat 1 df-bit siz

Router#ping 158.193.152.2 repeat 1 df-bit size 1500

Type escape sequence to abort.

Sending 1, 1500-byte ICMP Echos to 158.193.152.2, timeout is 2 seconds:

Packet sent with the DF bit set

!

Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms

Router#

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2, len 1500, local feature, NAT(2), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, sending

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, output feature, Post-routing NAT Outside(24), rtype 1, forus FALSE

, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, output feature, Common Flow Table(26), rtype 1, forus FALSE, sends

elf FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, output feature, Stateful Inspection(27), rtype 1, forus FALSE, sen

dself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, output feature, NAT ALG proxy(55), rtype 1, forus FALSE, s

Router#endself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.040: IP: s=10.49.71.41 (local), d=158.193.152.2 (GigabitEthernet8), len 1500, sending full packet

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, Common Flow Table(4), rtype 0, forus FALSE, sendself FALSE,

mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, Stateful Inspection(5), rtype 0, forus FALSE, sendself FALS

E, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, Virtual Fragment Reassembly(25), rtype 0, forus FALSE, send

self FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, Virtual Fragment Reassembly After IPSec Decryption(40), rty

pe 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, NAT Outside(67), rtype 0, forus FALSE, sendself FALSE, mtu

0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, input feature, MCI Check(81), rtype 0, forus FALSE, sendself FALSE, mtu 0,

fwdchk FALSE

Dec 14 20:07:00.184: IP: tableid=0, s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41 (GigabitEthernet8), routed via RIB

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41 (GigabitEthernet8), len 1500, output feature, Post-routing NAT Outside(24), rtype 1,

forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41 (GigabitEthernet8), len 1500, output feature, Common Flow Table(26), rtype 1, forus F

ALSE, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41 (GigabitEthernet8), len 1500, output feature, Stateful Inspection(27), rtype 1, forus

FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41 (GigabitEthernet8), len 1500, rcvd 3

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, stop process pak for forus packet

Dec 14 20:07:00.184: IP: s=158.193.152.2 (GigabitEthernet8), d=10.49.71.41, len 1500, enqueue feature, TCP Adjust MSS(5), rtype 0, forus FALSE, sendself FALSE,

mtu 0, fwdchk FALSE

Router#

Thanks for all the help,

Jeremias

[Peter Paluch]

Hi Jeremias,

I do not see anything unusual here... Unfortunately, at this point, I do not really know what is causing the problems, apart from knowing that shrinking the size of TCP segments has helped. It is kind of silly that I have suggested a possible cause of the problem being MTU issues, the workaround works as expected but I cannot prove that the problem is indeed caused by an MTU issue somewhere along the path.

One last question - can you verify the default MTU setting on your PC? If it is connected to a Gigabit Ethernet port on the Cisco router, it is perhaps increasing its MTU up to 9K. That could, in theory, cause some issues.

Best regards,

Peter

[jrscedano]

Hi Peter,

MTU is set to 1500 on my PC. I don't know what could be causing the problem but I am happy with the solution you've provided as this is a lab router. I only to access the internet from it for research purposes. It is easier to access the internet from my lab pc than switching to another machine to do my research. I appreciate all of your help.

Thanks,

Jeremias Cedano