• Tag : BGP


Support for BGP multicast aggregation

BGP address aggregation was previously only supported for IPv4 and IPv6 unicast address families. Equivalent BGP aggregation support has been added for IPV4 and IPV6 multicast address families. Existing aggregation support for IPv4/IPv6 unicast address-families has been preserved. IPv4/IPv6 Multicast aggregation support can be configured and managed through additional CLI commands within the respective multicast address-family configurations. The commands are similar to the existing unicast aggregation. The new multicast aggregation commands support the same configuration options as the equivalent unicast commands. For BGP peers where support for IPv4/IPv6 multicast address-families has been enabled, address aggregation may be performed on advertised...
Continue reading →

BGP multicluster route-reflector

Description The route reflector, as described in RFC 4456, is a router allowed to advertise (reflect) iBGP learned routes to other iBGP peers. The peers to a route-reflector can be qualified as clients (whose learned routes can be reflected to all peers) and non-clients (whose learned routes are only reflected to clients). The route reflector and its clients constitute a cluster. To prevent network loops, each cluster is assigned an identifier, namely, the cluster-ID. The cluster-ID is prepended to the path attribute cluster-list whenever a route is reflected. When a path is received and the cluster-list is present, the route...
Continue reading →

EVPN MPLS Virtual Private Wire Service (VPWS)

Description 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. VLAN Based Service Port Based Service Platform compatibility DCS-7280R DCS-7280R2 DCS-7280R3 DCS-7500R DCS-7500R2 DCS-7500R3 DCS-7800R3 Configuration VPWS configuration is made up of two main components on each participating router.  The first...
Continue reading →

BGP Remove-Private-As Ingress

Description Remove Private AS Ingress is a feature used for removing and replacing private AS numbers from inbound AS paths, so that private ASes from the outside will not be circulating inside the network. It can protect the network from misconfigurations or misbehaving networks. For example, when the outside networks fail to configure “remove-private-as” (egress), it can serve as a double safety check to make sure that no outside private ASes are intruding the network. Platform Compatibility Remove-private-as in ingress is a platform independent feature. And it is only supported in multi-agent mode. Configuration The configuration command: router bgp <AS>...
Continue reading →

EVPN Single-active Multihoming & Preference-based DF Election

Description Single-active multihoming Multihoming in EVPN allows a single customer edge (CE) to connect to multiple provider edges (PE or tunnel endpoint). The default mode of operation is all-active, in which the CE connects using link aggregation and can send traffic to either PE by hashing (or any other means) and expect the traffic to be successfully delivered. Introduced in EOS 4.26.0F for VXLAN and 4.27.0F for MPLS, single-active is an alternative mode of operation in which only one PE per VLAN per ethernet segment accepts traffic. Any other PE in the ethernet segment will drop all inbound packets, effectively...
Continue reading →

Sharing BGP update groups between similar RCF functions

Description In EOS, BGP creates different update groups based on the outbound configuration. Different route maps or Routing control functions (RCF) result in different update groups. A user can configure multiple RCF functions with functionally identical contents intended for use as outbound configuration for various peers. For example a user may wish to have a unique RCF function per peer, even though all of these RCF functions are identical. This would allow the user to modify the policy for a specific peer without impacting other peers. This enhancement allows a user to choose the above pattern without incurring the memory...
Continue reading →

Extending EVPN and VXLAN to the Host

Overview VxLAN provides a highly scalable, standards based approach for constructing L2 overlays on top of routed networks. It is defined in RFC7348, and encapsulates the original host Ethernet frame in a UDP + IP + Ethernet frame. BGP EVPN (RFC 7432 and RFC 8365 for its application to VXLAN) is a standards based control protocol to efficiently discover other endpoints (VTEPs) and distribute reachability information (MAC addresses). This post assumes the reader is already familiar with configuration and operations of EVPN and VXLAN for Arista. Goals The use case here is the extension of a L2 overlay south of the TOR/Leaf...
Continue reading →

bgp bestpath tie-break cluster-list-length doesn’t seem to work

Hi,   we realized that we have non-intended ECMP on a DCS-7060CX-32S because of BGP path only different in their cluster list length. We have added the “bgp bestpath tie-break cluster-list-length”, did a soft BGP reset, but the situation is the same. Should we do anything else to active the “bgp bestpath tie-break cluster-list-length” setting?   * >Ec 0 160 0 42864 ? * ec 0 160 0 42864 ? Or-ID: C-LST: * >Ec 0 160 0 41075 i * ec 0 160 0 41075 i Or-ID: C-LST:
Continue reading →

BGP Same Address Peering

Description This feature adds support for BGP peering with multiple peers using the same IP address. The router id of those peers is used in conjunction with IP address to disambiguate them. Hence it is expected that router id of the bgp instances in play should be unique. Platform compatibility This feature is available on all platforms in multi-agent mode in 4.25.2F. Configuration The option “peer-id include router-id” is added in the listen range configuration to enable same address peering. router bgp 1 bgp listen range peer-id include router-id peer-group pg1 remote-as 100 router bgp 1 bgp listen range...
Continue reading →

BGP Long Lived Graceful Restart

Description The BGP graceful restart mechanism has a limitation that the graceful restart time cannot exceed 4095 seconds per the IETF standard (RFC 4724). There are scenarios where this limitation poses a challenge in various  deployments, which need to allow the graceful restart process to complete over a longer period of time. This feature provides support for restarting BGP speakers that can take a long time to recover and complete the graceful restart procedures. The mechanism adopted is documented in the draft “Support for Long-lived BGP Graceful Restart” (draft-ietf-idr-long-lived-gr-00). Please note that only the “receiving speaker” or “helper” procedures are...
Continue reading →

