In order to facilitate a development network with room for various types of development activities, activities must be partitioned into network enclaves that are appropriate for those activities. These enclaves include:
- The Trusted Enclave
- The Development Enclave
A trusted enclave consists of any services required to recover the research and development capabilities of the network in the event of a destructive event. These include:
- Switches for connecting the various trusted and development services
- A firewall for protecting the trusted enclave from access from the development enclave
- A bastion host for further isolating privileged access to trusted enclave services
- A service for bootstrapping and managing the trusted enclave's other services
- A service for hosting the trusted enclave's virtual machines
- A service for verifying the identity of administrators and network owners
- A service for verifying the identity of physical workstation users
- A service for auditing login attempts and administrative actions in trusted enclave
- A service for monitoring key development systems for hardware failures
- A service for performing antivirus scans in the trusted enclave
- A service for scanning systems in the trusted enclave for vulnerabilities
- A service for backing up irreplaceable data from network services
- A service for providing a root certificate authority for signing intermediate CA certs
- A service for providing an intermediate certificate authority for signing services' certs
The development enclave will host all services required by developers to perform software development activities. The centrally-managed services that they use to do this type of work will be hosted in a segregated environment in order to prevent these services from having to compete for compute and storage resources with non-centrally-managed infrastructure used and controlled by the developers themselves. This model requires these development resources to either be hosted on a separate IaaS from the one provided to the developers for use, or it requires separate hypervisors on the same IaaS set aside for use by those maintaining the centrally-managed services. The centrally-managed services being provided for the developers will include:
- A service for bootstrapping and managing the development enclave's other services
- A service for hosting the development services' virtual machines and/or containers
- A service for verifying the identity of users accessing development services
- A service for storing, versioning, and managing updates to source code
- A service for providing task pipeline orchestration
- A service for providing a task standard library
- A service for providing a documentation capability for developers
- A service for providing developers with documentation about services
- A service for providing a workflow management capability
- A service providing an intermediate certificate authority for creating developers' certs
- A service for storing release artifacts created by developers
- A service for providing developers with a chat capability
- A service for providing basic reporting of services' statuses to developers
- A service for providing developers with storage for project working data
- A service for providing developers with a dev-to-dev file transfer capability
The network IP schema for a development network must be organized in a way that accommodates multiple interfaces for each component due to the numerous activities and interactions that each system is expected to engage in. There are specific activities that even warrant their own subnets, virtual local area networks (VLANs), and/or even their own physical hardware to isolate their network traffic.
As a result, care must be taken to properly design this space. Some of the requirements include the following. The network IP schema must:
- Be consistent throughout, using the same set of organizing principles in every VLAN and subnet used inside the network
- Be easy to remember, even when documentation is not available
- Accommodate both current and anticipated use cases for the foreseeable future
- Accommodate both current and future capacity for the foreseeable future
- Different workloads should be separated into different network segments
- Be designed with the following in mind: all the systems within a single subnet are susceptible to broadcast storms from systems within the same subnet; therefore
subnets should be limited in size whenever it is practical and reasonable to do so
There are three basic categories of subnets that are required for a development network:
- Public subnets
- These subnets should be routable to the core switch
- The core switch should host the gateway for these subnets
- The workstations should be able to directly access any gateways on the subnets within the public space, and any other subnets in the public space should be routable to it as well.
- Private subnets
- These subnets should be routable to the core switch
- The core switch should host the gateway for these subnets
- The workstations should not be able to directly access any gateways on the subnets within the private space, and not all other subnets in the private space should be routable to it as well.
- Interrack subnets
- These subnets should not be routable to the core switch
- An interrack switch (i.e. a switch that only connects to other switches in neighboring racks, not to the core) should host any gateways for these subnets, (if a gateway is even required)
- The workstations should not be able to directly access any gateways (or IP addresses) on the subnets within the interrack space, and no other subnets generally require direct access to subnets in this space
These three generic types of subnets collectively account for 100% of the subnets used with the network. Each subnet must conform to one of these three types of subnets for inclusion in the network.
In addition to generic subnet types, each subnet will also have a specific purpose. In a development network, there are a few different purposes to have subnets:
- Application Presentation Subnet
- This subnet purpose type is used to present an application (i.e. a web interface) to a user within the network
- Since this subnet type is used by the end user, its subnet access type is public
- Application Administration Subnet
- This subnet purpose type is used to administer an application, usually at the operating system level. This subnet type provides access to ports associated with this like: secure shell protocol (SSH), remote desktop protocol (RDP), and other access protocols designed to allow administrators to administer and interact with the host operating system that is hosting all/part of a service
- Another use for this type of subnet is intraservice communication. For example, if a service in one subnet needs to communicate with a service in another subnet. While this use case is equally valid, and in some cases, more common, this should still be referred to as the application administration subnet type to avoid confusion with between application inter- and intra-service subnets
- This subnet type is typically only accessible directly from a bastion host that has an IP address in both a public and private space; therefore, its subnet access type is private. Users must first login to a bastion host to access systems within private subnets. This additional layer of protection may not always be warranted
- Application Interservice Subnet
- This subnet purpose type is used for one part of an application's service to interact with another part of an application's service (i.e. a cluster of databases replicating data between two other clones of itself spread across three different systems so that if the primary system managing the database fails, it has two hot spares to pick up where it left off)
- Since this subnet type is only used for services to talk to one another and does not require access by administrators or users, this traffic is typically confined to its own interrack switches and as a result, its subnet access type is interrack
- Backup Subnet
- This subnet purpose type is used for transferring backups from each backed-up application to a central backup server that retains and manages backups
- Since a good disaster recovery strategy dictates that backups should not be kept in the same racks, or even the same building, as the services being backed up, this subnet type, out of necessity, must be routable to the core; however, there is little need for administrators or users to have direct access to these types of subnets, since these subnets are essentially just managing service-to-service traffic. As a result, their subnet access type is private, only so that traffic can span physical buildings, otherwise, the subnet access type would be interrack
- Lights-out Management Subnet
- This subnet purpose type is used for accessing a physical server's lights-out-management interface. This interface can either be a graphical web interface or a text-based interface (i.e. interface based on the IPMI, or similar, protocol). Traffic on this type of subnet is used for performing tasks like:
- powering a server on/off
- viewing logs related to the health of hardware components
- ther miscellaneous low-level hardware management tasks
- Since these interfaces need to be accessible by end users that are managing their own physical hardware that they may not have physical access to, the subnet access type for these subnets is public; while this does have its risks, it also facilitates the quick and graceful shutdown of the network in the event of a physical emergency necessitating a full network shutdown like an air conditioning or power failure in the server room
- This subnet purpose type is used for accessing a physical server's lights-out-management interface. This interface can either be a graphical web interface or a text-based interface (i.e. interface based on the IPMI, or similar, protocol). Traffic on this type of subnet is used for performing tasks like:
- Dynamic subnets
- This subnet purpose type is used for assigning IP addresses dynamically to different sets of systems that do not need to have their IPs allocated statically (e.g. desktop workstations, cloud virtual machines, etc)
A development network occupies private IPv4 space and is exposed to external networks via network address translation (NAT). As a result, the network's subnet ranges must be somewhere within the possible private network classes set aside by internet management authorities for private networks. These include:
- 10.0.0.1 - 10.255.255.255
- 172.16.0.0 - 172.32.255.255
- 192.168.0.0 - 192.168.255.255
One interesting thing about the amount of the private network class ranges is that it perfectly matches the amount of subnet access types defined elsewhere in this document. Within the network, this convenient coincidence is taken advantage of by ensuring that the first octet of every IPv4 address used within the network, indicates the subnet access type of the subnet that IP address is assigned to, like so:
- 10 - The public subnet access type's first octet
- 172 - The private subnet access type's first octet
- 192 - The interrack subnet access type's first octet
So, for example, if a server hosts a website and that server needs an IP address that provides users with access to the website. That server may use 10.16.5.21 for its address. The "10." part of the address, in this example, indicates that this IP lives on a subnet whose gateway address is assigned to the core switch, and a route exists between that subnet's gateway and every "10." gateway, allowing every "10." gateway to communicate with every other "10." gateway, and in-turn, anything with a "10." address should be able to communicate with anything else with a "10." address, which includes user workstations.
Another interesting thing about these available network ranges is that each of the smaller ones is a symmetrical subset, (from a size perspective), of the one above it. For example, the range starting with 192 has approximately 65,534 IP addresses within it. While the address range starting with 172 has approximately 1,048,574 addresses within it. This means that there are approximately 16 times the amount of addresses in the 172 range than there are in the 192 range. It also means that if this large 172 range is broken into 16 smaller subnets, each with its own "second octet", "172.16." (172.16.0.0 - 172.16.255.255) each has the exact same number of IP addresses as the 192 range (192.168.0.0 - 192.168.255.255). In-turn so does "172.17.", "172.18.", et cetera, all the way up to the sixteenth IP range: "172.31."
Similar to how the network IP schema makes use of the fact that there are three private network IP ranges reserved by internet authorities and three subnet access types, it can also make use of the fact that there are 16 different subnets within the 172 range, each matching the size of the 192 range. Of the six subnet purpose types, only two of those are "private" subnet purpose types. Each of these could be assigned its own 172.X.0.0 - 172.X.255.255 IP range, or in other words each could be given its very own "second octet". For example, two 172 ranges might be allocated to these for the two private subnet purpose types like so:
- 16.X.X/16 (172.16.0.0 - 172.16.255.255)
- Used for the "Application Administration Subnet" described in the "Subnet Purpose Types" section of this document
- 17.X.X/16 (172.17.0.0 - 172.17.255.255)
- Used for the "Backup Subnet" described in the "Subnet Purpose Types" section of this document
Allocating the same second octet digits for each different subnet purpose has some very nice advantages from an organization standpoint. Going back to the example of the server hosting the website that has a public IP address of 10.16.5.21, that server would also probably require administrators to access it via a remote access protocol, and would also require backups, so what IP addresses should it be assigned for those functions? Here is an example of what is possible by providing each subnet purpose type its own second octet:
- 16.5.21
- Public subnet address for accessing the website on the server
- 16.5.21
- Private subnet address used by administrators for administering the server via some remote access protocol like the secure shell protocol
- 17.5.21
- Backup subnet address used by the backup service to transfer backups from the server to a backup server in another building
This makes it very easy to determine any of the server's IP addresses for any subnet purpose type, as long as the server's IP address on any single subnet is known. This same schema can also be used for the server's other subnet purpose types as well, not just the private ones. A server that has an application public, private, and interservice subnet IP address, plus a backup and lights-out-management subnet IP, might look like this:
- 16.5.21
- Public subnet address for accessing the website on the server
- 17.5.21
- Lights-out-management subnet address used for remotely powering the server on/off or checking the status of the system's hardware, even when the operating system is not running
- 16.5.21
- Private subnet address used by administrators for administering the server via some remote access protocol like the secure shell protocol
- 17.5.21
- Backup subnet address used by the backup service to transfer backups from the server to a backup server in another building
- 168.5.21
- Interrack subnet address used by the website to communicate with clones of itself that need the exact same website content mirrored between the three
Looking at this example, it is also easy to see a pattern emerging in the third and fourth octets as well. Up to this point, in each subsequent example, they have remained the same. The third octet indicates the specific service that a system is associated with. In this case, the "service" is a website. The fourth octet indicates the specific server hosting a copy of the service. So, continuing on using this same example, a group of three servers that each host the same content would have the same third octet, but different fourth octets, like so:
- First web server's application presentation IP address
- 16.5.11
- Second web server's application presentation IP address
- 16.5.21
- Third web server's application presentation IP address
- 16.5.31
Looking at this latest set of addresses, another pattern emerges, the first digit of the fourth octet is different across all three servers. This is because this first digit within the fourth octet indicates the rack of that server. Looking back to the Physical Architecture section, it is known that clustered or highly-available services are typically spread across three servers, each in a different rack. Knowing this and looking at the three numbers in the example, it should now be clear that these three servers do not share a rack. If these web servers also relied upon three clustered database servers for the content that they are serving, these six servers might be addressed like so:
- First web server's application presentation IP address
- 16.5.11
- Second web server's application presentation IP address
- 16.5.21
- Third web server's application presentation IP address
- 16.5.31
- First database server's application presentation IP address
- 16.6.11
- Second database server's application presentation IP address
- 16.6.21
- Third database server's application presentation IP address
- 16.6.31
Looking at these latest IP address examples, it is apparent that the first database server and the first web server reside in the same rack, because the first digit in the fourth octet matches. Since this first number can range anywhere from 0-25, given the fact that the fourth octet's value could range from 0-255, this creates a schema that supports a network hosting equipment spread across up to 26 racks.
The last portion of the fourth octet, up to this point, has always been "1" in the examples above, so what does this mean? What if there are several servers of a single type spread across 21 different racks, with two residing in each of those 21 racks? The servers in the first, thirteenth, and twenty-first racks could be labeled like so:
- First server in first rack
- 16.4.11
- Second server in first rack
- 16.4.12
- First server in thirteenth rack
- 16.4.131
- Second server in thirteenth rack
- 16.4.132
- First server in twenty-first rack
- 16.4.211
- Second server in twenty-first rack
- 16.4.212
This implementation makes a very bold assumption, which is that a single rack will never hold more than 10 of the same type of server. This is not as unreasonable as it seems, considering the fact that most racks only hold so many units, and rarely, if ever, is an entire rack set aside for a single type of server, especially when services are clustered; however, if this reasonable limit is somehow reached, an additional third octet's worth of IP addresses could be set aside for this same type of server in order to accommodate an additional 10 servers per rack, for each third octet set aside for the service type.
While this schema makes sense for high-traffic application-specific subnets, it makes less sense for the much lower traffic backup and lights-out-management subnets. These require less isolation since the quantity of requests on these subnets is much lower than the others and an event like broadcast storm would have much less impact since nothing on these subnets has anywhere near a 100% uptime requirement.
In general, application presentation, administration, and interservice subnets should match in size and quantity across the entire network, and should be just large enough to contain enough IPs for the maximum foreseeable quantity of hosts that are required for that application to run.
As a result, the typical size for these subnets is 256 IP addresses, or a "/24" classless inter-domain routing (CIDR) notation. This especially helps the third octets and gateways align in such a way that one octet is set aside per application type and the gateways for each subnet are easy to predict.
However, for the backup net, a much larger subnet perhaps makes more sense. While the amount of data processed on this subnet during a single transaction might be high, the amount of transactions between systems is relatively low. Additionally, the uptime requirements for this subnet are much lower than the application-specific subnets.As a result, something like a large "/17" subnet makes more sense.
For general guidance on size, refer back to the guiding principles portion of the Network IP Schema section of this document to create a subnet that is the right fit for its purpose.
In general, application presentation, administration, and interservice subnets should match in size across the entire network, and should be just large enough to contain enough IPs for the maximum foreseeable quantity of hosts that are required for that application to run. As a result, the typical size for these subnets is 256 IP addresses, or a "/24" classless inter-domain routing (CIDR) notation. This also helps the third octets align in such a way that one octet is set aside per application type.
However, for the lights-out-management net, a much larger subnet perhaps makes more sense. The amount of data processed on this subnet during a single transaction is relatively low, while the amount of transactions between systems is also relatively low. Additionally, the uptime requirements for this subnet are much lower than the application-specific subnets. As a result, something like a large "/17" subnet makes more sense.
For general guidance on size, refer back to the guiding principles portion of the Network IP Schema section of this document to create a subnet that is the right fit for its purpose.
Dynamic subnets are quite different from not only the other subnet types discussed thus far, but can also be very different from one another. These subnets can not be guaranteed to conform to any particular type of behavior or traffic pattern, and as a result, no blanket assumptions can be made regarding their recommended size.
Sometimes, these subnets may deserve their very own second octet, not unlike the backup or lights-out-management subnets. However, there are other times where these subnets can just use the unused portions of an already allocated second octet without causing too much hassle or confusion. Each situation will be different and depend on the usage of the dynamic subnet.
For general guidance on size, refer back to the guiding principles portion of the Network IP Schema section of this document to create a subnet that is the right fit for its purpose.
In any subnet used in the network, regardless of access or purpose type, the following IP addresses should be reserved within the subnet whenever possible:
- The very first X.X.X.0 - X.X.X.9 range in the subnet
- The very last X.X.X.250 - X.X.X.254 range in the subnet
These should be reserved for gateways and other types of virtual IP addresses that should not be used to represent specific hosts, but rather, should be used as virtual IP addresses hosted on networking devices like switches and routers. These address ranges should be excluded from things like dynamic IP address assignment pools and should not be manually static IP addressed to individual hosts either.
In addition to subnets, there is also a portion of the network IP schema that specifies the use of VLANs. VLANs are used within the network to further isolate network traffic, and make things like segregating traffic via static routes, switchport configs, and firewall rules easier to do. Much like there are three different types of subnet access types and at least three available sets of private IP address ranges, there are also at least three usable groups of VLANs that can be assigned to these ranges:
- 2000-series VLANs
- Public subnets beginning with "10."
- 3000-series VLANs
- Private subnets beginning with "172."
- 4000-series VLANs
- Interrack subnets beginning with "192."
Anything above 1000 is considered to be an extended VLAN. These are not always enabled by default by network operating systems, but can be. Why use extended VLANs? It makes migration easier. For "greenfield" installations of brand-new development networks, this is not much of an issue, but more often than not, existing networks are converted over time from legacy network IP schemas to more advanced and robust IP schemas. Since these legacy schemas are typically simple in nature, (hence the need to upgrade them), it is unlikely they included the use of extended VLANs. This makes for a very clean transition from old to new VLAN schemas.
Why not start at 1000? Mainly because certain networking device manufacturers choose to reserve the first few VLANs in the 1000-series range for their own uses. The 2000-4000 series of ranges does not typically have this problem, and provides all the VLANs required in most situations, even though the 4000-series VLANs do not reach 4999. However, if a network does not and will not use a network operating system that reserves any 1000-series VLANs, shifting the examples above down by 1000 is completely acceptable.
So, how is this X000-series schema used exactly? The first digit has already been explained in the introduction to this section; however the last three numbers also have meaning as well. These numbers match the third octet of the IP address. For example, going back to our example of the web server used in subnets section of this document, here are the IPs, subnets, and VLANs for an example webserver:
- 16.5.21
- Subnet IP Range: 10.16.5.0 - 10.16.5.255
- Subnet CIDR Notation: 10.16.5.0/24
- VLAN of Server (and Subnet): 2005
As previously discussed, the first digit of the VLAN (2) indicates that this is a public subnet in the "10." range, while the last three digits (005) indicate the application-specific subnet (10.16.5.0/24) that this VLAN is associated with.
So, since the third octet is limited to 255, what happens to VLANs 2256-2999, and 3256-3999? Also, what about the "10.17" and "172.17" VLANs? How are those subnets provided with VLANs? Both of these questions can be answered with the following example. Here are the IPs, subnets, and VLANs for the same server, but this time, including its other subnets:
- 16.5.21 (Application Presentation IP Address)
- Subnet IP Range: 10.16.5.0 - 10.16.5.255
- Subnet CIDR Notation: 10.16.5.0/24
- VLAN of Server (and Subnet): 2005
- 17.5.21 (Lights-out-Management Subnet IP Address)
- Subnet IP Range: 10.17.0.0 - 10.17.127.255
- Subnet CIDR Notation: 10.17.0.0/17
- VLAN of Server (and Subnet): 2256
- 16.5.21 (Application Administration Subnet IP Address)
- Subnet IP Range: 10.16.5.0 - 10.16.5.255
- Subnet CIDR Notation: 10.16.5.0/24
- VLAN of Server (and Subnet): 3005
- 17.5.21 (Backup Subnet IP Address)
- Subnet IP Range: 172.17.5.0 - 172.17.127.255
- Subnet CIDR Notation: 172.17.5.0/17
- VLAN of Server (and Subnet): 3256
- 168.5.21 (Application Interservice Subnet IP Address)
- Subnet IP Range: 192.168.5.0 - 192.168.5.255
- Subnet CIDR Notation: 192.168.5.0/24
- VLAN of Server (and Subnet): 4005
Looking at this example, some additional patterns become apparent. Specifically, for additional subnets past the application-specific presentation, administration, and interservice subnets with their own second octet's worth of IP addresses, once the 2255 and 3255 VLANs are reached, the VLAN schema just rolls over to the next VLAN available and increments up from there.
Another feature that becomes apparent from this example is that fact that the third octet of an IP address does not always indicate the last three numbers of a VLAN. That is quite commonly the case, since most of the subnets are "/24" in size and therefore most VLANs occupy precisely one third octet, but when they are not a "/24" subnet, and therefore span across multiple third octets, the first third octet is the octet used to name the VLAN. This is why, in the example above, the Backup subnet IP is "172.17.5.21" but the VLAN is "3256". The subnet is a "/17" and therefore actually starts at "172.17.0.0", not "172.17.5.0".
Since this also starts with "172.17" and not "172.16", the "3000" VLAN that would normally be associated with a "172.X.0.0" address has already been used. This is how the VLAN tag ended up at "3256". The fast way to calculate VLANs in this "172.17" subnet is to just add "256" to whatever the VLAN tag should be based on the third octet. Since this one should have ended in "000", it ends in "256" (i.e. 256+000=256). To better illustrate this, here are some random IP addresses, their subnets, IP ranges, and what their VLAN tags are:
- 16.1.21
- Subnet: 10.16.1.0/24
- IP Range: (10.16.1.0 - 10.16.1.255)
- VLAN: 2001
- 16.67.11
- Subnet: 10.16.65.0/22
- IP Range: (10.16.65.0 - 10.16.68.255)
- VLAN: 2065
- 17.1.1
- Subnet: 10.17.1.0/24
- IP Range: (10.17.1.0 - 10.17.1.255)
- VLAN: 2257
- 18.0.1
- Subnet: 10.18.0.0/24
- IP Range: (10.18.0.0 - 10.18.0.255)
- VLAN: 2512
- 19.231.1
- Subnet: 172.19.231.0/24
- IP Range: (172.19.231.0 - 172.19.231.255)
- VLAN: 3999
The examples above illustrate another important point: even though there is currently no need for any subnets using: "10.18", "10.19", "172.18", or "172.19", this VLAN schema supports up to three "second octets" in the public (10.) and private (172.) IP ranges.
While this schema makes it easy to determine VLANs based on IP addresses, it does have some limitations. For instance, what if an administrator wished to implement these two subnets:
- Subnet: 10.16.1.0/25
- IP Range: (10.16.1.0 - 10.16.1.127)
- VLAN: ????
- Subnet: 10.16.1.128/25
- IP Range: (10.16.1.128 - 10.16.1.255)
- VLAN: ????
Which of these subnets has the right to use the 2001 VLAN? The answer is: one or the other, but not both. As a matter of fact, under this VLAN schema, only one of these subnets may exist at any one time, so in order to keep things consistent, the subnet starting with 10.16.1.0 should probably be used. Now, this subnet may still be a /25 and could even be a /32, but anything smaller than a /24 essentially wastes the remaining IP addresses out of the original 256 that use this same third octet, because no other subnets can now be implemented using that this same third octet, and in-turn the VLAN associated with that octet.
Another limitation that should be noted is that the 4000 series VLANs do not go all the way up to 4999. Extended VLANs currently only go up to 4096, and usually even have the one at the end reserved for use by network operating systems. This effectively limits the number of IP addresses that can have a public, private and interrack subnet access type associated with them. This is why VLANs ending in 2095, 3095, 4095, and below should be reserved for servers that will require all three types of IP addresses. However, the later ranges in each of these thousand-series (anything above 2095 or 3095) are not wasted; they can still be used for dynamic subnets that only require either a public or private subnet access type.
The network IP schema described in this section is architected independent of the enclaves described in other parts of this document. The VLANs and subnets used for the trusted and development enclaves can and will span the 2000-series, 3000-series, and 4000-series VLANs.
Architects using this reference architecture to design networks based on it, should feel free to allocate VLANs and subnets to specific enclaves in whatever manner they deem appropriate in order to accommodate their specific network administration considerations.
A simple example setup though might look something like this:
- Trusted Enclave
- VLANs 2000, 3000, and 4000
- Trusted Switches, routers, and firewalls
- VLANs 2001, 3001, and 4001
- Trusted bootstrap and mirror servers
- VLANs 2002, 3002, and 4002
- Trusted private cloud control plane servers
- VLANs 2003, 3003, and 4003
- Trusted private cloud storage servers
- VLANs 2004, 3004, and 4004
- Trusted private cloud compute pool servers
- VLANs 2005-2009, 3005-3009, and 4005-4009
- Reserved for trusted enclave, but not yet used
- VLAN 2128
- Trusted desktop workstation dynamic IP address pool
- VLANs 2000, 3000, and 4000
- Development Enclave
- VLANs 2010, 3010, and 4010
- Development Switches, routers, and firewalls
- VLANs 2011, 3011, and 4011
- Development bootstrap and mirror servers
- VLANs 2012, 3012, and 4012
- Development private cloud control plane servers
- VLANs 2013, 3013, and 4013
- Trusted private cloud storage servers
- VLANs 2014, 3014, and 4014
- Trusted private cloud compute pool servers
- VLANs 2015-2019, 3015-3019, and 4015-4019
- Reserved for development enclave, but not yet used
- VLAN 2192
- Development virtual machine dynamic IP address pool
- VLANs 2010, 3010, and 4010
This example schema uses the first ten VLANs in each X000-series of VLANs for the trusted enclave, and the next ten VLANs for the development enclave, but this may not be right for every organization. It largely depends on the scale, amount of different infrastructure types, and the anticipated growth of each enclave within the network over time.
Another important factor in network architecture is how systems are named. This includes things like hostnames of servers and networking devices, (e.g. switches, routers, and firewalls), as well as how each of these items (and more) are referenced within the domain name system. Here are some guiding principles to be used when naming systems within a network:
- Things that are similar, should be named in a similar manner
- Switches should be named like other switches, servers like other servers
- Things that are different, may be named differently, but don't have to be
- Switches and server could be named the same way, but don't need to be
- Physical and virtual hosts could be named the same way, but don't need to be
- Every host has a DNS entry
- It does not matter if it is a bare metal, virtual, or a containerised host
- This makes it clear what hosts live where, and how to reach them
- Do not repeat yourself
- If DNS A record already exists for an IP address, CNAME to it
The anatomy of a hostname can be complex depending on how many different components an administrator wishes to support. The choice of what to include heavily depends on the scale of the organization's infrastructure, as well as how dynamic the infrastructure is. Some components that administrators may find useful include, (but are not limited to):
- Domain name (e.g. Realm, domain, subdomain, etc.)
- Environment tier (e.g. production, staging, development, etc.)
- Environment designation (e.g. A/B, Blue/Green, etc.)
- Classification level (e.g. Top Secret, Secret, Confidental, etc.)
- Host type (e.g. Application, Webserver, Database, Storage, etc.)
- Host subtype (i.e. The shorthand name for a specific application or subcomponent)
- Host increment (i.e. Used when copies of the same host exists)
- Host location (e.g. region, availability zone, building, rack, etc)