09-09-2009 09:41 AM - edited 03-06-2019 07:39 AM
Hi there, imagine I am cleaning up access-lists. If you see an access-list like the one below, would you try to consolidate it? For example, I could do "permit ip any 172.66.217.22 0.0.0.1" and consolidate #20 and #30. Then I thought about it and it would make it more complex to analyze which hosts are part of the entry. Please let me know your thoughts. Thanks.
Extended IP access list MYACL
!
10 permit icmp any any
20 permit ip any host 172.66.217.22
30 permit ip any host 172.66.217.23
40 permit ip any host 172.66.217.24
50 permit ip any host 172.66.217.25
60 permit ip host 172.66.217.22 any
70 permit ip host 172.66.217.23 any
80 permit ip host 172.66.217.24 any
90 permit ip host 172.66.217.25 any
100 permit ip any host 172.66.217.131
110 permit ip any host 172.66.218.131
120 permit ip any host 172.66.217.132
130 permit ip any host 172.66.218.132
150 permit ip any host 172.66.218.22
160 permit ip any host 172.66.218.24
170 permit ip any host 172.66.217.28
180 permit ip any host 172.66.218.28
190 permit ip any host 172.66.206.30
200 permit ip host 172.66.217.131 any
210 permit ip host 172.66.218.131 any
220 permit ip host 172.66.217.132 any
230 permit ip host 172.66.218.132 any
240 permit ip host 172.66.218.22 any
250 permit ip host 172.66.218.24 any
260 permit ip host 172.66.217.28 any
270 permit ip host 172.66.218.28 any
280 permit ip host 172.66.206.30 any
350 deny ip host 172.66.206.5 any
360 deny ip host 172.66.206.6 any
370 deny ip host 172.66.206.7 any
380 deny ip host 172.66.206.8 any
390 deny ip host 172.66.206.9 any
400 deny ip host 172.66.206.10 any
410 deny ip host 172.66.206.29 any
420 deny ip any host 172.66.206.5
430 deny ip any host 172.66.206.6
440 deny ip any host 172.66.206.7
450 deny ip any host 172.66.206.8
460 deny ip any host 172.66.206.9
470 deny ip any host 172.66.206.10
480 deny ip any host 172.66.206.29
500 permit ip any any
end
!
09-09-2009 10:02 AM
Marlon
It really depends. The shorter the acl the quicker to process each packet especially if the entry that matches your packet is near at the end of the acl.
If you could summarise a group of addresses then yes do so although not sure i would go the the bother of using 0.0.0.1 to be honest.
What would simply the above acl considerably though is you are specifying the same host twice in all your entries eg.
20 permit ip any host 172.66.217.22
60 permit ip host 172.66.217.22 any
this doubles the size of the acl. Depending on the direction the acl is applied you only actually need one entry.
If you are applying the acl in both directions i would still cut it in half as
a) it makes it easier to read
b) it is shorter and therefore takes less time to process
Jon
09-09-2009 10:48 AM
Hey, sorry for my ignorance. What is the best you way to write such bidirectional ACLs in IOS then?
Using the example given,
20 permit ip any host 172.66.217.22
60 permit ip host 172.66.217.22 any
How do you suggest this consolidation in one line?
09-09-2009 10:53 AM
Marlon
Apologies, i didn't explain very well.
You can't consolidate the 2 lines into one. What i was trying to explain is that you apply an acl either in or out. So if the acl is applied inbound only one of those 2 lines is relevant. If the acl is applied outbound then the other line is relevant. But they can't both be relevant at the same time in the same direction.
Now if you applied it both inbound and outbound it is still worth only using the relevant lines in each acl. So you would end up with 2 different acl's each of which would be half the size of the full acl. The shorter the better, and in fact if you use the full acl you will always be checking against redundant entries because a single packet can't be going both in and out at the same time.
Jon
09-09-2009 10:55 AM
If your ending the ACL with permit ip any any then you will only need the deny information in it.
Matt
09-09-2009 11:03 AM
If your ending the ACL with permit ip any any then you will only need the deny information in it.
Not necessarily.
Say, you want to allow 192.168.1.1 but block 192.168.1.0/24
You have to start with a permit on 192.168.1.1, then deny on 192.168.1.0/24 and a finish with a permit ip any any.
__
Edison.
09-09-2009 11:08 AM
Absolutley ;-)
Just not in the ACL mentioned above.
Worth stating though, didnt mean it as a blanket statement.
Matt
09-09-2009 11:05 AM
Edson already clarified this. THanks.
09-09-2009 11:09 AM
Which direction are you applying the ACL? (in|out)?
There is no need to have bidirectional ACLs, ideally - you apply the ACL on ingress so with this approach, you can eliminate about 50% of your ACEs.
For instance, you will use these:
20 permit ip any host 172.66.217.22
30 permit ip any host 172.66.217.23
40 permit ip any host 172.66.217.24
50 permit ip any host 172.66.217.25
and eliminate this:
60 permit ip host 172.66.217.22 any
70 permit ip host 172.66.217.23 any
80 permit ip host 172.66.217.24 any
90 permit ip host 172.66.217.25 any
If you apply the ACL on the WAN facing interface on the ingress direction in your router.
09-09-2009 11:18 AM
As is now, I inherited the MYACL applied under the respective "interface vlan 300" like it is shown below. I see it is applied in and out. I agree, I could do this as 'in' only then.
4507
desc servers on layer2 switches connect to this 4507
int vlan 300
(...)
ip access-group MYACL in
ip access-group MYACL out
(...)
09-09-2009 11:23 AM
Marlon
You may well still want to apply it both in and out because in and out they do different things. However it is still worth using 2 separate acl's.
Jon
09-09-2009 11:32 AM
I agree with Jon. There are times when an in and out acces-group is needed on the interface but they should be 2 separate ACLs, not the same.
With that said, blocking or permitting a host on egress and doing the same on ingress does not make a lot of sense.
09-09-2009 11:52 AM
Understood.
It is true. I do not know enough about the application to guarantee that the servers could not for example generate traffic outbound trying to reach hosts. So I will keep it in and out. I will just build a separate MYACLOut and that is fine.
As always, thank you very much.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: