QoS Voice Priority over Data on PtoP Routed WAN Link

[I Philip]

From the attached diagram, I have 2 sites connected via a 1Mbps bridged Ethernet service. This service is terminated at each location by a 2626. At each site there is an exisintg data network, each on its own IP subnet.

I need to introduce 2 IP enabled PBX's. The handsets are analog, the only IP portion is the trunk that connects the 2 PBX's together.

Each switch comprises of 3 VLAN's.
1 for the WAN link
1 for the Data Network
1 for the Voice trunk

I require some guidance as to the best way to prioritise the Voice traffic going across the WAN link.

What method of QoS should I use ?
Where on the switch do I place the QoS commands ?
I.e If I have voice packets entering the s/w on VLAN3 and data on VLAN1 how do I ensure that the voice packets exiting the switch on VLAN2 are prioritised over the data ?

Your help is greatly appreciated.

[Matt Hobbs]

When going across slower WAN connections like you've described, usually you would use a more traditional router for advanced QoS requirements.

The 2600 has limited packet buffering capabilities - If asked to, it's going to send as much data as it can across that 1Mbit link and traffic is going to get dropped fairly indiscriminately.

With the 7000dl WAN routers you can set traffic-shape rate limits on your ethernet interfaces for exactly this type of scenario. From there you can divide up the actual bandwidth by setting policies to match your QoS requirements.

Since you're routing this traffic, you will want to use 802.1p and DiffServ.

The 2600 also is best for routing under ~128 or so hosts on each switch. If you have more hosts than this you may see the CPU utilisation start to rise and performance suffer.

See how you go with the 2600's first, if you find they're not quite cutting it I'd look at adding a 7102dl at each site.

[I Philip]

Matt,

Thank you for your response.

With regard to the QoS settings, as it is in a layer 3 environment and the QoS is purely between 2 devices (1 PBX in each IP network) would it be appropriate to prioritise based on IP address ?

Eg, For the 2626 in Site A could we use the following to prioritise voice taffic to the PBX in site B -

QoS Device-Priority 172.16.0.2 Priority 7

What do you think ?

[Matt Hobbs]

Come to think of it, that's probably the only command you need (you could also prioritise it based on the source-port or VLAN). When the switch receives a packet from that IP address, it will give it higher precedence in the outgoing queue. Since you're really only going across one hop, then setting the DSCP code really isn't that important as the interface on the other side is never going to be oversubscribed.

Just for completeness though, I'd set DSCP:
qos type-of-service diff-services
qos dscp-map < codepoint > priority < 0 - 7 >
qos device-priority < ip-address > dscp < codepoint >

[I Philip]

Matt,

Once again, thank you for your full and detailed response.

Moving back slighty to the issue you mentioned regarding the 2626's capability to cope with being connected to such a low speed WAN link.

Firstly Site B is a branch office with 17 users running terminal services to Site A. In addition (based on previous stats from the old TDM voice link between the 2 sites) it is envisaged that no more than 8 simultaneous voice calls will occur across the 1Mbps WAN link. It is calculated that these voice calls are 25Kbps each.

Based on the information above, does this increase your confidence regarding the suitability of the 2626 for this purpose ?

Thank you for you help

[Matt Hobbs]

QoS works by giving outbound precedence based on the incoming priority of the traffic.

For example, if you have 3x 100Mbit ports each in different VLANs - and all traffic is destined to go out a single 100Mbit uplink.

If all 4 ports are receiving a full 100Mbit of traffic, then generally 25% of packets from each will actually get through. By setting different QoS priorities you can change this ratio. For example, if you set priority 6 or 7 on one port it will ensure that 75% of it's packets will make it through the uplink. The other 3 will share the remaining 25%.

In your setup you can be fairly confident that all prioritised traffic is going to be forwarded out the 2600's WAN link port - this must be connected to an intermediate device. This is the bottleneck and I'm guessing that this device most likely will just treat packets as first come first served. Anything over that 1Mbit will be dropped. I'd look into if this device can do any form of QoS, if not I'd look at the 7000dl series which should be able to give you this level of control.

This is just how I think it's going to work, I'd still test with just the 2600's to start with and see how it performs. The real test is to make some calls while copying a large file across the WAN link.

[I Philip]

Matt,

Thanks again, I have been looking into the specs on the NTU that terminates the 1Mbps service.

Essentially it is a fractional E1 Ethernet bridge. It has no ability to perform QoS but does have a 340 frame buffer.

Furthermore, the manufacturer suggests if you are connecting a Fast Ethernet segment to a slow WAN link, then the unit can be configured to provide a 9 to 1 buffer division between LAN and WAN interfaces.

Perhaps the best thing to implement to try to maximise our chances of the NTU not dropping packets indiscriminately, is to not only divide the buffer in a 9:1 manner but also to ensure that the Ethernet interfaces (on the NTU and the connecting port on the 2626) are hardset to 10Mbps FD. My thinking behind the 10Mbps FD settings are it would be better having the 2626 sending packets to the NTU at 10Mbps rather than 100Mbps, at least if the 2626 has to start dropping packets it would be from a lower priority queue.

What do you reckon ?

[Matt Hobbs · Accepted solution]

Sounds good, I would definitely be experimenting with things like setting the port to 10Mbit only (auto-10 is probably the best, or if you do force it to 10-fdx, make sure it's also forced to 10-fdx on the NTU).

[I Philip]

Matt,

Thanks for your assistance with this matter.

It has been extremely helpful to be able to bounce these ideas of someone who obviously has a tremendous amount of experience in dealing with such issues.

Thanks again.

I think we can call this one closed with a perfect 10 ;)

[I Philip]

Thread Closed.

Now have a viable way forward.

A little further experimentation required, but I've learned something new and that can't be bad ;)

Thanks Matt