Azure Networking: Innovative Features and Multi-VNet Topologies

Azure Multi-VNET
Architectures and Topologies
Marius Zaharia
03/12/2016

1 Business scenario
4
Scripting and automation
5
Technical solution
Demo
2 Networking services
Architecture and topologies3
6

Cellenza : des experts reconnus
dans le Cloud, DevOps, Intégration, …
10
Azure
C#
ALM
SQL Server
Windows Client
1 4
Des publications :
• Livres blancs (Cell’Insights)
• http://www.cellenza.com/cellinsights
• Articles dans Programmez!
• Blog Cellenza
• http://blog.cellenza.com
• Organisation de TechEvent
• Speakers lors de conférences Microsoft
• TechDays, Azure Camp, …

Marius Zaharia
Senior Cloud Architect
Efficient
& Visionary
“Manage
Teams Architectures
Understand
ComplexInternational
+ Mon expérience
+ Mon expertise
IDÉATION CONCEPTION WIREFRAMES
Marius apporte aux clients son expertise et expérience dans l’analyse, conception et
développement d’applications complexes d’entreprise et d’intégration applicative et
d’infrastructure basées principalement sur des technologies Microsoft.
Son profile lui permet d’aborder les architectures Cloud Computing, SOA, hybridation
et urbanisation des SI dans des missions polyvalentes solution/développement et IT
pro.
Marius travaille également dans les activités de Business Development et avant-vente
de Cellenza, étant P-SELLER Azure (en partenariat avec Microsoft).
Dans le monde communautaire, Marius est impliqué dans l’organisation d’AZUG FR –
Azure User Group France et des conférences comme Global Azure Bootcamp, MS
Cloud Summit, des meetups réguliers avec la communauté Azure etc.
DevOps
P-SELLER
Azure

Introduction
 “Azure VNET to VNET VPN, across regions and data centers: not so
complicated”
 Connection between multiple Azure Virtual Networks, in particular a VNET-
to-VNET-to-VNET relationship
 All based on PowerShell scripting and classic deployment in Azure
 Azure moving to ARM deployment model and the new (modern)
portal
 Migration of existing features to ARM
 Migration to the new portal
 New innovative features

Business Case
 Multiple environments communicating with each other
 In the same Azure region
 Across 2 regions
 With the on-premises environments
 Implement network connectivity between the environments
 CONCRETE EXEMPLE: SQL Server AlwaysOn distributed cluster
 1 master replica in Dublin
 1 secondary replica (synchronous) in Dublin
 1 secondary replica (asynchronous) in Amsterdam

Azure Networks
 Virtual Network: logical isolation of the Azure cloud dedicated to your subscription
 Subnet: range of IP addresses in the VNet, divided for organization and security
 Public IP: allow Azure resources to communicate with Internet and Azure public-facing services
 Network Interface Card: interconnection between a Virtual Machine (VM) and the underlying
software network
 VPN Gateway: Azure service used to send network traffic between Azure virtual networks and
other locations
 ExpressRoute: lets you extend your on-premises networks into the Microsoft cloud over a
dedicated private connection facilitated by a connectivity provider
 Network Security Group: allow you to control inbound and outbound access to network
interfaces, VMs, and subnets, based on a list of access control list (ACL)
 User Defined Routes: specify the next hop for packets flowing to a specific subnet
 IP Forwarding: Azure setting for a VM allowing it to receive traffic addressed to other
destinations
 Virtual Appliance: VM in your VNet that runs a software based appliance function, such as
firewall, WAN optimization, or intrusion detection

Azure Networking: VNET Peering
 VNet peering: a mechanism that connects two VNets in the same region through the Azure backbone network
 Once peered, the two virtual networks appear as one for all connectivity purposes
 Low-latency, high-bandwidth connection
 Can connect ARM-to-ARM Vnet, or ARM-to-Classic
 Requirements and key aspects
 in the same Azure region.
 non-overlapping IP address spaces.
 no derived transitive relationship
 Peering two different subscriptions possible, but under conditions*
 Peering between ARM and Classic, under conditions*
 No Classic to Classic
 Networking bandwidth cap based on VM size still applies

Azure Networking: Load Balancer
Azure Load Balancer
 Layer 4 (TCP, UDP)
 Services
 Load balancing
 Internet-facing
 Internal
 Traffic forwarding (NAT)
 Features
 Load balancer: hash-based distrib.
 Port forwarding
 Automatic configuration
 Service health monitoring
 Source NAT (SNAT)
 multiple load-balanced IP addresses for VMs
 Probes
 TCP
 HTTP/S
 Guest agent (for PaaS only)

Azure networking: Traffic Manager
 Controls the distribution of user
traffic for service endpoints in
different datacenters
 uses DNS to direct client requests
 Features
 Traffic-routing methods
 Priority
 Weighted
 Performance
 Nested Traffic Manager profiles
 Monitoring of endpoint health
 Automatic failover

Azure Networking: Application Gateway
 Application Gateway
 Application Delivery Controller (ADC)
as a service
 layer 7 load balancing
 Features
 Web Application Firewall (Preview)
 HTTP load balancing
 Cookie-based session affinity
 SSL offload; end to end SSL
 URL-based content routing
 Multi-site routing (up to 20)
 Websocket support
 Health monitoring
 Advanced diagnostics

Load Balancer differences
 Azure Load Balancer works at the transport layer (Layer 4 in the OSI
network reference stack). It provides network-level distribution of
traffic across instances of an application running in the same Azure
data center.
 Application Gateway works at the application layer (Layer 7 in the
OSI network reference stack). It acts as a reverse-proxy service,
terminating the client connection and forwarding requests to back-
end endpoints.
 Traffic Manager works at the DNS level. It uses DNS responses to
direct end-user traffic to globally distributed endpoints. Clients then
connect to those endpoints directly.

Azure Networking - Cross-Premises Connections
Cross-premises connection options :
 Site-to-Site – VPN connection over IPsec (IKE v1 and IKE v2). This type of
connection requires a VPN physical or virtual (RRAS) device.
 Point-to-Site – VPN connection over SSTP (Secure Socket Tunneling
Protocol). This connection does not require a VPN device.
 VNet-to-VNet – This type of connection is the same as a Site-to-Site
configuration. VNet to VNet is a VPN connection over IPsec (IKE v1 and IKE
v2). It does not require a VPN device.
 Multi-Site – This is a variation of a Site-to-Site configuration that allows you
to connect multiple on-premises sites to a virtual network.
 ExpressRoute – ExpressRoute is a direct connection to Azure from your
WAN, not over the public Internet. See the ExpressRoute Technical
Overview and the ExpressRoute FAQ for more information.

On-premises
NetworkVNET 1
Simple Hybrid Topology (point-to-point)
VPN IPSec
G
W
G
W
VNET – S2S IPSec VPN
to On-premises
Site-to-Site – VPN
connection over IPsec
(IKE v1 and IKE v2).
This type of connection
requires a VPN physical
or virtual (RRAS) device.

On-premises
NetworkVNET 1
Simple Hybrid Topology (point-to-point)
VPN IPSec
G
W
G
WExpressRoute
VNET – S2S IPSec VPN
with on-premises
VNET – ExpressRoute
With on-premises
Direct connection to
Azure from your WAN,
not over the public
Internet.

VNET 2VNET 1
Simple Cloud-Only Topology
VPN IPSec
G
W
G
W
VNet-to-VNet –
is the same as a Site-to-
Site configuration.
It’s a VPN connection
over IPsec (IKE v1 and
IKE v2). It does not
require a VPN device.
(executed over
MS Backbone transport
layer)

VNET 2VNET 1
G
W
G
WExpressRoute
VNet-to-VNet –
is the same as a Site-to-
Site configuration.
It’s a VPN connection
over IPsec (IKE v1 and
IKE v2). It does not
require a VPN device.
(executed over
MS Backbone transport
layer)

VNET 2VNET 1
Peering
VNET – peering
to VNET
Transport
Backbone intra-
datacenter

VNET 2
Complex Topologies
VNET 4 VNET 5
VNET 3
VNET 1
« HUB & SPOKE »
• Configure simple
bidirectional
communications between
the master VNET end the
satellite VNETs.
• Any of the direct
connectivity options
described before (IPSec VPN,
ExpressRoute if the case, or
Peering) can be used here.

VNET 2
Complex Topologies
VNET 3
VNET 1
« DAISY CHAIN »
• Transitivity: the VNET 1 will
communicate with the VNET 3 via
specific routing configuration set
up in the VNET 2
• advantage : getting profit of a
connection already established
for the usage of another VNET
• inconvenient: if the VNET 2 (or its
gateway) loses its connectivity, it
will also affect the connectivity
between the lateral VNETs.

VNET 1
Complex Topologies
VNET 2 VNET 3
VNET 4
« (FULL) MESH »
• Let you master the direct
connectivity between various
VNETs, without having
dependencies on intermediate
VNETs or their gateways
• much more work to getting it
done
• it’s up to you to decide which
VNET communicate with which
one
Do it in Azure?
• VPN gateways & bidirectional
connections
• VNET peerings

TECHNICAL SOLUTION
for our
BUSINESS CASE

Technical Solution
The solution is composed of 3 main segments:
1. VNET Peering between VNET2 and VNET1 (both VNETs being in the
same region)
2. Site-to-Site VPN connection between VNET1 (Dublin) and VNET3
(Amsterdam), with VPN Gateways deployed in both VNETs
3. Transitivity for the VNET2 to VNET3 through the VPN Gateway 1.
This connection transitivity will be configured in the VNET Peering
settings directly

Technical Solution - Diagram
VNET 3VNET 1
VPN IPSec
G
W
G
W
VNET 2
DC
DUBLIN
DC
AMSTERDAM
Master
(Primary)
Replica
Secondary
Replica 1
Secondary
Replica 2VNET 4

Thank you !
Go to the blogs :
- blog.lecampusazure.net (EN)
- blog.cellenza.com (FR)
The sources are on github.com/lecampusazure

Azure Networking: Innovative Features and Multi-VNet Topologies

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Azure Networking: Innovative Features and Multi-VNet Topologies (20)

More from Marius Zaharia (13)

Recently uploaded (20)

Azure Networking: Innovative Features and Multi-VNet Topologies

Editor's Notes