[j-nsp] Upgrade from M10i?

[Alexandre Snarskii]

On Tue, Feb 03, 2009 at 12:49:10PM -0600, Richard A Steenbergen wrote:
> On Tue, Feb 03, 2009 at 06:35:34PM +0100, sthaug at nethelp.no wrote:
> > Given the requirement of full BGP routes, I don't believe the EX
> > platform is an acceptable alternative...
> 
> Well, that all depends what you want to do with the BGP routes. The EX
> has more than enough CPU and RAM to take a full table or two and do
> something useful with it, you just can't install more than 12k unicast
> routes into TCAM for hardware forwarding. Of course since Juniper has a
> policy-statement option sitting between the RIB to FIB export, you could 
> very easily export a limited number of routes to hw (i.e. default 
> routes) while still handling full BGP at a protocol level.
> 
> Or at least you could, if this functionality wasn't crippled in
> software. Even though the small EX's have 1GB of DRAM, there is a rlimit
> on rpd memory somewhere around 80MB which causes it to coredump if you
> use too much memory. I can't quite tell if this is just someone being
> silly (assuming you'll never need more ram with only 12k routes), or if
> this is being done intentionally to cripple the product so it can't be
> used as a route reflector (*) (even after you buy a BGP license). Either
> way it's a horrible disservice to the product, since this could be used
> to solve the classic "how to support full bgp on a top-of-rack L3
> aggregation switch" problem without resorting to ghetto Cogentesque 2
> BGP session hackery. If you think this would be useful, please ask 
> Juniper to remove the crippling rlimit and let the device handle full 
> routes.

That is not an rlimit, that is MAXDSIZ parameter of JUNIPER-EX kernel 
configuration. And while it hardcoded to kernel, it can be tweaked 
with the help of loader.conf. 

While this hack works, it has at least one major drawback: loader.conf 
is rewritten during JunOS upgrade, so, I'd prefer not to use it on
production networks..