Category: Software Gone Wild
Palo Alto Integration with Cisco ACI and OpenStack on Software Gone Wild
A while ago Christer Swartz explained how a Palo Alto firewall integrates with VMware NSX. In the meantime, Palo Alto announced integration with Cisco ACI and OpenStack, and it was time for another podcast with Christer deep-diving into the technical details of these integrations.
Spoiler: It’s not OpFlex. For more details, listen to Episode 53 of Software Gone Wild
x86-Based Switching at Ludicrous Speed on Software Gone Wild
Imagine you want to have an IPv6-only access network and transport residual IPv4 traffic tunneled across it. Sounds great, but you need to terminate those tunnels and encapsulate/decapsulate IPv4 traffic at multi-gigabit rate.
There are plenty of reassuringly-expensive hardware solutions that can do that, or you could work with really smart people and get software-based solution that can do 20 Gbps per CPU core.
Troubleshoot Your Network with PacketDesign on Software Gone Wild
Imagine you get a routing outage in your network resulting in three minutes of traffic blackholing. After a few tense minutes it goes away and life is good, but you desperately want to know what went wrong. Can you figure it out? Well, you could if you were using PacketDesign tools, as Cengiz Alaettinoglu explained on Episode 51 of Software Gone Wild.
VMware NSX Update on Software Gone Wild
A few months ago VMware launched NSX version 6.2, and I asked my friend Anthony Burke to tell us more about the new features. Not surprisingly, we quickly started talking about troubleshooting, routing problems, and finished with route-health-injection done with a Python script. The end result: Episode 50 of Software Gone Wild. Enjoy!
Docker Networking on Software Gone Wild
A year and a half ago, Docker networking couldn’t span multiple hosts and used NAT with port mapping to expose container-based services to the outside world.
Docker is the hottest Linux container solution these days. Want to know more about it? Matt Oswalt is running Introduction to Docker webinar in a few days.
In August 2014 a small startup decided to change all that. Docker bought them before they managed to get public, and the rest is history.
OpenSwitch Deep Dive on Software Gone Wild
A while ago I watched a Networking Field Day Extra video in which Chris Young and Michael Zayats talked about HP’s open source initiative – they decided to build yet another open networking operating system.
Obviously I wanted to know more, reached out to Chris, and we quickly managed to set up an online chat resulting in Episode 48 of Software Gone Wild podcast.
Running Open Daylight in Production Network on Software Gone Wild
Nick Buraglio used OpenDaylight and OpenFlow-enabled switches to build a part of the exhibition network of a large international supercomputing conference and was kind enough to talk about his real-life experience in Episode 47 of Software Gone Wild.
We covered:
CPLANE Networks on Software Gone Wild
When I wrote a blog post explaining the difference between centralized control and centralized control plane, John Casey, CEO of CPLANE Networks wrote a comment saying “yeah, that’s exactly what we’re doing.”
It took us a while to get the stars aligned, but finally we managed to sit down and chat about what they’re doing, resulting in Episode 46 of Software Gone Wild.
Fibbing: OSPF-Based Traffic Engineering with Laurent Vanbever
You might be familiar with the idea of using BGP as an SDN tool that pushes forwarding entries into routing and forwarding tables of individual devices, allowing you to build hop-by-hop path across the network (more details in Packet Pushers podcast with Petr Lapukhov).
Researchers from University of Louvain, ETH Zürich and Princeton figured out how to use OSPF to get the same job done and called their approach Fibbing. For more details, listen to Episode 45 of Software Gone Wild podcast with Laurent Vanbever (one of the authors), visit the project web site, or download the source code.
Test-Driven Network Development with Michael Kashin on Software Gone Wild
Imagine you’d design your network by documenting the desired traffic flow across the network under all failure conditions, and only then do a low-level design, create configurations, and deploy the network… while being able to use the desired traffic flows as a testing tool to verify that the network still behaves as expected, both in a test lab as well as in the live network.