Arista will put an emphasis on the technologies behind building and operating datacentres, and the reasons they give the results expected from them (varied traffic spike management, increasing bandwidth, end points and security), including very large-scale production environments.

2. PRESENTEDBY
LET’S BUILD A NG DC
LAURENT GALLAMPOIS
ARISTA
lg@arista.com
ROOM NAME
4.30 PM

3. HOW TO BUILD NEW GENERATION DC ?
AGENDA
Let’s summarize it in few steps
Building the topology
Automate deployment and day to day services
Monitor actively your DC

4. THE STORY BEGIN WITH SPINE/LEAF DESIGN
BUILDING THE TOPOLOGY
IP only between Spine and Leaves (IPv4 or IPv6)
Mainly BGP protocol between Spine and Leaves
Spine can be chassis or simple ToR (depending of scalability level)

5. IT WAS ABOUT OPTIMIZING ARCHITECTURE …
BUILDING THE TOPOLOGY
Universal SpineLeaf/SpineLegacy
Access
Distribution
Core
Switching
Legacy Core
Routing
Optical
DCIInternet DCIInternet
DCI
Transit
Public
Peering
Internet Inter-DC WAN
Spine
Leaf
EW
Spin
e
Spine
Leaf

6. THEN CLOUD COMPANIES HAVE ARRIVED …
BUILDING THE TOPOLOGY
Spine/Leaf still the reference design but they wanted
 Cost optimized products
 As few as possible references
 Huge scaling level
 Spine only pushing some traffic like a “switching Fabric in chassis”
 No proprietary model from Hardware and Software standpoint
OK, Chassis is not the most appropriate …
Well, how to scale … ?

7. HOW ANSWER TO THIS NEEDS ?
BUILDING THE TOPOLOGY
Let’s explode chassis component …
Switching Fabric are now Spine
LineCards are now Leaves
Internal links are now standard Ethernet
links, at desired speed, with BGP and
IPv4/IPv6 !!

8. SO WHAT ?
BUILDING THE TOPOLOGY
Finally we’ve just created a Spine/Leaf based on ToR, …
But in fully standardized manner
Ethernet,
IPv4/IPv6
BGP
1 RU,
Cost Attractive switches
Merchant Silicon Approach
1 RU,
Cost Attractive switches
Merchant Silicon Approach

9. LET’S PUT THIS IP FABRIC INTO CONTEXT
BUILDING THE TOPOLOGY
Each chassis is now a “PLAN”
PLAN - #1 PLAN - #2 PLAN - #3 PLAN - #4

10. PLAN CONCEPT IS HIGHLY SCALABLE …
BUILDING THE TOPOLOGY
Increase bandwidth on demand …
Increase density on demand …
Increase ToR bandwidth on demand …

11. IPV6 OR NOT IPV6 FOR THE FABRIC
THAT IS THE QUESTION ?
BUILDING THE TOPOLOGY
ServersServers
No real problem about using IPv4 – Except lack of IPv4 addresses perhaps
IPv6 can be deployed and some gateway between both world are there
 RFC 5549 : IPv4 with IPv6 nexthop
 IPv6 HW-VTEP is possible with T3, Jericho+/Jericho2, Tofino (Barefoot)
Rack 1 Rack N
ToR ToR
ASN-11 ASN-12
SW VTEP
IPv6 Fabrics/Plans
IPv6 connectivity
BGP for VTEP Reachability
HW – VTEP IPv6
Layer 2 – Layer 3 traffic
with dot1q or not
ServersServers
Rack 1 Rack Nq
ToR ToR
ASN-21 ASN-22
HW – VTEP IPv4
End to End IPv6 IPv4 VTEP with NH IPv6
IPv6 VTEP
IPv6 NLRI
IPv6 VTEP
IPv6 NLRI
IPv4 VTEP
IPv6 NLRI
IPv4 VTEP
IPv6 NLRI

12. NOW WE HAVE FABRICS
HOW DO WE ADD SERVICES ?
BUILDING THE TOPOLOGY
Servers Servers
Traffic encapsulated at HW-VTEP/ToR level
Only IP traffic to carry when entering IP Fabrics/Plans
Works for Layer 2 and Layer 3 services :
eVPN+VXLAN as standard solution
Rack 1 Rack N
ToR ToR
ASN-11 ASN-12
SW VTEP
IP Fabrics/Plans
IP connectivity
HW - VTEP
BGP for HW-VTEP
IP reachability
Shared Segment
Layer 2 – Layer 3 traffic
with dot1q or not

13. THE TRANSITION TO CLOUD NETWORKING
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Manual, Box-by-Box Automated, Network-wide
Legacy Networking Cloud Networking
Closed architectures
Open, decoupled,
standards-based approaches
Limited integration and control
Control through deeper
programmability at all layers
Networking skill sets
New skill sets - virtualization,
DevOps, scripting

14. ARISTA ZERO TOUCH PROVISIONING - ZTP
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
It’s the automated provisioning of new switches…
 New switches are provisioned automatically, including code version,
extensions and configuration.
 Powerful customization options using open standard tools, topology
awareness
Allows for the automatic and parallel operation of repetitive tasks
 Helping eliminate the chances of operator error
 Drastically reducing maintenance windows
Enables Zero Touch Replacement (ZTR)
 Reduces on-site skills requirement for hardware replacement
 Especially useful in secure or remote data centers
Rack… Connect… Power on…

