Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization

Chris Grundemann cgrundemann at gmail.com
Thu Dec 29 13:13:51 UTC 2016


I apparently wasn't very clear. In the layered approach to multiple
vendors, you would (obviously) choose your layer definitions to avoid such
delicate interdependence.

Regardless of my failure to fully explain, I'm curious as to how mixing
vendors at the same layer is seen to be less problematic than assigning
vendors specific roles?

----
>My Android sent this<
http://chrisgrundemann.com

On Dec 28, 2016 11:13 PM, "David Barak" <thegameiam at yahoo.com> wrote:

On Dec 28, 2016, at 5:34 PM, Randy Bush <randy at psg.com> wrote:

>> An alternative multi-vendor approach is to use 1 vendor per stack layer,
>> but alternate layer to layer. That is; Vendor A edge router, Vendor B
>> firewall, Vendor A/C switches, Vendor D anti-SPAM software, etc. This
>> doesn't address the bug impact issue as well as it alleviates the vendor
>> "ownership" issue though...
>
> i think this is where i say that i hope my competitors do this.  it
> is a recipe for a complex set of delicate dependencies and great fun
> debugging.
>
One of the more spectacular failures I've seen was a bug in a network core
router that caused bad into to be carried by all of that same vendor's
routers across the core to the edges (made by a different vendor) which
promptly barfed and locked up.

So I'd be cautious about saying "vendor X for one layer, vendor Y for
adjacent layer" as a multi-vendor strategy.

David Barak
Sent from mobile device, please excuse autocorrection artifacts



More information about the NANOG mailing list