Configuration guidelines for bACLs

The configuration considerations for bACLs are as follows:

• You can apply no more than one bACL at device level.
• You can apply no more than one bACL to an interface or VE.
• bACLs applied at device level filter traffic both on default-VRF and user-vrf interfaces.
• If a physical port is a member of a virtual interface, then ACL binding is permitted only at the VE level and not at the physical port level.
• If bACLs are applied both at device level and at interface- or VE-level, a match at interface- or VE-level takes precedence over a match at device level.
• For LAG ports, all ports within the LAG must have the same IP broadcast ACL applied to them before the LAG is created. On deleting the LAG, the IP broadcast ACL binding is replicated on all individual LAG ports.
• IP directed-broadcast ACL binding is not be permitted on VPLS and VLL endpoints.
• IP tunnel interfaces are not supported.
• Because ingress traffic matching bACLs is not subject to security ACLs or RL-ACLs, configure bACLs so that only directed broadcast traffic matches the bACL permit/deny/hard-drop rules.
• bACLs do not support ACL-based logging, Sample Flow (sFlow), or mirroring.
• Traffic matching bACLs is not subject to policy-based routing (PBR).
• CAM sharing is not supported for bACLs.
• Broadcast ACLs do not filter /31 addresses—because the /31-subnet supports only two unicast addresses.
• When ACLs of multiple types are applied, processing priority is as follows: bACLs > rACLs > PBR > Layer 3 ACLs > Layer 2 ACLs. However, if any filter has a drop match, the packet is dropped irrespective of the priority.
• When ACLs of multiple types are applied, processing priority is as follows: bACLs > rACLs > PBR > Layer 3 ACLs > Layer 2 ACLs > UDAs. However, if any filter has a drop match, the packet is dropped irrespective of the priority.