Azure Microsoft Peering Configuration

Microsoft Peering is the Azure ExpressRoute peering type for reaching Microsoft public services (Microsoft 365, Dynamics 365, Azure Storage public endpoints). This article documents the Tata Communications-side delivery parameters and the handoff to your CPE.

Microsoft Peering requires a public ASN that your organisation owns and public IP space registered to your organisation. Tata Communications allocates a /30 non-routable public BGP transit subnet and a /32 for NAT/PAT, both on C-tag 115. The customer’s public IP must be whitelisted by Microsoft before the BGP session can come up. On the default L3VPN delivery, Tata Communications runs the EBGP to the MSEE; your public ASN and public prefixes are still required so Microsoft can validate the advertised routes as yours.

Tata Communications-side delivery parameters

Parameter	Value
C-tag (VLAN)	115 (standard allocation for Microsoft Peering) (or a preferred C-tag from 2–4094 on request)
Microsoft ASN	12076 (fixed)
Tata Communications ASN	4755 (fixed)
Customer ASN	Public ASN required (registered to your organisation)
BGP transit subnet	/30 non-routable public, allocated by Tata Communications
CPE IP	/32 non-routable public, allocated by Tata Communications
MD5 BGP authentication	Optional; shared on both sides if used
BFD timer	300 ms hello × 3 multiplier
Route limit	200 advertised prefixes per BGP session

Whitelisting requirement

The customer public IP (the /30 for WAN-EBGP and the /32 for NAT/PAT) must be whitelisted by Microsoft before the EBGP session for Microsoft Peering can be established. Coordinate this with Tata Communications during provisioning – until whitelisting completes, the session stays in Idle or Active.

If your circuit is delivered as L2VPN

Most circuits are delivered as L3VPN, where Tata Communications runs the BGP to Microsoft and there is no CPE-to-MSEE session to configure. Where your circuit is instead delivered as a point-to-point L2VPN (an EoMPLS pseudowire), you run BGP from your CPE directly to Microsoft's edge. In that case apply, per your CPE vendor's configuration:

Behaviour	What to apply
BGP neighbours	Two – one per MSEE router IP allocated by Tata Communications
Remote ASN	12076 (Microsoft)
Local ASN	Your public ASN
Authentication	MD5 with a shared key (if used)
VLAN tagging	C-tag 115 on each peering sub-interface
Outbound prefix policy	Mandatory – restrict advertisements to public IPs owned by your organisation
Inbound prefix policy	Receive Microsoft public-service prefixes (selection controlled by route filters)
BFD	300 ms × 3

Common configuration mistakes

These apply where you configure the CPE session (L2VPN delivery).

Customer ASN not public – Microsoft Peering will not establish with a private ASN. Verify your ASN registration before provisioning.
Public IP not whitelisted – sessions stay in Idle or Active until whitelisting completes.
VLAN mismatch – confirm C-tag 115 on your sub-interfaces.

What’s on the Azure side

Configured in your Azure portal:

Microsoft Peering on the ExpressRoute circuit (primary/secondary subnet, VLAN, peer ASN, MD5, advertised public prefixes);
route-filter creation and rule selection (which Microsoft services to receive, identified by BGP community values);
and IRR records, which Microsoft validates so advertised prefixes are registered to your ASN.

For the BGP community values and route-filter mechanics, see Microsoft’s route-filter reference.