Welcome to Azure IaaS Day.
My name is Charley Wen,
I'm a Program Manager on Azure Networking team.
Today, I will be talking about hybrid networking.
I'll give you an update on new features, new services,
and also talk about some best practices.
These are the services I'll cover.
Some of services are fairly new.
I'll spend a bit more time on them.
Now, we'll begin with VPN.
Now, Azure VPN has two products.
One is called a Point-to-Site VPN.
It connects you or your device to Azure.
Another service product is called Site-to-Site VPN.
Site-to-Site VPN connects your branch office to Azure.
Point-to-Site VPN is also called a remote access VPN.
It requires a VPN client
to be installed on your user's machine.
What's new here is we have a new VPN client for macOS.
You can download this app from Apple Store.
This client is built on top of an OpenVPN protocol.
The OpenVPN protocol supports many features,
such as Azure AD authentication.
Now for advanced user,
this software also has some troubleshooting wizard.
You can also use this software
to customize your DNS and your routing policies.
Now we move from the client to the server.
The new Point-to-Site VPN server
supports multiple authentication types on a single gateway.
So now this expands the user base,
because users of many organizations are on different OS;
Linux, Windows, macOS.
Each of these OS has its own
default authentication software.
Some is based on certificate, some is based on Azure AD.
With this feature, you only need to deploy one gateway
for all of your users,
rather than one gateway for each type of OS.
So now let's look at the Site-to-Site VPN.
Site-to-Site VPN connects your branch office to Azure.
An important feature we introduced is NAT,
Network Address Translation,
A Network Address Translation, NAT,
is designed to address the Azure's overlapping problem
between your network and Azure.
NAT is a fairly old or mature technology.
I won't deep dive into that.
What I do want to call out is
our NAT has two configuration options.
One is static NAT and the other is dynamic NAT.
Which type to use depends
on your application's communication pattern.
If your application
has this server-to-server communication pattern,
meaning that if VMs in your on-prem and the VMs in Azure
both initiate connection to the other side,
then you need a static NAT.
However, if your applications follow these server
and a client communication pattern,
you only need dynamic NAT.
Now for more details, you can look at this document,
aka.ms/vpnnat.
Besides NAT, we also have some other new features.
If you're on VPN gateway 4 and 5,
you can config up to 100 tunnels.
You can also configure multiple BGP tunnels
Using APIPA address.
APIPA address is required
by some other cloud service providers.
So with this feature, if you're a user,
if you have a deployment on multiple clouds,
you can now set up multiple tunnels.
Overall, we have improved the monitoring
and the diagnostics for VPN.
If you log on to Azure Portal,
you will see a BGP Dashboard.
You can find all the active BGP sessions there.
You can see the routes advertised
and received by your VPN gateway.
As an advanced user,
you can also do packet capture on the portal.
You can also manage IPsec tunnel independently
for each IPsec and you can manage them independently.
So that's VPN.
Now I want to change the gear
and talk about ExpressRoute.
In contrast with VPN
which traverses over the public internet,
ExpressRoute is a private connection.
Once you have an ExpressRoute connection,
you have access to all Azure services.
You can also connect to Office 365 and Dynamics 365.
Now, ExpressRoute is a global service,
as you can see on this map.
We have a presence in six continents in 30 plus countries,
and we continue to expand our ExpressRoute paths
to new countries, new markets.
I want to spend some time
to talk about new ExpressRoute capabilities.
Now, for the past year also,
we've been focusing on IPv6, security, performance,
and manageability.
IPv6 is fairly straightforward.
IPv6 is designed
to solve the IPv4 exhaustion problem.
But we also found that IPv6 is enabling new scenarios,
scenarios in 5G mobile and IoT space and we are hopeful
that the option will pick up over time.
Now, on security, we are the first call service provider
that introduced the MACsec.
We have added new features, like new ciphers
and new capabilities to support the old hardware.
So now if you're on some old hardware,
there's a good chance you can also enable MACsec
on your ExpressRoute connections.
FastPath is a performance feature.
FastPath enables your on-prem traffic to Azure traffic
to bypass the ER gateway.
We've been supporting this feature for some time.
What's new here is we added the new scenarios,
like VNet Peering and the Private Link.
Last but not least, we are very happy to announce
the support of a BGP community on VNet.
So now if you have a hub-and-spoke design typology,
you can tag your hub VNet and your spoke VNet
with different BGP COMMUNITY strings.
And when you receive these routes in your on-prem,
you can apply different routing policies,
and even security policies to those routes.
So we hope this feature will help simplify
your network design and management.
Now, I want to talk about new scenarios and new designs.
The first one I want to talk about is Azure Virtual Desktop,
formerly known as Windows Virtual Desktop.
A common question we receive is
does ExpressRoute support Azure Virtual Desktop?
Now, before we answer that question, let's take a look
at the AVD Azure Virtual Desktop architecture.
AVD is built on top of Azure PaaS services.
At the center of this architecture
is RD Gateway, Remote Desktop Gateway.
Now, Remote Desktop Gateway is a multi-tenant service.
It facilitates communication between the client and the VMs.
The communication happening over the public internet
because of RD Gateway has the public IPs.
What's new here is the AVD team introduced a new feature
called the Shortpath.
With the Shortpath, AVD will orchestrate a direct connection
between the client and the target machines
using the VM's private IP address.
So if these virtual machines
are connected to your users over a private connection,
and these can reach to the private IPs,
then the client will send the old AVD traffic
ExpressRoute on this private connection.
So to the question, yes,
you can now enable AVD on top of ExpressRoute.
The second design I want to talk about
is related to the ExpressRoute Direct
and especially to Circuit.
But first, let's look at what's the concept
of ExpressRoute Direct ExpressRoute Circuit.
Now, ExpressRoute Direct is a connectivity model.
You can buy a pair of a 10G
or a pair of a 100G ports to connect to us directly.
Now, once you set up this physical connections,
you can create ExpressRoute Circuit,
which is a logical connection
on top of these physical connections.
Let's use an example.
So let's say you are connected to us in London.
You have three choices for your circuit.
Now, let's say you create a local circuit.
If you have a local circuit,
you can then connect from London to UK South.
UK South is a region next to London.
You have extend out of the circuit
and then you can connect to all Azure regions in Europe.
Now, if you have a premium circuit
and then you can connect to any Azure region in the world,
in the U.S., in Japan, in Australia.
So basically, the Circuit SKU defines the scope of access.
You can then decide which one to use
based on your need and based on application design.
Now on top of that, we have seen this design.
This is a very common design.
This design actually also follows
our best practice guidance.
So this customer connects to us at the two peering locations
in Amsterdam and in Dublin.
They also put the VMs in two regions,
West Europe and North Europe.
Each circuit is connected to both region.
As you can see, it's a Bowtie topology
that we call the Bowtie topology.
So this design gives you reachability and resiliency.
But you can actually make a slight modification
to the design.
Instead of a one standard circuit,
you can actually create a local circuit
at each peering location.
So you can create a local circuit
from Amsterdam to West Europe,
and a local circuit to North Europe.
So the benefit of a local circuit is
it doesn't charge your data transfer.
So if your application have a lot of data to send
from Azure to your on-prem,
you may find that this design will save you money.
That was ExpressRoute.
So now, let's look at this further service,
routing preference.
Now, as the name of the service suggests,
the service is all about choice,
so you can choose between Microsoft network and internet.
Now, if you choose Microsoft,
you basically hand off your traffic
to an internet POP near you
will pick up your traffic and then use our backbone
to connect you to your Azure region.
That's what we call cold potato routing.
Now, you can also choose internet.
In that case, your internet service provider
will carry your traffic all the way to a path
near your Azure region.
And in the return path,
we'll also hand off the traffic there,
your ISP or internet then will take the traffic,
send it back to you.
That's what we call hot potato routing.
The hot potato routing can give you a cost benefit.
So if you have a lot of data to send,
you may want to consider hot potato routing
to save you money.
The question is how to configure this feature.
Essentially, very straightforward.
When you are creating a public IP,
you will see this choice, routing preference.
You can choose Microsoft network or internet.
Once you create this IP,
then you can assign it to a VM or storage account.
And then we will take care of the rest.
We'll take care of routing
and where to hand off the traffic
to your internet service provider.
So I have an example for this service,
and I'll talk about that in a minute.
The last service I want to talk about is Azure Route Server.
We launched the service in September.
It's a fairly new service.
Azure Route Server enables dynamic routing
between your NVA and your VNet.
So Route Server will get all the routes in your VNet
and send those routes to the NVA.
And the NVA in return,
can send the routes in their own routing table
to the Route Server.
Now, the Route Server will program
the VM routes to the VMs routing table.
The Route Serve is a managed service.
Now, one example of that
is if you put a Route Server in AZ region,
we'll put the VMs in the Route Server
in different AZs,
so you'll have a zone redundancy by default.
You don't have to configure.
You don't have to worry about that.
The Route Server is also control plane only service,
meaning that it does not forward data,
so all data forwarding will be happening
between your NVA and your VMs,
so your Route Server will never be a bottleneck.
The Route Server relies on BGP
as a standard routing protocol,
so you can play with the BGP attributes
to set up your NVAs to be active-active, or active-passive.
Now, for more information, please go to aka.ms/routeserver.
So I want to talk about some designs and scenarios
enabled by this new service.
The first one I want to talk about is ER/VPN transit.
Now, imagine you have a VPN gateway
and ExpressRoute gateway in one VNet
and they are connected to two different on-prems.
Now without the Route Server,
the two on-prems don't talk to each other.
Now, if you add the Route Server to the same VNet,
then the Route Server will establish BGP peering
with the gateways automatically.
And then you can enable route exchange.
There's a flag we need to enable.
Once you enable that flag, the route exchange,
then your VPN on-prem and your ExpressRoute on-prem
can talk to each other.
So thus we've been seeing customers
taking advantage of this feature.
So the next design involves routing preference.
Now remember, routing preference enables you to choose
between Microsoft network and internet.
Now with the Route Server,
you can actually connect both networks to your service.
Again, to give you an example.
So now let's say you are in Japan.
You connect to us at the ExpressRoute path in Tokyo,
and then we use our backbone to carry your traffic
to the U.S., and in this example, your VMs are in West U.S.
Now you can add a SD-WAN device to the same VNet.
Now, in this case,
instead of assigning a Microsoft IP to this SD-WAN device,
you can assign an internal routing IP to this SD-WAN device.
Now, let's say something happens in our network,
you lose the connectivity on the ExpressRoute connection.
Now, the Route Server with detect the problem.
The Route Server will fail
to hand off the traffic to this SD-WAN device.
Now remember, you assigned the internal IP
to the SD-WAN device.
The SD-WAN device will follow the hot potato routing.
So we'll basically hand off the traffic to an internet POP
near this region, which is Silicon Valley, in this example.
And then your internet or your internet service provider
will pick up at the traffic in Silicon Valley
and using their backbone
to carry the traffic to you in Japan.
So with this design,
you have an extra level of resiliency.
So the last design I want to talk about is Anycast.
So Anycast is not supported natively on Azure,
but with the Route Server it's possible now.
So let's, again, use an example.
So you have a number of servers
hosting your games and your users are all over the world.
So what you can do is you can put these game machines
behind a load balancer.
And then your load balancer can advertise
its own IP to the Route Server.
The Route Server will inject that IP
to your network through ExpressRoute.
And then what you do is you replicate this design
in other Azure regions using the same IPs.
So then in your network, you receive the same N IP,
which is Anycast IP from multiple locations,
and then you do your Anycast configuration.
Now, if a user tries to connect to this IP,
and depending on their location,
and you will direct their traffic
to the nearby Azure region and there you have
this Anycast design for your applications.
So that concludes my presentation.
I want to thank you for your time.
If you have any questions, please reach out to me.