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.

I had a sweet problem with ipSpace.net webinars for quite a while: there are way more ideas than available time. However, a few days ago I stumbled upon a great tip on Trello blog and immediately decided to use it.

Result: list of future ipSpace.net webinars as a Trello board.

This article was initially sent to my SDN mailing list. To register for SDN tips, updates, and special offers, click here.

Usman asked a few questions in his comment on my blog, including:

At the moment, local RIB gets downloaded to FIB and we get packet forwarding on a router. If we start evaluating too many fields (PBR) and (assume) are able to push these policies to the FIB - what would become of the FIB table size?

Short answer: It would explode ;)

Almost a year ago I wrote a blog post explaining why I don’t think our future lies in becoming programmers. In the meantime, I found two interesting articles explaining the same idea from a programmer’s point-of-view:

Salman left an interesting comment on my Running BGP on Servers blog post:

My prior counterparts thought running OSPF on Mainframes was a good idea. Then we had a routing blackhole due to misconfiguration on the server. Twice! The main issue was the Mainframe admins lack of networking/OSPF knowledge.

Well, there’s a reason OSPF is called Interior Routing Protocol.

When someone starts complaining about networking device CLI, remind him that other parts of IT aren’t doing much better. For example, it’s oh-so-easy to install a package on Linux or OSX.

I spent the first half of the Introduction to SDN webinar explaining various attempts at defining SDN, and the obvious place to start was the centralized control plane mantra.

This part of the webinar is now public; to access the rest of the webinar, register on my web site.

Daniel Dib wrote a great series of BGP-related blog posts well worth reading.

• BGP convergence
• BGP confederations
• Inter-AS MPLS/VPN

Daniel is looking at BGP from the WAN/ISP perspective; if you want to know more about running BGP in the data center, watch the videos I recorded with Dinesh Dutt a few days ago.

The featured webinar in March 2016 is the Leaf-and-Spine Designs update to the Leaf-and-Spine Fabrics webinar, and in the featured videos (the ones marked with a star) you'll find in-depth explanation of BGP features available in Cumulus Linux, including a cool trick that allows you to run EBGP sessions across unnumbered interfaces.

My latest spanning tree protocol (STP) posts generated numerous comments, some of them so relevant that I decided to summarize them into another blog post.

Weird Things Happen

The unidirectional link scenario mentioned by Antonio is pretty well known:

A while ago I guestimated that most private clouds don’t have more than a few thousand VMs, and that they don’t need more bandwidth than what two ToR switches could provide.

Last autumn Iwan Rahabok published a blog post describing the compute- and storage parts of it, and I had a presentation describing the networking aspects of high-density consolidation. However…

After explaining the basics of BGP-LS and PCEP, and a quick deep dive into BGP-LS, Julian Lucek focused on the second topic of his excellent webinar and described the details of Path Computation Element Protocol (PCEP).

A few days ago Inside-IT published an interview Christoph Jaggi did with me. In case you don’t understand German, here’s the English version of it.

There is a lot of talk about data center fabrics. What problem do they try to solve?

The data center fabrics are supposed to solve a simple-to-define problem: building a unified data center infrastructure that seamlessly supports data and storage communications. As always, the devil hides in the details.

This article was initially sent to my SDN mailing list. To register for SDN tips, updates, and special offers, click here.

During one of my SDN workshops one of the attendees working for a mid-sized European ISP asked me this question:

Our management tells us we should build our network like Google does, including building our own switches. Where should we start?

The only answer I could give him was “You don’t have a chance.”

Continuing our bridging loops discussion Christoph Jaggi sent me another question:

Theoretically STP should avoid bridging loops, and yet you claim they cause data center meltdowns. What am I missing?

In theory, STP avoids bridging loops. In practice, there are numerous reasons STP got a bad name.