[193223] in North American Network Operators' Group
Re: Benefits (and Detriments) of Standardizing Network Equipment in a
daemon@ATHENA.MIT.EDU (David Barak via NANOG)
Thu Dec 29 00:31:31 2016
X-Original-To: nanog@nanog.org
In-Reply-To: <m2pokb7c32.wl-randy@psg.com>
Date: Wed, 28 Dec 2016 20:13:28 -0800
To: Randy Bush <randy@psg.com>
From: David Barak via NANOG <nanog@nanog.org>
Reply-To: David Barak <thegameiam@yahoo.com>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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...
>=20
> 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.
>=20
One of the more spectacular failures I've seen was a bug in a network core r=
outer that caused bad into to be carried by all of that same vendor's router=
s across the core to the edges (made by a different vendor) which promptly b=
arfed and locked up. =20
So I'd be cautious about saying "vendor X for one layer, vendor Y for adjace=
nt layer" as a multi-vendor strategy.
David Barak
Sent from mobile device, please excuse autocorrection artifacts=
