Azure : Is it possible to do a cross subscription network peering?

Introduction

Today I received a question if it was possible to do a cross subscription peering… with one big catch; that it was between the subscription of a service provider and their customer(s). So let’s see what is possible?

 

Update : Oct 2018

At Ignite 2018 it was announced that peering will also be able to work cross tenants.

 

Public Preview Announcement

When we take a look at the announcement, we see the following statement ;

Note that you can peer virtual networks that exist in two different subscriptions as long as a privileged user of both subscriptions authorizes the peering and the subscriptions are associated with the same Active Directory tenant.

Now the from this we can already see that it is possible to doe cross subscription peering. As a requirement, we need a user that is authorized on both subscriptions AND that the subscriptions are associated with the same AAD tenant.

The latter caused a bit of confusion on the requestor part, where the statement was made if a B2B invite would solve this issue. The answer to this is “no”. The B2B invite lies on the authorized user part, and is not related to the tenant of the subscription!

 

Let’s try it out?!?

Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.

Azure : What the BGP is going on there?

Introduction

Something I had on my to-do for a while now was to post a proof-of-concept to you guys/gals about what BGP on Azure can entail… Now some of you might go; “BGP? What the hell is that?!?”. Check out the following “CBT Micro Nugget” as it is a nice high level description of what BGP is.

 

So why should you care? BGP can offer you a way to deal with advanced routing paths. This in turn can deliver resiliency to your business.

 

Proof-of-Concept Design

For today, we’ll be building the following setup ; 

This will consist of the following components ;

• Four virtual networks ; VNET001, VNET002, VNET003 & VNET004
• Each VNET will have its own VPN Gateway. We’ll enable BGP on the VPN Gateway and give it its own (unique for, and private to, our deployment) ASN & peering address. The VPN Gateway will be set to “RouteBased”-routing and we’ll use a “Standard” SKU.
• Each VPN Gateway will have two connections towards the “previous” and “next” gateway. The keys per connection pair will be set to the same key and we’ll also enable BGP on the connection.
• We’ll deploy two systems into this PoC setup
  • System001 will reside in VNET001
  • System004 will reside in VNET004

 

To test our setup, we’ll execute the following scenario ;

• Connect from system001 to system004 whilst our ring is complete =>the green path will be followed
• Connect from system001 to system004 whilst having deleted the connections between VPNGW001 & VPNGW004 => the yellow path will be followed