I’ve been thinking about what to write on my first day of attendance at TFDx. I had so much going on in my tiny and inadequate brain that it’s really hard to put things on (digital) paper.
I’ll start saying that I’m thankful to the staff at GestaltIT for having had the opportunity of attending as a TFD delegate and meet the “best of breed” Network professionals.
The crew and I are having great fun talking about all sorts of weird (networking) stuff and always challenge each other with very nice problems to be solved.
This is what I was expecting and I’m very pleased about this.
Now, let me get onto the technical stuff. This event is sponsored and held at #CLEUR2018, so don’t expect me to talk anything but Cisco 🙂
Uh, before I go on, a disclaimer: this is a personal weblog. The opinions expressed here represent my own and may not represent those of my employer.
There was a lot going on about hybrid-cloud (rebranded as multi-cloud), with particular attention about how Cisco is trying to magically make the deployment of applications across different public-cloud providers an easy job, but especially a lot of focus on how to create a network overlay to connect the private cloud instance(s) to VPCs in the cloud using CSR1000Vs.
Now, I get the fact that having an IOS-XE router to play with is resuscitating our inner networking soul, but my gut feeling is that this is not a great idea, first and foremost because the basic problem it’s trying to solve (which is creating a networking overlay to connect workloads in multiple different environments – sounds like SD-WAN to me btw) can be already fixed with whatever tunneling technologies the Cloud Providers already provide.
I understand that with the 1000Vs you can get a lot of nice stuff and features on top of the IPSEC tunneling but still…would I pay for that? No.
Not to mention how inefficient that would be from a data-plane perspective where traffic would need to be hairpinned in and out of the 1000V VMs multiple times before it’s actually sent out. (see picture below)
Not efficient and not very cloud-native either.
Then we had a good session on umbrella + AMP for Endpoints, but honestly I’m not a security expert and my friend and TFDx peer Jasper (https://blog.packet-foo.com) will have more on that I am sure!
What caught my interest the most was two presentations at the end of the day on the Cisco Network Assurance Engine and Tetration.
Network assurance Engine
This is good. If I had to define it in a naïve way, this is Forward Networks or Veriflow with a different logo. (all based on formal-verification mathematical foundations)
The NAE collects state data from the network (any control-plane and forwarding-plane data-structure such as ARP Tables, MAC-address-tables, RIBs, FIBs, LFIBs, etc..) and builds a binary-decision tree model.
Now, under the assumption that whatever action a device takes when handling a packet is a deterministic transformation, the NAE can predict how packets flow into a complex system through the network (what Forward Networks does the same way – I understand).
This presentation was heavily washed with the word “intent“. The only intent I saw there was the “definition” of conditions that the tool verification mechanism needs to periodically check every time the network model is re-built. (similar to Forward).
Nice thing is that the tool give you some suggested steps on how to fix the issue (whether those make real sense I can’t really say, but if that works, that’s cool). Also cool is the capability to roll back in time to understand what happened at a certain point in time to a particular flow/device so that you can try and understand what went wrong and prevent it from happening in the future.
Also very useful their arc-styled diagram that shows visually “who can talk to who” (similar to the one you find in Tetration – see below), which helps identifying whether or not there are some non-intended paths across tenants who are not supposed to talk to one another.
I liked this a lot. Very non-Cisco-style. Presentation led by two very entertaining and captivating geeks (Tim Garner and Remi Philippe).
Tetration is a very powerful analytics tool that does a few things. #netflowreloaded
Tetration relies (sadly) on the use of proprietary (Cisco) ASICs to perform per-packet analytics on silicon and stream them every 100ms to a collector where the intelligence resides. (They also collect some more basic analytics directly on the hosts/tenants using a binary that does all the magic.)
They stream the data in a clever way as they don’t send metadata for each and every packet that traverses the silicon, but just the deltas between each packet and the following (reminds me of the old days when I was studying electrical communications 🙂
But, why doing that per-packet? They claim (and I sorta agree) that sometimes flows are so bursty that often times the sample rate is not high enough to capture transient issues.
Despite this intelligence, you can figure out pretty easily about one potential issue. The volume of data that those guys need to process and keep (the tool keeps also a history of the detailed-per-flow-per-packet analytics) is humongous. It’s real BIG data applied to network analytics. Fair enough. You can’t have good analysis with enough data. So, off we go.
(video from NFD16)
What I liked most about Tetration is their take on micro-segmentation. Their “zero-trust-model” allows for security policies to be tailored around the application and are applied on both ends of the communication.
The concept of workspace (the concept is not new, the name is, and this is very Cisco Style), adds another level of granularity where resources and applications are grouped by owner.
Owners can decide whether or not to “expose” a particular L4 endpoint to consumers outside its own workspace.
Perspective consumers then “request” access to that service via the Tetration GUI (or API). If the request is accepted Tetration goes on and applies the correct ACLs to the ACI fabric to make sure the communication does actually happen.
Now, you immediately realise what in my view is the weak point of Tetration. ACI.
I have the feeling that all the BUs in Cisco are officially asked to cling onto ACI, and desperately try to keep it alive.
My advice would be: try not to tie your future to ACI. This product can go very far, I think.
The second issue I think is that if they don’t find a way of doing this collection either on commodity ASICs (I asked about Barefoot/Cavium, and I got a “no comment” response which was quite encouraging) their market slice would be pretty limited in size. Also doing that right on the hosts leveraging the cores on SmartNICs would not be a bad idea.
The first day was really dense with content (and buzzwords) but I hope I captured some interesting points.
Overall, I kept reading and listening to this claim by Cisco that “there’s too many tools out there”, and that the landscape of Network OSS and assurance tools is too complicated.
Well, what can I say? In the short space of two days I heard about 3-4 different products (Tetration/NAE/DNA) whose features could be perfectly part of the same platform as they do quite similar things (albeit based on very different information sources).
So, bi-polar disorder or is it just me?
They sold us for years the story about the fact that with SDN we finally defy the lock-in (I wrote about this in Vendor lock-in effect and the SDN hype), but what I keep hearing is: “this works just with ACI”, “this requires the last generation of N9Ks”, “you need to use HyperFlex to do this”, and so on and so forth…
This sounds as lock-in 2.0 (perhaps even worse than its predecessor).
What do you think?