PACL restrictions.

[Mitrixsen]

Hello, everyone.

I am studying about ACLs for my ENCOR exam and the following piece of information is mentioned in my book:

PACLs have a few restrictions that vary from platform to platform.

• PACLs only support filtering incoming traffic on an interface (no outbound filtering
  support)
• PACLs cannot filter Layer 2 control packets, such as CDP, VTP, DTP, PAgP, UDLD, and
  STP.
• PACLs are supported only in hardware.
• PACLs do not support ACLs to filter IPv6, ARP, or Multiprotocol Label Switching
  (MPLS) traffic

The highlighted restrictions don't make much sense to me. From an architectural perspective, what exactly prevents an ACL that is applied to an L2 interface (so a PACL) on some platforms from being capable of outbound filtering or filtering IPv6?

Thank you.

David

[Joseph W. Doherty · Accepted solution]

"From an architectural perspective, what exactly prevents an ACL that is applied to an L2 interface (so a PACL) on some platforms from being capable of outbound filtering or filtering IPv6?"

From a general architectural perspective, I doubt there's a limitation.

From a specific platform architectural perspective, I suspect there's no hardware support.

I also suspect, you may agree with the above but then ask "but why not provide such hardware?"

Most likely reason is due to marketing. I.e. customer demand for such is likely not enough to cover the additional cost, at least according to Cisco's market analysis.

Remember, businesses focus on what they believe they can profitable sell.  Those that don't focus on that, go out of business.

[Mitrixsen]

Thank you for the response.

However, if a platform supports inbound filtering, doesn't it mean that there should also be support for outbound filtering? Since apart from the direction, there isn't really much of a difference, or is there? I just find it a little unusual that some platforms would omit outbound filtering but allow it inbound.

David

[Richard Burts]

David

I am not expert on this aspect (and if someone who is expert wants to join the discussion that would be great) but my understanding is that when we consider inbound filtering the data arrives at the switch, is passed to the interface, and the interface can determine whether to pass it to the connected device or not. If the interface does not pass the data to the connected device it does not have any effect on the device. But for outbound filtering we have a different situation. The connected device has sent data to the interface, expecting that it will be forwarded. If the interface denies the traffic there is not any mechanism for the interface to notify the device that its traffic has been denied.

[Joseph W. Doherty]

Rick, an interesting hypothesis, that might be possible in some aspect.

For ingress traffic, NICs, if they can, will locally (on the NIC) exclude frames/packets not specified of being of interest to the host.  The savings of needless processing, to the host, can be significant.  (Consider the classic problem of broadcast resource consumption when the actual broadcast is of no interest to the host.)

However, why would a NIC logically filter an egress frame/packet?  Because, as you note if the host has already sent the frame/packet to be transmitted, the assumption would be to transmit it.

As to "If the interface denies the traffic there is not any mechanism for the interface to notify the device that its traffic has been denied.", I would expect if it needs such information for stats, the hardware can be designed to provide it.

[Richard Burts]

Joseph makes an excellent point about the interface filtering traffic that it receives and which would not be of interest to the connected device. There is no impact to the connected host. And PACL provides an administrative tool to extend the logic for filtering inbound traffic. So there is an excellent basis for ingress filtering. But that logic does not apply to outbound traffic since anything generated by the connected device is of interest to that device. 

I would like to address one other aspect of the OP which asks "what exactly prevents an ACL that is applied to an L2 interface (so a PACL) on some platforms from being capable of outbound filtering or filtering IPv6?". The  answer is inherent in the layered network model. A L2 interface operates at layer 2 and IPv6 is at layer 3.

[Joseph W. Doherty]

"Since apart from the direction, there isn't really much of a difference, or is there?"

I doubt that's necessarily true, because if it were, then it would seem likely platforms would support similar features for both directions.  But, as they don't, there's likely some reason.

However, again, such a reason might not be due to just hardware, could be due to marketing.

[Joseph W. Doherty]

@Ramblin Tech could you comment on this?

[Ramblin Tech · Accepted solution]

PACLs have a few restrictions that vary from platform to platform.

• PACLs only support filtering incoming traffic on an interface (no outbound filtering
  support)
• PACLs cannot filter Layer 2 control packets, such as CDP, VTP, DTP, PAgP, UDLD, and
  STP.
• PACLs are supported only in hardware.
• PACLs do not support ACLs to filter IPv6, ARP, or Multiprotocol Label Switching
  (MPLS) traffic

The highlighted restrictions don't make much sense to me.

