--- Begin Message ---
Mostly in the interest of having better information circulating on this topic:
While the idea below is in the right idea, it's wrong in details. The key
detail here is that anything that causes a peer to not share the same rib-out
with peers in the same group will cause a group split. Threading doesn't have
anything to do with it, but is at least conceptually part of the right thinking.
It's generally safe to update a peer's import policy since that impacts the
per-peer rib-in.
-- Jeff
On 2/8/22, 10:23 AM, "juniper-nsp on behalf of Tom Beecher via juniper-nsp"
<juniper-nsp-boun...@puck.nether.net on behalf of juniper-nsp@puck.nether.net>
wrote:
[External Email. Be cautious of content]
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@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 <ank...@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://urldefense.com/v3/__https://bgpfilterguide.nlnog.net/guides/small_prefixes/*junos__;Iw!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-RqKaXQU$
).
> > >
> > > 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 <tellor...@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@puck.nether.net
> > >
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-xixdBDA$
> >
> >
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
>
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-xixdBDA$
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-xixdBDA$
Juniper Business Use Only
--- End Message ---
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
