Showing results for 
Search instead for 
Did you mean: 


We are observing an oddity that was wondering if anyone can figure out.

We have a point-to-point DS3 between 2 locations.

We usually test these things by sending large 1500byte pings sourced off of the HSSI on one side to the destination IP of the HSSI of the other. Everytime we ever did this test we got the expected bunch of "!"s and response times pretty uniform.

(Such as 7/8/8 ms)

Okay, so we now have a new circuit---tested clean from end to end with BERT testing and from the LECs.

We do our test and SPORATICALLY and without any rhyme or reason, the pings will sometimes seem to "stop" and pick up sometimes a very high MAX round trip reading (like 7/20/1750 ms)

Sometimes when we apply a simple QOS service-policy on either end, we will get some timeouts in the ping. Sometimes we don't---sometimes it just runs clean and sometimes the ping will stop and we will get some "."'s

There seems to be no rhyme or reason to when this problem occurs or doesnt occur but the CBWFQ policy seems to trigger it more than not. The Qos policies on each end have been modified and it doesnt seem to make a difference.

For what its worth, this simple policy is applied on both ends:

policy-map VoipT3

class Routing

bandwidth percent 5

class Voice

priority percent 17

class GOLD

priority percent 30

class class-default

bandwidth percent 25


The pings would fall into class class-default and would get 25% of the bandwidth..even went so far as putting an ACL on both sides putting ICMP in a LLQ with differing results (timeouts/no time-outs)

Buffers are clean memory is clean--no other traffic on this circuit (its a backup)

One Router is running 12.3(10c) on a 3745 router

One Router is running 12.2(3d) on a 3662 router

On either side there are no drops but the pings are no drops reported but this doesnt seem right at all--and doesnt happen with comparable policies with similar setups we have elsewhere

(class default)

Class-map: class-default (match-any)

345509 packets, 435912570 bytes

5 minute offered rate 3933000 bps, drop rate 0 bps

Match: any

Weighted Fair Queueing

Output Queue: Conversation 267

Bandwidth 25 (%)

(pkts matched/bytes matched) 345308/435855882

(depth/total drops/no-buffer drops) 0/0/0

exponential weight: 9

mean queue depth: 0

Any ideas?

Thanks very much



QOS policy is in effect only when there is congestion in the link. Since you dont have any traffic on that link, (backup), the policy should not affect normal ping traffic.

Is it just two p-p links between these two routers ? Have you tested your hardware with loopback tests?



Yup the CSUs were looped back with no errors.

Show buffer errors

and memory errors yields no problems.

We took the policy-map off again and the problem re-appeared as well...

Maybe some weird hardware problem with one of the routers or could be still a carrier/lec issue.

One other thing, is one of the HSSIs got its addressing via "SLARP" as opposed to NVRAM...Im assuming this is because it wasnt reloaded and a new card was added?? I never have seen that before though...could that have anything to do with it?

Thanks again for the reply.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards