Getting maximum performance from an MPLS network that is managed by the carrier and delivered via an Ethernet hand-off can be a challenge for your network if you don't take some additional steps to utilize it effectively. We see performance issues in these topologies on a regular basis. Think about this: how do you know if you are dropping traffic or your traffic is being slowed down considerably in some virtually bottomless queue across the MPLS cloud? Hopefully, your only feedback mechanism isn't the help desk. Don't trust the carrier to provide you with any shaping or any
protection for traffic over your purchased rate. For that matter, don't
even trust them for that. Make sure you actively test the MPLS cloud at
least quarterly. There are some steps you can take to improve this performance before the traffic leaves your network.
The top performance problems, aside from carrier issues, are loss and delay across the MPLS backbone. We find that these are caused most often by a mismatch in speeds between the Ethernet hand-off (100 Mbps) and the actual purchased bandwidth or committed rate from the carrier. This mismatch means that you are sending traffic to the carrier cloud at a much faster rate than it is provisioned to transmit that data. You might be thinking that the carrier is going to handle this mismatch for you, but from our analytics and experience, that's a mistake. The result is dropped packets or severely delayed packets sitting in carrier buffers.
We suggest that you don't count on the carrier to do anything correctly. You need to control everything you can about how your traffic goes into and comes out of the cloud. How do you do this, especially in a world of managed MPLS and Ethernet hand-offs? Always shape or police traffic as you send it towards the cloud. This allows you to compensate for the speed mismatch between your 100 Mbps hand-off and the actual bandwidth on the other side of the managed MPLS router. It also enables you to see when you are dropping packets because you're going past your purchased bandwidth.
If you have WAN acceleration or traffic-engineering products on each side of the link, then you probably get this feedback now, assuming you check the reports. Using a WAN acceleration device is the best option available because in addition to shaping, you also get all of the other benefits of WAN acceleration, such as compression. If you don't have the money to put in WAN acceleration devices, then traffic-shaping in a router is your next best option. Shaping is better than Policing for achieving the high performance that you need. You may still drop some traffic if you run out of shaping buffer, and some traffic may be delayed slightly, but typically, a shaping device will allow you to prioritize the traffic so that you can at least bump your real-time applications to the top of the queue and get them out the door first.
Finally, you can police traffic. If you are going directly into a LAN switch and not a router this may be your only option. Policing is more draconian than shaping and yields a saw-blade traffic pattern as opposed to a flat line, which shaping tries to deliver. But that traffic would have likely been dropped or delayed anyway, and at least you can check the stats and see the behavior immediately. Then, you can make a decision about how to prevent it in the future.
