ExpressRoute: design, peering and BGP

This lab has two parts. Part A uses the real Azure CLI and reads only public information at no cost. Part B builds a BGP session like ExpressRoute private peering on your laptop.

1Part A: find providers at a peering location

List the providers that offer ExpressRoute at Chennai:

az network express-route list-service-providers --query "[?contains(join(',', peeringLocations), 'Chennai')].name" -o tsv

You should see a list of provider names, something like this (the list changes over time):

Airtel
Sify
Tata Communications
...

Picking a location close to your data centre and a provider that serves your building is the first real decision in any ExpressRoute project.

2Part A: what creating a circuit looks like (simulated)

Don’t run this on a free account; it starts billing at once. This is the command and the kind of output you’d see:

az network express-route create --resource-group rg-saat-hub --name er-saat --bandwidth 50 --peering-location Chennai --provider Airtel --sku-family MeteredData --sku-tier Standard --query "{key:serviceKey, provider:serviceProviderProvisioningState, status:circuitProvisioningState}"

Simulated output:

{
  "key": "a1b2c3d4-....-....-....-............",
  "provider": "NotProvisioned",
  "status": "Enabled"
}

You send the key to the provider. When they finish, provider changes to Provisioned. Only then can you configure private peering with your ASN, two /30 subnets and a VLAN ID.

3Part B: build the BGP lab on your laptop

In Ubuntu 24.04 (WSL or VirtualBox), install FRRouting:

sudo apt update && sudo apt install -y frr

Save this script as er-lab.sh. It creates two routers on your laptop: msee plays Microsoft’s edge (ASN 12076, advertising the hub and spokes) and ce plays your edge router (ASN 65010, advertising the office 10.80.0.0/16):

#!/bin/bash
# SaatVedha Azure Lesson 50: simulated ExpressRoute private peering (primary link)
# msee = Microsoft edge (ASN 12076, 172.16.0.2), ce = your router (ASN 65010, 172.16.0.1)
set -e
LAB=/var/lib/frrlab
ip addr add 172.16.0.1/32 dev lo 2>/dev/null || true
ip addr add 172.16.0.2/32 dev lo 2>/dev/null || true
mkdir -p $LAB/msee $LAB/ce

cat > $LAB/msee/frr.conf <<'CONF'
frr defaults traditional
hostname msee
router bgp 12076
 bgp router-id 172.16.0.2
 no bgp ebgp-requires-policy
 no bgp network import-check
 neighbor 172.16.0.1 remote-as 65010
 neighbor 172.16.0.1 update-source 172.16.0.2
 neighbor 172.16.0.1 disable-connected-check
 address-family ipv4 unicast
  network 10.40.0.0/16
  network 10.41.0.0/16
  network 10.42.0.0/16
 exit-address-family
CONF

cat > $LAB/ce/frr.conf <<'CONF'
frr defaults traditional
hostname ce
ip prefix-list ONPREM seq 10 permit 10.80.0.0/16
route-map AZURE-OUT permit 10
 match ip address prefix-list ONPREM
route-map AZURE-IN permit 10
router bgp 65010
 bgp router-id 172.16.0.1
 no bgp network import-check
 neighbor 172.16.0.2 remote-as 12076
 neighbor 172.16.0.2 description er-primary
 neighbor 172.16.0.2 update-source 172.16.0.1
 neighbor 172.16.0.2 disable-connected-check
 address-family ipv4 unicast
  network 10.80.0.0/16
  neighbor 172.16.0.2 route-map AZURE-IN in
  neighbor 172.16.0.2 route-map AZURE-OUT out
 exit-address-family
CONF

chown -R frr:frr $LAB
for r in msee ce; do
  ip=$([ $r = msee ] && echo 172.16.0.2 || echo 172.16.0.1)
  /usr/lib/frr/bgpd -d -Z -l $ip -f $LAB/$r/frr.conf -i $LAB/$r/bgpd.pid --vty_socket $LAB/$r -P 0
done
echo "Lab started. Wait 10 seconds, then check the session."

Look at the ce config: it only advertises what the ONPREM prefix list allows, which is how real routers stop you leaking your whole network to Microsoft. The disable-connected-check lines exist only because both routers live on one laptop.

Run it:

sudo bash er-lab.sh

4Check the session like an engineer

Wait 10 seconds, then read the summary and the routes on your router:

sudo vtysh --vty_socket /var/lib/frrlab/ce -c 'show ip bgp summary'
sudo vtysh --vty_socket /var/lib/frrlab/ce -c 'show ip bgp'

You should see this (timers and counters will differ):

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
172.16.0.2      4      12076         9         7        0    0    0 00:00:09            3        1 er-primary

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.40.0.0/16     172.16.0.2               0             0 12076 i
*> 10.41.0.0/16     172.16.0.2               0             0 12076 i
*> 10.42.0.0/16     172.16.0.2               0             0 12076 i
*> 10.80.0.0/16     0.0.0.0                  0         32768 i

Read it like this: the session to 172.16.0.2 is up (a timer, not a state word), 3 prefixes received from AS 12076, 1 sent. The VNet routes have path “12076 i”, meaning they came from Microsoft.

5See what Microsoft sees

Check the msee side, which is what Azure shows you with list-route-tables:

sudo vtysh --vty_socket /var/lib/frrlab/msee -c 'show ip bgp'

You should see this:

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.40.0.0/16     0.0.0.0                  0         32768 i
*> 10.41.0.0/16     0.0.0.0                  0         32768 i
*> 10.42.0.0/16     0.0.0.0                  0         32768 i
*> 10.80.0.0/16     172.16.0.1               0             0 65010 i

On a real circuit, the same check from Azure is:

az network express-route list-route-tables --resource-group rg-saat-hub --name er-saat --peering-name AzurePrivatePeering --path primary -o table

It lists the routes the MSEEs learned from you on the primary link, with your ASN in the path. Run it with secondary too; both links should match.

✅ Checkpoint: The session is up, ce receives 3 Azure prefixes and msee receives 10.80.0.0/16 from AS 65010.