Genie's Tech Blog

Where knowledge has no dimensions

CEF - Monitoring and Debugging

Hey Guys,

Welcome back. Today I will continue my discussion on the old topic of Load Balancing and will discuss how to monitor and debug the CEF load balancing mechanism.

A number of configurtion, exec and debug commands exist to monitor and debug the load balancing in a running system. We shall now see them one - by - one.

1. ip cef accounting load-balance-hash

This configuration command enables the per hash packet counters which can be seen using the show ip cef <prefix> internal command. This command is supported on all the platforms that employ a software forwarding path. It is not supported on GSR linecards using the PSA forwarding ASIC. Please do remember that enabling this command on distributed platforms, with dCEF enabled will incur a small system performance penalty, as the stats are gathered on the linecards and need to be sent to RP for accumulation and reporting.

2. show ip cef summary

This exec command summarizes the state of the FIB database:

R3#sh ip cef summary 
IPv4 CEF is enabled and running
VRF Default
 24 prefixes (24/0 fwd/non-fwd)
 Table id 0x0
 Database epoch:        0 (24 entries at this epoch)

In the older IOS code, it used to also show what is the load sharing algorithm being used.

Router_R4_Oldcode#sho ip cef summary
IP Distributed CEF with switching (Table Version 73)
27 routes, 0 reresolve, 0 unresolved (0 old, 0 new)
27 leaves, 11 nodes, 14952 bytes, 115732 inserts, 115705 invalidations
1 load sharing elements, 328 bytes, 1 references
universal per-destination load sharing algorithm, id 98822274
20 CEF resets, 3 revisions of existing leaves
1 in-place modifications
refcounts: 68394 leaf, 68352 node
Adjacency Table has 4 adjacencies


3. Show ip cef <prefix> detail

This show command shows more detail for each of the active paths associated with a destination prefix: 

R4#sh ip cef det, epoch 0, per-destination sharing
  nexthop Ethernet1/0
  nexthop Ethernet0/0

R4#sh ip route  
Routing entry for
  Known via "ospf 100", distance 110, metric 12, type intra area
  Last update from on Ethernet1/0, 00:34:59 ago
  Routing Descriptor Blocks:
  *, from, 00:34:59 ago, via Ethernet0/0
      Route metric is 12, traffic share count is 1, from, 00:34:59 ago, via Ethernet1/0
      Route metric is 12, traffic share count is 1

The above output shows that the packet destined to this prefix will use per-destination load sharing and that there are two paths available.

4. Show ip cef <prefix> internal

This exec command shows some of the guts of the CEF load sharing algorithms. In this command we can also see the state of the hash buckets being used.

R4#sh ip cef internal, epoch 0, RIB[I], refcount 5, per-destination sharing
  sources: RIB 
  feature space:
   IPRM: 0x00028000
  path EECF38D8, path list EE998ECC, share 1/1, type attached nexthop, for IPv4
  nexthop Ethernet1/0, adjacency IP adj out of Ethernet1/0, addr EF3617D0
  path EECF3948, path list EE998ECC, share 1/1, type attached nexthop, for IPv4
  nexthop Ethernet0/0, adjacency IP adj out of Ethernet0/0, addr EF361930
  output chain:
    loadinfo EE142674, per-session, 2 choices, flags 0083, 5 locks
    flags: Per-session, for-rx-IPv4, 2buckets
    2 hash buckets
      < 0 > IP adj out of Ethernet1/0, addr EF3617D0
      < 1 > IP adj out of Ethernet0/0, addr EF361930

From teh above command we see that per-destination load sharing is being done. We also see that there are two buckets being used. In older coder code the output used to show a much detailed information and used to show all the 16 buckets as below:

ed6-120b-njarvis#sho ip cef internal, version 72, per-destination sharing
0 packets, 0 bytes
via, 0 dependencies, recursive
traffic share 1
next hop, FastEthernet6/0 via
valid adjacency
via, 0 dependencies, recursive
traffic share 1
next hop, FastEthernet6/1 via
valid adjacency
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)
Hash OK     Interface       Address     Packets
1       Y FastEthernet6/0  0
2       Y FastEthernet6/1  0
3       Y FastEthernet6/0  0
4       Y FastEthernet6/1  0
5       Y FastEthernet6/0  0
6       Y FastEthernet6/1  0
7       Y FastEthernet6/0  0
8       Y FastEthernet6/1  0
9       Y FastEthernet6/0  0
10      Y FastEthernet6/1  0
11      Y FastEthernet6/0  0
12      Y FastEthernet6/1  0
13      Y FastEthernet6/0  0
14      Y FastEthernet6/1  0
15      Y FastEthernet6/0  0
16      Y FastEthernet6/1  0

So, if you see the above command, you can see that how the 16 buckets are being filled and how the load sharing distribution is happening via "Load distribution: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 (refcount 1)"

5. Show ip cef exact-route <src> <dst>

This command is very helpful in cef troubleshooting as this will help you know through which exact interface the traffic is flowing out:

R4#sh ip cef exact-route -> => IP adj out of Ethernet1/0, addr

6. Debug ip cef hash

This debug command is not present in lot of the new IOS releases. You can see the output below:

1w0d: %CEF: ip cef load-sharing algorithm universal 0
1w0d: %CEF: Load balancing algorithm: universal
1w0d: %CEF: Load balancing unique id: 0AFDCFEA
1w0d: %CEF: Sending hash algorithm id 3, unique id 0AFDCFEA to slot 255
SLOT 6:1w0d: %CEF: Received hash algorithm id 3, unique id 0AFDCFEA
SLOT 6:1w0d: %CEF: Load balancing algorithm: universal
SLOT 6:1w0d: %CEF: Load balancing unique id: 0AFDCFEA

This command may be requested by the development engineers from Cisco to check and debug the behavior of the hash algorithm.

Please note that where ever i have used the router R3 and R4 are running on 15.0 IOS code which is mostly run on distributed platforms. You may want to check the other outputs on ISR's to get the expected results.

Hope this information was helpful.


Comments are closed