qos bandwidth per ip address

Unanswered Question
Feb 2nd, 2007

Hi,

we'd like to configure qos on our router.

Some ip addresses need more bandwidth when connecting to internet.

The config's as follow

class-map match-any a

match access-group 120

class-map match-any b

match access-group 121

policy-map ilimit

class a

bandwidth percent 40

class b

bandwidth percent 20

interface Ethernet0

description to internet

service-policy output ilimit

access-list 120 permit ip host 192.168.0.2 any

access-list 121 permit ip host 192.168.0.3 any

The output of a "sh policy-map interface e0" shows 0 packet for class-map a and b.

class-default has 18347 packets, 2736652 bytes.

the "show access-list 120 | 121" don't show any matches.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.8 (4 ratings)
Loading.
mschooley Fri, 02/02/2007 - 08:31

i'm going to guess that yo are natting on this router, and I'm not 100% sure, but I'm going to say that nat is taking place before the access list is being applied, so perhaps you could apply an inbound policy marking traffic with a dscp value the set the outbound policy to match on that dscp value. Someone smarter than me would have to confirm about the order of nat being applied before outbound policy is matched though.

m-haddad Fri, 02/02/2007 - 09:47

Hello,

The above technique is called congestion management. From the name you can predict that congestion management policies is applied when congestion happens. Currently you have connected your Ethernet to the internet however do you have an E10 to the internet? If not then the policy won't be effective because it has to wait till congestion happens before it starts policing traffic.

Another thing to note, the QOS usually uses 75% percent of the bandwidth inteface. Therefore, when you mentioned 40% for Class a it means 40% out of the 75% and when you mentioned 20 it means 20% out of the 75%.

The solution to the above is:

Set your interface bandwidth to the same speed of your internet pipe. Therefore, if you internet bandwidth is 2Mbps, go to the interface and issue the command "bandwidth 2000".

As for the QoS reserved bandwidth which is by default 75% you can enlarge it to use the 100% by issuing the command "max-reserved-bandwidth 100".

Let me know if the above helps,

Appreciate your rating,

Regards,

harinirina Sun, 02/04/2007 - 22:59

Hi,

yes, we're using nat and the port ethernet0 is connected to the internet.

The main problem is that packets are not classified as intended.They are put in class-default.

We'll try what you've suggered and we'll let you know.

Thank you

harinirina Mon, 02/05/2007 - 06:18

We've tried the following config.

class-map match-any a

match access-group 120

class-map match-any b

match access-group 121

policy-map p_in

class a

set ip dscp ef

class b

set ip dscp af41

int f0

to LAN

service-policy input p_in

class-map match-any c

match ip dscp ef

class-map match-any d

match ip dscp af41

policy-map p_out

class c

bandwidth percent 40

class d

bandwidth percent 20

int e0

to the internet

service-policy input p_out

There's no packet on class a, b, c,d.

what's wrong in the config ?

m-haddad Mon, 02/05/2007 - 08:56

Can you paste your access-lists? Becuase you should match the private IP addresses in your ACLs.

harinirina Mon, 02/05/2007 - 21:50

Hi,

here are the acls

access-list 120 permit ip host 192.168.0.2 any

access-list 121 permit ip host 192.168.0.3 any

m-haddad Tue, 02/06/2007 - 08:41

Hello,

What is the your internet pipe speed? Is it 10 Mbps?

I am asking this question because what you are using is congestion managment. This means the policy won't apply until there is congestion.

Regards,

harinirina Tue, 02/06/2007 - 22:14

Hi,

It's 512KB but it's shared for many clients, we only get about 6KB.

When there's no congestion,what should we get when executing "show policy-map interface e0", traffic should be classified as class a or b or should it classified as class-default?

harinirina Wed, 02/07/2007 - 01:31

hi again,

now,it shows packets on class a and b.

when you say

>> Currently you have connected your Ethernet to the internet however do you have an E10 to the internet? If not then the policy won't be effective because it has to wait till congestion happens before it starts policing traffic. <<

do you mean i need to put bandwidth 512?

I have also problem on dimensionning bandwidth to affect per class.I put 40% and 20% for testing.

Could you give any suggestion , please ?

m-haddad Wed, 02/07/2007 - 08:58

That's correct, I mean to put bandwidth 512000 on the interface. In this way, QoS will know that your CIR or bandwidth is 512Kbps and when congestion happens it will police the traffic according to your policy.

As for setting the bandwidth for each class, usually QoS is allowed to use 75% of the bandwidth of the interface leaving the other 25% for other protocols such as CDP, dynamic routing etc... So when you set 40% it means 40% out of the QoS resrved bandwidth.

To override the above issue you can set the command "max-reserved bandwidth 100" under the interface and in this way the QoS will consider using the 100% interface bandwidth which is 512Kbps in your case.

In order to assist you in setting the percentage I need to understand what are you trying to acheive.

Let me know how it goes,

Regards,

Appreciate your rating,

harinirina Fri, 02/09/2007 - 05:38

Hi,

The need of bandwidth's as follow, the first listed is the most who need bandwidth:

- voice

- some users works on http.they should have all bandwidth they need.

- The manager should always be able to access internet when they need.they use msn, mail, http.

- some users should be able to send file by ftp.

- all other users use bandwidth not used.

harinirina Mon, 02/12/2007 - 22:01

Hi Haddad,

Is there any more information i should give you?

what bandwidth some we attribute per class?

for http, many users use http but only some users should be given priority.

m-haddad Tue, 02/13/2007 - 08:44

Hello,

Sorry for the delayed reply. I have been so busy. Do you want to guarantee these bandwidth all the time or during congestion only?

Let me know your feedback,

Regards,

harinirina Tue, 02/13/2007 - 22:28

Hi,

Could you tell what to do for each case?

For our current configuration, we've tried what happen with qdm.

connexion seems slow but the bit rate graph are the same for pre and post-policy.

Normaly, bandwidth should be guaranted during congestion

m-haddad Wed, 02/14/2007 - 16:09

Hello,

What type of VoIP are using. This is because VoIP protocols differ from one application and vendor to the other. I have done the below bandwidth division while using LLQ for RTP traffic.

ip cef

class-map match-all VoIP

math protocol RTP

class-map Match-all Manager

match access-group 120

policy-map QoS

class voip

priority percent 30

class Manager

bandwidth percent 40

class class-default

bandwidth percent 30

interface Ethernet0

bandwidth 500

max reserved-bandwidth 100

service-policy output QoS

access-list 120 permit ip host 192.168.0.2 any

The above will guarantee

30 for VoIP RTP traffic

40 for your Manager

30 for all other user's internet traffic

The above policy would only start or take effect when the 500Kbps gets congested.

Please let me know if this solves your scenario,

Appreciate your rating,

Regards,

harinirina Sat, 02/17/2007 - 01:18

Hi,

Thanks for the config, do we need to specify bandwidth for http for only few users or is it unecessary ?

we'll try it and i'll let you know.

what do you use to monitor qos?

m-haddad Mon, 02/19/2007 - 10:16

Hello,

Hope this configuration works as per your requirements. To monitor the effieciency of the policy, try to get the link congested and issue the command "show ip policy interface e0/0" then check the counters and matches.

Remark: e0/0 is the interface where you applied the policy.

Let me know how it goes,

Regards,

harinirina Thu, 03/01/2007 - 10:27

Hi,

We used 2 classes for test.

We've tested qos by launching many download in 2 pcs of different class.

here's the output of show policy-map e0

Class-map: a (match-any)

52886 packets, 3437122 bytes

5 minute offered rate 7000 bps, drop rate 0 bps

Match: ip dscp ef (46)

52886 packets, 3437122 bytes

5 minute rate 7000 bps

Queueing

Output Queue: Conversation 265

Bandwidth 40 (%)

Bandwidth 1 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 271/20948

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

Class-map: b (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: ip dscp af41 (34)

0 packets, 0 bytes

5 minute rate 0 bps

Queueing

We've tested different values for bandwidth just for test.

There's no packet drop, no queue depth.

What's the interpretation of the result, how to know if the appropriate bandwidth was affected per class ?

harinirina Thu, 03/01/2007 - 22:54

Hi,

Like your config but we don't have put yet the class voip,we've put another class with acl

class-map match-any a

match access-group 120

class-map match-any b

match access-group 121

policy-map p_in

class a

set ip dscp ef

class b

set ip dscp af41

int f0

to LAN

service-policy input p_in

class-map match-any c

match ip dscp ef

class-map match-any d

match ip dscp af41

policy-map p_out

class c

bandwidth percent 40

class d

bandwidth percent 20

int e0

to the internet

bandwidth 500

service-policy input p_out

Regards

m-haddad Fri, 03/09/2007 - 08:28

Sorry for not getting back to you earlier. In the above configuration you are just guarnteeing bandwidth for the classes. However, for VoIP it is better to use priority because they require to exit the queue before any other traffic.

As for the show output your policy is taking effect but it didn't reach the stage where it starts dropping packets. Therefore, things looks from the perspective of the show output.

Appreciate your rating and let me know if you need anything else,

Regards,

harinirina Fri, 03/09/2007 - 07:33

Hi Haddad,

We will use the protocol RTP for voip.

It's not yet in use.

What can you say about the output above?

Is there any more information you need?

m-haddad Fri, 03/09/2007 - 08:29

If you are going to use RTP then it is better to use the below class.

class VoIP_RTP

match protocol RTP

PLease let me know if you need anything further,

Regards,

harinirina Mon, 03/12/2007 - 00:16

Hi Haddad,

Our problem is that the connection seems so slow for all classes,when we look at the post-policy and pre-policy bit rate, we've got the same graph.it seems as that's there's no congestion.

Is it normal?

m-haddad Tue, 03/13/2007 - 08:45

Hello,

How much is your exact internet pipe?

Let me know,

Regards,

harinirina Tue, 03/13/2007 - 22:49

Hi,

it's 512Kb, shared, it's not a guarented bandwidth.

While doing the test, we've used many different values for bandwidth.

m-haddad Wed, 03/14/2007 - 08:35

Hello,

It is very tough to do QoS on a shared pipe. This is because you are never guaranteed the bandwidth you've got on the interface. THerefore, the QoS should be based on your guaranteed bandwidth.

That is if your guaranteed bandwidth is 256Kbps you have to base your QoS on this band and not on the 512 because sometimes the ISP would be giving you 256Kbps for example and your router won't know that it has to activate the QoS until it reaches the 512Kbps congestion state. Therefore, your QoS would never queue and drop traffic according to matches.

Hope this helps,

Appreciate your rating,

Regards,

harinirina Wed, 03/14/2007 - 23:26

Hi,

We've also tested qos by using "bandwidth 3" for eth0, we didn't see queued / dropped packet.

How to see if it reaches 3Kbps ?

ilya.varlashkin Thu, 03/15/2007 - 14:38

The thing is congestion first occurs not on your 10Mbps interface, but whatever is the next device (a DSL modem/provider managed CPE?). That's why you don't see queued/dropped packets - they're not dropped by your router, but by next device.

Configuring bandwidth on the interface does nothing to restrict speed of the interface, it's only informational parameter which is used to calculate many operational parameters but it doesn't police traffic. In such situation you need to configure two-level hierarchical QoS - in the parent policy you define traffic shaping to whatever actual access link speed is, then you specify child policy to do CBWFQ. For example:

policy-map MyQoS

class A

band perc 40

class B

band perc 20

policy-map QoS-512

class class-default

shape ave 512

servcie-policy MyQoS

!

interface Eth0

service-policy QoS-512

Then you'll see queued/dropped packets.

Hope it helps.

harinirina Thu, 03/22/2007 - 04:34

Hi,

By applying QoS_512, we see now delayed packets.

It seems that prioritized ip also suffer when there's congestion.

However, there's no dropped nor queued packets for their class-map

How can we see if qos per ip address functionning normally, whose / which packets are delayed ?

ilya.varlashkin Thu, 03/29/2007 - 03:37

I was away whole last week. If the issue still open...

The smaller your output rate is, the longer is serialisation delay. Since packets are never removed from TX buffer even if there's "more important" packet coming next, big data packets can significantly delay priority packets on slower links. There are two tools to remedy the problem: 1) split big packets into smaller; and/or 2) reduce size of TX buffer.

In your case only (2) is available. Try applying 'tx-ring-limit 2' on the same interface where you apply service-policy. Limiting TX size can reduce overall throughput for data traffic, so you might need to play with size of the TX buffer to find "sweet spot" that would give satisfactory voice performance and throughput for data traffic.

Hope this helps.

j.schouwenburg Wed, 03/21/2007 - 14:03

I like to add a comment about the 75% rule. If you set 25% of 75% and 40% of 75% the conclusion is not correct that you only get 25% of 75% etc. All not used bandwidth between 75% an 100% will by default be distributed over the classes with respect to the 25% and 40%. There is only one exception, priority class traffic won't get extra bandwidth. So if the 25% class would be priority queued only the 40% class will get available bandwidth above the 40%. There is some tweaking possible but not needed most of the times.

Reading all the posts it seems you still have no traffic matched to the classes so the must be something wrong. It might be NAT. Look in cisco.com for the documents describing order of operation with NAT.

ilya.varlashkin Thu, 03/15/2007 - 14:27

m-haddad, you're right about default 75% of interface bandwidth, but whatever you specify in the class is calculated from full interface bandwidth. Max-reserved-bandwidth specify maximum allowed sum of 'bandwidth' in all classes. E.g. if your intf bw is 1Mbps, then 'bandw perc 40' would mean 400Kbps for that class, but all classed cannot exceed 750Kbps of reserved bandwidth.

I would advise not to change default max-reserved-bandwidth unless traffic profile is well known (service policy on the interface doesn't see ethernet overhead such as IFG, SFD and you may not always get 100% of interface bandwidth if you traffic consists mainly of small packets).

m-haddad Mon, 03/19/2007 - 12:24

Hello ilya,

Thanks for the clarification. Your point about the maximum reserved bandwidth is correct. This means when he say percent 40% it will be 400Kbps out of the 1Mbps. Since the reserved band is 75% this means he is left with 300Kbps for other queues. It is the maximum bandwidth reserved for the total QoS. However, if he wants to use the full interface bandwidth for the QoS then he has to use the maximum-reserved bandwidth.

He tried to set the maximum-reserved bandwidth to 3% which means 300 Kbps of the whole bandwidth on the interface and yet he didn't see any drops. What I suggest is that he set the interface bandwidth to lower speed like to 10kbps and he should see dropped packets in his output queue.

Regards,

harinirina Tue, 03/20/2007 - 01:21

Hi everybody,

Thanks for all your reply.

I haven't explain well, it's not bandwidth for class-map we've changed to 3, it's the bandwith of the ethernet interface.We've changed it to 3 kilobits.

Other information, we've tested it on 2 routeurs to 2 different isp, we use wic adsl for one connection, and ethernet for the other, there's an idu between us and the internet.

So for adsl, we should see packet dropped without applying the new qos ?

Regards

m-haddad Mon, 04/02/2007 - 10:34

Hello harinirina,

Just a buttom line for what you are passing through:

1- You can't guarantee QoS over the internet

2- You router is performing outgoing queueing which means it works only when there is congestion on the outgoing traffic of your link. However, the other side (ISP) is always treating this traffic as normal traffic without any QoS.

In short, you can't guarantee VoIP or QoS for certain traffic when crossing multiple hops out to the internet. You can do some queueing, and shaping mechnisms but this does not mean it will 100% fix the issue.

I just wanted to clarify this for you and usually you should get a good internet pipe with low delay and symetrical solution in order to tranport VoIP and other traffic.

In your case, you have a shared pipe and your QoS is being implemented taking into consideration you always have the full pipe which is not always true.

Hope this helps,

Regards,

harinirina Thu, 03/22/2007 - 04:43

Hi,

By applying QoS_512, we see now delayed packets.

It seems that prioritized ip also suffer when there's congestion.

However, there's no dropped nor queued packets for their class-map

How can we see if qos per ip address functionning normally, whose / which packets are delayed ?

Manjunatha Jayaram Thu, 03/29/2007 - 06:38

I have been watching these conversation since long time, i have got one dought is the same configuration need to be done on the ISP router.

ilya.varlashkin Thu, 03/29/2007 - 07:50

That's true, ISP needs to provide prioritisation for the voice traffic at least. Else affort on CPE alone might not be enough. But even if ISP doesn't provide QoS service, configuring CPE may slightly improve things.

Actions

This Discussion