The statements "vary from platform to platform" and "PACLs are supported only in hardware" go hand-in-hand. Packet filtering only scales when performed in hardware, and Cisco has many varieties of packet-forwarding ASICs/NPUs including home-grown UADP & SiliconOne, customized Trident/Typhoon/Tomahawk silicon from EZchip, and Broadcom DNX & XGS merchant silicon (just to name a few of the many). Each family, and each generation within a family, represents a particular set of capabilities that can vary widely between families and even between generations in the same family. Those capabilities result from engineering and marketing trade-offs by the chip manufacturer between such factors as bps/pps performance, table scale, cost, chip size, number/type of interfaces/SERDES, power consumption, etc, etc.

Cisco product architects then choose an NPU for their device, making their own comparable trade-offs to [ideally] hit a sweet-spot in the market. The point here is that with hardware-based forwarding, virtually all capabilities of the device is platform dependent and those platforms have a variety of hardware-based capabilities. Furthermore, those hardware-based capabilities are not infinite; there are only so many clock cycles, gates, cores, memory resources, etc in the NPU that must be spread out across all the features required by the product. [Naturally, a product architect should not choose an NPU completely unsuited for the XE/XR/NXOS place in the network for which the product is intended.]

OK, enough of all that... why don't I have feature X on my hardware-based platform? In my experience in working with Cisco BUs to get features implemented for my customers, the reasons came down to:

1. The feature violates a basic tenet of the NOS
2. The underlying hardware does not support implementing the feature
3. The underlying hardware does support implementing the feature, but a compelling use-case/business-case had not been made to commit development engineers to implement it.
4. The underlying hardware does support implementing the feature, but the required hardware resources are already being used to support feature Y. That is, you can have either X or Y, but not both concurrently, and right now we only offer Y.

"PACLs only support filtering incoming traffic on an interface (no outbound filtering support)".  I see XE PACLs as being more or less equivalent to XR L2 Access Lists. The ASR9000 XR-router supports L2 ACLs in both ingress and egress directions, while the Cisco 8000 XR-router supports only ingress. This ingress vs egress capability asymmetry in the 8K is not at all unusual, as many NPUs exhibit this. The 9K shows that egress L2 ACLs are not inherently impossible, so my guess on this is that NPU capability to support egress PACLs is not universal and that the product manager for the IOS PACL feature has not seen a compelling use-case to have it implemented on platforms that might also support the egress direction. [Note that Cisco 8K and some Cat9K platforms both use SiliconOne NPUs]

"PACLs do not support ACLs to filter IPv6, ARP, or Multiprotocol Label Switching (MPLS) traffic". Again, I will return to L2 ACLs on the 8K XR-router which does support IPv4/IPv6 filtering on L2 interfaces. This indicates that such filtering does not violate any tenets of XR (implies nothing about XE) and that filtering on IPv4/IPv6 on L2 interfaces is supported by at least some NPUs. It should be noted that the 8K also does not support MPLS filtering. My guess here is that MPLS filtering is difficult, if not impossible, in many NPUs, but the lack of IPv6 filtering on L2 interfaces probably comes down to dev priorities for XE.

[Joseph W. Doherty]

Thank you Jim!!!

You mentioned a couple of points I had thought of, but didn't mention, but one that never occurred to me.  I.e. particular hardware might support X or Y but not both X and Y.

David, I hope Jim's info also helps.

[Ramblin Tech]

Hey Joe, in some cases where we were told that “it’s either X or Y” and we said the customer only wants X, the BU gave us a software switch that would only allow one or the other to be configured.

[Mitrixsen]

This is a fantastic response, thank you for diving so deep into this. I don't even have a question regarding hardware support and specifications at this point since you've answered literally everything.

I do have one more question that I would like to ask (so I don't have to make a new forum thread) and that is about the following point:

• PACLs cannot filter Layer 2 control packets, such as CDP, VTP, DTP, PAgP, UDLD, and
  STP

I've read on the internet that L2 control packets are immediately sent to the CPU which skips the PACL that is implemented in hardware? So is this the reason why they are not matched and then filtered by the ACL?

If that is the case, why aren't L3 control packets also skipped by the ACL? Because I can easily create an ACL that would filter, say OSPF or EIGRP. If OSPF and EIGRP are L3 control packets, shouldn't they also be immediately sent to the CPU thus bypass the ACL?

Thank you.

David

[Ramblin Tech]

Hi David; I do not know why it was decided that L2 control protocol packets cannot be filtered by PACLs, but can speculate a couple of reasons why they might not:

• Some L2CP can be handled by the NPU or some other processor local to linecard module, and so would never be punted up to the control plane CPU. This might have implications for order-of-operations on packet processing. That is, handling of L2CP might always occur before application of PACLs.
• Catastrophe prevention: if your PACL filtered out PAgP/LACP or STP, then potentially an L2 loop could be formed with a subsequent broadcast domain meltdown.

The PMs/TMEs/DEs who are responsible for PACLs would have the real rationale for this restriction.