Re: [j-nsp] force-64bit

[Tim Hoffman via juniper-nsp]

On Wed, Jun 1, 2016 at 11:09 AM, Saku Ytti  wrote:

> On 1 June 2016 at 20:32, Phil Rosenthal  wrote:
> > I suspect that there is not that high of a risk of bugs due to this
> change, in all likelihood, the only changes required for this was a
> different compiler and perhaps the use of a few 64 bit instead of 32 bit
> variables — but even with a low risk of bugs, if there is no benefit, I’m
> not sure what the point of adding even a low risk of bugs.
>
> This is also not super new feature, it's been in shipping software for
> over two years.


So this means we're half way towards it being stable right
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Tim Hoffman via juniper-nsp]

64bit RPD is newer, and by nature will have more bugs - so don't run this
unless you need it. Check this with "show task memory" - this will show
what you have used of the RPD accessible memory. As Phil notes, you'd need
significant RIB scale (which does exist in larger networks) to require
this...

Enabling this will cause RPD to restart as you kill one process and start
another.

Tim

On Wed, Jun 1, 2016 at 9:22 AM, Phil Rosenthal  wrote:

> I’ll ask the obvious question — do you actually have a ‘need’ for this?
>
> Even on systems with many peers, 5+ full tables, and a full IGP mesh, I
> haven’t seen rpd much over 1GB of ram in use.  64bit rpd would only be
> beneficial if you have a need for a rpd process using more than 4GB of ram.
>
> Is this a theoretical use case, or is there an actual need?
>
> Best Regards,
> -Phil Rosenthal
> > On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> >
> > Hi,
> >
> > has anybody enabled „system processes force-64bit“ on 64bit Junos? Have
> you done this during daily ops or during a maintenance window? According to
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode:
> „You need not restart the routing protocol process (rpd) to use the 64-bit
> mode.“...
> >
> > Thanks in advance for your comments! ;-)
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > Cheers,
> > Theo Voss
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Tim Hoffman | Twitter, Inc.
1355 Market St. | San Francisco, CA | 94103
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Gracefully delete MPLS RSVP LSP

[Tim Hoffman via juniper-nsp]

Increase the route preference on the LSP;
[edit protocols mpls label-switched-path R1-R2-a]
+preference 200;


On Wed, Dec 16, 2015 at 2:29 PM, Masood Ahmad Shah 
wrote:

> Raising LSP metric sounds good to me
>
> On Wed, Dec 16, 2015 at 10:00 PM, tim tiriche 
> wrote:
>
> > Hello,
> >
> > i have 2 LSP to the same destination.
> >
> > 1st LSP name = R1-R2-a
> > 2nd LSP name = R1-R2-b
> >
> > I have link protection enabled.
> >
> > i want to delete the 1st LSP and wanted to know what is a graceful way to
> > do this?
> >
> > Is there a way to shift traffic from 1st LSP to 2nd LSP?  I don't have
> LSP
> > metric and rely on IGP metrics.
> >
> > eg: changing priorities, or can i introduce LSP metrics temporarily to
> 65k?
> >
> > Sincerely,
> > --Tim
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp