Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
We experienced phantom routing and arp issues as well in the 9 series, but 10.0s1.1 has been very stable. -Original Message- From: Cyrill Malevanov [mailto:c...@n-home.ru] Sent: Tuesday, June 22, 2010 10:18 AM To: Dan Farrell Cc: Laurent HENRY; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? We have a lot of routing problems on EX4200 VC's. Standalone EX works fine, but routing on high loads using VC - is a pain. Some routing loss, packets loss etc. Cyrill On 22.06.2010 17:59, Dan Farrell wrote: > Not in -this- version 10.0S1.1 . I sing the praises of the EX series because > it fits our needs like a glove and Cisco wants more money for less product. > But just 6 months ago it was a little rough because the platform, IMHO, was > 'growing up' in the 9.X series. There were some definite operational problems > we had on 9. With 10, aside from great stability, one noticeable difference > is interface groups- in our environment (virtualization hosting) this has > made configuring the devices significantly easier. > > At this point I can't fault them, and we are using 4200 VC stacks to slowly > expand our core routing/switching, one chassis at a time (getting ready to > add our first third chassis to a stacked core). We may eventually convert to > the 8208 platform there, but right now the 4200's price point is so > attractive it's hard not to continue in this direction. > > > Dan > > -Original Message- > From: Laurent HENRY [mailto:laurent.he...@ehess.fr] > Sent: Tuesday, June 22, 2010 5:23 AM > To: Dan Farrell > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? > > > Thank you ! > No weird bugs encountered ? > > > Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : > >> We leverage the EX3200 and 4200's extensively in our network, for >> edge, core, and access. >> >> As far as edge (ISP connectivity) we use EX3200's in pairs- each >> EX3200 has a separate peer session to each upstream provider, >> providing redundancy >> (high-availability) without merging the two units as one logical unit. >> This makes zero-downtime maintenance easier at your edge, as >> upgrading a stacked chassis involves rebooting all the devices at >> once. And they're cheaper than their 4200 counterparts. >> >> I'm elated at the 4200's performance in our core- I think what may be >> of use to you is a comparison to equivalent Cisco gear- in this light >> we just replaced a two-chassis 3750G stack with a two-chassis EX4200 >> stack (we stack them to take advantage of port densities with >> staggered growth in the core), and we are glad we did so. >> >> The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the >> Catalyst 3xxx series only actually supports 8 RVI's, and they don't >> publish this (you will find it when configuring the profile of the >> device). This created a problem with 10 OSPF interfaces (and 15 other >> non-OPSF >> interfaces) on the Cisco. Upon a link-state change on any of the >> Cisco's OSPF-configured interfaces, the CPU would crank up to 100% >> and the stacked device throughput was ground to a crawl (80%+ traffic >> loss). Changing the configuration in the OSPF subsection, elimination >> of the problem interface (flapping or not) from the configuration, or >> a complete reboot would solve the problem- none of which are >> attractive solutions to a problem we shouldn't have been having in the first >> place. >> >> Compare this to a two-chassis EX4200-48T stack we have in another >> part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's >> , and the stacked device hasn't given us any grief. They cost us 1/3 >> less than the Cisco solution, and doubled the port density (the >> Ciscos had >> 24 and the Junipers we got have 48 ports). >> >> There are platform limitations, like memory, which may cause you to >> be a little more exotic on BGP route selection, but the Catalyst >> 3750G's have even less memory as I recall. Overall they have been >> extremely good for our network, and have caused me to swear off Cisco >> completely. >> >> Hope this provides some insight. >> >> Dan >> >> -Original Message- >> From: juniper-nsp-boun...@puck.nether.net >> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent >> HENRY >> Sent: Monday, June 21, 2010 6:29 AM >> To: juniper-nsp@puck.nether.
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
We have a lot of routing problems on EX4200 VC's. Standalone EX works fine, but routing on high loads using VC - is a pain. Some routing loss, packets loss etc. Cyrill On 22.06.2010 17:59, Dan Farrell wrote: Not in -this- version 10.0S1.1 . I sing the praises of the EX series because it fits our needs like a glove and Cisco wants more money for less product. But just 6 months ago it was a little rough because the platform, IMHO, was 'growing up' in the 9.X series. There were some definite operational problems we had on 9. With 10, aside from great stability, one noticeable difference is interface groups- in our environment (virtualization hosting) this has made configuring the devices significantly easier. At this point I can't fault them, and we are using 4200 VC stacks to slowly expand our core routing/switching, one chassis at a time (getting ready to add our first third chassis to a stacked core). We may eventually convert to the 8208 platform there, but right now the 4200's price point is so attractive it's hard not to continue in this direction. Dan -Original Message- From: Laurent HENRY [mailto:laurent.he...@ehess.fr] Sent: Tuesday, June 22, 2010 5:23 AM To: Dan Farrell Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Thank you ! No weird bugs encountered ? Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
Not in -this- version 10.0S1.1 . I sing the praises of the EX series because it fits our needs like a glove and Cisco wants more money for less product. But just 6 months ago it was a little rough because the platform, IMHO, was 'growing up' in the 9.X series. There were some definite operational problems we had on 9. With 10, aside from great stability, one noticeable difference is interface groups- in our environment (virtualization hosting) this has made configuring the devices significantly easier. At this point I can't fault them, and we are using 4200 VC stacks to slowly expand our core routing/switching, one chassis at a time (getting ready to add our first third chassis to a stacked core). We may eventually convert to the 8208 platform there, but right now the 4200's price point is so attractive it's hard not to continue in this direction. Dan -Original Message- From: Laurent HENRY [mailto:laurent.he...@ehess.fr] Sent: Tuesday, June 22, 2010 5:23 AM To: Dan Farrell Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Thank you ! No weird bugs encountered ? Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : > We leverage the EX3200 and 4200's extensively in our network, for > edge, core, and access. > > As far as edge (ISP connectivity) we use EX3200's in pairs- each > EX3200 has a separate peer session to each upstream provider, > providing redundancy > (high-availability) without merging the two units as one logical unit. > This makes zero-downtime maintenance easier at your edge, as upgrading > a stacked chassis involves rebooting all the devices at once. And > they're cheaper than their 4200 counterparts. > > I'm elated at the 4200's performance in our core- I think what may be > of use to you is a comparison to equivalent Cisco gear- in this light > we just replaced a two-chassis 3750G stack with a two-chassis EX4200 > stack (we stack them to take advantage of port densities with > staggered growth in the core), and we are glad we did so. > > The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the > Catalyst 3xxx series only actually supports 8 RVI's, and they don't > publish this (you will find it when configuring the profile of the > device). This created a problem with 10 OSPF interfaces (and 15 other > non-OPSF > interfaces) on the Cisco. Upon a link-state change on any of the > Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and > the stacked device throughput was ground to a crawl (80%+ traffic > loss). Changing the configuration in the OSPF subsection, elimination > of the problem interface (flapping or not) from the configuration, or > a complete reboot would solve the problem- none of which are > attractive solutions to a problem we shouldn't have been having in the first > place. > > Compare this to a two-chassis EX4200-48T stack we have in another part > of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and > the stacked device hasn't given us any grief. They cost us 1/3 less > than the Cisco solution, and doubled the port density (the Ciscos had > 24 and the Junipers we got have 48 ports). > > There are platform limitations, like memory, which may cause you to be > a little more exotic on BGP route selection, but the Catalyst 3750G's > have even less memory as I recall. Overall they have been extremely > good for our network, and have caused me to swear off Cisco completely. > > Hope this provides some insight. > > Dan > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent > HENRY > Sent: Monday, June 21, 2010 6:29 AM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? > > Hi all, > I am thinking about using two EX 4200 as redondant border > routers of my main Internet link. > > In this design, I would then need to use BGP with my ISP and OSPF for > inside route redistribution. > > Reading the archive, and on my own experience with the product too, i > am looking for feedbacks about stability of this solution with EX. > > In archives i understood there could have been some huge stability > problems, am i right ? > > Could things be different with 10.1 JunOS release ? > > Does anyone actually use these features actively with this platform ? > > > Regards > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
Thank you ! No weird bugs encountered ? Le Monday 21 Ju4ne 2010 23:25:13 Dan Farrell, vous avez écrit : > We leverage the EX3200 and 4200's extensively in our network, for edge, > core, and access. > > As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has > a separate peer session to each upstream provider, providing redundancy > (high-availability) without merging the two units as one logical unit. This > makes zero-downtime maintenance easier at your edge, as upgrading a stacked > chassis involves rebooting all the devices at once. And they're cheaper > than their 4200 counterparts. > > I'm elated at the 4200's performance in our core- I think what may be of > use to you is a comparison to equivalent Cisco gear- in this light we just > replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we > stack them to take advantage of port densities with staggered growth in the > core), and we are glad we did so. > > The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the > Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish > this (you will find it when configuring the profile of the device). This > created a problem with 10 OSPF interfaces (and 15 other non-OPSF > interfaces) on the Cisco. Upon a link-state change on any of the Cisco's > OSPF-configured interfaces, the CPU would crank up to 100% and the stacked > device throughput was ground to a crawl (80%+ traffic loss). Changing the > configuration in the OSPF subsection, elimination of the problem interface > (flapping or not) from the configuration, or a complete reboot would solve > the problem- none of which are attractive solutions to a problem we > shouldn't have been having in the first place. > > Compare this to a two-chassis EX4200-48T stack we have in another part of > the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the > stacked device hasn't given us any grief. They cost us 1/3 less than the > Cisco solution, and doubled the port density (the Ciscos had 24 and the > Junipers we got have 48 ports). > > There are platform limitations, like memory, which may cause you to be a > little more exotic on BGP route selection, but the Catalyst 3750G's have > even less memory as I recall. Overall they have been extremely good for our > network, and have caused me to swear off Cisco completely. > > Hope this provides some insight. > > Dan > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY > Sent: Monday, June 21, 2010 6:29 AM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? > > Hi all, > I am thinking about using two EX 4200 as redondant border routers > of my main Internet link. > > In this design, I would then need to use BGP with my ISP and OSPF for > inside route redistribution. > > Reading the archive, and on my own experience with the product too, i am > looking for feedbacks about stability of this solution with EX. > > In archives i understood there could have been some huge stability > problems, am i right ? > > Could things be different with 10.1 JunOS release ? > > Does anyone actually use these features actively with this platform ? > > > Regards > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
On 22/06/10 18:13, Richard A Steenbergen wrote: > With a healthy dose of complex commit scripts you can get an MX commit > time up to 20 seconds in no time flat. Well at least you could, I > noticed they did something in 9.6 to make it a lot faster (at least for > me, with commit sync, etc). EX on the other hand can get to a 30 sec > config with half the number of commit scripts and a much smaller config. > Of course if you really want suffering try SRX, which takes 30 seconds > to commit a nearly blank config. :) I had a J6350 last night take over 10 minutes to commit. Under heavy BGP load, and although it won't admit it I strongly believe heavy memory pressures (two full feeds, plus four other feeds totalling ~50k routes on a 1GB system in 10.0R2, RAM has been ordered and the second full feed turned off). -- Julien Goodwin Studio442 "Blue Sky Solutioneering" signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
On Tue, Jun 22, 2010 at 09:38:21AM +0200, sth...@nethelp.no wrote: > > Guess you never had a heavily configured M10 or M20 if you think that 20 > > seconds is a long time to commit. I'll admit that I have gotten spoiled > > by the speed of the MX series, though. > > Yup - but how long will it stay that way? Juniper seems to be adding > more BRAS capabilities to the MX all the time, and that probably also > means it will handle nice lng BRAS config files. With a healthy dose of complex commit scripts you can get an MX commit time up to 20 seconds in no time flat. Well at least you could, I noticed they did something in 9.6 to make it a lot faster (at least for me, with commit sync, etc). EX on the other hand can get to a 30 sec config with half the number of commit scripts and a much smaller config. Of course if you really want suffering try SRX, which takes 30 seconds to commit a nearly blank config. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
> Guess you never had a heavily configured M10 or M20 if you think that 20 > seconds is a long time to commit. I'll admit that I have gotten spoiled > by the speed of the MX series, though. Yup - but how long will it stay that way? Juniper seems to be adding more BRAS capabilities to the MX all the time, and that probably also means it will handle nice lng BRAS config files. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
> From: Dan Farrell > Date: Mon, 21 Jun 2010 14:33:50 -0700 > Sender: juniper-nsp-boun...@puck.nether.net > > With 10.0.S1.1 the only headaches we encounter with our loaded > configuration on a 2-member 4200 stack (~850+ RVI's total, some on > OSPF) is the time it takes for the configuration to be checked or > implemented from the CLI. The wait times from "commit" to actually > being returned to the command prompt can be up to twenty seconds > sometimes. At first this scared me (making large changes in a > production environment... then ... wait.) but now I'm accustomed to > it. Guess you never had a heavily configured M10 or M20 if you think that 20 seconds is a long time to commit. I'll admit that I have gotten spoiled by the speed of the MX series, though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
With 10.0.S1.1 the only headaches we encounter with our loaded configuration on a 2-member 4200 stack (~850+ RVI's total, some on OSPF) is the time it takes for the configuration to be checked or implemented from the CLI. The wait times from "commit" to actually being returned to the command prompt can be up to twenty seconds sometimes. At first this scared me (making large changes in a production environment... then ... wait.) but now I'm accustomed to it. But the CPU under regular performance (no configuration changes or port mirroring stuff) leaves the CPU at an average of 12% on a very active network (routing internet access traffic along with switching SAN traffic for thousands of virtual servers, so it's doing some heavy lifting). Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ross Vandegrift Sent: Monday, June 21, 2010 11:33 AM To: Laurent HENRY Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? On Mon, Jun 21, 2010 at 12:29:00PM +0200, Laurent HENRY wrote: > Hi all, > I am thinking about using two EX 4200 as redondant border > routers of my main Internet link. > > In this design, I would then need to use BGP with my ISP and OSPF for > inside route redistribution. > > Reading the archive, and on my own experience with the product too, i > am looking for feedbacks about stability of this solution with EX. > > In archives i understood there could have been some huge stability > problems, am i right ? > > Could things be different with 10.1 JunOS release ? > > Does anyone actually use these features actively with this platform ? We make some use of layer 3 services on the EX-4200, and largely, our experience has been good in this department. Be aware that their FIB size is very limited, so you'll need defaults. We have EXes working a customer edge boxes for people that don't want a full table and it's reliable and cost effective if you can live without the missing features. We do OSPF, iBGP, and some MPLS, though the EXes are feature crippled there. If you care, uRPF sucks big time, but I'm used to that from the 6500. Be somewhat cognizant of RE CPU performance. Unfortunately, the EX CPU doesn't cope too well with large VC installations in complicated configuration. In my experience, you'll be fine if you stay away from virtual-chassis. We've only really hit this in our layer 2 deployments, where committing a config can cause STP to miss BPDU timers. However, I don't see any reason why a 10 member layer 3 VC wouldn't exhibit the same issue with (for example) OSPF hellos. Software choice can be annoying - things are still changing. 9.6 is my current target for layer 3 boxes because you finally get capable loopback filters with recent bugfixes. If you want to police LSPs though, you'll need 10.1. I've had good luck so far with 10.1R2 in this application. Of course neither of these are extended EOE... To sum up - if you can live with some missing features and headaches, they aren't bad. The price point is pretty attractive. Ross -- Ross Vandegrift r...@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
We leverage the EX3200 and 4200's extensively in our network, for edge, core, and access. As far as edge (ISP connectivity) we use EX3200's in pairs- each EX3200 has a separate peer session to each upstream provider, providing redundancy (high-availability) without merging the two units as one logical unit. This makes zero-downtime maintenance easier at your edge, as upgrading a stacked chassis involves rebooting all the devices at once. And they're cheaper than their 4200 counterparts. I'm elated at the 4200's performance in our core- I think what may be of use to you is a comparison to equivalent Cisco gear- in this light we just replaced a two-chassis 3750G stack with a two-chassis EX4200 stack (we stack them to take advantage of port densities with staggered growth in the core), and we are glad we did so. The EX series allows 1000 RVI's and 4k VLANS per virtual chassis- the Catalyst 3xxx series only actually supports 8 RVI's, and they don't publish this (you will find it when configuring the profile of the device). This created a problem with 10 OSPF interfaces (and 15 other non-OPSF interfaces) on the Cisco. Upon a link-state change on any of the Cisco's OSPF-configured interfaces, the CPU would crank up to 100% and the stacked device throughput was ground to a crawl (80%+ traffic loss). Changing the configuration in the OSPF subsection, elimination of the problem interface (flapping or not) from the configuration, or a complete reboot would solve the problem- none of which are attractive solutions to a problem we shouldn't have been having in the first place. Compare this to a two-chassis EX4200-48T stack we have in another part of the network- 13 OSPF interfaces and ~845 other non-OSPF RVI's , and the stacked device hasn't given us any grief. They cost us 1/3 less than the Cisco solution, and doubled the port density (the Ciscos had 24 and the Junipers we got have 48 ports). There are platform limitations, like memory, which may cause you to be a little more exotic on BGP route selection, but the Catalyst 3750G's have even less memory as I recall. Overall they have been extremely good for our network, and have caused me to swear off Cisco completely. Hope this provides some insight. Dan -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Laurent HENRY Sent: Monday, June 21, 2010 6:29 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ? Hi all, I am thinking about using two EX 4200 as redondant border routers of my main Internet link. In this design, I would then need to use BGP with my ISP and OSPF for inside route redistribution. Reading the archive, and on my own experience with the product too, i am looking for feedbacks about stability of this solution with EX. In archives i understood there could have been some huge stability problems, am i right ? Could things be different with 10.1 JunOS release ? Does anyone actually use these features actively with this platform ? Regards ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
On Mon, Jun 21, 2010 at 12:29:00PM +0200, Laurent HENRY wrote: > Hi all, > I am thinking about using two EX 4200 as redondant border routers of > my main Internet link. > > In this design, I would then need to use BGP with my ISP and OSPF for inside > route redistribution. > > Reading the archive, and on my own experience with the product too, i am > looking for feedbacks about stability of this solution with EX. > > In archives i understood there could have been some huge stability problems, > am i right ? > > Could things be different with 10.1 JunOS release ? > > Does anyone actually use these features actively with this platform ? We make some use of layer 3 services on the EX-4200, and largely, our experience has been good in this department. Be aware that their FIB size is very limited, so you'll need defaults. We have EXes working a customer edge boxes for people that don't want a full table and it's reliable and cost effective if you can live without the missing features. We do OSPF, iBGP, and some MPLS, though the EXes are feature crippled there. If you care, uRPF sucks big time, but I'm used to that from the 6500. Be somewhat cognizant of RE CPU performance. Unfortunately, the EX CPU doesn't cope too well with large VC installations in complicated configuration. In my experience, you'll be fine if you stay away from virtual-chassis. We've only really hit this in our layer 2 deployments, where committing a config can cause STP to miss BPDU timers. However, I don't see any reason why a 10 member layer 3 VC wouldn't exhibit the same issue with (for example) OSPF hellos. Software choice can be annoying - things are still changing. 9.6 is my current target for layer 3 boxes because you finally get capable loopback filters with recent bugfixes. If you want to police LSPs though, you'll need 10.1. I've had good luck so far with 10.1R2 in this application. Of course neither of these are extended EOE... To sum up - if you can live with some missing features and headaches, they aren't bad. The price point is pretty attractive. Ross -- Ross Vandegrift r...@kallisti.us "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie signature.asc Description: Digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 4200 stability with BGP and OSPF redistribution ?
On Monday 21 June 2010 06:29:00 pm Laurent HENRY wrote: > Does anyone actually use these features actively with > this platform ? We once used 2x EX4200-24F's as routers located in the centre of a core network built to drive a regional operator conference. They ran iBGP + IS-IS (IPv6 support included, for both) with Cisco 7206-VXR/NPE-G2's and originated the allocation that the conference was using. Given they were at the centre of the core (core switches, actually), their failure would have been more accurate/indicative of network problems rather than originating said routes on the border routers. In this role, they were very stable (they also run regular Layer 2 Ethernet features, e.g., RSTP, 802.1Q, e.t.c.). Haven't used them as routers elsewhere, yet (although I had plans to, until the MX80 came out). Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
