Tech Bytes

ThousandEyes presented at Network Field Day 17. The company started out monitoring the Internet “as a network” and has extended into monitoring the customer’s digital experience.

* ThousandEyes is moving from visibility into a more useful representation of the customer experience

* Internet visibility needs new tools for the networks that you don’t own when you use SD-WAN, hybrid cloud, SaaS, etc.

* User agents reporting to ThousandEyes improve troubleshooting

* The on-premises agent, which can be deployed on user machines or a server, gathers data from your private network and uploads it to ThousandEyes, which combines private and public network into a single view

* Product future: a) Routing anomalies such as BGP hijacks or leaks b) DDOS detection c) app outages

Fresh from a two-hour Network Field Day session at Juniper on its OpenContrail transition to the Linux Foundation, Greg and Drew do a hot take on what we saw and what it means.

We also quickly review Juniper’s ambitions for its commercial Contrail product.

* Moving OpenContrail to be fully open source is harder than it looks

* The move is customer driven (as we hinted previously)

* OpenContrail will diverge from Contrail

* Contrail wants to bridge your private and public clouds, with support for AWS, Google, etc.

* Juniper is building a network platform and moving past products

* Emphasizing security because you can control the network correctly

I had a briefing with netYCE on January 8, 2018. In this briefing, netYCE gave me an overview of their platform and shared some of the latest capabilities they’ve baked in. Listen to the audio in the embedded player above to hear what stuck out to me.

Who’s netYCE?

NetYCE is a maker of vendor agnostic network automation software. They play in the same space as Anuta Networks, Glue Networks, Tail-F and other big, grown up packages that hide messy, manual configuration from operators while preventing them from shooting themselves in the foot during complex network changes.

For More Information

Visit netyce.com. Note that netYCE has been selling to European markets and Asia primarily, but is planning to come to North America in 2018 once they have their support infrastructure in place.

CloudPassage talked with the Packet Pushers about Container Secure, a product announcement they made at AWS re:Invent earlier this year. Ethan Banks shares his impressions. Click to hear the audio recording in the player above.

What CloudPassage Discussed

Container Image Security is about protecting the container image registry or repository. Container Host Security is about protecting the host that containers are running on. Container Runtime Security is about securing the container when it’s in operation servicing client requests.

All of these features were added functionality to Halo, CloudPassage’s security platform.

The View From The Hot Aisle

The announcement of the Container Secure feature addition to the Halo platform is timely as more and more companies refactor their monolithic applications and redeploy them in container form factors, and possibly as microservices. This style of architecture blows up traditional operational processes, demanding new tools.

CloudPassage has been around for awhile working with their customers as they transition to cloud, and now they are going deeper down the rabbit hole as their customers work to get cloud right leveraging containers.

For More Information

https://www.cloudpassage.com/company/press-releases/container-secure/

Ethan Banks had a briefing with LightStep via cofounder Ben Sigelman on December 12th, 2017. Click in the player above hear the audio report.

Who’s LightStep?

LightStep is a performance monitoring software as a service company for cloud-native application architectures, although they will be happy to monitor your monolithic apps as well.

The system works via a local collector that observes transaction data, scrubs it for security reasons if required, and ships it to LightStep’s SaaS engine for analysis.

You can think of them in the APM space, although they describe themselves as “xPM.” From their website, xPM means, “APM reinvented to diagnose anything across all components of today’s software applications.”

Briefing Highlights

Unique performance profiles per customer. Build unique profiles tailored to each of your customer’s specific SLA requirements, giving you a “per customer” view of a complex infrastructure.

Break down transaction components into unsampled microsecond timeframes. LightStep highlights the anomalous records, bubbling them up to the surface so that they stand out.

Figure out what IS or perhaps what WAS going wrong as the application delivery infrastructure changes dynamically.

LightStep integrates with Kubernetes. For example, LightStep can make calls out to Kubernetes to find out information about the local environment.

LightStep ingests metadata from software processes today. Hardware telemetry will become a first-class citizen in the future.

The View From The Hot Aisle

My take is that LightStep is performance monitoring for the long-term. They have skated to where the puck is going, creating a system that excels in cloud-native application deployments, while still supporting those architectures that are transitioning from legacy into the future.

For More Information

http://lightstep.com

Quick Takeaways 

12.8 Tbps Line Rate L3 Ethernet Switch ASIC

* tailored to the needs of hyperscalers

* Tomahawk 3 is the world’s first 12.8Tbps switch chip, now sampling to customers, that will accelerate the next

* wave of 100GbE/400GbE hyperscale cloud build-out

* high port radix requires low latency,

* buffer architecture,

* instrumentation,

* 40% less power,

* 75% cheaper cost per 100Gpbs through the use of 50G PAM4 signalling

* Up to 256 x 50G-PAM4/25G-NRZ Dual-Mode Serde

Shrinks an OCP Backpack switch (which is basically 6 x 32 100 front facing switches with an internal spine) into a single switch. So what used 10 ASICs before, is now a single ASIC unit.

Architecture Notes

* architected for hyperscale – performance oriented, latency, L3/label switched fabrics, load balancing.

* But no reqt for programmable data plane.

* driven by Deep Learning / ML / AI

* Hyperscale DC market opportunity -growing

* NVMe over fabrics – the use of SSD in distributed storage means that network performance must be low latency

* Storage advances – NVMe over Ethernet

Compare Trident 3

* Trident 3 – has a programmable pipeline and lower latency but matters less.

* Tomahawk 3 at same power and cost but twice the bandwidth (but no programmability)

* Note that high radix, multi-hop Ethernet is their operation. HPC is building Slim Fly/DragonFly

* 16nm die process, gives an 18 month advantage (?)

Interpreting what this means

* focussing on low latency so its not a flexible architecture for overlays etc needing programmability. You likely won’t see this in the Enterprise (although Cisco could waste money building it into a spine only unit and claim its got magic inside)

* building nearly dedicated ASICs for cloud providers is a reflection of how much they are spending on data centres and the need to build products that are suited to their exact requirements.

* Broadcom has three ASIC families : Tomahawk is for speed and port density. Trident is for programmable features at medium density – ie data centres. Jericho is an ASIC targeting carrier grade needs such as routers.

* See Broadcom is the incumbent, it doesn’t have to be better than the competition. It needs to be good enough so that people don’t switch away (see MS Windows). With Marvell buying Cavium we are seeing consolidation in the ASIC market.

* The ASIC market is a scale up business, the larger volume you can manufacture the better your competitive advantage and that why Broadcom bought Brocade to scale up its Fibrechannel ASIC business and reduce costs.

* I don’t believe that Cisco can compete with Broadcom and the custom cloudscape chips on Nexus (which might be a slightly customised version of Marvell silicon)  doesn’t seem practical anymore when most people are focussed not he software defined parts and not on the hardware. In Enterprise, most people haven’t even gotten to 10G so a 32 port 400G silicon isn’t relevant.

* If you are in the Enterprise, this likely doesn’t matter since most of you don’t need more than 2 switches anyway. Having 2 switches with 32 x 400G ports with limited features but going very very makes no sense because you haven’t scaled out.

If you have the word “open” in your product then you must be open. The transition from ‘mine’ to ‘sharing a bit’ to ‘open’ seems to have been painful for Juniper. This isn’t leadership, this is being forced to move to open by customers.

…. announcing its intent to move the codebase for OpenContrail™, an open-source network virtualization platform for the cloud, to the Linux Foundation. Juniper first released its Juniper® Contrail® products as open sourced in 2013 and built a vibrant user and developer community around this project. Earlier this year, Juniper expanded the project’s governance, creating an even more open, community-led effort to strengthen the project for its next growth phase. Adding OpenContrail’s codebase to the Linux Foundation’s networking projects will further its objective to grow the use of open source platforms in cloud ecosystems.

Gregs View

* Putting your ‘open source’ project on a privately managed corporate system with a registration, approval and login is not open.

* Juniper seems to have struggled with being open for a number of years.

* But JunOS is built on top of open source (yeah yeah, different license) BSD Unix. How hard can it be ?

* Whats so hard about this ?

Thoughts: The struggle that established networking vendors have to embrace open source is difficult. Many open source projects are replacing  existing business & profits for all networking vendors and more recently the carriers & telcos are aggressively moving away from closed products in their networks.

Customers are moving there and now the vendors have to follow.

Juniper Networks – Juniper Networks Reinforces Longstanding Commitment to Open Source by Moving OpenContrail’s Codebase to the Linux Foundation : http://investor.juniper.net/investor-relations/press-releases/press-release-details/2017/Juniper-Networks-Reinforces-Longstanding-Commitment-to-Open-Source-by-Moving-OpenContrails-Codebase-to-the-Linux-Foundation/default.aspx

Juniper Networks has announced a trio of bots that aim to accelerate the adoption of automation in enterprise networks.

These bots, available in the first half of 2018, are lightweight applications that target common tasks such as BGP peering, configuration changes, and network health monitoring.

The bots are:

* Contrail PeerBot: Automates BGP peering tasks

* Contrail TestBot: Tests and validates pre-production network configuration changes

* AppFormix HealthBot: Monitors network and device health

Juniper plans to roll out more bots over time. While each bot can stand alone, the company intends for them to be used as part of an overall suite.

Customers who want to experiment with the bots ahead of their release can contact Juniper for beta testing.

For More Information

Juniper Networks Brings The Self-Driving Network(TM) Closer to Reality with New Juniper Bots – Juniper Networks

Barefoot Networks is big in the programmable networking space, known for their Tofino chip as well as the P4 programming language. In this briefing, Barefoot announced Barefoot Deep Insight, a network monitoring system they claim goes deep on every packet in the network. Listen to Ethan Banks’ take via the embedded player above.

Why Is This Interesting?

Analyzing every packet in the network is increasingly difficult as networks get both larger and faster. Network telemetry is a significant use case for Barefoot customers who want to know all the things, which led to Deep Insight being developed.

Deep Insight uses the P4 data plane plus in-band network telemetry (INT), providing line rate monitoring with nanosecond accuracy, because all of the data is coming right off the switching chip in real-time. Which chip? Tofino for now, but Barefoot reports that there are smart NIC vendors with INT coming, plus some interest in INT at the hypervisor edge in software switches.

Paired with the telemetry coming off of the INT data sources, Barefoot has created Deep Insight Analytic Software that performs real-time anomaly detection and ML based analytics, via a microservices-based architecture. The analytics software performance can be scaled out cheaply, running on commodity hardware. Most customers start with one server, and then add a few more servers as they increase the amount of data they wish to monitor.

Use Cases

The primary use case for Deep Insight’s ingestion of INT metadata was microburst detection to find out which flows are creating congestion, and which flows were victimized by the situation. With this tool, you can drill into microsecond level of detail to pinpoint a specific event, which you just can’t do with an SNMP poller.

Another use case was to identify in an NFV/SDN network stack where a latency spike was occurring. Was it a hardware switch? Software component? Etc.

Yet another application for Deep Insight is for the hottest marketing buzzword in the valley, Intent Based Networking. Analysis of INT could be a way to close the loop, verifying that a packet as it flowed through the network was indeed compliant with customer intent.

For More Information

* http://barefootnetworks.com

* Barefoot Networks Releases Per-Packet Network Monitoring Application – Packet Pushers

Cisco Tetration came out of the gate as a deep analytics and insights platform and is rapidly iterating on a variety of use cases. In this briefing, Cisco presented how Tetration can be used for network security. Ethan Banks discusses. Listen via the embedded audio player above.

* Automated microsegmentation was the chief use case cited in this briefing. Cisco described the problem of whitelisting flows between applications, making the point that it’s very difficult to know what the network flow dependency tree looks like between apps. For a human to get the whitelist right is nearly impossible. This is where Tetration steps in.

* Tetration builds a profile of every single endpoint on the network, feeds the profiles through a machine learning algorithm, and then groups endpoints together based on the granularity the customer desires.

* With the groups built, Tetration determines what ports should be opened between which groups. Cisco says that Tetration is going to get this right because it sees every single packet on the wire collected via endpoint agents, hardware sensors, and metadata gathered from network devices. Even short lived microflows will be analyzed, increasing the odds that the whitelist generated by Tetration is going to work correctly.

* For customers with variant seasonal traffic patterns, Tetration comes with an enormous amount of storage to be sure to capture flow patterns over several months, helping to insure that the whitelist generated is valid no matter what the season, although it would take a quarter or so to gather the data needed before deployment.

* Tetration policies can be deployed in a monitor-only mode, so that IT teams can observe what traffic would be dropped before placing the policy into production.

* Particularly risk averse customers have the option to be notified by Tetration when flows are denied by the whitelist, allowing them to add the denied flow to the permit side of the list. Customers can also write their own policies leveraging tag metadata or subnets to be merged in with Tetration’s machine learning generated policies, a nice feature to give Tetration hints about coming infrastructure changes.

* For folks imagining a complex set of five-tuple rules that has to be maintained by hand once Tetration has done its magic, Cisco stresses that Tetration is constantly refactoring the nitty-gritty rule sets as the IT infrastructure changes. Customers just manage intent-based policies that express in a higher level language about what should be allowed to talk to what. No fussy rules management is expected of ops teams, which is just as well since Tetration scales to 1 billion policy rules per Tetration cluster according to Cisco. I don’t know about you, but I don’t want to manage that by hand.

* For folks invested in security platforms other than Tetration, Cisco mentioned that the policies generated by Tetration are exportable, citing AWS, ACI, and even a nebulous “other vendors” as possible targets to import Tetration’s rulesets.

* Cisco also pointed out that Tetration works without caveat across several different workload platforms, including Azure, Google Cloud Platform, and AWS alongside of ACI in the data center. The point being that with the Tetration agent, any workload can be secured no matter where it is. With the press of a button, Cisco demonstrated global policy deployment. Upon accepting the “New host firewall rules will be inserted and any existing rules will be deleted on the relevant hosts,” warning, a policy was deployed to impacted endpoints.

* At the tail-end of the briefing, Cisco dropped the SaaS bomb, mentioning that Cisco Tetration Analytics as a service was coming soon, currently in testing with some select customers.

For more detailed information, watch…