A Little ACL Help

rob42

The last ACL Thread seems to have gone, so starting a new one...

Say I subnet the 150.100.10.0 network to have up to 30 hosts on each subnet, leaving room for additional subnets and choose a /27 mask...
150.100.10.0 /27
150.100.10.32 /27
150.100.10.64 /27
150.100.10.96 /27
etc...

I then setup an ACL...

access-list 1 permit 150.100.10.0 0.0.0.63

... would this permit all the hosts in my .0 and .32 subnets, blocking .64 and above, or am I looking at this in the wrong way?

I see the logic like this...

1 0 0 1 0 1 1 0 | 0 1 1 0 0 1 0 0 | 0 0 0 0 1 0 1 0 | 0 0 0 0 0 0 0 0 | = permit 150.100.10.0
0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0 | 0 0 1 1 1 1 1 1 | = W.C.M 0.0.0.63
1 0 0 1 0 1 0 0 | 0 1 1 0 0 1 0 0 | 0 0 0 0 1 0 1 0 | 0 0 x x x x x x | = 150.100.10. 0 - 63

With thanks.

WastedHat

Are you helping people who are studying ACLs or were you looking for help?


On the topics of ACLs I've still not found an explanation as to why standard IPv4 ACLs create entries in a seemingly random order. Was it something in the functionality that Cisco just didn't bother fixing?

rob42

WastedHat wrote: »

Are you helping people who are studying ACLs or were you looking for help?


On the topics of ACLs I've still not found an explanation as to why standard IPv4 ACLs create entries in a seemingly random order. Was it something in the functionality that Cisco just didn't bother fixing?

I'm trying to understand ACLs myself and was looking for conformation that my understanding is correct/incorrect.

I'm a little confused by your comment "... why standard IPv4 ACLs create entries in a seemingly random order.", as ACLs are user generated; nothing "random" that I'm aware of.

Maybe you could give me an example?

WastedHat

You're understanding is correct, the 0-63 range defined by the WC mask contains both of those subnets. It works the other way too, if you had 150.100.10.0/25 then the same ACL statement would only permit the first half of that subnet.


If you're defining a range of addresses the 'permit' or 'deny' statement should always use network/subnet address before the WC mask.

If you want to save time during the exam you can add the WC mask to the network/subnet address in decimal and it will give you the same address range.




R2(config)#access-list 1 permit 10.0.0.1
R2(config)#access-list 1 permit 10.0.0.2
R2(config)#access-list 1 permit 10.0.0.3
R2(config)#
R2(config)#do show ip access-lists
Standard IP access list 1
20 permit 10.0.0.2
30 permit 10.0.0.3
10 permit 10.0.0.1
R2(config)#

If I go into ACL editing mode and add/remove lines by sequence number the same thing happens, it just looks like a mess. If I do the same with extended ACLs everything works as expected. Weird.

rob42

Thanks for your input. I thought it made sense, but I'm finding it hard on my old brain... I'm going to 'Lab Test' this as soon as I get time.

Re: Your ACL.

I've not come across that issue, because I create ACLs in a slightly different way...

R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip access-list standard 1
R1(config-std-nacl)#permit 10.0.0.1
R1(config-std-nacl)#permit 10.0.0.2
R1(config-std-nacl)#permit 10.0.0.3
R1(config-std-nacl)#exit

R1(config)#do show ip access-list
Standard IP access list 1
10 permit host 10.0.0.1
20 permit host 10.0.0.2
30 permit host 10.0.0.3

R1(config)#

WastedHat

No problem.

Strange.. if I make a named standard ACL I get the same 'out of order' result. Are you using physical/simulator/emulator?

I've found quite a few things that don't work properly, I'm assuming it's my IOS version for now and I'll look into it more after the exam.

rob42

Mostly, I use CPT 7. I only fire-up my lab equipment if I want to try something that's not supported, such as the 'resequence' sub-command on ACLs, which I learned about from here... https://ccie-or-null.net/2012/01/09/working-with-cisco-access-control-lists-acls/

Cheers for the help and all the best with your exam.

rob42

WastedHat wrote: »

No problem.

Strange.. if I make a named standard ACL I get the same 'out of order' result. Are you using physical/simulator/emulator?

I've found quite a few things that don't work properly, I'm assuming it's my IOS version for now and I'll look into it more after the exam.

F.Y.I...

I just tried this on my C880 and my R2620. Both have ACL entries 'out of order', just as you have found.
My C880 is running IOS Version 15.0(1)M5, while my R2620 is running Version 12.2(27).

The IOS in the CPT 7 Routers seems to be Version 15.1(4)M4.

It's odd, but I don't suppose it makes a difference, (the order the permits are in), as the list will be processed, top-down, until a match is found, or 'deny' if a match is not found, right?

WastedHat

Thanks for checking. I searched and found other posts about it before but never found a reason why.

If it's standard ACL that only permits/denies single addresses then I would say you're right and it wouldn't make a difference. None that I'm aware of anyway. If you use WC masks then you need to put a bit more thought into the order. The rule I read was "place more specific statements first" in any ACL.


For example, if you want to permit an entire subnet but deny a host from that same subnet you would have an ACL like this:

access-list 1 deny 150.100.10.11
access-list 1 permit 150.100.10.0 0.0.0.63

If you were to put the deny statement after the permit statement it wouldn't have any effect because it's processed top down like you said.


When you compare WC masks 0.0.0.0 is the most specific because it needs to be that exact address and 255.255.255.255 is least specific because it means anything. When you look at extended ACLs the same logic applies to the "host" and "any" keywords.

I thought IOS might have been trying to arrange the ACL entries by high/low IP address and more/less specific WC mask but I always get the 'out of order' result with standard ACLs.