[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" <morrowc at ops-netman.net> כתב:

> At Mon, 28 Nov 2016 19:17:41 +0000,
> "Alex K." <nsp.lists at 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.
>