01-03-2005 06:51 PM
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.
Solved! Go to Solution.
01-06-2005 09:30 AM
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!
01-06-2005 09:30 AM
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!
01-06-2005 11:04 AM
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!!!
01-10-2005 09:19 AM
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?
01-11-2005 08:42 AM
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.
01-11-2005 10:24 AM
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.
01-11-2005 10:26 AM
The line:
policy-map RAP_Policy
...should read:
policy-map Policy
So that is correct.
01-11-2005 04:07 PM
That does look right, can you paste in a "show policy-map interface" for one of those FastE's?
01-12-2005 07:18 AM
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.
01-12-2005 09:35 AM
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!
01-12-2005 12:32 PM
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...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: