Tag :: Nexthop Group

This document describes the on_nexthop_group_programmed event within the context of both the EOS SDK and the EOS SDK RPC agent. This event is triggered when there is an update to the state of a watched nexthop group.   These state updates include both the hardware programming of the group itself, as well as the hardware status of any counters associated with the group.

Enhancement of QOS class maps to match on nexthop groups along with dscp (dscp being optional) to set any QOS actions

The nexthop group feature allows users to manually configure a set of tunnels. Nexthop group counters provide the ability to count packets and bytes associated with each tunnel nexthop, irrespective of the number of times it appears in one or more nexthop groups. In other words, if a nexthop group entry shares a tunnel resource with another entry, they will also share the same counter.

When a static route is configured with a nexthop group, by default the static route is eligible for FIB insertion

Nexthop groups is a routing mechanism where users can configure a set of nexthops by specifying their nexthop

This feature comprises two parts:

To extend Traffic Steering to Nexthop Groups (GRE) by allowing us to specify one or more nexthop groups of type DzGRE (DANZ GRE) as the destination for a TAP aggregation steering policy. A DzGRE header will be encapsulated to the packets sending out a nexthop group of type DZGRE.

To extend GRE Tunnel Termination by allowing decapsulation of traffic received from nexthop groups of type DZGRE and adding VLAN tags based on DZGRE metadata.

Traffic steering to nexthop groups allows specifying one or more nexthop groups as the destination for a TAP aggregation steering policy. Traffic steering is a TAP aggregation process that uses class maps and policy maps to direct data streams received on TAP ports.