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

2015-10-08 Thread 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?

2015-10-08 Thread 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?

2015-10-08 Thread 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?

2015-10-08 Thread 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?

2015-10-08 Thread 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?

2015-10-08 Thread 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" 
Sent: ‎10/‎8/‎2015 3:55 PM
To: "Saku Ytti" ; "Colton Conor" 
Cc: "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] vmx on aws

2015-10-08 Thread Pavel Shirshov 
It can't be imported anywhere, except Linux KVM and VMWare ESXi. I
think that import is possible, but I don't think it would work well on
aws.

On Tue, Oct 6, 2015 at 9:09 AM, Nikos Leontsinis  wrote:
> Anyone knows if the vmc can be imported as a vm on aws?
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 
With best regards, Pavel S. Shirshov
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp