2

Can anyone doublecheck my basic Cisco QoS configuration. I've got a small remote site connected via AT&T 20Mb line that communicates over an IPSec tunnel.

class-map match-any QoS-Voice
 match ip dscp ef
 match ip dscp cs5
 match ip dscp cs3
 match ip dscp af41

policy-map high-priority
 class Qos-Voice
  priority percent 25 5000
 class class-default
  fair-queue

interface Tunnel1
 description Tunnel 2 IR
 bandwidth 20000
 ip address x.x.x.x x.x.x.x

interface FastEthernet0/0
 description PX Corporate
 bandwidth 100000
 ip address x.x.x.x x.x.x.x
 service-policy output high-priority

interface FastEthernet0/1
 description ATT WAN
 bandwidth 100000
 ip address x.x.x.x x.x.x.x
 service-policy output high-priority

If I do a show policy-map interface f0/0, I can see packets being hit from those classes but I'm still seeing a lot of jitter on my system so I'm thinking I've got something wrong. The other side of this tunnel is an exact duplicate. There is a Cisco router that plugs into a switch and it is configured exactly the same.

The switches operating as the Core layer are layer 3 Enterasys switches that are prioritizing the traffic at layer 2.

  • The jitter is probably being caused by an upstream connection, possibly your tunnel. Does your VPN go over the Internet? – Ron Trunk Oct 11 '16 at 16:44
  • The connection goes over an AT&T MPLS connection. It does not have a connection to the Internet – Joshua Sanders Oct 11 '16 at 18:06
  • Keep in mind that QoS may help some when going through an IPsec tunnel over the internet, but once your traffic hits the INET you're at its mercy. It's a best-effort network and doesn't honor any QoS markings. – John K. Oct 26 '16 at 20:23
3

QoS needs to be comprehensive. You should mark traffic as close to the source as possible, e.g. on the access switches, so that you can treat the traffic for as long as possible on your network.

I don't see where you are shaping traffic on the WAN circuit, nor are you queuing on the tunnel. Since your WAN interface does not have 100 Mb service, you really need to shape the interface to the 20 Mb service that you do have. You are using a percent for the priority queue, but your are using the percent from the 100 Mb starting point, not the 20 Mb reality.

It is unlikely that you need to queue on your inside interface because it is so much faster than the WAN.

You probably want different queues for the traffic which isn't EF (CS5, CS3, AF41) VoIP traffic. If you lump larger packet sizes in the queue for VoIP then you will degrade the VoIP.

You can configure and run IP SLA to get real numbers for thing like jitter.

You probably have a real bottleneck on your distribution switches since they are connecting to the router via a 100 Mb interface. If you don't queue there, you are causing problems. You really need to look at your bandwidth oversubscription ratio on your network, and you need to queue where that happens.

QoS needs to be comprehensive. You should mark traffic as close to the source as possible, e.g. on the access switches, so that you can treat the traffic for as long as possible on your network.

Edit:

One thing to think about is that you need to take into account the packet sizes. With a lot of very small packets for VoIP, you need to adjust the bandwidth to a percentage of the bandwidth. You probably want to start around 85%, but you can adjust it later, after you test it.

What I have below should be for a Fast Ethernet WAN circuit that is really 20 Mb. Taking 85% of that gives you 17 Mb. That gives you 15% for the packet overhead. You can adjust the percentages and queue sizes, but I assume this is an ISR router, so I put realistic queues sizes for that type of router.

!***** QoS - Class Maps for Queuing Policy *****
class-map match-any QoS-Voice
  match ip dscp cs4 cs5 ef
class-map match-any QoS-Video
  match ip dscp af41 af42 af43
class-map match-any QoS-Control
  match ip dscp  cs3 af31 af32 af33 cs6 cs7
class-map match-any QoS-Medium
  match ip dscp cs2 af21 af22 af23
class-map match-any QoS-Low
 match ip dscp cs1 af11 af12 af13
