Brad Hedlund made a pretty valid comment to my “NEC Launched a Virtual OpenFlow Switch” blog post: “On the other hand, it's NEC end-to-end or no dice”, implicating the ultimate vendor lock-in.

Of course he’s right and while, as Bob Plankers explains, you can never escape some lock-in (part 1, response from Greg Ferro, part 2 – all definitely worth reading), you do have to ask yourself “am I looking for Windows or Mac?”

Martin Bernier has decided to open another can of IPv6 worms: how do you address multiple subnets in a very typical setup where you use a firewall (example: ASA) to connect a SMB network to the outside world?

During the IPv6 Security webinar, Eric Vyncke explained the intricate details of IPv6 Security Neighbor Discovery (SEND) and the reasons it will probably never take off.

We published the first draft of the BGP Operations and Security document almost a year ago. In the meantime, the authors and Merike Kaeo presented the draft at RIPE and IETF meetings and collected literally tons of feedback (well documented in change logs) ... and finally the draft was adopted as IETF opsec workgroup document and republished under a new name.

We would never get this far without relentless Jerome Durand who did most of the editing heavy lifting, persistent nudging from Gunter Van de Velde and gracious help of Merike Kaeo. Thank you all!

During a recent vMotion-over-VXLAN discussion Chris Saunders made a very good point: “Folks should be asking a better question, like: Can I use VXLAN and vMotion together to meet my business requirements.”

Yeah, it’s always worth exploring the actual business needs.

Based on a true story ...

A while ago I was sitting in a roomful of extremely intelligent engineers working for a large data center company. Unfortunately they had been listening to a wrong group of virtualization consultants and ended up with the picture-perfect disaster-in-waiting: two data centers bridged together to support a stretched VMware HA cluster.

Most web application developers remain blissfully unaware of the major performance roadblocks their applications face in the wild: access network bandwidth restrictions and unexpectedly high latency (see also Fallacies of Distributed Computing with an in-depth explanation). The impact of these two roadblocks is further amplified by behavior of TCP and HTTP, the protocols used by almost all web applications.

These issues are well documented in my Scalable Web Application Design course and in a free TCP, HTTP and SPDY webinar for those of you who won’t be able to make it to Ljubljana.

Numerous residential access technologies face path MTU discovery issues. PPPoE connections (with MTU = 1492 bytes instead of 1500 bytes) is the best-known example, and we’ll see more of them as various tunneling-based IPv4-to-IPv6 transition mechanisms (6rd, DS-Lite, MAP-E) become more popular.

Obviously you could use the same old MSS clamping tricks in the brave new IPv6 world or decide (like DS-Lite) to deal with IP fragmentation in underlay access networks ... but there’s another option in the IPv6 world: reduce client-side MTU with router advertisement messages.

On January 22nd NEC launched another component of their ProgrammableFlow architecture: a virtual switch for Hyper-V 3.0 environment. The obvious questions to ask would be: (a) why do we care and (b) how’s that different from Nicira or BigSwitch.

TL&DR summary: It depends.

During a recent ExpertExpress engagement I got an interesting question: “could we do per-customer policing and shaping on an MX-80 if we want to offer VPLS services and have Q-in-Q encapsulation on customer-facing links?” As I have preciously little Junos/MX knowledge, it was time for the classic “I’ll get back to you” reply and some heavy research.

You probably know how hard it is to find in-depth information on an unknown platform running unfamiliar software. Fortunately, Doug Hanks (@douglashanksjr) sent me a review copy of his new Juniper MX Series book a while ago. It was time for some serious reading.

This (not so very) short video explains what TCP MSS clamping is and why we’re almost forced to use it on xDSL (PPPoE) and tunnel interfaces.

TL&DW summary: because Internet-wide Path MTU Discovery rarely works.