If you want to enforce one path for outgoing traffic from AS 1 to AS 2 then it’s best to influence the attributes. Don’t let the router ID decide it. If you want to do this for the entire AS, it’s best to configure local preference inbound on R1 and/or R3.
I’m replicating this same scenario in GNS3 and even applying the filters to some specific routes, I lose all routes from the routing table and in the BGP table. Why is this so?
It is difficult to tell without seeing your prefix-list or the configuration. There might be an error in your prefix-list or you refer to the wrong one in your BGP configuration (which will deny everything).
can you explain the reason that the result of “show ip bgp” on R1 is giving the symbol ‘r’ beside the received prefixes from R2?
R1#show ip bgp BGP table version is 4, local router ID is 192.168.12.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path r> 18.104.22.168 192.168.12.2 0 0 2 i r> 172.16.0.0/24 192.168.12.2 0 0 2 i r> 192.168.1.0 192.168.12.2 0 0 2 i
I have tried it in a LAB and gave me the same result and these subnets were not reachable from R1.
The r indicates an RIB failure, that is a failure of the Routing Information Base. IN other words, this route was not added to the routing table. The reason for which that network has not been installed can be determined using the
show ip bgp rib-failure on the router. It should give you an idea of why the specific route was not installed in the routing table.
Because it failed to be installed in the routing table it does not stop the BGP process from advertising the route to other BGP peers. It could be that an IGP routing protocol provided a route to the destination, and since all IGP protocols have an administrative distance smaller than that of BGP, these routes failed to be inserted.
I hope this has been helpful!
thanks for clarification, but the matched prefixes in the access-list were already installed in the routing table before applying the access-list which means that it was preferred from the BGP and no other IGP was competing with BGP so my question is why the RIB Failure occurs although it was not appearing before?
I have tried to know the reason behind the RIB Failure by using the command show ip bgp rib-failure and the reason was the input filter as below:
R1#sh ip bgp rib-failure Network Next Hop RIB-failure RIB-NH Matches 22.214.171.124/24 126.96.36.199 Input filter n/a
why the input filter prevents the route from installing it in the routing table?
I just labbed this up again and I’m getting the same RIB failures. If you enable a debug, you can see the reason:
R1#debug ip routing IP routing debugging is on
This shows up when you clear the routing table or clear the BGP neighbor adjacency:
RT: rib validate nexthop return code: 3 RT: rib validate nexthop return code: 3 RT: rib validate nexthop return code: 3
Return code 3 means the prefix is filtered because of an access-list. This one got me scratching my head for a bit…
The weird thing is, the access-list seems to be correct. They use the exact same example here:
After some tests, it seems that R1 denies the next hop IP address. If you add a statement like this:
R1(config)#access-list 100 permit ip host 192.168.12.2 any
Then it works:
R1#show ip bgp BGP table version is 4, local router ID is 192.168.12.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 188.8.131.52 192.168.12.2 0 0 2 i *> 172.16.0.0/24 192.168.12.2 0 0 2 i *> 192.168.1.0 192.168.12.2 0 0 2 i
You can see it in the debug too:
R1#clear ip route * RT: updating bgp 184.108.40.206/8 (0x0) : via 192.168.12.2 0 1048577 RT: add 220.127.116.11/8 via 192.168.12.2, bgp metric [20/0] RT: updating bgp 172.16.0.0/24 (0x0) : via 192.168.12.2 0 1048577 RT: add 172.16.0.0/24 via 192.168.12.2, bgp metric [20/0] RT: updating bgp 192.168.1.0/24 (0x0) : via 192.168.12.2 0 1048577 RT: add 192.168.1.0/24 via 192.168.12.2, bgp metric [20/0]
And a match on the access-list:
R1#show access-lists Extended IP access list 100 10 permit ip host 18.104.22.168 host 255.0.0.0 (3 matches) 20 permit ip host 172.16.0.0 host 255.255.255.0 (3 matches) 30 permit ip host 192.168.1.0 host 255.255.255.0 (3 matches) 40 permit ip host 192.168.12.2 any (9 matches)
It’s strange and this doesn’t seem to be documented. Anyway, after adding it, it works.
thanks for your effort and explanation, it seems to be a software version error as I tried it again on an IOS XE router and it worked fine with your configuration.
Thanks for sharing that. I was wondering if it was related to platform/ IOS version. I originally wrote this article using IOS 12.4T and yesterday I tried it on IOS 15.x. Funny that it’s different on IOS XE.
Seems there is a typo:
R1(config)#access-list 100 permit ip 172.16.0.0 0.0.0.0 255.255.255.0 0.0.0.0
In the text you mention /16 so in the config example the subnet mask is incorrect.
Here’s a screenshot of the text in question:
It seems the text indicates a /24 subnet mask which is what is found in the access list. Unless I’m missing something… Please clarify when you get a chance.
It’s the text right below that screenshot:
“In the second entry we want an exact match for “172.16.0.0” so we use network 172.16.0.0 with wildcard 0.0.0.0. The prefix-length has to be exactly /16 so we use subnet mask 255.255.0.0 with wildcard 0.0.0.0.”
But indeed it would make sense to change that part to /24 and 255.255.255.0 instead so it all matches up.
My apologies, I found it. This is the issue:
That should read “The prefix length has to be exactly /24 so we use subnet mask 255.255.255.0 with…”
Thanks for that, I’ll let Rene know.
Hi Elias, Thanks for letting us know. I just fixed this.
i advertised this network but
i didnt see them
it can be that you didnt use mask for them
In order for BGP to advertise a route, that route must exist in the routing table of the device. The route must match exactly, that is both the network address and the subnet mask. If there is no subnet mask in the routes that you advertised, as you mention above, then the classfull mask will be used. In this case it would be 255.0.0.0. So if the 22.214.171.124 255.0.0.0 and 126.96.36.199 255.0.0.0 networks are in the routing table, then they will be advertised.
If you are following the configs in the lesson, then these should indeed be advertised as the subnet mask is in fact 255.0.0.0, the classful mask,.
I hope this has been helpful!
I have a question about “Filter anything with a /26 to /32 prefix length”.
Here is the access list:
R1(config)#access-list 106 permit ip 0.0.0.0 255.255.255.255 255.255.255.192 0.0.0.63
In your explanation, you are saying
“We want to match all prefixes from /26 to /32, by using this wildcard we tell the router that the last four bits have to match, we don’t care about the first four bits.”
If the wildcard mask for prefixes is 0.0.0.63, why is it responsible for 4 bits? Doesn’t it cover last 6 bits? Please explain.
Thanks in advance.
You are correct, this is a type. A wildcard of 0.0.0.63 means the last six bits match and we ignore the first two bits.
Thanks! Just fixed this.
Thank you for replying! And thank you for these materials, they are awesome.