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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 [email protected] >> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
