[j-nsp] Juniper route age reset behavior

Thu Apr 19 15:46:32 EDT 2018

Hi Jeff,

Thanks so much for your detailed explanation and invitation to comment. I look forward to some configurable option(s) wrt to route age timers.

Jeff> But people on older boxes that find their memory signature gets knocked over the edge for something they don't require get... cranky.

Ahah, yes. :)

Jeff> The motivations for the change was to permit all changes impacting route properties to be reflected in the route's age.  This is very useful for troubleshooting, such as the resolver, policy, etc.

And that’s very good information to have.

Jeff> Thus, a knob is being considered to have both the "only on-the-wire" impact or the "whenever the route's properties change" impact.

Can I suggest a knob with three options – the two you mention, plus an option to maintain /both/ timers? If that’s not feasible (for reasons you already eluded), so be it.

My preference is indeed for ‘best of both’.

Jeff> The question being: What's the default?

As you indicated, quite a few folk on older hardware will be sensitive to resource impacts.

I suggest the default should be on-the-wire as this incurs the minimal CPU hit, as I understand it.

1.       On-the-wire BGP updates will incur BGP route processing penalties in any case – this CPU cost is unavoidable.

2.       Route property changes will be at least as frequent as BGP updates, but possibly more frequent, so could consume more CPU cycles than are necessary.

3.       Maintaining both timers has a CPU and RAM cost I’m very happy to pay. :)

I’ve flagged this thread to my colleagues in GÉANT and invited them to chime in, however I can say with confidence ‘best of both’ is something we’d enable if it were available to us.

Best regards,

Niall

From: Jeff Haas [mailto:jhaas at juniper.net] 
Sent: 19 April 2018 20:27
To: Niall Donaghy <niall.donaghy at geant.org>
Cc: Magnus Bergroth <bergroth at nordu.net>; juniper-nsp <juniper-nsp at puck.nether.net>
Subject: Re: [j-nsp] Juniper route age reset behavior

[Speaking with my Juniper developer hat firmly on...] 

On Jan 26, 2018, at 8:21 PM, Niall Donaghy <niall.donaghy at geant.org <mailto:niall.donaghy at geant.org> > wrote:

Hello Magnus,

I would also prefer the old behaviour was retained as default, and that a configuration knob was provided to enable the new behaviour.

My arguments to Juniper would be:

- It should be a low-cost effort to make the code change so that TWO timers are kept, as the code already exists. Increased RAM utilisation ought to be slight.

Since we still live as much as humanly possible to "One JUNOS", we have to still be sensitive to changes that have per-route cost increases in terms of memory or CPU.  Your observation is absolutely correct that it's an easy change.  But people on older boxes that find their memory signature gets knocked over the edge for something they don't require get... cranky.

- It should be fairly trivial to include a configuration knob to select the behaviour you want; ideally the default is the old behaviour, but either way achieves the same goal.

- BGP route age timer should reflect changes in the eBGP route advertisement, because:
- Changes in your internal network which affect BGP route selection or next hop interface are a holistic function of your router's internal routing.
- The BGP route's age is, intuitively, the age since the route was received from the eBGP speaker, ie: RIB-In, not inet.0 (or whichever table).

- Why not give the best of both? Retain two route age timers and display both in the CLI. 

We haven't found this change in behaviour to adversely affect us in GEANT, but have the view that having both timers would be ideal.

There was a small amount of contention over the underlying change that caused this impact.  However, as you see, it managed to get out into the field anyway.  Work is now under-way to permit the old behavior to be restored.

The motivations for the change was to permit all changes impacting route properties to be reflected in the route's age.  This is very useful for troubleshooting, such as the resolver, policy, etc.  However, as noted in this thread, it impacts the ability to see when on-the-wire BGP is being impacted for a specific prefix.  The granularity of BGP messages in our counters isn't sufficient to really narrow such issues down.

Thus, a knob is being considered to have both the "only on-the-wire" impact or the "whenever the route's properties change" impact.

The question being: What's the default?

I'm soliciting the opinions of the operational community to help make that decision.  Please feel free to rally as many opinions as you feel fit to. :-)

-- Jeff

Best regards,
Niall

Niall Donaghy
Senior Network Engineer
GÉANT
T: +44 (0)1223 371393
M: +44 (0) 7557770303
Skype: niall.donaghy-dante
PGP Key ID: 0x77680027
nic-hdl: NGD-RIPE

Networks • Services • People 
Learn more at  <http://www.geant.org/> www.geant.org
GÉANT is the collective trading name of the GÉANT Association and GEANT Limited.

GÉANT Vereniging (Association) is registered in the Netherlands with the Chamber of Commerce in Amsterdam. Registration number: 40535155. Registered office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands.
GEANT Limited  is registered in England & Wales. Registration number: 2806796. Registered office: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK.

-----Original Message-----
From: juniper-nsp [ <mailto:juniper-nsp-bounces at puck.nether.net> mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Magnus Bergroth
Sent: 26 January 2018 11:45
To: juniper-nsp < <mailto:juniper-nsp at puck.nether.net> juniper-nsp at puck.nether.net>
Subject: [j-nsp] Juniper route age reset behavior

Hi

We have seen a change in how junos handles age in command "show route".
In Junos 15.1R bgp routes age told you how long the route had been present in the routing table. If you have a dual homed customer bgp age timer showed how long time ago the customer advertised the route. Very practical to see how stable the customer connection has been.

In 15.F and new releases this has been changed so that any change to the route will reset the age time. If a route goes from inactive to active "route age" gets reset. If your igp changes so the outgoing interface changes the "route age" gets reset.

We been trying to get juniper to change back the behavior but Juniper engineering thinks it's now working as it should.

We haven't been able to find any RFC the describes route age. The only argument towards Juniper that we have is that they are changing default behavior.

Are there any one else that has seen this new "route age" behavior and have any open cases with Juniper, or have any good argument that we can throw at Juniper?

Kindly

Magnus Bergroth
_______________________________________________
juniper-nsp mailing list  <mailto:juniper-nsp at puck.nether.net> juniper-nsp at puck.nether.net  <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=T-sa37bq-QjZoC4jLQ0QAtNyQAPQqGdTNBvhTirOBqc&m=H99vB5H3K1EP7Fk3XPjecrwUgovy43-C88QKYaFQh5s&s=vzel9uIG-GeEDJ6COhOK9OxaAJA7lHNl0PotOwuNWaw&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=T-sa37bq-QjZoC4jLQ0QAtNyQAPQqGdTNBvhTirOBqc&m=H99vB5H3K1EP7Fk3XPjecrwUgovy43-C88QKYaFQh5s&s=vzel9uIG-GeEDJ6COhOK9OxaAJA7lHNl0PotOwuNWaw&e=
_______________________________________________
juniper-nsp mailing list  <mailto:juniper-nsp at puck.nether.net> juniper-nsp at puck.nether.net
 <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=T-sa37bq-QjZoC4jLQ0QAtNyQAPQqGdTNBvhTirOBqc&m=H99vB5H3K1EP7Fk3XPjecrwUgovy43-C88QKYaFQh5s&s=vzel9uIG-GeEDJ6COhOK9OxaAJA7lHNl0PotOwuNWaw&e=> https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_juniper-2Dnsp&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=T-sa37bq-QjZoC4jLQ0QAtNyQAPQqGdTNBvhTirOBqc&m=H99vB5H3K1EP7Fk3XPjecrwUgovy43-C88QKYaFQh5s&s=vzel9uIG-GeEDJ6COhOK9OxaAJA7lHNl0PotOwuNWaw&e=