!
!***** QoS - Queuing Policy *****
policy-map QoS-Tunnel-Out
 description 20 Mb Tunnel
  class QoS-Voice
    priority percent 20
    police cir percent 20 conform-action transmit exceed-action drop
  class QoS-Video
    bandwidth remaining percent 15
    police cir percent 15 conform-action transmit exceed-action drop
  class QoS-Control
    bandwidth remaining percent 5
    random-detect dscp-based
    random-detect dscp 24 38 39
    random-detect dscp 26 31 39
    random-detect dscp 28 24 39
    random-detect dscp 30 16 31
    random-detect dscp 48 38 39
    random-detect dscp 56 38 39
  class QoS-Medium
    bandwidth remaining percent 5
    random-detect dscp-based
    random-detect dscp 16 33 34
    random-detect dscp 18 33 34
    random-detect dscp 20 28 34
    random-detect dscp 22 21 28
  class QoS-Low
    bandwidth remaining percent 5
    random-detect dscp-based
    random-detect dscp 8 8 13
    random-detect dscp 10 20 21
    random-detect dscp 12 17 21
    random-detect dscp 14 13 21
  class class-default
    bandwidth remaining percent 50
    random-detect dscp-based
    random-detect dscp default 59 79
!
!***** QoS - Generic Traffic Shaping *****
policy-map QoS-Shaping-Out
 description Shape WAN FE to 20 Mb
  class class-default
    shape average 17000000 68000
    service-policy QoS-Tunnel-Out
!
interface Tunnel1
 description Tunnel 2 IR
 bandwidth 17000
 ip address x.x.x.x x.x.x.x
 service-policy output QoS-Tunnel-Out
!
interface FastEthernet0/0
 description PX Corporate
 ip address x.x.x.x x.x.x.x
!
interface FastEthernet0/1
 description ATT WAN
 bandwidth 100000
 ip address x.x.x.x x.x.x.x
 service-policy output QoS-Shaping-Out
!

You should really set up marking on the access switches. The above configuration assumes that most traffic will be BE. You only want to mark traffic which will be treated differently, either higher or lower priority. It would be good to mark bulk-type traffic, e.g. server backup traffic, to a lower priority.

Cisco switches, by default, remark all incoming traffic to BE (default), unless you specifically configure trust on the interface.

If you have 48 1 Gb ports coming into a switch, and the switch only has a 1 Gb uplink to the distribution, you are oversubscribed by more than twice the recommendation of 20:1. Also, if you have a bunch of access switches coming into the distribution at 1 Gb, but the link to the WAN router is only 100 Mb, you really must queue there, too, otherwise you are just messing up your QoS. You will get a lot of congestion, and that will cause a lot of jitter.

| improve this answer | |
  • The video conference system is marking traffic as ef and af41. The cs5 & 3 I believe are happening from the Cisco phones. – Joshua Sanders Oct 11 '16 at 17:59
  • I can't apply the policy-map to the tunnel interface because I am using the fair-queue statement for class-default – Joshua Sanders Oct 11 '16 at 18:01
  • I kept the config simple and didn't include the different queues for other traffic besides EF so I can troubleshoot the issue. The site isn't that large and traffic shouldn't be affected. – Joshua Sanders Oct 11 '16 at 18:01
  • I wasn't sure about shaping the WAN interface as 100Mb or 20 because it is after all a Fast Ethernet connection. I'll change it to 20 and see if there is any noticeable difference in the jitter numbers my conference system is throwing out. – Joshua Sanders Oct 11 '16 at 18:02
  • The core, distribution & access levels of this network are collapsed to one stackable layer 3 Enterasys switch. As I said, it's a small site. The switch is prioritizing traffic from the conference system over all other traffic. – Joshua Sanders Oct 11 '16 at 18:05
2

Just wanted to circle back and mark the correct answer that fixed my issue. Turns out my system that I was seeing jitter on had a MTU value of 1440 and my Cisco routers were all set to 1400. Once I lowered my value in the 1200 range everything started working as expected.

| improve this answer | |
  • So, it was a configuration problem not related to QoS. – Ron Maupin Jan 6 '17 at 19:55
  • Correct. All that banging around the Qos config and I got showed up with a simple config change by a CCIE we do business with. Live and learn. – Joshua Sanders Jan 6 '17 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.