A while ago (eons before AWS introduced Gateway Load Balancer) I discussed the intricacies of AWS and Azure networking with a very smart engineer working for a security appliance vendor, and he said something along the lines of “it shows these things were designed by software developers – they have no idea how networks should work.”
In reality, at least some aspects of public cloud networking come closer to the original ideas of how IP and data-link layers should fit together than today’s flat earth theories, so he probably wanted to say “they make it so hard for me to insert my virtual appliance into their network.”
Got this question from one of the networking engineers “blessed” with rampant clueless-rush-to-the-cloud.
I plan to peer multiple VNet from different regions. The problem is that there is not any consistent deployment in regards to the private IP subnets used on each VNet to the point I found several of them using public IP blocks as private IP ranges. As far as I recall, in Azure we can’t re-ip the VNets as the resource will be deleted so I don’t see any other option than use NAT from offending VNet subnets to use my internal RFC1918 IPv4 range. Do you have a better idea?
The way I understand Azure, while you COULD have any address range configured as VNet CIDR block, you MUST have non-overlapping address ranges for VNet peering.
One of my readers sent me this question (probably after stumbling upon a remark I made in the AWS Networking webinar):
You had mentioned that AWS is probably not using EVPN for their overlay control-plane because it doesn’t work for their scale. Can you elaborate please? I’m going through an EVPN PoC and curious to learn more.
It’s safe to assume AWS uses some sort of overlay virtual networking (like every other sane large-scale cloud provider). We don’t know any details; AWS never felt the need to use conferences as recruitment drives, and what little they told us at re:Invent described the system mostly from the customer perspective.
I got a question along these lines from a friend of mine:
Google recently announced a huge data center build in country to open new GCP regions. Does that mean I should invest into mastering GCP or should I focus on some other public cloud platform?
As always, the right answer is “it depends”, for example:
There’s one thing no cloud vendor ever managed to change: virtual machines running on top of cloud infrastructure expect to have Ethernet interfaces.
It doesn’t matter if the virtual Ethernet Network Interface Cards (NICs) are implemented with software emulation of actual hardware (VMware emulated the ancient Novell NE1000 NIC) or with paravirtual drivers - the virtual machines expect to send and receive Ethernet frames. What happens beyond the Ethernet NIC depends on the cloud implementation details.
Last week we finally made it work - unfortunately only in a virtual event, so I got none of the famous Irish beer - and the video about alternate universes of public cloud networking is already online.
Maximilian Wilhelm had great fun turning my usual black-and-white statements into tweets, including:
A few weeks ago I described the basics of AWS networking, now it’s time to describe how different Azure is.
As always, it would be best to watch my Azure Networking webinar to get the details. This blog post is the abridged CliffsNotes version of the webinar (and here’s the reason I won’t write a similar blog post for other public clouds ;).
Greg Cusanza in #BRK3192 just announced #Azure Extended Network, for stretching Layer 2 subnets into Azure!
As I know a little bit about how networking works within Azure, and I’ve seen something very similar a few times in the past, I was able to figure out what’s really going on behind the scenes in a few seconds… and got reminded of an old Russian joke I found somewhere on Quora:
Dinesh Dutt added another awesome chapter to the EVPN saga last week explaining how (and why) you could run VXLAN encapsulation with EVPN control plane on Linux hosts (TL&DR: think twice before doing it).
In the last part of current Azure Networking series I covered external VNet connectivity, including VNet peering, Internet access, Virtual Network Gateways, VPN connections, and ExpressRoute. The story continues on February 6th 2020 with Azure automation.
You’ll need Standard ipSpace.net Subscription to access both webinars.
We also had a great guest speaker on the Network Automation course: Damien Garros explained how he used central source-of-truth based on NetBox and Git to set up a network automation stack from the grounds up.
Recordings are already online; you’ll need Standard ipSpace.net Subscription to access the Azure Networking webinar, and Expert ipSpace.net Subscription to access Damien’s presentation. Azure Networking webinar is also part of our new Networking in Public Clouds online course.
I recorded the hands-on demos in advance so we had plenty of time to discuss Azure API and CLI, geographies, regions and availability zones, high-availability concepts, and deployments models… and spent the second half of the live session focusing on virtual networks, subnets, interface, and IP addresses. The videos are already online and accessible with Standard ipSpace.net Subscription.
Next step (on September 24th): network security and user-defined routes.
Remember my rant about the glacial speed of Azure orchestration system? I decided I won’t allow it to derail yet another event and recorded the demos in advance of the first live session. The final videos are just over an hour long; it probably took me at least three hours to record them.
If you plan to attend the live webinar session on September 12th, you might want to watch at least the first few videos before the live session - I will not waste everyone’s time repeating the demos during the live session.
Six years ago, when I was talking about overlay virtual networks at Interop, I loved to joke that we must be living on a weird planet where Microsoft has the best overlay virtual networking implementation… at least as far as IPv6 goes.
Even then, their data plane implementation which was fully dual-stack-aware on both tenant- and underlay level was way ahead of what System Center could do.
I will use the slide deck in a day-long workshop in Zurich (Switzerland) on June 12th and run a series of live webinar sessions in autumn. If you’re a (paid) subscriber you can already download the slides and it would be great if you’d have time to attend the Zurich workshop – it’s infinitely better to discuss interesting challenges face-to-face than to type questions in a virtual classroom.