Azure Virtual Networks

  • Virtual NetworkAzure Virtual Network is a fundamental component that acts as an organization’s network in Azure. Organizations can use virtual networks to connect resources. Virtual networks in Microsoft Azure are network overlays that you can use to configure and control connectivity between Azure resources such as VMs and load balancers.
    • vNet: A virtual network is a logical isolation of the Azure cloud dedicated to your subscription.
      •  You can divide a VNet into multiple subnets for organization and security. It contains at least one Subnet
      • You can create up to 50 virtual networks per subscription per region. Although you have the ability to increase this limit to 500 by contacting Azure support.
      • If you connect to a VNet with a VPN or ExpressRoute, you must ensure that the address space is unique and does not overlap any of the ranges that are already in use on-premises or in other VNets.
      • Always plan to use an address space that is not already in use in your organization, either on-premises or in other VNets.
      • Even if you plan for a VNet to be cloud-only, you may want to make a VPN connection to it later. If there is any overlap in address spaces at that point, you will have to reconfigure or recreate the VNet.
      • Virtual networks (VNets) can contain both public and private (RFC 1918 address blocks) IP address spaces. When you add a public IP address range, it will be treated as part of the private VNet IP address space that is only reachable within the VNet, interconnected VNets, and from your on-premises location.
      • You add a public IP address range the same way you would add a private IP address range; by either using a netcfg file, or by adding the configuration in the Azure portal.
      • dhcpOptions: Object that contains single required property i.e dnsServers
      • dnsServers: Array of DNS servers used by the vNet. If no server is specified, then Azure internal name resolution is used.
    • Subnets: A subnet is a child resource of a vNet, and helps define segments of address spaces within a CIDR block range, using IP address prefixes.
      • You can further divide your network by using subnets for logical and security isolation of Azure resources. Each subnet contains a range of IP addresses that fall within the virtual network address space.
      • Can be one or more subnets in a single vNet.
      • The smallest subnet you can specify would be /29 subnet mask.
      • The first three and the last IP addresses are not available for use within a subnet.
      • NICs can be added to subnets, and connected to VMs, providing connectivity for various workloads.
      • Routing between subnet is automatic and ICMP is allowed within subents that belongs to the same vNet.
      • You can also configure route tables and NSGs to a subnet.
      • Keep Static and Dynamic subents separate for ease of management.
      • VMs and PaaS role instances deployed to subnets (same or different) within a VNet can communicate with each other without any extra configuration.
      • location: Azure location or region where subnet is defined.
      • addressPrefix: Single address prefix in CIDR notation that make up the subnet.
      • networkSecrurityGroup: NSG is applied to subnet.
      • routeTable: Route table applied to subnet.
      • ipConfigurations: Collection of IP configuration objects used by NICs which are connected to the subnet.
      • IaaSv2, you add the subnet to a NIC, rather than adding the VM to a subnet as you do for IaaSv1.
      • You can create user defined routes that specify the next hop for packets flowing to a specific subnet to go to your virtual appliance instead, and enabling IP forwarding for the VM running as the virtual appliance.
    • Network Security Group (NSG): List of rules that can allow or deny traffic to Azure resources.
      • Can be associated with either Subnets or Network Interfaces.
      • You can use network security groups to provide network isolation for Azure resources by defining rules that can allow or deny specific traffic to individual VMs or subnets.
      • Source: Any|IP Addresses|Service Tag
      • Source Port: port | range (1-65535) | *
      • DestinationAny|IP Addresses|VirtualNetwork
      • Destination Port: port | range (1-65535) | *
      • Protocol: Any|TCP|UDP
      • Action: Allow|Deny
      • They control inbound and outbound traffic passing through a Network Interface Card (NIC) (Resource Manage deployment model), a VM (classic deployment), or a subnet (both deployment models).
        • If the VM has multiple NICs, network security group rules are NOT automatically applied to traffic that is designated to other NICs.
      • Following are Default Rules, that you cannot delete, but can override, because they have the lowest priority:
        • allow all inbound and outbound traffic within a virtual network
        • allow outbound traffic towards the Internet
        • allow inbound traffic from Azure load balancer.
        • denies all inbound and outbound traffic with the lowest priority.
      • By default you can create 100 NSGs per region per subscription. You can raise this limit to 400 by contacting Azure support.
      • You can apply only one NSG to a NIC (RM deployment model), subnet, or VM (Classic deployment model).
      • By default, you can have up to 200 rules in a single NSG. You can raise this limit to 500 by contacting Azure support.
      • You can apply an NSG to multiple resources in the same or different resource groups.
      • If you have a NSG applied to Subnet and other associated to NIC, then subnet is evaluated first followed by NIC, with most restrictive rules winning.
    • IP addresses: VMs, Azure load balancers, and application gateways in a single virtual network require unique IP addresses in the same way as clients in an on-premises subnet do. This enables these resources to communicate with each other.
      • Private IP addresses: A private IP address is allocated to a VM dynamically or statically from the defined scope of IP addresses in the virtual network.
        • Used for communication within an Azure virtual network (VNet), and your on-premises network when you use a VPN gateway or ExpressRoute circuit to extend your network to Azure.
        • A private IP address is allocated from the address range of the subnet to which the resource is attached. The address range of the subnet itself is a part of the VNet’s address range.
        • An IP address that is allocated by DHCP has infinite duration and is released only if you deallocate (stop) the VM.
        • The RFC 1918 standard defines three private address spaces that are never used for addressing on the Internet.
        • Administrators use these ranges behind Network Address Translation (NAT) devices to ensure unique addresses used within intranets never prevent communication with Internet servers.
        • There are two methods in which a private IP address is allocated: dynamic or static.
        • The default allocation method is dynamic, where the IP address is automatically allocated from the resource’s subnet (using DHCP). This IP address can change when you stop and start the resource.
        • You can set the allocation method to static to ensure the IP address remains the same. In this case, you also need to provide a valid IP address that is part of the resource’s subnet. Static private IP addresses are commonly used for:
          • VMs that act as domain controllers or DNS servers.
          • Resources that require firewall rules using IP addresses.
          • Resources accessed by other apps/resources through an IP address.
        • These three address spaces are the only ones that are supported within an Azure VNet.
          • 10.0.0.0/8: 10.0.0.1 – 10.255.255.255.
          • 172.16.0.0/12: 172.16.0.1 – 172.31.255.255.
          • 192.168.0.0/16: 192.168.0.1 – 192.168.255.255.
        • Private IP is associated with the followings:
          • Virtual Machine (Dynamic\Static): NIC
          • Load balancer-Internal (Dynamic\Static): front end configuration.
          • Application Gateway (Dynamic): front end configuration
        • When you create a VM, a mapping for the hostname to its private IP address is added to the Azure-managed DNS servers.
        • In case of a multi-network interface VM, the hostname is mapped to the private IP address of the primary network interface.
        • You cannot set a static private IP address during the creation of a VM in the Resource Manager deployment mode by using the Azure portal. You must create the VM first, then set its private IP to be static.
      • Public IP addresses: Public IP addresses allow Azure resources to communicate with external clients and Internet.
        • Public IP addresses allow Azure resources to communicate with Internet and Azure public-facing services such as Azure Redis Cache, Azure Event Hubs, SQL databases, and Azure storage.
        • Public IP addresses are allocated dynamically when you create a VM, and are bound to the NICs.
        • VMs with multiple NICs, only one of those (primary network interface) can have a Public IP. And any interface that have public IP is also going to have private IP as well.
        • The list of IP ranges from which public IP addresses (dynamic/static) are allocated to Azure resources is published at Azure Datacenter IP ranges.
        • Public IP can be assigned to the following:
          • Virtual Machine (Dynamic|Static): Associated with NIC.
          • Load Balancer – External (Dynamic|Static): Front-end configuration.
          • Application Gateway (Dynamic): Front end configuration.
          • VPN Gateway (Dynamic): Gateway IP configuration.
        • Dynamic allocation: Its the default allocation method, where public IP address is allocated when you start (or create) the associated resource (like a VM or load balancer). The IP address is released when you stop (or delete) the resource. This causes the IP address to change when you stop and start a resource.
        • Static allocation: To ensure the IP address for the associated resource remains the same, you can set the allocation method explicitly to static. In this case an IP address is assigned immediately. It is released only when you delete the resource or change its allocation method to dynamic. Static public IP addresses are commonly used in the following scenarios:
          • First 5 static addresses are free to use, extras are charged.
          • End-users need to update firewall rules to communicate with your Azure resources.
          • DNS name resolution, where a change in IP address would require updating A records.
          • Your Azure resources communicate with other apps or services that use an IP address-based security model.
          • You use SSL certificates linked to an IP address.
        • Basic: Assigned to VM, LB, Application and VPN Gateways in specific zones.
        • Standard: Assigned with Static allocation to NIC and LB only. Zone redundant by default.
        • For public IP resource, you can specify a DNS domain label, FQDN and CNAME record.
        • The DNS domain name label for a public IP resource, which creates a mapping for label.location.cloudapp.azure.com to the public IP address in the Azure-managed DNS servers.
          • You can use this FQDN to create a custom domain CNAME record pointing to the public IP address in Azure.
          • Each domain name label created must be unique within its Azure location.
    • Network Interface: They are used to configure IP addresses, Virtual Network settings, and DNS servers that will be assigned to a VM, Azure supports attaching multiple NICs to a VM.
      • VMs communicate with other VMs and other resources on the network by using virtual network interface cards (NICs). Virtual NICs configure VMs with private and optional public IP address. VMs can have more than one NIC for different network configurations.
      • You can apply only one NSG to a NIC at a time.
      • Multiple NICs in Virtual Machines:
        • You can create virtual machines (VMs) in Azure and attach multiple network interfaces (NICs) to each of your VMs.
        • Multi NIC is a requirement for many network virtual appliances, such as application delivery and WAN optimization solutions.
        • Multi NIC also provides more network traffic management functionality, including isolation of traffic between a front end NIC and back end NIC(s), or separation of data plane traffic from management plane traffic.
        • The address for each NIC on each VM must be located in a subnet and multiple NICs on a single VM can each be assigned addresses that are in the same subnet.
        • The VM size determines the number of NICS that you can create for a VM.
        • The following limitations are applicable when using the multi NIC feature:
          • Multi NIC VMs must be created in Azure virtual networks (VNets). Non-VNet VMs cannot be configured with Multi NICs.
          • All VMs in an availability set need to use either multi NIC or single NIC. There cannot be a mixture of multi NIC VMs and single NIC VMs within an availability set. Same rules apply for VMs in a cloud service.
          • A VM with single NIC cannot be configured with multi NICs (and vice-versa) once it is deployed, without deleting and re-creating it.
    • User Defined Routes: User Defined Routes (UDR) control network traffic by defining routes that specify the next hop of the traffic flow. You can assign User Defined Routes to virtual network subnets.
    • Forced Tunneling: With forced tunneling you can redirect internet bound traffic back to the company’s on-premises infrastructure. Forced tunneling is commonly used in scenario where organizations want to implement packet inspection or corporate audit.
    • VNet-to-VNet (vNet Peering):  Its used to connect two Azure virtual networks with each other.
      • Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a virtual network to an on-premises site location.
      • Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE.
      • The VNets you connect can be in different subscriptions and different regions.
      • You can combine VNet to VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.
      • All traffic is routed to Azure network
      • Faster and easier to setup than VPN and no public IP is required.
      • Peering relationships are not transitive
      • Changes to address space require repeating the peering
      • Can’t use overlap addresses
    • Cloud-Only Virtual Networks: When you create a VM or cloud service, you can specify endpoints that external clients can connect to. An endpoint is a VIP and a port number. Therefore an endpoint can be used only for a specific protocol, such as connecting a Remote Desktop Protocol (RDP) client or browsing a website. These VNets are known as cloud-only virtual networks.
      • A dynamic routing gateway is not required in the VNet.
      • Endpoints are published to the Internet, so they can be used by anyone with an Internet connection, including your on-premises computers.
  • Load Balancer: Deliver high availability and network performance to your applications.
    • Azure load balancer is a transport layer (layer 4) load balancer that distributes incoming traffic across healthy virtual machine instances in the same data center using a hash-based distribution algorithm.
    • By default, Azure load balancers use a 5tuple (source IP, source port, destination IP, destination port, protocol type) hash to distribute traffic across available servers.
    • You can configure the load balancer to: Load balance incoming traffic across your virtual machines OR Forward traffic to and from a specific virtual machine using NAT rules.
    • Azure load balancers also support network address translation (NAT) to route traffic between public and private IP addresses.
    • SKU: Standard load balancer up to 1000 instances, greater backend pool flexibility, HA ports, zone-redundant scenarios.
    • Load balance traffic between virtual machines in a virtual network, between virtual machines in cloud services, or between on-premises computers and virtual machines in a cross-premises virtual network. This is called internal load balancing.
    • Backend pool: You can associate a LB with Availability Set, VM Scale Set or Single VM.
    • An endpoint listens on a public port and forwards traffic to an internal port. You can map the same ports for an internal or external endpoint or use a different port for them. The creation of a public endpoint triggers the creation of a load balancer instance.
    • Hash based distribution: The load balancer uses a hash-based distribution algorithm.
      • By default, it uses a 5-tuple (source IP, source port, destination IP, destination port, and protocol type) hash to map traffic to available servers.
      • It provides stickiness only within a transport session.
      • Packets in the same TCP or UDP session will be directed to the same datacenter IP instance behind the load-balanced endpoint.
      • When the client closes and reopens the connection or starts a new session from the same source IP, the source port changes. This may cause the traffic to go to a different datacenter IP endpoint.
    • Port Forwarding: The load balancer gives you control over how inbound communication is managed. This communication can include traffic that’s initiated from Internet hosts or virtual machines in other cloud services or virtual networks. This control is represented by an endpoint (also called an input endpoint).
      • An endpoint listens on a public port and forwards traffic to an internal port. You can map the same ports for an internal or external endpoint or use a different port for them.
    • Service Monitoring: The load balancer can probe the health of the various server instances. When a probe fails to respond, the load balancer stops sending new connections to the unhealthy instances. Existing connections are not impacted. There are following types of probes:
      • Guest agent probe (on PaaS VMs only): The load balancer utilizes the guest agent inside the virtual machine. It listens and responds with an HTTP 200 OK response only when the instance is in the ready state (i.e. the instance is not in a state like busy, recycling, or stopping). If the guest agent fails to respond with an HTTP 200 OK, the load balancer marks the instance as unresponsive and stops sending traffic to that instance.
        • The load balancer will continue to ping the instance. If the guest agent responds with an HTTP 200, the load balancer will send traffic to that instance again.
        • When you’re using a web role, your website code typically runs in w3wp.exe, which is not monitored by the Azure fabric or guest agent. This means that failures in w3wp.exe (e.g. HTTP 500 responses) will not be reported to the guest agent, and the load balancer will not know to take that instance out of rotation.
      • HTTP custom probe: This probe overrides the default (guest agent) probe. You can use it to create your own custom logic to determine the health of the role instance. The load balancer will regularly probe your endpoint (every 15 seconds, by default). The instance will be considered in rotation if it responds with a TCP ACK or HTTP 200 within the timeout period (default of 31 seconds).
      • TCP custom probe: This probe relies on successful TCP session establishment to a defined probe port.
    • Source NATAll outbound traffic to the Internet that originates from your service undergoes source NAT (SNAT) by using the same VIP address as for incoming traffic.
      • It enables easy upgrade and disaster recovery of services, since the VIP can be dynamically mapped to another instance of the service.
      • It makes access control list (ACL) management easier, since the ACL can be expressed in terms of VIPs and hence do no change as services scale up or down or get redeployed.
      • The load balancer configuration supports full cone NAT for UDP. Full cone NAT is a type of NAT where the port allows inbound connections from any external host (in response to an outbound request).
      • For each new outbound connection that a VM initiates, an outbound port is also allocated by the load balancer. The external host will see traffic with a virtual IP (VIP)-allocated port. If your scenarios require a large number of outbound connections, we recommend that the VMs use instance-level public IP addresses so that they have a dedicated outbound IP address for SNAT. This will reduce the risk of port exhaustion.
      • The maximum number of ports that can be used by the VIP or an instance-level public IP (PIP) is 64,000. This is a TCP standard limitation.
    • Public load balancer: A public load balancer maps the public IP address and port number of incoming traffic to the private IP address and port number of the virtual machine and vice versa for the response traffic from the virtual machine.
      • You can associate a public IP address with an Azure Load Balancer, by assigning it to the load balancer frontend configuration.
      • The public IP address serves as a load-balanced virtual IP address (VIP).
      • You can assign either a dynamic or a static public IP address to a load balancer front-end.
      •  You can also assign multiple public IP addresses to a load balancer front-end, which enables multi-VIP scenarios like a multi-tenant environment with SSL-based websites.
    • Internal load balancer: Internal Load Balancer only directs traffic to resources that are inside a virtual network or that use a VPN to access Azure infrastructure.
      • You can assign a private IP address to the front end configuration of an Azure Internal Load Balancer (ILB) or an Azure Application Gateway.
      • This private IP address serves as an internal endpoint, accessible only to the resources within its virtual network (VNet) and the remote networks connected to the VNet.
      • You can assign either a dynamic or static private IP address. to the front end configuration.
  • Application GatewayBuild secure, scalable, and highly available web front ends in Azure.
    • Azure application gateway is a dedicated virtual appliance providing application delivery controller (ADC) as a service.
    • It offers various Layer 7 load balancing capabilities for your application.
    • It allows customers to optimize web farm productivity by offloading CPU-intensive SSL termination to the application gateway.
    • It also provides other Layer 7 routing capabilities including round robin distribution of incoming traffic, cookie-based session affinity, URL path-based routing, and the ability to host multiple websites behind a single application gateway.
    • Application gateway can be configured as an Internet-facing gateway, internal-only gateway, or a combination of both.
    • A web application firewall (WAF) is also provided as part of the application gateway WAF SKU. It provides protection to web applications from common web vulnerabilities and exploits.
    • Your virtual network and public IP address must be in the same location as your gateway. Ensure that virtual network subnet to be used with Application Gateway is empty that’s it contains no other resources.
    • Works at Application Layer (layer 7) and works as reverse proxy service.
    • Application gateways provide load-balanced solutions for network traffic that is based on the HTTP/HTTPS protocol.
    • They use routing rules as application-level policies that can offload Secure Sockets Layer (SSL) processing from load-balanced VMs.
    • In addition, you can use application gateways for a cookie-based session affinity scenario.
    • You can associate a public IP address with an Azure Application Gateway, by assigning it to the gateway’s frontend configuration. This public IP address serves as a load-balanced VIP. Currently, you can only assign a dynamic public IP address to an application gateway frontend configuration.
    • The default health monitoring tests servers every 30 seconds for a healthy HTTP response. A healthy HTTP response has a status code between 200 and 399.
    • HTTP layer 7 load balancing is useful for:
      • HTTP load balancing: Applications, such as a content delivery network, that requires multiple HTTP requests on the same long-running TCP connection to be routed or load balanced to different back-end servers.
        • URL-based content routing
        • Multi-site routing
      • Cookie-based session affinity: Applications that require requests from the same user/client session to reach the same back-end virtual machine. Examples of these applications would be shopping cart apps and web mail servers.
      • Secure Sockets Layer (SSL) offload: Applications that want to free web server farms from SSL termination overhead.
    • Application Gateway Requirements:
      • Back-end server pool: The list of IP addresses of the back-end servers. The IP addresses listed should either belong to the virtual network subnet or should be a public IP/VIP.
      • Back-end server pool settings: Every pool has settings like port, protocol, and cookie-based affinity. These settings are tied to a pool and are applied to all servers within the pool.
      • Front-end port: This port is the public port that is opened on the application gateway. Traffic hits this port, and then gets redirected to one of the back-end servers.
      • Listener: The listener has a front-end port, a protocol (Http or Https, these are case-sensitive), and the SSL certificate name (if configuring SSL offload).
      • Rule: The rule binds the listener and the back-end server pool and defines which back-end server pool the traffic should be directed to when it hits a particular listener.
  • Traffic Manager: Route incoming traffic for high performance and availability.
    • You can use Traffic Manager to load balance between endpoints that are located in different Azure regions, at hosted providers, or in on-premises datacenters. These endpoints can include Azure VMs, Web Apps, and cloud services.
    • You can configure this load-balancing service to support priority or to ensure that users connect to an endpoint that is close to their physical location for faster response.
    • Traffic Manager works at the DNS level. Traffic Manager uses DNS to direct end users to particular service endpoints. Clients then connect to the selected endpoint directly. Traffic Manager is not a proxy, and does not see the traffic passing between the client and the service.
    • When using a vanity domain with Azure Traffic Manager, you must use a CNAME to point your vanity domain name to your Traffic Manager domain name. Due to a restriction of the DNS standards, a CNAME cannot be created at the ‘apex’ (or root) of a domain.
      • Thus you cannot create a CNAME for ‘contoso.com’ (sometimes called a ‘naked’ domain). You can only crate a CNAME for a domain under ‘contoso.com’, such as ‘www.contoso.com’.
      • Thus you cannot use Traffic Manager directly with a naked domain. To work around this, we recommend using a simple HTTP re-direct to direct requests for ‘contoso.com’ to an alternative name such as ‘www.contoso.com’.
    • Traffic Manager provides two key benefits:
      • Distribution of traffic according to one of several traffic-routing methods
        • Ensure the user is directed to the closest version of an app
      • Continuous monitoring of endpoint health and automatic failover when endpoints fail
        • Stop routing users to a location if traffic goes down
  • Azure DNS: Host your DNS domain in Azure.
    • The Domain Name System (DNS) enables clients to resolve user-friendly fully qualified domain names (FQDNs), such as http://www.adatum.com, to IP addresses.
    • Names of resources that are created in Azure can be resolved by using Azure-provided name resolution or by using a customer provided DNS server.
    • Azure provides a DNS system to support many name resolution scenarios. However, in some cases, such as hybrid connection you might need to configure an external DNS system to provide name resolution for virtual machines on a virtual network.
    • In a hybrid scenario where your on-premises network is connected to an Azure virtual network through a VPN or ExpressRoute circuit, an on-premises computer cannot resolve the name of a VM in an Azure virtual network until you configure the DNS servers with a record for the VM.
    • Resources created in the same virtual network and deployed with Azure Resource Manager (ARM) share the same DNS suffix; therefore, in most cases name resolution by using FQDN is not required.
    • For virtual networks that are deployed by using the Azure classic deployment model, the DNS suffix is shared among VMs that belong to the same cloud service. Therefore, name resolution between VMs that belong to different cloud services in the same virtual network require the use of FQDN.
    • A DNS server should have a static IP address because clients may not be able to locate it if its address changes.
    • Azure DNS does not currently support purchasing of domain names. If you want to purchase domains, you’ll need to use a third-party domain name registrar. The domains can then be hosted in Azure DNS for management of DNS records.
    • Azure uses Anycast networking so that each DNS query is answered by the closest available DNS server. This provides both fast performance and high availability for your domain.
    • The root zone contains NS records for ‘com‘ and shows the name servers for the ‘com’ zone. In turn, the ‘com’ zone contains NS records for ‘contoso.com’, which shows the name servers for the ‘contoso.com’ zone. Setting up the NS records for a child zone in a parent zone is called delegating the domain.
    • Name Resolution Scenarios:
      • VMs in the same cloud service. VMs can resolve the names of all other VMs in the same cloud service automatically by using the internal Azure name resolution.
      • VMs in the same VNet. If the VMs are in different cloud services but within a single VNet, those VMs can resolve IP addresses for each other by using the internal Azure name resolution service and their Fully Qualified Domain Names (FQDNs). This is supported only for the first 100 cloud services in the VNet. Alternatively, use your own DNS system to support this scenario.
      • Between VMs in a VNet and on-premises computers. To support this scenario you must use your own DNS system.
      • Between VMs in different VNets. To support this scenario you must use your own DNS system.
      • Between on-premises computers and public endpoints. If you publish an endpoint from a VM in an Azure VNet, the Azure-provided external name resolution service will resolve the public VIP. This also applies for any internet-connected computers that are not on your premises.
      • If two VMs are deployed in different IaaS cloud services but not in a VNet, they cannot communicate at all, even by using DIPs. Therefore name resolution is not applicable.
    • If you are planning to use your own DNS system, you must ensure that all computers can reach a DNS server for registering and resolving IP addresses. You can either deploy DNS on a VM in the Azure VNet or have VM register their addresses with an on-premises DNS server.
    •  Your DNS server must meet the following requirements:
      • The server must support Dynamic DNS (DDNS) registration.
      • The server must have record scavenging switched off. Because DHCP leases in an Azure VNet are infinite, record scavenging can remove records that have not been renewed but are still correct.
      • The server must have DNS recursion enabled.
      • The server must be accessible on TCP/UDP port 53 from all clients.
    • Domains and ZonesThe Domain Name System is a hierarchy of domains.
      • The hierarchy starts from the ‘root’ domain, whose name is simply ‘.’.
      • Below this come top-level domains, such as com, net, org, uk or jp.
      • Below these are second-level domains, such as org.uk or co.jp. And so on.
      • The domains in the DNS hierarchy are hosted using separate DNS zones. These zones are globally distributed, hosted by DNS name servers around the world.
    • Domain registrar: A domain registrar is a company who can provide Internet domain names.
      • They will verify if the Internet domain you want to use is available and allow you to purchase it.
      • Once the domain name is registered, you will be the legal owner for the domain name. If you already have an Internet domain, you will use the current domain registrar to delegate to Azure DNS.
    • Zone Delegation: Azure DNS allows you to host a DNS zone and manage the DNS records for a domain in Azure. In order for DNS queries for a domain to reach Azure DNS, the domain has to be delegated to Azure DNS from the parent domain.
      • To delegate authority to DNS zone hosted in Azure, you contact the registrar for your domain name to configure the name server (NS) records with NS records listed in the zone created in Azure.
      • NS records are created by default when DNS zone is created
      • Each delegation actually has two copies of the NS records; one in the parent zone pointing to the child, and another in the child zone itself.  The abc.com zone contains the NS records for abc.com (in addition to the NS records in com).
      • Each registrar has their own DNS management tools to change the name server records for a domain. In the registrar’s DNS management page, edit the NS records and replace the NS records with the ones Azure DNS created.
    • Record: Its property of a record set and list of individual records.
    • Record Sets: Its child resource of a DNS Zone, and is the collection of records with the same name and type.  For example:
    • DNS Zones: Its used to host the DNS records for a particular domain.
      • A domain is a unique name in the Domain Name System, for example contoso.com. A DNS zone is used to host the DNS records for a particular domain. For example, the domain contoso.com may contain a number of DNS records such as mail.contoso.com (for a mail server) and http://www.contoso.com (for a website).
      • You do not have to own a domain in order to create a DNS zone with that domain name in Azure DNS. However, you do need to own the domain to set up the delegation to Azure DNS with the registrar.
    • DNS Servers:
      • Authoritative DNS server hosts DNS zones. It answers DNS queries for records in those zones only.
      • Recursive DNS server does not host DNS zones. It answers all DNS queries by calling authoritative DNS servers to gather the data it needs.
      • Azure DNS provides an authoritative DNS service. It does not provide a recursive DNS service.
      • Cloud Services and VMs in Azure are automatically configured to use a recursive DNS that is provided separately as part of Azure’s infrastructure.
    • Supports Etags to prevent accidental concurrent changes.
  • VPN Gateway: Establish secure, cross-premises connectivity.
    • Azure VPN Gateway is used to connect an Azure virtual network (VNet) to other Azure VNets or to an on-premises network.
    • Virtual networks in Microsoft Azure also enable you to extend your on-premises networks to the cloud. To extend your on-premises network, you can create a virtual private network (VPN) between your on-premises computers or networks and an Azure virtual network.
    • The VPN gateway routes traffic between VMs and PaaS cloud services in the virtual network, and computers at the other end of the connection.
    • A virtual network gateway is the software VPN device for your Azure virtual network.
    •  You need to assign a public IP address to its IP configuration to enable it to communicate with the remote network. Currently, you can only assign a dynamic public IP address to a VPN gateway.
    • All VPN connections require a virtual gateway in the virtual network, which routes traffic to the on-premises computers.
    • The following VPN connections are available: Point-to-site, Site-to-site, VNet-to-Vnet, IaaS v1 VNet-to-IaaS v2 VNet, Multisite, and ExpressRoute.
    • Considerations for inter-site connection:
      • Azure supports a maximum of 30 VPN tunnels per VPN gateway. Each point-to-site VPN, site-to-site VPN, or VNet-to-VNet VPN counts as one of those VPN tunnels. A single VPN gateway can support up to 128 connections from client computers.
      • Address spaces must not overlap.
      • Redundant tunnels are not supported.
      • All VPN tunnels to a virtual network share the available bandwidth on the Azure VPN gateway.
      • VPN devices must meet certain requirements. These requirements are listed on the Microsoft website
    • VPN Type:
      • Route-basedPoint-to-site, inter-virtual network, and multiple site-to-site VPN connections are only supported with a route-based virtual network gateway.
        • In addition, if you are creating a VPN-type gateway to coexist with an ExpressRoute gateway, the VPN gateway must be route-based and the ExpressRoute gateway must be created first.
        • SKU: Route-based VPN gateway types are offered in three SKUs: Basic, Standard, and High Performance. Standard or High Performance must be chosen if the gateway is being created to coexist with an ExpressRoute gateway.
      • Policy-based:
        • SKU: Basic only
    • Point-to-Site VPN (P2S): This is a VPN that connects individual computers to an Azure virtual network.
      • No extra hardware is required but you must complete the configuration procedure on every computer that you want to connect to the VNet.
      • Can be used by the client computer to connect to a VNet from any location with an Internet connection.
      • Each client that connects to Azure by using Point-to-Site must have two things: the VPN client must be configured to connect, and the client must have a client certificate installed. VPN client configuration packages are available for Windows clients.
      • Configuration:
        • Configure an IP address space for clients
        • Configure a virtual gateway
        • Create root and client certificates
        • Create and install VPN client configuration
        • Connect to the VPN
    • Site-to-Site VPN (S2S)This is a VPN that connects an on-premises network and all its computers to an Azure virtual network.
      • A Site-to-Site (S2S) connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel.
      • This type of connection requires a VPN device located on-premises that has a public IP address assigned to it and is not located behind a NAT.
      • S2S connections can be used for cross-premises and hybrid configurations.
      • To create this connection, you must configure a gateway and IP routing in the on-premises network; it is not necessary to configure individual on-premises computers.
      •  You can use a Windows Server 2012 computer running RRAS as a gateway to the VNet. Alternatively, there are a range of third-party VPN devices that are known to be compatible.
      •  If you have a VPN device that is not on the known compatible list, you may be able to use it if it satisfies the list of gateway requirements.
      • If you have overlapping subnets, your connection won’t work properly.
      • To configure your VPN device, you’ll need the public IP address of the virtual network gateway for configuring your on-premises VPN device. Work with your device manufacturer for specific configuration information and configure your device.
      • To verify the connection run the following command:
        • Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConn -ResourceGroupName MyRG
      • Configuration of a Site-to-Site VPN:
        • An IP addressing scheme in the VNet.
        • The range of IP addresses that are available on the local, on premises subnet.
        • A gateway in the local subnet.
        • A virtual gateway in the VNet.
      • Gateway Subnet: You need to create a gateway subnet for the virtual network to which you want to connect. The gateway subnet you create must be named GatewaySubnet or it won’t work properly.
        • The gateway subnet prefix needs to be /28, /27, /26 etc.
        • Associating a Network Security Group (NSG) to the GatewaySubnet will cause your VPN gateway to stop functioning as expected. DO NOT associate NSGs to Gateway subnets.
      • Virtual Network Gateway: A virtual network gateway is the software VPN device for your Azure virtual network.
        • Use this with a connection to set up a site-to-site VPN connection between an Azure virtual network and your local network, or a VNet-to-VNet VPN connection between two Azure virtual networks.
        • It can also be used to connect a virtual network to an ExpressRoute circuit.
        • Because the virtual gateway is configured with the IP addresses in the VNet and the IP addresses in the local network, it can route packets from Azure to the local network.
      • Local Network Gateway: It represents the hardware or software VPN device in your local network.
        • Use this with a connection to set up a site-to-site VPN connection between an Azure virtual network and your local network.
        • There are no additional charges for creating local network gateways in Microsoft Azure.
        • IP address: If this local network represents an on-premises location, this is the public IP address of the VPN device that you want to connect to. It cannot be behind NAT and has to be reachable by Azure. If this local network represents another VNet, you will specify the public IP address that was assigned to the virtual network gateway for that VNet.
        • Address space: refers to the address ranges for the network that this local network represents. You can add multiple address space ranges. Make sure that the ranges you specify here do not overlap with ranges of other networks that you want to connect to.
    • VNet-to-VNet:
      • Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a VNet to an on-premises site location.
      •  Both connectivity types use an Azure VPN gateway to provide a secure tunnel using IPsec/IKE.
      • You can even combine VNet-to-VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.
      • The VNets you connect can be in the same or different Regions, Subscriptions or Deployment Models.
      • cloud service or a load balancing endpoint CANNOT span across virtual networks, even if they are connected together.
      • VNet-to-VNet requires Azure VPN gateways with RouteBased (previously called Dynamic Routing) VPN types.
      • VNet-to-VNet traffic travels across the Microsoft Network, not the Internet.
      • VNet-to-VNet traffic within the same region is free for both directions; cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions.
      • Virtual network connectivity can be used simultaneously with multi-site VPNs, with a maximum of 10 (Default/Standard Gateways) or 30 (High Performance Gateways) VPN tunnels for a virtual network VPN gateway connecting to either other virtual networks or on-premises sites.
      • The address spaces of the virtual networks and on-premises local network sites must not overlap. Overlapping address spaces will cause the creation of VNet-to-VNet connections to fail.
      • Redundant tunnels between a pair of virtual networks are not supported.
      • When you configure a VNet-to-VNet connection, you must specify the IP address spaces in use for private IP addresses on the opposite virtual networks so that the virtual gateway can route traffic to the correct location. In the user interface, this is referred to as the local network.
      • Configurations:
        • An IP addressing scheme in the West US VNet.
        • An IP addressing scheme in the North Europe VNet.
        • A virtual gateway in the West US VNet.
        • A virtual gateway in the North Europe VNet.
      • You may want to connect virtual networks for the following reasons:
        • Cross region geo-redundancy and geo-presence
        • Regional multi-tier applications with isolation or administrative boundary
  • ExpressRoute: Dedicated private fiber network connections to Azure.
    • Microsoft Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a dedicated private connection facilitated by a connectivity provider.
    • With ExpressRoute, you can establish connections to Microsoft Azure services, Microsoft Office 365, and Microsoft CRM Online.
    • Connectivity can be from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a connectivity provider at a co-location facility.
    • ExpressRoute connections do not go over the public Internet. This allows ExpressRoute connections to offer more reliability, faster speeds, lower latencies, and higher security than typical connections over the Internet.
    • You can connect to Microsoft in one of our peering locations and have access to all regions within the geopolitical region. For example, if you connected to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in Northern Europe and Western Europe.
    • You can enable the ExpressRoute premium add-on feature to extend connectivity across geopolitical boundaries. For example, if you are connected to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in all regions across the world.
    • You can purchase ExpressRoute circuits for a wide range of bandwidths i.e 50 Mbps – 10 Gbps.
    • Connection Options:
      • Connectivity providers can offer one or more connectivity models. You can work with your connectivity provider to pick the model that works best for you.
      • ExpressRoute capabilities and features are all identical across all of the below connectivity models.
      • 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) networksYou 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.
    • Features:
      • Layer 3 connectivityMicrosoft uses industry standard dynamic routing protocol (BGP) to exchange routes between your on-premises network, your instances in Azure, and Microsoft public addresses. Azure establish multiple BGP sessions with your network for different traffic profiles.
      • RedundancyEach ExpressRoute circuit consists of two connections to two Microsoft Enterprise edge routers (MSEEs) from the connectivity provider / your network edge. Microsoft will require dual BGP connection from the connectivity provider / your side – one to each MSEE. You may choose not to deploy redundant devices / Ethernet circuits at your end. A redundant Layer 3 connectivity configuration is a requirement for our SLA to be valid.
      • Dynamic scaling of bandwidthYou have the ability to increase the ExpressRoute circuit bandwidth (on a best effort basis) without having to tear down your connections.
  • Virtual Appliance:
    • A pre-configured virtual machine image, ready to run on a hypervisor, virtual appliances are a subset of the broader class of software appliances.
      • Replicate on-premises equipment in the Azure cloud
      • Leaverage existing expertise and configurations
      • Need for more robust network services
      • Load balancer, firewall, Application Delivery Controller (ADC), WAN optimizer
      • Its deployed into its own subnet in the virtual network
      • You need to define user-defined routes by defining next hop in Route Tables
      • You need to enable IP forwarding in virtual appliance
  • Content Delivery Network: Ensure secure, reliable network delivery with broad global reach.
  • Network Watcher: Network performance monitoring and diagnostic solution.
  • DDOS Protection: Protect your applications from Distributed Denial of Service (DDoS) attacks.
Advertisements

About Ishtiaque

I am IBM Certified Infrastructure Systems Architect, Linux Foundation Certified System Administrator, Oracle Certified Programmer in Java and Web Component Developer, and TOGAF 9 certified with over 10 years of support and development experience in IBM middleware software and Java. Additionally, have a sound grip in databases and OpenStack administration. I hold the following certifications: IBM Certified Infrastructure Systems Architect Linux Foundation Certified System Administrator (LFCS) TOGAF 9 Certified Oracle Certified Expert, Java EE6 Web Component Developer Oracle Certified Professional – Java 6 Programmer ITIL v3 Foundation Certified IBM Certified Solution Architect – Cloud Computing Infrastructure V1 IBM Certified System Administrator – WebSphere Portal V8, V7, V6.1, V6 IBM Certified System Administrator – WebSphere Application Server V7, V6.1 IBM Certified System Administrator – AIX V7 IBM Certified System Administrator – WebSphere MQ V7 IBM Certified Deployment Professional – Business Process Manager Advanced V7.5 IBM Certified Solution Advisor – Cloud Computing Architecture V3 IBM Certified Solution Developer – WebSphere Portal V5.1
This entry was posted in azure. Bookmark the permalink.