Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

Feedback on best practice, access-list organization

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

!

12 REPLIES
Hall of Fame Super Blue

Re: Feedback on best practice, access-list organization

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

New Member

Re: Feedback on best practice, access-list organization

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?

Hall of Fame Super Blue

Re: Feedback on best practice, access-list organization

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

New Member

Re: Feedback on best practice, access-list organization

If your ending the ACL with permit ip any any then you will only need the deny information in it.

Matt

Hall of Fame Super Bronze

Re: Feedback on best practice, access-list organization

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.

New Member

Re: Feedback on best practice, access-list organization

Absolutley ;-)

Just not in the ACL mentioned above.

Worth stating though, didnt mean it as a blanket statement.

Matt

New Member

Re: Feedback on best practice, access-list organization

Edson already clarified this. THanks.

Hall of Fame Super Bronze

Re: Feedback on best practice, access-list organization

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.

New Member

Re: Feedback on best practice, access-list organization

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

(...)

Hall of Fame Super Blue

Re: Feedback on best practice, access-list organization

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

Hall of Fame Super Bronze

Re: Feedback on best practice, access-list organization

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.

New Member

Re: Feedback on best practice, access-list organization

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.

199
Views
0
Helpful
12
Replies
CreatePlease to create content