The stars have finally aligned, and after months of scheduling Jason and myself found time to chat about network automation tools and all the other exciting things Jason is doing (and blogging about).

We started with easy topics:

Every now and then I get an email from a subscriber having video download problems. Most of the time the problem auto-magically disappears (and there’s no indication of packet loss or ridiculous latency in traceroute printout), but a few days ago Henry Moats managed to consistently reproduce the problem and sent me exactly what I needed: a pcap file.

TL&DR summary: you have to know a lot about application-level protocols, application servers and operating systems to troubleshoot networking problems.

After covering the basics of MPLS, my discussion with Seamus Gilchrist turned to the basics of MPLS Traffic Engineering.

The video of that discussion is available in the MPLS Essentials webinar.

During one of my ExpertExpress engagements I got an interesting question: “could we replace a pair of central firewalls with iptables on the Linux server?”

Short answer: Maybe (depending on your security policy), but I’d still love to see some baseline scrubbing before the traffic hits the server – after all, if someone pwns your server, he’ll quickly turn off iptables.

During the last round of polishing of my Designing Infrastructure for Private Clouds Interop New York session (also available in webinar format) I wondered whether one could use the recently-launched UCS Mini to build my sample private cloud.

I love reading blog posts on Plexxi blog (you SHOULD add them to your RSS reader) and the “It’s the Application, Stupid” series from Mat Matthews is no exception. What pleasantly surprised me was that a large enterprise came to the same conclusions I’m preaching for the last few years.

I hope you know TCP provides a reliable stream service not reliable packet delivery, but you might not have realized all the implications – I found an old post by Robert Graham explaining how things really work and how you can use them to bypass quick-and-dirty IDS that rely on signatures instead of doing proper protocol decodes.

Jeremy Schulman was the driving force behind the Puppet agent that Juniper implemented on some Junos switches (one of the first fully supported Puppet-on-a-switch implementations). In the meantime, he quit Juniper and started his own company focused on a network automation product – more than enough reasons to chat with him on Software Gone Wild.

I’m running or participating in five workshops or sessions during next week’s Interop New York. Three of them build on each other, so you might want to attend all of them in sequence:

Designing Infrastructure for Private Clouds starts with requirements gathering phase and focuses on physical infrastructure design decisions covering compute, storage, physical and virtual networking, and network services. If you plan to build a private (or a reasonable small public) cloud, start here.

In the first part of the Network Programmability webinar Matt Oswalt described some of the major challenges most networks are facing today:

• Why is everyone claiming that the network is so slow to change?
• Is that really the case? Why?
• Why is the manual configuration culture so widespread in networking?
• How does the holistic thinking in the design phase dissolve into the box mentality of CLI commands?
• How does the box mentality limit the scalability of network deployments?

Stefan de Kooter (@sdktr) sent me a follow-up question to my Going All Virtual with Virtual WAN Edge Routers blog post:

How would one interface with external Internet in this scenario? I totally get the virtual network assets mantra, but even a virtual BGP router would need to get a physical interconnect one way or another.

As always, there are plenty of solutions depending on your security needs.

Are you lucky enough to be one of the 87% of North American enterprises that plan to have SDN in production by 2016 or one of the 53% of the companies that plan to have SDN deployed in the near future? Even though we all know how inflated these claims are, you might have to start considering the deployment aspects of a solution a $vendor will persuade your CIO to buy.

If you’ve been reading my blog in the last few months, you might have noticed that I started a new podcast focused on software-defined everything (hence the name: Software Gone Wild – thanks to Jason Edelman).

The latest episodes are always available on this page; you can also subscribe to the podcast feed in RSS, Atom or iTunes format… and if you wonder why we need yet-another podcast, read the About Software Gone Wild document.

If you mention open-source cloud orchestration tools these days, everyone immediately thinks about OpenStack (including the people who spent months or years trying to make it ready for production use). In the meantime, there are at least two other comparable open-source products (CloudStack and Eucalyptus) that nobody talks about. Obviously having a working product is not as sexy as having 50+ vendors and analysts producing press releases.

A while ago Cisco added dynamic FCoE support to Nexus 5000 switches. It sounded interesting and I wanted to talk about it in my Data Center Fabrics update session, but I couldn’t find any documentation at that time.

In the meantime, the Configuring Dynamic FCoE Using FabricPath configuration guide appeared on Cisco’s web site and J Metz wrote a lengthly blog post explaining how it all works, triggering a severe attack of déjà vu.