[j-nsp] policy question

[Pedro Roque Marques]

Alexander Koch writes:

> that is too bad, yet I can live with it, if...
> my neighbors would not flap if I changed the export policy of the
> 10-15 iBGP neighbors in that current group. I have to say the
> occasional flaps of a specific peer when changing the export policy
> for it is seriously annoying, and I have not yet found any real
> pattern to it. If I change the policy I already have nothing flaps
> -- which is why I tried the 'to neighbor' thing... it would have
> been too nice to be true.

Alexander,
Neighbors flap when the group they are assigned to
changes... i.e. assume that you have 10 neighbors in a group, and you
now want to split these into 2 groups w/ 5 neighbors each. That means
defining one new group and moving the 5 neighbors to this new
group. These 5 neighbors would have to flap as we do not have the
ability to migrate peers between groups w/o reseting sessions.

There is a very significant ammount of state in BGP that is per
group... i.e. all the rib-out and all the outbound advertisement
queues which represent most of the complexity of the protocol
implementation. 

> Any chance you can shed some light on when a single peer flaps when
> changing the export policy? What I would want to do here is add a
> policy in front of the export policy shared with all others.  I
> would not want to split my backbone group into two, makes automatic
> config updates 'creative'.

This would mean that internally junos will split the main group in
2... one w/ existing unaffected neighbors and the new group that you
are defining. I would opt instead to really define 2 groups in the
configuration and explicitly move the peers. The impact will be the
same (session reset) but it will be much clearer in your configuration
which peers are in each group.

> So what happens if I add a policy in front of the one that is
> already there for 1/3 of all iBGP peers in a 'peer group'?

I'm not sure of the specifics that you are asking about... do a "show
bgp group" command and you will see what peers belong to each
operational groups. Adding a policy to all members of an existing
configuration group is handled gracefully... same rib-out is used for
all of them and junos just recalculates the new advertisement state.

Adding a policy to some of the members forces junos to split groups
(since 2 rib-outs are now necessary). Thus the session resets.

> Also what changes if I replace a policy for a single peer?

> Your suggestion of having another group (config- wise) would
> definitely flap all my iBGP neighbors, which I feel is inacceptable
> and unneeded.

All the ones that migrate groups.

> But then I surely do not have the full view of the
> implications, so help me to understand it, please.

I hope this clarifies the current behaviour.

> Ah, yeah, we are running 6.3 still

The changes to the group membership assignement algorithm that you saw
discussed in the mailing list are included in 6.3.

Still... if you do your config changes such that you explicitly define
groups and members w/ the same export policies then the software is
not making any "guesses" which used to be a bit simplistic before 6.3.

> Any hints on what has changed
> since then up to 7.2R2 would be greatly appreciated.

I would recomend you to ask the juniper SE that works w/ you to
compile the full list of changes. If you have questions regarding BGP
in particular i can try to help you but i don't have a system wide
view.

regards,
  Pedro.