Author's posts
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 4: Load balance non-HTTP(S) traffic in Azure – Unit 2: Explore Load Balancing
Load balancing is even distro of workloads (inbound traffic) across multiple backend resources/servers. Intended to optimize use, maximize throughput, minimize response time, avoid overloading. Low-key improve availability by sharing workload
- Load Balancing Option for Azure
- Various options available – the primary are
- Azure Load Balancer
- High-perf, ultra low latency L4 load balance (Rx/Tx) for UDP and TCP.
- Can handle millions of request/s
- Zone-redundant
- Traffic Managers
- DNS based allowing for distribution across global regions
- Slower fail over due to being DNS based with TTL’s and DNS caching
- Azure App Gateway
- Provides app delivery controller (ADC) as a service for various L7 capabilities
- Use to optimize web farm productivity offloading CPU intense SSL term to gateway
- Azure Front Door
- App delivery net providing global load balance and site acceleration for web apps
- L7 capabilities for e.g.
- SSL offload
- Path-based routing
- Fast failover
- Caching
- Etc
- Improves perf and HA for apps
- Categorizing Load Balancing Services
- Categorize in global vs regional
- Global
- Distribute traffic across regional backends/clouds/hybrid on-prem
- Route user traffic to closet backend
- React to changes in reliability or perf
- Regional
- Distribute withing VNet across VM’s or zonal & zone redundant endpoints in a region
- HTTP(S) vs non-HTTP(S)
- HTTP(S)
- L7 only accepts HTTP(S) traffic
- Intent for web apps or other HTTP(S) endpoints
- Include features such as SSL offload, web app FW, path-based load balance, session affinity
- Non-HTTP(S)
- Handle non-http(s) traffic recommended for nonweb workloads
- (Table below from MS Learn)
- Choosing a load balancing option for Azure
- Key factors
- Type of traffic
- Is it web app? Public-facing? Private?
- Scope
- Need to load balance VM’s/containers in VNet?
- Load balance across regions? Or both?
- Availability
- Cost
- Op cost to manage/maintain service on top of service itself?
- Visit Load balancing pricing MS page for predicting
- Features/Limitations
- Flow-chart to aid in choice (Pulled from MS Learn site)
- Use flowchart as starting point – evaluate app with multiple workloads with each workload independently
- Selecting a load balancing solution by using the Azure Portal
- Azure Load Balancing page in portal has a help me choose option
- Is a Yes/No questionaire
- Also has a Service Comparison and Tutorial tab including training on solutions
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-explore-load-balancing/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 10: Troubleshoot ExpressRoute Connection Issues
Azure net eng supporting ExpressRoute will have to diag and resolve connection issues.
ExpressRoute connectivity has 3 traditional zones
- Customer Network
- Provider Network
- MS DC
Offered with ExpressRoute Direct (10/100Gbps) customer can connect to MS Enterprise Edge routers directly meaning no provider network zone
- Verify circuit provisioning and state via Azure Portal
- Provisioning ExpressRoute creates redundant L2 connections between CE/PE-MSEE (2)/(4) and MSEE (5)
- Service Key is unique ID for ExpressRoute Circuit – required by partner to tshoot if assistance needed
- Steps
- In Azure Portal find ExpressRoute Circuit
- Under essentials status and enabled values are displayed
- Circuit status = MS side status
- Provider status = Provisions or Not provisioned
- Must be Circuit status:Enabled and Provider status: Provisioned to be operational
- Validate peering config
- Once SP provisions ExpressRoute Circuit, multiple eBGP routing configs possible between Ces/MSEE-Pes and MSEEs as noted above
- Each ExpressRoute circuit can have
- Azure private peering
- Microsoft peering
- Both
- Check peering under the ExpressRoute in Azure Portal
- In IPVPN model, SP handles config of peer (L3)
- After configured if peering blank refresh to pull current routing config from circuit
- Validate ARP
- ARP (RFC 826) is L2 mapping of MAC to IP. Used to validate L2 config and tshoot basic L2 issues
- ARP Table provides mapping for individual peering’s.
- Map of on-prem router int IP to MAC
- Map of ExpressRoute router int to MAC
- Age of mapping ARP can validate L2 config and tshoot basic L2 connectivity
- Next Steps
- Validate L3 config of ExpressRoute Circuit
- Get route summary for BGP status validation
- Get route table to see prefixes advertised via ExpressRoute
- Validate in/out bytes
- Open MS Support ticket if still issues
- ExpressRoute monitoring tools
- Uses Network insights for detailed topo mapping of all ExpressRoute components such as peering’s, connections, gateways). Also has preloaded metrics dashboard for availability, throughput, drops, gateway metrics.
- Analyze metric for ExpressRoute from other Azure services using explorer
- Open Metrics from Azure Monitor menu
- View ExpressRoute metrics: filter by resource type ExpressRoute circuits
- View Global Reach metrics: filter by resource type ExpressRoute circuits > select ExpressRoute circuit that has Global Reach enabled
- View ExpressRoute Direct metrics: filter by resource type > ExpressRoute Ports
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-troubleshoot-expressroute-connection-issues/
Reading Time: < 1 minute
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 9: Improve Data Path Performance Between Networks with ExpressRoute FastPath
FastPath is intended to improve path performance between on-prem and virtual network. Enabling has FastPath send traffic straight to VMs bypassing the gateway
- Circuits
- FastPath is available on all ExpressRoute Circuits
- Gateways
- FastPath still needs Virtual Network Gateway to exchange route between virtual and on-prem networks
- Gateway requirements for ExpressRoute FastPath
- Configuration – Virtual Network Gateway must be
- Ultra-Performance
- ErGw3AZ
- If planned use for IPv6 private peering must be this SKU only available for ExpressRoute Direct circuits
- Limitations
- Does not support
- UDR on gateway subnet: UDR has 0 impact on traffic FastPath sends from on-prem to VMs in a VNet
- Private link: If connecting private endpoint in VNet to on-prem it goes through virtual network gateway
- Configure ExpressRoute FastPath
- Requirements/Worekflow
- Active ExpressRoute Circuit required
- Follow instruction for ExpressRoute circuit and have provider enable
- Make sure Azure private peering configured for circuit
- Make sure Azure private peering configured and successful BGP between network and MS
- Make sure VNet and Virtual Network Gateway fully provisioned using GatewayType ‘ExpressRoute’
- Possible to link up to 10 VNets on standard SKU. All VNets in same geopolitical region when using standard
- Single VNet links up to 16 ExpressRoute Circuits
- If ExpressRoute premium, can link VNets outside of geopolitical region of circuit.
- Allows for more than 10 VNets based on chosen bandwidtch
- To create from ExpressRoute Circuit to target ExpressRoute Virtual Network Gateway
- Address spaces advertised from local/peered VNet must be = or < 200
- Once success can add up to 1000 address spaces
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-improve-data-path-performance-between-networks-with-expressroute-fastpath/
Reading Time: < 1 minute
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 8: Connect Geographically Dispersed Networks with ExpressRoute Global Reach
- Use cross-region connectivity to link multiple ExpressRoute Locations
- Various ways to design/implement ExpressRoute based on org requirements
- ExpressRoute connections allow access to
- Microsoft Azure Services
- Microsoft 365 Services
- Connecity to all regions in geopolitical region
- Connect MS in one peering location and access regions in same geopolitical region
- Global connectivity with ExpressRoute Premium
- Enable premium to extend across geopolitical boundaries
- Local connectivity with ExpressRoute Local
- Transfer data costly using Local SKU
- Bring data to ExpressRoute near Azure region desired
- Data transfer included in ExpressRoute port charge
- Across on-prem connectivity using Global Reach
- Enable ExpressRoute Global Reach to exchange across on-prem sites via connecting ExpressRoute Circuits
- Connect private DCs together through two ExpressRoute Circuits
- Cross DC traffic uses MS network
- Rich partner connection ecosystem
- Connectivity to national clouds
- MS operates isolate clouds for special geopolitical regions and customer segments
- ExpressRoute Direct
- Provides opp to connect direct to MS Global Network using peering locations.
- Offers dual 100Gbps connectivity in active/active
- Is private/resilient connection of on-prem to MS Cloud
- Can access services e.g. Azure and MS 365 from corp DC
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-connect-geographically-dispersed-networks-with-expressroute-global-reach/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 7: Connect an ExpressRoute Circuit to a Virtual Network
ExpressRoute circuits are logical connections between on-prem (or colo) and MS Cloud Services through a provider. Possible to order multiple ExpressRoute circuits with each in the same or difference regions connecting to on-prem via different providers. They don’t map to physical entities. Use a standard GUID: services key (s-key)
- Connect a virtual network to an ExpressRoute circuit
- Must have active ExpressRoute Circuit
- Verify Azure private peering configured on circuit
- Verify Azure private peering establishes BGP between network and MS
- Verify VNet and Virtual Network Gateway created and fully provisioned (virtual network gateway for ExpressRoute is GatewayType ‘ExpressRoute’
- Up to 10 VNets linked on standard ExpressRoute circuit
- All in same geopolitical region when using standard ExpressRoute
- VNet link to max of 16 ExpressRoute circuits
- Same subscription, different subscription, or combo
- If ExpressRoute premium add-on
- Can link VNet outside of geopolitical region of ExpressRoute circuit
- Allows more than 10 VNets to ExpressRoute circuit based on bandwidth selected
- Creating connection to ExpressRoute Circuit target ExpressRoute Virtual Network Gateway address spaces advertised from local to peer VNets = or < 200. Once successfully create can add other addr space up to 1000 to local or peered VNets
- Add a VPN to an ExpressRoute Deployment
- For secure encrypted connection between on-prem and Azure VNets over ExpressRoute private connection. Use MS peering for Site-toSite Ipsec/IKE VPN between on-prem and Azure VNets. Create secure tunnel over ExpressRoute for confidentiality, anti-replay, authenticity, integrity.
- When Site-to-Site over MS peering – charges for VPN gateway and egress
- Can enable HA/Redundancy over multiple tunnels via the 2 MSEE-PE pairs of circuit and enable load balancing
- Tunnels over MS Peering terminate either VPN Gateway or NVA through Azure Marketplace
- Can exchange routes statically or dynamically over tunnels
- Use BGP (difference then BGP session for MS peering) used
- For on-prem side, MS peering typically terminate on DMZ and private peering terminates on core.
- Two zones segregated using FW
- If MS peering exclusively filter through public IP’s of interest
- Steps
- Configure MS peering for ExpressRoute Circuit
- Advertise select Azure regional public prefixes to on-prem over MS peering
- Configure VPN gateway to establish Ipsec tunnels
- Configure on-prem VPN device
- Create Site-to-Site Ipsec/IKE connection
- Optionally: Config FW/Filtering on on-prem device
- Test/Validate Ipsec communication over circuit
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-connect-an-expressroute-circuit-to-a-virtual-network/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 6: Configure Peering for an ExpressRoute Deployment
- Create Peering Configuration
- Configure private or microsoft peering for ExpressRoute circuit
- Configure in any order
- Complete one at a time
- Must have active ExpressRoute circuit
- Must be in provisioned and enabled state
- If using shared key/MD5 hash use on both sides
- Max 25 alphanumeric
- Special Characters not supported
- Choose between private, microsoft, or both for peering options. (Table below from MS Learn)

- Enable one or more routing domains as part of ExpressRoute Circuit
- All routing domains can be put on same VPN if combining into single routing domain is desired
- Recommended config: private peering connected directly to network core, MS peering connected to DMZ
- Each peering require individuals BGP sessions (one pair per peer type)
- BGP session pairs offer HA link
- If L2 connectivity provider you own configuring and managing routing
- Note: IPv6 is in public preview: follow MS IPv6 for Azure VNet for guidelines
- Configure Private Peering
- Azure services – VMs and cloud services in a VNet – can be connected through private peering
- Private peering domain is trusted extension of core network into Azure
- Can create bi-directional connection between core and Azure VNets
- Allows connection to VMs and cloud services over private Ips
- Connect one or more VNets to private peering domain. Limits found at Azure Subscription and Service Limits, Quotas, and Constraints
- Configure Microsoft Peering
- Connection to MS Online Services (MS 365, Azure PaaS) through MS peering
- Offers bidirectional connectivity between WAN and MS cloud services
- Must connect MS Cloud Services ONLY over public IP’s you or your provider own
- Configure route filters for MS Peering
- Route filters used to consume subset of services via MS peering
- MS 365 such as Exchange online, sharepoint online, skype for business accessible via MS peering
- By default all services advertised via BGP session on ExpressRoute circuit
- BGP community is attached to each prefix for indentification
- Possible to limit prefixes added to route table
- Filter unwanted prefixes using route filters on communities
- Define route filters and apply to ExpressRoute Circuit
- New resource letting you select list of services
- ExpressRoute routers only send list of prefixes belonging to identified services in filter
- When MS Peering on ExpressRoute circuit BGP comes up
- By default no routes advertised to your network until route filter associated
- Route filter identifies services you want through ExpressRoute MS Peering
- An allow list of BGP communities
- Once created and applied matching community routes get advertised to you
- To attach route filter, authorization for MS 365 services via ExpressRoute required
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-configure-peering-for-an-expressroute-deployment/
Reading Time: < 1 minute
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 5: Exercise – Provision an ExpressRoute Circuit
Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)
- Task 1: Create and provision an ExpressRoute circuit
- Search and click ExpressRoute Circuits in Azure Portal
- Click Create
- Click Create New under the Resource group dropdown
- Enter a name and click OK
- Select a region from the dropdown
- Provide a name under the Instance details section
- Click Next : Configuration >
- Under Configuration Tab
- Pick a Provider from the dropdown
- Pick a Peering location from the dropdown
- Pick a bandwidth from the dropdown
- Click Review + create
- Once validated click create
- Task 2: Retrieve your Service key
- Search and select ExpressRoute Circuits in Azure portal
- Click the newly created circuit
- Note down the Service key as the provider will need it (copy button next to key)
- Task 3: Deprovisioning an ExpressRoute circuit
- Service provider will deprovision circuit upon request
- Navigate to the ExpressRoute Circuit in Azure Portal
- Verify Provider status as not provisioned
- Click Delete – Deleted will stop billing
- Confirm Yes
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-provision-an-expressroute-circuit/
Reading Time: < 1 minute
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 4: Exercise – Configure an ExpressRoute Gateway
Tasks (taken from MS Learn: Items without “Task” in front of them are personal additions)
- Task 1: Create the virtual network and gateway subnet
- Navigate to Virtual Networks in Azure Portal
- Click Create
- Select Create new under Resource group dropdown
- Enter Name under Instance Details
- Select Next : IP Addresses >
- Delete existing default address space (trash can icon next to addr range
- Add new addr range
- Select Add subnet
- In right panel add subnet name
- In right panel add subnet addr range
- In right panel click Add
- Select Review + create
- Once validated select Create
- Task 2: Create the virtual network gateway
- Search and Click Virtual Network Gateways in Azure Portal
- Click Create
- Enter Name under Instance details
- Select ExpressRoute for Gateway type under Instance Details
- Select VNet from dropdown under Instance details
- Enter Public Ip address name under Public IP address section
- Click Review + create
- Once validated click Create
- Once complete click Go to resource
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-exercise-configure-an-expressroute-gateway/
Reading Time: 2 minutes
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 3: Design an ExpressRoute Deployment
ExpressRoute used to connect on-prem with Azure. Plan decisions prior to deployment of an ExpressRoute Circuit
- ExpressRoute Circuit SKUs
- Three SKUs have different charges
- Local SKU
- Automatically charged Unlimited Data Plan
- Standard SKU
- Select Between Metered or Unlimited Data Plan
- Ingress are free except when using Global Reach
- Premium SKU
- Select Between Metered or Unlimited Data Plan
- Ingress are free except when using Global Reach
- Use Azure Pricing Calculator to estimate costs
- Choose a Peering Location
- Azure Region
- Global DCs housing Azure computer/network/storage resources
- Resource Location determins Azure DC or availability zone created in
- ExpressRoute Location (Peering Location)
- May be called Peering Location or Meet-me-location
- Colo where MS Enterprise Edge (MSEE) devices live
- Entry point to MS network – globally distributed allowing connectivity to MS network around the world
- Where ExpressRoute partners and ExpressRoute Direct customers cross-connect to MS network
- Azure regions to ExpressRoute location in geopolitical region
- ExpressRoute Connectivity Provider
- Connectivity through Exchange providers
- If connectivity provider not listed in above, still able to create connection
- Several providers already connected to Eth exchanges
- Connectivity through satellite operators
- Remote and no fiber
- Want to explore other options
- Other options
- Other service providers
- DC providers
- National Research and Education Networks (NERN)
- System integrators
- Choose the Right ExpressRoute Circuit and Billing Model
- MS various Express Route options based on desired bandwidth. Evaluate current usage as a starting point
- Deterring ExpressRoute based on requirements: keep in mind budge/SLAs
- Choose appropriate SKU and if applicable Metered vs Unlimited within the SKU
- Consider ExpressRoute Direct
- Connects network to closet MS Edge which connects to MS Global Network
- Usage of Global MS Network charged on top of ExpressRoute Direct
- Express Route pricing for metered and unlimited bandwidth details
- Available in range of bandwidths – check with provider for what they support
- Choose a billing model
- Unlimited
- Billing based monthly
- All Inbound/Outbound included
- Metered
- Billing based on monthly fee. Inbound free, Outbound per GB
- Rates vary by region
- ExpressRoute Premium add-on
- Additional Capabilities
- Increased route limits for Azure public/private peering from 4k to 10k routes
- Global connectivity for services. Circuit in any region (exclude national clouds) has access to resource in any other region
- Increased VNet links per ExpressRoute circuit from 10 based on bandwidth
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-design-an-expressroute-deployment/
Reading Time: 3 minutes
Notes from MS Learn AZ-700 Module 3: Design and Implement Azure ExpressRoute – Unit 2: Explore Azure ExpressRoute
ExpressRoute extends on-prem to Microsoft cloud via private connection with assistance of a provider. Creates connections to MS Cloud Services like Azure and MS 365. It can be any-to-any (IP VPN), point-to-point Ethernet, or virtual cross-connect through provider colo. Since no internet ExpressRoute connections are more reliable, faster, latency consistent, higher security.
- ExpressRoute Capabilities
- Key benefits
- L3 connection between on-prem and MS Cloud via provider
- Can be any-to-any (IPVPN), Point-to-Point Ethernet, Virtual Cross-Connect through an Ethernet Exchange
- Connection to MS Cloud Services over all regions in a geopolitical region
- Global connectivity to MS across all regions (with ExpressRoute premium)
- Built-in redundancy in every peering location
- Used to create private connectivity between Azure DC/infrastructure on-prem or a colo
- Increased reliability, speed, and lower latency since it doesn’t go over the internet
- Understand Use Cases for Azure ExpressRoute
- Faster/Reliable connection to Azure
- Not reliant on internet
- Can be cheaper for on-prem or colo facility data transfer to Azure
- Storage/Backup/Recovery
- Gast Reliable connection to Azure
- Bandwidths up to 100 Gbps
- Great for periodic data migration/replication/DR/addition HA strategy
- Extend DC Capabilities
- Connect and add computer/storage capacity to existing DCs
- High throughput and low latencies feel like natural extension
- Predictable/reliable/high throughput connectivity
- Build apps that span on-prem and Azure without compromising privacy/performance
- Example run intranet app in Azure with auth against on-prem AD
- Corp customers don’t have to route over public internet
- ExpressRoute Connectivity Models
- Many models available for on-prem/colo to the cloud in Azure. Examples
- Co-location at Cloud Exchange
- Facility with cloud exchange virtual cross-connects to MS cloud from providers Ethernet exchange
- Colo provider offer either L2 or managed L3 cross connection between infrastructure and MS Cloud
- Point-to-Point Ethernet
- Provider can offer L2 or L3 between on-prem and MS Cloud
- Any-to-Any (IPVPN)
- Provider offer any-to-any between branch offices and DCs
- MS Cloud can be interconnected to your WAN to look as a branch office
- WAN provider typically offer manage L3
- Direct from ExpressRoute
- Dual 100 GbPS or 10Gbps
- Active/Active at scale
- Design Consideration for ExpressRoute Deployments
- Choose model based on key considerations
- ExpressRoute Direct
- Connects direct to MS global network at peering location (distributed around world)
- Dual 100 or 10 Gbps
- Active/Active
- Can work with any SP for ExpressRoute Direct
- Features
- Massive Data Ingest into services E.g. Storage and Cosmos DB
- Physical isolation for regulated industries E.g. Bank, Gov, Retail
- Granular control of circuit distribution per business unit
- ExpressRoute Direct vs. Service Provider (Table from MS Learn)
- Design Redundancy for an ExpressRoute deployment
- Two ways to plan redundancy
- Configure ExpressRoute and Site-to-Site coexisting
- Advantages
- Secure failover path for ExpressRoute
- Connect to sites not connected through ExpressRoute
- Zero downtime when adding new gateway or gateway connection
- Network Limits and limitations
- Route-Based VPN gateways only
- ASN of Azure VPN Gateway must be 65515
- Gateway subnet must be /27 or shorter
- Dual stack VNet not supported
- Create zone redundant virtual network gateway in Azure Availability Zones
- VPN and ExpressRoute gateways can be deployed in Availability Zones
- This physically and logically separates gateways in a region
- Protects on-prem to Azure from zone-level failures
- Zone-redundant gateways
- Automatically deploy virtual network gateways across availability zones by using zone-redudant virtual gateways.
- These benefit from zone-resiliency for mission critical services in Azure
- Zonal Gateways
- Used to. Deploy gateway in specific zone
- When deployed, all instance deployed in same Availability Zone
- Gateway SKUs
- SKUs similar to corresponding existing SKKUs for ExpressRoute and VPN Gateway
- Exception: they are specific SKU’s identifiable by AZ in SKU name
- Public IP SKUs
- Both Zone-redundant and Zonal GW require Azure Public IP resource Standard
- Configure a Site-to-Site VPN as a Failover Path for ExpressRoute
- Applies only to VNets linked to Azure private peering path
- No VPN-based failover for services reachable through Azure MS Peering
- ExpressRoute circuit always primary
- Data through Site-to-Site VPN only if ExpressRoute circuit failure
- Avoid asymmetrical routing, local config should also prefer ExpressRoute over Site-to-Site path
- Set higher local pref to ExpressRoute received routes
Permanent link to this article: https://www.packetpilot.com/microsoft-az-700-explore-azure-expressroute/
Load more