Mailing List Archive

On Mon, Sep 29, 2003 at 12:15:45PM +0100, Umar.Ahmed@equinoxsolutions.com wrote:
> Just trawled through the Juniper website trying to find out if JunOS
> supports anything similar to the "on-startup" or "wait-for-bgp" command.
> This makes IS-IS wait for BGP to converge before clearing the overload bit.

Doesn't exist (sadly).


Best regards,
Daniel

On Mon, Sep 29, 2003 at 06:21:18PM +0200, Daniel Roesen wrote:
> On Mon, Sep 29, 2003 at 12:15:45PM +0100, Umar.Ahmed@equinoxsolutions.com wrote:
> > Just trawled through the Juniper website trying to find out if JunOS
> > supports anything similar to the "on-startup" or "wait-for-bgp" command.
> > This makes IS-IS wait for BGP to converge before clearing the overload bit.
>
> Doesn't exist (sadly).

Sorry, I have to clarify: something like "on-startup" exists
as "set protocols isis overload [timeout <seconds>]". But there is
nothing which watches for BGP keepalives in order to have a heuristic
for "BGP converged".


Best regards,
Daniel

On Monday, September 29, 2003, at 10:23 AM, Daniel Roesen wrote:
>
> Sorry, I have to clarify: something like "on-startup" exists
> as "set protocols isis overload [timeout <seconds>]". But there is
> nothing which watches for BGP keepalives in order to have a heuristic
> for "BGP converged".

That's probably a good thing, given the amount of churn in
the global routing system it's unlikely any full Internet
BGP speakers receive [post Open Confirm] "keepalives"
anyways (i.e., if the implementations are optimized such
that normal updates are counted as keepalives).

Implementations would be well served by employing the End-of-
RIB Marker for this purpose (even if Graceful Restart's not
being used), assuming peers support it, else falling back to
some reasonable fixed timer (say 120 seconds) or Loc-RIB
size.

-danny

Daniel,

I thought on-startup was only supported by the erx series routers ?

-----Original Message-----
From: Daniel Roesen
To: juniper-nsp@puck.nether.net
Sent: 29/09/2003 17:23
Subject: Re: [j-nsp] ISIS overload bit settings

On Mon, Sep 29, 2003 at 06:21:18PM +0200, Daniel Roesen wrote:
> On Mon, Sep 29, 2003 at 12:15:45PM +0100,
Umar.Ahmed@equinoxsolutions.com wrote:
> > Just trawled through the Juniper website trying to find out if JunOS
> > supports anything similar to the "on-startup" or "wait-for-bgp"
command.
> > This makes IS-IS wait for BGP to converge before clearing the
overload bit.
>
> Doesn't exist (sadly).

Sorry, I have to clarify: something like "on-startup" exists
as "set protocols isis overload [timeout <seconds>]". But there is
nothing which watches for BGP keepalives in order to have a heuristic
for "BGP converged".


Best regards,
Daniel
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp


------------------------------------------------------------------------------------------
Equinox Converged Solutions Limited.
Tel: +44 (0)1252 405 600
http://www.equinoxsolutions.com

IMPORTANT NOTICE:
This message is intended solely for the use of the Individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately.
If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Equinox Converged Solutions Limited.
Equinox Converged Solutions Limited accepts no responsibility for loss or damage arising from its use, including damage from virus.
------------------------------------------------------------------------------------------

On 29.09.2003 21:13:29 +0000, Umar.Ahmed@equinoxsolutions.com wrote:
> Daniel,
>
> I thought on-startup was only supported by the erx series routers ?

No,

[edit]
lyngbol@foo# set protocols isis overload timeout 60

[edit]
lyngbol@testnxj1# show protocols isis overload
timeout 60;


/Michael

> -----Original Message-----
> From: Daniel Roesen
> To: juniper-nsp@puck.nether.net
> Sent: 29/09/2003 17:23
> Subject: Re: [j-nsp] ISIS overload bit settings
>
> On Mon, Sep 29, 2003 at 06:21:18PM +0200, Daniel Roesen wrote:
> > On Mon, Sep 29, 2003 at 12:15:45PM +0100,
> Umar.Ahmed@equinoxsolutions.com wrote:
> > > Just trawled through the Juniper website trying to find out if JunOS
> > > supports anything similar to the "on-startup" or "wait-for-bgp"
> command.
> > > This makes IS-IS wait for BGP to converge before clearing the
> overload bit.
> >
> > Doesn't exist (sadly).
>
> Sorry, I have to clarify: something like "on-startup" exists
> as "set protocols isis overload [timeout <seconds>]". But there is
> nothing which watches for BGP keepalives in order to have a heuristic
> for "BGP converged".
>
>
> Best regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> ------------------------------------------------------------------------------------------
> Equinox Converged Solutions Limited.
> Tel: +44 (0)1252 405 600
> http://www.equinoxsolutions.com
>
> IMPORTANT NOTICE:
> This message is intended solely for the use of the Individual or organisation to whom it is addressed. It may contain privileged or confidential information. If you have received this message in error, please notify the originator immediately.
> If you are not the intended recipient, you should not use, copy, alter, or disclose the contents of this message. All information or opinions expressed in this message and/or any attachments are those of the author and are not necessarily those of Equinox Converged Solutions Limited.
> Equinox Converged Solutions Limited accepts no responsibility for loss or damage arising from its use, including damage from virus.
> ------------------------------------------------------------------------------------------
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

--
Michael Lyngb?l -- michael at lyngbol dot dk
Network Architect, AS3292 TDC, IP?backbone

http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/ht
ml/isis-summary30.html#1014637


Note that the default is 0, meaning the OL condition is persistent. With a
time-out of say 30 seconds, the OL bit should clear 30 seconds after rpd has
started. A commit does not restarted RPD. To test either reboot or issue
request restart routing.

It is not called "on-startup", but because rpd starts as part of a router's
start up, it functions like a start up option.

HTHs.



> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Umar.Ahmed@equinoxsolutions.com
> Sent: Monday, September 29, 2003 1:13 PM
> To: dr@cluenet.de; juniper-nsp@puck.nether.net
> Subject: RE: [j-nsp] ISIS overload bit settings
>
>
> Daniel,
>
> I thought on-startup was only supported by the erx series routers ?
>
> -----Original Message-----
> From: Daniel Roesen
> To: juniper-nsp@puck.nether.net
> Sent: 29/09/2003 17:23
> Subject: Re: [j-nsp] ISIS overload bit settings
>
> On Mon, Sep 29, 2003 at 06:21:18PM +0200, Daniel Roesen wrote:
> > On Mon, Sep 29, 2003 at 12:15:45PM +0100,
> Umar.Ahmed@equinoxsolutions.com wrote:
> > > Just trawled through the Juniper website trying to find
> out if JunOS
> > > supports anything similar to the "on-startup" or "wait-for-bgp"
> command.
> > > This makes IS-IS wait for BGP to converge before clearing the
> overload bit.
> >
> > Doesn't exist (sadly).
>
> Sorry, I have to clarify: something like "on-startup" exists
> as "set protocols isis overload [timeout <seconds>]". But
> there is nothing which watches for BGP keepalives in order to
> have a heuristic for "BGP converged".
>
>
> Best regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>
>
>
>
> --------------------------------------------------------------
> ----------------------------
> Equinox Converged Solutions Limited.
> Tel: +44 (0)1252 405 600
> http://www.equinoxsolutions.com
>
> IMPORTANT NOTICE:
> This message is intended solely for the use of the Individual
> or organisation to whom it is addressed. It may contain
> privileged or confidential information. If you have received
> this message in error, please notify the originator
> immediately. If you are not the intended recipient, you
> should not use, copy, alter, or disclose the contents of this
> message. All information or opinions expressed in this
> message and/or any attachments are those of the author and
> are not necessarily those of Equinox Converged Solutions
> Limited. Equinox Converged Solutions Limited accepts no
> responsibility for loss or damage arising from its use,
> including damage from virus.
> --------------------------------------------------------------
> ----------------------------
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>

On Mon, Sep 29, 2003 at 11:40:04AM -0600, Danny McPherson wrote:
|
| On Monday, September 29, 2003, at 10:23 AM, Daniel Roesen wrote:
| >
| >Sorry, I have to clarify: something like "on-startup" exists
| >as "set protocols isis overload [timeout <seconds>]". But there is
| >nothing which watches for BGP keepalives in order to have a heuristic
| >for "BGP converged".
|
| That's probably a good thing, given the amount of churn in
| the global routing system it's unlikely any full Internet
| BGP speakers receive [post Open Confirm] "keepalives"
| anyways (i.e., if the implementations are optimized such
| that normal updates are counted as keepalives).
|
| Implementations would be well served by employing the End-of-
| RIB Marker for this purpose (even if Graceful Restart's not
| being used), assuming peers support it, else falling back to
| some reasonable fixed timer (say 120 seconds) or Loc-RIB
| size.

agreed - still you'd need some heuristics to have some tolerance
against faulty states like e.g. "End-of-RIB Marker || Keepalives
received on 80% of all BGP sessions"

/hannes