Arista EOS BGP Peering Security Best Practices

An unprotected BGP session is an open door: a rogue peer can drain your routing table, blackhole prefixes or exhaust the control plane. This guide summarizes the official Arista EOS best-practice article on BGP peering security and manageability, translating it into concrete CLI configuration — TTL security, peer authentication, prefix and AS_PATH filtering, control-plane ACLs, route limits and BFD — that you can apply to any production Arista switch today, plus the logging and checklist items that turn the configuration into an operational habit.

Why BGP Peering Needs More Than a Neighbor Statement

RFC 7454 provides vendor-neutral guidance on BGP operations and security, but Arista's community article goes further with EOS-specific commands. The core idea: restrict who can form a session, restrict what routes you accept, and protect the switch's own control plane from BGP-driven load.

Those three ideas map to three distinct failure modes. An attacker or a misconfigured neighbour that can establish a session can advertise a more-specific route for your own address space and blackhole it. A peer that is legitimate but unbounded can send you a full table when you expected a handful of prefixes, filling the RIB or the FIB and destabilising every other protocol on the box. And a flood of BGP packets — valid or not — is processed by the supervisor CPU, so protecting the control plane is not a nicety on a switch that also answers SSH, eAPI and SNMP. Harden all three layers, then make the state visible so you notice when something changes.

1. TTL Security and Peer Authentication

Enable GTSM (TTL security) so packets from beyond the trusted domain cannot establish a session, and use MD5 authentication so even on-link attackers cannot forge BGP packets:

switch(config)# router bgp 64500
switch(config-router-bgp)# neighbor 192.0.2.1 remote-as 65001
switch(config-router-bgp)# neighbor 192.0.2.1 ttl maximum-hops 1
switch(config-router-bgp)# neighbor 192.0.2.1 password 7 <encrypted-key>

The maximum-hops value states how many hops away the legitimate peer may be. For a directly connected eBGP peer, 1 is correct: the peer sends with TTL 255 and GTSM expects the value that corresponds to one hop, so a packet launched from further away arrives with a TTL that fails the check and is dropped before it reaches the BGP process. For an iBGP or loopback-based session, set the value to the real hop count — too high and you have weakened the protection, too low and the legitimate session will never come up (and it will look like a transport problem, not an authentication problem).

Authentication is the second half of the pair. MD5 protects the TCP segment, but it is an old mechanism with known weaknesses; where your EOS release and peer both support it, prefer TCP-AO (RFC 5925). Either way, enforce two rules in your template: never configure a peer without authentication, and never re-use a key across neighbours. A password mismatch produces a session that stays in a non-established state with almost no diagnostic output, which is exactly the situation covered in our BGP session stuck in Idle/Active troubleshooting guide — check the key before you check the ACL.

2. Prefix Filtering at the Edge

Filter inbound and outbound prefixes with prefix-lists and route-maps. EOS also supports sourcing prefix-lists from a local file, refreshed on a schedule — ideal for bogon feeds that change daily:

switch(config)# schedule schedule-refresh-prefix-list at 03:00:00 interval 1440 \
  command "refresh ip prefix-list"
switch(config)# ip prefix-list PL-IBGP-IN seq 5 permit 0.0.0.0/0 le 24

Refresh the list at boot and on a schedule; an outdated bogon list either blocks legitimate prefixes or admits invalid ones.

Prefix filtering has to work in both directions. Inbound, list exactly what the peer is allowed to announce — for a customer, their registered ranges; for a transit provider, everything except your own space and the bogon prefixes. Outbound, list exactly what you are willing to announce, because announcing a prefix you do not own is how you blackhole somebody else's traffic:

switch(config)# ip prefix-list PL-CUSTOMER-IN seq 10 permit 203.0.113.0/24
switch(config)# ip prefix-list PL-CUSTOMER-IN seq 20 deny 0.0.0.0/0 le 32
switch(config)# ip prefix-list PL-OUT seq 10 permit 198.51.100.0/24
switch(config)# ip prefix-list PL-OUT seq 20 deny 0.0.0.0/0 le 32
switch(config)# route-map RM-CUSTOMER-IN permit 10
switch(config-route-map-RM-CUSTOMER-IN)# match ip address prefix-list PL-CUSTOMER-IN
switch(config)# route-map RM-OUT permit 10
switch(config-route-map-RM-OUT)# match ip address prefix-list PL-OUT
switch(config)# router bgp 64500
switch(config-router-bgp)# neighbor 192.0.2.1 route-map RM-CUSTOMER-IN in
switch(config-router-bgp)# neighbor 192.0.2.1 route-map RM-OUT out

Add an AS_PATH filter on top, so a peer cannot announce a prefix it does not own and cannot form a path that loops through your own AS. Denying your own AS number inbound also removes the simplest route-hijack vector a misconfigured neighbour can create:

switch(config)# ip as-path access-list AS-FILTER-AS65001 permit ^65001$
switch(config)# ip as-path access-list AS-FILTER-AS65001 deny .*
switch(config-router-bgp)# neighbor 192.0.2.1 filter-list AS-FILTER-AS65001 in

Where the EOS release supports RPKI origin validation, adding ROA-based checks catches the class of leak that prefix-lists cannot: a peer announcing address space it does not own but that falls inside a range it legitimately holds.

3. Protect the Control Plane

Copy the default control-plane ACL, tighten it to permit BGP only from trusted peer IPs, and apply it as the control-plane ACL. This shields the supervisor CPU from floods while keeping peering alive.

The reason to start from the default rather than from scratch is that the default already permits the traffic the switch needs to operate — management, routing protocols, and the established TCP sessions BGP relies on. Tighten it to an explicit list of peers, and remember to permit the BFD packets too, or you will have a session that survives a link failure for far longer than your timers promised:

