QoS on Ethernet interface with a bandwidth mismatch

[c2jkeegan]

We recently moved our WAN interface from a serial interface to a Fast Ethernet interface. The Fast Ethernet interface is connected to a satellite modem that bridges the connection to the satellite at 2Mbps.

We had a QoS policy on the serial interface with I transferred to the Fast Ethernet interface, but I was worried that the interface would never see congestion since it's at 100Mbps and the modem is 2Mbps. I worry that the modem will drop packets (voice and data alike) when it becomes congested and QoS goes out the window.

To ensure we don't go over the modem's bandwidth I implemented a shaper and used LLQ in the shaper to ensure that the modem never became congested and voice packets were not delayed, or so that was the thought. Now users are experiencing delays in their voice calls.

Here is the current config with the shape average command configured for real-time networks as per "End-to-End QoS Network Design" book:

policy-map ISP

class Priority

priority 256

class Voice

priority 576

policy-map SatTrafficShape

class class-default

shape average 2048000 20480 0

service-policy ISP

I'm thinking about going about it another way by using the interface bandwidth command set to 2048 Kbps, ditching the shaper and using just the ISP policy map, but I'm not certain this will work as intended since the bandwidth command is used mainly to tell routing protocols the amount of bandwidth on an interface and I am not sure it will be used by QoS.

Does anyone have any suggestions to implement QoS in this scenario?

[simontibbitts]

Hello.

I think your QoS config looks good. I would be interested to see what counters are incrementing under the 'show policy-map interface fx/x output' command.

My only other thought (and I just want to check you have checked it) is whether the satellite link is good enough for voice traffic? If you are talking about the satellite connection I am thinking of (the things that float in space!), I have used one of these before and it was great high bandwidth but with a massive delay, perfect for data but no good for voice?

One option could be to setup an ip sla on your router to check your new link for delay/jitter, it has lots of good tools for voice

R0(config-sla-monitor)#type ?

dhcp DHCP Operation

dns DNS Query Operation

echo Echo Operation

frame-relay Perform frame relay operation

ftp FTP Operation

http HTTP Operation

jitter Jitter Operation

pathEcho Path Discovered Echo Operation

pathJitter Path Discovered Jitter Operation

tcpConnect TCP Connect Operation

udpEcho UDP Echo Operation

voip Voice Over IP measurement

Simon

[c2jkeegan]

Thanks for replying and I'll look in to the SLA monitor.

Our old LAN link was also a satellite that was connected to the router via a V.35 connection and we had the ISP service policy installed on that interface. But since that interface already was running at the actual modem speed, we didn't need to worry about a shaper. Things were acceptable in the configuration.

Also if we remote the shaper QoS policy then voice traffic goes back to normal, although presumably with the risk of other call quality issues.

Don't get me wrong, our normal call quality is not great call quality and still has a delay, but it's dramatically worse with the shaper policy applied.

I'll post the show policy-maps in a second reply due to the 4000 char limit.

Thanks again for all your thoughts.

[c2jkeegan]

router#show policy-map int fa0/1

FastEthernet0/1

Service-policy output: SatTrafficShape

Class-map: class-default (match-any)

1371356 packets, 440552169 bytes

30 second offered rate 426000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

2048000/2048000 2560 20480 0 10 2560

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 1369404 440279872 271483 160790722 no

Service-policy : ISP

Class-map: Priority (match-any)

175835 packets, 99420090 bytes

30 second offered rate 92000 bps, drop rate 0 bps

Match: precedence 1

175835 packets, 99420090 bytes

30 second rate 92000 bps

Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 256 (kbps) Burst 6400 (Bytes)

(pkts matched/bytes matched) 17159/9570558

(total drops/bytes drops) 0/0

Class-map: Voice (match-any)

413322 packets, 56680572 bytes

30 second offered rate 50000 bps, drop rate 0 bps

Match: precedence 5

413322 packets, 56680572 bytes

30 second rate 50000 bps

Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 576 (kbps) Burst 14400 (Bytes)

(pkts matched/bytes matched) 37271/5113594

--More-- (total drops/bytes drops) 0/0

Class-map: class-default (match-any)

782199 packets, 284451507 bytes

30 second offered rate 282000 bps, drop rate 0 bps

Match: any

router#show policy-map int fa0/1

FastEthernet0/1

Service-policy output: SatTrafficShape

Class-map: class-default (match-any)

1373740 packets, 441410813 bytes

30 second offered rate 436000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

2048000/2048000 2560 20480 0 10 2560

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 1371785 441138081 271975 161109746 no

Service-policy : ISP

Class-map: Priority (match-any)

176165 packets, 99604102 bytes

30 second offered rate 91000 bps, drop rate 0 bps

Match: precedence 1

176165 packets, 99604102 bytes

30 second rate 91000 bps

Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 256 (kbps) Burst 6400 (Bytes)

(pkts matched/bytes matched) 17186/9585880

(total drops/bytes drops) 0/0

Class-map: Voice (match-any)

413852 packets, 56751592 bytes

30 second offered rate 41000 bps, drop rate 0 bps

Match: precedence 5

413852 packets, 56751592 bytes

30 second rate 41000 bps

Queueing

Strict Priority

Output Queue: Conversation 136

Bandwidth 576 (kbps) Burst 14400 (Bytes)

(pkts matched/bytes matched) 37318/5119892

--More-- (total drops/bytes drops) 0/0

Class-map: class-default (match-any)

783723 packets, 285055119 bytes

30 second offered rate 301000 bps, drop rate 0 bps

Match: any

[Joseph W. Doherty]

Two things you might try (and/or). First, tune down the burst size for the shaper. Shapers will allow the defined burst through before holding back where your child policy will prioritize LLQ. (It's somewhat similar to the issue of an interface's TX ring providing FIFO before the software queues kick in.)

Second, decrease your shaper's top rate to be somewhere between about 5 to 15% less then nomimal rate. This serves two purposes. First, we want to assure we manage transient congestion, i.e. it doesn't form later along the path when the ISP actually hits the 2 Mbps bottleneck. Second, since you're now running out an Ethernet interface, we might need to allow for extra Ethernet overhead vs. typical WAN link overhead.

With regard to using an ISP policy map, if your ISP can actually correctly manage LLQ traffic, based on perhaps a packet marking, then you shouldn't need to do anything beyond marking your LLQ traffic and allow the ISP to process it.

[simontibbitts]

Hi Joseph.

The Bc is already at its minimum, 2560bytes every 10ms

Simon

[Joseph W. Doherty]

"The Bc is already at its minimum, 2560bytes every 10ms "

Are you sure? I was just able to activate a 2 Mbps shaper, which only reject less than 4 ms.

e.g.

policy-map x

class class-default

shape average 2048000 9000

Router#sh policy-map i o

FastEthernet0/0

Service-policy output: x

Class-map: class-default (match-any)

198 packets, 16323 bytes

5 minute offered rate 1000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

2048000/2048000 2250 9000 9000 4 1125

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 198 16323 0 0 no

Whether you need an interval that small, is a different issue. But as shown above, 10 ms might not be the minimum possible.

[c2jkeegan]

Thank you for replying. I'll look into reducing the shaper to less than the nominal rate, accounting for Ethernet overhead may be something to consider.

Our ISP can handle and prioritize marked packets and is doing so. We need to make sure we are using QoS on this hop since in addition to our ISPs QOS since it's particularly prone to congestion.