[j-nsp] bgp peer flapping

[adamv0025 at netconsultings.com]

> From: Alexandre Snarskii [mailto:snar at snar.spb.ru]
> Sent: Thursday, April 27, 2017 12:00 PM
> 
> On Thu, Apr 27, 2017 at 08:00:33AM +0100, adamv0025 at netconsultings.com
> wrote:
> > > Aaron Gould [mailto:aaron1 at gvtc.com] Wednesday, April 26, 2017 7:08
> > > PM
> > >
> > > 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. 

> 
> > 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.  
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). 
   
 

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::