[j-nsp] BGP export policy, group vs neighbor level

[Tom Beecher]

What this is saying:

If you have a GROUP level policy, and make any MODIFICATIONS to INDIVIDUAL
neighbor policies, that individual neighbor will reset.

This means adding OR removing the peer level policy will trigger the reset.

As I recall, it is because there is normally a single BGP Update IO thread
for a given peer group that handles everything for all those peers. If you
override a specific peer , it has to move that to a different thread, which
is intrusive and requires the reset. Conversely, if you remove the
override, it also needs to reset to pull it back into the same update
thread with the others.

On Sat, Feb 5, 2022 at 4:04 AM Raph Tello via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

> Hey,
>
> not really clear to me what that KB is exactly saying.
>
> Does it say:
>
> a) Peer will be reset when it previously hadn’t an individual import/export
> policy statement but the group one and then an individual one is configured
>
> b) Peer will be reset each time it‘s individual policy is touched while
> there is another policy in the group
>
> or
>
> c) Peer is reset the first time it receives it‘s own policy under the group
>
> Unfortunate that this seems to be not really well documented.
>
>
> On Fri 4. Feb 2022 at 20:15, Andrey Kostin <ankost at podolsk.ru> wrote:
>
> > Hi,
> > this KB article just came in:
> >
> >
> https://kb.juniper.net/InfoCenter/index?page=content&id=KB12008&actp=SUBSCRIPTION
> > Symptoms:
> > Why does modifying a policy on a BGP neighbor in a group cause that
> > particular peer to be reset, when another policy is applied for the
> > whole peer group?
> > Solution:
> > Changing the export policy on a member (peer) in a group will cause that
> > member to be reset, as there is no graceful way to modify a group
> > parameter for a particular peer. Junos can gracefully change the export
> > policy, only when it is applied to the complete group.
> >
> > It's not much helpful but just provides a confirmation.
> >
> > Kind regards,
> > Andrey
> >
> > Raph Tello via juniper-nsp писал(а) 2022-02-04 09:33:
> > > I would also like to hear opinions about having ipv4 and ipv6 ebgp peer
> > > sessions in the same group and using the same policy instead of having
> > > two
> > > separate groups and two policies (I saw this kind policy at
> > > https://bgpfilterguide.nlnog.net/guides/small_prefixes/#junos).
> > >
> > > It would nicely pack things together. Could that be considered kind of
> > > new
> > > best practice?
> > >
> > > On Thu 3. Feb 2022 at 16:12, Raph Tello <telloraph at gmail.com> wrote:
> > >
> > >> Hi list,
> > >>
> > >> I wonder what kind of bgp group configuration would allow me to change
> > >> the
> > >> import/export policy of a single neighbor without resetting the
> > >> session of
> > >> this neighbor nor any other session of other neighbors. Similar to
> > >> enabling/disabling features on a single session without resetting the
> > >> sessions of others.
> > >>
> > >> Let‘s say I have a bgp group IX-peers and each peer in that group has
> > >> its
> > >> own import/export policy statement but all reference the same
> > >> policies. Now
> > >> a single IX-peer needs a different policy which is going to change
> > >> local-pref, so I would replace the policy chain of that peer with a
> > >> different one.
> > >>
> > >> Would this cause a session reset because the peer would be moved out
> > >> of
> > >> the update group?
> > >>
> > >> (I wonder mainly about group>peer>policy vs. group>policy vs. each
> > >> peer
> > >> it‘s own group)
> > >>
> > >> - Tello
> > >>
> > > _______________________________________________
> > > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>