Re: [j-nsp] Best route reflector platform
On Wednesday, April 24, 2013 02:24:18 PM Richard A Steenbergen wrote: I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else. One would hazard that the twisted thinking of someone at Juniper is that get yet-another-MX chassis into the customer's network, and hope that some bean-counting schmuck will say to the Engineering team, Hey, why do you want me to buy another MX chassis yet you have this big thing which can run both your route reflector function and the Multicast video services the Board is asking us to push by Q4'some year?. Since new products need low capital to get off the ground, Juniper will see an order for new line cards for what was a dedicated route reflector, and perhaps down the line, expect the customer to order another chassis so they can get back there dedicated route reflector once the new product starts making money... ... or something silly like all that. Who knows what Juniper are thinking? I stopped caring. 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
Re: [j-nsp] Best route reflector platform
On Sun, Apr 21, 2013 at 02:47:58PM +0400, Pavel Lunin wrote: 2. Branch SRX do not support more than 2G of RAM. Moreover about 700M+ is preallocated for flow session table and it is not released even when you switch the box into packed mode (well, at least used to be last time I checked a year or so ago). Plus JUNOS itself. In practice you have just about ~700M of free control plane memory on SRX650. A decent amount of memory is required for RR purposes too. We're pretty much to the point that if its not running 64-bit JUNOS (which actualley only bumps the max rpd memory from 2GB to 3GB, so it's not that big an improvement :P) it either won't work at all, or won't survive for very long. And that's after taking a lot of steps to reduce core IBGP mesh route load. I haven't touched any of the virtual SRX stuff, does it run 64-bit JUNOS? In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). So besides greatly pissing off many of its largest customers, they're leaving money on the floor and forcing people into other solutions with other vendors. I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else. -- Richard A Steenbergen r...@e-gerbil.net http://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] Best route reflector platform
On Wed, Apr 24, 2013 at 07:24:18AM -0500, Richard A Steenbergen wrote: In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). Even easier: ship a VM image of JUNOS, call it Olivia and a day. But that would be /too/ easy. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
2013/4/24 Richard A Steenbergen r...@e-gerbil.net wrote: it either won't work at all, or won't survive for very long. And that's after taking a lot of steps to reduce core IBGP mesh route load. I haven't touched any of the virtual SRX stuff, does it run 64-bit JUNOS? I haven't either (it's just rumors :) but I don't believe it will be any better than normal JUNOS from this perspective. There is another caveat. The difference of boxes like SRX or J (be it virtual or not) is that their PFE (fwdd process) also holds FIB (not only the flow session table), which is stored in the same RAM. You might be able to reduce it with a RIB-FIB policy, though I don't know whether it'll save any memory. For the Internet routes FIB might be not that huge thing, especially in comparison with the flow table, but for a VPN environment it might consume quite a noticeable amount of RAM. One might prefer to just totally shut up the fwdd on such an RR, but I don't believe it will work (at least stably). In fairness I really don't think there is a big market for dedicated RR's, so I'm sure it isn't on the top of anyone's radar. That said, it is an absurdly easy problem to solve, with almost no work required (ship JUNOS on 1U PC and call it JCS100). So besides greatly pissing off many of its largest customers, they're leaving money on the floor and forcing people into other solutions with other vendors. Agree. I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else BTW, does an empty chassis with just an SCB and RE work here? BGP will definitely run through fxp0 but I haven't ever tried to run an MX with no line cards. It seems this should work, but does it, anyone tried in production? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
2013/4/21 JP Velders j...@veldersjes.net There's also SRX-BGP-ADV-LTU for Advanced BGP License for SRX 650 only (Route Reflector), though I wonder how far it'll scale... In SP terms — almost not at all. 1. Branch SRX control plane runs on a single core of the Cavium Octeon, which is not fast (700 Mhz for SRX650). 2. Branch SRX do not support more than 2G of RAM. Moreover about 700M+ is preallocated for flow session table and it is not released even when you switch the box into packed mode (well, at least used to be last time I checked a year or so ago). Plus JUNOS itself. In practice you have just about ~700M of free control plane memory on SRX650. 3. Check out the 3 years old The hunt for a better route reflector threadon this list in the archives. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
Date: Wed, 17 Apr 2013 13:34:29 -0500 From: Richard A Steenbergen r...@e-gerbil.net Subject: Re: [j-nsp] Best route reflector platform I begged them to do this right when that box first came out, but there were no takers. They cripple it in software so the XRE can't be made to run rpd stand-alone and act as a route reflector. Weirdly enough, I spotted these (new) guys in the Juniper GPL: * MX240-RR-AC-B: MX240 route reflector AC bundle * S-RR: Route Reflector (RR) Software license for JCS1200 Spacewise I'd opt for the MX240, but an XRE would be better indeed. There's also SRX-BGP-ADV-LTU for Advanced BGP License for SRX 650 only (Route Reflector), though I wonder how far it'll scale... Anybody try to see if a Route Reflector in Junosphere's VJX worked ? Kind regards, JP Velders ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On Tue, Apr 16, 2013 at 09:26:29AM +1000, Craig Askings wrote: I'd love to see Juniper take the xre200, slap some extra ram into it and call it their route reflector platform. It would be a reasonable compromise between using generic compute and Juniper getting $$$ for selling you some tin. I begged them to do this right when that box first came out, but there were no takers. They cripple it in software so the XRE can't be made to run rpd stand-alone and act as a route reflector. -- Richard A Steenbergen r...@e-gerbil.net http://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] Best route reflector platform
I know that it's not apples and apples but, for what it's worth, Juniper are about to release JunOS Firefly V - a virtualised SRX (running JunOS of course). It's downloadable now with a test license, and can run in VMWare. On 16.04.2013 10:37, Phil Bedard wrote: I think at some point in the future there will be a virtualized Junos which can be deployed on a server, with limitations, but should be something that supports route reflection. Juniper has JCS today but it's obviously not as small of a box as I would like. Phil On 4/15/13 12:20 PM, Jeff Aitken jait...@aitken.com wrote: On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote: ASR1001 with 16GB DRAM. What more do you want, really? Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. --Jeff ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
Any thoughts on using the Vyatta platform (either software or their appliance) as a route reflector ? http://www.vyatta.com/sites/vyatta.com/files/pdfs/Vyatta_app_BGP.pdf Mick On Mon, Apr 15, 2013 at 7:26 PM, Craig Askings caski...@ionetworks.com.auwrote: On 16 April 2013 08:03, Mark Tinka mark.ti...@seacom.mu wrote: What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) You're preaching to the choir. Then again, I wouldn't suggest an ASR9001 for this task either. 8GB is not bad, but you can get 16GB on the ASR1001. Also, the ASR9001 is a PPC-based platform (unlike the Intel Xeon's on the ASR9006/9010), while the ASR1001 is an Intel, if that makes any difference to you. I'd love to see Juniper take the xre200, slap some extra ram into it and call it their route reflector platform. It would be a reasonable compromise between using generic compute and Juniper getting $$$ for selling you some tin. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ 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] Best route reflector platform
Hi Mark, Re the control plane L2VPN interop issues. I believe this is meant to have been fixed in 15.3(2)S. Currently about to start testing it in the lab and will report back. http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/relea se/15.3_2_S/configuration/guide/swmpls.html#wp1285989 Nick -- Nick Ryce Fluency Communications Ltd. e. n...@fluency.net.uk w. http://fluency.net.uk/ t. 0845 874 7000 On 14/04/2013 17:47, Mark Tinka mark.ti...@seacom.mu wrote: On Monday, February 25, 2013 04:56:39 PM Benny Amorsen wrote: Dedicating an MX routing engine to the task seems a bit silly, particularly since it would probably have to be an MX240 due to the limitations of the MX80 RE. A long-standing complaint of mine, for those who've seen most of my ranting about the same on this list. Mind you, I know several networks using M120's and MX240's/480's as route reflectors, simply because those are the smallest boxes with the largest memory for dedicated route reflection. I refuse to give in to that nonesense. On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. ASR1001 with 16GB DRAM. What more do you want, really? My only issue with Cisco route reflectors in a Juniper network (or vice versa) was the lack of compatibility in control plane l2vpn NLRI (where Juniper signals BGP NLRI for l2circuit-style (or l2vpn as it's known at Juniper) while Cisco is expecting VPLS-style, for a VPLS environment. I'm currently getting this confirmed as we're planning a major network upgrade, particularly for compatibility between both vendors re: MCAST-NLRI in NG-MVPN deployments (inet-mvpn as they call it at Juniper). Will report back if I find out anything interesting. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On Monday, April 15, 2013 11:12:53 AM Nick Ryce wrote: Hi Mark, Hello Nick. Re the control plane L2VPN interop issues. I believe this is meant to have been fixed in 15.3(2)S. Currently about to start testing it in the lab and will report back. http://www.cisco.com/en/US/docs/switches/metro/me3600x_38 00x/software/relea se/15.3_2_S/configuration/guide/swmpls.html#wp128598 That's on the ME3600X/3800X. While IOS is not that different from IOS XE, I'm not sure whether they have feature parity (something Cisco have been working on, which is why the code is now numbered the same across many platforms now, i.e., 15.x). Would be good to find out whether they have this in IOS XE, as that is what the ASR1001 will run. I'm waiting for feedback from my SE and will report to the list if there is interest. Having said all that, the main issue wasn't that Cisco never supported VPLS signaling in a BGP control plane. The issue was that the last time I tested this, there was a difference in the BGP Update message size for this SAFI where Juniper are sending 21 bytes based on 'draft-kompella-ppvpn- l2vpn-03' while Cisco are expecting 17 bytes based on RFC 4761, causing session establishment for this SAFI to fail. I believe the motivation for Juniper here was that if you're running an all-Junos backbone, you can signal EoMPLS pw's as well as VPLS pw's using the same code. As Cisco do not support BGP-based signaling of EoMPLS pw's (they insisted on LDP, which is fine by me), one can see where the inter-op failed. Admittedly, I stopped being a VPLS fan many years ago, but I now see a use-case that might require inter-op for this to work, so trying to catch up on how far inter-op development has come re: this topic. Will be eager to hear how your testing goes, Nick. Thanks. 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
Re: [j-nsp] Best route reflector platform
On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote: ASR1001 with 16GB DRAM. What more do you want, really? Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. --Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
Le 15/04/2013 18:20, Jeff Aitken a écrit : On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote: ASR1001 with 16GB DRAM. What more do you want, really? Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. RAML? ;) mh --Jeff ___ 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] Best route reflector platform
On Monday, April 15, 2013 06:20:15 PM Jeff Aitken wrote: Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. :-), in this particular case, I learned to put that aside. But that's exactly my point - if an all-Juniper network wants to run an all-Juniper network including route reflectors, and not feel like they're having their arms twisted, Juniper are really betting the farm that ISP's love for Junos transcends common sense; a notion I feel will soon run its course. It certainly has for me. For route reflection, I'm all about the hardware. I've ran route reflectors on Junos, IOS and IOS XE. IOS language does require extra care given its poorer checks balances than IOS XR or Junos, but for us, that does not outweigh the benefits provided by having the right hardware and cost for the right job. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) You're preaching to the choir. Then again, I wouldn't suggest an ASR9001 for this task either. 8GB is not bad, but you can get 16GB on the ASR1001. Also, the ASR9001 is a PPC-based platform (unlike the Intel Xeon's on the ASR9006/9010), while the ASR1001 is an Intel, if that makes any difference to you. Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. Cisco says ASR1000 line. What does Juniper say? I'm all for choice. Sadly, I'm not the vendors :-(. 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
Re: [j-nsp] Best route reflector platform
On 16 April 2013 08:03, Mark Tinka mark.ti...@seacom.mu wrote: What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) You're preaching to the choir. Then again, I wouldn't suggest an ASR9001 for this task either. 8GB is not bad, but you can get 16GB on the ASR1001. Also, the ASR9001 is a PPC-based platform (unlike the Intel Xeon's on the ASR9006/9010), while the ASR1001 is an Intel, if that makes any difference to you. I'd love to see Juniper take the xre200, slap some extra ram into it and call it their route reflector platform. It would be a reasonable compromise between using generic compute and Juniper getting $$$ for selling you some tin. -- Regards, Craig Askings io Networks Pty Ltd. mobile: 0404 019365 phone: 1300 1 2 4 8 16 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
I think at some point in the future there will be a virtualized Junos which can be deployed on a server, with limitations, but should be something that supports route reflection. Juniper has JCS today but it's obviously not as small of a box as I would like. Phil On 4/15/13 12:20 PM, Jeff Aitken jait...@aitken.com wrote: On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote: ASR1001 with 16GB DRAM. What more do you want, really? Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. --Jeff ___ 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] Best route reflector platform
On Monday, February 25, 2013 04:56:39 PM Benny Amorsen wrote: Dedicating an MX routing engine to the task seems a bit silly, particularly since it would probably have to be an MX240 due to the limitations of the MX80 RE. A long-standing complaint of mine, for those who've seen most of my ranting about the same on this list. Mind you, I know several networks using M120's and MX240's/480's as route reflectors, simply because those are the smallest boxes with the largest memory for dedicated route reflection. I refuse to give in to that nonesense. On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. ASR1001 with 16GB DRAM. What more do you want, really? My only issue with Cisco route reflectors in a Juniper network (or vice versa) was the lack of compatibility in control plane l2vpn NLRI (where Juniper signals BGP NLRI for l2circuit-style (or l2vpn as it's known at Juniper) while Cisco is expecting VPLS-style, for a VPLS environment. I'm currently getting this confirmed as we're planning a major network upgrade, particularly for compatibility between both vendors re: MCAST-NLRI in NG-MVPN deployments (inet-mvpn as they call it at Juniper). Will report back if I find out anything interesting. 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
Re: [j-nsp] Best route reflector platform
On Monday, February 25, 2013 07:20:46 PM Phil Mayers wrote: This depends on routing table size; we manage with an M7i on RE-400, but we've only got ~14k routes in the RIB! The M7i/M10i does have a 4GB RE (RE-1800X1), but I never did get a chance to try it out. Besides, it might still be costly (albeit cheaper than the M120 which can only do 4GB as well anyway). There's also the fact that Juniper will likely cease support for the M7i/M10i at some point. So, YMMV. 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
Re: [j-nsp] Best route reflector platform
On (2013-02-25 15:56 +0100), Benny Amorsen wrote: On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. It is clear-cut, the answer just isn't satisfactory, MX240. JNPR has ESX image for SRX firewall. Why not sell ESX image for route-reflection? I would prefer blazing fast 1RU PC, but I understand that keeping the HW inventory refreshed regularly is a cost, and ESX image is much more practical to sell. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On 02/25/2013 02:56 PM, Benny Amorsen wrote: Which Juniper platform would you pick for a dedicated route reflector? This depends on routing table size; we manage with an M7i on RE-400, but we've only got ~14k routes in the RIB! It does not currently seem obvious which Juniper router is best for dedicated route reflection duty for an MPLS network. It seems that the obvious choice used to be J-series; are they still fast enough in 2013? What about SRX? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
At some point we might see a virtualized Junos especially with all the SDN talk and various applications Juniper may want to split onto dedicated computing hardware. The JCS1200 is still pushed as a RR platform but that's not exactly cheap, but the new RE has 48G of RAM. They also recommend using the PTX as a route reflector since it has a 16G, runs 64-bit Junos, and by default doesn't download BGP routes into the FIB. Now that's a really expensive route reflector. :) I would agree right now the MX240 is probably the best option with the 16G RE. Phil On 2/25/13 10:32 AM, Saku Ytti s...@ytti.fi wrote: On (2013-02-25 15:56 +0100), Benny Amorsen wrote: On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. It is clear-cut, the answer just isn't satisfactory, MX240. JNPR has ESX image for SRX firewall. Why not sell ESX image for route-reflection? I would prefer blazing fast 1RU PC, but I understand that keeping the HW inventory refreshed regularly is a cost, and ESX image is much more practical to sell. -- ++ytti ___ 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] Best route reflector platform
O-Series... *ducks* On 26/02/2013, at 12:56 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Which Juniper platform would you pick for a dedicated route reflector? It does not currently seem obvious which Juniper router is best for dedicated route reflection duty for an MPLS network. It seems that the obvious choice used to be J-series; are they still fast enough in 2013? What about SRX? Dedicating an MX routing engine to the task seems a bit silly, particularly since it would probably have to be an MX240 due to the limitations of the MX80 RE. On the Cisco side the answer is ASR1k, but it seems less clear-cut with Juniper. /Benny ___ 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
