cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
301
Views
0
Helpful
4
Replies

Cisco 2600 PQ broken?

peter.payne
Level 1
Level 1

I am using a 2600 with priority queuing (LLQ) out a channelised E1 serial interface.

I have a 320Kbps PVC. I'm generating 200 byte packets and measuring jitter. I'm also sending low priority traffic (1500 byte packets) that is being fragmented. The fragmentation size is 206 bytes (which equates to a calculated 5.15ms head-of-line blocking delay).

The jitter I measure on the high-priority streams is 11.6 +/- 1.0ms. Which is approximately DOUBLE the calculated head-of-line blocking delay I should experience.

I have tried PQ and PIPQ with similar results. I have tried bursts of low priority unfragmented packets with similar results.

Is PQ letting through multiple low-priority fragments in front of a high priority fragment?

Has anyone else experienced this? Or can say with certainty (and actually measured) that PQ is strictly prioritising the priority queue?

My version:

IOS (tm) C2600 Software (C2600-IS-M), Version 12.2(24a), RELEASE SOFTWARE (fc3)

cisco 2611XM (MPC860P) processor (revision 0x100) with 90112K/8192K bytes of mem

ory.

Relevant aspects of config:

class-map match-all classmap-hiq

match access-group 161

policy-map policymap-hiq

class classmap-hiq

priority 264

class class-default

fair-queue

interface Serial1/0:1

max-reserved-bandwidth 90

interface Serial1/0:1.701 point-to-point

frame-relay interface-dlci 701

class mapclass-framerelay-hiq

map-class frame-relay mapclass-framerelay-hiq

no frame-relay adaptive-shaping

frame-relay cir 320000

frame-relay be 0

frame-relay mincir 320000

service-policy output policymap-hiq

frame-relay fragment 206

access-list 161 remark match for HIQ packets only

access-list 161 permit udp any any dscp ef

4 Replies 4

jaywydra
Level 1
Level 1

I don't see a "frame-relay bc" setting in your map-class. I believe if you do not have this defined it will defualt to 56000. You really should have it set for 32000 (10% of CIR) so that your time interval is 10ms. Right now your time interval is 17.5ms which could be the reason why the voip packets are experiencing extra jitter.

Jason

Also, I do not see the frame-relay traffic-shaping command under the main serial interface which enables FRTS and class map settings to be used. Maybe it was left out of the posting here ... just checking.

Hi sorry. The FRTS was enabled (I left it out of the original post).

With regard to the Bc problem, firstly if Tc = 17ms I would expect my jitter results to be 17ms, not 11ms as found.

Secondly, if the line rate of the serial controller is 320Kbps, then the Tc value should have no effect as effective no real burst is occuring (MINCIR=line_rate)?

Well, I would do a 'sh policy-map int sxxxxx.x' to see what the router thinks is actually hitting the queues, and a sh frame-relay fragment to make sure you are creating fragments. Also, you do really want to adjust your BC to 1/10th (or 1/100th) of CIR, you want the flow as smooth as possible, and the more intervals across a time period, the better. Also, I remember when the first did some major improvements with QOS, they had us going to the 12.2T train everywhere to get that, it was significantly better behaved. I don't know how much of those improvements ended up in the regular 12.2 train, even up where you are.

Mary Beth