Hello and thank you for joining me again. Purse. I Berries, Microsoft Azure Administrator A Z 103 course
and We'll Carlson And this is Episode 40 Virtual Network peering
In today's episode, we're gonna talk about the two different types of virtual network peering available to us here in Azure,
and we're gonna understand the benefits of why we would even want to do a virtual network peer.
We'll talk about the concept of Gateway Transit and how that alleviate some of the limitations here of bean appearing.
And then we're also going to get into portal and configure our first virtual network peer in that environment.
But the first thing that we need to discuss our what types of virtual network peering are there, and the 1st 1 we're going to discuss today is going to be a global the Net Pierre
and a global Pierre is going to connect to virtual networks in different azure regions.
One thing to keep in mind here about a global Pierre is that you cannot pier between a public cloud region and a government cloud region, because the government cloud is separate and secure by design.
The other type of the net Peering is going to be a local or a regional v net Pierre, and that's going to connect two different virtual networks within the same region.
But what are the benefits here? A virtual network peering Well, the first benefit is gonna be privacy. Because all of the traffic between two virtual networks are going to be private. It's gonna be kept within the Microsoft backbone network. This is very similar to the way that a service in point functions as well.
There will be no public Internet, your gateways
that the traffic is gonna be traversing. The traffic stays within the Azure or Microsoft Backbone network.
There's also gonna be improved performance and doing it this way because we're riding across that Microsoft backbone.
It's gonna be a load lightened. See, high bandwidth connection between those resource is in those different virtual networks.
Whereas if we try to get from particularly a global pier one region to another, we're gonna be taking that traffic across the public Internet where we'll lose a whole lot of control over that traffic and the late in C and bend with will not likely be as good as we have available to us on the azure backbone.
The other benefit here is going to be increased connectivity. And what I mean by this is that a virtual network peer allows us to transfer data from multiple subscriptions across multiple regions.
And all of the resource is that air within each of the virtual networks are going to be able to communicate with the other. Resource is in the other virtual network.
Because of the design of the virtual network Peer,
the last benefit we have here is that a virtual network peer doesn't cause us any downtime when we set it up so you can set up the virtual network peering in the middle of production, ours and it's not gonna bring the network down to configure that pier.
Another concept that we need to discuss here as we discuss virtual network peering is the concept of Gateway Transit and Gateway Transit is gonna be important for us because virtual network peers by design, are non transitive. And what I mean by that is that if we have virtual network, a
connected to virtual network be
and in virtual network B is connected to virtual network. See
what happens when I want to transfer traffic from Vienna. A TV net, See? Will it work
well Because these air non transitive it will not work. I cannot Pier all of those networks one to the other and past traffic from a to see It just does not work. So Gateway Transit helps us get around this limitation. In our example, we would set up Gateway Transit on virtual network be
and then I could pass traffic from a through B and ultimately get to see
the last thing I want to discuss here, before we get our hands into portal are some of the limitations pertaining to global peering in particular.
As I mentioned, global peering is only available through public clouds to public clouds. You cannot appear to the government cloud.
We're also gonna have limitations to load balancer communications across global piers. So to virtual networks globally appeared. You cannot communicate to load balancers internally within those networks
global peering. You should not use Gateway Transit with either. So we lose that benefit and we are forced into global peering situation to live in a non transitive environment. And that puts some limitations on us potentially as well.
So how do we set up a global peer? We're gonna go ahead and jump into Azure here and go into our virtual networks.
I'm gonna go ahead and select on the I T. Resource Group Virtual Network
and then I'm gonna come down to Pier Ings.
We could see that we don't currently have any peering set up for this network, so I'm gonna add one
Peering. Naming is oftentimes a interesting thing to see here in Azure because of its complexity in the interest of simplicity. So I'm gonna create a nightie resource group to the security resource group here.
These both use resource manager. I don't need to know my resource idea, because I can go ahead and select it here. So in this case, we're gonna be peering from the I T resource Group Virtual Network
on into the security virtual network. And then we need to go ahead and name this for the other side. And now we have a few options here under configuration, so
we could set to allow this essentially to be a one way virtual network peer is to how the traffic originated by disabling one or possibly even both, of these options
So this option allows virtual network traffic from the I T. Resource Group being it to the security of the Net. And this is just the opposite rule. We're gonna leave both of those enabled. We could also enable forwarded traffic from the security be net. So traffic not originating from the security V net, but forwarded
through to the I t. Resource Rubina,
We're gonna go ahead though, and leave that disabled. If we wanted to allow Gateway Transit, we could check mark that here. But we'll see that azure squawks at us a little bit. And it's doing that because we do not have a network gateway set up in either one of these locations.
So to allow Gateway Transit, it would stand to reason that we need a gateway for the traffic to transit.
An azure is telling us that we need to leave this menu, go set up the gateway and then come back and then check mark this box
after we have all those setting set up exactly like we want them. All we have to do is select okay to initiate this pier
and we can see now that Pierre is set up and What we've essentially done is we've limited all traffic between these two virtual networks to going across the azure backbone.
We've increased our performance through to the low light and see high bandwidth connection on the Microsoft Azure backbone network,
and we've done so during the middle of the day during the middle of production workloads without any interruption whatsoever.
So again, in today's episode, we talked about Vienna appearing and how it's just a way to connect two totally separate virtual networks together. Remember, virtual networks are going to be those really large lumps of cider notation groups. So an azure those are gonna be the slash 16 groups.
They're not going to have traffic allowed between virtual networks by default,
but by setting up a virtual network peer, we've enabled that communication
you can peer across different subscriptions and regions. But remember, we cannot pier between public and government regions.
An interesting fact here with virtual network peering has to do again with the Gateway Transit item that we talked about today. And Gateway Transit is gonna be the function that allows us to set up some hub and spoke. Architecture's here within azure. So,
for example, if We wanted to set up multiple locations or multiple V nets
to communicate through one central V net, and then we peer that one V net on through to others. What we've allowed ourselves to do is to only have to set up one peering connection between the outside location and the hub location.
And ultimately the outside location can now communicate toe all of the spoke locations as well,
because we've set up in allowed that Gateway Transit.
We also went through the very straightforward process of setting appearing in the azure portal.
This was made a whole lot easier, relatively recently by Microsoft because we can set up both sides of the pier all at once. Previously, we would have to set up one side and then the other, so this was a welcome change
coming up next. You know, maybe this automated, two sided virtual network peering was a little too easy for us, and we like to really do things the hard way.
We're going to step through the process of setting up a virtual network to virtual network peering connection that doesn't use the process that we used. In today's episode.
There are a number of times when this might be necessary or warranted, particularly when we're trying to peer between the azure environment and are on Premise Network. Thanks so much for joining me today, and I'm looking forward to the next episode.