Re: [j-nsp] JUNOS and MX Trio cards

[Joe Hughes]

On 30 June 2010 15:49, Chris Evans chrisccnpsp...@gmail.com wrote:
 Is there any way that someone could tell me how to reproduce the stalled
 route issue?  How do I see if is happening etc?

 We are about to purchase some mx's to replace our m series and would love to
 nail this.

The question of stability (or lack of) is of interest to me.

I began an exercise a few months back researching the options
available to replace some of our Cisco gear with Juniper. At the time
- it was looking like a combination of the M7i and the EX series
switches - but since learning the EX has limitations in regard to MPLS
and the fact the M7i is getting old - the MX looked a perfect
candidate; decent port density with sufficient horsepower. Despite the
attractiveness of the platform, I'm not sure I could cope with the
sleepless nights.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Joe Hughes]

Hi

Take the following scenario;

Several racks - each with a pair of EX3200 switches (cross-connected) - each
with separate L3 uplinks back to a pair of aggregation layer EX4200s (so, 1
from each rack switch), all running OSPF. I'm trying to understand if there
are any drawbacks in making the two aggregation layer EX4200s a VC - or
whether a simple L3 cross-connect using a LAG or the 10Gbps ports makes more
sense, factoring in things like resilience, ease of upgrades etc.

If you go on the basis the two EX4200s are two distinct switches with a L3
path between them, it is easy for me to visualise how the network will
behave and (hopefully) understand how failover scenarios will play out. The
obvious disadvantage of this is you are using up vital 10Gbps ports which
could be used elsewhere, and it does seem non-sensical given the higher
speed VC ports (+ the other VC advantages).

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? 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? 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?

Cheers

Joe
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp