The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Routing Information Base (RIB) is a distributed collection of information about routing connectivity among all nodes of a network. Each router maintains a RIB containing the routing information for that router. RIB stores the best routes from all routing protocols that are running on the system.
This module describes how to implement and monitor RIB on Cisco IOS XR network.
Note | For more information about RIB on the Cisco IOS XR software and complete descriptions of RIB commands listed in this module, see the Additional References section of this module. To locate documentation for other commands that might appear during the execution of a configuration task, search online in the Cisco IOS XR Commands Master List for the Cisco XR 12000 Series Router. |
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
To implement the Cisco RIB feature, you must understand the following concepts:
Each routing protocol selects its own set of best routes and installs those routes and their attributes in RIB. RIB stores these routes and selects the best ones from among all routing protocols. Those routes are downloaded to the line cards for use in forwarding packets. The acronym RIB is used both to refer to RIB processes and the collection of route data contained within RIB.
Within a protocol, routes are selected based on the metrics in use by that protocol. A protocol downloads its best routes (lowest or tied metric) to RIB. RIB selects the best overall route by comparing the administrative distance of the associated protocol.
RIB uses processes and maintains data structures distinct from other routing applications, such as Border Gateway Protocol (BGP) and other unicast routing protocols, or multicast protocols, such as Protocol Independent Multicast (PIM) or Multicast Source Discovery Protocol (MSDP). However, these routing protocols use internal data structures similar to what RIB uses, and may internally refer to the data structures as a RIB. For example, BGP routes are stored in the BGP RIB (BRIB), and multicast routes, computed by multicast routing protocols such as PIM and MSDP, are stored in the Multicast RIB (MRIB). RIB processes are not responsible for the BRIB and MRIB, which are handled by BGP and multicast processes, respectively.
The table used by the line cards and RP to forward packets is called the Forwarding Information Base (FIB). RIB processes do not build the FIBs. Instead, RIB downloads the set of selected best routes to the FIB processes, by the Bulk Content Downloader (BCDL) process, onto each line card. FIBs are then constructed.
Forwarding is done based on the longest prefix match. If you are forwarding a packet destined to 10.0.2.1, you prefer 10.0.2.0/24 over 10.0.0.0/16 because the mask /24 is longer (and more specific) than a /16.
Routes from different protocols that have the same prefix and length are chosen based on administrative distance. For instance, the Open Shortest Path First (OSPF) protocol has an administrative distance of 110, and the Intermediate System-to-Intermediate System (IS-IS) protocol has an administrative distance of 115. If IS-IS and OSPF both download 10.0.1.0/24 to RIB, RIB would prefer the OSPF route because OSPF has a lower administrative distance. Administrative distance is used only to choose between multiple routes of the same length.
Protocol |
Administrative Distance Default |
---|---|
Connected or local routes |
0 |
Static routes |
1 |
External BGP routes |
20 |
OSPF routes |
110 |
IS-IS routes |
115 |
Internal BGP routes |
200 |
The administrative distance for some routing protocols (for instance IS-IS, OSPF, and BGP) can be changed. See the protocol-specific documentation for the proper method to change the administrative distance of that protocol.
Note | Changing the administrative distance of a protocol on some but not all routers can lead to routing loops and other undesirable behavior. Doing so is not recommended. |
In Cisco IOS XR software, RIB tables support multicast and unicast routing.
The default routing tables for Cisco IOS XR software RIB are the unicast RIB tables for IPv4 routing and the multicast-unicast RIB tables for IPv6 routing. For multicast routing, routing protocols insert unicast routes into the multicast-unicast RIB table. Multicast protocols then use the information to build multicast routes (which in turn are stored in the MRIB). See the multicast documentation for more information on using and configuring multicast.
RIB processes ipv4_rib and ipv6_rib run on the RP card. If process placement functionality is available and supported by multiple RPs in the router, RIB processes can be placed on any available node.
RIB supports statistics for messages (requests) flowing between the RIB and its clients. Protocol clients send messages to the RIB (for example, route add, route delete, and next-hop register, and so on). RIB also sends messages (for example, redistribute routes, advertisements, next-hop notifications, and so on). These statistics are used to gather information about what messages have been sent and the number of messages that have been sent. These statistics provide counters for the various messages that flow between the RIB server and its clients. The statistics are displayed using the show rib statistics command.
RIB maintains counters for all requests sent from a client including:
Route operations
Table registrations
Next-hop registrations
Redistribution registrations
Attribute registrations
Synchronization completion
RIB also maintains counters for all requests sent by the RIB. The configuration will disable the RIB next-hop dampening feature. As a result, RIB notifies client immediately when a next hop that client registered for is resolved or unresolved.
RIB also maintains the results of the requests.
IPv6 Provider Edge (6PE) and IPv6 VPN Provider Edge (6VPE) leverages the existing Multiprotocol Label Switching (MPLS) IPv4 core infrastructure for IPv6 transport. 6PE and 6VPE enables IPv6 sites to communicate with each other over an MPLS IPv4 core network using MPLS label switched paths (LSPs).
RIB supports 6PE and 6VPE by providing 6VPE next hops. The next-hop information is stored in an opaque database in RIB, which is populated by protocol clients with data to be sent to the Forwarding Information Base (FIB).
For detailed information about configuring 6PE and 6VPE over MPLS, see Cisco IOS XR MPLS Configuration Guide for the Cisco XR 12000 Series Router.
RIB quarantining solves the problem in the interaction between routing protocols and the RIB. The problem is a persistent oscillation between the RIB and routing protocols that occurs when a route is continuously inserted and then withdrawn from the RIB, resulting in a spike in CPU use until the problem is resolved. If there is no damping on the oscillation, then both the protocol process and the RIB process have high CPU use, affecting the rest of the system as well as blocking out other protocol and RIB operations. This problem occurs when a particular combination of routes is received and installed in the RIB. This problem typically happens as a result of a network misconfiguration. However, because the misconfiguration is across the network, it is not possible to detect the problem at configuration time on any single router.
The quarantining mechanism detects mutually recursive routes and quarantines the last route that completes the mutual recursion. The quarantined route is periodically evaluated to see if the mutual recursion has gone away. If the recursion still exists, the route remains quarantined. If the recursion has gone away, the route is released from its quarantine.
The following steps are used to quarantine a route:
RIB detects when a particular problematic path is installed.
RIB sends a notification to the protocol that installed the path.
When the protocol receives the quarantine notification about the problem route, it marks the route as being “quarantined.” If it is a BGP route, BGP does not advertise reachability for the route to its neighbors.
Periodically, RIB tests all its quarantined paths to see if they can now safely be installed (moved from quarantined to "Ok to use" state). A notification is sent to the protocol to indicate that the path is now safe to use.
The Route Consistency Checker and Label Consistency Checker (RCC/LCC) are command-line tools that can be used to verify consistency between control plane and data plane route and label programming in IOS XR software.
Routers in production networks may end up in a state where the forwarding information does not match the control plane information. Possible causes of this include fabric or transport failures between the Route Processor (RP) and the line cards (LCs), or issues with the Forwarding Information Base (FIB). RCC/LCC can be used to identify and provide detailed information about resultant inconsistencies between the control plane and data plane. This information can be used to further investigate and diagnose the cause of forwarding problems and traffic loss.
RCC/LCC can be run in two modes. It can be triggered from EXEC mode as an on-demand, one-time scan (On-demand Scan) , or be configured to run at defined intervals in the background during normal router operation (Background Scan). RCC compares the Routing Information Base (RIB) against the Forwarding Information Base (FIB) while LCC compares the Label Switching Database (LSD) against the FIB. When an inconsistency is detected, RCC/LCC output will identify the specific route or label and identify the type of inconsistency detected as well as provide additional data that will assist with further troubleshooting.
RCC runs on the Route Processor. FIB checks for errors on the line card and forwards first the 20 error reports to RCC. RCC receives error reports from all nodes, summarizes them (checks for exact match), and adds it to two queues, soft or hard. Each queue has a limit of 1000 error reports and there is no prioritization in the queue. RCC/LCC logs the same errors (exact match) from different nodes as one error. RCC/LCC compares the errors based on prefix/label, version number, type of error, etc.
In On-demand Scan, user requests scan through the command line interface on a particular prefix in a particular table or all the prefixes in the table. The scan is run immediately and the results are published right away. LCC performs on-demand scan on the LSD, where as RCC performs it per VRF.
In Background Scan, user configures the scan that is then left to run in the background. The configuration consists of the time period for the periodic scan. This scan can be configured on either a single table or multiple tables. LCC performs background scan on the LSD, where as RCC performs it either for default or other VRFs.
To deploy and monitor RIB, you must understand the following concepts:
Perform this task to verify the RIB configuration to ensure that RIB is running on the RP and functioning properly by checking the routing table summary and details.
1.
show
route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
summary
[
detail
] [
standby
]
2.
show route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
] [
protocol
[
instance
] |
ip-address
mask
] [
standby
] [
detail
]
Perform this task to verify the operation of routes between nodes.
1.
show route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
] [
protocol
[
instance
] |
ip-address
mask
] [
standby
] [
detail
]
2.
show route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
backup
[
ip-address
] [
standby
]
3.
show
route
[
vrf
{
vrf-name
|
all
}] [
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
best-local
ip-address
[
standby
]
4.
show
route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
connected
[
standby
]
5.
show
route
[
vrf
{
vrf-name
|
all
}] [
afi-all
|
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
local
[
interface
] [
standby
]
6.
show
route
[
vrf
{
vrf-name
|
all
}] [
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
longer-prefixes
{
ip-address
mask
|
ip-address
/
prefix-length
} [
standby
]
7.
show
route
[
vrf
{
vrf-name
|
all
}] [
ipv4
|
ipv6
] [
unicast
|
multicast
|
safi-all
]
next-hop
ip-address
[
standby
]
Perform this task to disable RIB next-hop dampening.
1.
router
rib
2.
address-family
{
ipv4
|
ipv6
}
next-hop
dampening disable
3.
commit
Configuring RCC and LCC
Perform this task to trigger route consistency checker (RCC) and Label Consistency Checker (LCC) on-demand scan. The on-demand scan can be run on a particular address family (AFI), sub address family (SAFI), table and prefix, vrf, or all prefixes in the table.
1.
Use one of these commands.
2.
Use one of these commands.
Perform this task to run a background scan for Route Consistency Checker (RCC) and Label Consistency Checker (LCC).
1.
configure
2.
Use one of these commands:
3.
commit
4.
Use one of these commands.
The Border Gateway Protocol-Routing Information Base (BGP-RIB) feedback mechanism for update generation feature avoids premature route advertisements and subsequent packet loss in a network. This mechanism ensures that routes are installed locally, before they are advertised to a neighbor.
BGP waits for feedback from RIB indicating that the routes that BGP installed in RIB are installed in forwarding information base (FIB) before BGP sends out updates to the neighbors. RIB uses the the BCDL feedback mechanism to determine which version of the routes have been consumed by FIB, and updates the BGP with that version. BGP will send out updates of only those routes that have versions up to the version that FIB has installed. This selective update ensures that BGP does not send out premature updates resulting in attracting traffic even before the data plane is programmed after router reload, LC OIR, or flap of a link where an alternate path is made available.
To configure BGP to wait for feedback from RIB indicating that the routes that BGP installed in RIB are installed in FIB, before BGP sends out updates to neighbors, use the update wait-install command in router address-family IPv4 or router address-family VPNv4 configuration mode. The show bgp, show bgp neighbors, and show bgp process performance-statistics commands display the information from update wait-install configuration.
RIB is not configured separately for the Cisco IOS XR system. RIB computes connectivity of the router with other nodes in the network based on input from the routing protocols. RIB may be used to monitor and troubleshoot the connections between RIB and its clients, but it is essentially used to monitor routing connectivity between the nodes in a network. This section contains displays from the show commands used to monitor that activity.
The following is sample output from the show route command when entered without an address:
show 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, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local Gateway of last resort is 172.23.54.1 to network 0.0.0.0 C 10.2.210.0/24 is directly connected, 1d21h, Ethernet0/1/0/0 L 10.2.210.221/32 is directly connected, 1d21h, Ethernet0/1/1/0 C 172.20.16.0/24 is directly connected, 1d21h, ATM4/0.1 L 172.20.16.1/32 is directly connected, 1d21h, ATM4/0.1 C 10.6.100.0/24 is directly connected, 1d21h, Loopback1 L 10.6.200.21/32 is directly connected, 1d21h, Loopback0 S 192.168.40.0/24 [1/0] via 172.20.16.6, 1d21h
The following is sample output from the show route backup command:
show route backup 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, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local S 172.73.51.0/24 is directly connected, 2d20h, GigabitEthernet 4/0/0/1 Backup O E2 [110/1] via 10.12.12.2, GigabitEthernet 3/0/0/1
The following is sample output from the show route best-local command:
show route best-local 10.12.12.1 Routing entry for 10.12.12.1/32 Known via "local", distance 0, metric 0 (connected) Routing Descriptor Blocks 10.12.12.1 directly connected, via GigabitEthernet3/0 Route metric is 0
The following is sample output from the show route connected command:
show route connected C 10.2.210.0/24 is directly connected, 1d21h, Ethernet0 C 172.20.16.0/24 is directly connected, 1d21h, ATM4/0.1 C 10.6.100.0/24 is directly connected, 1d21h, Loopback1
The following is sample output from the show route local command:
show route local L 10.10.10.1/32 is directly connected, 00:14:36, Loopback0 L 10.91.36.98/32 is directly connected, 00:14:32, Ethernet0/0 L 172.22.12.1/32 is directly connected, 00:13:35, GigabitEthernet3/0 L 192.168.20.2/32 is directly connected, 00:13:27, GigabitEthernet2/0 L 10.254.254.1/32 is directly connected, 00:13:26, GigabitEthernet2/2
The following is sample output from the show route longer-prefixes command:
show route ipv4 longer-prefixes 172.16.0.0/8 longer-prefixes Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP 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, E - EGP, i - ISIS, L1 - IS-IS level-1 L2 - IS-IS level-2, ia - IS-IS inter area su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local Gateway of last resort is 172.23.54.1 to network 0.0.0.0 S 172.16.2.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.3.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.4.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.5.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.6.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.7.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.8.0/32 is directly connected, 00:00:24, Loopback0 S 172.16.9.0/32 is directly connected, 00:00:24, Loopback0
The following is sample output from the show route resolving-next-hop command:
show route resolving-next-hop 10.0.0.1 Nexthop matches 0.0.0.0/0 Known via "static", distance 200, metric 0, candidate default path Installed Aug 18 00:59:04.448 Directly connected nexthops 172.29.52.1, via MgmtEth0/ RP0 0/CPU0/0 Route metric is 0 172.29.52.1, via MgmtEth0/RP1/CPU0/0 Route metric is 0
rcc ipv6 unicast period 500
lcc ipv6 unicast period 500
show rcc ipv4 unicast 10.10.0.0/16 vrf vrf 1
show lcc ipv6 unicast all
For additional information on the protocols that interact with RIB, you may want to see the following publications:
Implementing MPLS Layer 3 VPNs in Cisco IOS XR MPLS Configuration Guide for the Cisco XR 12000 Series Router
Implementing BGP in Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router
Implementing EIGRP in Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router
Implementing IS-IS in Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router
Implementing OSPF in Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router
Implementing RIP in Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router
RIB Commands in Cisco IOS XR Routing Command Reference for the Cisco XR 12000 Series Router
Related Topic | Document Title |
---|---|
Routing Information Base commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples |
RIB Commands on Cisco IOS XR Software in Cisco IOS XR Routing Command Reference for the Cisco XR 12000 Series Router |
Standard/RFC | Title |
---|---|
Draft-ietf-rtgwg-ipfrr-framework-06.txt | IP Fast Reroute Framework, by M. Shand and S. Bryant |
Draft-ietf-rtgwg-lf-conv-frmwk-00.txt | A Framework for Loop-free Convergence, by M. Shand and S. Bryant |
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature. |
— |
MIB | MIBs Link |
---|---|
— |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Description | Link |
---|---|
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password. |