ARISTA ST2110 Smpte Truck Interconnectivity Deployment User Guide
- June 6, 2024
- ARISTA
Table of Contents
ST2110 Smpte Truck Interconnectivity Deployment
Specifications:
-
Product Name: Arista SMPTE ST2110 & OB Truck
Interconnectivity -
Manufacturer: Arista
-
Maximum Link Speed: 1.6TbE
-
Supports: /31 subnet masks
Product Information:
The Arista SMPTE ST2110 & OB Truck Interconnectivity
solution is designed to provide seamless connectivity between OB
trucks for SMPTE ST2110 workflows. It supports high-speed links up
to 1.6TbE and allows for easy configuration of IP addressing to
establish interconnections between trucks.
Product Usage Instructions:
Single Link Configuration:
To configure a basic T2T IP addressing for a single link between
Truck A and Truck B:
- Truck A – Switch A – e1: IP address 10.0.0.0/31
- Truck B – Switch B – e1: IP address 10.0.0.1/31
Multiple Links Configuration:
To configure multiple links between two OB trucks for increased
bandwidth:
-
Configure additional interfaces (e2, e3, e4, …, eN) on both
switches for each link -
Example configuration for e2 link: Truck A – Switch A – e2: IP
address 10.0.0.2/31, Truck B – Switch B – e2: IP address
10.0.0.3/31
Interconnecting Multiple Trucks:
To connect Truck A to Truck C or other future trucks:
-
Consider using IP unnumbered or dynamic routing protocols to
facilitate easy connectivity -
Ensure proper IP addressing and routing configurations for
seamless interconnection
FAQ:
What is IP unnumbered?
IP unnumbered is a method that allows devices to share the same
IP address, simplifying network configurations, especially in
scenarios where multiple devices need to be interconnected.
How can I ensure seamless connectivity between multiple OB
trucks?
You can achieve seamless connectivity by configuring proper IP
addressing, utilizing dynamic routing protocols, and ensuring
consistent network configurations across all trucks involved.
Deployment Guide
SMPTE ST2110 & OB truck interconnectivity
Introduction Within the Media & Entertainment (M&E) world there are various
stakeholders involved in the supply chain and value chain that exists between,
say, the live sporting event on the field and the television in your living
room used to watch this sporting event. Closer to the action on the field
there exists an industry of events production companies in the form of Outside
Broadcast (OB) trucks, flypacks, and “rolling racks” used to acquire
audio/video content which eventually, among other locations, ends up in your
living room. Within the OB trucks are a skilled team of audio & video experts
choreographing many elements of the content displayed on your living room
television, your phone, your tablets, and many other electronic viewing
devices. In addition to the director, who runs the show, there are audio
mixing personnel, color-correction specialists, replay technicians, graphics
and sound effects masters, as well as a team of engineers who are assigned to
each truck and travel with the trucks as they move from venue to venue. Over
the last several years the industry has adopted the SMPTE ST2110 framework for
live production. And as the industry continues to transition from SDI-based
workflows to IP-based workflows the presence of IP has enabled the ability to
allow for ease of integration when the inevitable need for creating elastic
environments suddenly presents itself. What is one to do if there is a premier
television sporting event that needs a lot more cameras, replay operators, and
other capabilities? Well you bring in more OB trucks, rolling racks, &
flypacks to increase the overall capacity needed for pre-game, game, and post-
game productions. Fortunately as a well-informed and enlightened systems
architect you had the foresight to choose a COTS-based, open API, standards-
based IP solution as the switch fabric within your new IP-based SMPTE ST2110
environment. Using a COTS-based IP & Ethernet switching fabric allows you to
quickly expand your fabric using either standards-based computer networking
protocols, an SDN controller solution, or both. We’ve also all heard about
“the cloud” and the ability to “pay as you go” in order to tap into compute,
storage, and services/workflows on-demand from many of the well-known cloud
service providers. Today it’s not unusual for workflows to exist on-the-
ground, at various remote broadcast studio locations thousands of miles away,
and/or in the aforementioned cloud. Regardless of whether your event needs
more OB trucks on-the-ground, remote workflows that are across the Internet or
a leased circuit, or more compute & storage horsepower in the cloud, a COTS-
based solution has the ability to make your constantly changing workflow needs
more agile, seamless, robust, and manageable in our IP world.
arista.com
Deployment Guide
Creative freedom on the SMPTE ST2110 network Over the last few years we’ve had
the opportunity to work with some of the top OB truck designers around the
world, many of whom have deployed Arista switch fabrics at the heart of their
IP designs. As mentioned earlier there are often times when televised events
need more than a single OB truck perhaps from the same OB truck manufacturer,
as well as situations where many of the competing OB truck manufacturers need
to interconnect all their trucks on-site and share SMPTE ST2110 workflows, IP
multicast flows, PTP, and more. We are already seeing this shared 2110 IP
workflow strategy become more and more frequent and mandatory.
If you’ve been a voracious reader of Arista’s Media & Entertainment deployment
and best practices guides you may be familiar with the differences between
Layer 2 (L2) and Layer 3 (L3) network designs. There are many advantages in,
say, a SMPTE ST2110 environment where we prefer an L3 design for, among other
things, increased bandwidth control, packet flooding control, and fault domain
control. We’ve all heard the stories where a technician randomly plugs in an
Ethernet switch into another Ethernet switch (because the technician just
needed more Ethernet ports to plug in more broadcast devices) and suddenly
there are lengthy disruptions to the live broadcast and comm links go down for
some brief (yet panic-inducing) and unacceptable period of time. This can
occur in L2 environments when there is a Spanning Tree reconvergence or
multicast flooding in large L2 domains.
For one of our large OB truck customers, for whom we’ve designed many trucks
over the years, we adhered to SMPTE ST2110 networking best practices. This
entailed keeping each truck on their own L3 boundary so that when their trucks
need to be connected together (for the reasons mentioned above) having routed
interfaces between trucks (“truck-to-truck” or “T2T”) makes the most sense.
From a very basic IP configuration (there is no consideration, just yet, for
IP multicast, routing protocols, PTP, etc) perspective, and from a best
practices perspective, let’s say that you want N number of links, perhaps as
shown below:
Given the physical T2T interconnections above, the basic L3 interconnections
would be as follows for 1 of those N links: Truck A, Switch A, e1 (basic T2T
IP addressing)
interface e1 description Truck A T2T-1 going to Truck B T2T-1 no switchport ip
address 10.0.0.0/31
Truck B, Switch B, e1 (basic T2T IP addressing)
interface e1 description Truck B T2T-1 going to Truck A T2T-1 no switchport ip
address 10.0.0.1/31
arista.com
2
Deployment Guide
NOTE: Yes, you can have an IP address ending in “.0” and Arista switches
support “/31” subnet masks to help conserve IP address space.
So right now we’ve only configured a single link between Truck A & Truck B
(let’s call it “T2T-1”) connecting the 2 trucks. This, of course, is a single
point of failure. What if I want more than a single link? And what if a single
link is just not enough bandwidth? As of this writing (year 2023), you can
easily have a 400GbE link as T2T-1, with 800GbE and 1.6TbE on the horizon.
As the picture above implies we can have N links between our 2 OB trucks. The
more links we provide, the more overall bandwidth between the 2 trucks for our
SMPTE ST2110 workflows. And, of course, we’d have to configure (among other
things) IP addressing for both Switch A & B’s e2, e3, e4, …, eN interfaces,
where the e2’s in both trucks might look like this (note the differences from
e1 in red):
Truck A, Switch A, e2 (basic T2T IP addressing) interface e2
description Truck A T2T-2 going to Truck B T2T-2 no switchport ip address
10.0.0.2/31 Truck B, Switch B, e2 (basic T2T IP addressing) interface e2
description Truck B T2T-2 going to Truck A T2T-2 no switchport ip address
10.0.0.3/31
The keen observer will realize that given the configs above for each of the
interfaces (e1, e2, …, eN) that T2T-1 must always go between Truck A’s e1 and
Truck B’s e1, and T2T-2 must always go between Truck A’s e2 and Truck B’s e2,
and so on for all N links. Otherwise the IP addressing must change if, say,
someone wants to connect Truck A’s e1 to Truck B’s e2 – or maybe a technician
accidentally connects the wrong T2T links. Wouldn’t it be nice if we did not
have to worry about e1 connecting to e1, and e2 connecting to e2, etc and just
randomly connect the 2 trucks routed interfaces as below:
Or what about when Truck A needs to connect to Truck C for an event next week across the country? Do we now have to re-IP Truck C’s IP addresses to mate with Truck A’s IP addresses (where Truck C would then have the same IP’s as Truck B on all T2T links)? What about when Trucks B & C come together someday further into the future?
arista.com
3
Deployment Guide
Wouldn’t it be nice if any OB truck could connect its SMPTE ST2110 network to
any other truck’s SMPTE ST2110 network easily and just be “plug and play”?
There are many ways one could solve this problem, here are just a few:
· Use Arista CloudVision with pre-defined T2T scenarios already built ·
Ansible playbooks also with pre-defined scenarios already built · Use the
following IETF RFC compliant (RFC 1812) “pure” networking approach with IP
unnumbered
What is IP unnumbered?
IP unnumbered is a network configuration & design method where multiple
interfaces share the same IP address. Instead of assigning a set of dedicated
IP addresses from a limited pool to, say, point-to-point links (where there is
a matching pair of /31 addresses on each link) and having to manage these IPs
and track them, you can reuse the IP address from a loopback (or other)
address thereby relieving the design engineer/architect of some
responsibility. This allows for more efficient use of IP address space.
Recall from earlier that these T2T interfaces are routed (or L3) interfaces.
Essentially they need an IP address assigned at each end, but we want the
flexibility of being able to connect any truck (hence, any switch) to any
other truck (switch) without having to reconfigure IP addresses on interfaces
constantly. The OB trucks are constantly moving around the country/world every
week for a different televised event and each new event will require a change
in (what is essentially) the network topology. Unlike your typical enterprise
or cloud datacenter, the OB truck fabric can grow or shrink as time moves
forward. Most datacenters just grow – monotonically increasing in size – they
rarely shrink from week to week. The OB trucks are assigned to various events
around the globe based on their geographic location at any point in time.
Therefore it’s highly probable that for events needing more OB trucks that the
allocation of trucks needing to be mated together in order to share SMPTE
ST2110 workflows needs to be flexible enough to allow for any truck to any
truck configurations.
Behind those routed/L3 T2T interfaces exist a bunch of IP subnets within each
truck. There may be subnets for cameras, audio devices, replay devices,
multiviewers, gateways, and other broadcast devices. How might we inform the
other (mated) OB trucks of these IP subnets? We can either statically define
routes between the trucks, or use a more agile and robust method via dynamic
routing protocols.
Routing
Let’s pretend that within a particular OB truck you have an L3 network on the
SMPTE ST2110 fabric and that amongst Ethernet/IP switches within that truck
fabric you decide to use OSPF as the routing protocol to advertise IP subnets
within the truck. Well when the day comes that requires more than just one
truck at an event, connecting two trucks is rather trivial in order to spread
workflows around.
arista.com
4
Deployment Guide
If you own both trucks, presumably you trust what’s going on in each truck.
Hence one could forgo needing to implement extra security and policy measures
in order to protect Truck A from Truck B and vice-versa. Note that in
heterogeneous environments where the OB trucks being mated together are
owned/built by different manufacturers, policy discussions may be beneficial
for all stakeholders and fortunately a COTS-based solution (like Arista
Networks) allows for flexibility in policy instantiation.
So we want to connect Trucks A & B together and our goal is to make sure that
the routed/L3 interfaces don’t need an explicit IP address and we also need to
run our chosen routing protocol (OSPF) to advertise IP subnets between the two
trucks. Let’s look at some possible configs now for our two switches from
examples earlier:
Truck A, Switch A (IP unnumbered)
interface lo100 description OSPF-IP-unnumbered ip address 10.99.99.99/32 ip
ospf area 0.0.0.0
interface e1 description Truck A T2T-1 going to other Truck T2T-1 no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0
interface e2 description Truck A T2T-2 going to other Truck T2T-2 no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0 . . .
interface eN description Truck A T2T-N going to other Truck T2T-N no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0
Truck B, Switch B (IP unnumbered)
interface lo100 description OSPF-IP-unnumbered ip address 10.199.199.199/32 ip
ospf area 0.0.0.0
interface e1 description Truck B T2T-1 going to other Truck T2T-1 no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0
arista.com
5
Deployment Guide
interface e2 description Truck B T2T-2 going to other Truck T2T-2 no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0 . . .
interface eN description Truck B T2T-N going to other Truck T2T-N no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0
Interesting to note, the loopback 100 (“lo100”) addresses don’t need to be on
the “same” IP subnet (Truck A has 10.99.99.99/32 and Truck B has
10.199.199.199/32) and also notice that for each T2T interface we’re reusing
the same loopback address (“lo100”) on all N links thereby conserving IP
addresses and making the configuration easier. Some of you might stop and
wonder to yourself how this might affect flow distribution on the N links for
both IP unicast or IP multicast flows.
ECMP, IP multicast, & IP unnumbered
When you have multiple parallel interfaces between trucks (if not for anything
else, for redundancy purposes) there is a selection mechanism in order to
determine which of these many paths a packet goes. Let’s use the new diagram
below as an example.
The FHR (or First Hop Router) is an L3 router running PIM-SM (Protocol
Independent Multicast – Sparse Mode) that is closest to the sender. The LHR
(or Last Hop Router) is the L3 router running PIM-SM that is closest to the
receiver. When a receiver desires to receive a particular IP multicast packet
it’ll issue an IGMP Join message. Let’s pretend that the receiver is IGMPv3
compliant and asks to receive an IP multicast flow (“G”) from a particular
sender (“S”) – in this case it’ll issue an IGMPv3 (S,G) Join. When this IGMP
Join reaches the LHR, the LHR will issue a PIM Join towards the direction of
the sender (“S”). It knows which direction to send that PIM Join towards based
on its unicast IP routing table entry for “S” (the path to “S”).
In the above case the LHR has to pick which of the 4 colored links to send that PIM Join down. How does it determine that? Before the PIM Join leaves the LHR performs a hash calculation based on 4 attributes (a “4-tuple”): (S, G, nextHopIP, interfaceID). The “S” & “G” are self-explanatory – they are the (S,G) in the original IGMP Join. The “nextHop IP” is the value of the IP address on the other side of the /31 link (on the FHR side, in the above diagram). Of the 4 possible inputs for “nextHop” (one per link), the “nextHopIP” values in each calculation will be “10.0.0.0”, “10.0.0.2”, “10.0.0.4”, and “10.0.0.6”, respectively. The “interfaceID” is a unique 32-bit identifier assigned to the interface that the PIM Join will leave the LHR from. Note that this LHR egress interface (that the PIM Join leave from) will then eventually be the IIF (Incoming Interface) for the IP multicast flow originating from the Sender. Likewise, when the multicast routing table on the FHR is programmed, its OIL (Output Interface List) will also contain that same physical link (that was chosen at the prior PIM Join stage for a particular (S,G) or (*,G)) when the multicast tree from the sender to receiver is built.
arista.com
6
Deployment Guide
Speaking of which, what about the situation when the receiver issues an IGMP
(,G) Join? The “S” value that is then chosen for the hash calculation at the
LHR will then be the RP (Rendezvous Point) IP address. The hash that is
highest across all 4 links will determine which of the 4 links is chosen. If 2
or more hash values are equal, then the link with the highest IP address will
be chosen.
You’ll also notice that the T2T interfaces in the diagram have unique /31 IP
routed interface addressing. How might the hash algorithm change when I use IP
unnumbered and I reuse the same loopback IP address on all 4 links? In that
case the 4-tuple hash is reduced down to a 3-tuple hash: (S, G, interface ID)
PIM & PTP
For SMPTE ST2110 we need to configure PIM-SM and PTP with the proper SMPTE
2059-2:2015 PTP profile and message rates on these interfaces. For brevity,
let’s just look at a single interface on a single truck of a T2T link and put
it all together.
Any truck, any switch (IP unnumbered, PIM, PTP)
interface eN description Truck B T2T-N going to other Truck T2T-N no
switchport ip address unnumbered lo100 ip ospf network point-to-point ip ospf
area 0.0.0.0 pim ipv4 sparse-mode ptp enable ptp sync-message interval -3 ptp
announce interval 0 ptp delay-req interval -3
There are, of course, global configurations (PIM, PTP, and routing protocol)
needed to round-out the complete configuration for a fully-operational switch
fabric. Assuming that the remainder of the configurations for the switches
pertaining to OSPF, PIM, IP routing, and PTP are present and accurate, you are
on your way to building a more robust & dynamic T2T fabric.
Let’s pretend that each of Truck A & B has their own PTP GMs (because these
trucks may also run independently from each other) and that each truck runs on
the same PTP domain, assuming that the PTP Priority1 & Priority2 values are
appropriately chosen, the PTP BMCA (Best Master Clock Algorithm) will just
choose a prevailing GM to synchronize the entire fabric of the combined
trucks. Essentially one of the GMs from one of the trucks will become the
timing source for both trucks.
RP design strategy
If we consider the single truck situation, say there only exists Truck A, in
order to handle PIM-SM and the case of IGMP (,G) Joins or devices that are
not capable of IGMPv3 (S,G) Joins we need to have an RP within the truck. In
fact, each truck needs an RP because each truck can run independently. But
what happens when 2 or more trucks need to come together for an event?
In a dynamic PIM-SM environment there are some IETF protocols which can be of
assistance here – notably AnyCastRP and MSDP. Both protocols are used to
synchronize RP state and tell the other truck(s) about active senders (aka
“sources”) from within their own truck. In a SMPTE ST2110 environment IP
multicast video flows consume many gigabits per second and IP multicast multi-
channel audio flows consume many 100’s of megabits per second, therefore
bandwidth consumption, predictability, & control are important.
In general, we try to design systems that place RPs closer to the IP multicast
senders in each truck, and since trucks can run independently from one another
there is already an RP in each truck. Having an RP in closer proximity to the
sender can reduce the possibility of disruptive & bursty PIM Register traffic
needed to build the IP multicast routing tables when the switchover from
shared-tree RPT (Root Path Tree) to shortest-tree SPT (Shortest Path Tree)
occurs.
arista.com
7
Deployment Guide
From an RP perspective, we essentially need to (1) know where our RP(s) exist
and (2) synchronize the necessary state between all of our RPs. Determining
the location of RPs can be configured manually or automatically through
another IETF protocol called BSR (Bootstrap Router). Since BSR only allows for
a single active RP in a PIM domain (while all other RP candidates are just
passive backups) we don’t recommend using BSR in a SMPTE ST2110 environment
due to the large bandwidths and the fact that by definition the active RP
would not be the “closest” RP for all active sources but only some sources.
From an IP addressing standpoint every RP is going to have the same IP address
– an AnyCastIP address. Well, how can this be? Given that we are using a
dynamic routing protocol (OSPF in this case), each RP will advertise this same
AnyCastIP address out to the surrounding routers. Every other router (non-RP)
in the switch fabric will find its shortest path to its nearest RP that shares
this AnyCastIP address. State is then shared via AnyCastRP to the other RPs.
Let’s take a look at some AnyCastRP example configurations.
Truck A, Switch A
interface lo0 ip address 10.1.0.1/32 ip address 10.0.0.1/32 secondary (This
will be the AnyCastIP address)
ip routing router multicast
ipv4 routing
router pim sparse-mode ipv4 ssm range standard rp address 10.0.0.1 anycast-rp
10.0.0.1 10.1.0.1 (This will be the RP for Truck A, this truck) anycast-rp
10.0.0.1 10.2.0.1 (This will be the RP for Truck B) anycast-rp 10.0.0.1
10.3.0.1 (This will be the RP for Truck C)
Truck B, Switch B
interface lo0 ip address 10.2.0.1/32 ip address 10.0.0.1/32 secondary (This
will be a virtual AnyCastIP address)
ip routing router multicast
ipv4 routing
router pim sparse-mode ipv4 ssm range standard rp address 10.0.0.1 anycast-rp
10.0.0.1 10.1.0.1 (This will be the RP for Truck A) anycast-rp 10.0.0.1
10.2.0.1 (This will be the RP for Truck B, this truck) anycast-rp 10.0.0.1
10.3.0.1 (This will be the RP for Truck C)
For any possible truck that, say, Truck A might connect to someday, you can
add more anycast-rp lines to the config above for each of the other possible
RPs in the connected T2T system. Do note that the state synchronization
between all RPs is done via a tunneled unicast UDP/IP PIM Register packets and
hence can follow a unicast forwarding path out a non-PIM interface. So if a
truck is not present and there is a default route in the configuration be
careful that you aren’t inadvertently sending this UDP traffic into a
blackhole (perhaps a perimeter firewall).
arista.com
8
Deployment Guide
For those wishing to safeguard the above situation, you have many options. You
could comment out a particular truck RP config (ie. comment out the specific
truck anycast-rp config line) that’s not physically present and connected. You
could use a null0 static route that is summarizable or with a high
administrative cost per truck route back to its loopback address used above.
When another truck (in the AnyCastRP list) is physically present and
dynamically advertising its loopback addresses via an L3 routing protocol the
lower administrative distance route (from the dynamic routing protocol) will
prevail over an administrative distance of 255.
Note that any other (non-RP) switches in the truck will just need this rp
address 10.0.0.1 (which is the AnyCastIP address of the entire switch fabric)
config line and not need any of the anycast-rp config line(s). All routers
will take the shortest path to the closest AnyCastIP address and will land on
its own RP first, assuming its own RP is the point of egress to another truck.
There are certainly various strategies with RPs that one can consider such as
placement of RPs, number of RPs, using certain RPs for certain IP multicast
ranges, etc. Each design requires different requirements and the real
advantage of using a COTS product is the ability to be able to utilize these
open-standard based protocols in very flexible, extensible, and agile manners.
Conclusion These are just some of the considerations for the various event
production companies to consider when bringing together two or more SMPTE
ST2110 entities, whether it’s two or more OB trucks, two or more rolling racks
or flypacks, or trucks mated with rolling racks and flypacks. The approaches
can range from a purely “plug and play” open-standards dynamic environment
built on openstandard IETF & IEEE networking protocols to an SDN (Software
Defined Networking) approach.
A plug and play approach may be an acceptable approach where bandwidth,
control, and trust are guaranteed. If all trucks/rolling racks/flypacks are
owned and operated by the same entity, in many cases these three attributes
are implied. In the latter SDN approach you may consider Arista MCS (Media
Control Service) which provides for a robust, resilient, and agile software
integration between your broadcast control software and an Arista switch
fabric. For those customers requiring more overall workflow control, more
workflow & salvo performance, more bandwidth control, and specific
architecting of IP multicast flow pathing within arbitrary topologies, we
invite you to learn more about Arista MCS on our website.
If competing OB truck (or rolling rack/flypack) vendors must come together to
collaborate from a SMPTE ST2110 perspective for a live production, it’s
perfectly plausible (and already proven in large global sporting events in
2023) for all vendors to come together from an open-standards perspective
using standard networking protocols. These protocols can also allow for the
addition of policies and rulesets given that the aforementioned implicit trust
may not always be present – in much the same way as multiple ISPs come
together to share information and traffic flows. One can also build a hybrid
SMPTE ST2110 system using both SDN and non-SDN approaches together. See the
following link about bringing together both Arista MCS and non-MCS
environments.
The flexibility of a COTS, open-standards, open API switch fabric (like Arista
Networks) also allows for robust interfacing & peering needs with non-COTS and
proprietary legacy-inspired IP-based vendors, helping to give these non-COTS
vendors a seat at the SMPTE ST2110 interoperability table, especially in
larger multi-vendor multi-OB truck or cloud workflow environments. We will
take a look at this topic in a future paper in this series.
In addition, future series papers will dive a bit deeper into the IETF/IEEE
protocols mentioned earlier. We will also talk about the complementary network
to the SMPTE ST2110 network used to managed everything – the management (or
“out of band”) network for GUI access, web interface access, software/firmware
updates, Internet and VPN connectivity, logging, telemetry, and WiFi for the
local & remote VPN users.
Whatever your architectural approach will be, let’s not forget that the stakes
are high within live television production across many stakeholders. Uptime
and MTBF (Mean Time Between Failures) are two of many operational metrics
within the hardware electronics world that align with reliability and
stability. Bug counts and security vulnerabilities are just two of the many
operational metrics that are valued in the software world. Combined together,
all of these metrics can and will affect your business.
arista.com
9
Deployment Guide
Before you choose Arista Networks as your SMPTE ST2110 switch fabric know that
we prioritize product quality and stability within our own hardware & software
designs, as well as within our culture. This is reflected in our annual
analyst ratings as leaders in the Ethernet/IP switching infrastructure
business and also within our world-class Net Promoter Score (NPS) ratings. The
last thing that we want is for our Media & Entertainment customers to worry
about the Ethernet/IP switch fabric at the heart of their SMPTE ST2110
environment. In fact, our co-founder, Ken Duda, is so committed to your
success and Arista product quality that he hands out his personal cell phone
number to every customer that he meets asking them to call him directly if
there is ever a problem that seems insurmountable.
Santa Clara–Corporate Headquarters 5453 Great America Parkway, Santa Clara, CA
95054
Phone: +1-408-547-5500 Fax:
+1-408-538-8920 Email: info@arista.com
Ireland–International Headquarters 3130 Atlantic Avenue Westpark Business
Campus Shannon, Co. Clare Ireland
Vancouver–R&D Office 9200 Glenlyon Pkwy, Unit 300 Burnaby, British Columbia
Canada V5J 5J8
San Francisco–R&D and Sales Office 1390 Market Street, Suite 800 San
Francisco, CA 94102
India–R&D Office Global Tech Park, Tower A, 11th Floor Marathahalli Outer Ring
Road Devarabeesanahalli Village, Varthur Hobli Bangalore, India 560103
Singapore–APAC Administrative Office 9 Temasek Boulevard #29-01, Suntec Tower
Two Singapore 038989
Nashua–R&D Office 10 Tara Boulevard Nashua, NH 03062
arista.com
Copyright © 2024 Arista Networks, Inc. All rights reserved. CloudVision, and
EOS are registered trademarks and Arista Networks is a trademark of Arista
Networks, Inc. All other company names are trademarks of their respective
holders. Information in this document is subject to change without notice.
Certain features may not yet be available. Arista Networks, Inc. assumes no
responsibility for any errors that may appear in this document. April 8, 2024
10