Thanks all, It was a inherited configuration from group which was making
the mess.
Fixed.
On Thu, May 26, 2016 at 2:51 AM, Eduardo Schoedler
wrote:
> 2016-05-25 6:15 GMT-03:00 Mark Tinka :
> >
> >
> > On 25/May/16 11:10, Anand Anand wrote:
> >
> >> Hi,
> >>
> >> Im trying to test l2vpn in log
On 25/May/16 23:39, Phil Rosenthal wrote:
>
> I think Juniper made the right call -- if you have a reason to "need" the
> bleeding edge RE, you should also be fine with running the bleeding edge
> Junos.
Which, I think, is fair.
If you are willing to support a popular but older generation, I
> On May 25, 2016, at 5:37 PM, Mark Tinka wrote:
>
>
>
> On 25/May/16 23:33, Phil Rosenthal wrote:
>
>> There is a different network card driver, so it would require a different
>> kernel.
>
> Which needs time, porting and testing...
>
> Mark.
Oh I know, I was just saying that this is pr
On 25/May/16 23:33, Phil Rosenthal wrote:
> There is a different network card driver, so it would require a different
> kernel.
Which needs time, porting and testing...
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.neth
> On May 25, 2016, at 5:03 PM, Mark Tinka wrote:
>
>
>
> On 25/May/16 21:50, raf wrote:
>
>>
>>
>> This is really strange. I don't see technical reason why 14, 13 or
>> even old one could not use a newer RE. After all it was just a newer
>> CPU and more RAM.
>> It should work a least with o
On 25/May/16 21:50, raf wrote:
>
>
> This is really strange. I don't see technical reason why 14, 13 or
> even old one could not use a newer RE. After all it was just a newer
> CPU and more RAM.
> It should work a least with one core and 4G enabled.
Time involved in porting and testing.
>
On 25/May/16 20:57, Saku Ytti wrote:
> I don't find much value in official recommendations. Generally
> strategy with all vendors is:
>
> 1) get newest supported (if long term release exist then that)
> software available
> 2) if defects, upgrade minor version
> 3) if hw requires or feature requ
On 25/May/16 19:28, Daniel Verlouw wrote:
> definitely good and valid points, however are you willing to deploy
> (what I consider) bleeding-edge code in your network to support the
> latest and greatest HW? I'm most certainly not, have plenty of issues
> today with so-called 'stable' releases..
On 25/May/16 18:52, Phil Rosenthal wrote:
>
> I would bet money on this being the case. I would assume that a certain
> company that has a large search engine is of the general opinion "We like the
> hardware, but we do not want to use your software in any way. We can write
> our own software
On 25/May/16 18:47, Colton Conor wrote:
> Besides swapping the inter processor out for a new one, and adding more and
> faster ram, is there really any other big differences?
No one ever complained about faster processors and more RAM.
But there is a lot more to consider before deploying that
On 25/May/16 18:44, Michael Still wrote:
> Couple reasons. First is that this is pretty shiny new product and it's a
> good idea to expect bugs to be found in it. Second is that it requires you
> to run much newer / less well baked code than a lot of people are
> comfortable with in their networ
On 25/May/16 18:31, Colton Conor wrote:
> Assuming we are not going to be using these new RE's to load any 3rd party
> software on them, the RE-S-X6-64G-BB will just be a quicker processor with
> more ram compared to an older RE right? Are there any other benefits?
> Juniper is offering the RE-S
Le 25/05/2016 à 18:52, Phil Rosenthal a écrit :
This new RE requires Junos 15.1R4 minimum. If you have a reason to use 14.x or
13.x, then this RE will not work for you.
This is really strange. I don't see technical reason why 14, 13 or even
old one could not use a newer RE. After all it
> Am 25.05.2016 um 21:00 schrieb Phil Rosenthal :
>
>
>> On May 25, 2016, at 2:57 PM, Saku Ytti wrote:
>>
>> I would personally be very interested in jumping to 16.1 as soon as
>> practice, as BGP is supposedly in its own thread. Maybe RPD in its own
>> core. So that might bring lot of stabil
On 25 May 2016 at 22:00, Phil Rosenthal wrote:
> RPD is already essentially in it's own core in 15.1, since the kernel is
> finally SMP. I don't see how there would be any benefit to forcing
> affinity, if that's what you are implying?
Yeah, I'd like affinity for it, so no way will there be con
> On May 25, 2016, at 2:57 PM, Saku Ytti wrote:
>
> I would personally be very interested in jumping to 16.1 as soon as
> practice, as BGP is supposedly in its own thread. Maybe RPD in its own
> core. So that might bring lot of stability.
RPD is already essentially in it's own core in 15.1, sin
On 25 May 2016 at 20:59, Colton Conor wrote:
> So how long before Junos 15.1R4 or higher will be the offical JTAC
> Recommended Junos Software Version for MX Series with NG MPCs? Right now
> it's Junos 14.1R7
I don't find much value in official recommendations. Generally
strategy with all vendor
2016-05-25 6:15 GMT-03:00 Mark Tinka :
>
>
> On 25/May/16 11:10, Anand Anand wrote:
>
>> Hi,
>>
>> Im trying to test l2vpn in logical system. when configuring vlan-ccc for
>> the interface within the logical system, i get an error. if i do the same
>> in the global configuration, it commits fine.
>
> On May 25, 2016, at 1:59 PM, Colton Conor wrote:
>
> So how long before Junos 15.1R4 or higher will be the offical JTAC
> Recommended Junos Software Version for MX Series with NG MPCs? Right now
> it's Junos 14.1R7
Based on how things have gone in the past, the official recommendation won't
So how long before Junos 15.1R4 or higher will be the offical JTAC
Recommended Junos Software Version for MX Series with NG MPCs? Right now
it's Junos 14.1R7
On Wed, May 25, 2016 at 12:28 PM, Daniel Verlouw
wrote:
> Hi,
>
> On Wed, May 25, 2016 at 7:06 PM, Saku Ytti wrote:
> > Longer time befor
On Wed, May 25, 2016 at 08:30:06PM +0300, Saku Ytti wrote:
> On 25 May 2016 at 20:28, Daniel Verlouw wrote:
>
> > definitely good and valid points, however are you willing to deploy
> > (what I consider) bleeding-edge code in your network to support the
> > latest and greatest HW? I'm most certai
On 25 May 2016 at 20:28, Daniel Verlouw wrote:
> definitely good and valid points, however are you willing to deploy
> (what I consider) bleeding-edge code in your network to support the
> latest and greatest HW? I'm most certainly not, have plenty of issues
> today with so-called 'stable' releas
Hi,
On Wed, May 25, 2016 at 7:06 PM, Saku Ytti wrote:
> Longer time before it's end of support, better resell value on top of
> normal better scale and convergence.
definitely good and valid points, however are you willing to deploy
(what I consider) bleeding-edge code in your network to support
On 25 May 2016 at 19:47, Colton Conor wrote:
> Besides swapping the inter processor out for a new one, and adding more and
> faster ram, is there really any other big differences?
Longer time before it's end of support, better resell value on top of
normal better scale and convergence.
--
++y
> On May 25, 2016, at 12:31 PM, Colton Conor wrote:
>
> Assuming we are not going to be using these new RE's to load any 3rd party
> software on them, the RE-S-X6-64G-BB will just be a quicker processor with
> more ram compared to an older RE right? Are there any other benefits?
> Juniper is off
Besides swapping the inter processor out for a new one, and adding more and
faster ram, is there really any other big differences?
On Wed, May 25, 2016 at 11:44 AM, Michael Still
wrote:
>
>
> On Wed, May 25, 2016 at 12:31 PM, Colton Conor
> wrote:
>
>> Assuming we are not going to be using thes
On 25 May 2016 at 19:31, Colton Conor wrote:
> Assuming we are not going to be using these new RE's to load any 3rd party
> software on them, the RE-S-X6-64G-BB will just be a quicker processor with
> more ram compared to an older RE right? Are there any other benefits?
> Juniper is offering the R
On Wed, May 25, 2016 at 12:31 PM, Colton Conor
wrote:
> Assuming we are not going to be using these new RE's to load any 3rd party
> software on them, the RE-S-X6-64G-BB will just be a quicker processor with
> more ram compared to an older RE right? Are there any other benefits?
> Juniper is offe
Assuming we are not going to be using these new RE's to load any 3rd party
software on them, the RE-S-X6-64G-BB will just be a quicker processor with
more ram compared to an older RE right? Are there any other benefits?
Juniper is offering the RE-S-X6-64G-BB for the same price as
the RE-S-1800X4-32
On 25 May 2016 at 17:10, raf wrote:
Hey,
> On this point I disagree. Virtualization add a layer and a little overhead,
> but nowadays it's a mature and stable technologies.
> And splitting things and decoupling them are always a good things for me. I
> talk about junos which was a relatively com
Le 23/05/2016 à 18:57, Saku Ytti a écrit :
I think this is driven by not having options mostly, freescale isn't
there for today's control-plane scale
Yes absolutely; but as a side effect we should have a much reactive
control plane while junos was primarily coded on x86; and porting on
other
On 25/May/16 11:10, Anand Anand wrote:
> Hi,
>
> Im trying to test l2vpn in logical system. when configuring vlan-ccc for
> the interface within the logical system, i get an error. if i do the same
> in the global configuration, it commits fine.
>
> missing anything?
>
> lab# show logical-system
Hi,
Im trying to test l2vpn in logical system. when configuring vlan-ccc for
the interface within the logical system, i get an error. if i do the same
in the global configuration, it commits fine.
missing anything?
lab# show logical-systems pe1 interfaces ge-0/0/3
unit 0 {
encapsulation vlan
33 matches
Mail list logo