Re: [j-nsp] EX4600 : Ping problem
G'day Doug, On 29 November 2016 at 11:02, Doug McIntyre wrote: > > On Tue, Nov 29, 2016 at 10:32:15AM +1100, Dale Shaw wrote: > > > > EX4600 runs Enhanced Layer 2 Software (ELS), so it's correct to use "irb.n" > > vs. "vlan.n" > ... > > As of JunOS 13.2X51-D25.. If you run the JTAC suggested 12.3 on this > platform it does not yet use ELS... 13.2X51-D25 was the first Junos release to support EX4600 and as you point out, it runs ELS. There is no release of Junos 12.3 that supports the EX4600 platform. Also, the JTAC recommended release for EX4600 is currently 14.1X53-D35. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
On Tue, Nov 29, 2016 at 10:32:15AM +1100, Dale Shaw wrote: > On 29 November 2016 at 08:35, Eduardo Schoedler wrote: > > > > Here on EX2200 I put ip address directly in the vlan. > > > > Try this: > > > > set interfaces vlan unit xxx family inet address 10.x.x.x/24 > > set vlans vlan-RESEAUX l3-interface vlan.xxx > > set interfaces ge-0/x/x unit 0 family ethernet-switching vlan members > > vlan-RESEAUX > > EX4600 runs Enhanced Layer 2 Software (ELS), so it's correct to use "irb.n" > vs. "vlan.n" ... As of JunOS 13.2X51-D25.. If you run the JTAC suggested 12.3 on this platform it does not yet use ELS... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
Hi Eduardo, On 29 November 2016 at 08:35, Eduardo Schoedler wrote: > > Here on EX2200 I put ip address directly in the vlan. > > Try this: > > set interfaces vlan unit xxx family inet address 10.x.x.x/24 > set vlans vlan-RESEAUX l3-interface vlan.xxx > set interfaces ge-0/x/x unit 0 family ethernet-switching vlan members > vlan-RESEAUX EX4600 runs Enhanced Layer 2 Software (ELS), so it's correct to use "irb.n" vs. "vlan.n" I assume Deloin's config was hand-typed because it should be "l3-interface" rather than "l3.interface". As someone else pointed out, if the link is point-to-point, only .4 and .5 will be reachable. xe-0/0/1 is the 2nd (bottom left) interface. We need some more "show" outputs and/or a complete config to figure out what's going on. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
Here on EX2200 I put ip address directly in the vlan. Try this: set interfaces vlan unit xxx family inet address 10.x.x.x/24 set vlans vlan-RESEAUX l3-interface vlan.xxx set interfaces ge-0/x/x unit 0 family ethernet-switching vlan members vlan-RESEAUX Regards, 2016-11-28 17:55 GMT-02:00 Deloin via juniper-nsp : > > Hello, > > I have 2 EX4600 switchs. > They have the same symetric configurations: > > > SWITCH EX4600-1SWITCH EX4600-2 > > interfaces { interfaces { > xe-0/0/1 { xe-0/0/1 { > unit 0 { unit 0 { > family ethernet-switching {family ethernet-switching { > interface-mode access; interface-mode access; > vlan { vlan { > members vlan-RESEAUX; members vlan-RESEAUX; > } } > storm-control default; storm-control default; > } } > } } > } } > > irb { irb { > unit 0 { unit 0 { > family inet { family inet { > address 10.101.0.4/16; address 10.101.0.5/16; > } } > } } > } } > } } > > > routing-options { routing-options { > static { static { > route 0.0.0.0/0 next-hop 10.101.0.1; route 0.0.0.0/0 next-hop > 10.101.0.1; > } } > } } > > > vlans {vlans { > default { default { > vlan-id 1; vlan-id 1; > } } > > vlan-RESEAUX { vlan-RESEAUX { > vlan-id 98;vlan-id 98; > l3.interface irb.0;l3.interface irb.0; > } } > } } > > I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the > other switch. > And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs. > I obtain : > root@EX4600-01# run ping 10.101.0.3 > PING 10.101.0.3 (10.101.0.3): 56 data bytes > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > the same for the other. > > Can you help me. Can you tell me where is the mistake, or what I forget ? > > Thank you ! > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Eduardo Schoedler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
On 28. nov. 2016 21:18, Eric Van Tol wrote: 'no route to host' normally means 'did not get an arp reply, could not deliver packet'. "no route to host" normally indicates that the route does not exist in the routing table, not that an ARP response isn't coming back. On a local network the two statements are identical. You don't have a "route" to the host, as you expect it to be directly connected, hence the reply "no route to host" when you don't get an arp-reply. Rgds. Ola Thoresen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
Can you provide the following outputs from both switches? - show interfaces terse- show vlans- show route -Regards, Jared On Monday, November 28, 2016 12:55 PM, Deloin via juniper-nsp wrote: Hello, I have 2 EX4600 switchs. They have the same symetric configurations: SWITCH EX4600-1 SWITCH EX4600-2 interfaces { interfaces { xe-0/0/1 { xe-0/0/1 { unit 0 { unit 0 { family ethernet-switching { family ethernet-switching { interface-mode access; interface-mode access; vlan { vlan { members vlan-RESEAUX; members vlan-RESEAUX; } } storm-control default; storm-control default; } } } } } } irb { irb { unit 0 { unit 0 { family inet { family inet { address 10.101.0.4/16; address 10.101.0.5/16; } } } } } } } } routing-options { routing-options { static { static { route 0.0.0.0/0 next-hop 10.101.0.1; route 0.0.0.0/0 next-hop 10.101.0.1; } } } } vlans { vlans { default { default { vlan-id 1; vlan-id 1; } } vlan-RESEAUX { vlan-RESEAUX { vlan-id 98; vlan-id 98; l3.interface irb.0; l3.interface irb.0; } } } } I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the other switch. And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs. I obtain : root@EX4600-01# run ping 10.101.0.3 PING 10.101.0.3 (10.101.0.3): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host the same for the other. Can you help me. Can you tell me where is the mistake, or what I forget ? Thank you ! ___ 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] EX4600 : Ping problem
> 'no route to host' normally means 'did not get an > arp reply, could not deliver packet'. "no route to host" normally indicates that the route does not exist in the routing table, not that an ARP response isn't coming back. Are all your interfaces operationally up, including the IRB? -evt > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > Chris Morrow > Sent: Monday, November 28, 2016 3:06 PM > To: deloin.rob...@laposte.net > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] EX4600 : Ping problem > > SAt Mon, 28 Nov 2016 20:55:04 +0100 (CET), > Deloin via juniper-nsp wrote: > > > > > > Hello, > > > > I have 2 EX4600 switchs. > > They have the same symetric configurations: > > > > > > SWITCH EX4600-1SWITCH EX4600-2 > > > > interfaces { interfaces { > > xe-0/0/1 { xe-0/0/1 { > > unit 0 { unit 0 { > > family ethernet-switching {family ethernet-switching { > > interface-mode access; interface-mode access; > > vlan { vlan { > > members vlan-RESEAUX; members vlan-RESEAUX; > > } } > > storm-control default; storm-control default; > > } } > > } } > > } } > > > > irb { irb { > > unit 0 { unit 0 { > > family inet { family inet { > > address 10.101.0.4/16; address 10.101.0.5/16; > > } } > > } } > > } } > > } } > > > > > > routing-options { routing-options { > > static { static { > > route 0.0.0.0/0 next-hop 10.101.0.1; route 0.0.0.0/0 next-hop > 10.101.0.1; > > } } > > } } > > > > > > vlans {vlans { > > default { default { > > vlan-id 1; vlan-id 1; > > } } > > > > vlan-RESEAUX { vlan-RESEAUX { > > vlan-id 98;vlan-id 98; > > l3.interface irb.0;l3.interface irb.0; > > } } > > } } > > > > I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the > other switch. > > And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs. > > you appear to have 2 interfaces connected, with a single fiber and a > /16 netblock assigned. Then you ping .3 which is on neither > interface, so ... 'no route to host' normally means 'did not get an > arp reply, could not deliver packet'. > > this sounds like it's working exactly as expected? > > > I obtain : > > root@EX4600-01# run ping 10.101.0.3 > > PING 10.101.0.3 (10.101.0.3): 56 data bytes > > ping: sendto: No route to host > > ping: sendto: No route to host > > ping: sendto: No route to host > > ping: sendto: No route to host > > the same for the other. > > > > Can you help me. Can you tell me where is the mistake, or what I forget ? > > > > Thank you ! > > ___ > > 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] Debug ip packet equivalent for directed at RE traffic
*Chris* בתאריך 28 בנוב' 2016 10:08 PM, "Alex K." כתב: > Thank you Tim, > > But it's not as easy. There seems to be no easy explanation, hence I'm > interested in a trace option that will shed a little bit more light, on how > EX process the packet. > > בתאריך 28 בנוב' 2016 9:53 PM, "Chris Morrow" > כתב: > >> At Mon, 28 Nov 2016 19:17:41 +, >> "Alex K." wrote: >> > >> > Thank you Tim and Chris, >> > >> > But correct me if I'm wrong - those are not quite the same thing. >> > >> > There's no doubt packets are reaching the box (I have PC connected >> directly >> > to the switch). >> > >> > The difference between traffic monitoring/mirroring and Ciscos' debug, >> is >> > that with debug you follow the path a packet takes. >> > >> > Traffic monitoring can be a really helpful first step (as I've said, >> there >> > virtually no doubt the packets are reaching the RE), but my question is >> > about - what's next? >> > >> > Assumed you see only echo requsts and no replies (by "monitor traffic", >> for >> > example), is there is a trace option to show why an EX decided it >> shouldn't >> > answer with reply (from its own address)? >> >> honestly it's not that hard to tell what went wrong: >> 1) route back to the source is broken/unknown >> b) loopback filter dropped inbound packet >> z) ... that's it. >> >> or that's been my experience. >> > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic
Thank you Tim, But it's not as easy. There seems to be no easy explanation, hence I'm interested in a trace option that will shed a little bit more light, on how EX process the packet. בתאריך 28 בנוב' 2016 9:53 PM, "Chris Morrow" כתב: > At Mon, 28 Nov 2016 19:17:41 +, > "Alex K." wrote: > > > > Thank you Tim and Chris, > > > > But correct me if I'm wrong - those are not quite the same thing. > > > > There's no doubt packets are reaching the box (I have PC connected > directly > > to the switch). > > > > The difference between traffic monitoring/mirroring and Ciscos' debug, is > > that with debug you follow the path a packet takes. > > > > Traffic monitoring can be a really helpful first step (as I've said, > there > > virtually no doubt the packets are reaching the RE), but my question is > > about - what's next? > > > > Assumed you see only echo requsts and no replies (by "monitor traffic", > for > > example), is there is a trace option to show why an EX decided it > shouldn't > > answer with reply (from its own address)? > > honestly it's not that hard to tell what went wrong: > 1) route back to the source is broken/unknown > b) loopback filter dropped inbound packet > z) ... that's it. > > or that's been my experience. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 : Ping problem
SAt Mon, 28 Nov 2016 20:55:04 +0100 (CET), Deloin via juniper-nsp wrote: > > > Hello, > > I have 2 EX4600 switchs. > They have the same symetric configurations: > > > SWITCH EX4600-1SWITCH EX4600-2 > > interfaces { interfaces { > xe-0/0/1 { xe-0/0/1 { > unit 0 { unit 0 { > family ethernet-switching {family ethernet-switching { > interface-mode access; interface-mode access; > vlan { vlan { > members vlan-RESEAUX; members vlan-RESEAUX; > } } > storm-control default; storm-control default; > } } > } } > } } > > irb { irb { > unit 0 { unit 0 { > family inet { family inet { > address 10.101.0.4/16; address 10.101.0.5/16; > } } > } } > } } > } } > > > routing-options { routing-options { > static { static { > route 0.0.0.0/0 next-hop 10.101.0.1; route 0.0.0.0/0 next-hop > 10.101.0.1; > } } > } } > > > vlans {vlans { > default { default { > vlan-id 1; vlan-id 1; > } } > > vlan-RESEAUX { vlan-RESEAUX { > vlan-id 98;vlan-id 98; > l3.interface irb.0;l3.interface irb.0; > } } > } } > > I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the > other switch. > And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs. you appear to have 2 interfaces connected, with a single fiber and a /16 netblock assigned. Then you ping .3 which is on neither interface, so ... 'no route to host' normally means 'did not get an arp reply, could not deliver packet'. this sounds like it's working exactly as expected? > I obtain : > root@EX4600-01# run ping 10.101.0.3 > PING 10.101.0.3 (10.101.0.3): 56 data bytes > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > ping: sendto: No route to host > the same for the other. > > Can you help me. Can you tell me where is the mistake, or what I forget ? > > Thank you ! > ___ > 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] EX4600 : Ping problem
Hello, I have 2 EX4600 switchs. They have the same symetric configurations: SWITCH EX4600-1SWITCH EX4600-2 interfaces { interfaces { xe-0/0/1 { xe-0/0/1 { unit 0 { unit 0 { family ethernet-switching {family ethernet-switching { interface-mode access; interface-mode access; vlan { vlan { members vlan-RESEAUX; members vlan-RESEAUX; } } storm-control default; storm-control default; } } } } } } irb { irb { unit 0 { unit 0 { family inet { family inet { address 10.101.0.4/16; address 10.101.0.5/16; } } } } } } } } routing-options { routing-options { static { static { route 0.0.0.0/0 next-hop 10.101.0.1; route 0.0.0.0/0 next-hop 10.101.0.1; } } } } vlans {vlans { default { default { vlan-id 1; vlan-id 1; } } vlan-RESEAUX { vlan-RESEAUX { vlan-id 98;vlan-id 98; l3.interface irb.0;l3.interface irb.0; } } } } I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the other switch. And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs. I obtain : root@EX4600-01# run ping 10.101.0.3 PING 10.101.0.3 (10.101.0.3): 56 data bytes ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host ping: sendto: No route to host the same for the other. Can you help me. Can you tell me where is the mistake, or what I forget ? Thank you ! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic
At Mon, 28 Nov 2016 19:17:41 +, "Alex K." wrote: > > Thank you Tim and Chris, > > But correct me if I'm wrong - those are not quite the same thing. > > There's no doubt packets are reaching the box (I have PC connected directly > to the switch). > > The difference between traffic monitoring/mirroring and Ciscos' debug, is > that with debug you follow the path a packet takes. > > Traffic monitoring can be a really helpful first step (as I've said, there > virtually no doubt the packets are reaching the RE), but my question is > about - what's next? > > Assumed you see only echo requsts and no replies (by "monitor traffic", for > example), is there is a trace option to show why an EX decided it shouldn't > answer with reply (from its own address)? honestly it's not that hard to tell what went wrong: 1) route back to the source is broken/unknown b) loopback filter dropped inbound packet z) ... that's it. or that's been my experience. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic
Thank you Tim and Chris, But correct me if I'm wrong - those are not quite the same thing. There's no doubt packets are reaching the box (I have PC connected directly to the switch). The difference between traffic monitoring/mirroring and Ciscos' debug, is that with debug you follow the path a packet takes. Traffic monitoring can be a really helpful first step (as I've said, there virtually no doubt the packets are reaching the RE), but my question is about - what's next? Assumed you see only echo requsts and no replies (by "monitor traffic", for example), is there is a trace option to show why an EX decided it shouldn't answer with reply (from its own address)? בתאריך 28 בנוב' 2016 8:45 PM, "Tim Jackson" כתב: > monitor traffic interface ge-0/0/0 size no-resolve layer2-headers > extensive > > -- > Tim > > On Mon, Nov 28, 2016 at 12:43 PM, Alex K. wrote: > >> Hello everyone, >> >> By any chance - is there an equivalent for Ciscos' "debug ip packet" >> command in Juniper? >> >> I'm fully aware that there is a complete distinction between forwarding >> layer and control layer, in those devices - But, I'm taking specifically >> about traffic TARGETING the box itself. >> >> I'm troubleshooting a strange behavior by Juniper EX line. It's a compex >> topology but the issue is very simple: under certain circumstances, an EX >> stop responding even to pings to its own addresses, even from directly >> connected interfaces. >> >> I'm fully aware that I can mirror a port on those machines (and such), but >> mirroring alone, will not answer the million dollar question - why? >> >> Since there is no doubt that packets are reaching the box (packets don't >> leak from a directly connected cable, with PC on its other end) - I was >> hoping, Juniper might have provided us with a trace option, for following >> the packet inside the box? >> >> Anyone know such trace option? >> >> >> Any suggestions will be welcomed. >> ___ >> 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] Debug ip packet equivalent for directed at RE traffic
monitor traffic interface ge-0/0/0 size no-resolve layer2-headers extensive -- Tim On Mon, Nov 28, 2016 at 12:43 PM, Alex K. wrote: > Hello everyone, > > By any chance - is there an equivalent for Ciscos' "debug ip packet" > command in Juniper? > > I'm fully aware that there is a complete distinction between forwarding > layer and control layer, in those devices - But, I'm taking specifically > about traffic TARGETING the box itself. > > I'm troubleshooting a strange behavior by Juniper EX line. It's a compex > topology but the issue is very simple: under certain circumstances, an EX > stop responding even to pings to its own addresses, even from directly > connected interfaces. > > I'm fully aware that I can mirror a port on those machines (and such), but > mirroring alone, will not answer the million dollar question - why? > > Since there is no doubt that packets are reaching the box (packets don't > leak from a directly connected cable, with PC on its other end) - I was > hoping, Juniper might have provided us with a trace option, for following > the packet inside the box? > > Anyone know such trace option? > > > Any suggestions will be welcomed. > ___ > 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] Debug ip packet equivalent for directed at RE traffic
At Mon, 28 Nov 2016 18:43:02 +, "Alex K." wrote: > > Hello everyone, > > By any chance - is there an equivalent for Ciscos' "debug ip packet" > command in Juniper? > monitor packet ... or start shell - su - tcpdump ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Debug ip packet equivalent for directed at RE traffic
Hello everyone, By any chance - is there an equivalent for Ciscos' "debug ip packet" command in Juniper? I'm fully aware that there is a complete distinction between forwarding layer and control layer, in those devices - But, I'm taking specifically about traffic TARGETING the box itself. I'm troubleshooting a strange behavior by Juniper EX line. It's a compex topology but the issue is very simple: under certain circumstances, an EX stop responding even to pings to its own addresses, even from directly connected interfaces. I'm fully aware that I can mirror a port on those machines (and such), but mirroring alone, will not answer the million dollar question - why? Since there is no doubt that packets are reaching the box (packets don't leak from a directly connected cable, with PC on its other end) - I was hoping, Juniper might have provided us with a trace option, for following the packet inside the box? Anyone know such trace option? Any suggestions will be welcomed. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 show chassis environment discrepancy
Hi Lucio, I believe there is no discrepancy between outputs because they show different things. As far as I remember, the "Status" field of "show chassis environment output" can be one of the following: ok, failed, check, testing, absent In your case EX-PFE2 is OK, but it's just too hot. I'd recommend to check air flow on site. It might be also useful to check in the logs since when fans are spinning at a high speed and if there is no indication of the faulty fan. Alarms related to the faulty fan might be set and cleared periodically, so you may not see them in "show system alarms" but they should be visible in the log. Regards, Wojciech 2016-11-28 9:34 GMT+01:00 Valentini, Lucio : > Hi folks, > Has any of you ever come across this issue? > > If I look at the "show chassis environment output", everything seems to be > OK, but when I look at the more common "show system alarms" , it tells me > the temp is too high. > > Should I worry or can we keep going ? and if so, for how long ? is that > perhaps a bug fixed in later versions? I am using ver. 12.3R3.4. > > > user@switch> show chassis environment > Class Item Status Measurement > Power FPC 0 Power Supply 0 OK > FPC 0 Power Supply 1 OK > Temp FPC 0 CPU OK 51 degrees C / 123 degrees > F > FPC 0 EX-PFE1 OK 69 degrees C / 156 degrees > F > FPC 0 EX-PFE2 OK 91 degrees C / 195 degrees > F > FPC 0 EX-PFE3 OK 68 degrees C / 154 degrees > F > FPC 0 GEPHY Front Left OK 44 degrees C / 111 degrees > F > FPC 0 GEPHY Front Middle OK 48 degrees C / 118 degrees > F > FPC 0 GEPHY Front RightOK 50 degrees C / 122 degrees > F > FPC 0 Uplink Conn OK 50 degrees C / 122 degrees > F > Fans FPC 0 Fan 1OK Spinning at full speed > FPC 0 Fan 2OK Spinning at full speed > FPC 0 Fan 3OK Spinning at full speed > > > user@switch > show system alarms > 1 alarms currently active > Alarm time Class Description > 2016-11-22 18:36:43 CET Minor FPC 0 EX-PFE2 Temp Too Warm > > user@switch > show version > fpc0: > -- > Hostname: xxx > Model: ex4200-48t > JUNOS Base OS boot [12.3R3.4] > JUNOS Base OS Software Suite [12.3R3.4] > JUNOS Kernel Software Suite [12.3R3.4] > JUNOS Crypto Software Suite [12.3R3.4] > JUNOS Online Documentation [12.3R3.4] > JUNOS Enterprise Software Suite [12.3R3.4] > JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R3.4] > JUNOS Routing Software Suite [12.3R3.4] > JUNOS Web Management [12.3R3.4] > JUNOS FIPS mode utilities [12.3R3.4] > > user@switch > show chassis temperature-thresholds >Fan speed Yellow alarm Red alarm > Fire Shutdown > (degrees C) (degrees C) (degrees C) > (degrees C) > Item Normal High Normal Bad fan Normal Bad fan >Normal > FPC 0 CPU6070 80 70 95 85 > FPC 0 EX-PFE16070 80 70 95 85 > FPC 0 EX-PFE26070 80 70 95 85 > FPC 0 EX-PFE36070 80 70 95 85 > FPC 0 GEPHY Front Left 6070 80 70 95 85 > FPC 0 GEPHY Front Middle 6070 80 70 95 85 > FPC 0 GEPHY Front Right 6070 80 70 95 85 > FPC 0 Uplink Conn6070 80 70 95 85 > > Is it going to shutdown when the temperature raises above 95 deg C ? > > Thanks > > Best regards > > Ing. Lucio Valentini > > ___ > 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] EX4200 show chassis environment discrepancy
Hey Valentini, Yes you should worry, and no, I don't believe there is discrepancy, the OK just means it's operational, temperatures are not reflected there. Start by inspecting the fans and filters. If that fails, JTAC. On 28 November 2016 at 10:34, Valentini, Lucio wrote: > Hi folks, > Has any of you ever come across this issue? > > If I look at the "show chassis environment output", everything seems to be > OK, but when I look at the more common "show system alarms" , it tells me the > temp is too high. > > Should I worry or can we keep going ? and if so, for how long ? is that > perhaps a bug fixed in later versions? I am using ver. 12.3R3.4. > > > user@switch> show chassis environment > Class Item Status Measurement > Power FPC 0 Power Supply 0 OK > FPC 0 Power Supply 1 OK > Temp FPC 0 CPU OK 51 degrees C / 123 degrees F > FPC 0 EX-PFE1 OK 69 degrees C / 156 degrees F > FPC 0 EX-PFE2 OK 91 degrees C / 195 degrees F > FPC 0 EX-PFE3 OK 68 degrees C / 154 degrees F > FPC 0 GEPHY Front Left OK 44 degrees C / 111 degrees F > FPC 0 GEPHY Front Middle OK 48 degrees C / 118 degrees F > FPC 0 GEPHY Front RightOK 50 degrees C / 122 degrees F > FPC 0 Uplink Conn OK 50 degrees C / 122 degrees F > Fans FPC 0 Fan 1OK Spinning at full speed > FPC 0 Fan 2OK Spinning at full speed > FPC 0 Fan 3OK Spinning at full speed > > > user@switch > show system alarms > 1 alarms currently active > Alarm time Class Description > 2016-11-22 18:36:43 CET Minor FPC 0 EX-PFE2 Temp Too Warm > > user@switch > show version > fpc0: > -- > Hostname: xxx > Model: ex4200-48t > JUNOS Base OS boot [12.3R3.4] > JUNOS Base OS Software Suite [12.3R3.4] > JUNOS Kernel Software Suite [12.3R3.4] > JUNOS Crypto Software Suite [12.3R3.4] > JUNOS Online Documentation [12.3R3.4] > JUNOS Enterprise Software Suite [12.3R3.4] > JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R3.4] > JUNOS Routing Software Suite [12.3R3.4] > JUNOS Web Management [12.3R3.4] > JUNOS FIPS mode utilities [12.3R3.4] > > user@switch > show chassis temperature-thresholds >Fan speed Yellow alarm Red alarm > Fire Shutdown > (degrees C) (degrees C) (degrees C) > (degrees C) > Item Normal High Normal Bad fan Normal Bad fan > Normal > FPC 0 CPU6070 80 70 95 85 > FPC 0 EX-PFE16070 80 70 95 85 > FPC 0 EX-PFE26070 80 70 95 85 > FPC 0 EX-PFE36070 80 70 95 85 > FPC 0 GEPHY Front Left 6070 80 70 95 85 > FPC 0 GEPHY Front Middle 6070 80 70 95 85 > FPC 0 GEPHY Front Right 6070 80 70 95 85 > FPC 0 Uplink Conn6070 80 70 95 85 > > Is it going to shutdown when the temperature raises above 95 deg C ? > > Thanks > > Best regards > > Ing. Lucio Valentini > > ___ > 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] execute a command in SLAX script which does not have XML RPC equivalent available
Phil, >Looks like a bug to me. Thank you for confirming this! >Please have your AM PR it for us. Done. regards, Martin On Fri, Nov 25, 2016 at 7:55 PM, Phil Shafer wrote: > Looks like a bug to me. Please have your AM PR it for us. > > Thanks, > Phil > > > > Martin T writes: >>Jonathan, Phil, >> >>thank you for replies! RPC does what I desire >>for example in Junos versions 13.3R4.6 and 13.3R9.13 but not in >>14.1R7.4. In 14.1 release for example following code: >> >> var $request_system_license_save_cmd = { >> "/tmp/key" ; >> } >> var $request_system_license_save_results = jcs:invoke( >>$request_system_license_save_cmd ); >> >>..creates a file /tmp/key with no content: >> >>-rw--- 1 root wheel 0 Nov 25 10:18 key >> >> >>On the other hand, "request system license save /tmp/key" CLI command >>writes the key into the file. According to "Junos OS 14.1 XML API >>Operational Developer Reference" the "" is >>supported on MX series. Is this a bug? Or am I doing something wrong? >> >> >>thanks, >>Martin >> >>On Wed, Aug 17, 2016 at 1:19 AM, Phil Shafer wrote: >>> Martin T writes: I have a SLAX script where I execute "request system license save ftp://root:passwd@10.11.12.5"; command. >>> >>> [Background: the UI comes in two pieces. The CLI process handles >>> terminal I/O, key-bindings, automore, file transfers, and not much >>> else. The real brain resides in MGD, which understands commands, >>> RPCs, how to parse them and what to do with them.] >>> >>> The "request system license save" command uses both halves. MGD >>> asks CLI to do the transfer, and then MGD does with real work. >>> >>> SLAX scripts use the API directly, so it cannot perform the >>> file-transfer. >>> >>> The fix is to pass a local file name to the "request system license >>> save" command RPC and then do the transfer explicitly using the >>> RPC. >>> >>> Thanks, >>> Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 show chassis environment discrepancy
Hi folks, Has any of you ever come across this issue? If I look at the "show chassis environment output", everything seems to be OK, but when I look at the more common "show system alarms" , it tells me the temp is too high. Should I worry or can we keep going ? and if so, for how long ? is that perhaps a bug fixed in later versions? I am using ver. 12.3R3.4. user@switch> show chassis environment Class Item Status Measurement Power FPC 0 Power Supply 0 OK FPC 0 Power Supply 1 OK Temp FPC 0 CPU OK 51 degrees C / 123 degrees F FPC 0 EX-PFE1 OK 69 degrees C / 156 degrees F FPC 0 EX-PFE2 OK 91 degrees C / 195 degrees F FPC 0 EX-PFE3 OK 68 degrees C / 154 degrees F FPC 0 GEPHY Front Left OK 44 degrees C / 111 degrees F FPC 0 GEPHY Front Middle OK 48 degrees C / 118 degrees F FPC 0 GEPHY Front RightOK 50 degrees C / 122 degrees F FPC 0 Uplink Conn OK 50 degrees C / 122 degrees F Fans FPC 0 Fan 1OK Spinning at full speed FPC 0 Fan 2OK Spinning at full speed FPC 0 Fan 3OK Spinning at full speed user@switch > show system alarms 1 alarms currently active Alarm time Class Description 2016-11-22 18:36:43 CET Minor FPC 0 EX-PFE2 Temp Too Warm user@switch > show version fpc0: -- Hostname: xxx Model: ex4200-48t JUNOS Base OS boot [12.3R3.4] JUNOS Base OS Software Suite [12.3R3.4] JUNOS Kernel Software Suite [12.3R3.4] JUNOS Crypto Software Suite [12.3R3.4] JUNOS Online Documentation [12.3R3.4] JUNOS Enterprise Software Suite [12.3R3.4] JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R3.4] JUNOS Routing Software Suite [12.3R3.4] JUNOS Web Management [12.3R3.4] JUNOS FIPS mode utilities [12.3R3.4] user@switch > show chassis temperature-thresholds Fan speed Yellow alarm Red alarm Fire Shutdown (degrees C) (degrees C) (degrees C) (degrees C) Item Normal High Normal Bad fan Normal Bad fan Normal FPC 0 CPU6070 80 70 95 85 FPC 0 EX-PFE16070 80 70 95 85 FPC 0 EX-PFE26070 80 70 95 85 FPC 0 EX-PFE36070 80 70 95 85 FPC 0 GEPHY Front Left 6070 80 70 95 85 FPC 0 GEPHY Front Middle 6070 80 70 95 85 FPC 0 GEPHY Front Right 6070 80 70 95 85 FPC 0 Uplink Conn6070 80 70 95 85 Is it going to shutdown when the temperature raises above 95 deg C ? Thanks Best regards Ing. Lucio Valentini ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp