Previously, by default, 802.1X allowed only one MAC address on each port at a time. This lead to major constraint in current network deployments where multiple hosts or MAC addresses were connected on a single port. Now, multi-auth and multi-host modes are supported by 802.1X to allow multiple hosts or MAC addresses on a single port. By default, dot1x configured port is in multi-auth mode. However, this behaviour can be altered by changing the host mode under dot1x profile. 802.1X port-control is also supported on pre-configured VLAN sub-interfaces along with multi-auth and multi-host modes. For VLAN sub-interfaces with VLAN IDs to be pre-configured, VLAN tagged traffic is allowed only after successful 802.1X authentication of the port.

For more information, see Protect Network using IEEE 802.1X Port-Based Authentication.

The command, dot1x host-mode is introduced.

BFD over Bundle with IPv4 Unnumbered Interface feature enables BFD to run on IP unnumbered interfaces, which take the IP address from the loopback address. This feature saves IP addresses space or range. The same loopback address is used on multiple interfaces.

For more information, see BFD over Bundle with IPv4 Unnumbered Interface

With the introduction of the BFD support on HSRP/VRRP, HSRP/VRRP will use BFD to detect a link failure and facilitate fast failover times without excessive control packet overhead.

With this feature, you can:

• Identify failure detection in less than one second.

• Support all types of encapsulation.

• Have support for almost all routing protocols.

For more information, see:

• Implementing HSRP

• Configuring VRRP

With the introduction of the BGP PIC multipath IPv4/IPv6 with interface peering support, BGP control plan installs multiple primary paths and one backup path for all primary paths in the BGP routing table. If one of the primary paths doesn’t work, the system adds a backup into the primary path.

For more information, see Additional-Path.

The Cisco Secure Boot subsystem verifies that the device boot image is genuine and untampered. The hardware-anchored secure boot process is designed to ensure that only genuine, unmodified code is allowed to boot on the following variants of the Cisco 540 Series Routers:

• N540-28Z4C-SYS-A

• N540-28Z4C-SYS-D

• N540-12Z20G-SYS-A

• N540-12Z20G-SYS-D

• N540X-12Z16G-SYS-A

• N540X-12Z16G-SYS-D

• N540X-16Z4G8Q2C-A

• N540X-16Z4G8Q2C-D

For more information, see Boot Integrity and Trust Visibility.

The Bridge-group Virtual Interface (BVI) with Double-Tagged AC Support feature allows you to configure the attachment circuit (AC) with double-VLAN tag encapsulation on the BVI. You must specify the rewrite ingress pop 2 symmetric option when you configure the AC on the BVI with double-VLAN tag encapsulation.

For more information, see Configure VLAN Sub-Interfaces.

Applicable only to Cisco N540-28Z4C-SYS-A/D, N540-12Z20G-SYS-A/D, N540X-12Z16G-SYS-A/D, and N540X-16Z4G8Q2C-A/D router variants.

Malicious attacks can come from various sources – starting from the CPUs or ASICs containing Trojan or malware. Sometimes, the chips may have a Trojan in the form of an added die in the package assembly. Cisco’s Chip Guard feature mitigates this threat with the use of unique identifiers that are buried inside the Trusted Anchor module (TAm) devices as a way to identify and track components throughout the lifecycle of products.

For more information, see Chip Guard.

Traditional Hierarchical QoS (H-QoS), while allowing for granular and multi-level management of traffic, does not allow for conforming traffic from a child-level policy to a parent-level policy to get priority. This inability means that in case of excess traffic, the parent policer drops conforming traffic packets as well.

With the conform-aware hierarchical policy feature, the parent policer is prevented from dropping any conforming traffic from child policers, thus increasing traffic throughput and efficiency.

For more information, see Conform Aware Hierarchical Policy Overview.

The command, hw-module profile qos conform-aware-policer is introduced.

With the introduction of egress interface published as part of ingress NetFlow, you can capture traffic flow for IP packets on the egress interface or on the outgoing interface of a router.

For more information, see IPFIX 315 Implementation Considerations.

With the introduction of the EVPN convergence improvements for BGP PIC, the following networks are supported, which rides over BGP PIC as transport:

• LxVPN

• EVPN

• 6PE

• 6VPE

For more information, see BGP PIC Implementation Considerations.

The EVPN E-Tree using Route Target (RT) constraints feature enables you to configure BGP RT import and export policies for an attachment circuit (AC). This feature allows you to define communication between the leaf and root nodes. The provider edge (PE) nodes can receive L2 traffic either from the attachment circuit (AC) of a bridge domain (BD) or from the remote PE node. For a given BD, L2 communication can only happen from a root to leaf and leaf to root nodes. This feature does not allow any L2 communication between the ACs of two or more leafs.

This feature provides the following benefits:

• Achieve efficiency of the BGP MAC routes scale

• Reduce the consumption of hardware resources

• Utilize the link bandwidth efficiently

The command, etree rt-leaf is introduced.

The GPRS Tunneling Protocol (GTP) Load Balancing feature enables efficient distribution of traffic in mobile networks, and provides increased reliability and availability for the network.

GTP load balancing is performed on IPv4 or IPv6 incoming packets with GTP payloads and on MPLS incoming labeled packets. This feature supports GTP hashing only when the GTP UDP port is 2152.

The number of MPLS label stack in the transport layer is limited to three for GTP hashing. GTP hashing is not considered when the MPLS label stack exceeds three.

For more information, see GTP Load Balancing.

This release introduces support for manually configured BGP Egress Peer Engineering (EPE) Peer SIDs. The ability to manually configure BGP-EPE peer SIDs allows for persistent EPE label values. Manual BGP-EPE SIDs are advertised through BGP-LS and are allocated from the Segment Routing Local Block (SRLB).

For more information, see Configuring Manual BGP-EPE Peering SIDs.

The Network Convergence using Core Isolation Protection feature allows the router to converge fast when remote links and local interfaces fail. This feature reduces the duration of traffic drop by rapidly rerouting traffic to alternate paths. This feature uses Object Tracking (OT) to detect remote link failure and failure of connected interfaces.

Tracking interfaces can only detect failure of connected interfaces and not failure of a remote router interfaces that provides connectivity to the core. Tracking one or more BGP neighbor sessions along with one or more of the neighbor’s address-families enables you to detect remote link failure.

For more information, see Network Convergence using Core Isolation Protection.

The command, if track is is introduced.

Currently, the steering of traffic through a Segment Routing (SR) policy is based on the candidate paths of that policy. For a given policy, a candidate path specifies the path to be used to steer traffic to the policy’s destination. The policy determines which candidate path to use based on the candidate path’s preference and state. The candidate path that is valid and has the highest preference is used to steer all traffic using the given policy. This type of policy is called a Per-Destination Policy (PDP).

Per-Flow Automated Traffic Steering introduces a way to steer traffic on an SR policy based on the attributes of the incoming packets, called a Per-Flow Policy (PFP). A PFP provides up to 8 "ways" or options to the endpoint. With a PFP, packets are classified by a classification policy and marked using internal tags called forward classes (FCs). The FC setting of the packet selects the “way”. For example, this “way” can be a traffic-engineered SR path, using a low-delay path to the endpoint. The FC is represented as a numeral with a value of 0 to 7.

For more information, see Per-Flow Automated Steering.

This feature allows you to add BUM traffic queueing support for attachment circuits in a bridge domain. BUM traffic is replicated through Ingress Replication, and the replicated packets use the Ingress VOQ.

For more information, see Queueing Support for BUM Traffic on Attachment Circuits.

The command, flood mode ac-ingress-replication is introduced.

After you configure the PTP profile on a T-BC or a T-TSC, any change in PTP offset from the T-GM clock triggers an immediate reaction in the servo. With the Slow Tracking feature enabled, the servo corrects any change in the phase offset in steps. The correction is based on the configured value which can be slower than the normal correction rate.

For more information, see PTP Slow Tracking.

Segment routing egress peer engineering (EPE) uses a controller to instruct an ingress provider edge, or a content source (node) within the segment routing domain, to use a specific egress provider edge (node) and a specific external interface to reach a destination. BGP peer SIDs are used to express source-routed interdomain paths. BGP peer SID types include Peer Node SIDs and Peer Adjacency SIDs.

This release adds support for a new type of BGP peering SID, called BGP Peer Set SID. A BGP Peer Set SID is a group or set of BGP peer SIDs, and can be associated with any combination of Peer Node SIDs or Peer Adjacency SIDs. Peer Set SIDs provide load balancing over BGP neighbors (nodes) or links (adjacencies).

For more information, see Segment Routing Egress Peer Engineering.

Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required (on-demand). SR-ODN provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated with a desired underlay SLA. The functionality applies equally to single-domain and multidomain networks.

An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. This release introduces SR-ODN support for EVPN services with either single-homing or multi-homing configurations.

For more information, see On-Demand SR Policy – SR On-Demand Next-Hop.

Segment Routing On-Demand Next Hop (SR-ODN) allows a service head-end router to automatically instantiate an SR policy to a BGP next-hop when required (on-demand). SR-ODN provides per-destination steering behaviors where a prefix, a set of prefixes, or all prefixes from a service can be associated with a desired underlay SLA. The functionality applies equally to single-domain and multi-domain networks.

