Metro Ethernet settings on Customer devices

Question

I am about to connect three remote sites to the main office by means of an metro ethernet provided by a service provider. The sites are connected by means of l3 and running OSPF on the connecting routers (it is a layer 2 cloud but terminating at l3 seems wise in my case). I assume that the service provider runs VPLS but not sure.

I am wondering about a couple of things:

The main site has a 300Mbit and the remote sites have 100Mbit (no over subscription). The routers have 1 Gbit interfaces connecting to a cpe at that same speed. Every remote site has several vlans so on the remote site routers there are subinterfaces..

Is wise to shape traffic at 100Mbit on the wan interface of the remote sites, or no need for this?

I will be implementing QoS later on. Where do I put the bandwidth command? On the sub interface, on the wan interface or on both?

Care to collaborate..?

Answer 1

The provider could be using one of a handful of technologies to provide multipoint-to-multipoint connectivity for you, VPLS being one of them. It's also not clear from your question if you're actually getting a true multipoint-to-multipoint service, or if your provider is giving you just a bunch of point-to-point services, or a rooted multi-point service.

MetroE providers (at least MEF-compliant ones) will typically advise you to shape into the UNI/EVC(s) for the best performance, but it's certainly not mandatory for you to do so because they'll likely be shaping on their ingress coming from you anyway. Depending on what services you've purchased from your provider, your typical bandwidth profile options are (it would be useful to get this information from your SLS/SLA):

• Bandwidth Profile per UNI
• Bandwidth Profile per EVC
• Bandwidth Profile per CoS ID

The last of the three being the most granular level of hierarchy. CoS ID can represent:

• The EVC
• PCP bits
• DSCP bits

You can use any of these for a CoS ID, but using the PCP bits keeps you from having to look into the L3 header for DSCP values, and you can have 8 individual CoS ID's if you want (one for each PCP bit). No matter what though, (if you do choose to go with using the PCP bits) you have to use all of them, and there can't be any overlap. It's also a possibility that your hardware doesn't have the ability to do QoS based on PCP bits, in which case doing it via the DSCP values in the IP header will work.

Ultimately in order for anyone to give you a useful answer of what kind of QoS policy to mock up, it would be beneficial to get the service-level specs from your metroE provider, because they should have told you what sort of bandwidth profile you'd be getting with your service... and if they haven't, then you should definitely ask. :-)

Answer 2

Question seems to be about QoS not VPLS.

You are thinking correctly, always when your interfaces actual rate is less than physical rate, you need to configure shaper.

Without this sub-rate shaper, QoS configuration cannot work, as you cannot know when to start dropping packets, as the router will think you have 1GE available capacity and will not realize you're congested at 300Mbps.

So you'd configure parent shaper of 300Mbps and under this shaper you'd configure your QoS policy. This config should be in physical interface.
If you have multiple VLANs, you need another hierarchy level, that is you'll first give physical interface 300Mbps, then distribute this as burstable percentages to different vlans, then apply to each of these vlans their own QoS policy.

I would start simple and work up. I.e. 300Mbps shaper in physical and QoS policy in the physical only, treating all VLANs as equal. If you'll specify platform, I can give example of HQoS config.

IOS example could be:

class-map match-any EF
 match  precedence 5
 match  precedence 6 
 match  precedence 7 
class-map match-any AF
 match  precedence 1 
 match  precedence 2 
 match  precedence 3 
 match  precedence 4
 match packet length max 200
!
policy-map Parent
 class class-default
    shape average 300000000
   service-policy Child
policy-map Child
 class EF
    priority percent 20
 class AF
    bandwidth percent 50
 class class-default
    bandwidth percent 30
!
interface X
  service-policy output Parent

This is purely random example, you should decide how many classes you need (I recommend as few as possible, and only add classes when you absolutely you know you must, start with 2) and you should decide how to distribute the guaranteed share of them. 'bandwidth percent X' is burstable, 'priority percent X' usually is not (should be accompanied with policer).
Good staring point would be two classes, both burstable (bandwidth percent X), some high priority traffic class and rest (class-default). Then you'd only need to decide what traffic to put in high priority class, and what their guaranteed share of the 300Mbps would be.