• Tag : BGP

 
 

Tunnel Preferences and Related Enhancements

Description Configuring the IGP cost for tunnels is a feature that allows influencing the BGP best path selection for routes resolving over MPLS tunnels. It works by overriding the existing preference (which is inherited from the underlying IGP) with the user defined preference. Platform compatibility This feature is supported on all Arista devices. Configuration Tunnel preferences can be statically configured by going under the tunnel-ribs mode, selecting the tunnel rib (system or custom) and setting it for a specific protocol. bgprtr1(config)#tunnel-ribs bgprtr1(config-tunnel-ribs)#tunnel-rib custom2 bgprtr1(config-tunnel-rib-custom2)#source-protocol ldp igp-cost preference 20 Show Commands If IGP preferences for tunnels are configured, ‘show running config’...
Continue reading →

Support for configuring color extended communities

Description EOS 4.23.1F introduces the ability to configure the color extended community in route-map set clauses and in an extcommunity-list for inbound and outbound policy application. As outlined in the IETF Segment Routing Policy Architecture draft, the color extended community is used for per-destination steering into Segment-Routing Traffic-Engineered (SR-TE) policies. If the next-hop and color of a BGP route match a particular policy (composed of an endpoint and color), any traffic bound to the destination can be steered according to the policy instead of forwarded via an IGP path or tunnel. Details on per-destination IP steering in EOS can be...
Continue reading →

BGP logical OR of multiple community lists in the same match command

Description In the multi-agent routing protocol model, the Bgp agent now supports matching community lists with a logical OR via the route map “match community or-results <community-list-1> <community-list-2>” command (same applies for extended and large communities with “match extcommunity” and “match large-community”). Without this new “or-results”, the default is to compute the logical AND of all provided community lists. Before this new feature one would need to merge existing community lists into one to do a logical OR: Issue: ip community-list COMMLIST1 permit 1:1 ip community-list COMMLIST2 permit 2:2 ! No way to match "COMMLIST1" or "COMMLIST2" in a singe...
Continue reading →

BGP Monitoring Protocol for Multi-agent Model

Description BGP Monitoring Protocol (BMP) 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 generated 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 functionality has been available with the single agent routing protocol model since EOS-4.21.1F, as described here. EOS 4.21.4F introduces support for BMP in the multi-agent routing protocol model. Platform Compatibility This feature is...
Continue reading →

EVPN VxLAN IPV6 Overlay

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from one IPV6 host to another IPV6 host on a stretched VXLAN VLAN. This TOI explains the EOS configuration and show commands. Platform Compatibility Platform supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F (Starting in 4.22.1F) DCS-7050SX3-48YC8 (Starting in 4.22.1F) DCS-7050/7050X/7050X2 (Starting in 4.22.1F) DCS-7260X/7260X3 (Starting in 4.22.1F) DCS-7060X/7060X2 (Starting in 4.21.1F) DCS-7250 (Starting in 4.22.1F) DCS-7300/DCS-7320 (Starting in 4.22.1F) Platform not supporting ND Proxy, No ND Suppression  DCS-7020R DCS-7160 DCS-7500R/7500R2/7500E Configuration Enable IPv6 Routing Enable global IPv6 unicast routing and IPv6...
Continue reading →

BGP nexthop resolution RIBs: EVPN and IPV4/6 labeled-unicast support

Description Adds the BGP Nexthop Resolution RIBs feature for EVPN and labeled-unicast address families. See BGP Nexthop Resolution RIBs TOI for further details. This feature is only available when running the multi-agent routing protocol model. Platform compatibility It is supported on all platforms. Configuration Example configuration for EVPN MPLS, EVPN Vxlan and BGP Labeled-unicast: router bgp <id> address-family evpn next-hop mpls resolution ribs PRIMARY-RIB [FALLBACK-RIB] next-hop vxlan resolution ribs IP-RIB ... address-family ipv4 labeled-unicast next-hop mpls resolution ribs PRIMARY-RIB [FALLBACK-RIB] address-family ipv6 labeled-unicast next-hop mpls resolution ribs PRIMARY-RIB [FALLBACK-RIB] PRIMARY-RIB and FALLBACK-RIB refers to either tunnel domain or IP RIB...
Continue reading →

