[j-nsp] Why JUNOS need re-establish neighbour relationship when configuring advertise-inactive

[James Bensley]

On 16 July 2017 at 12:23, Daniel Roesen <dr at cluenet.de> wrote:
> On Sat, Jul 15, 2017 at 12:33:16PM +0300, Saku Ytti wrote:
>> Usually JunOS (like other platforms) resets session when you have to
>> change update group. If you'd have multiple neighbours under TO-VRx
>> sharing same export-policy and you'd add 'advertise-inactive' under
>> one of the neighbours, not under the group directly. I would expect to
>> see reset.
>
> Which is technically unnecessary, so a bug. Or extremely sloppy
> programming causing operational impact for no good reason. I can't
> accept this behaviour as "industry standard".

This thread jogged my memory of an issue we had a while back that is
similar; bounced an eBGP inet-vpn session (Inter-AS Opt B) and the
session on that PE to both it's RR's bounced too.

It's this basicaly:
http://www.juniper.net/documentation/en_US/junos/topics/example/bgp-vpn-session-flap-prevention.html

The recommendation is to set up a passive BGP session to a
non-existing peer so that there is always a configure eBGP peer (even
thought the BGP FSM is not == "Established"), in that instance that
was one single eBGP inet-vpn peer to bouncing the BGP session mean the
last (only) eBGP inet-vpn session when down toggling the
instance.inet.0 <> bgp.l3vpn.0 redistribution.

An archaic feature of the Junos BGP implementation, not really carrier
grade stuff if you ask me. Just like some of their run-to-completion
code.

We have seen on IOS many times when activating a new
NLRI/address-family between two peers the router will immediately
bounce the session so that the new NLRI can be negotiated and used,
rather than waiting for the session to be manually cleared for
example. I find that quite annoying. Does anyone know if Junos has the
same behaviour?

Cheers,
James.