The interest of a peer-group is mutualisation between its neighbours:
- mutualisation of the configuration
- mutualisation of the OUTBOUND route filtering process
and this is true for all OSes (not only JunOS).
As wrote markw, if you add a specific EXPORT policy to a neighbour, it «breaks» the peer-group: the by-design common outbound filtering process for all the neighbours in the peer-group cannot be let as is. Therefore, this neighbour is extracted from the peer-group and put in a specific dedicated new «virtual» peer-group and therefore, flaps. Same thing if you remove its specific export knob.
But, no flap once it's in its own virtual peer-group (that is, if you change later the content of the export policy of this neighbour).
Actually in the configuration, this neighbour continues to be displayed in the same common peer-group, BUT if you check what's happening under the hood, you will see that in reality it's in its own one:
show bgp group
This command doesn't show what's configured, but what's really active under the hood, with the neighbours and the policies.
And you will see two different peer groups if you have one peer-group configured, in which one neighbour has its own specific export policy. With the same name, but not with the same index number (and not the same export policy chain and not the same neighbours of course).
------------------------------
Olivier Benghozi
------------------------------
Original Message:
Sent: 08-19-2021 04:19
From: Mark Weijers
Subject: Add routing policy to BGP Group peer cause peer flapping
The above statements are correct, however they are not mentioning 1 scenario in which a peer flap WILL occur:
What Juniper does is that it puts all peers that have identical policies in a peer group (might not be the formal name). This is not necessarily the same as the group you configured under "protocols bgp", but any peer that shares identical policies gets virtually placed in such a group.
If you then change the policies of 1 of the neighbors, while the other neighbors remain the same that basically splits that 1 neighbor out of that virtual group and that, as a result, will cause your BGP session to flap. This is because for the Juniper router you are "moving it into a new BGP group" so to say.
If you expect to make neighbor specific changes in a group it would be recommended to have unique policies for each neighbor in order to ensure they are all in a virtual group of their own and never need to "split off" from the pack. Alternatively you can make sure you configure the policies at a group level to make sure they "stay together", and that will also make the session stay up.
So for an individual neighbor, it is true that a policy change will not cause a flap to occur, but if there is a group of neighbors with identical policies, and you adjust 1 neighbor to no longer be identical, it will indeed flap because it gets moved out of the "group"
Original Message:
Sent: 08-18-2021 00:21
From: Unknown User
Subject: Add routing policy to BGP Group peer cause peer flapping
Hi! Experts
If we add routing policy to a peer (the peer previously with no policy applied) in BGP group, this will cause that peer's bgp status flapping. I heard this is expected behaviour but want to know what's the logical behind this design.
Thanks for your help