Hello Elias
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.
Laz
Hello Elias
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.
Laz
Hi Elias, Thanks for letting us know. I just fixed this.
Rene
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
Thank you for replying! And thank you for these materials, they are awesome.
If it helps anyone trying to understand this, here is how i visualised it in my own head when working it out, i split the image into two pieces.
Your using a wildcard mask to say which part of the network you want to match (purple)
Your then using a wildcard mask to say which part of the subnet mask you want to match (red)
In this lesson you reference prefix-list filtering, but in the ENCOR course track, that lesson is missing from the side menu. I think this is what is missing:
Thanks @rpgoeke , I just added it.
Rene
Hi,
I think there’s a typo in the below header:
1.8 Filter 172.16.0.0 networks with a /27 to /32 prefix length
should read
1.8 Filter 172.16.X.X networks with a /27 to /32 prefix length
Thanks,
Sam
hello Samir
Thanks for pointing that out, I’ll let Rene know to take a look…
Laz
I agree @samirkhair , I just changed this. Thanks!
Rene
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:
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:
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
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:
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!!