19 posts tagged with "Azure"

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.

This is a pretty niche feature preview and you can find the official documentation 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 you can do.

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.

Make it make sense​

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

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

Introduction​

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.

What to do about global site load balancing.

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

My Perspective​

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.

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.

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.

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.

Not all FQDN filters are built the same.

The glue you never knew you needed.

Introduction​

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.