Location of ACLSs--Definately a Guru topic
mikeybinec
Member Posts: 484 ■■■□□□□□□□
in CCNA & CCENT
The hardest part of access control lists, in my view, is the proper placement of them. I can write them and know the protocols
and so on and so on. So I'm looking for the Gurus to give me their simple rule on where to place them. Theory tells us extended go to the source and standard go to the destination. But Ive been working with Lammle's bonus labs and his solutions don't follow the standard rules..Refer to the exhibit below. I have a couple of hosts circled. Let's make it simple and say we dont want the circled ones to access the server, but everybody else can. Writing an acl is simple enough. What is the Guru decision process in deciding whether an ACL is placed inbound on an interface or outbound? That's the million dollar question.
Thanks
and so on and so on. So I'm looking for the Gurus to give me their simple rule on where to place them. Theory tells us extended go to the source and standard go to the destination. But Ive been working with Lammle's bonus labs and his solutions don't follow the standard rules..Refer to the exhibit below. I have a couple of hosts circled. Let's make it simple and say we dont want the circled ones to access the server, but everybody else can. Writing an acl is simple enough. What is the Guru decision process in deciding whether an ACL is placed inbound on an interface or outbound? That's the million dollar question.
Thanks
Cisco NetAcad Cuyamaca College
A.S. LAN Management 2010 Grossmont College
B.S. I.T. Management 2013 National University
A.S. LAN Management 2010 Grossmont College
B.S. I.T. Management 2013 National University
Comments
-
powmia Users Awaiting Email Confirmation Posts: 322Not a guru topic, for the simple reason that you are early in your studies and I'm sure you need a book answer that doesn't align with real-world practice.
To somewhat answer your question: It depends. The placement isn't about whether it's a standard, extended, named, whatever ACL... it's about what you are trying to filter. The books will tell you (used to? it's been a while) some crap about wasting resources and blah blah etc. You need to know that stuff for your CCNA. In reality, it just depends on the requirement. You put an ACL as close as feasibly possible to the host it pertains to. Whether you are denying/permitting packets to or from that host will determine whether it is inbound or outbound on that interface. Anything else will lead to a configuration that doesn't scale and isn't manageable. Imagine troubleshooting the reason for packets not getting to a server in your data center. Now imagine not being able to just look at the configs for the ports that server is connected to, because someone didn't want packets traversing the network just to get dropped right before that server (the blah blah etc). Instead you have to look at the ACLs applied to the 1,000 other switches connecting hosts to your network. At that point you're so frustrated that you aren't even thinking about the poor schmuck that had generated the ACLs for those 1,000 switches. -
docrice Member Posts: 1,706 ■■■■■■■■■■Fully agree. The CCNA books may impart a certain starting philosophy, but real-world environments have contextual nuances which may violate these principles for good reasons.
To answer one of your questions, in my experience I've seen ACLs applied on the inbound direction on the interface more often rather than out. There may be cases where you'd do it the other way simply because router ACLs are typically stateless and you want to reduce certain things or putting inbound ACLs on other interfaces isn't feasible for whatever reason. Once you get into stateful ACLs ("firewall" appliances or, oh dear, reflexive ACLs on routers), it changes your rule-writing approach quite a bit.
Managing rules can actually get quite complicated, especially with ones exceeding hundreds or thousands of lines with multiple deny and permit statements inserted in various ordering. Without a defined convention for your team, it can get out of hand and difficult to manage quickly.Hopefully-useful stuff I've written: http://kimiushida.com/bitsandpieces/articles/