• Tag : BGP

 
 

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 →

Redistribution of leaked routes into BGP

This feature allows routes that were leaked from one VRF (the source VRF) into another VRF (the destination VRF) – using the VrfLeak Agent to be redistributed into BGP for advertising to VRF-lite / Option A BGP peers.  Description As of 4.23.2F we support leaked routes learned (in the source VRF) via the following protocols: Connected Static ISIS OSPF/ OSPFv3 BGP Into the following AFI/SAFI’s within BGP: IPv4 Unicast IPv6 Unicast Platform compatibility This feature is supported on all platforms. Configuration The feature is available when the protocol agent model is multi-agent. The following command puts the system in multi-agent...
Continue reading →

BGP In-place Adjacency Replace (IAR)

Introduction A typical BGP router has a large number of routes compared to the number of nexthops. Under certain circumstances, mostly in highly symmetric CLOS networks, when all routes in RIB move from “Adjacency A” → “Adjacency B” as a result of a single (or a series of near simultaneous) events – we update “Adjacency A” “in-place” to refer to “Adjacency B” contents – thereby avoiding the need to change every route to refer to a new Adjacency. This operation of identifying and updating adjacency in-place is called – Inplace Adjacency Replace (IAR). The goal of IAR operation is to...
Continue reading →

Route Map – Match Interface Support in Multi-Agent

Description This feature adds support for ‘match interface’ clause under route-map config for Bgp policy application in multi-agent model. This feature may be used when a policy to filter routes on the basis of the resolved interface of a route is desired. A route-map can be used at various application points to filter routes based on the policy but ‘match interface’ is supported  only for specific application points. For such applications when a route-map with ‘match interface’ clause is applied, the interface of the resolved nexthop of each route is matched against the interface specified in route-map and the route...
Continue reading →

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 and RFC 4659 for IPv6 and the use...
Continue reading →

RFC 5549: IPv4 unicast NLRI with IPv6 next-hop support

Description This feature provides support for advertising IPv4 unicast Network Layer Reachability Information (NLRI) with IPv6 next-hops over IPv6 peering sessions described as the Extended Next Hop Encoding capability in RFC5549. 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). The feature enables: Negotiating Extended Next Hop Encoding capability for IPv4 unicast NLRI advertisements over IPv6 BGP sessions. In multi-agent mode IPv4 iBGP sessions are also supported. Encoding of the next-hop in the UPDATE message that allows determination of the next-hop’s address family. This...
Continue reading →

Migrating from legacy DC design to EVPN VXLAN Fabric

Introduction This document is intended to provide a reference of steps and sequence followed for:  (1) migrating a legacy 3-tier L2 network to EVPN based VXLAN environment using Leaf & Spine design (2) migrating an L2 Leaf & Spine network with VXLAN using CVX as the control plane to EVPN based control plane (3) migrating an L2 Leaf & Spine network with VXLAN using static VXLAN as the control plane to EVPN based control plane. Scope The key objective of this report is to migrate a Layer 2 datacenter to EVPN based VXLAN using Leaf & Spine (L3LS) solution for...
Continue reading →

Per Address Family BGP Missing Policy Action for Multi-agent Model

Description Prior to EOS-4.23.2F, BGP missing policy action configuration is a global BGP configuration that, when set to deny, will deny/reject import (and/or export) of all routes when route-map is missing or misconfigured and it only applies to IPv4 Unicast and IPv6 Unicast address family. Now for multi-agent routing protocol model (single-agent model remains unchanged), the missing policy action can be applied to all address families by specifying “address-family all” in the existing missing policy configuration. With “address-family all” enabled, missing-policy config will apply to all AFs. Note that “address-family all” applies a “loose” behavior that misconfigured route map in...
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 BGP has reachability for, either via a BGP peer or a redistribe source. 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. Any route map configured can...
Continue reading →

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 →

Follow

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

Join other followers: