What are VRFs? (Virtual Routing & Forwarding)

This blog covers what VRFs are and how you would set them up in your network.

TRADITIONAL ROUTING & INTRO TO VRFs

Typically, your router will have a routing table compiling all the known networks with all the possible routes. This is a sole table for all interfaces and subnets. For an organsation that handles one evnironment this is perfectly fine but what if you were a service provider with multiple customers using your network for technologies such as MPLS? This is were VRFs come in.

A VRF is the layer 3 version of a VLAN found at layer 2. With VLANs, you split up your broadcast domains into separate layer 2 domains, assosiating interfaces with a specific VLAN for it take part on that subnet. VRFs work similarly to this. You create your VRFs like you would a VLAN, and then you associate your interfaces with a VRF. Like VLANs, these VRFs are segragated from one another and only see other interfaces that are part of the same VRF.

The router no longer has a sole routing table, there's one for each VRF. As you associate an interface with a VRF, it is taken out the main routing table and put in the VRF's routing table. The built in routing table of the router won't even see that the interface exists. This segmentation of the routing does allow for configurations you wouldn't typically see such as the ability to have duplicate IP addresses on other VRFs and it's perfectly fine. They are virtually separate so there's no conflicts.

VRF USE CASE

VRF is used with service providers running MPBGP in MPLS as it allows them to segement custmer traffic over a WAN environment. The lighter version, VRF-Lite has even more use as it doesn't require MPBGP so places like data centers or large networks can use VRF-Lite to segment traffic for DMZs, extranet and internal to group traffic into zones.

Below shows an example of an ISP with two cusotmers. There's two VRFs for each one, the customers can only see the links part of their VRF so the customers won't see one another but the ISP can still manage both.

HOW IS IT CONFIGURED? 

VRF is configured similar to VLANs where you create the VLAN, assosicate an interface with said VLAN. The image below shows a router with 2 interfaces being assosicated with different VRFs and the console showing the commands. (You can even use one physical interface for multiple VRFs by using subinterfaces then associating each one with a VRF)

At the bottom, you can see you can look at the IP routing table for a specific VRF as well as setup OSPF for a specific VRF.

Data Redunancy for Azure Storage

This blog covers the various options available for data redundancy in Azure.

AZURE DATA REDUNDANCY

Data in Azure is replicated 3 times in a single site at the lowest cost level, the options are:

• Locally-Redundant Storage (LRS)
• Zone-Redundant Storage (ZRS)
• Geo-Redundant Storage (GRS)
• Geo-Zone-Redundant Storage (GZRS)

LRS - LOCALLY-REDUNDANT STORAGE

LRS will replicate your data 3 times across a single datacenter in your primary region. This is the lowest cost option as it provides basic redundnacy, protecting against failign drives or server racks but if something affected the whole datacenter then all copies of the data are affected.

 

 

ZRS - ZONE REDUNDANT STORAGE

Zone Redundancy takes it a step further by replicating your data across 3 availabilty zones in your primary region. Each of these availability zones are separate physical buildings with their own power, cooling and networking.

This protects you by allowing data to be accessed if a datacenter goes down as you will have two others for accessing your data. ZRS supports read / write operations which happens synchronously to all copies when writing to a file. If one zone does go down then Azure will handle re-pointing DNS to keep the data accessible.

 

 

GRS - GEO-REDUNDANT STORAGE

When you create a storage account, you select its primary region. Azure Regions have pairs, your primary region will have a distant pair which can be used for redundancy.

GRS is LRS but over two regions. In your primary region, your data is copied 3 times within a single physical site. The sam data is then copied to the paired region where it is copied 3 times again in a single physical site.

 

 

GZRS - GEO-ZONE-REDUNDANT STORAGE

This takes the ZRS concepts but adds a second LRS backup in the paired region. It behaves like ZRS coping the data over 3 availability zones in your primary region but then uses LRS in your paired region to have 3 copies of your data within a single physical site in the secondary region.

 

Wireless Topologies Explained (BSS, ESS and SSIDs)

This covers wireless topologies, going over BSS, ESS and SSIDs

CONNETING TO A WIRELESS NETWORK

When you connect to a wireless network, you typically connect to an available SSID then away you go. Once connected you can freely move around a building, moving from one access point to another access point all while still connected to the same SSID.

To manage the connected clients, wireless networks use BSS, ESS and SSIDs to enable mobility.

BASIC SERVICE SET (BSS) 

Thinking about SSIDs, you see it as one overall network for a whole building/campus where you are connected to just that wireless network. That WLAN is made up of access points all broadcasting the SSID for clients. As people connect to the SSID, they also connect to the access point within range.

Each access point has its own local wireless network which covers the broadcast radius of the access point's radios. This local WLAN of the access point is a BSS. For a WLAN, it isn't just the SSID of the whole building/campus but it is also multiple BSS networks that make up the foundations of the network.

Each BSS has an ID that the WLAN uses to track which AP a client is connected to and to ensure each BSS can be uniquely identified. If you go into CMD or PowerShell in Windows, you can use the command 'netsh wlan show interfaces' to see what the BSSID is of the BSS you are connected to. Below is an example.

EXTENDED SERVICE SET (ESS)

Extended Service Sets are basically what we typically call SSIDs. An ESS is a collection of BSSs that are broadcasting the same SSIDs to allow clients to roam between the APs. Below is an example of multiple BSS networks making up a larger WLAN to form an ESS.

SERVICE SET ID (SSID)

SSIDs are friendly names for WLAN networks. BSS networks have a BSSID which is the MAC of the broadcasting AP but SSIDs make things easier. For an ESS, there is no ESSID but the SSID giving it a friendly name removes the need for an ESSID. SSIDs are used for both BSS and ESS as it's easy to have the consistancy and avoids having to use the BSSID.

Automating Autopilot Deployments via Dynamic Device Groups

This covers automating the process of assigning Autopilot deployment profiles, apps and policies to Intune devices.

SETTING UP YOUR ENDPOINT GROUPS

When importing devices into Endpoint Manager, you need to place the device in a group within Azure AD for it to pick up an Autopilot deployment profile then pick up any apps and policies you targeted towards that group after enrollment. 

If it's one or two devices, it's not much work importing the devices then manually adding them to the group but it isn't going to be fun adding 50+ devices to a group. Here's were dynamic device groups come in handy. You can build dynamic groups based on the Group Tag field of Autopilot Devices. 

When generating the hardware ID of a device, you can set the Group Tag at the same time. You can use this tag to automate which group it joins in Azure AD once you've imported them. The rule below is used to match devices with specific Group Tags. The property is "devicePhysicalIds" with the value being "[OrderID]:TAG" replacing TAG with your group tag.

In my example I have used "Marketing" as my Group Tag. This particular group may be for Marketing devices that gets Marketing specific policies and apps. I could have a second dynamic device group for a different department that has different software and policy requirements, using a different Group Tag for them.

This can simplify the build process of devices to just, gather the hardware IDs whilst setting a Group Tag at the same time, importing your CSV file and then going through the OOBE once they have all been imported and have an Autopilot deployment profile assigned.

ASSIGNING A GROUP TAG WHEN GATHERING THE HARDWARE ID

The PowerShell cmdlet to generate the hardware ID has a parameter of -GroupTag followed by a value for your Group Tag such as "Marketing". If you're doing multiple then also use the -Append parameter to append each individual device to the next row of the CSV.

Adding Additional Local Administrators on Azure AD Joined Devices for Endpoint/Intune

 This covers how to define additional users as local admin on Azure AD joined devices.

CREATING AN AZURE AD GROUP FOR YOUR ADMIN USERS

Within Azure Active Directory, you need to create a group that will be used to define which users should be added to the local administrators groups for AzureAD joined devices, important if your environment is built upon Intune/Endpoint Manager.

The group needs to have the 'Azure AD roles can be assigned to the group' set as YES. This is so AzureAD can assign the local device administrator role to the users in that group.

SETTING THE GROUP AS LOCAL ADMINISTRATORS ON AZUREAD DEVICES

Within the Azure Portal under Devices, select the 'Device Settings' section then at the bottom is 'Additional local administrators on all Azure AD joined devices' where you define additional local administrators.

The link should open the screen shown below. You can use the 'Add Assignment' to add your AzureAD group to be used as local administrators on all Azure AD joined devices.

Once you have set your group with the assignment, you should be able to log into an Azure AD joined device and automatically be added as a local administrator.

Understanding OSPF LSA Types

This covers the different LSA types in OSPF and how they behave in OSPF AS.

PURPOSE OF LINK-STATE ADVERTISEMENTS (LSAs) IN OSPF

OSPF's LSDB is built using LSAs advertised by routers within the OSPF AS. These LSAs are complied in the LSDB with a LSID to identify them. The OSPF SPF algorithm uses these LSAs to calculate paths to destinations. There are different LSAs for different aspects of OSPF from internal area information to inter area (IA) routes shared by ABRs between areas to external routes through ASBRs running redistribution.

LSA TYPE 1 - ROUTER LSA

Type 1 LSAs are generated by a router and will contain information on all its connected links which are OSPF enabled. This information consists of:

• For non-DR elected interfaces, lists the router's interface subnet number/mask and interface OSPF cost.
• For interfaces with an elected DR, it lists the IP address of the DR with a notation that the interfaces connects to a transit network.

Every router in an area will create a single an Type 1 LSA for themselves and flood it through the same area it is in. ABRs on the other hand create multiple Type 1 LSAs, an LSA for each area they are in and flood it to the the areas the LSAs describe. As the ABR as one RID, that will be the same on each LSA.

The LSID for Type 1 LSAs is the RID of the advertising router and are listed as "O" in the routing table.

LSA TYPE 2 - NETWORK LSA

Type 2 LSAs are used on Multiaccess (MA) networks where there are multiple adjacencies over a shared broadcast domain. Once the DR has been elected, it will then create Type 2 LSAs for the subnet. OSPF cannot represent multiple routers on a single subnet using a link connection to all four routers. OSPF defines a Type 2 network LSA as a transit network. 

Each router's Type 1 LSA will describe a connection to this transit network which is then molded into a Type 2 LSA by the DR and uses it's interface IP as the LSID to show it is a Type 2 LSA. This is flooded within the local area as Type 1 LSAs are.

These are listed as "O" routes in the routing table.

LSA TYPE 3 - SUMMARY LSA

ABRs don't simply forward all Type 1 and 2 LSAs to other areas, that wpuld increase the complexity of the SPF algorithm as well as take up more memory. Instead, the ABR will summaries the subnets of an area and forward that out to simply say subnet XYZ exists in Area 2. 

These LSAs aren't detailed like Type 1 and 2 LSAs. The ABR will use the subnet's address as the LSID and include its own RID so others know which ABR advertised the route. Although it is called a Summary LSA, it doesn't summaries the subnets but the term simply means it isn't as detailed.

These are listed as "OIA" routes in the routing table.

LSA TYPE 4 - SUMMARY ASBR LSA

These are only created when an ABR recieves a Type 5 LSA from an ASBR. The LSA will bascially list the RID of a ASBR and the cost to get to it from said ABR. This is flooded out to all connected areas. The LSID used for these LSAs is the ASBR's RID.

The importance of these is when there are multiple possible paths to subnets external to the OSPF AS to act as tie breakers for routing for Type 2 External Routes.

LSA TYPE 5 - EXTERNAL LSA

Routes from an external AS are flooded through the OSPF AS through the ASBR. These LSAs are flooded to all none stubby areas, stubby areas will have to use default routes as they don't allow Type 5 LSAs in the area. The ASBR will generate a Type 5 LSA for each subnet including the following information.

• LSID which is the subnet IP address
• Mask which is the subnet mask
• Advertising Router which is the RID of the ASBR
• Metric which is set by the ASBR
• External Metric Type which can either be Type 1 or Type 2

There are two metric types used, External Type 1 or External Type 2. These are displayed in the routing table as either "E1" or "E2". 

• External Type 2 routes will just use the metric set by the ASBR, if there is multiple paths then having the same metric means it will then use the Type 4 LSA to calcualte which has the better cost. This is basically the cost of the ABR to the ASBR added to the existing metric.
• External Type 1 routes will use the metric set by the ASBR but then add on the internal costs. 

LSA TYPE 6 - MULTICAST LSA

These are used when routing using multicast through the MODPF routing protocol and this LSA isn't supported on Cisco products.

LSA TYPE 7 - EXTERNAL LSA

This is basically the same as a Type 5 LSA. As Type 5 LSAs cannot enter stubby area, the Type 7 LSA was developed to get round this if an ASBR is found within a stuby area. The Type 7 LSA is flooded within the stubby area but as it reaches the ABR, it is then converted to a Type 5 LSA and flooded through the normal areas.

The External Route types here are the same but in the routing table will use "N1" or "N2" rather than the "E1" and "E2" that Type 5 LSAs use.

LSA TYPE 8 - EXTERNAL ATTRIBUTES LSA FOR BGP

This LSA is for use with the Border Gateway Protocol (BGP) 

Setting Up Autopilot in Endpoint Manager

This guide covers creating Autopilot deployment profiles, Azure AD groups and importing Windows devices into Endpoint Manager for Autopilot configuration.

HOW AUTOPILOT WORKS

Autopilot will automate the process of enrolling a device into Endpoint Manager, deploying any security policies, installing your desired apps and setting up the device configuration, all within the intial setup period. User log in with their Azure AD credentials to access their enterprise data and resources.

Autopilot uses deployment profiles, these let you detail how the device is enroll whether it's self-deploying (Enrolls without needing a user to log in) or user driven (User logs in before it enrolls). 

These deployment profiles need to be linked to the devices you want it to apply to, this is where the Azure AD group comes into play. Once you have imported your Windows devices, you will need to add them to the group that is associated with your deployment profile. When you boot up the device, it will realise it is has an Autopilot profile assigned and then begins to follow that during the OOBE.

CREATING A GROUP FOR YOUR DEVICES

In Azure AD, create a security group which will be used by Endpoint Manager for your deployment profile. Later on when we import the device, we can add it to the Azure AD group.

This group can be used for targeting your configuration policies, app deployments, conditional access, etc.

CREATING AN AUTOPILOT DEPLOYMENT PROFILE

Under the Windows enrollment section, there is an option named 'Deployment Profiles' where you can create your profile. Simply create a new profile and follow through the wizard. 

You will get the option of User Driven or Self-Deploying.

• User Driven - The device is associated with a user, during the OOBE the user needs to log in with their Azure AD credentials. Once they log in, it will enroll into Endpoint and apply the security configurations, install the user's applications and setup it up ready for them to use.
• Self-Deploying - The device will enroll into Endpoint but won't require a user to log in. It will then display the Windows log in screen and during the first log in it will apply the security and device configuration.

I use the self-deploying profile in production but it's a matter of what better fits your enviornment. 

Follow through the rest of the setup, selecting your desired options, setting the default language and device name. Device name can use the value %SERIAL% to use the serial in the name or %RAND:4% for random numbers with the number representing how many random numbers (4 in this case)

Finally under the 'Included' groups, select your Azure AD group created for your devices.

IMPORTING YOUR WINDOWS DEVICE INTO ENDPOINT MANAGER

You can automate this by having your vendor provide you with the Hardware IDs of your new laptops which you can import into Endpoint so they can be unbox on delivery and will go striaght into the Autopilot process and enroll.

In this example, I will show you how to manually get the Hardware IDs and import the device into Intune.

You need to boot up the laptop and open Command Prompt. If you are in the OOBE then press Shift+F10 to open it up. Once open, enter 'PowerShell' to start PowerShell. Enter the command below.

New-Item -Type Directory -Path "C:\HWID"

Set-Location -Path "C:\HWID"

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

Install-Script -Name Get-WindowsAutoPilotInfo

Get-WindowsAutoPilotInfo -OutputFile AutoPilotHWID.csv

This will generate a CSV in the C:\HWID directory. Run the command 'explorer.exe' to open Windows Explorer and copy this CSV to a pendrive. Back in Endpoint under 'Windows Enrollment > Autopilot > Devices' you want to select the 'Import' option then upload your CSV. 

Once it has imported, you will need to add it to your Azure AD group. Under the Autopilot Devices menu, your device will get an Assigned status under the 'Profile Status' column which means the Autopilot Deployment Profile has successfully been assigned to that device.

Now you just need to reboot the device, go back into the OOBE and it should start the Autopilot process.