[j-nsp] EX4200 resilience (VC vs 10GB cross-connect)

[Ross Vandegrift]

On Wed, Jan 13, 2010 at 08:32:45PM +0000, Joe Hughes wrote:
> I've read the VC Best practice guide and in all their examples, they have
> two sets of 2-switch VCs at the aggregation layer - which is making me
> wonder if a single VC (of two switches) and treated as one switch poses more
> of a risk than simply two distinct switches. I'm guessing if you have two
> links back from each rack - each to a different member of the VC, then the
> 'risks' are pretty much the same as having two separate switches?

The risks are the same in terms of physical failures, but having a
single VC doesn't insulate you from control-plane failures.  If you
need to sustain a control plane failure and the extra interfaces are
worth the cost, don't VC.  If that's too expensive, or a control-plane
failure isn't something you care about surviving, go with the VC.

> In terms of software upgrades - is it possible to upgrade one member
> at a time (as you would in a non-VC setup) so as to not interrupt
> connectivity from the access\rack switches?

Nope - you have to upgrade the whole chassis and reboot it when you do
an upgrade.  This works quite smoothly.

> Are there any other situations\operations on a VC that would take
> both switches offline - further making it more sense to either have
> two switches, or two sets of 2 members VCs?

JUNOS bugs - by far, the #1 source of downtime in our EX4200s VCs.
If your aggregation layer is supposed to be HA, I'd keep the two
apart.

Ross

-- 
Ross Vandegrift
ross at kallisti.us

"If the fight gets hot, the songs get hotter.  If the going gets tough,
the songs get tougher."
	--Woody Guthrie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100113/23b0be27/attachment.bin>