[j-nsp] bgp peer flapping

[Alexandre Snarskii]

On Thu, Apr 27, 2017 at 03:04:41PM +0100, adamv0025 at netconsultings.com wrote:
> > > >
> > > > How often do we rename bgp group names ?  I don't ever.  Wondering
> > > > if this is something that people do often.
> > > >
> > > Do you never change bgp egress policies too?
> > >  - if you do it at the peer level it has the same effect.
> > 
> > Looks like it is not true since JunOS 15.1 or so.
> That would be great news, can you please share the link. 

Not sure if this change documented anywhere. However, what I see in
reality:

snar at Router> ...wnLinks neighbor 172.31.7.17 | compare rollback 1       
[edit protocols bgp group DownLinks neighbor 172.31.7.17]
- export default_and_google_only;
+ export default_originate_only;

{master}
snar at Router> ... DownLinks neighbor 172.31.7.17 | compare rollback 2    

{master}
snar at Router> show bgp summary | match 172.31.7.17    
172.31.7.17           65534      75147     176660       0       0 1w6d 1:08:30 Establ

As you see, policy was changed and than this change was rolled back
(another change) and session is stable for about two weeks..

> > 
> > > Basically Junos requires you to have each peer in its own group to be
> > > on safe side.
> > 
> > Having each peer in its own group is one of the best ways to shoot
> yourself in
> > the foot: instead of all peers with same egress policies share RIB-Out, in
> this
> > model each one will have its own RIB so memory use will go through the
> > roof.. (well, at least in SP scenario, where most peers need to keep
> full-view
> > in RIB).
> If the box is in a transit role (has to advertise full internet feed to
> multiple peers) then with separate peer group for each peer, depending on
> how may peers you have, this can harm you or not. But on modern code and RP
> you should be able to hold ~15M+ routes so unless you have 25 of such
> transit peers on one box you should be fine.  

... and with all those peers in one group I'm fine running 25 of such 
peers on good old RE-S-2000 with memory utilization of 24%:

Group        Type       Peers     Established    Active/Received/Accepted/Damped
DownLinks    External   28        25         

    DRAM                      3584 MB (4096 MB installed)
    Memory utilization          24 percent
    [...]
    Model                          RE-S-2000

Well, this is an easy case: all peers in this group have the same 
egress policy. However, even in a much more complicated setup, RE-S-2000
still shows memory utilization of 64%, nowhere close to its limits.

> But exactly,  
> Junos places peers to update groups based on actual commonalities in egress
> policies like IOS ONLY within a peer group (and unlike IOS if it changes
> that automatically it resets the peer), but egress policy commonalities are
> not compared across peer groups -so each new peer group is automatically new
> update group (very inefficient indeed). 

.. and so you shall have number of groups as small as possible.