01-05-2009 08:31 AM - edited 03-04-2019 03:20 AM
I have 3 main sites which have 45 mb into MPLS, I also have 30 remote sites that have a range of bandwidth into MPLS. Ranging from 1.5mb to 8mb. My question is can someone recommend a high level QOS design for this type of environment? My concern is, our larger sites could be over running our smaller sites as far as bandwidth is concerned.
Solved! Go to Solution.
01-05-2009 12:57 PM
"What type of MPLS egress QOS are we talking about?" Traffic from PE to CE, or traffic from MPLS cloud crossing your access link from MPLS cloud.
If you only had just one main site, you could keep from over running your smaller sites by using shapers, however your original post mentions 3 mains sites. Assuming each can send smaller (same) site, and also even assuming only those 3 sites send to smaller (same) site, you could divide smaller site bandwidth using 3 main site shapers but then there's likely to be unused bandwidth when not all 3 main sites are using their full allocation. This why it's best to manage congestion on PE, but you can only do so indirectly working within the MPLS provider's QoS framework.
"We current buy CBWFQ from them. But as I said our main site could over run our smaller sites." Yes it can. Also true for other cloud technologies that support asymmetrical bandwidth. Major difference is where you manage congestion.
01-05-2009 08:42 AM
Daniel
That is a rather broad question. Bear in mind also that no matter how you prioritise traffic within your sites all your traffic will be considered best effort within the MPLS clould unless you are paying for differentiated levels of service for your traffic to the Service Provider.
You don't say what sort of traffic is involved but if you are primarily concerned with no over running remote sites you should be looking at shaping. Attached is a link to a design doc for Enterprise QOS, it's a big read but you can pick out the relevant bits -
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book.html
Jon
01-05-2009 09:39 AM
As a high level QoS design, you'll want QoS at MPLS ingress (offen easily doable if you control the CE device) and you'll want QoS at MPLS egress (requires QoS support from your MPLS provider - support can vary much between MPLS vendors; MPLS vendors sometimes charge extra for this support).
If MPLS egress QoS not supported by vendor, you can sometimes still manage egress via ingress shaping but this is also often impractical if multiple sites can pass traffic to each other (e.g. p-2-p or hub-n-spoke practical; partial or full mesh impractical).
01-05-2009 09:59 AM
What type of MPLS egress QOS are we talking about? We current buy CBWFQ from them. But as I said our main site could over run our smaller sites. What is MPLS engress? Is that sending to each site from MPLS? Did I word that correctly?
01-05-2009 12:57 PM
"What type of MPLS egress QOS are we talking about?" Traffic from PE to CE, or traffic from MPLS cloud crossing your access link from MPLS cloud.
If you only had just one main site, you could keep from over running your smaller sites by using shapers, however your original post mentions 3 mains sites. Assuming each can send smaller (same) site, and also even assuming only those 3 sites send to smaller (same) site, you could divide smaller site bandwidth using 3 main site shapers but then there's likely to be unused bandwidth when not all 3 main sites are using their full allocation. This why it's best to manage congestion on PE, but you can only do so indirectly working within the MPLS provider's QoS framework.
"We current buy CBWFQ from them. But as I said our main site could over run our smaller sites." Yes it can. Also true for other cloud technologies that support asymmetrical bandwidth. Major difference is where you manage congestion.
01-05-2009 01:05 PM
Thanks Joseph, do you have a document that gives configuration examples for the shaping config with 1 main site?
01-06-2009 05:13 AM
Sorry, don't have an explicit document that I can point you to. However, CBWFQ config would be somewhat as follows:
(NB: syntax may be incorrect)
ip access-list extended site1
remark match againt destination addresses
ip permit any x.x.x.x y.y.y.y
ip access-list extended site2
remark match againt destination addresses
ip permit any x.x.x.x y.y.y.y
ip access-list extended siteN
remark match againt destination addresses
ip permit any x.x.x.x y.y.y.y
class-map match-xxx site1
match access-group site1
class-map match-xxx site2
match access-group site2
class-map match-xxx siteN
match access-group siteN
policy-map shapetosites
class site1
shape average x
class site2
shape average y
class siteN
shape average z
interface x
service-policy output shapetosites
04-21-2009 01:53 PM
Based on the design mentioned above a few questions have popped up. Because we are a fully meshed MPLS network some of our remote sites might have servers that some of the smallers sites access which in turn could affect this policy by over running the site. Thoughts? My thought was we try to place the shaper as close to the source of "most" of the traffic (central site). Any way around this? The big issue I am trying to help is our main sites over running our smaller sites which affects our voice quality. Any input would be great.
04-22-2009 02:59 AM
Once you start to encounter any-to-any traffic flows within MPLS, it's difficult to define configurations to guarantee VoIP performance without support of MPLS vendor provided QoS.
You would need to define at each site, shapers for all other reachable sites, and manage bandwidth allocations such that the incoming bandwidth to each site insures sufficient bandwidth is available for VoIP. (Such a design will also likely "waste" bandwidth into a site.)
Or, you might overlay GRE tunnels and route your traffic through a logical hub and spoke design. This too is non-trival but would make it a easier to manage bandwidth.
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