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.”

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 Designcourse and I’m running a free webinar on February 13th for those of you who won’t be able to make it to Ljubljana (the webinar includes a bonus feature: description of SPDY, the protocol IETF adopted as the basis for next-generation HTTP).

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.

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&DR summary: because Internet-wide Path MTU Discovery rarely works).

Cassidy Larson from InfoWest sent me an interesting challenge: using the sample configurations I provided in the Building Large IPv6 Service Provider Networks webinar he was getting weird DHCPv6 errors when a residential CPE device requested a delegated prefix from the BRAS router (before moving forward, have to mention how nice it is to see an US ISP deploying IPv6 ;).

Adam Sweeney, VP of EOS Engineering @ Arista Networks posed me a challenging question after my I-so-hate-PBR-CLI rant: “Is there something in particular that makes the IOS PBR CLI so painful? Is there a PBR CLI provided by any of the other systems out there that you like a lot better?”

My Twitter friends helped me find the answer to the second question: PBR in Junos is even more convoluted than it is in Cisco IOS... but what would be a better CLI?

I asked Martin Casado to check whether I correctly described his HotSDN’12 paper in my Edge and Core OpenFlow post, and he replied with another interesting observation:

The (somewhat nuanced) issue I would raise is that [...] decoupling [also] allows evolving the edge and core separately. Today, changing the edge addressing scheme requires a wholesale upgrade to the core.

The 6PE architecture (IPv6 on the edge, MPLS in the core) is a perfect example of this concept.

We have Cisco's 2901s with the data license running MPLS/VPN on customer site (the classical PE is at the customer site). Should we use eBGP between CPE router and network edge router, some sort of iBGP route reflector design, or something completely different?

The “it depends” answer depends primarily on how much you can trust the routers installed at the customer site (CPE routers).

Tomas Kubica made an interesting comment to my Stackable Data Center Switches blog post: “Suppose all your servers have 4x 10G port and you bundle them to LACP NIC team [...] With this stacking link is not going to be used for your inter-server traffic if all servers have active connections to all nodes of your ToR stack.” While he’s technically correct, the idea of having four 10GE ports on each server just to cater to the whims of stackable switches is somewhat hard to sell.

Simon Gordon introduced me to the magic U-curve during a fantastic meeting with the QFabric team more than a year ago. It turns out you can explain around 80% of IT phenomena with the U-curve (assuming you choose the proper metrics and linear or log scale) … and you can always try the hockey stick if the U-curve fails.

The author

Ivan Pepelnjak (CCIE#1354 Emeritus), Independent Network Architect at ipSpace.net, has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced internetworking technologies since 1990.