06-15-2012 11:41 AM - edited 03-04-2019 04:41 PM
Hello!
I am wondering what the best way is to implement some sort of traffic shaping for a customer using an MPLS 'cloud' for their WAN connections. They have several remote sites connected with full T1s, one with 2 x T1, and the central site is connected with 4 x T1s.
Obviously, my concern is not to send traffic from the 4 x T1 (or the 2 x T1) site to a T1 site at a higher bandwidth than that site can handle. In the past, I'd have set up FRTS per DLCI to match the bandwidth of the remote side. I'm wondering what the current best practice recommendation is for this situation (i.e., a "full mesh" with BGP routes from each site directly to any other site).
By the way, I have configured CBWFQ/LLQ outbound on all routers, and so the most critical traffic (VoIP) should be OK, but I'm concerned about shaping so that other traffic types don't get sent at higher bandwidths than the remote sides can handle.
Thanks for any suggestions/directions that you may have!
Deb
Solved! Go to Solution.
06-20-2012 12:28 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
For your T1 sites, try something like:
class-map match-any VoIP
match . . .
policy-map CBWFQ
class VoIP
priority percent 30
class class-default
fair-queue
For your multiple bundled T1 sites, try something like:
class-map match-any Site1
match . . .
class-map match-any Site2
match . . .
class-map match-any SiteN
match . . .
policy-map Shape_T1
class Site1
shape average 1300000
service-policy CBWFQ
class Site2
shape average 1300000
service-policy CBWFQ
class SiteN
shape average 1300000
service-policy CBWFQ
06-21-2012 05:36 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
Your 2x is probably because you're using shape peak, not shape average (as I suggested).
I also suggest shaping at about 85% of nominal bandwidth, to allow for L2 overhead not accounted for by a L3 shaper; becomes important for VoIP.
Lastly, with FQ in clas-default, you often don't need any other classes other than LLQ. I.e. you probably don't need the explicit classes for Network-Control or VoIP-Signaling.
06-15-2012 11:46 AM
First thing, make contact with the MPLS provider and find out what they support for this customers service level.
What ever you do will have to work in their framework.
06-15-2012 03:15 PM
Yes, thanks vmiller, I do understand the need to coordinate with the MPLS provider. However, if the central site sends traffic at 4 times the rate that the far end can handle, we're very likely to have problems (no matter what the SP is doing for the customer). So, I'm trying to figure out what the current best practice is for that central site's customer premise router.
Thanks again for your suggestion, and we certainly will do so!
06-15-2012 03:30 PM
You will need to rate limit after you classify, and make it work with how the carrier handles QOS on the MPLS backbone.
You can start here to get cozy with the terminolgy. there are some nice design guides on the cisco site.
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml
06-15-2012 05:34 PM
Thanks, vmiller. I was already completely familiar with the material at the link you sent; however, at the very bottom of that doc is a link to CBWFQ *inside* of GTS, and the ability to do *that* is the what I've been missing. I have CBWFQ set up already, and shaping or policing on top of that (using GTS) differently to the different remote sites based on their connected bandwidth looks like exactly what I need.
Thanks again for your time! It's very much appreciated!
06-16-2012 05:14 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
You can shape on each sites egress to avoid over running the far side's ingress, however this is only practical if you have few sites and also assuming you can treat your topology as hub-and-spoke. (I.e. a logical topology much like you might have for frame-relay or ATM.)
If you want to take advantage of L3 VPN on MPLS, then you need QoS support from your MPLS vendor for some options of egress processing from their MPLS cloud to each of your sites. You still want QoS to manage egress congestion to the MPLS cloud but additionally you would mark traffic so that it will be properly treated upon MPLS egress.
The two common disadvantages of this approach are often the MPLS vendor might only offer rudimentary egress QoS policy options and they might charge more for activation (especially for real-time guarantees).
06-19-2012 07:18 PM
Thanks for your time and suggestions, Joseph.
I've followed the config examples for "CBWFQ inside GTS" at this link:
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfcbshp.html#wp1002823
However, the config is not working.
I'll paste in here the config example from that link, and then use it to explain the problem I'm having:
cust1-classes Configuration
Router(config)# policy-map cust1-classes
Router(config-pmap)# class gold
Router(config-pmap-c)# bandwidth percent 50
Router(config-pmap)# class silver
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap)# class bronze
Router(config-pmap-c)# bandwidth percent 15
cust2-classes Configuration
Router(config)# policy-map cust2-classes
Router(config-pmap)# class gold
Router(config-pmap-c)# bandwidth percent 30
Router(config-pmap)# class silver
Router(config-pmap-c)# bandwidth percent 15
Router(config-pmap)# class bronze
Router(config-pmap-c)# bandwidth percent 10
Customer Policy and QoS Features Configuration
Router(config)# policy-map cust-policy
Router(config-pmap)# class cust1
Router(config-pmap-c)# shape average 384000
Router(config-pmap-c)# service-policy cust1-classes
Router(config-pmap)# class cust2
Router(config-pmap-c)# shape peak 512000
Router(config-pmap-c)# service-policy cust2-classes
Router(config-pmap-c)# interface Serial 3/2
Router(config-if)# service out cust-policy
So, in my config, when I entered the equivalent commands to these:
policy-map cust-policy
class cust1
I got an error message that the class-map cust1 wasn't configured yet.....hmmmm...this example made it look like that wasn't necessary. However, I issued the (equivalent for my config) command to:
class-map cust1
Then, the policy-map accepted the command, and I proceeded to apply the shape and service-policy commands.
So, I thought all was well. However, *no* traffic is matching my embedded CBWFQ service-policies. No packets, no bytes. (All packets are matching the class-default class-map.)
Any suggestions? Does anyone have a complete known good working config that I could see?
(I should probably mention that I have defined a bunch of class-maps that are used by the (equivalent of) the embedded "service-policy cust1-classes", "service-policy cust2-classes", etc.)
Thanks again for any time/suggestions/help!
Deb
Message was edited by: Deborah Smith
06-20-2012 12:28 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
For your T1 sites, try something like:
class-map match-any VoIP
match . . .
policy-map CBWFQ
class VoIP
priority percent 30
class class-default
fair-queue
For your multiple bundled T1 sites, try something like:
class-map match-any Site1
match . . .
class-map match-any Site2
match . . .
class-map match-any SiteN
match . . .
policy-map Shape_T1
class Site1
shape average 1300000
service-policy CBWFQ
class Site2
shape average 1300000
service-policy CBWFQ
class SiteN
shape average 1300000
service-policy CBWFQ
06-21-2012 05:06 PM
Hello, Joseph.
Thank you for your suggestion. I have set up something similar to what you suggested.
I *thought* that all was well. However, for some reason the target shape rate is twice the configured peak rate:
sho policy-map int mu1
Multilink1
Service-policy output: QoS-Shape-T1-Out
Class-map:
5266361 packets, 1472713784 bytes
30 second offered rate 58000 bps, drop rate 0 bps
Match: access-group name
5266361 packets, 1472713784 bytes
30 second rate 58000 bps
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/3070/0
(pkts output/bytes output) 5263291/1470261787
bandwidth 760 kbps
shape (peak) cir 1400000, bc 5600, be 5600
target shape rate 2800000
FYI: The interface Mu1 consists of 4 x T1. It is exactly twice over-subscribed by either single or dual T1s at the remote sites. So, you can see in the config below that I'm setting the guarenteed minimum bandwidth for each single T1 site to 760k (a bit less than half of a T1), and trying to shape to a peak of 1400kbps (a bit less than a full T1). I've been poring through docs on CCO, but so far I'm baffled as to why the target shape rate is being set by IOS to 2800k.
Thanks very, very much for your help already! If you have any idea on why the target shape rate is twice the CIR, I would greatly appreciate hearing it!
Best Regards,
Deb
P.S.
By the way, I tried to use 768k for the bandwidth, but it seems that with IOS 15.x at least 1% of the available b/w of the physical interface must not be reserved (i.e., left for the automatically created class "class-default"). So, I used 760.
-----------------------------------------------------------------------------------------
Here is an excerpt of the relevant parts of the configuration:
class-map match-any Network-Control
match ip dscp 48
match ip dscp 56
class-map match-any VOIP-Bearer
match ip dscp 46
class-map match-any VOIP-Signaling
match ip dscp 24
!
policy-map QoS-LLQ-Out
class Network-Control
bandwidth percent 5
class VOIP-Bearer
priority percent 18
class VOIP-Signaling
bandwidth percent 5
!
class-map match-any Site1
match access-group name Site1-Subnets
class-map match-any Site2
match access-group name Site2-Subnets
!
policy-map QoS-Shape-T1-Out
class Site1
bandwidth 760
shape peak 1400000
service-policy QoS-LLQ-Out
class Cashmere
bandwidth 760
shape peak 1400000
service-policy QoS-LLQ-Out
!
06-21-2012 05:36 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
Your 2x is probably because you're using shape peak, not shape average (as I suggested).
I also suggest shaping at about 85% of nominal bandwidth, to allow for L2 overhead not accounted for by a L3 shaper; becomes important for VoIP.
Lastly, with FQ in clas-default, you often don't need any other classes other than LLQ. I.e. you probably don't need the explicit classes for Network-Control or VoIP-Signaling.
06-21-2012 06:28 PM
Thank you, once again, Joseph. "Shape average" (yes, as you suggested) did take care of the 2x target shape rate problem (*that* was unexpected: shaping to a "peak" sounds like a not-to-exceed, vs shaping to an average).
Once again, I offer my thanks and appreciation for all of your time and suggestions!
Deb
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