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
2013/4/24 Richard A Steenbergen 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
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
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 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] Best route reflector platform
2013/4/21 JP Velders > > 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 > 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 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] 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
wrote:
> On 16 April 2013 08:03, Mark Tinka 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
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" 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
On Tuesday, April 16, 2013 02:37:27 AM 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. That discussion has been going on for a long time now. And the key reason for that idea, apparently, was to support remote labs and testing so folk don't have to buy lab gear to spend time securing lab time at Sunnyvale/Westford, e.t.c. I did ask whether there would be plans to let folk buy that hardware, and the answer was an emphatic "No". But then again, that was 2010. 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
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" 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 16 April 2013 08:03, Mark Tinka 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
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
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 Mon, Apr 15, 2013 at 04:20:15PM +, Jeff Aitken 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.
I've lost count of the number of network operators who have begged for
Juniper to release a decent route reflector platform, for more years
than I can count, and they have steadfastly refused to do so. In fact,
the more we beg for an incredibly simple, cheap, effective, and known
working product (e.g. take the JCS and put it on a single 1U PC instead
of a $%^(*ing 12U blade server), the more they insist that what we
REALLY need is something much more fucked-in-the-head like a virtualized
SRX. This of course has zero interest from anyone attached to it, and
thus nothing happens.
Apparently all the big/slow/stupid carriers are satisfied with buying
stub MX240s and RE-1800x4's for their route reflectors. And since
they're really the only ones throwing money at Juniper in this category
(I guess enterprises don't need dedicated route reflectors :P), we're
all but guaranteed that they will continue to ignore every other network
operator on the planet who is begging them to do better.
Le sigh.
--
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] Best route reflector platform
> 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, Funniest point in this talk is that it happens at the same time as the SDN hysteria gains momentum. Looks like we'll rather end up with the whole Internet switched to static routes and FBF-filters managed through a centralized "controller", than a more or less ideal (aka pure piece of control plane software) BGP reflector platform will be released by one of the two vendors :) ___ 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
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
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" 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, 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 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
O-Series... *ducks* On 26/02/2013, at 12:56 AM, Benny Amorsen 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
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" 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
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
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
