One of the comments added to my Using BGP in Data Centers blog post said:

With symmetric fabric… does it make sense for a node to know every bit of fabric info or is reachability information sufficient?

Let’s ignore for the moment that large non-redundant layer-3 fabrics where BGP-in-Data-Center movement started don’t need more than endpoint reachability information, and focus on a bigger issue: is knowledge of network topology (as provided by OSPF and not by BGP) beneficial?

While the large data centers increasingly use BGP as the routing protocol within their fabrics, the enterprise engineers tend to shy away from that idea because they think BGP is too complex/scary/hard-to-configure/obsolete/unknown/whatever.

It’s time to fix that.

A while ago I answered a few questions that Dan Novak from University of Maryland sent me, and as they might be relevant to someone out there decided to publish the answers.

Dan started with a soft one:

What circumstances led you to choosing network engineering for a career?

It was pure coincidence.

John Herbert published an awesome blog post based on the recent Networking Field Day SDN discussion. Try to figure out who said what ;)… it's not that hard.

Julian Lucek did a fantastic job describing how NorthStar controller uses BGP-LS and PCEP, so I asked him whether he’d be willing to do a deep dive on these two topics. He gracefully agreed, and the results are already online.

Five years after the SDN hype exploded, it remains as meaningless as Cloud, and it seems that all we’re left with is a plethora of vendors engaged in SDN-washing their products.

Even when a group of highly intelligent engineers considering these topics on a daily basis gets together they don’t get very far apart from a great question: “what business problem is it supposed to solve?” (or maybe they got distracted by irrelevant hot-air opinions).

Is it still worth trying to find a useful definition of SDN? It seems it’s easier to list what SDN is not like I’ll be doing in the free Introduction to SDN webinar on February 10th. Let’s see:

It all started with a tweet by Stephane Clavel:

@ioshints @BradHedlund I'm puzzled NSX dFW does not track connections seq #. Still true? To me this is std fw feature.

— stephaneclavel (@stephaneclavel) January 31, 2016

Trying to fit my response into the huge Twitter reply field I wrote “Tracking Seq# on FW should be mostly irrelevant with modern TCP stacks” and when Gal Sagie asked for more elaboration, I decided it’s time to write a blog post.

Harry Taluja asked an interesting question in his comment to one of my virtualization blog posts:

If vShield API is no longer supported, how does a small install (6-8 ESXi hosts) take care of east/west IPS without investing in NSX?

Short answer: It depends, but it probably won’t be cheap ;) Now for the details…

Robert Graham published another great blog post explaining why you need user-space handling of network traffic for multigigabit performance on x86 servers. A must-read if you’re interested in performance of software-based packet forwarding.

Want more? Listen to Snabb Switch Deep Dive and PF_RING Deep Dive podcasts.

Need product details? I collected some performance data points in the NFV webinar.

A few days ago Dell announced their next-generation network OS based on Debian Linux, and bloggers (like my good friend Tom Hollingsworth) started wondering what’s going to happen with Cumulus Linux.

Let’s get into prognostication mode…

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.

Continuing the IPv6 address selection discussion we have a few days ago, Luka Manojlovič sent me a seemingly workable proposal:

I think we were discussing a borderline problem. In a server environment there won’t be any SLAAC, and we could turn off DHCPv6 client on servers with fixed IP addresses.

Sounds great, but as always, the reality tends to be a bit harsher.

A long time ago in a podcast far, far away one of the hosts saddled his pony unicorn and started explaining how stateful firewalls work:

Stateful firewall is a way to imply trust… because it’s possible to hijack somebody’s flows […] and if the application changes its port numbers… my source port changes when I’m communicating with my web server - even though I’m connected to port 80, my source port might change from X to Y. Once I let the first one through, I need to track those port changes […]

WAIT, WHAT? Was that guy really trying to say “someone can change a source port number of an established TCP session”?

The proponents of microsegmentation solutions would love you to believe that it takes no more than somewhat-stateful packet filters sitting in front of the VMs to get rid of traditional subnets. As I explained in my IPv6 Microsegmentation talk (links below), you need more if you want to have machines from multiple security domains sitting in the same subnet – from RA guard to DHCPv6 and ND inspection.

The breadth of address allocation options available in IPv6 world confuses many engineers thoroughly fluent in IPv4, but it also gives operating system developers way too many options… and it turns out that different operating systems behave way differently when faced with the same environment.

2016-01-21: In the meantime, Luka got further details on Windows behavior, and Enno Rey provided a few additional links.