BGP Extended Access-List Filtering

Hi Rene,
Please help explain on the access list below, especially
host 255.255.255.255, and host 255.255.255.128
It is ‘host’ instead of ‘Subnet Mask’ follow by ‘Subnet Mask Wildcard’

ip access-list extended ACL-ALLOW
 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.255 
 permit ip 100.64.0.0 0.0.255.0 host 255.255.255.128

router bgp 65100
 bgp log-neighbor-changes
 neighbor 10.12.1.2 remote-as 65200
 !
 address-family ipv4
  neighbor 10.12.1.2 activate
  neighbor 10.12.1.2 distribute-list ACL-ALLOW in
 exit-address-family

Can the access list also be written as:

ip access-list extended ACL-ALLOW
permit ip 192.168.0.0 0.0.255.255 255.255.255.255 0.0.0.0
permit ip 100.64.0.0 0.0.255.0 255.255.255.128 0.0.0.127

Hello Kenneth

In this example here, the access list is being used in conjunction with a distribution list The distribute-list is referencing the access list in the distribute-list 100 in command. In particular, when an extended access list is called by a distribute-list, the actual IP addresses and subnet masks have a different meaning.

In such a scenario, the ACL is not matching source and destination pairs, but addresses and subnet masks. So the following ACL command:

R1(config)#access-list 100 permit ip 20.0.0.0 0.0.0.0 255.0.0.0 0.0.0.0

when referenced by a distribute list is saying:

  • I want to match 20.0.0.0 exactly as the IP address
  • I want to match 255.0.0.0 exactly as the subnet mask

The “exactly” comes from the 0.0.0.0. If the command was:

R1(config)#access-list 100 permit ip 20.0.0.0 255.255.255.0 255.0.0.0 0.0.0.0

then what it’s saying is:

  • I want to match any IP address between 20.0.0.0 to 20.0.0.255
  • that has a subnet mask that matches 255.0.0.0 exactly

When you see the output of the show access-lists 100 command, it uses the ACL syntax of “host” wherever it sees the 0.0.0.0, and that’s why it can be confusing in the context of a distribute-list.

What that output is actually saying is that it will match 20.0.0.0 exactly as the IP address, and 255.0.0.0 exactly as the subnet mask.

For more info on how extended ACLs and distribute-lists interact, take a look at this link:

I hope this has been helpful!

Laz

2 Likes

Are these 2 extended access list ACL-ALLOW below the same (filtering the same networks)?

ip access-list extended ACL-ALLOW
permit ip 192.168.0.0 0.0.255.255 host 255.255.255.255
permit ip 100.64.0.0 0.0.255.0 host 255.255.255.128

ip access-list extended ACL-ALLOW
permit ip 192.168.0.0 0.0.255.255 255.255.255.255 0.0.0.0
permit ip 100.64.0.0 0.0.255.0 255.255.255.128 0.0.0.0

Hello Kenneth

Yes, the access lists you have stated are the same. The host keyword has the same effect as placing a subnet mask of 0.0.0.0.

Similarly the following two ACL statements are the same:

  • permit ip host 10.10.10.5
  • permit ip 10.10.10.5 0.0.0.0

Both commands are saying that the 10.10.10.5 address must be matched exactly as a single IP address, or in other words, the IP address of a specific host.

You can find out more about the host keyword and other aspects of ACLs at the following lesson:

But always remember, the extended ACL, used in conjunction with distribute-lists has a different definition, as described in the previous post.

I hope this has been helpful!

Laz

Hello Rene/Lazaros

This access list is what I utilized to permit the listed prefixes below to allow 10.1-10.8 with masks ranging for /24 to /28

access-list 101 permit ip 10.0.0.0 0.15.255.255 255.255.255.0 0.0.0.240
10.0.0.0/24      
10.1.0.0/24      
10.2.0.0/24     
10.3.0.0/25      
10.3.0.128/25    
10.4.0.0/25      
10.4.0.128/25    
10.5.0.0/26      
10.6.0.0/27      
10.7.0.0/28      
10.8.1.0/24      
10.8.2.0/24

I’m confused as to why using a wildcard value of 0.0.0.240 worked instead of 0.0.0.15

Hello Germaine

It seems that extended access lists accept any dotted decimal value as the wildcard mask. At first, I found that strange, but I did some labbing and found that any value between 0.0.0.0 and 255.255.255.255 is accepted as the wildcard mask. In addition, the Cisco command reference simply says that a wildcard mask indicates which bits to ignore (1) and which bits must match (0). It doesn’t require you to have a contiguous stream of ones or zeros. They can be mixed and matched. This is why the wildcard mask of 0.0.0.240 was accepted.

Almost all uses of wildcard masks tend to be in the format of contiguous zeros and then ones. For example 0.0.0.15 which is 00000000.00000000.00000000.00001111 in binary. Such a wildcard mask will match the first 28 bits, which is where the zeros are, and will ignore the last four bits.

If you use a wildcard mask such as 0.0.0.240, which is 11111111.11111111.11111111.11110000 in binary, it will simply match the last four bits, where the zeros are.

Now in your case, when used with BGP, the subnet mask and the subnet mask wildcard are:

  • 255.255.255.0
  • 0.0.0.240

In binary those are:

  • 11111111.11111111.11111111.00000000
  • 11111111.11111111.11111111.11110000

What that is saying is that anywhere where there is a zero, it should remain the same. Thus, any subnet mask that has the final four bits “0000” is acceptable.

The subnet masks used in your list of prefixes are /24, /25, /26, /27, and /28. All five of these subnet masks have the last four bits set to 0, so they are all matched. Thus they are permitted, thus, the access list works. However, if you added the prefix 10.8.3.0/29, this would not be matched.

So the wildcard mask you used, although typically incorrect, will still allow the specific list of prefixes, and that is why they worked. However, the result can be unpredictable, so it is best to use the wildcard mask in its normal format.

I hope this has been helpful!

Laz

Laz, thank you so much for taking the time to provide a detailed explanation!! I’m on my way to getting my CCNP and networklessons.com has been undoubtedly pivotal to my growth as a network engineer! Kudos to you and Rene!!

Hello Germain

Thanks so much for your kind words! It is a pleasure to help out. I wish you success in your exam and in your career, and as always, we’ll be here to help along the way.

Laz

is it just me or are prefix lists much more clear than this? access-list 105 permit ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.255. I suppose we are trying to match a range of ips, but man this statement makes my eyes hurt. Also, Can someone explain what exactly this means?

I get what is going on. I wish this way didn’t exist. Prefix lists have to be more clear. Is there a conceivable reason this would be used in real life? I mean I am grateful you show it here because knowing it exists is valuable in itself, but yikes!

Hello Justin

Take a look at this post for more details:

This particular behavior exists only when ACLs are called by distribution lists.

It can be difficult to get your head around, however once you get proficient in its use, it becomes clearer and easier to apply.

Note the following comment from Rene’s lesson:

Nowadays we use prefix-lists to filter BGP prefixes. Prefix-lists are very convenient since they allow you to specify a network address with a specific prefix length or a range of prefix lengths. Back in the days, before prefix-lists existed on Cisco IOS you had to use extended access-lists for this.

You really don’t want to use these anymore since the prefix-list does the same thing and the configuration is much easier. However, when you face a CCIE lab it might be possible that a task requires you to filter certain prefixes but you are not allowed to use the prefix-list. The extended access-list will be your only option then…

So don’t use them in a production network, but keep in mind that they exist, and be prepared to use them in a CCIE lab.

I hope this has been helpful!

Laz

This method won’t work, I assume ?

R1(config)#ip access-list  extended ACL-LIMIT-R2-NETWORKS
R1(config-ext-nacl)#permit ip 172.16.0.0 0.0.255.255 255.255.255.0 0.0.0.0
R1(config-ext-nacl)#router bgp 1
R1(config-router)#distribute-list ACL-LIMIT-R2-NETWORKS IN
% The ACL cannot be created or an ACL with the same name but incompatible type already exists.
R1(config-router)#

Hello Mathew

It seems that distribute-lists do not support named extended ACLs in some IOS versions. I have found that I get the same error as you in my lab as well. My version is:

Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.9(3)M4, RELEASE SOFTWARE (fc3)

I find that I am able to successfully create the distribute-list with a numbered ACL, and also with a standard named ACL, but not an extended named ACL. The same is true for distribute lists for EIGRP and OSPF as well.

This seems to be the case for some versions of IOS while not for others.

I hope this has been helpful!

Laz

Rene Absolutely amazing explanation !

1 Like

It was a great explanantion. Thank you!

Could you please explain Outbound Route Filtering (ORF)?

Hello Sai

Thanks for the question, this is a great one. I have created a NetworkLessons Note on the topic here.

I hope this has been helpful!

Laz

Is there a way to allow an ASA to learn 0.0.0.0/0 using BGP to route all internet traffic down a VPN VTI for a single device or all devices on the Lan?

Hello Brian

BGP can be used to inform the ASA of a default route regardless of whether it is via a VPN VTI or via a normal physical interface.

To find out more about how you can advertise a default route using BGP, take a look at this NetworkLessons note titled “BGP advertising a default route”.

I hope this has been helpful!

Laz

Hi Lazaros,

That is very helpful. Thank you very much. I appreciate it!

1 Like

Hi the lecture is informative, but the explanation of /26 to /32 prefix length and /27 to /32 prefix length are very confusing to me. For /26 to /32 prefix length example, shouldn’t be the 4th octet’s last six bits don’t care, the first two bits have to match? Because the difference between /26 to /32 is the last six bits.
For /27 to /32 prefix length example, wildcard of 0.0.0.31 4th octet has 5 ones and 3 zeros, so I don’t know why we only checked the last four bits (“and the last four bits of the 4th octet”). And why 255.255.255.192 should be included in this example? I thought 255.255.255.192 is mask of /26.

Hello Tracy

When you filter “anything between two different prefix lengths” you have to indicate:

  1. The initial prefix length
  2. The wildcard bits that can change

When we say we want to filter anything with a /24 to /32 prefix length, we must first indicate:

  1. The /24 prefix length. This is indicated using the following subnet mask in binary:

11111111.11111111.11111111.00000000 which is 255.255.255.0

  1. The wildcard bits that will indicate that we can have any value. In this case, we want to indicate that the last 8 bits of the subnet mask can have any value, so we would use a wildcard mask of:

00000000.00000000.00000000.11111111 which is 0.0.0.255

This means that when we match that up with the subnet mask, the bold digits can be anything.

11111111.11111111.11111111.00000000
00000000.00000000.00000000.11111111

This means that we can have any of the following possibilities:

11111111.11111111.11111111.00000000
11111111.11111111.11111111.10000000
11111111.11111111.11111111.11000000
11111111.11111111.11111111.11100000
11111111.11111111.11111111.11110000
11111111.11111111.11111111.11111000
11111111.11111111.11111111.11111100
11111111.11111111.11111111.11111110
11111111.11111111.11111111.11111111

That is a range between /24 and /32.

Similarly, for ranges between /26 and /32 we have the following subnet mask and subnet mask wildcard:

11111111.11111111.11111111.11000000
00000000.00000000.00000000.00111111

In this case we have the following ranges of allowed subnet masks:

11111111.11111111.11111111.11000000
11111111.11111111.11111111.11100000
11111111.11111111.11111111.11110000
11111111.11111111.11111111.11111000
11111111.11111111.11111111.11111100
11111111.11111111.11111111.11111110
11111111.11111111.11111111.11111111

Now for the case where we are filtering to match 172.16.x.x networks with a /27 to /32 prefix length, we do the same thing, where we use a subnet mask of 255.255.255.224, which is /27, and we use a wildcard mask of 0.0.0.31 to indicate a range of /27 to /32. In binary this looks like this:

11111111.11111111.11111111.11100000
00000000.00000000.00000000.00011111

So the actual extended access list will filter the following:

Any network of 172.16.0.0 with a subnet mask that ranges between /27 to /32.

You are correct. That should state, “the first three octets as well as the last five bits of the 4th octet must match.” Also, 255.255.255.192 should not be included. I will let Rene know to make the changes.

I hope this has been helpful!

Laz