Show bgp neighbors history

Description This command stores and displays a list of failed BGP connection attempts for each peer. This may be particularly useful while troubleshooting flappy connections. If dynamic peering is enabled, the failure history will be remembered even after the peers are no longer present. Platform compatibility This feature is supported on all platforms. Configuration Relevant error messages are recorded by default, without any configuration. To clear all messages for a peer or group of peers, though, it is necessary to use the command “clear bgp history”. The syntax for this command is described as: switch#clear bgp [ PEER | PREFIX...
Continue reading →

Securing Inter Domain Routing with RPKI

Problem definition The debate over challenges and solutions for Secure Interdomain Traffic Exchange is hot as ever these days. The obstacle lies in the fundamental principle of BGP – mutual trust between network operators. Unfortunately, though this principle has led to a number of incidents in the industry, to the public eye only the tip of the iceberg is visible. The results of these incidents are traffic redirection, eavesdropping, DoS attacks and black-holing, to name a few. While incidents number in thousands, the underlying issues are only a few, and vary between accidental route leak through intentional prefix hijack and...
Continue reading →

BGP IPv6 link-local peering support

Introduction This feature adds support for BGP peering over IPv6 link-local addresses. This feature is available with the with the ribd routing protocol model since EOS-4.20.5 and multi-agent routing protocol model since EOS-4.22.1. As defined in RFC 4007, IPv6 addresses have multiple possible scopes. The prefix range fe80::/10 is reserved for uniquely identifying interfaces on a single link, or of link-local scope. Previous EOS versions supported BGP sessions with IPv4 or IPv6 peer addresses, as in: router bgp 64496 router-id 0.0.1.1 neighbor 192.0.2.1 remote-as 64497 neighbor 192.0.2.1 maximum-routes 12000 ! However, attempting to peer using the designated IPv6 link-local address...
Continue reading →

EVPN VxLAN IPV6 Overlay TOI

Description Starting with EOS release 4.22.0F, the EVPN VXLAN L3 Gateway using EVPN IRB supports routing traffic from IPV6 host to another IPV6 host on a stretched Vxlan VLAN. This TOI explains the EOS configuration and show commands. Platform Compatibility Platform supporting ND Proxy and ND Suppression DCS-7280R/7280R2 DCS-7050CX3-32S-F DCS-7050SX3-48YC12-F ( Starting in 4.22.1F ) DCS-7050SX3-48YC8 ( Starting in 4.22.1F ) DCS-7050/7050X/7050X2 ( Starting in 4.22.1F ) DCS-7260X/7260X3 ( Starting in 4.22.1F ) DCS-7060X/7060X2 ( Starting in 4.21.1F ) DCS-7250 ( Starting in 4.22.1F ) DCS-7300/DCS-7320 ( Starting in 4.22.1F ) Platform not supporting ND Proxy, No ND Suppression  DCS-7020R...
Continue reading →

MSDP support for multi-agent model

Description The Multicast Source Discovery Protocol (MSDP) provides a mechanism to connect together multiple PIM Sparse-Mode (PIM-SM) domains. Through peering relationships with MSDP-speaking routers in other PIM-SM domains, an MSDP speaker can learn of multicast sources in these domains, and interested receivers in its own can then be delivered multicast data from these over an inter-domain distribution tree. Existing support is in place for MSDP with the ribd routing protocol model. EOS-4.22.1F introduces support for MSDP with the multi-agent routing protocol model. Platform compatibility This feature is platform-independent. SA Messages and RPF-Peer Selection In both the ribd and multi-agent models,...
Continue reading →

Support for UCMP “adjust auto” (multi-agent)

