VMware Hands-on Labs - HOL-1703-SDC-1-PT


Visão geral do laboratório - HOL-1703-SDC-1 - Tour de recursos do VMware NSX

Orientação de laboratório


Observação: a conclusão deste laboratório levará mais de 90 minutos. Espera-se que você termine apenas de 2 a 3 módulos durante o horário disponível para você.  Os módulos são independentes uns dos outros para que você possa começar do início de cada módulo e prosseguir de onde parou. Use o Índice para acessar qualquer módulo à sua escolha.

Ele pode ser acessado no canto superior direito do Manual do laboratório.

O VMware NSX é a plataforma de virtualização de rede do data center definido por software (SDDC) e o principal foco deste laboratório. Neste laboratório, guiaremos você pelos recursos básicos do NSX. Primeiro acompanharemos uma instalação típica do NSX e de todos os componentes necessários. Em seguida, veremos a comutação e o roteamento lógicos para que você compreenda melhor esses conceitos. Depois abordaremos o gateway de serviços do Edge e como ele oferece serviços comuns, como DHCP, VPN, NAT, roteamento dinâmico e balanceamento de carga. Por fim, abordaremos como criar uma ponte entre uma VLAN física e uma VXLAN e então o firewall distribuído. A lista completa de módulos de laboratório é mostrada abaixo e todos os módulos são totalmente independentes, de forma que você possa se mover livremente entre eles.

Lista de módulos de laboratório:

Chefes do laboratório:

Este manual de laboratório pode ser obtido por download no site de Documentos do laboratório prático que se encontra aqui:

[http://docs.hol.pub/HOL-2017]

Este laboratório pode estar disponível em outros idiomas.  Para definir sua preferência de idioma e ter um manual localizado implantado com seu laboratório, você pode usar este documento para orientá-lo pelo processo:

http://docs.hol.vmware.com/announcements/nee-default-language.pdf


 

Local do console principal

 

  1. A área dentro da caixa VERMELHA contém o console principal.  O Manual do laboratório está na guia à direita do console principal.
  2. Um laboratório específico pode ter outros consoles em guias separadas na parte superior esquerda. Se necessário, você será direcionado para abrir outro console específico.
  3. Seu laboratório começa com 90 minutos no cronômetro. Não é possível salvar o laboratório. Você deve fazer todo o seu trabalho durante a sessão do laboratório. No entanto, é possível clicar em EXTEND para estender o tempo. Se você estiver em um evento da VMware, poderá estender o tempo do laboratório duas vezes, por no máximo 30 minutos. Cada clique acrescenta 15 minutos. Fora de eventos da VMware, você pode estender o tempo do seu laboratório por no máximo nove horas e 30 minutos. Cada clique acrescenta uma hora.

 

 

Métodos alternativos de entrada de dados por teclado

Durante este módulo, digite o texto no console principal. Além da digitação direta, há dois métodos muito práticos que facilitam a entrada de dados complexos.

 

 

Clicar e arrastar conteúdo do manual do laboratório para a janela ativa do console

Você pode também clicar e arrastar textos e comandos da interface de linha de comando (CLI, Command Line Interface) diretamente do Manual do laboratório para a janela ativa no console principal.

 

 

Acesso ao teclado internacional on-line

 

Você pode também usar o teclado internacional on-line do console principal.

  1. Clique no ícone de teclado que fica na barra de tarefas de Início Rápido do Windows.

 

 

Clicar uma vez na janela ativa do console

 

Neste exemplo, você utilizará o teclado on-line para inserir o sinal "@" usado em endereços de e-mail. Nos layouts de teclado US, pressione as teclas Shift+2 para inserir o sinal "@".

  1. Clique uma vez na janela ativa do console.
  2. Clique na tecla Shift.

 

 

Clicar na tecla @

 

  1. Clique na tecla "@".

Observe o sinal @ inserido na janela ativa do console.

 

 

Observe a parte inferior direita da tela

 

Verifique se foram concluídas todas as rotinas de inicialização do seu laboratório e se ele está pronto para você começar. Se aparecer algo diferente de "Ready", aguarde alguns minutos.  Após cinco minutos, se o laboratório ainda não aparecer como "Ready", peça ajuda.

 

 

Solicitação ou marca d'água de ativação

 

Quando você iniciar o laboratório pela primeira vez, talvez observe uma marca d'água na área de trabalho, que indica que o Windows não está ativado.

Um dos principais benefícios da virtualização é que as máquinas virtuais podem ser movidas e executadas em qualquer plataforma.  Os laboratórios práticos utilizam esse benefício, e é possível executá-los em vários data centers.  No entanto, esses data centers podem não ter processadores idênticos, o que aciona uma verificação de ativação da Microsoft pela Internet.

A VMware e os laboratórios práticos estão em total conformidade com os requisitos de licenciamento da Microsoft.  O laboratório que você está usando é um pod autocontido e não tem acesso completo à Internet, o que é necessário para que o Windows verifique a ativação.  Sem o acesso completo à Internet, esse processo automatizado falha e essa marca d'água é exibida.

Esse problema superficial não afeta seu laboratório.

 

Módulo 1 - Passo a passo da instalação (15 minutos)

Introdução à implantação do NSX (copied)


O VMware NSX é a plataforma líder de virtualização de redes que fornece o modelo operacional de uma máquina virtual para a rede. Assim como a virtualização de servidores oferece controle extensível de máquinas virtuais executadas em um pool de hardware de servidor, a virtualização de rede com o NSX oferece uma API centralizada para aprovisionar e configurar várias redes lógicas isoladas executadas em uma única rede física.

As redes lógicas separam a conectividade da máquina virtual e os serviços de rede da rede física, fornecendo aos provedores de nuvens e às empresas a flexibilidade de posicionar máquinas virtuais em qualquer lugar do data center ou de migrá-las para qualquer lugar do data center oferecendo, ainda assim, suporte à conectividade de camada 2/camada 3 e a serviços de rede de camada 4 a 7.

Neste módulo, nós nos concentraremos em como executar a implantação real do NSX em seu ambiente. No ambiente de laboratório, a implantação real já foi concluída para você.

Este módulo contém as seguintes lições:


 

Componentes do NSX

 

Neste laboratório, você acompanhará o processo necessário para a instalação dos diversos componentes, que incluem o NSX Manager, os NSX Controllers e depois a instalação dos módulos do kernel no hypervisor.

 

Simulação Interativa do Hands-on Labs: Instalação e Configuração do NSX


Esta parte do laboratório é apresentado como Simulação Interativa do Hands-on Labs. Esta simulação irá orientá-lo para a Instalação e Configuração do NSX Manager.

  1. Clique aqui para abrir a simulação interativa. A simulação será aberta em uma nova janela ou tab do browser
  2. Quando concluído, clique no link "Return to the lab" no canto superior direito da janela do browser ou feche a janela para continuar este laboratório.

Conclusão do Módulo 1 (copied)


Neste módulo, mostramos a simplicidade na qual o NSX pode ser instalado e configurado para começar a fornecer camada 2(L2) por meio de sete serviços no software.

Nós abordamos a instalação e a configuração do appliance do NSX Manager, que incluem a implantação, a integração com o vCenter e a configuração de registro em log e de backups. Depois disso, abordamos a implantação de NSX Controllers como a camada de controle e a instalação dos pacotes do VMware Infrastructure (vibs) que são módulos do kernel enviados por push para o hypervisor. Por fim, mostramos a implantação automatizada de endpoints de túnel de VXLAN (VTEPs), a criação de um pool de identificadores de rede de VXLAN (VNIs) e a criação de uma zona de transporte.


 

Você terminou o Módulo 1

Parabéns por concluir o Módulo 1.

Se você estiver procurando informações adicionais sobre a implantação do NSX, acesse o centro de documentação do NSX 6.2 por meio do URL abaixo:

Continue em qualquer módulo abaixo que seja do seu interesse:

Lista de módulos de laboratório:

Chefes do laboratório:

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END

 

Módulo 2 - Switch lógico (30 minutos)

Switch lógico - Visão geral do módulo


Neste laboratório, inicialmente você analisará os principais componentes do VMware NSX. Há outros aspectos principais abordados neste módulo:

1) A adição do cluster do NSX Controller eliminou o requerimento de suporte ao protocolo multicast no ambiente físico. O cluster de controllers oferece, entre outras funções, resolução de VTEP, IP e MAC.

2) Você criará um switch lógico e então anexará duas VMs ao switch lógico que criou.

3) Por fim, revisaremos o dimensionamento e a alta disponibilidade da plataforma NSX.


Switch lógico


Nesta seção:

  1. Confirmaremos que a configuração dos hosts está pronta.
  2. Confirmaremos a preparação de rede lógica.
  3. Criaremos um novo switch lógico.
  4. Anexaremos o switch lógico ao Gateway do NSX Edge.
  5. Adicionaremos VMs ao switch lógico.
  6. Testaremos a conectividade entre as VMs.

 


 

Iniciar o Google Chrome

 

Abra um navegador clicando duas vezes no ícone do Google Chrome na área de trabalho.

 

 

Fazer login no vSphere Web Client

 

Se você ainda não tiver feito login no vSphere Web Client:

(A página inicial deve ser o vSphere Web Client.  Caso contrário, clique no ícone da Barra de tarefas do vSphere Web Client para o Google Chrome).

  1. Faça login marcando a caixa "Use Windows Session Authentication".
  2. Clique em Login.

 

 

Navegue até a seção Networking & Security no Web Client

 

  1. Clique na guia Networking & Security.

 

 

Visualizar os componentes implementados

 

  1. Clique em Installation.
  2. Clique em Host Preparation.  

Você verá que os componentes do plano de dados, também chamados de virtualização de rede, são instalados nos hosts em nossos clusters. Esses componentes incluem o seguinte:  

módulos de kernel no nível do hypervisor para Port Security, VXLAN, firewall distribuído(Distributed Firewall-DFW) e roteamento distribuído. As funções de Firewall e VXLAN são configuradas e ativadas em cada cluster após a instalação dos componentes de virtualização de rede. O módulo de Port Security auxilia a função VXLAN, enquanto o módulo de roteamento distribuído é habilitado assim que a VM de controle de roteador lógico(Logical Router Control) do NSX Edge é configurada.

 

 

A topologia após a preparação do host com os componentes do Data Plane

 

 

 

Visualizar a configuração do VTEP

 

  1. Clique na guia Logical Network Preparation.
  2. Clique na guia VXLAN Transport.
  3. Clique no twistie para expandir os clusters.

A configuração da VXLAN pode ser dividida em três etapas importantes:

Como mostrado no diagrama, os hosts nos clusters de computação são configurados com os mesmos endpoints de túnel de VXLAN, VTEP. O ambiente usa a subnet 192.168.130.0/24 para o pool VTEP.

 

 

A topologia após a configuração dos VTEPs nos clusters

 

Um dos principais desafios que os clientes tinham com a implantação da VXLAN no passado é que o suporte ao protocolo multicast era necessário nos dispositivos de rede física. Esse desafio é endereçado na Plataforma NSX ao fornecer uma implementação de VXLAN baseada em controller, removendo qualquer necessidade de configuração multicast na rede física. Esse modo (Unicast) é o modo padrão, e os clientes não precisam configurar qualquer endereço multicast enquanto definem o pool de redes lógicas.

Se o modo de replicação multicast for escolhido por um determinado switch lógico, o NSX confiará no recurso multicast L2/L3 nativo da rede física para garantir que o tráfego de vários destinos encapsulados de VXLAN seja enviado para todos os VTEPs. Nesse modo, um endereço IP multicast deve ser associado a cada segmento L2 VXLAN definido (isto é, o switch lógico). O recurso multicast L2 é usado para replicar o tráfego para todos os VTEPs no segmento local (isto é, endereços IP do VTEP que façam parte da mesma subnet IP). Adicionalmente, IGMP snooping deve ser configurado nos switches físicos para otimizar a entrega de tráfego multicast L2.

O modo híbrido oferece uma simplicidade operacional semelhante ao modo unicast - a configuração de roteamento de multicast IP não é necessária na rede física - e aproveita o recurso multicast L2 dos switches físicos.

Dessa forma, os três modos de configuração de camada de controle são:

 

 

Configuração do ID do segmento e do endereço de grupo multicast

 

  1. Clique em Segment ID. Observe que a seção Multicast addresses acima está em branco.  Como mencionado acima, estamos usando o nó unicast padrão com uma implementação de VXLAN baseada em controller.

 

 

Definição de configurações da zona de transporte

 

  1. Clique em Transport Zones.
  2. Clique duas vezes em RegionA0_TZ.

Uma zona de transporte define a extensão de um switch lógico. As zonas de transporte definem quais clusters podem participar do uso de uma rede lógica em particular. À medida que você adicionar novos clusters ao seu datacenter, poderá aumentar a zona de transporte e, portanto, aumentar a extensão das redes lógicas. Uma vez que o switch lógico estiver se estendendo por todos os clusters de computação, consegue-se remover todas as barreiras de mobilidade que existiam antes por causa dos limites da VLAN.

 

 

Confirme os Clusters como membros da zona de transporte local

 

Confirme se todos os três clusters estão presentes na zona de transporte.

  1. Clique na guia Manage para mostrar os clusters que fazem parte dessa zona de transporte.

 

 

A topologia após a definição da zona de transporte

 

Depois de examinarmos os diferentes componentes NSX e a configuração relacionada da VXLAN, agora percorreremos a criação de uma rede lógica, também conhecida como switch lógico.

 

 

Volte para o menu Networking & Security

 

  1. Clique no botão History back para voltar para a última janela; no seu caso, o menu Networking & Security.

Se por acaso você tiver clicado em outra opção depois de visualizar a zona de transporte, volte para a seção Networking & Security do Web Client por meio do menu Home como feito nas etapas anteriores.

 

 

Criar um novo switch lógico

 

  1. Clique em Logical Switches no lado esquerdo.
  2. Clique no ícone "+" Verde para criar um novo switch lógico.
  3. Dê ao switch lógico o nome: Prod_Logical_Switch.
  4. Verifique se RegionA0_TZ está selecionado como a zona de transporte Observação: o modo unicast deveria estar selecionado automaticamente.
  5. Unicast deve ser selecionado automaticamente.
  6. Deixe a caixa Enable IP Discovery marcada.

A função IP Discovery ativa a supressão ARP.

A seleção da função IP Discovery ativa a supressão ARP (Address Resolution Protocol). O ARP é usado para determinar o endereço MAC (Media Access Controle) de destino de um endereço IP por meio do envio de um broadcast em um segmento de camada 2. Se o host ESXi com o NSX Virtual Switch receber tráfego ARP de uma VM (Máquina Virtual) ou de uma solicitação Ethernet, o host enviará a solicitação para o NSX Controller que possui uma tabela ARP. Se a instância do NSX Controller já tiver as informações em sua tabela ARP, elas serão retornadas ao host que responderá à máquina virtual.

7.     Clique em OK.

 

 

Anexe o novo switch lógico ao NSX Edge Services Gateway para acesso externo

 

  1. Destaque o switch lógico recém-criado.
  2. Clique com o botão direito do mouse em Prod_Logical_Switch e selecione Connect NSX Edge.

 

 

Conectar o switch lógico ao NSX Edge

 

O roteamento será descrito em mais detalhes no próximo módulo, mas, para obter conectividade da nossa VM do console principal e/ou outras VMs em nosso laboratório, para as VMs em nosso novo switch lógico, precisaremos conectá-las ao roteador. Como mencionado na seção de componentes, o NSX Edge poderá ser instalado de duas formas diferentes: Roteador distribuído e Gateway de perímetro.

Neste exemplo, você conectará o switch lógico ao NSX Edge Services Gateway (Perimeter-Gateway).

  1. Clique no botão de opção ao lado de Perimeter-Gateway.
  2. Clique em Next.

 

 

Conectar o switch lógico ao NSX Edge

 

  1. Clique no botão de opção ao lado de vnic7.
  2. Clique em Next.

 

 

Dê um nome à Interface e configure o seu endereço IP

 

  1. Nome da interface:  Prod_Interface.
  2. Selecione Connected.
  3. Clique no sinal "+" para Configure subnets (deixe as outras configurações como estão)

 

 

Atribuir um IP à interface

 

  1. Digite o endereço IP primário 172.16.40.1  (deixe o endereço IP secundário em branco)
  2. Digite 24 em Subnet Prefix Length.
  3. Verifique se as configurações estão corretas e clique em Next.

 

 

Concluir o processo de edição da interface

 

  1. Clique em Finish  (você verá o novo switch lógico mostrado na lista de switches lógicos)

 

 

A topologia após a conexão de Prod_Logical_Switch ao NSX Edge Services Gateway

 

Depois de configurar o switch lógico e de conceder acesso à rede externa, será o momento de conectar as máquinas virtuais do aplicativo Web a esta rede.

 

 

Acesse Hosts and Clusters

 

  1. Clique no botão Home.
  2. Clique em Hosts and Clusters.

 

 

Conectar as VMs ao vDS

 

Para poder adicionar as VMs ao switch lógico que criamos, precisamos garantir que o adaptador de rede das VMs esteja habilitado e conectado ao vDS correto.

  1. Clique no botão Hosts & Clusters.
  2. Expanda o twisty em RegionA01-COMP01.
  3. Selecione Web-03a.
  4. Selecione Manage.
  5. Selecione Settings.
  6. Selecione Edit.

 

 

Conectar e ativar a interface de rede

 

  1. Ao lado de Network Adaptor, clique no menu suspenso de interfaces.
  2. Selecione VM-RegionA01-vDS-COMP (RegionA01-vDS-COMP)
  3. Marque a caixa Connected ao lado dele.
  4. Clique em OK.

Repita as mesmas etapas para Web-04a, que você pode encontrar no cluster RegionA01-COMP2.

 

 

Anexe web-03a and web-04a ao Prod_Logical_Switch recém-criado

 

  1. Clique no botão home.

 

 

Voltar para Network  Security

 

  1. Clique em Networking & Security.

 

 

Selecione Logical Switches

 

  1. Selecione a guia Logical Switches.

 

 

Adicionar as VMs

 

  1. Clique para realçar o novo switch lógico criado.
  2. Clique com o botão direito do mouse e selecione o item de menu Add VM.

 

 

Adicionar Máquinas Virtuais a serem anexadas ao novo switch lógico

 

  1. Informe um filtro para localizar as VMs cujos nomes comecem com "web".
  2. Destaque as VMs web-03a e web-04a.
  3. Clique na seta para a direita para selecionar as VMs a serem adicionadas ao switch lógico.
  4. Clique em Next.

 

 

Adicionar vNICs das VMs ao switch lógico

 

  1. Selecione as vNiCs de duas VMs.
  2. Clique em Next.

 

 

Complete Add VMs to Logical Switch

 

  1. Clique em Finish.

 

 

Testaremos a conectividade entre Web-03a e Web-04a

 

 

 

Visualização de hosts e clusters

 

  1. Clique no botão Home.
  2. Selecione Hosts and Clusters no menu suspenso.

 

 

Expanda os clusters

 

 

 

Abra o Putty

 

  1. Clique em Iniciar.
  2. Clique no ícone do aplicativo Putty no Menu Start.

Você está se conectando do MainConsole, que está na subnet 192.168.110.0/24. O tráfego passará pelo NSX Edge e então pela Interface da Web.

 

 

Abra uma sessão SSH para web-03a

 

  1. Selecione web-03a.corp.local.
  2. Clique em Open.

**Observação - se web-3a não for mostrando como uma opção por algum motivo, você também poderá tentar colocar o endereço IP 172.16.40.11 na caixa Host Name.

 

 

Fazer login na VM

 

Observação: se você tiver dificuldade de se conectar a web-03a, revise suas etapas anteriores e verifique se elas foram concluídas corretamente.

 

 

Faça ping no web server web-sv-04a para mostrar a conectividade da camada 2

 

Lembre-se de usar a opção SEND TEXT para enviar este comando para o console. (Consulte a Orientação de laboratório)

Insira ping -c 2 web-04a para enviar somente 2 pings em vez de um ping contínuo.  OBSERVAÇÃO: web-04a tem o IP 172.16.40.12, você poderá fazer ping por IP em vez de por nome, se necessário.

ping -c 2  web-04a 

***Observe que talvez você veja pacotes duplicados. Isso se deve à natureza do ambiente de laboratório da VMware que está sendo também virtualizado. Isso não acontecerá em um ambiente de produção.

****Não feche sua sessão do Putty. Minimize a janela para uso posterior.

 

Escalabilidade/disponibilidade


Nesta seção, você examinará o dimensionamento e a disponibilidade dos Controllers. O cluster de controllers na plataforma NSX é o componente da camada de controle responsável pelo gerenciamento dos módulos de switch e de roteamento nos hypervisors. O cluster de controllers consiste em nós de controllers que gerenciam switches lógicos específicos. O uso de um cluster de controllers no gerenciamento de switches lógicas baseados em VXLAN elimina a necessidade de suporte multicast da infraestrutura de rede física.

Para obter resiliência e desempenho, as implantações de produção devem instalar um cluster do controllers com vários nós. O cluster do NSX controller representa um sistema distribuído de dimensionamento horizontal(scale-out), onde cada Nó do controller recebe um conjunto de funções que define o tipo de tarefas que o nó poderá implementar.  Os nós das controllers são implantados em números ímpares. A prática atual recomendada (e a única configuração compatível) é que o clustertenha três nós de compartilhamento e redundância de carga ativo-ativo-ativo.

Para aumentar as características de escalabilidade da arquitetura NSX, um mecanismo de "fatiamento" é utilizado para garantir que todos os nós das controlllers possam estar ativos em um determinado momento.

Caso algum controller falhe, o tráfego do plano de dados (VM) não será afetado. O tráfego continuará fluindo. isso acontece porque as informações da rede lógica foram enviadas por push para os switches lógicos (o plano de dados). O que você não pode fazer é adicionar/mover/alterar sem que a camada de controle (cluster do controller) esteja intacto.


 

Escalabilidade/Disponibilidade do NSX Controller

 

  1. Passe o mouse sobre o ícone Home.
  2. Clique em Networking & Security.

 

 

Verificar a configuração do controller existente

 

  1. Clique em Installation.
  2. Clique em Management.

Examine os nós do NSX Controller, onde será possível ver se há três controllers implantados. Os NSX Controllers são sempre implantados em números ímpares para obtenção de alta disponibilidade e dimensionamento.

 

 

Visualize as VMs do NSX Controller

 

Para ver os NSX Controllers no ambiente virtual

  1. Passe o mouse sobre oícone Home.
  2. Clique em VMs and Templates.

 

 

Você verá os 3 NSX Controllers

 

  1. Expanda o contêiner "RegioA01"
  2. Destaque um dos NSX_Controllers
  3. Selecione a guia Summary.

Observe o host ESX ao qual este controlador está conectado. Os outros controladores podem estar em um host ESX diferente neste ambiente de laboratório. Em um ambiente de produção, cada controlador residiria em um host diferente no cluster com regras antiafinidade do DRS definidas para evitar várias falhas de controller devido à interrupção de um único host.

 

Conclusão do Módulo 2


Neste módulo, demonstramos os principais benefícios da plataforma NSX.

A velocidade na qual você pode aprovisionar switches lógicos e fazer a interface deles com máquinas virtuais e redes externas.

A escalabilidade da plataforma é demonstrada pela capacidade de aumentar a zona de transporte bem com os nós dos controllers


 

Você terminou o Módulo 2

Parabéns por concluir o Módulo 2.

Se você estiver procurando por informações adicionais sobre switches lógicos, visite o URL abaixo:

Continue em qualquer módulo abaixo que seja do seu interesse:

Lista de módulos de laboratório:

Chefes do laboratório:

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END

 

Módulo 3 - Roteamento lógico (60 minutos)

Visão geral de roteamento


Visão geral do módulo de laboratório

No módulo anterior, você viu que os usuários podem criar switches/redes lógicos isolados com apenas alguns cliques. Para fornecer comunicação entre essas redes lógicasisoladasde camada 2, o suporte de roteamento é essencial. Na plataforma NSX, o roteador lógico distribuído permite que você roteie o tráfego entre os switches lógicos. Um dos principais recursos de diferenciação desse roteador lógico é que a capacidade de roteamento é distribuída no hypervisor. Ao incorporarem esse componente de roteamento lógico, os usuários poderão reproduzir topologias de roteamento complexas no espaço lógico. Por exemplo, em um aplicativo de 3 camadas conectado a três switches lógicos, o roteamento entre as camadas é tratado por esse roteador lógico distribuído.

Neste módulo, você demonstrará o seguinte

1) Como o tráfego flui quando o roteamento é tratado por um roteador físico externo ou um NSX Edge Services Gateway.

2) Em seguida, percorreremos a configuração das Interfaces lógicas (LIFs) no roteador lógico e ativaremos o roteamento entre as camadas de aplicativo e de banco de dados do Aplicativo

3) Posteriormente, configuraremos protocolos de roteamento dinâmico entre o roteador lógico distribuído e o NSX Edge Services Gateway. Mostraremos como são controladas as divulgações de rotas internas para o roteador externo.

4) Por fim, nós veremos como os diversos protocolos de roteamento, como o ECMP (Equal Cost Multipath Routing), podem ser usados para escalar e proteger o gateway de serviços do Edge.

Este módulo nos ajudará a compreender alguns dos recursos de roteamento com suporte na plataforma NSX e também como utilizar esses recursos durante a implantação de um aplicativo de 3 camadas.


 

Instruções especiais para comandos da CLI

 

Em muitos dos módulos, você deverá inserir comandos de linha na console (CLI, Command Line Interface).  Há duas maneiras de enviar comandos da CLI para o laboratório.

A primeira é enviar um comando da CLI para o console do laboratório:

  1. Destaque o comando da CLI no manual e use Control+c para copiar para a área de transferência.
  2. Clique no item de menu do console SEND TEXT.
  3. Pressione Control+v para colar da área de transferência para a janela.
  4. Clique no botão SEND.

Na segunda, um arquivo de texto (README.txt) foi colocado na área de trabalho do ambiente, permitindo que você copie e cole com facilidade comandos ou senhas complexos nos utilitários associados (CMD, Putty, console etc). Com frequência, determinados caracteres não estão presentes em teclados usados globalmente.  Este arquivo de texto também é incluído para layouts de teclado que não oferecem esses caracteres.

O arquivo de texto chama-se README.txt e pode ser encontrado na área de trabalho.

 

Roteamento dinâmico e distribuído


Primeiro, examine a configuração do roteamento distribuído e veja os benefícios do roteamento no nível do kernel.


 

Uma visão da topologia atual e do fluxo de pacotes

 

Na imagem acima, observe que a VM do aplicativo e a VM do banco de dados residem no mesmo host físico, que é o cenário do laboratório.  Sem o roteamento distribuído, para que essas duas VMs se comuniquem, podemos ver o fluxo do tráfego apontado pela seta vermelha nas etapas acima.  Primeiro, vemos o tráfego deixar a VM do aplicativo e, como a VM do banco de dados não está na mesma subnet, o host físico enviará esse tráfego para um dispositivo de camada 3.  No ambiente, esse é o NSX Edge (perímetro) que reside no Cluster de gerenciamento.  Em seguida, o NSX Edge envia o tráfego de volta para o host onde ele finalmente atinge a VM do banco de dados.

No final do laboratório, nós visitaremos novamente um diagrama de fluxo de tráfego semelhante para vermos como alteramos esse comportamento após a configuração do roteamento distribuído.

 

 

Acessar o vSphere Web Client

 

 

 

Fazer login no vSphere Web Client

 

Faça login no vSphere Web Client usando a autenticação de sessão do Windows.

  1. Clique em Use Windows session authentication - isso preencherá automaticamente com as credenciais CORP\Administrator / VMware1!
  2. Clique em Login

 

 

Confirme o funcionamento do aplicativo de camada 3

 

  1. Abra uma nova guia do navegador
  2. Clique no favorito chamado Customer DB App

 

 

Aplicativo Web retornando informações do banco de dados

 

Antes de você começar a configurar o Roteamento distribuído, vamos verificar se o aplicativo Web de 3 camadas está funcionando corretamente. As três camadas do aplicativo (Web, aplicativo e banco de dados) estão em switches lógicos diferentes e o NSX Edge fornece o roteamento entre as camadas.

 

 

Remoção das interfaces do aplicativo e do banco de dados do Edge de perímetro.

 

Como você viu na topologia anterior, os três switches lógicos ou as 3 camadas do aplicativo são terminados no Edge de perímetro. O Edge de perímetro fornece o roteamento entre as 3 camadas. Vamos alterar essa topologia; primeiro remova as interfaces do aplicativo e do banco de dados do Edge de perímetro. Depois de excluirmos as interfaces, as moveremos para o perímetro distribuído.  Para economizar tempo de implantação de um componente, o roteador distribuído foi criado para você.

  1. Clique no botão Networking & Security

 

 

Selecione o NSX Edge

 

  1. Clique em NSX Edges no painel de navegação esquerdo
  2. Clique duas vezes em "edge-3 Perimeter-Gateway-01" para abrir a configuração do Perimeter-Gateway

 

 

Selecione interfaces na guia Settings para exibir as interfaces atuais

 

  1. Clique na guia Manage
  2. Clique em Settings
  3. Clique em Interfaces no painel de navegação Settings

Você verá as interfaces atualmente configuradas e as propriedades delas.  As informações incluem o número vNIC, o nome da interface, se a interface foi configurada como interna ou como um uplink e qual é o status atual, ativo ou desativado.

 

 

Exclua a interface do aplicativo

 

  1. Destaque a interface App_Tier.  A barra Actions será iluminada, oferecendo opções específicas para a interface selecionada
  2. Clique no X vermelho para excluir a interface selecionada do Edge de perímetro.  Aparecerá uma caixa de aviso solicitando a confirmação de que desejamos excluir a interface
  3. Clique em OK para confirmar a exclusão

 

 

Exclua a interface do banco de dados

 

  1. Destaque a interface DB_Tier.  A barra Actions será iluminada, oferecendo opções específicas para a interface selecionada
  2. Clique no X vermelho para excluir a interface selecionada do perímetro.  Aparecerá uma caixa de aviso solicitando a confirmação de que desejamos excluir a interface
  3. Clique em OK para confirmar a exclusão

 

 

A topologia após a remoção das interfaces do aplicativo e do banco de dados do Edge de perímetro

 

 

 

Navegue de volta para a página inicial do NSX

 

Agora que você removeu as interfaces do aplicativo e do banco de dados do Edge de perímetro, precisará navegar de volta para a tela do dispositivo de perímetro para acessar o perímetro distribuído.

 

 

Adicione as interfaces do aplicativo e do banco de dados ao roteador distribuído

 

Agora começaremos a configurar o roteamento distribuído ao adicionarmos a interface do aplicativo e do banco de dados ao "roteador distribuído".

  1. Clique duas vezes em edge-6 para configurar o roteador distribuído

 

 

Exiba as interfaces no roteador distribuído

 

  1. Clique em Manage
  2. Clique em Settings
  3. Clique em Interfaces para exibir todas as interfaces atualmente configuradas no roteador distribuído

 

 

Adicione as interfaces ao roteador distribuído

 

  1. Clique no sinal "+" verde para adicionar uma nova interface
  2. Nomeie a interface como App_Tier
  3. Clique em Select na seção Connected To

 

 

Especifique a rede

 

  1. Selecione o botão de opção App_Tier_Logical_Switch que será a rede em que esta interface se comunicará
  2. Clique em OK

 

 

Adicione subnets

 

  1. Clique no sinal "+" verde para Configure Subnets.
  2. Clique na caixa Primary IP Address e digite 172.16.20.1 como o endereço IP
  3. Digite 24 como o Subnet Prefix Length
  4. Em seguida, clique em OK para concluir a adição da sub-rede

 

 

Adicione a interface do banco de dados

 

Assim que o sistema concluir a adição e a configuração da interface DB.  Verifique se as interfaces App_Tier e DB_Tier correspondem à imagem acima.

 

 

A nova topologia após a mudança das interfaces do aplicativo e do banco de dados para o roteador distribuído

 

Após a configuração dessas interfaces no roteador distribuído, as configurações de interface serão automaticamente enviadas por push para cada host no ambiente. A partir daí, no Roteamento distribuído (DR) do host, o módulo carregável do Kernel tratará o roteamento entre as interfaces do aplicativo e do banco de dados. Assim, se duas VMs conectadas a duas subnets diferentes estiverem em execução no mesmo host com o qual querem se comunicar, o tráfego utilizará um caminho ideal como mostrado no diagrama de fluxo de tráfego anterior.

 

 

Volte para a guia do navegador com o aplicativo Web de 3 camadas

 

Depois de fazer as alterações, você testará se o acesso ao aplicativo de 3 camadas falha.  O motivo da falha é que enquanto configuramos o roteamento a ser tratado pelo roteador distribuído, não há uma rota entre ele e o local onde os Servidores Web estão localizados.

Observação: caso você tenha fechado a guia nas etapas anteriores, abra uma nova guia do navegador e clique no bookmark favorito Customer DB App

 

 

Verifique se o aplicativo de três camadas para de funcionar

 

  1. Clique em Refresh

O aplicativo levará alguns segundos para realmente atingir o tempo limite, talvez seja necessário selecionar o "x" vermelho para parar o navegador.  Se você realmente observar  os dados do cliente, talvez eles tenham sido obtidos do cache anteriormente e talvez seja necessário fechar e reabrir o navegador para corrigí-los.

Feche a guia criada para testar a conectividade ao servidor Web. Em seguida, vamos configurar o roteamento para restaurar o serviço.

Observação: se você tiver de reabrir o navegador, depois de verificar que o aplicativo de 3 camadas não está funcionando, clique no marcador para o vSphere Web Client no navegador e faça login novamente com as credenciais "root" e senha "VMware1!".  Em seguida, clique em Networking and Security, Edge Appliances e, por fim, clique duas vezes em "Distributed-Router".

 

 

Configure o roteamento dinâmico no roteador distribuído

 

  1. Clique na guia Routing
  2. Clique em Global Configuration
  3. Clique no botão Edit ao lado de Dynamic Routing Configuration

 

 

Edite a configuração do roteamento dinâmico

 

  1. Selecione a ID do roteador padrão, que é o endereço IP da interface Uplink, nesse caso, Transit_Network_01 - 192.168.5.2
  2. Clique em OK

Observação: o ID do roteador é importante na operação do OSPF, já que indica a identidade dos roteadores em um sistema autônomo. É um identificador de 32 bits indicado como um endereço IP, mas pode ser específico de subnets relativas ao roteador específico. Em nosso caso, estamos usando uma ID do roteador igual ao endereço IP da interface de uplink no dispositivo de perímetro, o que é aceitável, porém desnecessário. A tela voltará para a tela principal "Global Configuration e a caixa de diálogo verde "Publish Changes" aparecerá novamente.

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Configure os parâmetros específicos do OSPF

 

Usaremos o OSPF como o nosso protocolo de roteamento dinâmico.

  1. Selecione OSPF na árvore de navegação em Routing para abrir a página principal de configuração do OSPF
  2. Clique em Edit à direita de OSPF Configuration para abrir a caixa de diálogo OSPF Configuration

 

 

Ative o OSPF

 

  1. Clique na caixa de diálogo Enable OSPF
  2. Digite 192.168.5.3 na caixa Protocol Address
  3. Digite 192.168.5.2 na caixa Forwarding Address
  4. Verifique se a caixa de diálogo Enable Graceful Restart está marcada
  5. Em seguida, clique em OK

Observação: para o roteador distribuído, o campo "Protocol Address" será obrigatório para o envio do tráfego de controle para a Máquina Virtual de controle do roteador distribuído. O endereço de encaminhamento é para onde todo o tráfego do plano de dados será enviado.  A tela voltará para a janela de configuração principal do "OSPF".  A caixa de diálogo verde "Publish Changes" será exibida.

Observação: a separação do tráfego da camada de controle e do plano de dados no NSX cria a possibilidade da manutenção do recurso de encaminhamento de dados da instância de roteamento enquanto a função de controle é reiniciada ou recarregada. Essa função é chamada de "Graceful Restart" ou de "Non-stop Forwarding".

NÃO PUBLIQUE AS ALTERAÇÕES AINDA!Em vez de publicar alterações em todas as etapas, continuaremos a percorrer as alterações de configuração e as publicaremos todas de uma vez.

 

 

Configurar a definição de área

 

  1. Clique no sinal "+" verde para abrir a caixa de diálogo New Area Definition
  2. Digite 10 na caixa Area ID.  Você pode deixar as outras caixas de diálogo com as configurações padrão
  3. Clique em OK

Observação: o ID da área para o OSPF é muito importante.  Existem vários tipos de áreas OSPF.  Verifique a área correta em que os dispositivos de perímetro devem estar para que funcionem corretamente com o resto da configuração na rede.

 

 

Mapeamento de área para interface

 

  1. Clique no sinal de mais verde na área "Area to Interface Mapping" para abrir a caixa de diálogo "New Area to Interface Mapping"
  2. Selecione Transit_Network_01 como interface
  3. Selecione 10 como a Area
  4. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Confirme se o roteamento OSPF está rodando no roteador distribuído

 

Agora podemos confirmar que ativamos e configuramos o OSPF no perímetro distribuído  Confirme se todas as informações exibidas estão corretas.

 

 

Confirme a redistribuição de rota

 

 

 

Verifique a redistribuição de rota

 

 

 

Adicionar BGP à tabela de redistribuição de rotas OSPF

 

  1. Clique em OSPF da tabela Route Redistribution
  2. Clique no ícone de lápis para editar as configurações de OSPF
  3. Marque a caixa de BGP na lista Allow learning from
  4. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Configure o roteamento OSPF no Edge de perímetro

 

Agora devemos configurar o roteamento dinâmico no dispositivo Edge de perímetro para restaurar a conectividade para o nosso aplicativo de 3 camadas de teste.

 

 

Selecione o Edge de perímetro

 

Os nossos dispositivos de perímetro configurados são exibidos na página principal NSX Edges.  

 

 

Configuração global do Edge de perímetro

 

  1. Clique na guia de navegação Manage
  2. Selecione o botão de navegação Routing para ir para a página de configuração de roteamento do dispositivo
  3. Clique em OSPF
  4. Clique em Edit à direita de OSPF Configuration para abrir a caixa de diálogo OSPF Configuration

Você observará que esse dispositivo Edge já foi configurado para roteamento dinâmico com BGP.  Essa configuração de roteamento é definida de forma que esse dispositivo Edge possa comunicar e distribuir rotas para o roteador que esteja executando o laboratório geral.  Agora prosseguiremos ao conectarmos esse dispositivo Edge ao roteador distribuído lógico.  Todas as configurações globais de roteador e BGP já foram concluídas para o dispositivo Edge.

 

 

Ative o OSPF

 

  1. Clique na caixa de diálogo Enable OSPF
  2. Verifique se a caixa de diálogo Enable Graceful Restart está marcada
  3. Em seguida, clique em OK

 

 

Configurar a definição de área

 

  1. Clique no sinal "+" verde para abrir a caixa de diálogo New Area Definition
  2. Digite 10 na caixa Area ID. Você pode deixar as outras caixas de diálogo com as configurações padrão
  3. Clique em OK.

Observação: o ID da área para o OSPF é muito importante. Existem vários tipos de áreas OSPF. Verifique a área correta em que os dispositivos de perímetro devem estar para que funcionem corretamente com o resto da configuração na rede.

 

 

Adicione a interface de trânsito ao mapeamento de área para interface

 

Agora só precisamos direcionar o OSPF para a comunicação pela interface que se comunicará com os roteadores distribuídos.

  1. Clique no sinal "+" verde ao lado de Area to Interface Mapping
  2. Selecione Transit_Network_01 em vNIC
  3. Selecione 10 em Area
  4. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Confirme se o roteamento OSPF está rodando no Edge de perímetro

 

Agora podemos confirmar que ativamos e configuramos o OSPF no perimeter-edge. Confirme se todas as informações exibidas estão corretas.

 

 

Configurar a redistribuição de rota

 

  1. Clique em Route Redistribution para abrir a página de configuração principal da redistribuição de rota.
  2. Clique em Edit à direita de Route Redistribution Status para abrir a caixa de diálogo Change redistribution settings

 

 

Alterar as configurações de redistribuição

 

  1. Clique na caixa de diálogo OSPF
  2. Verifique se a caixa de diálogo BGP está marcada
  3. Clique em OK

Observação: O BGP é o protocolo de roteamento usado entre o Perimeter-Gateway-01 e o roteador vPod.

 

 

Editar os critérios de redistribuição de BGP

 

  1. Destaque BGP na tabela Route Redistribution em Learner
  2. Clique no ícone de lápis para editar o Learner selecionado do perímetro.
  3. Clique na caixa de diálogo OSPF
  4. Clique em OK

 

 

Configurar a redistribuição de rota OSPF

 

  1. Clique no sinal "+" verde na tabela Route Redistribution
  2. Selecione OSPF como Learner Protocol
  3. Clique na caixa de diálogo BGP 
  4. Clique na caixa de diálogo Connected
  5. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Revise a nova topologia

 

Examinando a configuração da topologia, você pode ver como está ocorrendo o peering de rota entre o roteador distribuído e o dispositivo Edge de perímetro do NSX.  Todas as redes criadas sob o roteador distribuído agora serão distribuídas até o perímetro e, nesse ponto, você poderá controlar a forma como ela é roteado para a sua rede física.

A próxima seção abordará isso em mais detalhes.

 

 

Verifique a comunicação com o aplicativo de três camadas

 

Agora vamos verificar se o roteamento está funcionando.  As informações de roteamento do roteador distribuído para o Perimeter-Gateway estão sendo trocadas, o que restaurou a conectividade ao aplicativo Web.  Para verificar isso, testaremos novamente o aplicativo Web.

  1. Clique na guia que você tinha aberto anteriormente para o aplicativo Web, que talvez diga "503 Service Temp..." na guia do teste que falhou.
  2. Atualize seu navegador para verificar se o aplicativo de 3 camadas funciona novamente

Observação: A propagação da rota pode levar um pouco por causa deste ambiente virtualizado estar em outro virtualizado.

 

 

Roteamento distribuído e dinâmico concluído

Isso conclui a seção sobre a configuração do roteamento dinâmico e distribuído.  Na próxima seção, revisaremos o roteamento centralizado com o Edge de perímetro.

 

Roteamento centralizado


Nesta seção, examinaremos diversos elementos para vermos como o roteamento é feito em direção a saída a partir do perímetro.  Isso inclui a forma como o roteamento dinâmico OSPF é controlado, atualizado e propagado pelo sistema.  Verificaremos o roteamento no appliance Edge de perímetro até o appliance de roteamento virtual que executa e roteia o laboratório inteiro.

Observação especial: na área de trabalho, você encontrará um arquivo chamado README.txt.  Ele contém os comandos da CLI necessários nos exercícios do laboratório.  Se você não conseguir digitá-los, poderá copiá-los e colá-los nas sessões do putty.  Caso você veja um número com "chaves - {1}" isso dirá a você para procurar o comando da CLI para este módulo no arquivo de texto.


 

Topologia atual do laboratório

 

Este diagrama é a topologia atual do laboratório, incluindo o link em direção a saída até o roteador vPod.  Você pode observar que o OSPF está redistribuindo rotas do roteador NSX Edge até o roteador lógico distribuído.

 

 

Examine o roteamento OSPF no Perimeter-Gateway.

Primeiro, confirmaremos se o aplicativo Web está funcionando, então nos conectaremos ao gateway de perímetro do NSX para visualizarmos os vizinhos  OSPF e vermos a distribuição de rotas existente.  Isso mostrará como o gateway de perímetro está aprendendo as rotas não só do roteador distribuído, mas também do roteador vPod que está executando o laboratório inteiro.

 

 

Confirme a funcionalidade de aplicativo de camada 3

 

  1. Abra uma nova guia do navegador
  2. Clique no favorito chamado Customer DB App

 

 

Aplicativo Web retornando informações do banco de dados

 

Antes de você começar a configurar o Roteamento distribuído, vamos verificar se o aplicativo Web de 3 camadas está funcionando corretamente. As três camadas do aplicativo (Web, aplicativo e banco de dados) estão em switches lógicos diferentes e o NSX Edge fornece o roteamento entre as camadas.

 

 

Navegue até a VM do Perimeter-Gateway

 

 

 

Iniciar o console remoto

 

  1. Expanda a pasta RegionalA01
  2. Selecione Perimeter-Gateway-01-0
  3. Selecione a guia Summary
  4. Clique em Launch Remote Console

 

 

Acessar o console remoto

 

Quando a janela VMRC abrir pela primeira vez, ela estará preta.  Clique dentro da janela e pressione Enter algumas vezes para fazer o console aparecer do protetor de tela.

***OBSERVAÇÃO*** Para liberar seu cursor da janela, pressione as teclas Ctrl+Alt

 

 

Fazer login no gateway de perímetro

 

Faça login no gateway de perímetro com as credenciais a seguir.  Observe que todos os dispositivos Edge têm senhas complexas de 12 caracteres.

 

 

Instruções especiais para comandos da CLI

 

Em muitos dos módulos, você deverá inserir comandos da interface de linha de comando (CLI, Command Line Interface).  Há duas maneiras de enviar comandos da CLI para o laboratório.

A primeira é enviar um comando da CLI para o console do laboratório:

  1. Destaque o comando da CLI no manual e use Control+c para copiar para a área de transferência.
  2. Clique no item de menu do console SEND TEXT.
  3. Pressione Control+v para colar da área de transferência para a janela.
  4. Clique no botão SEND.

Na segunda, um arquivo de texto (README.txt) foi colocado na área de trabalho do ambiente, permitindo que você copie e cole com facilidade comandos ou senhas complexos nos utilitários associados (CMD, Putty, console etc). Com frequência, determinados caracteres não estão presentes em teclados usados no mundo.  Este arquivo de texto também é incluído para layouts de teclado que não oferecem esses caracteres.

O arquivo de texto chama-se README.txt e pode ser encontrado na área de trabalho.  

 

 

Visualizar os vizinhos BGP

 

A primeira coisa que faremos é examinar os vizinhos BGP até o Edge de perímetro, que está no meio da camada de roteamento do laboratório.

OBSERVAÇÃO - a conclusão da guia funciona em dispositivos Edge no NSX.

show ip bgp neighbor

 

 

Revisão das informações sobre o vizinho BGP exibido

 

Agora, vamos revisar o conteúdo exibido e o seu significado.

  1. BGP neighbor is 192.168.100.1 - é a ID do roteador vPod dentro do ambiente do NSX
  2. Remote AS 65002 - mostra o número do sistema autnomo da rede externa do roteador vPod
  3. BGP state = Established, up - significa que a adjacência do vizinho BGP está completa e os roteadores BGP enviarão pacotes de atualização para trocar informações de roteamento.

 

 

Revise rotas no Edge de perímetro e a origem delas

 

Digite show ip route

show ip route

 

 

Revise informações sobre rota

 

Vamos revisar o conteúdo das rotas exibidas.

  1. A primeira linha mostra a nossa rota default, que se origina no roteador vPod (192.168.100.1) e o B no início das linhas mostra que ela foi aprendida via BGP.
  2. A linha 172.16.10.0/24 é o switch lógico Web-Tier e sua interface.  Já que ele está diretamente conectado ao Edge, há um C no início da linha para demonstrar isso.
  3. A seção com um 3 compõe as duas outras partes do nosso aplicativo Web, que são os segmentos de rede para a camada do aplicativo e do banco de dados.  Como na linha 1, elas têm um O no início da linha para denotar que foram aprendidas via OSPF por meio do roteador distribuído (192.168.5.2)

 

 

Controle da distribuição de rotas BGP

Pode haver uma situação em que você só desejará que as rotas BGP sejam distribuídas dentro do ambiente virtual, mas não para o ambiente físico externo.  Podemos controlar essa distribuição de rotas com facilidade na interface do Edge.

 

 

Navegue até o NSX no vSphere Web Client

 

**OBSERVAÇÃO** Você precisa pressionar Ctrl+Alt para sair da janela VMRC do Perimeter-Gateway

 

 

Acesse o Perimeter-Gateway

 

  1. Clique em NSX Edges
  2. Clique duas vezes em edge-3

 

 

Acesse a configuração do roteamento BGP

 

  1. Selecione a guia Manage
  2. Clique em Routing
  3. Clique em BGP no painel esquerdo

 

 

Remover relacionamento de vizinhança BGP com o roteador vPod

 

Agora, removeremos o mapeamento da área BGP Local AS 65002. Ao fazermos isso, o gateway de perímetro e o roteador vPod não terão mais troca de rota.

  1. Destaque o endereço IP do roteador vPod, 192.168.100.1, na seção Neighbors
  2. Clique no X vermelho para excluir o relacionamento de vizinho selecionado.

 

 

Confirme a exclusão

 

 

 

Publicar a alteração

 

  1. Clique no botão Publish Changes para enviar a alteração de configuração por push.

 

 

Navegue até o VMRC do gateway de perímetro

 

Selecione Perimeter-Gateway em sua barra de tarefas

 

 

Mostrar vizinhos BGP

 

**OBSERVAÇÃO** Assim que a janela aparecer, talvez seja necessário clicar dentro dela e pressionar a tecla Enter para fazer a tela aparecer

1. Digite show ip bgp neighbor e pressione Enter

show ip bgp neighbor

Você verá que o roteador vPod (192.168.250.1) saiu da lista.

 

 

Mostrar as rotas

 

1. Digite show ip route e pressione Enter

show ip route

Você pode ver que as únicas rotas aprendidas via OSPF estão vindo do roteador distribuído (192.168.5.2)

 

 

Verifique se o aplicativo de três camadas para de funcionar

 

**OBSERVAÇÃO** Você precisa pressionar Ctrl+Alt para sair da janela VMRC do Perimeter-Gateway

Como não existem rotas entre o seu centro de controle e o ambiente de rede virtual, o aplicativo Web deverá falhar.

  1. Clique na guia HOL - Multi-Tier App
  2. Clique em Refresh.

O aplicativo poderá levar alguns instantes para o timeout, talvez seja necessário selecionar o "x" vermelho para parar o navegador.  Se você observar os dados do cliente, talvez eles tenham sido obtidos do cache anteriormente e talvez seja necessário fechar e reabrir o navegador para corrigi-los.

 

 

Reestabeleça o peering  de rota

 

Agora vamos recriar o peering de rota entre o gateway de perímetro e o roteador vPod.

 

 

Adicionar novamente a configuração de vizinho BGP

 

  1. Clique no ícone "+"  verde no painel Neighbors
  2. Digite 192.168.100.1 em IP Address
  3. Digite 65002 em Remote AS
  4. Clique em OK

 

 

Publicar a alteração

 

  1. Clique no botão Publish Changes para enviar a alteração de configuração por push.

 

 

Navegue até o VMRC do gateway de perímetro

 

Selecione Perimeter-Gateway em sua barra de tarefas

 

 

Mostrar vizinhos BGP

 

**OBSERVAÇÃO** Assim que a janela aparecer, talvez seja necessário clicar dentro dela e pressionar a tecla Enter para fazer a tela aparecer

1. Digite show ip bgp neighbor e pressione Enter

show ip bgp neighbor

Você verá que o roteador vPod (192.168.100.1) saiu da lista.

 

 

Revise rotas no Edge de perímetro e a origem delas

 

Digite "show ip route"

show ip route

 

 

Mostrar as rotas

 

A rota padrão e a rede conectada do roteador vPod (192.168.100.1) voltaram para a lista.

 

 

Verifique se o aplicativo de três camadas está funcionando

 

**OBSERVAÇÃO** Você precisa pressionar Ctrl+Alt para sair da janela VMRC do Perimeter-Gateway

Com as rotas novamente definidas, o aplicativo Web deverá funcionar outra vez.

  1. Clique na guia HOL - Multi-Tier App
  2. Clique em Refresh.

Isso conclui esta seção do laboratório e prosseguiremos para o ECMP e a alta disponibilidade com os NSX Edges.

 

ECMP e alta disponibilidade


Nesta seção, adicionaremos outro gateway de perímetro à rede e usaremos o ECMP (Equal Cost Multipath Routing) para escalar horizontalmente a capacidade do Edge e aumentar sua disponibilidade. Com o NSX, podemos executar uma adição de um dispositivo Edge e ativar o ECMP.

O ECMP é uma estratégia de roteamento que permite o encaminhamento de pacotes ao próximo hop para um único destino e pode ocorrer por vários caminhos otimizados. Esses caminhos otimizados podem ser adicionados estaticamente ou como resultado de cálculos de métrica por protocolos de roteamento dinâmico como OSPF ou BGP. O Edge Services Gateway utiliza a implementação de pilha de rede do Linux, um algoritmo round-robin com um componente de aleatoriedade. Depois que o próximo hop for selecionado para um determinado par de endereços IP de origem e de destino, o cache de rota armazena o próximo hop selecionado. Todos os pacotes para esse fluxo vão para o próximo hop selecionado. O roteador lógico distribuído usa um algoritmo XOR para determinar o próximo hop de uma lista de possíveis próximos hops ECMP. Esse algoritmo usa o endereço IP de origem e de destino no pacote de saída para que se mantenha aleatoriedade na distribuição de pacotes.

Agora vamos configurar um novo gateway de perímetro e estabelecer um cluster ECMP entre os gateways de perímetro para o roteador lógico distribuído para aproveitar a capacidade e a disponibilidade aumentadas.  Nós testaremos a disponibilidade desligando um dos gateways de perímetros e observando a alteração no caminho de tráfego.


 

Navegue até o NSX no vSphere Web Client

 

**OBSERVAÇÃO** Você precisa pressionar Ctrl+Alt para sair da janela VMRC do Perimeter-Gateway

  1. Clique no ícone Home
  2. Clique em Networking & Security

 

 

Adicione outro Edge de gateway de perímetro

 

A nossa primeira etapa é adicionar outro dispositivo Edge de perímetro.

  1. Clique em NSX Edges
  2. Clique no sinal "+" verde

 

 

Selecione e nomeie o Edge

 

  1. Clique em Edge Services Gateway como Install Type
  2. Digite Perimeter-Gateway-02 em Name
  3. Clique em Next

 

 

Defina a senha

 

  1. Insira a senha VMware1!VMware1!
  2. Confirme a senha VMware1!VMware1!
  3. Marque Enable SSH Access
  4. Clique em Next

OBSERVAÇÃO - todas as senhas de NSX Edges são senhas complexas de 12 caracteres.

 

 

Adicione um appliance Edge

 

  1. Clique no sinal "+" verde em NSX Appliances para fazer a caixa de diálogo Add NSX Edge Appliance aparecer
  2. Selecione RegionA01-MGMT01 como Cluster/Resource Pool
  3. Selecione RegionA01-ISCSI01-MGMT01 como Datastore
  4. Selecione esx-04a.corp.local como o host
  5. Clique em OK

 

 

Continue a implantação

 

  1. Clique em Next

 

 

Adicione a interface Uplink

 

  1. Clique no sinal "+" verde para adicionar a primeira interface

 

 

Selecione Switch Connected To

 

Nós escolhemos a interface do switch voltada para o norte para este perímetro, que é um port group distribuídas.

  1. Clique em Select ao lado do campo Connected To
  2. Clique em Distributed Portgroup
  3. Selecione Uplink-RegionA01-vDS-MGMT
  4. Clique em OK

 

 

Nomeie e adicione o IP

 

  1. Insira Uplink em Name
  2. Selecione Uplink em Type
  3. Clique no sinal "+" verde
  4. Digite 192.168.100.4 em Primary IP Address
  5. Insira 24 em Subnet Prefix Length
  6. Clique em OK

 

 

Adicione a interface Edge Transit

 

  1. Clique no sinal "+" verde para adicionar a segunda interface

 

 

Selecione Switch Connected To

 

Nós escolhemos a interface do switch voltada para o norte para este perímetro, que é um switch lógico baseado em VXLAN.

  1. Clique em Select ao lado do campo Connected To
  2. Clique em Logical Switch
  3. Selecione Transit_Network_01_5006
  4. Clique em OK

 

 

Nomeie e adicione o IP

 

  1. Insira Transit_Network_01 em Name
  2. Selecione Internal em Type
  3. Clique no sinal "+" verde
  4. Insira 192.168.5.4 em Primary IP Address
  5. Insira 29 em Subnet Prefix Length

OBSERVAÇÃO - é 29, não 24!  Digite o número correto ou o laboratório não funcionará.

  1. Clique em OK

 

 

Continue a implantação

 

IMPORTANTE Antes de continuar, revise as informações e se os números de IP Addresses e de Subnet Prefix estão corretos.

  1. Clique em Next

 

 

Remova o gateway padrão

 

Estamos removendo o gateway padrão porque receberemos essa informação via OSPF

  1. DESMARQUE Configure Default gateway
  2. Clique em Next

 

 

Configurações padrão de firewall

 

  1. MARQUE Configure Firewall default policy
  2. Selecione ACCEPT
  3. Clique em Next

 

 

Finalize a implantação

 

 

 

Implantação do Edge

 

A implantação do Edge pode demorar alguns minutos.

  1. Nós observaremos que o status do Edge-7 diz Busy e que também mostra 1 item installing.  Isso significa que a implantação está em andamento.
  2. Nós podemos clicar no ícone de atualização no cliente Web para acelerar a atualização automática nessa tela.

quando o status mostrar Deployed, você poderá seguir para a próxima etapa.

Observação: se o status do Edge-7 não puder ser visto, rolar até a janela à direita permitirá que o status da implantação seja visualizado.

 

 

Configure o roteamento no novo Edge

 

Agora, você deve configurar o OSPF no novo dispositivo Edge antes de podermos ativar o ECMP.

  1. Clique duas vezes no edge-7 recém-implantado

 

 

Configuração global de roteamento

 

Devemos definir a configuração base para identificarmos o roteador para a rede.

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Selecione Global Configuration no painel esquerdo
  4. Clique em Edit ao lado de Dynamic Routing Configuration
  5. Selecione Uplink -192.168.100.4 como Router ID
  6. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Ative o OSPF

 

  1. Selecione OSPF no painel esquerdo
  2. Clique em Edit ao lado de OSPF Configuration
  3. MARQUE Enable OSPF
  4. Clique em OK

 

 

Adicione uma nova área

 

  1. Clique no sinal "+" verde ao lado de Area Definitions
  2. Insira 10 como Area ID
  3. Clique em OK

 

 

Adicione o mapeamento da interface Transit

 

Agora deve ser feito o mesmo para a interface downlink até o roteador distribuído

  1. Clique no sinal "+" verde ao lado de Area to Interface Mapping
  2. Selecione Transit_Network_01 como vNIC
  3. Selecione 10 como Area
  4. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Ativar o BGP

 

  1. Selecione BGP no painel esquerdo
  2. Clique em Edit ao lado de BGP Configuration
  3. MARQUE Enable BGP
  4. Insira 65001 como o Local AS
  5. Clique em OK

 

 

Adicionar novo vizinho

 

  1. Clique no sinal "+ verde ao lado de Neighbors
  2. Insira Digite 192.168.100.1 em IP Address
  3. Insira 65002em Remote AS
  4. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Ative a distribuição de rota BGP e OSPF

 

Agora, devemos ativar a redistribuição de rotas BGP e OSPF para que as rotas possam ser acessadas por meio deste perímetro.

  1. Clique em Route Redistribution no painel esquerdo
  2. Clique em Edit para Route Redistribution Status
  3. Marque OSPF
  4. Marque BGP
  5. Marque OK

 

 

Ativar a tabela de distribuição de rotas

 

  1. Clique no sinal de mais verde em Route Redistribution Table
  2. Marque BGP
  3. Marque Connected
  4. Clique em OK

 

 

Tabela de distribuição de rotas BGP

 

  1. Clique no sinal "+" verde em Route Redistribution Table
  2. Selecione BGP como Learner Protocol
  3. Marque OSPF
  4. Marque Connected
  5. Clique em OK

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes na caixa de diálogo novamente para enviar por push a configuração atualizada para o dispositivo de perímetro distribuído.

 

 

Ativar o ECMP

 

Vamos ativar o ECMP no roteador distribuído e nos gateways de perímetro

  1. Clique no botão back de Networking & Security no painel Navigator

 

 

Ativar o ECMP no roteador distribuído

 

Primeiro ativaremos o ECMP no roteador distribuído

  1. Clique em NSX Edges
  2. Clique duas vezes em edge-6

 

 

Ativar o ECMP no DLR

 

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Clique em Global Configuration no painel esquerdo
  4. Clique no ENABLE Button ao lado de ECMP

 

 

Publicar a alteração

 

  1. Clique em Publish Changes para enviar a alteração de configuração por push.

 

 

Voltar para Edge Devices

 

  1. Clique no botão back de Networking & Security para voltar para a página anterior.

 

 

Acesse o gateway de perímetro 01

 

  1. Clique duas vezes em edge-3 (gateway de perímetro 01)

 

 

Ativar o ECMP no gateway de perímetro 01

 

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Clique em Global Configuration no painel esquerdo
  4. Clique no botão Enable ao lado de ECMP

 

 

Publicar a alteração

 

  1. Clique em Publish Changes para enviar a alteração de configuração por push.

 

 

Voltar para Edge Devices

 

 

 

Acessar o gateway de perímetro 02

 

 

 

 

Ativar o ECMP no gateway de perímetro 02

 

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Clique em Global Configuration no painel esquerdo
  4. Clique no ENABLE Button ao lado de ECMP

 

 

Publicar a alteração

 

  1. Clique em Publish Changes para enviar a alteração de configuração por push.

 

 

Visão geral da topologia

 

Neste estágio, esta é a topologia do laboratório.  Ela inclui o novo gateway de perímetro adicionado, o roteamento configurado e o ECMP ativado.

 

 

Verificar a funcionalidade ECMP do roteador distribuído

 

Agora vamos acessar o roteador distribuído para garantirmos que o OSPF esteja se comunicando e que o ECMP esteja funcionando.

  1. Clique no ícone Home
  2. Selecione VMs and Templates

 

 

Iniciar o console remoto

 

  1. Clique no ícone Refresh
  2. Expanda a pasta RegionA01
  3. Selecione Distributed-Router-01-0
  4. Selecione a guia Summary
  5. Clique em Launch Remote Console

 

 

Acessar o console remoto

 

Quando a janela VMRC abrir pela primeira vez, ela estará preta.  Clique dentro da janela e pressione Enter algumas vezes para fazer o console aparecer do protetor de tela.

Observação: para liberar seu cursor da janela, pressione as teclas Ctrl+Alt

 

 

Fazer login no gateway de perímetro

 

Faça login no roteador distribuído com as credenciais a seguir

  1. Nome de usuário: admin
  2. Senha: VMware1!VMware1!

 

 

Visualizar os vizinhos OSPF

 

A primeira ação que faremos é examinar os vizinhos OSPF até o roteador distribuído.

  1. Digite show ip ospf neighbors e pressione Enter.  (Lembre-se de usar a opção SEND TEXT).
show ip ospf neighbors 

Isso nos mostra que agora o roteador distribuído tem dois vizinhos OSPF.  Os vizinhos são Perimeter-Gateway-1(192.168.100.3) e Perimeter-Gateway-2 (192.168.100.4).

Observação: a conclusão da guia funciona em dispositivos Edge no NSX.

 

 

Revisar rotas do roteador distribuído para Edges de perímetro

 

  1. Insira show ip route e pressione Enter
show ip route

Observação: os segmentos de rede do roteador vPod e a rota padrão são publicados por meio de endereços de rede do gateway de perímetro.  As setas vermelhas acima estão apontando para os endereços do Perimeter-Gateway-01 e do Perimeter-Gateway-02.

Deixe essa janela aberta para as próximas etapas.

 

 

Verificar a funcionalidade ECMP do roteador vPod

 

Observação: para liberar seu cursor da janela, pressione as teclas Ctrl+Alt

Agora examinaremos o ECMP do roteador vPod, que simula um roteador físico em sua rede.

  1. Clique no ícone PuTTY na Barra de Tarefas

 

 

Abrir a sessão SSH para o roteador vPod

 

  1. Usando a barra de rolagem, role para baixo e selecione vPod Router
  2. Clique em Load
  3. Clique em Open

 

 

Fazer login no roteador vPod

 

A sessão Putty deve fazer login automaticamente como o usuário root

 

 

Acessar o módulo BGP

 

Devemos fazer telnet no módulo que controla o BGP no roteador vPod.

1.  Insira telnet localhost 2605 e pressione Enter.  (Lembre-se de usar a opção SEND TEXT).

telnet localhost 2605

2.  Insira a senha VMware1!

 

 

Mostrar vizinhos BGP

 

Devemos fazer telnet no módulo que controla o OSPF no roteador vPod.

  1. Insira show ip bgp neighbors e pressione Enter
show ip bgp neighbors
  1. Nós veremos Perimeter-Gateway-01 (192.168.100.3) como um vizinho BGP com um estado BGP Established, up

 

 

Verificar o relacionamento de Perimeter-Gateway-02

 

  1. Verifique na parte inferior da lista BGP Neighbors se vemos Perimeter-Gateway-02 (192.168.100.4) como um vizinho BGP com um estado BGP Established, up

 

 

Mostrar as rotas

 

1. Insira show ip bgp e pressione Enter

show ip bgp

2. Nesta seção, você observa que todas as redes têm dois roteadores de próximo hop listados e isso acontece porque Perimeter-Gateway-01 (192.168.100.3) e Perimeter-Gateway-02 (192.168.100.4) são vizinhos estabelecidos para essas redes.

Neste ponto, todo o tráfego conectado ao roteador distribuído poderá sair dos gateways de perímetro com ECMP.

Deixe essa janela aberta para as próximas etapas.

 

 

Desligar o gateway de perímetro 01

 

Simularemos um nó ficando offline ao desligarmos o Perimeter-Gateway-01

  1. Expanda as pastas RegionA01
  2. Clique com o botão direito do mouse em Perimeter-Gateway-01-0
  3. Clique em Power
  4. Clique em Shut Down Guest OS

 

 

Confirmar o desligamento

 

  1. Clique em Yes

 

 

Testar a alta disponibilidade com ECMP

 

Com o ECMP, BGP e o OSPF no ambiente, podemos alterar as rotas dinamicamente no caso de uma falha em um determinado caminho.  Agora simularemos a queda de um dos caminhos e a redistribuição da rota.

  1. Clique no ícone do Prompt de Comando na barra de tarefas

 

 

Ping db-01a no servidor de banco de dados

 

  1. Insira ping -t db-01a e pressione Enter
ping -t db-01a

Você verá os pings do centro de controle para o servidor de banco de dados (db-01a) começarem.  Deixe essa janela aberta e em execução enquanto prossegue para a próxima etapa.

 

 

Acessar a console remoto do roteador distribuído

 

 

 

Verificar as rotas atuais

 

  1. Insira show ip route e pressione Enter
show ip route

Observação: somente o Perimeter-Gateway-02 está disponível para acessar os segmentos de rede do roteador vPod.

Deixe essa janela aberta para as próximas etapas.

 

 

Ligar o gateway de perímetro 01

 

  1. Expanda as pastas RegionA01
  2. Clique com o botão direito do mouse em Perimeter-Gateway-01-0
  3. Clique em Power
  4. Clique em Power On

 

 

Verificar se Perimeter-Gateway-01 está online

 

Levará um minuto ou dois para que a VM seja ligada.  Assim que ela mostrar que as VMTools estão online no VM Summary, você poderá prosseguir para a próxima etapa.

  1. Clique no ícone Refresh para verificar se há atualizações no status das VMTools.

 

 

Voltar para o teste de ping

 

 

 

Pareamento de vizinho BGP

 

Embora essa não seja uma representação clara do failover do Perimeter-Gateway-02 para o Perimeter-Gateway-01, o tráfego de ping migraria do Perimeter-Gateway-02 para o Perimeter-Gateway-01 com impacto mínimo caso o caminho ativo ficasse inativo.

 

 

Acessar a console remoto do roteador distribuído

 

 

 

Mostrar as rotas

 

vamos verificar o status das rotas no Distributed Router 01 desde que ligamos o Perimeter-Gateway-01b novamente.

  1. Insira show ip route e pressione Enter
show ip route

Observação: agora devemos ver que todas as redes do roteador vPod voltaram à conectividade dupla.

 

 

Observação final sobre ECMP

Uma observação final sobre ECMP e HA neste laboratório.  Embora tenhamos feito você desligar o Perimeter-Gateway-01, o resultado de fazer isso no Perimeter-Gateway-02 seria o mesmo.  

A única ressalva é que o Customer DB App não funcionará quando o Perimeter-Gateway-01 estiver offline, já que as VMs do servidor Web estão diretamente conectadas a ele.  Isso poderia ser resolvido movendo a camada da Web para o Distributed-Router-01, como foi feito com as redes do banco de dados e do aplicativo na seção Roteamento dinâmico e distribuído deste laboratório.  Depois de concluído, o Customer DB App funcionará caso o Perimeter Gateway 1 ou 2 esteja off-line.  É importante observar que a execução dessa migração prejudicará os outros módulos deste laboratório!  Esse é o motivo porque isso não será feito como parte do manual.  Se você não for experimentar os outros módulos, poderá executar essa migração sem problemas.

 

Antes de passar para o Módulo 3 - conclua as etapas de limpeza a seguir


Caso você planeje prosseguir para qualquer outro módulo deste laboratório depois de concluir o Módulo 2, deverá concluir as etapas a seguir ou o laboratório não funcionará adequadamente daqui em diante.


 

Exclua o segundo dispositivo Edge de perímetro

 

  1. Volte ao vSphere Web Client
  2. Clique no ícone Home, então em Networking & Security 

 

 

Exclua o Edge-7

 

Precisamos excluir o Edge que acabamos de criar

  1. Selecione NSX Edges
  2. Selecione Edge-7
  3. Clique no X vermelho para excluir

 

 

Confirme a exclusão

 

  1. Clique em Yes para confirmar a exclusão.

 

 

Desative o ECMP no DLR e o Perimeter Gateway-01

 

  1. Clique duas vezes em Edge-6

 

 

Desative o ECMP no roteador distribuído

 

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Clique em Global Configuration no painel esquerdo
  4. Clique em DISABLE Button ao lado de ECMP

 

 

Publicar a alteração

 

  1. Clique em Publish Changes para enviar a alteração de configuração por push.

 

 

Voltar para Edge Devices

 

  1. Clique no botão back de Networking & Security para voltar para a página anterior.

 

 

Acesse o gateway de perímetro 1

 

  1. Clique duas vezes em Edge-3

 

 

Desative o ECMP no gateway de perímetro 1

 

  1. Clique na guia Manage
  2. Clique na guia Routing
  3. Clique em Global Configuration no painel esquerdo
  4. Clique em DISABLE Button ao lado de ECMP

 

 

Publicar a alteração

 

  1. Clique em Publish Changes para enviar a alteração de configuração por push.

 

Conclusão do Módulo 3


Neste módulo, mostramos os recursos de roteamento do NSX para o serviço de kernel do hypervisor, o roteador lógico distribuído, bem como os recursos de serviços avançados dos NSX Edge Services Gateway.

Nós abordamos a migração de switches lógicos do gateway de serviços do Edge para o roteador lógico distribuído (DLR), e a configuração de um protocolo de roteamento dinâmico entre o Edge e o DLR.  Nós também revisamos os recursos de roteamento centralizados do gateway de serviços do Edge e as informações de emparelhamento de rota dinâmica. Por fim, pudemos demonstrar a escalabilidade e a disponibilidade dos gateways de serviços do Edge em uma configuração de rota ECMP (vários caminhos de custo equivalente). Nós implantamos um novo gateway de serviços do Edge e estabelecemos o emparelhamento de rota com o DLR e o roteador vPod para aumentar o throughput e a disponibilidade aproveitando o ECMP. Nós também limpamos nossa configuração ECMP para nos prepararmos para outro módulo deste ambiente de laboratório.


 

Você terminou o Módulo 3

Parabéns por concluir o Módulo 3.

Se você estiver procurando por informações adicionais sobre os recursos e a configuração do roteamento do NSX e então examine o centro de documentação do NSX 6.2 por meio do URL abaixo:

Continue em qualquer módulo abaixo que seja do seu interesse:

Lista de módulos de laboratório:

Chefes do laboratório:

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END

 

Módulo 4 - Edge Service Gateway - ESG (60 minutos)

Introdução ao NSX Edge Services Gateway


O NSX Edge oferece serviços de segurança e de gateway de perímetro de rede para isolar uma rede virtualizada. Você pode instalar um NSX Edge como um roteador lógico (distribuído) ou como um gateway de serviços.

O roteador lógico (distribuído) do NSX Edge oferece roteamento distribuído Leste-Oeste com isolamento para o intervlo de endereçamento IP (multi-tenant) e do plano de dados. As máquinas virtuais ou as cargas de trabalho que residem no mesmo host em subnets diferentes podem se comunicar umas com as outras sem precisar atravessar uma interface de roteamento tradicional.

O NSX Edge Services Gateway conecta redes stub isoladas a redes compartilhadas (uplink) ao fornecer serviços de gateway comuns, como DHCP, VPN, NAT, roteamento dinâmico e balanceamento de carga. As implantações comuns de NSX Edges incluem os ambientes de DMZ, VPN, Extranets e ambientes multi-tenant em nuvem, onde o NSX Edge cria limites virtuais para cada tenant.

Este módulo contém as seguintes lições:


Implantar o Edge Services Gateway como balanceador de carga


O NSX Edge Services Gateway também pode oferecer a funcionalidade de balanceamento de carga.  Empregar um balanceador de carga é vantajoso porque ele leva a uma utilização de recursos mais eficiente. Os exemplos podem incluir um uso mais eficiente de throughput de rede, tempos de resposta mais curtos para aplicativos, a capacidade de escalar e também pode fazer parte de uma estratégia para garantir a redundância e a disponibilidade de serviço.

As solicitações TCP, UDP, HTTP ou HTTPS podem ter sua carga equilibrada utilizando o gateway de serviços do NSX Edge. O gateway de serviços do Edge pode fornecer balanceamento de carga até a Camada 7 do modelo OSI (Open Systems Interconnection).

Nesta seção, implantaremos e vamos configurar um novo appliance do NSX Edge como um balanceador de carga em modo One-Armed.


 

Validar se o laboratório está pronto

 

As verificações de validação garantem que todos os componentes do laboratório sejam corretamente implantadas e, assim que a validação for concluída, o status será atualizado para Green/Ready. É possível ter uma falha de implantação de laboratório devido a restrições de recursos do ambiente.

 

 

Fazer login no vSphere Web Client

 

Se você ainda não tiver feito login no vSphere Web Client:

Clique no ícone do Google Chrome na Barra de Tarefas. A página inicial deve ser o vSphere Web Client.

  1. Marque a caixa Use Windows session authentication
  2. Clique no botão Login

 

 

Obtenha espaço na tela ao recolher o painel direito de tarefas

 

Clicar nos Push-Pins permitirá que os painéis de tarefa sejam recolhidos e forneçam mais espaço de visualização para o painel principal.  Você também pode recolher o painel esquerdo para obter o máximo de espaço.

 

 

Abra Networking &  Security

 

  1. Clique em "Networking & Security"

 

 

Criação de um novo Edge Services Gateway

 

Nós vamos configurar o serviço de balanceamento de carga em modo One-Armed em um Edge Services Gateway. Para iniciar o processo de criação do Edge Services Gateway, verifique se está na seção Networking & Security do vSphere Web Client:

  1. Clique em NSX Edges
  2. Clique no ícone do sinal "+ verde (+)

 

 

Definição do nome e do tipo

 

Para o novo NSX Edge Services Gateway, defina as seguintes opções de configuração

  1. Insira o nome: OneArm-LoadBalancer
  2. Clique no botão Next

 

 

Configuração da conta do administrador

 

  1. Defina a senha como: VMware1!VMware1!
  2. Clique no botão Next

 

 

Definição do tamanho do Edge e do posicionamento da VM

 

Existem quatro tamanhos de appliance diferentes que podem ser escolhidos para o Edge Services Gateway, com as seguintes especificações (número de CPUs, memória):

Nós selecionaremos um Edge de tamanho compacto para este novo Edge Services Gateway, mas vale a pena lembrar que esses Edge Services Gateway também podem ser atualizados para um tamanho maior após a implantação.  Para continuar com a criação do novo Gateway de serviços do Edge:

  1. Clique no ícone de sinal "+" verde para abrir a janela pop-up Add NSX Edge Appliances.

 

 

Posicionamento do cluster/datastore

 

  1. Selecione RegionA01-MGMT01 como seu posicionamento de Cluster/Resource Pool
  2. Selecione RegionA01-ISCSI01-MGMT01 como posicionamento de Datastore
  3. Selecione um host esx-05-a.corp.local
  4. Clique em OK

 

 

Configurar a implantação

 

  1. Clique no botão Next

 

 

Incluindo uma nova interface de rede no NSX Edge

 

Já que ele é um balanceador de carga em modo One-Armed, só precisará de uma interface de rede.  Nesta seção do processo do novo NSX Edge, daremos a esse Edge um novo adaptador de rede e vamos configurá-lo.

  1. Clique no ícone do sinal "+" verde.

 

 

Configuração da nova interface de rede do NSX Edge

 

Este é o local onde vamos configurar a primeira interface de rede para o novo NSX Edge.

  1. Dê à nova interface o nome WebNetwork
  2. Marque Internal como um tipo
  3. Clicando no link Select

 

 

Seleção de rede para nova interface do Edge

 

Essa interface do balanceador de carga em modo One-Armed precisará estar na mesma rede que os dois servidores da Web para os quais este Edge fornecerá serviços de balanceamento de carga.

  1. Selecione a guia Logical Switch
  2. Selecione o botão de opção de Web_Tier_Logical_Switch (5000)
  3. Clique no botão OK

 

 

Configuração das Subnets

 

  1. Em seguida, vamos configurar um endereço IP para esta interface. Clique no pequeno ícone de sinal "+" verde.

 

 

Configuração do pop-up Subnets

 

Para adicionar um novo endereço IP a esta interface:

  1. Insira um endereço IP 172.16.10.10
  2. Insira um comprimento de prefixo de sub-rede 24
  3. Clique em OK

 

 

Confirme a lista de interfaces

 

Examinar configurações/seleções

  1. Clique no botão Next para continuar

 

 

Configuração do Default Gateway

 

Nesta próxima seção de aprovisionamento, um novo Edge nos permitirá configurar o Default Gateway para este Edge Services Gateway.  Para configurar o gateway:

  1. Insira um IP de gateway 172.16.10.1
  2. Clique no botão Next

 

 

Configuração de opções de firewall e de HA

 

Para economizar tempo depois, podemos configurar algumas opções padrão do firewall, bem como ativar um Edge Services Gateway a ser executado em modo de alta disponibilidade (HA).  Nenhum recurso é relevante para esta seção em particular do módulo e, portanto, para continuar, configure o seguinte:

  1. Marque a caixa de seleção Configure Firewall default policy
  2. Selecione Accept as the Default Traffic Policy
  3. Clique em Next

 

 

Revisão da configuração geral e Finalize

 

Confirme se a configuração se parece com esta captura de tela.

  1. Clique em Finish.

 

 

Monitoramento da implantação

 

Para monitorar a implantação do Gateway de serviços do Edge:

  1. Clique no botão Installing enquanto o Edge estiver sendo implantado para ver o andamento das etapas da instalação.

Depois disso, veremos o andamento da implantação do Edge.

 

Configurar o Edge Services Gateway como balanceador de carga


Agora que o Edge Services Gateway foi implantado, vamos configurar os serviços de balanceamento de carga.


 

Configure o serviço do balanceador de carga

 

Acima, é representada a topologia eventual que teremos para o serviço do balanceador de carga fornecido pelo NSX Edge Services Gateway que acabamos de implantar.  Para começar, na área NSX Edges do plug-in Networking & Security para o vSphere Web Client, clique duas vezes no Edge em cuja página de manutenção acabamos de entrar.

 

 

Configure o recurso de balanceamento de carga no balanceador de carga em modo One-Armed

 

  1. Clique duas vezes em edge-7 (OneArm-LoadBalancer)

 

 

Navegando até a página de gerenciamento do novo Edge

 

  1. Clique na guia Manage (se ela ainda não tiver sido selecionada)
  2. Clique na subguia Load Balancer
  3. Clique em Global Configuration (se ela ainda não tiver sido selecionada)
  4. Clique no botão Edit para ir para a janela pop-up de configuração global Edit Load Balancer

 

 

Edite a Configuração global do Balanceador de carga

 

Para ativar o serviço do balanceador de carga;

  1. Marque a caixa de seleção Enable Load Balancer
  2. Clique no botão OK

 

 

Criação de um novo perfil de aplicativo

 

Um perfil de aplicativo é como nós definimos o comportamento de um tipo de tráfego de rede típico.  Esses perfis são então aplicados a um servidor virtual (VIP) que tratará do tráfego com base nos valores especificados no perfil de aplicativo.

A utilização de perfis pode tornar as tarefas de gerenciamento de tráfego menos propensas a erro e mais eficientes.

  1. Clique em Application Profiles
  2. Clique no ícone de sinal "+" para abrir a janela pop-up New Profile

 

 

Configuração do HTTPS de um novo perfil de aplicativo

 

Para o novo perfil de aplicativo, configure as seguintes opções:

  1. Nome: OneArmWeb-01
  2. Tipo: HTTPS
  3. Marque a caixa de seleção Enable SSL Passthrough. Isso permitirá que o HTTPS seja encerrado no servidor do pool.
  4. Clique no botão OK quando terminar

 

 

Modifique o monitor padrão de HTTPS

 

Os monitores garantem que os membros do pool que atendem aos servidores virtuais estejam prontos e funcionando. O monitor HTTPS padrão simplesmente fará um "GET" em "/". Modificaremos o monitor padrão para fazermos uma verificação de integridade no URL específico do aplicativo. Isso ajudará a determinar que não só os servidores membros do pool estão prontos e funcionando, mas que o aplicativo também está.

  1. Clique em Service Monitoring
  2. Clique e realce default_https_monitor
  3. Clique no ícone de lápis
  4. Digite "/cgi-bin/hol.cgi" como URL
  5. Clique em OK

 

 

Crie um novo pool

 

Um grupo de servidores de Pool é a entidade que representa os nós para os quais está sendo feito o balanceamento de carga do tráfego.  Nós adicionaremos os dois servidores da Web web-01a e web-02a a um novo pool. Para criar o novo pool, primeiro:

  1. Clique em Pools
  2. Clique no ícone de sinal "+" verde para abrir a janela pop-up Edit Pool

 

 

Configuração do novo pool

 

Para as configurações neste novo pool, configure o seguinte:

  1. Nome: Web-Tier-Pool-01
  2. Monitores: default_https_monitor
  3. Clique no sinal "+" verde

 

 

Adicione membros ao pool

 

  1. Insira web-01a como Name
  2. Insira 172.16.10.11 como IP Address
  3. Insira 443 em Port
  4. Insira 443 em Monitor Port
  5. Clique em OK

Repita o processo acima para adicionar mais um membro do pool usando as informações a seguir

 

 

Salve as configurações do pool

 

  1. Clique em OK

 

 

Crie um novo servidor virtual

 

Um servidor virtual é a entidade que aceita o tráfego do "front-end" de uma configuração de serviço com balanceamento de carga.  O tráfego do usuário é direcionado para o endereço IP representado pelo servidor virtual e então é redistribuído para nós no "back-end" do balanceador de carga. Para configurar um novo servidor virtual neste Gateway de serviços do Edge, primeiro

  1. Clique em Virtual Servers
  2. Clique no ícone de sinal "+" verde pequeno para abrir a janela pop-up New Virtual Server

 

 

Configure o novo servidor virtual

 

Configure as opções a seguir para o novo servidor virtual:

  1. Nomeie este servidor virtual como Web-Tier-VIP-01.
  2. Insira 172.16.10.10 como IP address.
  3. Selecione HTTPS como Protocol.
  4. Selecione Web-Tier-Pool-01
  5. Clique no botão OK para concluir a criação deste novo servidor virtual

 

Balanceador de carga do Edge Services Gateway - verificar a configuração


Agora que configuramos os serviços de balanceamento de carga, verificaremos a configuração.


 

Teste o acesso ao servidor virtual

 

  1. Clique em uma guia em branco do navegador
  2. Clique no marcador de favoritos para 1-Arm LB Customer DB
  3. Clique em Advanced

 

 

Ignore o erro de SSL

 

  1. Clique em Proceed to 172.16.10.10 (unsafe)

 

 

Teste o acesso ao servidor virtual

 

Neste momento, devemos obter êxito ao acessar o balanceador de carga em modo One-Armed que acabamos de configurar!

  1. Clicar no botão de atualização de página permitirá a você ver o acesso alternado(Round-Robin) nos dois membros do pool.

 

 

Mostre as estatísticas do pool

 

Para ver o status dos membros individuais do pool:

  1. Clique em Pools
  2. Clique em Show Pool Statistics.
  3. Clique em "pool-1"

Nós veremos o status atual de todos os membros.

  1. Feche a janela clicando no X.

 

 

Aprimoramento de resposta do monitor (Health Check)

 

Para auxiliar na solução de problemas, agora o comando "show ...pool" do balanceador de carga do NSX 6.2 gerará uma descrição informativa para falhas de membro do pool. Nós criaremos duas falhas diferentes e examinaremos a resposta usando comandos show no Edge Gateway do balanceador de carga.

  1. Digite "LoadBalancer" no canto superior direito da caixa de pesquisa do vSphere Web Client.
  2. Clique em "OneArm-LoadBalancer-0".

 

 

Abra o console do balanceador de carga

 

  1. Clique na guia Summary
  2. Clique em Launch Remote Console

Observação: o console será aberto em uma nova guia do navegador

 

 

Faça login no OneArm-LoadBalancer-0

 

  1. Faça login usando usuário: admin e senha: VMware1!VMware1!

 

 

Instruções especiais para comandos da CLI

 

Em muitos dos módulos, nós teremos de inserir comandos da interface (CLI, Command Line Interface).  Há duas maneiras de enviar comandos da CLI para o laboratório.

A primeira é enviar um comando da CLI para o console do laboratório:

  1. Destaque o comando da CLI no manual e use Control+c para copiar para a área de transferência.
  2. Clique no item de menu do console SEND TEXT.
  3. Pressione Control+v para colar da área de transferência para a janela.
  4. Clique no botão SEND.

Na segunda, um arquivo de texto (README.txt) foi colocado na área de trabalho do ambiente, fornecendo a você todas as contas e senhas de usuário para o ambiente.

 

 

Examine o status do pool antes da falha

 

Faça login com o nome de usuário "admin" e a senha "VMware1!VMware1!"

show service loadbalancer pool

Observação: o status do membro do pool web-sv-01a é mostrado como "UP"

 

 

Inicie o PuTTY

 

  1. Clique no atalho PuTTY na Barra de Início do Windows.

 

 

SSH para web-01a.corp.local

 

  1. Role para baixo até Web-01a.corp.local
  2. Selecione Web-01a.corp.local
  3. Clique em Load
  4. Clique em Open

 

 

Desligue o HTTPD

 

Nós desligaremos o HTTPD para simular a primeira condição de falha

  1. Digite service httpd stop para desligar o HTTPD.
service httpd stop

 

 

Console do balanceador de carga

 

show service loadbalancer pool

Como o serviço está inativo, o detalhe da falha mostrará que o cliente não conseguiu estabelecer a sessão SSL.

 

 

Reinicie o serviço HTTPD

 

Volte para a sessão SSH do Putty para web-01a

1. Digite service httpd start

service httpd start

 

 

Desligue web-01a

 

Navegue de volta para o navegador Chrome e o vSphere Web Client.

  1. No canto superior direito da caixa de pesquisa do vSphere Web Client, digite "web-01a"
  2. Clique em web-01a

 

 

Desligue web-01a

 

  1. Clique em Actions
  2. Clique em Power
  3. Clique em Power Off

 

 

Verifique o status do pool

 

show service loadbalancer pool

Como agora a VM está inativa, o detalhe da falha mostrará que o cliente não conseguiu estabelecer a conexão L4, ao contrário da conexão L7 (SSL) da etapa anterior.

 

 

Ligue web-01a

 

  1. Clique em Actions.
  2. Clique em Power
  3. Clique em Power On

 

 

Conclusão

Neste laboratório, implantamos e configuramos um novo Edge Services Gateway e ativamos os serviços de balanceamento de carga para o aplicativo 1-Arm LB Customer DB.

Isso conclui a lição sobre o balanceador de carga do gateway de serviços do Edge. Em seguida, saberemos mais sobre o firewall do Edge Services Gateway.

 

Firewall do Edge Services Gateway


O firewall do NSX Edge monitora o tráfego Norte-Sul para fornecer a funcionalidade de segurança de perímetro, incluindo firewall, NAT (Network Address Translation), bem como a funcionalidade IPSec site-to-site e VPN SSL. As configurações do firewall se aplicam ao tráfego que não corresponde a nenhuma regra de firewall definida pelo usuário. A política de firewall do Edge padrão bloqueia todo o tráfego de entrada.


 

Trabalhando com regras do firewall do NSX Edge

Podemos navegar até um NSX Edge para ver as regras de firewall que se aplicam a ele. As regras de firewall aplicadas a um roteador lógico só protegem o tráfego da camada de controle de e para a máquina virtual do roteador lógico de controle. Elas não impõem qualquer proteção ao plano de dados. Para proteger o tráfego do plano de dados, crie regras do firewall lógico para proteção Leste-Oeste no nível do Edge Services Gateway para a proteção Norte-Sul.

As regras criadas na interface do usuário do firewall aplicável a este NSX Edge são exibidas em um modo somente leitura. As regras são exibidas e impostas na seguinte ordem:

  1. As regras definidas pelo usuário através da interface do usuário do firewall (somente leitura).
  2. Regras autoconectadas (regras que permitem que o tráfego de controle flua para serviços do Edge).
  3. As regras definidas pelo usuário através da interface do usuário do firewall do NSX Edge.
  4. Regra padrão(default).

 

 

Clique em Networking & Security

 

  1. Clique em Networking & Security 

 

 

Abrir um NSX Edge

 

  1. Selecione NSX Edges
  2. Clique duas vezes em Perimeter Gateway-01

 

 

Abrir a guia Manage

 

  1. Selecione a guia Manage
  2. Selecione Firewall
  3. Selecione a Default Rule, que é a última regra na tabela do firewall.

 

 

Edite a ação de regra de firewall

 

  1. Aponte o mouse para a célula Action da regra e clique
  2. Clique no menu suspenso Action e selecione Deny

 

 

Publique as alterações

 

Nós não faremos alterações permanentes na configuração do firewall do gateway de serviços do Edge.

  1. Selecione Revert para reverter as alterações.

 

 

Adicionando uma regra no firewall do Edge Services Gateway

 

Agora que já conhecemos a edição de uma regra de firewall do Edge Service Gateway, adicionaremos uma nova regra de firewall do Edge que bloqueará o acesso do Control Center ao Customer DB App.

  1. Selecione o símbolo verde (+) para adicionar uma nova regra de firewall.
  2. Passe o mouse sobre o canto superior direito da coluna Name e selecione o símbolo (+)
  3. Insira o nome da regra: Main Console FW Rule
  4. Clique em OK.

 

 

Especifique a origem

 

Passe o mouse sobre o canto superior direito do campo Source e selecione o símbolo (+)

  1. Clique no menu suspenso Object Type e selecione IP Sets
  2. Clique no link New IP Set...
  3. Digite Main Console na caixa de texto IP Set Name
  4. Digite o endereço IP do Control Center: 192.168.110.10
  5. Clique em OK

 

 

Confirme a origem

 

  1. Confirme se Main Console está em Selected Objects
  2. Clique em OK

 

 

Especifique o Destino

 

Passe o mouse sobre o canto superior direito da coluna Destination e selecione o símbolo (+)

  1. Clique no menu suspenso Object Type e selecione Logical Switch
  2. Clique em Web_Tier_Logical_Switch
  3. Clique na seta para a direita para mover Web_Tier_Logical_Switch para Selected Objects
  4. Clique em OK

 

 

Configurar ação

 

  1. No canto superior direito da coluna Action, clique no ícone (+)
  2. Clique no menu suspenso Action e selecione Deny
  3. Clique em OK.

 

 

Publique as alterações

 

  1. Clique em Publish Changes

 

 

Testar nova regra de firewall

 

Agora que já configuramos uma nova regra de firewall que bloqueará o acesso do Control Center ao switch lógico da camada Web, vamos executar um teste rápido:

  1. Abra uma nova guia do navegador Chrome
  2. Clique no bookmark favorito chamado Customer DB App
  3. Verifique se Main Console não pode acessar o Customer DB App

Depois de alguns instantes, devemos ver uma página do navegador declarando que o site não pode ser acessado. Agora, vamos modificar a regra de firewall para permitir que o Main Console acesse o Customer DB App.

 

 

Alterar a regra Main Console FW para Accept

 

Volte para a guia vSphere Web Client.

  1. Clique no símbolo (+) no canto superior direito da coluna Action da regra Main Console FW
  2. Clique no menu suspenso Action e selecione a opção Accept
  3. Clique em OK.

 

 

 

Publicar as alterações

 

1. Clique em Publish Changes

 

 

Confirmar acesso ao Customer DB App

 

Agora que a regra Main Console FW foi alterada para "Accept", o Main Console pode acessar o Customer DB App

 

 

Excluir a regra Main Console FW

 

  1. Selecione a linha Main Console FW Rule
  2. Clique no ícone (x) vermelho para excluir a regra de firewall
  3. Clique em OK para confirmar a exclusão

 

 

Publicar as alterações

 

1. Clique em Publish Changes

 

 

Conclusão

Neste laboratório, aprendemos a modificar uma regra de firewall do Edge Services Gateway existente e a configurar uma nova regra de firewall do Edge que bloqueia o acesso externo ao Customer DB App.

Isso conclui a lição sobre o firewall do Edge Services Gateway. Em seguida, saberemos mais sobre como o gateway de serviços do Edge pode gerenciar serviços DHCP.

 

DHCP Relay


Em uma rede onde houver o mesmo segmento de rede, os clientes DHCP poderão se comunicar diretamente com o servidor DHCP. Os servidores DHCP também podem fornecer endereços IP para várias redes, mesmo aquelas que não estiverem nos mesmos segmentos deles. Entretanto, quando eles estiverem servindo endereços IP para intervalos IP fora do seu próprio, não poderão se comunicar diretamente com esses clientes. Isso acontece porque os clientes não têm um endereço IP roteável ou um gateway do qual estejam cientes.

Nessas situações, será necessário um agente de DHCP Relay para transmitir o que foi recebido de clientes DHCP e enviar para o servidor DHCP em unicast. O servidor DHCP selecionará um escopo DHCP com base no intervalo de onde o unicast está vindo, retornando-o ao endereço de agente que então será transmitido de volta à rede original e para o cliente.

Áreas tratadas neste laboratório:

Neste laboratório, os itens a seguir foram pré-configurados


 

Topologia do laboratório

 

Este diagrama mostra um layout da topologia final que será criada e usada neste módulo do laboratório.

 

 

Acesse o NSX por meio do Web Client

 

Acesse a seção Networking & Security do Web Client

  1. Clique em Networking & Security no painel esquerdo.

 

 

Crie um novo switch lógico

 

Primeiro, devemos criar um novo switch lógico, que será a nossa nova rede 172.16.50.0/24.

  1. Selecione Logical Switches
  2. Clique no sinal "+" verde para criar um novo switch lógico

 

 

Informe os novos parâmetros do switch

 

Para configurar o switch lógico, devemos definir o nome e a zona de transporte.

  1. Transport Zone, clique em Change

 

 

Selecione Transport Zone

 

  1. Selecione RegionA0_TZ
  2. Clique em OK

 

 

Informe os novos parâmetros do switch

 

O nome não importa especificamente, mas é usado para ajudar na identificação do switch.

  1. Nome = DHCP-Relay
  2. Clique em OK

 

 

Conecte o switch lógico ao gateway de perímetro

 

Agora, conectaremos o switch lógico a uma interface no gateway de perímetro.  Essa interface será o default gateway para a rede 172.16.50.0/24 como endereço 172.16.50.1.

  1. Clique em NSX Edges no painel esquerdo.
  2. Clique duas vezes em edge-3, que é o Perimeter-Gateway neste laboratório.

 

 

Adicione uma interface

 

Esta seção conectará o switch lógico a uma interface no gateway de perímetro.

  1. Clique em Manage
  2. Clique em Settings
  3. Clique em Interfaces
  4. Selecione vnic9
  5. Clique no ícone de lápis para editar a interface

 

 

Selecione a qual switch lógico a interface está conectada

 

Selecionaremos a qual switch lógico a interface está conectada.

  1. Clique em Select

 

 

Selecione o switch lógico recém-criado

 

Selecione o novo switch lógico que acabamos de criar nas etapas anteriores.

  1. Selecione DHCP-Relay Logical Switch
  2. Clique em OK

 

 

Adicione um endereço IP à interface

 

Adicionaremos um novo endereço IP.

1. Clique no sinal "+" verde

 

 

Configure o endereço IP da interface

 

Atribuiremos um endereço IP à nova interface.

  1. Primary IP address = 172.16.50.1
  2. Subnet Prefix Length = 24

 

 

Conclua a configuração da interface

 

Verifique todas as informações e conclua a configuração

  1. Altere o nome de vnic9 para DHCP Relay para facilitar a identificação posteriormente.
  2. Clique em OK

 

 

Configure o DHCP Relay

 

Permanecendo no gateway de perímetro, você deverá fazer a configuração global do DHCP Relay.

  1. Agora clique na guia Manage
  2. Clique no botão DHCP
  3. Clique na seção Relay no painel esquerdo
  4. Clique em Edit

 

 

Configuração global do DHCP

 

Na configuração global do DHCP, nós selecionamos os servidores DHCP que responderão a solicitações de DHCP das nossas VMs guest.

Há três métodos pelos quais nós podemos definir IPs de servidores DHCP:

Conjuntos de IPs

Os conjuntos de IPs são configurados em Global Configuration, no NSX Manager, e permitem que especifiquemos um subconjunto de servidores DHCP ao criar um agrupamento nomeado.

Endereços IP

É possível especificar manualmente os endereços IP de servidores DHCP neste método.

Nomes de domínio

Esse método permite especificar um nome DNS, que pode ser um ou vários endereços de servidor DHCP.

 

Neste laboratório, usaremos um endereço IP único.

  1. IP Addresses = 192.168.110.10é o IP do servidor DHCP.
  2. Clique em OK

 

 

Configure o agente de DHCP Relay

 

O agente de DHCP Relay transmitirá todas as solicitações DHCP do endereço do gateway no switch lógico para os servidores DHCP configurados.  Devemos adicionar um agente ao switch lógico/segmento criado em 172.16.50.0/24.

  1. Clique no sinal de mais verde na seção DHCP Relay Agents

 

 

Selecione a interface do gateway de perímetro

 

Selecione qual interface do gateway de perímetro terá o agente de transmissão.

  1. Clique na lista suspensa vNIC, selecione a interface criada anteriormente, DHCP Relay Internal
  2. Clique em OK

 

 

Publique configurações nas configurações do DHCP Relay

 

Agora precisamos publicar todas essas alterações para o roteador distribuído.

  1. Clique em Publish Changes

 

 

Crie uma VM em branco para a inicialização PXE

 

Agora criaremos uma VM em branco que inicializará por PXE do servidor DHCP para onde estamos transmitindo.

  1. Clique no ícone Home
  2. Clique em Hosts and Clusters

 

 

Crie uma nova VM

 

  1. Expanda RegionA01-COMP01
  2. Selecione esx-02a.corp.local
  3. Selecione o menu suspenso Actions
  4. Em seguida, clique em New Virtual Machine and New Virtual Machine

 

 

Configure a nova VM

 

  1. Selecione Create a New Virtual Machine
  2. Clique em Next

 

 

Nomeie a VM

 

  1. Name = PXE VM
  2. Clique em Next

 

 

Selecione Host

 

  1. Clique em Next

 

 

Selecionar o armazenamento

 

Deixe com o valor padrão

  1. Clique em Next

 

 

Selecione Compatibility

 

Deixe com o valor default

  1. Clique em Next

 

 

Selecione Guest OS

 

Deixe com o valor default

  1. Selecione Linux em Guest OS Family
  2. Selecione Other Linux (64-bit) em Guest OS Version
  3. Clique em Next

 

 

Especificar o hardware - remover o disco rígido

 

Precisamos excluir o disco rígido default. Como estamos inicializando da rede, o disco rígido não será necessário.  Isso acontece porque a imagem PXE está inicializando e sendo executada totalmente na RAM.

  1. Mova o cursor sobre New Hard Disk e o X aparecerá à direita.  Clique nesse X para remover o disco rígido.

 

 

Especificar o hardware - escolher a rede

 

Agora selecionaremos o switch lógico baseado em VXLAN criado anteriormente, DHCP-Relay.  Nós podemos selecioná-lo aqui ou, como alternativa, atribuir a VM ao switch lógico.  Isso é feito por meio do menu NSX Logical Switch selecionando o switch lógico e clicando em add.

  1. Selecione a rede que mostra as palavras DHCP Relay.  O UUID inteiro do switch lógico poderá variar da captura de tela acima, mas somente um terá DHCP-Relay escrito nele. Se você não conseguir ver a rede listada, clique em "show more networks".
  2. Clique em Next

 

 

Concluir a criação da VM

 

  1. Clique em Finish.

 

 

Acesse a VM recém-criada

 

Em seguida, abriremos um console para essa VM e a ligaremos e veremos sua inicialização da imagem PXE.  Ela recebe essas informações por meio do servidor DHCP remoto configurado anteriormente.

  1. Selecione PXE VM no painel esquerdo
  2. Selecione a guia Summary
  3. Clique em Launch Remote Console

 

 

Ligue a VM

 

Ligue a nova VM.

  1. Clique no botão Play

 

 

Obtendo o DHCP de um servidor remoto

 

Observe que a VM agora está tentando inicializar e obter um endereço DHCP.

 

 

Inicialização da imagem

 

Esta tela aparecerá assim que a VM tiver um endereço DHCP e estiver fazendo download da imagem PXE do servidor de inicialização.  Esta tela levará cerca de 1 a 2 minutos, prossiga para a próxima etapa.

 

 

Verifique o fornecimento de IP pelo DHCP

 

Enquanto aguardamos a inicialização da VM, podemos verificar o endereço usado no DHCP Lease.

  1. Vá para o desktop do Main Console e clique duas vezes no ícone DHCP.

 

 

Visualize os endereços

 

Podemos examinar qual endereço a VM obteve do servidor DHCP.

  1. Expanda as seções clicando nas setas
  2. Selecione Address Leases
  3. Você verá o endereço 172.16.50.10, que está no intervalo criado anteriormente

 

 

Visualize as opções

 

Também podemos ver as opções de escopo usadas para inicializar a imagem PXE

  1. Selecione Scope Options
  2. Você observará que as opções 66 e 67 foram usadas

Agora você pode fechar o DHCP.

 

 

Acesse a VM inicializada

 

  1. Volte para o console PXE VM selecionando-o na barra de tarefas.

 

 

Verifique o endereço e a conectividade

 

O widget no canto superior direito da VM mostrará as estatísticas, além do IP da VM.  Ele deve corresponder ao IP mostrado no DHCP anteriormente.

 

 

Verifique a conectividade

 

Como o roteamento dinâmico já está pronto na rede virtual, temos conectividade com a VM em sua criação.  Podemos verificar isso executando ping na VM do Main Console.

  1. Clique no ícone do Prompt de Comando na barra de tarefas.

2.     Digite ping 172.16.50.10 e pressione enter.   (Lembre-se de usar a opção SEND TEXT).

ping 172.16.50.10

Você verá então uma resposta de ping da VM.  Agora a janela de comando pode ser fechada.

 

 

Conclusão

Neste laboratório, concluímos a criação de um novo segmento de rede, então transmitimos as solicitações de DHCP da rede para um servidor DHCP externo.  Ao fazermos isso, pudemos acessar outras opções de inicialização desse servidor DHCP externo e PXE em um SO Linux.

Este laboratório foi concluído. Em seguida, vamos explorar os serviços L2VPN do gateway de serviços do Edge.

 

Configuração do L2VPN


Neste módulo, utilizaremos os recursos L2VPN do NSX Edge Gateway para estender umos limites L2 entre dois clusters vSphere separados. Para demonstrar um caso de uso baseado nessa capacidade, implantaremos um servidor L2VPN do NSX Edge no cluster RegionA01-MGMT01 e um cliente L2VPN do NSX Edge no cluster RegionA01-COMP01 e por fim testaremos o status do túnel para verificar uma configuração bem-sucedida.

 


 

Abrir o Google Chrome e navegar até o vSphere Web Client

 

  1. Abra um navegador Google Chrome do desktop (se ainda não estiver aberto).

 

 

Navegar até a seção Networking & Security do vSphere Web Client

 

  1. Clique em Networking & Security.

 

 

Criação do NSX Edge Gateway para o L2VPN-Server

 

Para criar o serviço L2VPN Server, primeiro devemos implantar um NSX Edge Gateway em que esse serviço será executado.

  1. Clique em NSX Edges.
  2. Clique no sinal "+" verde para criar um novo Edge.

 

 

Configuração de um novo NSX Edge Gateway: L2VPN-Server

 

O assistente New NSX Edge aparecerá com a primeira seção, "Name and Description", exibida.  Insira os valores a seguir, correspondentes aos números seguintes.  Deixe os outros campos em branco ou com seus valores padrão.

  1. Insira L2VPN-Server em Name.
  2. Clique em Next.

 

 

Definir configurações para o novo NSX Edge Gateway: L2VPN-Server

 

Na seção Settings do assistente New NSX Edge, execute estas ações:

  1. Insira"VMware1!VMware1!" nos campos Password e Confirm Password e deixe todas as outras opções com seus padrões.
  2. Clique no botão Next para continuar.

 

 

Adição do novo appliance do NSX Edge: L2VPN-Server

 

Na janela pop-up modal "Add NSX Edge Appliance" exibida, insira os seguintes valores:

  1. Clique no sinal "+" verde para criar um novo NSX Edge Appliance.
  2. Defina Cluster/Resource Pool:  RegionA01-MGMT01.
  3. Defina Datastore: RegionA01-ISCSI01-MGMT01.
  4. Defina Host: esx-05a.corp.local.
  5. Defina Folder: máquina virtual descoberta.
  6. Clique no botão OK para enviar esta configuração.

 

 

Voltar para Configure Deployment do novo NSX Edge Gateway: L2VPN-Server

 

  1. Clique no botão Next para continuar.

 

 

Adicione uma interface

 

  1. Clique no sinal "+"  verde para adicionar a interface.

 

 

Adição de uma nova interface ao NSX Edge Gateway: L2VPN-Server

 

  1. Insira L2VPNServer-Uplink no campo Name.
  2. Selecione Uplink para o tipo.
  3. Clique no ícone de sinal "+" verde para listar os campos para um novo Primary IP Address.
  4. Insira 192.168.5.5 como o endereço IP.
  5. Insira 29 em Subnet Prefix Length. Verifique se o comprimento inserido é 29 e NÃO 24
  6. Click no link rotulado como Select ao lado da caixa de texto chamada Connected To.

 

 

Conexão da nova interface a um switch lógico

 

Verifique se a guia Logical Switch está selecionada e execute as seguintes ações:

  1. Clique no botão de opção do switch lógico chamado Transit_Network_01 - 5006.
  2. Clique no botão OK para continuar.

 

 

Confirmação da nova configuração de interface: L2VPN-Server

 

Antes de continuar, examine estas configurações:

  1. Clique em OK para concluir a configuração.

 

 

Continuação da nova configuração do NSX Edge Gateway: L2VPN-Server

 

  1. Clique no botão Next para continuar.

 

 

Definir configurações de gateway padrão para o novo NSX Edge Gateway: L2VPN-Server

 

  1. Insira Digite 192.168.5.1 em Gateway IP.
  2. Clique em Next.

 

 

Definir configurações de firewall e HA para o novo NSX Edge Gateway: L2VPN-Server

 

Para a seção Firewall and HA, configure estas propriedades:

  1. Clique na caixa de seleção Configure Firewall default policy.
  2. Defina a configuração Default Traffic Policy como Accept.
  3. Clique no botão Next para continuar.

 

 

Examinar a nova implantação do NSX Edge Gateway e concluir: L2VPN-Server

 

  1. Clique no botão Finish para começar a implantar o NSX Edge.

 

 

Preparação do NSX Edge L2VPN-Server para conexões L2VPN

Antes de configurarmos o NSX Edge recém-implantado para conexões L2VPN, algumas etapas preparatórias serão necessárias, incluindo:

1.) Adição de uma interface trunking ao NSX Edge Gateway L2VPN-Server.

2.) Adição de uma subinterface ao NSX Edge Gateway L2VPN-Server.

3.) Configuração do roteamento dinâmico (OSPF) no Edge Gateway L2VPN-Server.

 

 

Configuração do NSX Edge L2VPN-Server

 

  1. Clique duas vezes no NSX Edge Gateway que criamos anteriormente, chamado "L2VPN-Server" para entrar em sua área de configuração.

 

 

Adição da interface trunking

 

  1. Clique na guia Manage.
  2. Clique na guia Settings.
  3. Clique em  Interfaces
  4. Selecione a vNIC com o número"1" e o nome"vnic1" como mostrado na captura de tela.
  5. Clique no ícone de lápis para abrir o assistente Edit NSX Edge Interface.

 

 

Configuração da interface trunking

 

Na janela Edit NSX Edge Interface que aparecer, insira os seguintes valores:

  1. Insira L2VPN-Server-Trunk como o nome.
  2. Defina Type: Trunk
  3. Click no link Select ao lado da caixa de texto Connected To.

 

 

Seleção do port group de tronco

 

No pop-up "Connect NSX Edge to a Network", execute estas ações:

  1. Clique em Distributed Portgroup.
  2. Clique no botão de opção de Trunk-Network-regionA0-vDS-MGMT.
  3. Clique no botão OK.

 

 

Adição de uma subinterface à interface trunking

 

  1. Clique no ícone de sinal "+" verde abaixo do rótulo Sub Interfaces.

 

 

Configuração da subinterface

 

No pop-up "Add Sub Interface", insira os valores a seguir.

  1. Name: L2VPN-Server-SubInterface
  2. Tunnel Id: 1
  3. Backing Type: Network
  4. Clique no ícone de sinal "+"  verde.
  5. Insira 172.16.10.1 no campo Primary IP Address
  6. Insira 24 em Subnet Prefix Length.
  7. Click no link Select ao lado da caixa de texto Connected To.

 

 

Conexão da subinterface a um switch lógico

 

  1. Verifique se a guia Logical Switch está selecionada.
  2. Clique no botão de opção de Web_Tier_Logical_Switch (5000).
  3. Clique no botão OK.

 

 

Confirmação da configuração da nova interface do NSX Edge

 

  1. Deixe as outras propriedades como os padrões no pop-up Edit NSX Edge Interface e clique no botão OK.

 

 

Configuração do ID do roteador para este NSX Edge

 

Em seguida, vamos configurar o roteamento dinâmico neste Edge Gateway.

  1. Clique na subguia Routing deste Edge Gateway,
  2. Clique em Global Configuration na barra de navegação esquerda.
  3. Clique no botão Edit na seção Dynamic Routing Configuration Isso mostrará uma janela pop-up onde podemos configurar a Router ID.

 

 

Adicionar L2VPNServer-Uplink

 

  1. Clique em OK.

 

 

Publicar as alterações para definir Router ID

 

  1. Clique no botão Publish Changes para enviar a alteração de configuração para este Edge Gateway.

 

 

Configuração de OSPF no NSX Edge L2VPN-Server

 

Fique na subguia Routing e

  1. Clique no item OSPF na barra de navegação esquerda.  
  2. Clique no ícone de sinal "+" verde abaixo da seção Area to Interface Mapping.

 

 

Configuração do mapeamento de área para a interface

 

No pop-up "New Area to Interface Mapping", configure os seguintes valores:

  1. vNIC: L2VPNServer-Uplink (caso ainda não esteja selecionada)
  2. Area: 0  
  3. Clique no botão OK.

 

 

Ativar o OSPF no NSX Edge L2VPN-Server

 

  1. Para ativar a configuração OSPF neste Edge Gateway, clique no botão Edit na seção OSPF Configuration.
  2. Marque a caixa de seleção Enable OSPF.
  3. Clique no botão OK.

 

 

Publicar as alterações do NSX Edge L2VPN-Server

 

  1. Clique no botão Publish Changes para enviar a alteração de configuração para este Edge Gateway.

 

 

Ativar o OSPF Route Redistribution

 

  1. Clique em Route Redistribution.
  2. Clique no botão Edit para o status Route Redistribution.
  3. Caixa de seleção OSPF para ativar o OSPF.
  4. Clique no botão OK.

 

 

Adicionar BGP à tabela de redistribuição de rotas OSPF

 

  1. Em seguida, clique no ícone de sinal "+" verde  abaixo da seção da tabela Route Redistribution.

 

 

Configurar a entrada da tabela Route Redistribution

 

No pop-up "New Redistribution criteria", configure os seguintes valores:

  1. Clique na caixa de seleção Connected e deixe todas as outras caixas de seleção desmarcadas.
  2. Clique no botão OK.

 

 

Publicar as alterações

 

  1. Clique no botão Publish Changes.

Uma vez concluído, todos os pré-requisitos foram executados para o prosseguimento da configuração do serviço L2VPN neste Edge Gateway.

 

 

Configuração do serviço L2VPN no NSX Edge L2VPN-Server

Agora que o endereço 172.16.10.1 pertence ao Edge Gateway L2VPN-Server e ele está distribuindo suas rotas dinamicamente via OSPF, começaremos a configurar o serviço L2VPN neste Edge Gateway para que o Edge aja como um "Servidor" no L2VPN.

 

 

Navegação até a área de serviços de VPN no NSX Edge Gateway L2VPN-Server

 

  1. Clique na guia VPN.
  2. Clique na seleção L2 VPN na barra de navegação esquerda.
  3. Clique no botão Change como mostrado na captura de tela.

 

 

Definição das configurações do servidor L2VPN

 

Nas definições do servidor L2 VPN, configure os seguintes valores:

  1. Defina Encryption Algorithm: ECDHE-RSA-AES256-GCM-SHA384
  2. Clique no botão OK para continuar.

 

 

Adicionar uma nova configuração de site

 

  1. Clique no ícone do sinal "+"  verde.

 

 

Configuração de um novo site L2VPN

 

  1. Marque a caixa de seleção Enable Peer Site.
  2. Insira HOLSite1 no campo de nome.
  3. User ID:  siteadmin
  4. Password: VMware1!  
  5. Clique no link Select Sub Interfaces

 

 

Seleção de uma subinterface

 

No pop-up "Select Object", execute estas ações:

  1. Selecione o objeto L2VPN-Server-SubInterface.
  2. Clique na seta para a direita para movê-lo para a lista Selected Objects.
  3. Clique no botão OK.

 

 

Confirmação da configuração do novo site

 

  1. Clique no botão OK para continuar.

 

 

Publicar as alterações para a configuração L2VPN

 

  1. Antes de clicar no botão Publish Changes, verifique se L2VPN Mode está definido como "Server."
  2. Clique no botão Publish Changes para enviar a configuração do servidor L2 VPN.

 

 

Ativar o serviço do servidor L2VPN

 

  1. Por fim, para ativar o serviço do servidor L2 VPN, clique no botão Enable como mostrado na captura de tela.  
  2. Clique em Publish Changes.

 

Isso conclui a configuração do servidor L2 VPN.  Em seguida, implantaremos outro NSX Edge Gateway novo, que agirá como o cliente L2 VPN.

 

 

Implantação do NSX Edge Gateway L2VPN-Client

Agora que o lado servidor do L2VPN está configurado, prosseguiremos com a implantação de outro NSX Edge Gateway para agir como o cliente L2 VPN. Antes de implantar o NSX Edge Gateway L2VPN Client, precisamos configurar o Uplink e Trunk port groups distribuídos  no switch virtual distribuído.

 

 

Configurar o Uplink e os Trunk port groups

 

  1. Volte para a tela inicial do vSphere Web Client e selecione Networking

 

 

Configurar o port group distribuído Uplink

 

  1. Selecione RegionA01-vDS-COMP
  2. Clique em Create a new port group

 

 

Nomear o novo port group distribuído

 

  1. Entre no Uplink-RegionA01-vDS-COMP
  2. Clique em Next

 

 

Definir configurações

 

  1. Mantenha as configurações padrão e clique em Next

 

 

Pronto para concluir

 

  1. Clique em Finish.

Repita as etapas anteriores para configurar Trunk-Network-RegionA01-vDS-COMP

 

 

Configuração vDS concluída

 

  1. Quando concluído, você deverá ver os port groups distribuídos recém-criados.
  2. Clique em Home

 

 

Volte para Networking & Security

 

  1. Clique em Networking & Security

 

 

NSX Edges

 

  1. Selecione NSX Edges

 

 

Criação do novo NSX Edge Gateway para ser o L2VPN-Client

 

  1. Clique noícone de sinal de mais verde (+) para abrir o assistente New NSX Edge.

 

 

Nome e descrição do NSX Edge L2VPN-Client

 

Para as opções aqui, selecione os seguintes valores:

  1. Install Type: Edge Services Gateway
  2. Name: L2VPN-Client
  3. Verifique se"Deploy NSX Edge" está marcado e clique no botão Next.

 

 

Definição das configurações do NSX Edge

 

Para a seção Settings, configure os seguintes valores:

  1. User Name: admin
  2. Password e confirm password: VMware1!VMware1!
  3. Clique no botão Next para continuar.

 

 

Configurar o posicionamento do NSX Edge

 

No pop-up "Add NSX Edge Appliance", configure os seguintes valores:

  1. Clique no sinal "+" verde para criar o NSX Edge Appliance.
  2. Cluster/Resource Pool: RegionA01-COMP02.
  3. Datastore: RegionA01-ISCSI01-COMP01.
  4. Host: esx-03a.corp.local.
  5. Folder: máquina virtual descoberta.
  6. Clique no botão OK para enviar esta configuração de posicionamento de VM do Edge.

 

 

Confirmar a implantação do NSX Edge

 

  1. Confirme se a configuração parece com a captura de tela mostrada aqui e clique no botão Next para continuar.

 

 

Configurar interfaces para o NSX Edge L2VPN-Client

 

  1. Na seção Configure interfaces do assistente, clique noícone do sinal de mais verde (+).

 

 

Adicionar nova interface

 

Para os parâmetros nesta interface, insira os seguintes valores:

  1. Name: L2VPN-Client-Uplink
  2. Type: Uplink
  3. Clique no sinal "+" verde para adicionar um novo endereço IP.
  4. Insira 192.168.200.5 em Primary IP Address.
  5. Insira 24 em Subnet Prefix Length.
  6. Clique no link Select ao lado da caixa de texto "Connected To" para abrir a lista de redes para escolher a que esta interface estará conectada.

 

 

Conectar a interface ao port group distribuído

 

No pop-up "Connect NSX Edge to a Network", execute estas ações:

  1. Clique na guia Distributed Portgroup.
  2. Clique no botão de opção de Uplink-RegionA01-vDS-COMP.
  3. Clique no botão OK para continuar.

 

 

Confirmar a configuração da interface

 

  1. Clique em OK para confirmar a nova interface.

 

 

Clique em Next

 

  1. Clique em Next

 

 

Configurar o Default gateway

 

Na seção Default Gateway Settings, configure os seguintes valores:

  1. Gateway IP: 192.168.200.1
  2. Clique no botão Next para continuar.

 

 

Configurações de firewall e HA

 

Na seção "Firewall e HA", execute estas ações:

  1. Marque a caixa de seleção Configure Firewall default policy.
  2. Clique no botão de opção de Accept for "Default Traffic Policy.
  3. Clique no botão Next para continuar.

 

 

Confirmar a nova configuração do NSX Edge

 

  1. Clique no botão Finish para enviar a nova configuração do Edge Gateway e iniciar o processo de implantação.

 

 

Configuração do NSX Edge Gateway L2VPN-Client

 

  1. Clique duas vezes na entrada do Edge recém-criado para entrar em sua área de gerenciamento.

 

 

Adição da Trunk Interface

 

Assim como o Edge Gateway L2VPN-Server, também há uma necessidade de adicionar uma Trunk interface nesse Edge. Para abrir a janela de configuração da nova interface, execute estas ações:

  1. Clique na guia Manage.
  2. Clique na subguia Settings.
  3. Clique na seleção Interfaces na barra de navegação esquerda.
  4. Selecione a interface chamada vnic1 sob a coluna Name.
  5. Clique noícone de lápis para abrir a área de configuração dessa interface.

 

 

Configuração da Trunk interface

 

No pop-up Edit NSX Edge Interface, insira os seguintes valores:

  1. Name: L2PVN-Client-Trunk
  2. Type: Trunk
  3. Clique no link Select ao lado da caixa de texto "Connected To" para abrir a lista de redes do vSphere disponíveis às quais essa interface será conectada.

 

 

Conectando ao Trunk port group distribuído

 

  1. Clique na guia Distributed Portgroup.
  2. Selecione o botão de opção de Trunk-Network-RegionA01-vDS-COMP.
  3. Clique no botão OK.

 

 

Configuração da subinterface

 

Configure a subinterface com os seguintes valores:

  1. Clique no sinal "+" verde para adicionar a subinterface.
  2. Name: L2VPN-Client-SubInterface.
  3. Tunnel ID: 1
  4. Backing Type: Network
  5. Clique no ícone do sinal "+" verde
  6. Insira 172.16.10.1 em Primary IP Address.
  7. Insira 24 em Subnet Prefix Length.
  8. Clique no link Select ao lado da caixa de texto Network para abrir a lista de redes disponíveis às quais essa subinterface será conectada.

 

 

Conectar a subinterface à rede de VMs

 

  1. Selecione a guia Distributed Portgroup.
  2. Marque o botão de opção de VM-RegionA01-vDS-COMP.
  3. Clique no botão OK.

 

 

Confirmar a configuração da subinterface

 

  1. Confirme se a configuração da Subinterface se parece com a captura de tela mostrada aqui e clique no botão OK para continuar.

 

 

Confirmar a adição do trunk e da subinterface

 

  1. Confirme se a configuração da Subinterface se parece com a captura de tela mostrada aqui e clique no botão OK para continuar a configurar o serviço de cliente L2 VPN.

 

 

Configurar serviços do cliente L2VPN

 

Para iniciar a configuração do cliente L2VPN, execute estas ações:

  1. Clique na subguia VPN.
  2. Clique na seleção L2 VPN na barra de navegação esquerda.
  3. Clique no botão de opção de Client na área L2VPN Mode.
  4. Clique no botão Change na área Global Configuration Details.

 

 

Configurações do cliente L2VPN

 

Para as configurações de cliente insira os seguintes valores:

  1. Server Address: 192.168.5.5
  2. Encryption algorithm: ECDHE-RSA-AES256-GCM-SHA384
  3. Para os detalhes do usuário, insira siteadmin em User ID,
  4. Insira VMware1! nos campos Password and Confirm Password.
  5. Clique no link Select Sub Interfaces ao lado da lista de subinterfaces disponíveis às quais o serviço será conectado.

 

 

Adicionar subinterface

 

Para adicionar uma nova subinterface ao serviço L2 VPN, execute as seguintes ações:

  1. Selecione o objeto L2VPN-Client-SubInterface da lista de objetos disponíveis à esquerda.
  2. Clique na seta para a direita para mover o objeto para a lista Selected Objects.
  3. Clique no botão OK.

 

 

Confirmar as configurações do cliente L2VPN

 

  1. Confirme se a configuração parece com a captura de tela aqui e clique no botão OK para continuar.

 

 

Ativar o serviço do cliente L2VPN

 

  1. Para ativar o serviço do cliente L2 VPN, clique no botão Enable como mostrado na captura de tela.

 

 

Publicar as alterações

 

  1. Clique em Publish Changes.

 

 

Buscar o status de L2VPN

 

  1. Uma vez ativado, clique no botão chamado Fetch Status. Talvez seja necessário clicar nisso algumas vezes após a ativação do serviço.
  2. Expanda Tunnel Status.
  3. Verifique se o Status é Up como visto na captura de tela acima.

Parabéns! Nós configuramos com sucesso o serviço NSX L2VPN.

Isso conclui a lição sobre a configuração dos serviços L2VPN do Edge Services Gateway.

 

Conclusão do Módulo 4


Isso conclui o Módulo 4 - Gateway de serviços do Edge: Esperamos que você tenha aproveitado o laboratório! Não se esqueça de preencher a pesquisa quando terminar.

Se você estiver procurando informações adicionais sobre a implantação do NSX, acesse o centro de documentação do NSX 6.2 por meio do URL abaixo:

Caso tenha tempo sobrando, confira a lista dos outros módulos que fazem parte deste laboratório e o tempo estimado para concluir cada um.

Clique no botão "Índice" para ir rapidamente para um módulo no manual

Lista de módulos de laboratório:

Chefes do laboratório:


Módulo 5 - Bridge físico-virtual (60 minutos)

VxLAN Bridge - Funcionalidade Nativa


O NSX oferece recursos de Bridge L2 (VxLAN Bridge) em software através do kernel, o que permite que as organizações conectem diretamente as cargas de trabalho tradicionais e VLANs à redes virtualizadas VxLAN. A VxLAN Bridge é amplamente usada em ambientes existentes para simplificar a adoção da virtualização de redes, bem como de outros cenários que envolvam sistemas físicos que exijam conectividade L2 às máquinas virtuais.

Os roteadores lógicos distribuídos podem oferecer a funcionalidade de bridge L2 entre as redes lógicas VxLAN do NSX e as VLANs das redes físicas. Isso permite a criação de uma Bridge L2 entre um Logical Switch e uma VLAN, permitindo assim a migração de dispositivos físicos para cargas de trabalho virtuais sem afetar os endereços IP. Ao criar uma Bridge entre o domínio de broadcast do Logical Switch para o domínio de broadcast da VLAN, a rede lógica VxLAN pode aproveitar um gateway L3 existente e acessar os recursos de segurança existentes nas redes físicas. No NSX-V 6.2, essa função foi aprimorada, permitindo agora que as Bridges VxLAN sejam conectadas diretamente a Logical Switches que utilizam Roteadores Lógicos Distribuídos (DLR) como Default Gateway. Esta operação não era permitida em versões anteriores do NSX.

Este módulo nos guiará pela configuração de uma instância de Bridge L2 entre uma VLAN tradicional e um Logical Switch do NSX.


 

Introdução

 

A imagem acima mostra as melhorias de Bridge L2 fornecidas no NSX 6.2:

Agora você vai configurar a Bridge L2 do NSX com o NSX 6.2 utilizando a configuração recém-suportada.

 

 

Instruções especiais para comandos da CLI

 

Em muitos dos módulos, você deverá inserir comandos da interface de linha de comando (CLI, Command Line Interface).  Há duas maneiras de enviar comandos da CLI para o laboratório.

A primeira é enviar um comando da CLI para o console do laboratório:

  1. Destaque o comando da CLI no manual e use Control+c para copiar para a área de transferência.
  2. Clique no item de menu do console SEND TEXT.
  3. Pressione Control+v para colar da área de transferência para a janela.
  4. Clique no botão SEND.

Na segunda, um arquivo de texto (README.txt) foi colocado na área de trabalho do ambiente, permitindo que você copie e cole com facilidade comandos ou senhas complexos nos utilitários associados (CMD, Putty, console etc). Com frequência, determinados caracteres não estão presentes em teclados usados no mundo.  Este arquivo de texto também é incluído para layouts de teclado que não oferecem esses caracteres.

O arquivo de texto chama-se README.txt e pode ser encontrado na área de trabalho.  

 

 

Acesse o vSphere Web Client

 

 

 

Faça login no vSphere Web Client

 

Faça login no vSphere Web Client usando a autenticação de sessão do Windows.

  1. Clique em Use Windows session authentication - isso preencherá automaticamente com as credenciais administrator@corp.local / VMware1!
  2. Clique em Login

 

 

Verifique a configuração inicial

 

Agora você pode verificar a configuração inicial. O ambiente vem com um Port Group no Cluster Management & Edge, chamado "Bridged-Net-RegionA0-vDS-MGMT" (Bridge-Net). As VMs correspondentes aos servidores Web são chamadas "web-01a" e "web-02a" estão conectadas ao switch lógico Web-Tier-01 no momento e estão isoladas do Port Group "Bridged-Net". A imagem mostra a topologia.

 

 

Acesse a configuração de rede do vSphere

 

  1. Clique no ícone Home
  2. Clique em "Networking" para acessar a interface de configuração de rede do vSphere.

 

 

Acesse o Port Group

 

  1. Expanda a árvore de objetos ("vcsa-01a.corp.local", "RegionA01", "RegionA01-vDS-MGMT")
  2. Clique no port group "Bridged-Net-RegionA0-vDS-MGMT" presente na lista

 

 

Edite as Configurações

 

  1. Clique em Actions.
  2. Clique em Edit Settings.

Observação: vamos definir a VLAN para permitir a apresentação do Port Group "Bridged-Net" para o Roteador Distribuído criar a Bridge L2.

 

 

Edite as Configurações de VLAN

 

  1. Clique em VLAN na lista Edit Settings.
  2. Clique na lista suspensa VLAN type.
  3. Selecione VLAN.

 

 

Adicione a VLAN 101 ao Port Group "Bridge-Net

 

  1. Adicione "101" ao campo VLAN ID.
  2. Clique em OK.

 

 

Verifique o ID da VLAN

 

  1. Clique na guia "Summary".
  2. Verifique se o Port Group está configurado com a VLAN ID 101.

 

 

Migre a VM web-01a para o cluster RegionA01-MGMT01

 

  1. Clique no ícone Home
  2. Selecione VMs and Templates

 

 

Migre a VM web-01a

 

  1. Expanda a lista suspensa vcsa-01a.corp.local vCenter.
  2. Expanda a lista suspensa RegionA01data center.
  3. Clique com o botão direito do mouse em web-01a.corp.local.
  4. Clique em Migrate.

 

 

Selecione o tipo de migração

 

  1. Selecione Change both compute resources and storage.
  2. Selecione a opção Select compute resource first.
  3. Clique em Next.

 

 

Selecione o recurso de processamento

 

  1. Expanda a lista suspensa vcsa-01a.corp.local vCenter.
  2. Expanda a lista suspensa RegionA01data center.
  3. Expanda o cluster RegionA01-MGMT01.
  4. Selecione esx-04a.corp.local.
  5. Clique em Next.

 

 

Selecione o armazenamento

 

  1. Selecione o armazenamento RegionA01-ISCSI01-MGMT01.
  2. Clique em Next.

 

 

Selecione a rede de destino

 

  1. Clique no menu suspenso na coluna Destination Network.
  2. Selecione Browse.

 

 

Selecione Bridged-Net-RegionA0-vDS-MGMT

 

  1. Selecione a rede Bridged-Net-RegionA0-vDS-MGMT.
  2. Clique em OK.

 

 

Verifique a rede de destino e clique Next

 

  1. Clique em Next.

 

 

Selecione a prioridade do vMotion

 

  1. Selecione Schedule vMotion with high priority (recommended)
  2. Clique em Next.

 

 

Clique em Finish

 

  1. Clique em Finish.

 

 

Visualize as VMs conectadas

 

  1. Clique no botão Back para ir para Networking.

 

 

Visualize os objetos relacionados ao Port Group "Bridged-Net"

 

  1. Selecione o port group Bridged-Net-RegionA0-vDS-MGMT.
  2. Selecione a guia Related Objects.
  3. Selecione a visualização Virtual Machines.

Observação: a VM web-01a.corp.local deverá estar listada agora. Caso necessário clique no botão "Refresh" para atualizar o status

4.    Clique em web-01a.corp.local.

 

 

Abra o console da VM web-01a

 

  1. Clique na guia Summary e verifique se a VM tem um endereço IP 172.16.10.11.
  2. Clique em Launch Remote Console.

 

 

Verifique se a VM está isolada

 

Assim que a janela do console estiver aberta, clique no meio da tela e pressione "Enter" para que algo apareça nela.

  1. Faça login como root com a senha VMware1!
  2. Digite ping -c 3 172.16.10.1     (lembre-se de usar a ferramenta SEND TEXT)
ping -c 3 172.16.10.1

Aguarde até o ping atingir o tempo limite: você acabou de verificar que a VM está isolada, já que não há outros dispositivos na VLAN 101 e a Bridge L2 ainda não está configurada.

 

 

Migre o Web_Tier_Logical_Switch para o Roteador Lógico Distribuído

 

  1. Clique no ícone Home.
  2. Selecione Network & Security.

 

 

Remova Web_Tier do roteador Perimeter Gateway

 

  1. Clique em NSX Edges.
  2. Clique duas vezes em edge-3 Perimeter-Gateway-01.

 

 

Remova a interface vNIC da camada Web

 

  1. Clique na aba Manage.
  2. Clique na aba Settings.
  3. Selecione Interfaces.
  4. Selecione a interface com nome Web_Tier.
  5. Exclua o Logical Switch Web_Tier do ESG.

 

 

Clique em OK

 

 

 

Volte para o menu "Edges

 

  1. Clique no botão Back de Networking & Security para voltar para o menu "Edges.

 

 

Selecione o Distributed-Router-01

 

  1. Clique duas vezes em Distributed-Router-01.

 

 

Conecte o Logical Switch da camada Web

 

  1. Clique em Manage.
  2. Clique em Settings.
  3. Selecione Interfaces no menu esquerdo.
  4. Clique no "sinal de mais verde" para adicionar o Logical Switch da camada Web.

 

 

Conecte o Logical Switch da camada Web

 

  1. Insira Web-Tier no campo Name.
  2. Clique em Select ao lado do campo Connected To.

 

 

Selecione o Logical Switch da camada Web

 

  1. Selecione Web_Tier_Logical_Switch.
  2. Clique em OK.

 

 

Adicione o Endereço IP Primário

 

  1. Clique no "sinal de mais verde" para configurar o endereço IP primário da sub-rede.
  2. Insira "172.16.10.1" em Primary IP Address.
  3. Insira "24" em Subnet Prefix Length.
  4. Clique em OK.

 

 

Confirmar a adição do Logical Switch ao Roteador Lógico Distribuído

 

Confirme se o Logical Switch da camada Web foi implantado com êxito.

 

 

Configurar a Bridge L2 do NSX

 

Agora você poderá ativar a Bridge L2 do NSX entre a VLAN 101 e o Logical Switch Web-Tier-01, para que a VM "web-01a" consiga se comunicar com o restante da rede. Com o NSX-V 6.2, agora é possível ter uma Bridge L2 e um Roteador Lógico Distribuído conectado ao mesmo Logical Switch. Isso representa uma melhoria importante, já que simplifica a integração do NSX à ambientes existentes, bem como a migração da rede física para a rede virtual.

 

 

Criando uma nova Bridge L2

 

  1. Clique na guia "Bridging".
  2. Verifique se não há instâncias de Bridge configuradas na lista, então clique no ícone de "sinal de mais verde" para adicionar uma.

 

 

Insira o nome da Bridge

 

  1. Insira Bridge-01 no campo de entrada "Name".
  2. Em seguida, clique no ícone para selecionar um Logical Switch ao qual nossa Bridge será conectada.

 

 

Selecione o Logical Switch

 

  1. Selecione Web_Tier_Logical_Switch.
  2. Clique em OK.

 

 

Abra a caixa de diálogo de seleção do Port Group Distribuído

 

 

 

Selecione o Port Group Distribuído

 

  1. Selecione o Port Group Distribuído Bridged-Net-RegionA0-vDA-MGMT
  2. Clique em OK

 

 

Confirme a configuração da Bridge

 

 

 

Publique as alterações

 

 

 

Verifique se o roteamento está ativado

 

Verifique a configuração publicada. Você notará a mensagem "Routing Enabled": ela significa que esta Bridge L2 também está conectada a um Roteador Lógico Distribuído, que é uma melhoria do NSX-V 6.2.

 

 

Verifique a Bridge L2

A Bridge L2 do NSX foi configurada. Agora você verificará a conectividade L2 entre a VM "web-01a" conectada à VLAN 101 e as máquinas conectadas ao Logical Switch "Web-Tier-01"

 

 

Verifique a conectividade do Default Gateway

 

  1. Abra a guia do console web-01a na barra de tarefas e tente executar um ping com default gateway novamente
  2. Realize um ping -c 3 172.16.10.1
ping -c 3 172.16.10.1

Agora, o ping foi bem-sucedido: você verificou a conectividade entre uma VM conectada à VLAN 101 e ao Roteador Lógico Distribuído que é o Default Gateway da rede, por meio de uma Brisge L2 fornecida pelo NSX!

Observação: talvez você experimente pings "duplicados" durante este teste (as respostas aparecem como DUP!): isso se deve à natureza do ambiente dos laboratórios práticos e não acontecerá em um cenário real.

 

 

Exclusão da Bridge L2 criada no módulo

Se você quiser prosseguir para os outros módulos deste laboratório prático, siga as próximas etapas para desativar a Bridge L2, já que a configuração de exemplo realizada neste ambiente específico poderia entrar em conflito com outras seções, como L2VPN.

 

 

Volte ao vSphere Web Client

 

  1. Clique na guia vSphere Web Client no navegador.

 

 

Acesse a Menu de configuração do NSX

 

  1. Clique no ícone Home.
  2. Clique em"Networking & Security"no menu.

 

 

Abra a seção de configuração do Roteador Lógico

 

  1. No menu Navigator à esquerda, clique em "NSX Edges" e aguarde até a lista de NSX Edges ser carregada.
  2. Clique duas vezes no edge-6 chamado "Distributed-Router-01" para acessar sua página de configuração.

 

 

Exclua a instância de Bridge

 

  1. Clique na guia "Manage" se ela ainda não tiver sido selecionada.
  2. Em seguida, clique na guia "Bridging" se ela ainda não tiver sido selecionada.

Observação: nós devemos ver somente a instância "Bridge-01" criada anteriormente, que é destacada por padrão.

3.     Clique no ícone Delete para destruí-la.

 

 

Publique as alterações

 

  1. Clique no botão "Publish Changes" para confirmar a configuração.

 

 

Verifique a exclusão da Bridge

 

Verifique se a instância da Bridge foi excluída.

 

 

Migre a VM web-01a de volta ao cluster RegionA01-COMP01

 

  1. Clique no ícone Home.
  2. Selecione VMs and Templates.

 

 

Migre web-01a

 

  1. Expanda a lista suspensa vcsa-01a.corp.local vCenter.
  2. Expanda a lista suspensa RegionA01data center.
  3. Clique com o botão direito do mouse em web-01a.corp.local.
  4. Clique em Migrate.

 

 

Selecione o tipo de migração

 

  1. Selecione Change both compute resources and storage.
  2. Selecione a opção Select compute resource first.
  3. Clique em Next.

 

 

Selecione o recurso de processamento

 

  1. Expanda a lista suspensa vcsa-01a.corp.local vCenter.
  2. Expanda a lista suspensa RegionA01data center.
  3. Expanda o cluster RegionA01-COMP01.
  4. Selecione esx-01a.corp.local.
  5. Clique em Next.

 

 

Selecionar o armazenamento

 

  1. Selecione o armazenamento RegionA01-ISCSI01-COMP01.
  2. Clique em Next.

 

 

Selecionar a rede de destino

 

  1. Clique no menu suspenso em Destination Network.
  2. Selecione vxm-dvs-43-virtualwire-1-sid-5000-Web_Tier_Logical_Switch.

 

 

Selecione a prioridade do vMotion

 

  1. Selecione Schedule vMotion with high priority (recommended)
  2. Clique em Next.

 

 

Clique em Finish

 

 

 

Conclusão

Parabéns, você concluiu o módulo Bridge Físco-Virtual do NSX!  Neste módulo, configuramos e testamos a Bridge entre uma VLAN de um Port Group e uma VxLAN de um Logical Switch do NSX.

 

Introdução ao HW VTEP com Arista


As seções do módulo a seguir relacionadas a Hardware VTEP são informativas. Se você quiser pular diretamente para o trabalho de laboratório, avance para o Módulo 6 - Firewall Distribuído.

Em vários data centers, algumas cargas de trabalho não foram virtualizadas ou não podem ser virtualizadas. Para integrá-las à arquitetura do SDDC, o NSX oferece a capacidade de estender a rede virtual para a física por meio de Gateways de Camada 2 ou de Camada 3. Esta seção se concentrará no recurso de Gateway de Camada 2, como ele pode ser utilizado nativamente em um host que executa o NSX, ou também por meio de um dispositivo de hardware de terceiros, como o switch de rede da Arista que ainda pode ser controlado pelo NSX. Como uma plataforma, o NSX oferece aos parceiros a capacidade de integrar e criar soluções e baseado nas funcionalidades existentes. O NSX também permite que haja uma infraestrutura base ágil para ambientes de nuvem pública e privada.

O NSX como uma plataforma opera de forma eficiente, usando uma camada de "hypervisor de rede" distribuída entre todos os hosts. No entanto, em alguns casos, determinados hosts na rede não são virtualizados e não podem implementar nativamente os componentes do NSX. O NSX oferece a capacidade de criar uma Bridge ou de rotear para redes não virtualizadas externas. Novamente, ao nos concentramos na solução de Brigde, nós mostraremos como um Gateway de Camada 2 estende uma rede lógica L2 para uma rede física L2.


 

Informações de direitos autorais do guia de design da Arista e crédito da demonstração off-line

 

Esta seção do módulo do laboratório foi usada, e o material modificado do Guia de design da Arista para o NSXfor vSphere com Arista CloudVision, Versão 1.0, agosto de 2015.

Nós também gostaríamos de agradecer Francois Tallet, gerente de produtos técnicos sênior da unidade de negócios de rede e segurança da VMware nos EUA, por nos conduzir por este laboratório para fornecer a demonstração off-line da próxima seção do módulo.

 

 

Revisão do caso de uso

 

O NSX opera de forma eficiente, usando uma camada de "hypervisor de rede" distribuída entre todos os hosts. No entanto, em alguns casos, determinados hosts na rede não são virtualizados e não podem implementar nativamente os componentes do NSX. O NSX oferece a capacidade de criar uma Bridge ou de Rotear para redes não virtualizadas externas. Este módulo se concentra mais especificamente na solução de Bridge, onde um Gateway de Camada 2 estende uma rede lógica de Camada 2 para uma rede física de Camada 2.

A funcionalidade principal de um gateway de Camada 2 é:

Mapear um Logical Switch do NSX para uma VLAN. A configuração e o gerenciamento do gateway de Camada 2 são incorporados ao NSX.

O tráfego recebido no Logical Switch do NSX por meio de um túnel é desencapsulado e encaminhado para a porta/VLAN apropriada na rede física. Da mesma forma, o tráfego da VLAN na outra direção é encapsulado e encaminhado de forma apropriada no Logical Switch do NSX.

O NSX inclui de forma nativa uma versão em software da funcionalidade de Gateway da Camada 2 com um plano de dados inteiramente implementado no kernel do Hypervisor, para desempenho máximo. Além dessa funcionalidade, o NSX como uma plataforma permite ainda a integração de componentes de terceiros para obter a funcionalidade do gateway de camada 2 em hardware.

 

 

Visão geral dos componentes

 

Vários componentes estão envolvidos na conexão do gateway de hardware ao NSX. Eles são representados na figura acima.

O NSX controlleré responsável por lidar com a interação com o gateway em hardware. Para essa finalidade, uma conexão é estabelecida entre o NSX controller e um software dedicado chamado de Hardware Switch Controller (HSC). O HSC pode ser incorporado no gateway em hardware ou pode ser executado como um appliance autnomo separado. O HSC pode controlar um ou vários gateways de hardware. A Arista, por exemplo, aproveita a plataforma CloudVision como um HSC, que age como um único ponto de integração para o NSX para vários gateways em hardware Arista. O HSC executa um servidor OVSDB (Open vSwitch Database), e o NSX é conectado como um cliente OVSDB. O OVSDB é o protocolo Open vSwitch Database Management detalhado na RFC 7047. É um projeto de código aberto que oferece a capacidade de gerenciamento remoto de um banco de dados.

O NSX controller enviará a associação configurada pelo administrador entre o Lógical Switch e o switch/porta/VLAN físico para o gateway em hardware por meio do HSC. O NSX Controller também publicará uma lista de Replication Service Nodes (RSNs) que o gateway em hardware aproveitará para encaminhar tráfego de "broadcast", "unknown unicast" ou de "multicast" (BUM). O NSX Controller publicará no HSC a lista de VTEPs do Hypervisor relevantes aos Logical Switches configurados no gateway em hardware. O NSX Controller também publicará no HSC a associação entre o endereço MAC das VMs na rede virtual e o VTEP por meio do qual elas poderão ser acessadas.

Observação: pode haver vários NSX controllers em uma implantação do NSX, fornecendo redundância e dimensionamento horizontal. As tarefas mencionadas como executadas pelo NSX Controller são, na verdade, compartilhadas entre todos os NSX Controllers na rede. O HSC se conectará a todos os controllers.

 

 

Integração do NSX com o Arista CloudVision e o gateway em hardware

 

A plataforma Arista CloudVision oferece visibilidade de toda a rede e um único ponto de integração ao NSX.

A fundação do CloudVision é um serviço de infraestrutura, compartilhando e agregando o estado de trabalho de switches físicos que estejam executando o Arista EOS para fornecer visibilidade de rede e uma coordenação central. O estado de cada nó EOS físico participante é registrado no CloudVision usando a mesma arquitetura de publicação/assinatura do banco de dados do sistema do EOS (SysDB). Como um exemplo, o VCS (VXLAN Control Service) do CloudVision agrega o estado da VXLAN de toda a rede para integração e orquestração com o VMware NSX. O CloudVision também fornece gateways L2 em hardware redundante para NSX como MLAG com funcionalidade de VXLAN. MLAG com VXLAN em switches Arista oferece encaminhamento ativo-ativo sem bloqueio e redundância com failover sem ocorrência em caso de falha de switch. Além disso, o Arista CloudVision e os switches Top of Rack executam o VCS internamente, que cada VTEP de hardware usa para compartilhar o estado uns com os outros para estabelecerem túneis de VXLAN sem a necessidade de uma camada de controle multicast.

 

 

Ponto de integração operacional

 

Na operação, o Arista CloudVision se registrará no NSX controller e usará o protocolo OVSDB para sincronizar as informações de topologia, MAC para endpoints de VXLAN e associações de ID de VXLAN com o NSX. O CloudVision programará apropriadamente o switch Arista ou pares de switches MLAG (Multi-Chassis Link Aggregation) como o gateway de hardware do NSX. Essa integração de gateway de hardware permite uma sincronização quase que instantânea do estado entre endpoints de túnel de VXLAN virtuais e físicos durante qualquer alteração de rede ou evento de modificação de carga de trabalho.

O NSX Manager da VMware tem como front-end a plataforma de virtualização de rede inteira do NSX. Os usuários também podem gerenciar e operar cargas de trabalho que se estendem por sistemas virtuais e não virtualizados do NSX como um painel único.

A plataforma CloudVision da Arista oferece um conjunto de serviços que simplifica o gerenciamento do monitoramento e a integração do NSX com switches Arista no data center virtualizado. Os usuários podem aprovisionar VTEPs Arista como nós de gateway por meio da interface do usuário do NSX Manager. Isso acelera a entrega de serviço e ajuda as empresas a atender melhor às necessidades de uma forma programática e automatizada nos data centers.

A implantação da plataforma CloudVision da Arista exige duas etapas:

  1. Ativar o VXLAN Control Service (VCS) em switches ToR Arista e no CloudVision.
  2. Ativar o serviço Hardware Switch Controller (HSC) no CloudVision.

 

 

Simulação interativa do laboratório prático: VTEP de hardware com o Arista


Esta parte do laboratório é apresentada como um laboratório prático - simulação interativa. Essa simulação permitirá que você navegue pela interface do software como se estivesse interagindo com um ambiente dinâmico.

  1. Clique aqui para abrir a simulação interativa. Ela será aberta em uma nova janela ou guia do navegador.
  2. Quando terminar, clique no link "Return to the lab" no canto superior direito da janela do navegador da Web ou feche a janela para continuar nessa guia.

Considerações de design de Bridge


Há algumas diferenças significativas entre os gateways em hardware e em software:

Isso afeta a redundância e o escopo da Camada 2 na rede. Esta seção do módulo consiste em considerações de design durante a implementação de uma arquitetura de gateway de hardware com as considerações mencionadas anteriormente.  As práticas recomendadas serão mencionadas, mas é aconselhável que os usuários que estejam planejando a implementação de gateways em hardware com o NSX consultem um profissional da VMware para obter considerações específicas de seu próprio ambiente.


 

Informações de direitos autorais do guia de design da Arista

 

Esta seção do módulo do laboratório foi obtida, e seu material modificado, do Guia de design da Arista para o NSXfor vSphere com Arista CloudVision, Versão 1.0, agosto de 2015.

 

 

Alta disponibilidade com MLAG

 

A Arista dá suporte a MLAG por meio do processamento e de VXLAN juntos em sua ampla variedade de switches, o que oferece redundância de gateway L2 em hardware para o NSX. MLAG com VXLAN em switches Arista oferece encaminhamento ativo-ativo sem bloqueio e redundância com failover sem ocorrência em caso de falha de switch. O Arista CloudVision abstrai os detalhes de Multi-Chassis LAG (MLAG) e apresenta um par de switches MLAG como um único VTEP.

O fato de que vários gateways de hardware podem estar ativos ao mesmo tempo também pode influenciar o design da rede. Normalmente, um switch lógico é estendido para uma VLAN para fornecer conectividade para algum serviço que não possa ser virtualizado. Normalmente, esse serviço é redundante, o que significa que sua implementação física s estende por vários racks diferentes no data center.

 

 

Impacto no escopo de Camada 2 na rede

 

Se você examinar o lado esquerdo da figura acima, algumas máquinas virtuais estão anexadas a um Logical Switch e acessam servidores físicos por meio de um Gateway em software (Edge Services Gateway). Todo o tráfego do switch lógico para a VLAN 10, onde os servidores físicos estão localizados, precisa passar por uma única instância de ponte. Isso significa que a VLAN 10 precisa ser estendida entre os racks para acessar todos os servidores físicos necessários.

A tendência nas redes de data center nos últimos anos tem sido tentar reduzir o máximo possível a extensão da conectividade de Camada 2 para minimizar seus riscos e limitações associadas. A figura no lado direito da imagem acima mostra como isso pode obtido aproveitando um gateway em hardware ativo separado. Nesse design alternativo, cada rack que hospeda servidores físicos é configurado com um gateway de hardware. Graças a esse modelo, não há necessidade de estender a conectividade de Camada 2 entre os racks, já que os switches lógicos podem se estender diretamente até o gateway de hardware relevante ao acessarem os servidores físicos.

Observação: as VLANs definidas nos racks têm significado local (o exemplo está mostrando que o switch lógico é estendido para a VLAN 10 em um rack e para a VLAN 20 no outro).

 

 

Componentes do NSX e conectividade de cluster

 

As funções e a operação de componente do NSX são definidas no Guia de design de virtualização de rede do VMware NSX for vSphere versão 3.0 (disponível em https://communities.vmware.com/docs/DOC-27683). É altamente recomendável que o leitor consulte esse documento para seguir a lógica relacionada à conectividade com a rede física. As funções e a organização dos componentes do NSX são mapeadas para o cluster apropriado. O Guia de design de virtualização de rede do VMware NSX for vSphere solicita a organização dos componentes, do processamento e do gerenciamento do ambiente virtualizado do NSX.

O Guia de design de virtualização de rede do VMware NSX for vSphere recomenda a criação de três tipos de clusters diferentes do vSphere. A figura acima mostra um exemplo de componentes lógicos de design de cluster para o posicionamento do rack físico.

Observação: as configurações ainda menores em um único rack podem ser usadas para oferecer conectividade para o cluster de perímetro e o de gerenciamento. O conceito fundamental é que a configuração do cluster de perímetro seja localizada em um par de switches ToR para reduzir a extensão dos requisitos de camada 2; isso também ajuda a localizar a configuração de roteamento de saída para um par de switches ToR. A localização de componentes de perímetro também permite a flexibilidade na seleção do hardware apropriado (CPU, memória e NIC) e recursos baseados nas funcionalidades centradas na rede, como firewall, NetFlow, NAT e roteamento ECMP.

 

 

Switches Arista e roteamento do NSX

O NSX Edge Services Gateway oferece roteamento baseado em ECMP (Equal Cost Multi-path), que permite até oito VMs apresentem encaminhamento de tráfego bidirecional de 8 vias do domínio lógico do NSX para o core do DC da empresa ou para a Internet. Isso representa até 80 Gbps (8x10 interfaces GE) de tráfego que podem ser oferecidos do domínio virtual do NSX para a rede externa em ambas as direções. É dimensionável por "Tenant" e, portanto, a quantidade de largura de banda é elástica, já que cargas de trabalho sob demanda e/ou "multi-tenant" se expandem ou se contraem. Os requisitos de configuração para dar suporte ao Edge Gateway ECMP NSX para o roteamento Norte-Sul são os seguintes:

 

 

Design de uplink VDS com host ESXi no cluster Edge

 

O rack de perímetro tem vários requisitos de conectividade de tráfego. Primeiro, ele oferece conectividade para tráfego leste-oeste para o domínio da VXLAN via VTEP; depois, oferece uma função centralizada para usuário/tráfego externo que acessam cargas de trabalho no domínio do NSX via Port Groups suportados por VLANs dedicadas. Essa última conectividade é obtida por meio do estabelecimento de adjacências de roteamento com os dispositivos L3 no próximo "hop". A figura acima representa dois tipos de conectividade de uplink do host que utilizam comunicação ECMP através da Edge VM de perímetro.

 

 

Vizinhança ECMP do Edge e VLAN design

 

Assim que o modo de "Teaming" e "Failover" dos uplinks for determinado, a próxima etapa será fornecer diretrizes de design para a configuração da VLAN e o mapeamento para o uplink, bem como as configurações de vizinhança com os switches Arista. A primeira decisão é quantos uplinks lógicos deverão ser implantados em cada NSX Edge. A opção de design recomendada é sempre mapear o número de uplinks lógicos para o número de dvUplinks do VDS definidos nos NSX Edges disponíveis hospedados nos servidores ESXi. Isso significa sempre mapear uma VLAN (port group) para um dvUplink do VDS, que então serão mapeados para um link físico no host ESXi que se conecta ao switch Arista por meio de um ESG que forma a vizinhança de roteamento com o switch Arista.

No exemplo mostrado acima, as VMs ECMP do NSX Edge (E1 a E8) são implantadas em hosts ESXi com dois uplinks físicos conectados aos switches ToR Arista. Dessa forma, a recomendação é implantar dois uplinks lógicos em cada NSX edge. Como um uplink lógico do NSX edge está conectado a um port grupo suportado por VLAN, é necessário usar dois segmentos de VLAN externos para conectar aos roteadores físicos e estabelecer adjacências de protocolo de roteamento. Como mostrado na figura acima, cada nó ECMP é pareado com suas respectivas VLANs externas para exatamente um roteador Arista. Cada VLAN externa é definida somente em um uplink ESXi (na figura acima, a VLAN 10 externa é ativada no uplink em direção a R1, quanto a VLAN 20 externa no uplink para R2). Isso é feita de forma que, sob circunstâncias normais, ambos os uplinks ESXi possam ser utilizados de forma concomitante para enviar e receber tráfego norte-sul, mesmo sem exigir a criação de um canal de porta entre o host ESXi e os dispositivos ToR.

Além disso, com esse modelo, uma falha física de uma NIC ESXi corresponderia a uma falha de uplink lógico para o NSX edge em execução no host, e o Edge continuaria a enviar e a receber tráfego ao aproveitar o segundo uplink lógico (a segunda interface NIC ESXi física).

 

 

Recomendações de temporizador de protocolo de roteamento do NSX Edge

 

O roteador lógico NSX edge permite o roteamento dinâmico e o estático. A recomendação é usar um protocolo de roteamento dinâmico para parear com switches Arista para reduzir a sobrecarga da definição de rotas estáticas sempre que a rede lógica for definida. Os roteadores lógicos NSX edge dão suporte aos protocolos de roteamento OSPF e BGP. A configuração do modo ECMP do NSX edge dá suporte à redução do temporizador "hello and hold" do protocolo de roteamento para melhorar a recuperação de falhas de tráfego no caso de falha de nó ou de link. O temporizador mínimo recomendado para OSPF e BGP é mostrado na tabela acima.

 

 

Benefícios da arquitetura do NSX com a infraestrutura da Arista

O NSX permite que os usuários criem serviços lógicos para rede e segurança sem precisar fazer alterações de configuração na infraestrutura física. Nesse caso, assim que os switches Arista estiverem configurados para fornecer conectividade IP e a configuração de roteamento for aprovisionada, poderemos continuar a implantar novos serviços com o NSX.

 

 

Conectividade de camada lógica

 

As opções de conectividade de camada lógica para servidores na infraestrutura física permite que eles estejam em sub-redes diferentes, mais uma rede base permite que as VMs fiquem na mesma sub-rede e na camada 2 adjacente, fornecendo essencialmente conectividade independente de topologia e mobilidade além da limitação da topologia estruturada imposta pela rede física.

 

 

Roteamento para infraestrutura física

 

Para roteador da rede lógica para a rede física, o NSX pode aprender e trocar rotas com a infraestrutura física para acessar recursos como um servidor de banco de dados ou um aplicativo não virtualizado, que poderia estar em uma sub-rede diferente em uma rede física.

O NSX oferece uma arquitetura de roteamento de dimensionamento horizontal com o uso de ECMP entre o roteador distribuído NSX e as instâncias de roteamento do NSX Edge como mostrado na figura acima. Os NSX Edges podem parear usando protocolos de roteamento dinâmico (OSPF ou BGP) com os roteadores físicos e fornecer largura de banda dimensionável. No caso de uma infraestrutura de switch Arista, o par de roteamento poderia ser qualquer ToR Arista.

 

 

Operação e dimensionamento simplificados

 

A solução CloudVision da Arista simplifica a integração de ambientes físicos e virtuais. O CloudVision aproveita um banco de dados de rede, que coleta o 'estado' da rede física inteira e apresenta uma única interface aberta para o VMware NSX integrar à rede física. Usar o CloudVision como o ponto de integração permite que os detalhes da rede física sejam abstraídos dos orquestradores de nuvem e dos controllers base. Além disso, o CloudVision simplifica o esforço de integração do NSX porque o NSX só precisa se integrar ao próprio CloudVision. Isso permite que os clientes evitem a complicação de certificar o NSX com as diversas combinações de versões de hardware e de software. Por sua vez, o CloudVision fornece o estado agregado da rede física para a sincronização física para virtual mais efetiva. Isso oferece uma abordagem mais simples e mais dimensionável para a integração do controller à rede física.

Observação: o CloudVision foi criado sobre APIs abertas, incluindo OVSDB e JSON, o que oferece uma abordagem baseada em padrões para essa integração.

 

 

Visibilidade de rede lógica e física com o Arista VM Tracer

O recurso VM Tracer da Arista para NSX é nativamente integrado ao Arista EOS. Ele automatiza a descoberta de infraestrutura virtual diretamente conectada, simplificando o aprovisionamento dinâmico de VLANs relacionadas e perfis de porta na rede. Os switches Arista utilizam as APIs do VMware vCenter e do NSX Manager para coletar informações de aprovisionamento. O VM Tracer então combina essas informações aos dados do banco de dados do switch para fornecer um mapeamento claro e conciso da rede virtual para física. Os clientes podem obter um rastreamento em tempo real de switches lógicos e VMs de uma única CLI em qualquer switch Arista na rede.

 

 

Segurança com firewall distribuído

 

Por padrão, o NSX permite o firewall distribuído em cada VM no nível da vNIC. O firewall sempre está no caminho do tráfego entrando e saindo da VM. O principal benefício é que ele pode reduzir a exposição de segurança na raiz para o tráfego leste-oeste e não no local centralizado. Os benefícios adicionais do firewall distribuído incluem:

 

 

Dimensionamento flexível de aplicativos com o balanceador de carga virtualizado

 

O dimensionamento elástico da carga de trabalho de aplicativo é um dos requisitos críticos no data center de hoje. O dimensionamento de aplicativos com um balanceador de carga físico pode não ser suficiente, dada a natureza dinâmica das cargas de trabalho de TI de autoatendimento e do estilo DevOps. A funcionalidade de balanceamento de carga com suporte nativo no gateway de serviços do NSX Edge aborda a maioria dos requisitos práticos encontrados em implantações. Ela pode ser implantada programaticamente com base em requisitos de aplicativo dimensionamento e recursos apropriados. O nível de suporte a escala e ao aplicativo determina se o balanceador de carga poderá ser configurado com serviços de camada 4 ou de camada 7. O balanceador de carga ciente da topologia pode ser implantado em modo em linha ou braço único. O modo é selecionado com base em requisitos específicos do aplicativo, mas o design braço único oferece extensa flexibilidade, já que pode ser implantado próximo ao segmento do aplicativo e pode ser automatizado com a implantação do aplicativo.

A figura acima mostra o poder de um balanceador de carga baseado em software no qual várias instâncias do balanceador de carga servem vários aplicativos ou segmentos. Cada instância do balanceador de carga é um appliance de perímetro que pode ser dinamicamente definido via uma API como necessário e implantado em um modo de alta disponibilidade. Como alternativa, o balanceador de carga pode ser implantado em um modo em linha, que pode ser o domínio lógico inteiro. O balanceador de carga em linha pode dimensionar por meio da ativação de perímetro de várias camadas por aplicativo, já que cada aplicativo e um domínio dedicado para o qual o perímetro de primeira camada é um gateway para um aplicativo, o perímetro de segunda camada pode ser um gateway ECMP para fornecer a largura de banda norte-sul dimensionável.

 

 

Conclusão

A solução de Virtualização de Redesda VMware endereça os desafios atuais da infraestrutura computacional e da rede física, trazendo flexibilidade, agilidade e escalabilidade por meio de redes lógicas baseadas em VxLAN. Juntamente com a capacidade de criação de redes lógicas sob demandas usando VxLAN, o NSX Edge Gateway ajuda os usuários a implantar diversos serviços de redes como firewall, DHCP e NAT. Isso é possível devido à sua capacidade de dissociar a rede virtual da rede física e então reproduzir as propriedades e os serviços necessários no ambiente virtual.

Concluindo, a Arista e a VMware estão entregando a primeira e melhor solução dimensionável do setor para Virtualização de Redes no Data Center Definido por Software. Os provedores de nuvem, as empresas e os clientes da Web poderão acelerar drasticamente seus serviços de negócios, reduzir a complexidade operacional e os custos. Tudo isso está disponível agora, em uma solução SDDC totalmente automatizada e programática que cria a ponte entre a infraestrutura virtual e física.

 

Conclusão do Módulo 5


Neste módulo, mostramos a capacidade do NSX de criar uma Bridge entre redes VLAN e redes lógicas VXLAN.  Nós realizamos a configuração de uma Bridge no Roteador Lógico Distribuído do NSX para mapear uma VLAN para uma VXLAN.  Também realizamos uma migração de uma VM de um Logical Switch para um dvPortGroup configurado com uma VLAN para simular a comunicação entre as VMs. Por fim, clicamos na demonstração off-line da integração do NSX com um VTEP em hardware Arista para mostrar a extensão de um gateway L2 à um switch.


 

Você terminou o Módulo 5

Parabéns por concluir o Módulo 5.

Se você estiver procurando informações adicionais sobre a implantação do NSX, acesse o centro de documentação do NSX 6.2 por meio do URL abaixo:

Continue em qualquer módulo abaixo que seja do seu interesse:

Lista de módulos de laboratório:

Chefes do laboratório:

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END

 

Módulo 6 - Firewall distribuído (45 minutos)

Introdução ao Direwall Distribuído - DFW


Firewall Distribuído do NSX (DFW - Distributed Firewall). Um dos componentes do NSX é o módulo de firewall distribuído que opera diretamente no kernel do ESXi.  O DFW é instalado em todos os hosts de um mesmo cluster vSphere que precisam dessa funcionalidade ativa. O DFW opera com performance próxima à velocidade wire-speed e possui toda a resiliência da plataforma vSphere. O DFW também permite a criação de regras de acordo com o reconhecimento da identidade do usuário (Identify Firewall) além de oferecer ferramentas exclusivas para monitoramento e auditoria das atividades em uma determinada VM (Activity Monitoring).

Neste módulo, você vai explorar como o DFW ajuda a proteger um Aplicativo de 3 camadas. As tradicionais regras de firewall baseadas em endereço IP impõem limites rígidos sobre a mobilidade das VMs e reduzem a flexibilidade da utilização dos pools de recursos (Resource Pools). Ao invez das tradicionais regras de firewall baseadas em endereços IP, aqui será demonstrado o processo de criação dessas mesmas regras agora baseadas em Grupos de Segurança (Security Groups - SG) e em identidades (Identity Firewall). Este módulo basea-se em quatro guest VMs que compõem um Aplicativo de 3 camadas comum.  A camada de Apresentação (Web) possui dois servidores Web (web-01a and web-02a). A camada de Apresentação se comunica com uma VM chamada app-01a, que executa um software correspondente a sua camada de Aplicação. A VM da camada de Aplicação, por sua vez, se comunica com uma VM chamada db-01a, que está executando o MySQL na camada de Banco de Dados.  A aplicação da regras de segurança para a filtragem de acesso entre as camadas é realizada pelo DFW do NSX.  

Abaixo estão descritas brevemente as atividades referentes a esse módulo:

Firewall Distribuído - DFW

Inicie o módulo do seu desktop.  O desktop é o jumpbox do seu Control Center no ambiente virtual.  Desse desktop, você acessará o vCenter Server Appliance implantado em seu data center virtual.

Observação especial: na área de trabalho, você encontrará um arquivo chamado README.txt.  Ele contém os comandos da CLI necessários nos exercícios do laboratório.  Se você não conseguir digitá-los, poderá copiá-los e colá-los nas sessões do putty.  Caso você veja um número com "chaves - {1}" isso dirá a você para procurar o comando da CLI para este módulo no arquivo de texto.


Confirme a ativação do DFW


Use o vCenter Web Client para confirmar se o DFW está instalado e ativado.


 

Inicie o navegador Google Chrome

 

  1. Clique no ícone do navegador Chrome na barra de tarefas ou na área de trabalho do console principal.

 

 

Realize o login do vSphere Web Client

 

Se você ainda não tiver feito login no vSphere Web Client.

  1. Faça login marcando a caixa "Use Windows Session Authentication".
  2. Ou alternativamente utilize o User name: administrator@vsphere.local e o Password: VMware1!

 

 

Obtenha espaço na tela ao recolher os Paineis de Tarefas do lado direito

 

 

 

Explorando o Novo Firewall Distribuído do NSX

 

  1. Clique em Networking & Security.

 

 

Verifique a Instalação

 

  1. Primeiro, clique em Installation.
  2. Clique na guia Host Preparation.  A tabela mostrará os clusters no data center virtual.

 

Configure regras para o acesso ao Aplicativo Web


Agora você vai configurar o Firewall Distribuído para proteger o acesso ao aplicativo de 3 camadas (Customer DB-app). O aplicativo tem dois servidores Web, um servidor de aplicação e outro de banco de dados. Também há um balanceador de carga atendendo os dois servidores Web.


 

Testar a conectividade entre as VMs do Customer DB-app usando o PuTTY

 

Em seguida, você testará a comunicação e o acesso entre os segmentos de rede e as guests VMs que compõem o Aplicativo de 3 camadas. Seu primeiro teste será abrir uma console para web-01a.corp.local e realizar um ping nos outros membros.

  1. Clique no atalho do PuTTY na barra de tarefas do desktop 

 

 

Abrir uma sessão SSH para web-01a

 

  1. Localize e clique em web-01a.corp.local na lista Saved Sessions
  2. Clique em Open para conectar a sessão SSH à web-01a.

 

 

Realize o ping da web-01a para outros membros do Aplicativo de 3 camadas

 

  1. Primeiro, você vai se assegurar que a web-01a pode realizar um ping para a web-02a:
ping -c 2 172.16.10.12
  1. Agora ping app-01a.
  2. Teste o ping em db-01a.
ping -c 2 172.16.20.11
ping -c 2 172.16.30.11

(Observação: Talvez você veja DUP! no final de uma linha de ping.  Isso se deve à natureza do ambiente do laboratório virtual usando uma arquitetura Nested e o modo promíscuo nos roteadores virtuais. Você não verá isso nos ambientes em produção.

Não feche a janela, basta minimizá-la para uso posterior.

 

 

Demonstre o Customer DB-App usando um navegador web

 

Usando um navegador, você acessará o aplicativo de 3 camadas para demonstrar a função entre as 3 partes.

  1. Abra uma nova guia do navegador
  2. Clique no favorito "Customer DB-app"

 

 

Demonstre o Customer DB-App usando um navegador web (cont.)

 

Você deve receber a resposta dos dados requisitados pela camada Web para a VM app-01a e, por fim, consultados na VM db-01a.

A.  Observe a conexão HTTPS à camada Web.

B.  Observe a conexão TCP na porta 8443 para a camada de Aplicação.

C.  Observe a conexão TCP na porta 3306 para a camada de Banco de Dados.

Observe que o servidor Web real que responde pode ser diferente do mostrado.

 

 

Altere a política de firewall padrão de Allow para Block

 

Nesta seção, você mudará a regra padrão Allow para Block e mostrará a interrupção na comunicação com o Aplicativo Customer DB App de 3 camadas. Depois disso, você criará novas regras de acesso para restabelecer a comunicação em um método seguro.

  1. Clique novamente na guia do vSphere Web Client.
  2. Selecione Firewallà esquerda.  

Você verána seção General o Default Section Layer3.

 

 

Examine as regras padrão

 

  1. Expanda a seção usando o "twistie".  

Observe se as regras têm marcas verdes de verificação.  Isso significa que uma regra está ativada.  As regras são incorporadas da maneira típica com os campos de origem, de destino e de serviço.  Os serviços são uma combinação de protocolos e de portas.  

A última Default Ruleé uma permissão básica de todos para todos ("any-to-any-allow").

 

 

Explore a última regra padrão

 

Role até a direita para poder ver as opções de ação (Action) para a regra padrão e posicione o cursor no campo Action:Allow.  Isso mostrará um sinal de lápis, que permite à você ver as opções deste campo.

  1. Passe o mouse e Clique no sinal de lápis.

 

 

Altere a ação última regra padrão (Default Rule) de Allow para Block

 

  1. Selecione a opção de ação Block.
  2. Clique em Save.

 

 

Publicar as alterações da última regra padrão (Default Rule)

 

Você observará uma barra verde anunciando que agora é necessário escolher entre "Publish Changes", "Revert Changes" ou "Save Changes".  "Publish" envia as alterações para o DFW.  "Revert" cancela as suas edições. E por fim "Save Changes" permite que você salve e publique mais tarde.

  1. Selecione Publish Change para salvar sua regra de bloqueio.

 

 

Reabra a sessão PuTTY

 

  1. Clique em sua sessão PuTTY para web-01a na barra de tarefas.

 

 

Verifique se a alteração da regra bloqueia a comunicação

 

Para testar a regra de bloqueio usando suas sessões anteriores do PuTTY e do navegador

PuTTY: em alguns instantes após abrir o PuTTY, um aviso mostrará que ele não está mais ativo, isso ocorre devido à regra padrão, que agora bloqueia tudo, incluindo SSH.  Minimize o console novamente.

 

 

Verifique se o acesso ao navegador é negado

 

  1. Clique na guia referente à webapp.corp.local.
  2. Clique no botão Refresh.

O site atingirá o tempo limite em alguns segundos, isso mostrará que o acesso está bloqueado pela regra padrão definida como Block.

 

Criação dos Security Groups - Grupos de Segurança


Agora criaremos os Security Groups (Grupos de Segurança). Os Security Groups nos permitem criar contêineres reutilizáveis de VMs para os quais podemos aplicar políticas. A associação dos objetos aos grupos pode ser estabelecida de forma estática e/ou dinâmica.


 

Crie Security Groups para as 3 camadas do Aplicativo Web

 

  1. Clique na guia do navegador referente ao vSphere Web Client.
  2. Clique em Service Composer.

O Service Composer define um novo modelo para o consumo de serviços de rede e de segurança para ambientes virtuais e em nuvem. As políticas são aplicadas através da visualização dos serviços internos ou soluções de terceiros e seu simples consumo. Essas mesmas políticas podem ser reaproveitadas facilmente por meio de recursos de exportação/importação, o que poderia facilitar a implantação ou recuperação de um ambiente em caso de um problema. Um desses objetos de uso repetitivo é "Security Group".

 

 

Adicionando um Security Group

 

  1. Selecione Security Groups. Observação: pode ser necessário o uso de Security Groups existentes de outros módulos do laboratório
  2. Para adicionar um novo Security Group, clique no ícone New Security Group

 

 

Novo Security Group - Web

 

  1. Nomeie este primeiro grupo de Web-tier
  2. Clique na seção "Select objects to include"

 

 

Selecione os objetos que devem ser incluídos

 

  1. Expanda o menu Object Types e selecione Virtual Machines.
  2. Você pode filtrardigitando web na janela de pesquisa.
  3. Selecione web-01a.corp.local.
  4. Clique na "seta para a direita" para enviar a VM para a janela Selected Objects.
  5. Repita para web-02a.corp.local.
  6. Clique em Finish.

Observação:  como atalho, você pode clicar duas vezes nas VMs à esquerda e elas se moverão para a direita nesta etapa.

 

 

Verifique a criação do Security Group

 

Você criou um Security Group chamado Web-tier com 2 VMs atribuídas a ele.

Observe o Security Group Web-tier.

Observe o número de VMs incluídas no Security Group.

 

Criação das Regras de Acesso


Crie Regras de Acesso para as 3 camadas do aplicativo Customer DB.


 

Criando as Regras de Acesso de 3 camadas

 

Em seguida, você adicionará novas regras para permitir o acesso às VMs da camada Web e depois configurar o acesso entre as camadas.

  1. No menu à esquerda, escolha Firewall.

 

 

Adicione uma nova seção para as regras do Aplicativo de 3 camadas

 

  1. Na extremidade direita da linha "Flow Monitoring & Trace Flow Rules-Disabled by Default (Rule1)", clique no botão Add Section, que se parece com uma pasta.
  2. Nomeie a seção como "Customer DB-app".
  3. Clique em Save.

 

 

Adicione uma nova regra à nova seção

 

  1. Na linha da nova seção "Customer DB-app", clique no ícone Add rule, que é um "sinal de mais" verde.

 

 

Edite a nova regra

 

  1. Clique no "twistie" para abrir a regra.
  2. Passe o mouse sobre o canto superior direito do campo "Name" até um "ícone de lápis aparecer, então clique no lápis.
  3. Insira "EXT to Web" como o nome.
  4. Clique em Save.

 

 

Defina a origem e o destino da regra

 

Origem:deixe "Rule Source" (Origem) definido como "any" (qualquer).

  1. Passe o ponteiro do mouse sobre o campo Destination (Destino) e selecione o "sinal de lápis" do Destination.

 

 

Defina os valores do Security Group

 

Especifique o destino (Destination):

  1. Expanda o menu "Object Type" e role para baixo até encontrar Security Group.
  2. Clique em Web-tier.
  3. Clique na seta superior para mover o objeto para a direita.
  4. Clique em OK.

 

 

Definindo um serviço

 

  1. Passe o mouse clique no "lápis"do campo "Service".

 

 

Defina o serviço da regra

 

Passe o mouse no campo Service e clique no sinal de lápis.  

  1. No campo de pesquisa, você pode pesquisar pelos serviços padrão correspondentes. Digite "https"e pressione Enter para ver todos os serviços associados ao https do nome.
  2. Selecione o serviço HTTPS simples.
  3. Clique na seta superior.
  4. Observação: repita as etapas 1 a 3 acima para localizar e adicionar o serviço SSH.  (Você verá posteriormente no módulo que precisaremos de SSH).
  5. Clique em OK.

 

 

Crie uma regra para permitir o acesso do Security Group Web ao Switch Lógico App_Tier

 

Agora você adicionará uma segunda regra para permitir que o Security Group Web acesse a camada de Aplicação por meio da porta correspondente.

  1. Comece abrindo o "sinal de lápis.
  2. Você deseja que esta regra seja processada depois da regra anterior, portanto escolha "Add Below" na caixa suspensa.

 

 

Crie os campos Nome e Origem da Segunda Regra

 

  1. Como feito anteriormente, passe o mouse sobre o campo Name e clique no "sinal de mais". Digite "Web to App" como nome.
  2. Escolha o Security Group Object Type: Web-tier no campo Source.

 

 

Defina o destino

 

  1. Passe o mouse e clique no lápis na coluna Destination.

 

 

Crie o campo Destino da Segunda Regra: escolha Logical Switch

 

Na primeira regra, você usou o Security Group Web-tier como destino. Você poderia prosseguir com as regras restantes da mesma maneira.  Mas, como você pode ver na lista suspensa, será possível usar diversos objetos do vCenter já definidos. A integração do vSphere com as funções de segurança do NSX permitem que você economize tempo, permitindo a utilização de objetos existentes no datacenter virtual em suas regras em vez de começar do zero. Aqui, você usará um switch lógico de VXLAN como o destino. Isso permite que você crie uma regra a ser aplicada a todas as VMs conectadas a esta rede.

  1. Role para baixo na lista suspensa Object Type e clique na opção Logical Switch.
  2. Selecione App_Tier_Logical_Switch.
  3. Clique na seta superior para mover o objeto para a direita.
  4. Clique em OK.

 

 

Definindo um serviço

 

  1. Passe o mouse e clique no "lápis"da coluna Service.

 

 

Crie o Serviço da Segunda Regra: New Service

 

O Aplicativo de 3 camadas usa a porta tcp 8443 entre as camadas da Web e Aplicação.  Você criará um novo serviço chamado MyApp para ser o serviço permitido.

  1. Clique em New Service.
  2. Digite MyApp como o nome do novo serviço.
  3. Selecione TCP como o protocolo.
  4. Digite 8443 como o número da porta.
  5. Clique em OK.

 

 

Clique em OK

 

  1. Clique em OK.

 

 

Crie a Terceira Regra: Permitir que Logical Switch App_Tier acesse Logical Switch DB_Tier

 

Repetindo as etapas: por conta própria, crie a terceira e última regra permitindo o acesso entre a camada de Aplicação (App_Tier) e a camada de Banco de Dados (DB_Tier).

  1. Crie a regra final que permite ao Logical Switch deAplicação se comunicar com o Logical Switch deBanco de Dados por meio do serviço predefinido para o MySQL.  O serviço é predefinido, portanto, você só precisará pesquisá-lo em vez de criá-lo.
  2. Publicar as alterações. Clique em "Publish Changes".

 

 

Verifique se as novas regras permitem a comunicação com o Customer DB App

 

  1. Abra seu navegador e volte para a guia usada anteriormente para o Aplicativo Web.  
  2. Atualize o navegador para mostrar que você está obtendo os dados por meio do Customer DB App.

OBSERVAÇÃO: se uma guia ainda não estiver aberta ou caso você tenha fechado a anterior.  Use o favorito "Customer DB-App Direct Connect" na barra de favoritos.

 

 

Reinicie a sessão do PuTTY para web-01a

 

  1. Clique no ícone Session no canto superior esquerdo
  2. Clique em Restart Session.

 

 

Teste de ping entre camadas

 

Experimente executar o ping entre as guest VMs do aplicativo de 3 camadas.

Observação: lembre-se de usar a opção SEND TEXT.

  1. Ping web-02a
ping -c 2 172.16.10.12
  1. Ping app-01a.
ping -c 2 172.16.20.11
  1. Ping db-01a.
ping -c 2 172.16.30.11

Os pings não são permitidos e falharão porque o ICMP não é permitido entre camadas ou entre os membros de uma mesma camada em suas regras. Sem permitir o ICMP entre as camadas, agora a regra padrão bloqueará todos os outros tráfegos.

Minimize a sessão do PuTTY para web-01a.

 

 

Topologia após a adição de regras do firewall distribuído para o aplicativo Customer DB de 3 camadas.

 

O diagrama mostra o ponto de controle e segurança referente ao firewall no nível das vNICs.  Embora o DFW seja um módulo carregável no kernel do Host ESXi do vSphere (Kernel Loadable Module - KLM), as regras são aplicadas na vNIC da guest VM.  Esta proteção acompanha a VM durante o vMotion para fornecer proteção completa e ininterrupta, não permitindo assim que haja uma "janela de oportunidade" durante a qual a VM fica suscetível a ataques.

 

Conclusão do Módulo 6


Neste módulo, usamos o recurso Firewall Distribuído (DFW) do NSX para fornecer políticas de segurança para um Aplicativo típico de 3 camadas. Este módulo ilustra como é possível fornecer um pequeno conjunto de regras que podem ser aplicadas à um grande número de VMs. Podemos usar a microssegmentação para proteger milhares de VMs em nossos ambientes com intervenção administrativa mínima.


 

Você terminou o Módulo 6

Parabéns por concluir o Módulo 6!

Se você estiver procurando informações adicionais sobre a implementação do NSX, acesse o centro de documentação do NSX 6.2 por meio do URL abaixo:

Continue em qualquer módulo abaixo que seja do seu interesse:

Lista de módulos de laboratório:

Chefes do laboratório:

 

 

Como encerrar o laboratório

 

Para encerrar o laboratório, clique no botão END.

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1703-SDC-1-PT

Version: 20161212-051220