Networking in the (Thunder) Clouds

More Thoughts on Networking and Cloud Computing

In last week's blog, I dove into the network issues I see surrounding the much-hyped "cloud computing" solutions.

I thought I'd continue my harangue a bit this week with three more issues I see. But don't fear, next week the storm clouds will start to clear (or at least I'll have some ideas on how to weatherize your network).

With cloud federations over the Internet, QoS is going to be nonexistent. Yes, you can control QoS internally before it reaches your Internet exit point and queue the traffic outbound to the Internet, but after that it's all best effort. Plus, return traffic from the cloud (which is most likely to be heavy since it is traffic returning from the cloud) will be uncontrolled. Buying separate Internet circuits for just cloud traffic is an option, but that raises costs, requires detailed routing plans, and does not get around Internet backbone problems.

Plus, even if you did have QoS (maybe with cloud services provided by your MPLS VPN provider), you have to agree on QoS policy. Will the provider set application and servers to mark DSCP bits as you want? If not, will the cloud provider's LAN mark packets in the manner (policy) you want? Does that policy align to what the MPLS carrier provides? How many MPLS providers do you have?

There are big technical issues to address first, and then larger process, policy, and procedure issues afterwards.

I thought I heard someone mention something about public IPv4 space running low?

If you're using the Internet to connect to a cloud, that is going to take some public IPv4 addresses. Many cloud providers will not communicate natively with RFC1918 addresses, only public IPs. So, you better have a chunk of space available now because the RIRs are not giving more out.

NAT is of course a solution, but NAT has limitations with inbound flows (requires static NAT), it requires symmetric traffic flows, and dynamic NAT is limited based on TCP port numbers (yes, there are a lot of TCP ports to overload, but think of the millions of connections that could be coming from a fortune 100 company through a NAT to a cloud data center).

(Could this be the business case for IPv6 we have long waited for???? hmmmmmmm....let's see next week)

My final issue is my favorite network topic of all - good old fashion dynamic routing. Getting traffic to this cloud - maybe over the Internet through a VPN tunnel with NAT'ing - is going to take a very good routing design. Do you have a completely dynamic routing design now? Or did you static route the Internet connections because routing protocols through the firewalls were too tough to design (technically and politically)? Can your routing design scale to handle many more routes? Or are running OSPF with poor area design and no summarization? How is your routing protocol security?

Next, is your core routing protocol BGP or is BGP at least a part of your design for external connections? You can bet that's the only protocol cloud providers will allow you to run with them to exchange routes. If you are using the Internet, how will you deal with inconsistent AS-path length paths to the cloud provider over diverse ISPs?

There's a reason Cisco built a multi-billion dollar business on the back of routing technology. It's tough to do right and, outside of some very good networking people, still not well understood in IT. Most IT people have no concept of how hard it is to efficiently move packets from A to B. It's going to get harder with clouds.

But, as I mentioned at the beginning, all is not hopeless. None of these problems are insurmountable. If we can land on the moon, we can do networking with a cloud.

I'll jump into some ideas next week.

More >From the Field blog entries:

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

Not a Lot of Excitement for Networkers This Year?

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

• BGP
• cloud computing
• IPv4
• IPv6
• networking
• QoS
• RFC1918