Re: [j-nsp] mx960 junos upgrade fail

Thanks Brian, you mentioned issu not supported from 15.1R to 16.1R, but I'm not doing that... I'm going from 15.1F to 16.1R - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX204 and copper SFP?

On 5 Apr 2018, at 17:07 EAT, Chris Adams wrote: Once upon a time, Ola Thoresen said: Don't we all love that "linux" changed from eth0, eth1, eth2... to beautiful stuff like wwp0s20u4 and enp0s25... Just call them port-x/x/x and be done with it. Well, to be fair, the Linux

Re: [j-nsp] MX204 and copper SFP?

Back-in-the-day we had fe-x/x/x for 10/100 Mbps ports. Now we have ge-x/x/x that can take a 100 Mbps SFP, but the name doesn't change to fe-x/x/x AFAIK. So there is precedent for the names not changing when the speed changes. But I do like having the ability to match ports based on speed,

Re: [j-nsp] MX204 and copper SFP?

Once upon a time, Chris Adams said: > FiberStore tri-rate, chipped as Juniper. I'm getting a non-tri-rate SFP > from somebody else to test and see if that's the issue. For the archives: yes, it appears that's the issue - a third-party EX-SFP-1GE-T links up and passes traffic.

Re: [j-nsp] MX204 and copper SFP?

I'm only aware of et- being used for both 100GE and 40GE. Is there another speed bearing this naming? -Original Message- From: Julien Goodwin [mailto:jgood...@studio442.com.au] Sent: 05 April 2018 15:02 To: Niall Donaghy ; Chris Adams ;

Re: [j-nsp] mx960 junos upgrade fail

(bugging me) Found it, release notes for 16.1R2 : ISSU is not supported from 15.1R releases to 16.1R releases, if ... multiple sections with all sorts of hardware limitations for ISSU. I'm waiting on 16.1 or will upgrade during a major outage window. Brian -Original Message- From:

Re: [j-nsp] mx960 junos upgrade fail

I'd first check if /var is mounted on the hard drive. Regards, Wojciech czw., 5.04.2018, 17:32 użytkownik Aaron Gould napisał: > mx960 junos upgrade fail due to the following reasons. any idea how to > overcome? > > > > > > I already did request system storage cleanup > > > >

Re: [j-nsp] mx960 junos upgrade fail

My notes for upgrade from 15.1F# to 16.1 state ISSU not supported to that release level of 16.1. Can't find the exact reference; but it was way down in a detailed note on support for the various MPCs. 15.1F# is a non-supported, at your own risk release anyway. Brian On 04/05/2018 10:30 AM,

[j-nsp] mx960 junos upgrade fail

mx960 junos upgrade fail due to the following reasons. any idea how to overcome? I already did request system storage cleanup {master} agould@mx960> show version invoke-on all-routing-engines | grep "Model|Junos:" Model: mx960 Junos: 15.1F7.3 Model: mx960 Junos: 15.1F7.3

Re: [j-nsp] mx960 crashed

It seems not be documented by juniper - atleast i couldnt find any (MX related) info. However its a basic linux procedure, see: https://en.wikipedia.org/wiki/Magic_SysRq_key Juniper only has some info regarding SysRQ & the IDP series at:

Re: [j-nsp] mx960 crashed

Thanks Rob, Is a break followed by c within 5 seconds a documented way to crash a RE-S-X6-64G ? Btw, Jtac couldn't find the dump Rma'ing RE ... said bad SSD on RE -Aaron -Original Message- From: Rob Foehl [mailto:r...@loonybin.net] Sent: Wednesday, April 4, 2018 2:11 PM To: Aaron

Re: [j-nsp] MX204 and copper SFP?

Once upon a time, Ola Thoresen said: > Don't we all love that "linux" changed from eth0, eth1, eth2... to > beautiful stuff like wwp0s20u4 and enp0s25... > > Just call them port-x/x/x and be done with it. Well, to be fair, the Linux port changes are essentially like port-x/x/x,

Re: [j-nsp] MX204 and copper SFP?

On 05/04/18 05:09, Niall Donaghy wrote: > Even more sad to see that 1G ports retain their xe- naming rather than > changing to ge- as you would hope and expect. Isn't the first time that's happened, IIRC 10g PICs on T640s presented as ge-x/x/x. Newer kit seemed to be converging on et-x/x/x for

Re: [j-nsp] MX204 and copper SFP?

Port-foo is so archaic. It's an interface, inf-x/x/x would be more germane. Brian -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ola Thoresen Sent: Thursday, April 05, 2018 3:59 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp]

Re: [j-nsp] MX204 and copper SFP?

On 05. april 2018 10:44, Saku Ytti wrote: Since of the fathers. 'Cisco did it'. I also see no value in it. Don't we all love that "linux" changed from eth0, eth1, eth2... to beautiful stuff like wwp0s20u4 and enp0s25... Just call them port-x/x/x and be done with it. /Ola (T)

Re: [j-nsp] MX204 and copper SFP?

Since of the fathers. 'Cisco did it'. I also see no value in it. On 5 April 2018 at 11:38, Thomas Bellman wrote: > On 2018-04-04 21:09, Niall Donaghy wrote: > >> Even more sad to see that 1G ports retain their xe- naming rather than >> changing to ge- as you would hope and

Re: [j-nsp] MX204 and copper SFP?

On 2018-04-04 21:09, Niall Donaghy wrote: > Even more sad to see that 1G ports retain their xe- naming rather than > changing to ge- as you would hope and expect. I have never understood the reason for having different names for ports depending on the speed of the transceiver. To me, it just

Re: [j-nsp] MX204 and copper SFP?

They don't even need to be MethodE, that string just needs to appear there as vendor. I think there is some part of code which uses that vendor string to discriminate how the CuSFP does link-state. CuSFP is notoriously difficult compared to opticals. On 5 April 2018 at 02:59, Daniel Roesen