BGP nexthop resolution RIBs

Description This feature adds support for user-configured BGP Nexthop Resolution RIB profiles for various BGP-based services e.g. IP unicast, L3 VPN, EVPN, etc. The feature allows an administrator to customize the next hop resolution semantics of BGP routes with an ordered list, or profile, of resolution RIB domains (i.e., either tunnel or IP domain). This allows EOS to direct specific services over the specified RIB domains, overriding the default behavior. Further, this feature, through the use of user-defined tunnel RIBs, empowers an administrator to further select a subset of tunnelling protocols for specific services. Refer to User-defined tunnel RIBs for...
Continue reading →

Support for BGP Peer Flap Damping

Description This document describes the Bgp Peer Flap Damping feature which allows session damping for peers with bfd enabled. BGP takes a long time to detect failures such as failing links due to longer keepalive/hello time-out values. It takes advantage of detecting link failures faster by receiving notification through BFD. This is very useful until we are faced with a link flapping scenario, as it will cause BGP sessions to establish and break down over and over, causing unnecessary traffic loss and churn.  This feature allows delaying establishment of BGP sessions during BFD flapping, which ends up reducing traffic loss...
Continue reading →

RFC 6368 – iBGP as PE-CE Protocol for BGP/MPLS L3 VPNs

Description 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 isolate the customer’s network BGP attributes from the SP backbone’s attributes, by saving them into a special attribute called ATTR_SET, code 128. This separation introduces a “route server” model that allows the customer’s BGP path attributes to be stored in the SP backbone along with the VPN-IPv4/v6 paths. This feature is enabled by configuring the AS number of the PE’s VRF to match the CE’s AS number. This will cause the exported paths by...
Continue reading →

Route-Target Membership

Description 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).   In large SP networks, each PE device may learn a significant number of VPN paths even though they might only handle a relatively small number of customer VRFs. In BGP VPN deployments (EVPN, MPLS VPN IPv4 and MPLS VPN...
Continue reading →

Scrubbing large BGP communities

Hi there, I was wondering how to best scrub large BGP communities that match a certain regex. I’ve tried the following: ip large-community-list regexp INFORMATIONAL permit 65000:101:.+ ! route-map SCRUB-COMMUNITIES permit 10 set large-community large-community-list INFORMATIONAL delete But it appears that when running `config-sanity`, it hints the route-map is incorrect: router(config)#show route-map config-sanity route-map SCRUB-COMMUNITIES permit 10

Arista BGP Redistribute Static Default Route

Hi, I am trying to confirm the mechanism for redistributing a static default route under bgp. In Cisco, in order to redistribute a static default route, “default-information originate” command is required. From what I have seen in the lab, it seems to be that Arsita does not require this command, to redistribute a static default route under bgp. Also, if possible I want to find out the ways in which default routes can be originated in bgp on Arista. I wanted to confirm this behavior in Arista please. Thanks and regards, Abid Ghufran

Routing Control Functions

Description Routing control functions (RCF) is a new language that can be used to express BGP route filtering and attribute modification logic in a powerful and programmatic fashion. It supports a new set of workflows to define and apply these functions in EOS. The broader feature set includes: The base RCF language framework; Support for RCF function application to BGP neighbors; Support for matching and modifying BGP protocol attributes; Workflows to define and apply routing control functions; CLI commands to provide visibility into operational status. The following points of application are supported: Point of application Supported since Inbound BGP neighbor...
Continue reading →

Support for deleting link bandwidth extended community without specifying value (“set extcommunity lbw delete”) or with specified AS number (“set extcommunity lbw asn delete”)

Description This feature extends link bandwidth extended community deletion mechanism, which previously always required specifying the exact community value (both BGP AS number and link bandwidth value), to now allow deletion of link bandwidth extended community attribute from path attribute without having to specify exact community value or with just specifying the BGP AS number.  The TOI which describes link bandwidth extended community deletion mechanism as it existed previously can be found here.  Note that this extended support for this mechanism is only supported in the multi-agent routing protocol model. Platform compatibility This feature is platform independent. Configuration The following...
Continue reading →

BGP Override Graceful Restart Time

Description The BGP graceful restart mechanism has a limitation that the graceful restart time cannot exceed 4095 seconds as per the IETF standard (RFC 4724). On a restarting speaker, Arista’s CLI configuration currently allows only up to 3600 seconds. There are scenarios where this limitation poses a challenge in certain customer deployments, and a need is felt for increasing the restart time to a very high value. This feature provides a way of configuring the restart time to be considered by a graceful restart helper, overriding the value sent by the peer in the graceful restart capability. Using this feature,...
Continue reading →

BGP Link State (BGP-LS) Producer for IS-IS LSDB

Description The BGP-LS extension (RFC7752/to be obsoleted by draft-ietf-idr-rfc7752bis) allows IGP (OSPF/IS-IS) link state database information to be injected into BGP. This is typically used in deployments where some external component, (like a controller or Path Computation Engine) can do centralized path computations by learning the entire IGP topology through BGP-LS. The controller can then communicate the computed paths based on the BGP-LS updates to the head end device in the network. The mechanism used by the controller to communicate the computed TE paths is outside the scope of this document. Using BGP-LS instead of an IGP peering with the...
Continue reading →


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

Join other followers: