O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como implantar duas estruturas EVPN VXLAN individuais e como mesclar essas duas estruturas em uma implantação de estrutura de vários sites EVPN usando o Cisco Data Center Manager (DCNM) 11.2(1).
O domínio de vários sites (MSD), apresentado na versão 11.0(1) do DCNM, é um contêiner de várias malhas criado para gerenciar várias malhas de membros. É um ponto único de controle para uma definição de redes de sobreposição e Virtual Routing and Forwarding (VRF) que são compartilhados pelas malhas de membros.
Observação: este documento não descreve os detalhes com relação às funções/propriedades de cada guia no DCNM. Consulte Referências no final que não abordam explicações detalhadas.
A Cisco recomenda que você tenha conhecimento destes tópicos:
vCenter/UCS para implantar máquina virtual DCNM
Familiaridade com NX-OS e Nexus 9000s
ToRs e EoRs do Nexus 9000s conectados de forma leaf/spine
As informações neste documento são baseadas nos seguintes softwares e hardwares:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Etapa 1. No vCenter, implante o modelo OVF (Open Virtualization Format) no servidor/host de sua escolha, como mostrado na imagem.




Etapa 2. Depois de concluir, inicie sua VM DCNM, conforme mostrado aqui.


Etapa 3. Inicie o console da Web, uma vez no console, você deverá ver estes prompts (o IP difere, pois é específico ao seu ambiente e à sua configuração):

Etapa 4. Vá para https://<seu IP>:2443 (Este é o IP que você configurou anteriormente durante a implantação do OVA) e clique em Comece agora. Neste exemplo, uma instalação Fresh é abordada.

Etapa 5. Depois de configurar a senha do administrador, você deve selecionar o tipo de malha que deseja instalar. Selecione entre LAN ou FAB, já que cada tipo tem um propósito diferente, portanto, certifique-se de entender e escolher corretamente. Para este exemplo, a estrutura de LAN é usada, ela é para a maioria das implantações de VXLAN-EVPN.

Etapa 6. Siga os prompts do instalador com o DNS, o servidor Network Time Protocol (NTP), o nome de host DCNM da sua rede, etc.

Etapa 7. Configurar o IP e o gateway de gerenciamento. A rede de gerenciamento fornece conectividade (SSH, SCP, HTTP, HTTPS) ao Servidor DCNM. Esse também é o IP que você usa para acessar a GUI. O endereço IP deve ser pré-configurado a partir da instalação do OVA feita anteriormente.


Etapa 8. Configurar a rede in-band. A rede In-Band é usada para aplicativos como o Localizador de Endpoint, que requer conectividade de porta do painel frontal com os 9Ks na estrutura para funcionar como uma sessão de BGP (Border Gateway Protocol) estabelecida entre o DCNM e os 9K.

Etapa 9. Configurar a Rede Interna de Serviços de Aplicações —
Para começar com a versão 11.0 do DCNM, o DCNM oferece suporte ao Application Framework (AFW) com a instalação DCNM LAN OVA/ISO. Essa estrutura usa o Docker para orquestrar aplicativos como microsserviços em ambientes de cluster e sem cluster para realizar uma arquitetura de dimensionamento horizontal.
Outros aplicativos que são enviados por padrão com o DCNM são o localizador de endpoint, a torre de observação, o plug-in do Virtual Machine Manager, a conformidade de configuração etc. O AFW cuida do gerenciamento do ciclo de vida desses aplicativos, incluindo o fornecimento de rede, armazenamento, autenticação, segurança, etc. O AFW também gerencia a implantação e o ciclo de vida dos aplicativos Network Insights, ou seja, NIR e NIA. Essa sub-rede é para serviços de Docker quando você tem NIA/NIR habilitado.
A seção Operações do dia 2 aborda como instalar o NIA/NIR.

Note: Essa sub-rede não deve se sobrepor às redes atribuídas às interfaces eth0/eth1/eth2 atribuídas ao DCNM e aos nós de computação. Além disso, essa sub-rede não deve se sobrepor aos IPs alocados aos switches ou a outros dispositivos gerenciados pelo DCNM. A sub-rede escolhida deve permanecer consistente durante a instalação dos nós principal e secundário do DCNM (no caso de uma implantação de HA nativa).
Etapa 10. Revise e confirme todos os detalhes da configuração e inicie a instalação.

Etapa 11. Quando o DCNM estiver totalmente instalado, faça login na GUI (endereço IP ou nome do host que você configurou anteriormente).
Etapa 1. Na GUI do DCNM, navegue até o Fabric Builder. Control > Fabrics > Fabric Builder para criar sua primeira malha.

Etapa 2. Clique em Create Fabric e preencha os formulários conforme necessário para sua rede — Easy Fabric é o modelo correto para a implantação de EVPN VXLAN local:

Etapa 3. Preencher os requisitos de subjacência, sobreposição, vPC, replicação, recursos, etc. da estrutura.
Esta seção abrange todas as configurações de Sobreposição, Sobreposição, vPC, Replicação etc. necessárias via DCNM. Isso depende do esquema de endereçamento de rede, requisitos, etc. Para este exemplo, a maioria dos campos são deixados como padrão. O L2VNI e o L3VNI foram alterados de forma que os L2VNIs começam com 2 e os L3VNIs começam com 3 para facilitar a solução de problemas posteriormente. A Detecção de Encaminhamento Bidirecional (BFD - Bidirectional Forwarding Detection) também é habilitada junto com outros recursos.




Etapa 4. Na configuração de bootstrap, configure o intervalo de endereços DHCP que você deseja que o DCNM distribua aos switches na estrutura durante o processo POAP. Configure também um gateway padrão apropriado (existente). Clique em Save quando terminar e agora você poderá adicionar switches à malha.

Etapa 1. Navegue até Control > Fabrics > Fabric Builder e selecione sua estrutura. No painel do lado esquerdo, clique em Add Switches, conforme mostrado na imagem.

Você pode descobrir switches usando um IP semente (o que significa que o IP mgmt0 de cada switch deve ser configurado manualmente) ou pode descobrir os switches via POAP e fazer com que o DCNM configure todos os endereços IP mgmt0, gerenciamento VRF, etc. Para este exemplo, usaremos POAP.
Etapa 2. Quando vir o(s) switch(es) de seu interesse, insira o endereço IP e o nome de host desejados para o DCNM, insira Admin PW e clique em Bootstrap, como mostrado na imagem.

Um registro de inicialização bem-sucedido deve ser semelhante ao mostrado na imagem aqui do console do switch.


Etapa 3. Antes de implantar a configuração para a malha inteira, certifique-se de ter configurado previamente o DCNM com as credenciais do dispositivo. Um pop-up deve aparecer na GUI quando você faz login. Caso isso não aconteça, você sempre poderá acessá-lo via Administração > Gerenciamento de credenciais > Credenciais de LAN.
Note: Se as credenciais do dispositivo estiverem ausentes, o DCNM não enviará a configuração aos switches.


Etapa 1. Depois de descobrir todos os switches da malha especificada usando as mesmas etapas, navegue para Controle > Malhas > Fabric Builder > <sua malha selecionada>. Você deve ver seus switches junto com todos os seus links aqui. Clique em Salvar e implantar.

Etapa 2. Na janela Config Deployment, você verá quantas linhas de configuração para cada switch DCNM envia. Você também pode visualizar a configuração, se desejar, e comparar o antes e o depois:

Verifique se todos os switches estão no estado COMPLETED e 100% sem erros — Se houver erros, certifique-se de resolvê-los um de cada vez (consulte a seção Problemas encontrados durante esta implantação para obter exemplos)

Etapa 3. (Opcional) Você pode fazer login nos dispositivos neste ponto e emitir qualquer CLI show run para verificar se a configuração foi enviada com êxito pelo DCNM.
Exemplo:

Execute as mesmas etapas como antes com a estrutura RTP usando valores diferentes para BGP AS, etc.
Etapa 1. Navegue até Controle > Malhas > Fabric Builder > Criar malha > Nomeá-la!
Esta seção abrange todas as configurações necessárias de Sobreposição, Sobreposição, vPC, Replicação, etc. Isso depende do esquema de endereçamento de rede, requisitos, etc.
Note: O MAC do gateway Anycast aqui deve corresponder ao outro Fabric se o Multi-Site for usado, mais tarde, não há suporte para MACs diferentes do gateway Anycast. Isso foi corrigido mais tarde durante a seção Implantação em vários sites (não mostrado no artigo para ser breve).


Etapa 2. Configurar a seção de bootstrap como feito antes. Navegue por Add Switches novamente. Quando todos forem descobertos, clique em Save & Deploy para implantar a configuração. Tudo isso foi abordado na seção Implantação de estrutura RTP (omitindo aqui para resumir).

Topologia da perspectiva do Fabric Builder no final.

Idealmente, todos os switches devem aparecer em verde junto com seus links. Esta imagem mostra as diferentes cores de status na média DCNM.

Etapa 3. Depois que as duas malhas estiverem configuradas e implantadas, certifique-se de salvar a configuração e recarregar para que as alterações de TCAM entrem em vigor. Vá para Controles > Fabrics > Fabric Builder > <sua malha>, navegue para Visualização tabular, como mostrado na imagem.

Etapa 4. Em seguida, clique no botão power (isso recarrega todos os switches simultaneamente):

Etapa 1. Navegue até Control > Fabrics > Networks, conforme mostrado na imagem.

Etapa 2. Como mostrado na imagem, selecione o Escopo da alteração. ou seja, a qual estrutura essa configuração precisa ser aplicada?

Etapa 3. Clique no sinal +, conforme mostrado na imagem.

Etapa 4. O DCNM o orienta no processo de criação da interface virtual do switch (SVI) (ou VLAN L2 pura). Se nenhum VRF for criado nesse estágio, clique no botão + novamente e isso o levará temporariamente para o passo a passo de VRFs antes de prosseguir com as configurações de SVI.



Esses recursos podem ser configurados na guia Avançado:
Etapa 5. Clique em Continue para implantar a configuração Network/VRF.

Etapa 6. Clique duas vezes em um dispositivo (ou dispositivos) na exibição da topologia (o DCNM o leva automaticamente até aqui) para selecioná-los para a configuração aplicável. Clique em Save, conforme mostrado na imagem.

Etapa 7. Uma vez selecionados, os switches devem ficar azuis (Prontos para implantar), como mostrado nesta imagem.



Observação: se quiser verificar a configuração da CLI antes da implantação, você pode clicar em Detail View em vez de Deploy e clicar em Preview na próxima tela.
Os switches ficam amarelos enquanto a configuração é aplicada e retornam para verde quando ela é concluída.
Etapa 8. (Opcional) Você pode fazer login na CLI para verificar a configuração, se necessário (lembre-se de usar a opção expand-port-profile):

Para essa implantação inicial, a malha MSD é implantada por meio de peering direto entre Border Gateways (BGWs). Uma alternativa é usar um servidor de roteamento centralizado, não abordado neste documento.
Etapa 1. Navegue até Controle > Fabric Builder > Criar estrutura, como mostrado na imagem.

Etapa 2. Dê um nome à Malha multisite e escolha MSD_Fabric_11_1 na lista suspensa Modelo de malha.
Etapa 3. Em Geral, certifique-se de que suas faixas L2 e L3 VNI correspondam ao que suas malhas individuais estão usando. Além disso, o MAC do Gateway Anycast deve corresponder em ambas as malhas (RTP/SJ neste exemplo). O DCNM apresentará um erro se os MACs do Gateway forem incompatíveis e precisarem ser corrigidos antes de prosseguir com a implantação do MSD.



Etapa 4. Clique em Salvar, navegue até a malha do MSD e clique em Salvar e implantar. Sua topologia deve ser semelhante a estas (todos os switches + links verdes) depois de concluída com êxito:


Para este exemplo, troncos vPC de dois pares VTEP diferentes são configurados e testam a conectividade dentro da estrutura RTP local. Topologia relevante conforme mostrado na imagem:

Etapa 1. Navegue até Control > Fabrics > Interfaces, conforme mostrado na imagem.

Etapa 2. Clique no sinal + para entrar no assistente para Adicionar uma Interface, como mostrado na imagem.

Neste exemplo, um tronco vPC é criado no downstream para o N7K, que é usado para fazer ping nos testes nessa passagem.
Etapa 3. Selecione o par vPC apropriado, interfaces físicas, LACP ativado/desativado, BPDUGuard, etc.


Etapa 4. Clique em Save quando terminar. Como alternativa, você pode implantar diretamente, como mostrado na imagem.


Etapa 5. (Opcional) Revise a configuração a ser aplicada.


Etapa 6. (Opcional) Configuração manual em 7K:

Etapa 7.(Opcional) Criar uma SVI de teste em N7K para fazer ping nos VTEPs em RTP (os VTEPs têm o gateway Anycast de 10.212.20.1 em VRF e rea_red):

Etapa 8. (Opcional) Verifique se outros VTEPs no RTP veem este host via EVPN/HMM:

Etapa 9.(Opcional) Repita o mesmo processo para seoul-bb11/12 (criar canal de porta vPC, criar SVI 2300). Efetuando ping de RTP-Esquerda para RTP-Direita para confirmar a conectividade de L2 sobre EVPN na Estrutura RTP:

Etapas semelhantes podem ser seguidas para criar canais de porta não-vPC, interfaces de acesso, etc no contexto Adicionar interfaces.
Etapa 1. Carregue uma imagem (ou um conjunto de imagens no servidor do DCNM) e navegue para Control > Image Management > Image Upload, conforme mostrado na imagem.

Etapa 2. Siga os prompts para um upload local, então o(s) arquivo(s) deve(m) aparecer(m) como mostrado(s) nesta imagem:


Etapa 3. Depois que os arquivos forem carregados, você poderá prosseguir para Instalação e atualização se os switches precisarem de uma atualização. Navegue para Controle > Gerenciamento de imagem > Instalar e atualizar, como mostrado na imagem.

Etapa 4. Selecione os switches que você gostaria que fossem atualizados. Para este exemplo, toda a malha RTP é atualizada.

Etapa 5. Selecionar a versão do NX-OS para a qual você deseja atualizar os switches (como prática recomendada, atualizar todos os switches para a mesma versão do NX-OS):

Etapa 6. Clique em Next e o DCNM executará os switches através de verificações de pré-instalação. Essa janela pode demorar um pouco, então você pode selecionar Concluir instalação mais tarde e agendar a atualização enquanto estiver ausente.

Isso enfileira a tarefa e é semelhante ao mostrado na imagem aqui, depois de concluído.

Observação: a exceção no caso acima foi que um dos switches RTP não tinha espaço suficiente para a imagem do NX-OS.
Etapa 7. Uma vez concluída a compatibilidade, clique em Finish Installation na mesma janela, como mostrado na imagem.

Etapa 8. Você pode selecionar as atualizações a serem feitas simultaneamente (todas ao mesmo tempo) ou sequenciais (uma de cada vez). Como este é um ambiente de laboratório, a opção selecionada é simultânea.

A tarefa é criada e aparece EM ANDAMENTO, como mostrado na imagem.


Uma maneira alternativa de selecionar a imagem é mostrada aqui.


Para que os aplicativos DCNM funcionem corretamente, você deve ter conectividade em banda entre o servidor DCNM e uma porta de painel frontal para um dos Nexus 9000s na estrutura. Para este exemplo, o Servidor DCNM está conectado à Ethernet1/5 de um dos Spines na Estrutura RTP.
Etapa 1. Esta CLI é adicionada manualmente ao Nexus 9000:

Etapa 2. Certifique-se de que você possa fazer ping no Servidor DCNM e vice-versa nessa conexão ponto a ponto.

Etapa 3. Navegue até DCNM GUI > Control > Endpoint Locator > Configure, conforme mostrado na imagem.

Etapa 4. Selecione a estrutura em que deseja que o localizador de endpoint esteja habilitado, como mostrado na imagem.

Etapa 5. Como mostrado na imagem, selecione um Spine.

Etapa 6. (Opcional). Antes de passar para a próxima etapa, o IP da eth2 foi alterado da implantação original por meio dessa CLI no Servidor DCNM (essa etapa não é necessária se o IP original configurado durante a nova instalação do Servidor DCNM permanecer correto):

Etapa 7. Verificar a configuração da interface in-band. Isso deve corresponder ao que foi configurado na etapa anterior.


Etapa 8. Depois de revisar a configuração, clique em Configure. Esta etapa pode levar alguns minutos:

Uma vez concluída, a notificação, conforme mostrado na imagem, é exibida.

Observe que o DCNM configurou um vizinho BGP no Spine selecionado na família L2VPN EVPN.

Etapa 9. Agora você pode usar o Localizador de Ponto Final. Navegue até Monitor > Endpoint Locator > Explorar.

Neste exemplo, você pode ver os dois hosts que foram configurados para os testes de ping local na Estrutura RTP:

Um par de switches tinha cabeamento ruim, o que causou um erro de empacotamento para o canal de porta 500 do link par do vPC. Exemplo:

Etapa 1. Navegue de volta para Controle > Fabric Builder e revise os erros:

Etapa 2. Para o primeiro erro referente à falha do comando port-channel500 — Verificado via show cdp neighbors que a conexão com o peer do vPC estava em uma porta 10G e 40G (não compatível). Removida a porta 10G fisicamente e excluído o link do DCNM também:


Pelo segundo erro relacionado à falha na configuração do "recurso ngoam" — O switch foi atualizado para uma versão mais recente do NX-OS, na qual há suporte para o "recurso ngoam", e clique em Salvar e implantar novamente. Ambos os problemas foram resolvidos.
Enquanto a segunda malha é implantada, SJ, a mesma sub-rede foi usada (se fisicamente separada, deve ser OK); no entanto, o DCNM registra um conflito e o POAP falha. Isso é resolvido à medida que a estrutura SJ é colocada em uma VLAN de gerenciamento diferente e altera o intervalo dos endereços DHCP.


Etapa 1. Para interfaces breakout em alguns dos switches (consulte a topologia), esta CLI foi adicionada manualmente para os T2 Spines:

Etapa 2. Navegue até Control > Interfaces e exclua as interfaces pai:

As interfaces realmente usadas são Eth1/6/1-4 e Eth1/7/1-4. Se você não corrigir isso, a opção Salvar e implantar falhará mais tarde. Há uma maneira de fazer a reunião à parte pelo próprio DCNM (botão ao lado do sinal +; no entanto, não abrangidos por este artigo)


Alguns dos chassis (T2s) no SJ Fabric não oferecem suporte ao TRM; portanto, quando o DCNM tentou forçar essa configuração, ele não conseguiu avançar. Suporte a TRM aqui: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/92x/vxlan-92x/configuration/guide/b-cisco-nexus-9000-series-nx-os-vxlan-configuration-guide-92x/b_Cisco_Nexus_9000_Series_NX-OS_VXLAN_Configuration_Guide_9x_chapter_01001.html#concept_vw1_syb_zfb
Desmarcada a caixa TRM Enable nas janelas Network e VRF Edit é mostrada na imagem.
Repita o mesmo processo em Control > Fabric Builder > VRF.



Clique em Continuar e em Implantar, respectivamente, como feito anteriormente.
Peering de estrutura vPC
Estruturas roteadas baseadas em eBGP
Ativar EVPN no início
Melhorias fáceis no campo de malha
Coluna da borda/Coluna da borda GW
PIM Bidir
Multicast Roteado pelo Locatário
Dia-0/Bootstrap com servidor DHCP externo
Operações do Dia 2:
Recursos do Network Insights
Consultor de insights de rede
Suporte IPv6 para acesso externo (eth0)
Visibilidade de computação do VMM com UCS-FI
Aprimoramentos da exibição de topologia
Atualização em linha de 11.0/11.1
Mudança de vPC tradicional para vPC sem MCT usando DCNM:
Benefícios do vPC sem MCT:
Solução dual-homing aprimorada sem desperdiçar portas físicas
Preserva as características tradicionais do vPC
Roteamento otimizado para endpoints single homed com PIP
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
19-Sep-2019
|
Versão inicial |
Feedback