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 <[email protected]> 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 > <[email protected]>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 <[email protected]> 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> >> >> > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
