AZ-700 Azure Networking

Azure Provided DNS Namespace

.internal.cloudapp.net.

Forced tunneling

Forced tunneling lets you redirect or "force" all Internet-bound traffic back to your on-premises location via a Site-to-Site VPN tunnel for inspection and auditing.

Enable Service Endpoint

1. Turn off public access to the service. 2. Add the Service Endpoint to a virtual network.

Supported Redirect types

301 Permanent Redirect 302 Found 303 See Other 307 Temporary Redirect

Service Tags

A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules.

Configure a LB

Add backend pool Add VMs to backend pool Add health probes Add LB rule

DDoS Adaptive real-time tuning

Automatic learning of per-customer (per- Public IP) traffic patterns for Layer 3 and 4. Minimizing false positives, considering that the scale of Azure allows it to absorb a significant amount of traffic.

Choosing between Azure Application Gateway v2 and Web Application Firewall V2 SKUs

Autoscaling: With autoscaling enabled, the Application Gateway and WAF v2 SKUs scale up or down based on application traffic requirements. Minimum capacity ensures that Application Gateway and WAF v2 don't fall below the minimum instance count specified, even in the absence of traffic. Manual: You can alternatively choose Manual mode where the gateway won't autoscale. In this mode, if there is more traffic than the Application Gateway or WAF can handle, it could result in traffic loss. With manual mode, specifying instance count is mandatory. Instance count can vary from 1 to 125 instances.

Azure Private Link

Azure Private Link enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a Private Endpoint in your virtual network.

Services you can use with Service Endpoints

Azure Storage Azure SQL Database Azure Cosmos DB Azure Key Vault Azure Service Bus Azure Data Lake

Configure Azure Application Gateway

Frontend configuration For the Application Gateway v2 SKU, there must be a public frontend IP configuration. You can still have both a Public and a Private frontend IP configuration, but Private only frontend IP configuration (Only ILB mode) is currently not enabled for the v2 SKU. You can configure the Frontend IP to be Public or Private as per your use case. Backend configuration The backend pool is used to route requests to the backend servers that serve the request. Backend pools can be composed of NICs, virtual machine scale sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service. You can create an empty backend pool with your application gateway and then add backend targets to the backend pool. Configure health probes An application gateway automatically configures a default health probe when you don't set up any custom probe configurations. The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the back-end pool. Configure listeners A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. When you configure a listener, you must enter values that match the corresponding values in the incoming request on the gateway. Basic: All requests for any domain will be accepted and forwarded to backend pools. Multi-site: Forward requests to different backend pools based on the host header or host names. You must specify a host name that matches with the incoming request. This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. For the v2 SKU, multi-site listeners are processed before basic listeners. Front-end IP address Choose the front-end IP address that you plan to associate with this listener. The listener will listen to incoming requests on this IP. Front-end port Choose the front-end port. Select an existing port or create a new one. Choose any value from the allowed range of ports. You can use not only well-known ports, such as 80 and 443, but any allowed custom port that's suitable. A port can be used for public-facing listeners or private-facing listeners. Protocol Choose HTTP or HTTPS

Redirection Support Capabilities

Global redirection: Redirects from one listener to another listener on the gateway. This enables HTTP to HTTPS redirection on a site. Path-based redirection: Enables HTTP to HTTPS redirection only on a specific site area, for example a shopping cart area denoted by /cart/*. Redirect to external site: Requires a new redirect configuration object, which specifies the target listener or external site to which redirection is desired. The configuration element also supports options to enable appending the URI path and query string to the redirected URL. The redirect configuration is attached to the source listener via a new rule.

Traffic Manager key features

Increase application availability Traffic Manager delivers high availability for your critical applications by monitoring your endpoints and providing automatic failover when an endpoint goes down. Improve application performance Azure allows you to run cloud services and websites in datacenters located around the world. Traffic Manager can improve the responsiveness of your website by directing traffic to the endpoint with the lowest latency. Service maintenance without downtime You can have planned maintenance done on your applications without downtime. Traffic Manager can direct traffic to alternative endpoints while the maintenance is in progress. Combine hybrid applications Traffic Manager supports external, non-Azure endpoints enabling it to be used with hybrid cloud and on-premises deployments, including the burst-to-cloud, migrate-to-cloud, and failover-to-cloud scenarios. Distribute traffic for complex deployments Using nested Traffic Manager profiles, multiple traffic-routing methods can be combined to create sophisticated and flexible rules to scale to the needs of larger, more complex deployments.

Application Gateway Multiple Site Routing

Multiple site routing configures more than one web application on the same application gateway instance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the Application Gateway, specifying the name of each site. Application Gateway uses separate listeners to wait for requests for each site. Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool.

Create a Traffic Manager Profile

Name Enter a unique name for the Traffic Manager profile. Routing method Select the routing method to use in this profile. Subscription Select the subscription from the list that you want this profile to be applied to. Resource group Select the appropriate resource group from the list or create a new one. Resource group location The Azure Traffic Manager service is global and not bound to a location. This setting refers to the location of the selected resource group and has no impact on the runtime availability of your Traffic Manager profile.

Add LB Health Probes

Name: Enter a unique name for the health probe Protocol: Select either TCP or HTTP Port: Specify the destination port number for the health signal. The default is port 80 Interval: Specify the interval time in seconds between probe attempts. The default is 5 seconds Unhealthy threshold: Specify the number of consecutive probe failures that must occur before a virtual machine is considered to be in an unhealthy state. The default is 2 failures

Add a LB Rule

Name: Enter a unique name for the load balancing rule IP Version: Select either IPv4 or IPv6 Frontend IP address: Select the existing public-facing IP address of the load balancer Protocol: Select either the TCP or UDP protocol Port: Specify the port number for the load balancing rule. The default is port 80 Backend port: You can choose to route traffic to the virtual machine in the backend pool using a different port than the one that clients use by default to communicate with the load balancer (port 80) Backend pool: Select an existing backend pool. The virtual machines in this backend pool will be the target for the load balanced traffic of this rule. Health probe: Select an existing health probe or create a new one. The load balancing rule uses the health probe to determine which virtual machines in the backend pool are healthy and therefore can receive load balanced traffic. Session persistence: You can choose None, or Client IP, or Client IP and protocol. Session persistence specifies that traffic from a client should be handled by the same virtual machine in the backend pool for the duration of a session. None specifies that successive requests from the same client may be handled by any virtual machine. Client IP specifies that successive requests from the same client IP address will be handled by the same virtual machine. Client IP and protocol specifies that successive requests from the same client IP address and protocol combination will be handled by the same virtual machine. Idle timeout(minutes): Specify the time to keep a TCP or HTTP connection open without relying on clients to send keep-alive messages. The default idle timeout is 4 minutes, which is also the minimum setting. The maximum setting is 30 minutes. Floating IP: Choose between Disabled or Enabled. With Floating IP set to Disabled, Azure exposes a traditional load balancing IP address mapping scheme for ease of use (the VM instances' IP). With Floating IP set to Enabled, it changes the IP address mapping to the Frontend IP of the load balancer to allow for additional flexibility.

Application Gateway Path-based routing

Path-based routing sends requests with different URL paths different pools of back-end servers. For example, you could direct requests with the path /video/* to a back-end pool containing servers that are optimized to handle video streaming, and direct /images/* requests to a pool of servers that handle image retrieval.

Redirect Traffic

You can use application gateway to redirect traffic. It has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site.

Traffic Manager Routing Methods

Priority Select this routing method when you want to have a primary service endpoint for all traffic. You can provide multiple backup endpoints in case the primary or one of the backup endpoints is unavailable. Weighted Select this routing method when you want to distribute traffic across a set of endpoints based on their weight. Set the weight the same to distribute evenly across all endpoints. Performance Select the routing method when you have endpoints in different geographic locations, and you want end users to use the "closest" endpoint for the lowest network latency. Geographic Select this routing method to direct users to specific endpoints (Azure, External, or Nested) based on where their DNS queries originate from geographically. With this routing method, it enables you to be compliant with scenarios such as data sovereignty mandates, localization of content & user experience and measuring traffic from different regions. MultiValue Select this routing method for Traffic Manager profiles that can only have IPv4/IPv6 addresses as endpoints. When a query is received for this profile, all healthy endpoints are returned. Subnet Select this routing method to map sets of end-user IP address ranges to a specific endpoint. When a request is received, the endpoint returned will be the one mapped for that request's source IP address.

Azure Private Endpoint

Private Endpoint is the key technology behind Private Link. Private Endpoint is a network interface that enables a private and secure connection between your virtual network and an Azure service. In other words, Private Endpoint is the network interface that replaces the resource's public endpoint.

Create a Load Blanacer

Subscription - select the Azure subscription that you want to create your new load balancer resource in. Resource group - here you can select an existing resource group or create a new one. Name - provide a unique name for the instance. Region - select the region where the virtual machines were created. Type - this is where you select whether your load balancer is going to be Internal (private) or Public (external). If you choose Internal, you will need to specify a virtual network and IP address assignment, but if you choose Public, you will need to specify several Public IP address details. SKU - here you can select either the Standard SKU or the Basic SKU (for production workloads you should choose Standard, but for testing and evaluation and training purposes, you could choose Basic, but you will not get all the possible load balancer features). Depending on which SKU you select here, the remaining configuration options will differ slightly. Tier - this is where you select whether your load balancer is balancing within a region (Regional) or across regions (Global) - If you select the Basic SKU above, this setting is greyed out. Public IP address - here you specify whether to create a new public IP address for your public-facing front-end, or use an existing one, and you also specify a name for your public IP address, and whether to use a dynamic or statically assigned IP address. You can optionally also assign an IPv6 address to your load balancer in addition to the default IPv4 one.

Load Balance HTTP/S Traffic — Application Gateway Features

Support for the HTTP, HTTPS, HTTP/2 and WebSocket protocols. A web application firewall to protect against web application vulnerabilities. End-to-end request encryption. Autoscaling, to dynamically adjust capacity as your web traffic load change. Redirection: Redirection can be used to another site, or from HTTP to HTTPS. Rewrite HTTP headers: HTTP headers allow the client and server to pass parameter information with the request or the response. Custom error pages: Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.

Azure Private Link Service

This service lets you offer Private Link connections to your custom Azure services. Consumers of your custom services can then access those services privately—that is, without using the internet—from their own Azure virtual networks.

Add endpoints to Traffic Manager Profile

Type Select the type of endpoint to add. You can select from the following endpoint types: Azure endpoints External endpoints Nested endpoints Depending on which endpoint type you select here, the remaining options will differ. Name Enter a unique name for the endpoint. Target resource type (for Azure endpoints only) If you select the Azure endpoint type, you can select from the following resource types: Cloud service App Service App Service slot Public IP address Target resource (for Azure and Nested endpoints only) Select the appropriate target service, IP address, or profile from the list. The available options will differ depending on which endpoint type and target resource type are selected above. Fully-qualified domain name (FQDN) or IP (for External endpoints only) Specify the FQDN or IP address for the external endpoint. Priority Specify the priority for this endpoint. If you enter 1, then all traffic goes to this endpoint when it's healthy. Minimum child endpoints (for Nested endpoints only) Specify the minimum number of endpoints that must be available in the child Traffic Manager profile for it to receive traffic. If the available endpoints in the child profile falls below this threshold, this endpoint will be considered as degraded. Custom Header setting (optional setting) You can configure custom headers for your endpoint, using the following paired formatting: host:contoso.com,customheader:contoso The maximum number of supported pairs is 8, and they are applicable for both the HTTP and HTTPS protocols. These endpoint Custom Header settings override the settings configured in a profile. Add as disabled (optional setting) Disabling an endpoint in Traffic Manager can be useful to temporarily remove traffic from an endpoint that is in maintenance mode or being redeployed. Once the endpoint is running again, it can be re-enabled.

Azure Service Endpoints

Use virtual network Service Endpoints to extend your private address space in Azure by providing a direct connection to your Azure services. Service Endpoints let you secure your Azure resources to only your virtual network. Service traffic will remain on the Azure backbone and doesn't go out to the internet.

Types of DDoS Attacks

Volumetric attacks - These attacks flood the network layer with a substantial amount of seemingly legitimate traffic. They include UDP floods, amplification floods, and other spoofed-packet floods. DDoS Protection Standard mitigates these potential multi-gigabyte attacks by absorbing and scrubbing them, with Azure's global network scale, automatically. Protocol attacks - These attacks render a target inaccessible, by exploiting a weakness in the layer 3 and layer 4 protocol stack. They include SYN flood attacks, reflection attacks, and other protocol attacks. DDoS Protection Standard mitigates these attacks, differentiating between malicious and legitimate traffic, by interacting with the client, and blocking malicious traffic. Resource (application) layer attacks - These attacks target web application packets, to disrupt the transmission of data between hosts. They include HTTP protocol violations, SQL injection, cross-site scripting, and other layer 7 attacks. Use a Web Application Firewall, such as the Azure Application Gateway web application firewall, as well as DDoS Protection Standard to provide defense against these attacks. There are also third-party web application firewall offerings available in the Azure Marketplace.

WAF Detection Modes

When you create a Web Application Firewall (WAF) policy, by default the WAF policy is in Detection mode. In Detection mode, WAF does not block any requests; instead, requests matching the WAF rules are logged at WAF logs. To see WAF in action, you can change the mode settings from Detection to Prevention. In Prevention mode, requests that match rules that are defined in Default Rule Set (DRS) are blocked and logged at WAF logs.

Azure Front Door

While both Front Door and Application Gateway are layer 7 (HTTP/HTTPS) load balancers, the primary difference is that Front Door is a global service whereas Application Gateway is a regional service.

Choosing an Azure Application Gateway SKU

• Application Gateway is available under a Standard_v2 SKU • Web Application Firewall (WAF) is available under a WAF_v2 SKU The new v2 SKU includes the following enhancements: Autoscaling: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns. Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity. In the Standard_v2 and WAF_v2 SKU, Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. Fixed capacity mode is useful for scenarios with consistent and predictable workloads. Autoscaling mode is beneficial in applications that see variance in application traffic. Zone redundancy: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, which makes it more resilient to zone failure. The backend pool for applications can be similarly distributed across availability zones. Not all Azure regions support availability zones yet. Static VIP: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart. There isn't a static VIP in v1, so you must use the application gateway URL instead of the IP address for domain name routing to App Services via the application gateway. Header Rewrite: Application Gateway allows you to add, remove, or update HTTP request and response headers with v2 SKU. Key Vault Integration: Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS enabled listeners. Azure Kubernetes Service Ingress Controller: The Application Gateway v2 Ingress Controller allows the Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) known as AKS Cluster. Performance enhancements: The v2 SKU offers up to 5X better TLS offload performance as compared to the Standard/WAF SKU. Faster deployment and update time: The v2 SKU provides faster deployment and update time as compared to Standard/WAF SKU. This also includes WAF configuration changes.

Routing Traffic to an NVA (network virtual appliance) in a separate Vnet (service chaining)

Create user-defined routes to direct traffic from the Source VNet to the NVA in the destination VNet

Private DNS Record Support

pointers, MX, SOA, service, A/AAAA, and text records

Reserved IP for Recursive Resolvers in Azure DNS

168.63.129.16.

Default System Routes

0.0.0.0/0 10.0.0.0/8 192.168.0.0/16 100.64.0.0/10

Public IP Assignment in Azure

An IP address is assigned from a pool of available addresses, based on the location of the resource. Public IP addresses are allocated from a range that's unique to each region in each Azure cloud. Public IP addresses can't be moved between regions; all IP addresses are region-specific. If your business needs to have datacenters in different regions, you will have a different public IP address range for each region. You can use technology like Azure Traffic Manager to balance traffic between region-specific instances.

ExpressRoute supported Bandwidth

50 Mbps 100 Mbps 200 Mbps 500 Mbps 1 Gbps 2 Gbps 5 Gbps 10 Gbps

What is required when needing connectivity to private resources outside of a Vnet?

A Gateway. (Allow Gateway Transit setting in VPN Peering) • Use a site-to-site VPN to connect to an on-premises network. • Use a VNet-to-VNet connection to another virtual network. • Use a point-to-site VPN to connect to a client.

Availability Zone

An Azure Availability Zone enables you to define unique physical locations within a region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking. Designed to ensure high-availability of your Azure services, the physical separation of Availability Zones within a region protects applications and data from datacenter failures.

Three supported authentication methods for P2S VPN Connections

Authenticate using native Azure certificate authentication When using the native Azure certificate authentication, a client certificate on the device is used to authenticate the connecting user. Client certificates are generated from a trusted root certificate and then installed on each client computer. You can use a root certificate that was generated using an Enterprise solution, or you can generate a self-signed certificate. The validation of the client certificate is performed by the VPN gateway and happens during establishment of the P2S VPN connection. The root certificate is required for the validation and must be uploaded to Azure. Authenticate using native Azure Active Directory authentication Azure AD authentication allows users to connect to Azure using their Azure Active Directory credentials. Native Azure AD authentication is only supported for OpenVPN protocol and Windows 10 and requires the use of the Azure VPN Client. With native Azure AD authentication, you can leverage Azure AD's Conditional Access as well as multifactor authentication (MFA) features for VPN. At a high level, you need to perform the following steps to configure Azure AD authentication: • Configure an Azure AD tenant • Enable Azure AD authentication on the gateway • Download and configure Azure VPN Client Authenticate using Active Directory with integrated RADIUS server AD Domain authentication is a popular option because it allows users to connect to Azure using their organization domain credentials. It requires a RADIUS server that integrates with the AD server. Organizations can also leverage their existing RADIUS deployment.

Private DNS Auto-registration

Auto-registration will create resource records based on the Azure resource name.

Azure Firewall

Azure Firewall is a managed cloud-based network security service that protects your Azure Virtual Network resources.

Azure Load-Balancing Options

Azure Load Balancer - high-performance, ultra-low-latency Layer 4 load-balancing service (inbound and outbound) for all UDP and TCP protocols. It is built to handle millions of requests per second while ensuring your solution is highly available. Azure Load Balancer is zone-redundant, ensuring high availability across Availability Zones. Traffic Manager - DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness. Because Traffic Manager is a DNS-based load-balancing service, it load-balances only at the domain level. For that reason, it can't fail over as quickly as Front Door, because of common challenges around DNS caching and systems not honoring DNS time-to-live values (TTLs). Azure Application Gateway - provides application delivery controller (ADC) as a service, offering various Layer 7 load-balancing capabilities. Use it to optimize web farm productivity by offloading CPU-intensive SSL termination to the gateway. Azure Front Door - application delivery network that provides global load balancing and site acceleration service for web applications. It offers Layer 7 capabilities for your application like SSL offload, path-based routing, fast failover, caching, etc. to improve performance and high-availability of your applications.

ExpressRoute Use Cases

Faster and Reliable connection to Azure services Storage, backup, and Recovery Extends Data center capabilities Predictable, reliable, and high-throughput connections

Configuring ExpressRoute BFD

BFD is configured by default under all the newly created ExpressRoute private peering interfaces on the MSEEs. As such, to enable BFD, you only need to configure BFD on both your primary and secondary devices. Configuring BFD is two-step process. You configure the BFD on the interface and then link it to the BGP session. When you disable a peering, the Border Gateway Protocol (BGP) session for both the primary and the secondary connection of your ExpressRoute circuit is shut down. When you enable a peering, the BGP session on both the primary and the secondary connection of your ExpressRoute circuit is restored.

ExpressRoute BFD

BFD is used to speed up the link failure detection betwee Microsoft Enterprise Edge (MSEE) and the routers that your ExpressRoute circuit connect through.

Basic SKU IP Address

Basic SKU public IPs can be assigned by using static or dynamic allocation methods. Basic IPs have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed outbound originated flow idle timeout of 4 minutes. Basic IPs are open by default, so the use of Network security groups is recommended but optional for restricting inbound or outbound traffic. Basic public IPs can be assigned to any Azure resource that can be assigned a public IP address, such as network interfaces, VPN gateways, application gateways, and internet-facing load balancers. They do not support availability zone scenarios. You must use a Standard SKU public IP for an availability zone scenario.

How can DNS queries be sent to the correct Vnet for resolution?

Because the DNS suffix is different in each virtual network, you can use conditional forwarding rules to send DNS queries to the correct virtual network for resolution.

Encryption over Express Route: IPsec-protected path vs ExpressRoute without IPsec encryption

It is possible to send traffic encrypted or non-encrypted over ExpressRoute. To send encrypted, ensure traffic is routed to the VPN GW in Azure from On Premises. Anything not routed to the VPN GW will be cleartext. More specific routes take precedence.

ExpressRoute connectivity Models (4)

Co-located at a cloud exchange If you are co-located in a facility with a cloud exchange, you can order virtual cross-connections to the Microsoft cloud through the co-location provider's Ethernet exchange. Co-location providers can offer either Layer 2 cross-connections, or managed Layer 3 cross-connections between your infrastructure in the co-location facility and the Microsoft cloud. Point-to-point Ethernet connections You can connect your on-premises datacenters/offices to the Microsoft cloud through point-to-point Ethernet links. Point-to-point Ethernet providers can offer Layer 2 connections, or managed Layer 3 connections between your site and the Microsoft cloud. Any-to-any (IPVPN) networks You can integrate your WAN with the Microsoft cloud. IPVPN providers (typically MPLS VPN) offer any-to-any connectivity between your branch offices and datacenters. The Microsoft cloud can be interconnected to your WAN to make it look just like any other branch office. WAN providers typically offer managed Layer 3 connectivity. Direct from ExpressRoute sites You can connect directly into the Microsoft's global network at a peering location strategically distributed across the world. ExpressRoute Direct provides dual 100 Gbps or 10-Gbps connectivity, which supports Active/Active connectivity at scale.

Design Redundancy for an ExpressRoute deployment (2)

Configure ExpressRoute and site to site coexisting connections Create a zone redundant VNET gateway in Azure Availability zones

Configure a VPN connection to an ExpressRoute deployment

Configure Microsoft peering for your ExpressRoute circuit. Advertise selected Azure regional public prefixes to your on-premises network via Microsoft peering. Configure a VPN gateway and establish IPsec tunnels Configure the on-premises VPN device. Create the site-to-site IPsec/IKE connection (Optional) Configure firewalls/filtering on the on-premises VPN device. Test and validate the IPsec communication over the ExpressRoute circuit.

VPN Gateway redundancy

Every Azure VPN gateway consists of two instances in an active-standby configuration. For any planned maintenance or unplanned disruption that happens to the active instance, the standby instance would take over (failover) automatically and resume the S2S VPN or VNet-to-VNet connections. The switch over will cause a brief interruption. For planned maintenance, the connectivity should be restored within 10 to 15 seconds. For unplanned issues, the connection recovery will be longer, about 1 to 3 minutes in the worst case. For P2S VPN client connections to the gateway, the P2S connections will be disconnected, and the users will need to reconnect from the client machines.

ExpressRoute Global Reach

ExpressRoute Global Reach is designed to complement your service provider's WAN implementation and connect your branch offices across the world.

ExpressRoute

ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a private connection with the help of a connectivity provider. ExpressRoute connections do not go over the public Internet, this approach allows ExpressRoute connections to offer more reliability, faster speeds, consistent latencies, and higher security.

How to view Effective Routes for troubleshooting purposes

Find a VM that you wish to investigate. Under settings for that VM, navigate to networking and select the NIC. Within the NIC, under Support + Troubleshooting, select Effective Routes to view a list of routes.

P2S Software and Connecting to Azure

For Windows clients, you must have administrator rights on the client device to initiate the VPN connection from the client device to Azure. For Windows devices, the VPN client configuration consists of an installer package that users install on their devices. For Mac devices, it consists of the mobileconfig file that users install on their devices.

Configure Forced Tunneling

Forced tunneling can be configured by using Azure PowerShell. It can't be configured using the Azure portal. To configure forced tunneling, you must: • Create a routing table. • Add a user-defined default route to the VPN Gateway. • Associate the routing table to the appropriate VNet subnet(s). Forced tunneling must be associated with a VNet that has a route-based VPN gateway. • You must set a default site connection among the cross-premises local sites connected to the virtual network. • The on-premises VPN device must be configured using 0.0.0.0/0 as traffic selectors.

VPN Configuration Items

Gateway type: VPN or ExpressRoute. VPN Type: Route based or Policy based. Most VPN types are Route-based. The type of VPN you choose depends on the make and model of your VPN device, and the kind of VPN connection you intend to create. Typical route-based gateway scenarios include point-to-site, inter-virtual network, or multiple site-to-site connections. Route-based is also selected when you coexist with an ExpressRoute gateway or if you need to use IKEv2. Policy-based gateways support only IKEv1. SKU: Use the drop-down to select a gateway SKU. Your choice will affect the number of tunnels you can have and the aggregate throughput benchmark. The benchmark is based on measurements of multiple tunnels aggregated through a single gateway. It is not a guaranteed throughput due to Internet traffic conditions and your application behaviors. Generation: Generation1 or Generation2. You cannot change generations or SKUs across generations. Basic and VpnGw1 SKUs are only supported in Generation1. VpnGw4 and VpnGw5 SKUs are only supported in Generation2. Virtual Networks: The virtual network that will be able to send and receive traffic through the virtual network gateway. A virtual network cannot be associated with more than one gateway.

Global vs Regional Load Balancing Services

Global load-balancing services distribute traffic across regional backends, clouds, or hybrid on-premises services. These services route end-user traffic to the closest available backend. They also react to changes in service reliability or performance, in order to maximize availability and performance. Regional load-balancing services distribute traffic within virtual networks across virtual machines (VMs) or zonal and zone-redundant service endpoints within a region.

Dual-redundancy: active-active VPN gateways for both Azure and on-premises networks

Here you create and set up the Azure VPN gateway in an active-active configuration and create two local network gateways and two connections for your two on-premises VPN devices as described above. The result is a full mesh connectivity of 4 IPsec tunnels between your Azure virtual network and your on-premises network. All gateways and tunnels are active from the Azure side, so the traffic will be spread among all 4 tunnels simultaneously, although each TCP or UDP flow will again follow the same tunnel or path from the Azure side. Even though by spreading the traffic, you may see slightly better throughput over the IPsec tunnels, the primary goal of this configuration is for high availability. And due to the statistical nature of the spreading, it is difficult to provide the measurement on how different application traffic conditions will affect the aggregate throughput. This topology will require two local network gateways and two connections to support the pair of on-premises VPN devices, and BGP is required to allow the two connections to the same on-premises network. These requirements are the same as the above.

HA Options for VPN Connections

High availability options for VPN connections To provide better availability for your VPN connections, there are a few options available: • VPN Gateway redundancy (Active-standby) • Multiple on-premises VPN devices • Active-active Azure VPN gateway • Combination of both

Associating Route Tables to Subnets

In Azure, each subnet can have zero or one associated route table. When you create a route table and associate it to a subnet, the routes within it are combined with, or override, the default routes Azure adds to a subnet.

Zone Redundant LB

In a region with Availability Zones, a Standard Load Balancer can be zone-redundant. This traffic is served by a single IP address. A single frontend IP address will survive zone failure. The frontend IP may be used to reach all (non-impacted) backend pool members no matter the zone. One or more availability zones can fail and the data path survives as long as one zone in the region remains healthy. The frontend's IP address is served simultaneously by multiple independent infrastructure deployments in multiple availability zones. Any retries or reestablishment will succeed in other zones not affected by the zone failure.

Active-active VPN gateways

In this configuration, each Azure gateway instance will have a unique public IP address, and each will establish an IPsec/IKE S2S VPN tunnel to your on-premises VPN device specified in your local network gateway and connection. Note that both VPN tunnels are part of the same connection. You will still need to configure your on-premises VPN device to accept or establish two S2S VPN tunnels to those two Azure VPN gateway public IP addresses. Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network to your on-premises network will be routed through both tunnels simultaneously, even if your on-premises VPN device may favor one tunnel over the other. For a single TCP or UDP flow, Azure attempts to use the same tunnel when sending packets to your on-premises network. However, your on-premises network could use a different tunnel to send packets to Azure. When a planned maintenance or unplanned event happens to one gateway instance, the IPsec tunnel from that instance to your on-premises VPN device will be disconnected. The corresponding routes on your VPN devices should be removed or withdrawn automatically so that the traffic will be switched over to the other active IPsec tunnel. On the Azure side, the switch over will happen automatically from the affected instance to the active instance.

ExpressRoute SKUs

Local SKU - With Local SKU, you are automatically charged with an Unlimited data plan. Standard and Premium SKU - You can select between a Metered or an Unlimited data plan. All ingress data are free of charge except when using the Global Reach add-on.

All Azure resource types have a scope that defines the level that resource names must be unique. A resource must have a unique name within its scope. There are four levels you can specify a scope: (4)

Management group Subscription Resource group Resource Scopes are hierarchical, with each level of hierarchy making the scope more specific.

NAT Traffic Flow Limit

NAT Provides up to 64,000 concurrent traffic flows per Public IP. You can have up to 16 public IP addresses.

Create a VPN Connection

Name. Enter a name for your connection. Connection type. Select Site-to-Site (IPSec) from the drop-down. Shared key (PSK). In this field, enter a shared key for your connection. You can generate or create this key yourself. In a site-to-site connection, the key you use is the same for your on-premises device and your virtual network gateway connection.

NSG and VNet Peering

Network security groups can be applied in either virtual network to block access to other virtual networks or subnets. When configuring virtual network peering, you can either open or close the network security group rules between the virtual networks.

When performing Vnet peering, do you need to peer twice for the same set of vnets?

No, when you add a peering on one virtual network, the second virtual network configuration is automatically added.

How many VPN Gateways are supported per Vnet?

One (1)

ExpressRoute and Site to Site coexisting connections Limitations

Only route-based VPN gateway is supported. You must use a route-based VPN gateway. You also can use a route-based VPN gateway with a VPN connection configured for 'policy-based traffic selectors'. The ASN of Azure VPN Gateway must be set to 65515. Azure VPN Gateway supports the BGP routing protocol. For ExpressRoute and Azure VPN to work together, you must keep the Autonomous System Number of your Azure VPN gateway at its default value, 65515. If you previously selected an ASN other than 65515 and you change the setting to 65515, you must reset the VPN gateway for the setting to take effect. The gateway subnet must be /27 or a shorter prefix, (such as /26, /25), or you will receive an error message when you add the ExpressRoute virtual network gateway. Coexistence in a dual stack VNet is not supported. If you are using ExpressRoute IPv6 support and a dual-stack ExpressRoute gateway, coexistence with VPN Gateway will not be possible.

P2S Supported Protocols

OpenVPN® Protocol, an SSL/TLS based VPN protocol. A TLS VPN solution can penetrate firewalls, since most firewalls open TCP port 443 outbound, which TLS uses. OpenVPN can be used to connect from Android, iOS (versions 11.0 and above), Windows, Linux, and Mac devices (macOS versions 10.13 and above). Secure Socket Tunneling Protocol (SSTP), a proprietary TLS-based VPN protocol. A TLS VPN solution can penetrate firewalls, since most firewalls open TCP port 443 outbound, which TLS uses. SSTP is only supported on Windows devices. Azure supports all versions of Windows that have SSTP (Windows 7 and later). IKEv2 VPN, a standards-based IPsec VPN solution. IKEv2 VPN can be used to connect from Mac devices (macOS versions 10.11 and above).

Plan a VPN Gateway. When you're planning a VPN gateway, there are three architectures to consider: (3)

Plan a VPN gateway • Point to site over the internet • Site to site over the internet • Site to site over a dedicated network, such as Azure ExpressRoute

Provision and Deploy ExpressRoute (2 pre-reqs)

Pre-reqs: Task 1: Create the VNet and gateway subnet Task 2: Create the virtual network gateway Deploy: Task 1: Create and provision an ExpressRoute circuit Task 2: Retrieve your Service key Task 3: Deprovisioning an ExpressRoute circuit

CNAME Record Sets Limit

Record sets of type CNAME can contain one record at most

Local Network Gateway

Refers to the On-premises VPN device. IP Address. The public IP address of the local gateway. Address Space. One or more IP address ranges (in CIDR notation) that define your local network's address space. If you plan to use this local network gateway in a BGP-enabled connection, then the minimum prefix you need to declare is the host address of your BGP Peer IP address on your VPN device.

Before you can create a VNet, you must create a _______________. A ________________ is ....

Resource group. A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group.

Enable Global Reach

Select the Azure private peering configuration. Select Add Global Reach to open the Add Global Reach configuration page. On the Add Global Reach configuration page, give a name to this configuration. Select the ExpressRoute circuit you want to connect this circuit to and enter in a /29 IPv4 for the Global Reach subnet. Azure uses IP addresses in this subnet to establish connectivity between the two ExpressRoute circuits. Select Save to complete the Global Reach configuration.

Subdomain NS Record Locations

Setting up a subdomain follows the same process as typical delegation. The only difference is that NS records must be created in the parent zone contoso.com in Azure DNS, rather than in the domain registrar.

Standard SKU IP Address

Standard SKU public IP addresses always use the static allocation method. They have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed outbound originated flow idle timeout of 4 minutes. Standard IPs are secure by default and closed to inbound traffic. You must explicitly allow inbound traffic by using a network security group. Standard IPs can be assigned to network interfaces, Standard public load balancers, application gateways, or VPN gateways. Standard IPs are zone-redundant by default and optionally zonal (they can be created zonal and guaranteed in a specific availability zone).

Bastion Host

The Azure Bastion service is a new fully platform-managed PaaS service that you provision inside your virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL. When you connect via Azure Bastion, your virtual machines do not need a public IP address.

ExpressRoute FastPath Gateway Requirements

To configure FastPath, the virtual network gateway must be either: • Ultra-Performance • ErGw3AZ

Highly Available VNet-to-VNet

The same active-active configuration can also apply to Azure VNet-to-VNet connections. You can create active-active VPN gateways for both virtual networks, and connect them together to form the same full mesh connectivity of 4 tunnels between the two VNets, as shown in the diagram. This ensures there are always a pair of tunnels between the two virtual networks for any planned maintenance events, providing even better availability. Even though the same topology for cross-premises connectivity requires two connections, the VNet-to-VNet topology shown above will need only one connection for each gateway. Additionally, BGP is optional unless transit routing over the VNet-to-VNet connection is required.

Subnet Size Limitations

The smallest supported IPv4 subnet is /29 The largest is /2 (using CIDR subnet definitions). IPv6 subnets must be exactly /64 in size.

Next-hop type: Virtual Appliance

Virtual appliance: A virtual appliance is a virtual machine that typically runs a network application, such as a firewall. When you create a route with the virtual appliance hop type, you also specify a next hop IP address. The IP address can be: • The private IP address of a network interface attached to a virtual machine. • The private IP address of an Azure internal load balancer.

Private DNS Scope and Access Limits

They are global in scope, so you can access them from any region, any subscription, any VNet, and any tenant. If you have permission to read the zone, you can use it for name resolution. Private DNS zones are highly resilient, being replicated to regions all throughout the world. They are not available to resources on the internet.

Multiple on-premises VPN devices

This configuration provides multiple active tunnels from the same Azure VPN gateway to your on-premises devices in the same location. There are some requirements and constraints: • You need to create multiple S2S VPN connections from your VPN devices to Azure. When you connect multiple VPN devices from the same on-premises network to Azure, you need to create one local network gateway for each VPN device, and one connection from your Azure VPN gateway to each local network gateway. • The local network gateways corresponding to your VPN devices must have unique public IP addresses in the GatewayIpAddress property. • BGP is required for this configuration. Each local network gateway representing a VPN device must have a unique BGP peer IP address specified in the BgpPeerIpAddress property. • You should use BGP to advertise the same prefixes of the same on-premises network prefixes to your Azure VPN gateway, and the traffic will be forwarded through these tunnels simultaneously. • You must use Equal-cost multi-path routing (ECMP). • Each connection is counted against the maximum number of tunnels for your Azure VPN gateway, 10 for Basic and Standard SKUs, and 30 for HighPerformance SKU. In this configuration, the Azure VPN gateway is still in active-standby mode, so the same failover behavior and brief interruption will still happen as described above. But this setup guards against failures or interruptions on your on-premises network and VPN devices.

Zone redundant VNet gateway in Azure availability zones

To deploy gateways in a specific zone, you can use zonal gateways. When you deploy a zonal gateway, all instances of the gateway are deployed in the same Availability Zone. Zone-redundant gateways When you create a public IP address using the Standard public IP SKU without specifying a zone, the behavior differs depending on whether the gateway is a VPN gateway, or an ExpressRoute gateway. For a VPN gateway, the two gateway instances will be deployed in any 2 out of these three zones to provide zone-redundancy. For an ExpressRoute gateway, since there can be more than two instances, the gateway can span across all the three zones. Zonal gateways When you create a public IP address using the Standard public IP SKU and specify the Zone (1, 2, or 3), all the gateway instances will be deployed in the same zone. Regional gateways When you create a public IP address using the Basic public IP SKU, the gateway is deployed as a regional gateway and does not have any zone-redundancy built into the gateway.

True or False: VPN Gateways can be used for connections between virtual networks in Azure

True

True or False: You can add address spaces AFTER creating a Vnet.

True

True or False: You can perform VNet Peering across Regions

True — Unless using Azure Government Cloud Regions

ExpressRoute FastPath Limitations

UDR on the gateway subnet: This UDR has no impact on the network traffic that FastPath sends directly from your on-premises network to the virtual machines in Azure virtual network. VNet Peering: If you have other virtual networks peered with the one that is connected to ExpressRoute, the network traffic from your on-premises network to the other virtual networks (i.e., the so-called "Spoke" VNets) will continue to be sent to the virtual network gateway. The workaround is to connect all the virtual networks to the ExpressRoute circuit directly. Basic Load Balancer: If you deploy a Basic internal load balancer in your virtual network or the Azure PaaS service you deploy in your virtual network uses a Basic internal load balancer, the network traffic from your on-premises network to the virtual IPs hosted on the Basic load balancer will be sent to the virtual network gateway. The solution is to upgrade the Basic load balancer to a Standard load balancer. Private Link: If you connect to a private endpoint in your virtual network from your on-premises network, the connection will go through the virtual network gateway.

ExpressRoute Billing Model

Unlimited data. Billing is based on a monthly fee; all inbound and outbound data transfer is included free of charge. Metered data. Billing is based on a monthly fee; all inbound data transfer is free of charge. Outbound data transfer is charged per GB of data transfer. Data transfer rates vary by region. ExpressRoute premium add-on. ExpressRoute premium is an add-on to the ExpressRoute circuit. The ExpressRoute premium add-on provides the following capabilities: • Increased route limits for Azure public and Azure private peering from 4,000 routes to 10,000 routes. • Global connectivity for services. An ExpressRoute circuit created in any region (excluding national clouds) will have access to resources across every other region in the world. For example, a virtual network created in West Europe can be accessed through an ExpressRoute circuit provisioned in Silicon Valley. • Increased number of VNet links per ExpressRoute circuit from 10 to a larger limit, depending on the bandwidth of the circuit.

Improve Data Path Performance with ExpressRoute

Use ExpressRoute FastPath

Virtual Network (VNet) Address Ranges

When creating a VNet, it is recommended that you use the address ranges enumerated in RFC 1918, which have been set aside by the IETF for private, non-routable address spaces: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) In addition, you cannot add the following address ranges: 224.0.0.0/4 (Multicast) 255.255.255.255/32 (Broadcast) 127.0.0.0/8 (Loopback) 169.254.0.0/16 (Link-local) 168.63.129.16/32 (Internal DNS)

Troubleshoot Azure VPN Gateway using diagnostic logs

Using diagnostic logs, you can troubleshoot multiple VPN gateway related events including configuration activity, VPN Tunnel connectivity, IPsec logging, BGP route exchanges, Point to Site advanced logging. There are several diagnostic logs you can use to help troubleshoot a problem with your VPN Gateway. GatewayDiagnosticLog - Contains diagnostic logs for gateway configuration events, primary changes, and maintenance events. TunnelDiagnosticLog - Contains tunnel state change events. Tunnel connect/disconnect events have a summarized reason for the state change if applicable. RouteDiagnosticLog - Logs changes to static routes and BGP events that occur on the gateway. IKEDiagnosticLog - Logs IKE control messages and events on the gateway. P2SDiagnosticLog - Logs point-to-site control messages and events on the gateway. Use Azure Monitor to analyze the data collected in the diagnostic logs.

ExpressRoute Gateway Types: (2)

VPN - To send encrypted traffic across the public Internet, you use the gateway type 'VPN'. This is also referred to as a VPN gateway. Site-to-Site, Point-to-Site, and VNet-to-VNet connections all use a VPN gateway. ExpressRoute - To send network traffic on a private connection, you use the gateway type 'ExpressRoute'. This is also referred to as an ExpressRoute gateway and is the type of gateway used when configuring ExpressRoute.

Gateway Subnet

VPN Gateways require a gateway subnet. You can create a Gateway subnet before you create a VPN gateway, or you can create it during the creation of the VPN Gateway. The gateway subnet contains the IP addresses that the virtual network gateway VMs and services use. When you create your virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings. Never deploy anything else (for example, additional VMs) to the gateway subnet. The gateway subnet must be named GatewaySubnet to work properly. Naming the gateway subnet GatewaySubnet tells Azure know that this is the subnet to deploy the virtual network gateway VMs and services to.

ExpressRoute Route Advertisement

When Microsoft peering gets configured on your ExpressRoute circuit, the Microsoft Edge routers establish a pair of Border Gateway Protocol (BGP) sessions with your edge routers through your connectivity provider. No routes are advertised to your network. To enable route advertisements to your network, you must associate a route filter. In order to associate a route filter: • You must have an active ExpressRoute circuit that has Microsoft peering provisioned. • Create an ExpressRoute circuit and have the circuit enabled by your connectivity provider before you continue. The ExpressRoute circuit must be in a provisioned and enabled state. • Create Microsoft peering if you manage the BGP session directly. Or, have your connectivity provider provision Microsoft peering for your circuit.

Gateways and Vnet peering

When virtual networks are peered, you configure a VPN gateway in the peered virtual network as a transit point. In this case, a peered virtual network uses the remote gateway to gain access to other resources. A virtual network can have only one gateway. Gateway transit is supported for both VNet Peering and Global VNet Peering.

Gateway Subnet Recommended Size

While you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet of /27 or larger (/27, /26 etc.) if you have the available address space to do so. This will accommodate most configurations.

NSG Assignment in Vnets and Subnets

You can associate zero or one NSG to each subnet in a virtual network. You can associate the same, or a different, network security group to each subnet.

Zonal LB Design

You can choose to have a frontend guaranteed to a single zone, which is known as a zonal. This scenario means any inbound or outbound flow is served by a single zone in a region. Your frontend shares fate with the health of the zone. The data path is unaffected by failures in zones other than where it was guaranteed. You can use zonal frontends to expose an IP address per Availability Zone.

DDoS Protection

You can select to enable Standard DDoS protection. Standard DDoS Protection is a paid service plan that offers enhanced DDoS mitigation capabilities via adaptive tuning, attack notification, and telemetry to protect against the impacts of a DDoS attack for all protected resources within this virtual network. Basic DDoS protection is integrated into the Azure platform by default and at no additional cost.

Azure services that support Availability Zones fall into three categories:

Zonal services: Resources can be pinned to a specific zone. For example, virtual machines, managed disks, or standard IP addresses can be pinned to a specific zone, which allows for increased resilience by having one or more instances of resources spread across zones. Zone-redundant services: Resources are replicated or distributed across zones automatically. Azure replicates the data across three zones so that a zone failure does not impact its availability. Non-regional services: Services are always available from Azure geographies and are resilient to zone-wide outages as well as region-wide outages.

Reserved IP Addresses per Network (5)

x.x.x.0: Network address x.x.x.1: Reserved by Azure for the default gateway x.x.x.2, x.x.x.3: Reserved by Azure to map the Azure DNS IPs to the VNet space x.x.x.255: Network broadcast address

Vnet Peering Benefits

• A low-latency, high-bandwidth connection between resources in different virtual networks. • The ability to apply network security groups in either virtual network to block access to other virtual networks or subnets. • The ability to transfer data between virtual networks across Azure subscriptions, Azure Active Directory tenants, deployment models, and Azure regions. • The ability to peer virtual networks created through the Azure Resource Manager. • The ability to peer a virtual network created through Resource Manager to one created through the classic deployment model. • No downtime to resources in either virtual network is required when creating the peering, or after the peering is created.

When resources deployed in virtual networks need to resolve domain names to internal IP addresses, they can use one the three methods: (3)

• Azure DNS Private Zones • Azure-provided name resolution • Name resolution that uses your own DNS server

Limitations of Azure-provided Internal DNS

• Can't resolve across different VNets. • Registers resource names, not guest OS names. • Does not allow manual record creation.

Next-hop types: (3)

• Virtual network: Routes traffic between address ranges within the address space of a virtual network. Azure creates a route with an address prefix that corresponds to each address range defined within the address space of a virtual network. Azure automatically routes traffic between subnets using the routes created for each address range. • Internet: Routes traffic specified by the address prefix to the Internet. The system default route specifies the 0.0.0.0/0 address prefix. Azure routes traffic for any address not specified by an address range within a virtual network to the Internet, unless the destination address is for an Azure service. Azure routes any traffic destined for its service directly to the service over the backbone network, rather than routing the traffic to the Internet. You can override Azure's default system route for the 0.0.0.0/0 address prefix with a custom route. • None: Traffic routed to the None next hop type is dropped, rather than routed outside the subnet. Azure automatically creates default routes for the following address prefixes: 10.0.0.0/8 and 192.168.0.0/16: Reserved for private use in RFC 1918. 100.64.0.0/10: Reserved in RFC 6598.

Azure VNets enable resources in Azure to securely communicate with each other, the internet, and on-premises networks. (5)

• Communication with the internet. All resources in a VNet can communicate outbound to the internet, by default. You can communicate inbound to a resource by assigning a public IP address or a public Load Balancer. You can also use public IP or public Load Balancer to manage your outbound connections. • Communication between Azure resources. There are three key mechanisms through which Azure resource can communicate: VNets, VNet service endpoints and VNet peering. Virtual Networks can connect not only VMs, but other Azure Resources, such as the App Service Environment, Azure Kubernetes Service, and Azure virtual machine scale sets. You can use service endpoints to connect to other Azure resource types, such as Azure SQL databases and storage accounts. When you create a VNet, your services and VMs within your VNet can communication directly and securely with each other in the cloud. • Communication between on-premises resources. Securely extend your data center. You can connect your on-premises computers and networks to a virtual network using any of the following options: Point-to-site virtual private network (VPN), Site-to-site VPN, Azure ExpressRoute. • Filtering network traffic. You can filter network traffic between subnets using any combination of network security groups and network virtual appliances like firewalls, gateways, proxies, and Network Address Translation (NAT) services. • Routing network traffic. Azure routes traffic between subnets, connected virtual networks, on-premises networks, and the Internet, by default. You can implement route tables or border gateway protocol (BGP) routes to override the default routes Azure creates.

Private DNS Enablers:

• Configure a specific DNS name for a zone. • Create records manually when necessary. • Resolve names and IP addresses across different zones. • Resolve names and IP addresses across different VNets.

When planning to implement subnets, you need to consider the following: (4)

• Each subnet must have a unique address range, specified in Classless Inter-Domain Routing (CIDR) format. • Certain Azure services require their own subnet. • Subnets can be used for traffic management. For example, you can create subnets to route traffic through a network virtual appliance. • You can limit access to Azure resources to specific subnets with a virtual network service endpoint. You can create multiple subnets, and enable a service endpoint for some subnets, but not others.

When planning to implement virtual networks, you need to consider the following: (6)

• Ensure non-overlapping address spaces. Make sure your VNet address space (CIDR block) does not overlap with your organization's other network ranges. • Is any security isolation required? • Do you need to mitigate any IP addressing limitations? • Will there be connections between Azure VNets and on-premises networks? • Is there any isolation required for administrative purposes? • Are you using any Azure services that create their own VNets?

2 Basic Steps: Configure encryption over ExpressRoute (2)

• Establish ExpressRoute connectivity with an ExpressRoute circuit and private peering. • Establish the VPN connectivity.

DNS Forwarding Options (2)

• Forwarding - specifies another DNS server (SOA for a zone) to resolve the query if the initial server cannot. • Conditional forwarding - specifies a DNS server for a named zone, so that all queries for that zone are routed to the specified DNS server.

Express Route Capabilities

• Layer 3 connectivity between your on-premises network and the Microsoft Cloud through a connectivity provider • Connectivity can be from an any-to-any (IPVPN) network, a point-to-point Ethernet connection, or through a virtual cross-connection via an Ethernet exchange • Connectivity to Microsoft cloud services across all regions in the geopolitical region • Global connectivity to Microsoft services across all regions with the ExpressRoute premium add-on • Built-in redundancy in every peering location for higher reliability

Limitations of NAT

• NAT is compatible with standard SKU public IP, public IP prefix, and load balancer resources. Basic resources (for example basic load balancer) and any products derived from them aren't compatible with NAT. Basic resources must be placed on a subnet not configured with NAT. • IPv4 address family is supported. NAT doesn't interact with IPv6 address family. NAT can't be deployed on a subnet with an IPv6 prefix. • NAT can't span multiple virtual networks. • IP fragmentation is not supported.

Two types of Vnet peering: (2)

• Regional VNet peering: connects Azure virtual networks in the same region. • Global VNet peering: connects Azure virtual networks in different regions. When creating a global peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions, but not in Government cloud regions. You can only peer virtual networks in the same region in Azure Government cloud regions.

Two Methods of Linking Vnets to DNS Private Zones

• Registration: Each VNet can link to one private DNS zone for registration. However, up to 100 VNets can link to the same private DNS zone for registration. • Resolution: There may be many other private DNS zones for different namespaces. You can link a VNet to each of those zones for name resolution. Each VNet can link to up to 1000 private DNS Zones for name resolution.

Requirements for Resolving VM host name by DNS Server VM (2)

• The DNS server VM must reside in the same virtual network • The DNS server must be configured to forward host name queries to Azure.

DNS Design Considerations (5)

• The name of the zone must be unique within the resource group, and the zone must not exist already. • The same zone name can be reused in a different resource group or a different Azure subscription. • Where multiple zones share the same name, each instance is assigned different name server addresses. • Root/Parent domain is registered at the registrar and pointed to Azure NS. • Child domains are registered in AzureDNS directly.

DNS Caveats

• When delegating a domain to Azure DNS, you must use the name server names provided by Azure DNS. You should always use all four name server names, regardless of the name of your domain. • The parent and child zones can be in the same or different resource group. Notice that the record set name in the parent zone matches the child zone name, in this case partners.

Limitations on VNet Connections to ExpressRoute circuits

• You can link up to 10 virtual networks to a standard ExpressRoute circuit. All virtual networks must be in the same geopolitical region when using a standard ExpressRoute circuit. • A single VNet can be linked to up to 16 ExpressRoute circuits. Use the following process to create a new connection object for each ExpressRoute circuit you are connecting to. The ExpressRoute circuits can be in the same • If you enable the ExpressRoute premium add-on, you can link virtual networks outside of the geopolitical region of the ExpressRoute circuit. The premium add-on will also allow you to connect more than 10 virtual networks to your ExpressRoute circuit depending on the bandwidth chosen.