• Tag : 4.22.1F

 
 

SSU support for L2 EVPN with VXLAN

Description Smart System Upgrade (SSU) aims to minimize traffic loss during a software upgrade. The Smart System Upgrade (SSU) process includes the core functionality of Accelerated Software Upgrade, plus additional optimizations that permit a hitless restart of several features. SSU leverages protocols capable of graceful restart to minimize traffic loss during upgrade. For protocols not capable of graceful restart, SSU generates control plane messages and buffers them in hardware to be slowly released when the control plane is offline. Additionally, under SSU, the forwarding ASIC does not get reset and ports do not flap. Starting EOS 4.22.1F SSU is now...
Continue reading →

Inter-VRF Local Connected Route Leaking

Description This feature allows the leaking of connected routes from one VRF (the source VRF) to another VRF (the destination VRF) on the same router. Connected routes can be leaked using the following methods: BGP based leaking using the appropriate import and export route targets configured on the source and destination VRFs. VrfLeak Agent based leaking using the appropriate subscription policy in the destination VRF. Leaking connected routes differs from leaking other types of routes in that it causes additional routes to be leaked. These additional routes are: Attached routes covered by the connected route being leaked. An attached route...
Continue reading →

BGP per AFI/SAFI Update Wait-for-Convergence

Description BGP update wait-for-convergence feature prevents BGP from programming routes into hardware and advertising routes to other BGP peers until a convergence event is resolved, which can reduce CPU and hardware programming churn. The existing BGP update wait-for-convergence feature can only be configured at BGP instance level (router-bgp) for all address families.  In certain EVPN deployment scenarios, BGP is used for both overlay (EVPN) and underlay (IPv4 Unicast). Overlay EVPN sessions are typically dependent on underlay IPv4 unicast routes, because EVPN sessions can only be established after underlay IPv4 unicast routes are installed. Since “update wait-for-convergence” is enabled at BGP...
Continue reading →

Pseudowire Resolution Over User-defined Tunnel RIBs

Description This feature allows configuring user-defined tunnel RIBs for the resolution of LDP pseudowire endpoints. User-defined tunnel RIBs were introduced in EOS 4.22.0F.   Applications can have different requirements and preferences for the tunnel protocols they use. This necessitates the use of separate tunnel RIBs for specific requirements. Pseudowires, too, can be configured to be resolved over user-defined tunnel RIBs. Platform Compatibility Resolution of LDP pseudowires over user-defined tunnel RIBs is available on all platforms supporting LDP pseudowires. For the full list of supported platforms, please see LDP pseudowires. Configuration The tunnel RIB used by pseudowires is configured by the...
Continue reading →

RSVP-TE Bandwidth Management

Description RSVP-TE Bandwidth management feature allows signaled paths to reserve a specified amount of bandwidth per egress interface on a Label Switching Router (LSR). Platform compatibility 7500R, 7280R family of switches Configuration To enable bandwidth management, first same set of steps should be taken as to enable RSVP-TE:  MPLS should be enabled IP routing should be enabled IS-IS should be enabled Traffic engineering should be enabled The amount of traffic-engineering bandwidth must be specified: (config-te)#interface Ethernet1 (config-if-Et1)#traffic-engineering (config-if-Et1)#traffic-engineering bandwidth [<bandwidth>]   The exact amount of bandwidth available per interface is an optional parameter. If omitted, the 75% of the interface’s...
Continue reading →

RSVP-TE Node Protection

Description RSVP-TE node protection is a Fast-ReRoute feature that provides protection against the failure of nexthop LSR in the protected LSP. It works by creating a bypass LSP to reach next-nexthop LSR avoiding the next LSR. In case of nexthop link or node failure, traffic is automatically rerouted using the bypass LSP. Platform Compatibility RSVP-TE node protection is supported on Arista 7500R, 7280R family of switches. Configuration Support for Fast Reroute (FRR) node protection/NNHOP (RFC 4090) is enabled by setting the Fast Reroute mode to “node-protection” in mpls-rsvp sub-mode. (config)# mpls rsvp (config-mpls-rsvp)# (config-mpls-rsvp)# fast-reroute mode node-protection Show Commands If...
Continue reading →

DSCP support for CPU generated traffic

Description The differentiated services code point (DSCP) is a 6-bit field in the IP header, which can be used to mark traffic for providing quality of service (QOS). This feature adds the support to set the DSCP value individually for NTP, DNS, Syslog, Traceroute, OSPF, and OSPF3 protocols. All protocol specific traffic leaving the switch will be marked with the configured DSCP value. In the case of NTP, DNS, Syslog, and Traceroute, the configured DSCP value will be applicable for both ipv4 and ipv6 traffic. This feature is an extension to DSCP support. Platform compatibility This feature is provided on...
Continue reading →

Support for TI-LFA FRR using IS-IS Segment Routing

Description Topology Independent Fast Reroute, or TI-LFA, uses IS-IS SR to build loop-free alternate paths along the post-convergence path. These loop-free alternates provide fast convergence in the range of sub-50 ms.   The PLR ( point of local repair – the router where TI-LFA is configured ) switches to these loop-free alternate backup paths in the event of a link down ( link-protection ) or BFD neighbor down (node-protection) event, protecting traffic destined to IS-IS SR node segments, adjacency segments, and anycast segments while the IGP converges and the post-convergence paths are computed. Anycast segment protection is restricted to those...
Continue reading →

Dot1x – User Should Be Able to Set Access Direction

Summary When passive non-Dot1x speaking devices are connected to Dot1x port and it is expected that they would be authenticated by MAC address. These devices would not actively send packets and only respond to poll requests such as ping, arp and etc., but not Dot1x requests. These devices have ip preconfigured, and the switch would have a routed port and SVI for each of access vlans to route traffic to the connecting host/devices once they are authenticated and assigned with a vlan. With current Dot1x design switch blocks forwarding in both ingress and egress directions, and only sends out Dot1x...
Continue reading →

VOQ Delete Logging Using Event-Handler Framework

Description This feature allows customers to take user-defined actions on “VOQ delete” occurrences on Arad/Jericho based platforms. VOQ deletes happen when an active VOQ does not receive any credits and no packets are dequeued from the head of the queue for a fixed period of time (credit watchdog threshold : 500 ms) which leads to the queue entering the “delete state”. All the packets in a VOQ are flushed in this state. With this feature, a user can set the threshold on number of VOQ delete occurrences for an interface within a specified time-window after which the stated action must...
Continue reading →

MPLS VPN Export Without MPLS labels

Description RFC4364 supports exporting VRF routes into the VPN table and advertising these VPN routes to peers. Exporting the VRF IPv4/IPv6 Unicast routes as MPLS VPN routes requires MPLS labels to be allocated for each route. MPLS label allocation is supported only on some platforms. On other platforms, where MPLS label allocation is not supported, VRF routes can still be exported as VPN routes without having to allocate MPLS labels, with the support of this feature. These routes are exported with dummy labels ( explicit-null MPLS label ) if this feature is enabled. Platform compatibility This feature is supported on...
Continue reading →

DHCP Relay Across VRF

The EOS DHCP relay agent now supports forwarding of DHCP requests to DHCP servers located in a different VRF to the DHCP client interface VRF. IP Version 4 Enabling VRF support for the DHCP relay agent has a prerequisite that Option 82 (DHCP Relay Agent Information Option ) is enabled. Option 82 is used by the DHCP relay agent to insert client specific information to pass on to the DHCP server. The DHCP relay agent will insert Option 82 information into the DHCP forwarded request when the DHCP server belongs to a network on an interface that belongs to a...
Continue reading →

7500 and 7280 R3 Series Support

EOS Version 4.22.1F Newly supported Hardware Category Product Description Fixed Configuration 7280CR3-32P4 32x100G QSFP + 4x400G OSFP 7280CR3K-32P4 32x100G QSFP + 4x400G OSFP (large tables) 7500 Series Linecards 7500R3-36CQ 36x100G QSFP Linecard 7500 Series Fabric Cards 7508R3-FM Fabric module for 7508 Chassis 7504R3-FM Fabric module for 7500 Chassis Supported features Layer 1 QSFP100 100G-4/40G/10G/25G/50-2 OSFP 50G-1, 100G-2, 200G-4, 400G-4 OSFP 25G, 50G-2, 100G-4, 10G, 40G OSFP copper OSFP optics OSPF-QSFP Adapter support (with optics) Copper cable support with NRZ autoneg at 25G, 50G, 100G Copper cable support with PAM4 autoneg at 50G and 100G Forward Error Correction (FEC) Speed groups...
Continue reading →

UCMP: Append Interface Speed to Received Link-Bandwidth

Description Unequal Cost Multi Path (UCMP) is a mechanism for forwarding traffic for an ECMP route by using a ratio of weights assigned to each of the route’s next hops.  This is done for BGP by disseminating BGP link-bandwidth extended community attribute information with BGP paths. The receiving device programs next hops for that route in the FIB, in the ratio of the received link-bandwidth values. The link-bandwidth value received by a device may refer to some bandwidth constraint further downstream from the sending device and thus may not take into consideration the bandwidth available on the link between the...
Continue reading →

DirectFlow

Description DirectFlow runs alongside the existing layer 2/3 forwarding plane, enabling a network architecture that incorporates new capabilities, such as TAP aggregation and custom traffic engineering, alongside traditional forwarding models. DirectFlow allows users to define flows that consist of match conditions and actions to perform that are a superset of the OpenFlow 1.0 specification. DirectFlow does not require a controller or any third party integration as flows can be installed via the CLI. Platform Compatibility DirectFlow configuration may vary on different platforms. This TOI describes the configuration for the following platforms: CCS-720XP (Starting in EOS 4.23.0F) DCS-7050CX3 DCS-7050QX DCS-7050SX DCS-7050SX3-48YC8...
Continue reading →

SSL support for CVX AttrLog connections

Description EOS 4.22.1F release adds support for secure In-band connection between CVX and Arista switches. Prior to this release, only Out-of-band connections between CVX and Arista switches supported secure communication.    The executive summary of this change is as follows: Added support for SSL communication in tacc  Added new SSL connection and listener modules in Sysdb and Controllerdb Uses the same configuration as SSL for out-of-band CVX connections. Seamless upgrade paths (see more below) Previously, Arista switches and CVX did not support secure communication over the In-band connections between them and the following was displayed when SSL profiles were in...
Continue reading →

Lanz Mirroring

Description Lanz Mirroring feature allows users to automatically mirror traffic queued as a result of congestion to either CPU or a different interface.  Platform compatibility 7150S-64 7150S-52 7150S-24 7050QX-32 7050QX-32S 7050SX-72Q 7050SX-64 7050SX-72 7050SX-96 7050SX-128 7050TX-48 7050TX-64 7050TX-72 7050TX-96 7050TX-128 7050TX-72Q 7060CX-32S 7060CX-32S-ES 7060CX2-32S 7060SX2-48YC6 7050QX2-32S 7050SX2-72Q 7050SX2-128 7050TX2-128 7010T-48 7010T-48-DC Configuration Enabling LANZ Mirroring LANZ mirroring is disabled by default. In order to enable LANZ mirroring, LANZ must be enabled. Enabling LANZ mirroring will also reserve one port mirroring session. Arista(config)#queue-monitor length mirror Arista(config)#no queue-monitor length mirror Arista(config)#default queue-monitor length mirror Selecting Destination Interface When congestion occurs on any...
Continue reading →

RFC 7606: BGP Enhanced Error Handling

Platform Compatibility Multi Agent, Platform independent. Show Commands Related information can be seen under the heading Update Attribute Errors in the output of:  show bgp neighbor Description This feature supports RFC 7606, which  provides improved security and robustness in the processing of errors in the BGP Update messages that are received from peer routers. In earlier releases, the BGP agent would reset the BGP peering session according to RFC 4271 (BGP for IPv4) and RFC 4760 (Multi-protocol BGP) if it detected errors in the BGP Updates received from a given peer. This feature was supported by the BGP implementation in...
Continue reading →

VLAN Aware PTP Boundary Clock – Single BMCA

Description This feature makes the PTP agent aware of VLANs, running with a single Best Master Clock Algorithm (BMCA). It allows you to enable PTP on certain VLANs on a trunk port, on which PTP packets will be sent and processed. By default, enabling PTP on a trunk port will follow the previous behaviour, which is to only egress PTP packets VLAN untagged on the native VLAN and process ingress PTP packets regardless of their VLAN tag. With this feature, PTP states are now per-port per-VLAN pair and ingress/egress PTP packets on a trunk port is based on the VLAN...
Continue reading →

SSH Certificates

Description SSH certificates (as implemented by OpenSSH, introduced in version 5.4) allow for easy management of user authentication and authorization for passwordless logins, as well as host verification. User authentication is achieved through having a certificate authority (CA) that signs user public keys with its private key, while configuring sshd to trust that CA’s public key. User authorization is achieved by signing the user key with specific principals, which define which accounts the user is allowed to login as. Signing the user key with the CA private key generates the user’s certificate, which the user will present when attempting to...
Continue reading →

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: