CHECKING THE NEXUS FIB

I don't know about you, but I like my show ip cef and show adjacency detail commands. They give you a bit more information and are rather useful when show ip route and show ip arp are not really enough. But what happens when you jump on a device that doesn't have CEF?

It just happens that I work quite a bit with Nexus 7000s, so I decided I wanted to know how to get the same information from NX-OS (which might have a very similar command syntax, but is a different beast inside).

What do these commands do?

The easy answer is that they show you the contents of the FIB. The slightly awkward answer is that they show you what the router thinks went into the FIB. Most of the time (99.9%, a number which I totally haven't invented on the spot) it knows what's in there, but very nasty bugs can make it so that the RP thinks it programmed one thing and the (distributed) hardware has another thing.

To give you a snapshot of what the high-level interactions between the RIB, FIB and protocol data is, I took a diagram from the article linked below and decided to include it as a piece of ASCII art. Why, you might ask? Because I keep my notes (mostly) in text format and in this case there's no loss of information.

ISIS, BGP, OSPF            ARP
      |                     |
      URIB <------- Adjacency Manager (AM)
      |
Unicast FIB Distribution Module (uFDM)
      |
      Unicast FIB (per module)

Routing protocols and ARP feed information about prefixes and next-hop reachability into the Unicast RIB, from which the Unicast FIB Distribution Module pulls the data it then programs into the distributed FIB in each module. For more details, read up on the Cisco website: Managing the Unicast RIB and FIB

Nexus commands you said...

Here you go. I'll start with the equivalent of show ip cef - the output is quite similar.

nexus7k# show forwarding ipv4 route vrf A

slot  1
=======

IPv4 routes for table A/base

------------------+------------------+----------------------+-----------------
Prefix            | Next-hop         | Interface            | Labels
------------------+------------------+----------------------+-----------------
0.0.0.0/32           Drop               Null0
127.0.0.0/8          Drop               Null0
255.255.255.255/32   Receive            sup-eth1
0.0.0.0/0            30.30.30.158       port-channel20.1111
                     30.30.30.162       port-channel21.1112
30.30.23.34/32       30.30.30.158       port-channel20.1111
30.30.23.35/32       30.30.30.162       port-channel21.1112
30.30.30.156/30      Attached           port-channel20.1111
30.30.30.156/32      Drop               Null0
30.30.30.157/32      Receive            sup-eth1
30.30.30.158/32      30.30.30.158       port-channel20.1111
30.30.30.159/32      Attached           port-channel20.1111
30.30.30.160/30      Attached           port-channel21.1112
30.30.30.160/32      Drop               Null0
30.30.30.161/32      Receive            sup-eth1
30.30.30.162/32      30.30.30.162       port-channel21.1112
30.30.30.163/32      Attached           port-channel21.1112
30.30.30.164/30      30.30.30.158       port-channel20.1111
30.30.30.168/30      30.30.30.162       port-channel21.1112

slot  2
=======
...

Next up is a closer look at the adjacency tables, for which you can use either of these commands:

nexus7k# show ip adj vrf A

Flags: # - Adjacencies Throttled for Glean
       G - Adjacencies of vPC peer with G/W bit

IP Adjacency Table for VRF A
Total number of entries: 7
Address         MAC Address     Pref Source     Interface
30.30.30.158    000c.882a.d980  50   arp        port-channel20.1111
30.30.30.162    000c.882b.61c0  50   arp        port-channel21.1112
nexus7k# show forwarding adjacency 30.30.30.158 detail

slot  1
=======

IPv4 adjacency information

next-hop         rewrite info    interface    Origin AS  Peer AS  Neighbor
-------------- --------------- ------------- ---------- --------- --------------
30.30.30.158    000c.882a.d980 port-channel20.1111

slot  2
=======
...

I'll throw in two more commands, because I'm feeling generous. show routing memory gives you a boatload of statistics and the one below shows you information for load-balanced prefixes - to which next-hop will a packet with source 1.1.1.1 and destination 2.2.2.2 be sent.

nexus7k# show routing hash 1.1.1.1 2.2.2.2 vrf A

Load-share parameters used for software forwarding:
load-share mode: address source-destination port source-destination
Universal-id seed: 0x1acda87
Hash for VRF "A"
Hashing to path *30.30.30.158
For route:
0.0.0.0/0, ubest/mbest: 2/0
    *via 30.30.30.158, Po20.1111, [110/1], 3w4d, ospf-1, type-2, tag 10
    *via 30.30.30.162, Po21.1112, [110/1], 3w5d, ospf-1, type-2, tag 10

Of course, your best friend is the question mark. Explore show routing and show forwarding and you'll get more than you probably need for usual troubleshooting purposes. But then again, if you need to look at the FIB you don't have an easy one, do you? Good luck.

And, as always, thanks for reading.


comments powered by Disqus