The Everything Feed - All Packet Pushers Pods

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).

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.

Hard things are fun, boring things means boring,

Taking ownership of open source to replace vendor requests

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.

Corvil's Intelligence Hub uses machine learning to extract both IT and business insights from network data.