01-12-2012 02:22 PM - edited 03-04-2019 02:53 PM
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
01-12-2012 02:39 PM
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
01-13-2012 11:07 AM
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.
01-13-2012 11:51 AM
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
01-13-2012 11:53 AM
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.
01-13-2012 06:49 PM
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
01-16-2012 08:44 PM
Thanks. I will try the settings and get back to you.
01-17-2012 03:19 AM
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:
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-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. |
01-17-2012 06:50 AM
@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.
01-17-2012 05:56 PM
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:
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?
01-18-2012 08:27 AM
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
01-18-2012 04:08 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide