Re: [j-nsp] EX4600 : Ping problem

[Dale Shaw]

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

[Doug McIntyre]

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

[Dale Shaw]

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

[Eduardo Schoedler]

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

[Ola Thoresen]

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

[Jared Gull via juniper-nsp]

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

[Eric Van Tol]

> '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

[Alex K.]

*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

[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] EX4600 : Ping problem

[Chris Morrow]

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

[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

Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic

[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

[Alex K.]

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

[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

[Chris Morrow]

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

[Alex K.]

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

[Wojciech Janiszewski]

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

[Saku Ytti]

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

[Martin T]

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

[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