Latest Entries »

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

Provavelmente, você já viu essa mensagem de erro ao tentar configurar uma porta!?!?!

“ERROR: Ethernet1/4: Config not allowed, as first port in the port−grp is dedicated”
Para entender o que essa mensagem representa, precisamos compreender o que é um port-group.
Veja abaixo a imagem da line card  N7K – M132XP -12 .

N7k-M108X2-12LEste line-card tem 32 portas e todos são de 10 portas Gig.

 

E o que isso significa? Será que isso significa que podemos ter todas essas 32 portas conectadas ao mesmo tempo e que possamos ser capaz de obter 320 Gbps de velocidade?

Não exatamente …!

Bem, elas realmente são de 10Gig, no entanto, esses 10Gig são compartilhados entre quatro portas em um grupo. Esse grupo é basicamente contempla todas as portas no mesmo ASIC.

 

Então, vamos lá:
De acordo com a figura abaixo, podemos 0bservar que as portas “pares ou ímpares” são contínuas de um lado e cada grupo de quatro portas estão no mesmo ASIC.
As portas que podem ser dedicadas são marcadas de amarelo como você pode ver no diagrama abaixo .
dedicated

O line-card N7K-M132XP-12 tem 32 portas 10Gig, isso significa que cada port-group (grupo de 4 portas para esse line-card) compartilham os 10Gig.
Cada porta  não tem a largura de banda dedicada 10G . Assim, a capacidade total do line card é de 80Gig , e não 320Gig (como estávamos esperando) como não pode ser de 8 port-group de 4 portas cada.

Então  as portas 1,3,5,7 estará no mesmo port-group e similar a 2,4,6,8 e assim por diante … !

E se tivermos necessidade de alguma aplicação crítica que precisamos largura de banda dedicada de 10Gig?  boa pergunta!

Nesse caso, a primeira porta de um grupo de portas pode ser colocado no modo ” dedicado” e que a porta será sempre o primeiro do grupo. marcado em amarelo, como mostrado na foto acima .

Temos que, as portas  1,2,9,10,17,18,25,26 pode ser colocado em modo dedicado e se você colocar uma porta em um port-group em modo dedicado, todos os outros 3 portas desse grupo vai ficar desativado. Você não pode configurá-los.

Exemplo: Se você colocar Eth1 / 2 em modo dedicado , e se você tentar configurar Eth1 / 4, então você vai ter:

“ERROR: Ethernet1/4: Config not allowed, as first port in the port−grp is dedicated”

Shared mode vem como modo default. O comando para configurar como modo dedicado é:
(Não esqueça de colocar a porta em shutdown primeiro)

N7K# config t
N7K(config)#interface Eth1/2
N7K(config-if)#rate-mode dedicated

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

Cisco Nexus 2000 FEX

N2k Fabric Extender (FEX) nada mais é do que uma continuação do Nexus7k ou 5k ( Line cards remotos)

solution_overview_c22-588237-5

São utilizados para eliminar os longos cabos nos DataCenteres, geralmente utilizado na topologia ToR ( Top of  Rack)

solution_overview_c22-588237-1

Imagine um Cisco 6500 com duas supervisoras e suas Line-Cards ( Modulos)

Pois bem, a idéia do Nexus é bem similar onde temos o Nexus 5k ou 7k como os Chassis (com suas supervisoras) em uma topologia EoR (End of Row)  e o Nexus 2k como seus Line-cards dependente  em uma topologia ToR ( Top of Rack) conforme a figura acima:

Toda a gerencia do Nexus2k é realizada pelo Nexus5k ou 7k, não existe console ou vty no Nexus 2k

O NX-OS faz automaticamente o download do Switch Parente ( Nexus 5k ou Nexus 7k)

Não faz local Switching

Tráfego entre portas locais no FEX deve fluir para o “norte” via Uplink com Switch Parent (5k ou 7k) e voltar para o “sul”

Traduzindo…

O tráfego irá de dois servidores interligados no mesmo FEX, percorre até o SwitchParent e volta para FEX até ser entregue ao servidor de destino.

Diferenças entre Nexus 5k e Nexus 7k como SwitchParente:

Nexus 5k :

Suporta Static Pinning e vPC

Vamos entender o que vem a ser um Pinnging estático:

FEX_static_pinning

Digamos que você tenha 4 Uplinks entre o Nexus2k e o Nexus 5k, onde no FEX você tenha 48 portas.

As portas de 1-12 irão respeitar o Uplink 1 ( Quando falamos de CAM)

As portas de 13-24 irão respeitar o Uplink2

As portas de 25-36 irão respeitar o Uplink3

As portas de 37-48 irão respeitar o Uplink4

Nexus 7k como SwitchParent:

  • Nem todas as Line Cards suportam FEX
  • Pinning estático SOMENTE
  • Fex deve ser um Port-Channel
  • Portas FEX L2 switchport ou interface roteada L3

solution_overview_c22-588237-3

Configurando FEX

Utilizaremos a seguinte topologia:

1111

Primeira coisa a ser feita é inicializar a feature-set FEX no Nexus 5k

feature fex

2

Verifique as interfaces selecionadas

3

Após veja quais os “Line cards” (Nexus 2k) o SwitchParent encontrou:

4

install feature-set fex  & feature fex  no Nexus 7k

5

Voltando ao Nexus 5k… Entre nas interfaces e coloque-as como switchport mode fex

6

Então para configurar os downlinks para FEX

switchport mode fex

fex associate [num]

No Nexus 7k é necessário crair um Port-Channel

8

10

11

Repare que as portas do Nexus 2k irá aparecer como FEX 102 (conforme configurado anteriormente) fazendo Pinning automático

Para verificar se o SwitchParent  descobriu o FEX digite o comando: show fex detail

9

 

NX-OS fará o download para o FEX em alguns minutos

Uma vez o download concluído, o FEX deverá aparecer normalmente no SwitchParent

Atenção: No Nexus 7k , o modulo M1, fazendo FEX não suporta CDP

Se você estiver usando Nk-C2232-10GE, lembre-se de alterar o SPEED, caso esteja conectado a uma interface GE

12

 

 

13

 

Virtual Device Contexts é uma técnica utilizada nos Cisco Nexus 7000 para virtualizar  o Hardware, muito similar ao SDRs do IOS-XR e ao Contexts do Cisco ASA

VDC também pode virtualizar os protocolos de  Control Plane do Nexus 7000 ( diferentemente de VLAN e VRFs)

– Separa o control-plane por VDC.

        Exemplo: Vlan10  no VDC1 não é a mesma Vlan10 no VDC2

                             OSPF1 no VDC1 não é o mesmo  OSPF1 no VCD2

Então…. Por que usar VDC?

  • Multiplas régras lógicas por Chassi físico:

                           Ex.: Core & Agregação(Distribuição)  na mesma caixa;

VDC DESIGN

  • Multi-Tenancy ( Alocação);
  • Ter a possibilidade de testar features fora da área de produção;
  • Algumas features não podem co-existir no mesmo VDC:

                                 Exemplo:  OTV e inteface VLAN (SVIs)

  • Separação de interfaces F1 e M1 para cada VDC.

Limitações de VDCs:

  • 4  VDCs por Chassi com SUP1
  • 4+1 VDCs por Chassi com SUP2
  • 8+1 VDCs por Chassi com SUP2E*
  • Não existe comunicação entre VDCs, muito similar ao VRF
  • Cabos físicos podem ser conectados para interconectar VDCs

Configuração Default:

  • Nexus 7k já vem por default com VDC1 não pode ser removido
  • Usado para criar e gerenciar outros VDCs

Alocação de portas por VDCs: Por default, todas as interfaces estão associadas na VDC1

Alocação de recursos: Números de VLANs, VRFs e tabela de roteamento;

  • Pode ser usada para operações normais de DataPlane
  • Recomendada para gerenciar o Chassis SOMENTE

Tarefas do VDC default:

  • Criar, modificar e suspender VDCs
  • Alocação de recursos – Interfaces, memórias e etc…
  • NX-OS Upgrade através de todos os VDCs
  • ISSU ou EPLD Upgrade
  • Capturas de EtherAnalyzer – Tráfego de Control Plane
  • Instalação de Feature-set para o Nexus 2k, FabricPath e FCoE
  • Control Plane Policing (CoPP)
  • Port Channel Load Balance hash
  • Controle de checagem de hardware IDS
  • Captura de ACL
  • System-Wide QoS

Criando uma VDC: 

O VDC deriva de VDC hostname+VDC name: combined-hostname

Ex.:  N7k-1-N7k-2#

Alocando interfaces no VDC:

A alocação das interfaces deve seguir as limitações do port-group

Exemplo: N7k-M132XP-12  tem 4 portas pares e 4 impares:

group1 = 1,3,5,7   group2 = 2,4,6,8

N7k-F132XP-15 tem duas portas por grupo:

group1 = 1,2   group2  = 3,4

Limitações dos recursos no VDC:

Cada VDC tem seus recursos limitados definidos:

VLAN, VRF, PortChannel, SPAN,ERSPAN, IPv4 e IPv6 Unicast  e Multicast Routing table e tipos de módulos.

Configurado como:

limit-resource      abaixo do modo de configuração do VDC

vdc resource template     no modo global

Movendo-se entre VDCs:

Administradores podem trocar de VDCs com o comando switchto que é muito similar ao changeto context do CISCO ASA

switchback  Comando para voltar a VDC default

Gerenciando VDC:

Pela interface CMP

Pela interface mngt0 que faz overlaps entre todos os VDCs

  • Um IP e MAC  separado para cada VDC

As features telnet e ssh estão em off por default

Cada VDC tem um user owner em seu database

Usuários VDC:

vdc-admin: Acesso FULL

vdc-operator: Acesso somente leitura

vdc-admin e vdc-operator não podem fazer switchback para VDC default

Os usuários da VDC default herdam os privilégios de leitura/escrita ou só leitura dos VDCs não-default.

network-admin: Assume todas as regras do vdc-admin

network-operator: Assume todas as regras do vdc-operator

VDC  HA – Alta disponibilidade:

As políticas de HA são definidas quando ocorre um CRASH no VDC

  • Restart VDC, Bringdown DVC, reload SUP, Switchover to Standby SUP
  • As políticas de HA são diferentes dependendo do número de supervisoras no chassi.
  • Configurado como ha-policy abaixo da configuração de VDC

Configurando:

1

2

34 5

Já temos o primeiro CCIE Data Center, é o Canadense  Robert Burns.

ca.linkedin.com/pub/robert-burns/10/755/bb

Tive o prazer de trocar algumas “figurinhas” com ele via twitter @cciedatacenter.

Parabéns ao Robert e que isso sirva de estimulo para todos nós!

Nada é impossível para aquele que crer!

CCIEdc

Management

Vamos abortar agora um tópico muito importante, GERENCIAMENTO.

No nosso LAB de DataCenter, usaremos a seguinte topologia de gerenciamento da rede.

mgmt0

Verifique que o tráfego é totalmente OUT-OF-BAND (OOB)

mgmt1

mgmt2

Se você tentar pingar o dispositivo… não irá responder… Pois eles só funcionam na mesma vrf ( management)

mgmt3

Então… pingando via vrf management, você obterá sucesso!

mgmt4

Repare que nesse momento, você já consegue encontrar somente o seu Physical Fabric ( LOCAL), pois a distribuição está desabilitada:

mgmt5

Com o comando show cfs status, você  percebe que a distribuição está habilitado, mas não sobre IP ou Ehternet:

mgmt6

Para habilitar a distribuição via IPv4 e Ethernet, segue abaixo os comandos:

mgmt7

Então… já consegue receber o WWN do viziho:

cfs2

mgmt8

Lembrando sempre que o Servidor NTP fará parte da rede de gerencia, ou seja, 192.168.0.10/24

ntp

Relembrando alguns comandos de verificação de NTP:

show ntp status

show ntp session status

show ntp peers-status

show clock

———————————————————

SPAN, RSPAN, ERSPAN, EthAnalyzer

SPAN – Switchport Analyzer

Usado para redirecionar (espelhar) um determinado tráfego para uma porta específica ( rodando sniffer)

RSPAN –  Remote SPAN

Quando a origem do tráfego não pertence a mesma switch, conforme topologia abaixo:

erspan

É necessário a criação de uma VLAN específica para passar o tráfego remote-span:

11

112

Quando falamos de NX-OS,  usamos o ERSPAN, a lógica é basicamente a mesma, porém o tráfego é passado via GRE

erspann

Output do ERSPAN no NX-OS

show erspan

EthAnalyzer

Nada mais é do que um Wireshark dentro da Supervisora do Nexus, porém BEM LIMITADO!

Ethanalyse1

Salvando o .pcap no NX-OS

Ethanalyse2

Para uma maior abordagem, sugiro o seguinte material:

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/ps9512/white_paper_c11-554444.html

O Cisco Fabric Services ( CFS ) é usado para sincronizar configurações  algumas features entre chassis.

Exemplos: NTP, AAA, RBAC, Call Home, Config Sync

Também sincroniza Control Plane de algumas features entre chassis:

Exemplos: ARP, ICMPv6 ND, IGMP Snooping over vPC

Suporta o transporte vie Ethernet (CFS0E), IP (CFSoIP) e IPv6 (CFSoIPv6)

O transporte depende da aplicação.

Comando para verificação:

show cfs application

Obs.: O Escopo também pode ser setado por região  cfs region,  porém em chassis em diferentes regiões não sincronizam!

cfs

Vamos dar início aos estudos, começando pelo setup inicial do Nexus.

Toda vez que você “starta” um Nexus do zero, ele irá mostrar esse promtp:

initial

Digite: no

Após isso, o  Nexus irá solicitar que você entre com a senha de admin, conforme print abaixo:

initial2

Após colocar a senha de admin, irá aparecer um prompt para colocar a senha e iniciar os trabalhos:

initial3

Como no Catalyst IOS, o NX-OS irá lhe propor um setup de configuração, geralmente não uso essa opção:

initial5

Pronto, você já está no modo privilegiado do NX-OS. Assim como no IOS, para entrar no modo de configuração global, digite: configure terminal

Vejamos agora, alguns comandos de verificação comuns ao IOS:

show running-config

initial6-show-run

show interface status

initial7-show-interface-status

Repare que o NX-OS usa sempre a nomenclatura “Eth” independentemente da sua velociadade (10/100/1000/10000)

show ip interface brief

initial9-sho-ip-int-brief

show interface Ethernet1/1

initial10-sh-int-e1

Vimos o exemplo do Nexus 5k,  agora vejamos no Nexus7k

initial7k1

Dando um show running-config no Nexus 7000:

initial7k-shrun

Lembrando que todos os processos/features são licenciados e ativados  individualmente:

show feature 

show feature

show license 

license

O comando license grace-period  serve no caso para você testar uma determinada feature

Caso queira instalar qualquer feature, é bem simples….

digite o comando feature < feature desejada>

Ex.:  feature ospf

feature

Lembrando que TODAS as features vem, por default OFF.

show license file < nome do arquivo>

license file

Segue abaixo o procedimento para realização do BackUp da licença:

bakcup

backup2

High availability

show inventory

Supervisora redundante

Power Supply redundante

Line card redundante

ha

show environment power 

enviroment power

power redundance

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…