switch(config)# ip access-list CP-BGP
switch(config-acl-CP-BGP)# 10 permit tcp host 192.0.2.1 any eq bgp
switch(config-acl-CP-BGP)# 20 permit tcp host 192.0.2.1 eq bgp any
switch(config-acl-CP-BGP)# 30 permit udp host 192.0.2.1 any eq 3784
switch(config-acl-CP-BGP)# 40 permit tcp any any established
switch(config-acl-CP-BGP)# 100 deny ip any any
switch(config)# control-plane
switch(config-cp)# ip access-group CP-BGP in

Order matters: the peer-specific permits come first, the broad established permit keeps return traffic working, and the explicit deny makes the policy auditable. Test any control-plane change on an out-of-band path — a mistake here locks you out of the switch, and recovery requires console access.

4. Bound What You Accept: maximum-routes

EOS differentiates maximum-routes (warning only, default 12000) from maximum-accepted-routes (shuts the peer into IDLE when exceeded, until a manual clear):

switch(config-router-bgp)# neighbor 192.0.2.1 maximum-routes 20000
switch(config-router-bgp)# neighbor 192.0.2.1 maximum-accepted-routes 25000 warning-limit 20000

Use the two together: the warning threshold tells you a peer is drifting, and the accepted limit is the circuit breaker that prevents a bad day from becoming an outage. Size the numbers from the peer's real table size plus headroom, and record the value in your peer documentation — a limit that is too low turns a legitimate growth in the peer's table into an outage that requires a manual clear bgp to recover. On a full-table transit session, the limit should reflect the current global table size with room for several months of growth; on a customer session announcing a handful of prefixes, a limit of a few hundred is generous and will catch a leak instantly.

5. Convergence: BFD and Visibility

Pair BGP with BFD to detect link loss in milliseconds instead of hold-timer seconds. For observability, stream BGP updates (trigger-based, no polling) to a collector or use the ARISTA-BGP4V2-MIB over SNMP. See also our Arista EOS troubleshooting cookbook and MLAG configuration guide for adjacent topics.

switch(config)# bfd interval 300 min-rx 300 multiplier 3
switch(config)# router bgp 64500
switch(config-router-bgp)# neighbor 192.0.2.1 bfd

A detection time of roughly 900 ms (300 ms × 3) is a sane starting point for a routed uplink: fast enough to beat any reasonable reconvergence requirement, slow enough not to flap on a congested link. Make sure the control-plane ACL permits BFD, make sure both ends agree on the timers, and remember that BFD detects forwarding failure — it does not validate routing policy, so it complements prefix limits and filters rather than replacing them.

6. Outbound Hygiene and Session State

Half of BGP security is what you send, not what you receive. A short, disciplined list applied to every peer:

• Never aggregate away a peer's traffic: prefer explicit outbound prefix-lists over default-originate, which can advertise a default route to a neighbour that will then send you its entire traffic volume in the wrong direction.
• Shut down unused peers with neighbor 192.0.2.1 shutdown instead of deleting the configuration; the session cannot form, but the intent stays documented, and re-enabling it is a single command.
• Use peer-groups so that every neighbour inherits the same filters, timers and limits. A peer configured by hand outside the group is the one that will be missing a prefix-list during the next incident.
• Keep the TCP-AO or MD5 key, the peer address and the remote AS in your source of truth; drift between the documentation and the running config is how unauthenticated sessions appear.
• Be deliberate about graceful restart and long-lived graceful restart: they keep stale routes alive across a control-plane restart by design, which improves availability and modestly increases the window in which stale information is forwarded.
• Separate management from transit where the topology allows — a management VRF keeps eAPI, SSH and SNMP reachable even when the control plane ACL is under pressure.

7. Logging and Change Verification

Detection is part of hardening. Turn on BGP traps and make sure neighbour state changes reach your collector, because the first sign of an attack or a leak is usually a session flap or a route-count jump rather than a packet capture:

switch(config)# snmp-server enable traps bgp
switch(config)# logging host 10.0.0.5
switch(config)# logging trap informational
switch(config)# show ip bgp summary
switch(config)# show ip bgp neighbors 192.0.2.1
switch(config)# show ip bgp neighbors 192.0.2.1 received-routes

Then verify the hardening itself — a filter that is configured but not applied is worse than none, because it produces false confidence. Check that the prefix-list is attached in the direction you intended, that the AS_PATH filter matches the received routes, and that the route count in show ip bgp summary is in the range you expect for that peer. Baseline those counts and alert on deviation.

BGP Peering Hardening Checklist

• GTSM (ttl maximum-hops) set to the real hop count on every peer.
• Authentication configured on every session; TCP-AO preferred over MD5 where both ends support it.
• Inbound and outbound prefix-lists applied, with an explicit trailing deny and no reliance on defaults.
• AS_PATH filter denying your own AS and unexpected origin ASes inbound.
• Control-plane ACL permitting BGP and BFD only from known peers, applied on an out-of-band connection.
• maximum-routes warning limit plus maximum-accepted-routes circuit breaker, sized per peer.
• BFD enabled with agreed timers, and BFD permitted through the control-plane ACL.
• SNMP traps and syslog forwarded; route counts baselined and alerted on.
• Peer-groups used so no session is exempt from the standard policy.
• Unused peers shut down rather than deleted, and key material documented outside the config.

Related: BGP neighbor flapping root causes, Arista EOS BGP peers and peer-groups configuration.

原文链接：https://arista.my.site.com/AristaCommunity/s/article/bgp-peering-configuration-best-practices-security-and-manageability