[prev in list] [next in list] [prev in thread] [next in thread] 

List:       juniper-nsp
Subject:    Re: [j-nsp] Debug ip packet equivalent for directed at RE traffic
From:       "Alex K." <nsp.lists () gmail ! com>
Date:       2016-11-28 20:09:19
Message-ID: CAA0bn6MPd09oP0c7UhDbgxQ8-3waamu6xFt-CsC9pgD6CAS4Kw () mail ! gmail ! com
[Download RAW message or body]

*Chris*

בתאריך 28 ב� וב' 2016 10:08 PM,‏ "Alex K." <nsp.lists@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@ops-netman.net>
> כתב:
>
>> At Mon, 28 Nov 2016 19:17:41 +0000,
>> "Alex K." <nsp.lists@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
[prev in list] [next in list] [prev in thread] [next in thread]