887VA Bandwidth per VLAN

[daniel.mckinney]

Hello

I am trying to understand if there are alternatives for QOS on INGRESS on the Dialer1 interface as we cannot queue but we can police.
I have read through Bufferbloat.net and various blogs/documents/articles - everything points towards ingress being an issue.
Would this be an option?

Suppose there is a VDSL connected to Dialer1 on the 887VA and it has speeds of 17 upload and 70 download.
There are 2 SVI's configured on an 887VA.

Int VLAN1 (Staff-PCs)
Int VLAN2 (Phone)

If instead of policing on the Dialer1 ingress - If I police on Int VLAN1 (Staff-PCs) and Int VLAN2 (Phone)
e.g.

policy-map rate_20meg_pmap
class class-default
police cir 20000000
conform-action transmit
exceed-action drop

policy-map rate_5meg_pmap
class class-default
police cir 5000000
conform-action transmit
exceed-action drop

Interface Vlan1
service-policy input rate_5meg_pmap
service-policy output rate_20meg_pmap

Interface Vlan2
service-policy input rate_5meg_pmap
service-policy output rate_20meg_pmap

Will this mean that the Dialer1 interface only gets pushed for 20mb down and 5mb up by Int VLAN1 (Staff-PCs) allowing the available bandwidth to be used for by the other VLAN? essentially guaranteeing an amount of up/down bandwidth to devices in each VLAN.

As Int VLAN1 is only capable of downloading 20mb and uploading 5mb - but the overall Dialer1 connection is capable of 70/17 - does this mean that there is no bottle neck and VLAN2 can also download 20mb and upload 5mb at the same time.

Or is there likely to be an issue as there is no policy on the Dialer1 interface?

Thanks

[Joseph W. Doherty]

You can police on dialer ingress or VLAN egress to accomplish the same.  The only real differences, if you police VLAN egress, you impact any VLAN to VLAN traffic, unless you explicitly exclude such, and when policing on VLAN egress, you don't need to identify the traffic as you would on dialer ingress.

Whichever approach you use, for bandwidth management (of your WAN ingress bandwidth), your "mileage may vary".

I.e. you cannot really set aside/reserve bandwidth (as precisely) as you hope.  There are multiple reasons for this.

BTW, for traffic like TCP, you can also shape egress ACKs to somewhat manage ingress TCP flow rates.

[daniel.mckinney]

Hello Joseph

Thanks for the response.

I configured the policy maps to police against the SVI's and I can see what you mean about the "mileage may vary" point.

I get varied speeds in around the specified 5 upload 20 download e.g. 4.5/19, 4.1/19.2 etc.

This is not ideal but not a show stopper.

Regarding the VLAN egress point, I am not allowing any communication between the VLAN's 1 and 2 at the moment but it is good to know of that limitation for the future and that it can be worked around.

Assuming I allocate bandwidth per VLAN and do not need to be exact, while also leaving space so the amounts specified per VLAN do not equal the line speeds given by the ISP.

Can I have the bandwidth available for each VLAN at all times and not saturate the WAN connection stopping either VLAN1 or VLAN2 from getting upload/download?

This way I can share the circuit for VLAN1 and VLAN2 on a small site?

Each VLAN cannot use more that they are issued which is much smaller that the throughput on the Dialer1/VDSL connection - so in theory there should always be space for either VLAN to use the internet connection?

Kind Regards

[Joseph W. Doherty]

For your up bandwidth, you're normally better off using prioritized queuing.

For your down bandwidth, yea, you can somewhat manage you ingress bandwidth, but the crux of the matter is, your policer is after the bottleneck, so it doesn't really guarantee bandwidth allocations before the traffic gets to the policer.  Traffic that slows when it detects drops (e.g. TCP) will slow their transmission rate but can still burst above the police rate.  Plus, your policer only statically is more likely to drop packets from a bandwidth hog, so that's not guaranteed either.  Then, not all traffic will slow when it detects drops.

Policing ingress often provides some control of ingress bandwidth, but generally to guarantee a set amount of bandwidth for other traffic, you need to police much lower then you really want.

For example, if you have 70 down, and you want to guarantee 20 rather than policing other traffic at 50, you might need to police at 25.

BTW, I believe most Cisco devices policers and shapers don't allow for L2 overhead.

[daniel.mckinney]

Hi Joseph

Yes I sort of thought that might be the case for ingress traffic...

I have LLQ set on the Dialer1 interface:

-EGRESS-

class-map match-all VOICE
match ip dscp ef
class-map match-any SIGNALING
match ip dscp cs3
match ip dscp af31

policy-map CHILD_QOS_VOICE
class VOICE
priority percent 30
class SIGNALING
bandwidth percent 5
class class-default
fair-queue
random-detect dscp-based
policy-map PARENT_QOS_VOICE
class class-default
shape average 15000000
service-policy CHILD_QOS_VOICE

interface Dialer1
service-policy output PARENT_QOS_VOICE

So this should prioritise the traffic types that are sent out from VLAN2 if there is congestion - as it contains IP Phones only, but I can't figure out how to police the CIR or DSCP values that relate to this VLAN2 for ingress on the Dialer1.

e.g important call traffic -> Dialer1 Policed ->VLAN2 -> telephones

Essentially I am trying to ensure that the voice/signal traffic does not suffer ingress/egress due to general user traffic consuming the bandwidth. Separating the devices with VLANs was the first step, then LLQ for traffic type the second, but can't figure how to keep the return path stable.

If you can think of any solutions or example configs please let me know.

Thanks for your help

[Joseph W. Doherty]

Is it possible to manage egress on the far side?  If so, its egress is near side's ingress.

BTW, I highly recommend against using WRED unless you're a QoS expert.  I especially recommend against using it if also using FQ.

As to policing ingress DSCP and/or CIR rates from a LAN, if you have Catalyst switches, you should be able to do that at the physical port and or SVI ingress.

If your doing on a router you can have both ingress and egress policies for the same traffic, and can also rate limit and manage ToS markings.

[daniel.mckinney]

Hi Joseph

Unfortunately it is not possible to manage egress on the far side.

I have noted your point about WRED, thanks

I suspect that the big problem will be that I cannot queue the traffic on the WAN interface so if UDP traffic is compromised by TCP this will have an effect on voice quality. Because the traffic is outside the router and cannot be queued upon arrival (ingress on Dialer1) - I cannot see a way to prioritise the UDP so as to avoid voice quality issues for the phones on the end of the SG300?

Thanks for your help 

[Joseph W. Doherty · Accepted solution]

You're on the right track, however . . .

If you police your non-VoIP ingress traffic enough, it may preserve enough ingress bandwidth that VoIP isn't adversely impacted.  Again, the issue is, this approach doesn't really guarantee ingress bandwidth to VoIP.  It also tends to preclude your non-VoIP traffic taking full advantage of all you non-VoIP bandwidth.

You could also consider using a 3rd party traffic shaping appliance.  It too will still need to deal with some intractable issues when managing ingress bandwidth, but such devices have a few more tricks at their disposal and they can react faster.  For example, two of their techniques is to spoof TCP RWINs, which will rate control TCP senders and/or shape a flow's return ACKs, which can also control a TCP sender's transmission rate.

[daniel.mckinney]

Hi Joseph

Thanks for the suggestions.

I guess at this stage due to the complexities involved with this type of scenario.

I am inclined to go with a dedicated circuit for each.

It seems there are a lot of areas to configure for QOS and without a stable/predictable WAN queueing technology, it will be easier to advise on a separate circuit for voice.

Many thanks for your help