Arista Emphasizes Secure-by-Design Multi-Model AI Network in Q2 2026

Management view on Multi-model AI network and security at Arista (ANET)

1) Core message: multi-model AI must be “secure by design,” and it’s not a solo effort

Management framed the “mythos and vulnerabilities” of AI as central, emphasizing that Arista is committed to a “rock-solid foundation” via the EOS architecture and “the lowest vulnerabilities.” ¹ However, they also stated that making AI secure is not solely Arista’s responsibility: it requires working with “the leading model providers,” building “a robust infrastructure,” and partnering with “the best security vendors.” ¹

They specifically tied this partnership approach to their strategy of combining “the best-of-breed network model and security providers,” arguing that while “vulnerabilities are a fact of life,” the differentiator is how proactively customers are protected through “the right technology, with the right systems and the right process.” ¹

2) Multi-model network is required because model diversity is increasing—and traffic priorities will vary

Management said that, in practice, enterprise AI will increasingly involve “a lot of diversity of models” and that the system must remain robust “no matter what the model.” ¹ They described a lifecycle shift toward “inference” after training, and said Arista is “taking a lot of care” to build a “multi-model network” able to handle “all of the traffic and all of the different priorities and SKUs.” ¹

They also acknowledged that some performance/behavior requirements (e.g., from “MRC”) can necessitate work on the network—specifically around “packet spraying” and “how the end host behaves.” ¹

3) Security enablement through operational security controls: reduce downtime when patching/exploits emerge

A concrete management claim about security resilience came through Arista’s EOS upgrade philosophy. Management explained that frequent upgrades are a “hard reality today,” especially because AI both “uncovers security vulnerabilities and creates tools to exploit them.” ² They contrasted this with systems that require a full reboot: Arista’s EOS “handles these upgrades seamlessly,” ensuring customers stay secure “without sacrificing even a single minute of valuable XPU cycles.” ²

So, in management’s view, security is supported not only by vulnerability reduction, but also by fast, disruption-free remediation via SSU. ²

4) Performance and reliability features that support secure, robust multi-model traffic

Management linked their AI networking innovations to both performance and operational robustness—two prerequisites for secure deployments.

MRC (Multipath Reliable Connection): handle path diversity without sacrificing correctness/performance

Management described MRC as a mechanism to spray traffic across many paths “through the fabric,” while receivers reassemble out-of-order data so traffic does not lose performance from hash collisions. ² This matters for multi-model environments because with diverse workloads and traffic patterns, congestion and collisions are more likely; management positioned MRC as a way to maintain utilization and reliability while routing choices vary. ²

SRv6 + traffic engineering: deterministic routing with dynamic congestion avoidance

Management described SRv6/Segment Routing as enabling the sender to “tag each packet with a stack of SRv6 segment IDs,” dictating the exact path the packet takes. ² They added that the system then uses “real-time congestion signaling” to move packets away from hotspots. ²

They also discussed a broader scale-across capability: “programmable and deterministic routing,” “multi-plane forwarding,” “multi-tenancy and traffic engineering,” and “load balancing across the regions,” with “near instantaneous recovery” for congestion, packet loss, or physical failures independent of cluster geography. ³ While this is framed as scale-across functionality, it is directly relevant to running many model workloads securely and reliably across regions because it supports isolation, deterministic behavior, and rapid recovery. ³

5) Architecture strategy: open/interoperable but with EOS depth for reliability/vulnerability

Management repeatedly emphasized that they’re positioned as a “best-of-breed” player in an ecosystem of multiple model makers and infrastructure providers. ⁴ In discussing EOS versus “white box” approaches, management argued that customers adopting EOS typically value:

• Operational excellence (less staffing, operational simplicity), ⁵
• Depth and breadth of AI features that are hard to recreate in a white box, ⁵
• Reliability and vulnerability—explicitly described as “becoming top and center,” with the idea that you can’t risk “blow[ing] up” security/reliability-critical systems. ⁵

They also said customers may want “either EOS itself in its entirety or a hybrid combination of open NOSes and EOS,” implying a secure multi-model strategy can be implemented in different deployment modes while still preserving Arista’s security/reliability strengths. ⁵

6) Practical implication management gave: robust networking must work across NVIDIA and non-NVIDIA accelerators

While not strictly “multi-model,” management tied networking strategy to heterogeneity of accelerators and workloads, which parallels the “multi-model” reality. They said they “live in an NVIDIA world” with a high percentage of GPUs connected, but emphasized they perform better in scale-out/scale-across domains in NVIDIA cases. ⁶ For non-NVIDIA accelerators, they described working with customers in scale-up/scale-out to build custom racks to better tune the network to inference/training engine behavior. ⁶

In management’s framing, robust network design has to accommodate model/hardware diversity without undermining security and reliability. ⁶

---

Bottom line (what management said, in plain terms)

Management’s view is that multi-model AI forces networks to handle diverse models, traffic patterns, priorities, and SKUs while remaining secure. ¹ They portrayed security as enabled by both (a) EOS architecture commitments to low vulnerabilities and proactive handling of vulnerabilities through the right systems/processes and ecosystem partners ¹ and (b) operational mechanisms like SSU to patch/remediate rapidly without downtime. ² They further described MRC and SRv6-based traffic engineering as core building blocks to keep multi-workload traffic reliable and resilient—supporting secure operations even as routing/loads/congestion conditions change. ²³