09-09-2008 03:10 PM - edited 03-03-2019 11:28 PM
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?
09-09-2008 11:46 PM
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
09-10-2008 06:42 AM
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.
09-10-2008 06:43 AM
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
09-10-2008 04:30 AM
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.
09-10-2008 04:56 AM
Hi Joseph.
The Bc is already at its minimum, 2560bytes every 10ms
Simon
09-10-2008 08:56 AM
"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.
09-10-2008 06:47 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: