[193224] in North American Network Operators' Group
Re: Benefits (and Detriments) of Standardizing Network Equipment in a
daemon@ATHENA.MIT.EDU (Chris Grundemann)
Thu Dec 29 08:13:56 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <CAC1-dtmidnMUQYLcwz6YCFhp6Tdg57xVH2_viEChY0GQUry+_w@mail.gmail.com>
From: Chris Grundemann <cgrundemann@gmail.com>
Date: Thu, 29 Dec 2016 08:13:51 -0500
To: David Barak <thegameiam@yahoo.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
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@yahoo.com> wrote:
On Dec 28, 2016, at 5:34 PM, Randy Bush <randy@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
