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

[bbird at epik.net]

-----BEGIN PGP SIGNED MESSAGE-----
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
future.


Ben  

#-----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
L
#
#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
other 
#times that similar changes were made, and it did not result in
similar 
#flapping.
#
#
#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
would 
#>> not
#>> restart on *every* configuration commit. On some occassions I
could 
#>> make
#>> large changes without trouble, and in other instances, the 
#simple act 
#>> of
#>> issuing "commit" after making no changes at all, or simple
changes 
#>> such
#>> as adding routing-options static routes, would cause an rpd
restart.
#>
#>> 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
the
#> 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
F8B1 
#> 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
#http://puck.nether.net/mailman/listinfo/juniper-nsp
#

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP9lcd9FQh6ARB7TZEQLEPgCeOiIX6uq5Pg59Y9Ave0RNEPTIz/4An2JR
E7vZ4bDSmAQSSyRO+PqeA+eB
=8nP4
-----END PGP SIGNATURE-----