On Wed, Mar 9, 2011 at 3:20 PM, Tim Durack <[email protected]> wrote: > > On Wed, Jan 26, 2011 at 3:51 PM, Peter Rathlev <[email protected]> wrote: >> >> On Wed, 2011-01-26 at 20:01 +0000, Phil Mayers wrote: >> > There are some funny behaviours w.r.t traceroute under PFC-3B and >> > earlier versions. Do you have a mix of PFC/DFC versions? >> >> Thanks for the tip. I looked more carefully at other devices and found >> out that at least one other device behaves like this. And it's also >> PFC3B with traffic exiting a CFC-equipped 6724-SFP, like this device. >> >> Other devices with PFC3C (i.e. VS-S720-10G) but similar CFC-equipped >> cards haven't got the problem. And PFC3B-equipped cards where the >> traffic arrives on DFC3C-equipped cards (WS-X6708-10GE) also haven't. >> >> > We see oddities routinely with penultimate hop popping and vrf aggregate >> > labels, including the same behaviour you're seeing. I believe it's a >> > hardware limitation. > > I think I'm seeing something similar with a few 6504/SUP720-3BXL/6724-CFC > running 12.2(33)SXI3. > Traceroutes crossing these units in the global table timeout. Works fine in > a VRF. > Can't mpls ping/traceroute from these units in the global table. Works fine > in a VRF. > This makes troubleshooting unnecessarily difficult. Anyone found Cisco > documentation explaining this behavior? > -- > Tim:> >
For the record, my problems were self-inflicted. CoPP configured with a default deny. Had missed an important class: mpls ping/traceroute uses udp 3503, not icmp. Added class, problem solved. -- Tim:> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
