Tag: Networking

Azure Virtual WAN (Hub-Spoke v2.0)

Over the past few years I have been promoting customers to adopt the Microsoft/Azure’s Hub-Spoke (Hub and Spoke) network topology and its architecture. Not too long ago (Ignite 2019), Azure has made some significant improvements with their architecture and best practices by introducing “Virtual WAN“. I like to call this new service and evaluation as the new Hub-Spoke architecture version 2.0.

What is Azure Virtual WAN?

Azure Virtual WAN, or vWAN is a networking solution/service that allows you to integrate key functionalities such as networking, routing and security within a single pane. Azure vWAN is really a software-defined (SD) solution of WAN based technologies, and similar to service endpoints, and private links, Azure vWAN leverages the Microsoft network backbone to build a highly-available and high-speed global transit network. These functionalities include branch connectivity such as Site to Site VPNs, Point to Site VPN, ExpressRoute and intra-cloud/transitive networks, Azure Firewall and encrypted private connectivity.

Azure vWAN SKU Type

Microsoft has made it simple with the options you get with Azure vWAN, either basic or standard. Once you deploy Azure vWAN, you can get started with one of the use cases (as mentioned above) and add functionalities as your network evolves.

With Basic, you can only leverage vWAN for a Site to Site VPN connection. However once you go to the Standard SKU, you can now leverage all of the functionalities mentioned above, ie. Site to Site, Point to Site, ExpressRoute and Inter-Hub and VNet to VNet transiting via the vHUB.

Architecture (simplified) Overview

The image below depicts a high level but comprehensive with its capabilities on how Azure Virtual WAN can be integrated for various scenarios. With the “Any to Any” connectivity model, the Global transit network enables to connect your branch offices, remote users, datacenters, Azure VNets to one another. The image and model below, a spoke can be your Azure VNet, or a branch office, or a remote user, or perhaps the Internet. This architecture enables logical one-hop transit connectivity between the networking endpoints.

Source: https://docs.microsoft.com/en-us/azure/virtual-wan/media/virtual-wan-global-transit-network-architecture/figure1.png

Conclusion

The Azure vWAN architecture is a hub and spoke architecture that incorporates scalability, resilience and performance built in for branches (VPN/SD-WAN devices), users (Azure VPN/OpenVPN/IKEv2), ExpressRoute circuits, and Azure virtual networks (VNets). There are some excellent benefits of using Azure Virtual WAN within your architecture as it simplifies the overall network topology and provides a handful of opportunities to integrate your on-premises datacenters, branch offices, remote users into a global transit network architecture. There are some limitations I can already see today, and that being not being able to leverage 3rd party network virtual appliances (NVA) such as Palo Alto, Checkpoint, etc., however I am sure that is already within the roadmap.

(more…)

Azure Service Endpoints versus Azure Private Links

Recently a lot of folks have been asking about Azure Service Endpoints and Azure Private Links — what’s the difference? when to use which? and why?

For starters, let’s review what is a Service Endpoint, and what is a Private Link? Followed by which solution is better to use, and why….

Azure Service Endpoints

With any Azure Virtual Network (VNet) you can leverage a ‘service endpoint’ that provides a secure connection and a direct connection to Microsoft Azure’s service over Microsoft’s backbone network infrastructure. The service endpoints allow you to run services/resources over the VNet and enables private IP Address within the VNet to communicate with the Azure service without the requirement of having a public IP on the VNet. Service Endpoints work by enabling your VNet or subnet(s) to support the Service Endpoint, and once enabled, you can configure which PaaS resource(s) can accept traffic from those subnet(s)/VNets. There is no requirement to do any IP filtering and/or NAT translation, all you need to tell is the PaaS resource(s) which VNet/Subnet to allow traffic from. When Service Endpoints are enabled, the PaaS resource sees traffic coming from your VNet private IP, not the public IP.

Azure Private Link

Azure Private Link allows you to access Azure (PaaS) services, like Key Vault, Storage, Log Analytics, etc., over a private endpoint within your Azure VNet. The communication between the Private Link (endpoint) and your VNet continue to travel over the Microsoft’s backbone network, however your service is no longer exposed over the Internet. One drawback with Private Link is that to support resolution of the PaaS resources using the same name, you do need to implement DNS to resolve the private link zone for that resource. There is integration with Azure Private DNS to set this up for you, but this can be problematic if you have your DNS service already running, or do not want to use Azure Private DNS with your VNet. Once enabled, you have now granted access to a specific PaaS resource within your VNet. Meaning, you can control the egress to the PaaS resource. Unlike Service Endpoints, Private Link allows access from your on-premises infrastructure to Azure resources over an ExpressRoute circuit, or Site to Site VPN tunnel, or via its peered VNets.

What’s the difference, and when to use?
  • The biggest difference between Private Links and Service Endpoints, is Public IPs. With Private Link, there is never any Public IP created and traffic can never go through the Internet, whereas with Service Endpoints, you have the option to limit access.
  • Second key difference with Private Link is, once enabled, you have now granted access to a specific PaaS resource within your VNet. Meaning, you can control the egress to the PaaS resource.
  • Service Endpoints are much simpler to implement and significantly reduce the complexity of your VNet/Architecture design.
  • Private Link will always ensure traffic stays within your VNet.
  • Another key difference between Private Links and Service Endpoints, is cost. There is a $0 cost to implement Service Endpoints, as the cost is already integrated within the VNet cost itself. Whereas Private Links costs can quickly grow depending on the total ingress and egress traffic and the runtime of the link. For example, within Azure Canada Central, to have a Private Link that is available for 730 hours in a given month, and that allows 100TB of ingress and egress (for both) can run over $2,000 monthly.
    • This is something to factor when designing or implementing either solution, as Private Links will quickly add to your monthly spend.
  • Another consideration is, availability, meaning Service Endpoints and Private Links are not generally available for all services, for example. There is no Service Endpoint as of writing this post, for Azure Log Analytics. However, there is a solution for Private Links for Log Analytics. Both services are available but not for all resources/services. For the complete list you can visit the links below, Service Endpoints: HERE ; Private Link: HERE.

Ultimately, if you are considering either solution, Private Link versus Service Endpoint, then you are probably concerned with security and with that said, Private Link is superior to Service Endpoints. The services available to Private Link will continue to grow like Service Endpoints, but based on my observation, it appears Private Link has a much deeper portfolio with Azure services integration.

Step-by-Step – SCOM 2012 R2 Update Rollup 11 (UR11) Install Procedure

My personal notes,  SCOM 2012 R2 Update Rollup 11 (UR11) has a lot of networking monitoring fixes, Linux/UNIX support and security fixes, along with more OMS integration. What is OMS, please go HERE. It is highly recommended to upgrade your lab/Dev environments first before upgrading your Production environment(s). The step by step procedures below are the steps I took and in no way shape or form do I accept responsibility for any data loss, and/or issues within your environment. It is advised to always take a backup of your SQL databases and/or snapshots of your SCOM environment(s). Please take these notes as suggestions. Always refer to Microsoft’s KB (posted above) for full documentation steps.

Here are the key updates for UR11 (source Microsoft):

Issues that are fixed in this update rollup can be found here, https://support.microsoft.com/en-us/kb/3183990

Once you are ready to begin your upgrade, it is recommend you do the following server/roles in the order below:

  1. Install the update rollup package on the following server infrastructure:
  • Management server or servers
  • Audit Collection Services
  • Gateway servers
  • Web console server role computers
  • Operations console role computers
  1. Apply SQL scripts.
  2. Manually import the management packs.
  3. Apply the agent update to manually installed agents, or push the installation from the Pending view in the Operations console.

Once you have downloaded the rollup files, I like to extract and only keep the language I need, in this case, ENU (English). You will need to install these with Administrative rights, I like to use PowerShell as Local Administrator. It really does frustrate me, as there is no indication that the rollup installed correctly, (other than looking at the file version number change via File Explorer).

1

2

3

Personally, I prefer to execute the MSP files via PowerShell (RunAs Administrator) console.

Again, the order needs to be:

  1. Management Servers
  2. Audit Collection Services
  3. Gateway Servers
  4. Web Console Role Servers
  5. Operations Console Role Servers

Once the rollups are installed, you will now need to apply the SQL scripts. First update the Data Warehouse, then followed by the OpsMgr DB.

The scripts can be found here, “%SystemDrive%\Program Files\System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups

Please note, the user executing these scripts needs to have read and write permissions to the database(s).

4

5

6

Once you have successfully executed the SQL scripts, you will now need to import the updated Management Packs (MP). These MPs can be found here, “%SystemDrive%\Program Files\System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups“.

You will need to import the following MPs, please see below:

7

Once the MPs have been imported, you should now go back to your Pending Management view, under the Administrations pane, and update all servers.

8

And that is that! You are now on the latest and greatest System Center release for SCOM 2012 R2.

(more…)

Hyper-V Network Virtual Switches

So you’ve spun up a Windows 2012R2 machine with Hyper-V installed and ready to go. However, now you’re stuck and not sure which type of  Network Virtual Switch (vSwitch) applies to your environment(s)…

In Windows 2012R2, Hyper-V’s network virtual switch runs at Layer 2 (Data Link layer). If you are unfamiliar with this, or either terms, I suggest good old Wikipedia. 🙂 Layer 2 maintains a MAC address table contains the MAC addresses of all the virtual machines (VMs) connected to it. The switch determines where to direct/redirect the packets to based on MAC addresses. It should be noted, in Hyper-V, you can have an unlimited amount of VMs connected to this vSwitch.

In Hyper-V you have three types of Network Virtual Switches: External, Internal and Private. All have similar functions but are disgustingly different.

  1. External vSwitch allows communication between the VMs running within the Hyper-V hosts, the Hyper-V parent partition, and between all VMs on the remote host server. The External vSwitch does require a network adapter on the host (that is not mapped to any other Hyper-V External vSwitch). You can also tag to a VLAN ID.
  2. Internal vSwitch allows communication between all VMs that are connected to the vSwitch and also allows communication between the Hyper-V parent partition. You can also tag to a VLAN ID.
  3. Private vSwitch allows communication between all VMs that are connected to the vSwitch, and that is it. (Note, no communication between the VMs and its Hyper-V parent partition. Also no VLAN ID tagging can occur on the vSwitch)

Without the use of SCVMM (System Center Virtual Machine Manager), I have found there are two ways to go about creating a vSwitch, one via Hyper-V GUI and second via PowerShell.

Let’s start with the GUI:

Launch the Hyper-V console, and right-click on the Hypervisor’s Virtual Switch Manager. Now selecting New virtual network switch, you can specify your properties here. Name your vSwitch, associate to the correct vNIC, tag to the appropriate VLAN ID, etc.

1 vSwitch HyperV Host

You can now specify which vSwitch for your guest VM to use. Within the VMs properties, you will have the option to chose within the Virtual Switch (you will need to create a Network Adapter if not already done). Once selected you can specify your VLAN ID here. (I am finding you cannot specify the VLAN within the Management vSwitch, but it must be done on the client VM’s end) *Again, this is without the use of SCVMM..yet*

2 vSwitch client OS

 

The same process above can be automated via PowerShell. If you’re like me and need to provision a few dozen Hyper-V hosts, creating vSwitches via the GUI is rather tedious. This can be automated with PowerShell (and SCVMM). Please see the code below:

First you will need to get a list of all the Network Adapters your Hyper-V host has to offer. Hopefully you have named them, if you have not, I highly suggest doing this, and considering this best practice and keeping your sanity.

3 Get Adapter names via PS

Once you have the list of vNICs and their names, you can go ahead and start creating vSwitches.

4 Create vSwitch via PS Code 5 Output Create vSwitch via PS

If the code below worked (note only Line 6 is needed to create the External vSwitch) your Hyper-V host should have the vSwitch, or something similar:

1 vSwitch HyperV Host

 

(more…)