WVD Implementation step by step guides in Non ARM(WVD 1.0) and ARM Model (WVD 2.0)
WVD Implementation step by step guides in Non ARM(WVD 1.0) and ARM Model (WVD 2.0)
|Azure NetApp files||Azure Files/ Premium Files|
|Fully managed, Highly performing enterprise class File Storage Service and easy to integrate with Modern applications like analytics,HPC,AI/ML, VDI and mission critical application workloads||Fully managed File shares Only|
|Provides both NFS and SMB . NFS versions supportedNFs3,NFSv4, NFSv4.1. SMB versions supported v2.1, v3.0 and v3.1.1.||Primarily SMB, supports SMB 3.0 and above. Supports 2.1 but with lot of restrictions in terms of mounting and encryption of data.|
|Can be natively mounted to Linux machines||Linux distributions need to have SMB kernel client|
|SLA based tiering in terms of performance – Tiers are Standard, Premium and extreme||Tiering is storage media based with tier of Premium and standard.|
|Movement across ANF tiers can be done using Cloudsync. On the fly data in place tier changing in the Roadmap||Changing of tiers requires data to be migrated to the new tier using Data migration tools|
|Minimum deployment is 4TB and max is 100TB max ANF capacity is limited by Storage Account limitation of 500TB.||Minimum deployment min 100GB and maximum 100TB. For Standard files max is 5TB only|
|Max file size is 16TB||Max File Size is 1TB only|
|Performance depends on the selected SLA tier.||Max iops per share is 100K only.|
|Sub-quotas can be set.||No quota management, basically works and provisioned capacity level|
|Snapshots are highly space efficient , included in the price of ANF. Upto 256 snapshots per volume(Snap.0 to snap.255)||Snapshots are charged separately and are not space efficient. Snapshot charges $0.22 and $.0075 per used GB/month for Premium and Standard respectively|
|Data can be replicated using cross region replication ( azure marketing name for Snapmirror replication)||No Data replication options|
|CloudSync can be used in case of NAS or File server as the Source. Very fast and very cost effective and schedule based or one time run options available. CloudSync is free of Cost with ANF||Data Migration to Azure premium Files/files require a combination of Migration tools Filesync+AzureDatabox+Robocopy for Windows file server source and Robocopy only for NAS source. Robocopy inherently slow and manual monitoring is required.|
|Consistent sub milli sec latency||No latency consistency|
|Restoration can be easily done through snapshots. NetApp is a pioneer with snapshot technology and proven industry acceptance for more than 25 years.||No protection against accidental deletion ( Soft delete is in Preview as we speak and is not a mature technology in Azure)|
|Instant R/w Cloning with zero space occupancy until a unique write is made. Extremely useful in a devops and test dev environments.||No Cloning Capability.Snapshots are the only option available, however they are read only|
|Compliance and reporting included with ANF. Automated data privacy controls for GDPR, CCPA and many more. Free for ANF||Very good compliance template available. However reporting is not robust.|
|Firewall & ACLs||Security Groups|
AWS Network ACLs
|Network Security Groups|
|VCN Security Lists||Cloud Security Groups||NAT Gateway|
|IPS/IDS||3rd Party Only||Azure Firewall||3rd Party Only||3rd Party Only||3rd Party Only||Anti-Bot Service|
Website Threat Inspector
|Web Application Firewall|
AWS Firewall Manager
|Application Gateway||Cloud Armor||Oracle Dyn WAF||Cloud Internet Services||Web Application Firewall|
|AWS Security Hub|
Event Threat Detection
|Oracle Security Monitoring and Analytics||IBM Log Analysis|
Cloud Activity Tracker
|Antimalware||3rd Party Only||Microsoft Antimalware|
Azure Security Center
|3rd Party Only||3rd Party Only||3rd Party Only||Server Guard|
|Data Loss Prevention|
|Amazon Macie||Information Protection|
|Cloud Data Loss Prevention API||3rd Party Only||3rd Party Only||Web Application Firewall|
|File Integrity Monitoring|
|3rd Party Only||Azure Security Center||3rd Party Only||3rd Party Only||3rd Party Only||3rd Party Only|
|Key Management||Key Management Service KMS)||Key Vault||Cloud Key Management Service||Cloud Infrastructure Key Management||Key Protect|
|Key Management Service|
|Encryption At Rest||EBS/EFS Volume Encryption|
|Storage Encryption for Data at Rest||Part of Google Cloud Platform||Cloud Infrastructure Block Volume||Hyper Protect Crypto Services||Object Storage Service|
|DDoS Protection||AWS Shield||Built-in DDoS defense||Cloud Armor||Built-in DDoS defense||Cloud Internet Services||Anti-DDoS|
|Email Protection||3rd Party Only||Office Advanced Threat Protection||Various controls embeded in G-Suite||3rd Party Only||3rd Party Only||3rd Party Only|
|Application Load Balancer||Application Gateway||HTTPS Load Balancing||3rd Party Only||Cloud Load Balancer||Server Load Balancer (SLB)|
|Endpoint Protection||3rd Party Only||Microsoft Defender ATP||3rd Party Only||3rd Party Only||3rd Party Only||Server Guard|
|Certificate Management||AWS Certificate Manager||Key Vault||3rd Party Only||3rd Party Only||Certificate Manager||Cloud SSL Certificates Service|
|Container Security||Amazon EC2 Container Service (ECS)||Azure Container Service (ACS)||Kubernetes Engine||Oracle Container Services||Containers – Trusted Compute||Container Registry|
|Identity and Access Management||Identity and Access Management (IAM)||Azure Active Directory||Cloud Identity|
|Oracle Cloud Infrastructure IAM||Cloud IAM|
|Resource Access Management|
|Privileged Access Management (PAM)||3rd Party Only||Azure AD Privileged Identity Management||3rd Party Only||3rd Party Only||3rd Party Only||3rd Party Only|
|Multi-Factor Authentication||AWS MFA (part of AWS IAM)||Azure Active Directory||Security Key Enforcement||Oracle Cloud Infrastructure IAM||App ID||Resource Access Management|
S3 Bucket Logging
|Azure Audit Logs||Stackdriver Logging|
|Oracle Cloud Infrastructure Audit||Log Analysis with LogDNA||Log Service|
|Load Balancer||Application Load Balancer|
Classic Load Balancer
|Azure Load Balancer||Cloud Load Balancing|
HTTPS Load Balancing
|Cloud Infrastructure Load Balancing||Cloud Load Balancer||Server Load Balancer|
|LAN||Virtual Private Cloud (VPC)||Virtual Network||Virtual Private Cloud Network||Virtual Cloud Network (VCN)||VLANs||Virtual Private Cloud (VPC)|
|WAN||Direct Connect||ExpressRoute||Dedicated Interconnect||FastConnect||Direct Link||VPN Gateway|
|VPN||VPC Customer Gateway|
AWS Transit Gateway
|Google VPN||Dynamic Routing|
|Governance Risk and Compliance Monitoring||AWS Security Hub|
AWS Compliance Center
|Azure Security Center|
|Cloud Security Command Center||3rd Party Only||3rd Party Only||ActionTrail|
|Backup and Recovery||AWS Backup|
Amazon S3 Glacier
Azure Site Recovery
Cloud Storage Nearline
|Archive Storage||IBM Cloud Backup||Hybrid Backup Recovery|
|Vulnerability Assessment||Amazon Inspector|
AWS Trusted Advisor
|Azure Security Center||Cloud Security Scanner||Security Vulnerability Assessment Service||Cloud Security Advisor|
Website Threat Inspector
|Patch Management||AWS Systems Manager||Azure Security Center|
|3rd Party Only||IBM Cloud Orchestrator||3rd Party Only||3rd Party Only|
|Change Management||AWS Config||Azure Automation (Change Tracking)||3rd Party Only||3rd Party Only||3rd Party Only||Application Configuration Management (ACM)|
What is RBAC?
When it comes to identity and access, most organizations that are considering using the public cloud are concerned about two things:
Azure Active Directory (Azure AD) and Role-Based Access Control (RBAC) work together to make it simple to carry out these goals.
First, remember that each Azure subscription is associated with a single Azure AD directory. Users, groups, and applications in that directory can manage resources in the Azure subscription. The subscriptions use Azure AD for single sign-on (SSO) and access management. You can extend your on-premises Active Directory to the cloud by using Azure AD Connect. This feature allows your employees to manage their Azure subscriptions by using their existing work identities. When you disable an on-premises Active Directory account, it automatically loses access to all Azure subscriptions connected with Azure AD.
What is RBAC?
Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of resources in Azure. With RBAC, you can grant the exact access that users need to do their jobs. For example, you can use RBAC to let one employee manage virtual machines in a subscription while another manages SQL databases within the same subscription.
What is role-based access control?
You grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent scope also grants access to the child scopes contained within it. For example, a user with access to a resource group can manage all the resources it contains, like websites, virtual machines, and subnets. The RBAC role that you assign dictates what resources the user, group, or application can manage within that scope.
The following diagram depicts how the classic subscription administrator roles, RBAC roles, and Azure AD administrator roles are related at a high level. Roles assigned at a higher scope, like an entire subscription, are inherited by child scopes, like service instances.
In the preceding diagram, a subscription is associated with only one Azure AD tenant. Also note that a resource group can have multiple resources but is associated with only one subscription. Although it’s not obvious from the diagram, a resource can be bound to only one resource group.
What can I do with RBAC?
RBAC allows you to grant access to Azure resources that you control. Suppose you need to manage access to resources in Azure for the development, engineering, and marketing teams. You’ve started to receive access requests, and you need to quickly learn how access management works for Azure resources.
Here are some scenarios you can implement with RBAC.
RBAC in the Azure portal
In several areas in the Azure portal, you’ll see a pane named Access control (IAM), also known as identity and access management. On this pane, you can see who has access to that area and their role. Using this same pane, you can grant or remove access.
The following shows an example of the Access control (IAM) pane for a resource group. In this example, ramtest has been assigned the Backup Operator role for this resource group.
How does RBAC work?
You control access to resources using RBAC by creating role assignments, which control how permissions are enforced. To create a role assignment, you need three elements: a security principal, a role definition, and a scope. You can think of these elements as “who”, “what”, and “where”.
1. Security principal (who)
A security principal is just a fancy name for a user, group, or application that you want to grant access to.
2. Role definition (what you can do)
A role definition is a collection of permissions. It’s sometimes just called a role. A role definition lists the permissions that can be performed, such as read, write, and delete. Roles can be high-level, like Owner, or specific, like Virtual Machine Contributor.
Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles:
If the built-in roles don’t meet the specific needs of your organization, you can create your own custom roles.
3. Scope (where)
Scope is where the access applies to. This is helpful if you want to make someone a Website Contributor, but only for one resource group.
In Azure, you can specify a scope at multiple levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. When you grant access at a parent scope, those permissions are inherited by the child scopes. For example, if you assign the Contributor role to a group at the subscription scope, that role is inherited by all resource groups and resources in the subscription.
Once you have determined the who, what, and where, you can combine those elements to grant access. A role assignment is the process of binding a role to a security principal at a particular scope, for the purpose of granting access. To grant access, you create a role assignment. To revoke access, you remove a role assignment.
The following example shows how the Marketing group has been assigned the Contributor role at the sales resource group scope.
RBAC is an allow model
RBAC is an allow model. What this means is that when you are assigned a role, RBAC allows you to perform certain actions, such as read, write, or delete. So, if one role assignment grants you read permissions to a resource group and a different role assignment grants you write permissions to the same resource group, you will have read and write permissions on that resource group.
RBAC has something called NotActions permissions. Use NotActions to create a set of allowed permissions. The access granted by a role, the effective permissions, is computed by subtracting the NotActions operations from the Actions operations. For example, the Contributor role has both Actions and NotActions. The wildcard (*) in Actions indicates that it can perform all operations on the control plane. Then you subtract the following operations in NotActions to compute the effective permissions:
To provide applications, services, or devices access to a central identity, there are three common ways to use Active Directory-based services in Azure. This choice in identity solutions gives you the flexibility to use the most appropriate directory for your organization’s needs. For example, if you mostly manage cloud-only users that run mobile devices, it may not make sense to build and run your own Active Directory Domain Services (AD DS) identity solution. Instead, you could just use Azure Active Directory.
Although the three Active Directory-based identity solutions share a common name and technology, they’re designed to provide services that meet different customer demands. At high level, these identity solutions and feature sets are:
Active Directory Domain Services (AD DS)
Enterprise-ready lightweight directory access protocol (LDAP) server that provides key features such as identity and authentication, computer object management, group policy, and trusts.
AD DS is a central component in many organizations with an on-premises IT environment, and provides core user account authentication and computer management features.
For more information, see Active Directory Domain Services overview in the Windows Server documentation.
The Active Directory Domain Services (AD DS), is the traditional on-premises version of domain services provided by AD. Organizations use AD DS to centrally manage all their resource objects, such as users, computers, printers, shared folders, groups, organizational units (OUs), etc. These objects are part of the Active Directory domain, which allows the administrators to securely manage them through Group Policies. Some of the key features offered by AD DS includes:
AD DS is managed by the organizations on-premises. The Enterprise Administrators are responsible for managing AD DS domain controllers, AD sites, trust relationships between the domains, Group Policies, backing up and restoring AD DS, etc.
NOTE: In this article, the terms traditional AD and traditional AD DS, refer to the on-premises deployment of Active Directory and Active Directory Domain Services.
Azure Active Directory (Azure AD)
Azure Active Directory (Azure AD) is the Azure solution for identity and access management. Azure AD is a multitenant, cloud-based directory and identity management service from Microsoft. It combines core directory services, application access management, and identity protection into a single solution.
Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Office 365, the Azure portal, or SaaS applications.Azure AD can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.
Azure AD offers some of the same features in the cloud, as AD DS offers on-premises. However, just because they both have AD in their names, doesn’t mean they are identical services. Azure AD is a cloud-based identity service that offers the following:
Because Azure AD is hosted and managed by Microsoft in the cloud, organizations don’t have direct access to AD domain controllers the way they do in their on-premises environment. Microsoft exposes parts of the Azure AD to organizations through the web-based interface so they have enough control to run and customize the services, but Microsoft is responsible for managing the services and servers behind the scenes in its datacenters across the globe.
Azure Active Directory Domain Services (Azure AD DS)
Provides managed domain services with a subset of fully-compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.
Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.
The Azure AD DS is a managed AD DS service in the cloud. In other words, if you want the traditional AD DS running in the cloud, you can take advantage of the Azure AD DS service by running AD DS under Azure AD. This means that you will be able to use traditional AD DS features, such as Kerberos and NTLM authentication, Group Policies (which aren’t supported in Azure AD), LDAP, etc.
For organizations who are interested in running traditional AD DS services in the cloud, Microsoft offers a couple of methods. You can either use a managed domain or a self-managed domain. Here’s the difference.
A managed domain is something that you will create in the cloud using AD DS and Microsoft will create and manage the associated resources as necessary.
A self-managed domain is an AD DS environment that you can create in the cloud using the traditional tools. For example, you will use Virtual Machines (VMs) to install the AD DS domain controllers, member servers, etc. This is a self-managed domain so you (not Microsoft) will be responsible for managing the domain just like you do in your on-premises environment.
With Azure AD DS, the core service components are deployed and maintained for you by Microsoft as a managed domain experience. You don’t deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).
Azure AD DS provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there’s no AD forests, domain, sites, and replication links to design and maintain. For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Azure AD DS provides a managed domain experience with the minimal amount of administrative overhead.
When you deploy and run a self-managed AD DS environment, you have to maintain all of the associated infrastructure and directory components. There’s additional maintenance overhead with a self-managed AD DS environment, but you’re then able to do additional tasks such as extend the schema or create forest trusts.
Azure AD DS and Azure AD
Azure AD lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Azure AD, which provides the device with an identity. Azure AD then authenticates the device when a user signs in to Azure AD and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.
Traditional computers and laptops can also join to Azure AD. This mechanism offers the same benefits of registering a personal device with Azure AD, such as to allow users to sign in to the device using their corporate credentials.
Azure AD joined devices give you the following benefits:
On an Azure AD-joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.
With Azure AD DS-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy
|Aspect||Azure AD-joined||Azure AD DS-joined|
|Device controlled by||Azure AD||Azure AD DS managed domain|
|Representation in the directory||Device objects in the Azure AD directory||Computer objects in the Azure AD DS managed domain|
|Authentication||OAuth / OpenID Connect based protocols||Kerberos and NTLM protocols|
|Management||Mobile Device Management (MDM) software like Intune||Group Policy|
|Networking||Works over the internet||Must be connected to, or peered with, the virtual network where the managed domain is deployed|
|Great for…||End-user mobile or desktop devices||Server VMs deployed in Azure|
|Feature||Azure AD DS||Self-managed AD DS|
|Secure deployments||✓||Administrator secures the deployment|
|DNS server||✓ (managed service)||✓|
|Domain or Enterprise administrator privileges||✕||✓|
|Domain authentication using NTLM and Kerberos||✓||✓|
|Kerberos constrained delegation||Resource-based||Resource-based & account-based|
|Custom OU structure||✓||✓|
|AD domain / forest trusts||✓ (one-way outbound forest trusts only)||✓|
|Secure LDAP (LDAPS)||✓||✓|
|LDAP write||✓ (within the managed domain)||✓|
Most of us have years of experience with Active Directory and delegating rights to Administrators that control the environment. Some enterprises don’t grant Domain Admin rights to all the Administrators. How does one set up just the right amount of access in Azure for Admins to manage the WVD Spring release?
To answer this question, I started with Role Base Access Control (RBAC). In this scenario, the Administrators will have the Contributor role on the Azure subscription, and the Admin should have the ability to manage other users’ permissions both in Azure and WVD.
Azure uses RBAC to manage resources. A role is a group of permissions.
Azure has many built-in roles; some of the main are Owner, Contributor, and Reader. See here for a list of built-in roles. You can also use PowerShell to get a list with the command: Get-AzRoleDefinition | FT Name,Description
The Owner role has full access to everything, including the ability to delegating access to users. The Contributor role has the permissions to create and manage resources, even create a new tenant but, cannot delegate access to users. The Reader role can view all but make now changes.
If the Administrator has Owner, the person would have full access to manage all resources, but we don’t want that for our Administrator in this case. We know the Administrator has the Contributor role. However, that means the Administrator does not have the right to delegate access to users. The Administrator will need the ability to add and remove users/groups to WVD.
There are multiple ways to solve this; you can grant the Administrator rights on the individual resource groups.
You can add a custom role. If you are more comfortable with the GUI, select Subscriptions, Access control (IAM), Add custom role.
To make it easier, you can choose to clone a role as a starting point.
The predefined permissions already defined will give you a good starting point.
However, to accomplish the requirements, it will need to be adjusted.
You can add permissions and exclude permissions from the above page, but there are limitations. The better method would be to edit the JSON.
Below is a JSON example:
“description”: “Custom Role to allow contribution and access control”,
To use the PowerShell to create the custom role using a json file:
New-AzRoleDefinition –InputFile “C:\CustomRoles.json”
This solution is granular and most secure, but it will involve some research and knowledge of JSON. If you are new to Azure, this can be challenging.
So, for this use case since the granular security is not a requirement, the Administrator will be granted two built-in roles that allow for the access needed, not just for WVD but Azure as well.
Below are Azure Windows Virtual Desktop (WVD) Reference conceptual architectures.
Reference Architecture 1
Reference Architecture 2
Reference Architecture 3
Reference Architecture 4
Reference Archiecture 5
This overview picture is meant to show a simple WVD architecture High-level and also the different features and options one has available as part of Windows Virtual Desktop. Where I split it up into two main services, where the first part is Microsoft services in Azure and the second is 3.party services
For more details, refer https://msandbu.org/windows-virtual-desktop-ecosystem/
To understand subnetting, you should first understand the decimal and binary structure of an IP address.
Let’s start with the basics. Here’s what an IP address looks like: 192.168.1.20
An IPv4 address is a 32-bit number. To make addresses more straightforward, they are divided into four 8-bit numbers — or octets — separated by a decimal point. These octets range in number from zero to 255.
Why do octets only go up to 255? Because they’re binary.
The biggest IP address possible is 255.255.255.255
In binary, this IP address looks like this: 11111111.11111111.11111111.11111111
Note that there are eight numbers between the decimal points. Each number represents a bit. Hence the term octet or the 8-bit number grouping.
Binary corresponds to this table:
Let’s use this binary number, for example: 10000001
Every 1 in a binary number “turns on” the number in its position. So, 1 in the first and last positions “turn on” 128 and 1.
Add up all the positions to get the decimal number: 128 + 1 = 129
When all the positions are “turned on,” they add up to 255.
You can see how it works here. These are the most common octets you’ll encounter in subnetting:
During the early stages of the internet, organizations assigned IP addresses like crazy until we nearly ran out. Luckily, the designers of IP addressing came up with a way to end this wasteful practice: Dividing networks using subnetting.
The process of taking an extensive network and splitting into smaller networks is known as subnetting — and it’s freeing up more public IPv4 addresses.
There are two parts to an IP address: The network portion and the host portion.
It’s like the address for a house. The network portion is like the city, state, and zip code. The host portion is like the house and street number.
A subnet defines the number of bits, out of 32, used for the “network portion” of the address. Subnet masks can also be defined in a more common ‘slash’ representation, known as CIDR notation. In the following table, the red digits represent the bits used for the network. The black digits will be used for device IP addresses. Note that the 255.0.0.0 mask can also be represented as a ‘/8’ because it reserves 8 bits of the overall 32 bits used to describe an IPv4 address as the network portion.
|Bits used for mask||Default netmask||Subnet binary|
For example, you might have a network with devices (known as hosts) with the following IP addresses:
Computer 1: 172.16.56.40
Computer 2: 172.16.56.55
Printer 1: 172.16.56.100
In this case, we’re using 24 bits (or three octets) for the network. Notice that every host device in the network has the same first three octets. That’s the network portion of the IP address with a /24 mask.
IP address: 172.16.56.40
Binary mask: 11111111.11111111.11111111.00000000
The last octet is the host portion of the IP address. That’s where you’d assign your devices. In this case, you could assign up to 254 hosts. (More on that later.)
IP address: 172.16.56.40
Binary mask: 11111111.11111111.11111111.00000000
Let’s look at the table again. If it were /16, then the first two octets would be the network portion, and the host portion would occupy the last two octets.
If it were an /8 network, then only the first octet would be the network portion.
These are the most common masks because they’re the simplest, but when you need more than one network, you have to subnet. Subnetting enables you to choose the number of bits to use for the Network portion. You can even steal bits from the host portion for the network.
Here’s what the full subnet mask table looks like. In this table, 1s represent the network portion, and 0s represent the host portion.
|Slash||Netmask||1st Octet||2nd Octet||3rd Octet||4th Octet|
To complicate things further, IP addresses have five classes, but only three are applicable to subnetting — A, B, C.
Here are the IP address ranges by class:
Class A = 188.8.131.52 to 127.0.0.0
Class B = 184.108.40.206 to 220.127.116.11
Class C = 192.0.0.0 to 18.104.22.168
Remember these IP addresses are represented in binary.
Here are the largest subnet IP addresses in these ranges:
This is important to know because it affects the number of hosts and subnets available in a network.
Notice that Class A addresses provide the most room for host addresses (the black digits). That’s because the network portion only occupies the first octet. Most large enterprises use Class A IP addresses for this reason. You can connect more devices to a Class A network than a Class C.
In every class, you can steal bits from the hosts to create more subnets, but you’re also reducing the number of hosts. Notice how stealing just one bit for the network drops the number of hosts significantly.
|Network Bits||Subnet Mask||Number of Subnets||Number of Hosts|
Class B IP addresses offer fewer hosts than Class A because its network portion occupies the first two octets.
|Network Bits||Subnet Mask||Number of Subnets||Number of Hosts|
Class C IP addresses offer the fewest hosts because the network portion occupies three octets.
You might notice that the default IP address your home router uses falls into the Class C category. This is a special subnet reserved for private IP addresses, you can read why in the Network Address Translation article.
|Network Bits||Subnet Mask||Number of Subnets||Number of Hosts|
These standards make subnetting a little easier. For example, if you choose a Class ‘C’ address, you know that it uses at least 24 bits (/24) of the 32 available bits for the network portion of the address.
Now that we know about classes, binary, and subnets. Let’s dive into a subnet.
Here’s the IP address we’ll use: 22.214.171.124/27
Here’s what it looks like in binary:
From the IP address we already know two things:
In that case, we know the network portion of the subnet will occupy these bits:
Let’s reverse engineer this last octet to determine the network portion of the address or what the subnet is for this address.
Here’s what we want to do:
Here’s an example:
1. Determine number of allowed subnets using /27 network mask.
Here’s the binary representation of the possibilities for the last octet with a /27 mask:
|000|0 0000||001|0 0000||010|0 0000||011|0 0000||100|0 0000||101|0 0000||110|0 0000||111|0 0000|
This gives us eight possible subnets with the /27 mask.
2. How to determine what subnet your IP address lives
Now, let’s find the subnet address where this IP address resides.
Remember that the IP address is 126.96.36.199
We are only looking at the last octet because the first three octets are the network portion.
We just have to take a look at our table again. 71 falls above the 188.8.131.52 subnet and below the 184.108.40.206 subnet. So it belongs in the 220.127.116.11 subnet.
|Subnet||Last Octet||Block size||IP Address|
We now have the subnet for 18.104.22.168: 22.214.171.124.
|Prefix size||Network mask||Usable hosts per subnet|
|Visual Subnet Calculator – Good One|