In most production environments, you usually cannot disable CEF, even on a per-interface basis, during normal production. This is because in many production networks, traffic rates exceed the software-switching capabilities of the router, and disabling CEF forces software switching. Therefore, disabling CEF to troubleshoot CEF is not always an option. The next step in these situations is to verify the CEF table information.
Example 4-17 illustrates the use of the show ip cef command to gather details about the CEF table on a per-entry basis. The values chosen for this example match those for the troubleshooting example.
Example 4-16 CEF Accounting
Router-2#configure terminal
Router-2(config)#ip cef accounting per-prefix Router-2(config)#end
Router-2#show ip cef 10.18.118.84
10.18.118.0/24, version 53, epoch 0, cached adjacency 172.18.114.1 240 packets, 14400 bytes
via 172.18.114.1, Ethernet0/0, 0 dependencies next hop 172.18.114.1, Ethernet0/0
valid cached adjacency
Example 4-17 Gathering CEF Table Details
Router-2#show ip cef 10.18.118.184 detail
10.18.118.0/24, version 23, cached adjacency 172.18.114.1 0 packets, 0 bytes
via 172.18.114.1, Ethernet0/0, 0 dependencies
continues
From the output shown in Example 4-17, the host 10.18.118.184 next hop is 172.18.114.1 and is a valid cached adjacency through Ethernet0/0. The first step is to verify this output against Figure 4-3 and the show ip route command from Example 4-5. The details are correct. The next step is to verify the next-hop CEF entry for 10.18.118.184, which is 172.18.114.1. Again, this information appears to be correct based on Figure 4-3. If this information was not correct, the next step is to either disable CEF and test connectivity or open a Cisco TAC case.
Another possible reason for packet loss with CEF is CEF drop adjacency. CEF drop adjacencies define hardware-switched drops for prefixes. CEF drop adjacencies allow dropping frames in hardware rather than punting every frame for software switching. This is an effective method in preventing denial of service (DoS) attacks and high CPU usage due the CPU processing excessive drops. If a CEF drop adjacency exists, it is generally because of one of the following reasons:
•
Unsupported features.•
Packets destined to prefixes associated with punt adjacencies that exceed a predefined rate. Punting rate limiters exist to prevent DoS attacks and high CPU usage caused by excessive punts.•
Unresolved or missing FIB entry.•
Unsupported frame type.Example 4-18 illustrates a sample output from the show cef drop command. In respect to Figure 4-3 and Example 4-5, attempting to relate the CEF drop counters to the ICMP packets can yield additional details about why the packets are being dropped. However, in a production environment, it is difficult to correlate the ICMP packet loss to show cef drop counters because production environments generally have multiple flows passing traffic simultaneously. Nonetheless, if the show cef drop counters remain 0 during the ping tests, you can rule out the notion that the ping failed because of CEF drop adjacencies. In later code, the show ip cef switching statistics command gives detailed information about why a drop occurs and replaces the show cef not command.
next hop 172.18.114.1, Ethernet0/0 valid cached adjacency
Router-2#show ip cef 172.18.114.1 detail
172.18.114.1/32, version 17, cached adjacency 172.18.114.1 0 packets, 0 bytes
via 172.18.114.1, Ethernet0/0, 1 dependency next hop 172.18.114.1, Ethernet0/0 valid cached adjacency
Example 4-17 Gathering CEF Table Details (Continued)
Troubleshooting IP Connectivity 125
Table 4-2 defines the fields associated with the show cef drop command.
In controlled environments, preferably in nonproduction environments, use debugs to troubleshoot CEF. If you can narrow your issue to a specific host or subnet and the router or switch under investigation is logging drops or receives, you can use debugs that are limited to specific destinations to troubleshoot the issue. Limiting debugs is done by limiting debug output to specific IP sources or destinations configured in an access list.
Example 4-19 illustrates an example of configuring an access control list (ACL) to limit the output of a CEF debug to a specific destination.
Example 4-18 show cef drop Command Example
Router-2#show cef drop CEF Drop Statistics
Slot Encap_fail Unresolved Unsupported No_route No_adj ChkSum_Err RP 3 0 0 0 0 0
Table 4-2 show cef drop Field Descriptions
Field Description
Slot Refers to the slot for the respective ingress packet counts. For Cisco IOS routers that do not support dCEF, this value is always RP.
Encap_fail Indicates the number of packets dropped after exceeding the limit for packets punted to the processor because of missing adjacency information such as an unresolved ARP request. Note that CEF throttles packets punted to the process level at a rate of one packet per second to aid in susceptibility of DoS attacks.
Unresolved Indicates the number of packets dropped because of an unresolved prefix in the FIB table.
Unsupported Indicates the number of packets fast-dropped by CEF (drop adjacency) because of an unsupported feature.
No_route Indicates the number of packets dropped because of a missing prefix in the FIB table.
No_adj Indicates the number of packets dropped because of incomplete adjacency.
Chksum_Err Indicates the number of IP version 4 (IPv4) packets received with a checksum error.
Example 4-19 Controlling Debug Output Defined by an ACL
Router-2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router-2(config)#access-list 10 permit 10.1.1.1 Router-2(config)#end
Router-2#debug ip cef drop 10
IP CEF drops debugging is on for access list 10
continues
Based on the example in Figure 4-3 and Example 4-5, the debug output illustrates the router processing “receive” packets destined for its own interface. Receive packets include packets punted by CEF for software switching. Drop packets appear in the debug output in the same manner. As a result, this debug, used in controlled environments, can yield additional information helpful in troubleshooting.