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
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
015 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 inte
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;
/*
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
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
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
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
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
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
> 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?
>
>
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
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
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
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
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
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
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
;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]
&g
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'
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
> 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
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
> 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
> 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
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
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
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 :)
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
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
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.
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
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
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
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
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
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
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
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
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
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
et" <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 c
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
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
> 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
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
-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 an
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
http://www.juniper.net/documentation/en_US/junos13.3/topics/reference/configuration-statement/routing-edit-system-processes.html
Statement introduced in Junos OS
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
.
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
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
-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 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
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
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
74 matches
Mail list logo