Description Unequal-cost multi-path (UCMP) for BGP is a mechanism for forwarding ECMP route traffic using weights, with which the next hops of those routes are programmed in the FIB. This is done using BGP by disseminating BGP link-bandwidth extended community attribute information with BGP routes, such that the receiver device of all routes programs the next hops in the FIB using the received link-bandwidth values. This feature appends the percentage of interface speed with a route’s received link bandwidth extended community value. The idea is to rebalance the weight ratio of the traffic sent over egress ports, such that we...
Continue reading →

BGP shutdown and reset communication (multi-agent)

Description This feature implements support for RFC8203/BIS so that users can attach the reason of BGP instance or peer session administrative shutdown or hard reset to the BGP Cease Notification sent to the peers. Platform compatibility This feature is platform independent and only available when multi-agent mode is enabled. Configuration Below is a list of all possible configurations under this feature: (config-router-bgp)# shutdown [reason REASON] (config-router-bgp)# neighbor ( addr | peer-group) shutdown [reason REASON] (config-router-bgp)# clear [ip | ipv6] bgp [(neighbor (addr | peer-group)) | * ] [vrf (all | default | VRFNAME)] [reason REASON] Note that attaching ‘reason REASON’...
Continue reading →

Segment Routing Traffic Engineering Policy (SR-TE) multi-agent routing model TOI

Description Segment Routing Traffic Engineering Policy (SR-TE) aka SR Policy makes use of Segment Routing (SR) to allow a headend to steer traffic along any path without maintaining per flow state in every node. A headend steers traffic into an “SR Policy”.    EOS 4.21.0F added support for SR Policy for the MPLS dataplane (SR-MPLS) for Type-1 SR Policy segments in single agent routing model. EOS 4.22.1F adds support for SR-TE in multi-agent routing model.    For a detailed description of the functional behavior please refer to the “Description” section of EOS 4.21.0F TOI for SR-TE in single agent routing...
Continue reading →

EVPN – MLAG single homed hosts

Description As described in the Multi-VTEP MLAG TOI, singly connected hosts can lead to suboptimal peer-link utilisation. 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. The multi-VTEP MLAG feature has been extended to add EVPN control plane support. VXLAN bridging (EVPN Type-2 and Type-3 routes) and routing (EVPN Type-5 routes and IRB) are supported by this feature. When multi-VTEP MLAG mode is enabled, outgoing EVPN route advertisements will contain a nexthop and router MAC extended community as summarized...
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. If the best BGP path (as chosen by the algorithm) is also chosen as the winning path from among the other non-BGP paths (if any), it will be installed in the RIB and used to forward traffic to that network. The best BGP path will also be the path that is subsequently advertised to any BGP neighbors. BGP best-path steps When comparing any two paths...
Continue reading →

EVPN peering not being established

I’m building an EVPN test network using GNS3 (v2.2.0) and vEOS-lab images (4.22.2.1F) basing the configuration on the EVPN Deployment guide. I’ve built a network with 2 pairs of leaf switches & a pair of spine switches (see image). The Underlay BGP network is established fine, and I can reach the endpoints correctly. However when I try and establish the eVPN overlay peerings between the leaf switches and the spines some links never proceed beyond ‘OpenConfirm’ state. spine1(config-router-bgp)#show bgp evpn summary BGP summary information for VRF default Router identifier 192.168.31.129, local AS number 65000.0 Neighbor Status Codes: m - Under...
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 →

General Router ID

Description The General Router-ID configuration provides the ability to configure a common Router-ID for all routing protocols configured on the device. This implies that you do not need to configure a Router-ID for each routing protocol individually. Platform compatibility All platforms. Configuration A general router ID can be configured under the “router general” configuration mode for each address family: rtr(config)#router general rtr(config-router-general)#router-id ipv4 <A.B.C.D> rtr(config-router-general)#router-id ipv6 <A:B:C:D:E:F:G:H> For each address family, a per-VRF general router ID can be configured under the VRF submode under the “router general” configuration mode: rtr(config-router-general)#vrf RED rtr(config-router-general-vrf-RED)#router-id ipv4 <A.B.C.D> rtr(config-router-general-vrf-RED)#router-id ipv6 <A:B:C:D:E:F:G:H> Note that to...
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 →

Follow

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

Join other followers: