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

Jeff Haas jhaas at juniper.net
Tue Feb 8 10:37:15 EST 2022


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-bounces at puck.nether.net on behalf of juniper-nsp at 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 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://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 <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://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!SZ3o6mi78alS5Q0PKix5WQlodQB6H7lLLbN6IQ5IWkt06ynL-x6-ruO-xixdBDA$
    > >
    > >
    > _______________________________________________
    > juniper-nsp mailing list juniper-nsp at 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 at 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


More information about the juniper-nsp mailing list