Network Design Evaluation
This is an evaluation of some decisions that went into the design of this network.
This guide does not pretend to use a network design that everybody will recognize is the ideal network layout for every scenario. In fact, there are some issues that many good, experienced networking administrators may be likely to immediately object to. Here is a rundown of some of those objections.
This is an attempt to cover some aspects of the design that many network professionals may immediately consider to be a problem, a limitation, or at least a drawback compared to a different design. Sosme of those aspects include:
- having traffic go through two firewalls
- performing only a single key service on a machine
- using virtual machines as extensively as they are used (rather than just relying on physical hardware)
- internal routing is largely being done at the third layer of the standard OSI model
The reasons that these are problems are:
- Going through two firewalls provides extremely little benefit. (There might be some super-slight benefit by having some minor redundancy.) Yet there may be a great cost in speed.
Machines are capable of running more than one service.
- Communication may be faster within a machine than when data needs to go from one machine to another machine.
- Having just one key service per machine causes lots of machines. This may increase costs like maintenance that needs to be done for each machine, increasing the amount of documentation.
- There is some cost to using virtualization. Most notably, things may run slower. Resources, such as physical memory on a computer, may be used up to provide virtualization, while those same resources could be utilized in a different way if a different design was used. Modern virtualization software offers virtualization of decent hardware with far less costs than software from the twentieth century. Even if the costs are rather minimal using some modern software, there are still some costs.
Many network professionals favor the use of VLANs to control network routing.
- There may be some speed benefit. This is probably because VLANs typically operate by using a modification of traditional Ethernet frames (such as the 802.11Q modification), which basically means operating at the second layer of the OSI Model (in addition to the first layer of the OSI model), instead of using IP addressing which basically means using the third layer of the OSI Model (in addition to also needing to use both the second layer and the first layer of the OSI model).
- The device does not need any configuration details about the VLAN configuration, which means the device does not need to do anything at all to start operating on a different VLAN. For instance, a network professional can alter how a switch operates, and a computer that communicates to that switch won't need to do anything. Using VLANs provides the freedom to make such a change without needing to worry about whether the settings on a computer are correct. In contrast, routing using IP subnetting may require the computer to make a change. Even if the computer will eventually recover by automatically obtaining the new IP settings, the computer would remain broken until it does automatically perform that action. The concern of that downtime simply doesn't exist when VLANs are used.
Reasons this gets done
With so many issues, why even bother proceeding?
First, understand that a complex designs may have limitations and/or drawbacks that other designs may not have. However, those other designs may have different limitations and/or drawbacks that the first doesn't have.
- multiple firewalls
Basically, the physical hardware must perform some sort of traffic handling in order to get the traffic to a virtual machine. So, the outer firewall is not optional if an inner firewall will be getting used.
The purpose of this design is to try to maximize the amount of decision making that is handled by a virtual machine. Using a virtual machine allows the firewall to be moved to other physical hardware with minimal effort. By having the physical hardware offload many of the traffic handling decisions, this keeps the focus/concentration of the physical hardware on performing only the decisions that it must. That may help to simplify some of the configuration of the physical hardware.
- many machines
This is one of the most striking drawbacks. Dedicating an entire computer to a small-scale DHCP/IPv4 server may seem extraordinarily wasteful. The service could easily be combined into another machine.
The primary benefit to doing this may simply be to provide the educational opportunity to demonstrate how one machine communicates to another machine. By working with many machines, even if many of them are “virtual” machines and not physical machines, people may get some experience working with network communications between machines. If the number of machines was minimized, that would reduce the number of opportunities where a person has a reason to look at what types of communications are occurring.
A configuration that will work with multiple machines will commonly work well with a single machine. For instance, a person could read documentation showing an address of 192.0.2.10 for an “automatic addressing” server, and 192.0.2.11 for the “name resolution” server, but on my network there is one machine at 198.51.100.15 that provides both of those features.” If a person is following that guide, then the person might simply need to insert 198.51.100.15 in the locations where the example documentation shows either 192.0.2.10 or 192.0.2.11. There could be exceptions where it doesn't work that easily, but often it will work just that easily.
On the other hand, having documentation for a single machine that does everything, but then trying to utilize that example as things get deployed to multiple machines, might be more challenging. Using the same example IP addresses that were described above, if the documentation showed 198.51.100.15, then the person might need to take some additional time to figure out whether the address needs to become 192.0.2.10 or 192.0.2.11. That additional amount of decisions might be more prone to errors.
Also, things might be more likely to work when they are on the same machine, because many firewalls will be more prone to accept traffic that comes from a program running on the same machine as the firewall. By having multiple services on one machine, firewalls may be less likely to cause problems. This documentation was designed to try to address the most challenging case. That way, the documentation is more likely to be suitable, even for cases where firewalls are prone to be cautious about non-local traffic.
Network sniffing might also produce results that are a bit easier to clearly understand if network traffic is using two different network interfaces, rather than a loopback interface.
- Using virtualization
This does use some overhead. This also provides quite a bit of flexibility. Services can be moved from one piece of physical hardware to another piece of physical hardware with relatively little struggle. This can be nice if one piece of hardware needs to go to a repair shop, or if there is a desire to have services provided by a new computer (which is presumably faster).
If two virtual machines are running low on disk space, an organization might be able to fix the problem by buying one larger storage device (traditionally a magnetic “hard drive”). Physically replacing one storage device
This is, perhaps, the primary benefit the virtualization. There may be other benefits, such as being able to remotely access a system by communicating with the physical host and using software to view the “local display” of a virtual machine, which might work even if the virtual machine's networking stops working. Of course, this isn't any real benefit if the physical machine's networking stops working. So, in theory, there may be little benefit to the added complexity. In practice, the potential benefit may actually be more likely. Software-based configuration changes may be more likely to occur on the machines that people are interacting with a lot. By using virtual machines for the core tasks, this means that the machine which will break may be more likely to be a virtual machine.
- Using Layer 3 routing
Some people may prefer to use VLANs. However, there are some drawbacks to that approach.
The most substantial drawback is that some equipment may not support compatible VLAN communications. With physical equipment, the professional standard that is most compatible is 802.11Q. However, lower end consumer equipment may not support that. Also, when dealing with virtual hardware, different software may provide different compatibility. In contrast, implementations of IPv6 are compatible with other devices using IPv6, and implementations of IPv4 are compatible with other devices using IPv4. So relying on IP implementations will likely work without issues of compatibility.
Relying on IP routing may also provide some exposure to the task of working with mulitple subnets, and people will gain experience with referring to IP addresses. Using VLANs typically involves spending more time with configuring infrasturcture equipment (like managed switches). That's not necessarily a bad thing for people to learn, but the approach used by this guide will have people spending time configuring computers, which is also a useful skill.
Also, there is a philosophical point against relying on VLANs for routing. Using VLANs for routing typically involves routing at Layer 2 of the OSI Model. The primary benefit gained by the OSI Model's layer 2 is identification of a device on a local network link. MAC addresses, and standard Ethernet frame format, provide the ability for devices to communicate with that benefit. Routing is really a feature supported by IP, which is widely recognized to be at Layer 3 of the OSI Model. Using 802.11Q VLANs involves altering the traditional Ethernet frame format to stuff in some routing information. The argument being made here (which is admittedly more based on a philosophy of opinions, rather than facts that strongly disprove the inaccuracy of an opposing opinion) is that 802.11Q VLANs are providing a feature in the wrong spot of the network packets. Yes, the 802.11Q VLAN method does work, but it violates the principle of segregating information into layers based on concepts.
More ways are acceptable too
Sometimes, there may be more than one way to do a thing. This guide tries to share knowledge by showing how to do some things using the methods by this guide. This guide is not trying to say that these methods will serve everybody's desires in the best possible way. Those who wish to promote an alternate design are free to do so. Another design may have some advantages, and might even be better overall. Meanwhile, this design works, and documentation is readily available. People interested in learning about this stuff are encouraged to use this readily available resource and gain whatever benefits are easily obtainable. Then, if there's a desire to explore additional possibilities, people may go ahead and do that as well. If people learn additional knowledge while doing that too, then that's also good.