Layer-2 DCI and the infinite wisdom of acmqueue

Yesterday I got pulled into a layer-2 DCI tweetfest. Not surprisingly, there were profound opinions all over the place, including “We've been doing it (OTV) for almost a year now. No problems.

OTV is in fact the least horrible option – it does quite a few things right, including tight control of unicast flooding and reduction of STP scope.

Today I stumbled across this gem in the acmqueue blogs:

You might as well ask why people insist on not wearing seatbelts after all of the years that particular technology has been proven to save lives.

People will, it seems, persist in the optimistic belief that everything will be OK so long as they are otherwise careful. They think that bad things happen only to other people’s protocols, or packets, but not to theirs. Hope springs eternal and dies in the cold, cold winter of experience.

Finding this one a day after discussing layer-2 DCI? There really are no coincidences.


  1. Without strong network-focused architects in an Enterprise/Organization, the shiny gem of migration of machines in a metropolitan (or larger) area without a corresponding address change seems so easy and magical.

    Its really hard to fight against that, especially if plans have already been made (or executed!) implementing L2 DCI.

    If you can't fight this tide, I think a compromise would be in order. An intelligent application segmentation plan where you isolate applications that cannot use application HA or GLB (not many GOOD reasons exist in modern, supported application) from the rest that can, and then only allowing the VLANs for these nasty legacy apps across a DCI.

    If you can put in all the appropriate measures in place to prevent br/mu storms, you can just live with only the unknown unicast noise you must.
Add comment