The Imperfect Lab: Connecting a VNET to another VNET

As I mentioned yesterday, I'm struggling with setting up the "perfect" lab environment for myself. So instead of trying to make it perfect, I'm just going to start by simply getting started and letting in evolve.  Because starting is most of the battle, right?  Most environments grow and change and become a bit messy, so I am just going to embrace a little chaos!

My starting goal is to create two networks in Azure (in two different regions) and connect them.  To start I'll need two VNETs in Azure. I also created two corresponding storage accounts in each region, so that when I'm building my servers, everything is as neat an organized as I can make it.

In each of the networks, I carved out a few subnets, because I don't know exactly what I'm doing with them yet. Keep in mind you will need to make at a small Gateway subnet in each. Also, as soon as you put a VM in a subnet, you can no longer edit it.

• ImperfectNet - 192.168.1.0/22 (West region)
• AnotherNet - 192.168.4.0/23 (East region)

Because I want to connect them together with site-to-site networking, I have to create corresponding "local" networks in Azure to sort of trick each network into thinking its connecting to a physical network.  So under the "Local Networks" tab, I created "ImperfectLocal" and "AnotherLocal" with the same IP address ranges as the virtual networks. Be sure to put in a fake VPN Gateway Address as a placeholder here, you'll update it later after Azure gives you a real gateway address.

In each network, I threw the ticky-box under Site-to-Site Connectivity, selected the correct "local" network and then created the Gateway subnet.  After everything was finished configuring, when you return to the dashboard page of each network, you will see the remote network showing.  Azure will tell you that "the gateway was not created".

Click "create gateway" at the bottom. For VNET to VNET connectivity, you have to go with Dynamic Routing.  Do this for each network and wait for it to complete.  (Creating gateways actually takes a while, this might be a good time to get lunch.)

Once your gateways are created, write down the IP addresses carefully and then edit those "local networks" with the fake VPN gateways to the correct ones Azure just assigned you.

Finally, you have connect the networks together with shared key.  There isn't any way to do this in the portal, so pop over to PowerShell and use the following code to hook them together.  You have to run the command twice with the corresponding network names and the SAME shared key. Please make your key longer then the sample I put in here.

Set-AzureVNetGatewayKey -VNetName YourVNETName -LocalNetworkSiteName TheOppositeLocalNet -SharedKey abc123xyz

Set-AzureVNetGatewayKey -TheOtherVNetName YourVNETName -LocalNetworkSiteName TheOtherLocalNet -SharedKey abc123xyz

So now I've got two connected networks in Azure, albeit empty of servers.  Next up... starting to build out my "imperfect" domain.

One more thing... if you want the offical "Azure" instructions for this, complete with images, go to http://msdn.microsoft.com/en-us/library/azure/dn690122.aspx.  

Modernizing Your Infrastructure with Hybrid Cloud - Week 3 Has Arrived!

This week's focus is on networking. It starts out with Kevin Remde and Keith Mayer continuing the series on “Modernizing Your Infrastructure with Hybrid Cloud” and in today’s episode they discuss various options for networking. Tune in as they go in depth on what options are available for hybrid cloud networking as they explore network connectivity and address concerns about speed, reliability and security.

• [2:46] What components are involved in Hybrid Cloud Networking?
• [5:30] What are some of the technical capabilities of Hybrid Cloud networking?
• [9:25]  Which VPN gateways are supported with Microsoft Azure?
• [11:28]  What are some of the common scenarios that customers are implementing for Hybrid Cloud networking?
• [15:40]  Besides Site-to-Site IPSec VPNs, are there any other connectivity options for Hybrid Cloud networking?
• [20:10] DEMO: Can you walk us through the basic steps for setting up a Hybrid Cloud network?

Check back at http://aka.ms/ModernCloud as the week progresses for some related blog posts:

• Tuesday: Step by Step: Setting a Static IP address on your Azure VM by Brian Lewis
• Wednesday: Building Microsoft Azure Virtual Networks by Matt Hester
• Thursday: Cross-premises connectivity with Site-to-Site VPN by Kevin Remde
• Friday: Cross-premises connectivity with ExpressRoute by Keith Mayer

Getting Comfortable with Azure Virtual Networks and DHCP

One of the great features of Azure IaaS is being able to extend your existing internal network to the cloud over a site-to-site VPN. You can bring your own IP addresses, but remember, the devil is always in the details. Or rather, knowledge is power!

Azure IaaS supports the standard private IP network ranges - 10.x, 172.x and 192.x – so you can easily give your Azure network a range that is comparable to the network range you are using in your data center.

However, Azure expects all guests to receive their IP address via DHCP. This took me a bit to grow comfortable with, as I spent years in smaller datacenters were each server was lovingly assigned an IP address that had been selected from a master spreadsheet. (Old school, I know!)  My favorite servers were given “choice” addresses with easy to remember numbers.

But networking is changing and we must change with it, so I’m becoming more comfortable with having less control over the particular address assigned to a given machine. This is key thinking when it comes to network virtualization.  By abstracting away some of the nuts and bolts of the network, the ability to be more flexible is introduced – which is good.  Someone I was talking to at a conference recently compared it to the adoption of IPv6.  IPv6 addresses are so long you would never statically assign them to a machine, that is all automated.

But, can I give my Azure VM a static address? Well, lets just say nothing is stopping you. You can go into your VM IP settings and do whatever you want.  But the risk of introducing a future IP address conflict is high and you will eventually lose the ability to connect to your VM.  Azure expects to get periodic DHCP renewal requests and when those stop the Azure fabric will remove that IP as active and stop forwarding traffic to it. There is no way to connect to the “console” of your Azure VM, so lost remote access to a machine due to an addressing issue will make for a very unhappy day.

Let’s say my internal network for my servers is 192.168.10.x/24.  I have two basic options for my Azure network:

1. Configure 192.168.10.x/24 in Azure, with a subnet for 192.168.10.128/25. I would need to make sure that everything in my physical datacenter was assigned IPs in the beginning half of the range, leaving 192.168.10.128 – 192.168.10.255 under Azure control. Azure also grabs a few other address out of the range for internal use, so I’d likely want to make sure I wasn’t using those in my physical network either. I think this option is messy and prone to errors. Also, I’m sure someone who does networking configuration all day will tell me it makes them cringe for more than one reason.
2. Create an different address range for Azure and make sure my internal switching gear is set up to route to it, like 192.168.20.x/24.  This would allow me to use a numbering scheme that makes sense within my organization, but also makes it easy to quickly identify resources that are internal vs. Azure based.

Keep in mind that any server in Azure will be assigned a persistent private IP address from your range with an infinite lease time, so if you are worried about domain controllers or other servers where the current “best practice” is to have a static assigned address, you can relax.  The only time a machine would loose it’s IP lease is when it’s in the “Stopped – Deallocated” state.

Finally, keeping with my “plan twice, create once” mantra, once your add a machine to an Azure network, you can only make limited changes - like adding new subnets or adjusting subnets that are not yet used.

For more information visit the Windows Azure Virtual Networks Overview.

Upcoming - TechDays Technology Guru Speakers!

PacITPros and LearnIt have teamed up to bring you an opportunity to learn more about the future of mobile and cloud technologies. Todd Lammle and Mark Minasi will be joining forces on April 5th from 1pm-6pm, covering some great topics.

Todd will cover Cisco's plans for taking wireless networks to a new level, Mark will cover the future of the cloud and then they will join forces to discuss IPv6 and the future of the related networking technologies.

When: Tuesday, April 5, 2011 (1pm - 6pm)
Where: Microsoft: San Francisco Office (835 Market St.)
Cost: $79 
Register at: http://techdays.org/2011/03/todd-lammle/

This speaker series takes place right before the regular April PacITPros meeting, so rest up for a jam packed afternoon and evening of tech talk.

Network Clean Up: Don’t Forget About Your LAN

“The network is slow.” 

Probably the worst complaint a Systems Administration team at any small to mid-sized office can get.  The end users often can’t pinpoint what “slow” is or when it happens, it’s seemingly random, or they report it after the fact when there is nothing to actively troubleshoot.

I am not a networking “guru” by stretch of the imagination. Like many small offices, our NetOps team consists of several people who may have some areas they enjoy or “specialize” in, but are mostly jack-of-all trades, ready to jump in and sort things out whenever things need attention.  I enjoy the variety, but sometimes the ongoing project list leaves you in a situation where certain areas of your “kingdom” are left until they cry out in pain.

The LAN in my office was one of those lost souls.  Sure, I’ve got my Network+ training, I used to have a valid CCNA certification, I know the difference between a hub and a switch and I can find enough of the settings in my HP and Cisco switches to assign IP addresses for management access and use some basic features.  And then my skill set drops off there – because small networks are often “set it and forget it”.   

We think about collecting SNMP logs and monitoring traffic and all that cool stuff and then reality sets in: I wish I had the time to spend installing and learning enough about those tools so they can be really useful when someone comes knocking with a “slowness” complaint.  But I don’t.  So finally I brought in someone who actually looks at networks every day. Someone who knows the settings on network gear and can look at how they work together.  Yes, I can pull out some crossover cables and make packets move from point A to point B, but I wanted some advice from someone who really understood how it all worked.

It was eye-opening.  My switches that linked the users workstations to our servers were all connected, but they were naturally oversubscribed without taking advantage of trunking any of the ports together to pass traffic to core switch over larger pipe. Spanning tree was configured incorrectly and not at turned on all on some switches.

The end result was that while my Layer 3 setup looked fine to me, the Layer 2 traffic was actually taking an extra hop through a switch that was accidentally acting as the spanning tree root, adding unnecessary delay.  After correcting that issue and ordering up some gig modules to add trunking up to our core switch, upload/download speeds of files to servers appears to be coming close the maximum available from the desktops.

Next up - increasing the speed of our internet connect by switching from frame relay to fiber from our ISP and subscribing to a bigger pipe on that end.