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" <morr...@ops-netman.net> כתב: > At Mon, 28 Nov 2016 19:17:41 +0000, > "Alex K." <nsp.li...@gmail.com> 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