ACME Tutorials

This tutorial walks through creating a complex experiment in which users develop a prototypical corporate network and then verify that access controls for the data center are properly working.

The topology for the ACME Corporation is a simple, fictional enterprise that consists of a gateway, a firewall, two buildings, and a data center.

At a high-level the topology will look like:

Getting Started

Create a new directory called acme and install it as a FIREWHEEL repository.:

$ mkdir acme
$ firewheel repository install acme

How many model components will I need/want?

Model components should each should accomplish one specific goal. They should also be readable by others. Lastly, they should be as reusable as possible. That is, you should minimize future duplication of code. Our objective is to ensure that the rules put in place on the firewall ensure that only hosts from Building 2 can access the data center servers. Given this exact scenario, we can likely accomplish this goal with a single model component. However, this monolithic MC might be difficult to understand and will not be reusable. Therefore, we recommend breaking this experiment into two distinct model components. The first will contain the network topology. This MC can now be used as a baseline for conducting other experiments with the ACME network. The second MC will contain logic to add the firewall rules.

Will my MCs have any dependencies?

We have now determined that we need two model components.

Topology

To understand what dependencies are needed, we need to first convert the high-level diagram into a network topology.

We can assume that both the gateway and firewall are routers. Additionally, each building and the data center will need to route traffic. We can assume that all workstations are running Ubuntu Desktop 22.04 and that the data center servers are Ubuntu Server 22.04. Lastly, we will need several switches to help connect all the routers/hosts. Here is what the network diagram will look like.

To build this topology, we will first need a model component which provides the Experiment Graph attribute (e.g. graph).

Once a graph is available to use, we will need to add vertices to that graph and then specify what kind of vertices they are. For this topology, three types of vertices are will be used: Ubuntu2204Desktop, Ubuntu2204Server, and Helium118. In order to be able to import those classes within the topology file we need to depend on the modules that provide them. In this case, the vyos.helium118_mc and the linux.ubuntu2204_mc model components. Additionally, we will need to connect our VMs to various Switches to facilitate the network connectivity. The Switch object is provided by the base_objects_mc MC. If you look at these model components you’ll see the definitions for various model component objects which can be imported and used to help build out the experiment.

Based on our above analysis, we will depend on the graph attribute and the base_objects_mc, vyos.helium118_mc, and linux.ubuntu2204_mc model components.

Firewall Rules

For our MC which will install the firewall rules, we will need to depend on having a topology exist.

What assumptions am I making about this experiment?

While it is almost impossible to identify all assumptions, it is always important to identify assumptions which might impact the validity of the experiment. For this tutorial, the biggest assumption being made is that the OS types/versions may not be accurate.

How will I validate my results?

For this tutorial, we will leave the verification up to the user. However, one test would be to trying pinging from building_1-host_1.acme.net to datacenter-1.acme.net before installing the firewall rules to ensure connectivity and then once after installing the rules to ensure connectivity has been lost.