For Ethernet fed multi-tenant applications, there are several issues to consider when attempting to limit or guarantee bandwidth to a particular customer(s). Outbound traffic toward the ISP, can be controlled on a per customer basis using Class Based Weighted Fair Queuing (CBWFQ) QoS policies to guarantee each customer a portion of the available bandwidth but does allow the customer to burst above their allotted bandwidth, up to the interface rate.
If all customers are transmitting simultaneously with enough data to saturate the WAN, then QoS insures each customer receives their bandwidth allocation. This burst can be controlled by using the shape average command within Enhanced Ethernet QoS (EEQoS) but, there is a limit of 5 shapers per QoS policy, and only one QoS policy per interface. Using this approach only 5 customer subnets can be controlled. This 5 customer limit does not apply to standard CBWFQ QoS policies
Inbound or downloads, traffic coming toward the customer, is the primary issue when dealing with multi-tenant applications. If the ISP does not traffic shape per sub-interface or IP subnet back toward the customer, a single tenant can take more than their fair share of the bandwidth when downloading packets. While traffic shaping can be applied to the router interface facing the customer, the traffic at that point has reached the router therefore has traversed the link and already caused a bottle neck.
Using traffic shapers, TCP traffic can be affected by queuing the traffic and causing TCP window sizing to slow down the transmit rate. This is only applicable for TCP packets as UDP traffic does not operate in this fashion and could flood the link causing delay for all customers. Relying on TCP window sizing is not a guaranteed method and does allow traffic to burst, possibly causing temporary traffic delay for other customers. TCP knows nothing of the speed of a link only that packets are not being received in a timely fashion and retransmits are required. This can cause the TCP connection to slow down dramatically, well below what the interface rate actually is.
For Ethernet fed multi-tenant applications, the best practice is to use 802.1q encapsulation with sub interfaces for each customer and each customer has their own Public IP subnet. This is commonly referred to as EVCs or Ethernet Virtual Circuits. In this scenario each sub interface (customer’s interface) is rate limited to a specified rate. EEQoS allows each customer to get full utilization of their prescribed bandwidth by allowing them to set QoS and shaping policies per application that is relevant to them. The only limitation is the 5 shaper limit per Qos Policy. Since the ISP would provide traffic shaping toward the customer, there is no longer a concern with the link being saturated by any one customer’s traffic.
