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