30 posts tagged with "Networks"

Cold open​

The internet packed a sandwich and went outside this week. Azure's networking blog is unchanged since the 19th, Ivan over at ipSpace has gone on summer break, and the only mildly newsworthy DNS story is the same encrypted-DNS metadata-leak paper I covered last week. So this is a slim one — but the AWS Cloud WAN routing-policy series got its Part 2, and the White House quietly handed everyone a 2030 deadline for post-quantum crypto. Both are worth your Monday morning.

Three things this week: a DNS privacy paper that politely points out your "encrypted" lookups are still wearing a name badge, a long retrospective on the February Cloudflare BYOIP outage that's making the rounds again, and Azure quietly shipping the kind of plumbing you don't see in keynotes but absolutely use on Monday morning. Plus a small Cloudflare BGP wobble on the 17th — short, contained, and a useful reminder that nothing on the internet is "settled."

A like-minded colleague and I used to look at network topologies and ask one simple question. If there was a traffic-engineering choice to make, could we leave more of the hard work to the routing protocol and simplify everything else?

AWS is now running production data centre networks that are wired at random and still deliver strong performance. That sounds wrong at first, but the paper Expanding into Reality: Random Graphs for Datacenter Networks shows why it works.

The key idea is simple: move from rigid hierarchy to high-connectivity randomness, then design routing and operations around that choice.

Azure VPN Gateway has supported site-to-site connections with pre-shared keys for years. They work, but a shared secret passed between two parties is only as strong as the process you use to manage it. Certificate authentication gives you something more robust, and it's now generally available.

This feature lets you authenticate your site-to-site VPN tunnels using X.509 certificates rather than a pre-shared key. Certificates live in Azure Key Vault, and the VPN gateway accesses them through a User-Assigned Managed Identity. That means no secrets sitting in a config file, no manual rotation conversations, and a much cleaner audit trail.

If you've been waiting for GA before rolling this out to production, the wait is over.

I use ping a lot, but milliseconds can hide the detail I care about. That's where uping comes in. It's a small C tool for macOS and Linux that measures ICMP round-trip time in microseconds, with colour-coded output you can read at a glance.

The CNAME (Canonical Name) record is one of the most straightforward DNS record types in concept: it creates an alias for a domain name. Yet the DNS specifications impose very rigid constraints on where and how CNAMEs can be used. These rules exist for good reasons: consistency, cache efficiency, and preventing resolver bugs. This post is about all the rules relating to CNAME usage, drawing directly from RFC 1034 (Domain Names - Concepts and Facilities) and RFC 1912 (Common DNS Operational and Configuration Errors). More importantly, it should explain some of the really annoying gotchas that have tripped me up at various points in my career, and that I want you to be better equipped to avoid.

I saw a clever little tool on LinkedIn the other week. Someone had written a "ping" in Go that fired HTTP requests instead of ICMP echoes. I sent it over to Zain and we both agreed the idea was great. But writing it in Go felt like a lot of effort for what is, at heart, a loop around curl. So I wrote a Bash version in about ten minutes. Then I wrote one for DNS. Then one for NTP. They all live here now: @simonpainter/network-tools.

I'm enjoying reading "DNS: The Internet's Control Plane" by Enrique Somoza and one of the things it mentioned was that there are exactly 13 DNS root servers and this is a hangover from the early days of the internet. It also predates the anycast architecture that allows each root server IP to be served by multiple machines around the world. I thought it worth a little dig. Get it?

The book itself, and many of the search results I found, say that it is due to the 512-byte limit of a UDP DNS response. But I wanted to get into the detail that wasn't easily found and understand exactly what the response was and how the 13 is calculated.

Microsoft have quietly released Azure Virtual Network Routing Appliance into public preview in February 2026. This is a new Azure network construct that sits in a hub network to provide high capacity routing between spoke networks. I had a look at why we might need it and if it is something we should be using. There was a bit of a glimpse of the technical details in Ignite last year but this is the first time we've seen the actual deployment experience.

I recently got drawn into a bit of LinkedIn rage bait: a post with a CCNA level question asking people to identify the broadcast domains in a given diagram. The diagram was simple enough and it was pretty clear what the question was trying to test, an understanding of what a broadcast domain is. The question did, however, elicit a lot of discussion. It left enough ambiguity that there was a valid answer for multiple interpretations.

I had another one of those weird problems which made me revisit the egress IP decision tree again.

Services like Azure Storage are really great, and they are super secure, but they seem to make infosec people a bit nervous. The idea of data being secured by identity rules only and not behind a firewall feels a bit too open for some people. I am a big fan of the zero trust security model but that puts all the trust into your identity provider and the way you manage identities and that is a big ask for some organisations.

We've taken a look at 168.63.129.16, the magic IP address in Azure, and now it's time to explore 169.254.169.254, the instance metadata IP address. This IP address is used by Azure virtual machines to access instance metadata, which provides information about the VM and its environment.

While looking at the magic ip I touched upon the idea of Azure Service Tags. They're supported within NSGs and Azure Firewall rules and are essentially Microsoft managed IP address groups that represent specific services within the Azure ecosystem.

From time to time I have a conversation about Azure networking and a topic comes up that I need to dig into a little more. Normally the documentation is pretty good but sometimes I just need to bottom out all the behaviour. Today's topic is 168.63.129.16, an IP address that keeps coming up in various places in Azure.

There are a few things going on with ExpressRoute Gateways and they are related to Public IPs. First of all the retirement of Basic SKU Public IPs for ExpressRoute Gateways is something to be aware of as it has a hard end date and will require a migration to a different SKU. The second one is the HOBO (Hosted On Behalf Of) public IP feature which has an interesting drawback.

In a recent blog post I wrote: "As network engineers we are used to the declarative model of configuration management and so this fits nicely into that mindset - you declare what you want and Terraform will make it so." But declaring what you want is only half the battle. The real challenge lies in how you structure that declaration to handle the messy reality of business requirements whilst maintaining the automation benefits that drew us to declarative tools in the first place.

I happened upon the diagram below within the pages on default outbound internet access and it seemed a little counterintuitive. The decision flow seems to suggest that a VM will use the egress IP of a NAT gateway preferably over an assigned PIP.

A couple of days ago, I saw a meme targeted at network engineers that mentioned "the VLAN add disaster." I immediately understood what it meant. It feels like such a well-known thing now, enough to warrant a place in a meme, that it's become part of our professional zeitgeist over the last decade in networking.

Most people think of Azure Public Load Balancer as that thing that spreads web traffic across multiple servers. Fair enough - that's what it does best. But it's actually a Swiss Army knife for network address translation that can solve some tricky connectivity problems you might not expect.

Any time I have to do anything with OSPF I remind myself how it can be so damn awkward about MTU. A little while ago I was busy trying to integrate some Juniper SRX firewalls into a perimeter around some Cisco Nexus 7K and reached a problem that looked like MTU, smelled like MTU, quacked like MTU but we couldn't work out how it was MTU. Here's how it was MTU and what we learned.

I had a look recently at Azure Subnet Peering which was mostly undocumented at the time except for a blog post by Jose Moreno, one of the gurus of Azure Networking.

When I set out to explore network latency in Azure, I had a simple goal: to understand how physical distance affects performance. After all, we've all heard that farther apart means slower connections. But I wanted specifics - exactly how much slower? And how consistent is that performance? I also wanted to see how long lived TCP connections performed across the Azure network.

I'm sharing what I've learned from my first round of tests, setting a baseline that we can build on later.

I've been exploring a pretty niche feature preview that you can find documented here. In some cases, you might want to expand the size of a subnet, but if you have a constrained IP space, you might not have contiguous space available. Here's what I've found you can do.

Counting prefixes the same way my wife counts my mistakes​

Anyone who has accidentally advertised too many prefixes and watched their ISP BGP peerings collapse (I'm looking at you, BT) knows that prefix limits are a common safeguard in networking. While exploring anycast configurations in Azure, I carefully noted the official Route Server prefix limit of 1,000 routes. However, I recently discovered something far more interesting in the fine print about how Azure actually calculates this limit.

I've recently been exploring one of the sneaky under-the-radar features that could be a game changer in the near future: Azure Subnet Peering. This is a feature that's already there in the API but not really documented or productised yet.

When packets travel through a cloud network, they face many decision points. Among these, one stands out as really important: the initial routing decision. At its heart is an algorithm that might seem strange at first - the Longest Prefix Match (LPM). Why do we prioritise longer prefix matches? Why not shorter ones, or why not simply use the first match we find? The answer lies in a fascinating mix of computing efficiency, network design, and how cloud computing has evolved.

By far the stand out session for me at Ignite this year was Unveiling the latest in Azure Networking for a secure connected cloud | BRK240 which covered a lot of interesting announcements and enhancements in Azure Networking. Many of these are particularly relevant for projects I'm working on right now.

I wrote an article about a rather neat solution for global application delivery in Azure via anycast, however there are some limitations which exist to prevent transit routing in Azure that I'd like to discuss further.

The glue you never knew you needed.

Introduction​

I've seen many organisations face the challenge of securely exposing services across various network boundaries. Whether it's sharing resources during a merger, providing services to customers, or managing internal shared services, the need for secure, private connections is paramount. Azure Private Link service is a powerful solution to these challenges, offering a way to enable private connectivity to services in Azure across organisational and networking boundaries without exposure to the public internet.