Skip to content

Guidance on which ASN to use (Public/Private/Reserved) when using the Virtual WAN Route-Maps feature for outbound prepend over ExpressRoute

Notifications You must be signed in to change notification settings

adstuart/azure-vwan-routemaps-asn

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 

Repository files navigation

Azure Virtual WAN Route-Maps ASN guidance

Introduction

Customers making use of the Virtual WAN route-maps feature (currently in public preview), for the purposes of AS-path-prepend outbound (towards On-Premises) via ExpressRoute, will expect that ASNs added to the path are preserved and sent to their CPE (connected to MSEE). They will use this behaviour to influence how their On-Premises networks send traffic to Azure. The most common scenario is shown below, and is an alternative to the traditional method of On-Premises Route Manipulation (typically by applying Local Preference to routes when they come inbound to Customer CPE).

This behaviour relies on the AS-Path-prepend intent defined within the Virtual WAN Hub Route-Maps feature propagating all the way to the customer CPE, in other words, the AS-path added by the VWAN Hub, needs to remain appended to the route, as it leaves the Microsoft network (via the MSEE) outbound over the ExpressRoute Private Peering.

The core message of this short tech note, is to provide guidance as to which AS Number (ASN) to use for this scenario, and which ASN will be preserved when leaving the Microsoft Edge Router (MSEE).

Note this article is specific to ExpressRoute, and does not apply to VPN connected branches that may be using BGP.

TL;DR

You need to use a Public ASN when prepending with the Route-Maps feature, otherwise this will get stripped by MSEE. This article offers the possible use of Reserved Public ASN for this purpose.

ASN Testing

Private ASN

Here a short test to show that Private ASN are stripped when using them within the context of this article.

VWAN Route-Map Rule, Prepend ASN 64500 64500 64500

Route is propagated to MSEE

Route is not propagated to customer (Note AS path is only AS 12076)

ASN 12076

What about ASN 12076, the Azure ASN? Its a public ASN, can we not use that? No, as per Route-maps docs this is prohibited, and causes traffic blackhole.

VWAN Route-Map Rule, Prepend ASN 12076 12076 12076_

Route is not propagated to MSEE, as it sees its own ASN in the path, and rejects it as per normal BGP loop prevention.

A "normal" Public ASN

Here we see a regular ASN (E.g. 1234) behaving as expected. The challenge here however, is, "what ASN would I pick?". If a customer uses their own ASN, their CPE will reject the route (same logic as previous section on 12076). If they cannot use their own ASN, then they must pick one randomly, and this is "bad bgp behaviour" as it will belong to another company somewhere in the world, and you could imagine corner cases where this route leaking around an Enterprise network might cause a very tricky issue to unpick.

But, for completeness, lets show this working anyway:

_VWAN Route-Map Rule, Prepend ASN 1234 1234 1234 _

Route is propagated to MSEE

Route is propagated to customer with prepend (Assuming of course they are not ASN 1234 themselves)

A possible solution - Reserved Public ASN

As per RFC 5398 there is a block of ASN that are classified by routers as "Public", and are reserved for documentation/testing use. These ASN are in the range 64496 - 64511, and guaranteed to not overlap with either existing customer Public ASN, or any "normal" Public ASN used within the "Internet".

NB. Whilst unlikely, you should ensure that these ASN are not already in use within your private Enterprise network.

The captures below show a Route-Maps prepend with ASN 64500 successfully propagating fully through to On-Premises.

_VWAN Route-Map Rule, Prepend ASN 1234 1234 1234 _

Route is propagated to MSEE

Route is propagated to customer with prepend (Assuming of course they are not ASN 1234 themselves)

Appendix A - Combinations of Public and Private ASN

Examples of this behaviour are documented by some popular networking vendors

E.g. Juniper here

VWAN Route-Map Prepend: <no prepend>
Observed AS Path OnPremise: 12076

VWAN Route-Map Prepend: 65113,65111,65112,65113
Observed AS Path OnPremise: 12076

VWAN Route-Map Prepend: 1234,1234,1234
Observed AS Path OnPremise: 12076 1234 1234 1234

VWAN Route-Map Prepend: 65113,1234,65111,65112,65113
Observed AS Path OnPremise: 12076 1234 65111 65112 65113

VWAN Route-Map Prepend: 65113,65113,1234,65111,65112,65113
Observed AS Path OnPremise: 12076 1234 65111 65112 65113

VWAN Route-Map Prepend: 1234,65111,65112,65113
Observed AS Path OnPremise: 12076 1234 65111 65112 65113

E.g. Cisco here

VWAN Route-Map Prepend: <no prepend>
Observed AS Path OnPremise: 12076

VWAN Route-Map Prepend: 65113,65111,65112,65113
Observed AS Path OnPremise: 12076

VWAN Route-Map Prepend: 1234,1234,1234
Observed AS Path OnPremise: 12076 65515 1234 1234 1234

VWAN Route-Map Prepend: 65113,1234,65111,65112,65113
Observed AS Path OnPremise: 12076 65515 65113 1234 65111 65112 65113

VWAN Route-Map Prepend: 65113,65113,1234,65111,65112,65113
Observed AS Path OnPremise: 12076 65515 65113 65113 1234 65111 65112 65113

VWAN Route-Map Prepend: 1234,65111,65112,65113
Observed AS Path OnPremise: 12076 65515 1234 65111 65112 65113

About

Guidance on which ASN to use (Public/Private/Reserved) when using the Virtual WAN Route-Maps feature for outbound prepend over ExpressRoute

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published