One of my friends sent me this design challenge:

Assume you’re migrating from another WAN transport technology to MPLS. The existing network has 3000 routes but the MPLS carrier is limiting you to 1000 routes. How could you solve this with MPLS?

Personally, I think MPLS is a red herring.

With all the intent-based hype (and the previous SDN-will-rule-the-world-hype) you’d think that the network is the ultimate ossified roadblock on the path to agile nirvana.

You’d be totally wrong (and you’d deserve it – never trust a vendor peddling a product).

Here’s an amazing discovery I made when I was still running on-site SDN and network automation workshops.

Here’s the list of webinars and events planned for October and November 2017:

• Second part of Network Visibility with Flow Data webinar on October 5th;
• Network automation workshop in Rome on October 18th;
• Cumulus Linux Update (part of Data Center Fabrics updates) on October 26th;
• QoS webinar on November 9th (no description yet);
• Day-long data center automation event in Zurich on November 14th (more details soon).

Hint: you get access to all live webinar sessions, and 170 hours of downloadable videos with ipSpace.net subscription.

An update of PERL libraries broke a number of my scripts (don't ask). Here's the current status:

• Fixed: credit card processing. It was impossible to buy products from ipSpace.net with credit cards (the credit card form didn't appear at all)
• Fixed: Google+ login
• Unrelated and fixed: blog search

Anything else not working? Please write a comment or send me an email. Thank you!

A while ago a large airline had a bad-hair day claiming it was caused by a faulty power supply. Not surprisingly, I got a question along the lines of “is that feasible?”

Short answer: Yes. However, someone should be really worried if that wasn’t made up.

Here’s a common scenario I’m encountering on Ansible-related forums:

Q: I cannot connect to network devices with my Ansible network modules. I keep getting these weird error messages…

Me: Are you sure you have the device SSH keys in known_hosts file?

Q: How did you know?

In the Future of Networking with Fred Baker Fred mentioned an interesting IPv6 deployment scenario: give a /64 prefix to every server to support container deployment, and run routing protocols between servers and ToR switches to advertise the /64 prefix to the data center fabric preferably using link-local addresses.

Let’s recap:

Joel Knight published his blogging toolkit and processes he uses to write blog posts. Definitely worth reading even if you never plan to blog as he nicely documents how to sync creative process across multiple platforms.

A while ago I got a kind email from Kireeti Kompella, CTO @ Juniper Networks, saying “A colleague sent me an email of yours regarding SDN, the trough of disillusionment, and the rise of automation. Here's a more dramatic view: the Self-Driving Network -- one whose operation is totally automated.”

Even though Software Gone Wild podcast focuses on practical ideas that you could deploy relatively soon in your network, we decided to make an exception and talk about (as one of my friends described it) a unicorn driving a flying DeLorean with a flux capacitor.

One of my readers was wondering about the stability and scalability of large layer-2 domains implemented with VXLAN. He wrote:

If common BUM traffic (e.g. ARP) is being handled/localized by the network (e.g. NSX or ACI), and if we are managing what traffic hosts can send with micro-segmentation style filtering blocking broadcast/multicast, are large layer-2 domains still a recipe for disaster?

There are three major (fundamental) problems with large L2 domains: