[MUSIC]. >> Hi, everyone. My name
is Reshmi Yandapalli, I'm the Principal Product
Manager in Azure networking, and today I'm going to
cover how to architect and simplify hybrid networking
with Azure Virtual WAN. We also have a key
announcement from one of our SD-WAN partners that
I'll also go over shortly. There's a ton of topics today, so if I'm going very
fast, I apologize. Feel free to check
out the documentation on the Azure Virtual WAN page. On the topics, we are going to first cover the Azure Virtual WAN overview, followed by the announcements. We'll touch on monitoring, then we'll look at some detailed
transit routing use cases, followed by an Integrated
Network Virtual Appliance demo, and then it will be a wrap. What is Azure Virtual WAN? Virtual WAN is basically a unified framework for
networking, security and routing. You can connect, you
can globally transit, you can secure it, you can do a multiple
routing functionalities, and we also now
provide the ability to deploy a Network Virtual Appliance
inside the Virtual WAN hubs. Let's go over each one of
those pillars one by one. On the connectivity size, you can connect in from branches
through site-to-site VPN, from remote users through
Point-to-Site VPN, and for private connectivity, you can connect through the
ExpressRoute mechanisms. For site-to-site VPN, we support all the standard protocols for IPSec, so we allow IP1, IP2. We have partnerships with multiple
VPN and SD-WANs, CPE providers. They have different solutions, but the automation that
kicks in is the automation of IPSec from the device
to the Azure VPN gateways. In terms of scale, we support
up to 1000 connections per hub. There is a hub in every region and each one of these connections
is an active-active deployment. You can pretty much do 1,000
branches in every region. In terms of aggregate capacity, we support up to 20 Gbps
for that VPN gateway. Some of the new
capabilities that we have recently introduced are
the FQDN based IPSec. This assumes that the VPN gateway can reach the DNS server
that's hosting the FQDN. There's also custom BGP or the APIPA support that
is also available. It is for the 4169254 address space, also take a look at that. For Point-to-Site VPN, we support
IKEv2 and the open VPN protocol. There is also an Azure
VPN client that you can download and you can connect
to Azure Virtual WAN, but you can also use
other clients like other IKEv2 or OpenVPN
clients that are out there. In terms of authentication, we support both cert based and RADIUS based authentication,
and in terms of scale, we support up to 10,000 users and will probably
be supporting more, as well as the aggregate
capacity of 20 Gbps. Recently, we also announced
the capability to add custom DNS and this is also
something that you can try out. In terms of ExpressRoute, there is support for encryption
with the Azure native VPN gateway. In terms of scale, we
support up to 20 Gbps, which is again aggregate throughput
of the ExpressRoute gateway, and the two new features that
we are very happy to announce are the ability to connect up to eight circuit
connections per region. So you have one hub per region, and you can connect
up to eight circuits, and you can also connect
Standard circuits now. Earlier you had the ability
to attach Premium circuits, now, we have opened it up, you can also attach standard
circuits to any hub. The key part of the announcement
is all the partnerships. There are three kinds of partners. In Virtual WAN, we have
partners that automate connectivity from the devices
into the Azure Virtual WAN VPN. We have partners such as the
MSBs like the telcos or the SIS, that are the system
integrators that provide end-to-end connectivity services with Virtual WAN and also partners, the recent addition, which
is basically the ability to provide network which in appliance
and deploy them inside the hub. Recent addition is Barracuda, and we are very pleased
to add Cisco to the mix. The two other partners
that I want to call out, are Aruba and open systems
that we have also added to the VPN SD-WAN device automation
on the left-hand side. On the right-hand side, Cisco is the latest edition for which we will have a
demo coming up shortly. Moving on, in terms of the second pillar of global
transit architecture, what this means is you
get a fully meshed hub. When you deploy a Virtual WAN hub and you have multiple
hubs in the Virtual WAN, all of those hubs are fully meshed and you can have
any-to-any connectivity. You can connect a branch, a remote user to Azure, but not just to Azure, you can actually interconnect. So you can interconnect an
ExpressRoute end point to a remote user or to a branch that
is behind and site-to-site VPN. You'll get all this
transit functionality, including VNet to VNet through
this fully meshed hub system, to the global transit architecture. The point aspect of
Virtual WAN is routing. Every hub has a router
and each router basically controls
all the routes with all the other gateways
in the Virtual WAN hub. This router also provides the
VNet to VNet transit capability, so the packet is
actually flowing through the router and the aggregate
capacity is 50 Gbps. Recently, we also announced the
capabilities of Custom routing, and I'm going to go over a lot of those capabilities when I call
the transit routing use cases. The fourth section of
Azure Virtual WAN, is a secure virtual hub, which is nothing but
a Virtual WAN hub. Again, a hub is per region, and it's a hub with a firewall in it. You can deploy multiple firewalls, you can use the Azure
firewall manager to create policies and apply across
multiple firewalls. You can work across regions,
subscriptions, deployments, you can secure Internet and private traffic where
private is VNet or branches. With the firewall manager, you have the additional
capabilities in Virtual WAN, to set up policies where
you can steer the traffic to security as a service
partner such as the Zscaler, iboss, and Check Point companies. The fifth part is the Integrated
Network Virtual Appliance. Here you have the ability
to deploy a marketplace based appliance inside
the Virtual WAN hub and what it gives you is an
integration with Virtual WAN. All the transit scenarios
are supported with the SDWAN appliances that
are deployed in here. You can connect an SD-WAN branch to, let's say, an ExpressRoute
endpoint and so on. There's also the additional
capability of SASE, which is Secure Access
Service Edge and this is basically a combo of SD-WAN and security through
the Azure Firewall. There's built-in resiliency, so
you don't have to deploy your VM, NVAs and manage them. This is just built-in and it
just comes with the package. There is no hazard routing, and what that means is
you don't have to deploy User Defined Routes or
UDRs to your NVA's. As soon as you put the NVA
inside the virtual hub, the routing kicks in. There is BGP between the NBA
and the virtual hub router, and it's just a one happy family
inside the hub of gateways. Last but not the least, the cool value prop is this Virtual Appliance
provider can actually keep their secret source or the proprietary IP because it
keeps all the features intact. In the SD-WAN world, these drive devices have to talk to their sister counterpart gateways. In order to do that, they basically have to communicate with
each other and they have this proprietary information
which gives them the ability to do all these
cool SD-WAN functionalities like path selection, application-based routing, different kinds of link
aggregation and so on, so that also is intact node. Basically, you get the
best of both worlds. You get the SD-WAN capability, you get the Azure native
capabilities of built-in resiliency, no hassle routing and you'll get to enjoy all the other feature since
you're in Azure Virtual WAN. Let's put it together, a lot
of our customers, they ask us, how is this different from
what we do today in Azure? It is a lot different and
let me walk you through it. when you want to do this your style, you can deploy an ExpressRoute and use a VPN or
site-to-site VPN or VNet, or a firewall. You can do that. In Virtual LAN, also you do it, but it just makes it easier for
you and who wouldn't want that. Basically, here is a hub
with a bunch of VNets, there's a hub with a firewall
in it, which is the right side. What you also see is a bunch of
branches and some V-nets here. Now, this is something you
can do outside but in vWAN, you basically have scale. So you have 20 Gbps aggregate
capacity for the site-to-site VPN, for the point-to-site VPN, which is a different gateway for ExpressRoute and if you wanted
to do VNet to VNet transit, you'll also get 50 Gbps. All of this scale is built-in. To add to that, the
unique capabilities are, with ExpressRoute you get encryption, the point-to-site, you'll get
the Global Traffic Manager, which means if the
user is a global user, they're in one country in one point and another country in another point, and if they've downloaded
the global config, then they can connect
to multiple hubs and be able to reach
the Azure resources. We talked about the site-to-site
connectivity automation partners, that's also unique to Virtual
WAN, and then of course, we also spoke about the
Firewall Manager Partners, which is a security as a service
partners like the Zscalers, the iboss, and Check Point. >> If you look at the flow, you have a fully meshed hub, you have different kinds of flows, and you can pretty much do any-to-any connectivity all of this
seamlessly in Virtual WAN. Now the routing capabilities
in Virtual WAN are unique. You get a Microsoft managed hub, it's a managed service, and this hub has a router, which provides you-all
these fully mesh and the transit capabilities with custom routing and the integrated
virtual appliance scenarios. What's the pricing? This is
a question we get often. The pricing principles
are also very simple, you just pay for what you use. It's not like you have
to pay an entire set of a price for functionality
that you may not be using. Basically, whatever you
use is what you pay. The concepts are very simple. Each one of the
Site-to-Site, ExpressRoute, and Point-to-Site capabilities, they have gateways and so you
pay for the throughput. Five hundred Mbps is one scale unit, so you pay for the scale unit. As you connect in users, you pay for the users
or the branches. Then for the firewall
and the virtual hub, there is a per hour
and per GB charge. If there's no traffic flowing
through it, there is no charge. In terms of hub-to-hub,
so if you have, let's say a data center in West US and if you had a
data center in Australia, you have to put together an entire
missionary to connect that up. In this, you don't have
to do any of that. All you have to do is we'll provision those hubs and fully meshed hubs just gives you those capabilities and the charges are
basically Egress only. If you're going from
West US to Australia, you're going to pay for the
traffic that leaves West US, there is no inbound charges anywhere. Let's say if you're going
from West US to Europe, you're going to be
a different charge. That's basically the philosophy of what you'll learn to
bring in this network, security and routing using the Microsoft global
backbone and that's key. Microsoft spots and the edges and the data centers are pretty
much everywhere on the planet. When an ISP connects any of the on-premise endpoints to
the closest Microsoft Edge, it drives the entire
Microsoft backbone. This cold-potato router are routing
and enabled in the system due to which your user gets to the
other end as fast as they can. In terms of monitoring, so you have all this capability, obviously you need to
be able to see it. Very pleased to announce
Monitoring Insights. You have a lovely button here, you can see the entire topology. We've also built in a bunch
of metrics like bandwidth, etc, also in there, so give it a check. Let's move on to the
transit routing use cases. This is where we will take a
detail look at all the scenarios. First let's understand the concepts. When you have S-to-S sites or Point-to-Site users
or ExpressRoutes, you basically connect them with a connection resource and they are on connection resource
that are connecting those endpoint to some gateway
inside the Virtual WAN hub. Similarly for VNets, you have
the virtual network connections. Now these connections,
they have to get to each other or
somewhere to some routes. In order for them to get to some destination or to be
able to access destination, they need to be associated
to a route table. Once they associate to a route table, they run the routes from
those route tables. Similarly, let's say all the
VNets and all these branches, they're associated to a
default route table and once they are associated
to a default route table, they need to be able to get or
be able to access something. This is where this connections they propagate routes to a route table. Let's say VNet1 is propagating its route to the default route table, this is how the default
route table gets their route or learns about
the routes dynamically. Here I have propagated the
routes from all my branches, which is the 192 address prefixes, and all my VNets, which is the 10 address prefixes
and we call on these routes, they all show up in the
default route table. If all these VNets and branches associate their connections
to this route table, this is how they get the
any-to-any connectivity. Moving on, there is a new
concept of custom route tables. VNets can associate to
custom route tables, branches cannot associate
to customer route tables, and when I say branches it means Site-to-Site, Point-to-Site,
and ExpressRoute. Let's say we have a custom
route table called RT_VNET. VNet1 is associated to it and it
also propagates its route to it, so the route gets
into the route table dynamically and let's just say
that VNet2 also propagates to it. Now what this means is all these VNets have propagated
the routes into this route table. For this example, let's
assume that the VNets, in order to get to these branches, they need to be able to get
to a virtual appliance, which is sitting in
that [inaudible] like, it's sitting inside this VNet3. In order to do that, you would actually go ahead and add a static route for
this branch prefixes. You can aggregate them, so I have aggregated it here. The next hub is this
VNet3 connection. But then in order for
the traffic to go from VNets to these branches
via this big dot, which is a virtual appliance, there needs to be somewhere
we need to enter this IP. This is where you are
actually going to add a next hub IP in that
connection resource. With a very simple way, you basically done this. Now let's look at it
how you isolate VNets. In this use case, you basically have two
VNets, some branches, and you want the branches to be
able to connect to each other, the branches to be
able to reach VNets, but the VNets needs to be isolated. Let's start with the
default route table. The branches, they associate to the default route table and
because we want to isolate VNets, we want to customize
how the traffic flow, so we will create a
custom route table. In this case, we have
created our two VNet, the VNets that are associated to it. Because the branches need
to be able to get to each other and they associate to
the default route table, they'll propagate, which
are these yellow lines, to the default route table. The branches, they need to be
also able to get to VNets, which means the VNets,
they need to be able to propagate their routes
into this route table. Also, the branches are required to be propagating
to the custom route table because the VNets are associated to the custom route table and if they
see the routes of the branches, that's how they know how
to get to the branches. Now with a very simple way of
association and propagation, you have simply isolated
the VNets and still kept the flows between
VNets and branches. The next use case is how to
route to a shared services VNet. Let's say we take the same setup. We have a shared services VNet and we have an end-time network behind it, and it's like a one-way street. Let's say VNet1 wants to get
to another network behind this VNet and it has
a shared services VN, and that's why I'm calling
this a shared services VNet. Branches, they need to be
able to get to each other. Branches need to be able to get to VNets: all the VNet1, 2, and 3s. But VNet1 and 2, they
need to be able to get to this network.
How do we do that? Branches, they will propagate to the default route table because they need to be
able to get to VNet3, VNet1 and 2, so all of these VNets will propagate
to this route table as well. The VNets, VNets1 and 2, they associate to the RT_VNET, which is the custom route table. Because they have to
get to the branches, they propagate to the
custom route table and because these VNets
need to get to VNet3, so VNet3 also propagates to
this custom route table. With this very simple
association propagation, we've essentially now steered traffic in a different way to a
shared services VNet. The next use case is the
custom isolation VNet. Here I have a setup where I have
a blue VNet and a pink VNet, and basically the concept is that I want the blue VNets to be
able to get to each other, the pinks to be able to get
to each other and the VNets, they should all be reachable
from all the branches. Now in order to do that, we would
have a default route table, and all of the branches, they will propagate to it because the branches need to be
able to get to each other, so they need to see the routes. Then for the custom route tables, because we want to isolate
the pink and the blue VNets, we would have custom route
tables, the blue VNet, and there's a custom route
table for the pink VNet. This is where I want to
introduce the concept of labels. Labels are logical
grouping of route tables. If you wanted to have routes
or multiple route tables, then you would propagate
to a label and this would just propagate to all the route tables
with those labels. In this case, all of the
blue VNets are associated to the blue custom route table and the pink VNet is associated
to the pink route table. The branches, they need
to be able to get to the blues and the pink VNets they need to be able to
get to the branches. Obviously, the branches have to propagate to the blue and
the pink route table. Similarly, because the blues have to get to each other,
so all of the blues, they are going to be propagating to the custom route table blue and the pinks are going to be all propagating to the
custom route table pink. With this, the last
step would be to make sure that the branches are able
to get to this blue and pinks, so that's why all of this
blue and pink VNets, they should be propagating to the default route
table because that's what the branches are associated to. The next use case is where
we take a closer look at the routing configuration
so that any-to-any, the default route table gets on the routes of all
these connections, the VNet connection,
the branch connections. This is what gives you any-to-any. But actually what's happening is the routing configuration of this
VNet and the branch connections, they are getting the association
and the propagation sent to the right route tables due to which they're able to support these flows. The next one, we mix it up a bit, basically we take the
previous use case where we have a default any-to-any, but we have a firewall in the mix. If you use a Firewall Manager UI, the routing is taken care of, it is abstracted for you. The user goes and picks an option
to secure Internet traffic, which is where Azure
becomes your Internet edge, so you can do VNet to Internet
via the Azure Firewall, branch to Internet via
the Azure Firewall. For the private traffic, let's say you decide to go direct, all you have to do is in the
Azure Firewall manager UI, secure Internet traffic
and the routing kicks in, which basically is a
static route of 0.0 with next hub Azure Firewall in the
default route table, very simple. The next use case is one of
the most common in use cases, where customers want to be able to route traffic through
virtual appliances. Here I have a pink dot
in both these VNets, VNet 2 and VNet 4, and this is NVA or network
virtual appliance. Let's say you have an
entire network behind it, and you want to be able
to do VNet-to-VNet. In order to do VNet-to-VNet, this is the topology that is
supported in Virtual WAN. Currently we do not support
the ability for going from VNet-to-VNet through
another virtual appliance which is sitting in a third VNet, but that's in our roadmap. Let's say you have this
network and you have a default route table setup with all the branches and the VNet
spokes propagating to it. In here, the steps are; you would first define the UDRs or the routes from this indirect
VNets to the NVA VNet. The second step would be
to ensure that there is a static route to get
to the NVA connections, and those you would add to
the default route table. Then the third step, would be
to make sure that you specify the NVA IP in that VNet connection. This is how you get routing through
the NVAs and you can basically mix and match it up with the other use cases to
give you all the flows. In this case you get the V2 reflows, you can get across
hubs within the hub, you can get branch to VNet
across hub within the hub, and you can also get the
Internet cut out flows in here. Let's take a closer
look at the portal. In the portal, every hub
has a routing section, and inside the routing section you can basically create a route table. You can setup the static
routes in the Basic tab, you can setup labels, you can associate the connections, so when you pick connections here, all you're doing is
you're associating those connections to
this route table. You can propagate the
routes from connections, so when you are selecting let's say your VNet connection
in this drop-down, what you're saying
is propagate routes from the VNet connection
to this route table. Also, you can look at the
effective routes of a route table, and here as you can see
you can see the next hub, you can see origin from where
this route was learned, and you have a lot of
information through which you can do some
troubleshooting. To summarize, branches are all collectively terms for
site-to-site point to set an ExpressRoute connection, they associate to default
route table and they propagate to the same
set of route tables. Let's say branch A
propagates to route table A and branch B also will
propagate to the route table A. Similarly for custom route tables, you have certain abilities, custom route tables
they apply to VNets, you can setup static routes, you can view effective routes. The last concept here is if you
did not want to propagate routes, you can propagate to something
called a non-route table, which basically is saying
that the connection does not want to propagate the
route to any route table. The next section is basically the
integrated virtual appliance. Very pleased to announce the Cisco Viptela NVA now
available in Virtual Hub. It supports transit, as I mentioned before there's the
entire SASE framework, there's built-in resiliency,
there's no hassle routing. Let's hear from Cisco folks. >> This video describes Cisco SD-WAN and Microsoft Virtual
WAN integration. I'm Nikolai Pitaev, Senior TME, SD-WAN solution team.
Let's get started. On the left side you
see SD-WAN branch with multiple teams x sync
applications in a data center. In the last years, you see applications moving from
On-prem data center to Azure because of multiple reasons like cost saving and
Agile development. The key question now
is how to connect SD-WAN with Azure in secure, reliable, and automated way. Cisco Cloud OnRamp solution for IaaS integrates CSR 1000V
with virtual WAN. Traditional solution
requires two different UIs, vManage for SD-WAN and Azure Portal
for Virtual WAN configuration. After 17.4 IOS XE SD-WAN release, the whole interconnection
workflow will be done in single UI in vManage. Before Cisco SD-WAN and
Azure vWAN integration, the solution used gateway
VNet in the middle with two CSRs connected to host VNets
via standard IPSec tunnels. We used BGP on top of it and
OMP to BGP redistribution. The new Cloud OnRamp for IaaS vWAN integration dramatically
simplifies the network design, introducing two CSRs in the middle, connecting directly to vWAN and
providing connectivity between SD-WAN network on the left side and host VNets Cloud infrastructure
on the right side. This is how the whole workflow
looks like in the vManage. First of all, you will need to do some basic configuration
like providing your Azure credentials and generic
configuration like CSR version. Then you will be discovering
and tagging host VNETs, then setting up Cloud Gateway and mapping VNets to SD-WAN service VPNs. Let us see it in a short demo. First of all, we will
select Microsoft Azure and provide some basic
details as account name, client ID, secret
key, and description. Once we have the account saved, then we can spin up
Cloud Gateways to CSRs. We will provide some basic
information like name, description, we will select the account to
be used and two CSR UUIDs, basically two CSR licenses. Once we hit "Save", vManage will go ahead
and bring up both CSRs on Azure and integrate this
with Microsoft Virtual WAN, as you see here both
CSRs are up and running. Next step is to tag two host VNets, I'll be using just
a demo tag for both of host VNets and that
will be used later on in the last step for interconnection between host
VNets and SD-WAN infrastructure. Once I define my tags, then I can execute my last
step which is mapping between Azure VNets and SD-WAN VPN. That's it, we successfully connected Cisco SD-WAN and
Azure infrastructure. Let me conclude with the
following statement. You have Cisco SD-WAN with different transports,
MPLS, Internet, LTE, data centers and branches connected, and now you've got public Cloud, Microsoft Azure with
VMs containers on it. The question is; how to
interconnect Cisco SD-WAN and Microsoft Azure in secure
automated reliable way. Between SD-WAN and Azure, there's a bridge,
Cloud OnRamp for IaaS. >> All right, that gets us to the end of our presentation,
so let's summarize. Virtual WAN provides you unified
framework for connecting, routing, and securing
to the Azure Firewall. It's deployed in a hub-and-spoke architecture so that you
can architect your network, rearchitect it, scale it or simply just simplify it. Thank
you for watching. [MUSIC]
