I’ve been trying to piece all this together and get a single, concise blog post that covers all bases around the changes that have happened and are going to be happening for Microsoft ExpressRoute peering. That’s been a bit of a challenge because, I hope I don’t harp on this too much, but, communication could be a bit better from the product group team. With that said, though, it’s no secret for those that use ExpressRoute, Microsoft is looking to simply it’s configuration. Good news I guess?

The main change that I’m going to delve into here comes by way of merging Microsoft Peering and Public peering into a single Microsoft Peer. Microsoft announced this at the Ignite 2017 conference:

“To simplify ExpressRoute management and configuration we merged public and Microsoft peering” ¹.

Fast forward from September 2017, there’s not been much communication around this shift in ExpressRoute config. I’ve been scouring the interwebs for publicly available confirmation; and all I could find is a blog post ² that highlighted that:

“As of April 1, 2018, you cannot configure Public peering on new ExpressRoute circuits."

Searching the Twitterverse for the hashtag #PublicPeering, we get the following confirmation only a few days later on April 5th:

“Its official..client tried to add #PublicPeering to their #Azure #ExpressRoute, #deprecated! Use #MicrosoftPeering with #routeFilters for dedicated connectivity to #Microsoft #PaaS and #SaaS services. https://t.co/BYBamp0B6b Microsoft @Azure #Networking” - Sam Murcio

So, we have confirmation that this change in ExpressRoute Public peering is happening; followed by a confirmation that as of April 1st, 2018 (no this wasn’t a joke), any new ExpressRoute circuits provisioned on or after that April fools date cannot have Public Peering. Well, given the breadth of Microsoft, communication is in a grey area. Apart from that Japanese TechNet blog post, there’s really only suggestions and recommendations budging customers to Microsoft peering. Here’s two examples:

1. Microsoft peering is the preferred way to access all services hosted on Azure. (Source)
2. All Azure PaaS services are also accessible through Microsoft peering. We recommend you to create Microsoft peering and connect to Azure PaaS services over Microsoft peering. (Source)

I know I’m banging on about this for too long, but, for me this is a grey area and better communication is required!

Migration

If you’re currently using Public peering and need to move to Microsoft peering, there’s some pretty good guidance from Microsoft on how to Migrate - available here.

NOTE: Microsoft peering of ExpressRoute circuits that were configured prior to August 1, 2017 will have all service prefixes advertised through Microsoft peering, even if route filters are not defined. Microsoft peering of ExpressRoute circuits that are configured on or after August 1, 2017 will not have any prefixes advertised until a route filter is attached to the circuit. (Source)

For many customers, and recently a customer I’ve been working with, they’ve had ExpressRoute for several years now. This change has culminated in some interesting circumstances. For this customers migration process, they were actually after upgrading to a faster network carriage and faster ExpressRoute circuit. This meant we could line up the new environment in parallel to the legacy and in configuring peering on the new service, we just configured it as Microsoft Peering only, no more Public peering.

This is all well and good, but, using a legacy ExpressRoute circuit that was configured in ASM/Classic, there’s now also the consideration of Route Filters. In the legacy or Classic ExpressRoute deployment, BGP Communities were not used. Routes were advertised as soon as the peer came on line and, ARP done and eBGP session established between Azure and the customer.

In the ARM ExpressRoute deployment model, Azure Route Filters ³ are a requirement for Microsoft peering (only). Note that this is an Azure side config, not a customer side which can confuse people when talking BGP Route Filters. Similar concept, similar name, much confuse.

ExpressRoute Microsoft peering, out of the box, no routes are advertised from Azure to the customer until such time that a Route Filter is associated with the peer. Inside of that Route Filter, BGP Community tags for the relevant services also need to be defined.

Again, just need to highlight that Route Filters are only required for Microsoft Peering, not for Private peering.

Here’s a few more relevant references to ExpressRoute, Route Filters and BGP Communities:

• https://docs.microsoft.com/en-us/azure/expressroute/expressroute-routing
• https://support.office.com/en-us/article/using-bgp-communities-in-expressroute-for-office-365-scenarios-9ac4d7d4-d9f8-40a8-8c78-2a6d7fe96099?ui=en-US&rs=en-US&ad=US
• https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2?ui=en-US&rs=en-US&ad=US#bkmk_exo

Changes to Azure AD

Recently Microsoft gave everyone that used ExpressRoute public peering about a 45-day notice that from August 2018 Azure AD authentication and authorisation traffic will no longer be routable via Public peering. This functionality is still available if you use Office 365 over ExpressRoute, simply create a Route Filter and assign the BGP Community “Other Office 365 Services”.

To get access to that BGP Community, its much like any Office 365 service being accessed via ExpressRoute- that will need to have your Microsoft TAM approve the request as the Microsoft stance on using ExpressRoute for Office 365 traffic seesaw has swung again in the “you should really use the internet for Office 365, unless maybe Skype for Business/Teams latency is a problem”- again this is my experience.

Summary

• ExpressRoute public peering has been on the radar to be deprecated for some time now
• If you create new ExpressRoute circuits in parallel to your legacy ones, don’t expect to have the new ones work the same as legacy
  • I’ve even had the Azure product group “restore service” on a ASM/Classic ExpressRoute circuit that had Public peering, which did not restore service at all
  • We essentially spun up Microsoft peering and added the relevant Azure Route Filter
• ARM ExpressRoute
  • Microsoft Peering has merged with Public peering so Microsoft peering does everything it did before + Public peering
  • Microsoft Peering requires RouteFilters to be applied to advertise routes from Azure to the customer
    • BGP Community tags are used inside of RouteFilters
  • As of August 1st 2018, ExpressRoute Public peering will no longer advertise Azure AD routes
    • This can be accessed via Microsoft Peering, using a Route Filter and the BGP Community tag of “Other Office 365 services”
  • No changes to Private peering at all - woohoo! (as of the date of writing this blog)
• ASM/Classic ExpressRoute
  • You can’t provision a Classic ExpressRoute circuit anymore
  • If you have one, you’ve likely been bumped up to ARM, given the ASM portal is deprecated
  • Legacy ExpressRoute circuits that have been in-place since prior to August 1 2017, enjoy it while it lasts!
    • Any changes that you might need may be difficult to arrange- you’ll likely need to change the service to comply to current standards

Enjoy!