What Is Azure Route Server?
Coming from the world of enterprise networking, I’ve longed for the ability to do actual routing in Azure. Really actually have control of where packets go. Not just user defined route tables and automagical Azure mystery system routes (see quick thought on SQL Managed Instances here). I want to peer with something, change metrics, see actual route tables, do routing stuff!
The Azure Route Server that recently came out of preview doesn’t let you do all of that stuff, BUT it is a step in the right direction! It’s a bit limited but I’ve found a good use case for it. So far, it’s working great.
So, why would we really need more control anyway? The magical stuff is nice, and most of the time Azure does a perfectly adequate job of getting stuff from point A to place B without much fussing on our part. But there are times that you want to take back the reigns.
A few scenarios where we need more control:
New network visibility:
If a new VNet is added to the infrastructure, I want my network appliances (NVAs) to know about it. In order for my firewall to deal with any new networks, I have to create static routes. I can use BGP with ExpressRoute, but not on my VPN backups. Yes, you can do this just fine with Azure’s Virtual Network Gateway but that’s not an NVA. Don’t get me started on Azure’s firewall ‘appliance’.
Changes in topology:
This is obvious since that’s generally the whole point of a routing protocol. If a VPN gateway goes down, or network on the other side of an ExpressRoute drops I want traffic to use a different path.
Default routing:
Azure can easily become Internet Swiss cheese. Each VNet can, by default, just get to “The Internet”. I don’t want that. I want all data leaving to go out to where I want it to go out. If my firewall can’t see it, I don’t know what’s happening and I can’t inspect what’s coming back. Some exceptions exist of course, but as a general rule of thumb I want to see it all.
Less user interaction:
The less I need to use a UDR and place static routes in my infrastructure, the better. And the less that someone else needs to do to deploy their stuff, also better. Azure is a playground for developers to do all sorts of nifty important things, and I don’t want them to have to worry about routing. I also don’t want them breaking everything. We need to install little bumpers on the sharp edges so no one gets hurt.
Azure Route Server doesn’t present itself as a full routing protocol implementation. At least in your ability to configure it.
Capabilities
It does introduce some nice new capabilities, these are the ones I care about:
ECMP – (Equal Cost Multipath):
You can advertise multiple equal cost routes to the same destination. Think of multiple egress NVAs or high availability.
Branch to Branch route exchange:
Strikingly similar to what Azure Virtual WAN is doing 🙂 This allows you to use Azure as a transit between two remote sites. Either with ExpressRoute or VPN.
AS Path Prepending:
It’s BGP. Path prepending is the go-to easy method to setup secondary routes
Funky Things I Learned
The Azure Route Server isn’t in the data-path. It’s a control plane device. It sort of acts like a BGP route reflector. The odd thing is that even though packets don’t actually flow through it, the route tables show the Route Server as the next hop. Another case of where we don’t’ REALLY know what’s going on behind the scenes. We just have to trust that it isn’t in the data path and therefore won’t end up being a bottleneck.
You can’t use ARS to control intra-VNet traffic. So subnet to subnet within the same VNet. System routes still rule there. You assign a subnet to a UDR and use static routes, but you can’t force subnet to subnet traffic to go through an NVA using the ARS. That’d be nice.
I’m going to be using this feature more. It will allow me to simplify templates, have more control, and prevent misconfigurations.
In a later post I’ll get into how I set this up and use it.
More info on Azure Route Server here
