How to implement this QoS policy...?

[alec.waters]

Hi all,

I have a 2821. Let's say it has four interfaces:

- Net 1, a point-to-point link to an ISP

- Net 2, owned by customer One

- Net 3, owned by customer Two

- Net 4, also owned by customer Two

The bandwidth provided by the ISP over Net 1 is a symmetric 4Mb/s over a fastethernet interface - the ISP uses a traffic shaping policy of their own to give us the 4Mb/s.

Here's what I want to achieve:

- Net 2 is guaranteed a minimum rate of 1Mb/s to and from the Internet. The maximum rate is also 1Mb/s.

- Net 3 and Net 4 have all the remaining bandwidth between them, including any of Net 2's 1Mb/s that they're not using.

I could implement this as a heirarchical policy-map, with the top-level policy shaping to 4Mb/s, and a "child" policy to split the bandwidth between the two customers:

policy-map sharebandwidth

class custOne

bandwidth 1024 ! to set a minimum

shape average 1024000 ! to set a maximum

class custTwo

shape average 4096000 ! to set a maximum - note sure if this is strictly necessary!

policy-map toplevel

class class-default

shape average 4096000 ! need to do this so that the bandwidth command in the sharebandwidth policy will actually do something

service-policy sharebandwidth

policy-map toplevel could be applied to the router's interface on Net1, and will work fine (I think!) for Internet-bound traffic (i.e. outbound traffic from the point of view of Net1).

However, it won't work for "downloads" because I can't apply this policy inbound on Net1.

Is there anything I can do to fix this?

many thanks,

alec

[thomas.chen]

set the traffic level on various things such as an subnet (matched by an access-list)..

configure the bandwidth command on the inerfaces .

[robert.hyde]

Alec,

Interesting scenario, and you're on the right track. Your "toplevel" policy will shape the outbound traffic down to 4 megs, forcing traffic into your queuing scheme. Then you can guarantee and shape custOne traffic to 1024, and simply leave the rest alone, no need to shape the remaining traffic since the parent policy will not allow the total to exceed 4 megs.

Now for the traffic coming back from the internet... Since your guaranteed rate from the ISP is less than your Net 1 link speed, you will never experience congestion inbound on the Net1 interface, so you don't really NEED to apply anything there. But if you want to make sure that custOne is not getting a better download speed than they are paying for...

You can not directly control the mix of traffic coming back from the ISP, in such a way as to guarantee that custOne only gets 1 meg of return traffic from the upstream ISP box. But if you apply policing or shaping to return custOne traffic on your router, you can control the amount of custOne return traffic that actually makes it back to custOne, and custOne TCP traffic will respond by throttling back/windowing, so that ultimately custOne traffic returning from the ISP box should max out at around 1 meg. That's the best you can do to try and control the mix of traffic coming from an upstream box.

This could be done in one of two ways:

1) Apply a "net1_downloads_lan" policy outbound on the Net2 interface, shaping traffic outbound to custOne down to 1 meg. This would be pretty easy since you can apply the policy to the entire default class on that interface. Or police instead of shape - easier on router resources, more intrusive on the traffic.

OR...

2) Apply a "net1_downloads_wan" policy inbound on the Net1 interface, to police traffic destined for custOne to 1 meg. But for that you would need to sort custOne traffic from the rest of the inbound traffic by access-list, which can consume router resources. So I would recommend option 1).

Either way, by default, custTwo will automatically receive (4 megs minus custOne bandwidth) back from the internet, so no need to apply anything explicitly for traffic from the internet back to custTwo.

I would also recommend adding RED (random-detect) as it really helps IP traffic during congestion. So here is what you are left with...

policy-map sharebandwidth

class custOne

bandwidth 1024 ! to set a minimum

shape average 1024000 ! to set a maximum

random-detect

class class-default

fair-queue 1024

random-detect

policy-map toplevel ! apply outbound to Net 1 interface

class class-default

shape average 4096000 ! need to do this so that the bandwidth command in the sharebandwidth policy will actually do something

service-policy sharebandwidth

!----

policy-map net1_downloads_lan ! apply outbound to Net 2 interface

class class-default

shape average 1024000 ! to set a maximum

random-detect

!-- OR --

policy-map net1_downloads_wan ! apply inbound to Net 1 interface

class custOne_return

police 1024000 ! to set a maximum

random-detect

!----

Let me know if you have any questions. Good luck!

[alec.waters]

Hi Robert,

Many thanks for your reply!

Robert wrote:

"Either way, by default, custTwo will automatically receive (4 megs minus custOne bandwidth) back from the internet, so no need to apply anything explicitly for traffic from the internet back to custTwo."

In the "from-the-Internet" direction, I was hoping to be able to _guarantee_ custOne 1Mb (with the "bandwidth" command or similar") as well as limit them to 1Mb. I want to be able to provide custOne with "uncontended bandwidth", to borrow a phrase from the DSL industry.

I could apply a slightly modified "policy-map toplevel" (matching on an ACL) outbound on the net2, net3 and net4 interfaces, but is that going to work when the policy is spread out over more than one interface?

Might be time to try some of this out for real!

many thanks,

alec

[robert.hyde]

Alec,

Mali is right - the only way to truly guarantee custOne that uncontended 1 meg back from the ISP would be for the ISP to configure their router as such. When you are trying to control the mix of return traffic from an upstream point of congestion that is out of your administrative reach, the best you can do is to control the mix of return traffic once it hits your box, and rely on stateful protocols and stateful-ish applications to respond appropriately by throttling/windowing down when necessary. So keep in mind that there won't be any perfect combination here, simply combinations of different QoS mechanisms to try and get close to your goal.

I see what you mean by the modified "toplevel" policy, that would be cool, but you are right, it won't work because you can't spread it out among multiple interfaces. If you want to both limit and guarantee return custOne traffic, you will have to limit return custTwo traffic. And since custOne seems to be the preferred traffic, you should be okay policing custTwo, and that would have to be done inbound on the Net 1 interface. But as mentioned before, you will have to use per-destination-subnet access-lists to separate inbound traffic. Access-lists consume additional router resources, but applied on a 100-meg interface only receiving 4 megs of traffic should be okay.

And one more thing... on the platforms that I tested (though we don't have a 2800), shaping can only be applied to level 1 of a hierarchical policy-map. So I could not shape to 4096 with the parent policy and shape to 1024 with the child, the child had to use policing instead. And since we want to both police and guarantee that class to 1024, that's exactly what priority bandwidth does, so you will see the new version of policy-map "sharebandwidth" below.

So now we have...

policy-map toplevel ! apply outbound to Net 1 interface, parent to "sharebandwidth"

class class-default

shape average 4096000 ! forcing traffic into the child policy "sharebandwidth" when 4 megs or more is present

service-policy sharebandwidth

policy-map sharebandwidth ! child to "toplevel"

class custOneIn ! match on input-interface Net 2

priority 1024 ! to set a minimum and maximum

random-detect

class class-default

fair-queue 1024

random-detect

policy-map net1_downloads_lan ! apply outbound to Net 2 interface

class class-default

shape average 1024000 ! to set a maximum

random-detect

!-- AND --

policy-map net1_downloads_wan ! apply inbound to Net 1 interface

class custTwo_return ! based on an access-list for custTwo subnets

police 3072000 ! to set a maximum

random-detect

!----

Why shape custOne outbound on Net 2 but police custTwo inbound on Net 1, instead of just policing both inbound on Net 2? Well, shaping is much nicer to traffic, especially non-stateful or realtime traffic that does not respond well to drops. The momentary peaks above 1 meg are buffered instead of dropped. But really you could just police custOne to 1024000 and custTwo to 3072000 inbound on Net 1 and leave Net 2 alone, it is up to you. ISP's generally police instead of shape.

That probably covers about as much as possible for this scenario. Let me know if you have any questions. Enjoy!

[mbasalp]

hi alex;

the configuration you have done would be valid only for the upstream traffic from your side to the isp.

to control downstream traffic your, ISP should configure their router according to the different nets on your side.

This is the only solution.

hope helps

mali