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

[Mohan Nanduri]

It's been a while but if my memory serves me correct, we opened ER
(17039) while back to assign tags to interfaces similar to static
routes.

Cheers,
-Mohan


On Wed, Oct 21, 2015 at 5:44 PM, Chad Myers  wrote:
> On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:
>
>> hey,
>>
>>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
>>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K
>>
>> Thats what I had in mind as well.
>
> I'm for that method as well.
>
>
> 
>
> 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.
> ___
> 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

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

[Mike Williams]

On Saturday 03 October 2015 02:41:09 Olivier Benghozi wrote:
> I have heard that:
> 1) forget it about PowerPC CPUs (MX 80/104).

As we've got a couple MX104s on the bench waiting for some testing I decided 
to give this a try.
15.1F3, no SMP.

% sysctl hw.ncpu
hw.ncpu: 1
% 


It's also clear you really shouldn't be using this release, so who knows.

--- JUNOS 15.1F3.11 built 2015-10-27 19:44:29 UTC
At least one package installed on this device has limited support.
Run 'file show /etc/notices/unsupported.txt' for details.


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

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

[Chad Myers]

Since I rekindled this once already...

I don't get what the benefit of "load  interactive" would be over just 
doing normal set commands.  Putting everything on a single line with inline 
comments like that seems like a recipe for headaches.  Each time I look at it I 
have to go back over it again 2-3 times to make sense of what is a comment, 
what is a setting, and how they actually link together.  Could just be me 
having a hard time grasping it quickly.

On a related note, this reminded me of something in the behavior of "load 
terminal" that bit me once and I'm wondering if it bit anyone else.  When using 
load merge terminal, and likely replace and override as well, if you break out 
using ctrl-C to abort the load instead of ctrl-D to save it,  it doesn't 
actually abort the load.  Anything that parsed successfully up to that point is 
now part of the candidate configuration, exactly the same as if you used ctrl-D 
to exit "load terminal" normally.  Anyone else learn that unexpectedly?

-Chad

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Stepan Kucherenko
Sent: Saturday, October 24, 2015 3:23 PM
To: Phil Shafer
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Multi Core on JUNOS?

> This would allow set-ish style (since the UI really doesn't need the
> braces on input) as well as allowing the placement of comments:
>
> [edit]
> cli# load terminal merge interactive
> [Type ^D at a new line to end input]
> protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
> /* You can also put braces here */
> protocols {
> bgp {
>/* goo is not */
>group goo { local-as 51; }}}
> ^D
> load complete
>

Is it possible to delete last line(s) ? If yes then this way of
configuring something will become the only one I will use all the time. :-)

I think it's great.

>
> But I need to work out what (and how) would get redrawn when you
> type "?" deep under braces (like at the "51" above).  I can't emit
> the [edit] line, but just redrawing the current line doesn't give
> the context the way I'd like it to.  Perhaps a distinct key to give
> the content-as-edit-line?

I'd be happy even with the current line. But maybe someone else will
have more ideas ?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Stepan Kucherenko]

This would allow set-ish style (since the UI really doesn't need the
braces on input) as well as allowing the placement of comments:

[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
/* You can also put braces here */
protocols {
bgp {
   /* goo is not */
   group goo { local-as 51; }}}
^D
load complete



Is it possible to delete last line(s) ? If yes then this way of 
configuring something will become the only one I will use all the time. :-)


I think it's great.



But I need to work out what (and how) would get redrawn when you
type "?" deep under braces (like at the "51" above).  I can't emit
the [edit] line, but just redrawing the current line doesn't give
the context the way I'd like it to.  Perhaps a distinct key to give
the content-as-edit-line?


I'd be happy even with the current line. But maybe someone else will 
have more ideas ?

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

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

[Stepan Kucherenko]

On 22.10.2015 22:37, Phil Shafer wrote:
> Stepan Kucherenko writes:
>> What else...oh, annotate ! It's clunky and not very easy to use.
> 
> Yes, annotate is a sore spot.  I made the grammar production:
> 
>  K_ANNOTATE annotate_target T_STRING
> 
> with the expectation that I'd be able to coerce a path into the
> target, but it didn't happen.  I should have done it as:
> 
>  K_ANNOTATE T_STRING annotate_target
> 
> and then allow anything as a target, like:
> 
>  cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address 
> 1.2.3.4/5
> 
> but can't make that work without making a new command ("comment"?).
> 
>> I wish we could just add a comment in the end of a line instead, like
>> "set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and
>> then see "x.x.x.x/y //client X" and the same line when asking for
>> |display set.
> 
> We generate line comments in JUNOS, so we need to discard them (and
> comments before close braces) to prevent out-of-date comments from
> getting loaded as real annotations.
> 
> Hmm  I should make a M-, keybinding to copy all arguments from the
> previous command so you can:
> 
>  [edit interfaces ge-0/0/0 unit 0]
>  cli# set family inet address 1.2.3.4/5
> 
>  [edit interfaces ge-0/0/0 unit 0]
>  cli# comment "Client X" [ESC-,]
> 
> and it will insert the "family inet address 1.2.3.4/5" from
> the previous "set" command.
> 
> This is similar to the existing M-. and M-/ bindings.

So when we say show interfaces ge-0/0/0.0 we'll see something like

family inet {
/* Client X */
address 1.2.3.4/5;
}

But let's say we want to add another address for another client

[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 6.7.8.9/10

[edit interfaces ge-0/0/0 unit 0]
сli# comment "Client Y" [ESC-,]

family inet {
/* Client Y */
address 1.2.3.4/5;
address 6.7.8.9/10;
}

Correct ?

I was thinking of something like that:

[edit]
cli# set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 // Client X //

[edit]
cli# set interfaces ge-0/0/0.0 family inet address 6.7.8.9/10 // Client Y //

[edit]
cli# show interfaces ge-0/0/0.0
family inet {
address 1.2.3.4/5;   // Client X //
address 6.7.8.9/10;   // Client Y //
}

Or maybe set interfaces ge-0/0/0.0 family inet address 1.2.3.4/5 comment 
"Client X"  instead of "//", or /* Client X */ in "show" output, whatever, 
it'll be cosmetic anyway.

Basically the same as descr command but available at any hierarchy level for 
any element but which doesn't use a separate line. Configurations are way too 
big already and separate line comments will eat into precious screen real 
estate.


It'll be easier to parse, easier to work with, will stay in the configuration 
with the same rules as everything else, it'll be deleted after deleting the 
element it comments and it won't be necessary to say "edit interfaces 
ge-0/0/0.0" first to work with it, you'll be able to do it from top (inability 
to do that probably annoys me the most in annotate).




Maybe even something like 

