Oh, and on the affected router (say the one at the center of this). The standard ping packet loss shows up on non-mpls, non-backbone ports as well as the backbone mpls ports. Routers away from the affected router (even 1 hop) show no packet loss to their connected ports other than towards the central router.
My concern is that if I set CoPP, and it is a CPU spike issue, that will essentially make the problem permanent as the packets will just get dropped earlier -- or am I misunderstanding the order of operations here? thanks! On Fri, Oct 19, 2012 at 2:08 AM, FF <[email protected]> wrote: > I have the defaults set for the mpls except mpls ldp graceful-restart. > > This used to work fine a few months ago, and I'm not sure when the > cosmetic problem showed up. I only noticed it by happening into a ping for > a new link [which has since been shelved while we are examining this]. > > Thanks! > > > > On Fri, Oct 19, 2012 at 1:56 AM, Jim Devane <[email protected]> wrote: > >> Maybe Mpls ip ttl-expiration pop X (likely 1) >> Sounds like the return packet is being pushed with a label instead of an >> IP packet? >> >> Although, copp or mls rate-limiter could very well be as well. >> >> Thanks, >> Jim >> >> >> >> >> -----Original Message----- >> From: [email protected] [mailto: >> [email protected]] On Behalf Of FF >> Sent: Thursday, October 18, 2012 10:50 PM >> To: [email protected] >> Subject: [c-nsp] Standard ping vs MPLS ping >> >> I've been seeing some "cosmetic" ping losses, as high as 4% when traffic >> is >> transit'ing a particular router, or any of the routers directly connected >> to it. [all 6500's running IOS SXH5->8b]. Routers "two hops" away from >> this >> particular router have no cosmetic ping losses. The packet losses are not >> sticky to any particular port, blade or wire. They appear on third party >> circuits, as well as [lit] dark fiber pathways. >> >> When I say they are cosmetic, traffic flows absolutely wonderfully through >> them (at the same levels before this problem showed up). >> >> The equipment is MPLS enabled, and mpls ipv4 pings show absolutely ZERO >> losses. So "normal" ping is lossy and mpls ping isn't. >> >> So the first question is, is "ping mpls ipv4 xx.xx.xx.xx/32 repeat 1000" >> differently handled than "ping xx.xx.xx.xx repeat 1000" is the former run >> in hardware and the latter run on the CPU? >> >> The problem *looks* like a control plane issue, but the CPU isn't spikey >> (the router at the center of this is averaging about 10-15% cpu >> utilization) and the problem doesn't seem to change much based on >> time-of-day. >> >> Was going to open a TAC ticket, but was wondering if there is a sensible >> "oh, look at this, and you'll see you need to see CoPP to xx" direction to >> go in. >> >> If its not a control plane issue, then clearly mpls is hiding/protecting >> the traffic from it, but I'm at a loss for what could be causing it. >> >> thanks in advance! >> >> FF >> >> -- >> FF >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> CONFIDENTIAL INFORMATION >> >> This email message, its chain, and any attachments: (a) may include >> proprietary information, trade secrets, confidential information and/or >> other protected information ("Confidential Information") which are hereby >> labeled as Confidential for protection purposes, (b) is sent to you in >> confidence with a reasonable expectation of privacy, (c) may be protected >> by confidentiality agreements requiring this notice and/or identification, >> and (d) is not intended for transmission to, or receipt by unauthorized >> persons. If you are not the intended recipient, please notify the sender >> immediately by telephone or by replying to this message. Please then delete >> this message, any attachments, chains, copies or portions from your >> system(s). Thank you. >> > > > > -- > FF > -- FF _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
