Inbound vs. outbound access list performance

[bbrunette]

We are required to have an ACL on our Internet router to permit traffic only to legitimate ports. An "expert" told us that applying the ACL to the outbound traffic on our internal interface is more efficient than applying it to inbound traffic on the external interface. I'm wondering if anybody can confirm or debunk this statement.

Thanks,

Bob

[vincent-n]

Inbound ACL is more efficient than outbound due to the fact that with inbound, any matched "deny" packet is dropped BEFORE the packet gets routed to the destined outbound interface. With outbound, the packets (both deny and permit) gets routed to the outbound interface and then those that are denied will be dropped. In this sense, inbound is more efficient because there is one less step for those denied packets. Hope this help.

[bbrunette]

Yeah, that's what I thought too. But the expert said that outbound filtering is more efficient because the packet is already in the buffer needed to do the filtering at that point. And the efficiency savings from not routing unwanted packets isn't all that great, because a relatively small percentage of packets are dropped anyway. Any thoughts on that?

Bob

[GW6]

I guess it depends on what types of traffic you are seeing and dropping.

I would have to agree that inbound ACL's are preferable. The quicker you can get a deny statement to match that packet the quicker the router can forget about it.

[thisisshanky]

There are two things that are to be considered here.

1. Effectiveness of the list

2. Performance impact of the list on the router.

If you take criteria 1, inbound is better, than outbound, because it will deny or block all unwanted ports, depending on what you have configured. Attacks coming from external world is better blocked with an inbound access-list on the external interface.

If you take criteria 2, inbound access-lists create more router load compared to outbound ACLs. The router has to match all packets coming in on an interface applied with inbound ACL, and remember, ACLs cause the router to do process switching on that interface.

I would recommend using a combination of both types of access-lists on the external interface, and possibly configure Reflexive access-lists on your border router. This would make sure that only those sessions initiated from inside your networks will be permitted.

[bbrunette]

Thanks for the good answer. I have two more questions and then I think I'm done.

First, you point out that inbound ACLs cause the router to do process switching on the inbound interface. Does this imply that outbound ACLs do NOT cause process switching on the outbound interface?

Second, since I have to do inbound ACLs anyway to protect the router, does it make sense to just put everything in the inbound ACL and eliminate the outbound ACL?

[thisisshanky]

Answer to question 1:

All access-list whether applied inbound or outbound does make the router, do process switching on that interface. But there is a difference.

consider this example E0----R1----E1.

|

|

E2

If an access-list has been applied inbound, on E0, every packet entering the interface E0 has to be process switched and compared with the access-list, no matter, whether the packet will be routed to port E1 or E2.

If an access-list was applied outbound on interface E1 (say)...every packet entering the router via E0, is first routed, to the appropriate destination interface (E1 or E2) and then checked to see if there is an access-list (outbound). The router finds that only E1 has an access-list and E2 has not, so only those packets routed out E1, will be compared against the access-list.

So there is less overhead always when configuring outbound access-list.

If you are creating normal ACL's, then you can use just an inbound ACL to protect your network from the outside. Sometimes, this creates problems like, you cannot ping from inside to outside, because you have blocked ICMP packets, coming from outside. Here comes the use of Reflexive ACL;s, where you use a combination of Outbound and Inbound ACL's. Reflexive ACL's allows you to say ping, telnet, ftp etc from inside to outside, but at the same time, block all connections (ping, telnet, ftp) initiated from outside to inside.

Take this example.

ip access-list extended outboundfilter

permit icmp any any reflect ICMPtraffic

ip access-list extended inboundfilter

evaluate ICMPtraffic.

int s0

ip access-group outboundfilter out

ip access-group inboundfilter in

Here ICMPtraffic is the reflexive access-list, which is a dynamic ACL, which is created only when a connection (ping in this case) is initiated from inside to outside. This dynamic entry can be verified using "show access-list". This dynamic entry, will allow the return ICMP echo traffic from outside to inside. At the same time, this access-list will not allow ping traffic initiated by somebody from outside to inside.

Hope that helps.

[vcjones]

One factor which has been ignored (because it has nothing to do with ACL efficiency) but is probably very relevant in this context, is that only an inbound ACL will protect the router. Putting the access controls on the internal interface may save CPU cycles protecting the inside network, but does nothing to protect the router itself from attack from the Internet (in which case, I sure hope you have upgraded the IOS to defend against the latest DoS vulnerability).

If you're the cautious type (or have untrusted internal users), you'll want to protect the router from inside attacks as well as Internet attacks, which means inbound filters on every interface plus filters on those few services which are still allowed to run on the router.

Good luck and have fun!

Vincent C Jones

www.networkingunlimited.com

[bbrunette]

You're absolutely right, and that is what started me thinking about this in the first place. We had put the outbound ACL on the inside interface on the advice of the expert some time ago and had a minimal inbound ACL on the outside interface as well. When I had to add to it to for the latest DoS vulnerability, I got thinking again about which is more efficient.

Given all the good discussion I have heard here, I plan to move everything to the inbound ACL on the outside interface and eliminate the outbound ACL on the inside interface. It is more secure, makes for a more understandable config, and doesn't sound like a big efficiency hit.

Thanks to all who contributed; you've been a big help.

Bob

[t.baranski]

Access lists don't necessarily force a router to resort to process switching. This used to be the case many years ago, but ACL fast-switching has been possible for quite some time and now ACL's can even be CEF switched. This is highly dependant on what hardware and software you're using, however, so check the documentation.

Note, however, that there are some ACL-related features (including use of the "log" keyword in an access-list statement, and sending ICMP unreachables when a packet is blocked) that may still cause a less-desirable switching path to be used even to this day. I haven't looked into this very recently, though, and things are always changing, so the documentation for your particular software version is generally the best place to get such information from.

[l33T_Admin]

Acls do not normally apply cpu/process switching, if they did your forwarding plane would be limited to the size of your back plane as all traffic would be looked at and this would flood the back plane. Instead acl logic is performed at the TCAM, with wildcards. the only exception to this is with the "log" function of acls, due to this requiring a bump up to cpu to generate additional data to be written or sent off. Applying a "permit any any log" ACL to any interface effectively turns fast switching off, by forcing the cpu to see all traffic routed/forwarded over this interface

[Richard Burts]

The comments in the most recent response correctly reflect the processing environment of 2019. The original discussion of this thread is from 2003. A lot has changed since then (introduction of Fast Switching, introduction of CEF, TCAM processing, etc) so the comments about access list causing process switching was appropriate for the time it was made. But does not apply to current environments.

HTH

Rick

[Joseph W. Doherty]

Something to keep in mind, even now, I believe most Cisco ISRs still perform all routing functions using the main CPU, i.e. unlike a L3 switch, you're unlikely to find TCAM (or dedicated ASICs [rather than ASICs, if there's "extra" hardware, perhaps it's more likely to be a PLA, FPGA or CPLD]).

If I'm correct, the only real difference between "fast" switching (or interrupt processing) and "process" switching is whether the software performing the function is very efficient and driven off an interrupt or is handled by a scheduled software process. Either will drive the CPU load up, again, where they differ is how the CPU load is accounted for and how "efficient" or "optimal" the software is. (BTW, for the latter, beside the possibility of some already mentioned "extra" hardware, it's also possible "fast" switching uses special hardware CPU instructions [e.g. custom microcode] designed to accelerate certain functions.)

[Richard Burts]

Joseph

Actually the difference between process switching and fast switching is that in process switching the CPU is used for a series of steps (route table lookup, identify outbound interface, build the encapsulation) and it did the complete process for every packet. In fast switching the CPU does this processing for the first packet of a conversation (or flow or whatever you want to call a series of packets with same source and same destination address) and then builds a cache entry which is used to forward succeeding packets which makes them much more efficient because now it is just evaluate the destination address, search for a matching cache entry, use the cache entry to build the outbound header, and send the packet.

HTH

Rick

[Joseph W. Doherty]

Rick, believe you've described (1st packet processing) is also known as flow caching. That aside, what processes the subsequent packets after the first on most small CPU routers? I.e. what still just evaluates ". . . the destination address, search for a matching cache entry, use the cache entry to build the outbound header, and send the packet.", the main CPU or not?

We both agree, I believe, whatever Cisco does in the "fast path" is more efficient than how the same function might have been done in the "process switching" path.