cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4027
Views
20
Helpful
7
Replies

Why do the access-lists not apply to the locally generated traffic in a router?

sarahanand
Level 1
Level 1

Most sources mention that the locally generated traffic cannot be filtered by access-lists. However, these sources just stop there. They never mention the "Why".

Does the fact that in multilayer switches, ACLs are placed into TCAM and filtered/forwarded in hardware whereas locally generated traffic is processed in the CPU and processed switched, have any implications on this limitation?

If so, then how is processed-switched transit traffic filtered by ACLs?

Any explanations would be greatly appreciated.

Thank You.

2 Accepted Solutions

Accepted Solutions

Richard Burts
Hall of Fame
Hall of Fame

You ask an interesting question. And I agree that I do not believe that I have seen a real authoritative answer about why access lists applied outbound do not filter the traffic generated by the router/switch. The suggestion that it might be related to hardware processing/TCAM is appealing, but the behavior goes back further. When the layer 3 switches were being developed the IOS routers already had this behavior that access lists applied outbound would not filter traffic generated by the router itself.

I have assumed that the reason for this behavior is related to concepts of trust boundaries - what should we trust and what should we not trust and therefore should be subject to access list filtering. Anything that comes to the router/switch from outside (is inbound on the interface) is not trusted and access lists applied inbound do filter all the traffic entering the interface. Any traffic that is transit traffic (originated from somewhere else and is passing through the router/switch) and is outbound through the interface is not trusted and is subject to access list filtering. Traffic that is generated by the router/switch itself is trusted and is not subject to filtering by access lists on the interface.

If anyone in the forum has a better explanation then I would be very interested in knowing it.

HTH

Rick

HTH

Rick

View solution in original post

I agree to Richard's position on the fact that routers showed this behavior from the early beginning on, even in IOS versions before v7, when I started my journey in Cisco (jeez, I am old).   I asked this question a few times at conferences and tech forums and the only answer I got was "This is an architectural design and treating trespassing traffic differently made it easier to optimize performance". None of the people I asked were sure about that "fact", it was more like an assumption.

Maybe a developer could chime in, but I also assume that this might be proprietary design information and we may never know.

Just my $0.02

Patrick

View solution in original post

7 Replies 7

Richard Burts
Hall of Fame
Hall of Fame

You ask an interesting question. And I agree that I do not believe that I have seen a real authoritative answer about why access lists applied outbound do not filter the traffic generated by the router/switch. The suggestion that it might be related to hardware processing/TCAM is appealing, but the behavior goes back further. When the layer 3 switches were being developed the IOS routers already had this behavior that access lists applied outbound would not filter traffic generated by the router itself.

I have assumed that the reason for this behavior is related to concepts of trust boundaries - what should we trust and what should we not trust and therefore should be subject to access list filtering. Anything that comes to the router/switch from outside (is inbound on the interface) is not trusted and access lists applied inbound do filter all the traffic entering the interface. Any traffic that is transit traffic (originated from somewhere else and is passing through the router/switch) and is outbound through the interface is not trusted and is subject to access list filtering. Traffic that is generated by the router/switch itself is trusted and is not subject to filtering by access lists on the interface.

If anyone in the forum has a better explanation then I would be very interested in knowing it.

HTH

Rick

HTH

Rick

I agree to Richard's position on the fact that routers showed this behavior from the early beginning on, even in IOS versions before v7, when I started my journey in Cisco (jeez, I am old).   I asked this question a few times at conferences and tech forums and the only answer I got was "This is an architectural design and treating trespassing traffic differently made it easier to optimize performance". None of the people I asked were sure about that "fact", it was more like an assumption.

Maybe a developer could chime in, but I also assume that this might be proprietary design information and we may never know.

Just my $0.02

Patrick

Thanks Richard,

Working on my CCNP but this basic concept had.my stumped.  Thank you for putting it in CLEAR and EASY to understand language!

Mike

Mike

Thanks for the kind words. I am glad that my explanation was helpful. Best wishes as you work to complete your CCNP.

HTH

Rick

HTH

Rick

mamikhai
Cisco Employee
Cisco Employee

Locally (control plane) generated traffic goes from control plane directly to "tx-ring".

That is different from processing/forwarding of Transit traffic.

Please see the platform's "packet journey" session of Cisco Live or other documentation to see the different internal path & processing for: Transit, forus, exception, locally generated.

In my response I asked if someone had a better explanation. I am very glad to see this explanation of the behavior. So +5.

HTH

Rick

Having been a software developer for a couple of decades, I suspect the actual "truth" behind the "why" for this difference has multiple components, possibly including considerations for "why" noted by @Richard Burts, @PATRICK GESCHWINDNER and @mamikhai.

One very, very important consideration is trading off features vs. cost to provide.  In a case with a vendor, like Cisco, they heavily consider what their customers want/require.  The need for ACLs for transit traffic, would likely be considered a "must" requirement by many (early) customers.  The need for ACLs, for router sourced traffic, not so much a "must" requirement (NB: I'm using router mainly because it would have been more germane when Cisco first entered the market).

Further, as noted by @mamikhai, some packets are handled, by a router, differently, such as, it seems, router locally sourced packets.  I.e. this would, likely, add to the complexity in adding such a feature (i.e. ACL support for this traffic), not to mention other software development considerations when adding any feature.

It's possible, I suspect, the requirement for ACLs against locally sourced packets was never even considered (hindsight is 20/20), or such a requirement was considered, but the cost to add, vs. the potential "benefit", caused such feature development to be dropped, although possibly with consideration for later inclusion if there was a real need.

 

Review Cisco Networking products for a $25 gift card