## Give a short overall explanation in your own words of what you did in this assignment (max. 200 words). (5 Points)

First, we prepared a virtual environment on GCP to deploy openstack. We created VPC networks, subnets, spun three virtual machines that support nested virtualization and created all the neccessary firewall rules to allow tcp, icmp and udp traffic. Second, we deployed OpenStack on the previously created machines using Kolla Ansible. This involved a lot of troubleshooting such as installing additional packages and setting a proper timezone to finish MariaDB setup. Third, we configured the OpenStack itself. After login in via the OpenStack dashboard, downloading neccessary files and setting the environment variables that are used for authentication we were able to use the OpenStack cli. Then thanks to having OpenStack, we were able to spawn a client VM hosted in OpenStack. Finally, we executed performance benchmarks inside the OpenStack VM.

## After creating all gc VMs, deploying OpenStack and starting an OpenStack VM, how many virtual networks are involved to establish the connectivity? (1 Point)

There are three virtual networks: two GCP and one OpenStack.

## Initially, the OpenStack VM was not reachable from the gc controller VM (step 11). Why? (2 Points)

The reason for this behavior is that there is no packet forwarding set up yet when we reach step 11. The appropriate firewall rules are configured in step 13. Otherwise, the OpenStack VM is not reachable from the outside.

## Look into the iptables-magic.sh script. What is happening there? Describe every command with 1-2 sentences. (5 Points)

# Simple variable assignment. We use this variable later on to specify subnetwork address space.
floating_subnet="10.122.0.0/24"

# Simple variable assignment. We use this variable later on to specify the default gateway for our floating subnetwork to the rest of the network. 
floating_gateway="10.122.0.1"

# Execute the ip(8) command in a Docker container called "openvswitch_vswitchd". The ip(8) command creates a new networking device called "br-ex" and adds it to  the $floating_gateway address (see ip-address(8) for more details). 
docker exec openvswitch_vswitchd ip a add $floating_gateway dev br-ex
# Within the openvswitch_vswitchd container change the state of the device to up. This "activates" the br-ex network interface (otherwise no traffic could pass through this interface). For more details see the ip-link(8) manual.
docker exec openvswitch_vswitchd ip link set br-ex up
# This command configures the MTU parameter for the "br-ex" device. MTU stands for "maximum transmission unit" and indicates the size of the maximum size of a transmission unit (it basically limits the size of packets that are transmitted on an interface).
docker exec openvswitch_vswitchd ip link set dev br-ex mtu 1400  # Ensure correct ssh connection

# This command calls ip-route(8). It adds an entry to the in-kernel routing table. As a result, whenever a packet wants to reach an address in the subnet indicated by $floating_subnet, it will be routed through the $floating_gateway address, which can be reached on device "br-ex".
ip r a "$floating_subnet" via $floating_gateway dev br-ex

# The following command configures NAT packet matching table (via "-t nat") to replace the IP address of the device on the local network where the packet originated with an IP address of the "ens4" device (it is called masking and is achieved via "-j MASQUARADE"). "-A POSTROUTING" means that the whole procedure takes place after the routing decision is done.
iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE

# Connections coming in on "ens4" will be forwarded to "br-ex". The target option "ACCEPT" tells the firewall to let the packet thourgh (another target could be, e.g., "DROP", which would drop the packet).
iptables -A FORWARD -i ens4 -o br-ex -j ACCEPT

# Connections coming in on "br-ex" will be forwarded to "ens4".
iptables -A FORWARD -i br-ex -o ens4 -j ACCEPT

-------

# Notes

# The rule uses the NAT packet matching table and specifies the built-in POSTROUTING chain for NAT on the firewall's external networking device (-o eth0). POSTROUTING allows packets to be altered as they are leaving the firewall's external device. The private IP address of a node is masked with the external IP address of the firewall/gateway. 
# the part above is copy pasted edit please


# XXX: What is -j ACCEPT -> 
# Target options: Once a packet has matched a particular rule, the rule can direct the packet to a number of different targets that decide its fate and, possibly, take additional actions. Each chain has a default target, which is used if none of the rules on that chain match a packet or if none of the rules which match the packet specify a target. 
# ACCEPT — Allows the packet to successfully move on to its destination or another chain.
# -j — Jumps to the specified target when a packet matches a particular rule. Valid targets to use after the -j option include standard options (ACCEPT, DROP, QUEUE, and RETURN) as well as extended options that are available through modules loaded by default with the Red Hat Enterprise Linux iptables RPM package, such as LOG, MARK, and REJECT, among others. Refer to the iptables man page for more information about these and other targets.