RIB, FIB, LFIB, LIB etc

It can be quite confusing to work out what all these terms are exactly referring to. I’ll try and put a concise answer for all of them here with an example.

RIB – Routing Information Base
This is the route table. i.e. When you do a show ip route, the RIB is what you see

AR1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/32 is subnetted, 1 subnets
C       10.255.255.5 is directly connected, Loopback0

A router may have many separate RIB’s. If you’re running vrf’s with customer, then each vrf will have a separate RIB:

AR1#sh ip route vrf CUS1 | begin Gateway
Gateway of last resort is not set

C    192.168.1.0/24 is directly connected, FastEthernet0/0

AR1#sh ip route vrf CUS2 | begin Gateway
Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.1.0 is directly connected, FastEthernet2/0

FIB – Forwarding Information Base
The FIB is an optimised version of the RIB. Or more correctly it’s the table a router looks at when deciding where to actually forward traffic. In Cisco land, the CEF table is a FIB.

AR1#sh ip cef
Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/8           drop
0.0.0.0/32          receive
10.255.255.5/32     receive
127.0.0.0/8         drop
224.0.0.0/4         drop
224.0.0.0/24        receive
240.0.0.0/4         drop
255.255.255.255/32  receive

Like the RIB, there can be multiple FIB tables on a router:

AR1#sh ip cef vrf CUS1
Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/32          receive
192.168.1.0/24      attached             FastEthernet0/0
192.168.1.0/32      receive
192.168.1.1/32      receive
192.168.1.255/32    receive
224.0.0.0/24        receive
255.255.255.255/32  receive

AR1#sh ip cef vrf CUS2
Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/32          receive
172.16.1.0/24       attached             FastEthernet2/0
172.16.1.0/32       receive
172.16.1.1/32       receive
172.16.1.255/32     receive
224.0.0.0/24        receive
255.255.255.255/32  receive

LIB – Label Information Base
The LIB is an MPLS table. This is the place where the router will keep all known MPLS labels. To take a look, you just need to use show mpls ldp bindings:

AR1#sh mpls ldp bindings
  tib entry: 10.0.0.0/30, rev 18
        local binding:  tag: 21
        remote binding: tsr: 10.255.255.1:0, tag: imp-null
        remote binding: tsr: 10.255.255.2:0, tag: imp-null
  tib entry: 10.0.0.4/30, rev 16
        local binding:  tag: 20
        remote binding: tsr: 10.255.255.1:0, tag: 32
        remote binding: tsr: 10.255.255.2:0, tag: imp-null
  tib entry: 10.0.0.8/30, rev 44
        local binding:  tag: 34
        remote binding: tsr: 10.255.255.1:0, tag: 31
        remote binding: tsr: 10.255.255.2:0, tag: 32
  tib entry: 10.0.0.12/30, rev 42
        local binding:  tag: 33
        remote binding: tsr: 10.255.255.1:0, tag: imp-null
        remote binding: tsr: 10.255.255.2:0, tag: 31
  tib entry: 10.1.0.0/30, rev 5
        local binding:  tag: imp-null
        remote binding: tsr: 10.255.255.1:0, tag: imp-null
        remote binding: tsr: 10.255.255.2:0, tag: 30
  tib entry: 10.2.0.0/30, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 10.255.255.1:0, tag: 30
        remote binding: tsr: 10.255.255.2:0, tag: imp-null
  tib entry: 10.7.0.0/30, rev 36
        local binding:  tag: 30
        remote binding: tsr: 10.255.255.1:0, tag: 25
        remote binding: tsr: 10.255.255.2:0, tag: 26
  tib entry: 10.8.0.0/30, rev 34
        local binding:  tag: 29
        remote binding: tsr: 10.255.255.1:0, tag: imp-null
        remote binding: tsr: 10.255.255.2:0, tag: 25
  tib entry: 10.255.255.1/32, rev 30
        local binding:  tag: 27
        remote binding: tsr: 10.255.255.1:0, tag: imp-null
        remote binding: tsr: 10.255.255.2:0, tag: 23
  tib entry: 10.255.255.2/32, rev 10
        local binding:  tag: 17
        remote binding: tsr: 10.255.255.1:0, tag: 23
        remote binding: tsr: 10.255.255.2:0, tag: imp-null
  tib entry: 10.255.255.3/32, rev 28
        local binding:  tag: 26
        remote binding: tsr: 10.255.255.1:0, tag: 22
        remote binding: tsr: 10.255.255.2:0, tag: 22
  tib entry: 10.255.255.4/32, rev 26
        local binding:  tag: 25
        remote binding: tsr: 10.255.255.1:0, tag: 21
        remote binding: tsr: 10.255.255.2:0, tag: 21
  tib entry: 10.255.255.5/32, rev 6
        local binding:  tag: imp-null
        remote binding: tsr: 10.255.255.1:0, tag: 20
        remote binding: tsr: 10.255.255.2:0, tag: 20
  tib entry: 10.255.255.7/32, rev 24
        local binding:  tag: 24
        remote binding: tsr: 10.255.255.1:0, tag: 18
        remote binding: tsr: 10.255.255.2:0, tag: 18
