QoS via layer 2 WAN link?

[Photogregor]

Hi all,

I'm thinking aobut prioritizing traffic over a L2 MAN link (200 MBit Colt Etherlink). Background scenario is: We mainly have two sorts of traffic. One is system monitoring, heart beats etc. of our systems at another branch. This traffic should not be more than a few KB/s. The other sort of traffic is replication between data store cluster, which is congesting the line for several hours per day and preventing monitoring systems from working flawlessly during this time.

On both ends of the MAN link we use Cisco 3850 switches.

My question is more of a fundamental nature: Is QoS/traffic shaping within such a L2 scenario basically possible and sensible?

Thank you in advance if someone has a few helpful words to say on this subject.

Regards
Stefano

[Joseph W. Doherty]

"My question is more of a fundamental nature: Is QoS/traffic shaping within such a L2 scenario basically possible and sensible?"

Possible? I haven't worked with the 3850, so cannot say for sure it's possible, but it would have been on the prior 3560/3750, so good chance it is too on a 3650/3850.

Sensible? Yes.

[Yogi-Bear]

Talk to your provider, they can probably provide you with CoS. If their WAN L2 is MEF compliant, you can read more about it on Internet since its standardized. You would ask them to add CoS that is real-time or prioritized over the synchronization traffic. I would guess your current EVC is best-effort or standard class, not more than that.

Basically it would be the ideal scenario to add a CoS to your WAN since you could do end-to-end QoS.

[Joseph W. Doherty]

Bobby makes a good suggestion, as sometimes MetroE providers do provide some QoS support. However, be very careful to fully understand their QoS support, and its potential impact.

In a case like yours, you often need to manage traffic priorities before you inject traffic into MetroE provider's cloud. I.e. shaping and prioritization might still be needed on your equipment.

[Eric101]

Hello Stefano,

It is possible and sensible. It is the best practice to police your outbound traffic data rate to not exceed your contracted data rate with your service provider.
As an example, assuming you have a 1Gbps interface, your switch may attempt to throw more than 200Mbps trafffic at the Service provider, which they will then begin to drop indiscriminately (sometimes replication, other times your monitoring). If you move the policing and dropping decision to your switch, you can choose which traffic is dropped.

[Joseph W. Doherty]

Eric, could you give a generic example how you would accomplish what you suggest?

I ask because I know you can police the aggregate, but then you don't have control over which traffic gets dropped. I also know you can police per kind of traffic, but then you're unable to take full advantage of all the aggregate bandwidth.

[Eric101]

Depends really on how in depth you want to go and how critical the traffic is (zero-loss verus some loss)
I would mark down replication traffic, implement a generic policer and, just adjust the queuing policy to drop the marked down traffic at a higher rate than the default.
If you know that your monitoring traffic will never exceed a certain value and cannot risk to lose any packets, you can carve out the bandwidth and protect by policing per-class, but as you noted you lose some of the aggregate bandwidth, but in the case of blocking 1 Mbps for your Kbps of monitoring, it isn't wort the hassle.

[Joseph W. Doherty]

"I would mark down replication traffic, implement a generic policer and, just adjust the queuing policy to drop the marked down traffic at a higher rate than the default."

I agree with that, but again, I don't know how to do it. Could you provide a generic sample?

[Eric101]

Hello Joe,

As an example mark inbound replication traffic to a desired DSCP marking (in this case af11) based on the parameters (e.g. NetApp NDMP replication)

ip access-list extended bulk-data
permit ip 10.1.10.0 0.0.0.255 10.2.10.0 0.0.0.255 eq 10000
!
class-map match-any marker-bulk-data
match access-group name bulk-data
!
policy-map qos-inbound-marker
class marker-bulk-data
set dscp af11
class class-default

You need to apply the marker to the interfaces inbound from the datacentre block, or optionally somewhere else such as the port the traffic source is connected to.
e.g.
interface te1/1/1
service-policy input qos-inbound-marker

Once the traffic is marked, you can make decisions on it at the metro link.


class-map match-any match-bulk-data
match dscp af11
!
policy-map qos-outbound-shaper-child
class match-bulk-data
bandwidth percent 75
class class-default
bandwidth percent 25
!
policy-map qos-outbound-shaper-parent
class class-default
shape average 200000000
service-policy qos-outbound-shaper-child

The policy needs to be applied to the outbound interface to the metro link.

interface gi 1/1/1
service-policy output qos-outbound-shaper-parent

This is a very basic policy, that would cover the stated requirement. Obviously if replication is NFS, iSCSI, or some other protocol, or perhaps all replication sources/destinations are in unique subnets, the matching ACL should change accordingly. If there is more than the management and replication traffic, a more complex QoS may be warranted. For example, network management traffic would normally want to be categorised and protected as it traverses the network into it's unique class. I would suggest looking at the Campus QoS Validated design guides and Medianet, for more information on mapping traffic to available hardware queues.

[Joseph W. Doherty]

"policy-map qos-outbound-shaper-child
class match-bulk-data
bandwidth percent 75
class class-default
bandwidth percent 25"

BTW, you could allocate bandwidth as you've done, but if match-bulk-data is non-essential traffic, you might want to mark with the "scavenger" marking (CS1) and set the bandwidth percentage for it to 1%. (Remember CBWFQ percentage is a minimum guarantee - i.e. such traffic, could obtain and use all the link bandwidth, if otherwise unused. Setting it to a low percentage insures other traffic jumps ahead of it, yet the 1% guarantees it's never fully stopped.)