[j-nsp] DSCP-marked traffic mysteriously being dropped by MX960

[John Neiberger]

Someone else off-list just mentioned something similar. We're checking
into that now.

Thanks!
John

On Fri, Jul 20, 2012 at 3:49 PM, Wayne Tucker <wayne at tuckerlabs.com> wrote:
> Does show interfaces <blah> extensive on the interface between Router A and
> Device A show any drops?  IIRC, the default scheduler map does not define
> schedulers for anything other than be and nc - so if you're classifying the
> packets on input then it could be that they're going to a class that has no
> resources on the egress interface.
>
> :w
>
>
> On Fri, Jul 20, 2012 at 2:15 PM, John Neiberger <jneiberger at gmail.com>
> wrote:
>>
>> We have packet captures going at the endpoints, but not in between,
>> unfortunately. It would be nice if we had a sniffer at that location
>> so we could mirror the ports and get some data there.
>>
>> The inbound filter on Router C looks like this:
>>
>> term netmgmt {
>>     then {
>>         count fec-cs2;
>>         loss-priority high;
>>         forwarding-class MNGMT;
>>
>> Elsewhere, MNGMT is defined as cs2.
>>
>> The outbound filter on Router A toward the end device is very long,
>> but the first two terms should allow ICMP and traceroute from the
>> address space that Device B is in. Further down in the filter is
>> another term that specifically permits CS2, among other things. We
>> know that that filter is working because when we remove the ingress
>> marking filter everything starts working, which indicates that the
>> outbound filter on Router A is correctly matching the source IP
>> address of Device B. I'd like to post more of the config, but I'm
>> trying to keep it sanitized and anonymous.  :)  I don't want to
>> irritate any bosses by posting our configs publicly.
>>
>> Thanks,
>> John
>>
>> On Fri, Jul 20, 2012 at 3:04 PM, OBrien, Will <ObrienH at missouri.edu>
>> wrote:
>> > Have you captured traffic before and after to validate the marking?
>> > Relavent config bits would help.
>> >
>> > On Jul 20, 2012, at 3:56 PM, John Neiberger wrote:
>> >
>> >> We've been troubleshooting a strange problem for a few days. JTAC is
>> >> on the case, too, but we have not found any resolution. I thought
>> >> maybe picking some minds here would be helpful. Here is a simplified
>> >> diagram:
>> >>
>> >> [Device A] -------   [Router A] -------  [Router B] ------- [Router C]
>> >> ----- [Device B]
>> >>
>> >> The problem is that packets from Device B to Device A are being
>> >> dropped at Router A. Routers A and C are MX960s. Router B is a CRS.
>> >> Router C has an ingress firewall filter that does nothing but mark
>> >> traffic as cs2. Router A has an egress firewall filter toward Device
>> >> A, but it specifically allows the source IP address of Device B as
>> >> well as any traffic marked as cs2.
>> >>
>> >> Here is where it really gets weird. If we remove the filter on Router
>> >> C that marks the traffic, everything starts working. Put the filter
>> >> back in place and the traffic stops. We've been looking at this for a
>> >> couple of days and JTAC has spent a few hours looking at it and we're
>> >> still no closer to figuring out why cs2 traffic is being dropped. With
>> >> the filter in place, traceroutes from Device B to A stop at Router A.
>> >> Remove the marking filter and traceroutes complete and pings start
>> >> succeeding.
>> >>
>> >> Can any of you think of a potential culprit that we're not seeing? I
>> >> would hope that if this were something obvious, JTAC would have caught
>> >> it by now. We're all stumped.
>> >>
>> >> Thanks!
>> >> John
>> >> _______________________________________________
>> >> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> >
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>