set protocols bgp group ix-v4 type external import [ reject-some-prefixes 
///don't like them// set-community //for further filtering// ] peer-as X 
neighbor 1.2.4.5 //location// export customers-only //please don't delete this//

then if we say show protocols bgp group ix-v4 we'll get:

type external;
import [ reject-some-prefixes ///don't like them// set-community //for further 
filtering// ];
peer-as X;
neighbor 1.2.4.5 //location// {
export customers-only; //please don't delete this//
}


Or with |display set:

set protocols bgp group ix-iv type external
set protocols bgp group ix-iv import reject-some-prefixes ///don't like them//
set protocols bgp group ix-iv import set-community //for further filtering//
set protocols bgp group ix-iv peer-as X
set protocols bgp group ix-iv neighbor 1.2.4.5 //location// 
set protocols bgp group ix-iv neighbor 1.2.4.5 export customers-only //please 
don't delete this//

Makes sense ? 


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

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

[Phil Shafer]

Stepan Kucherenko writes:
>But let's say we want to add another address for another client
>
>[edit interfaces ge-0/0/0 unit 0]
>cli# set family inet address 6.7.8.9/10
>
>[edit interfaces ge-0/0/0 unit 0]
>сli# comment "Client Y" [ESC-,]
>
>family inet {
>/* Client Y */
>address 1.2.3.4/5;
>address 6.7.8.9/10;
>}
>
>Correct ?

No, each object in the database can have its own comment attached,
and since the two addresses are distinct objects, each can carry a
comment, like:

[edit]
phil@dent# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
/* one */
address 10.1.2.3/30;
/* two */
address 10.4.5.6/30;
}
}
}

>set protocols bgp group ix-v4 type external import [ reject-some-prefixes 
>///don't like 
>them// set-community //for further filtering// ] peer-as X neighbor 1.2.4.5 
>//location//
> export customers-only //please don't delete this//

Personally, I dislike this.  It makes command lines less readable and
more likely to cause errors.

But along the same line, I have kicked around the idea of making
"load" be truly interactive, so I could to stuff like:

[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp group foo local?
Possible completions:
  local-addressAddress of local end of BGP session
> local-as Local autonomous system number
  local-interface  Local interface for IPv6 link local EBGP peering
  local-preference Value of LOCAL_PREF path attribute
protocols bgp group foo local-as ?
Possible completions:
Autonomous system number in plain number or 'higher 
16bits'.'Lower 16 bits' (asdot notation) format
  aliasTreat this AS as an alias to the system AS
  loopsMaximum number of times this AS can be in an AS path 
(1..10)
  no-prepend-global-as  Do not prepend global autonomous-system number in 
advertised paths
  private  Hide this local AS in paths learned from this peering
protocols bgp group foo local-as 42;
^D
load complete

This would allow set-ish style (since the UI really doesn't need the
braces on input) as well as allowing the placement of comments:

[edit]
cli# load terminal merge interactive
[Type ^D at a new line to end input]
protocols bgp /* foo is cool */ group foo /* local-as is also */ local-as 42;
/* You can also put braces here */
protocols {
   bgp {
  /* goo is not */
  group goo { local-as 51; }}}
^D
load complete


But I need to work out what (and how) would get redrawn when you
type "?" deep under braces (like at the "51" above).  I can't emit
the [edit] line, but just redrawing the current line doesn't give
the context the way I'd like it to.  Perhaps a distinct key to give
the content-as-edit-line?

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

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

[Phil Shafer]

Stepan Kucherenko writes:
>What else...oh, annotate ! It's clunky and not very easy to use.

Yes, annotate is a sore spot.  I made the grammar production:

K_ANNOTATE annotate_target T_STRING

with the expectation that I'd be able to coerce a path into the
target, but it didn't happen.  I should have done it as:

K_ANNOTATE T_STRING annotate_target

and then allow anything as a target, like:

cli# annotate "Client X" interfaces ge-0/0/0.0 family inet address 1.2.3.4/5

but can't make that work without making a new command ("comment"?).

>I wish we could just add a comment in the end of a line instead, like 
>"set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and 
>then see "x.x.x.x/y //client X" and the same line when asking for 
>|display set.

We generate line comments in JUNOS, so we need to discard them (and
comments before close braces) to prevent out-of-date comments from
getting loaded as real annotations.

Hmm  I should make a M-, keybinding to copy all arguments from the
previous command so you can:

[edit interfaces ge-0/0/0 unit 0]
cli# set family inet address 1.2.3.4/5

[edit interfaces ge-0/0/0 unit 0]
cli# comment "Client X" [ESC-,]

and it will insert the "family inet address 1.2.3.4/5" from
the previous "set" command.

This is similar to the existing M-. and M-/ bindings.

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

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

[Mark Tinka]

On 22/Oct/15 00:40, Chad Myers wrote:

>   And finally putting commas in the monitor interface traffic output.

Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
Tbps :-).

Mark.
___
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 Vitkovsky]

Hi Jeff,

> Jeff Haas
> Sent: Wednesday, October 21, 2015 8:16 PM
>
>
> That said, we are preserving the One JUNOS paradigm.  Even if we did go
> multi-process with disjoint protocol implementation (that's not what we're
> doing),
>

Can you expand on this please?
I thought that's the plan to separate routing protocols to separate processes 
or is this concerning only BGP?
Thank you.

adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

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

[Mark Tinka]

On 22/Oct/15 09:12, Raphael Mazelier wrote:

>
>  
> +1. When I begin to use Junos I was really surprised/frustated that I
> couldn't use tag/communities on connected, which break the classic
> logic of redistributing route in junos. That said this is even worse
> on other network os.

In IOS and IOS XE, my annoyance is that you can't use a tag as a match
condition to export routes to BGP neighbors.

Not sure what the policy in IOS XR is.

For exporting Direct routes in Junos, we go the old-fashioned way; but
yes, being able to add tags to those would be great.

Mark.

___
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 Vitkovsky]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 11:54 AM
> On 22 October 2015 at 10:38, Adam Vitkovsky
>  wrote:
>
> Hey,
>
> > I thought that's the plan to separate routing protocols to separate
> processes or is this concerning only BGP?
>
> Not processes, threads, due to IPC concerns.
>
Hey,

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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 22 October 2015 at 14:31, Adam Vitkovsky  wrote:
> I see, so no possibility to offload BGP to another node nor multi-chassis 
> capability in Junos right?
> With regards to IPC, there got to be some XR folks in Juniper so where's the 
> holdup :)

IOS-XR seems to have fair share problems with the IPC :)

-- 
  ++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?

[Phil Mayers]

On 22/10/15 13:05, Saku Ytti wrote:

On 22 October 2015 at 14:31, Adam Vitkovsky  wrote:

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)


IOS-XR seems to have fair share problems with the IPC :)



In fairness, concurrency is "teh hardz" on any platform, in any framework.

You can use threads and shared memory then problems two you have.

You can bodge it by serialising everything and pushing data between 
threads/processes with queues and using craploads of locking, but you 
typically want fast CPUs for that. Or you can cheat and coop multitask, 
but then you're back at IOS classic / JunOS rpd.


You can write it in a concurrent-friendly language like Erlang (or maybe 
Go) but then you have problem employing developers on the cheap, and 
have to discard your existing codebase (yikes!)


I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases 
they can't afford to discard because of the years of accumulated 
real-world behavioural tweaks, but proper concurrency typically involves 
ground-up design principles.


It's not a solved problem yet :o(
___
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 22 October 2015 at 10:38, Adam Vitkovsky  wrote:

Hey,

> I thought that's the plan to separate routing protocols to separate processes 
> or is this concerning only BGP?

Not processes, threads, due to IPC concerns.

-- 
  ++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?

[Saku Ytti]

On 22 October 2015 at 08:30, Bradley Gould
 wrote:

Hey,

> "routing-options interface-routes" already exists, so keeping commonality 
> with "routing-options static":
>
> set routing-options interface-routes family inet community [ 1:1 2:2 3:3 ]
> set routing-options interface-routes interface xe-1/2/3 family inet community 
> [ 1:1 2:2 4:4 ]
>
> I'd think you'd want an ability to set a "global" community set for all 
> interface routes and also be able to set them individually.

I don't see 'interface-routes interface X' in config?

http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/interface-routes-edit-routing-options.html


Even if this exits, it does not seem to give address granularity,
which is crucial point, so you can discriminate between two addresses.



-- 
  ++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?

[Zaid Hammoudi]

On Thu, Oct 22, 2015 at 6:36 AM, Stepan Kucherenko  wrote:

> If we're speaking about "quality of life" stuff then I wish JunOS/FreeBSD
> traceroute would stop adding source routing bit when you include source
> interface/gateway/bypass-routing.
>

JUNOS currently uses a version of traceroute that is over 13 years old.
Apparently that's also what the latest version of FreeBSD uses too.
___
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]

In fairness, concurrency is "teh hardz" on any platform, in any framework.

You can use threads and shared memory then problems two you have.

You can bodge it by serialising everything and pushing data between
threads/processes with queues and using craploads of locking, but you
typically want fast CPUs for that. Or you can cheat and coop multitask,
but then you're back at IOS classic / JunOS rpd.

You can write it in a concurrent-friendly language like Erlang (or maybe
Go) but then you have problem employing developers on the cheap, and
have to discard your existing codebase (yikes!)

I'm sympathetic to Juniper/Cisco/etc. here - they've got huge codebases
they can't afford to discard because of the years of accumulated
real-world behavioural tweaks, but proper concurrency typically involves
ground-up design principles.

It's not a solved problem yet :o(


The approach to run rpd on one core, and other process on avaibles one 
is a quick win. And optimizing the actual code before thinking in 
paralelism may be a faster approach to make speed gain ?


I complelty agree that to make a good paralelized junos, major rewrite 
or complete rewrite must be engaged.


Btw Junos on intel RE is fast enough for me. But not all on other cpu, 
specially on EX/QFX one... Perhaps Juniper should install x86 cpu on 
switch too (other vendor do this).



--
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?

[Phil Mayers]

On 22/10/15 15:06, Raphael Mazelier wrote:


The approach to run rpd on one core, and other process on avaibles one
is a quick win. And optimizing the actual code before thinking in
paralelism may be a faster approach to make speed gain ?


Sure, moving the rest of the OS onto other cores is a no-brainer; 
they're already crossing a process boundary.



Btw Junos on intel RE is fast enough for me. But not all on other cpu,
specially on EX/QFX one... Perhaps Juniper should install x86 cpu on
switch too (other vendor do this).


Better CPU choices would help a lot of devices ;o)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Phil Bedard]

Well you may see the ability to run the  Junos CP on more powerful external 
servers with virtualized hardware, I think a few vendors are working on those 
type of a solutions.  Juniper has done similar things in the past with 
multi-chassis.  

Phil

-Original Message-
From: "Adam Vitkovsky" <adam.vitkov...@gamma.co.uk>
Sent: ‎10/‎22/‎2015 7:31 AM
To: "Saku Ytti" <s...@ytti.fi>
Cc: "<juniper-nsp@puck.nether.net>" <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] Multi Core on JUNOS?

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 11:54 AM
> On 22 October 2015 at 10:38, Adam Vitkovsky
> <adam.vitkov...@gamma.co.uk> wrote:
>
> Hey,
>
> > I thought that's the plan to separate routing protocols to separate
> processes or is this concerning only BGP?
>
> Not processes, threads, due to IPC concerns.
>
Hey,

I see, so no possibility to offload BGP to another node nor multi-chassis 
capability in Junos right?
With regards to IPC, there got to be some XR folks in Juniper so where's the 
holdup :)

adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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

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

[Doug McIntyre]

On Thu, Oct 22, 2015 at 08:51:10AM +0200, Mark Tinka wrote:
> On 22/Oct/15 00:40, Chad Myers wrote:
> 
> >   And finally putting commas in the monitor interface traffic output.
> 
> Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
> Tbps :-).

I so wish there was a '-h' flag to 'monitor interface' that did that..


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

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

[Stepan Kucherenko]

If we're speaking about "quality of life" stuff then I wish 
JunOS/FreeBSD traceroute would stop adding source routing bit when you 
include source interface/gateway/bypass-routing.


It's being filtered EVERYWHERE in real world so it's not possible to 
look at the second-best route via non-active path, it's either best 
route or guessing. Or maybe I'm missing something ?



Also fractional interval in traceroute monitor (=mtr), I always use -i 
0.1 or even less in real life for faster drop detection but can't do the 
same in Junos even if it's the same mtr.



What else...oh, annotate ! It's clunky and not very easy to use.

I wish we could just add a comment in the end of a line instead, like 
"set interface ge-0/0/0.0 family inet address x.x.x.x/y //client X" and 
then see "x.x.x.x/y //client X" and the same line when asking for 
|display set.



I'm sure you guys can add even more stuff like that. It's small but I 
think it's still important. And a low-hanging fruit in many cases :-)



On 22.10.2015 15:33, Doug McIntyre wrote:

On Thu, Oct 22, 2015 at 08:51:10AM +0200, Mark Tinka wrote:

On 22/Oct/15 00:40, Chad Myers wrote:


   And finally putting commas in the monitor interface traffic output.


Or just use the correct units of measurement, e.g., Kbps, Mbps, Gbps and
Tbps :-).


I so wish there was a '-h' flag to 'monitor interface' that did that..


___
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

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

[Adam Vitkovsky]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, October 22, 2015 1:05 PM
>
> On 22 October 2015 at 14:31, Adam Vitkovsky
>  wrote:
> > I see, so no possibility to offload BGP to another node nor multi-chassis
> capability in Junos right?
> > With regards to IPC, there got to be some XR folks in Juniper so where's the
> holdup :)
>
> IOS-XR seems to have fair share problems with the IPC :)
>
Well I'm alright with that for as long as I can distribute BGP process suits to 
several nodes and unless it doesn't severely impact performance which I'm not 
aware of.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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 21/10/15 23:44, Chad Myers a écrit :

On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:


hey,


set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K


Thats what I had in mind as well.


I'm for that method as well.




+1. When I begin to use Junos I was really surprised/frustated that I 
couldn't use tag/communities on connected, which break the classic logic 
of redistributing route in junos. That said this is even worse on other 
network os.


--
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?

[Jeff Haas]

> On Oct 21, 2015, at 3:05 PM, Chad Myers  wrote:
> 
> 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.

I always found using communities on non-BGP routes a little weird, but everyone 
has their favorite operational tricks.  (And I try to seek out people to talk 
about them at conferences.  It often leads to small features.)

That said, we are preserving the One JUNOS paradigm.  Even if we did go 
multi-process with disjoint protocol implementation (that's not what we're 
doing), we'd be keeping the same source base.  Thus, static routes could have 
communities, or color or your unusual mechanism of choice. :-)

-- 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?

[Jeff Haas]

> On Oct 21, 2015, at 3:21 PM, Tarko Tikan  wrote:
> 
> hey,
> 
>> I always found using communities on non-BGP routes a little weird,
>> but everyone has their favorite operational tricks.  (And I try to
>> seek out people to talk about them at conferences.  It often leads to
>> small features.)
> 
> Communities on static routes are great.
> 
> But everyone wants more :) It would be super helpful if you would support 
> communities or tags on connected routes as well.

Hijacking the thread momentarily, what would you expect that to look like in 
the config?  community/tag keywording in a interface ... family foo {} scope?

-- 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?

[Saku Ytti]

On 21 October 2015 at 22:29, Jeff Haas  wrote:
> Hijacking the thread momentarily, what would you expect that to look like in 
> the config?  community/tag keywording in a interface ... family foo {} scope?

set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K

HTH,
-- 
  ++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?

[Chad Myers]

On Oct 9, 2015, at 10:08 AM, Jeff Haas  wrote:

> 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.

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.

-Chad



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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Tarko Tikan]

hey,


I always found using communities on non-BGP routes a little weird,
but everyone has their favorite operational tricks.  (And I try to
seek out people to talk about them at conferences.  It often leads to
small features.)


Communities on static routes are great.

But everyone wants more :) It would be super helpful if you would 
support communities or tags on connected routes as well.


--
tarko
___
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 21 October 2015 at 22:05, Chad Myers  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.

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.




-- 
  ++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?

[Tarko Tikan]

hey,


set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K


Thats what I had in mind as well.

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

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

[Chad Myers]

On Oct 21, 2015, at 3:58 PM, Tarko Tikan  wrote:

> hey,
>
>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 tag Z
>> set interfaces xe-1/2/3 unit 42 family inet address 1.2.3.4/30 community K
>
> Thats what I had in mind as well.

I'm for that method as well.




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.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chad Myers]

On Oct 21, 2015, at 3:34 PM, Saku Ytti  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.

-Chad



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.
___
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

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

[Giuliano (WZTECH)]

And the change now announced on 15.1 (new release) using freebsd 10 will not 
help to solve it ?

> On Oct 8, 2015, at 12:33, Colton Conor  wrote:
> 
> Saku,
> 
> You seem to be very familiar with the major routing vendors implementations
> on SMP. Do you consider the lack of SMP support on Juniper a reason not to
> go with Juniper until implemented. Particularly interested to hear about
> JunOS vs TimOS.
> 
>> On Thu, Oct 8, 2015 at 10:13 AM, Saku Ytti  wrote:
>> 
>> On 3 October 2015 at 03:41, Olivier Benghozi
>>  wrote:
>> 
>> Hey,
>> 
>>> I have heard that:
>>> 1) forget it about PowerPC CPUs (MX 80/104).
>> 
>> This is shame, but completely understandable, give customers couple
>> more years on old kit or force them to buy new kit? I'm afraid maybe
>> no HW of current generation will get SMP support. I'm sure marketing
>> is pondering lot how many customers would switch vendor versus how
>> many customers would just buy new next-gen hardware when deciding
>> which platforms to target for SMP.
>> 
>> I honestly believe that SMP is weekend project for single developer on
>> JunOS now that they've remedied the underlaying FreeBSD issues. Fixing
>> rpd mess is certainly big deal. But just affinity to put RPD on its
>> own core and rest on the other core on MX80/MX104 should be terribly
>> trivial.
>> 
>> Even radar plans for RPD + threads is far cry from what other vendors
>> are doing already with SMP on XR, EOS and particularly TimOS. But
>> still very nice that JNPR is finally doing something.
>> 
>> --
>>  ++ytti
>> ___
>> 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

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

[Saku Ytti]

On 3 October 2015 at 03:41, Olivier Benghozi
 wrote:

Hey,

> I have heard that:
> 1) forget it about PowerPC CPUs (MX 80/104).

This is shame, but completely understandable, give customers couple
more years on old kit or force them to buy new kit? I'm afraid maybe
no HW of current generation will get SMP support. I'm sure marketing
is pondering lot how many customers would switch vendor versus how
many customers would just buy new next-gen hardware when deciding
which platforms to target for SMP.

I honestly believe that SMP is weekend project for single developer on
JunOS now that they've remedied the underlaying FreeBSD issues. Fixing
rpd mess is certainly big deal. But just affinity to put RPD on its
own core and rest on the other core on MX80/MX104 should be terribly
trivial.

Even radar plans for RPD + threads is far cry from what other vendors
are doing already with SMP on XR, EOS and particularly TimOS. But
still very nice that JNPR is finally doing something.

-- 
  ++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?

[Colton Conor]

Saku,

You seem to be very familiar with the major routing vendors implementations
on SMP. Do you consider the lack of SMP support on Juniper a reason not to
go with Juniper until implemented. Particularly interested to hear about
JunOS vs TimOS.

On Thu, Oct 8, 2015 at 10:13 AM, Saku Ytti  wrote:

> On 3 October 2015 at 03:41, Olivier Benghozi
>  wrote:
>
> Hey,
>
> > I have heard that:
> > 1) forget it about PowerPC CPUs (MX 80/104).
>
> This is shame, but completely understandable, give customers couple
> more years on old kit or force them to buy new kit? I'm afraid maybe
> no HW of current generation will get SMP support. I'm sure marketing
> is pondering lot how many customers would switch vendor versus how
> many customers would just buy new next-gen hardware when deciding
> which platforms to target for SMP.
>
> I honestly believe that SMP is weekend project for single developer on
> JunOS now that they've remedied the underlaying FreeBSD issues. Fixing
> rpd mess is certainly big deal. But just affinity to put RPD on its
> own core and rest on the other core on MX80/MX104 should be terribly
> trivial.
>
> Even radar plans for RPD + threads is far cry from what other vendors
> are doing already with SMP on XR, EOS and particularly TimOS. But
> still very nice that JNPR is finally doing something.
>
> --
>   ++ytti
> ___
> 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

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

[Adam Vitkovsky]

Hi Saku,

> Of Saku Ytti
> Sent: Thursday, October 08, 2015 5:34 PM
> TimOS has been able to distribute work from BGP to many cores, as far as I
> know all other vendors will only ever use one core for BGP at given time.
>
Actually IOS XR "had" the capability to run BGP in a standalone or distributed 
mode on CRS (found a comment that on 4.2.0 the "bgp distributed speaker" config 
was removed).
-in distributed mode up to 15 BGP speaker process could be offloaded to DRPs 
-even in different nodes (multi-chassis) and you can assign peers to different 
speaker processes.
-but there are some drawbacks during best path selection algorithm because only 
the partial best paths for a local speaker process are stored into dRIB that is 
then shared via IPC between the different speaker processes.
-and also some restrictions on how AFs can be distributed across the speaker 
processes but it's worth nothing that in case of a failure of one process/AF 
the other AFs are intact.

The other "current" possibility on XR is to run Multi-Instance BGP.
In this mode each BGP instance (max 4) is a completely separate set of 
processes running on the same or different RP or DRP the processes don’t share 
any RIB so no need for distributed adj-rib-in.
If required each instance can have a different AS number.

I'm not familiar with TimOS (other than reviewing the config guide) so I'd be 
interested to see what options are there.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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 00:36, Phil Bedard  wrote:

> Timos (now SROS) is all internal, no config knobs I am aware of,  but the
> whole system was built to be multithreaded from the beginning.  Their vRR
> implementation is very fast because it can distribute the neighbor sessions
> across multiple cores.  If you look at the vRR stuff they have put out there
> are some more details.

I understood that it's not per neighbour, but it's like one
process/task for rib-in, rib-out and keepalive. And routing-instances
live in separate set of three processes/tasks.
I guess it shouldn't be too hard to further split rib-out per
update-group, but you'll quickly run out of cores and start to pay
context switch tax.

-- 
  ++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?

[Phil Bedard]

Timos (now SROS) is all internal, no config knobs I am aware of,  but the whole 
system was built to be multithreaded from the beginning.  Their vRR 
implementation is very fast because it can distribute the neighbor sessions 
across multiple cores.  If you look at the vRR stuff they have put out there 
are some more details.  

Phil

-Original Message-
From: "Adam Vitkovsky" <adam.vitkov...@gamma.co.uk>
Sent: ‎10/‎8/‎2015 3:55 PM
To: "Saku Ytti" <s...@ytti.fi>; "Colton Conor" <colton.co...@gmail.com>
Cc: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] Multi Core on JUNOS?

Hi Saku,

> Of Saku Ytti
> Sent: Thursday, October 08, 2015 5:34 PM
> TimOS has been able to distribute work from BGP to many cores, as far as I
> know all other vendors will only ever use one core for BGP at given time.
>
Actually IOS XR "had" the capability to run BGP in a standalone or distributed 
mode on CRS (found a comment that on 4.2.0 the "bgp distributed speaker" config 
was removed).
-in distributed mode up to 15 BGP speaker process could be offloaded to DRPs 
-even in different nodes (multi-chassis) and you can assign peers to different 
speaker processes.
-but there are some drawbacks during best path selection algorithm because only 
the partial best paths for a local speaker process are stored into dRIB that is 
then shared via IPC between the different speaker processes.
-and also some restrictions on how AFs can be distributed across the speaker 
processes but it's worth nothing that in case of a failure of one process/AF 
the other AFs are intact.

The other "current" possibility on XR is to run Multi-Instance BGP.
In this mode each BGP instance (max 4) is a completely separate set of 
processes running on the same or different RP or DRP the processes don’t share 
any RIB so no need for distributed adj-rib-in.
If required each instance can have a different AS number.

I'm not familiar with TimOS (other than reviewing the config guide) so I'd be 
interested to see what options are there.


adam



Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


___
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

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

[Colton Conor]

Does anyone have an update on when Juniper will release SMP (symmetrical
multi processor) aka the ability to use multiple cores? Do you think the
second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
MX240/480 have one or 2 cores?

On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:

>
>
> On 11/May/15 13:27, Olivier Benghozi wrote:
> >
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> <
> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > "Statement introduced in Junos OS Release 13.3 R4"
>
> We decided not to enable this now because I understand the plan is for
> 64-bit mode to become the default in later versions of Junos.
>
> Mark.
> ___
> 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

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

[joel jaeggli]

On 10/2/15 2:33 PM, Phil Rosenthal wrote:
>> On Oct 2, 2015, at 5:11 PM, Colton Conor  wrote:
>>
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?

afaik the re2000 was a single core pentium-m the re4x1800 is a bit more
robust.

> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>>
>>>
>>>
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html


 "Statement introduced in Junos OS Release 13.3 R4"
>>>
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>>
>>> Mark.
>>> ___
>>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Phil Rosenthal]

> On Oct 2, 2015, at 5:11 PM, Colton Conor  wrote:
>
> Does anyone have an update on when Juniper will release SMP (symmetrical
> multi processor) aka the ability to use multiple cores? Do you think the
> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
> MX240/480 have one or 2 cores?
>

I have heard that this is planned for Junos 15.

-Phil
>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>
>>
>>
>>> On 11/May/15 13:27, Olivier Benghozi wrote:
>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>> <
>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>>
>>>
>>> "Statement introduced in Junos OS Release 13.3 R4"
>>
>> We decided not to enable this now because I understand the plan is for
>> 64-bit mode to become the default in later versions of Junos.
>>
>> Mark.
>> ___
>> 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

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

[Olivier Benghozi]

I have heard that:
1) forget it about PowerPC CPUs (MX 80/104).
2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP 
activated; but I guess that as long as rpd won't be recoded accordingly, it 
won't be any faster.

> Le 2 oct. 2015 à 23:33, Phil Rosenthal  a écrit :
> 
>> On Oct 2, 2015, at 5:11 PM, Colton Conor > > wrote:
>> 
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?
>> 
> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka  wrote:
>>> 
>>> 
>>> 
 On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
 
 
 "Statement introduced in Junos OS Release 13.3 R4"
>>> 
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>> 
>>> Mark.

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

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

[Phil Bedard]

I thought I saw a roadmap blurb about multi-core RPD in 16.x.  I think its a 
considerable amount of work.  

Phil

-Original Message-
From: "Olivier Benghozi" <olivier.bengh...@wifirst.fr>
Sent: ‎10/‎2/‎2015 8:41 PM
To: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>
Subject: Re: [j-nsp] Multi Core on JUNOS?

I have heard that:
1) forget it about PowerPC CPUs (MX 80/104).
2) JunOS 15.1 uses a more recent FreeBSD 10 base (as said in the doc) with SMP 
activated; but I guess that as long as rpd won't be recoded accordingly, it 
won't be any faster.

> Le 2 oct. 2015 à 23:33, Phil Rosenthal <p...@isprime.com> a écrit :
> 
>> On Oct 2, 2015, at 5:11 PM, Colton Conor <colton.co...@gmail.com 
>> <mailto:colton.co...@gmail.com>> wrote:
>> 
>> Does anyone have an update on when Juniper will release SMP (symmetrical
>> multi processor) aka the ability to use multiple cores? Do you think the
>> second core on the MX80 or MX104 will ever be used? Does the RE-2000 in the
>> MX240/480 have one or 2 cores?
>> 
> 
> I have heard that this is planned for Junos 15.
> 
> -Phil
>>> On Mon, May 11, 2015 at 7:04 AM, Mark Tinka <mark.ti...@seacom.mu> wrote:
>>> 
>>> 
>>> 
>>>> On 11/May/15 13:27, Olivier Benghozi wrote:
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>> <
>>> http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
>>>> 
>>>> 
>>>> "Statement introduced in Junos OS Release 13.3 R4"
>>> 
>>> We decided not to enable this now because I understand the plan is for
>>> 64-bit mode to become the default in later versions of Junos.
>>> 
>>> Mark.

___
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

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

[Mark Tinka]

On 11/May/15 13:27, Olivier Benghozi wrote:
 http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
  
 http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html

 Statement introduced in Junos OS Release 13.3 R4

We decided not to enable this now because I understand the plan is for
64-bit mode to become the default in later versions of Junos.

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

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

[Olivier Benghozi]

http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
 
http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html

Statement introduced in Junos OS Release 13.3 R4


 Le 11 mai 2015 à 04:55, Colton Conor colton.co...@gmail.com a écrit :
 
 What version of 13.3 is this available in Adam?
 
 On Sun, May 10, 2015 at 6:25 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk
 wrote:
 
 I know what you mean though there's an option so should the 4GB of RAM be
 not enough for a single BGP instance you can always start up to 3 more
 independent BGP instances to use all the memory you can.
 From 13.3 Junos BGP process can cross the 4GB boundary so there's no
 restriction on BGP scaling.

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

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

[Colton Conor]

What version of 13.3 is this available in Adam?

On Sun, May 10, 2015 at 6:25 AM, Adam Vitkovsky adam.vitkov...@gamma.co.uk
wrote:

  From: Mark Tinka [mailto:mark.ti...@seacom.mu]
  Sent: 10 May 2015 11:44
 
 
  On 9/May/15 20:12, Adam Vitkovsky wrote:
 
   If you are struggling with memory utilization you might want to be
   looking at BGP Multi-Instance feature available since 4.2.
   If you are struggling with horsepower you can distribute BGP instances
   across multiple DRPs (only on CRS).
 
  Not struggling with either one.
 
  Just a shame that when the RP you buy comes with 12GB of RAM, and you
  can't use that, money not well spent.

 I know what you mean though there's an option so should the 4GB of RAM be
 not enough for a single BGP instance you can always start up to 3 more
 independent BGP instances to use all the memory you can.
 From 13.3 Junos BGP process can cross the 4GB boundary so there's no
 restriction on BGP scaling.

 adam

 ---
  This email has been scanned for email related threats and delivered
 safely by Mimecast.
  For more information please visit http://www.mimecast.com

 ---
 ___
 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

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

[Adam Vitkovsky]

 From: Mark Tinka [mailto:mark.ti...@seacom.mu]
 Sent: 10 May 2015 11:44
 
 
 On 9/May/15 20:12, Adam Vitkovsky wrote:
 
  If you are struggling with memory utilization you might want to be
  looking at BGP Multi-Instance feature available since 4.2.
  If you are struggling with horsepower you can distribute BGP instances
  across multiple DRPs (only on CRS).
 
 Not struggling with either one.
 
 Just a shame that when the RP you buy comes with 12GB of RAM, and you
 can't use that, money not well spent.

I know what you mean though there's an option so should the 4GB of RAM be not 
enough for a single BGP instance you can always start up to 3 more independent 
BGP instances to use all the memory you can. 
From 13.3 Junos BGP process can cross the 4GB boundary so there's no 
restriction on BGP scaling.

adam
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Mark Tinka]

On 9/May/15 20:12, Adam Vitkovsky wrote:

 If you are struggling with memory utilization you might want to be
 looking at BGP Multi-Instance feature available since 4.2.
 If you are struggling with horsepower you can distribute BGP instances
 across multiple DRPs (only on CRS).

Not struggling with either one.

Just a shame that when the RP you buy comes with 12GB of RAM, and you
can't use that, money not well spent.

My CRS's are BGP-free (IPv4), so there is a lot of RAM and CPU to go around.

The ASR9001's that do peering are still good as well, as the number of
peers on them is reasonable.

Mark.
___
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 (2015-05-09 09:40 +0300), Jesper Skriver wrote:


  On (2015-05-08 20:16 +0200), Mark Tinka wrote:
  
  IOS XE uses multiple cores in the data plane, but now that I think about
  it, I haven't delved into what their strategy for the RP is. I should ask.
  
  iosd uses several kernel threads, so RP is using more than one core. But it
  looks like it's role-based, and single ios-xr task itself cannot use 
  multiple
  core.
 
 Not true, FIB on XR for example is multithreaded, so are some other processes.

I battled with myself should I repost and fix the mistype, but decided there
was enough context (Mark explicitly stating so, and iosd) to determine I meant
IOS-XE, but I clearly I made a mistake.

So iosd, if you look in ios-xe linux shell it has multiple threads, but their
cpu time is significantly different, implying ios tasks themselves are not
actually threaded, rather the 'ios vm' has few processes, which are exposed to
linux as threads. If I'd venture a quess, one thread does all ios tasks, one
threads does punt injection, one does clocking. But these are just guesses.

-- 
  ++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?

[Jesper Skriver]

On 09 May 2015, at 10:44, Saku Ytti s...@ytti.fi wrote:

 On (2015-05-09 09:40 +0300), Jesper Skriver wrote:
 
 
 On (2015-05-08 20:16 +0200), Mark Tinka wrote:
 
 IOS XE uses multiple cores in the data plane, but now that I think about
 it, I haven't delved into what their strategy for the RP is. I should ask.
 
 iosd uses several kernel threads, so RP is using more than one core. But it
 looks like it's role-based, and single ios-xr task itself cannot use 
 multiple
 core.
 
 Not true, FIB on XR for example is multithreaded, so are some other 
 processes.
 
 I battled with myself should I repost and fix the mistype, but decided there
 was enough context (Mark explicitly stating so, and iosd) to determine I meant
 IOS-XE, but I clearly I made a mistake.
 
 So iosd, if you look in ios-xe linux shell it has multiple threads, but their
 cpu time is significantly different, implying ios tasks themselves are not
 actually threaded, rather the 'ios vm' has few processes, which are exposed to
 linux as threads. If I'd venture a quess, one thread does all ios tasks, one
 threads does punt injection, one does clocking. But these are just guesses.

IOS-XE is a different beast, it runs iosd, which is very close to IOS-classic 
as a process, within iosd one thread runs the IOS classic scheduler which runs 
all the IOS-classic “processes”/tasks.

As you note, iosd does have other threads, one of which is the “fast path” 
software forwarding aka punt path, that is mostly unused on XE as all packet 
forwarding is done by an underlying HW forwarding plane. In addition to that 
iosd has a few other threads.

