The Azure Cloud Switch becomes open source.
Intel takes the stage to talk Altera and optics.

A friend of mine has just ordered a shiny new packet generator for his network lab. I’ve spent some time working as a QA engineer in a network lab and wanted to share some advice.
You can purchase stateful and stateless packet generators from major vendors like Spirent, IXIA or Agilent. If you just need to test throughput, latency or loss, a stateless packet generator will do the trick. The test hardware will use an ASIC to produce line-rate 10G traffic or higher. The Cisco Enterprise Testing Book calls this a ‘bit-blaster’ which I love. In the wrong hands it can also be a ‘network-melter’.
You need a stateful packet generator if you want to test your routing protocols in conjunction with traffic load. A stateful packet generator such as Ixia’s IxNetwork, will use dedicated CPUs to form and maintain adjacencies, inject routing protocol packets, etc. You can use the stateful feature to inject prefixes which are then used as test targets by high-rate stateless traffic.
Licensing is a major source of pain when operating a stateful packet generators. There are often licenses required per protocol and even per-combination of protocols. For example, I had to buy a license for Continue reading
A friend of mine has just ordered a shiny new packet generator for his network lab. I’ve spent some time working as a QA engineer in a network lab and wanted to share some advice. You can purchase stateful and … Continue reading
The post Getting started with Network Packet Generators appeared first on The Network Sherpa.
It took a 48V rack to bring Google into OCP.
The Infotrek podcast debuts with a discussion of infrastructure redundancy, including when it should and shouldn't be used, implementation challenges, redundancy testing, and more.
The post Infotrek Podcast Episode 1: Redundancy appeared first on Packet Pushers.
The Infotrek podcast debuts with a discussion of infrastructure redundancy, including when it should and shouldn't be used, implementation challenges, redundancy testing, and more.
The post Infotrek Podcast Episode 1: Redundancy appeared first on Packet Pushers.

In case you missed it, Ansible 2.0’s Windows support includes a number of improvements and new features that make automating Windows with Ansible easier. Because of Red Hat’s commitment to solid cross-platform management, you’ll also see an acceleration of these kinds of improvements in future Ansible releases. I’ll highlight a few of the items I’m most excited about from 2.0, and give a quick peek at what’s scheduled for future releases.
Update management is a common pain point for Windows administrators. The new win_updates module makes it easy to orchestrate updates during your maintenance windows- no more logging into individual machines to kick off updates or hoping a scheduled update pass actually ran!
2.0 shipped with a suite of modules for managing IIS. From configuring websites, AppPools, virtual directories, and more- now Ansible can deploy and manage your IIS apps with ease.
Since WinRM doesn’t have a built-in file transfer mechanism, Ansible has to jump through some “interesting” hoops to deploy its module code and copy files from the control host to a managed Windows box. Historically, this process was very slow, and could only transfer small Continue reading
Juniper contributes its networking, including SDN.
Takeaway: I was supposed to learn life lessons by participation in “sportsball” at school. Looking back, everything I learned was wrong for the modern era. So you played sportsball because the school education systems tells you that its good for your education. Sportsball is generic term for whatever team sport you played at school – […]
The post Playing Sportsball In High School Damaged My Team Skills appeared first on EtherealMind.
A new study sheds light on the state of OpenStack adoption in the enterprise.

The first post in this series is here.
Finally, let’s consider the first issue, the SPF run time. First, if you’ve been keeping track of the SPF run time in several locations throughout your network (you have been, right? Right?!? This should be a regular part of your documentation!), then you’ll know when there’s a big jump. But a big jump without a big change in some corresponding network design parameter (size of the network, etc.), isn’t a good reason to break up a flooding domain. Rather, it’s a good reason to go find out why the SPF run time changed, which means a good session of troubleshooting what’s probably an esoteric problem someplace.
Assume, however, that we’re not talking about a big jump. Rather, the SPF run time has been increasing over time, or you’re just looking at a particular network without any past history. My rule of thumb is to start really asking questions when the SPF run time gets to around 100ms. I don’t know where that number came from—it’s a “seat of the pants thing,” I suppose. Most networks today seem to run SPF in less than 10ms, though I’ve seen a few that Continue reading
Embracing containers, open source, and hybrid clouds all at once.