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 ;).

One of my readers sent me a surprising question: “We run only LDP in our MPLS network and need to run RSVP for TE and then phase out LDP. How could we do it?”

My first reaction was “Why would you ever want to do that” and I got no reasonable answer (suggestions, anyone?) but let’s focus on “Could you do it?”

TL&DR summary: You could, but that doesn’t mean you should.

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?

Yesterday I described the roadblocks you might encounter when faced with a seemingly simple challenge:

In a network with two data centers (connected with a DCI link), ensure the applications in a data center stay reachable even if its Internet links fail.

In the Solutions Corner (a brand new part of my web site) you’ll find a short high-level design document describing the overall solution and listing the technologies you could use to implement it (you might want to watch the video before reading the document).

During one of my ExpertExpress consulting engagements I encountered an interesting challenge:

We have a network with two data centers (connected with a DCI link). How could we ensure the applications in a data center stay reachable even if all local Internet links fail?

On the face of it, the problem seems trivial; after all, you already have the DCI link in place, so what’s the big deal ... but we quickly figured out the problem is trickier than it seems.

... and someone mentions redundant layer-2 data center interconnect might fail creating a split-brain problem:

Source: DevOps Reactions (HT @Bigmstone)

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.

Erich has encountered a familiar MPLS/VPN design challenge:

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.