Category: Tecnologias


VXLAN

Com o crescimento dos Data Centers, da virtualização de máquinas e de serviços de Cloud, surgiu a necessidade de estender as VLANs através ou além dos DCs, utilizando assim os recursos computacionais de maneira mais eficiente com VMs  que pertencerão a um ambiente compartilhado (ou não) em inumeras localizações físicas, atribuíndo e estas VMs a habilidade de mover-se entre diferente localizações sob-demanda.

Mas a movimentação de VMs necessita que a máquina retenha o endereço MAC e IP de forma que o processo ocorra de maneira transparente para as camadas superiores do modelo OSI, como a de Aplicação, e este é um grande desafio para o modelo tradicional de Data Center, onde VMs necessitam mover-se dentro de um tradicional domínio de broadcast.

Para suportar a mobilidade de VMs entre PODs em um DC, ou sites, a rede deve ser desenhada como uma grande rede L2, o que acarreta varias limitações que precisam ser re-endereçadas:

– Primeiro: Devido a virtualização de servidores, cada máquina virtual (VM) requer um endereço MAC único e um endereço IP. A escalabilidade da tabela de endereços de camada 2 é uma das grandes preocupações em Data Centers virtualizados pois o número de endereços MAC por porta pode atingir de 50 a 100 VMs por servidor, sobrecarregando assim os Switches ToR (Top-of-Rack) ou da camada de aggregação.Com isso após a tabela MAC dos Switches atingir o limite, uma parte do tráfego começa a ser “inundado” por toda a rede, resultando em um grande fluxo de dados  desnecessário.

– Outro ponto importante é a extensão de VLANs pelos Switches do DC que torna-se uma tarefa complexa quando planejamos  uma implantação fim-a-fim pelo Data Center.

– Com a utilização do STP para fornecer uma topologia livre de loops de camada 2, o protocolo Spanning-Tree desativa links redundantes. Assim, Equal-Cost Multi-Path (ECMP) não é habilitado. No entanto, 0 ECMP é fácil de habilitar em uma rede IP.

VXLAN

O padrão VXLAN (Virtual eXtensible Local Area Network) trabalha em cima da limitação da quantidade de VLANs em um Data Center que é a de 4K VLANs. O Protocolo VXLAN emprega MAC sobre IP/UDP, e permite assim aumentar o número de domínios de Broadcast para 16 milhões.

O VXLAN é uma rede de camada 2 sobreposta em uma rede de camada 3. Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier (Identificador de Rede VXLAN) ou VXLAN ID. A identificação de uma máquina virtual é uma combinação do endereço MAC e o VNI.  As Máquinas virtuais em VXLAN diferentes não podem comunicar umas com as outras (sem a utilização de um roteador). O pacote original enviado pela VM na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquela máquina virtual pertence.

VXLAN-frame-550x104

Imagem  do site  http://blogs.cisco.com/datacenter/cisco-vxlan-innovations-overcoming-ip-multicast-challenges/

O encapsulamento do quadro é feito pelo equipamento que está na extremidade do túnel VXLAN, que é chamado de VTEP (VXLAN Tunnel Endpoint).

VXLAN-VTEP

O VTEP pode tanto ser implementado como um módulo de software em um Switch Virtual, em um Servidor ou em um Switch Top-of-Rack (ToR). Uma interface VTEP é vinculada a um endereço IP único e pode ser considerada equivalente a uma interface loopback.

Quando uma VM quer comunicar com outra VM no mesmo segmento, o VTEP vinculado à VM atribui o encapsulamento adequado da VXLAN, inserindo o cabeçalho VXLAN, sobre o cabeçalho original, colocando o endereço IP de origem do VTEP (como Source IP Address [SIP] nesse novo cabeçalho) e o endereço de destino (Destination IP Address [DIP]) correspondente ao VTEP que a VM de destino reside. Quando o pacote é recebido pelo VTEP de destino, o cabeçalho VXLAN é removido e o pacote interno e é encaminhado para a VM de destino.

O VTEP mantém uma tabela de endereços MAC aprendidos e armazena o endereço IP do túnel para o VTEP remoto. Os Quadros unicast entre VMs são enviadas diretamente para o endereço unicast L3 do VTEP remoto. Os pacotes multicast e broadcast das VMs são enviados a um grupo IP multicast associado à VNI, o VTEP remoto recebe o quadro multicast, encaminha o pacote à máquina destino (efetuando todos os mapeamentos do VTEP e VM de origem. A VM de destino faz uma respota ARP normalmente em unicast. O VTEP encapsula o pacote ARP com o padrão VXLAN e encaminha o quadro para o  VTEP da VM de origem….

Consequentemente, um segmento VXLAN “estendido” requer:

  • Um  Grupo IP Multicast associado
  • Roteamento Multicast entre os VTEP

Mas como é feita a comunicação com equiapamentos não-virtualizados?

Uma das maneiras de permitir a conexão entre VXLAN e uma VLAN tradicional é através de um equipamento (virtual ou não) chamado de VXLAN Gateway.

A funcionalidade do Gateway VXLAN pode ser embutida no VTEP, fazendo o mapeamento para substituição do encapsulamento VXLAN para cabeçalho 802.1Q  e assim por diante, tendo a responsabilidade como um ponto de entrada e saída de uma nuvem VXLAN.

Pelas caracteristicas de funcionamento para o Gateway VXLAN entre o ambiente fisico  e virtual, encontramos essa função em documentações atríbuida comoLayer 2 VXLAN Gateway (ou Gateway VXLAN de Camada 2).

VXLAN-Gateway

Já para o roteamento entre VXLANs essa função pode ser atribuída ao VXLAN Gateway, também chamada de Layer 3 VXLAN Gateway.

Referência

  • Data Center Virtualization Fundamentals – Cisco Press – 2013 – Gustavo A.A. Santana
  • Using TRILL, FabricPath, and VXLAN – Cisco Press 2014 – Sanjay K. H., Shuyam Kapadia,Padmanabhan Krishnan.
Anúncios

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-interfaces3

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:

otv-neighbor-discovery

  • 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

otv-mac-advertising

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

otv-traffic-forwarding

  • 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:

otv-header

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).

otv-aed-1

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.

Isolamento de FHRS.

O HSRP (Host Standby Routing Protocol), VRRP (Virtual Router Redundancy Protocol) e GLBP (Gateway Protocol Load Balancing) são muitas vezes implementadas para fornecer um endereço IP comum (VIP) a ser usado como um gateway padrão e fornecer redundância e balanceamento de carga para os clientes em que sub-rede.

Uma vez, o OTV estendendo as VLANs em múltiplos Data Centers, o tamanho do segmento ‘local’ é mais alargado e não tão ‘local’ assim.

Os protocolos FHRP também são estendidas entre os Data Centers que abre a possibilidade do dispositivo FHRP ‘ativo’ responsável por encaminhar o tráfego não ser mais fisicamente localizado.

O Tráfego inter-VLAN pode atravessar um Data Center remoto onde o gateway FHRP reside, embora ambos hosts de origem e de destino residem no mesmo Data Center local.

Um aumento na latência entre os Data Centers poderia compensar adicionalmente a estabilidade dos protocolos FHRP.

otv-fhrp1

Este problema é abordado pelo que chamamos de “Isolamento de FHRP”, o que limita / isola todos os quadros FHRP para cada Data Center local.

Com a ausência de comunicação do site-to-site FHRP, cada Data Center escolheria membro um “ativo” a FHRP local como o gateway padrão.

Isto significa que o tráfego de saída será capaz de seguir o caminho ideal e mais curto, sempre aproveitando o gateway padrão local

Limitações do OTV.

OTV e SVI no mesmo VDC:

Com as implementações atuais de NX-OS, o encapsulamento OTV (isto é, o OTV Edge device) e o SVI VLAN devem ser em dispositivos ou VDCs separados.

Existem duas formas implementação usando OTV VDC, são elas:

OTV Appliance on a Stick & Inline OTV Appliance

 

otv-vdcs

Limitações do NX-OS:

Suporte a Unicast para a rede de transportes.

  • Suporte a IPv6 para uma rede de transportes.
  • A Join Interface deve ser uma interface física.
  • Balanceamento de carga do AED baseado por fluxo.
  • Mecanismo de flooding seletivo.
  • Supressão de broadcast.
  • FHRP isolamento feito usando comandos nativos.
  • Mais de dois Edge devices por site.
  • Mais de seis Edge devices em todos os sites.
  • Mais de três sites de OTV suportados.
  • Mais que 128 VLANs por overlay.

Vamos colocar a mão na massa!

Elaborei um LAB  usando dois Switches Nexus 7000, cada um com quatro VDCs, dois Switches Nexus 5000 e um switch Catalyst 3750.
Emulando dois sites dentro do mesmo Data Center. Site1 inclui Switches 11-14 (quatro VDCs em N7K-1) e Switch 15 (N5K), enquanto Site2 inclui switches 21-24 (quatro VDCs no N7K-2) e switch 32 (3750).

Esta será a topologia utilizada no nosso site:

otv-lab1

Antes de configurarmos o OTV, lembre-se da limitação do OTV junto com SVI .

Configurando…

Passo 1:  feature  OTV

Habilite a feature  OTV dentro do VDC. Para utlilizar o  OTV  será necessário uma licença especial chamada : Transport_Services_PKG.  Alternativamente, se apenas para testes ou POC, habilite o grace-periodic, que permitirá uma demo por um periodo de 120 dias para usar e testar.

1

Passo 2: VLANs

Crie e identifique as VLANs que devem ser estendidas entre os Data Centers.

Certifique-se que todas as VLANs estão ativas.

2

Passo 3: OTV site-VLAN

Por default, a  VLAN 1 vai será usada. Recomenda-se usar uma VLAN dedicada.

A VLAN alocada para o Site-VLAN não pode ser estender através do overlay. Como resultado, o mesma VLAN pode ser usada em ambos Data Center. Mesmo se tiver apenas um OTV Edge device, o Site VLAN ainda deve ser definido. Criar  e definir uma nova VLAN para ser usada como OTV Site-VLAN.

3

Passo 4: Join Interfaces
Apenas uma Join interface pode ser especificada por overlay em cada dispositivo. Configure um endereço IP em cada interface física conectada à rede IP, ative o IGMP v3 (obrigatório fazer join nos grupos SSM). Não ative o PIM na Join Interface.

4

Passo 5:  As interfaces internas

Configure as interfaces LAYER 2 de cada Data Center. Estas são as interfaces que irão participar na STP e de aprendizagem dos endereços MAC a partir do Data Center local. É recomendado  apenas as VLANs relevantes sobre essas interfaces, ou seja, as VLANs para ser estendidas e a Site-VLAN. Faça quaisquer configuração de STP, caso necessário.

5

Passo 6: Overlay Interface 

Crie uma a interface Overlay lógica.  Multiplas Interfaces Overlay  podem ser usadas para permitir que diferentes VLANs usem caminhos diferentes na rede IP, mas são necessárias duas condições para isso. O número de overlay deverá corresponder entre Data Center e uma VLAN só pode ser atribuída a um overlay. Desabilite a a interface Overlay antes de configurá-la. Especifique o  OTV Control-group e OTV Data-group.

6

Passo 7: VLANs estendida

Adicione as VLANs a serão transportadas através do overlay. Observe que o Site-VLAN não é prorrogado.

7

Passo 8: valores de MTU

Configurando os valores de MTU dentro dos Data Centers é o menos importante, mas na rede IP os valores deverão ser corretos. Lembre-se que o bit DF é definida em todos os pacotes OTV saindo de  um Edge device.
8

 

 

Passo 9: “No shutdown” na a Interface overlay

Se houver apenas um  OTV Edge device presente por Data Center local, este passo é trivial.

Se houver dois  OTV Edge device por site para fins de compartilhamento de carga, por uma questão de estabilidade, verifique se a conectividade está OK antes de levantar a redundância.

9

Passo 10: Teste de Conectividade

Um simples ping de um Data Center para outro será o suficiente. Este, porém, não pode ser feito a partir dos OTV Edge device, já que eles não têm SVI das VLANs estendidas. No início, é normal perder o primeiro / segundo ECHO para o tempo limite. Este é o tempo que leva para o processo de solicitação ARP IP para completar e permitir OTV para anunciar os endereços MAC recém-aprendidos de ambos os Data Centers.

10

 

 

 

 

 

Comandos de verificação

show1

show2

show3

show5show6

 

show7

 

FHRP Isolation


E por último vamos falar sobre o Isolamento de  FHRP.

Eu configuramos o HSRP para VLAN-10 em ambos os Site-1 (entre switch 11 e 12) e Site-2 (entre switch 21 e 22).

Porque é uma sub-rede contígua todos os hosts na VLAN-10 tem o seu gateway configurado como 10.1.1.1, que é o mesmo endereço IP do gateway virtuais em ambos os sites.

O tráfego de Site-1 deve sair via switch 11 e o tráfego de Site-2 deve sair via switch 21 desde que ambos os switches estejam configurados com uma prioridade HSRP de 105. Mas isso não é o que acontece por padrão. Dê uma olhada no output abaixo:

fhrp1

Na switch 11, o ativo HSRP  para VLAN-10 é switch 21. Este seria o mesmo dos switches 12 e 22.

Mas, por que?

Uma vez que tanto switch 11 e 21 têm suas prioridades HSRP definido para 105, o roteador com o maior endereço IP da interface será eleito como o dispositivo HSRP Ativa.Neste caso alternar 21.

Isso significa que todo o tráfego para a porta de entrada de 10.1.1.1 será em frente ao Site-2.

Este é o problema que agora será corrigido.

O próximo resultado mostra o tráfego de Site-1 é destinado através do overlay.

fhrp2

O Isolamento de FHRP nada mais é do que o ato de filtragem HSRP, VRRP ou GLBP atravessando o overlay, e forçando eleições FHRP locais.

Existem duas partes para filtrar.

1 – O processo de eleição deve ser contido dentro de cada site.
2 – Os endereços MAC virtuais ainda serão anunciados.
Ponto número 1 é realizado usando uma ACL VLAN nos OTV Edge device para filtrar o respectivo tráfego dependendo do protocolo que FHRP usado. O exemplo abaixo mostra como filtrar todos eles:

filter1

Para evitar que os endereços MAC virtuais possam causar movimentos MAC através do overlay e permitir um design mais limpo, um OTV route-map deve ser configurado.

Este route-map deve corresponder ao MAC virtual do protocolo FHRP usado. Por exemplo HSRP v1 utiliza o MAC virtual: 0000.0c07.acXX onde o último byte (XX) é o número do grupo HSRP em HEX.

Formatos semelhantes se aplicam para VRRP e GLBP. A configuração abaixo mostra como filtrar todos os protocolos FHRP e deve ser aplicada em todos os OTV Edge device.

filter2

Uma vez que os filtros é aplicada, verificaremos os mesmos outputs anteriores.

filter3

Topologia – CCIE DataCenter

Topologia

Essa topologia está composta pelos seguintes dispositivos:

2x  Nexus 7010s  com M1/F1 10GigEth

2x  Nexus 5548up

2x Nexus  2232 1/10Gig  100/1Gig

4x Routers 3825

etc…

The first portion of the vSeminar deals with the hardware and software blueprint for the upcoming CCIE DC Written Exam and CCIE DC Lab Exam. Specifically this includes the following:

  • Nexus 7009 v6.0(2) w/ SUP1, 10GE F1, 10GE M1
  • Nexus 5548 v5.1(3)
  • Nexus 2232
  • Nexus 1000v v4.2(1)
  • UCS 5108 Blade Chassis
    • B200 M2 Blade Servers
    • 6248UP Fabric Interconnects v2.0(1x)
    • 6204 FEX
  • UCS C200 Series Server
  • Application Control Engine (ACE) 4710 vA5(1.0)
  • MDS 9222i v5.2(2)
  • JBODs
  • Cisco Data Center Manager software v5.2(2)
  • 2511 Router & Catalyst 3750 for mgmt access

The next section deals with the technical topics that are within the scope of the exam, and goes through a high level design overview of the hardware platforms and where their software features fit into the modern Data Center design. Specifically we have subdivided the topics into three main topic domains, which are:

  • Nexus Switching
  • Storage
  • Computing

Beyond this we talk more about our plans for delivery methods for CCIE Data Center training, the expected release schedule, and additional training domains moving forward.  Specifically the four main delivery methods we will be offering are:

  • Online & Live Onsite Classes
  • Streaming & Downloadable Videos
    • DRM free & cross platform support
  • Self-Paced Labs
  • Rack Rentals
The first of these products that we will be releasing are the Live Online Classes.  You can sign up for these classes here, which will give you access to attend the classes live, and also to the recorded versions of the classes which will be available about a week after each class’s completion.  These classes and dates are:

More details about other products such as the primer, deep dive, & troubleshooting video series, self-paced labs, rack rentals, and live onsite classes will be available within the next coming days and weeks and will be posted here on our blog.

Let us know what questions you have going forward with CCIE Data Center training, and Data Center focused training in general, as we are as excited about this brand new track addition as you are!

Private VLAN

Topologia sugerida:

Iremos usar a  sub-rede 192.168.200.0/24  que será segmentada em 3 sub-domínios, identificados pelas PVLANs 200, 300 e 400, e a PVLAN 100 como primária:

VLAN 100: PVLAN primária das PVLANs 200, 300 e 400.

VLAN 200: PVLAN secundária do tipo isolada. A esta estará conectado o host 192.168.200.1 (Fa1/0/1).

VLAN 300: PVLAN secundária do tipo comunidade. A esta estarão conectados os hosts 192.168.200.30 (Fa1/0/3) e 192.168.200.40 (Fa1/0/2).

VLAN 400: PVLAN secundária do tipo comunidade. A esta estarão conectados os hosts 192.168.200.10 Fa1/0/5) e 192.168.200.20 (Fa1/0/4).

O Cisco router  (192.168.200.254), estará conectado a porta promíscua Fa1/0/24, pois será o gateway da rede.

Para verificar a configuração, podem ser usados os comandos show vlan private-vlan’ e ‘show vlan private-vlan type’.