Arista's Extensible Operating System (EOS) treats routing protocols differently than traditional network operating systems. Instead of a single, monolithic process handling all routing information, EOS uses a multi-agent model where each protocol, including BGP, runs as a separate, isolated process. These agents then communicate with the Routing Information Base Daemon (Ribd) to program the forwarding plane.

This design significantly improves stability and performance. If the BGP agent encounters an issue, it can be restarted without affecting OSPF or the underlying hardware forwarding. It also allows Arista to develop and update features for specific protocols without requiring a full system-wide software upgrade.

Starting the BGP process on an Arista switch is straightforward. You define the BGP autonomous system (AS) number and immediately take explicit control over which address families are active.

The command no bgp default ipv4-unicast is crucial. By default, older BGP implementations would automatically start trying to negotiate IPv4 unicast sessions with every configured neighbor. Disabling this forces you to be deliberate. You must explicitly activate the IPv4 or IPv6 address family for each neighbor, which prevents accidental route exchanges and makes the configuration clearer and more secure.

Next, you need a stable BGP Router-ID. This is a 32-bit number, usually formatted like an IPv4 address, that uniquely identifies the router within the BGP domain. If you don't set one, EOS will choose one for you, typically from the highest IP address on a loopback interface, or the highest IP on a physical interface if no loopbacks exist. Relying on a physical interface is risky; if that interface goes down, the Router-ID can change, causing all BGP sessions to reset. The best practice is to manually configure a dedicated loopback interface and use its IP address.

With the BGP process running, you can define your neighbors. The configuration differs slightly for external BGP (eBGP) peers, which are in a different AS, and internal BGP (iBGP) peers, which are in the same AS.

Notice the update-source command for the iBGP neighbor. Because iBGP peers often connect using their stable loopback addresses, you must tell BGP which source IP to use for its TCP connection. For eBGP, this is typically not needed as peers are usually directly connected.

As you add more neighbors with similar configurations, repeating the same commands becomes tedious and error-prone. Arista EOS supports BGP Peer Groups to solve this. You create a group, define the shared configuration once, and then simply assign neighbors to that group. This makes the configuration cleaner and more scalable.

Simply configuring a neighbor isn't enough. Because we used no bgp default ipv4-unicast, no routes will be exchanged until we explicitly activate an address family. This is done within the neighbor or peer group configuration.

Once activated, the BGP process will attempt to establish a session with the neighbor. This process follows a state machine. In EOS, the key states you'll see are:

You can check the status of your BGP neighbors with the show ip bgp summary command. An established session is the goal, and any other state indicates a specific point of failure in the connection process.

With these building blocks, you can create stable and scalable BGP peerings on Arista EOS, forming the foundation for more advanced routing policies.