Re: [j-nsp] DHCPv6 client on SRX210 - IPv6 forwarding breaks at lease expiration

[will]

On Sat, Aug 01, 2015 at 09:28:50AM -0700, Chris Woodfield wrote:
> TL;DR: IPv6 forwarding breaks when my DHCPv6 client lease expires, even 
> though CLI output claims it’s been renewed.

I expereinced this too on SRX240H (not H2) running 12.1X46-D35 on comcast cable.

Hopefully it's this:
https://prsearch.juniper.net/InfoCenter/index?page=prcontent=PR1084269

fixed in -D40 released last month as noted:
http://www.juniper.net/techpubs/en_US/junos12.1x46/information-products/topic-collections/release-notes/12.1x46/topic-82926.html#cbbu-rn-junos-srx-j-issues

I've got a 12-day dhcpv6 lease time though so it will take a couple weeks to 
see if it's really fixed.

-Will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Raphael Mazelier]

Le 08/10/15 18:46, Saku Ytti a écrit :

On 8 October 2015 at 18:45, Giuliano (WZTECH)  wrote:




It's the step#1, they can get the underlaying OS to support SMP.




But rpd is still 100% flat, run-to-completion. You can almost think of
FreeBSD as hypervisor and rpd as virtual pc on top of it, it has own
scheduler, memory management etc.
IOS-XE is almost same architecture, Linux with flat ios as process.
Otoh iosd is already slightly distributed and runs like 5 threads (but
no meaningful routing work is distributed).

Easy step#2 would be to give rpd affinity to push it on its own dedicated core.


I think we are close to this step.



Hard step#3 is to make rpd use multiple cores. JNPR seems to choose to
DIY inside rpd and just launch threads. I personally would like to see
rpd distributed to multiple OS processes, and capitalise more on
FreeBSD's memory management and scheduling. But I'm not sure how to
handle the IPC efficiently without large cost in data duplications
across processes.



In my opinion rpd should also be split in several process. I know there 
was a lot of interprocess communication/synchonisation, but this can be 
rethink. For example arista propose a central/fast db called sysdb to 
handle communication/sync to other process (see : 
https://www.arista.com/assets/data/pdf/EOSWhitepaper.pdf for detail). I 
don't know if was a good/viable approach, but on the paper it seems 
promising.



--
Raphael Mazelier
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Saku Ytti]

On 9 October 2015 at 16:45, Adam Chappell  wrote:

Hey Adam,

> I can imagine that making rpd MT is probably hard to the point of almost not
> being worth the benefit (with current REs), unless one can adequately break

Yeah I can imagine there are tons of problems in the legacy code which
make concurrency hard. And as it's large company, probably very hard
to find person who is going to drive internally any huge refactoring,
chance of failure vs. reward on success does not make sense in career
terms. So the thread stuff they are doing, probably is extremely
complex and thus fragile. But hopefully I'm just being negative.

Sometimes I wonder if it would be sensible investment to always keep
on your payroll team of 3-6 competent people who are given greenfield
to solve particular problem, insurance towards if your main
development efforts fail.

> I'm quite intrigued by the tidbit in the Juniper docs, though, that suggests
> that switching from a 32-bit to a 64-bit rpd is not service affecting though
> which means that the wait-and-see approach is viable?  Or am I totally
> misunderstanding this?

Switching definitely is service affecting, rpd process will be
replaced by another rpd process, completely different binary.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Jeff Haas]

Adam,

> On Oct 9, 2015, at 9:45 AM, Adam Chappell  wrote:
>> 
> I can imagine that making rpd MT is probably hard to the point of almost
> not being worth the benefit (with current REs), unless one can adequately
> break down the problem into divisable chunks of work that are insensitive
> to execution order.  BGP peer route analysis, comparison against import
> policy and current RIB might fall into that category, but not without a lot
> of locking and potential for races.

It is non-trivial work.  But it is also somewhat easier to incrementally 
introduce threading than it is to split large hunks of code and workflow into 
multiple processes.

We're not going into deep technical detail on mailing lists such as these at 
the moment.  The work is in progress.  

> 
> I think there's more bang for buck in the 64-bit address space change what
> with Internet FIB table size, and I'm quite interested in the developments
> to make rpd 64-bit clean which I'm sure are also not insignificant. I
> notice Mr Tinka already expressed a conservative view on jumping into a
> 64-bit rpd and I can totally understand and appreciate that view. Juniper
> haven't made this a default on the 14.1R5 cut of code that we're currently
> testing, so I imagine they're still looking for bleeding-edge feedback to
> whittle out the potential nasties.

I've not quite understood our strategies for choosing whether we do 32 or 
64-bit by default.  The balance is covered somewhat by the split between having 
a RE with sufficient base memory vs. release, but the group responsible for 
that choice is being conservative.  In my opinion, 64-bit has been perceived 
internally clean for quite some time, and we do a significant portion of our 
internal testing in that environment.

The biggest reason to be cautious about the default mode is that on systems 
with insufficient memory, or systems with insufficient need, the cost of 64-bit 
may be a bit much.  Since the bulk of internal data structures are pointers, 
you tend to see at least a 2x increase in base memory use when running in 
64-bit mode.  

> 
> I'm quite intrigued by the tidbit in the Juniper docs, though, that
> suggests that switching from a 32-bit to a 64-bit rpd is not service
> affecting though which means that the wait-and-see approach is viable?  Or
> am I totally misunderstanding this?
> 
> https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/configuration-statement/routing-edit-system-processes.html

Ok, I find this comment to be confusing if not misleading:
Tip: You need not restart the routing protocol process (rpd) to use the 64-bit 
mode.

I suspect the most generous reading of this is that rpd is restarted for you.  
I'll open a doc PR for clarification.

> It doesn't say that one needs NSR or any sort of "help" from the backup RE
> which might be the first assumption. So I wonder how they manage to get one
> process to exit and the other one to start up with different runtimes,
> differently sized pointers etc., and somehow share the same in-core RIB and
> protocol state etc etc.? If this really does work, there's probably someone
> sitting somewhere in Sunnydale immensely smug and under-stated right now,
> and if so I'm sure he/she'd eat the MT problem for breakfast!

I've often thought working over the hell-mouth would be interesting, but 
engineer retention in Silicon Valley is already tricky enough.  Good thing the 
office is in Sunnyvale. :-)

-- Jeff

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Multi Core on JUNOS?

[Adam Chappell]

On 8 October 2015 at 17:46, Saku Ytti  wrote:

>
> Hard step#3 is to make rpd use multiple cores. JNPR seems to choose to
> DIY inside rpd and just launch threads. I personally would like to see
> rpd distributed to multiple OS processes, and capitalise more on
> FreeBSD's memory management and scheduling. But I'm not sure how to
> handle the IPC efficiently without large cost in data duplications
> across processes.
>
>
I can imagine that making rpd MT is probably hard to the point of almost
not being worth the benefit (with current REs), unless one can adequately
break down the problem into divisable chunks of work that are insensitive
to execution order.  BGP peer route analysis, comparison against import
policy and current RIB might fall into that category, but not without a lot
of locking and potential for races.

I think there's more bang for buck in the 64-bit address space change what
with Internet FIB table size, and I'm quite interested in the developments
to make rpd 64-bit clean which I'm sure are also not insignificant. I
notice Mr Tinka already expressed a conservative view on jumping into a
64-bit rpd and I can totally understand and appreciate that view. Juniper
haven't made this a default on the 14.1R5 cut of code that we're currently
testing, so I imagine they're still looking for bleeding-edge feedback to
whittle out the potential nasties.

I'm quite intrigued by the tidbit in the Juniper docs, though, that
suggests that switching from a 32-bit to a 64-bit rpd is not service
affecting though which means that the wait-and-see approach is viable?  Or
am I totally misunderstanding this?

https://www.juniper.net/documentation/en_US/junos14.1/topics/reference/configuration-statement/routing-edit-system-processes.html

It doesn't say that one needs NSR or any sort of "help" from the backup RE
which might be the first assumption. So I wonder how they manage to get one
process to exit and the other one to start up with different runtimes,
differently sized pointers etc., and somehow share the same in-core RIB and
protocol state etc etc.? If this really does work, there's probably someone
sitting somewhere in Sunnydale immensely smug and under-stated right now,
and if so I'm sure he/she'd eat the MT problem for breakfast!

-- Adam.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp