[c-nsp] Standard ping vs MPLS ping

[FF]

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 <fusionfoto at gmail.com> 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 <jdevane at switchlv.com> 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: cisco-nsp-bounces at puck.nether.net [mailto:
>> cisco-nsp-bounces at puck.nether.net] On Behalf Of FF
>> Sent: Thursday, October 18, 2012 10:50 PM
>> To: cisco-nsp at puck.nether.net
>> 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  cisco-nsp at puck.nether.net
>> 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