Tag :: BGP

BGP VPN routes today advertise a label by dynamically allocating it from a dynamic label range block without providing the user any control over the label value that is allocated per VRF’s address Family - VPNv4 or VPNv6. This feature allows the user to configure a unique label per VRF’s configured address-family, VPNv4 or VPNv6, thereby allowing the user granular control over the label value advertised with VPN routes exported from a VRF.

The feature adds cross-VRF support for dynamic prefix-list.

Dynamic prefix-list policy construct is similar to the traditional IP and IPv6 prefix-list, except that they have an additional state associated. This state associated with the dynamic prefix-lists, is determined on the basis of the route entries in FIB, and hence as and when the FIB changes, the state also changes dynamically. This state determines the dynamic prefix-list behavior, when used in route-map/RCF match clauses or route injection.

The “maximum-paths <m>” (default m=1) configuration that controls BGP’s multipath behavior, is available as a global knob, and not as a peer/peer-group knob today in EOS. When “maximum-paths” CLI is configured with m > 1, BGP starts forming ECMP groups for paths with similar attributes received from all configured neighbors.

In a Service Provider network, a Provider Edge (PE) device learns VPN paths from remote PEs and uses the Route Target

Routing control functions (RCF) is a new language, a different way of policy definition and application in a programmatic fashion (https://www.arista.com/en/support/toi/eos-4-27-2f/15102-routing-control-functions-language-and-configuration). EOS Application Programmable Interface (eAPI) is another means whereby commands are sent to the switch (i.e. aside from the switch’s command-line interface - CLI which has been the norm), which can be executed through various methods like web interface, shell or a program/script.

The eBgp "ip next hop unchanged" feature allows a router to send routes to its eBgp peers without changing their next

As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilization. By adding a local VTEP to each MLAG peer, the control plane is able to advertise singly connected hosts as being directly behind a specific local VTEP / MLAG peer.

This new feature explains the use of the BGP Domain PATH (D-PATH) attribute that can be used to identify the EVPN domain(s) through which the EVPN MAC-IP routes have passed. EOS DCI Gateway provides new mechanisms for users to specify the EVPN Domain Identifier for its local and remote domains.   DCI Gateways sharing the same redundancy group should share the same local domain identifier and same remote domain identifier.

Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint). In any multihoming EVPN instance (EVI), for each ethernet segment a designated forwarder is elected using EVPN type 4 Ethernet Segment (ES) routes sent through BGP. In single-active mode, the designated forwarder (DF) is responsible for sending and receiving all traffic. In all-active mode, the DF is only used to determine whether broadcast, unknown

EVPN MPLS VPWS (RFC 8214) provides the ability to forward customer traffic to / from a given attachment circuit (AC) without any MAC lookup / learning. The basic advantage of VPWS over an L2 EVPN is the reduced control plane signalling due to not exchanging MAC address information. In contrast to LDP pseudowires, EVPN MPLS VPWS uses BGP for signalling. Port based and VLAN based services are supported.

Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint).

Flexible cross-connect service is an extension of EVPN MPLS Virtual Private Wire Service (VPWS) (RFC 8214). It allows for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel while still providing single-active and all-active multi-homing.

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6

Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6

A forwarding equivalence class (FEC) entry is the data structure that holds all reachable vias where the packets should be sent to, for certain routes. Before this feature, a FEC could not contain both IPv4 next hop vias and IPv6 next hop vias. This feature starts supporting FECs that have both IPv4 next hop vias and IPv6 next hop vias. In an Equal Cost Multi-Path (ECMP) FEC, some of the vias may have IPv4 next hop and others may have IPv6 next hop. 

The General Router ID configuration provides the ability to configure a common Router ID for all routing protocols

This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect

This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect

Prior to release EOS 4.29.1, a statically configured BGP neighbor, listen range or interface peer could reference a single peer group for inheriting configuration parameters. EOS 4.29.1 adds the ability for that peer group to inherit configuration from up to 8 additional “ancestor” peer groups. The term “leaf peer group” is given to the peer group which is directly referenced by the BGP neighbor, listen range or interface peer.

This feature introduces the ability to match on 1) any BGP aggregate contributor or 2) a specific BGP aggregate’s

This feature enables the user to configure a list or range of BGP attributes to be ignored by the router on receipt of a BGP update message. The BGP attributes are discarded from the BGP update message, and unless the action of discarding an attribute causes the update message to trigger error handling, then the update message is parsed as normal.

EVPN VXLAN all-active multihoming (AA-MH) provides redundancy to reduce or eliminate the impact of outages and maintenance. The objective of Maintenance Mode on AA-MH is to gracefully drain away the traffic from the EVPN core flowing through a switch that is part of multihoming while the switch is put into maintenance, and to gracefully add it back into the network and attract traffic again once the switch is out of maintenance. During the maintenance cycle any customer edge Ethernet or Port-Channel interfaces, whether they are participating as ethernet segments or not, can also be put into maintenance mode. Doing so eliminates the northbound traffic from the customer edge from flowing through the switch under maintenance. The traffic will instead take a path through other available multi-homing peers.

