Azure Private Peering Configuration

Azure ExpressRoute Private Peering is the peering type that carries traffic to your Virtual Networks (VNets). This article documents the Tata Communications-side delivery parameters and the handoff to your CPE.

On the default L3VPN delivery, two BGP sessions are established per circuit to the two MSEE routers, on C-tag 113, and they run between the Tata Communications MPLS PE and Microsoft's edge – you reach Private Peering across the L3VPN and do not peer with the MSEE directly. In the Azure portal you configure Azure Private Peering with Peer ASN 4755 (the Tata Communications edge) and the Tata Communications-allocated /30 subnets. Microsoft's ASN (12076) applies to the PE <--> MSEE session; MD5 is optional.

Tata Communications-side delivery parameters

On the default L3VPN delivery these parameters are configured by Tata Communications on the PE <--> MSEE sessions. You do not configure a BGP session to the MSEE; in the Azure portal you set Azure Private Peering to Peer ASN 4755 with the allocated /30 subnets, and you exchange routes with the Tata Communications L3VPN.

Parameter	Value
C-tag (VLAN)	113 (standard allocation for Private Peering)
Microsoft ASN	12076 (fixed)
Tata Communications ASN	4755 (fixed)
BGP transit subnet	/30 private, allocated by Tata Communications
MD5 BGP authentication	Optional; provided by the customer and shared on both sides if used
BFD timer	300 ms hello × 3 multiplier
Route limit (Standard SKU)	4,000 advertised prefixes on Private Peering
Route limit (Premium SKU)	10,000 advertised prefixes on Private Peering
BGP sessions per circuit	2 (one per MSEE for redundancy)

C-tag 113 applies to Private Peering by standard agreement between Tata Communications and Microsoft. A different C-tag (from the 2–4094 range) can be allocated on request.

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 customer ASN
Authentication	MD5 with a shared key, identical on both sides (if used)
VLAN tagging	C-tag 113 on each peering sub-interface
Outbound prefix policy	Advertise only your on-premises prefixes intended for VNet access
Inbound prefix policy	Receive VNet CIDRs
BFD	300 ms × 3

In the L2VPN model you own the ASN and both MSEE sessions, and manage failover between them.

Path control between primary and secondary

Microsoft presents the redundant ExpressRoute circuit as active/active. Tata Communications applies BGP attributes to make one path primary and the other a standby, so traffic is predictable. Tata Communications makes one path primary and the other standby on its side, and aligns the preference with your on-premises routing policy – agree the intended behaviour with your account team.

Common configuration mistakes

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

VLAN tag mismatch – confirm C-tag 113 on your sub-interfaces (or the non-default C-tag you requested) on both sides.
MD5 key mismatch – if MD5 is enabled, sessions silently fail to establish unless the key is identical on both sides.
ASN mismatch – the remote ASN must be exactly 12076; your local ASN must match the value you set in the Azure portal.

What’s on the Azure side

Configured in your Azure portal:

Private Peering on the ExpressRoute circuit (primary/ secondary subnet, VLAN, peer ASN, MD5 shared key);
VNet Gateway provisioning and connection to the circuit; and VNet route-table configuration for ExpressRoute-learned routes.