• Tag : BGP

 
 

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 →

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 →

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 model. Platform...
Continue reading →

BGP Nexthop Resolution RIBs: MPLS VPN support

Description Adds the BGP Nexthop Resolution RIBs feature for MPLS VPN 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 router bgp <id> address-family vpn-ipv4 next-hop resolution ribs PRIMARY-RIB [FALLBACK-RIB] address-family vpn-ipv6 next-hop resolution ribs PRIMARY-RIB [FALLBACK-RIB] PRIMARY-RIB and FALLBACK-RIB refers to either tunnel domain or IP RIB domain. Tunnel domain can be configured as: tunnel-rib <tunnel-rib-name> where <tunnel-rib-name> refers to either system-tunnel-rib or user defined tunnel rib. Please refer to the “User-defined tunnel RIBs” TOI on...
Continue reading →

Route Map Debugging CLI 

Description This document describes a new CLI command to help debug how and why route maps permit and deny paths. The aim of this CLI command is for the user to debug a route map by specifying as input a prefix for which the peer receives a route via BGP. The path information for this prefix is then used in the evaluation of a route map. The route map can be specified by the user, but if none is specified the route map applied to the peer is used. The output will contain the sequences that were evaluated in the...
Continue reading →

Arista 7280SR BGP sflow on vlan interfaces

Hello, I am using BGP on Arista 7280SR, and the ip are on vlan interfaces (not sub-interfaces). I’d like to enable sflow and its BGP extension to see the traffic per-AS with AS-stats / elastiflow, although I cannot enter the following command, which is not available in interface vlan configuration mode. sflow enable Is it a limitation of the Jericho chip, EOS, or did I misunderstand the way I’m supposed to get BGP extension informations via sflow in my setup ? Thank you.

BGP VPN and Inter-VRF Local Route Leaking Support for default VRF

Description This feature extends the BGP Layer 3 VPN Import/Export and VRF Route Leaking functionality to “default” VRF. Currently, these functionalities are only supported for non-default VRF. Please refer to this TOI for more details on the support for non-default VRF. EOS supports the following two types of VPN configurations and this feature is applicable for both. RFC 4364 BGP/MPLS L3 VPN (TOI Link) BGP L3 EVPN (TOI Link) This feature is available when configuring BGP in the multi-agent routing protocol model. Platform Compatibility DCS-7250 DCS-7050TX/SX/QX DCS-7060X DCS-7280R DCS-7500R Configuration Configuring BGP VPN in default VRF is similar to how it is...
Continue reading →

Prefix-length support for IPv6 attached-host routes

Description This feature supports generation of non-host routes for the IPv6 neighbor entries learnt on an SVI interface. These non-host routes can further be redistributed into BGP protocol to take part in the route selection decision process and to get advertised to the peers. These routes are not installed into the hardware and are only being generated for advertisement purpose. This feature works for both static and dynamic neighbors. Neighbor generated routes are also referred to as ‘attached-host’ routes in the context of this document even though the routes are non necessarily host routes ( /128 ). A neighbor will...
Continue reading →

4 Byte ASDOT Notation Support

Description This feature allows a user to configure Autonomous System Number (ASN) in Asdot notation and get the ASN in output of Bgp show commands either in Asplain or Asdot notation depending on a knob. ASN is a 32 bit integer value ranging from 0 to 4294967295. According to RFC-5396, there can be following formats for representing AS numbers: Asplain Represents AS number as a decimal integer. Range: 0 – 4294967295 Example: ASN: 42949672950 => Asplain: 4294967290 Asdot+ Represents all AS numbers using a notation of two integer values joined by a period character: <high order 16-bit value in decimal>.<low...
Continue reading →

Follow

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

Join other followers: