 Hi, welcome to another episode of Azure Unblogged. Today, I'm really excited to talk about AVS landing zones and some of the networking topologies that are available within it. So stay tuned. I have two special guests here to talk about their experience. Sabine, nice to have you on. Hi, I'm Mahesh. How's it going? I'm Sabine Blair. I'm with the customer of Global Architecture and Engineering Team, CAE, say that really fast. What I do is I have a customer facing an engineering role. So really helping customers with their designs and architectures to end-to-end patterns using the VMware and Azure solution. That's great. Mahesh? Yeah. Thank you, Amy and Sabine. It's great to be with you. My name is Mahesh. I'm a Cloud Solution Architect. I work with the global partners and then help them successful on the AVS engagements. Besides work, I do love my team. So don't mind if I drink my tea during this presentation. All good. I love tea too. Good. Let's talk something about AVS. All right. Let's do it. Sabine, so I'm assuming with networking, there's a bunch of building blocks. What from your perspective are those building blocks? Sure. Well, first and foremost, this really comes down to what the customers are trying to do. They're coming in with many different scenarios. They could be coming to AVS to extend their on-premise data center or they could be coming into migrate workloads. But either way, this solution really helps them to facilitate their hyper-Cloud desires and really put together an end-to-end footprint. That's exactly what a landing zone is, depending on where you land, can really facilitate how your different architectures look. One of the key components that you get is this Azure Dedicated Express Route. This is a 10-gig circuit that comes as soon as you spin up your AVS solution. This is not an additional cost. This is not an additional thing you have to add from a third-party vendor. This is something that you're getting directly from Azure. That comes with a great benefit. You get that 10-gig circuit, but unlike other vendors, we don't rate limit this. Within AVS itself, you have your ESXi hosts. Those ESXi hosts have four NICs, two for management and two for workloads. Those workloads are going at 25 gigabits per second each. When you do some optimizations on the AVS side and on Express Route side, you can get a much faster connection. Then we also have NSXT, and this is something that a lot of our customers who are using VMware already are pretty familiar with. This is the management portal, so this is what's going to help them do their static and dynamic IP addressing of their workloads. This is what they do their DCP, their DNS, their segmentation for different CIDR blocks that they're going to use for different workloads or to be dev or on production. There's a lot of things. This is a very powerful robust tool that we're really excited to have on the solution. They also get the T0 and the T1 routers. Again, that's something that's native to NSXT, where you basically have your workloads, and they communicate with those T1 routers, and then they'll communicate with the T0 router. That T0 router sits right at the edge. That's the physical uplink. Then the T1 routers is what connects to the actual NICs for those workloads. It's responsible for managing that east-west traffic between those workloads and your software-defined data centers. From there, we have network virtual appliances. This is interesting because this can be something that you use natively within NSXT. But this is something as a customer, you have the freedom to bring in as well, whether you have a license for one already on-prem, or you want to get a virtual appliance up and going in NSXT itself, in your software-defined data center, or if you want to have this in Azure. We'll see in some of the different diagrams we have later on, that we have different flows for where you want to have that traffic inspection occur, which is why you would use a network virtual appliance. With that said, if you do use that network virtual appliance in Azure, you're going to need a third-party device to do a layer three, to have some user-defined routes. That's where Azure Routes Server comes into play. That's that appliance that's going to allow you to have those user-defined routes so you can really communicate and have that flow from your NBAs to wherever it is that you want to go and have that traffic inspection. Then lastly, but not least, we also have the option for customers to use Azure Firewall. This is something that we really help to make easy for customers, because right in the AVS portal, you could just say internet enabled and your workloads were able to communicate with the internet, but that's something that's for POC because you will not be able to see that traffic and you will not be able to manage those firewall rules. This is where Azure Firewall comes into play, right in the portal, you could deploy a secure VLAN hub, configure your rules, report 80, report 443, and that route from AVS would take precedence to that Azure secured hub and then out to internet where you get that nice robust, stateful traffic inspection to help meet your security needs. So a lot of moving blocks here, a lot of things that we're excited to talk about. Yeah, that's great. Wow. So with so many components or building blocks, how does that look when it's like all put together for a customer? Yeah, and that's a great question because that is the question. That's what a lot of customers are asking us. Where exactly do we see all these different things coming into place? And it really comes into place when we think about where is it that they're trying to connect to and where is it that they're trying to go? So for example, like say you have your workloads and you're in the software defined data center, how do you communicate to workload in another software defined data center? And now we have something under a hood called any connect. And what any connect does is that underneath the hood, it's a nice full mesh point to point route leak within the AVS network itself. And that has like a tunnel that will go between those software defined data centers. Now, if you want to go outside of AVS, let's say to your Azure vNets, this is where again, you're hitting that edge. You're going from your direct connect, you're hitting that Microsoft dedicated edge. And from there, you're able to go to your Azure vNets and you're also able to go to your on-prem. And the way you'd go to on-prem or a different co-location data center is that in between those circuits, they are paired with something called global reach. So global reach is an attachment that's at your end of your express route circuit. So let's say that you have your on-prem data center and you have your AVS, your on-prem data center is going to get a direct connect, could be from vendor, could be Azure direct, but that's going to terminate with an Azure at an edge. And then it's the same thing for your AVS solution. You're going to have a direct Azure dedicated circuit, it's going to hit the global reach and then those two circuits can peer. So now you're right in the backbone, you're not going over to internet, you have like an Azure backend to have that communication end to end. Some things that we also see as well, customers looking for that traffic inspection, they could do so using the Azure firewall rule and that public IP option. So when you go to AVS and you select that public IP option, whether it be in the portal or through automation or even connected to an existing, you know, Azure VLAN, you're going to get that Azure VLAN hub, you're going to get that firewall, you're going to get those stateful rules and policies allowing you to have that traffic inspection and you're going to have that route that's going to take precedence to your internet. So that Azure firewalls was going to advertise that QuadZero to the internet. So different communication that you can even have even within Azure VNets, right? Because customers are excited to use things that are Azure native as well, they might want to start using like, you know, storage accounts and whatnot or Cosmos DB or Key Vault. So your Azure VNets can be configured in the hub and scope topology or again using that secure VLAN hub. And this is where we really see customers looking to have those different things that they can do to connect securely. That's great, wow. So speaking of like a network virtual appliance and we're talking about VMware, are there, if I'm currently using something on premises like a third party NVA, can I use that in AVS? Yeah, absolutely. And there's a different, you know, options and how you want to do that because it really depends on where you want that traffic inspection to occur. And that can really dictate where you put that network virtual appliance. So say for example, we see this is a really popular demand with customers because they may already have a network virtual appliance on premises. And if they do that, what they can do from there is just have that traffic inspection initiate from on-prem to their Azure VNets. Also, if they're in the software defined data center itself, they could use NSXT natively, but they also have the option to use a network virtual appliance that they just, you know, spin up on a virtual machine or just spin up an appliance within the software defined data center itself. So they could do that traffic inspection between their workloads East-West, but they could also have that traffic inspection where we're saying is North-South, you know, going out to those Azure VNets. Where we do see things get complicated is when they want to have that traffic inspection end to end from on-premise to your Azure VNets to your AVS, so that whole, you know, solution. What we see customers do there is one, if they don't have like the Google reach available to them, they disable it. And therefore that doesn't take precedence. So your precedence literally of your route is going to Azure, but you need to have your traffic inspection happening on both sides. So you need traffic inspection coming into Azure, boom, network virtual appliance. Then you have AVS going into Azure, boom, network virtual appliance. And then how those communicate with each other is now they need that layer three device, which would be the route servers. So that would either set up like the VXLant tunnel or EBGP, but both ways, you know, now you have that end-to-end traffic inspection. That's great, wow. Okay, so I think Mahesh has the slides like showing us the connectivity to share with us. And I have a question for you, Mahesh. Can I use my third-party NVA? Sounds like I can use my third-party NVA, but is there something at like, I can use that directly integrated in AVS? It looks like there's a lot of Azure tools that are already built. So is there anything like that? Yeah, absolutely. And we're coming back to your question and you use your favorite third-party NVA directly integrated with AVS, absolutely you can. So let's take a look at how that scenario would look like. So as you can see on the screen, you don't have any NVA running inside of an Azure Virtual Network. Instead, you will see that your favorite third-party NVA is running inside of an AVS SDBC here. And this is a great place to actually run the NVA because then you can sort of carry on your operational processes that you might have created around specific feature set of your NVA, or you have plenty of policies that you might have created based on your on-premise location and you want to carry forward those policies into AVS as well. So yes, absolutely you can run your NVA directly integrated with the AVS SDTC. So let's take a look at some of the major network flows and let's start with the connectivity with on-premise environment. So the connectivity with on-premise environment is again established using ExpressRoute Group of Reach. So this is the feature or service that connects the AVS ExpressRoute Circuit with the ExpressRoute Circuit that you already may have which connects your on-premise environment with Azure. So no change there. Let's move into the e-grace traffic now and then again the e-grace traffic would originate from the AVS guest VMs. So the traffic would originate from the guest VMs inside of an AVS SDTC. It will traverse through this NVA and this is where you can run those policies, you can inspect your traffic and then do all the things that you otherwise would have done from your on-premise environment. Once the traffic is deemed to be good, then it traverses through the tier one and tier zero gateways and then reaches to the AVS ExpressRoute Circuit. And from the ExpressRoute Circuit that is associated with AVS, it breaks out into the internet. Now, one thing to note here is that the scenario one which Sabin covered earlier, the scenario differs that instead of routing that traffic through an Azure firewall which would have been integrated with VirtualVan, the internet breakout happens directly from the AVS ExpressRoute Circuit. So that's the egress traffic, Amy that you can sort of take a look at when using your third party NVA. Now, the other two important sort of traffic flows are let's talk about the ingress traffic and let's first begin with the non-HTTP or HTTPS traffic. So this traffic would originate from internet and the Azure firewall which is integrated with the Azure VirtualVan. From there, the traffic would flow on to the AVS ExpressRoute Circuit and then over to the tier zero and tier one gateway. And it will hit this third party NVA once again. And again, you have an opportunity where you can inspect that traffic. If you want to do any processing, you can do that. And then if everything is all right, then it will hit those backend VMs for the final delivery. So that's the ingress traffic on HTTPS and HTTPS protocol for you, Amy. That leaves the last important traffic flow which is the traffic flow around or on the HTTP or HTTPS ports. Now, just like in the previous network flow, the traffic would originate out in the internet somewhere and here it would terminate on an application gateway. So application gateway is the service that provides the services like WAV or SSL termination. And once that is done, then the traffic is routed over an ExpressRoute connection back into the AVS ExpressRoute circuit. And from here, it takes its usual path through the tier zero gateway, then back to tier one inside your NVA and a backend VM that might be serving that request. So overall, this is how that scenario would look like Amy where you can run your NVA directly integrated with the AVS SDTC. Wow, that's great. And I like all your drawings of the paths that helps visualize the network traffic. Yeah, I hope it was useful. Oh, yeah, definitely. And then, so if I wanna inspect all like internet bound traffic from AVS but I wanna do it on premises, can I do that instead? Absolutely. This is exactly what the scenario depicts. So, so far we have looked at the NVA placements in multiple places. So let's sort of compare those scenarios with this. So just like in the previous case, as you would see here, there are no NVs running inside of Azure Virtual Network. There is no virtual band or there are no NVs running inside of an AVS. Instead, you would notice that your NV is now running from an on-premise location. The one thing that we'll have to note here is you will have to ensure that the quad zero route is advertised over to Azure. Now, this can be done over an express route circuit that you already might have. So this is the only thing that will have to ensure Amy that you do before you take this scenario or before you make this scenario operational. Now, just like in the previous sort of scenarios, let's take a look at some of the important network flows and then let's begin with once again the on-premise connectivity. So just like in the previous scenario, the on-premise connectivity is established using ExpressRoute Global Reach. This is the same service that connects the AVS ExpressRoute circuit with your existing on-premise ExpressRoute circuit. So no change there. Now let's move on to the egress traffic, Amy. And once again, for the egress traffic, the origin would be an AVS STD CPM. So the traffic would originate from that VM. It will pass through the tier one, tier zero gateways and then hit the AVS ExpressRoute circuit. From here, it traverses over the ExpressRoute Global Reach and to the on-premise ExpressRoute circuit and eventually reaches the NVA that is running from the on-premise location. And from here, it will break out into the internet. Now, the reason why this happens is that quad-zero route that I earlier talked about. Because you are publishing that quad-zero route from your on-premise location into Azure, that same route will be honored by AVS. And that's how basically AVS knows that it has to route all the traffic to your on-premise NVA for internet breakout from that location. Does that make sense, Amy? Yeah, that's the default route. Absolutely. Okay. So yeah, let's move on to the egress traffic now. And then let's once again begin with the egress traffic on, let's say, the non-HTTP or HTTPS ports. And this would typically, or protocols, this would typically include traffic on, let's say, RDP or the TCP ports. So here, the traffic would again originate from internet. And it would hit your NVA running from your on-premise location. From there, it will take its usual path to the on-premises extra south circuit over the global reach on to the AVS extra south circuit. And from here, back to AVS through the T-zero and tier one gateway. So no chain there. So this is how the, let's say, non-HTTP or non-HTTPs traffic would be handled. That leaves us the last network flow, which is basically talking about the egress traffic on HTTP or HTTPS protocol. And just like in the previous mode, the traffic would originate somewhere in the internet. Now, instead of routing it to firewall, we would recommend that you route it over application gateway because this is the service that, as you talked about, provides you the protection against the common web attacks. It also provides access to the termination. So all the great options when it comes to processing your web traffic. So once the traffic arrives at the application gateway, then again, using an express route connection, it would go to the AVS express route. And then from AVS express route, it would go to the tier zero, tier one gateways and back to the backend VM that will actually serve that web traffic for the users. Back to you, Amy. All right, well, great. I mean, it was great to learn about these four scenarios that you both have seen. What are some key takeaways? Obviously, networking and security are really important. So as part of an AVS landing zone, what would you say is like a key takeaway for someone listening today? Yeah, absolutely. And just to do that, I'm not limited to these four scenarios. Depending on the customer needs, there's plenty of scenarios. So these are really here to be prescriptive. So as long as customers really understand the building blocks, they know the different things that they'll be able to design. Gotcha. Yeah, absolutely. And coming back to your point, Amy. So this is, I would say, what our audience should sort of take away from this session. So remember that from the AVS perspective, the key components are Azure Virtual Ban, Azure Firewall and Application Gateway. So these are some of the Azure native services which facilitate in-grace as well as e-grace traffic flows from and to the AVS SDTC. So pay attention to that. Obviously, NVS play a huge role in the whole AVS networking. As you saw in those some of the key scenarios, NVS can be put or deployed inside multiple locations. You can run them from the Azure Virtual Network or directly integrate with AVS SDTC. Or if you want, you can run them from your on-premise locations as well. The other important thing to be aware of are the expressed-out circuits. And as Sabine earlier talked about, expressed-out circuits are that clue which connects the on-premise side with the AVS SDTC through global reach. So that has to be enabled in most of the scenarios. The final thing to be aware of are the quad-zero routes. Now quad-zero routes essentially determine how the internet breakout happens. And then specifically in some scenarios like virtual ban, those routes gets top-overted to your on-premise location. Now that means that all the internet-bound traffic might have to be routed to Azure and you may or you may not want that. So please pay special attention to the quad-zero routes. If you looked or as seen in the scenario four, in some cases you would actually deliberately want to push or advertise the quad-zero route from your on-premise location to Azure so that you can have the internet breakout from your on-premises location. So pay special attention to the quad-zero routes. And a quick summary in scenario one that we discussed, we looked at Azure Virtual Van as the key service. In scenario two, we looked at NV which was running from a Azure virtual network along with an Azure route server. In scenario three, we looked at the NV which was directly integrated with AVS. And finally in scenario four, we looked at an NV which was running from an on-premise location. So that's a quick summary I would say, Amy, for our audience. That was great. Yeah, I learned a lot. There's so much to take in. And then do we have a final slide to share with the architecture you referenced? Okay, great. So we have the AVS landing zone, reference architecture, implementation and guidance. And I thank you Mahesh and Sabine for joining me today and sharing your in-depth knowledge. This was great. And for everyone watching, you can definitely get the slides from today and any links below. And I just want to thank you again. Thanks for joining. Anytime. Thank you. Thank you. So goodbye. Have a good day. You too. Thank you.