I found an interesting little field hidden in plain sight in Microsoft documentation. A clever chap recently said this to me: 'if you can figure out what problem the engineers were trying to solve then it makes it easier to understand why the product works the way it does'.
When you create a VNet in Azure or a VPC in AWS you have to allocate a CIDR range from which you subnets will be allocated. There are some nuances between the different service providers as you try to expand your networks which can lead to some challenges. Knowing the different rules from the start can help you plan your CIDR ranges appropriately. We'll start with what's the same across AWS and Azure and then look at the differences.
I will always be a network engineer and that means that some words have very specific meanings that have taken root in my soul. The terminology within ExpressRoute has bothered me for ages and when speaking to a few people I found that I am not the only one who finds it unintuitive. To me a circuit is a single link but to Microsoft a circuit is the pair of links and the associated peerings! Two thumbs up to that, Microsoft, or rather in your own language 'one expressroute thumb'.
There seems to be an obsession over on Reddit about the Mandela Effect which was named after a collective but strongly held false memory that the eponymous Nelson Mandela had died in prison in the '80. It seems that our minds can play tricks on us and sometimes things which we clearly remember turn out to be a shared fantasy. I feel a little like this about those weird two weeks in about April 2021, in midst of the 'rona years, where everyone on LinkedIn got Aviatrix certification for free and then shared it with their contacts so that they too could benefit from a free certification in an emerging technology vendor's product. The reason I am not sure if it's a Mandela Effect is that I don't really think I have heard of anyone since who has actually used that certification for anything other than to pad out their Credly.
I took a look at egress security a little while ago and advocated for the 'less is more' approach for most organisations due to the proliferation of VPCs and vNets and the risk of either having a very large amount of very expensive firewalls providing very little value or, perhaps worse, another pet in the form of centralised internet egress. There may be another way.
In a recent conversation about IPv6 adoption at a Western technology company, a familiar scene played out. Engineers and architects discussed IPv6 implementation as an optional future consideration rather than an immediate necessity. 'We don't really need it yet', was the prevailing sentiment. This perspective, common among Western organisations, reveals a profound blindspot born of privilege – one that unconsciously perpetuates digital inequality on a global scale.
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.
A good friend of mine is doing his AZ-700 next week and asked me a few questions about Azure Traffic Manager, Azure Front Door and the WAF capabilities in Azure. Some of the questions were a bit confusing in the practice exams he has been taking. As he's not only a good friend but also the kind chap who proof reads a lot of these blog posts I thought I'd do something to try to explain what the options are any when you'd use them. On a side note if you fancy talking to a top tier network guy and all round nice fella I thoroughly recommend you look up Zain Khan.
When working with Azure cloud networking, certain limitations become apparent, particularly around DNS capabilities for private networks. In this post, I'll explore an unconventional approach: using Amazon Route 53 to address some of Azure's DNS limitations. While this might seem controversial, it offers interesting solutions to two specific challenges: cross-region failover for private resources and closest-instance routing within private networks.
I had a conversation today about sharding in Azure. It's a fairly well known thing in AWS but it's employed in Azure as well and has some important implications for workload placement in a few specific use cases. This post explores the concept of AZ sharding, its implications for cross-subscription services, and techniques for mapping physical AZs to achieve optimal performance.
One of the sneaky under the radar features that could to be a game changer in the near future is Azure Subnet Peering. This is a feature that is already there in the API but not really documented or productised.
On a few occasions I have been asked to explain networks to people with no prior experience and it's quite hard to work out where to start; there is so much history and so many concepts from general computer science that have got us to where we are today. I have long believed that to truly understand a concept it's very valuable to be able to organise your understanding in a way that means you can explain it to someone else. My goal here is not just to explain many of the contributions to networking that make the internet work but also organise some of my own understanding and explore areas where I have taken things on faith rather than asking why they are the way they are. The approach for this will be to assume we're starting with nothing and rebuilding the internet from the ground up and solving the problems that were solved to get us where we are today.
In the tech industry, there's an unspoken assumption that technical teams should be led by those with the deepest technical expertise. This conventional wisdom, while seemingly logical, may actually be holding organisations back from achieving their full potential. The practice of promoting technical experts into management positions creates a complex web of challenges that ripple throughout organisations, affecting everything from innovation to career development.
Some common search alorithms and how they work.
Over my years in networking I've sat on both sides of countless technical interviews. There's a familiar dance that occurs when discussing OSPF: the candidate confidently states "OSPF uses Dijkstra's algorithm for route calculation," and the interviewer will nod approvingly. Yet recently, I had a moment of clarity: in hundreds of these exchanges, I've never once asked a candidate to explain what that actually means, nor have I been asked to explain it myself. This perfunctory mention of Dijkstra has become almost ceremonial in our industry, a shibboleth that we repeat without truly engaging with its significance. Yet understanding this algorithm isn't just academic—it fundamentally shapes how OSPF operates, influences our network designs, and explains why certain design patterns have become best practices. When a link fails in your network and OSPF begins recalculating routes, there's significant computational overhead that many engineers never consider. This processing cost isn't just theoretical—it's the hidden force behind many of our design decisions, from area sizing to adjacency limits. Today, we'll bridge the gap between theory and practice, exploring how this fundamental algorithm shapes the way we deploy and scale OSPF networks, and why it matters for your day-to-day operations.
What to do about global site load balancing.
Note for US readers: CV, or Curriculum Vitae, is the standard term in the UK and many other countries for what Americans call a resume. While traditionally a CV might be longer and more detailed than a resume, the terms are often used interchangeably in today's international job market.
I was chatting with a friend who is doing his AZ-700 and he had found this rather neat way of finding your IP using Google DNS.
The reason I fell down the rabbit hole with regard to finding my public ip was because of a section in an old Azure networking book my friend was reading which said:
To allow Azure internal communication between resources in Virtual Networks and Azure services, Azure assigns public IP addresses to VMs, which identifies them internally. Let's call these public IP addresses AzPIP (this is an unofficial abbreviation). You can check the Azure internal Public IP address bound to the VM with the command dig TXT short o-o.myaddr.google.com.
Over two decades of experience implementing network and cloud infrastructure across financial services, retail, healthcare, and public sector organisations has shown me a clear pattern: the success of cloud initiatives correlates strongly with an organisation's readiness for cloud adoption. Yet surprisingly few organisations conduct thorough readiness assessments before embarking on their cloud journey.
Notifications and alerts are ubiquitous in our always-on, hyper-connected world. But as I’ve learnt from personal experience and my work in enterprise IT, more alerts don’t necessarily mean better outcomes. In fact, over-alerting can be downright counterproductive.
When packets traverse a cloud network, they face numerous decision points. Among these, one stands out as particularly fundamental: the initial routing decision. At its heart lies an algorithm that might seem counterintuitive 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 intersection of computational efficiency, network architecture, and the evolution of cloud computing.
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 anouncements and enhancements in Azure Networking; many of these are particularly relevant for things I am doing.
Rethinking Infrastructure Support
In the world of IT operations, there’s a metric that network teams know all too well: Mean Time to Innocence (MTTI). It’s the average time it takes for a network team to prove they’re not responsible for an outage or performance issue. While this might sound amusing, it points to a deeper problem in how we structure and organise our infrastructure teams.
I've now extended the github action for those who want to create their sites in Docusaurus and then have the commited and pushed changes automagically get built and synced to their S3 bucket. Static S3 sites are a great way to host static sites and Docusaurus is a great tool for rendering sites out of simple markdown content.
I used to run a hosted linux web server, which was great for stuff like all those weird little scripts and things I wanted to run 'always on'. After a while I put a few websites on it, and some websites for friends, and my little brother, and the local residents association, and next thing I knew I was running a load of instances of Wordpress. I was also constantly fending off the advances of hackers who were forever finding exploits in the famously insecure blogging platform. Recently I got around to removing the last of the sites from my web server and finally cancelled the contract and let it die the death it long deserved. The sites I have left under my control are now all static sites either, like this, generated by Docusaurus or purely static things that are built by Claude with a little help from me. All of it is now in S3 buckets hosted as static public websites. Being the github fanboi that I am I have put each of the static sites in a repository and it occurred to me that when I commit a change it would be great if I could just bash the whole lot over to S3 with an action.
The Business Case Challenge
Traditional justifications for SD-WAN adoption have often focused on cost savings versus MPLS or enhanced network features. However, these arguments frequently fall short under scrutiny. The fundamental challenges that limited VPN adoption in enterprise networks – including performance consistency, reliability, and operational complexity – remain relevant despite improvements in internet infrastructure.
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.
When Microsoft unveiled Azure Virtual WAN, it was heralded as a revolutionary solution for simplifying complex networking scenarios in the cloud. The vision was compelling: a comprehensive service that would streamline branch connectivity to Azure, enable seamless hub-and-spoke architectures, provide automated routing with simplified security, and offer easy integration with SD-WAN appliances. For organisations grappling with the intricacies of cloud networking, this sounded like a panacea and I know plenty who fell for it. However, as many have discovered, the reality of implementing and managing Virtual WAN has proven far more challenging than initially anticipated.
I am working on a DHCP migration and it turns out that the people who managed the DHCP server previously weren’t that great at cleaning up old scopes when sites were closed. It’s next to impossible to identify from the number of leases because some of the live sites are only rarely used so I thought I’d knock up a little script to ping the default gateway to see if the subnet is still there.
The Case for Application-Level Controls
The approach to securing outbound internet traffic often reflects an organisation’s security maturity more than its technical requirements. System-to-system communication, such as API calls to cloud services, presents fundamentally different challenges compared to user browsing. Understanding these differences is crucial for implementing effective security controls without unnecessary complexity or risk.
Not all FQDN filters are built the same.
This analysis examines the technical implementations of FQDN filtering across three platforms: Azure Firewall, FortiGate, and Enforza. We explore the fundamental differences in their approaches to DNS handling, TLS inspection, and wildcard filtering capabilities. Key focus areas include:
The glue you never knew you needed.
Often 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.
I went down the AWS Gateway Load Balancer rabbit hole recently and it's an interesting solution to some quite specific problems. There are use cases for it on ingress and egress where regulatory requirements, or more likely legacy skillsets, dictate that traffic passes through NVA based network security appliances. The problem with NVAs is often the difficulty scaling them in AWS. You need to distribute traffic and typically you need a loadbalancer but you can't use an ALB or a NLB because unlike Azure the load balancers in AWS do not allow for traffic routing so they cannot be targets for route tables in the same way Azure loadbalancers can be targets for UDRs.
There used to be a great little website for route summarisation and it did it far more intelligently than Cisco kit does it. It looks like the site has dropped off the internet which is a shame but there is a handy python library called netaddr with has the same capabilities.
I have written a little wrapper for it which will regex the prefixes out of a ‘show ip bgp’ and then list the summary routes. You pass the output of ‘show ip bgp’ as a text file, it’s the only argument the script expects.