Tech Bytes

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

I had a briefing with Ian Eyberg, CEO of NanoVMs today.

Who is NanoVMs?

NanoVMs makes software to help you create and deploy unikernels. In this briefing, Ian discussed with me the state of the unikernel ecosystem and how NanoVMs fits into things.

Quick context for you if you don’t know what a unikernel is. Quoting from unikernel.org, “Unikernels are specialised, single-address-space machine images constructed by using library operating systems. They are built by compiling high-level languages directly into specialised machine images that run directly on a hypervisor, such as Xen, or on bare metal.”

A big point with unikernels is that of security. Since unikernels are single process with a minimal attack surface, they aren’t interesting targets for hackers. A hacker can’t do anything with a unikernel, even if they were to find a vulnerability.

If that context didn’t help, search for datanauts + unikernels for several podcasts we’ve recorded on the subject.

Let’s jump back to the conversation I had with Ian.

One point Ian made was that unikernels, even though you haven’t been hearing much about them lately, are seeing a lot of interest and adoption. Unikernels are in production in shops both large and small, and there are several startups in the space.

That said, there are some barriers to unikernel adoption, the main one being that they are a challenge to work with if you come from a typical operations background. You gotta create the unikernel before you can deploy it, and making a unikernel isn’t like firing up apt-get and installing all the stuff you need into an base operating system until you get to a golden image.

Instead, unikernel creation requires working with source code and binaries, compiling everything required for the machine image to run. That’s a knowledge gap for many operators, as most of us aren’t really systems-level people. We work above that layer.

This is at the core of what NanoVMs helps with–handling that system level work that’s required to make a unikernel so that anyone could do it using their GUI.

Speaking of their GUI,

I did get a passing glance at it at VMworld in late August. Ian was there at the NanoVMs booth, and I did an on-the-spot interview with him for our YouTube channel, so Google Ian Eyberg and Packet Pushers if you want a distant look at the GUI through the lens of our camera.

In addition to helping you create unikernels,

NanoVMs helps you deploy them.

Maybe you’re equating unikernels with just a different sort of container, and thinking that you’d rather use Kubernetes for unikernel deployment than NanoVMs tooling. Ian pointed out to me that while unikernels have many parallels with containers, they are different beasts.

Kubernetes is very good at container orchestration, but not optimized for unikernel orchestration. You’d actually be incurring a needless performance penalty using K8s to deploy unikernels. So, sure…you COULD integrate NanoVMs with a Kubernetes environment, but Ian is pretty sure you don’t actually want to do that.

Furthermore, the unikernel orchestration process will vary depending on the unikernel use case. Unikernels are finding uses in IoT, embedded systems, NFV, edge computing, and cloud infrastructure. Those use cases differ dramatically, meaning a different sort of orchestrator might be appropriate in each. Kubernetes isn’t a fit everywhere.

Another issue I raised with Ian about the barriers to unikernel adoption ...

Mode briefed Ethan Banks about their cloud private network. Whoa! Thought Mode was an SD-WAN company? Not quite. Mode partners with several SD-WAN platforms so that it’s easy to stand up a tunnel from your SD-WAN forwarders to Mode’s private network. That makes Mode a network alternative to private MPLS that integrates with your SD-WAN fabric.

As a Mode customer, you can spin up and spin down virtual networks on the fly, optimizing each virtual network for whatever characteristics you find most important–jitter, latency, loss, etc. How does Mode enforce the SLA required to meet your goals? Math! Math that was sorted out at Cornell University and is brought to life as HALO, a link-state algorithm that reacts to changes in traffic flows across the network, flooding link state changes in 150ms.

The result is a dynamic, routed network that is optimized for your specific needs. Listen in the audio player above for Ethan’s impressions.

For More Information

* https://www.mode.net

* HALO: Hop-by-Hop Adaptive Link-State Optimal Routing (PDF, academic research paper)

Mode briefed Ethan Banks about their cloud private network. Whoa! Thought Mode was an SD-WAN company? Not quite. Mode partners with several SD-WAN platforms so that it’s easy to stand up a tunnel from your SD-WAN forwarders to Mode’s private network. That makes Mode a network alternative to private MPLS that integrates with your SD-WAN fabric.

As a Mode customer, you can spin up and spin down virtual networks on the fly, optimizing each virtual network for whatever characteristics you find most important–jitter, latency, loss, etc. How does Mode enforce the SLA required to meet your goals? Math! Math that was sorted out at Cornell University and is brought to life as HALO, a link-state algorithm that reacts to changes in traffic flows across the network, flooding link state changes in 150ms.

The result is a dynamic, routed network that is optimized for your specific needs. Listen in the audio player above for Ethan’s impressions.

For More Information

* https://www.mode.net

* HALO: Hop-by-Hop Adaptive Link-State Optimal Routing (PDF, academic research paper)

Agentless automation. This is key to why networking likes Ansible instead of similar products. Because just about all network devices cannot have network agents installed. (that is a feature of whitebox though)

I can’t sell you automation, it has to come from within. (kind of spiritual but true)

Anisible should be simple, its shouldn’t turn into something complex. At the same time people are doing unlikely things here,

Used for multiple systems – ie. works for Linux, Windows, as well firewalls, switches, appliances etc etc. Also used to manage SDN controllers.

Ansible has an enthusiastic community, with a lot participation. For open source projects this is important.

Ansible is not a programming language, its an automation language. Important differentiator. Its also not a SDN controller (implying that you are likely to have an SDN controller and Ansible can work that as a configuration destination, since Ansible is licensed per IP address (end node) – an SDN controller is not a single node for licensing, its still every device in the network

Ansible is geared towards team efforts – a playbook can bridge network/server/storage silos and bring them together. This is behind the fundamental intention of the product.

Automation changes the work of a network engineer to be better work by removing tedious work.

Ansible Network Engine

group of prepared playbooks that are widely used. They are packaged into a default distribution.

these are part of the supported solution in licensed product.

Loosely, what CVD is to Cisco products, Ansible Network Engine is a set of playbooks that are universal to most organisations.

the playbooks are opinionated through curation based on an understanding of what is widely used. Instead of everyone writing playbooks for configuration backups of well known devices, just ship them as part of a default set. Build them to a level of best practices,

bi-weekly recurring release cycle, ship early, ship often.

Nyansa is taking performance management and network assurance is relatively unknown sub-genre of network analytics. First generation analytics companies tend to focus on simpler things like visibility into applications, or replay, or reaction purposes. Many analytics products just focus on these limited functions but scale them up to something very large. As you scale up you can’t actually

They apply intelligence to the analysis. The early versions of the product were focussed on understanding performance in Wireless Networks. naturally this extended to Campus (they were catching the Campus trend early)

Today they extending their assurance functions in the WAN. Because they rely on synthetic testing via agents that you install around the network edge, they can be technology independent.

Why ? Lets say that you have a WAN in migration – legacy physical plus SD-WAN. And for some reason your vendor has decided that your first generation SD-WAN product needs to be replaced with a 2nd generation product.

Stop nodding your head over there Cisco IWAN customers.

Use Software Client Agent – running synthetic tests is is good idea. The challenge has always been getting the agent installed onto user nodes i.e. desktops,

Agents are necessary if you want to get deep detail, and accurately represent real traffic. Most analytics companies are using flow export, useful for working at scale but lacks granular data. Its difficult to accurately determine real application performance from a flow, (you aren’t seeing the TCP headers).

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.

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…

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 June 21, 2018, and here’s what’s happening.

I attended a technical webinar held by Arista Networks talking about their recently announced 7170 series multi-function programmable network switches. In this webinar, Arista explained what the new 7170 switch line was all about.

The Central Reason This Switch Exists Is Programmability

You can argue that all switches are programmable in some way or another, but what Arista is getting at is that the silicon is the programmable Tofino chipset from Barefoot Networks. Webinar speaker Martin Hull pointed out,

“What’s different about the Arista 7170 series based on the Barefoot Tofino chipset, is it’s the most flexible. It is a completely programmable packet processor.”

Why do you need a completely programmable packet processor? That’s a good question, and Arista answers that when you have a fully programmable packet switching platform, that device is more than just a switch. Now, it’s a switch that can be customized to handle at line rate a whole lot of features that were once the domain of smart NICs, x86 middleboxes, and single-purpose network appliances.

If you can reduce your dependency on specialized network hardware, you can simplify your network design as well as operations, potentially reduce licensing costs, and eliminate the bottlenecks that middleboxes sometimes create.

To that way of thinking, you should be able to replace a whole lot of network infrastructure with 7170s, and I’ve even heard it argued that the 7170 could be the last switch you’d ever need to buy. Arista said that they’d come alongside of customers who want custom network applications created for their companies on top of the 7170, as most shops will lack expertise in the P4 silicon programming language.

That’s a whole lot of value proposition and some big promises being made.

How Does The 7170 Deliver On These Bullet Points?

Speeds and feeds, for starters. There are 2 different switches in the 7170 line. The first is a 2U box with 64 ports of 100GbE that forward at full line rate for 12.8Tbps of performance, as high as 5 billion packets per second.

Port to port latency is sub-microsecond which maybe doesn’t knock your socks off, but remember first that this is a programmable pipeline, and second as Arista pointed out, there are ways to get the latency a little higher or lower depending on features in use. Power consumption is listed as typically less than 5 watts per 100G port. This 2U box is shipping now.

The second switch has the same numbers as the first, except that it’s a 32 port, 1RU box, with 6.4Tbps of throughput available sometime in Q3 of 2018, late July or early August Arista speculated.

Both switch are fixed configuration. They have have multiple fans and power supplies. Use cases for these switches include leaf or spine in your data center fabric.

Speeds and feeds are nice, but what about the guts? What can we do with this thing? Of course, the 7170 is programmable, so from one perspective it can be made to do any sort of fancy packet forwarding that you can dream up, and I know a few of you out there have peculiar dreams indeed. More than that, Arista touted…

Several Out Of The Box Features

I’ll hit some of them here.

Tunneling was one, where you can get 192K tunnels terminated on a 7170, while still managing to push as much as 5Bpps. Tunnel types include MPLSoGRE, MPLSoUDP, VXLAN, and even custom encapsulation types such as your very own unicorn flavor of VXLAN.

Application telemetry is another interesting out of the box featu…