Enterprise QOS

Answered Question

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.

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 8 years 2 weeks ago

"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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jon Marshall Mon, 01/05/2009 - 08:42

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

Joseph W. Doherty Mon, 01/05/2009 - 09:39

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).

Correct Answer
Joseph W. Doherty Mon, 01/05/2009 - 12:57

"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.

Joseph W. Doherty Tue, 01/06/2009 - 05:13

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

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.

Joseph W. Doherty Wed, 04/22/2009 - 02:59

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.

Actions

This Discussion