• Tag : 4.20.1F

 
 

BGP Monitoring Protocol

Introduction BGP Monitoring Protocol (BMP) [1] allows a monitoring station to connect to a router and collect all of the BGP announcements received from the router’s BGP peers. The announcements are sent to the station in the form of BMP Route Monitoring messages formed from path information in the router’s BGP Adj-Rib-In tables. A BMP speaker may choose to send either pre-policy routes, post-policy routes, or both. BMP is unidirectional: Messages are sent from the router to the monitoring station. No messages are ever sent from the monitoring station to the router. The information sent to a monitoring station is controlled by the router’s...
Continue reading →

MP BGP for v4 multicast

Introduction The feature MP-BGP v4 Multicast provides a way to populate the MRIB (Multicast Routing Information Base). MRIB is an alternate routing table used in PIM’s RPF (Reverse Path Forwarding) lookup. Up until now, there was only one way to populate the routes in the MRIB. Users can add a static route into the MRIB via the ip mroute command. With BGP support for multicast SAFI in EOS 4.20.1F, users can advertise multicast static routes and connected routes to other PIM routers. These routes learned via BGP are stored in the MRIB. Additionally, users should be aware that the RPF...
Continue reading →

OSPFv3 Flood Pacing

EOS release 4.20.1F adds OSPFv3 flood pacing support that allows configuring the minimum interval between the transmission of consecutive LS update packets. This feature prevents the draining of the flood queue at once generating multiple LS update packets. Flood pacing helps mitigate high CPU or socket buffer utilization issues observed when a large number of LSAs get flooded at once. Increasing the flood pacing interval will help reduce LSA flooding in scenarios where the LSDB is being updated frequently. It should be noted that in case of large OSPF LSDBs, increasing the flood pacing interval to a larger than requried...
Continue reading →

RFC 7606: BGP enhanced error handling

This feature supports RFC 7606 to provide improved security and robustness in the processing of errors in the BGP Update messages that are received from peer routers. In the earlier releases, the Rib 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 will provide the following new functionality:   Treat-as-withdraw: In certain scenarios, the malformed BGP Update will be treated in such a way that all contained routes have been withdrawn by the peer instead of being installed in...
Continue reading →

UCMP for LU over v4/v6

The BGP labeled-unicast (LU) RFC is used to advertise BGP routes with a stack of MPLS labels, thereby allowing distribution of MPLS tunnel paths through BGP. This feature enables deriving and using link-bandwidth attribute for BGP LU paths which further enables applying weighted nexthop sets for BGP LU routes installed in IP FIB and for IP routes resolving over LU tunnel routes. As part of UCMP support for BGP LU routes, the following functionality has been added: IP routes resolving over BGP LU routes should be able to inherit the link-bandwidth information from the resolving BGP LU route (if the...
Continue reading →

IS-IS Graceful Restart

IS-IS Graceful Restart adds support for Restart Signaling for IS-IS, IETF RFC 5306. When IS-IS is used as the IGP, the following EOS features require NSF and support for the graceful restart from IS-IS: ASU2 – Software upgrades. SSO – Planned SSO initiated by an operator for maintenance or Unplanned SSO due to failures on the active supervisor. RIB agent restart due to software failures. With IS-IS Graceful Restart (GR) configured, a redundancy switchover from active to standby supervisor or ASU2 or restart of the IS-IS software (the RIB Agent) should, if the GR completes successfully, be a hitless event.  Which means that neighbor routers continue to...
Continue reading →

URL based import of AS path access lists

This feature adds the capability to import as path access-list from a URL, in release 4.20.1F.  The file specified by the URL can contain one or more as-path access-list entries. All the entries that are in the file are added to the as-path access-list being configured. This feature gives the advantage of using one EOS CLI command to configure many as-path access-list entries, instead of adding each one of them line by line in the CLI. Platform compatibility This is a platform independent feature.   Configuration [no] ip as-path access-list list_name source URL duplicate DUPLICATE_HANDLING Parameters list_name         the name of...
Continue reading →

BGP Aggregate Address Advertise-only

The aggregate address advertise-only feature adds the capability of NOT installing the Null0 route in the FIB/kernel for an aggregate route while still advertising it to BGP peers. By default, BGP aggregates are installed as a drop/Null0 route which will blackhole destinations in the aggregate prefix’s range that don’t have a more specific route. With this feature enabled, the drop/Null0 route is not installed thereby allowing a covering route (say the default route) to route such traffic. Configuration The CLI option will appear under the “aggregate-address” command in router-bgp mode.  The full syntax of the CLI is given below with...
Continue reading →

BGP route-map match on route type

Introduction This feature adds support for a ‘match route-type’ route-map match clause in release 4.20.1F. This clause allows filtering routes based on the peer from which the route was learned. Specifically, the user can match on ‘external’, ‘internal’, ‘local’, or ‘confederation-external’ which match on EBGP, IBGP, locally originating (e.g. aggregate), or confed-EBGP routes, respectively. This clause has a wide range of potential use cases. One use case is to add specific communities to all externally (EBGP) routes prior to propagating them into a customer’s network. Configuration In order to configure this feature, the following command is configured in the route-map...
Continue reading →

Expanded VRRP, VARP, and MLAG Peer Gateway Virtual MAC Capabilities on the 7500R, 7280R, 7500R2, 7280R2, 7020R Series

EOS-4.20.1F introduces expanded VRRP, VARP and MLAG Peer Gateway virtual MAC capabilities on the 7500R, 7280R, 7500R2, 7280R2, and 7020R series because of improved hardware capabilities. The highlights are: Simultaneous support for VRRP, VARP and MLAG Peer Gateway. VARP and MLAG Peer Gateway take priority over VRRP Support for IPv4 and IPv6 Dual Stack VRRP Platform Compatibility DCS-7500R/R2 series DCS-7280R/R2 series DCS-7020R series Configuration For detailed VRRP, VARP, and MLAG Peer Gateway configuration information and examples please refer to links in the Resources section. Hardware oversubscription on the 7500R, 7280R, 7500R2, 7280R2, and 7020R series is defined as exceeding 16...
Continue reading →

Tap aggregation – traffic steering on MPLS labels

This article describes the Tap Aggregation Traffic Steering on MPLS Labels feature. The purpose of this feature is to allow steering of MPLS packets based on their labels. A packet is considered an MPLS packet when the first header is Ethernet with Ethertype=0x8847 (MPLS). Platform compatibility DCS-7280E DCS-7280R DCS-7500E DCS-7500R DCS-7280R2 Configuration TCAM profile This feature requires the tap-aggregation-extended TCAM profile. The profile should be specified when enabling Tap Aggregation, for example: 7500(config)#tap aggregation 7500(config-tap-agg)#mode exclusive profile tap-aggregation-extended MPLS labels rules MPLS labels rules are specified in the MAC access-list rules for MPLS-type packets. The rules can match on any...
Continue reading →

Connectivity Monitor

Connectivity Monitor is an EOS feature that allows users to monitor their network resources from their Arista switches. The resources being monitored may or may not be Arista devices. Connectivity monitoring is unidirectional in nature.   Supported Platforms This feature is supported on all platforms Configuration Connectivity Monitor is configured under the monitor-connectivity submode: Arista(s1)(config)# monitor connectivity Arista(s1)(config-mon-connectivity)#? interval Configure connectivity probe interval host Configure host parameters shutdown Shutdown connectivity monitoring Host is used to configure the end points being monitored. A host is associated with a single IPv4 address and an HTTP or HTTPS URL.  Arista(s1)(config-mon-connectivity)#[no] host AWS-EAST Arista(s1)(config-mc-AWS-EAST)#?...
Continue reading →

EAPI configurable in multiple VRFs

This feature allows eAPI to run in multiple non-default VRFs on the same physical router. In this way, users can configure Arista switch through eAPI from both default and management VRF. Platform compatibility This feature is supported on all platforms Configuration To run eAPI in more than one VRFs, from “management api http-commands” mode, you can enter each VRF mode by command “vrf <vrfName>”. In this submode, you can enable or disable eAPI running in each VRF, including the default VRF, by typing “[no|default] shutdown”. If no VRF is configured and eAPI is enabled then it will run in default VRF. Note: for backward compatibility, when...
Continue reading →

Config Checkpoint

  Config checkpoint mechanism provides a shortcut to copy the current running-config into a file stored in checkpoint directory. Checkpoint can be made specifically by the user or it will be generated automatically before session commit or configure replace. Checkpoint allows user to preserve a series of snapshots of running-config in the flash and reload later. It can be used as a backup to rollback to previous config, or it can be saved as a configuration template to be operated multiple time in the future. Platform compatibility Config checkpoint works on all EOS platforms. Configuration To make a checkpoint: Arista#configure...
Continue reading →

LANZ on 7160 series

  Introduction LANZ on 7160S-32CQ, 7160-48YC6 and 7160-48TC6 adds support for monitoring congestion on front panel ports with Start, Update and Stop congestion events. This feature is supported on 7160 from EOS version 4.20.1F onwards. Platform compatibility 7160S-32CQ 7160-48YC6 7160-48TC6 Configuration LANZ can be enabled on the switch with the following command: 7160(config)#queue-monitor length This enables LANZ on all front panel ports with the default high and low threshold values. LANZ can be disabled on interface Ethernet1 with the following command: 7160(config-if-Et1)#no queue-monitor length 7160 uses a default high threshold of 450 pages and low threshold of 128 pages: 7160(config-if-Et2)#default...
Continue reading →

Policing: Rate limiting packets based on Ether Type

Introduction Traffic is managed through policy maps that apply data shaping methods to specific data streams. A policy map is a data structure that identifies specific data streams and then defines shaping parameters that modify packets within the streams. QoS policy maps are user-defined. The switch does not provide preconfigured QoS policy maps and in the default configuration, policy maps are not applied to any Ethernet or port channel interface. Policy maps and class maps are created and applied to interfaces through configuration commands. A QoS policy map is composed of one or more classes. Each class contains an eponymous...
Continue reading →

Arista EOS-4.20.1F TOI Index Page

Arista Platform Independent Features Config Checkpoint OpenConfig – NETCONF and Interface Counter Models eAPI – Support for multiple VRFs Connectivity Monitor CVX VIP VLAN Aware bundle mode for EVPN BGP route-map match on route-type Advertise-only option to the aggregate-address command Route-map URL BFD for Static routes IS-IS GR support IPv6 Neighbor Discovery Enhancements UCMP over Labeled Unicast Tunnels for IPv4 RFC 7606 – BGP enhanced error handling OSPFv3 Flood Pacing Support for BGP IPv6 Labeled Unicast MP-BGP for v4 Multicast BGP Monitoring Protocol L3 EVPN MPLS IPv6 RA inconsistent logging Redistribute static routes pointing to next-hop group via BGP Host...
Continue reading →

100G unidirectional links

Starting 4.15.2F, this feature provides a capability to use a 100G link as a unidirectional link. There are 3 unidirectional link modes: send-only, receive-only, and send-receive. In send-only mode, the interface can only send packets but cannot receive any packet. In receive-only mode, the interface can only receive packets but cannot send any packet. In send-receive mode, the interface can both send and receive packets. However, the interface sends packets to one partner interface but receives packets from a completely different partner interface. In unidirectional link modes, any protocol that requires two-ways interactions on the link will not work properly....
Continue reading →

Filtered Mirroring of MPLSoGRE Packets

MPLSoGRE Filtered Mirroring is a specialized version of Mirroring to GRE Tunnel and Filtered Mirroring in which IPv4oMPLSoGRE and IPv6oMPLSoGRE packets entering a GRE tunnel endpoint on which an MPLS lookup is performed may also be be selected for mirroring based on the destination IP address field in the inner IPv4 or IPv6 header. Packets selected for mirroring will have the following header format: The packets described above when forwarded based on either the L2 or outer L3 header destination address will not be subject to mirroring. When mirroring to a GRE tunnel, the payload of the outgoing GRE packet...
Continue reading →

Traffic Steering using User-Defined Fields

This article describes the TAP Aggregation User-Defined Fields feature. The purpose of the User-Defined Fields feature is to provide custom offset pattern matching to be used in TAP Aggregation Traffic Steering. This allows for deeper packet inspection of up to 128 bytes. User-Defined Fields, or UDFs, are defined as part of an access-list filter and are comprised of an offset, length and pattern match. This describes a single portion of any incoming packet to match the provided value upon. Access-list filters containing a UDF are then applied as usual as part of a TAP Aggregation Traffic Steering policy. UDFs may also be...
Continue reading →

Follow

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

Join other followers: