05-01-2004 11:29 AM - edited 03-02-2019 03:24 PM
Hi; I appear to be having strange trouble with CEF and adjacency on a Cisco 1711 running 12.3(7)T. I suspect that it is a bug.
I have now recreated the problem in a lab environment. A small diagram is attached. The network is setup as follows:
- Cisco 1711 connected to two networks:
via FastEthernet 0 (209.144.236.222 /255.255.255.240)
via Vlan 1 (10.0.200.1 / 255.0.0.0)
- Attached to FastEthernet 0 is a hub
connected to that hub are 2 more hosts:
1. 209.144.236.209 / 255.255.255.240
- this is the default gateway for the 1711
2. 209.144.236.221 / 255.255.255.240
- this is a standard Linux host
- Attached to vlan 0 is a hub
connected to that hub is 1 more host:
1. 10.0.0.200 / 255.0.0.0
- this is a standard WinXP Pro Laptop
- Cisco 1711 is reset to factory defaults. Config appears later in this message.
- From the Cisco 1711, I can ping all hosts.
ping 209.144.236.209 succeeds
ping 209.144.236.221 succeeds
ping 209.144.236.222 succeeds
ping 10.0.0.200 succeeds
ping 10.0.200.1 succeeds
- From the host 10.0.0.200, I can ping the Cisco 1711 (10.0.200.1, 209.144.236.222) and the def gateway (209.144.236.209).
- From the host 10.0.0.200, I CANNOT ping the Linux host at 209.144.236.221 - it FAILS.
- Digging around some more, I discover that if I log into the Cisco 1711 first and ping 209.144.236.221 (which succeeds), the Cisco 1711 properly does an ARP lookup, and then 10.0.0.200 CAN ping 209.144.236.221. However if I remove 209.144.236.221 from the ARP table 10.0.0.200 cannot talk with it anymore. The Cisco 1711 won't do the arp lookup on behalf of 10.0.0.200.
- Digging around some more, I discover that CEF is giving drop messages:
*Mar 2 01:22:05.315: CEF-Drop: Incomplete adjacency for 0.0.0.0 on FastEthernet0 for destination 209.144.236.221
*Mar 2 01:22:05.315: CEF-Receive: Packet for 209.144.236.221 -- no adjacency
*Mar 2 01:22:05.315: CEF-Drop: Stalled adjacency for 0.0.0.0 on FastEthernet0 for destination 209.144.236.221
*Mar 2 01:22:05.315: CEF-Drop: Packet for 209.144.236.221 -- encapsulation
- Disabling CEF ('no ip cef') causes the Cisco 1711 to behave as expected. That is, if it receives a packet from 10.0.0.200 to 209.144.236.221 (and it doesn't have an arp address), it does an arp lookup, and then routes the data properly. Re-enabling CEF ('ip cef') causes the Router to exhibit the bad behavior. CEF is required because we want ip unicast verify reverse-path.
------
Cisco Config File (with cef enabled)
Router#show run
Building configuration...
Current configuration : 1005 bytes
!
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
no aaa new-model
ip subnet-zero
!
!
!
!
ip cef
ip audit po max-events 100
no ftp-server write-enable
!
!
!
!
!
no crypto isakmp enable
!
!
!
interface FastEthernet0
ip address 209.144.236.222 255.255.255.240
duplex auto
speed auto
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
shutdown
!
interface FastEthernet3
no ip address
shutdown
!
interface FastEthernet4
no ip address
shutdown
!
interface Vlan1
ip address 10.0.200.1 255.0.0.0
!
interface Async1
no ip address
!
ip classless
ip route 0.0.0.0 0.0.0.0 209.144.236.209
no ip http server
no ip http secure-server
!
!
!
!
!
control-plane
!
!
line con 0
line 1
stopbits 1
speed 115200
flowcontrol hardware
line aux 0
line vty 0 4
login
!
!
end
--
Thanks,
Devin Nate
05-06-2004 02:13 PM
Might be a bug "CSCdy51754" or "CSCdp32284". Please see the following link to troubleshoot CEF.
http://www.cisco.com/en/US/tech/tk827/tk831/technologies_tech_note09186a0080094303.shtml
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: