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