• Tag : BGP


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 →


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 Platform Compatibility (No ND Proxy, No ND Suppression) DCS-7020R DCS-7260X/7260X3 DCS-7050/7050X/7050X2 DCS-7060X/7060X2 DCS-7160 DCS-7250 DCS-7500R/7500R2/7500E DCS-7300X/DCS-7320X Configuration Enable IPv6 Routing First, enable global IPv6 unicast routing.  Then enable IPv6 unicast routing for each VRF. hs482(config)#ipv6 unicast-routing hs482(config)#ipv6 unicast-routing vrf tenant-c Virtual Router MAC (config-t)#ip virtual-router mac-address <mac> IPV6 SVI If...
Continue reading →

BGP replace remote-as

Description The replace remote AS feature allows a provider edge (PE) router to change the autonomous system (AS) number used by a customer edge (CE) device, on an external BGP (EBGP) session. Enterprises, which are geographically distributed, are connected via providers. As a best practice, these enterprises use same BGP AS across multiple sites. This will cause the local AS number to be carried in AS_PATH via external BGP sessions, as illustrated in the diagram below. BGP, by default, does not accept routes with an AS path attribute that contains the local AS number to prevent routing loops. In the...
Continue reading →

Multicast forwarding using BESS (MFA)

Description The PIM routing protocol builds multicast routing state based on control packets and multicast data events. In our current implementation, we rely on the Linux kernel to notify the PIM agents regarding the multicast data events. Also, the Linux kernel forwards a multicast data packet before hardware gets programmed to do so. As an alternative to the Linux kernel, Multicast Forwarding based on BESS ( Berkeley Extensible Soft Switch ), MFA, can be used to generate multicast data events and forward multicast data packets. As the first release of MFA, it is officially supported for IPv6 PIM SSM. Although...
Continue reading →

BGP route-map prepend last-as

Description The “set as-path prepend” clause in route-map configuration mode has been enhanced with the addition of the “last-as” keyword, which will prepend the AS_PATH with the specified number of instances of the last AS number in the AS_PATH. The command also accepts an explicit list of AS numbers to prepend to the AS_PATH. This list may also include one or more “auto” keywords in place of AS numbers, which are replaced by the peer AS number for inbound routes, and the local AS number for outbound routes. By extending some AS paths, this feature enables customers to configure their...
Continue reading →

Nexthop resolution ribs vrf-unicast-rib

Description The regular MplsVpn functionality works as follows : For the VPN routes received from a neighbor, if and only if the nexthop of the VPN routes is resolvable via an MPLS tunnel in the default VRF, the route is imported (based on route-targets) and installed in the target VRF (import-vrf). This feature removes the above restriction and enables VPN routes to be imported and installed in a target VRF (import-vrf) if the nexthop of the VPN routes is resolvable in the imported VRF itself. With this feature no attempt is made  to resolve the VPN routes over an MPLS...
Continue reading →

BGP Nexthop Resolution RIBs

Description The EOS 4.22.0F release introduces BGP Nexthop Resolution RIB support for IPv4 and IPv6 unicast address families. The typical use case is to customize the next hop resolution of BGP routes by providing the order of resolution RIB domain (i.e., either tunnel domain or IP domain). This will help EOS direct specific services over the specified RIB domains (IP and Tunnel) and with a greater granularity of picking tunnel protocol sources (such as LDP, ISIS-SR) within the tunnel RIB as well as connected routes within the IP RIB. Refer to the “User-defined tunnel RIBs” TOI for details on how...
Continue reading →


Description This feature involves the use of packet’s Time to Live (TTL) (IPv4) or Hop Limit (IPv6) attributes to protect BGP peering sessions (both iBgp and eBgp) from an attacker on the network segment causing denial of service using forged IP packets by spoofing the BGP peer’s IP address. The solution is described by the RFC 3682 (Generalized TTL Security Mechanism). The user can configure a minimum TTL for incoming IP packets received from the BGP peer. BGP session will only get established if the TTL value in the received IP packet header is greater than or equal to the...
Continue reading →

Preventing BGP maximum-routes overflow

I configured a DCS-7050QX-32S for a simple BGP failover, accepting only a default route. Is there a way to protect against route overflow when the peer sends more than the specified maximum-routes? The prefix-list limits accepted routes to only one, but the maximum-routes limit is applied to received (not accepted ) routes, causing an Idle(MaxPath) state. Setting “maximum-routes 0” would seem a logical alternative, except that with it BGP doesn’t converge when the peer sends a large number of routes. ip prefix-list default_route seq 10 permit ! router bgp 1001 router-id timers bgp 10 30 neighbor remote-as...
Continue reading →

Basic BGP Troubleshooting

Objective The objective of this document is to outline the various common issues faced in BGP and the troubleshooting commands for the same. I. Neighborship BGP sends unicast messages, unlike other routing protocols. For this reason, please make sure the neighbor’s IP address is reachable. For issues with BGP neighborship, check the output of ‘show ip bgp summary vrf all’ to check the neighborship state. R1#show ip bgp summary vrf all BGP summary information for VRF default Router identifier, local AS number 100 Neighbor Status Codes: m - Under maintenance Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State...
Continue reading →

BGP Crashing with VXLAN EVPN

I have a network setup with 6 Arista 7050QX running VXLAN-EVPN. All nodes are doing eBGP. I can establish eBGP sessions and configure EVPN as well but the moment I start sending traffic via VXLAN then BGP stops working saying “BGP agent not running”. I have tried 4.21.5F, 4.21.3F and currently using 4.20.5F but same result. Config looks like this at one end. Router bgp 65001 vlan 101 rd route-target both 101:10000002 redistribute learned interface Vxlan1 description VXLAN Interface vxlan source-interface Loopback0 vxlan udp-port 4789 vxlan vlan 100 vni 10000001 vxlan vlan 101 vni 10000002 Arista DCS-7050QX-32-R Hardware version:...
Continue reading →

Bgp Monitoring Protocol for Multi-agent Model

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

Displaying Neighbors’ Names with OSPF and BGP

This article describes how to configure Arista devices to display user-defined names for OSPF and BGP neighbors. OSPF First define name to IP address mappings, one per neighbor, where IP address is neighbor’s OSPF router ID: SW1(config)# ip host SW2 Next enable OSPF name resolution: SW1(config)# ip ospf name-lookup Finally, validate the output of ‘show ip ospf neighbor’ command. The command should display the user-defined name instead of router-ID: SW1(config)# show ip ospf neighbor Neighbor ID   VRF         Pri       State             Dead Time     Address        Interface SW2   ...
Continue reading →

iBGP over VRF – Open Message Error/bad BGP ID

Hi all, I am trying to establish iBGP between 2 Arista devices in a VRF, and got this error: Peering failure hint: Open Message Error/bad BGP ID Do you what what does it mean? The current status is: DEFRA2-NDSW99#sh ip bgp nei vrf PSP BGP neighbor is, remote AS 65508, internal link BGP version 4, remote router ID, VRF PSP Failed connection attempts is 321 Idle-restart timer is inactive BGP state is Active Peering failure hint: Open Message Error/bad BGP ID Last sent notification:Open Message Error/bad BGP ID, Last time 00:01:48, First time 35d13h, Repeats 41026 Last rcvd...
Continue reading →

Enterprise Internet Routing

Overview The objective of this document is to cover the most common Enterprise Internet Routing use case. The information provided here is based on two Arista switches peering with two ISP’s (Internet Service Providers) for redundancy. There are many other valid deployment models that are not covered in this document. Terminology BGP – Border Gateway Protocol ISP – Internet Service Provider BGP Peering – a session between two BGP routers that allows exchange of routes Full Internet Routing Table – all public routes on the Internet AS – Autonomous System – defines domain boundaries IGP – Interior Gateway Protocol EGP...
Continue reading →

Identifying BGP aggregate contributors in outbound policy

Description This feature adds a new match clause for outbound route maps. The new match clause allows matching on 1) any BGP aggregate contributor or 2) a specific BGP aggregate’s contributor. Matching on BGP aggregate contributors allows for the selective application of attributes (such as communities) to said contributors; these attributes can then be used for identification and filtering purposes by neighbors. Currently this feature is supported in the ribd routing protocol model only. Configuration Match contributors to any aggregate To match contributors to any BGP aggregate and set attributes (say communities) on said contributor, add an outbound policy with the...
Continue reading →


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

Join other followers: