Category Archives: Networking

Azure Virtual WAN: introduction to the solution

Azure Virtual WAN is a new network service that allows you to optimize and automate the branch-to-branch connectivity through Azure. Thanks to this service you can connect and configure network devices in branch to allow communication with Azure (branch-to-Azure). This article examines the components involved in Azure Virtual WAN and shows the procedure to be followed for its configuration.

 

Figure 1 – Azure Virtual WAN overview

The Azure Virtual WAN configuration includes the creation of the following resources.

 

Virtual WAN

The Virtual WAN resource represents a virtual layer of Azure network and collect different components. It is a layering that contains links to all the virtual hubs that you want to have inside the Virtual WAN. Virtual WAN resources are isolated and cannot contain common hubs.

Figure 2 – Start the process of creating Azure Virtual WAN

Figure 3 – Creating Azure Virtual WAN

When creating the Virtual WAN resource you are prompted to specify a location. In reality it is a global resource that does not reside in a particular region, but you are prompted to specify it just to be able to manage and locate more easily.

By enabling the option Network traffic allowed between branches associated with the same hub allows traffic between the various sites (VPN or ExpressRoute) associated with the same hub (branch-to-branch).

Figure 4 – Branch-to-branch connectivity option

 

Site

The site represents the on-prem environment. You will need to create as many sites as are the physical location. For example, if you have a branch office in Milan, one in New York and one in London, you will need to create three separate sites, which contain their endpoints of network devices used to establish communication. If you are using Virtual WAN partner network equipment, provides solutions to natively export this information into the Azure environment.

Figure 5 – Creating a site

In the advanced settings you can enable BGP, which if activated becomes valid for all connections created for the specific site . Among the optional fields you can specify device information, that may be of help to the Azure Team in case of any future enhancements or Azure support.

 

Virtual Hub

A Virtual Hub is a Microsoft-managed virtual network. The hub is the core component of the network in a given region and there can be only one hub for Azure region. The hub contains different service endpoints to allow to establish connectivity with the on-prem environment. Creating a Virtual Hub involves the generation of a new VNet and optionally a new VPN Gateway. The Hub Gateway is not a classic virtual network gateway that is used for ExpressRoute connectivity and VPN and it is used to create a Site-to-site connection between the on-prem environment and the hub.

Figure 6 – Creating a Hub

Figure 7 -Association of the site with a Hub

The Hubs should be associated with sites residing in the same region where there are the VNet.

 

Hub virtual network connection

The resource Hub virtual network connection is used to connect the hub with the virtual network. Currently you can create connections (peering) with virtual networks that reside in the same region of the hub.

Figure 8 – Connection of the VNet to a hub

Configuring the VPN device on-prem

To configure the VPN on-prem device, you can proceed manually, or if you are using Virtual WAN partner solutions, the configuration of the VPN devices can occur automatically. In the latter case the device controller gets the configuration file from Azure and applies the configuration to devices, avoiding the need to proceed with manual configurations. It all feels very comfortable and effective, saving time. Among the various virtual WAN partners we find: Citrix, Riverbed, 128 Technology, Barracuda, Check Point, NetFoundry and Paloalto. This list is intended to expand soon with more partners.

By selecting Download VPN configuration creates a storage account in the resource group 'microsoft-network-[location]’ from which you can download the configuration for the VPN device on-prem. That storage account can be removed after retrieving the configuration file.

Figure 9 - Download the VPN configuration

Figure 10 – Download the configuration file on the storage account

After configuration of the on-prem device, the site will be connected, as shown in the following figure:

Figure 11 - State of the connected site

It also provides the ability to establish ExpressRoute connections with Virtual WAN, by associating the circuit ExpressRoue to the hub. It also provides for the possibility of having Point-to-Site connections (P2S) towards the virtual Hub. These features are now in preview.

The Health section contains useful information to check the connectivity for each Hub.

Figure 12 – Check Hub health

 

Conclusions

Virtual WAN is the new Azure service that enables centralized, simple and fast connection of several branch, with each other and with the Microsoft public cloud. This service allows you to get a great experience of connectivity, taking advantage of the Microsoft global network, which can boast of reaching different region around the world, more than any other public cloud providers.

Azure Networking: characteristics of Global VNet peering

The Virtual Networks in Azure are logically isolated, to allow you to securely connect different Azure resources. The Global VNet peering in Azure provides the possibility of connecting virtual networks residing on different regions of Azure. This article discusses the benefits and current constraints imposed by the Global VNet peering. It will also show the procedure for activating a Global VNet peering.

Figure 1 - Sample connection of two Azure VNet in different regions

When you configure the peering between two virtual networks that reside in different regions of Azure, you expand the logical boundary and virtual machines attested on these VNet can communicate with each other with their own private IP addresses, without having to use gateway and public IP addresses. In addition, you can use the hub-and-spoke network model, to share resources such as firewalls or virtual appliances, even connecting virtual networks in different regions of Azure, through the Global VNet peering.

Benefits of Global VNet peering

The main benefits that can be obtained using the Global VNet peering to connect virtual networks are:

Figure 2 – Microsoft's backbone network

  • You can use a low-latency connectivity and with a high bandwidth.
  • Setup is simple and does not require gateway to establish VPN tunnel between different networks.

 

Current constraints of Global VNet peering

Currently there are some constraints that should be taken into account when making a Global VNet peering:

  • In the presence of a Global peering VNET you can not use the remote gateway (option "use remote gateways") and you can't allow the gateway transit (option "allow gateway transit") on the virtual network. These options are currently usable only when you make a virtual network peering with virtual networks residing within the same region of Azure. It follows then the Global VNet peering are not transitive, then the downstream VNet in a region cannot communicate, using this methodology, with the VNet to another region. For example,, assuming a scenario where between the vNet1 and the vNet2 there is a Global VNet peering and between vNet2 and vNet3 there is another Global VNet peering. In this case there will be no communication between the vNet1 and the vNet3. If needed, you can create an additional Global VNET peering to put them in communication.
  • For a resource that resides on a virtual network, is not allowed to communicate using the IP address of an internal Azure load balancer that resides on the virtual network in peer. This type of communication is allowed only if the source IP and the IP address of the Load Balancer are in the same VNet.
  • The Global VNet peering can be created in all Azure public regions, but not with VNet residing in Azure national clouds.
  • The creation of the Global VNet peering is allowed between VNet residing in different subscriptions, as long as they are associated with the same Active Directory tenant.
  • The virtual networks can inserted into peering if there is no overlapping in its address space. In addition, after the creation of the peering, if you need to modify the address space you must remove the peering.

 

Global VNet peering configuration

Configuring Global VNet peering is extremely simple. In the following images are documented the steps to connect two virtual networks created in different regions, in this case West Europe and Southeast Australia.

Figure 3 - Adding peering from VNet settings

Figure 4 - Configure the peering parameters

Selecting "Allow virtual network access", allows communication between two virtual networks. With this setting the address space of the VNet in peer is added to the tag Virtual_Network.

Figure 5 – Peering added, in state Initiated

The same operations, documented in Figure 3 and figure 4, must be repeat even on the Virtual Network that resides in the other region and with whom you want to configure the Global VNet peering. The communication will be activated when the status of the peering will be "Connected"on both VNet.

Figure 6 – Peering in state Connected

Selecting a virtual machine, attested on a virtual network configured with the global VNET Peering, you will see a specific route for VNet associated, as shown in the following figure:

Figure 7 – Effective route of the VNet in Global Peering

The Global VNet peering involves costs for inbound and outbound network traffic in transit in the peering and the cost varies depending on the areas covered. For more details you can refer to the official page of costs.

 

Conclusions

The Global VNet peering allows a great flexibility in managing in a simple and efficient way as various workloads can be connected, allowing to expand the possible implementation scenarios on Azure, without having to consider the geographical boundaries as a limit. Significant benefits can be obtained in particular in data replication and disaster recovery architectures.

Azure Networking: introduction to the Hub-Spoke model

A network topology increasingly adopted by Microsoft Azure customers is the network topology defined Hub-Spoke. This article lists the main features of this network architecture, examines the most common use cases, and shows the main advantages that can are obtained thanks to this architecture.

The Hub-Spoke topology

In a Hub-Spoke network architecture, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. The Spoke are virtual networks running the peering with the Hub and can be used to isolate workloads.

The architecture basic scheme:

Figure 1 – Hub-Spoke basic network architecture

This architecture is also designed to position in the Hub network a network virtual appliance (NVA) to control the flow of network traffic in a centralized way.

Figure 2 - Possible architecture of Hub vNet in the presence of NVA

In this regard it should be noted that Microsoft recently announced the availability of the’Azure Firewall, a new managed service and fully integrated into the Microsoft public cloud, that allows you to secure the resources present on the Virtual Networks of Azure. At the moment the service is in preview, but soon it will be possible to assess the adoption of Azure Firewall to control centrally, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. This service, in the presence of Hub-Spoke network architectures , lends itself to be placed in the Hub network, in order to obtain complete control of network traffic.

Figure 3 - Positioning Azure Firewall in the Hub Network

For additional details on Azure Firewall you can see Introduction to Azure Firewall.

When you can use the Hub-Spoke topology

The network architecture Hub-Spoke is typically used in scenarios where these characteristics are required in terms of connectivity:

  • In the presence of workloads deployed in different environments (development, testing and production) which require access to the shared services such as DNS, IDS, Active Directory Domain Services (AD DS). Shared services will be placed in the Hub virtual network, while the various environments (development, testing and production) will be deployed in Spoke networks to maintain a high level of insolation.
  • When certain workloads must not communicate with all other workloads, but only with shared services.
  • In the presence of reality that require a high level of control over aspects related to network security and needing to make a segregation of the network traffic.

Figure 4 – Hub-Spoke architecture design with its components

The advantages of the Hub-Spoke topology

The advantages of this Azure network topology can be summarized as:

  • Cost savings, because shared services can be centralized in one place and used by multiple workloads, such as the DNS server and any virtual appliances. It also reduces the VPN Gateways to provide connectivity to the on-premises environment, with a cost savings for Azure.
  • Granular separation of tasks between IT (SecOps, InfraOps) and workloads (Devops).
  • Greater flexibility in terms of management and security for the Azure environment.

Useful references for further reading

The following are the references to the Microsoft technical documentation useful to direct further investigation on this topic:

Conclusions

One of the first aspects to consider when you implement solutions in the cloud is the network architecture to be adopted. Establish from the beginning the most appropriate network topology allows you to have a winning strategy and avoid to be in the position of having to migrate workloads, to adopt different network architectures, with all the complications that ensue.

Each implementation requires a careful analysis in order to take into account all aspects and to make appropriate assessments. It is therefore not possible to assert that the Hub-Spoke network architecture is suitable for all scenarios, but certainly it introduces several benefits that make it effective for obtaining certain characteristics and have a high level of flexibility.

What's new in Virtual Machine Manager 1807

Following the first announcement of the Semi-Annual Channel release of System Center, took place in February with the version 1801, in June has been released the new update release: System Center 1807. This article will explore the new features introduced in System Center Virtual Machine Manager (SCVMM) the update release 1807.

Networking

Information related to the physical network

SCVMM 1807 introduced an important improvement in the field of network. In fact, using the Link Layer Discovery Protocol (LLDP), SCVMM can provide information regarding connectivity to the physical network of Hyper-V hosts. These are the details that SCVMM 1807 can retrieve:

  • Chassis ID: Switch chassis ID
  • Port ID: The Switch port to which the NIC is connected
  • Port Description: Details on the port, such as the Type
  • System Name Manufacturer: Manufacturer and Software version details
  • System Description
  • Available Capabilities: Available features of the system (such as switching, Routing)
  • Enabled Capabilities: Features that are enabled on the system (such as switching, Routing)
  • VLAN ID: Virtual LAN identifier
  • Management Address: management IP address

The consultation of this information can be via Powershell or by accessing the SCVMM console: View > Host > Properties > Hardware Configuration > Network adapter.

Figure 1 – Information provided by SCVMM 1807 regarding the physical connectivity of Hyper-V hosts

These details are very useful for having visibility on the physical network and to facilitate troubleshooting steps. This information will be made available for Hyper-V hosts that meet the following requirements:

  • Windows Server Operating System 2016 or later.
  • Features DataCenterBridging and DataCenterBridging-LLDP-Tools enabled.

Conversion SET in Logical Switch

SCVMM 1807 can convert a Hyper-V Virtual Switch, created in Switch Embedded Teaming mode (SET), in a logical switch, using directly the SCVMM console. In previous versions of SCVMM this operation was feasible only through PowerShell commands. This conversion can be useful to generate a Logical Switch, that can be used as a template on different Hyper-V hosts that are managed by SCVMM. For more information on Switch Embedded Teaming (SET) I invite you to consult the article Windows Server 2016: the new Virtual Switch in Hyper-V

Support for host VMware ESXi v6.5

SCVMM 1807 introduced support for VMware ESXi host v 6.5 within its fabric. For what is my experience, even in environments that consist of multiple hypervisors, hardly you use SCVMM to manage VMware host. This support is important because it introduces the ability to convert VMs hosted on VMWare ESXi host 6.5 in Hyper-v VMs.

 

Storage

Support for selecting the CSV to use when adding a new disk

SCVMM 1807 allows you to specify, during the addition of a new virtual disk to an existing VM, in which cluster shared volumes (CSV) place it. In previous releases of VMM this possibility was not provided and by default the new virtual disks were placed on the same CSV where the disks that have been associated with the virtual machine were present. In some circumstances, such as in the presence of CSV with little free space available, this behavior could be inadequate and inflexible.

Figure 2 – Adding a new disk to a virtual machine by selecting which CSV place it

Support for the update of cluster Storage Spaces Direct (S2D)

In Virtual Machine Manager 2016 there is support for making the deployment of Storage Spaces Direct cluster (S2D). With SCVMM 1807 has also introduced the possibility of patching and update of Storage Spaces Direct cluster nodes, orchestrating the entire update process, which will use the baseline configured in Windows Server Update Services (WSUS). This feature allows you to more effectively manage the Storage Spaces Direct environment, cornerstone of the Software Defined Storage of Microsoft, that leads to the achievement of the Software Defined Data Center.

 

Statement of support

Support for SQL Server 2017

In SCVMM 1807 was introduced the support for SQL Server 2017 to host its database. This allows you to upgrade from SQL Server 2016 to SQL Server 2017.

 

Conclusions

The update release 1807 introduces several innovations in Virtual Machine Manager that greatly enrich it in terms of functionality. In addition, This update also addresses a number of issues listed in Microsoft's official documentation. It is therefore recommended to evaluate an update of the Virtual Machine Manager deployments, for greater stability and to take advantage of the new features introduced. Remember that the release belonging to the Semi-Annual Channel have a support period of 18 months.

To try out System Center Virtual Machine Manager, you must access to theEvaluation Center and after the registration you can start the trial period.

Introduction to Azure Firewall

Microsoft recently announced the availability of a long-awaited service required by the users of systems in the Azure environment , it is the’Azure Firewall. The Azure Firewall is a new managed service and fully integrated into the Microsoft public cloud, that allows you to secure the resources present on the Virtual Networks of Azure. This article will look at the main features of this new service, currently in preview, and it will indicate the procedure to be followed for its activation and configuration.

Figure 1 – Positioning of Azure Firewall in network architecture

The Azure Firewall is a type of firewall stateful, which makes it possible to centrally control, through policy enforcement, network communication streams, all cross subscriptions and cross virtual networks. This service, in the presence of type of network architectures hub-and-spoke, lends itself to be placed in the Hub network, in order to obtain a complete control of the traffic.

The Azure Firewall features, currently available in this phase of public preview, are the following:

  • High availability (HA) Built-in: high availability is integrated into the service and are not required specific configurations or add-ons to make it effective. This is definitely an element that distinguishes it compared to third-party solutions that, for the configuration of Network Virtual Appliance (NVA) in HA, typically require the configuration of additional load balancers.
  • Unrestricted cloud scalability: Azure Firewall allows you to scale easily to adapt to any change of network streams.
  • FQDN filtering: you have the option to restrict outbound HTTP/S traffic towards a specific list of fully qualified domain names (FQDN), with the ability to use wild card characters in the creation of rules.
  • Network traffic filtering rules: You can create rules to allow or of deny to filter the network traffic based on the following elements: source IP address, destination IP address, ports and protocols.
  • Outbound SNAT support: to the Azure Firewall is assigned a public static IP address, which will be used by outbound traffic (Source Network Address Translation), generated by the resources of the Azure virtual network, allowing easy identification from remote Internet destinations.
  • Azure Monitor logging: all events of Azure Firewall can be integrated into Azure Monitor. In the settings of the diagnostic logs you are allowed to enable archiving of logs in a storage account, stream to an Event Hub, or set the sending to a workspace of OMS Log Analytics.

Azure Firewall is currently in a managed public preview, which means that to implement it is necessary to explicitly perform the enable via the PowerShell command Register-AzureRmProviderFeature.

Figure 02 – PowerShell commands for enabling the public preview of Azure Firewall

Feature registration can take up to 30 minutes and you can monitor the status of registration with the following PowerShell commands:

Figure 03 – PowerShell commands to verify the status of enabling Azure Firewall

After registration, you must run the following PowerShell command:

Figure 04 – Registration command of Network Provider

To deploy the Azure Firewall on a specific Virtual Network requires the presence of a subnet called AzureFirewallSubnet, that must be configured with a sunbnet mask at least /25.

Figure 05 – Creation of the subnet AzureFirewallSubnet

To deploy Azure Firewall from the Azure portal, you must select Create a resource, Networking and later See all:

Figure 06 - Search Azure Firewall in Azure resources

Filtering for Firewall will also appear the new resource Azure Firewall:

Figure 07 – Microsoft Firewall resource selection

By starting the creation process you will see the following screen that prompts you to enter the necessary parameters for the deployment:

Figure 08 – Parameters required for the deployment of the Firewall

Figure 09 – Review of selected parameters and confirmation of creation

In order to bring outbound traffic of a given subnet to the firewall you must create a route table that contains a route with the following characteristics:

Figure 10 - Creation of the Rule of traffic forwarding to the Firewall Service

Although Azure Firewall is a managed service, you must specify Virtual appliance as next hop. The address of the next hop will be the private IP of Azure Firewall.

The route table must be associated with the virtual network that you want to control with Azure Firewall.

Figure 11 - Association of the route table to the subnet

At this point, for systems on the subnet that forwards the traffic to the Firewall, is not allowed outgoing traffic, as long as it is not explicitly enabled:

Figure 12 – Try to access blocked website from Azure Firewall

Azure Firewall provides the following types of rules to control outbound traffic.

Figure 13 – The available rule Types

  • Application rules: to configure access to specific fully qualified domain names (FQDNs) from a given subnet.

Figure 14 - Creating Application rule to allow access to a specific website

  • Network rules: enable the configuration of rules that contain the source address, the protocol, the address and port of destination.

Figure 15 – Creating Network rule to allow traffic on port 53 (DNS) towards a specific DNS Server

Conclusions

The availability of a fully integrated firewall in the Azure fabric is certainly an important advantage that helps to enrich the capabilities provided natively by Azure. At the time are configurable basic operations, but the feature set is definitely destined to get rich quickly. Please note that this service is currently in preview, and no service level agreement is guaranteed and is not recommended to use it in production environments.

Azure Application Gateway: monitoring with Log Analytics

Azure Application Gateway is an application load balancer (OSI layer 7) for web traffic, available in Azure environment, that manages HTTP and HTTPS traffic of the applications. This article is discussed how to monitor of Azure Application Gateway using Log Analytics provides.

Figure 1 - Azure Application Gateway basic schema

Using the Azure Application Gateway you can take advantage of the following features:

  • URL-based routing
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Native support for WebSocket and HTTP/2 protocols

For more details on Azure Application Gateway can be found in the Microsoft's official documentation.

Configuring Diagnostics logs for the Application Gateway

The Azure Application Gateway can send diagnostic logs to a workspace of Log Analytics . This feature is very useful for checking the performance, to detect any errors and is essential for troubleshooting steps, in particular in the presence of the WAF module. To enable the diagnostic from the Azure portal you can select the Application Gateway resource and go to the "Diagnostics logs":

Figure 2 – Starting configuration of Diagnostics logs

Figure 3 – Configuring Diagnostics logs

After choosing your Log Analytics workspace where to send diagnostics data, in the Log section, you can select which type of log collecting among the following:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): these logs are generated only if the Web Application Firewall is configured on the Application Gateway.

In addition to these logs are also collected by default Activity Log generated by Azure. These logs are maintained for 90 days in the store of the Azure event logs. For more details you can refer this specific document.

Azure Application Gateway analytics solution of Log Analytics

Microsoft offers the solution Azure Application Gateway analytics that can be added to the workspace of Log Analytics by following these simple steps:

Figure 4 - Launching the procedure of adding the solution to the OMS workspace

Figure 5 – Selection of the Azure Application Gateway analytics solution

Figure 6 - Addition of the solution in the selected workspace

After enabling the sending of diagnostics logs into the workspace of Log Analytics and adding the solution to the same, by selecting the tile Azure Application Gateway analytics in the Overview page, you can see an overview of the collected log data from the Application Gateway:

Figure 7 – Screen overview of the Azure Application Gateway analytics solution

You can also view the details for the following categories.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways

Figure 8 - Screenshot of the Application Gateway Access logs

  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests

Figure 9 – Screenshot of the Application Gateway performance

Customized dashboard of Log Analytics for the Application Gateway monitor

In addition to this solution can also be convenient to use a special dashboard of Log Analytics, specifically for the monitoring of the Application Gateway, available at this link. The deployment of the dashboard is via ARM template and requires also in this case the Diagnostics logs of the Application Gateway enabled, as described above. The various queries of Log Analytics, used by the dashboard, are documented in this blog. Thanks to these queries the dashboard shows several additional information exposed by the diagnostic of the Application Gateway.

Figure 10 – Custom dashboard of Log Analytics for Application Gateway monitoring

Query of Log Analytics to monitor the Firewall Log

Using the solution Azure Application Gateway analytics of Log Analytics or the custom dashboard (stated in the previous paragraph) are not contemplated at the time the Firewall log, generated when is active the Web Application Firewall (WAF) on the Application Gateway. The WAF is based on rules of OWASP Core Rule Set 3.0 or 2.2.9 to intercept attacks, for the web applications, that exploit the known vulnerabilities. To name a few, we find for example the SQL injection and attacks cross site scripting.

In this case, if you decide to check the Firewall log, you must directly query the Log Analytics, for example:

Figure 11 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI, divided by RuleID

To see the list of rules of the WAF, by associating the RuleId to its description, you can consult this document.

The descriptive message of the rule is also listed within the results returned by the query:

Figure 12 – The Query to retrieve blocked requests by the WAF module, over the past 7 days, for a specific URI and for a specific RuleId

Conclusions

In my experience, in Azure architectures that require secure publishing of web services to Internet, is often used Azure Application Gateway service with the WAF module active. With the ability to send diagnostic logs of this component to Log Analytics you have the option of having a qualified monitor, that is fundamental to analyse any error conditions and to assess the state of the component in all its facets.

Microsoft Azure: network monitoring solutions overview

Microsoft Azure provides several solutions that allow you to monitor network resources, not only for cloud environments, but even in the presence of hybrid architectures. That are cloud-based features, to check the health of your network and connectivity to your applications. In addition, they give detailed information about network performance. This article will be made an overview of the various solutions such as the main features, needed to orient the use of the network monitor tools most appropriate for your needs.

Network Performance Monitor (NPM) is a suite that includes the following solutions:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

In addition to the tools included in the Network Performance Monitor (NPM) you can use Traffic Analytics and DNS Analytics.

Performance Monitor

The most commonly used approach is to have hybrid environments with heterogeneous networking, that allows you to connect your own on-premises infrastructure with the environment implemented in the public cloud. In some cases you may also have different cloud providers, that make the network infrastructure even more complicated . These scenarios require the use of flexible monitor tools that can work across on-premises, in cloud (IaaS), and in hybrid environments. Performance Monitor has all of these characteristics and thanks to the use of synthetic transactions, provides the ability to monitor, almost in real time, the network parameters to get performance information, like packet loss and latency. In addition, this solution allows to easily locate the source of a problem in a specific network segment or identifying a particular device. The solution requires the presence of the OMS agent and keeping track of the retransmission packets and the roundtrip time, it is able to return a graph of easy and immediate interpretation.

Figure 1 - Hop-by-hop chart provided by Performance Monitor

Where to install the agents

The installation of the agent of Operations Management Suite (OMS) is necessary on at least one node connected to each subnet from which it intends to monitor the connectivity to other subnets. If you plan to monitor a specific network link you must install agents on both endpoints of the link. In cases where you do not know the exact network topology, one possible approach is to install agents on all servers that hold critical workloads and for which you need to monitor your network performance.

The Cost of the Solution

The cost of the feature Performance Monitor in NPM is calculated on the basis of the combination of these two elements:

  • Monitored Subnet link. To obtain the costs for monitoring of a single subnet link for one month, you can see Ping Mesh.
  • Data volume.

For more details please visit the Microsoft's official page.

ExpressRoute Monitor

Using ExpressRoute Monitor it is possible to monitor the end-to-end connectivity and verify the performance between on-premises environment and Azure, in the presence of ExpressRoute connectivity with Azure Private peering and Microsoft peering connections. The key features of this solution are:

  • Auto-detection of the circuit ExpressRoute associated with your subscription Azure.
  • Detection of network topology.
  • Capacity planning and bandwidth usage analysis.
  • Monitoring and alerting both the primary and the secondary path of the circuit ExpressRoute.
  • Monitoring connectivity towards the Azure services such as Office 365, Dynamics 365 using ExpressRoute as connectivity.
  • Detection of possible deterioration of connectivity with the various virtual network.

Figure 2 – Topology view of a VM on Azure (left) connected to a VM on-prem (right), via ExpressRoute

Figure 3 - Trend on the use of the bandwidth and latency on the ExpressRoute circuit

Where to install the agents

In order to use ExpressRoute Monitor you need to install an Operations Management Suite agent on a system that resides on Azure virtual network and at least one agent on a machine attested on the subnet on-premises, connected via private peering of ExpressRoute.

The Cost of the Solution

The cost of ExpressRoute Monitor solution is calculated based on the volume of data generated during the monitoring operations. For more details please visit the specific section in the cost page of NPM .

Service Endpoint Monitor

Using this solution, you have the ability to monitor and test the reachability of your services and your applications, almost in real time, simulating user access. You also have the ability to detect network side performance problems and identify the problematic network segment.

Here are reported the main features of the solution:

  • It does the monitor end-to-end of the network connections to your applications. The monitor can be done by any endpoint "TCP-capable" (HTTP, HTTPS, TCP, and ICMP), as websites, SaaS applications, PaaS applications, and SQL databases.
  • It correlates application availability with network performance, to precisely locate the degradation point on the network, starting from the user's request until the application.
  • It tests applications reachability from different geographical location .
  • It determines the network latencies and lost packets to reach the applications.
  • It detects hot spots on the network that can cause performance problems.
  • It does the monitor of the availability of applications Office 365, through specific built-in test for Microsoft Office 365, Dynamics 365, Skype for Business and other Microsoft services.

Figure 4 - Creating of a Service Connectivity Monitor test

Figure 5 – Diagram showing the topology of the network, generated by different nodes, for a Service Endpoint

Where to install the agents

To use Service Endpoint Monitor you must install the Operations Management Suite agent on each node where you want to monitor network connectivity to a specific service endpoint.

The Cost of the Solution

The cost for using Service Endpoint Monitor is based on these two items:

  • Number of connections, where the connection is understood as reachability test of a single endpoint, from a single agent, for the entire month. In this regard you can see Connection Monitoring in the cost page.
  • Volume of data generated by the monitor. The cost is obtained from cost page of Log Analytics, in the section Data Ingestion.

Traffic Analytics

Traffic Analytics is a totally cloud-based solution, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (vNet) it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet. The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.
  • Analysis of the VPN gateway capabilities or other services, to detect problems caused by over-provisioning and underutilization.

Figure 6 – Traffic Analytics overview

Figure 7 - Map of Active Azure Regions on the subscription

DNS Analytics

DNS Analytics solution is able to collect, analyze and correlate logs of DNS and provides administrators the following features:

  • Identifies clients that try to resolve domains considered malevolent.
  • Finds records that belong to obsolete resources.
  • It highlights domain names frequently questioned.
  • View the load of requests received by the DNS server.
  • It does the monitor of dynamic DNS registrations failed.

Figure 8 – Overview of DNS Analytics solution

Where to install the agents

The solution requires the presence of the OMS agent or the Operations Manager agent installed on each DNS server to be monitored.

Conclusions

With increasing complexity of network architectures in hybrid environments, consequently increases the need to be able to use tools able to contemplate different network topologies. Azure provides several cloud based tools and integrated into the fabric, such as those described in this article, that allow you to fully and effectively monitor the networking of these environments. Remember to test and evaluate free Operations Management Suite (OMS) you can access this page and select the mode that is most appropriate for your needs.

Everything you need to know about new Azure Load Balancer

Microsoft recently announced the availability in Azure of Standard Load Balancer. They are load balancers Layer-4, for TCP and UDP protocols that, compared to Basic Load Balancer, introduce improvements and give you more granular control of certain features. This article describes the main features of the Standard Azure Load balancers, in order to have the necessary elements to choose the most suitable type of balancer for your needs.

Any scenario where you can use the SKU Basic of Azure Load balancers, can be satisfied using the Standard SKU, but the two types of load balancers have important differences in terms of scalability, functionality, guaranteed service levels and cost.

Scalability

The Standard Load balancers have higher scalability, compared to Basic Load Balancer, as regards the maximum number of instances (IP Configuration) that can be configured in the backend pool. The SKU Basic allows you to have up to 100 instances, while using the Standard SKU the maximum number of instances is equal to 1000.

Functionality

Backend pool

With regard to the Basic Load Balancer, in the backend pool, can reside exclusively:

  • Virtual machines that are located within an availability set.
  • A single standalone VM.
  • Virtual Machine Scale Set.

Figure 1 – Possible associations in the Basic Load Balancer backend pool

In Standard Load Balancer instead, it is allowed to enter into backend pool any virtual machine attested on a particular virtual network. The integration scope, in this case, is not in fact the availability set, as for the Basic load balancer , but it is the virtual network and all its associated concepts. A requirement to consider, in order to insert into the backend pool of Standard Load Balancer the virtual machines, is that these should not have associated public IP or must have Public IP with Standard SKU.

Figure 2 Standard Load Balancer backend pool association

Availability Zones

Standard Load Balancers provide integration scenarios with Availability Zones, in the regions that include this feature. For more details you can refer this specific Microsoft document, that shows the main concepts and implementation guide lines.

Ports High Availability

The load balancers with Standard SKU, of type "Internal", allow you to balance the TCP and UDP flows on all ports simultaneously. To do that, in the rule of load-balancing, there is the possibility to enable the "HA Ports" option:

Figure 3 - Configuring the load balancing rule with "HA Ports" option enabled

The balancing is done for flow, which is determined by the following elements: source IP address, source port, destination IP address, destination port, and protocol. This is particularly useful in scenarios where are used Network Virtual Appliances (NVAs) requiring scalability. This new feature improves the tasks that are required for NVAs implementations.

Figure 4 - Network architecture which provides the use of LB with "HA Ports" option enabled

Another possible use for this feature is when you need to balance a large number of ports.

For more details on the option "HA Ports" you can see the official documentation.

Diagnostics

Standard Load Balancer introduce the following features in terms of diagnostic capability:

  • Multi-dimensional metrics: You can retrieve various metrics that allow you to see, in real time, usage status of load balancer, internal and public. This information is particularly useful for troubleshooting.

Figure 5 – Load Balancer metrics from the Azure Portal

  • Resource Health: in Azure Monitor you have the opportunity to consult the health status of Standard Load Balancer (currently only available for Standard Load Balancer, type Public).

Figure 6 – Resource health of Load Balancer in Azure Monitor

You can also consult the history of the health state :

Figure 7 – Health history of Load Balancer

All details related to diagnostics, of the Standard Load Balancer, can be found in the official documentation.

Security

