Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

QOS Configuration Help

I am trying to troubleshoot a QOS problem on a Sprint MPLS connection.  I currently have two 50Mb ethernet circuits from the CE router to Sprint's PE router at two locations.  I get choppy video calls between these locations and the only way I can remedy is to stop replication traffic that is also traversing the same links.  Utilization on both circuits at both locations is less than 50 percent.  I would like to know how to guarantee voice and video traffic priority when there is no congeston on the lines.  Here's my QOS config:

class-map match-any APPS

match access-group name CITRIX

class-map match-any TAG-VOICE

match access-group name CISCO-VOICE

class-map match-all TAG-VIDEO

match access-group name TANDBERG

class-map match-all VIDEO

match access-group name TANDBERG

class-map match-any VOICE

match access-group name CISCO-VOICE

class-map match-any REPLICATION

match access-group name RECOVERPOINT

class-map match-all TAG-APPS

match access-group name CITRIX

!

!

policy-map TAG

class TAG-VOICE

  set dscp ef

class TAG-VIDEO

  set dscp af41

class TAG-APPS

  set dscp af31

class class-default

  set dscp default

policy-map FRIT-QOS

class VOICE

    priority percent 4

class VIDEO

    bandwidth percent 9

class APPS

    bandwidth percent 70

class class-default

     random-detect

interface GigabitEthernet0/1/0

bandwidth 50000

ip address 192.168.0.29 255.255.255.252

ip flow ingress

ip flow egress

no negotiation auto

service-policy output FRIT-QOS

!

interface GigabitEthernet0/2/0

bandwidth 50000

ip address 192.168.0.25 255.255.255.252

ip flow ingress

ip flow egress

no negotiation auto

service-policy output FRIT-QOS

!

ip access-list extended CISCO-VOICE

permit ip 10.1.7.0 0.0.0.255 any

permit ip 10.2.7.0 0.0.0.255 any

ip access-list extended CITRIX

permit tcp any host 192.168.254.34 eq 443

permit ip any host 172.16.3.198

permit ip any host 172.16.3.197

permit ip any host 172.16.3.244

permit ip any host 172.16.3.165

permit ip any host 172.16.2.168

permit ip any host 172.16.2.167

ip access-list extended RECOVERPOINT

permit tcp any host 172.16.0.18

permit tcp any host 172.16.0.19

ip access-list extended TANDBERG

permit ip host 172.16.7.202 any

Thanks

11 REPLIES

QOS Configuration Help

You need to perform shaping on the egress interface:

policy-map Shape50Mb

class class-default

  shape average 50000000

  service-policy FRIT-QOS

!

interface GigabitEthernet0/1/0 (and obviously the same for Gi0/2/0)

bandwidth 50000

service-policy output Shape50Mb

!

Explanation: Without the shaper, the egress port will burst regularly beyond 50Mb.

This causes drops at the provider side.

regards,

Leo

New Member

QOS Configuration Help

Hi Leo,

I tried your suggestion but the issue is still occurring.  I can view real-time COS stats on the Sprint router and I am not seeing any drops on any queues.  I believe the issue is on the CE router.  It seems replication packets are being processed before Voice\Video on the eggress port.  Voice\Video packets are being tagged as EF and AF41 respectively.  How do I makesure that the egress port processes these in sequenece before replication traffic.  I am limiting replication traffic from the replication appliance to 16MB so it should not be consuming more bandwidth.

Remember the issue stops if I pause replication.

QOS Configuration Help

Hi there,

If it is still occurring there may be two other issues. Complex problems tend to have more than one cause.

Still its a pity that some people are reluctant to rate posts before their issue is completely resolved.

The issue I pointed at is clearly a problem which needed fixing before you can discover to the real root-cause.

BTW: did it work? You may be using a switch and switches generally  do not support many egress queueing functions, especially no shaping. This is a typical reason to use a router on the customer edge.

The other two problems could be:

1: Misconfigured qos settings on the provider side. This can only be resolved through tedious consultation with them. If this is the cause (quite likely) they will keep denying it until faced with clear evidence that the problem is NOT on your side.

2: Much easier to resolve: Providers tend to fix speed and duplex settings on their customer edge. Check your side of the link and if it is half-duplex, you have found the next problem. I am mentioning this because of the setting: no neg auto on the egress ports.

regards,

Leo

Super Bronze

QOS Configuration Help

Disclaimer

The     Author of this posting offers the information contained within this     posting without consideration and with the reader's understanding  that    there's no implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not   be construed as rendering professional advice of any kind.   Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In     no event shall Author be liable for any damages whatsoever   (including,   without limitation, damages for loss of use, data or   profit) arising  out  of the use or inability to use the posting's   information even if  Author  has been advised of the possibility of  such  damage.

Posting

There are multiple possible reasons that might cause the performance issue you're seeing.  One might be, MPLS often supports multipoint, and if there are multiple sites sending to another, QoS at MPLS egress is often a critical requirement in addition to individual site to cloud QoS.  (If your two MPLS links are logically p2p, this shouldn't be an issue.)

Another possible issue, when you shape for logical bandwidth, some shapers do not account for L2 overhead but the vendor may.  For these, you often need to shape slower than the nominal bandwidth.  Unfortunately L2 overhead % varies per packet size, so you either need to shape for worst % or expect some lost of performance.

Software queuing only engages when the hardware interface queue overflows, so you sometimes also need to adjust you tx-ring limit down.

You've only set your video class to 9%.  This might well cover average bandwidth utilization, but video often is extremely variable in its short term bandwidth usage and, for live video streams, is delay sensitive.  The solution is to up the dequeuing priority for this traffic, either by moving the class to LLQ or by giving the class a much, much larger percentage of reserved bandwidth.

QOS Configuration Help

I recompiled your classes.

class-map match-any APPS
   match access-group name CITRIX

class-map match-any TAG-VOICE
   match access-group name CISCO-VOICE

class-map match-all TAG-VIDEO
   match access-group name TANDBERG

class-map match-all VIDEO
   match access-group name TANDBERG

class-map match-any VOICE
   match access-group name CISCO-VOICE

class-map match-any REPLICATION
  match access-group name RECOVERPOINT

class-map match-all TAG-APPS
   match access-group name CITRIX

!

!

policy-map TAG
class TAG-VOICE
    set ip precedence 5

class VOICE
    set ip precedence 5

  class TAG-VIDEO
    set ip precedence 4

class VIDEO
    set ip precedence 4

class APPS
   set ip precedence 4 

class TAG-APPS
     set ip precedence 3 
class REPLICATION
    set ip precedence 1

class class-default
  set ip precedence 0
!

!


interface GigabitEthernet0/2/0

Description Assuming this interface facing inside

bandwidth 50000

ip address 192.168.0.25 255.255.255.252

ip flow ingress

ip flow egress

no negotiation auto

service-policy input TAG


------------------------------------------

policy-map FRIT-QOS

class p5
  match ip precedence 5
   bandwidth 16500000

class p4
   match ip precedence 4
     bandwidth 12000000

class p3
  match ip precedence 3
   bandwidth 10000000

class p1
  match ip precedence 1
   bandwidth 8000000

class p0
   match ip precedence 0
    bandwidth 3500000

interface GigabitEthernet0/1/0

Description Assuming this interface facing outside

bandwidth 50000

ip address 192.168.0.29 255.255.255.252

ip flow ingress

ip flow egress

no negotiation auto

service-policy output FRIT-QOS

----------------------------------------------------------

You may change the bandwidth allocation as you wish.

I see you have dictated the bandwidth on both interfaces as "bandwidth 50000" this is equivalent to megabit 0.05

So, my recommendation is to remove the bandwidth statement from both interfaces inside and outside. If you want to manipulate routes use delay instead when you use bandwidth on the interface it is kind of suicidal for QoS not recommended at all.

Let me know the results

Thanks

Rizwan Rafeek

New Member

QOS Configuration Help

Thanks.  I will try the settings and get back to you.

Super Bronze

QOS Configuration Help

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

So, my recommendation is to remove the bandwidth statement from both interfaces inside and outside. If you want to manipulate routes use delay instead when you use bandwidth on the interface it is kind of suicidal for QoS not recommended at all.

Rizwan, this is an interesting recommendation as I don't recall seeing similar before.  Might you provide any additional references that shows why bandwidth statements on interfaces is suicidal for QoS and not recommended at all?

As for using delay to manipulate routes, that makes sense for a routing protocol such as EIGRP, but don't believe it would manipulate routes for a routing protocol like OSPF which, on most Cisco routers, is influenced by the bandwidth setting.  Could you expand upon this recommendation?

I'm also curious why you changed from using DSCP to IP Prec ToS marking, could you explain the advantage of doing so?

I'm also curious why you recommend settings such as:

class p0

   match ip precedence 0

    bandwidth 3500000

since, I believe (see ref., below), policy map bandwidths are in Kbps, 3,500,000 is 3.5 Gbps.

I realize policy-map bandwidth really only sets scheduler weights, and as such is relative to the other classes, but policy maps usually enforce explicit bandwidths against what the policy considers the total bandwidth.  Since you've still configured bandwidth 50,000 for the interface, the policy map should think it only has 50 Mbps to work with.  Would this be an issue?

ref:

http://www.cisco.com/en/US/docs/ios-xml/ios/qos/command/A_through_C.html#GUID-F22E2937-CB0F-4D80-856B-5654A04506BE

bandwidth (policy-map class)

To specify or modify the bandwidth allocated for a class belonging  to a policy map, or to enable ATM overhead accounting, use the              bandwidth  command in policy-map class configuration mode. To remove the bandwidth  specified for a class or disable ATM overhead accounting, use the              no form of this command.

bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}                                             [account {qinq | dot1q} aal5 subscriber-encapsulation]
no bandwidth
.
.

Syntax Description

bandwidth-kbps

Amount of bandwidth, in kilobits per second (kbps), to be  assigned to the class. The amount of bandwidth varies according to the  interface and platform in use. The value must be between 1 and 2,000,000  kbps.

QOS Configuration Help

@JosephDoherty

"but don't believe it would manipulate routes for a routing protocol like OSPF which"

Please check OSPF reference for influencing OSPF route

Interface FastEthernet 0/0

Ip ospf cost 1-65535

@altafmir

Please make sure, bandwidth allocation is in kbps required.

@JosephDoherty

altafmir stated "I currently have two 50Mb ethernet circuits from the CE router to Sprint's PE"

interface GigabitEthernet0/2/0

bandwidth 50000

ip address 192.168.0.25 255.255.255.252

ip flow ingress

ip flow egress

no negotiation auto

service-policy output FRIT-QOS

Assuming this is in bit (50000) is equivalent to megabit 0.05, therefore (bandwidth 3500000) megabit 3.5 and it was an illustration for which I stated "You may change the bandwidth allocation as you wish."

Yes you right it is not in bits but in kbps.

Super Bronze

Re: QOS Configuration Help

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

rizwanr74 wrote:

@JosephDoherty

"but don't believe it would manipulate routes for a routing protocol like OSPF which"

Please check OSPF reference for influencing OSPF route

Interface FastEthernet 0/0

Ip ospf cost 1-65535

Thank you, I'm aware you may use OSPF cost on interfaces, but "it" was referencing delay, which I don't recall influences OSPF route path selection; am I mistaken?

Additionally, regarding bandwidth and OSPF, "OSPF: Frequently Asked Questions" (http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml), we find:

Q. How do I change the reference bandwidth in OSPF?

A. You can change the reference bandwidth in Cisco IOS Software Release 11.2 and later using the ospf auto-cost reference-bandwidth command under router ospf.  By default, reference bandwidth is 100 Mbps. The ospf link-cost is a  16-bit number. There...

Q. How does OSPF calculate its metric or cost?


A. OSPF uses a reference bandwidth of 100 Mbps  for cost calculation. The formula to calculate the cost is reference  bandwidth divided by interface bandwidth. For example, in the case of  Ethernet, it is 100 Mbps / 10 Mbps = 10.

Note: If ip ospf cost cost is used on the interface, it overrides this formulated cost. For more information, refer to OSPF Cost.

So most of the later Cisco platforms OSPF path selection appears to be influenced by bandwidth, unless overridden by the interface OSPF cost statement you've noted.  So are you recommending, for OSPF, bandwidth always be overridden by the interface OSPF cost statement?

Re: QOS Configuration Help

I think, I was not clear with you, that these classes (p0, p1, p3, p4, p5) must exist before you import them into policy FRIT-QOS.

class p5

match ip precedence 5

  

class p4

   match ip precedence 4

  

class p3

match ip precedence 3

class p1

match ip precedence 1

  

class p0

   match ip precedence 0

-----------------------------------

when classes are created import them into policy and set the bandwidth desired.

policy-map FRIT-QOS

class p5

   bandwidth xxxxxxx --> your-bandwidth in kbps

class p4

   bandwidth xxxxxxx --> your-bandwidth in kbps

class p3

   bandwidth xxxxxxx --> your-bandwidth in kbps

class p1

   bandwidth xxxxxxx --> your-bandwidth in kbps

class p0

bandwidth xxxxxxx --> your-bandwidth in kbps

Thanks

Rizwan Rafeek

Super Bronze

Re: QOS Configuration Help

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Thanks for your replies.

1027
Views
0
Helpful
11
Replies
CreatePlease to create content