Currently, the 'maximum routes' knob allows one to set an upper bound on the number of routes that can be received from a

The "set metric" clause in a route map sequence has been enhanced with the addition of the "igp nexthop cost" keyword.

MPLS over GUE (Generic UDP Encapsulation) is a tunneling mechanism for encapsulating MPLS IP traffic in a UDP header. This feature adds support for MPLS over GUE encapsulation for BGP VPN routes resolving over IPv4 next hops. 

The Multicast Source Discovery Protocol (MSDP) provides a mechanism to connect together multiple PIM Sparse Mode

EOS supported two routing protocol implementations: multi-agent and ribd. The ribd routing protocol model is removed starting from the EOS-4.32.0F release. Multi-agent will be the only routing protocol model. Both models largely work the same way though there are subtle differences.

Add support for dynamic prefix list based matching in multi agent model. Please refer the TOI for rib

The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our

This feature allows a compatible SSH client to authenticate to EOS via a FIDO2-anchored SSH key via the “该邮件地址已受到反垃圾邮件插件保护。要显示它需要在浏览器中启用 JavaScript。” or “该邮件地址已受到反垃圾邮件插件保护。要显示它需要在浏览器中启用 JavaScript。” key types. In OpenSSH this was introduced in version 8.2p1. This feature is not compatible with the Federal Information Processing Standards (FIPS)restrictions mode in EOS; if both are configured, this feature will take precedence.

Prior to EOS 4.23.2F, BGP missing policy action configuration is a global BGP configuration that, when set to deny,

This feature introduces per-nexthop MPLS label allocation for the IPv4-unicast default-route and the IPv6-unicast default-route. Previously, BGP-VPN VRFs only supported a per-VRF label scheme. With a per-VRF label scheme, each BGP-VPN supported AFI-SAFI (i.e. IPv4-unicast and IPv6-unicast) in the BGP-VPN VRF is allocated a single "per-VRF" label that will be shared by all the AFI-SAFI’s routes. When the routes are exported as BGP-VPN routes, all the routes will be exported with the same "per-VRF" VPN label. In the Label FIB (LFIB), each allocated "per-VRF" label is associated with an ip-lookup action inside their corresponding BGP-VPN VRF.

This document describes a new CLI command to help debug how and why policy permits and denies paths. The aim of this CLI command is for the user to debug a route map or RCF (Routing Control Functions) function by specifying as input a prefix for which BGP has reachability for, either via a BGP peer or a redistribute source.

This feature supports generation of non host routes for the IPv6 neighbor entries learnt on an SVI interface. These

This feature allows redistribution of bgp unicast routes into multicast address families. Specifically it allows redistribution of ipv4 unicast routes into the ipv4 multicast address family and ipv6 unicast routes into the ipv6 multicast address family.

This feature allows routes that were leaked from one VRF (the source VRF) into another VRF (the destination VRF) using

In the BGP Update message’s AS_PATH, routers have the capability to perform route aggregation and combine the ASes an update has traversed, merging the discrete entries into an  AS_SET. Routers can also do this within the local confederation with member AS numbers, using an AS_CONFED_SET. Route aggregation can be problematic as it blurs the semantics of what it means to originate a route. RFC 6472 recommends not using AS_SET or AS_CONFED_SET in BGP, and further justifies reasoning as to why, as well as provides a recommended way to handle updates with these messages.

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with

This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with

This is an extension to BGP MPLS VPNs that allows us to use iBGP as the PE CE protocol. This feature also provides a way to

This feature provides support for advertising VPN-IPv4 Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC8950. Extended Next Hop Encoding capability can be supported for IPv4 unicast, IPv4 Labeled Unicast, and IPv4 VPN address and sub-address families (1/1, 1/4, 1/128 respectively) per RFC. The Extended Next Hop support for IPv4 unicast is described in RFC 5549 .

RIB Route Control is a collection of mechanisms for controlling how IP routing table entries get used. Next hop

This feature adds support for ‘match interface’ clause under route map config for Bgp policy application in

This feature adds support for ‘match ip(v6) resolved next hop’ clause under route map config for BGP policy

This document describes a new CLI command to help debug how and why route maps permit and deny paths. The aim of this CLI

In a Service Provider (SP) network, a Provider Edge (PE) device learns virtual private network (VPN) paths from remote PEs and uses the Route Target (RT) extended communities carried by those paths to determine which customer Virtual Routing and Forwarding (VRF) the paths should be imported into (from where they can be subsequently advertised to Customer Edge (CE) devices).

Routing control functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion. This document serves as a reference guide for: Routing protocol attributes, Operators for comparing and modifying attributes, built-in functions provided in RCF

Routing Control Functions (RCF) is a language that can express route filtering and attribute modification logic in a powerful and programmatic fashion.

Routing Control Functions (RCF) is a language that can be used to express route filtering and attribute modification logic in a powerful and programmatic fashion.