03-10-2016 06:53 AM - edited 03-05-2019 03:32 AM
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.
Solved! Go to Solution.
03-10-2016 08:36 AM
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
03-10-2016 08:58 AM
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
03-10-2016 08:36 AM
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
03-10-2016 08:58 AM
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
07-30-2017 05:49 AM
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
07-31-2017 11:29 AM
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
12-18-2021
07:28 AM
- last edited on
12-27-2021
06:25 AM
by
Translator
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.
12-18-2021 08:57 AM
In my response I asked if someone had a better explanation. I am very glad to see this explanation of the behavior. So +5.
12-18-2021 02:22 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide