The Fat Pipe - All Packet Pushers Pods

Today's Weekly Show episode brings a real-world perspective to disaggregation and whitebox with an engineer who's brought open networking into production. Our guests are Andrey Khomyakov and Pete Lumbis.

Cloud First Networking – the challenge of networking in multiple clouds is substantial 

How can we make on-prem look like the public cloud. 

Don’t make AWS look like a on-prem network, make an off-prem network look like an on-prem network. Instead of configuring VRFs and VLANs, we should be configuring the public cloud equivalent of VPCs. AWS is a logical network 

I’ve said multiple times that supporting multi-cloud is a major challenge for Enterprise IT staff but I’ve never considered changing the basic unit of networking. Today we use IP subnets and VLANs as the basic unit of a network configuration but public clouds use a virtual unit. Can we adapt the virtual unit for the 

Federated SDN Controllers

you can have dozens of SDN controllers all unified into a single system regardless of off-prep and on-prem. 

Big Mon Fabric

* the ability to get visibility via flow data or packet capture. 

* presenting a single operational model for the visibility fabric regardless of cloud type. 

* packer recorder 

* smart replay – the network time machine, can i recreate the security incident through packet capture. 

* its possible that Big Switch is more efficient, more perfromant, because they have large numbers of customers. 

Big Mon Analytics

We have seen a substantial boom in analytics over the last two years, its not slowing down. SDN platforms have analytics as an add on product, and its built in as a fabric. 

Every visibility solution relies on data source, data collection and data analysis. 

* Mostly this means working on generating xFlow via network taps/agents in the OS/in line proxy. 

* Then you have to transport and store the flow records. 

* then you need to turn data into useful information via analytics. 

For big switch, perhaps the unique thing here is integration between the visibility fabric, and analytics. Analytics products are only as good as their data sources and often these are limited by the network they operate in. Big Mon lets capture data from a wider range of sources and, for me, demonstrates 

 

Edgecore

* Edgecore is a wholly owned subsidiary of Accton

* Producing increasing diversity of network equipment, the range of possible applications of Broadcom silicon. 

* Includes a optical solution 

* the choice to focus on SP is interesting, does this imply that 

* All of these products run IPinfusion software. 

Broadcom

* Talking about the breadth of their portfolio 

* There are market segments that have adopted merchant silicon namely the data centre while there are other market staying with black box. 

* the variety of ASICs is somewhat bewildering 

* eg. Trident 3 has five basic package offering

* jericho 2 has many options including the ability to interface to high speed memory to increase TCAM capacity

* Features in the ASIC have to be supported by the NOS

* NOS may emphasise some features over others and could create a diversity of solutions i.e. all NOSs are not equal

Why This Matters

* The open optical movement coming from the Telecom Infrastructure Project is targeted at two markets – telcos and DCI

* big market in data centre owners to have large amounts of bandwidth between data centres. 

* talking about up to 1.6Tbps in increments of 100G is possible. 

I broadly consider Gluware an automation engine that can deliver effective automation inside an brownfield network. That is, its multi-vendor, multi-technology (e.g. switches / firewalls, routers, QOS,) and works with the existing tooling such as CLI.

So you don’t have to buy new hardware to start the SDN process. Thats a useful way to start the transition when you can’t change the underlying systems. You could argue that modernising would get you further but I generally think that Gluware can get you what you need.

Its conceptually possible to use Python and Ansible do build something like this but the unique engine in the core is valuable, more importantly you don’t have to maintain that engine.

Python Problems

Skill gap

Platform maintenance

Integration of platforms

GUI, DB, versioning, admin and more,

Constant Resource Reset

Do you really want to do these things ?

Today they are demonstrating how model-driven multi-vendor automation.

Previous demonstrations of Gluware focussed on use cases of the era – QOS, Routing.

Today we are seeing demos around firmware/NOS updates and reducing that pain including aspects like image management (ie. only use images that you have approved or tested)

Configuration normalisation is interesting – most networks that are CLI managed have drift in various area – e.g. SNMP configuration works on all the devices but there are slight differences between them. Now some devices will have different SNMP configuration but may also have extra SNMP strings or enabled features. Gluware can model the right configuration between different devices (like software / hardware) and homogenise the configuration.

This point was further emphasised Qos configuration and then again with Campus using NAC. The campus is back baby.

The key part of the Campus demo was getting the dot1x template to apply to ports as needed. By deploying Gluware can being the automation process by building on the base models provided by Gluware, then defining the CLI that you want (that effectively a policy) and then having Gluware  to push that policy across large numbers of devices, which is in the campus.

If you run a helpdesk style operation, a tier 2/3 engineer can build the models and script verification, then handover the actuation to tier 1 for work inside a controlled change environment.

You’ve got your traditional on-premises network. You know how it works. Lots of manual configuration and ticket-y stuff to get the job done when someone needs something.

And then you’ve got your cloud network. You don’t worry about that one as much. The devs provision what they need automatically, hitting APIs as they go, and you keep tabs on things from a watchful distance, helping out as needed.

What if you could operate your on-premises network like you do your public cloud network? What if your hybrid cloud was operationally consistent? Today on the Datanauts, sponsor Big Switch Networks makes some pretty big hybrid cloud networking announcements, and we quiz them on the why and how.

Our guest is Kyle Forster, founder of Big Switch.

We talk about Big Switch’s new products, including the ability to create an on-premises VPC within Big Switch’s data center fabric. The goal is to provide the same operational constructs within your own data center as you’d get in a public cloud like AWS, Azure, or Google.

Show Links:

Big Switch Networks

Big Switch Labs

Multi-Cloud Director Tech Demo

Big Cloud Fabric-Public Cloud Tech Demo

Big Switch Networks on Twitter

Big Switch Networks on LinkedIn

Kyle Forster on LinkedIn

Big Switch is hiring. Check out opportunities here.

The following is a transcript of the audio recording you can listen to in the player above.

Welcome to Briefings In Brief, an audio digest of IT news and information from the Packet Pushers, including vendor briefings, industry research, and commentary.

I’m Ethan Banks, it’s July 16, 2018, and here’s what’s happening. I had a briefing with Arrcus late last week.

Who’s Arrcus?

Arrcus is a startup that’s built a modern network operating system for the disaggregated networking market. They are running on $15M of Series A funding, and as of today, they have emerged from stealth. In this briefing, Arrcus shared some of the details behind ArcOS, their core product offering. First off…

Why Arrcus And ArcOS?

Doesn’t the world have enough network operating systems, especially when you consider the open networking world? My impression of Arrcus is that they are not competing with the average open source networking solution. Instead, they see Cisco, Juniper, and Arista as their chief competition. Arrcus doesn’t want to be viewed as a commercialized open source NOS, because they aren’t. Arrcus built ArcOS from the ground up to work at the very highest levels of scalability, giving them a software platform to go after the established vendors with. There you go – why Arrcus exists.

Notice I didn’t say that Arrcus is making switches and bundling their NOS with it. And they aren’t. ArcOS is a disaggregation play, meaning you can mix and match switching hardware of your choice with ArcOS running on top. If you follow the disaggregated space, you’ll know that porting a NOS to this whitebox or that Ethernet chipset is not easy to do. Open & commercial disaggregated network operating systems have hardware compatibility lists for this reason. Therefore…

What Hardware Can You Run Arrcus’ ArcOS On?

According to Arrcus, just about anything. In fact, they made it clear in the briefing that they will run on loads of chipsets from Broadcom, Barefoot, Cavium, Innovium, Mellanox, and Nephos. They went so far as to say that ArcOS is the first OS to run on a couple of shiny new emerging chipsets from Broadcom.

How has ArcOS been ported to so many whitebox platforms while so many other disaggregated network operating systems struggle in this area? Arrcus answers that there’s magic in something they call DPAL, or dataplane adaptation layer. The way in which they wrote their DPAL gives them the ability to, with minimal engineering effort, bring new chipsets on board. So we know you can run ArcOS on a wide variety of hardware. Sounds great.

But What Is ArcOS All About As Network Operating System Software?

One feature of ArcOS that came up repeatedly is scalability. ArcOS is a “built from the ground up,” “clean-slate” product, and it was written to handle, among other things, massive ingestion of routes. One example cited brought in the entire Internet routing table and converged a total of 5M paths in 30 seconds. Another example was of bringing in 18M routes and settling in 3 minutes. So ArcOS scales big, and scales across cores for performance.

Architecturally, ArcOS has a run anywhere form factor. It can be deployed a VM or container, and of course on bare metal. And the platform is based on microservices, although we didn’t have a chance to get into any detail on that point. Microservices does underscore Arrcus’ point about per-module restartability, however. Feels like a modern style OS to me.

What about routing protocol daemons? Here again, Arrcus built their own from the ground up. For instance, they could have used Quagga or Free Range Routing open source code as a starting point, but for the way they wanted their daemons to run, it didn’t make sense to start with open source code. Instead, they built their protocol implementations from scratch.

Another key…

Russ White returns to the podcast to discuss the pros and cons of information hiding in the control plane.

Today on the Packet Pushers Priority Queue, we get nerdy about disaggregation, where you mix and match software from one vendor and hardware from another.

Our sponsor today is Cisco, and if you just did a double-take, that’s right, Cisco wants to talk to you about disaggregation, but there’s more to it than just hardware/software separation.

Joining us are Bhavna Prasad, Product Manager at Cisco; and Akshat Sharma, Technical Marketing Engineer for Cisco’s Service Provider BU.

We discuss the different kinds or degrees of disaggregation, and then drill into specifics around IOS-XR.

We also look at the programmatic capabilities and interfaces of IOS-XR, what hardware it’s available on, use cases, and more.

Show Links:

@XRDOCS – Cisco Systems

XRDOCS on Twitter

Akshat Sharma on Twitter

On today's IPv6 Buzz, we chat with Stephan Lagerholm of T-Mobile to learn about the uptake of IPv6 in mobile networks and why 464XLAT is a critical translation mechanism for mobile IPv6.

“Cloud native applications are designed to be managed by software in all stages. This includes ongoing health checks as well as initial deployments. Human bottlenecks should be eliminated as much as possible in the technology, processes, and policies.”

That quote is from the O’Reilly book Cloud Native Infrastructure. On today’s Datanauts episode, we talk to Justin Garrison, one of the authors and a senior systems engineer.

We dive into the chapter about managing cloud native applications, including a general conversation about the definition of a cloud-native app–that is, an application managed by software rather than humans.

Then we discuss the challenges of managing a microservices architecture, explore the concept of sidecar proxies, and walk through the process of deploying a new cloud application into production.

We also look at troubleshooting tools and techniques, and examine the necessity of service discovery and resource scheduling.

Sponsor: Linux Academy

Linux Academy offers the most hands-on training content in AWS, Azure, OpenStack, Linux, DevOps, Containers, security, and Google Cloud. Beginners and advanced learners alike will find up-to-date courses in skills development and certification prep. Hands-on labs let you work in actual cloud environments. Find out about the newest courses available online–including free courses–here.

Show Links:

Cloud Native Infrastructure – O’Reilly

Justin Garrison on Twitter