Outside iosd, IOS-XE has other processes which handle various things, some 
features like 802.1x etc are handled by these processes and doesn’t involve 
iosd much (or not at all). Other processes handle programming of HW, they are 
fed data from iosd, but the actual programming is done other processes, which 
can use other cores.

So IOS-XE can and does take advantage of multiple cores, however IOS-classic 
processes like BGP for example runs within iosd’s single thread for IOS-classic 
processes.

That said, in practice IOS-XE performance for things like BGP is quite 
respectable despite them being effectively single threaded.

/Jesper

___
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 Vitkovsky]

Hi Mark

 Of Mark Tinka
 Sent: 08 May 2015 19:19
 To: Chris Morrow; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Multi Core on JUNOS?
 
 
 
 On 8/May/15 20:12, Chris Morrow wrote:
  yes, mostly (not xr I think, if I recall correctly)
 
 One my biggest frustrations about IOS XR is the use of QNX on the CRS
 and ASR9000. So you end up with an RP that has greater than 4GB of RAM,
 and yet you can't access it.
 
If you are struggling with memory utilization you might want to be looking at 
BGP Multi-Instance feature available since 4.2.
If you are struggling with horsepower you can distribute BGP instances across 
multiple DRPs (only on CRS).

adam
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jesper Skriver]

 On 08 May 2015, at 23:34, Saku Ytti s...@ytti.fi wrote:
 
 On (2015-05-08 20:16 +0200), Mark Tinka wrote:
 
 IOS XE uses multiple cores in the data plane, but now that I think about
 it, I haven't delved into what their strategy for the RP is. I should ask.
 
 iosd uses several kernel threads, so RP is using more than one core. But it
 looks like it's role-based, and single ios-xr task itself cannot use multiple
 core.

Not true, FIB on XR for example is multithreaded, so are some other processes.

/Jesper

 
 -- 
  ++ytti
 ___
 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

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

[Colton Conor]

When is that supposed to be released?

On Fri, May 8, 2015 at 10:23 AM, Arie Vayner ar...@vayner.net wrote:

 Junos 15
 On May 8, 2015 7:57 AM, Colton Conor colton.co...@gmail.com wrote:

 Release 15 or in 2015?

 On Fri, May 8, 2015 at 9:17 AM, Arie Vayner ar...@vayner.net wrote:

 It's coming in 15
 On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote:

 Has juniper implemented the use of multicore processors in their
 software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?

 For example, the MX80 has two cores. Are both of them in use?
 ___
 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

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

[Arie Vayner]

It's coming in 15
On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote:

 Has juniper implemented the use of multicore processors in their software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?

 For example, the MX80 has two cores. Are both of them in use?
 ___
 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

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

[Colton Conor]

Release 15 or in 2015?

On Fri, May 8, 2015 at 9:17 AM, Arie Vayner ar...@vayner.net wrote:

 It's coming in 15
 On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote:

 Has juniper implemented the use of multicore processors in their software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?

 For example, the MX80 has two cores. Are both of them in use?
 ___
 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

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

[Arie Vayner]

Junos 15
On May 8, 2015 7:57 AM, Colton Conor colton.co...@gmail.com wrote:

 Release 15 or in 2015?

 On Fri, May 8, 2015 at 9:17 AM, Arie Vayner ar...@vayner.net wrote:

 It's coming in 15
 On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote:

 Has juniper implemented the use of multicore processors in their software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?

 For example, the MX80 has two cores. Are both of them in use?
 ___
 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

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

[Olivier Benghozi]

In 15 for Intel based RE, but for MX80 PowerPC, not sure if the second core 
will ever be supported...

 Le 8 mai 2015 à 16:17, Arie Vayner ar...@vayner.net a écrit :
 
 It's coming in 15
 On May 8, 2015 7:13 AM, Colton Conor colton.co...@gmail.com wrote:
 
 Has juniper implemented the use of multicore processors in their software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?
 
 For example, the MX80 has two cores. Are both of them in use?

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

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

[Colton Conor]

So are the other vendors, Brocade, Cisco and ALU all single core in
software as well, or is this just a Juniper thing? Whats the point of
having all these cores on the RE's if you unable to use be one of them?

On Fri, May 8, 2015 at 1:05 PM, Mark Tinka mark.ti...@seacom.mu wrote:



 On 8/May/15 16:12, Colton Conor wrote:
  Has juniper implemented the use of multicore processors in their software
  yet? From what I read I heard it was coming, but I am not sure in what
  release. I can't seem to find any information about it on Juniper's
  website? What is the current status of multi core threads in Junos?
 
  For example, the MX80 has two cores. Are both of them in use?

 The code is starting to get optimized in the later years of Junos 14,
 but much of this will begin to surface in Junos 15 and 16.

 Knowing how things go, it's likely going to take some time before the
 whole thing is structured properly. So expect real improvements to
 happen gradually.

 This is quite painful because it means constant upgrades if you want the
 support, and all the hassle that comes with that.

 Mark.

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

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

[david.roy]

Alu uses 10 cores.

Br



 Message d'origine 
De : Colton Conor
Date :08/05/2015 20:09 (GMT+01:00)
À : Mark Tinka
Cc : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] Multi Core on JUNOS?

So are the other vendors, Brocade, Cisco and ALU all single core in
software as well, or is this just a Juniper thing? Whats the point of
having all these cores on the RE's if you unable to use be one of them?

On Fri, May 8, 2015 at 1:05 PM, Mark Tinka mark.ti...@seacom.mu wrote:



 On 8/May/15 16:12, Colton Conor wrote:
  Has juniper implemented the use of multicore processors in their software
  yet? From what I read I heard it was coming, but I am not sure in what
  release. I can't seem to find any information about it on Juniper's
  website? What is the current status of multi core threads in Junos?
 
  For example, the MX80 has two cores. Are both of them in use?

 The code is starting to get optimized in the later years of Junos 14,
 but much of this will begin to surface in Junos 15 and 16.

 Knowing how things go, it's likely going to take some time before the
 whole thing is structured properly. So expect real improvements to
 happen gradually.

 This is quite painful because it means constant upgrades if you want the
 support, and all the hassle that comes with that.

 Mark.

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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

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

[Mark Tinka]

On 8/May/15 20:12, Chris Morrow wrote:
 yes, mostly (not xr I think, if I recall correctly)

One my biggest frustrations about IOS XR is the use of QNX on the CRS
and ASR9000. So you end up with an RP that has greater than 4GB of RAM,
and yet you can't access it.

IOS XR over Linux on the NCS will be the answer, but I'm nowhere near
the capacity of my CRS-X platform, so... then again, a BGP-free core
means my control plane memory is well under control on those boxes, but
we do have ASR9001's that do quite a bit of peering, so one has to think
about that.
 can't buy a single core intel/amd chip anymore?

This is also true.

It's not like the vendors have a choice nowadays anyway.

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

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

[Chris Morrow]

On 05/08/2015 03:15 PM, Colton Conor wrote:
 use multiple cores

