QoS / 3745

[djmlmco]

OK... I have not run across any good examples of completing this so far.

My topology is pretty simple. 3745 at the core and 1721's out at remote sites.

The sites are connected via either 256k modems or low speed 28.8 modems. The 256k modems have an Ethernet interface to the routers while the low speed modems are serial.

My first issue is the speed mismatch between the router and the 256k modem. At that point I need to prioritize 3 TCP ports and 1 UDP ports worth of traffic over everything else... This is seemingly impossible because if I implement CBWFQ it takes the interface speed of the Ethernet port (100Mb) and then throws off bandwidth percentages.

How can I get around this?!?!? The Ethernet NM in the 3745 is the 16ESW and the 4ESW in the 1721s.

Regards...

GTS has been working the best, I've tried CQ and CBWFQ but maybe my configs were not correct. I need to apply these policies to the Ethernet interfaces that are being dumped out to the modems. The traffic back does not need to be prioritized.

[robert.hyde · Accepted solution]

Hello,

In order to convert from GTS to QoS shaping in this scenario, the key would be to implement a parent policy-map that applies the shaping, and then a child policy map that prioritizes the traffic once it has been shaped. It would look something like this if you were using access-list PRIORITY_PORTS to identify the ports:

class-map match-all PRIORITY_CLASS

match access-group name PRIORITY_PORTS

policy-map PRIORITY_POLICY

class PRIORITY_CLASS

bandwidth percent 80

policy-map SHAPE_TO_28

class class-default

shape average 28800

service-policy PRIORITY_POLICY

policy-map SHAPE_TO_256

class class-default

shape average 256000

service-policy PRIORITY_POLICY

interface FastE x

service-policy SHAPE_TO_256

interface Serial y

service-policy SHAPE_TO_28

When traffic reaches interface FastE x, all traffic is shaped down to an average rate of 256k, since the class-default matches everything. Then that traffic is mapped into the child policy PRIORITY_POLICY, which guarantees PRIORITY_PORTS 80% of the bandwidth. And since the parent policy has already shaped the traffic to 256k, that 80% is not 80% of the interface speed, but rather 80% of 256k. The same goes for interface Serial y, when the traffic maps into PRIORITY_POLICY, it will be 80% of 28.8k.

If that doesn't quite answer the question let me know. Good luck!

[djmlmco]

This sounds exactly like what I want to do... I will give it a shot and let you know as well as rate for your help!

Many thanks!!!

[djmlmco]

Robert,

This works well, with one exception. The traffic shaping is working as predicted, however my ACL's don't seem to catch the traffic. It almost appears that the ACL's grab the incoming traffic to that interface, and I need it to catch them on the outgoing traffic.

When applied to the interface the command I'm using is:

service-policy output SHAPE_TO_X

Any suggestions?

[robert.hyde]

That's a good one. Perhaps if you could paste in a "show policy-map interface", as well as the access-list(s). You will want to verify that if the class-map has more than one line, that you use "class-map match-any" instead of "class-map match-all"; the former will match any packet that meets any criteria listed, while the latter is default and will require a packet to match all criteria listed. I look forward to your reply.

[djmlmco]

Robert,

Not in front of the router, but this should suffice:

class-map match-any Class2

match access-group 102

class-map match-any Class3

match access-group 103

class-map match-any Class1

match access-group 101

class-map match-any Class4

match access-group 104

policy-map RAP_Policy

class Class1

bandwidth percent 35

class Class2

bandwidth percent 20

class Class3

bandwidth percent 15

class Class4

bandwidth percent 10

policy-map Shape_64

class class-default

shape average 64000

service-policy Policy

policy-map Shape_256

class class-default

shape average 256000

service-policy Policy

policy-map Shape_336

class class-default

shape average 33600

service-policy Policy

policy-map Shape_9

class class-default

shape average 9600

service-policy Policy

policy-map Shape_128

class class-default

shape average 128000

service-policy Policy

access-list 101 permit tcp any any range 1 5

access-list 101 permit tcp any range 1 5any

access-list 102 permit tcp any any eq 6

access-list 102 permit tcp any eq 6 any

access-list 103 permit tcp any any eq 7

access-list 103 permit tcp any eq 7 any

access-list 104 permit udp any any eq 8

access-list 104 permit udp any eq 8 any

The policy line being applied to an interface looks like:

service-policy output Shape_256

This is being applied to an FA port of a 16ESW NM in a 3745.

It seems as if the access lists are getting hit, but they are not getting thrown into the bandwidth percentages. In other words, the ACL has more packets that matched than the "packets matched" line in the queue - hopefully that makes sense.

[djmlmco]

The line:

policy-map RAP_Policy

...should read:

policy-map Policy

So that is correct.

[robert.hyde]

That does look right, can you paste in a "show policy-map interface" for one of those FastE's?

[djmlmco]

Robert,

As follows:

FastEthernet2/0

Service-policy output: Shape_256

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

215306 packets, 70922027 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

256000/256000 1984 7936 7936 31 992

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 215107 70802731 27737 26592145 no

Service-policy : Policy

Class-map: Class1 (match-any)

130281 packets, 7841014 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 101

130281 packets, 7841014 bytes

5 minute rate 0 bps

Queueing

Output Queue: Conversation 41

Bandwidth 35 (%)

Bandwidth 89 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 3145/189171

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

Class-map: Class2 (match-any)

40541 packets, 40526332 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 102

40541 packets, 40526332 bytes

5 minute rate 0 bps

Queueing

Output Queue: Conversation 42

Bandwidth 20 (%)

Bandwidth 51 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 20652/22031751

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

Class-map: Class3 (match-any)

495 packets, 49120 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 103

495 packets, 49120 bytes

5 minute rate 0 bps

Queueing

Output Queue: Conversation 43

Bandwidth 15 (%)

Bandwidth 38 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 7/420

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

Class-map: Class4 (match-any)

34821 packets, 18260569 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 104

34204 packets, 17942284 bytes

5 minute rate 0 bps

Queueing

Output Queue: Conversation 44

Bandwidth 10 (%)

Bandwidth 25 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 1140/598055

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

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

9168 packets, 4244992 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

It just seems like the packets matched by the ACL don't match up with the "Queueing" pkts matched. Maybe this is how it is supposed to work... Would having CEF enabled or disabled affect the ACLs?

Regards.

[robert.hyde]

That output looks pretty good too. But when looking to see how many packets a class-map matched, look at the number of packets just under the class-map name, not further down where it lists "(pkts matched/bytes matched)". While the former is a true count of how many packets matched that class-map, the latter is just a count of how many matched during periods of congestion. In this case, you are artificially creating congestion by shaping the output to 256k, so "congestion" ocurrs anytime the output of the interface tries to exceed 256k and thus is shaped down.

From this output, I see that Class1 matched 130281 packets total, and 3145 of those ocurred during periods of time when the total output of the interface was trying to exceed 256k. So the other (130281 - 3145) packets were sent out of the interface when the total output was already below 256k, without having to be shaped.

This link will explain it better, I just found it myself:

http://www.cisco.com/en/US/partner/tech/tk543/tk760/technologies_tech_note09186a0080108e2d.shtml

Though you may be ahead of me and the packets still don't match up, in which case let me know and we will dig deeper. Thanks!

[djmlmco]

Your explanation of the packets in the queueing section make sense. I do think everything is working as it should be - I was more concerned that, statistically, I wasn't getting what I should. Performance to those ports is more stable so I feel the solution you proposed was the right way to go. Thank you for all of your help and I will rate the original post up accordingly! Thanks again for all of your help Robert. Take care...