[j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

[Giuliano Medalha]

Morgan,

I really dont know why JUNIPER did this kind of crazy environment with
EX8200.

Considering the MX family (240, 480 and 960 with TRIO 3D) and the new MX-L
I think you do not need the external routing engines for virtual chassis.

About the line card ... the information I have is that you need 8 port line
card to interconnect chassis.

Take a look:

http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/line-cards-ex8200.html

You cannot use 40 port 10 gig to interconnect.. maybe in future with a new
JUNOS code you could use it.

I will try to check it.

Att,

Giuliano


On Fri, Oct 26, 2012 at 7:36 PM, Morgan McLean <wrx230 at gmail.com> wrote:

> I know I need the XRE200, but my question would be why? Why is this the
> only EX product requiring external RE's? And also, it looks like you need
> two local RE's to be able to connect to two external RE's? Seems
> unnecessarily expensive.
>
> Also, are the 8XS required for inter connects? Right now I only have two
> 8208's each with an 8XS and the 40 port 10g card, but I plan on adding
> another 40 port and in the future two additional EX8208's at another site
> with two 40 port 10gig cards each, no more 8XS cards. I would like to
> spread the interconnections across two cards to protect against a module
> failure.
>
> Morgan
>
> On Fri, Oct 26, 2012 at 2:19 PM, Giuliano Medalha <giuliano at wztech.com.br>wrote:
>
>> Morgan,
>>
>> We have some cases running EX8200 as a Virtual Chassis, but you will need
>> the XRE200 External Routing Engines:
>>
>>
>> http://www.juniper.net/in/en/products-services/switching/ex-series/options/xre200/
>>
>> Don't forget that you will need the 8 ports (10 gig)  for chassis inter x
>> connections - EX8200-8XS
>>
>> It is a very good topology and we have very good performance with not bad
>> uptime (196 days) right now.
>>
>> Without STP problems.
>>
>> We have used a lot of EX4200 pairs (48 port) connected by Virtual Chassis
>> for Client Access.
>>
>> 2 x 10 giga fiber (1 for each EX4200) connect using Aggregated Ethernet
>> Interfaces to both EX8200 (10 gig modules)
>>
>> I really recommend it for you.
>>
>> Att,
>>
>> Giuliano
>>
>>
>>
>>
>> On Fri, Oct 26, 2012 at 4:46 PM, Morgan McLean <wrx230 at gmail.com> wrote:
>>
>>> Hey guys,
>>>
>>> So I run SRX as my core firewalls, with EX8200's doing core switching and
>>> EX3300's doing access switching. I have two SRX's, two 8208's, and two
>>> 3300's at every cabinet. Spanning tree is a pain in my ass, especially
>>> since I have other environments setup the same way, just with smaller
>>> switches. Right now the SRX reth interfaces only come down as legs, not
>>> full mesh. The top of rack switches have only one link active at a time,
>>> legs. The interconnects between the core switches of different
>>> environments
>>> are legs, not full mesh due to spanning tree constraints (it closes the
>>> lag
>>> center trunk between the core switches).
>>>
>>> It would be a lot easier if I could just VC the core and VC the access
>>> switch pairs so that multi-chassis lags can be run everywhere and I can
>>> for
>>> the most part cut spanning tree out of the picture and have greater link
>>> fault tolerance. How reliable is VC? I've really done my best to avoid it
>>> up to this point as I try to keep redundant systems as separate as
>>> possible
>>> so one doesn't take down the other. Then again, when it comes down to it
>>> my
>>> edge and core firewalls are all SRX clusters, so... :) lol
>>>
>>> I'm not really sure what kind of information I'm looking for here. I
>>> would
>>> just run 20G lags eveywhere instead of having 10G forward/blocking STP
>>> pairs. I don't really know how things work when a device fails, how fast
>>> convergence is, split brain scenarios etc.
>>>
>>> Any major lessons learned with this technology? I am aware that with the
>>> 8200's I would need the external SRE.
>>>
>>> Thanks,
>>> Morgan
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>