Arista EOS BGP Configuration: Peers, Peer Groups and Verification

Arista EOS speaks the same BGP dialect as Cisco IOS with a handful of differences that surprise experienced engineers: peer groups are almost mandatory in practice, address-family activation is explicit, and configuration sessions let you stage and diff a routing change before committing it. This guide builds an EOS BGP configuration from router-id to route policy, covers the address-family and next-hop details that break in multi-protocol designs, and finishes with the verification and session-management commands you will use during incidents.

Base session and peer group

switch# configure session BGP-2026-09
switch(config-sess-BGP-2026-09)# router bgp 65001
switch(config-router-bgp)# router-id 10.0.0.1
switch(config-router-bgp)# no bgp default ipv4-unicast
switch(config-router-bgp)# maximum-paths 4 ecmp 4
switch(config-router-bgp)# neighbor ISP peer group
switch(config-router-bgp)# neighbor ISP remote-as 65002
switch(config-router-bgp)# neighbor ISP description "Transit peers"
switch(config-router-bgp)# neighbor 203.0.113.1 peer group ISP
switch(config-router-bgp)# neighbor 203.0.113.5 peer group ISP
switch(config-router-bgp)# neighbor IBGP peer group
switch(config-router-bgp)# neighbor IBGP remote-as 65001
switch(config-router-bgp)# neighbor IBGP update-source Loopback0
switch(config-router-bgp)# neighbor 10.0.0.2 peer group IBGP
switch(config-router-bgp)# address-family ipv4
switch(config-af)# neighbor ISP activate
switch(config-af)# neighbor IBGP activate
switch(config-af)# network 10.0.0.0/24
switch(config-af)# exit
switch(config-router-bgp)# exit
switch(config-sess-BGP-2026-09)# show session-config named BGP-2026-09 diffs
switch(config-sess-BGP-2026-09)# commit

no bgp default ipv4-unicast disables the legacy behaviour of activating every new neighbour in the IPv4 unicast family implicitly. Using it forces you to activate families deliberately - the right choice for any modern design, and the reason a peer can be "up" with no routes if you forget the activation line. Configuration sessions add the same commit/diff safety that IOS XR engineers expect; EOS keeps a running history of session commits too.

Route policy, next-hop and BFD

switch(config)# ip prefix-list PL-DEFAULT seq 10 permit 0.0.0.0/0
switch(config)# route-map RM-IN permit 10
switch(config-route-map-RM-IN)# match ip address prefix-list PL-CUSTOMER
switch(config-route-map-RM-IN)# set local-preference 150
switch(config-route-map-RM-IN)# set community 65001:100 additive
switch(config-route-map-RM-IN)# exit

switch(config-router-bgp)# neighbor ISP route-map RM-IN in
switch(config-router-bgp)# neighbor IBGP next-hop-self
switch(config-router-bgp)# neighbor ISP bfd
switch(config-router-bgp)# neighbor ISP timers 10 30
switch(config-router-bgp)# address-family ipv4
switch(config-af)# neighbor ISP route-map RM-OUT out
switch(config-af)# redistribute connected route-map RM-CONNECTED

switch(config)# router bgp
switch(config-router-bgp)# address-family ipv6
switch(config-af)# neighbor IBGP6 activate
switch(config-af)# neighbor IBGP6 next-hop address-family ipv6 originate

Two gotchas live here. First, when a BGP session is established over IPv6 link-local addresses carrying IPv4 prefixes, EOS will not negotiate RFC 8950 IPv6 next hops unless you explicitly configure next-hop address-family ipv6 originate - without it the IPv4 prefixes get useless IPv4 next hops or are not advertised at all. Second, BFD brings sessions down far faster than BGP timers alone; enable it only where the peer supports it, otherwise you increase the chance of a false positive flap.

Verification

switch# show ip bgp summary
switch# show ip bgp neighbors 203.0.113.1
switch# show ip bgp neighbors 203.0.113.1 advertised-routes
switch# show ip bgp neighbors 203.0.113.1 received-routes
switch# show ip bgp
switch# show ip bgp 10.0.0.0/24 detail
switch# show ip bgp regexp ^65002_
switch# show ip route bgp
switch# show ip bgp community 65001:100
switch# clear ip bgp 203.0.113.1 soft in
switch# clear ip bgp *

Read the summary table as three columns of truth: state (established), uptime, and prefix count. Established with zero prefixes narrows the fault to activation or an inbound filter; not established narrows it to reachability, timers or authentication. soft in is the safe way to re-apply inbound policy without dropping the session - practise using it instead of the reflexive clear ip bgp *.

Operating EOS BGP in production

Stage the change in a configuration session, review the diff, apply it on one route reflector or leaf first, verify the RIB and traffic, then roll forward. Keep policy in named route-maps and prefix-lists so an audit is possible, and remember that the fastest way to debug a fabric is often show ip bgp on the egress leaf rather than on the core. Related reading: EOS configuration sessions, BGP peering security, best path selection and BGP in EVPN fabrics.

原文链接：https://www.arista.com/en/um-eos/eos-border-gateway-protocol-bgp