Distribute-list filtering in BGP

Contents

Intro

Distribute-list filtering in BGP is used to filter incoming or outgoing routing updates based on the network specified in an ACL. I’ll show you how to do this so you can control which routes are advertised to or received from BGP peers.

Topology

Topology diagram showing BGP distribute list filtering with three routers: R1 in AS1, R2 and R3 in AS23.
The last octet is the router number unless specified otherwise. Example: R1's G0/1 is 10.10.12.1/24. Don't forget to download the EVE-NG topology file for this tutorial below.

Initial Configs

Configuration Steps

1. Configure Basic BGP

The first thing I’ll do is get all of the BGP peerings up using their respective AS numbers.

R1:

router bgp 1
 neighbor 10.10.12.2 remote-as 23

R2:

router bgp 23
 neighbor 10.10.12.1 remote-as 1
 neighbor 10.10.23.3 remote-as 23

R3:

router bgp 23
 neighbor 10.10.23.2 remote-as 23

After a few seconds a message pops up on the console letting me know the neighbors are up.

R1:

%BGP-5-ADJCHANGE: neighbor 10.10.12.2 Up

R2:

%BGP-5-ADJCHANGE: neighbor 10.10.12.1 Up 
%BGP-5-ADJCHANGE: neighbor 10.10.23.3 Up

R3:

%BGP-5-ADJCHANGE: neighbor 10.10.23.2 Up

The peerings on all 3 routers are up. The next thing I’ll do is create two loopback interfaces on R1. Loopback1 with an IP of 1.1.1.1/24  and Loopback11 with an IP of 11.11.11/24 and Looback111 with an IP of 111.111.111.0/24. After that I’ll advertise them into BGP on R1. These will be the test networks I’ll use to permit or deny with the distribute-list.

R1:

interface Loopback1
 ip address 1.1.1.1 255.255.255.0

interface Loopback11
 ip address 11.11.11.1 255.255.255.0

interface Loopback111
ip address 111.111.111.1 255.255.255.0

router bgp 1
 network 1.1.1.0 mask 255.255.255.0
 network 11.11.11.0 mask 255.255.255.0
 network 111.111.111.0 mask 255.255.255.0

These prefixes should be sent by R1 to the routers in AS23. Let me verify by using the show ip bgp command on R2 and R3.

These prefixes should be advertised by R1 to its peer R2 which lives in AS23. Let me verify this from R1’s perspective by using the sh ip bgp neighbors 10.10.12.2 advertised-routes.

R1#sh ip bgp neighbors 10.10.12.2 advertised-routes
BGP table version is 10, local router ID is 10.10.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
 *>   1.1.1.0/24       0.0.0.0                  0         32768 i
 *>   11.11.11.0/24    0.0.0.0                  0         32768 i
 *>   111.111.111.0/24 0.0.0.0                  0         32768 i

Total number of prefixes 3

I can see in the above output R1 is advertising the 3 prefixes to R2. Let me confirm the BGP tables on R2 and R3 have these prefixes as well.

R2#sh ip bgp
BGP table version is 10, local router ID is 10.10.23.2
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
 *>   1.1.1.0/24       10.10.12.1               0             0 1 i
 *>   11.11.11.0/24    10.10.12.1               0             0 1 i
 *>   111.111.111.0/24 10.10.12.1               0             0 1 i
R3#sh ip bgp
BGP table version is 1, local router ID is 10.10.23.3
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
 * i  1.1.1.0/24       10.10.12.1               0    100      0 1 i
 * i  11.11.11.0/24    10.10.12.1               0    100      0 1 i
 * i  111.111.111.0/24 10.10.12.1               0    100      0 1 i

Both R2 and R3 which live in AS23 have the prefixes in their BGP table. Now I’ll show you how to configure a distribute-list to only allow the 1.1.1.1/24 prefix into BGP in AS23. 

2. Distribute-list in the outbound direction

First I’ll create a standard ACL on R1 to specify what prefixes should be allowed or denied. Keep in mind that there is an implicit deny at the end of an ACL. Anything that’s not permitted is getting denied. 

R1:

access-list 10 permit 1.1.1.0 0.0.0.255

This ACL permits the source network 1.1.1.0/24. Any prefixes that don’t match this network will get denied by the implicit deny at the end of the ACL. The ACL is created but it doesn’t do anything unless I reference it in a distribute-list in BGP. I’ll show you this now .

R1:

router bgp 1
 neighbor 10.10.12.2 distribute-list 10 out

The distribute list is applied to the neighbor 10.10.12.2 in the outbound direction and it references access-list 10. Any prefixes in a BGP update will have to go through this distribute-list before being sent outbound to R2. I’ll recheck what R1 is sending to R2 by using the same show ip bgp neighbors advertised routes command. 

Don't forget to do a clear ip bgp * soft on R1 to speed things up. 
R1#sh ip bgp neighbors 10.10.12.2 advertised-routes
BGP table version is 10, local router ID is 10.10.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
 *>   1.1.1.0/24       0.0.0.0                  0         32768 i

Total number of prefixes 1

R1 is now only sending the 1.1.1.0/24 prefix to R2. The other 2 prefixes don’t match our ACL so they get denied. I’ll check the BGP tables of R2 and R3 to be 100 percent sure. 

R2#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.0/24       10.10.12.1               0             0 1 i
R3#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 * i  1.1.1.0/24       10.10.12.1               0    100      0 1 i

The routers in AS23 only have the 1.1.1.0/24 prefix. 

If you want to see the counters on the ACL you can check this on R1 by using the show access-list command. 

R1#sh access-lists 
Standard IP access list 10
    10 permit 1.1.1.0, wildcard bits 0.0.0.255 (2 matches)

The counters in the above output show how many times a BGP UPDATE message that contained the 1.1.1.0/24 prefix was sent outbound from R1 to R2.

3. Distribute-list in the inbound direction

Instead of configuring the distribute-list outbound on R1, I can configure it inbound on R2. This is helpful if for some reason I don’t have access to R1 or you’re in a CCIE lab and there are routers you’re not allowed to touch. Let me remove the distribute-list on R1 and make sure all the prefixes show up back to normal on R2 and R3.  

R1:

router bgp 1
 no neighbor 10.10.12.2 distribute-list 10 out

With the distribute-list removed, I’ll do a quick check of the BGP tables on R2 and R3. 

R2#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.0/24       10.10.12.1               0             0 1 i
 *>   11.11.11.0/24    10.10.12.1               0             0 1 i
 *>   111.111.111.0/24 10.10.12.1               0             0 1 i

R3#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 * i  1.1.1.0/24       10.10.12.1               0    100      0 1 i
 * i  11.11.11.0/24    10.10.12.1               0    100      0 1 i
 * i  111.111.111.0/24 10.10.12.1               0    100      0 1 i

Everything is back to normal. Now on R2, I’ll configure the same ACL and distribute-list that permits 1.1.1.0/24 and denies the rest of the prefixes. 

R2:

access-list 10 permit 1.1.1.0 0.0.0.255

router bgp 23
 neighbor 10.10.12.1 distribute-list 10 in

The ACL that permits the 1.1.1.0/24 network is created and I applied the distribute list to the 10.10.12.1 neighbor in the inbound direction. Prefixes that come inbound from R1 that aren’t permitted in the ACL get denied, let’s check the BGP table of R2 and R3. 

R2#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>   1.1.1.0/24       10.10.12.1               0             0 1 i

R3#show ip bgp | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 * i  1.1.1.0/24       10.10.12.1               0    100      0 1 i

You can see in the above output that the prefixes that made it past R2’s inbound distribute-list made it into R2 and R3’s BGP table. In this case it’s only the 1.1.1.0/24 network.

That’s how you can use distribute-list filtering in BGP. We did it outbound on R1 and then inbound on R2 to show you it works either way. If it’s up to me I would just do the filtering outbound on R1. The logic is if R2 is not supposed to have certain prefixes, then don’t send them across the link anyway just block them on R1 before they travel outboud.

I hope you enjoyed the tutorial, if you have any questions please let me know. Don’t forget to download the EVE-NG topology file and practice it on your own. 

EVE-NG Lab File

To download the EVE-NG topology file you'll need to be a member. You can register here, it's free! It will be right here once you log in.

Full Configs

Here are the full configs from all routers if you want to try it out yourself.

Discussion

You need to be a member if you want to use or view the support forum. Register here, it's free.