Simon Painter

There is an excellent Terraform provider for Netbox that allows you to manage your Netbox resources using Terraform. This is particularly useful for automating the management of network devices, IP addresses, and other resources in a consistent and repeatable manner. I have been working through the process of setting this up and have found it to be a powerful tool for a documentation first and a documentation as code approach to network management.

I've had some concerns around Model Context Protocol being a new fad to put another front end on poorly managed data, like the search appliances Google sold a decade and a half ago, but I had a play with the MCP server for Netbox and it's pretty handy.

Since Anthropic open sourced the Model Context Protocol last year there have been lots of notable implementations across many areas of tech. Every day I seem to see a breathless introduction on LinkedIn to some new MCP front end to a service or dataset.

The impending deadline of Azure IP armageddon is nearly upon us. In September a fairly major shift is taking place in Azure which will see a change to the default behaviour for outbound internet for Azure VMs. The change itself has been fairly well discussed but you can now get ahead of the curve with Azure Private Subnet and start building things as they will be after September.

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.

The topic of documentation always comes up in tech and it's one that has had a lot of attention in world of software development which has led to some excellent solutions. In the world of infrastructure, however, the solutions have not been as readily available or adopted.

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.

I have found that Azure networking has been designed to be familiar to network engineers, even though a lot of the logical constructs are based on smoke and mirrors they largely behave like the things we're used to; a great example being the VNet that doesn't exist or the load balancer that is also a figment of our imagination. AWS Networking on the other hands seems to have been created by a bunch of developers high on peyote who thought they knew better than everyone else. This is why it took me a few years to pass the AWS Advanced Networking exam but only a few days to pass the Azure Networking Engineering Associate exam.

The shift from traditional network perimeters to zero trust architectures represents one of the biggest changes in cybersecurity thinking over the past two decades. But there's a dangerous misconception floating around that zero trust means ditching network security controls for identity-based systems. This misunderstanding has led many organisations to roll out incomplete solutions that create new vulnerabilities while trying to fix legacy security problems.

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.

In my previous post, I shared some basic latency tests across Azure networks. The results were pretty predictable: the closer things are physically, the faster they communicate. Not exactly groundbreaking.

But when I expanded my testing to include longer distances and different connection methods, I stumbled onto something genuinely surprising: PrivateLink connections can actually be faster than direct VNET peering - sometimes significantly so.

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.

I've already written a bit about various firewalls and their performance with FQDN filtering. I've also made the case for a 'less is more' approach to egress security where it makes sense. But the topic of FQDN filtering keeps coming up, so I thought I'd share a few more thoughts on it.

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 like to point out to people that it's easier to train a network person on cloud than it is to train a cloud person on networks. It's a glib generalisation but it holds true for the most part because there is so much to networking that comes from history and quite a lot of grounding that a seasoned network engineer or architect will already understand. A big chunk of the AWS and Azure networking certification covers BGP and that's one of the reasons they are considered quite hard for some but quite easy for others. BGP is a topic that many very experienced network engineers in enterprise networking can get through their entire career without touching, but for those who operate at scale or work with MSP and telco networks it's bread and butter.

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.

Introduction: Beyond the Basics​

FizzBuzz has long been a staple of programming interviews. The problem is deceptively simple: print numbers from 1 to n, but replace multiples of 3 with "Fizz", multiples of 5 with "Buzz", and multiples of both with "FizzBuzz". It's not meant to be a challenging algorithmic puzzle; most candidates with basic programming knowledge should solve it without difficulty.

So why does this trivial problem persist in the interview landscape? Because I believe FizzBuzz's true value isn't in filtering out candidates who can't code—it's in opening discussions about complexity, language characteristics, optimisation, and the subtle costs of different operations. The best interviewers don't just ask candidates to solve FizzBuzz; they use it as a starting point for a deeper technical conversation.

A little while ago I set out to find a way to measure the overhead that FQDN filtering places on HTTPS web traffic. I've shared the results here, but I thought I'd take the opportunity to discuss the methodology in a bit more detail.

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 need to allocate a CIDR range for your subnets. There are key differences between these cloud providers when expanding networks, which can create challenges. Knowing these rules from the start helps you plan your CIDR ranges better. I'll start with what's similar across AWS and Azure, then look at the differences.

Make it make sense​

I will always be a network engineer, and that means 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'm 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 '80s. 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'm not sure if it's a Mandela Effect is that I don't really think I've 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. But I think there may be another way.

A Matter of Western Digital Privilege​

In a recent conversation about IPv6 adoption at a Western technology company, I witnessed a familiar scene play 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.

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.

A good friend of mine is taking 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 in his practice exams were a bit confusing. 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 try to explain what the options are and 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.

Introduction​

When working with Azure cloud networking, I've noticed certain limitations, 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. In this post, I'll explore the concept of AZ sharding, its implications for cross-subscription services, and techniques for mapping physical AZs to achieve optimal performance.

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.

Let's explore solutions for global site load balancing.

I was chatting with a friend who's studying for his AZ-700 exam, and he showed me this rather neat way of finding your IP address using Google DNS.

The Mystery Begins​

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. It 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.

My Perspective​

After 20+ years implementing network and cloud infrastructure across finance, retail, healthcare, and public sector, I've seen a clear pattern: cloud success strongly links to an organisation's readiness. Yet surprisingly few organisations do thorough readiness checks before starting their cloud journey.

Lessons from Personal Tech and Enterprise IT​

Notifications and alerts are everywhere in our always-on, connected world. But as I've learned from personal experience and my work in enterprise IT, more alerts don't always mean better outcomes. In fact, too many alerts can be completely counterproductive.

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.

Rethinking Infrastructure Support​

In IT operations, there's a metric that network teams know all too well: Mean Time to Innocence (MTTI). It's how long it takes for a network team to prove they're not responsible for an outage or performance issue. While that might sound funny, it highlights a serious problem in how we structure our infrastructure teams.

The Business Case Challenge

I've found that 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 that I'd like to discuss further.

Is it as great as Microsoft says or as bad as the customers say?​

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'm working on a DHCP migration and discovered the previous admins didn't clean up old scopes when sites closed. It's hard to identify dead scopes from lease numbers since some live sites are rarely used. So I've created a simple script to ping the default gateway to check if the subnet still exists.

The Case for Application-Level Controls

Introduction​

I've noticed that an organisation's approach to securing outbound internet traffic often reflects its 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.

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.

I recently went down the AWS Gateway Load Balancer rabbit hole, and I've found it to be 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 in AWS is often the difficulty in scaling them. You need to distribute traffic, and typically you need a load balancer, but you can't use an ALB or an NLB because unlike Azure, the load balancers in AWS don't allow for traffic routing, so they can't be targets for route tables in the same way Azure load balancers 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.