[j-nsp] Debug ip packet equivalent for directed at RE traffic

[Alex K.]

*Chris*

בתאריך 28 בנוב' 2016 10:08 PM,‏ "Alex K." <nsp.lists at gmail.com> כתב:

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