It's Really Only Partly Cloudy Out There

Weatherize Your Network Now Before the Clouds Roll In

In the last couple blogs I listed some network issues I foresee with the coming Cloud Computing rush. The five major areas I listed as issues are:

  1. Bandwidth - is there ever enough?
  2. Network Security - how much do you really trust that SaaS provider?
  3. QoS - you mean there's no QoS on the Internet?
  4. IPv4 space - you're unlikely to be able to use RFC1918 address space to communicate with the cloud.
  5. Routing - how do we get the data to the cloud in the first place?

Despite the gloomy forecast I gave, it's not all tornados and floods. There are fixes to each of these issues. Preparation (now!) is the key.


First, get some WAN acceleration for both your field sites and your internal data centers. Even though you will probably need to buy more bandwidth, you can't buy less WAN delay which will be worse now. And, WAN acceleration will lessen the extra bandwidth you need. The user experience with the cloud applications will be better; bulk data center to data center transfers will complete faster; and you'll have better visibility to all traffic flows. From a business perspective, WAN acceleration should be included in any business case for a cloud service. It should not be a separate ROI justification, it should be included as part of the overall business case for cloud services. Next, start working now with your InfoSec Architects and CISO to develop security policies for cloud services. Researching, discussing, and agreeing to a generalized security model for all cloud services will take the most time. Once you have that, you can develop network security templates to connect to cloud services. If it's Internet-based cloud services, you'll probably need VPNs and firewall rules based on the general policies you've already created. Don't forget other InfoSec services like logging, IDPS, and content controls. Game plan different types of connections to clouds including Internet and private WAN (MPLS) based connections. How would you handle each? How will traffic flow through appropriate security devices? Put yourself in the shoes of a cloud provider and think about what you would need from a single customer. I would argue you will have 90% of solution for a cloud service before you even buy a service. For QoS, WAN acceleration will help, but it's still not end-to-end QoS. If you're using the Internet to connect to the cloud, provide QoS for all cloud-destined traffic on your internal network. At least you will eliminate any QoS problems on your internal network. Next, if you can make the routing work properly and the costs are justified, buy dedicated Internet circuits for the cloud traffic. Since the Internet bottleneck is often the local access circuit, eliminating all non-cloud traffic on that circuit (YouTube, Facebook, etc) will help. Finally, check with the cloud provider to see if they have preferred relationships will certain ISPs. Some ISPs will provide basic QoS on their Internet backbone provided the traffic never leaves their Internet backbone. If your cloud provider has an Internet circuit to ISP X, and ISP X offers basic Internet QoS, buy a dedicated Internet circuit from ISP X. If the cloud is internal (maybe off your MPLS network), then you can have end-to-end QoS. The problem here will be aligning QoS policies. Start brainstorming ways to map your QoS policies into more basic QoS policies. Focus on RFC standards for DSCP usage. This way you are prepared to support whatever QoS model the cloud provider has even if it's not an exact match to what you use today. For IP space, this IS the opportunity to use IPv6, but not exclusively. No way 99% of enterprises are ready to use IPv6 exclusively with a cloud provider. You'll need IPv4. But, use IPv6 too. IPv4/6 dual-stack should be part of the standard service set with any new cloud provider. This will get your feet wet with IPv6, get your application teams used to the idea of having to support IPv6, and prepare you to move off IPv4 (maybe someday). For the time being, you are going to need more public IPv4 space. If you are lacking free address space, make an effort to recapture space. For example, you probably have your Internet router IP addresses configured with public IPv4 addresses (like loopbacks). Why? They can be private. The only thing that needs to be public on Internet routers is the interface to the ISPs. Make every effort to save and recapture public IPs. Be careful using space from ISPs since you will be tied to their Internet service, but it may be necessary. Use more NAT for inbound applications that are in your DMZ instead of directly accessible public IPv4 addresses. Saving public IPv4 space should be a call-to-arms for your networking team. Finally, routing. To make it succinct - everything (EVERYTHING!) needs to be dynamic, probably with BGP. If your routing protocol design stinks (don't lie to yourself), start fixing it now. There will be no room for poor OSPF design, unsummarized EIGRP, bad redistribution, or no written BGP policy. You won't be able to log into a cloud provider's core router and add a static route to fix a pesky routing problem. It's going to be a problem that can't be fixed because your routing protocol design is bad and some obnoxious, smart-ass network engineer from the cloud provider is going to call you on it. Now you'll be found out and have to explain to the CIO why this problem hasn't been fixed in your 4+ years with the company. Ouch! As a network engineer, I would make this topic #1 to work on to prepare for clouds.


See, now doesn't that feel better? It's sort of sunny out now, humidity is low and there's a cool breeze. Now skip all that nice weather, stay inside, and start preparing for the Clouds.

More >From the Field blog entries:

Networking in the (Thunder) Clouds

Networking in the (Storm) Clouds

How to Save Some $$$s - Keep Competition in Your Network

You Knew I Had to Comment on the Cisco Certified Architect Program

Happy 2-Year Anniversary - A Reminder to Focus on What's Really Important in Network Engineering

Using FCAPS for IP Telephony Management

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Copyright © 2009 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022