Continue....
Border Gateway Protocol
BGP-version 4- Part 7
BGP RIB Failure
Sometimes when configuring BGP we come accross routes that show rib-failure.
BGP RIB-Failure is a situation where some routes from the BGP process cannot be installed in the main routing table due to different reasons::
- A route with a better administrative distance is already installed in the routing table.
- Installing the route in the routing table is causing the configured route-limit for a particular VRF to be exceeded.
- A memory problem on the BGP speaker prevents the route from getting installed in the RIB,
Here we discuss one of the condition.
BGP routes with higher administrative distance than other route sources were silently ignored (similar to all other routing protocols) but you can display BGP routes that are not inserted in the IP routing table with the "show ip bgp rib-failure" command, The output explains why the BGP route was not inserted in the IP routing table. Contrary to all other routing protocol, BGP routes that are not used due to higher administrative distance are still advertised to all BGP peers, unless you configure "bgp suppress-inactive" command.
What exactly does this mean? Have a look at this output:
R3#sh
ip bgp
Network Next Hop Metric LocPrf Weight Path
r>
172.16.220.0/24 172.16.220.1 0 0 3 i
*>
192.68.0.0/16 172.16.220.1 0 0 3 {2,1} i
*>
192.68.10.0 172.16.220.1 0 3 2 i
|
172.16.220.0/24 is showing up as r> in BGP table– but what exactly is going on? There is a command you can use to see what’s happened: show ip bgp rib-failure
R3#sh
ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
172.16.220.0/24 172.16.220.1 Higher admin distance n/a
|
Here it’s clearly indicating that the BGP could not be injected into the routing table as there is already a route with a higher administrative distance there. This is proved with the ip routing table below:
R3#sh ip route
172.16.220.0
Routing entry
for 172.16.220.0/24
Known via "connected", distance
0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/1
Route metric is 0, traffic share count
is 1
|
As this is not best route for the routing table, it was not injected into the IP routing table but it is a valid and best bgp route, therefore it is still advertised to other BGP peers.
Configuring one or two iBGP neighborship may not consume much time or results any overhead but in a large ISP environment, it is often required to config several iBGP neighborship. This consumes lots of time and configuration overhead. It has also impact on routers memory and processing power.
Instead of configuring each individual IBGP neighborship seperatly, BGP Peer Groups concept was designed to allow do configuration in groups and saves routers memory instead of applying same set of configuration commands for each individual neighbor again and again.
example:
There are three routers R1, R2 and R3 and we need to create neighborship between loopback addresses of R1 to R2 and R1 to R3.
R1(lo1 1.1.1.1)=====IBGP======R2(lo1 2.2.2.2)
R1(lo1 1.1.1.1)=====IBGP======R3(lo1 3.3.3.3)
Creating Peer Group Config on R1
R1(config-router)#neighbor PEERS1 peer-group
R1(config-router)#neighbor PEERS1 remote-AS 200
R1(config-router)#neighbor PEERS1 next-hop-self
R1(config-router)#neighbor PEERS1 update-source lo1
Here PEERS1 is the peer-group name that we created.
Applying Peer-Group Config
Neighborship between R1 and R2
R1(config-router)#neighbor 2.2.2.2 peer-group PEERS1
Neighborship between R1 and R3
R1(config-router)#neighbor 3.3.3.3 peer-group PEERS1
Please read BGP-version 4- Part 7 for more information.
No comments:
Post a Comment