EANTC 2020

Mar 31, 2020

Overview

At Arrcus, we fundamentally believe in creating a unique opportunity for our customers by enabling open integration, that is, the ability to choose any hardware system, any silicon, and the software for both switching and routing. We have achieved this with our focus on defining, promoting, and building agile, open and standards-based solutions for the Data Center (DC), Backbone, Edge, and beyond. This also entails a significant effort to ensure interoperability with third-party systems from

  • a software perspective (both the control plane and the forwarding plane)
  • a hardware perspective (silicon, platform, optics, market-leading testing tools such as Ixia)

The Arrcus team has been actively involved in defining multiple standards in the Internet Engineering Task Force (IETF) spanning several working groups – SPRING, BESS, IDR, LSVR, OSPF, SIDROPS and GROW, to name a few. In addition, we have active participation in and contributions to the OpenConfig Working Group and the NetDev community.

Large and small operators routinely introduce new vendors and new technologies that are often bleeding edge into their networks. While they want to leverage the numerous benefits of multi-vendor networks, they must ensure that any technology supported by these vendors is fully interoperable. Arrcus’ participation in the EANTC 2020 multi-vendor interoperability testing underlines our unwavering commitment to our customers and the industry as a whole to deliver standards-based, interoperable solutions. EANTC 2020 marked the first year of our participation in this hot-staging event held in Berlin, Germany. Over the course of two weeks of testing across 10 different vendors with multiple products, Arrcus successfully demonstrated interoperability across a wide array of latest standards and technologies including SRv6, EVPN, MPLS Segment Routing, NETCONF/ YANG, etc. We are thankful to and supportive of 3rd party vendor-neutral test centers like European Advanced Networking Test Center (EANTC) for hosting public multi-vendor interoperability tests.

Arrcus Participating Devices

At this year’s event, we showcased both switching and routing, as well as the automation capabilities of the Arrcus operating system (ArcOS). We used Quanta’s IX8A Trident 3 switching platform and the Quanta IXAE Jericho 2 routing platform. This is a great example of executing with a single operating system solution and of our open integration capabilities for these diverse use cases with the leading generation of silicon and hardware platform(s) from our ecosystem partners (Broadcom and QCT respectively).

In addition, Arrcus was the only vendor to participate in a wide range of test cases with ArcRR, our Route Reflector product, running as a Docker container implementing various BGP AFI/SAFIs and interoperating with a wide array of vendor products and software stacks.

Here is a brief description of the devices and products used in the interoperability testing and pointers to the related collateral:

Device / ProductDescriptionSolution Pointers
ArcOS on QuantaMesh T4048-IX8A

 

ArcOS – Modern, microservices-based, open network operating system designed for performance, scale (scale-up and scale-out), and security across switching and routing environments

HW Platform – 1RU 48x25G + 8x100G ethernet switch with Broadcom Trident 3 packet processor

ArcOS®: Delivering Greater Business Agility and Operational Flexibility with Composable Network Software

ArcOS®: Building Scalable, Automated, Multi-Tenant Data Center Fabrics

EVPN Solution brief

ArcOS on QuantaMesh T7040-IXAE

 

ArcOS – Modern, microservices-based, open network operating system designed for performance, scale (scale-up and scale-out), and security across switching and routing environments

HW platform – 1RU 40x100G router with Broadcom Jericho 2 packet processor

ArcOS: Enabling the open integration era for routing

Why Building a Routing Software from First Principles Matters

ArcRR

 

Carrier-grade, scale-out route reflector with industry-leading performance and convergence timesArcRR At-A-Glance

The Changing Role of Route Reflectors in the Modern Internet

 

Arrcus Summary of Test Cases

Let us take a look at the highlights from each of the test case categories spanning DC and WAN topologies that Arrcus participated in.

EVPN VxLAN

Arrcus featured ArcOS running on the QuantaMesh T4048-IX8A devices for all EVPN VxLAN interoperability testing. Highlights from EVPN testing:

  • ArcOS devices featured in both the leaf and spine layers of the EVPN IP Clos topology
  • Arrcus completed full range of symmetric IRB test cases for distributed routing with EVPN VxLAN
  • ArcOS devices also participated as single-homed Provider Edge (PE) node in auxiliary EVPN feature testing such as MAC mobility and a new draft in BESS covering Proxy MAC/IP advertisements
  • ArcOS was able to interoperate with both single-homed and multi-homed remote PE nodes in EVPN tests across wide range of vendors such as Cisco, Juniper, Arista, Nokia, Huawei
  • ArcRR was also deployed in all the EVPN tests, acting as a route reflector for all leaf nodes, including reflecting route types 6, 7, and 8 in the IGMP proxy test case in addition to the route types 1 though 5 used in the other EVPN test cases.

Checkout the demo video for multi-vendor interoperability showcasing EVPN MAC mobility.

SDN: NETCONF/YANG for Automation

Automated processes accelerate and streamline network provisioning, operations, and deployment. ArcOS has built-in, native YANG/OpenConfig support to simplify integration into existing frameworks that customers may use, enhancing operational velocity. ArcOS provides full feature parity to all APIs allowing for a rapid and smooth plugin to various open source tools and custom-made frameworks alike. ArcOS model-based approach was on display during the NETCONF portion of the SDN testing at the EANTC hot-staging event.

  • Cisco NSO (Tail-F) successfully provisioned a single feature as well as multiple features in a single transaction on Arrcus nodes. Transaction rollback was also verified
  • Both operational state and configuration changes were able to be read/changed over NETCONF, including full services like EVPN over a VxLAN data plane

SRv6

Arrcus is committed to delivering cutting-edge solutions such as SRv6 in ArcOS with open integration on routing platforms based on latest generation merchant silicon including and not limited to Broadcom’s Jericho 2. As edge computing and 5G technologies drive the need for more native IPv6 network deployments, operators are looking to optimize and simplify use cases around Traffic Engineering and Service Chaining. SRv6 provides the ability to realize these use cases by eliminating layers of signaling and routing protocols with a unified IPv6 transport.

We kicked off our SRv6 journey earlier this year, by demonstrating SRv6 uSID data path capability on Jericho 2 at NANOG 78. Here is the pointer to the demo video and slide presentation.

At EANTC, we executed on the next steps, delivering control plane and data plane interoperability for SRv6. Highlights from SRv6 interop testing:

  • ArcOS support for ISIS SRv6 extensions
  • ArcOS support for End SID SRv6 function along with PSP (Penultimate Segment Pop) on Jericho 2
  • ArcOS acts as a PQ (repair) node in SRv6 TI-LFA and performs SRv6 End SID PSP function
  • ArcOS acts as a TE node and steers packets into SRv6-TE tunnels by performing SRv6 End SID function

For the first time at EANTC, we showcased advanced SRv6 functionality with SRv6-TE and SRv6 TI-LFA, with Arrcus devices providing critical TE functionality in both these cases. Checkout the demo video for multi-vendor SRv6-TE and TI-LFA interoperability.

ArcRR

ArcRR was the deployed route reflector interoperating with all participating vendor PE nodes, reflecting BGP overlay routes required across many test cases [AFI/SAFI’s: IPv4 Unicast, VPNv4, BGP LU/SR, IPv6 Unicast, 6vPE, EVPN (RouteType 1 8)].

More importantly, the same ArcRR image was integrated into all transport domains, namely VxLAN, MPLS LDP, SR MPLS and SRv6 transports.

Key takeaways from the EANTC interop testing of ArcRR:

  • ArcRR in EVPN VxLAN testing – EVPN route-types 1 through 8 were advertised
  • ArcRR reflected BGP EVPN routes for all-active, E-TREE, VPWS, Unicast and Multicast tests, and BGP L3VPN (IPv4 and IPv6) routes to all PE’s in MPLS topologies (LDP, ISIS SR, OSPF SR)
  • ArcRR was integrated into the SRv6 overlay, reflecting BGP L3VPN (AFI 1, SAFI 128) overlay routes to PE’s, in this case with an IPv6 next hop

Throughout the testing, ArcRR was deployed using EANTC’s compute resources, running as a Docker container on this 3rd-party environment. This highlights the flexibility this ArcRR deployment model affords, and the ease with which the ArcRR product can be integrated into any environment.

BGP Segment Routing/Labeled Unicast MPLS

ArcOS also supports segment routing using the MPLS data plane and in these tests, we demonstrated MPLS SR using BGP Labeled Unicast/Segment Routing as the control plane. ArcOS supports BGP-SR/LU on both the Quanta IX8A Trident 3 and the Quanta IXAE Jericho 2-based hardware platforms to provide customers the flexibility to enable MPLS SR in DC or WAN use cases.

Some key takeaways from the interop tests:

  • ArcOS delivered the role of Spine/RR helping create an SR MPLS fabric
  • ArcOS generated BGP SR routes and acted as a RR to reflect the BGP SR routes generated by leafs
  • ArcOS created MPLS forwarding tables based on downstream, upstream, and local BGP SR routes

Checkout this Egress Peer Engineering (EPE) demo video highlighting MPLS SR capabilities.

BGP Flowspec

While BGP Flowspec is traditionally deployed as a key security feature (DDOS protection) for edge routing, it is also used by some customers in the DC for dynamic ACL distribution via centralized policy controller. ArcOS supports BGP Flowspec on various Broadcom XGS-based and DNX-based hardware platforms for applicability across both DC and WAN use cases. ArcOS supports BGP Flowspec for both IPv4 & IPv6 data planes and also provides flexibility in terms of using either IPv4 or IPv6 BGP transport between the controller and the Flowspec node.

In the EANTC interop testing, ArcOS device acted as a BGP Flowspec node and filtered IPv6 traffic based on (one or more of), Layer3 header such as destination address, Layer4 header such as UDP port number, QoS information such as DSCP.

For more details on all the test cases and results, please checkout the Multi-vendor Interoperability Test Whitepaper from EANTC.

Summary

At Arrcus, our goal as a modern OEM is to continue to provide

  • best-in-class open, standards-based software solutions
  • a flexible consumption model and
  • the lowest total cost of ownership for our customers

Visit us at https://www.arrcus.com to learn more about our solutions and how we can help address your network transformation needs.