15. DEVOPS AND SCRIPTING CAPABILITIES : …
… EVERYTHING CAN BE AUTOMATED
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
AEM : Advanced Event Management
 Trigger some action based on criteria : Interfaces state, counters, VM move, …
 Launch action based on time, repetitively, ...
 Monitor network activity : mac, arp, next-hop, ...
Multiple API available :
 eAPI over http, https
 C++ SDK with Python interface : Ability to create your own agent
 Go API
Access to Bash running on unmodifed Linux kernel
 Install existing package
 Install package you created
 Access to Docker capabilities
Support of Ansible, Puppet, …
NetConf/RestConf Yang

16. AEM : ADVANCED EVENT MANAGER
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Event Scheduler
 Execute script, command or any program
 Based on given time every day
 Every amount of time.
Event Handler
 Execute script, command or any program triggered by specific event
▪ on-boot trigger condition occurs on system boot
▪ on-counters trigger condition occurs on evaluating statistical counters
▪ on-intf trigger condition occurs on specified interface changes
▪ on-logging trigger condition occurs when regex match any log message
▪ on-maintenance trigger condition occurs on maintenance operation
▪ on-startup-config trigger condition occurs on startup config changes
▪ vm-tracer trigger condition occurs on VmTracer events

17. EAPI : DEAD SIMPLE AUTOMATION API
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Anything you can do, you should be able to automate…
… in just a few lines of code!
Send a list of any CLI commands, and get back structured data
Use JSON over HTTP(S) for painless, cross-platform compatibility
Works well for remote or on-box programming

18. EAPI
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Very simple protocol means you can use any language you'd like: Python, Go,
Javascript, C++, Java, Bash (hello curl!), node.js, Ruby, Perl, and almost every
other language
 There is an eAPI specific library in Python to make the API even easier: pyeapi
3rd party client libraries:
▪ Ruby https://github.com/imbriaco/arista-eapi
▪ Node.js https://github.com/thwi/node-eAPI
▪ Go https://github.com/fredhsu/eapigo, etc.

19. EOS SDK: UNLEASH THE FULL POWER OF EOS
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
A very powerful C++/Python API that enables the development of native,
high performance applications/agents that can manipulate and react to
switch state via a stable API to Sysdb.
 third-party agents get all of the EOS goodness: event-driven notifications, ProcMgr control,
CLI + eAPI integration, etc.
 open development and docs on GitHub
 30+ modules available now, more coming soon

20. IN ANY CASES, VALIDATION IS KEY
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Test everything you can, to anticipate problems :
Deployment automation,
Service deployment,
Software upgrade,
…
You need flexible environment to achieve it easily …

21. EOS FLEXIBILITY IS ALLOWING EASIER VALIDATION
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Arista Hardware x86 Server
EOS
(Linux)
Multi-Hypervisor
X86 Server
Arista hardware
3rd Party hardware
Linux Kernel
Container
Docker
cEOS
VM
vEOS
(Linux)
HW+SW Bundled solution
vEOS Lab
vEOS Router
Kernel independence (Cloud)
Hardware Disaggregation
General lab simulation
Standard EOS EOS in a virtual machine EOS in a container
Use
casesArchitecture

22. MONITOR ACTIVELY YOUR DC
MONITOR ACTIVELY YOUR DC
SNMP: Networking’s old school API
Ubiquitous and well integrated in standard tools
Well documented models
Support for common types of configuration and notifications
But this doesn’t catch everything …
When we should be able to do it

23. WHAT IS STATE STREAMING ?
MONITOR ACTIVELY YOUR DC
Every NetDB state change. From every device. Instantaneously.
Interface Counters
sFlow Data
Temperature Sensor
Routing Tables
MAC Tables ACL Counters
Buffer Utilization
System logs
CPU Load
Fan Speed
Power Draw
VXLAN Mappings
State Streaming
Every state change triggers an
update…
LANZ Data
Table Utilization
Configurations
…and streamed to a
central state repository

24. WHY IS IT SO EASY FOR EOS ?
MONITOR ACTIVELY YOUR DC
Low Inter-Process Communication
Arista EOS – Publish / Subscribe
Efficient Publish/Subscribe
Publish
Notify
PIM
SNMP BGP
Driver
MLAG
STP eAPI
IGMP
Linear Cloud Scale
This is just about adding a new agent !!
No internal polling with process before
streaming : Agent is connected on NetDB
Telemetry
NetDB

25. SUMMARY
AUTOMATE DEPLOYMENT AND DAY TO DAY SERVICES
Un grand merci à OVH et ses équipes pour nous avoir :
Choisi pour les déploiements initiaux VXLAN en 2014
Fait confiance pendant ces 4 années de collaboration
MERCI !!

27. 27
Complete, Real-time state streaming
EOS TerminAttr EOS TerminAttr EOS TerminAttr EOS TerminAttr EOS TerminAttr
Custom
backend
OR
EOS OpenConfig EOS OpenConfig EOS OpenConfig EOS OpenConfig EOS OpenConfig
ODL or other Controller
(YANG models)
gRPC (protobuf),
HTTP, Custom
gRPC (protobuf),
RESTCONF,
NETCONF
All EOS internal state (data models) including SysDB,
Counters, logs, kernel; etc
Data models defined by OpenConfig
YANG models
Open APIs
• CloudVision Apps
• Partner Apps
• Custom Apps
TerminAttr OpenConfig
OR
Ingest (ockafka)
Kibana / Elastic Search /
Logstash