12-01-2013 04:34 PM - edited 03-07-2019 04:52 PM
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.
Solved! Go to Solution.
12-14-2013 08:28 AM
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
12-02-2013 01:48 AM
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.
12-02-2013 10:08 AM
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
12-14-2013 08:14 AM
I am still experiencing this issue. Does anyone have any suggestions?
Thanks,
Jeremias
12-14-2013 08:28 AM
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
12-14-2013 10:04 AM
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
12-14-2013 10:36 AM
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
12-14-2013 11:06 AM
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#
12-14-2013 11:38 AM
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
12-14-2013 12:09 PM
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
12-14-2013 01:55 PM
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
12-14-2013 03:09 PM
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
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