O OTV (Overlay Transport Virtualization) é uma tecnologia que fornece a extensão de camada dois entre os diferentes Data Centers.
Em outras palavras, o OTV é uma nova tecnologia que encaminha informações baseadas em MAC address através do encapsulamento no pacote IP.
Overview sobre OTV
Tecnologias tradicionais de L2VPN, tais como EoMPLS e VPLS, dependem fortemente de túneis. Ao invés de criar túneis stateful, o OTV encapsula o tráfego layer 2 em um cabeçalho IP e não cria túneis fixos.
O OTV requer apenas a conectividade IP entre os Data Center, o que permite as infraestruturas de transporte a ser baseada em layer2.
O OTV não requer alterações nos Data Centers existentes para trabalhar, mas atualmente só é compatível com os switches da série Nexus7000 com linecards M1-Series.
O encaminhamento MAC-in-IP é feita através do encapsulamento de um quadro Ethernet dentro de um pacote IP antes de encaminhado.
A ação de encapsular o tráfego entre os dispositivos OTV, cria o que é chamado de overlay entre os Data Centers. Pense em uma overlay como uma rede multiponto entre os sites distintos.
Cada dispositivo de borda deve ter um endereço IP válido na rede para prover acessibilidade, isto permite o OTV ser inserido em qualquer tipo de rede de uma forma muito mais simples.
O OTV é implantado em dispositivos de bordas do Data Center, conhecidos como “Edge device”.
Terminologias OTV
OTV Edge Device.
É um dispositivo (Nexus 7000 ou Nexus 7000 VDC), que fica na borda de um Data Center, realizando todas as funções OTV, com o objetivo de conectar a outros Data Centers.
O OTV Edge device está ligado ao domínio layer2 do Data Center, bem como su domínio layer 3.
Com NX-OS 5.1, no máximo dois OTV Edge device podem ser implantados em um Data Center para permitir a redundância.
Interfaces internas.
São as interfaces de camada 2 no OTV Edge device configurado como um tronco ou uma porta de acesso, essas interfaces participam do domínio STP e aprendem MAC address normalmente.
Join Interface.
É uma interface de camada 3 no OTV Edge device que se conecta à rede de IP (MPLS/EoMPLS/etc..).
Essa interface é usada como origem para o tráfego OTV encapsulado, que é enviado para o OTV Edge device remoto.
Com NX-OS 5.1, pode ser uma interface física ou Port-channel layer3.
As interfaces loopback não são suportadas nas implementações atuais.
Somente uma interface poderá fazer “Join”em um overlay OTV.
Vários overlays também podem compartilhar a mesma Join Interface.
Overlay Interface.
É uma interface multi-acesso e multicast, onde toda a configuração OTV são explicitamente definidas por um usuário.
A Overlay Interface funciona como uma interface brigde entre Data Centers para mostrar como os frames layer 2 devem ser encapsulados dinamicamente OTV antes encaminhados a Interface Join.
OTV Control-group.
É um grupo multicast usado pelo OTV speaker em uma rede overlay.
Um endereço de multicast exclusivo é necessário para cada grupo de overlay.
OTV Data-group.
Usado para encapsular todo o tráfego multicast layer2 que se estende através do overlay.
Extended-VLANs.
São as VLANs que são explicitamente permitidos ser estendido através de overlay entre Data Centers.
Se não for explicitamente permitido, os endereços MAC de uma VLAN não será anunciado em todo overlay.
Site-VLAN.
É a VLAN utilizada para a comunicação entre dispositivos OTV dentro de um Data Center.
também usado para facilitar o papel eleição da AED (Authoritative Edge Devices).
O Site VLAN deve ser existir e ser ativo.
Operação do OTV
O OTV depende do control-plane para anunciar endereços MAC. O protocolo de roteamento usado no control-plane é o IS-IS (Intermediate System Intermediate System).
Os IS-IS hellos e LSPs são encapsulados no cabeçalho IP de multicast do OTV.
Os pacotes OTV IS-IS usam um endereço de layer2 de destino multicast distintos. Portanto, os pacotes OTV IS-IS não entram em conflito com pacotes IS-IS utilizados para outras tecnologias.
Razões para o uso do IS-IS.
Em primeiro lugar IS-IS não usa IP para realizar roteamento de mensagens, ele usa CLNS. Assim, o IS-IS é neutro quanto ao tipo de endereços de rede para que ele possa encaminhar o tráfego, tornando-se ideal para encaminhar endereços MAC.
Em segundo lugar a utilização de TLVs. A TLV (Type, Length, Value) é um formato de codificação usado para adicionar informações opcionais de protocolos de comunicação de dados. Por isso, o IS-IS pode ser facilmente estendido para realizar os novos campos de informação
Você precisa entender o IS-IS para entender OTV?
Você precisa saber como o motor de um carro funciona para dirigi-lo?
Não, mas é melhor ter pelo menos um conhecimento básico de como tudo se encaixa.
Antes da troca de qualquer endereço MAC, todos os OTV Edge device deve tornar-se “adjacentes”.
Isto é possível utilizando um OTV Control-group específico em toda a infraestrutura de transporte para trocar as mensagens do protocolo de controle e anunciar os endereços MAC.
Todos os OTV Edge device devem ser configurados para fazer “join” com um ASM específico (Any Source Multicast) grupo onde desempenham simultaneamente o papel de receptor e origem.
Esta é uma funcionalidade multicast, conforme figura abaixo:
- Cada OTV Edge device envia um IGMP report para fazer um join ao grupo ASM específico utilizado para realizar trocas de protocolo de controle. Os Edge devices fazem “join” no grupo como host. Este é IGMP, não PIM.
- Os Pacotes hello OTV são gerados para todos os outros OTV Edge device, para comunicar o Edge device local e acionar o estabelecimento adjacências.
- Os pacotes hello OTV são enviados através da overlay Interface para o dispositivo remoto. O endereço IP de origem é o da Join Interface e o destino é o do grupo multicast ASM conforme especificado.
- Os quadros multicast são replicados para cada dispositivo OTV que fizer join no Control-group multicast.
- Os OTV Edge device que receberam os pacotes, tiram o encapsulamento do cabeçalho IP antes de ser transmitido para o processamento.
- Uma vez que os OTV Edge devices se conhecem (formam adjacências), eles estão prontos para trocar endereços MAC
Anúncios de endereços MAC
- Os OTV Edge device no Data Center West aprende novos endereços MACs ( MAC-A, MAC-B e MAC-C pela vlan 100) através da interface interna. Isso é feito através da aprendizagem normal de data-plane.
- Uma mensagem “OTV update” é criada com as informações de MAC-A, MAC-B e MAC-C. Essa mensagem é encapsulada e transportada via Layer3, como dito anteriormente, o endereço de origem é o da Join Interface e o endereço de destino é o do grupo multicast ASM.
- Os quadros multicast são replicados para cada dispositivo OTV que fez join no Control-group multicast. Os pacotes são OTV desencapsulados e entregues para o OTV control-plane.
- Os endereços MAC são importados nas tabelas de endereços MAC (CAMs) dos Edges devices. Os MACs são aprendidos pela interface que faz Join no Edge device no Data Center East.
- Uma vez que as adjacências do control-plane entre os OTV Edge devices são estabelecidss e os endereços MAC forem trocados, o tráfego entre os sites são possíveis.
Tráfego de encaminhamento de data-plane
- O frame layer 2 está destinado a um endereço MAC aprendido através do overlay, uma vez que a mesma é a interface do próximo salto.
- O quadro original layer 2 é encapsulado como OTV e o bit DF está definido.
- O overlay encapsula o quadro layer2 em UDP usando GRE usando a porta de destino 8472.
- O endereço IP de origem é o da Join Interface.
- O IP de destino não é mais o grupo multicast, mas sim, o endereço IP da interface que participa com OTV Edge device remoto que anunciava o MAC-3.
- O quadro Unicast é entregue através da infraestrutura diretamente ao OTV Edge device remoto.
- Se fosse um quadro de broadcast seria entregue a todos os OTV Edge devices.
- Se fosse um multicast que só iria ser encaminhado para os OTV Edge devices remotos que subscrevam como membros usando um endereço de OTV Data-group.
- O OTV Edge device desencapsula quadro, expondo a camada 2 original.
- O OTV Edge device remoto realiza um lookup no quadro ethernet original e determina a interface de saída para o destino.
- O quadro alcança o seu destino.
O formato do cabeçalho.
Algumas considerações devem ser levadas em conta, quando falamos em OTV, uma delas é a MTU em toda a infraestrutura. Considerando o layout do cabeçalho do pacote:
O cabeçalho OTV tem 42 bytes adicionado o DF (Não Fragmento) bit é definida em todos os pacotes OTV.
O bit DF está definido porque o Nexus 7000 NÃO suporta fragmentação e remontagem.
A origem VLAN ID e o OverlayID são definidos, e os bits de prioridade 802.1q do quadro layer2 original é copiado para o cabeçalho OTV, antes que seja encapsulado no pacote IP.
Se faz necessário o aumentando o tamanho da MTU de todas as interfaces de transporte para OTV.
Este desafio não é diferente de outras tecnologias como VPLS e EoMPLS.
Separação do Spanning-tree.
Os OTV Edges devices participam do Spanning-tree normalmente, enviando e recebendo BPDUs em sua interface interna, como faria com qualquer outro Switch de camada 2.
Mas um OTV Edge device NUNCA dará origem ou encaminhará um BPDU em uma overlay interface.
O OTV limita assim o domínio STP de cada Data Center. Isso significa que um problema de STP local, não tem efeito nos Data Centers remotos.
Esse, sem dúvidas, é um dos maiores benefícios do OTV, em comparação com outras tecnologias.
Isso só é possível, pois o MAC é aprendido via protocolo de Control-plane e não de flooding como de costume.
Com a separação de STP por Data Center, a capacidade de diferentes sites usar diferentes tecnologias STP é possível com OTV, ou seja, um site pode executar MSTP enquanto outro corre RSTP.
Multi-Homing.
O OTV permite que vários OTV Edge devices existam no mesmo site para fins de compartilhamento de carga. (Com NX-OS 5.1 que é limitado a dois OTV Edges device por Data Center.)
A ausência de STP entre os sites detém benefícios valiosos, mas um mecanismo de prevenção do circuito continua a ser necessário, portanto, um método alternativo foi utilizado. Os Engenheiros que escreveram OTV, decidiu eleger um dispositivo principal responsável para o encaminhamento de tráfego (semelhante a alguns protocolos não-STP).
No OTV este dispositivo eleito master é chamado de AED (Authoritative Edge Device).
Um AED é um OTV Edge device que é responsável por encaminhar os quadros de VLANs estendidas dentro e fora de um Data Center, através da rede de overlay.
Somente a AED irá encaminhar o tráfego para fora do Data Center através da overlay.
A AED, garante assim que o tráfego de cruzar o limite site overlay não se duplica ou criar loops quando um site é multi-homed.
Voltando à causa original, uma AED permite o compartilhamento de carga de tráfego se vários OTV Edge devices presentes em um Data Center.
Um AED pode ser eleito de forma dinâmica ou estática.
A AED é eleito usando um algoritmo determinista, através da atribuição de números ordinais para cada OTV Edge device no Data Center local com base no OTV System -ID.
Em caso de duas AEDs em um DataCenter, elas se dividiram em VLANS pares e ímpares entre os dois dispositivos.
Mais especificamente, o OTV Edge devide com um menor System-ID vai se tornar oficial para todas as VLANs estendidas PARES, enquanto o OTV Edge device com maior System-ID serão autorizada as VLANs estendidas ÍMPARES.
Uma vez que todo o tráfego só pode sair através da AED para uma determinada VLAN estendida, é altamente recomendável configurar um vPC peer-link entre os OTV Edge devices para um redirecionamento ideal.
O vPC peer-link será utilizado para orientar o tráfego entre os dispositivos AEDs.
Se um AED falhar, a outra AEDs irá perceber a falha e assumir a autoridade para todas as VLANs estendidas.
O Site-VLAN deve ser definido mesmo que eu tenha somente um Edge em meu Data Center?
O Site-VLAN é uma VLAN utilizada para a comunicação entre os OTV Edge device locais dentro de um Data Center (não via o Overlay). Ele é utilizado para facilitar a função de eleição do AED.
O Site-VLAN NÃO deve ser estendido através do overlay.
Ela não necessita corresponder entre os OTV Edge device locais, mas recomenda-se a utilização da mesma VLAN.
A VLAN utilizada como site VLAN deve estar ativo, porém não passar o tráfego.
Mobilidade de MAC address.
Uma das grandes características da Ethernet é a capacidade de se adaptar dinamicamente a endereços MAC.
Esta capacidade também deve ser alcançada quando se desloca de uma MAC através do OTV de um Data Center para outro.
VMotion é um exemplo comum de mobilidade MAC.
VMotion ocorre quando a máquina virtual se move de um Data Center para outro.
Se a AED tem um endereço MAC armazenado na tabela de encaminhamento que aponta para a interface de overlay, isso significa que um OTV Edge device de um outro Data Center tem explicitamente anunciado o endereço MAC como local para seu Data Center.
Quando o MAC aparece em um novo Data Center, que foram previamente anunciados por outro, a AED irá anunciar o endereço MAC (recém-aprendido na interface interna), com um valor de métrica de 0.
Quando o OTV Edge device deixar de ouvir o anúncio, ele vai retirar o endereço MAC que tinha anunciado anteriormente.
Uma vez que o endereço MAC é retirado, o OTV Edge device, mudará o valor da métrica para 1.
Muito cuidado quando for usar endereços MAC estáticos.