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
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
Wrote this morning. Just received my Pearson VUE confirmation.
I now have my ticket to the LAB :D
Now the real study starts!
WOOHOO!!!
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…
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:
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.
Comments