No history yet

State-Sharing Architecture

A Smarter Way to Share State

Traditional network operating systems are built on a fragile foundation. In these legacy systems, different software processes, like the one handling OSPF routing and the one managing the forwarding table, communicate directly with each other. This method, known as Inter-Process Communication (IPC), creates tight, brittle dependencies. If one process crashes, it can cause a domino effect, destabilizing others or even forcing the entire switch to reboot.

Arista's Extensible Operating System (EOS) reimagined this model from the ground up. Instead of having processes talk to each other, EOS separates the state of the system from the processes that act on it. At the heart of this design is a centralized, in-memory database called . It acts as the single source of truth for everything happening on the switch, from interface statuses to routing tables. Processes, which in EOS are called , no longer communicate directly. Instead, they interact with SysDB.

The Publish-Subscribe Model

The interaction between agents and SysDB follows a clean and efficient pattern: the publish-subscribe-notify model. It works just like a news feed.

  1. Publish: An agent that owns a piece of information publishes its state to SysDB. For example, the BGP agent would publish updates about newly learned routes.
  2. Subscribe: Other agents that need this information, such as the agent that programs the forwarding hardware, subscribe to that specific data within SysDB.
  3. Notify: When the BGP agent publishes a change, SysDB immediately notifies all subscribed agents. Those agents then read the new state and take appropriate action.

This model completely decouples the agents from one another. The BGP agent doesn't need to know who needs its information, and the forwarding agent doesn't need to know where the route came from. They only need to talk to SysDB. This loose coupling is the source of EOS's renowned stability. If an agent crashes, it can simply be restarted. Upon restart, it re-reads the state it needs from SysDB and picks up exactly where it left off, all without impacting the rest of the system.

From Switch to Network

The power of this state-sharing architecture extends beyond a single device. Arista expanded this concept network-wide with NetDB and, more recently, the Network Data Lake (NetDL). NetDB aggregates the SysDB from every switch in the network into one unified, logical database. This gives operators and automation tools a real-time, holistic view of the entire network's state.

The Network Data Lake (NetDL) is the next evolutionary step. While NetDB holds the current state of the network, NetDL stores a time-series history of that state. This allows for powerful analytics and troubleshooting. An engineer can effectively rewind time to see exactly what the network's MAC address table or routing state looked like last Tuesday at 2:15 AM, just before an issue occurred. This depth of visibility is impossible with traditional, polling-based systems.

This state-centric architecture is the foundation of EOS's programmability and resilience. By treating state as a structured database rather than a fleeting series of messages, Arista created a system that is not only more stable but also inherently built for modern automation and analytics.