[j-nsp] Multi Core on JUNOS?

Chad Myers Chad.Myers at theice.com
Wed Oct 21 18:40:10 EDT 2015

On Oct 21, 2015, at 3:34 PM, Saku Ytti <saku at ytti.fi> wrote:
> Hey Chad,
>> Please don't go the IOS/EOS/non-Junos method for rpd where each protocol is completely independent and isolated from the others.  It is extremely helpful to be able to do things like put communities on static routes.  Even protocols that don't use communities can leverage them in the export policy, the community just isn't announced.  Ditto for import policies.
>> Sacrificing that flexibility and simplicity to multithread rpd and shifting to explicit route redistribution with limited route attributes per protocol would be a huge loss.
> You don't need to worry, these two issues have nothing in common. What
> you're talking about is very high level concept and it implies nothing
> about the underlaying architecture.

True, but I also know a good bit about the underlying architecture and have a good grasp of general system and programming concepts.  Definitely not a developer though so I don't typically know the specifics on how something is implemented.

>From a general view it seems that the simplest and fastest method to get rpd to leverage multicore systems better is splitting apart the different protocols.  That opens up having to deal with contention amongst the different protocols trying to access a single global route table simultaneously.  It can be done but it could also be sidestepped entirely by having per protocol tables rather than a single global table.  I would hope that isn't the path taken, but I've already dealt with various groups within Juniper and elsewhere that have made design decisions ranging from fantastic to questionable to absolutely horrible.  My request is just trying to prevent seeing Junos core do something really bad, either inadvertently or on purpose.

> Having said that, why on earth no tags/communities on direct/connected
> routes on any(?) platform. It dilutes usefulness in static routes as
> well, as you're still going to need to have logic to provision
> prefix-lists, so might as well do it same way for statics and directs.

Adding that would be on the fantastic side of design decisions.

As would getting the group that handles spd to adhere to the same standards as the rest of Junos with regard to naming conventions, inheritance, and prefix-list expansions.  And finally putting commas in the monitor interface traffic output.



This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

More information about the juniper-nsp mailing list