NSX - Edge Service Gateway

O NSX Edge Gateway é configurado em uma Máquina Virtual que oferece múltiplas funções para múltiplos usos de virtualização para redes, podendo fornecer taxa de transferência perto de 10gbps, isso é quase o dobro do que outros devices virtuais permitem.

O Edge forma um dos pontos de terminação entre o mundo físico e o mundo virtual e pode fornecer serviços de Roteamento, serviços de VPN, Capacidade de firewall de perímetro, bridge Layer 2, Balanceamento de carga, NAT, DNS e DHCP.

Figura 1: Recursos do NSX Edge

O Edge pode ser instalado como um OVA através do NSX Manager, e para isso precisa obedecer alguns requisitos. Devido o Edge ser um dispositivo virtual, ao contrário do que são em contra partes do kernel, cada Edge requer vCPU, memória e recursos de armazenamento. Ele deve ser tratado como qualquer VM.

A implantação varia de acordo com seu uso e oferece opções específicas de implantação a serem usados, dependendo das funcionalidades que precisam ser ativadas:

Os requisitos são os seguintes:

•         Forma Compact - 1 vCPU, 512MB de memória RAM
•         Forma: Large - 2 vCPU, 1024MB de memória RAM
•         Forma: Quad-Large - 4 vCPU, 4096MB de memória RAM
•         Forma: Extra-Large - 6 vCPU, 8192MB de memória RAM

Figura 2: Formas recursos necessários para o NSX Edge

A forma Quad-Large é recomendada para um firewall de alto nível, enquanto o Extra-Large é adequado para o Load Balancing e o SSL offload. Isso pode ser para vários pools ou para apenas um único pool de aplicativos. É uma interação simples que permite o redimensionamento do gateway Edge. Isto segue em ambos os sentidos - de pequeno a grande e grande a pequeno e se adequá a ambientes onde o desempenho é planejado para crescer para um determinado evento ou período de tempo.

A forma do NSX Edge pode ser alterada a partir de suas implantações iniciais via UI ou API calls, embora isso irá causar uma pequena interrupção do serviço.

• Obs.: 
• 1 segundo é a frequência de Heartbeat entre as instancias de Edge configurados em HA.
• 15 segundos é o delay quando a instancia do Edge Ativa antes a instancia Standby assumir.
• É possível configurar 2 syslog servers no Edge.

Descrição das Funções do Edge Service Gateway:

ROUTING:

Uma das funções principais do NSX Edge são os gateways L3, que possuem a capacidade de fornecer uma interface de sub-rede ao anexar um segmento lógico, além de possibilitar a otimização do tráfego de rede. O NSX Edge fornece roteamento centralizado entre as redes lógicas implementadas no domínio NSX e os recursos físicos externos da infraestrutura de rede. O NSX Edge suporta vários protocolos de roteamento dinâmico, com OSPF, iBGP, eBGP, IS-IS e roteamento estático.

A redistribuição desempenha um papel crítico em uma rede escalável e dinâmica. É possível a redistribuição de um protocolo para outro. Filtragem de lista de prefixos também está disponível;

A configuração de roteamento suporta dois modelos, Active-Standby e ECMP.

O primeiro modelo é modo Active/Standby, no qual todos os serviços estão disponíveis.

O segundo modelo é o modo ECMP, que oferece largura de banda (até oito VM Edge que suportam até 80 GB de tráfego por DLR) e convergência mais rápida.

No modo ECMP, apenas o serviço de roteamento é acessível. Os serviços statefull não podem ser suportados devido ao encaminhamento assimétrico inerente ao encaminhamento baseado no ECMP.

ECMP( Equal Cost Multipathing):

Na versão 6.1 do NSX, o protocolo Equal Cost Multi Path (ECMP) foi introduzido. Cada dispositivo NSX Edge pode usar o ECMP possibilitando um trafego de 10Gbps por dispositivo. Podem existir aplicações que requerem mais largura de banda, assim o ECMP ajuda a resolver este problema. Ele também permite uma maior resiliência. Em vez de cenários Active/standby em que um link não é usado de forma alguma, o ECMP pode habilitar vários caminhos para um destino. O compartilhamento de carga também significa que quando a falha ocorre apenas um subconjunto de largura de banda é perdido e não todo o recurso.

O ECMP pode ser ativado tanto no roteador lógico distribuído como no NSX Edge, contanto que o caminho possua custo igual. Dessa forma haverá várias rotas utilizáveis para o tráfego.

Figura 3: ECMP

É importante lembrar que no modo Active/Active o ECMP não oferece suporte para FW, Balanceamento de carga ou NAT. Isto é devido o Edge não compartilhar o estado deas conexão entre si.

O ECMP do NSX utiliza um dos dois algoritmos de hash. No Edge, o balanceamento de carga é baseado no kernel do linux. Trata-se de um fluxo randômico baseado em Round Robin. Um fluxo é determinado por um par de IPs de origem e de destino. No roteador lógico distribuído o hash é feito simplesmente pelo IP de origem e de destino.

Quando uma Edge falha os fluxos correspondentes são re-hashed. Re-hashed é realizado através dos Edges ativos restantes. Uma vez que o tempo limite de adjacências e as entradas da tabela de roteamento são removidos um re-hash é disparado.

NAT (NETWORK TRANSLATION):

A conversão de endereços de rede permite a topologia de dev-ops que pode ser ativada sob demanda. O NAT é parte integrante da funcionalidade do balanceador de carga. O NAT pode ser executado para tráfego que flui através do Edge. Ambos os NAT de origem e de destino são suportados.

Com NAT o NSX edge pode mudar o endereço ip de origem ou destino e os números das portas TCP/UDP encontrados no cabeçalho do pacote IP.

O NSX suporta dois tipos de NAT:

Source NAT:

Source NAT traduz o ip de origem do pacote IP.

Usando Source NAT o NSX edge traduz o ip "interno' para um IP público para alcançar a internet por exemplo.

Destination NAT:

Destination NAT traduz o endereço IP de destino do pacote IP.

NSX Edge executa um NAT de destino para traduzir o destino de um IP público para o um endereço IP interno.

FIREWALL:

O NSX Edge suporta recurso de firewall stateful, complementando o Distributed Firewall (DFW) habilitado no kernel dos hosts ESXi. Embora o DFW seja utilizado principalmente para impor políticas de segurança para comunicação entre cargas de trabalho conectadas a redes lógicas (ou seja, tráfego leste-oeste), o firewall do NSX Edge filtra principalmente as comunicações entre o espaço lógico e a rede física externa (ou seja, o tráfego norte-sul).

LOAD BALANCING:

O NSX Edge pode executar serviços de balanceamento de carga para farms de servidores de cargas de trabalho implantadas no espaço lógico. As funcionalidades de balanceamento de carga suportadas nativamente no Edge cobrem a maioria dos requisitos típicos encontrados nas implementações da vida real.

DICA: Se o balanceador de carga é configurado modo de alta disponibilidade (HA) e se o Load Balancer principal tiver uma falha, o Load Balancer secundário NSX assume a função de primário. Os fluxos existentes precisarão ter suas conexões restabelecidas;

O NSX Edge Logical Load Balancer suporta dois modos de load balancing:

One-Arm mode, também conhecido como Proxy mode:

Esta implementação consiste de um NSX Edge router conectado diretamente na rede lógica onde o load-balancing services são requiridos.

A vantagem desse modelo pe que é mais simples e flexível.

Contudo esse modelo requer o provisionamento de mais instancias do Edge;

One-Arm precisa da configuração de source NAT;

Obs: Source NAT não permite os servidores do DC ver o endereço IP original dos clientes.

Figura 4: Source NAT

In-Line mode, também conhecido como Transparent mode:

Esta implementação é simples para implementar

In -line mode permite os servidores ver o endereço IP original do cliente

Somente roteamento em modo centralizado deve ser adotado para os segmentos em vez de roteamento em modo distribuído.

Importante lembrar que nesse modo o Load Balance é outro serviço adicionado no NSX edge o qual já prove o roteamento entre a rede lógica e física, sendo assim recomendado configurar o Edge como X-LARGE antes de habilitar os serviços de load-balancing;

Figura 4: Destination NAT

VPN (VIRTUAL PRIVATE NETWORKS):

O NSX Edge fornece serviços de VPNs como:  Remote-Access, Site-to-Site, VPN Layer 2 e VPN Layer 3.

VPN Layer 2:

Representa uma arquitetura de client server; (configura-se um lado como VPN client e outro lado como VPN server);

A conexão da VPN Layer 2 é um tunel SSL conectando redes separadas em cada localização.

Um único server de VPN Layer 2 pode suportar múltiplos clientes VPN remotos;

Figura 5: VPN Layer 2

O client de VPN faz uma requisição de conexão via a porta TCP default - 443;

São geralmente posicionadas para estender domínios L2 entre datacenters geograficamente separados em apoio de casos de uso, incluindo recursos de computação e implantações de nuvem híbrida;

Figura 6: VPN SSL

As VPN de Camada 2 são usadas para estender com segurança os segmentos Ethernet em um meio não confiável.

O NSX Edge Service Gateway pode formar uma VPN de Camada 2 com um dispositivo físico compatível com padrões.

VPN Layer 3:

Serviços de VPN layer 3 são usados para prover conectividade layer 3 de forma segura de locais remotos para o data center.

Os casos de uso mais comuns para VPNs Layer 3 incluem conectividade site-a-site através de IPSEC e conectividade VPN SSL para acesso a redes privadas atrávés do NSX Edge.

Serviços de VPN podem ser usados pelos clientes remotos alavancando túneis SSL para conexão segura entre o NSX Edge gateway, o qual atua como um Layer 3 VPN server no data center. Esse metódo as vezes é chamado de SSL VPN plus;

O NSX Edge pode estabelecer conexões site-to-site, através do protocolo padrão IPSEC, e pode interoperar com todos os vendors de soluções de VPN;

Figura 7: VPN Layer 7

Métodos de autenticação VPN:

·         RSA Secure ID

·         Active Directory

DHCP, DNS e IP (DDI):

O NSX Edge suporta funcionalidades de retransmissão de DNS e atua como servidor DHCP, fornecendo endereços IP, gateway padrão, servidores DNS e parâmetros de busca para cargas de trabalho conectadas às redes lógicas. NSX versão 6.1 apresenta suporte para DHCP Relay no NSX Edge, permitindo que um servidor DHCP centralizado e localizado remotamente forneça endereços IP para as cargas de trabalho através das redes lógicas.

DHCP:

DHCP Server:

O NSX Edge pode ser configurado como um servidor DHCP. Isso permite o gerenciamento e a simplificação e automação do endereço IP. Os clientes que utilizam uma plataforma hospedada não precisam configurar em uma solução de gerenciamento de infra-estrutura e podem usar o DHCP a partir do Edge. Útil para ambientes que exigem endereçamento dinâmico, mas são voláteis por natureza.

DHCP Relay:

A partir da versão 6.1 o NSX adicionou suporte a DHCP Relay. Isso nem sempre foi adequado para clientes ou topologias de aplicativos. O suporte do DHCP Relay pelo NSX e DLR permite a retransmissão de mensagens Discover, Offer, Request e Accept que compõem o DHCP.

O NSX Edge encaminha todas as solicitações DNS de máquinas virtuais enviadas para ele para o servidor DNS.

• Obs.: NSX Edge suporta 20.000 DHCP Pools.

L2 Bridging

NSX Edge suporta a capacidade de bridge"ponte" de uma VLAN L2 para VXLAN. Isso é, permite a conectividade de uma VLAN física ou um grupo de portas de back-up de VLAN. Conexão com cargas físicas ainda são uma realidade neste dia uma idade. A capacidade de fazer bridge permite a migração P-to-V, conexão com sistemas legados e uma série de outros casos de uso.

• L2 Bridge entre o switch lógico e uma VLAN, habilita migrar a carga de trabalho virtual para o dispositivo fisico;
• VXLAN para VLAN Bridge habilita a conectividade entre as VMs em um distributed port group, essa conectividade é chamada de layer 2 bridging.
• A conectividade ethernet pode ser extendida para dispositivos físicos assinando um uplink para o distributed port group;
• L2 bridging habilita a VM em switch lógico para acessar a rede física;

• L2 bridging é usado para:

• Efetuar a migração física para virtual (P2V) sem mudar o IP;
• Extende o serviço virtual em um switch lógico para devices externos;
• Extende os serviços de rede física para VMs em switches lógicos
• Acessa a rede física existente em switches lógicos;

• L2 Bridge não deve ser usado para:

• Conectividade  entre VXLAN para VXLAN;
• Data center interconnect;

NSX - Distributed Logical Router

A Evolução no Roteamento nos Datacenters:

Os padrões de design e as topologias de roteamento nos Datacenters estão constantemente se adaptando as novas tendencias de tecnologias, tendo como modelo as conexões e a dependência através do modelo de infraestrutura tradicional de roteamento com roteadores físicos, passando para o modelo de NFV, através de roteadores virtuais e atualmente a utilização do conceito de roteamento direto no Hypervisor dos hosts.

Observação: Nenhum dos modelos deixaram de existir e é importante lembrar que os 3 modelos citados podem coexistir de forma simultânea e interconectados, pois ambos usam os mesmos conceitos de roteamento com relação aos padrões e protocolos utilizados.

Figura 1: Evolução do Roteamento

O padrão atual do tráfego entre os servidores é considerado Leste-Oeste, contudo o legado dos datacenters tem o design o padrão de tráfego Norte-Sul.

Figura 2: Roteamento Norte-sul

Exitem um problema de roteamento muito comum dentro nos Datacenters, conhecido como Hairpinning, que basicamente retorna uma mensagem de um endpoint de uma origem de volta na mesma direção em que veio, com uma forma de alcançar o seu ponto final de destino.

Figura 3: Hairpinning

Hairpinning:

Quando uma VM precisa se comunicar com outra VM que encontra-seno mesmo host estando em subnets diferentes, a solicitação é enviada ao default gateway que esta em outro host, sendo assim necessário que o pacote saia de um host para ter a definição de roteamento que esta em outro host epara ser reencaminhada a VM do host de origem.

Caminhos de roteamento Norte-Sul podem criar gargalos de roteamento na rede e não são adequados para a rede dos data centers de hoje, que considera a abordagem mais eficiente através do conceito de roteamento Leste-Oeste;

Roteamento no NSX: Pré-requisitos e considerações:

O DLR e o ESG contam com o DVS para fornecer serviços de encaminhamento L2 para dvPortgroups (ambos baseados em VXLAN e VLAN) para que a conectividade de ponta a ponta funcione. Isso significa L2 que os serviços de encaminhamento que estão conectados ao DLR ou ESG devem ser configurados e estarem operacionais.

Durante o processo de instalação do NSX, esses serviços são fornecidos por "Preparação do host" e "Preparação da rede lógica".

Ao criar zonas de transporte em configurações DVS de vários grupos, certifique-se de que todos os clusters no DVS selecionado estão incluídos na zona de transporte. Isso garante que o DLR está disponível em todos os clusters onde DVS dvPortgroups estão disponíveis. Quando uma zona de transporte está alinhada com o limite DVS, a instância DLR é criada corretamente.

Certifique-se de que o Controlador de Cluster está disponível antes de criar ou alterar uma configuração de DLR.

O DLR deve ser conectado a VLAN dvPortgroups, assegure-se de que os hosts ESXi com o DLR configurado possam comunicar através da porta UDP 6999 para que o proxy ARP baseado no DLR funcione corretamente.

Considerações:

• O DLR depende do Cluster Controller para funcionar, enquanto o ESG não.

• Uma determinada instância DLR não pode ser conectada a switches lógicos que existem em diferentes zonas de transporte. Isso é para garantir que todos os switches lógicos e DLR instâncias estão alinhadas.

• O DLR não pode ser conectado a grupos de portas com suporte a VLAN, se esse DLR estiver conectado a switches lógicos que abrangem mais de um DVS. Como acima, isso é para garantir o alinhamento correto de instâncias DLR com opções lógicas e dvPortgroups entre hosts.

• Ao selecionar o posicionamento do DLR Control VM, evite colocá-lo no mesmo host como um ou mais de seus ESGs upstream usando regras anti-affinity DRS se eles estiverem no mesmo cluster. Isso é para reduzir o impacto da falha de host no encaminhamento DLR.

• OSPF pode ser habilitado somente em um único Uplink (mas suporta múltiplas adjacencias). BGP, por outro lado, pode ser habilitado em várias interfaces Uplink, onde é necessário.

Tipos de Roteamento do NSX:

O NSX possui dois tipos de roteamento, otimizados para duas necessidades especificas:

Roteamento dentro do ambiente lógico, também conhecido como roteamento "Leste-Oeste", fornecido pelo Roteador Lógico Distribuído (DLR);

Roteamento entre o ambiente físico e o ambiente lógico, também conhecido como roteamento "Norte-Sul", fornecido pelos Gateways de Serviços de Borda (ESG).

O DLR suporta a execução de um único protocolo de roteamento dinâmico de cada vez (OSPF ou BGP), enquanto o ESG suporta a execução de ambos os protocolos de roteamento ao mesmo tempo. A razão para isso é que o DLR foi projetado para ser um roteador "stub", com um único caminho, o que significa que configurações de roteamento mais avançadas normalmente não são necessárias.

• Ambos fornecem opções para escalonamento horizontal.
• Tanto o DLR como o ESG suportam uma combinação de rotas estáticas e dinâmicas.
• Tanto o DLR como o ESG suportam as rotas ECMP.

Ambos fornecem separação de domínio L3, o que significa que cada instância de um Roteador Lógico Distribuído ou um ESG tem sua própria configuração L3, semelhante a um VRF L3VPN.

Roteamento Classful e Classless

O conceito e utilização do termo "class' faz referência às classes de endereçamento de redes A, B e C. Alguns protocolos de roteamento levam em consideração a classe da sub-rede para poder realizar seu serviço, outros simplesmente a ignoram.

Os protocolos de roteamento que respeitam as regras de classes são chamados de classful e os protocolos que não respeitam essa regra são chamados de protocolos de roteamento classless.

Os protocolos de roteamento classful fazem anúncio de rotas em classe full ou seja anunciam apenas uma rota para todas as suas interfaces pertencentes a uma mesma rede dentro das classes A, B ou C. Essa funcionalidade é chamada de auto-resumo, uma característica dos protocolos classful.

Os protocolos de roteamento classless, diferentemente dos protocolos classful, enviam informações da máscara de sub-rede junto às atualizações de roteamento. Esses protocolos possuem suporte a VLSM (Variable Length Subnet Masks) e ao resumo de rotas.

Figura 4: Roteamento Classless

Na figura 4 acima, foi configurado duas subredes com segmentos e endereçamentos distintos considerando o endereçamento da  subnet segmentada em uma netmask /25, ambas sendo configuradas com um endereço de classe B e com alteração apenas no último octeto da rede

O DLR e o ESG reconhecem as redes de forma separadas e as tratam com segmentos distintos, diferentemente de uma rede calssfull o qual teria duplicidade na rede por estarem na mesma classe de rede e com os 3 octetos inciais idênticos.

DLR - Logical Distributed Routing

O NSX fornece para o vSphere o roteamento L3 dentro do hypervisor. Conhecido como Roteador Lógico Distribuído que fornece o roteamento dentro do kernel de cada host, permitindo que o plano de dados de roteamento distribuído em todo o domínio habilitado para NSX. Não é possível otimizar os fluxos de tráfego entre os níveis de rede.

O roteamento lógico fornece o roteamento escalável. Ele pode suportar um grande número de LIFs até 1000 por Logical Distributed Router com suporte aos protocolos de roteamento dinâmico, como BGP e OSPF permite que as topologias de roteamento sejam escalonáveis. Um benefício adicional é que não há mais hair-pinning de tráfego como o que é encontrado em aplicações tradicionais e arquiteturas de rede. O DLR permite a otimização pesada dos fluxos de tráfego leste-oeste e melhora as arquiteturas de aplicativos e de rede.

O DLR é otimizado para encaminhamento no espaço lógico entre VMs, no VXLAN-backed ou VLAN backed grupos de porta.

O DLR tem as seguintes propriedades:

• Alto desempenho, baixo overhead primeiro-hop roteamento
• Escala linearmente com o número de hosts
• Suporta ECMP de 8 vias em uplink
• Até 1.000 instâncias DLR por host
• Até 999 interfaces lógicas (LIFs) em cada DLR (8 x uplink + 991 interno) + 1 x gerenciamento
• Até 10.000 LIFs por host distribuídos em todas as instâncias do DLR (não implementadas pelo NSX Manager)

Considerações:

• Não é possível conectar mais de um DLR a qualquer VLAN ou VXLAN.
• Não é possível executar mais de um protocolo de roteamento em cada DLR.
• Se o OSPF é usado, não pode executá-lo em mais de um uplink DLR.
• Para encaminhar entre VXLAN e VLAN, a zona de transporte deve ter DVS único.

O projeto do DLR em um nível alto é análogo a um chassi de roteador modular, das seguintes maneiras:

• Os hosts ESXi são como line cards:

• Eles têm portas com estações terminais conectadas (VMs).
• Isto é onde as decisões de encaminhamento são feitas.

• O DLR Control VM é como um Route Processor Engine:

• Ele executa protocolos de roteamento dinâmico para trocar informações de roteamento com o resto da rede.
• Ele calcula as tabelas de encaminhamento para "cartões de linha" com base na configuração de interfaces, rotas estáticas e informações de roteamento dinâmico.
• Ele programa essas tabelas de encaminhamento para os "cartões de linha" (através do Cluster Controlador, para habilitar escala e resiliência).

• A rede física que conecta os hosts ESXi é como um backplane:

• Ele transporta dados encapsulados em VLAN ou VXLAN entre os "cartões de linha".

Observação: Somente uma interface  de DLR é permitido por Switch Lógica/VXLAN

O NSX Logical Routing permite a comunicação entre workloads virtuais pertencentes a redes IP distintas e separadas;

Figura 5: Roteamento direto no vmKernel

Porta do roteador lógico:

Independentemente da quantidade de instâncias de rota que estão dentro dos hosts ESXi, existe uma porta especial chamada "Porta de Roteamento Lógico" ou "Porta de vdr".

Esta porta funciona como um conceito de "route in stick". Isso significa que todo o tráfego roteado passará por esta porta. Podemos pensar em route-instance como vrf lite porque cada route-instance terá seus próprios LIFs e tabela de roteamento, mesmo o endereço IP de LIFs pode se sobrepor com outros.

Como o DLR otimiza o tráfego east-west:

• DLR conecta diretamente aos switches lógicos(layer 2 VXLAN networks).
• As VMs conectam diretamente aos switches lógicos.
• DLR prove uma interface layer 3 para cada rede VXLAN, servido como default gateway;
• O tráfego entre as diferentes VMs são roteadas pelo DLR local.
• DLR suporta rotas estáticas e protocolos de roteamento dinâmico;

Figura 6: Tráfego leste-oeste

Módulo do kernel e tabela ARP

O DLR não se comunica com o Controlador NSX para descobrir o endereço MAC das VMs. Em vez disso, envia uma solicitação ARP para todos os membros do VTEP do host ESXi nesse switch lógico. Os VTEPs que recebem essa solicitação ARP enviam-no para todas as VMs do switch lógico.

A instância DLR pode ter entradas ARP diferentes entre diferentes hosts ESXi. Cada módulo DLR Kernel mantém sua própria tabela ARP.

DLR Control Plane e Data Plane:

DLR control VM é o componente de Control Plane, que possui a função de estabelecer as sessões do protocolo de roteamento com outros roteadores. Os dados de roteamento atual é executado no Data Plane pelo módulo DLR Kernel.O DLR Control VM não influencia no caminho do dado.

DLR Control VM:

• DLR control VM é o componente do control plane;
• Estabelece as sessões do protocolo de roteamento;
• DLR control VM não é o caminho do dado;
• Comunica com NSX Manager e envia routing updates para o VMware NSX Controller cluster;
• Para evitar um único ponto de falha, deve-ser configurar o DLR control VM no modo Active/Standby;
• O módulo Kernel tem o RIB que é conhecido como routing table;
• O Data Plane atua como Route lookup ou ARP entry lookup são atribuídos pelo módulos do kernel;
• A camada de redes é responsável por routing, forwarding, controlling e sequencing dos pacotes;

DLR Control VM comunica com o NSX manager e envia as atualizações de roteamento para o Cluster NSX Controller.

Existe um firewall instalado no DLR Control VM, contudo esse firewall não filtra o trafego Leste-Oeste, ele é utilizado especificamente para proteção do DLR control VM.

Figura 7: DLR Control VM

No nível do Data plane existe um módulo DLR kernel(VIBs), que são instalados no host ESXi e são partes do domínio NSX.

• Os módulos Kernel são similares aos line cards em módulos de chassis suportando roteamento layer 3.
• Os módulos Kernel tem uma RIB - Routing information Base que é conhecida como tabela de roteamento, e é aplicada do cluster de controllers.
• Funções do Data Plane como lookup route ou ARP entry lookup são executadas pelos módulos de Kernel.

DLR Control VM comunications:

DLR Control VM é uma máquina virtual que normalmente é implementada no cluster de Gerência ou no  Edge. Quando o host ESXi é preparado pela plataforma NSX, uma dass VIBs cria o canal para o controle entre os hosts ESXi para os controladores NSX O serviço daemon dentro do host ESXi é o responsável por este canal, sendo chamado  de netcpad, referido como o User World Agent (UWA).

O netcpad é responsável pela comunicação entre o controlador NSX e o host ESXi, o qual aprende as informações de endereço MAC / IP / VTEP para comunicações entre as VXLAN. A comunicação é protegida e usa SSL para se comunicar com o controlador NSX no plano de controle. O UWA também pode se conectar a várias instâncias do controlador NSX.

Outro serviço daemon chamado vShield-Statefull-Firewall é responsável por interagir com a Manager. Este daemon de serviço recebe informações de configuração da Manager para criar (ou excluir) a DLR Control VM, criar (ou excluir) o ESG. Além disso, esse daemon também executa as tarefas de firewall NSX como:

• Recuperar as regras de diretiva DFW,
• Reunir as informações de estatísticas DFW e enviá-las para a manager
• Enviar logs de auditoria e informações para a Manager 

DLR Control VM Firewall

O DLR Control VM pode proteger suas interfaces de gerenciamento ou Uplink com o firewall embutido. Para qualquer dispositivo que precise se comunicar com a própria DLR Control VM, precisamos de uma regra de firewall para aprová-la.

Por exemplo SSH para o controle DLR VM ou mesmo adjacências OSPF com o roteador superior precisará ter uma regra de firewall. Podemos desativar / ativar o firewall de VM de controle DLR globalmente.

Observação: A regra de firewall da DLR Control VM é independente da regra de firewall distribuído

Alta Disponibilidade do DLR - HA

A DLR Control VM de Alta Disponibilidade (HA) permite a redundância no nível DA VM. O modo HA é ativo / passivo onde a VM de Controle DLR ativa possui o endereço IP e se a VM de Controle DLR ativa falhar, a VM de Controle DLR passiva assumirá a propriedade do endereço IP (evento flip). A instância de rota DLR e a interface dos LIFs e do endereço IP existem no host ESXi como um módulo de kernel e não fazem parte deste evento de ativação de modo Ativo / Passivo.

Figura 8:  Redundância da VM de Controle DLR com Heartbeat sobre VXLAN

A tabela de encaminhamento de sincronização do Active DLR Control VM para a DLR Control VM secundária, se a ativa falhar, a tabela de encaminhamento continuará a ser executada na unidade secundária até que o DLR secundário renove a adjacência com o roteador superior.

A mensagem de heartbeat de HA é enviada através da interface de gerenciamento DLR. É preciso haever conectividade L2 entre o Active DLR Control VM e o Secondary DLR Control VM. O mecanismo de detecção de falha padrão é de 15 segundos, mas pode ser alterado para até 6 segundos. O heartbeat usa a porta UDP 694 para sua comunicação.

Pode-se verificar o status de HA executando o seguinte comando:

• show service highavailability (Mostra a disponibilidade do serviço)

• show service highavailability connection-sync (Mostra a disponibilidade das conexões)

• show service highavailability link (Mostra a disponibilidade dos links)

Tipos de interface do DLR:

Interface Uplink: 

É usado pela DLR para conectar o roteador de borda "trânsito", sendo a interface de trânsito entre o router lógico com o router físico. O DLR suporta OSPF e BGP em sua interface Uplink, contudo podem ser executados ao mesmo tempo. O OSPF pode ser ativado somente em uma única interface Uplink.

Interface Gerenciamento:

A interface de gerenciamento do DLR pode ser usada para diferentes propósitos. O primeiro é gerenciar o controle remoto DLR com o acesso remoto como SSH. Outro utilização é a Alta Disponibilidade. O último é enviar informações de syslog para um servidor syslog. A interface de gerenciamento faz parte da tabela de roteamento do controle VM; Não há nenhuma tabela de roteamento separada. Quando configuramos um endereço IP para a interface de gerenciamento, somente os dispositivos na mesma sub-rede que a sub-rede de gerenciamento poderão alcançar o IP de gerenciamento da DLR Control VM .

Figura 9: Tipos de interface do DLR

Interface LIFs:

Existem LIFs no host ESXi no nível do kernel; LIFs são as interfaces Layer 3 que atuam como o gateway padrão para todas as VMs conectadas a switches lógicos.

LIFs são as conexões virtuais feitas do DLR para os switches lógicos.

As interfaces lógicas, conhecidas como LIFs, são configuradas em roteadores lógicos. Eles são análogos às interfaces virtuais comutadas ou interfaces fisicas  na infra-estrutura de rede tradicional. Os endereços IP são atribuídos a LIFs e pode haver vários LIFs por DLR. Quando um LIF é configurado, ele é distribuído para todos os outros hosts. Uma tabela ARP também é criada e mantida para cada LIF

O conceito de LIF é similar as interfaces em um router físico, ou seja LIF é o default gateway do segmento de rede o qual esta conectado.

• Os módulos kernel são equipados com logical interfaces (LIFs). 
• Uma LIF conecta a um switch lógico e tem um único IP;
• DLR mantem um table a ARP para cada LIF.
• DLR inclui a LIF o qual conecta aos switches lógicos ou port groups;
• Máximo de 1000 LIFs podem ser configurados;
• Possui uma tabela ARP e os IPs são  assinados para as LIFs de cada segmento

Figura 10: LIF

MAC Virtual  e  MAC Físico:

Virtual Media Access Control (vMAC)

• vMAC é o MAC address da LIF;
• VMs usam o MAC associado com a LIF para acessar o default gateway;
• Quando uma VM envia um ARP request, o vMAC é usado;
• Porque o vMAC das VMs não é armazenado na tabela MAC do switch físico, os hosts rodando na instancia DLR envia o vMAC de cada LIF para as VMs em um switch lógico;

Physical MAC (pMAC)

• pMAC é o MAC do uplink o qual o tráfego do switch segue para a interface física;
• Na interface do DLR para um Distributed port Group, o router pode comunicar com a entidade física, usando o MAC address de origem, isso permite o switch físico ver o pMAC e ter o pMAC na tabela MAC;

Routing Component Interactions:

• O DLR é implementado através do NSX manager. Um protocolo de roteamento dinâmico pode ser configurado na instância do DLR.
• O Controller NSX envia a configuração para os hosts ESXi. 
• Os peerinf OSPF e BGP são estabelecidos entre o ESG e o DLR control VM usando o protocolo Controller VM.
• As rotas aprendidas pelo DLR control VM  são enviadas para o cluster de distribuição
• O Cluster de Controller NSX envia as atualizações para todos os hosts ESXi.
• O caminho dos dados entre o DLR kernel modules nos hosts e a troca de dados do ESG é realizada através das interfaces lógicas.
• ESG trunk interface é usado para agregar conexões para múltiplas instancias de DLR de múltiplos tenants.
• O conceito de Sub-Interface é similar ao disponível aos roteadores físicos. Peer de roteamento estabelecido em cada trunk sub-interface permite diferentes DLC control VM instancies peer com uma única ESG vNIC;

DICA: Todos os pacotes são processados pelo roteador distribuído. Nenhum pacote é processado pelo Router Lógico Control VM no processamento de pacotes do tráfego da camada 3 em uma topologia NSX para vSphere;



Roteamento DLR com ESG  ou roteador físico

DLR suporta roteamento estático e dinâmico.

Roteamento Estático:

Com o roteamento estático, podemos fazer roteamento com vários ESGs ou roteadores físicos sobre o mesmo ou diferente Uplink LI,

Figura 11: Roteamento Estático DLR com LIDs de um unico uplink

Figura 12: Roteamento Estático DLR com LIDs com múltiplos uplinks

Roteamento Dinâmico:

Para o roteamento dinâmico, o DLR Control VM precisa ser implantado como o componente de plano de controle.


Ao contrário do roteamento estático, não podemos estabelecer o roteamento dinâmico em vários LIFs de Uplink. Para estabelecer roteamento dinâmico com vários pares, o peering terá de ser estabelecido sobre o mesmo Uplink LIF.

Figura 13: Topologia DLR com roteamento dinâmico com múltiplo Peering

ESG - Edge Service Gateway

O ESG é um appliance virtual com controle e plano de dados que pode fornecer muitos serviços de rede e segurança, como roteamento, firewall, balanceador de carga:

É possível Implantar o ESG através de uma topologia Inline ou One-Arm:

ESG Trunk Interface

O suporte dessa função esta desde a versão de software 6.1. A interface de trunk do NSX ESG, pode ser usado para aumentar a escalabilidade do projeto de rede virtual com o NSX.

Como o  ESG é um appliance virtual, ele suporta um máximo de 10 vNICs. Isso significa que só podemos conectar até 10 segmentos (VXLAN ou VLAN). Para dimensionar o número de segmentos que um ESG pode conectar, o NSX versão 6.1 apresenta a Interface de Trunk do ESG.

Um ESG suporta até 200 sub-interfaces (em todos os vNIC).

Cada sub-interface representa uma VLAN e a interface lógica L3 da VLAN. No NSX, a interface de trunk é um vNIC e a sub-interface é a interface lógica de camada 3 que se conecta a um segmento VLAN ou VXLAN.

Figura 14: ESG Trunk Interface

Um dos casos de uso do suporte de interface trunk é estender  múltiplos segmentos de rede lógicos (VLAN ou VXLAN) com a VPN L2 do ESG. Anteriormente apenas um VXLAN pode ser estendida com um ESG.

A interface ESG Trunk também pode ser usada para conectar o NSX ESG ao Roteador Lógico Distribuído (DLR).

ESG Redundância (HA)

Como o DLR Control VM, o ESG também suporta Redundância Ativa / standby.

Figura 15: ESG Redundancy (HA)

ECMP

Tanto o DLR como o ESG suportam o roteamento ECMP (Equal Cost Multi-Path) com até 8 caminhos.

Com ECMP o fluxo de tráfego é assimétrico (tráfego de entrada e saída não estão atravessando o mesmo caminho / dispositivos). Dessa forma, não devemos habilitar nenhum serviço stateful
como o Firewall nos ESGs.

Os ESGs podem fazer o roteamento ECMP em direção à rede física, assumindo que vários roteadores físicos estão presentes.

Não é necessário que o ECMP seja configurado em ESGs para o DLR, porque todos os LIFs DLR são "locais" no mesmo host onde o ESG reside. Não haveria nenhum benefício adicional fornecido configurando múltiplas interfaces de uplink em um DLR.

Em situações em que é necessária mais largura de banda Norte-Sul, vários ESGs podem ser colocados em diferentes hosts ESXi para escalar até 80Gbps com 8 ESGs.


Protocolos de Roteamento suportado nos roteadores Lógicos:

Protocolo OSPF:

• Version 2;
• Backbone Area e NSSA support;
• Clear Text e MD5 peer authentication;
• DR e BRD interface support;
• Hello interval e dead interval configuration;
• Priority for DR e BDR election;
• Interface  cost configuration;

• Area Border Router - ABR:

• Conecta um ou mais OSPF areas com a backbone network;
• Mantém uma copia individual do link-state database na memoria para cara área conectada;

• Autonomous System Boundary Router - ASBR

• Conecta roteadores que pertencem a outras áreas usando static routing ou outros protocolos de roteamento como IS-IS em adição ao OSPF;
• Distribui rotas descobertas de um sistema externo para outro OSPF enabled Router;

• Internal Router:

• É um OSPF-enable router que pertence somente a uma área e tem vizinho somente dentro da área;

• Ares do OSPF:

• É uma coleção de roteadores, links e redes que tem a mesma identificação de área;
• Cada router OSPF combina com outras áreas e forma um backbone área;
• Backbone área combina múltiplas e independentes áreas dentro de um domínio logico e tem o ID como (0);
• Principal responsabilidade é distribuir routing information entre non-backbone áreas;
• Quando é habilitado o OSPF a área 0 e 51  são criadas por default;
• Default área do NSX é a área 51 o qual pode ser deletada e reconfigurada com a área desejada;
• Cada área mantem uma database separada;
• Stub áreas são áreas que não recebem  route advertismentes external para o AS;
• NSA são áreas stub que podem importar AS external routes e envia-las para outras areas;

• Tipos de Area do OSPF:

• Normal
• Stub
• Not-so-Stub area (NSSA)

• OSFP AS (Autonomous System)

• Conhecido como dominio de roteamento;
• Inclui todos os roteadores que rodam OSPF e trocam link-state information com cada router;
• Cada router interface que esta participando do processo OSPF é colocado na area;

Protocolo IS-IS:

• Inter-domain Routing Protocol;
• Tem o design similar ao OSPF;
• Roda sobre camada 2 e suporta múltiplos routed protocols;
• Suporta um grande dominios de roteamento e oferece router área e interface level support;

• Router level support:

• Envolve a configuração de Área ID
• System ID
• IS Type - Level 1-2, 
• Dominios passwords
• Área password

• Area-Level Support:

• Até 3 IP address por area
• Amplo range de niveis de interface

• Interface-Level Support:

• vNIC Name
• Hello timer
• Hello Multiplier
• Metric
• Priority
• Circuit Type
• LSP Level
• Mesh Group
• Password

• IS-IS AREAS:

• Usa 2 niveis de hierarquia oara gerenciar, escalar grandes redes
• Um dominio é e particionado em 2 areas - Level 1 e Level 2
• Similar a OSPF, associa routers para areas e identifica as areas usando numeros
• Level 1 Areas são equivalentes a area normal no OSPF, non-backbone ares
• Level 2 Areas são similares a Backbone ares do OSPF

Protocolo BGP:

• RFC 4271;
• Recursos:
• iBGP e eBGP support;
• Router-level Configuration;
• Local AS to route packets to other AS;
• Neighbor-Level configuration;

Checking Logical Routing - Comandos do NSX Manager:

• show edge (Os comandos da CLI para o Edge ServicesGateway (ESG) começam com 'show edge)
• show edge all (Lista todos os Edges)
• show edge EDGE-ID (Lista todos os serviços e detalhes de implementação de um Edge) 
• show logical-router (Comandos de CLI para o Roteador Lógico Distribuído (DLR) começam com show lógical-router)
• show edge EDGE-ID ip route (Exibir a tabela de roteamento no Edge)
• show edge EDGE-ID ip ospf neighbor (Exibir roteamento do edge vizinho)
• show logical-router host hostID connection (Exibir informações de conexão de roteadores lógicos)

Checking Logical Routing—Commands Run from NSX Controller

• show control-cluster logical-routers instance all (Localizar todas as instâncias do roteador lógico)
• show control-cluster logical-routers instance (Exibir detalhes de cada roteador lógico)
• show network connections of-type tcp (Mostra todas as conexões de rede estabelecidas, como uma saída de estatísticas de rede)

Checking Logical Routing—Commands Run from Edge 

• show configuration (Verificar a configuração global)
• show ip route (Verificar as rotas aprendidas)
• show ip forwarding (Verificar a tabela de encaminhamento)
• show interface (Verificar as interfaces vDR)
• debug ip ospf|bgp (debug o protocolo de roteamento)

• OSPF commands:

• show configuration ospf
• show ip ospf interface
• show ip ospf neighbor
• show ip route ospf
• show ip ospf database
• show tech-support (and look for strings “EXCEPTION” and “PROBLEM”)

• BGP commands

• show configuration bgp
• show ip bgp neighbor
• show ip bgp
• show ip route bgp
• show ip forwarding
• show tech-support (look for strings “EXCEPTION” and “PROBLEM”)

NSX - Service Composer

Nos Data Centers os workloads de aplicações são constantemente provisionadas, movidas, alteradas e desativadas por demanda.

O provisionamento de serviços de segurança usando o Service Composer é uma dos maiores recursos do NSX distributed Firewall.

Service Composer é a ferramenta que define um novo modelo de configuração de serviços de segurança e redes. Ele permite aprovisionar e assinar as regras e politicas de firewall e serviços de segurança para as aplicações em tempo real.

Service Composer é um interface de configuração que da ao administrador um concistente e centralizada forma para aprovisionar, aplicar e automatizar serviços de segurança de rede como:

Esses serviços são nativos do NSX ou podem ser de parceiros, 3° party solutions

O Service Composer oferece uma forma de automatizar os serviços de segurança através de grupos, aplicando as policitas em grupos de segurança e definindo as VMs nesses grupos, assim quando mais VMs forem adicionadas no grupo as politicas são aplicadas automaticamente nas VMS.

Então sempre que um maquina virtual é movida, as politicas de segurança e redes é movida junto com a VM sem intervenção humana.

Security Group:

O Grupo de segurança o que o adminsitrador quer proteger:

DICA:

Se um grupo de segurança for a origem para uma regra de firewall lógico geral, cada Máquina Virtual identificada no campo Aplicado a da Regra de Firewall Lógico  será afetada pela regra.


Permite estaticamente ou dinamicamente agrupar itens baseado na inclusão e exclusão de objetos:

    

Security Policy:

Políticas de segurança especificam como quer que a proteção seja executada, através de software de antívirus, firewall, intrusion protection, ou perfil de segurança com regras especificas.

Security policies podem ser aplicadas em um ou mais grupos de segurança onde os worloads são membros.

Security policies é uma coleção de serviços de segurança ou  regras de firewall e pode conter:

Guest introspection services:

• São dados de segurança ou soluções de terceiros como antivirus ou serviços de gerenciamento de vulnerabilidades.

Distributed firewall rules:

• São regras aplicadas nas vNICs, são regras que definem o tráfego que será permitido para ou de um grupo de segurança.

Network introspection services

• São serviços que monitoram a rede.

Security services:

• Serviços de gerenciamento de vulnerabilidades como IPS, IDS ou firewall Next Generation podem ser inseridos no fluxo de tráfego.

O mapeamento entre Security Groups e Security Policies, resultam em uma configuração que é imediatamente aplicada.

O Service Composer oferece a Canvas View que mostra todos os Security Groups. Esta visualização reduz a complexidade de gerenciamento dos serviços de segurança e melhora a visibilidade dos workloads.

Security Tag/Etiquetas de segurança:

Security Tag é um mecanismo de rotulagem que pode ser usado como uma abstração para descrever um estado. Isso pode ser impresso em uma carga de trabalho ou ser o critério de correspondência para um grupo de segurança.
Pode-se criar vários rótulos de acordo com a forma como eles querem identificar uma carga de trabalho específica. Uma vez que os critérios de correspondência de um grupo de segurança podsam ser uma tag de segurança, uma carga de trabalho, pode ser automaticamente colocada em um grupo de segurança. Enquanto um administrador pode expressar uma tag de segurança para uma carga de trabalho via Web Client, a API ou a integração com terceiros podem ser usadas para marcar uma carga de trabalho.

Algo que usa a API diretamente seria uma plataforma de gerenciamento de nuvem, como vRealize Automation. Quando um plano é selecionado por um usuário ou administrador, ele pode ser configurado ou definido para rotular uma ou mais etiquetas de segurança. Como resultado, as cargas de trabalho herdarão a pertença do grupo relevante.