Initial Important Findings

The Admin tenant has higher privileges and therefore all the information about the networks is fully visible. T1user1, T1user2 can see the entire network because t1user2net & t1user1net are created by the same tenant that the two users belong. Ext-net & Network1 are shared networks which means every user in the cloud can see them and connect to them. The difference between Admin and other users are the provider information -only visible by Admin- network-type, physical network and segmentation.

Only IP addresses attached to the VMs are linked with Security groups. However, IP addresses assigned to ports in the router, DHCP or belong to an external network (floating IP) are not connected to a Security group.

The commandneutron router-port-list $router_idlists all ports connected to specific router, and five commands were necessary to get the full picture:

• Commandneutron port-listgave the port details,

• Commandneutron port-show$port_id gave the router id that connected to,

• Commandneutron router-list &neutron router-show $router_idgave the router id and name and ports from external network, not the private network,

Command

Gathered Information

Description

neutron port-list

port ID, MAC, fixed IP(

subnet id, IP)

List all the ports in each net-

work created by neutron.

neutron

port-show

$port_id

ID, host, vif_typ, device

ID, device owner, fixed IP

(subnet id, IP), MAC, net-

work ID, tenant.

Using the ID of each port

from the previous command

to show detailed information

about each port.

neutron router-list

ID, name, net id, subnet id,

IP

List all the routers in the

cloud infrastructure

neutron

router-show

$router_id

ID, name, net id, subnet id,

IP, tenant ID

Using the router ID from the

previous command to show

all the details of each router

neutron router-port-list

$router_id

ID, MAC, subnet ID, IP

Using router ID as in the

above command to list all the

ports of each router

neutron floatingip-list

ID, Fixed_ip, floating IP,

port ID (fixed ip port)

List the floating IP provided

by neutron

neutron floatingip-show

$floatip_id

ID, fix IP, float ip, float net

ID, pot id (fixed), router id,

tenant ID

Expand the details of each

floating IP using the Floating

IP ID from the previous com-

mand.

• Command neutron router-port-list $router_id listed router id and port ids linked to (both external and internal).

By matching the router IDs and port IDs we obtained information about which port connected to which router. In other words, no direct command was available to obtain the router name matched with the port IP, hence we used several commands to achieve this.

Theneutron floatingip-listcommand lists only the floating IP address that is associated with VMs IPs, which matches the information in Table A.3 in Appendix A. The floating ID listed before under the commandneutron port-show $port_idwith Device ID for VM ports. Theneutron floatingip shows $floatip_idlisted as the floating ID, and floating IP as the associated VM IP. The port ID of the VM IP is the router ID that contains the floating IP and the router Tenant ID. This means that although the floating IP is associated with VM IP, which is physically located in the Compute Node, the floating IP is located in a router owned by a tenant, which in our case is the same owner of the VM. Logically fixed and floating IPs assigned to the same VM, but not in the same physical location as the router, means keeping the floating IP contained in its namespace in the Network/Controller Node for NAT processing of the external connectivity. At this point we understood where each port was physically resident. The commandneutron port-show $port_idprovided information called binding:host_id which indicated which Node controller | computer the port existed in.

Moreover, the command neutron port-show $port_id provided another information called binding:vif_type. If the result is OVS that means this port belongs to the OVS switch but we do not know which OVS switch it belongs to.

Another useful piece of information is device_owner and its meaning is as follows:

• network:router_interface: network means usually located in the Controller Node, where the NaaS runs, and it is an interface of the router namespace. Most likely this port belongs to a private network within the cloud.

• compute:nova: this in the Compute Node and belongs to an instance with a private ip address on the internal network the instance is connected to.

• network:router_gateway : this in the Controller Node and contains an ip address from the external network which is a router (namespace) gateway the instance uses to connect to the outside.

• network:floatingip: although this port was assigned to the network (Controller Node), the binding host was not specified and it is a floating ip address associated with an instance.

• network:DHCP: this port is in the Controller Node and belongs to a namespace called DHCP. It holds a private network ip address.

One more useful piece of information; as mentioned earlier in §3.3.3, is that the port ID has been used to define the actual port within the infrastructure. As shown in Figure 3.7, each port in the diagram starts with qr-,qg-,tap, qbr,qvo,qvb followed by 11 characters from the port ID.

We gathered the following information about the ports including: • Which node they are located in,

• Which network and subnet they belong to,

• What is their purpose? e.g. Instance interface, router interface, gateway, instance associated floating ip address, DHCP interface.

• Were they created by OVS or not?

However, we do not have information about where they are located in each node and how the node is connected. There is more information gathered that will help us decipher all these tangled concepts to clarify the construction of the DeepDive diagram in the next sections.