Tag :: Traffic Policy

ACL based traffic management often requires matching packets’ destination addresses against one or more sets of

Creating Traffic Policies that regulate control plane traffic from BGP peers by writing the list of BGP peer addresses statically in a field-set is error prone and difficult to update. Selecting only internal or external peers requires additional care. This feature automatically populates a field-set with IPv4 or IPv6 prefixes corresponding to iBGP or eBGP peers. 

This feature enables IPv6 access control list (ACLs) on cloudEOS and AWE-series platforms, providing access control on incoming traffic (ingress direction). ACLs use packet classification to mark certain packets going through the packet processor pipeline and then take configured action against them. Rules are defined based on various fields of packets.

This feature adds support to interface traffic policies for routing matched unicast IPv4 or IPv6 traffic which ingresses on L3 interfaces according to the routing table of a secondary VRF.

The feature adds support for redirecting traffic matching on traffic policy rules applied to an egress interface to a specified next-hop or next-hop group. This feature requires the packet to be recirculated a second time through the packet forwarding pipeline to get its configured single or multiple next-hops to be resolved. This is achieved by configuring traffic-policy with redirect interface action applied on egress interface in conjunction with ingress redirect next-hop action applied on the recirculation interface. Redirect interface action is used to forward the egressing packet through an interface on which traffic loop-back ( a.k.a recirculation ) is enabled.

This feature extends the capabilities of Tap Aggregation traffic steering to allow for using interface traffic policies. Initially, interface traffic policies only allowed packet drop, count, qos (set traffic class, set dscp) and log actions.

Access Control Lists (ACL) use packet classification to mark certain packets going through the packet processor pipeline and then take configured action against them. Rules are defined based on various fields of packets and usually TCAM is used to match packets to rules. For example, there can be a rule to match the packet source IP address against a list of IP addresses, and drop the packet if there is a match. This will be expressed in TCAM with multiple entries matching the list of IP addresses. Number of entries is reduced by masking off bits, if possible. TCAM is a limited resource, so with classifiers having a large number of rules and a big field list, TCAM runs out of resources.

This feature introduces the support for Traffic Policy on VLANs. Traffic Policy allows the user to configure rules to match on certain packets through the packet processing pipeline. The user can also place actions to match packets.

This feature enables applying traffic policies on incoming traffic and redirecting the traffic to a nexthop other than the one the routing logic would choose. This essentially overrides the routing logic decision. If there is no rule matching the packet, the packet is sent to the routing logic to be routed.