• Tag : BGP

 
 

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 2.58.168.0/22 217.113.61.226 0 160 0 42864 ? * ec 2.58.168.0/22 217.113.61.56 0 160 0 42864 ? Or-ID: 217.113.61.224 C-LST: 217.113.61.188 * >Ec 5.56.32.0/24 217.113.61.226 0 160 0 41075 i * ec 5.56.32.0/24 217.113.61.56 0 160 0 41075 i Or-ID: 217.113.61.224 C-LST: 217.113.61.188...
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 1.0.0.0/24 peer-id include router-id peer-group pg1 remote-as 100 router bgp 1 bgp listen range...
Continue reading →

The BGP best-path selection algorithm

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. The best BGP path (as chosen by the algorithm) is then used as follows: If it is also chosen as the RIB winner (i.e. the winning path from among any other non-BGP paths), it will be installed in the RIB and used to forward traffic to that network. With the multi-agent routing protocol model since EOS-4.23.2, RIB installation can be skipped by using the “bgp...
Continue reading →

Identifying BGP aggregate contributors in outbound policy

Description This feature introduces the ability to match on 1) any BGP aggregate contributor or 2) a specific BGP aggregate’s contributor, in the outbound route maps. Matching on BGP aggregate contributors allows for the selective application of route modifications (such as communities) to its contributors. These modified attributes can then be used for identification and filtering purposes by BGP peers. The use cases include : Advertise contributors to all aggregates with added attributes. This allows the upstream router to identify and filter contributor routes. Advertise aggregates and their contributor routes to the neighbor with added attributes, such as a community...
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 →

BGP Prefix Origin Validation with Resource Public Key Infrastructure (RPKI)

Description RPKI provides a mechanism to validate the originating AS of an advertised prefix. EOS support includes: Connecting to RPKI cache server(s) using the RTR protocol and syncing the Route Origin Authorizations (ROA) that have been synced from the global repositories. Validating prefixes received in BGP Update messages either using the ROAs that have been synced, or the Origin Validation State Extended Community attached to the received routes. Using the result of the validation to apply inbound policy in a route map. Platform Compatibility This feature is available on all platforms. Configuration Configuration consists of 3 steps: Configuration of an...
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...
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

RFC 4364 BGP/MPLS L3 VPN

Description This feature allows a Service Provider (SP) or an Enterprise to provide the service of interconnecting geographically dispersed customer sites. Such a service can be provided to multiple customers over the common network backbone infrastructure of the Service Provider, while: Maintaining privacy of each customer Allowing for overlapping IP addresses amongst customers Having constrained route distribution – i.e. only those routers in the Service Provider’s network that need the customer routes, have them. And the above is achieved through the extensions to BGP as defined in RFC 4364 for IPv4, RFC 4659 for IPv6 and the use of VPN...
Continue reading →

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 →

The BGP best-path selection algorithm

Description BGP routing information often contains more than one path to the same destination network. The BGP best-path selection algorithm determines which of these paths should be considered as the best path to that network. The best BGP path (as chosen by the algorithm) is then used as follows: If it is also chosen as the RIB winner (i.e. the winning path from among any other non-BGP paths), it will be installed in the RIB and used to forward traffic to that network. With the multi-agent routing protocol model since EOS-4.23.2, RIB installation can be skipped by using the “bgp...
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 →

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

Follow

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

Join other followers: