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.

Design Issues

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:

The reasons that these are problems are:

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.