Highly Available NVAs in Microsoft Azure
Vložit
- čas přidán 8. 07. 2024
- In this video we go super deep on things like symmetric routing, SNAT, hashing to support highly available NVAs in Azure.
Whiteboard - github.com/johnthebrit/Random...
Load Balancer Deep Dive - • Azure Load Balancer De...
HA Ports - docs.microsoft.com/en-us/azur...
NVA HA architectures - docs.microsoft.com/en-us/azur...
00:00 Introduction
01:38 Load Balancer functionality review
06:48 Floating IP
08:52 Next hop behavior
10:55 SDN L3 differences from a L2 physical world and numbers of NICs
14:37 Stateful HA NVAs
16:12 Internal facing NVAs
26:15 External and internal NVAs. No SNAT
32:38 With SNAT!
36:15 x-forwarded-for with SNAT
37:14 Using Floating IP
39:30 Using Route Server
44:00 Summary - Věda a technologie
this kind of video goes beyond Azure / cloud knowledge, you learn about principals. John is the man!
Most of the times I'm really surprised how this kind of content is so underrated. To allow John continue his job it is very simple that he has to get fair payment for this. Please share this content with your colleagues! Cloud is the future and your future is tomorrow! :)
Thank you but I have all advertising turned off. I make no money from this channel. It's just a way to give back and help people.
Detailed, direct to the point, touching different real world scenarios and awesome, like always!
Thanks John 🤟
Thanks for sharing your knowledge. Looking forward to the ARS video
No one goes into that level of details! Thank you very much 🙏
Brilliant video. You often cover something I've thought about but haven't made time to research. I love all the whiteboard sessions but in particular I'd really like to see a "putting/seeing it in practice session"
John, very informative training, you are the KING of Azure.Thank you so much.
Thanks a ton for breaking all of this down. Definitely helped me understand the concepts of HA NVA's!
Great to hear!
Hey John, your videos are turning out to be one stop shop for all queries on complex issues on Azure environment... Thanks a ton for posting such informative videos
You are very welcome
Thanks a lot for this incredible explanation. This just saved me 6hours from a presentation on the subject. I appreciate. Keep up the excellent work
Excellent content! Am looking forward to your next video on Azure Route Server especially NVA’s and routing to Azure Private Link IP’s.
Route server is next week. Have something else for this Thursday.
Whoa... this was...'Brainfull'! I am overloaded, need to go back and rewatch this. Thanks a bunch John!
You are like the Tech whisperer, a couple of days back we were configuring the Palo Alto Firewall Appliance in Azure, and now it's slowly making sense why the configuration needed to be a certain way! Woohoo. You are amazing.
That’s awesome! Glad it was timely :)
The best explanation of these concepts period.
good video mate - cheers
I know just saying thanks won't be enough to all your hard work which you had done and are doing continuously to teach azure Cloud to all those who are interested. It's really amazing and you are one the best Tutor on Azure. Thank you John for all your efforts. By the way what inspire you most & how you looks so fit. It's really Crazyyyy
You're very welcome! Thank you
brilliant!!! thx a lot!
Fantastic, as always
Thank you! Cheers!
@@NTFAQGuy With the vswitch and vfp can I ask is that a construct per backend pool? Or is it one per lb instance or per backend nic. Or is it a bit more mysterious than that?
@@evolagenda its at the host.
Like everyone else in the comments is saying, great video! Clear, thorough, easy to follow. It has it all. It blows my mind that a video like this can have over 16k views and only 482 (as of now) likes. Wake up, people. Hit that thumb. There isn't better Azure content out there that I can find.
hehe, thanks.
Hi John, as always, thanks for the hard work, bring us another amazing episode. Quick question, @35:03 the response seems bypassing the Internal LB, so in this case, is the Internal LB being used at all? do we still need it in this case? thanks
Watch my load balancer deep dive to understand flow. Lb required to distribute/failover multiple instances
Great content as always John. Wondering if the route server will break statefulness if the NVAs are Firewalls, with two ECMPs in the route table with both NVAs as the next hop.
Look at my new video on gateway load balancer
Hi John, great vid as always :) Got one question: a third-party firewall from the Azure Marketplace is essentially a NVA?
basically yes.
Thanks for another great video. I am not sure I understand the point of the internal LB in your Active/Active scenario. When is it being used by the VMs? When they are the source of the request to an "external IP"?
I’m the internal scenario they were always used for traffic sent between subnets hence the udr. Think packet inspection/firewall
@@NTFAQGuy Thanks John.
MASSIVE CAVEAT FOR ROUTE SERVER: It doesn't work to route between subnets in a vnet, every vnet can only have 1 subnet if you want it to regulate traffic between subnets, due to how the BGP tables are built between vnets and how there's no escape hatch with a user-defined route that works that doesn't end up bouncng the traffic back to the host or the route server in a loop.
However it is awesome for an edge NVA and SD-WAN as John showed, just don't try to use it for an NVA firewall that you want to monitor inter-subnet traffic with.
Will be covering route server next week lol
Excellent! Thanks John for the teaching! One thing about the ARS and BGP demo, I got what you meant for the ECMP. But what you wrote down on the whiteboard "CIDR2 => NVA1" does not match what you said. Most likely it's just a typo. I guess it should be "CIDR1 => NVA 2".
Glad you like the video. I would have to rewatch to know as no memory :)
👍🏻🤙
@John How does NVA1 knows about VNET prefixes and forward traffic. Do we need to add static routes on NVAs to forward traffic to VNets and UDR on route tables attached to the subnet? And what if traffic is destined for peered vnets?
NVAs typically will be configured but may interact with vnet to learn or hook into something like route server potentially.
Amazing!!! For the internal facing NVAs to work properly, do I need to enable IP forwarding in the guest OS as I do it in the NIC of the NVA as well?
Forwarding would be part of the nva
actually deep dive
Excellent. Can you elaborate on when SNAT is not a viable option?
its really based on the receiving workload and if they need the true IP of the client and can't handle x-forwarded-for etc.
How about Zone based Firewalls that require 1 NIC per zone? Haven’t found and option to to 1 NIC with Palo Alto Networks Firewall and some other vendors.
Different vendors work in different ways but the reality is the VNet is flat. multiple NICs really don't change that. Work with the vendor but the point here is if you are multi-NIC and stateful then you SNAT.
In Palo Alto case, you can certainly just do two NICs with HA ports sandwiching it and load balancer it all to the one NIC, and then apply your policies at the source/destination level rather than the zone level. Your zones are just "Internal" and "External" and internal can have as many subnets as you want routed to it via UDR.
I don't see any reason why you couldn't deploy some PA-VMs with a single NIC in a load-balancer sandwich. Granted, most PA-VMs will have two NICs (one for data-plane and one for management-plane), but there should be nothing stopping you from running the PA-VM with one data-plane NIC. Everything will be "intrazone," which will necessitate you modifying the behavior of the factory-default intrazone rule from "allow" to "deny" or something similar. From there, you will just add more specific "allow" Security-Policies above the default catchall. Don't forget the default route in the Virtual-Router, either.
Check out PANW's Azure reference architecture, if you haven't already.
@@kilosandkeyboards having a NIC for management is fine. Just where the load balancing for the symmetric flow need same LB with same NIC.
Hello John, great videos! With regard to SNATing and using X-FORWARDED-FOR - you refer to this as an IP header. Isn't this an HTTP header? I.e., if the protocol being used is vanilla TCP then you can't use it and the backend VM doesn't get to see the source IP.
Yes, i should have been clearer on that.