diff --git a/docs/latex/report.dvi b/docs/latex/report.dvi
new file mode 100644
index 0000000000000000000000000000000000000000..41c347e696f9568bda8e8800bbeca29c6374f6a9
Binary files /dev/null and b/docs/latex/report.dvi differ
diff --git a/docs/latex/report.pdf b/docs/latex/report.pdf
index 577a2a6ec74aa506d577ca20cb19fec1c3657d2a..70cf1494a84cbdc4c5cd3a28289f9f9f91ef8083 100644
Binary files a/docs/latex/report.pdf and b/docs/latex/report.pdf differ
diff --git a/docs/latex/report.tex b/docs/latex/report.tex
index d59fb4ae00e58fc55f7b19df16d0550472b3ea20..394c99f5a739052f6fa4d896c3af2d0f3e55e893 100644
--- a/docs/latex/report.tex
+++ b/docs/latex/report.tex
@@ -3311,7 +3311,1008 @@ El mechanism driver Open vSwitch tiene soporte para los siguientes tipos de driv
\subsection{Escenario 1}
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/diagrama}
+ \caption{Diagrama de arquitectura para el escenario 1 de Open vSwitch}
+ \label{fig:ovs:scenario1:diagram}
+\end{figure}
+
+\subsubsection{Análisis de componentes}
+
+A continuación se detallan los componentes ubicados en los nodos de cómputo para dar soporte a este escenario. Dado que los componentes son análogos en ambos nodos se describen solamente los del nodo de cómputo 1.\\
+
+\textbf{Nodos de cómputo}\\
+
+Al igual que con el driver Linux Bridge, el hypervisor KVM se encarga de crear una nueva máquina virtual para cada nueva instancia definida.\\
+
+Debido a la utilización de los security group en forma híbrida, las instancias no se conectan directamente al br-int sino que tienen como intermediario un linux bridge llamado \path{brq-xx}. Este último se conecta al integration bridge mediante un veth pair, donde la interfaz asociada al \path{brq-xx} se llama \path{qvb-xx} y la asociada al br-int se llama \path{qvo-xx}. A continuación se muestra la salida de algunos comandos para apreciar lo mencionado:
+Listar las instancias del escenario 1:
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack server list --project "Escenario 1" -f json
+ [
+ {
+ "Status": "ACTIVE",
+ "Name": "instance-2",
+ "Image": "",
+ "ID": "045e7faf-852b-449d-9cec-4bf1f462fa6d",
+ "Flavor": "small",
+ "Networks": "tenant-network-1=192.168.1.102"
+ },
+ {
+ "Status": "ACTIVE",
+ "Name": "instance-1",
+ "Image": "",
+ "ID": "dbda5442-4fb7-4cf6-93a5-be85ede7d8d7",
+ "Flavor": "small",
+ "Networks": "tenant-network-1=192.168.1.101"
+ }
+ ]
+\end{lstlisting}
+
+Con los siguientes comandos se listan y detallan las redes del Escenario 1:
+
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack network list --project "Escenario 1" -f json
+ [
+ {
+ "Subnets": "afc6b545-0507-4392-9618-290af027f1cc",
+ "ID": "4974712b-c7ce-4a89-a4f1-145bc64d4d2b",
+ "Name": "tenant-network-1"
+ }
+ ]
+
+ [root@infra1-utility-container-161eebae ~]# openstack network show 4974712b-c7ce-4a89-a4f1-145bc64d4d2b -f json
+ {
+ "provider:physical_network": null,
+ "ipv6_address_scope": null,
+ "dns_domain": null,
+ "is_vlan_transparent": null,
+ "revision_number": 2,
+ "port_security_enabled": true,
+ "provider:network_type": "vxlan",
+ "id": "4974712b-c7ce-4a89-a4f1-145bc64d4d2b",
+ "router:external": "Internal",
+ "availability_zone_hints": "",
+ "availability_zones": "nova",
+ "segments": null,
+ "name": "tenant-network-1",
+ "location": {
+ "project": {
+ "domain_id": null,
+ "id": "65fc6646a9e943d491b24a71b8d8f19f",
+ "name": null,
+ "domain_name": null
+ },
+ "zone": null,
+ "region_name": "RegionOne",
+ "cloud": ""
+ },
+ "ipv4_address_scope": null,
+ "shared": false,
+ "project_id": "6 5fc6646a9e943d491b24a71b8d8f19f",
+ "status": "ACTIVE",
+ "subnets": "afc6b545-0507-4392-9618-290af027f1cc",
+ "description": "",
+ "tags": "",
+ "updated_at": "2020-01-04T12:15:01Z",
+ "is_default": null,
+ "provider:segmentation_id": 19,
+ "qos_policy_id": null,
+ "admin_state_up": "UP",
+ "created_at": "2020-01-04T12:15:00Z",
+ "mtu": 1450
+ }
+
+\end{lstlisting}
+
+Entre los detalles de la red tenant-network-1 podemos destacar el tipo de red que es VXLAN y el VNI el cual es 19.\\
+Con el ID de la instance-1 se obtienen más detalles sobre la misma:
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack server show dbda5442-4fb7-4cf6-93a5-be85ede7d8d7 -f json
+ {
+ "OS-EXT-STS:task_state": null,
+ "addresses": "tenant-network-1=192.168.1.101",
+ "image": "",
+ "OS-EXT-STS:vm_state": "active",
+ "OS-EXT-SRV-ATTR:instance_name": "instance-0000000b",
+ "OS-SRV-USG:launched_at": "2020-01-04T18:10:08.000000",
+ "flavor": "small (ba063391-5431-456e-ad92-a7e9fe1e8c82)",
+ "id": "dbda5442-4fb7-4cf6-93a5-be85ede7d8d7",
+ "security_groups": "name='default'",
+ "volumes_attached": "id='74748f6c-ca5a-4f86-a683-f02a61533b53'",
+ "user_id": "d844634b4f8942cc85e2cf88c8d1f096",
+ "OS-DCF:diskConfig": "AUTO",
+ "accessIPv4": "",
+ "accessIPv6": "",
+ "progress": 0,
+ "OS-EXT-STS:power_state": "Running",
+ "OS-EXT-AZ:availability_zone": "nova",
+ "config_drive": "",
+ "status": "ACTIVE",
+ "updated": "2020-01-04T18:10:07Z",
+ "hostId": "b91cc2c2ec44a5b4231f42a8de608b0c26430838aa0a7f49ce32aa62",
+ "OS-EXT-SRV-ATTR:host": "compute1",
+ "OS-SRV-USG:terminated_at": null,
+ "key_name": null,
+ "properties": "",
+ "project_id": "65fc6646a9e943d491b24a71b8d8f19f",
+ "OS-EXT-SRV-ATTR:hypervisor_hostname": "compute1.openstack.local",
+ "name": "instance-1",
+ "created": "2020-01-04T18:09:54Z"
+ }
+\end{lstlisting}
+
+A partir de esta salida se puede ver que la instancia está alojada en el nodo de cómputo 1 y que el nombre de la misma en el hypervisor es \path{instance-0000000b}.
+Con este último dato es posible obtener el nombre de la interfaz tap creada por KVM para dicha instancia:
+
+\begin{lstlisting}
+ [root@compute1 ~]# virsh domiflist instance-0000000b
+ Interface Type Source Model MAC
+ -------------------------------------------------------
+ tap570ebdbc-45 bridge qbr570ebdbc-45 virtio fa:16:3e:be:b9:2e
+\end{lstlisting}
+
+Con esta salida se obtiene el identificador “xx” mencionado previamente, que se repite en los veth pairs y el bridge creados para la instancia. En este caso es \path{“570ebdbc-45”}.\\
+
+Con el siguiente comando se puede ver que efectivamente el bridge tiene asociadas dos interfaces, la tap encargada de conectarse con la instancia y la qvb encargada de conectarse con el br-int.\\
+
+\begin{lstlisting}
+ [root@compute1 ~]# brctl show qbr570ebdbc-45
+ bridge name bridge id STP enabled interfaces
+ qbr570ebdbc-45 8000.e6e8fe347d4a no qvb570ebdbc-45
+ tap570ebdbc-45
+\end{lstlisting}
+
+Con el siguiente comando se pueden ver las interfaces conectadas a todos los switches virtuales de OVS.
+
+\begin{lstlisting}
+ [root@compute1 ~]# ovs-vsctl show
+eabf27d2-60fe-4b0c-9fb0-1adfab96ffa3
+ Manager "ptcp:6640:127.0.0.1"
+ is_connected: true
+ Bridge br-int
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port int-br-provider
+ Interface int-br-provider
+ type: patch
+ options: {peer=phy-br-provider}
+ Port "qvo570ebdbc-45"
+ tag: 6
+ Interface "qvo570ebdbc-45"
+ Port patch-tun
+ Interface patch-tun
+ type: patch
+ options: {peer=patch-int}
+ Port br-int
+ Interface br-int
+ type: internal
+ Bridge br-tun
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port patch-int
+ Interface patch-int
+ type: patch
+ options: {peer=patch-tun}
+ Port "vxlan-0a001f16"
+ Interface "vxlan-0a001f16"
+ type: vxlan
+ options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="10.0.31.12", out_key=flow, remote_ip="10.0.31.22"}
+ Port "vxlan-0a001f0b"
+ Interface "vxlan-0a001f0b"
+ type: vxlan
+ options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="10.0.31.12", out_key=flow, remote_ip="10.0.31.11"}
+ Port br-tun
+ Interface br-tun
+ type: internal
+ Bridge br-provider
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port phy-br-provider
+ Interface phy-br-provider
+ type: patch
+ options: {peer=int-br-provider}
+ Port br-provider
+ Interface br-provider
+ type: internal
+ Port br-vlan
+ Interface br-vlan
+ ovs_version: "2.11.0"
+\end{lstlisting}
+
+A las interfaces qvo se les asigna un tag interno que luego en el bridge provider o túnel será utilizado para realizar el mapeo que corresponda a el tipo de red seleccionado. La interfaz que brinda conectividad a la instancia 1 es \path{qvo570ebdbc-45} con el tag interno 6.
+
+Como la red tenant creada es de tipo VXLAN este escenario utiliza el bridge dedicado para las redes de overlay llamado br-tun, conectado al integration bridge mediante el patch port “patch-int”. En la entrada de options se indica el nombre del patch port par en el otro bridge. Adicionalmente este bridge tiene dos puertos utilizados para crear la red mesh de VXLAN entre el nodo de cómputo en cuestión, el otro nodo de cómputo y el nodo de red. Estos son \path{vxlan-0a001f16} y \path{vxlan-0a001f0b}.
+
+\subsubsection{Análisis de tráfico}
+
+En este primer ejemplo se analiza el tráfico generado cuando la instancia 1 intenta comunicarse con la instancia 2, asumiendo que las mismas aún no conocen las direcciones MAC destino.
+
+\subparagraph{Paso 1}
+La instancia 1 envía el paquete ICMP echo request hacia la instancia 2. Para esto determina que se encuentra directamente conectada con el host destino y por lo tanto no necesita ningún salto intermedio.
+
+\subparagraph{Paso 2}
+La instancia 1 debe obtener la MAC de la instancia 2, como esta no es conocida se dispara el protocolo ARP. A continuación se detalla cómo se lleva a cabo el protocolo de resolución de direcciones entre las instancias virtuales.
+
+\begin{enumerate}
+
+\item La instancia 1 envía una trama ARP request preguntando por la IP 192.168.1.102 (1). Dicha trama es enviada hacia el linux bridge asociado a través del veth pair (2).
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/tap-instance1-arp-request}
+ \caption{Paquete ARP request capturado en la interfaz eth0 de la instancia 1}
+ \label{fig:ovs:scenario1:paq-arp-eth0-inst1}
+ \end{figure}
+
+\item El bridge recibe el pedido ARP (3) y lo reenvía a través del puerto qvb (4) hacia el integration bridge de OVS.
+
+\item Este último recibe el pedido por el puerto qvo (5), el cual etiqueta el paquete con el VLAN ID 6.
+
+\item Luego el bridge lo procesa siguiendo las reglas de OpenFlow, mostradas a continuación. A efectos de mejorar la legibilidad de las mismas se eliminan los campos: duration, cookies, n\_packets y n\_bytes (en las siguientes salidas del mismo comando se realizará el mismo filtro).
+
+\begin{lstlisting}
+ [root@compute1 ~]# ovs-ofctl dump-flows br-int --rsort
+ 1. table=0,priority=65535,vlan_tci=0x0fff/0x1fff actions=drop
+ 2. table=0,priority=10,icmp6,in_port="qvo570ebdbc-45",icmp_type=136 actions=resubmit(,24)
+ 3. table=0,priority=10,arp,in_port="qvo570ebdbc-45" actions=resubmit(,24)
+ 4. table=0,priority=9,in_port="qvo570ebdbc-45" actions=resubmit(,25)
+ 5. table=60,priority=3 actions=NORMAL
+ 6. table=0,priority=2,in_port="int-br-provider" actions=drop
+ 7. table=24,priority=2,icmp6,in_port="qvo570ebdbc-45",icmp_type=136,nd_target=fe80::f816:3eff:febe:b92e actions=resubmit(,60)
+ 8. table=24,priority=2,arp,in_port="qvo570ebdbc-45",arp_spa=192.168.1.101 actions=resubmit(,25)
+ 9. table=25,priority=2,in_port="qvo570ebdbc-45",dl_src=fa:16:3e:be:b9:2e actions=resubmit(,60)
+ 10. table=0,priority=0 actions=resubmit(,60)
+ 11. table=23,priority=0 actions=drop
+ 12. table=24,priority=0 actions=drop
+\end{lstlisting}
+La primer regla que coincide con el paquete recibido en el \path{br-int} es la número 3 la cual establece que los paquetes ARP recibidos en el puerto \path{qvo570ebdbc-45} se envíen a la tabla 24. Luego las reglas 8 y 9 son utilizadas para evitar un spoofing de ARP, en donde se verifica que la dirección IP y MAC de origen del paquete ARP, coincidan con las de la instancia 1. Finalmente el paquete es procesado por la tabla 60 en la regla 5 donde se toma la acción NORMAL indicando a Open vSwitch que debe actual como un switch en modo de aprendizaje generando que el tráfico sea enviado a todos los puertos con la excepción del entrante.
+
+\item Luego del procesamiento el paquete ARP request llega al bridge \path{br-tun} mediante el patch port \path{patch-int} (6).
+
+\item En dicho bridge se aplican nuevamente reglas de OpenFlow, listadas a continuación.
+
+\begin{lstlisting}
+ [root@compute1 ~]# ovs-ofctl dump-flows br-tun --rsort
+ 1. table=0,priority=1,in_port="patch-int" actions=resubmit(,2)
+ 2. table=0,priority=1,in_port="vxlan-0a001f0b" actions=resubmit(,4)
+ 3. table=0,priority=1,in_port="vxlan-0a001f16" actions=resubmit(,4)
+ 4. table=4,priority=1,tun_id=0x13 actions=mod_vlan_vid:6,resubmit(,10)
+ 5. table=10,priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xb8003f26cd0d7430,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:OXM_OF_IN_PORT[]),output:"patch-int"
+ 6. table=22,priority=1,dl_vlan=6 actions=strip_vlan,load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f0b",output:"vxlan-0a001f16"
+ 7. table=0,priority=0 actions=drop
+ 8. table=2,priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
+ 9. table=2,priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
+ 10. table=3,priority=0 actions=drop
+ 11. table=4,priority=0 actions=drop
+ 12. table=6,priority=0 actions=drop
+ 13. table=20,priority=0 actions=resubmit(,22)
+ 14. table=22,priority=0 actions=drop
+\end{lstlisting}
+
+
+La primer regla que coincide es la 1 en donde se envía el procesamiento a la tabla 2. La regla 8 no coincide debido a que no se conoce la MAC destino, entrando en la regla 9 donde se envía a la tabla 22. Luego en la regla 6 se verifica que coincida el VLAN ID del paquete con el asignado al manejo interno (\path{dl_vlan=6}). Luego se elimina el VLAN ID (strip\_vlan), y se agrega el VNI 19 en este caso (\path{load:0x13->NXM_NX_TUN_ID[]}), para finalmente enviar el paquete por todos los puertos vxlan (7) dado que no conoce que VTEP alberga a la instancia por la que se está consultando.
+
+\item De esta forma el paquete ARP alcanza la infraestructura subyacente que brinda soporte al tráfico VXLAN. En primer lugar pasa por el Linux Bridge br-vxlan, el cual envía el paquete a la subinterfaz \path{eth2.31} (8).
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/br-vxlan-arp-request}
+ \caption{ARP request encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cómputo 1}
+ \label{fig:ovs:scenario1arp-req-br-vxlan-comp1}
+ \end{figure}
+
+\item En la subinterfaz el paquete es etiquetado con el tag 31 y enviado hacia el bridge virbr6 (9) (infraestructura física) a través de eth2.
+
+\item Al llegar al nodo de cómputo 2 se realiza el proceso inverso de los puntos 7 y 8. Alcanzando así la solicitud ARP al bridge br-tun (10) del nodo de cómputo 2.
+
+\item En dicho bridge se aplican nuevamente reglas de Open Flow, listadas a continuación.
+
+\begin{lstlisting}
+ [root@compute2 ~]# ovs-ofctl dump-flows br-tun --rsort
+ 1. table=0,priority=1,in_port="patch-int" actions=resubmit(,2)
+ 2. table=0,priority=1,in_port="vxlan-0a001f0b" actions=resubmit(,4)
+ 3. table=0,priority=1,in_port="vxlan-0a001f0c" actions=resubmit(,4)
+ 4. table=4,priority=1,tun_id=0x13 actions=mod_vlan_vid:3,resubmit(,10)
+ 5. table=10,priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0x3f05eaa5b010cd3f,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:OXM_OF_IN_PORT[]),output:"patch-int"
+ 6. table=22,priority=1,dl_vlan=3 actions=strip_vlan,load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f0b",output:"vxlan-0a001f0c"
+ 7. table=0,priority=0 actions=drop
+ 8. table=2,priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
+ 9. table=2,priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
+ 10. table=3,priority=0 actions=drop
+ 11. table=4,priority=0 actions=drop
+ 12. table=6,priority=0 actions=drop
+ 13. table=20,priority=0 actions=resubmit(,22)
+ 14. table=22,priority=0 actions=drop
+\end{lstlisting}
+
+Con el comando \path{ovs-vsctl} show se puede observar que el puerto “\path{vxlan-0a001f0c}” se corresponde con el nodo de cómputo 1, por lo tanto la primer regla que coincide es la 3, en donde se envía a la tabla 4. En la regla 4 se verifica que el VNI del paquete sea 19, se modifica el VLAN ID al asignado por OVS para esta red tenant en el nodo de cómputo 2 y se envía a la tabla 10. El tag interno asignado a una red virtual puede ser diferente en cada nodo físico, en este caso el tag es 3.
+La regla 5 a partir del paquete recibido crea una nueva regla, en donde las precondiciones serán que el VLAN ID coincida con el tag interno asignado (\path{NXM_OF_VLAN_TCI[0..11]}) y la MAC destino sea igual a la MAC del paquete recibido (\path{NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[]}) y las acciones serán cargar el VLAN ID con 0 (\path{load:0->NXM_OF_VLAN_TCI[]}) y el VNI de la red virtual (\path{load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[]}) además de enviar el paquete por el puerto correspondiente (\path{output:OXM_OF_IN_PORT[]}). Luego de crear la regla se envía el paquete hacia el br-int por el puerto “\path{patch-int}”
+
+\item Nuevamente en el bridge \path{br-int} se procesa el paquete de acuerdo a las reglas de OpenFlow listadas a continuación.
+
+\begin{lstlisting}
+ [root@compute2 ~]# ovs-ofctl dump-flows br-int --rsort
+ 1. table=0,priority=65535,vlan_tci=0x0fff/0x1fff actions=drop
+ 2. table=0,priority=10,icmp6,in_port="qvob677998f-e6",icmp_type=136 actions=resubmit(,24)
+ 3. table=0,priority=10,arp,in_port="qvob677998f-e6" actions=resubmit(,24)
+ 4. table=0,priority=9,in_port="qvob677998f-e6" actions=resubmit(,25)
+ 5. table=60,priority=3 actions=NORMAL
+ 6. table=0,priority=2,in_port="int-br-provider" actions=drop
+ 7. table=24,priority=2,icmp6,in_port="qvob677998f-e6",icmp_type=136,nd_target=fe80::f816:3eff:fe92:57e4 actions=resubmit(,60)
+ 8. table=24,priority=2,arp,in_port="qvob677998f-e6",arp_spa=192.168.1.102 actions=resubmit(,25)
+ 9. table=25,priority=2,in_port="qvob677998f-e6",dl_src=fa:16:3e:92:57:e4 actions=resubmit(,60)
+ 10. table=0,priority=0 actions=resubmit(,60)
+ 11. table=23,priority=0 actions=drop
+ 12. table=24,priority=0 actions=drop
+\end{lstlisting}
+
+La primera regla que coincide es la 10 en donde envía el procesamiento a la tabla 60. En la regla 5 como no tiene ninguna precondición se procesa ejecutando la acción NORMAL. De esta forma se envía por todos los puertos qvo, en particular por el puerto “\path{qvob677998f-e6}” (12) hacia el Linux Bridge asociado a la instancia 2. Previo al reenvío, el puerto qvo se encarga de quitar el tag de VLAN 3.
+
+\item En el linux bridge se aplican las reglas del grupo de seguridad y se envía hacia la instancia 2 mediante el veth pair (13).
+
+\item La instancia 2 recibirá la trama, y al verificar que se está consultando por su IP responderá a la instancia 1 con un ARP reply directo a su MAC. Esta respuesta es enviada hacia el linux bridge asociado a través del veth pair (13).
+
+\item El bridge recibe el pedido ARP reply y lo reenvía a través del puerto qvb hacia el integration bridge de OVS.
+
+\item Este último recibe el pedido por el puerto qvo (12), el cual etiqueta el paquete con el VLAN ID 3.
+
+\item Luego el bridge lo procesa siguiendo las mismas reglas de OpenFlow del paso 11. El procesamiento es análogo al descrito en el paso 4, realizando una verificación anti spoofing y reenviando el paquete hacia el \path{br-tun}.
+
+\item El \path{br-tun} recibe el paquete por el \path{patch-int} y lo procesa con las siguientes reglas de OpenFlow, incluyendo la sexta regla aprendida en el paso 10.
+
+\begin{lstlisting}
+ [root@compute2 ~]# ovs-ofctl dump-flows br-tun --rsort
+ 1. table=0,priority=1,in_port="patch-int" actions=resubmit(,2)
+ 2. table=0,priority=1,in_port="vxlan-0a001f0b" actions=resubmit(,4)
+ 3. table=0,priority=1,in_port="vxlan-0a001f0c" actions=resubmit(,4)
+ 4. table=4,priority=1,tun_id=0x13 actions=mod_vlan_vid:3,resubmit(,10)
+ 5. table=10,priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0x3f05eaa5b010cd3f,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:OXM_OF_IN_PORT[]),output:"patch-int"
+ 6. table=20,hard_timeout=300, priority=1,vlan_tci=0x0003/0x0fff,dl_dst=fa:16:3e:be:b9:2e actions=load:0->NXM_OF_VLAN_TCI[],load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f0c"
+ 7. table=22,priority=1,dl_vlan=3 actions=strip_vlan,load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f0b",output:"vxlan-0a001f0c"
+ 8. table=0,priority=0 actions=drop
+ 9. table=2,priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
+ 10. table=2,priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
+ 11. table=3,priority=0 actions=drop
+ 12. table=4,priority=0 actions=drop
+ 13. table=6,priority=0 actions=drop
+ 14. table=20,priority=0 actions=resubmit(,22)
+ 15. table=22,priority=0 actions=drop
+\end{lstlisting}
+
+De esta forma la regla 1 es la primera que coincide y se envía a la tabla 2. En este caso como la MAC destino no es de broadcast la regla 9 procesa y envía a la tabla 20. Finalmente la nueva regla se encarga en primer lugar de verificar que el VLAN ID coincida con el tag interno (en este caso 3) y la MAC destino se corresponda con la asignada a la instancia 1, para luego modificar el VLAN ID, el VNI y enviar el paquete por el puerto vxlan asociado al nodo de cómputo 1.
+
+\item El envío del paquete a través de la infraestructura física hasta el \path{br-tun} del nodo de cómputo 1 es análogo a lo detallado en los pasos 7, 8 y 9.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/br-vxlan-arp-reply}
+ \caption{ARP reply encapsulado en VXLAN capturado en la interfaz br-vxlan del nodo de cómputo 1}
+ \label{fig:ovs:scenario1-arp-reply-br-vxlan-comp2}
+ \end{figure}
+
+\item Al alcanzar al bridge \path{br-tun} el paquete es procesado por las reglas de OpenFlow de forma análoga al paso 10. Es aquí donde el bridge aprende la siguiente regla y se reenvía el paquete al bridge de integración.
+\path{table=20,hard_timeout=300, priority=1,vlan_tci=0x0006/0x0fff,dl_dst=fa:16:3e:92:57:e4 actions=load:0->NXM_OF_VLAN_TCI[],load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f16"}
+
+\item Ya en el \path{br-int} el recorrido para alcanzar la instancia 1 es análogo a los pasos 11 y 12.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/tap-instance1-arp-reply}
+ \caption{Paquete ARP reply capturado en la interfaz eth0 de la instancia 1}
+ \label{fig:ovs:scenario1-arp-reply-tap-inst1}
+ \end{figure}
+
+\item De ahora en más, mientras se mantengan actualizadas las tablas de resolución ARP de las instancias y las reglas OpenFlow, la comunicación entre ambas máquinas virtuales será siempre en forma directa, análogamente a lo detallado para el ARP reply.
+
+\end{enumerate}
+\subparagraph{Paso 3}
+Ahora que se conoce la dirección MAC, la instancia 1 retoma el envío del paquete ICMP hacia la instancia 2.
+
+\begin{enumerate}
+\item El mensaje es enviado por el veth pair (2) hacia el linux bridge.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/tap-instance1-icmp-request}
+ \caption{Paquete ICMP request capturado en la interfaz eth0 de la instancia 1}
+ \label{fig:ovs:scenario1-icmp-req-tap-inst1}
+ \end{figure}
+
+
+\item En el bridge se aplican las reglas del grupo de seguridad reenvía el paquete a través del puerto qvb (4) hacia el integration bridge de OVS.
+
+\item Este último recibe el pedido por el puerto qvo (5), el cual etiqueta el paquete con el VLAN ID 6.
+
+\item Luego el bridge lo procesa siguiendo las mismas reglas de OpenFlow del paso 2.4. La primer regla que coincide con el paquete recibido en el \path{br-int} es la número 4 recibidos por el puerto \path{qvo570ebdbc-45} se envíen a la tabla 25. Luego la regla 9 es utilizada para evitar spoofing, en donde se verifica que la dirección MAC de origen del paquete coincida con la de la instancia 1. Finalmente el paquete es procesado por la tabla 60 en la regla 5 donde se toma la acción NORMAL, enviando el paquete al \path{br-tun}.
+
+\item Una vez en el bridge de tunelización, se aplican las mismas reglas de OpenFlow del paso 2.6 incluyendo la aprendida en el paso 2.19.
+
+\begin{lstlisting}
+ [root@compute1 ~]# ovs-ofctl dump-flows br-tun --rsort
+ 1. table=0,priority=1,in_port="patch-int" actions=resubmit(,2)
+ 2. table=0,priority=1,in_port="vxlan-0a001f0b" actions=resubmit(,4)
+ 3. table=0,priority=1,in_port="vxlan-0a001f16" actions=resubmit(,4)
+ 4. table=4,priority=1,tun_id=0x13 actions=mod_vlan_vid:6,resubmit(,10)
+ 5. table=10,priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xb8003f26cd0d7430,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:OXM_OF_IN_PORT[]),output:"patch-int"
+ 6. table=20,hard_timeout=300, priority=1,vlan_tci=0x0006/0x0fff,dl_dst=fa:16:3e:92:57:e4 actions=load:0->NXM_OF_VLAN_TCI[],load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f16"
+ 7. table=22,priority=1,dl_vlan=6 actions=strip_vlan,load:0x13->NXM_NX_TUN_ID[],output:"vxlan-0a001f0b",output:"vxlan-0a001f16"
+ 8. table=0,priority=0 actions=drop
+ 9. table=2,priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
+ 10. table=2,priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
+ 11. table=3,priority=0 actions=drop
+ 12. table=4,priority=0 actions=drop
+ 13. table=6,priority=0 actions=drop
+ 14. table=20,priority=0 actions=resubmit(,22)
+ 15. table=22,priority=0 actions=drop
+\end{lstlisting}
+
+El procesamiento de las reglas es análogo al detallado en el paso 2.17 pero con sentido opuesto. De esta forma mediante el port “\path{vxlan-0a001f16}” se alcanza al bridge \path{br-vxlan} (8).
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario1/br-vxlan-icmp-request}
+ \caption{ Paquete ICMP request encapsulado en VXLAN 19 capturado en el bridge br-vxlan en el nodo de cómputo 1}
+ \label{fig:ovs:scenario1-icmp-req-br-vxlan-comp1}
+ \end{figure}
+
+\item El procesamiento desde este bridge hasta la instancia 2 es análogo a los pasos 2.7 - 2.12 con la salvedad que es un paquete ICMP request en lugar de un ARP request.
+
+\end{enumerate}
+
+\subparagraph{Paso 4}
+El procedimiento para la respuesta con el paquete ICMP reply es similar al descrito pero en sentido contrario.
+
+\subsection{Escenario 2}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario2/diagrama}
+ \caption{Diagrama de arquitectura para el escenario 2 de Open vSwitch}
+ \label{fig:ovs:scenario2:diagram}
+\end{figure}
+
+\subsubsection{Análisis de componentes}
+
+A continuación se detallan los componentes virtuales requeridos para instanciar el escenario propuesto. Salvo diferencias en los identificadores, los componentes que son creados en los nodos de cómputo son iguales a los del escenario 1, con lo cual no es relevante volver a detallarlos. Por el contrario, sí se detallan los nuevos componentes en el nodo de infraestructura encargados de interconectar las redes tenant.
+
+\textbf{Nodos de infraestructura / red}\\
+En este escenario las redes instancias por Neutron son:
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack network list --project "Escenario 2" -f json
+ [
+ {
+ "Subnets": "c9e2ffc8-3802-4881-8367-a234483bca33",
+ "ID": "c2f9aefe-fde9-452b-9cce-9071268129c6",
+ "Name": "tenant-network-1"
+ },
+ {
+ "Subnets": "13c29613-fa50-4f97-8751-5dad3b7703cb",
+ "ID": "ed653eb8-9e23-47df-a73e-62e15263c5cf",
+ "Name": "tenant-network-2"
+ }
+ ]
+\end{lstlisting}
+
+Al igual que en el plugin Linux Bridge, la comunicación entre dos subredes diferentes requiere de un router como intermediario, implementado como un network namespace. El siguiente comando brinda una lista de los routers del escenario.
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack router list --project "Escenario 2" -f json
+ [
+ {
+ "Status": "ACTIVE",
+ "Name": "router-X",
+ "Project": "e7e830fdcaeb49e3a947104a39440261",
+ "State": "UP",
+ "HA": false,
+ "ID": "9ead41f9-0ab5-47a7-a333-55065b1e7372"
+ }
+ ]
+\end{lstlisting}
+
+El namespace asociado al router tiene tantas interfaces como puertos tenga configurados, en este caso son dos debido a que se están conectando dos redes tenant. Con el siguiente comando se listan las interfaces mencionadas:
+
+\begin{lstlisting}
+ [root@infra1 ~]# ip netns exec qrouter-9ead41f9-0ab5-47a7-a333-55065b1e7372 ip a
+ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+ 150: qr-b39964a8-f9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:5d:84:93 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.1.1/24 brd 192.168.1.255 scope global qr-b39964a8-f9
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fe5d:8493/64 scope link
+ valid_lft forever preferred_lft forever
+ 151: qr-b6abf816-c0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:50:de:59 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.2.1/24 brd 192.168.2.255 scope global qr-b6abf816-c0
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fe50:de59/64 scope link
+ valid_lft forever preferred_lft forever
+\end{lstlisting}
+
+Para que el router se encuentre asociado a ambas redes, es necesario que las mismas se encuentren instanciadas en el nodo de red. Esto se logra de la misma forma que en los nodos de cómputo, instanciado los tres bridges de OVS. A su vez, las interfaces qr del router pertenecen al integration bridge con el fin de comunicar el namespace con Open vSwitch. Esto se puede observar con la salida del siguiente comando, donde dentro de las interfaces del \path{br-int} también se encuentran las tap asociadas a los servicios de \path{DHCP}.
+
+\begin{lstlisting}
+ [root@infra1 ~]# ovs-vsctl show 952599e3-c14d-4e8f-a02a-1c9ecc3db874
+ Manager "ptcp:6640:127.0.0.1"
+ is_connected: true
+ Bridge br-provider
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port phy-br-provider
+ Interface phy-br-provider
+ type: patch
+ options: {peer=int-br-provider}
+ Port br-provider
+ Interface br-provider
+ type: internal
+ Port br-vlan
+ Interface br-vlan
+ Bridge br-tun
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port "vxlan-0a001f0c"
+ Interface "vxlan-0a001f0c"
+ type: vxlan
+ options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="10.0.31.11", out_key=flow, remote_ip="10.0.31.12"}
+ Port patch-int
+ Interface patch-int
+ type: patch
+ options: {peer=patch-tun}
+ Port "vxlan-0a001f16"
+ Interface "vxlan-0a001f16"
+ type: vxlan
+ options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="10.0.31.11", out_key=flow, remote_ip="10.0.31.22"}
+ Port br-tun
+ Interface br-tun
+ type: internal
+ Bridge br-int
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port "tape888d441-79"
+ tag: 2
+ Interface "tape888d441-79"
+ type: internal
+ Port "tapa62a5790-6b"
+ tag: 3
+ Interface "tapa62a5790-6b"
+ type: internal
+ Port patch-tun
+ Interface patch-tun
+ type: patch
+ options: {peer=patch-int}
+ Port "qr-b39964a8-f9"
+ tag: 2
+ Interface "qr-b39964a8-f9"
+ type: internal
+ Port int-br-provider
+ Interface int-br-provider
+ type: patch
+ options: {peer=phy-br-provider}
+ Port br-int
+ Interface br-int
+ type: internal
+ Port "qr-b6abf816-c0"
+ tag: 3
+ Interface "qr-b6abf816-c0"
+ type: internal
+ Port "tap6f197381-b4"
+ tag: 5
+ Interface "tap6f197381-b4"
+ type: internal
+ ovs_version: "2.11.0"
+\end{lstlisting}
+
+\subsubsection{Análisis de tráfico}
+Como se describe en el escenario, se analiza el tráfico generado en la comunicación de la instancia 1 ubicada en el nodo de cómputo 1 con la instancia 2 alojada en el nodo de cómputo 2. Se supone que las instancias no tienen cargadas las tablas ARP y las reglas de OpenFlow para los destinos específicos no se encuentran cargadas.
+
+\subparagraph{Paso 1}
+La instancia 1 envía el paquete ICMP echo request hacia la instancia 2. Para esto determina que se encuentran en subredes diferentes y por lo tanto busca el siguiente salto en la tabla de ruteo.
+
+\begin{lstlisting}
+ $ ip r
+ default via 192.168.1.1 dev eth0
+ 169.254.169.254 via 192.168.1.50 dev eth0
+ 192.168.1.0/24 dev eth0 src 192.168.1.101
+\end{lstlisting}
+
+En la salida se observa que la IP del default gateway es la 192.168.1.1.
+
+\subparagraph{Paso 2}
+La instancia 1 debe obtener la MAC asociada a la IP del router X, como esta no es conocida se dispara el protocolo ARP. Este proceso no se explica dado que es análogo al paso 2 del escenario 1.
+
+\subparagraph{Paso 3}
+Ahora que se conoce la dirección MAC, la instancia 1 retoma el envío del paquete ICMP hacia la instancia 2 a través del router X. El proceso desde que el paquete parte de la instancia 1 hasta el router es análogo al explicado en el paso 3 del escenario 1.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario2/br-vxlan-compute1-icmp-request}
+ \caption{Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cómputo 1}
+ \label{fig:ovs:paq-icmp-req-br-vxlan-comp1:diagram}
+\end{figure}
+
+\subparagraph{Paso 4}
+
+Cuando el paquete llega al router se envía hacia la red tenant-network-2 de acuerdo a la tabla de ruteo del namespace:
+
+\begin{lstlisting}
+ [root@infra1 ~]# ip netns exec qrouter-9ead41f9-0ab5-47a7-a333-55065b1e7372 ip r
+ 192.168.1.0/24 dev qr-b39964a8-f9 proto kernel scope link src 192.168.1.1
+ 192.168.2.0/24 dev qr-b6abf816-c0 proto kernel scope link src 192.168.2.1
+\end{lstlisting}
+
+Como se encuentra directamente conectado con el host destino, no necesita ningún salto intermedio.
+\subparagraph{Paso 5}
+El router X debe obtener la MAC de la instancia 2, como hasta el momento esta no es conocida se dispara el protocolo ARP. Este proceso no se explica dado que es análogo a los descubrimientos detallados anteriormente.
+
+\subparagraph{Paso 6}
+
+Ahora que se conoce la dirección MAC, el router X retoma el envío del paquete ICMP hacia la instancia 2. El proceso desde que el paquete parte del router hasta su destino es análogo al explicado en el paso 3 del escenario 1.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario2/br-vxlan-compute2-icmp-request}
+ \caption{Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cómputo 2}
+ \label{fig:ovs:paq-icmp-req-br-vxlan-comp2:diagram}
+\end{figure}
+
+\subparagraph{Paso 7}
+El procedimiento para la respuesta con el paquete ICMP reply es similar al descrito pero en sentido contrario.
+
+\subsection{Escenario 3}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario3/diagrama}
+ \caption{Diagrama de arquitectura para el escenario 3 de Open vSwitch}
+ \label{fig:ovs:scenario3:diagram}
+\end{figure}
+
+\subsubsection{Análisis de componentes}
+A continuación se detallan los componentes virtuales requeridos para instanciar el escenario propuesto. Los componentes relacionados a la red tenant en el nodo de cómputo y en el nodo de infraestructura son análogos a las escenarios 1 y 2. Los componentes a analizar son los empleados para dar soporte a la red provider. \\
+
+\textbf{Nodos de infraestructura / red}\\
+En este escenario las redes tenant instancias por Neutron son:
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack network list --project "Escenario 3" -f json
+ [
+ {
+ "Subnets": "af7d8f67-8d00-40f9-ba9e-b38224e7d7ee",
+ "ID": "94b2baa9-ed72-409b-a74d-fd47c0b50d19",
+ "Name": "tenant-network-1"
+ }
+ ]
+\end{lstlisting}
+
+Mientras que la red externa utilizada es:
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack network list --external -f json
+ [
+ {
+ "Subnets": "905e5c2f-14b9-40d8-9647-4fb0680aca22",
+ "ID": "0610e256-5b34-4479-95a4-452519c10234",
+ "Name": "provider-vlan"
+ }
+ ]
+\end{lstlisting}
+
+Al igual que en el escenario anterior, la comunicación entre dos subredes diferentes requiere de un router como intermediario, implementado como un network namespace. Con el siguiente comando se obtiene el router del escenario.
+
+\begin{lstlisting}
+ [root@infra1-utility-container-161eebae ~]# openstack router list --project "Escenario 3" -f json
+ [
+ {
+ "Status": "ACTIVE",
+ "Name": "router-Y",
+ "Project": "4909f8000a82406b9dd34d647e23f03c",
+ "State": "UP",
+ "HA": false,
+ "ID": "93d73f33-21f9-49f2-920e-0af9917fdf12"
+ }
+ ]
+\end{lstlisting}
+
+En este escenario el namespace asociado al router tiene dos interfaces, una asociada a la red tenant y otra asociada a la red provider. Como ya se analizó con el plugin Linux Bridge, el nombre de las interfaces asociadas a una red tenant tienen el formato \path{qr-<id_port>} mientras que las interfaces asociadas a una red provider tienen el formato \path{qg-<id_port>}.
+
+\begin{lstlisting}
+ [root@infra1 ~]# ip netns exec qrouter-93d73f33-21f9-49f2-920e-0af9917fdf12 ip a
+ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+ 164: qg-1559b31f-5d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:31:8a:5a brd ff:ff:ff:ff:ff:ff
+ inet 10.0.100.114/24 brd 10.0.100.255 scope global qg-1559b31f-5d
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fe31:8a5a/64 scope link
+ valid_lft forever preferred_lft forever
+ 165: qr-e85900b1-10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:60:4f:63 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.1.1/24 brd 192.168.1.255 scope global qr-e85900b1-10
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fe60:4f63/64 scope link
+ valid_lft forever preferred_lft forever
+\end{lstlisting}
+
+La red tenant sigue siendo implementada mediante OVS por los bridges \path{br-int} y \path{br-tun} al igual que en los escenarios anteriores. Por otro lado, para instanciar la red provider con el vlan id 100 se requiere de dos estructuras:
+
+\begin{itemize}
+
+\item La primera es la arquitectura subyacente creada por el administrador, la cual es idéntica a la detallada en el escenario 3 del plugin Linux Bridge.
+
+\item La segunda estructura consiste en un nuevo bridge provider de OVS que brinda conectividad con la red VLAN de la infraestructura física. En este caso concreto se nombra \path{br-provider} y tiene asociadas las siguientes interfaces:
+
+\begin{lstlisting}
+ Bridge br-provider
+ Controller "tcp:127.0.0.1:6633"
+ is_connected: true
+ fail_mode: secure
+ Port phy-br-provider
+ Interface phy-br-provider
+ type: patch
+ options: {peer=int-br-provider}
+ Port br-provider
+ Interface br-provider
+ type: internal
+ Port br-vlan
+ Interface br-vlan
+\end{lstlisting}
+
+Dentro de estas interfaces cabe destacar el patch port compuesto por los pares (\path{phy-br-provider} y \path{int-br-provider}) el cual brinda conectividad con el \path{br-int} y la interfaz \path{br-vlan} que es la interfaz física del nodo de red dedicada a las redes provider VLAN.
+\end{itemize}
+
+\subsubsection{Análisis de tráfico}
+El objetivo de este escenario es analizar el tráfico generado en la comunicación entre la instancia 1 y un host externo al manejo de Openstack. En este caso se considera al router de la infraestructura física como host externo debido a que si la instancia logra comunicarse con el mismo, entonces tendrá acceso a cualquier host que este alcance.
+
+\subparagraph{Paso 1}
+La instancia 1 envía el paquete ICMP echo request hacia el router físico. Para esto determina que se encuentran en subredes diferentes y por lo tanto busca el siguiente salto en la tabla de ruteo
+
+\begin{lstlisting}
+ $ ip r
+ default via 192.168.1.1 dev eth0
+ 169.254.169.254 via 192.168.1.1 dev eth0
+ 192.168.1.0/24 dev eth0 src 192.168.1.101
+\end{lstlisting}
+
+En la salida se observa que la IP del default gateway es la 192.168.1.1.
+
+\subparagraph{Paso 2}
+La instancia 1 debe obtener la MAC asociada a la IP del router Y, como esta no es conocida se dispara el protocolo ARP. Este proceso no se explica dado que es análogo al paso 2 del escenario 1.
+
+\subparagraph{Paso 3}
+Ahora que se conoce la dirección MAC, la instancia 1 retoma el envío del paquete ICMP hacia el router físico a través del router Y. El proceso desde que el paquete parte de la instancia 1 hasta el router Y es análogo al explicado en el paso 3 del escenario 1.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario3/paq-icmp-br-vxlan-comp1}
+ \caption{Paquete ICMP echo request encapsulado en VXLAN capturado en la interfaz br-vxlan en el nodo de cómputo 1}
+ \label{fig:ovs:scenario3:icmp-req-br-vxlan-comp1}
+\end{figure}
+
+\subparagraph{Paso 4}
+Cuando el paquete llega al router Y se envía hacia la red provider-vlan de acuerdo a la tabla de ruteo del namespace:
+
+\begin{lstlisting}
+ [root@infra1 ~]# ip netns exec qrouter-93d73f33-21f9-49f2-920e-0af9917fdf12 ip r
+ default via 10.0.100.2 dev qg-1559b31f-5d
+ 10.0.100.0/24 dev qg-1559b31f-5d proto kernel scope link src 10.0.100.114
+ 192.168.1.0/24 dev qr-e85900b1-10 proto kernel scope link src 192.168.1.1
+\end{lstlisting}
+
+Como se encuentra directamente conectado con el host destino, no necesita ningún salto intermedio.
+
+\subparagraph{Paso 5}
+El router Y debe obtener la MAC del router físico, como hasta el momento esta no es conocida se dispara el protocolo ARP. A continuación se detalla cómo se lleva a cabo el protocolo de resolución de direcciones entre el router virtual y el físico.
+
+\begin{enumerate}
+\item El router Y envía una trama ARP request preguntando por la IP 10.0.100.2 hacia el integration bridge a través del puerto qg (1).
+
+\item El \path{br-int} recibe el pedido ARP, lo etiqueta con el VLAN ID interno 8 y lo reenvía siguiendo las siguientes reglas de OpenFlow:
+
+\begin{lstlisting}
+ [root@infra1 ~]# ovs-ofctl dump-flows br-int --rsort
+ 1. table=0,priority=65535,vlan_tci=0x0fff/0x1fff actions=drop
+ 2. table=0,priority=3,in_port="int-br-provider",dl_vlan=100 actions=mod_vlan_vid:8,resubmit(,60)
+ 3. table=60,priority=3 actions=NORMAL
+ 4. table=0,priority=2,in_port="int-br-provider" actions=drop
+ 5. table=0,priority=0 actions=resubmit(,60)
+ 6. table=23,priority=0 actions=drop
+ 7. table=24,priority=0 actions=drop
+\end{lstlisting}
+La primer regla que coincide es la número 5 en donde se envía el procesamiento a la tabla 60. La regla 3 ejecuta la acción NORMAL enviando el paquete a todas las interfaces del \path{br-int} menos la qg por la cual llego el mensaje.
+
+\item Las reglas del bridge \path{br-tun} descartaran el paquete debido a que no manejan la etiqueta interna 8 (2). Por otro lado, el \path{br-provider} (3) modificará el VLAN interno por la etiqueta 100 y reenviará el paquete a todas las interfaces (en particular la \path{br-vlan}).
+
+\begin{lstlisting}
+ root@infra1 ~]# ovs-ofctl dump-flows br-provider --rsort
+ 1. table=0,priority=4,in_port="phy-br-provider",dl_vlan=8 actions=mod_vlan_vid:100,NORMAL
+ 2. table=0,priority=2,in_port="phy-br-provider" actions=drop
+ 3. table=0,priority=0 actions=NORMAL
+\end{lstlisting}
+
+\item El paquete es recibido por el linux bridge \path{br-vlan} y reenviado a través de la interfaz \path{eth2}. El mismo es transportado mediante la infraestructura física subyacente (4), alcanzando todos los nodos dentro de la VLAN 100.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario3/arp-req-br-vlan}
+ \caption{Paquete ARP request taggeado con el VLAN ID 100 capturado en la interfaz br-vlan en el nodo de red}
+ \label{fig:ovs:scenario3:arp-req-br-vlan-red}
+\end{figure}
+
+\item Cuando el router físico recibe la consulta por su interfaz \path{eth3.100} (5), quita el tag de VLAN y procesa el paquete. Esto genera una respuesta hacia al router Y con un ARP reply directo a su MAC.
+
+\item El procedimiento para la respuesta es similar al descrito pero en sentido contrario.
+\end{enumerate}
+
+\subparagraph{Paso 6}
+Ahora que se conoce la dirección MAC, el router Y retoma el envío del paquete ICMP hacia el router físico. Previo al mismo, debe encargarse de realizar un source NAT para permitir que la respuesta alcance la instancia. Esto se realiza utilizando la interfaz qg (10.0.100.114) como la dirección IP de origen.
+
+\begin{enumerate}
+\item El mensaje es enviado hacia el integration bridge por el puerto qg (1).
+
+\item El \path{br-int} recibe el paquete y realiza la misma acción que el punto 2 del paso 5.
+
+\item Nuevamente el \path{br-provider} realiza la misma acción que el punto 3 del paso 5.
+
+\item El paquete es recibido por el linux bridge \path{br-vlan} y reenviado a través de la interfaz \path{eth2} hacia el router físico. El mismo es transportado mediante la infraestructura física subyacente (4), alcanzando el destino.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario3/paq-icmp-br-vlan-red}
+ \caption{Paquete ICMP echo request capturado en la interfaz br-vlan del nodo de red}
+ \label{fig:ovs:scenario3:icmp-req-br-vlan-red}
+\end{figure}
+
+\item El paquete es recibido por la interfaz \path{eth3.100} del router físico, la cual quita el tag de VLAN y procesa el ICMP echo request.
+
+\end{enumerate}
+
+\subparagraph{Paso 7}
+El procedimiento para la respuesta \path{ICMP echo reply} es similar al descrito pero en sentido contrario.
+
+\subsection{Escenario 4}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario4/diagrama}
+ \caption{Diagrama de arquitectura para el escenario 4 de Open vSwitch}
+ \label{fig:ovs:scenario4:diagram}
+\end{figure}
+
+\subsubsection{Análisis de componentes}
+Los componentes virtuales requeridos para instanciar el escenario 4 son exactamente los mismos que los definidos en el escenario anterior. La única diferencia existente se da en las interfaces del router Z en el nodo de infraestructura, debido a que debe realizar la correspondencia entre la IP flotante y la IP fija de la instancia. Al igual que fue mencionado en el análisis de componentes anterior, se detallan las interfaces del router accediendo al namespace del mismo mediante el siguiente comando:
+
+\begin{lstlisting}
+ [root@infra1 ~]# ip netns exec qrouter-5ba76c31-f4cf-4fe2-95b8-a888e3a415fc ip a
+ 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+ 163: qg-3f5f5f87-bb: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:df:7d:3e brd ff:ff:ff:ff:ff:ff
+ inet 10.0.100.136/24 brd 10.0.100.255 scope global qg-3f5f5f87-bb
+ valid_lft forever preferred_lft forever
+ inet 10.0.100.71/32 brd 10.0.100.71 scope global qg-3f5f5f87-bb
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fedf:7d3e/64 scope link
+ valid_lft forever preferred_lft forever
+ 167: qr-6c9d0914-5e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
+ link/ether fa:16:3e:49:3f:f8 brd ff:ff:ff:ff:ff:ff
+ inet 192.168.1.1/24 brd 192.168.1.255 scope global qr-6c9d0914-5e
+ valid_lft forever preferred_lft forever
+ inet6 fe80::f816:3eff:fe49:3ff8/64 scope link
+ valid_lft forever preferred_lft forever
+ \end{lstlisting}
+
+En la salida de este comando se observa que la interfaz \path{qg-3f5f5f87-bb} dedicada para la red provider, tiene asignadas la IP del router (10.0.100.136) y la flotante de la instancia (10.0.100.71) necesaria para implementar el NAT estático uno a uno con la IP fija de la instancia en la red tenant (192.168.1.101).
+
+\subsubsection{Análisis de tráfico}
+El objetivo de este escenario es analizar el tráfico generado en la comunicación desde un host externo al manejo de Openstack hacia la instancia 1. En este caso se considera al router de la infraestructura física como host externo debido a que si este logra comunicarse con la instancia, entonces también podrá hacerlo cualquier host externo que alcance al router.
+
+\subparagraph{Paso 1}
+El router físico envía el paquete ICMP echo request hacia la instancia 1 utilizando la IP flotante, es decir que el destino será el router Z. Para esto determina que se encuentra directamente conectado con el host destino y por lo tanto no necesita ningún salto intermedio. Con el siguiente comando se observa la tabla de ruteo de dicho router:
+
+\begin{lstlisting}
+ [root@router ~]# ip r
+default via 10.0.40.1 dev eth0 proto static metric 100
+ 10.0.10.0/24 dev eth1 proto kernel scope link src 10.0.10.2 metric 101
+ 10.0.20.0/24 dev eth2 proto kernel scope link src 10.0.20.2 metric 102
+ 10.0.30.0/24 dev eth3 proto kernel scope link src 10.0.30.2 metric 103
+ 10.0.40.0/24 dev eth0 proto kernel scope link src 10.0.40.2 metric 100
+ 10.0.100.0/24 dev eth3.100 proto kernel scope link src 10.0.100.2 metric 400
+ 10.0.101.0/24 dev eth3.101 proto kernel scope link src 10.0.101.2 metric 401
+\end{lstlisting}
+
+\subparagraph{Paso 2}
+
+El router físico debe obtener la MAC del router Z, como hasta el momento esta no es conocida se dispara el protocolo ARP. Este procedimiento no se explica dado a que es análogo, pero en sentido inverso, al detallado en el paso 5 del escenario 3.
+
+\subparagraph{Paso 3}
+Ahora que se conoce la dirección MAC, el router físico retoma el envío del paquete ICMP hacia el router Z.
+
+\begin{enumerate}
+ \item El mensaje es enviado por la subinterfaz \path{eth3.100} (5) en donde se etiqueta el mismo con el VLAN ID 100 hacia la infraestructura física subyacente (4).
+
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario4/paq-icmp-eth3-router}
+ \caption{Paquete ICMP echo request taggeado con el VLAN ID 100 capturado en la interfaz eth3 del router físico}
+ \label{fig:ovs:scenario4:icmp-req-eth3-router}
+\end{figure}
+
+\item El paquete es recibido por la interfaz \path{eth2} del nodo de red y se reenvía hacia el linux bridge \path{br-vlan} llegando luego al bridge \path{br-provider} (3).
+
+\item En este punto el paquete es procesado por las reglas OpenFlow que determinan el reenvío el paquete por todas las interfaces, particularmente por el patch port \path{phy-br-provider}.
+
+\begin{lstlisting}
+ root@infra1 ~]# ovs-ofctl dump-flows br-provider --rsort
+ 1. table=0,priority=4,in_port="phy-br-provider",dl_vlan=8 actions=mod_vlan_vid:100,NORMAL
+ 2. table=0,priority=2,in_port="phy-br-provider" actions=drop
+ 3. table=0,priority=0 actions=NORMAL
+\end{lstlisting}
+
+\item El paquete llega al bridge de integración (2) de OVS donde nuevamente es procesado por las reglas OpenFlow.
+
+\begin{lstlisting}
+ [root@infra1 ~]# ovs-ofctl dump-flows br-int --rsort
+ 1. table=0,priority=65535,vlan_tci=0x0fff/0x1fff actions=drop
+ 2. table=0,priority=3,in_port="int-br-provider",dl_vlan=100 actions=mod_vlan_vid:8,resubmit(,60)
+ 3. table=60,priority=3 actions=NORMAL
+ 4. table=0,priority=2,in_port="int-br-provider" actions=drop
+ 5. table=0,priority=0 actions=resubmit(,60)
+ 6. table=23,priority=0 actions=drop
+ 7. table=24,priority=0 actions=drop
+\end{lstlisting}
+
+En esta oportunidad, se ejecuta la regla 2 que cambia el tag 100 por el interno 8 y lo envía a todas las interfaces mediante la regla 3.
+
+\item En particular el paquete alcanza la interfaz qg (1) del namespace del router de Neutron.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario4/paq-icmp-qg-infra1}
+ \caption{Paquete ICMP echo request capturado en la interfaz qg del router de Neutron}
+ \label{fig:ovs:scenario4:icmp-req-qg-infra1}
+\end{figure}
+
+\end{enumerate}
+
+\subparagraph{Paso 4}
+En el router el servicio de iptables realiza el DNAT sobre el paquete utilizando la IP de la instancia como dirección destino. Estos mapeos se pueden ver en detalle con el comando: ip netns exec qrouter-5ba76c31-f4cf-4fe2-95b8-a888e3a415fc iptables -t nat -L.
+
+\subparagraph{Paso 5}
+El router envía el nuevo paquete ICMP hacia la instancia 1. El proceso desde que el paquete parte del router hasta su destino es análogo al explicado en el paso 3 del escenario 1.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{analisis/ovs/escenario4/paq-icmp-qr-infra1}
+ \caption{Paquete ICMP echo request capturado en la interfaz qr del router de Neutron}
+ \label{fig:ovs:scenario4:icmp-req-qr-infra1}
+\end{figure}
+
+\subparagraph{Paso 6}
+El procedimiento para la respuesta ICMP echo reply es similar al descrito pero en sentido contrario, con la salvedad de que en el momento en que el router Z reenvía la respuesta hacia el router físico, deberá realizar un source NAT cambiando la IP de origen de la instancia 1 por la de la interfaz qg.
\chapter{Trabajo a futuro}
diff --git a/docs/latex/report.toc b/docs/latex/report.toc
index b84d38d495a09ca57374bceb29a9c1830f9e28a0..4a7cd3b3bda8481896a279a72098fb87b968ddef 100644
--- a/docs/latex/report.toc
+++ b/docs/latex/report.toc
@@ -162,9 +162,44 @@
\contentsline {subparagraph}{Paso 6}{100}{section*.201}
\contentsline {section}{\numberline {7.3}Open vSwitch}{101}{section.7.3}
\contentsline {subsection}{\numberline {7.3.1}Escenario 1}{101}{subsection.7.3.1}
-\contentsline {chapter}{\numberline {8}Trabajo a futuro}{102}{chapter.8}
-\contentsline {subsubsection}{Firewall}{102}{section*.202}
-\contentsline {subsubsection}{Arquitectura segura}{102}{section*.203}
-\contentsline {subsubsection}{Brindar conexi\IeC {\'o}n directa a Internet}{102}{section*.204}
-\contentsline {subsubsection}{Gesti\IeC {\'o}n de Openstack en operaci\IeC {\'o}n}{102}{section*.205}
-\contentsline {chapter}{\numberline {9}Conclusiones}{103}{chapter.9}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de componentes}{101}{section*.203}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de tr\IeC {\'a}fico}{105}{section*.204}
+\contentsline {subparagraph}{Paso 1}{105}{section*.205}
+\contentsline {subparagraph}{Paso 2}{105}{section*.206}
+\contentsline {subparagraph}{Paso 3}{110}{section*.211}
+\contentsline {subparagraph}{Paso 4}{112}{section*.214}
+\contentsline {subsection}{\numberline {7.3.2}Escenario 2}{113}{subsection.7.3.2}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de componentes}{113}{section*.216}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de tr\IeC {\'a}fico}{116}{section*.217}
+\contentsline {subparagraph}{Paso 1}{116}{section*.218}
+\contentsline {subparagraph}{Paso 2}{116}{section*.219}
+\contentsline {subparagraph}{Paso 3}{116}{section*.220}
+\contentsline {subparagraph}{Paso 4}{117}{section*.222}
+\contentsline {subparagraph}{Paso 5}{117}{section*.223}
+\contentsline {subparagraph}{Paso 6}{117}{section*.224}
+\contentsline {subparagraph}{Paso 7}{117}{section*.226}
+\contentsline {subsection}{\numberline {7.3.3}Escenario 3}{118}{subsection.7.3.3}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de componentes}{118}{section*.228}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de tr\IeC {\'a}fico}{120}{section*.229}
+\contentsline {subparagraph}{Paso 1}{120}{section*.230}
+\contentsline {subparagraph}{Paso 2}{120}{section*.231}
+\contentsline {subparagraph}{Paso 3}{120}{section*.232}
+\contentsline {subparagraph}{Paso 4}{121}{section*.234}
+\contentsline {subparagraph}{Paso 5}{121}{section*.235}
+\contentsline {subparagraph}{Paso 6}{122}{section*.237}
+\contentsline {subparagraph}{Paso 7}{123}{section*.239}
+\contentsline {subsection}{\numberline {7.3.4}Escenario 4}{123}{subsection.7.3.4}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de componentes}{123}{section*.241}
+\contentsline {subsubsection}{An\IeC {\'a}lisis de tr\IeC {\'a}fico}{124}{section*.242}
+\contentsline {subparagraph}{Paso 1}{124}{section*.243}
+\contentsline {subparagraph}{Paso 2}{124}{section*.244}
+\contentsline {subparagraph}{Paso 3}{124}{section*.245}
+\contentsline {subparagraph}{Paso 4}{125}{section*.248}
+\contentsline {subparagraph}{Paso 5}{125}{section*.249}
+\contentsline {subparagraph}{Paso 6}{126}{section*.251}
+\contentsline {chapter}{\numberline {8}Trabajo a futuro}{127}{chapter.8}
+\contentsline {subsubsection}{Firewall}{127}{section*.252}
+\contentsline {subsubsection}{Arquitectura segura}{127}{section*.253}
+\contentsline {subsubsection}{Brindar conexi\IeC {\'o}n directa a Internet}{127}{section*.254}
+\contentsline {subsubsection}{Gesti\IeC {\'o}n de Openstack en operaci\IeC {\'o}n}{127}{section*.255}
+\contentsline {chapter}{\numberline {9}Conclusiones}{128}{chapter.9}
diff --git a/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-reply.png b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-reply.png
new file mode 100644
index 0000000000000000000000000000000000000000..628a7e0641d62c389373948db3b7208d3c0ce6c8
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-reply.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-request.png b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..4751effc9b3629b50606973e33c6438330419556
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-arp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-icmp-request.png b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-icmp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..17e04bec5fff03220597041a19874b6630f3012d
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/br-vxlan-icmp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/diagrama.png b/docs/latex/resources/analisis/ovs/escenario1/diagrama.png
new file mode 100644
index 0000000000000000000000000000000000000000..8e77348acf19ae0545bdbf54c8b99f6aaebafada
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/diagrama.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-reply.png b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-reply.png
new file mode 100644
index 0000000000000000000000000000000000000000..a7ff1077841f5520b948f40715b25d43764f6603
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-reply.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-request.png b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..0c7e3b0e9d53ad58d886221ac93c131edba6f4f6
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-arp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-icmp-request.png b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-icmp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..dac601f5129a8ab50c53edcd864011a179a4f90a
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario1/tap-instance1-icmp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute1-icmp-request.png b/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute1-icmp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..b4eb5f85a3aeaea1b9a9928667a2a680562adb0e
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute1-icmp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute2-icmp-request.png b/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute2-icmp-request.png
new file mode 100644
index 0000000000000000000000000000000000000000..6e7f074f857f09baf0a9bf4be57363b0872ccc47
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario2/br-vxlan-compute2-icmp-request.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario2/diagrama.png b/docs/latex/resources/analisis/ovs/escenario2/diagrama.png
new file mode 100644
index 0000000000000000000000000000000000000000..19b243da761bdc0f150755a092bd50e9c705edad
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario2/diagrama.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario3/arp-req-br-vlan.png b/docs/latex/resources/analisis/ovs/escenario3/arp-req-br-vlan.png
new file mode 100644
index 0000000000000000000000000000000000000000..e5320efbd621533d4edcd6808720ae609f77ba17
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario3/arp-req-br-vlan.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario3/diagrama.png b/docs/latex/resources/analisis/ovs/escenario3/diagrama.png
new file mode 100644
index 0000000000000000000000000000000000000000..0ab9efc68a2f1482f9a4e68d990984d83ef8c0aa
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario3/diagrama.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vlan-red.png b/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vlan-red.png
new file mode 100644
index 0000000000000000000000000000000000000000..6c9b5742a06be83b9937d7199a8b55f9a7e1a269
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vlan-red.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vxlan-comp1.png b/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vxlan-comp1.png
new file mode 100644
index 0000000000000000000000000000000000000000..fdd24d3479737949e80ccb1744b617e2a87c9c94
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario3/paq-icmp-br-vxlan-comp1.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario4/diagrama.png b/docs/latex/resources/analisis/ovs/escenario4/diagrama.png
new file mode 100644
index 0000000000000000000000000000000000000000..091119200f7c5d7fb523f4fb99534fa9142c9998
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario4/diagrama.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-eth3-router.png b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-eth3-router.png
new file mode 100644
index 0000000000000000000000000000000000000000..4f38278a3aabc72ae4fdb03a5aa2f68669109d07
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-eth3-router.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qg-infra1.png b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qg-infra1.png
new file mode 100644
index 0000000000000000000000000000000000000000..003d9f4cd21bc7441d6bdddb40e1a81019a677c4
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qg-infra1.png differ
diff --git a/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qr-infra1.png b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qr-infra1.png
new file mode 100644
index 0000000000000000000000000000000000000000..c00a237e1b9b0bf16a2ff116ae3ae97440ee6ea0
Binary files /dev/null and b/docs/latex/resources/analisis/ovs/escenario4/paq-icmp-qr-infra1.png differ