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

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

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

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

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

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

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

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

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

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 {

[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 {

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

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

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

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 ___

[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

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

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

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

[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