Re: [j-nsp] mx960 junos upgrade fail

[Aaron Gould]

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?

[Patrick Okui]

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 port changes are essentially like 
port-x/x/x, just without slashes... enp0s31f6 is ethernet on PCI bus 0 
slot 31 function 6, so like ge-0/31/6.


Apart from of course when they fall back to using Mac addresses as in 
enxf4f9***


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

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

[Chuck Anderson]

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, e.g. find all 
"uplink" ports by assuming ge-* are access ports and xe-* are uplinks.  
Patterns can be used within configuration groups and interface-ranges.

On Thu, Apr 05, 2018 at 01:38:46PM +, Nelson, Brian wrote:
> 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] 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)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Adams]

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.  You can do gig copper, just
not with a 10/100/1000 SFP (use a gig-only SFP).

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

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

[Niall Donaghy]

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 ;
juniper-nsp@puck.nether.net
Subject: 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 any ethernet speed, but
perhaps not given the 204 is a brand new model.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx960 junos upgrade fail

[Nelson, Brian]

(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: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Brian Nelson
Sent: Thursday, April 05, 2018 10:41 AM
To: Aaron Gould ; juniper-nsp@puck.nether.net
Subject: 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, Aaron Gould wrote:
> 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
>
>   
>
>   
>
> {master}
>
> agould@mx960> request system software validate in-service-upgrade 
> junos-install-mx-x86-64-16.1R3-S7.1.tgz
>
> error: Not enough free_space: 17770832 reqd_pkgsize: 18181496
>
> error: not enough space in /var on re0.
>
> error: need at least 9308927696 bytes free.
>
>   
>
>   
>
>   
>
>   
>
> - Aaron
>
> ___
> 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] mx960 junos upgrade fail

[Wojciech Janiszewski]

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
>
>
>
>
>
> {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
>
>
>
>
>
> {master}
>
> agould@mx960> request system software validate in-service-upgrade
> junos-install-mx-x86-64-16.1R3-S7.1.tgz
>
> error: Not enough free_space: 17770832 reqd_pkgsize: 18181496
>
> error: not enough space in /var on re0.
>
> error: need at least 9308927696 bytes free.
>
>
>
>
>
>
>
>
>
> - Aaron
>
> ___
> 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] mx960 junos upgrade fail

[Brian Nelson]

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, Aaron Gould wrote:

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

  

  


{master}

agould@mx960> request system software validate in-service-upgrade
junos-install-mx-x86-64-16.1R3-S7.1.tgz

error: Not enough free_space: 17770832 reqd_pkgsize: 18181496

error: not enough space in /var on re0.

error: need at least 9308927696 bytes free.

  

  

  

  


- Aaron

___
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

[j-nsp] mx960 junos upgrade fail

[Aaron Gould]

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

 

 

{master}

agould@mx960> request system software validate in-service-upgrade
junos-install-mx-x86-64-16.1R3-S7.1.tgz

error: Not enough free_space: 17770832 reqd_pkgsize: 18181496

error: not enough space in /var on re0.

error: need at least 9308927696 bytes free.

 

 

 

 

- Aaron

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

Re: [j-nsp] mx960 crashed

[Jonas Frey]

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:
https://kb.juniper.net/InfoCenter/index?page=content=KB6660=MET
ADATA

-Jonas
Am Donnerstag, den 05.04.2018, 09:34 -0500 schrieb Aaron Gould:
> 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 Gould
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] mx960 crashed
> 
> On Wed, 4 Apr 2018, Aaron Gould wrote:
> 
> > 
> > Any idea why this happened and how do I tshoot cause ?
> > 
> > login: root
> > 
> > Password:SysRq : Trigger a crash
> Looks like you're running a RE-S-X6-64G, and somehow sent it SysRq c
> --
> which is a break followed by c within 5 seconds on a serial console
> -- and
> the hypervisor dutifully crashed and wrote out a dump.  Can't really
> blame
> it for doing what it's told.
> 
> -Rob
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

signature.asc
Description: This is a digitally signed message part
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] mx960 crashed

[Aaron Gould]

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 Gould
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] mx960 crashed

On Wed, 4 Apr 2018, Aaron Gould wrote:

> Any idea why this happened and how do I tshoot cause ?

> login: root
>
> Password:SysRq : Trigger a crash

Looks like you're running a RE-S-X6-64G, and somehow sent it SysRq c --
which is a break followed by c within 5 seconds on a serial console -- and
the hypervisor dutifully crashed and wrote out a dump.  Can't really blame
it for doing what it's told.

-Rob

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

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

[Chris Adams]

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, just without slashes... enp0s31f6 is ethernet on PCI bus 0
slot 31 function 6, so like ge-0/31/6.
-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Julien Goodwin]

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 any ethernet speed,
but perhaps not given the 204 is a brand new model.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Nelson, Brian]

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] 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)
___
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] MX204 and copper SFP?

[Ola Thoresen]

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

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

[Saku Ytti]

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 expect.
>
> I have never understood the reason for having different names for
> ports depending on the speed of the transceiver.  To me, it just
> makes things more confusing.
>
> Can someone enlighten me on the benefits of that?
>
>
> /Bellman
>
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



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

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

[Thomas Bellman]

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
makes things more confusing.

Can someone enlighten me on the benefits of that?


/Bellman



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] MX204 and copper SFP?

[Saku Ytti]

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  wrote:
> On Wed, Apr 04, 2018 at 11:59:31AM -0500, Chris Adams wrote:
>> Has anyone tried a copper SFP in an MX204?  With 18.1R1, the ports can
>> be set to 1G mode, and I can use a fiber SFP, but a copper SFP doesn't
>> work for me.  The router sees it, but the port shows "up" (even with no
>> wire connected), and it won't actually pass any traffic when connected
>> (both ends see transmits but 0 receives).
>
> I've seen this with Finisar Copper-SFPs in 20x1G MICs which worked fine
> in 40x1G DPCs. Swapping them out with Methode Elec. SFPs did the trick.
>
> I remember that there were basically two different ways to signal
> link status from SFP to host, and the Finisars didn't do it the way the
> newer MX hardware expected it.
>
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



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