AR1#

LFIB – Label Forwarding Instance Base
The LFIB is another MPLS table. This is the table that the router uses to forward labelled packets going through the network. Much like the RIB uses the FIB to forward traffic, so the LIB uses the LFIB to forward traffic. This is how you view it:

AR1#sh mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
17     Pop tag     10.255.255.2/32   0          Se1/2      point2point
20     Pop tag     10.0.0.4/30       0          Se1/2      point2point
21     Pop tag     10.0.0.0/30       0          Se1/2      point2point
       Pop tag     10.0.0.0/30       0          Se1/0      point2point
24     18          10.255.255.7/32   0          Se1/0      point2point
25     21          10.255.255.4/32   0          Se1/2      point2point
26     22          10.255.255.3/32   0          Se1/0      point2point
27     Pop tag     10.255.255.1/32   0          Se1/0      point2point
29     Pop tag     10.8.0.0/30       0          Se1/0      point2point
30     25          10.7.0.0/30       0          Se1/0      point2point
33     Pop tag     10.0.0.12/30      0          Se1/0      point2point
34     32          10.0.0.8/30       0          Se1/2      point2point
       31          10.0.0.8/30       0          Se1/0      point2point

Creative Routing Contest

Steve over at networking-forum.com has a contest going, and the winner can win a few sweet prizes.

Take a look here: http://www.networking-forum.com/viewtopic.php?f=29&t=23223&start=0

350-001 CCIE Written v4 passed

Wrote this morning. Just received my Pearson VUE confirmation.

I now have my ticket to the LAB :D

Now the real study starts!

WOOHOO!!!

350-001 booked for 21/03/11

I actually booked my exam a while back, and then promptly moved it a week forward. I actually wanted to move it 2 weeks forward but the testing centre did not have any open slots for me.

This final 2 weeks is mainly for revision. I’ve gone through both Routing TCP/IP Vol1 and the CCIE Routing and Switching Cert Guide 4. I’ve also been reading a number of Cisco pages on technologies that were thin in the cert guide.

Let’s see what happens…

Route filter effects. Link-State vs Distance-Vector

You may think that setting up a route filter would be pretty much the same, no matter what the actual routing protocol is, but you’d be wrong. The main difference is essentially the main difference with these 2 types of protocols to begin with.

A distance-vector protocol exchanges routes with it’s neighbours. A link-state protocol exchanges link states, not routes. You can’t filter link states from a neighbour when that neighbour is in the same area. Why? If you remember your OSPF and IS-Is studies, you’ll remember that in order to function and converge, all routers in the same area need to have identical link-state databases.

So what exactly does a route filter do for different protocols? Let’s do a simple test to find out.

Let’s use the following topology:
Routefilterseffect Route filter effects. Link State vs Distance Vector
The routers BUDA and PEST are separated by the router named DANUBE. Both BUDA and PEST with both be redistributing routes into the routing domain. DANUBE will have route filters configured. We will then check to see which routes were actually seen.

Let’s do a DV protocol first, EIGRP. Let’s first do the basic configuration.

Buda:

interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.0 255.255.255.254
!
router eigrp 1
network 10.1.1.0
network 192.168.1.0
no auto-summary

Danube:

interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.254
!
interface FastEthernet1/0
 ip address 10.1.1.2 255.255.255.254
!
router eigrp 1
 network 10.1.1.1
 network 10.1.1.2
 no auto-summary

Pest:

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.1.3 255.255.255.254
!
router eigrp 1
 network 10.1.1.3
 network 172.16.0.0
 no auto-summary

I now want to create a route-filter on Danube that blocks 172.16.1.0/24 from being advertised into Danube. This should also prevent the route from getting to Buda. Before I do that I want to ensure that Buda and Danube actually do see the 172.16.1.0/24 network:

Buda#sh ip route |  include 172.16
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.1.0 [90/158720] via 10.1.1.1, 00:01:31, FastEthernet0/0
!
!
Danube#sh ip route |  include 172.16
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.1.0 [90/156160] via 10.1.1.3, 00:01:53, FastEthernet1/0

Danube:

access-list 1 deny   172.16.1.0 0.0.0.255
access-list 1 permit any
!
router eigrp 1
 distribute-list 1 in

Now do we see the routes?

Danube#sh ip route |  include 172.16
Danube#
!
!
Buda#sh ip route |  include 172.16
Buda#

Pest of course still sees everything:

Pest#sh ip route | include 192.168
D    192.168.1.0/24 [90/158720] via 10.1.1.2, 00:05:14, FastEthernet0/0

Let’s now change everything to OSPF and see what happens. I’m only going to show Danube’s configuration as the others are almost identical:

router ospf 1
 log-adjacency-changes
 network 10.1.1.1 0.0.0.0 area 0
 network 10.1.1.2 0.0.0.0 area 0

Does Buda and Danube see the routes?

Buda#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/3] via 10.1.1.1, 00:01:03, FastEthernet0/0
!
Danube#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/2] via 10.1.1.3, 00:01:01, FastEthernet1/0

Indeed they do. The same access-list is still on Danube, so I’ll now apply a distribute list on Danube.

router ospf 1
  distribute-list 1 in

What routes do we see on Buda and Danube?

Danube#sh ip route |  include 172.16
Danube#
!
Buda#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/3] via 10.1.1.1, 00:00:39, FastEthernet0/0

On Danube the route is gone, but Buda has the route! Why is this?
The explanation is really simple in fact. In a DV protocol like EIGRP, a router learns how to get to routes from it’s direct neighbours. Danube says to Buda that “I’ve learnt how to get to Pest’s loopback from Pest, so I can now advertise reachability to that network through me” – This is why when that route was filtered out, Danube no longer advertised that route out as it could not get there itself.

With a LS protocol like OSPF, the rules change. Remember that one of the rules of OSPF is that ALL routers in an area with have identical link-state databases. Let’s check this on Danube:

Danube#sh ip ospf database

            OSPF Router with ID (10.1.1.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.1.1.2        10.1.1.2        361         0x80000005 0x006666 2
172.16.1.1      172.16.1.1      369         0x80000003 0x000CB9 2
192.168.1.1     192.168.1.1     545         0x80000003 0x00279E 2
!
truncated

Danube has the 172.16.1.1 LSA in it’s database. The only thing the distribute-list is doing on Danube is preventing that LSA being entered into the RIB (routing-table)

Buda also has the same link-state database as it’s also in area 0.

The above though does actually create a problem. If I try and send a ping from Buda to Pest’s loopback, it’ll send that packet off to Danube. Danube however won’t have the route so it’ll drop the packet. Let’s test this:

Buda#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

The only time a distribute-list or LSA filter has any effect, is when you’re going from one area to another. If you’re filtering intra-area you’re only going to run into routing problems.