07-09-2015 01:03 PM - edited 03-05-2019 01:50 AM
I apologize if this is the wrong section for this (LAN connecting to WAN- Internet), but I'm having some issues connecting to the internet using my Cisco 2821 ISR.
Since I'm (hopefully) on the track to my CCNA as a high school student in a technical program involving computers and networking, I decided to take it upon myself to purchase some used Cisco gear and set myself up a test network to get a feel for IOS and networking in general before learning it in class. While the experience has been extremely educational, and I've solved quite a few issues with the thing, this issue has stumped me. When I finally got my network connected to the internet via my comcast modem, I noticed that browsing the internet was painfully slow, with webpages taking minutes to load, or not at all. The odd thing was, on places like youtube, I could watch 30 minute+ videos in 1080p 60fps without ever buffering, meaning that speed wasn't the issue. So, I did the normal thing and started looking for issues. This is what I got...
Router2821#ping
Protocol [ip]:
Target IP address: 8.8.8.8
Repeat count [5]: 4
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 4, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
*Jul 9 20:14:53.675: IP: tableid=0, s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:53.675: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, sending
*Jul 9 20:14:53.675: ICMP type=8, code=0
*Jul 9 20:14:53.699: IP: tableid=0, s=8.8.8.8 (GigabitEthernet0/0), d=10.0.0.5 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:53.699: IP: s=8.8.8.8 (GigabitEthernet0/0), d=10.0.0.5 (GigabitEthernet0/0), len 92, rcvd 3
*Jul 9 20:14:53.699: ICMP type=0, code=0
*Jul 9 20:14:53.699: IP: tableid=0, s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:53.699: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, sending
*Jul 9 20:14:53.699: ICMP type=8, code=0
*Jul 9 20:14:53.699: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, encapsulation failed
*Jul 9 20:14:53.699: ICMP type=8, code=0.!
*Jul 9 20:14:55.699: IP: tableid=0, s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:55.699: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, sending
*Jul 9 20:14:55.699: ICMP type=8, code=0
*Jul 9 20:14:55.719: IP: tableid=0, s=8.8.8.8 (GigabitEthernet0/0), d=10.0.0.5 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:55.719: IP: s=8.8.8.8 (GigabitEthernet0/0), d=10.0.0.5 (GigabitEthernet0/0), len 92, rcvd 3
*Jul 9 20:14:55.719: ICMP type=0, code=0
*Jul 9 20:14:55.719: IP: tableid=0, s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), routed via RIB
*Jul 9 20:14:55.719: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, sending
*Jul 9 20:14:55.719: ICMP type=8, code=0
*Jul 9 20:14:55.719: IP: s=10.0.0.5 (local), d=8.8.8.8 (GigabitEthernet0/0), len 100, encapsulation failed
*Jul 9 20:14:55.719: ICMP type=8, code=0.
Success rate is 50 percent (2/4), round-trip min/avg/max = 20/22/24 ms
Not being one to give up, I hit google in search of the solution. I gathered that encapsulation failure occurs when ARP cannot translate the L2 to L3 addresses. As a result show ip arp shows this right after pinging...
Router2821#show ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 8.8.8.8 0 Incomplete ARPA
Internet 10.0.0.1 0 5823.8c3c.c574 ARPA GigabitEthernet0/0
Internet 10.0.0.5 - 001a.a121.d168 ARPA GigabitEthernet0/0
Internet 69.0.0.1 - 001a.a121.d169 ARPA GigabitEthernet0/1
Internet 69.0.0.3 16 14da.e9c9.bcc1 ARPA GigabitEthernet0/1
But soon after pinging, that address entry simply disappears. (All this behavior is replicated using any outside address from any computer (or the router, obviously) within the LAN, but everything works great when pinging to an address within the LAN). The interesting thing is, from hours of google searching, no one has had partial encapsulation failures. They all have all packets with encapsulation failures.
Here is my running config, for those who can spot an error from just the config:
Router2821#show run
Building configuration...
Current configuration : 1518 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router2821
!
boot-start-marker
boot-end-marker
!
enable secret 5 <<redacted>>
enable password <<redacted>>
!
no aaa new-model
!
resource policy
!
ip subnet-zero
!
!
ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 69.0.0.1 69.0.0.2
!
ip dhcp pool LAN
import all
network 69.0.0.0 255.0.0.0
default-router 69.0.0.1
dns-server 75.75.75.75 75.75.76.76
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/0
description INTERNET
ip address dhcp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface GigabitEthernet0/1
ip address 69.0.0.1 255.0.0.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
!
interface Serial0/0/0
no ip address
shutdown
!
interface Serial0/1/0
no ip address
shutdown
no cdp enable
!
interface Serial0/2/0
no ip address
shutdown
no cdp enable
!
router ospf 1
log-adjacency-changes
!
ip classless
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0
ip route 0.0.0.0 0.0.0.0 dhcp
!
ip http server
no ip http secure-server
ip nat inside source list 101 interface GigabitEthernet0/0 overload
!
access-list 101 permit ip 69.0.0.0 0.255.255.255 any
!
!
control-plane
!
!
!
line con 0
logging synchronous
line aux 0
line vty 0 4
password <<redacted>>
login
!
scheduler allocate 20000 1000
no process cpu extended
no process cpu autoprofile hog
!
end
And the network looks like this:
[Internet]
\/
[Cisco 2821]<--[Comcast Modem] --> [Netgear WAP]
\/
[Cisco 2950 Switch]
\/
[Various Computers in LAN]
((The Netgear WAP/Router/Thing has no issues))
Now, I realize, with this being new to me, that I've most likely done something stupid within my configuration. All I need is someone to point it out.
Thanks for those who read so far, and hopefully we can get this issue resolved!
Solved! Go to Solution.
07-09-2015 02:51 PM
Hi,
The clue is in the way you have configured your default route. You have actually defined two different default routes: One is defined to be right away out Gi0/0, the other is defined to be whatever DHCP tells you. The one through Gi0/0 doesn't work, the one using DHCP-derived gateway works, and because your router obviously performs per-packet load balancing (all router's self-generated packets are load-balanced on a per-packet basis), 50% of your packets toward Internet get lost.
Now, why is the Gi0/0 default route wrong? If you check your show ip route output you will find out, slightly surprisingly, that the default route is shown as 'C'onnected even though you have defined it as a static route. This is the gotcha on Cisco routers: Every static route pointing out an interface without a next hop is considered to be a directly connected network. Now recall how an IP works in a single directly connected network: For every destination address in that directly connected network, use the ARP to resolve it into a MAC address, and then encapsulate the packet toward that MAC address. So if your router treats your default route as directly connected, it considers the whole internet to be directly reachable over Gi0/0 and so it tries to resolve every packet's destination IP into a MAC address using ARP. That is the reason why your show ip arp shows an entry for 8.8.8.8 - otherwise, ARP table would never hold entries for IP addresses that do not belong into your directly connected networks. However, because the Google server 8.8.8.8 obviously isn't directly attached to your Gi0/0 interface, this ARP request goes unanswered - and that's the root cause for the "encapsulation failed" messages you are seeing.
The remedy is very easy, really: Remove the default route through Gi0/0 using no ip route 0.0.0.0 0.0.0.0 Gi0/0 and make sure that the only default route that is defined in your configuration is the one using DHCP information, that is:
ip route 0.0.0.0 0.0.0.0 dhcp
Please let us know if it helped.
Best regards,
Peter
07-09-2015 02:51 PM
Hi,
The clue is in the way you have configured your default route. You have actually defined two different default routes: One is defined to be right away out Gi0/0, the other is defined to be whatever DHCP tells you. The one through Gi0/0 doesn't work, the one using DHCP-derived gateway works, and because your router obviously performs per-packet load balancing (all router's self-generated packets are load-balanced on a per-packet basis), 50% of your packets toward Internet get lost.
Now, why is the Gi0/0 default route wrong? If you check your show ip route output you will find out, slightly surprisingly, that the default route is shown as 'C'onnected even though you have defined it as a static route. This is the gotcha on Cisco routers: Every static route pointing out an interface without a next hop is considered to be a directly connected network. Now recall how an IP works in a single directly connected network: For every destination address in that directly connected network, use the ARP to resolve it into a MAC address, and then encapsulate the packet toward that MAC address. So if your router treats your default route as directly connected, it considers the whole internet to be directly reachable over Gi0/0 and so it tries to resolve every packet's destination IP into a MAC address using ARP. That is the reason why your show ip arp shows an entry for 8.8.8.8 - otherwise, ARP table would never hold entries for IP addresses that do not belong into your directly connected networks. However, because the Google server 8.8.8.8 obviously isn't directly attached to your Gi0/0 interface, this ARP request goes unanswered - and that's the root cause for the "encapsulation failed" messages you are seeing.
The remedy is very easy, really: Remove the default route through Gi0/0 using no ip route 0.0.0.0 0.0.0.0 Gi0/0 and make sure that the only default route that is defined in your configuration is the one using DHCP information, that is:
ip route 0.0.0.0 0.0.0.0 dhcp
Please let us know if it helped.
Best regards,
Peter
07-09-2015 03:04 PM
Heh, it works flawlessly, thank you. I knew it would be a simple fix... but wow, haha!
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