[j-nsp] /32 host routes on down interfaces

Richard A Steenbergen ras at e-gerbil.net
Fri Apr 23 19:47:58 EDT 2010


On Fri, Apr 23, 2010 at 11:44:30PM +0200, Daniel Roesen wrote:
> It's like that since at least JUNOS 4.3 - I ran (painfully) into it in
> 2001...

I guess I must have just gotten lucky and missed it. :)

> Do any config change in the "chassis" hierarchy => chassisd gets a
> config change trigger => suddenly any DPC boots that is in "offline"
> state as chassisd invokes the chassis power sequencer. JNPR insists
> that this is expected behaviour and reasonable. I don't like
> unexpectedly booting hardware just you do a totally unrelated config
> change, but that's prolly just me weirdo complaining.

Yeah that one used to annoy me as well. Why not just power off the card
in the config, so it stays down? They used to have the power off option
hidden, but now it's exposed at least.

> Or think of the technically unnecessary BGP session resets.

Essentially every unnecessary BGP session reset I've come across has
traced back to the breaking of update replication groups. If you make a
change that causes an existing group to be split into different groups,
the session will flap. If on the other hand you change the config on
every neighbor in that group, or make the neighbor be a group of only
itself by putting something unique in the export policy chain, it won't
flap.

The problem here is feature prioritization. AT&T comes to Juniper and
says "we want some new obscure feature for multicast vpns over L2MP LSPs
for our IPTV product and we'll give you $50mil in business if you do
it", and that is what is going to get worked on. Nobody is tieing
business to making BGP not flap when you change your export policy, so
it gets no attention, even though it is a problem which affects nearly
everyone. I'd be nice if someone at Juniper gave a little time and 
attention to the long tail of customers and their issues, rather than 
throwing out everything that doesn't have a multi-million dollar bribe 
attached.

> To be fair, still, JUNOS really "sucks less".

True, but the question is how long can they keep milking it? Honestly,
other than commit/op/event scripts, I can't think of any feature that
makes me buy Juniper over any other router vendor today that wasn't
written 10+ years ago back when Juniper was small enough to care about
these things. For all their hype about how awesome JUNOS is (and it is),
most of those great little features that make everyone's life better you
couldn't get them to implement today if your life depended on it. 

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


More information about the juniper-nsp mailing list