A while ago I received the following question:
“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”
I must admit that I had to stop and think for a second before giving my response.
For the above diagram I have a simple BGP configuration:
router bgp 65301 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 192.168.0.2 remote-as 65302 neighbor 192.168.0.2 timers 5 15 ! address-family ipv4 network 1.1.1.1 mask 255.255.255.255 network 2.2.2.2 mask 255.255.255.255 network 3.3.3.3 mask 255.255.255.255 neighbor 192.168.0.2 activate exit-address-family
router bgp 65302 bgp log-neighbor-changes neighbor 192.168.0.1 remote-as 65301 neighbor 192.168.0.1 timers 5 15
Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:
R2#sh ip bgp neighbors 192.168.0.1 received-routes % Inbound soft reconfiguration not enabled on 192.168.0.1
OK, that’s not good. Am I missing the command? Let’s see:
R2#sh ip bgp neighbors 192.168.0.1 ?
advertised-routes Display the routes advertised to a BGP neighbor
dampened-routes Display the dampened routes received from neighbor (eBGP
peers only)
flap-statistics Display flap statistics of the routes learned from
neighbor (eBGP peers only)
paths Display AS paths learned from neighbor
policy Display neighbor polices per address-family
received Display information received from a BGP neighbor
received-routes Display the received routes from neighbor
routes Display routes learned from neighbor
| Output modifiers
-> received-routes – Display the received routes from neighbor
OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?
Let’s recall what “soft-reconfiguration inbound” command actually does.
*Cisco BGP-4 Command and Configuration Handbook
According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.
Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors 192.168.0.1 received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.
A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.
Where are these updates stored?
In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.
When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.
To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:
R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.0.1 0 0 65301 i
*> 2.2.2.2/32 192.168.0.1 0 0 65301 i
*> 3.3.3.3/32 192.168.0.1 0 0 65301 i
Total number of prefixes 3
-> routes – Display routes learned from neighbor
The output is what exists in the Loc-RIB table, after processed by the inbound policy.
Let me show you an example of the above explanation.
I’ll apply the “soft-reconfiguration inbound” first:
R2(config-router)#neighbor 192.168.0.1 soft-reconfiguration inbound
Now I’ll check again the received routes:
R2#sh ip bgp neighbors 192.168.0.1 received-routes | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.0.1 0 0 65301 i
*> 2.2.2.2/32 192.168.0.1 0 0 65301 i
*> 3.3.3.3/32 192.168.0.1 0 0 65301 i
Total number of prefixes 3
OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):
R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.0.1 0 0 65301 i
*> 2.2.2.2/32 192.168.0.1 0 0 65301 i
*> 3.3.3.3/32 192.168.0.1 0 0 65301 i
Total number of prefixes 3
The Adj-RIB-in and Loc-RIB tables are identical.
Now, I’ll apply an inbound policy that will filter the 3.3.3.3 prefix.
R2(config)#ip prefix-list LIST permit 3.3.3.3/32 R2(config)#route-map INBOUND deny 10 R2(config-route-map)#match ip address prefix-list LIST R2(config-route-map)#route-map INBOUND permit 1000 R2(config-route-map)#router bgp 65302 R2(config-router)#neighbor 192.168.0.1 route-map INBOUND in
OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the 3.3.3.3 prefix.
R2#sh ip bgp neighbors 192.168.0.1 received-routes | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.0.1 0 0 65301 i
*> 2.2.2.2/32 192.168.0.1 0 0 65301 i
* 3.3.3.3/32 192.168.0.1 0 0 65301 i
The above output is what we receive from BGP peer. Notice that the 3.3.3.3 prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).
R2#sh ip bgp neighbors 192.168.0.1 routes | b Net
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 192.168.0.1 0 0 65301 i
*> 2.2.2.2/32 192.168.0.1 0 0 65301 i
Now we can see that the inbound policy is working fine as the 3.3.3.3 prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the 3.3.3.3 prefix in Adj-RIB-in.
I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.
Please let me know in Comments if you have any questions.
