Benefits (and Detriments) of Standardizing Network Equipment in a Global Organization
nanog at thedaileyplanet.com
Thu Dec 29 16:02:55 UTC 2016
I'm not a fan of vendor lock-in, and have been bitten by it. I eschew
vendor specific solutions unless it is essential to delivering a particular
result. Keeping multiple players at the table, and making those players
aware that you have other options that you can and do take advantage of
seems to keep them on their toes when it's time for refresh.
On Thu, Dec 29, 2016 at 9:44 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Dec 28, 2016 at 01:39:59PM -0500, Chris
> Grundemann 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...
> While a lot of people seem to be beating you up over this approach, many
> folks end up in it for various reasons. For instance the chances a
> vendor makes both a functional edge router and a high quality firewall
> are low, which means they often are sourced from different companies.
> But I think the question others are trying to ask is a different
> hyptothetical. Say there are two vendors, of of which makes perfectly
> good edge routers and core routers. What are the pros to buying all
> of the edge from one, and all of the core from the other?
> I have to admit I'm having trouble coming up with potential technical
> upsides to such a solution. There may well be a business up side,
> in that due to the way price structures are done that such a method
> saves captial. But in terms of technical resilliance, if there's a
> bug that takes out all cores or all edges the whole network is down,
> and there's actually 2x the risk as it could happen at either layer!
> Leo Bicknell - bicknell at ufp.org
> PGP keys at http://www.ufp.org/~bicknell/
More information about the NANOG