NOTAS CCIE WRITTEN - OTV

OTV (Overlay Transport Virtualization) fue creado prácticamente por la necesidad de los Data Centers de gestionar las máquinas virtuales. Es un protocolo para interconectar Data Centers.

Es una VPN de capa 2 sobre IP, como las anteriores. Lo único que necesitamos es conectividad IP entre Data centers. Optimiza los flujos tanto para el data plane como para el control plane, como por ejemplo la caché de ARP o la reducción del flooding. Se focaliza en tres ventajas:

• Pasa de un aprendizaje en data plane a un apendizaje en Control Plane
• Pasa de túnles con pseudo-wire a encapsulación dinámica
• Pasamos de complejas redes multi-home a muy fáciles

Un Data Center puede tener muchas VLAN y si lo que hacemos es interconectar varios Data Center con sus respectivas VLANs, también estamos extendiendo el dominio de broadcast y el escenario de spanning-tree. Con OTV se intenta minimizar el impacto al control plane de los equipos.

Tienen un IGP corriendo entre los data Center (normalmente IS-IS) para propagar las direcciones mac (Mac Routing), es decir, aunque es un escenario de capa 2, no hace el broadcast típico del switching. OTV encapsula las direcciones mac en un paquete IP. La red de transporte no se entera de nada.
 

OTV usa Ethernet sobre GRE. OTV coge la cabecera de la vlan 802.1q y la inserta en su cabecera OTV.

ping X.X.X.X size 1514 df-bit para comprobar conectividad WAN

Cuando un servidor del Data Center hace un flooding/broadcast para encontrar una mac, al llegar al equipo OTV si ve que es una mac desconocida, descarta la trama y no envía el flooding a través de los enlaces WAN. Pero si la ha recibido en un UPDATE de otros sitios, se la servirá en elproceso normal de capa 2. El hecho de que el equipos OTV no mande el flooding reduce drásticamente el tráfico WAN.

De esta manera, cada sitio conserva su dominio de spanning-tree y no están interconectados, por lo que no se influyen entre ellos.

Pero si tenemos varios equipos OTV para redundar, se nos puede crear un bucle dentro de la propia topología OTV:

Para evitar un posible bucle, OTV elige un equipo concreto en cada sitio para ser el único que intercambie información OTV con otros sitios. A estos equipos se les llama AED ( Authoritative  Edge Device). Se le asigna las VLAN's que puede propagar, por lo que si tenemos varios sitios con varios OTV (Multihoming) podemos balancear el tráfico OTV y usar un equipo para unas VLANs y otro para otras.

El AED envía el tráfico a todos los demás equipos OTV de los sitios remotos. Pero solo los equipos AED de los sitios remotos envían el tráfico hacia dentro del DC.


Los equipos OTV forman adyacencias y se intercambian los updates. Tampoco envía multicast a donde no tiene receptor solicitándolo. ¡Y estamos hablando del escenario de capa 2 que se ha creado con los túneles!

Cuando un equipo OTV descubre una nueva dirección mac en su Data Center, manda un mensaje update a los otros OTV con la vlan a la que pertenece y su next-hop.

OTV soporta Multicast. De hecho, los equipos OTV se replican las bases de datos a través de multicast.


INTERFACES

Al equiop OTV se le llama Edge Device.Tenemos 3 tipos de interfaces:

• Internal Interfaces -> las que reciben las VLAN de dentro del DC. Son las interfaces normales Acces/Trunk y no necesitan ninguna configración OTV. También es por donde se comunican los OTV de un mismo sitio, por ejemplo , para elegir el AED.

• Join Interfaces -> las que envían el tráfico a la capa 3 del DC. Pueden ser física o lógicas y también en Port-Channel. Al menos una tiene que ser habilitada.

• Overlay Interface ->  es la interface lógica/virtual donde configuramos OTV. Es el "túnel" que creamos.

MODOS DE IMPLEMENTACIÓN

Dependiendo de la red que nos transporte, podemos implementar OTV con:

• Multicast -> se específica un grupo multicast para el intercambio de OTV
• Unicast -> se crea una arquitectura Servidor-Cliente

En el modo Unicast configuramos uno o varios equipos OTV como servidores y los demás equipos como clientes apuntando a una dirección ip unicast. No hay descubrimiento de vecinos.

 
Interface Overlay 0
 otv join-interface X
 otv use-adjacency-server X.X.X.X
 otv extend-vlan 100-199

Con Multicast, sin embargo, el primer paso es el descubirmiento de vecinos para formar las adyacencias. Todos dispositivo OTV se integran como Multicast Host y no como Routers. Mandan un Hello al grupo y estos responde formando la adycencia. Esto facilita enormemente la integración de más DC. Simplemente apuntamos al grupo multicast y nos unimos al escenario oTV sin interrumpción de red ni recalculos de árbol multicast.

OTV usa 2 grupos multicast:

• ASM (Any Source Multicast) -> para establecer adyacencias y enviar la información de la alcanzabilidad mac. En modo Bidir-PIM.
• SSM (Source Specific Multicast) -> para generar la información multicast de cada sitio.

otv site vlan X
interface Overlay 0
 otv join-interface X
 otv control-group X.X.X.X
 otv data-group X.X.X.X
 otv extend-vlan 100-199


Comandos útiles para verificar:

show otv summary
show otv detail
show adjacency

show otv vlan

show otv isis neighbors 
show otv route


Documentos de Cisco:

• White Paper
• Configuración en Nexus

Para el laboratorio usamos un CSRv1000. Nexus 7k no se puede emular en gns3. La configuración es un poco especial por la "service instance" de las ethernet,pero es fácil de entender y trasladar a Nexus.

El túnel levanta rápido pero luego tardan en verse los PCs. Sed pacientes.

Configuración en modo Unicast

Hacemos a CSR1 que tenga el rol de Servidor OTV. El switch de capa 2 tiene un trunk contra el CRSX y luego puerto de acceso.

CSR1

otv site bridge-domain 1 -> vlan por donde hablan los OTV de un mismo sitio

otv site-identifier 0000.0000.0001

interface Overlay0
 no ip address
 otv join-interface GigabitEthernet1
 otv use-adjacency-server 172.16.1.1 unicast-only
 otv adjacency-server unicast-only
 service instance 100 ethernet
  encapsulation dot1q 100
  bridge-domain 100
 !
 service instance 150 ethernet
  encapsulation dot1q 150
  bridge-domain 150
 !
!
interface GigabitEthernet1
 mtu 9216
 ip address 172.16.1.1 255.255.255.0

!
interface GigabitEthernet2
 no ip address
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
 !       
 service instance 100 ethernet
  encapsulation dot1q 100
  bridge-domain 100
 !       
 service instance 150 ethernet
  encapsulation dot1q 150
  bridge-domain 150
 !       

CRS2

otv site bridge-domain 1
otv site-identifier 0000.0000.0002

interface Overlay0
 no ip address
 otv join-interface GigabitEthernet1
 otv use-adjacency-server 172.16.1.1 unicast-only
 service instance 100 ethernet
  encapsulation dot1q 100
  bridge-domain 100
 !
 service instance 150 ethernet
  encapsulation dot1q 150
  bridge-domain 150
 !
!
interface GigabitEthernet1
 ip address 172.16.1.2 255.255.255.0
!
interface GigabitEthernet2
 no ip address
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
 !
 service instance 100 ethernet
  encapsulation dot1q 100
  bridge-domain 100
 !
 service instance 150 ethernet
  encapsulation dot1q 150
  bridge-domain 150
 !

Fijaos que el PC3 solo tiene una dirección arp,la de PC1. Para él, es como si hubiera un switch conectado entre ellos.

Configuración para modo Multicast

Aquí no hay rol de Servidor. Todos los equipos OTV se unen a un mismo grupo multicast.

CSR1

ip pim ssm default
ip multicast-routing distributed
interface Gi1
  ip pim passive
  ip igmp version 3

interface overlay 0

 no otv use-adjacency-server 172.16.1.1 unicast-only
 no otv adjacency-server unicast-only

 otv control-group 226.0.0.1 

 otv data-group 232.0.0.0/24

CSR2

ip pim ssm default
ip multicast-routing distributed
interface Gi1
  ip pim passive
  ip igmp version 3

interface overlay 0

 no otv use-adjacency-server 172.16.1.1 unicast-only

 otv control-group 226.0.0.1
 otv data-group 232.0.0.0/24

Fijaos como entre CRS1 y CRS2 se comunican por ISIS. De hecho,si miráis en la configuración se han añadido líneas de ISIS sin que nosotros lo hayamos configurado. También vemos los grupos multicast usados.