Archive

Category Archives for "Networking"

Some Market Thoughts on the Broadcom SDKLT

Broadcom, to much fanfare, has announced a new open source API that can be used to program and manage their Tomahawk set of chips. As a general refresher, the Tomahawk chip series is the small buffer, moderate forwarding table size hardware network switching platform on which a wide array of 1RU (and some chassis) routers (often called switches, but this is just a bad habit of the networking world) used in large scale data centers. In fact, I cannot think of a single large scale data center operating today that does not somehow involve some version of the Tomahawk chip set.

What does this all mean? While I will probably end up running a number of posts on SDKLT over time, I want to start with just some general observations about the meaning of this move on the part of Broadcom for the overall network engineering world.

This is a strong validation of a bifurcation in the market between disaggregation and hyperconvergence in the networking world. Back when the CCDE was designed and developed, there was a strong sense among the folks working on the certification that design and operations were splitting. This trend is still ongoing, probably ultimately resulting Continue reading

IDG Contributor Network: Mean time to innocence – using AI to uncover the truth behind perceived WiFi issues

Mean Time to Repair (MTTR) is a common term in IT that represents the average time required to repair a failed component or device. In networking, MTTR is often longer than desired because there are many interdependencies, whereby an issue in one part of the network may cause a problem much farther downstream. Furthermore, a configuration change might appear to create a new issue, when in fact it just exposed something that was there all along but hidden. It takes quite a bit of forensics to get to the root cause of a network problem. In the meantime (pun intended), there is plenty of blame to go around. The Wi-Fi network seems to be at the top of the list when the accusations fly – more so than any other section of the network. Why is that?To read this article in full, please click here

IDG Contributor Network: Mean time to innocence – using AI to uncover the truth behind perceived WiFi issues

Mean Time to Repair (MTTR) is a common term in IT that represents the average time required to repair a failed component or device. In networking, MTTR is often longer than desired because there are many interdependencies, whereby an issue in one part of the network may cause a problem much farther downstream. Furthermore, a configuration change might appear to create a new issue, when in fact it just exposed something that was there all along but hidden. It takes quite a bit of forensics to get to the root cause of a network problem. In the meantime (pun intended), there is plenty of blame to go around. The Wi-Fi network seems to be at the top of the list when the accusations fly – more so than any other section of the network. Why is that?To read this article in full, please click here

Machine Learning and Network Traffic Management

A while ago Russ White (answering a reader question) mentioned some areas where we might find machine learning useful in networking:

If we are talking about the overlay, or traffic engineering, or even quality of service, I think we will see a rising trend towards using machine learning in network environments to help solve those problems. I am not convinced machine learning can solve these problems, in the sense of leaving humans out of the loop, but humans could set the parameters up, let the neural network learn the flows, and then let the machine adjust things over time. I tend to think this kind of work will be pretty narrow for a long time to come.

Guess what: as fancy as it sounds, we don’t need machine learning to solve those problems.

Read more ...

Intentional Infrastructure

I gave a presentation at the recent Network Field Day 17 (on my 3rd day working for Juniper). My main goal for this presentation was just to get people excited about building stuff.

We tend to focus on vendor-provided solutions in this industry, and there’s a lot of good reasons for that, but it’s also good to stay sharp and be able to build your own solution to fill gaps where necessary. One reason I joined Juniper is that much of what we offer is built on a highly programmable foundation. So you get the best of both worlds - high-level products to solve the hard problems, but you still have the ability to insert your own custom tooling at various points in the stack.

In the above video, I outlined a simple Github-available demo for applying policies to a vSRX based on the existing services running in Kubernetes, and then verifying those policies are actually working by again using Kubernetes to determine what applications should be available.

My demo is designed to be self-sufficient, meaning you should be able to follow the README and get a working demo. Feel free to watch the above video first for context, then Continue reading

Intentional Infrastructure

I gave a presentation at the recent Network Field Day 17 (on my 3rd day working for Juniper). My main goal for this presentation was just to get people excited about building stuff.

We tend to focus on vendor-provided solutions in this industry, and there’s a lot of good reasons for that, but it’s also good to stay sharp and be able to build your own solution to fill gaps where necessary. One reason I joined Juniper is that much of what we offer is built on a highly programmable foundation. So you get the best of both worlds - high-level products to solve the hard problems, but you still have the ability to insert your own custom tooling at various points in the stack.

In the above video, I outlined a simple Github-available demo for applying policies to a vSRX based on the existing services running in Kubernetes, and then verifying those policies are actually working by again using Kubernetes to determine what applications should be available.

My demo is designed to be self-sufficient, meaning you should be able to follow the README and get a working demo. Feel free to watch the above video first for context, then Continue reading

Intentional Infrastructure

I gave a presentation at the recent Network Field Day 17 (on my 3rd day working for Juniper). My main goal for this presentation was just to get people excited about building stuff. We tend to focus on vendor-provided solutions in this industry, and there’s a lot of good reasons for that, but it’s also good to stay sharp and be able to build your own solution to fill gaps where necessary.

77 Facts About Cyber Crimes One Should Know In 2018

I am pleased to publish an infographic called "77 Facts About Cyber Crimes One Should Know In 2018." The infographic includes the top 10 biggest data breaches of the 21st century, top cyber crimes, stats of cyber attacks, fun facts and a ton more interesting info.

 I am glad to thank BestVPNs for kind permission to republish the original article on my blog.

Note: Click image to enlarge.

1 … 1,456 1,457 1,458 1,459 1,460 … 3,423