An on-demand SR policy is created dynamically for BGP global or VPN (service) routes. This release introduces SR-ODN support for EVPN-VPWS services with multi-homing configurations.

For more information, see On-Demand SR Policy – SR On-Demand Next-Hop.

Currently, a Flexible Algorithm definition is unknown to the Segment Routing Path Computation Element (SR-PCE). In order to select a Flexible Algorithm across domains, Flexible Algorithm definition can now be distributed to a PCE topology database from the gateway ABR/ASBR. The SR-PCE Flexible Algorithm Multi-Domain Path Computation feature incorporates the following changes:

• BGP-LS has been augmented to carry a Flexible Algorithm definition (FAD)

• PCEP vendor-specific objects have been added to indicate SR policy Flexible Algorithm constraints to the PCE and to request a path computation based on the Flexible Algorithm number

• PCE algorithms have been augmented to compute paths based on a Flexible Algorithm constraint

For more information, see SR-PCE Flexible Algorithm Multi-Domain Path Computation.

The Segment Routing TI-LFA (Topology independent Loop-free alternate) Support for GRE Tunnels feature extends the TI-LFA logic to span different instances or different IGP domains by using a Generic Routing Encapsulation (GRE) tunnel that runs between two ABRs as a backup path for TI-LFA protection in an SR Core. GRE is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol by means of encapsulation.

For more information, see SR-MPLS over GRE as TI-LFA Backup Path.

From Release 7.2.1 onwards, you can configure peak burst size for egress shaping. This configuration gives your router interface the ability to manage the traffic burst for a particular traffic class such that the peer node can accommodate the burst and does not drop packets either due to lower burst policing or due to shorter queue depth.

For more information, see Configure Traffic Shaping.

The command, shape average is modified.

With the shared policer feature, you can now share a policer bucket among two or more classes. You can also view the statistics in aggregated mode or per-class mode.

For more information, see Shared Policer.

The command, hw-module profile qos shared-policer-per-class-stats is introduced.

A Path Computation Element (PCE) computes SR-TE that is paths based on the SR-topology database that stores the connectivity, state, and TE attributes of SR network nodes and links. BGP Labeled Unicast (BGP-LU) provides MPLS transport across IGP boundaries by advertising the loopbacks and label binding of edge and border routers across IGP boundaries.

The SR-PCE Inter-Domain Path Computation Using SID Redistribution feature adds new functionality to the SR-PCE that enables it to compute a path for remote non-SR end-point devices that are distributed by BGP-LU.

For more information, see Inter-Domain Path Computation Using Redistributed SID.

This feature introduces support for SRv6 Anycast Locator. An SRv6 Anycast locator is a type of locator that identifies a set of nodes (END SIDs). SRv6 Anycast Locators and their associated END SIDs may be provisioned at multiple places in a topology. Anycast routing enables the steering of traffic toward multiple advertising nodes. Packets addressed to an Anycast address are forwarded to the topologically nearest nodes.

One use case is to advertise Anycast END SIDs at exit points from an SRv6 network. Any of the nodes that advertise the common END SID could be used to forward traffic out of the SRv6 portion of the network to the topologically nearest node.

For more information, see Segment Routing over IPv6 Overview.

The Support for DHCPv4 and DHCPv6 Client over the BVI feature allows you to configure DHCPv4 and DHCPv6 client on the Bridged Virtual Interface (BVI). You can configure a BVI, and request DHCP IPv4 or IPv6 address on the BVI. This configiration allows your customer’s device to have initial connectivity to your network without any user intervention in the field. After the device is connected to your network, the customer devices can push a node-specific configuration with static IP addresses on a different BVI for a customer deployment.

For more information, see Support for DHCPv4 and DHCPv6 Client over BVI.

TCP Message Digest 5 (MD5) authentication is used for authenticating PCEP (TCP) sessions by using clear text or encrypted password. This feature introduces TCP Authentication Option (TCP-AO), which replaces the TCP MD5 option. TCP-AO is compatible with Master Key Tuple (MKT) configuration. TCP-AO also protects connections when using the same MKT across repeated instances of a connection. TCP-AO protects the connections by using traffic key that are derived from the MKT, and then coordinates changes between the endpoints.

For more information, see TCP Authentication Option.

With this feature, you can lperform oad-balance for incoming traffic over multiple paths of varying costs. UCMP applies a weight to a path, and adds more forwarding instances to a path that has a higher weight (or larger bandwidth). This feature results in an equal load distribution over paths of varying bandwidths (and costs).

For more information, see UCMP Over MPLS-TE.