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, prefix filtering, control-plane ACLs, route limits and BFD — that you can apply to any production Arista switch today.

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.

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>

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.

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.

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

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.

Related: BGP neighbor flapping root causes.

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