Why this Access list only match this IPs

amb1s1

I have R1 has eigrp neighbor with R2 and I have an access-list that block some of the prefix coming from R2 to R1.

Here is the R1 Ip route eigrp output before an access-list
D 192.168.1.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.2.0/24 [90/130816] via 173.35.33.100, 00:00:13, Vlan999
D 192.168.5.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.6.0/24 [90/130816] via 173.35.33.100, 00:00:13, Vlan999
D 192.168.7.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.8.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.9.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.10.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999

Here is the output with an access list and distribute-list
D 192.168.2.0/24 [90/130816] via 173.35.33.100, 00:02:30, Vlan999
D 192.168.6.0/24 [90/130816] via 173.35.33.100, 00:02:30, Vlan999

Here is the Access-list on R1
access-list 1 permit 192.168.2.0 0.0.4.255

Distribute-list:
router eigrp 9999
distribute-list 1 in
network 173.35.33.33 0.0.0.0

My question is why is blocking 192.168.5.0 from been in R1 ip route? I thought that 192.168.2.0 0.0.4.255 will catching the 192.168.5.0 network. I know that I must been missing something. Thanks in advance

smcclenaghan

at a glance, shouldn't you be using 0.0.3.255 instead of 0.0.4.255?

amb1s1

If I do that I only match these routes:
D 192.168.1.0/24 [90/130816] via 173.35.33.100, 00:00:47, Vlan999
D 192.168.2.0/24 [90/130816] via 173.35.33.100, 01:52:54, Vlan999

Which, I'm more confused.

theodoxa

#1 - As stated it should be 0.0.3.255
#2 - The prefix/subnet address is wrong, though I suspect IOS will silently correct it to 192.168.0.0

access-list 1 permit 192.168.0.0 0.0.3.255

theodoxa

amb1s1 wrote: »

If I do that I only match these routes:
D 192.168.1.0/24 [90/130816] via 173.35.33.100, 00:00:47, Vlan999
D 192.168.2.0/24 [90/130816] via 173.35.33.100, 01:52:54, Vlan999

Which, I'm more confused.

That is correct. Your ACL should only match addresses between 192.168.0.0 and 192.168.3.255. Those are the only two subnets in that range.

theodoxa

If you change it to 192.168.0.0 0.0.7.255 you should see the following 3 routes [in addition to the 2 existing routes]:

D 192.168.5.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999
D 192.168.6.0/24 [90/130816] via 173.35.33.100, 00:00:13, Vlan999
D 192.168.7.0/24 [90/130816] via 173.35.33.100, 00:00:03, Vlan999

You would need either 192.168.0.0 0.0.15.255 or multiple permit statements to cover all your subnets.

amb1s1

But why this access-list(access-list 1 permit 192.168.2.0 0.0.4.255) is not catching the 192.168.5.0 network? if it is catching the 192.168.6.0 network

theodoxa

amb1s1 wrote: »

But why this access-list(access-list 1 permit 192.168.2.0 0.0.4.255) is not catching the 192.168.5.0 network? if it is catching the 192.168.6.0 network

The Wildcard Mask. Normally, a Wilcard mask would be all 1s from some point to the end with no interleaved zeroes. But, in this case there are zeroes interleaved between ones.

The correct mask would be:

00000000.00000000.00000011.11111111

Notice that there are no zeroes in between any of the ones. The result is that all matches will be consecutive.

But, your mask is:

00000000.00000000.00000100.11111111

Because there are zeroes interleaved between ones, the matches won't necessarily be consecutive.

11000000.10101000.00000010.00000000 (192.168.2.0)
11111111.11111111.11111011.00000000 (255.255.251.0 - Subnet Mask matching the WC Mask of 0.0.4.255)

---

11000000.10101000.00000010.00000000 (192.168.2.0)

The first problem is that the incorrect subnet address + incorrect mask results in an incorrect result when ANDED together. So, it is incorrectly starting at 192.168.2.0 instead of 192.168.0.0. Then, the interleaved zeroes cause the ACL to match non-consecutive subnets.

Apparently, this is something they actually want you to be able to do [intentionally] on the CCIE. But, at the CCNA/CCNP level, we never use masks with interleaved zeroes.

Steven’s Technical Blog » ACL Maths
Binary Math - Part I
Binary Math, Part II
CCIE Practical Studies, Volume I | Access Lists, Wildcard Masks, and Binary Math | InformIT

It took a little digging to find the actual algorithm used to test ACLs, but here goes:

(Test_IP_Address|| Wildcard_Mask) == (Prefix || Wildcard_Mask)

For 192.168.2.0, the Prefix and Test Address are the same, so they will always match.

11000000.10101000.00000010.00000000 (192.168.2.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000110.11111111 (192.168.6.255)

Let's try 192.168.5.0

11000000.10101000.00000101.00000000 (192.168.5.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000101.11111111 (192.168.5.255) NOT A MATCH

Let's move on to 192.168.6.0:

11000000.10101000.00000110.00000000 (192.168.6.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000110.11111111 (192.168.6.255) MATCH!!!

FloOz

If you want the access list to cover all the routes in R1's table you will need to use a wildcard mask of 0.0.15.255

instant000

Yes, the interleaved zeroes are expected in ACLs at the IE level. Not just the lab though, prepare for them in the Written, too.

Binary Math - Part I
Binary Math - Part I Answers
Binary Math, Part II
Binary Math - Part II Answers

Please note that if you really understand how the math works, no problem can catch you off guard. It will be EASY points on test day.

EDIT: Oops, someone already posted the Scott Morris stuff!

Hope this helps!

amb1s1

theodoxa wrote: »

The Wildcard Mask. Normally, a Wilcard mask would be all 1s from some point to the end with no interleaved zeroes. But, in this case there are zeroes interleaved between ones.

The correct mask would be:

00000000.00000000.00000011.11111111

Notice that there are no zeroes in between any of the ones. The result is that all matches will be consecutive.

But, your mask is:

00000000.00000000.00000100.11111111

Because there are zeroes interleaved between ones, the matches won't necessarily be consecutive.

11000000.10101000.00000010.00000000 (192.168.2.0)
11111111.11111111.11111011.00000000 (255.255.251.0 - Subnet Mask matching the WC Mask of 0.0.4.255)

---

11000000.10101000.00000010.00000000 (192.168.2.0)

The first problem is that the incorrect subnet address + incorrect mask results in an incorrect result when ANDED together. So, it is incorrectly starting at 192.168.2.0 instead of 192.168.0.0. Then, the interleaved zeroes cause the ACL to match non-consecutive subnets.

Apparently, this is something they actually want you to be able to do [intentionally] on the CCIE. But, at the CCNA/CCNP level, we never use masks with interleaved zeroes.

Steven’s Technical Blog » ACL Maths
Binary Math - Part I
Binary Math, Part II
CCIE Practical Studies, Volume I | Access Lists, Wildcard Masks, and Binary Math | InformIT

It took a little digging to find the actual algorithm used to test ACLs, but here goes:

(Test_IP_Address|| Wildcard_Mask) == (Prefix || Wildcard_Mask)

For 192.168.2.0, the Prefix and Test Address are the same, so they will always match.

11000000.10101000.00000010.00000000 (192.168.2.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000110.11111111 (192.168.6.255)

Let's try 192.168.5.0

11000000.10101000.00000101.00000000 (192.168.5.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000101.11111111 (192.168.5.255) NOT A MATCH

Let's move on to 192.168.6.0:

11000000.10101000.00000110.00000000 (192.168.6.0)
00000000.00000000.00000100.11111111 (0.0.4.255)

---

11000000.10101000.00000110.11111111 (192.168.6.255) MATCH!!!

This was exactly what I was looking for. I took the CCIE CIERS1 bootcamp and in the lab I was stuck on the answer where the ask for matching only 192.168.2.1 and 192.168.6.1. Thanks I understand now

W Stewart

Weird, I'm used to working with ASAs at work and all of our access lists use the subnet mask rather than a wild card mask.

RouteMyPacket

W Stewart wrote: »

Weird, I'm used to working with ASAs at work and all of our access lists use the subnet mask rather than a wild card mask.

That's because us Security cats are cool like that. ha Both are easy, now the interleaving is something entirely different all together. Ugh. I will cross that bridge when the time comes

theodoxa

W Stewart wrote: »

Weird, I'm used to working with ASAs at work and all of our access lists use the subnet mask rather than a wild card mask.

I seem to remember reading that IOS will silently change a subnet mask to the corresponding wildcard mask in some cases. Probably works the same way on an ASA.

xXErebuS

What messes me up on the asa is I try to type show ip access-list.... =(

phoeneous

theodoxa wrote: »

#1 - As stated it should be 0.0.3.255
#2 - The prefix/subnet address is wrong, though I suspect IOS will silently correct it to 192.168.0.0

access-list 1 permit 192.168.0.0 0.0.3.255

I thought so too, but it doesnt silently correct it. Isnt that wildcard considered invalid?

R1#sh access-lists
Standard IP access list 1
10 permit 192.168.2.0, wildcard bits 0.0.4.255


My trick to wildcards has always been to subtract the host bits from 255. Oh, and reading this http://media.packetlife.net/media/library/15/IPv4_Subnetting.pdf

theodoxa

I thought it would. But, I guess not doing so allows the advanced configurations used at the CCIE level. At the CCNA and CCNP levels the listed Wilcard would not be used. But, at the CCIE level...the rules change.