Mailing List Archive

Please report it to the JTAC. I have just tested this configuration
and saw no rpd restart.

me@router# run monitor start messages

[edit]
me@router# set routing-options autonomous-system 200 loops 2

[edit]
me@router# commit
Dec 11 15:03:37 router mgd[25131]: UI_COMMIT: User 'me' performed
commit: no
comment
commit complete

[edit]
me@router#

Gary

On Dec 11, 2003, at 2:52 PM, Jeff Wheeler wrote:

> Is anyone using routing-options autonomous-system N loops L on any of
> their routers? I am experiencing a problem that I believe is a bug with
> this configuration. When using '2' or '1' as the value for L, config
> commits cause rpd to choke and restart. The following is syslogged..:
>
> Dec 11 14:47:49 bordercore3.chcgil02 mgd[4630]: UI_COMMIT: User 'root'
> performed commit: no comment
> Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]:
> UI_CONFIGURATION_ERROR:
> Process: rpd, path: <none>, statement: <none>, Invalid loop count
> configured
> Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]: RPD_EXIT: Exit
> rpd[4675] version 6.1R2.2 built by builder on 2003-11-21 23:53:00 UTC,
> caller 809f3cb
> Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4675) exited
> with status=0 Normal Exit
> Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4928) started
>
> Obviously the rpd restart causes my routing protocols to restart, which
> flaps eBGP peers and causes havoc on the IGP as well. The only cure
> I've
> found was to simply remove the loops statement (which was a challenge
> in
> and of itself, thanks, CLI!). This complicates my configuration, as I
> really do want to receive (some) routes over eBGP sessions containing
> my
> own as number one or more times! :-(
>
> --
> Jeff at Reflected Networks
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

gtate@juniper.net (Gary Tate) writes:

Gary,
This is probably same as 41157.

The error message indicates that Jeff is attempting to configure the
same AS w/ two different loops settings. For instance top level as 200
and "local-as 200 loops 10".

This configuration should be rejected.

Pedro.

> Please report it to the JTAC. I have just tested this configuration
> and saw no rpd restart.
>
> me@router# run monitor start messages
>
> [edit]
> me@router# set routing-options autonomous-system 200 loops 2
>
> [edit]
> me@router# commit
> Dec 11 15:03:37 router mgd[25131]: UI_COMMIT: User 'me' performed
> commit: no
> comment
> commit complete
>
> [edit]
> me@router#
>
> Gary
>
> On Dec 11, 2003, at 2:52 PM, Jeff Wheeler wrote:
>
> > Is anyone using routing-options autonomous-system N loops L on any of
> > their routers? I am experiencing a problem that I believe is a bug with
> > this configuration. When using '2' or '1' as the value for L, config
> > commits cause rpd to choke and restart. The following is syslogged..:
> >
> > Dec 11 14:47:49 bordercore3.chcgil02 mgd[4630]: UI_COMMIT: User 'root'
> > performed commit: no comment
> > Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]:
> > UI_CONFIGURATION_ERROR:
> > Process: rpd, path: <none>, statement: <none>, Invalid loop count
> > configured
> > Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]: RPD_EXIT: Exit
> > rpd[4675] version 6.1R2.2 built by builder on 2003-11-21 23:53:00 UTC,
> > caller 809f3cb
> > Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4675) exited
> > with status=0 Normal Exit
> > Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4928) started
> >
> > Obviously the rpd restart causes my routing protocols to restart, which
> > flaps eBGP peers and causes havoc on the IGP as well. The only cure
> > I've
> > found was to simply remove the loops statement (which was a challenge
> > in
> > and of itself, thanks, CLI!). This complicates my configuration, as I
> > really do want to receive (some) routes over eBGP sessions containing
> > my
> > own as number one or more times! :-(
> >
> > --
> > Jeff at Reflected Networks
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

Thanks Pedro

On Dec 11, 2003, at 3:24 PM, Pedro Roque Marques wrote:

> gtate@juniper.net (Gary Tate) writes:
>
> Gary,
> This is probably same as 41157.
>
> The error message indicates that Jeff is attempting to configure the
> same AS w/ two different loops settings. For instance top level as 200
> and "local-as 200 loops 10".
>
> This configuration should be rejected.
>
> Pedro.
>
>> Please report it to the JTAC. I have just tested this configuration
>> and saw no rpd restart.
>>
>> me@router# run monitor start messages
>>
>> [edit]
>> me@router# set routing-options autonomous-system 200 loops 2
>>
>> [edit]
>> me@router# commit
>> Dec 11 15:03:37 router mgd[25131]: UI_COMMIT: User 'me' performed
>> commit: no
>> comment
>> commit complete
>>
>> [edit]
>> me@router#
>>
>> Gary
>>
>> On Dec 11, 2003, at 2:52 PM, Jeff Wheeler wrote:
>>
>>> Is anyone using routing-options autonomous-system N loops L on any of
>>> their routers? I am experiencing a problem that I believe is a bug
>>> with
>>> this configuration. When using '2' or '1' as the value for L, config
>>> commits cause rpd to choke and restart. The following is syslogged..:
>>>
>>> Dec 11 14:47:49 bordercore3.chcgil02 mgd[4630]: UI_COMMIT: User
>>> 'root'
>>> performed commit: no comment
>>> Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]:
>>> UI_CONFIGURATION_ERROR:
>>> Process: rpd, path: <none>, statement: <none>, Invalid loop count
>>> configured
>>> Dec 11 14:47:50 bordercore3.chcgil02 rpd[4675]: RPD_EXIT: Exit
>>> rpd[4675] version 6.1R2.2 built by builder on 2003-11-21 23:53:00
>>> UTC,
>>> caller 809f3cb
>>> Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4675) exited
>>> with status=0 Normal Exit
>>> Dec 11 14:47:50 bordercore3.chcgil02 init: routing (PID 4928)
>>> started
>>>
>>> Obviously the rpd restart causes my routing protocols to restart,
>>> which
>>> flaps eBGP peers and causes havoc on the IGP as well. The only cure
>>> I've
>>> found was to simply remove the loops statement (which was a challenge
>>> in
>>> and of itself, thanks, CLI!). This complicates my configuration, as I
>>> really do want to receive (some) routes over eBGP sessions containing
>>> my
>>> own as number one or more times! :-(
>>>
>>> --
>>> Jeff at Reflected Networks
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

On Thu, 2003-12-11 at 18:38, Gary Tate wrote:
> Hi Jeff - can give me your config and can you do a show version brief.
> I'd like to try and recreate this in the lab here.

Unfortunately I've already removed the autonomous-system N loops L from
my configuration, which was actually quite challenging as the CLI would
not co-operate. Only by deleting routing-options autonomous-system and
creating it again, was I able to alter the value from loops 2. I had
this trouble on both my affected boxes, running 6.1R1.4 and 6.1R2.2.

I also experience the same rpd restart problem on JunOS 6.1R1.4. One box
was upgraded to 6.1R2.2 to try to fix this problem, without success.

There is only one routing-instance on both affected boxes, and the value
used for loops in routing-options autonomous-system is the equal to or
greater than any configured protocol bgp group foo local-as loops value.

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.

--
Jeff at Reflected Networks

To delete the loops you do the following:

delete routing options autonomous-system loops

There is a PR 41157 open for this bug if you see another core/rpd
restart you should open a case with JTAC so they can add the
information to the PR.

Gary

On Dec 11, 2003, at 4:36 PM, Jeff Wheeler wrote:

> On Thu, 2003-12-11 at 18:38, Gary Tate wrote:
>> Hi Jeff - can give me your config and can you do a show version brief.
>> I'd like to try and recreate this in the lab here.
>
> Unfortunately I've already removed the autonomous-system N loops L from
> my configuration, which was actually quite challenging as the CLI would
> not co-operate. Only by deleting routing-options autonomous-system and
> creating it again, was I able to alter the value from loops 2. I had
> this trouble on both my affected boxes, running 6.1R1.4 and 6.1R2.2.
>
> I also experience the same rpd restart problem on JunOS 6.1R1.4. One
> box
> was upgraded to 6.1R2.2 to try to fix this problem, without success.
>
> There is only one routing-instance on both affected boxes, and the
> value
> used for loops in routing-options autonomous-system is the equal to or
> greater than any configured protocol bgp group foo local-as loops
> value.
>
> 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.
>
> --
> Jeff at Reflected Networks
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

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@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

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@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@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
--Phil Rosenthal
ISPrime, Inc.

-----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@isprime.com]
#Sent: Thursday, December 11, 2003 10:36 PM
#To: Richard A Steenbergen
#Cc: juniper-nsp@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@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@puck.nether.net
#> http://puck.nether.net/mailman/listinfo/juniper-nsp
#>
#>
#--Phil Rosenthal
#ISPrime, Inc.
#
#_______________________________________________
#juniper-nsp mailing list juniper-nsp@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-----