*Chris* בתאריך 28 בנוב' 2016 10:08 PM, "Alex K." <[email protected]> כתב:
> 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" <[email protected]> > כתב: > >> At Mon, 28 Nov 2016 19:17:41 +0000, >> "Alex K." <[email protected]> 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 [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