The Load Balancer with standard SKU are configured to be secure by default in fact, in order to operate, you must have a Network Security Group (NSG) where the traffic flow is explicitly allowed. As previously reported, the Load Balancer standards are fully integrated into the virtual network, which is characterized by the fact that it is private and therefore closed. The Standard Load Balancer and the public Standard IP are used to allow the access to the virtual network from outside and now by default you must configure a Network Security Group (closed by default) to allow the desired traffic. If there is no a NSG, on the subnet or on the NIC of the virtual machine, you will not be allowed the access by the network stream from the Standard Load Balancer.

The Basic Load Balancers by default are opened and the configuration of a Network Security Group is optional.

Outbound connections

The Load Balancer on Azure support both inbound and outbound connectivity scenarios. The Standard Load Balancer, compared to the Load Balancer Basic, behave differently with regard to outbound connections.

To map the internal and private IP address of the virtual network to the public IP address of the Load Balancer it uses the Source Network Address Translation technique (SNAT). The Load Balancer Standard introduce a new algorithm to have stronger SNAT policies, scalable and accurate, that allow you to have more flexibility and have new features.

Using the Standard Load Balancer you should consider the following aspects with regard to outbound scenarios:

  • Must be explicitly created to allow outgoing connectivity to virtual machines and are defined on the basis of incoming balancing rules.
  • Balancing rules define how occur the SNAT policies.
  • If there are multiple frontend, It uses all the frontend and for each of these multiply the preallocated SNAT ports available.
  • You have the option to choose and control whether a specific frontend you don't want to use for outbound connections.

Basic Load Balancers, in the presence of more public frontend IP, it is selected a single frontend to be used in outgoing flows. This selection can not be configured and occurs randomly.

To designate a specific IP address, you can follow the steps in this section of the Microsoft documentation.

Management operations

Standard Load balancers allow enabling management operations more quickly, much to bring the execution times of these operations under 30 seconds (against the 60-90 seconds to the Load Balancer with Basic SKU). Editing time for the backend pools are also dependent on the size of the same.

Other differences

At the moment, Public Standard Load Balancer cannot be configured with a public IPv6 address:

Figure 8 – Public IPv6 for Public Load Balancer

Service-Level Agreements (SLA)

An important aspect to consider, in choosing the most appropriate SKU for different architectures, is the level of service that you have to ensure (SLA). Using the Standard Load Balancer ensures that a Load Balancer Endpoint, that serve two or more instances of health virtual machines, will be available in time with an SLA of 99.99%.

The Load Balancer Basic does not guarantee this SLA.

For more details you can refer to the specific article SLA for Load Balancer.

 

Cost

As for Basic Load Balancer are not expected cost, for Standard Load Balancer there are usage charge provided on the basis of the following elements:

  • Number of load balancing rules configured.
  • Number of inbound and outbound data processed.

There are no specific costs for NAT rules.

In the Load Balancer cost page can be found the details.

 

Migration between SKUs

For Load Balancer is not expected to move from the Basic SKU to the Standard SKU and vice versa. But it is necessary to provide a side-by-side migration, taking into consideration the previously described functional differences.

Conclusions

The introduction of the Azure Standard Load Balancer allows you to have new features and provide greater scalability. These characteristics may help you avoid having to use, in specific scenarios, balancing solutions offered by third party vendors. Compared to traditional Load balancers (Basic SKU) change operating principles and have distinct characteristics in terms of costs and SLAS, this is good to consider in order to choose the most suitable type of Load Balancer, on the basis of the architecture that you must accomplish.

How to monitor network activities in Azure with Traffic Analytics

Worldwide cloud networks have substantial differences compared to those in the on-premises, but they are united by the need to be constantly monitored, managed and analyzed. All this is important for to know them better, in order to protect them and optimize them. Microsoft introduced in Azure the solution called Traffic Analytics, fully cloud-based, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. This article analyzes the characteristics of the solution and explains how you can turn it.

Operating principles of the solution

In Azure to allow or deny network communication to the resources connected with Azure Virtual Networks (vNet) it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet. The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis of NSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment.

Figure 1 – Data flow of Traffic Analytics

Solution functionality

Using Traffic Analytics you can do the following:

  • View network activities cross Azure subscriptions and identify hotspots.
  • Intercept potential network security threats, in order to take the right remedial actions. This is made possible thanks to the information provided by the solution: which ports are open, what applications attempt to access to Internet and which virtual machines connect to unauthorized networks.
  • Understand network flows between different Azure regions and Internet, in order to optimize their deployment for network performance and capacity.
  • Identify incorrect network configurations that lead to having incorrect communication attempts.

How to enable the solution

In order to analyze the network traffic you must have a Network Watcher in every region where there are the NSGs for which you intend to analyze traffic. The Network Watcher is a regional service, which makes it possible to monitor and diagnose the networking of Azure. Enabling Network Watcher can be made by Azure Portal, using Powershell or via REST API. By creating it from the portal it is not possible to determine the name of the Network Watcher and its Resource Group, but is assigned a default name in both entities.

Figure 2 – Enabling Network Watcher from the portal

Figure 3 – Enabling Network Watcher using PowerShell

As this is a preview service in order to use it you need to redo the registration of the network resource provider on the Azure subscription interested. You must also register the provider Azure Insights.

Figure 4 - Registration of the providers through PowerShell

In order to enable the collection of NSG Flow Logs you must have a storage account on which to store them. You must also have a workspace OMS Log Analytics on which Traffic Analytics will consolidate the aggregated and indexed data. The information present in Log Analytics will then be used to generate the analysis.

First configuration step of the NSG flow logs settings:

Figure 5 - Selection of the NSGs on which enable the collection of flow logs

Choice of storage account and workspace OMS Log Analytics for each NSGs:

Figure 6 – Enabling the collection of NSG flow logs and consolidation in OMS Log Analytics

The steps above must be repeated for each NSG for which you want to enable Traffic Analytics.

Figure 7 – List of NSGs with settings enabled

Within a few minutes from enabling, time necessary to obtain a quantity of sufficiently indicative aggregated data, its dashboard is populated with the information of Traffic Analytics.

Figure 8 – Traffic Analytics Dashboard

From the dashboard of Traffic Analytics information is readily available such as: hosts with a high level of communication, the most widely used application protocols, the communications that occur more frequently and the flows relating to network traffic in the cloud.

Selecting the section of interest is shown the query of Log Analytics that extrapolates the data:

Figure 9 - Sample query of Log Analytics showing the allowed malicious traffic

For a complete overview of the possible scenarios for using Traffic Analytics you can see this Microsoft's document.

Conclusions

Traffic Analytics is a new feature, currently in preview, introduced in Azure. It is an effective and easy-to-use tool that helps you keep track of the status of your network in Azure reporting very useful data, as who and where are connected, which ports are exposed to the internet, which network traffic is generated and more. This information is critical for detecting anomalies and make appropriate corrective actions. All operations that are difficult to achieve without this fully integrated tool in the platform.

OMS and System Center: What's New in November 2017

In November there have been several announcements from Microsoft concerning Operations Management Suite (OMS) and System Center. This article will summarize briefly with the necessary references to be able to conduct further studies.

Operations Management Suite (OMS)

Log Analytics

As already announced since 30 October 2017 Microsoft has launched the upgrade process of the OMS workspaces not yet updated manually. In this regard has been released this useful document that shows the differences between a legacy OMS workspace and a updated OMS workspace, with references for further details.

Solutions

Those that use circuit ExpressRoute will be glad to know that Microsoft announced the ability to monitor it through Network Performance Monitor (NPM). This is a feature currently in preview that allows you to monitor connectivity and performance between the on-premises environment and vNet in Azure in the presence of ExpressRoute circuit. For more details about the features announced you can consult theofficial article.

Figure 1 – Network map showing details of ExpressRoute connectivity

Agent

As usual it was released a new version of the OMS Agent for Linux systems that now takes place on a monthly basis. This release fixes bugs related diagnostics during agents onboarding. Are not being introduced new features. To obtain the updated version please visit the official GitHub page OMS Agent for Linux Patch v 1.4.2-124.

Protection and Disaster Recovery

Azure Backup always protected backups from on-premises world toward Azure using encryption that takes place using the passphrase defined during the configuration of the solution. To protect VMs in Azure the recommendation for greater security in the backup was to use VMs with disk-encrypted. Now Azure Backup uses Storage Service Encryption (SSE) to do the encryption of backups of virtual machines on Azure, allowing to obtain in an integrated manner in the solution a mechanism for the implementation of the backup security. This also will happen to existing backup automatically and through a background task.

Microsoft, in order to bring more clarity with regard to pricing and licensing of Azure Site Recovery, updated the FAQ which you can see in the official page of pricing of the solution.

System Center

As is already the case for the operating system and System Center Configuration Manager, the other System Center products, in particular, Operations Manager, Virtual Machine Manager, and Data Protection Manager will follow a release of updated versions every 6 months (semi-annual channel). The goal is to rapidly deliver new capabilities and to ensure a speedy integration with the cloud world, which is essential given the speed with which it evolves. In November was announced the System Center preview version 1711 which you can download at this link.

Figure 2 – Summary of what's new in System Center preview version 1711

To know the details of the new features in this release, please consult theofficial announcement.

System Center Configuration Manager

For System Center Configuration Manager current branch version 1706 was issued an important update rollup you should apply as it solves a lot of problems.

Released the version 1710 for the Current Branch (CB) of System Center Configuration Manager that introduces new features and major improvements in the product. Among the main innovations of this update definitely emerge the possibilities offered by the Co-management that expand the possibilities for device management using either System Center Configuration Manager and Microsoft Intune.

Figure 3 – Features and benefits of Co-management

For a complete list of new features introduced in this version of Configuration Manager, you can consult theofficial announcement.

Released the version 1711 for the Technical Preview branch of System Center Configuration Manager. The new features in this update are:

  • Improvements in the new Run Task Sequence step.
  • User interaction when installing applications in the System context even when running a task sequence.
  • New options, in the scenario of using Configuration Manager associated with Microsoft Intune, to manage compliance policy for devices Windows 10 related to Firewall, User Account Control, Windows Defender Antivirus, and OS build versioning.

I remind you that the releases in the Technical Preview Branch allows you to evaluate in preview new SCCM functionality and is recommended to apply these updates only in test environments.

Released an updated version of the Configuration Manager Client Messaging SDK.

System Center Operations Manager

Released the new wave of the SQL Server Management Packs (version 7.0.0.0):

The Management Packs for SQL Server 2017 can be used for the monitor of SQL Server 2017 and subsequent releases (version agnostic), this allows you to avoid having to manage different MPs for each version of SQL Server. The controls for versions of SQL Server earlier than 2014 are included in the generic MP "Microsoft System Center Management Pack for SQL Server".

System Center Service Manager

Microsoft has published a series of tips and best practices to be followed during Authoring Management Pack of System Center Service Manager (SCSM).

Please remember that in order to test and evaluate for free Operations Management Suite (OMS) you can access this page and select the mode that is most appropriate for your needs.