Jeremy Littlejohn


Upcoming Events

Where the Cloud Touches Down: Simplifying Data Center Infrastructure Management

Thursday, July 25, 2013
10:00 AM PT/1:00 PM ET

In most data centers, DCIM rests on a shaky foundation of manual record keeping and scattered documentation. OpManager replaces data center documentation with a single repository for data, QRCodes for asset tracking, accurate 3D mapping of asset locations, and a configuration management database (CMDB). In this webcast, sponsored by ManageEngine, you will see how a real-world datacenter mapping stored in racktables gets imported into OpManager, which then provides a 3D visualization of where assets actually are. You'll also see how the QR Code generator helps you make the link between real assets and the monitoring world, and how the layered CMDB provides a single point of view for all your configuration data.

Register Now!

A Network Computing Webinar:
SDN First Steps

Thursday, August 8, 2013
11:00 AM PT / 2:00 PM ET

This webinar will help attendees understand the overall concept of SDN and its benefits, describe the different conceptual approaches to SDN, and examine the various technologies, both proprietary and open source, that are emerging. It will also help users decide whether SDN makes sense in their environment, and outline the first steps IT can take for testing SDN technologies.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up

See more from this blogger

Fumble Your MPLS Handoff: Shaping And Policing

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.


Related Reading


More Insights


Network Computing encourages readers to engage in spirited, healthy debate, including taking us to task. However, Network Computing moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Network Computing further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | Please read our commenting policy.
 
Vendor Comparisons
Network Computing’s Vendor Comparisons provide extensive details on products and services, including downloadable feature matrices. Our categories include:

Next Gen Network Reports

Research and Reports

Network Computing: April 2013



TechWeb Careers