please define this better.
Does their version of rpd actually get multi-threaded? and end up using
more than 1 core at once? does the 'rpd' get stuck to a single core and
everything else floats around on several more?

this is what, in a sense, newer junos does... nothing you care about is
multithreaded (or just straight smp), but the underlying fbsd is so
somethings run on other cores.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Mark Tinka]

On 8/May/15 16:12, Colton Conor wrote:
 Has juniper implemented the use of multicore processors in their software
 yet? From what I read I heard it was coming, but I am not sure in what
 release. I can't seem to find any information about it on Juniper's
 website? What is the current status of multi core threads in Junos?

 For example, the MX80 has two cores. Are both of them in use?

The code is starting to get optimized in the later years of Junos 14,
but much of this will begin to surface in Junos 15 and 16.

Knowing how things go, it's likely going to take some time before the
whole thing is structured properly. So expect real improvements to
happen gradually.

This is quite painful because it means constant upgrades if you want the
support, and all the hassle that comes with that.

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

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

[Chris Morrow]

On 05/08/2015 02:08 PM, Colton Conor wrote:
 So are the other vendors, Brocade, Cisco and ALU all single core in
 software as well, or is this just a Juniper thing? Whats the point of

yes, mostly (not xr I think, if I recall correctly)

 having all these cores on the RE's if you unable to use be one of them?

can't buy a single core intel/amd chip anymore?



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

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

[Colton Conor]

So, what ALU is telling me is true. They have a slide that shows how their
routers use multiple cores, but they mentioned Juniper and Cisco don't. I
told them that I know that's not true as Juniper and Cisco both have multi
core processors, but I guess they are semi correct since from the sounds of
it Juniper and Cisco's software isn't up to date to do muticore processes?

It is 2015 right? Why are we acting like multicore processors just came
out? What is taking these giants so long to update their code to support
multiple cores in processors in their own products? This blows my mind.

On Fri, May 8, 2015 at 1:15 PM, david@orange.com wrote:

  Alu uses 10 cores.

 Br



  Message d'origine 
 De : Colton Conor
 Date :08/05/2015 20:09 (GMT+01:00)
 À : Mark Tinka
 Cc : juniper-nsp@puck.nether.net
 Objet : Re: [j-nsp] Multi Core on JUNOS?

 _

 Ce message et ses pieces jointes peuvent contenir des informations 
 confidentielles ou privilegiees et ne doivent donc
 pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
 ce message par erreur, veuillez le signaler
 a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
 electroniques etant susceptibles d'alteration,
 Orange decline toute responsabilite si ce message a ete altere, deforme ou 
 falsifie. Merci.

 This message and its attachments may contain confidential or privileged 
 information that may be protected by law;
 they should not be distributed, used or copied without authorisation.
 If you have received this email in error, please notify the sender and delete 
 this message and its attachments.
 As emails may be altered, Orange is not liable for messages that have been 
 modified, changed or falsified.
 Thank you.

 So are the other vendors, Brocade, Cisco and ALU all single core in
 software as well, or is this just a Juniper thing? Whats the point of
 having all these cores on the RE's if you unable to use be one of them?

 On Fri, May 8, 2015 at 1:05 PM, Mark Tinka mark.ti...@seacom.mu wrote:

 
 
  On 8/May/15 16:12, Colton Conor wrote:
   Has juniper implemented the use of multicore processors in their
 software
   yet? From what I read I heard it was coming, but I am not sure in what
   release. I can't seem to find any information about it on Juniper's
   website? What is the current status of multi core threads in Junos?
  
   For example, the MX80 has two cores. Are both of them in use?
 
  The code is starting to get optimized in the later years of Junos 14,
  but much of this will begin to surface in Junos 15 and 16.
 
  Knowing how things go, it's likely going to take some time before the
  whole thing is structured properly. So expect real improvements to
  happen gradually.
 
  This is quite painful because it means constant upgrades if you want the
  support, and all the hassle that comes with that.
 
  Mark.
 
 ___
 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

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

[Mark Tinka]

On 8/May/15 20:08, Colton Conor wrote:
 So are the other vendors, Brocade, Cisco and ALU all single core in
 software as well, or is this just a Juniper thing? Whats the point of
 having all these cores on the RE's if you unable to use be one of them?

I can't speak to Brocade or ALU, but it's just about the same in Cisco land.

IOS XR should see more improvement as they transition from QNX to Linux
for the NCS (especially since they plan to support IOS XR VM's on the
NCS control plane). But I don't expect that to back-port to the CRS;
maybe to the ASR9000 at some point.

IOS XE uses multiple cores in the data plane, but now that I think about
it, I haven't delved into what their strategy for the RP is. I should ask.

I guess I have been less keen on Cisco's side of things because over the
years, they have re-written IOS (and by extension, IOS XE) to improve
the routing performance tremendously, even on non-Intel platforms. RPD
in Junos has suffered for a long time, and I think improvements there -
first and foremost - are what most of us are waiting for.

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

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

[Alastair Johnson]

Yes, routing protocols on SR OS use multiple cores (within protocols, and 
across protocols).

Feel free to contact me off-list, or on alcatel-nsp, for further discussion.

AJ

  Original Message  
From: Chris Morrow
Sent: Friday, May 8, 2015 3:22 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Multi Core on JUNOS?



On 05/08/2015 03:15 PM, Colton Conor wrote:
 use multiple cores

please define this better.
Does their version of rpd actually get multi-threaded? and end up using
more than 1 core at once? does the 'rpd' get stuck to a single core and
everything else floats around on several more?

this is what, in a sense, newer junos does... nothing you care about is
multithreaded (or just straight smp), but the underlying fbsd is so
somethings run on other cores.
___
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

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

[Chris Morrow]

On 05/08/2015 04:05 PM, Alastair Johnson wrote:
 Yes, routing protocols on SR OS use multiple cores (within protocols, and 
 across protocols).
 
 Feel free to contact me off-list, or on alcatel-nsp, for further discussion.

neat!
___
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 (2015-05-08 20:16 +0200), Mark Tinka wrote:

 IOS XE uses multiple cores in the data plane, but now that I think about
 it, I haven't delved into what their strategy for the RP is. I should ask.

iosd uses several kernel threads, so RP is using more than one core. But it
looks like it's role-based, and single ios-xr task itself cannot use multiple
core.

-- 
  ++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?

[Mike Allen]

With Brocade, it is platform dependent.  DC switching (VDX) for now use
multiple cores/VM's for the OS, and all of the newer campus products have
multicore processors, with a roadmap to utilize them in the future.

Mike

On Fri, May 8, 2015 at 1:34 PM Saku Ytti s...@ytti.fi wrote:

 On (2015-05-08 20:16 +0200), Mark Tinka wrote:

  IOS XE uses multiple cores in the data plane, but now that I think about
  it, I haven't delved into what their strategy for the RP is. I should
 ask.

 iosd uses several kernel threads, so RP is using more than one core. But it
 looks like it's role-based, and single ios-xr task itself cannot use
 multiple
 core.

 --
   ++ytti
 ___
 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