BGP Extended Access-List Filtering

Topology attached

Hi Shady,

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.

Rene

Hi, Rene.

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?

Hi @stlourenco,

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).

Hi Rene,

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> 20.0.0.0         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.

Thanks
Walid

Hello Walid

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!

Laz

Hi Laz,

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
20.20.20.0/24      2.2.2.2                      Input filter              n/a

why the input filter prevents the route from installing it in the routing table?

Thanks,
Walid

Hi Walid,

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
 *>   20.0.0.0         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 20.0.0.0/8 (0x0)  :
    via 192.168.12.2   0 1048577

RT: add 20.0.0.0/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 20.0.0.0 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.

Rene

Hi Rene,

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,
Walid

Hi Walid,

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.

Rene

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.

Hello Elias

Here’s a screenshot of the text in question:

image

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.

Thanks!

Laz

Hi Laz,

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.

Hello Elias

My apologies, I found it. This is the issue:

image

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.

Laz

1 Like

Hi Elias, Thanks for letting us know. I just fixed this.

Rene

1 Like

Hi
i advertised this network but
i didnt see them
20.0.0.0
30.0.0.0
it can be that you didnt use mask for them

Hello Bahri

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 20.0.0.0 255.0.0.0 and 30.0.0.0 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!

Laz

Hi,
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.

Hi Dmitriy,

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.

Rene

1 Like

Thank you for replying! And thank you for these materials, they are awesome.

1 Like