cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
518
Views
0
Helpful
2
Replies

2821 Router ARP issues? (50% of packets encapsulation failure)

bluewolves10
Level 1
Level 1

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!

 

 

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

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
 

View solution in original post

2 Replies 2

Peter Paluch
Cisco Employee
Cisco Employee

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
 

Heh, it works flawlessly, thank you. I knew it would be a simple fix... but wow, haha!