[j-nsp] autonomous-system N loops L / local-as N loops L

bbird at epik.net bbird at epik.net
Fri Dec 12 01:10:56 EST 2003

Hash: SHA1

I also agree.

There are instances where I've made changes to an import policy on an
a single neighbor, which is part of a bgp group.  In turn, other,
unchanged neighbors, in the same bgp group, had their eBGP sessions
reset due to "unconfigured peer".  The neighbor I changed didn't
reset.  How is that for unexpected behavior?  In fact, the eBGP peers
that were reset, had absolutely no reason, based on the protocol, to
due so.

I was informed by JTAC, this is an "artifact of the design".  Since
JunOS creates an internal group structure, based on common
attributes/options that affect import policy, the peers can be
internally regrouped, so to speak.  As a result, peers that had no
changes made to them, are reset, due to the buckets they are placed
in being rearranged.  You can get some visibility into this by the
operational 'show bgp group' command (NOT in config/edit mode). 
However, without being a developer for JunOS, knowing exactly what
might happen is difficult at best.

I apologize for, what I'm sure is, an oversimplification of this
process. But none the less, this is extremely annoying and
frustrating for the network operator, and his/her peers/customers.

Juniper's response disturbed me even more.  When I explained the
heartache this would cause me, and as you can see, others.  I was
told by JTAC that I am not using the bgp groups, as the developers
had intended.  They explained that only peers sharing common import
policies should be configured as part of a group.  And that if, at
any time, any peers in a member of a group would have an exception to
the group's import policy, it should be originally configured in it's
own separate group.  Either that, or I should be willing to accept
that peer, or other peers in that group being reset.

My intentions were to create groups of bgp neighbors, where either
import, export, or both import and export, policies were common.  And
then in instances where import policies differed, I would override
the group import policy with an explicit import policy on the
neighbor.  Think peering router with dozens of peers, all sharing a
common import/export policy.  With the exception being the occasional
peer who registers routes properly, and you can create explicit
filters, or the occasional peer that needs a little extra insurance
policy :).  When I explained how the Juniper docs in 5.3 support this
behavior, I was told it was a doc. bug, and would be corrected in the


#-----Original Message-----
#From: Phil Rosenthal [mailto:pr at isprime.com] 
#Sent: Thursday, December 11, 2003 10:36 PM
#To: Richard A Steenbergen
#Cc: juniper-nsp at puck.nether.net
#Subject: Re: [j-nsp] autonomous-system N loops L / local-as N loops
#I agree.
#There have been quite a few times that I've made changes to a peer 
#(like putting it in it's own rib-group, or changing the import or 
#export polices), and it had to flap the peer, whereas there were
#times that similar changes were made, and it did not result in
#On Dec 11, 2003, at 9:17 PM, Richard A Steenbergen wrote:
#> On Thu, Dec 11, 2003 at 07:36:51PM -0500, Jeff Wheeler wrote:
#>> Further complicating my trouble-shooting process was that rpd
#>> not
#>> restart on *every* configuration commit. On some occassions I
#>> make
#>> large changes without trouble, and in other instances, the 
#simple act 
#>> of
#>> issuing "commit" after making no changes at all, or simple
#>> such
#>> as adding routing-options static routes, would cause an rpd
#>> From the "wouldn't it be nice" department:
#> Sometimes it is not easy to predict when committing a 
#complicated set 
#> of
#> changes will result in the automatic reset of a BGP session, or
#> automatic soft clearing of a BGP session, or even the automatic 
#> restart of
#> rpd (renames, inserts, group changes, any of a multitude of 
#knobs). It
#> would be nice if there was a way to get a little warning as 
#to how bad
#> your flapping is going to be, perhaps with a command to test the 
#> proposed
#> configuration similar to commit check?
#> Just a thought. :)
#> -- 
#> Richard A Steenbergen <ras at e-gerbil.net>       
#> http://www.e-gerbil.net/ras
#> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA
#> 2CBC)
#> _______________________________________________
#> juniper-nsp mailing list juniper-nsp at puck.nether.net
#> http://puck.nether.net/mailman/listinfo/juniper-nsp
#--Phil Rosenthal
#ISPrime, Inc.
#juniper-nsp mailing list juniper-nsp at puck.nether.net

Version: PGP 8.0.3


More information about the juniper-nsp mailing list