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.

SDDC

SDDC - Software Defined Data Center

SDDC habilita automação completa com zero-downtime para qualquer aplicação e hardware

SDDC extende o conceito de virtualização como:  pooling, automação para todo o datacenter e serviços.

Compute virtualization, Network Virtualization e Software Defined Storage oferecem pooling embarcado para automação de serviços de compute, network e storages;

Antes do SDDC:

• Inteligencia no hardware
• Vendedores specificos e dedicados de infraestrutura
• Configuração e gerenciamento manual

Depois do SDDC:

• Capacidade de Compute, Network e Storage
• Vendas pelo melhor preço e performance
• Configuração e gerenciaemnto simplificado

SDDC embarca soluções de Compute, Storage, Networking, Infraestructure e Cloud Management:

Desafios devido a falta de virtualização na rede:

• Slow Provisioning
• Limited Mobility
• Complexity in Service Deployment
• Manual and Risk-prone Configuration
• Capital and Operational Costs
• Contranints on Cloud Resources
• Insuficient and weak Security

Network Virtualization como Core do SDDC:

VMware NSX como um solução verdadeira para Network Virtualization:

NSX reproduz um modelo inteiro de redes baseado em software, habilitando uma topologia de rede forma simples e conmplexa com redes em niveis de multi-tier, além de ofercer a capacidade de provisionamento em segundos:

NSX - Port Mirroring

Espelhamento de porta é um recurso tradicional disponível no switch físico para capturar o tráfego da porta e redirecionar para um destino remoto. 

Uma porta física localizada no mesmo switch físico (Switch port Analyzer ou SPAN port). O tráfego é simplesmente copiado para a porta de destino também.

Uma porta física localizada em um switch físico conectado L2 remoto (Remote SPAN ou RSPAN port). O tráfego para cada sessão RSPAN é transportado sobre uma VLAN RSPAN especificada pelo usuário que é dedicada para essa sessão RSPAN em todos os switches participantes.

Um host remoto (RSPAN encapsulado ou porta ERSPAN). ERSPAN adicionar um cabeçalho ERSPAN para os pacotes originais e encapsula-lo usando GRE.

Uma porta SPAN / RSPAN / ERSPAN é normalmente utilizada para fins de monitorização (depuração da rede, monitorização do desempenho da aplicação, prevenção de segurança ...). No mundo do vSphere, o mirror de portas é um recurso específico disponível em switches distribuídos. Uma solução alternativa está disponível se somente switches padrão estiverem disponíveis.

MONITORAMENTO DE PORTAS EM SWITCH VSS

Um vSwitch não tem recursos de espelhamento, mas uma solução simples pode ser usada para implementar uma porta como SPAN;

Usando switches padrão a única solução é:

• Criar outro grupo de portas equivalente ao anterior dentro do mesmo vSwitch;
• Substituir no grupo de portas a política de segurança "Modo promíscuo";
• Mover a VM e receptor vnic para o novo grupo de portas;
• Ambas as VMs devem ser executadas no mesmo host vSwitch / ESXi.

O "Modo promíscuo" configura o vSwitch como um hub: todas as VMs conectadas a este grupo de portas irão transmitir tráfego para todas as VMs conectadas.

Agora, um monitor de software (como tcpdump) em execução na VM do receptor pode analisar o tráfego da VM monitorada. VM conectada a outros grupos de portas ou vSwitches não receberão tráfego da VM monitorada

MONITORAMENTO DE PORTAS EM SWITCH VDS

Um switch distribuído oferece um recurso nativo para espelhar um vnic: dvMirror. Estão disponíveis cinco opções:

Configuração do Espelhamento:

vCenter Vsphere > Home > Networking > Seleciona a Switch > Manage > Port Mirroring

Distributed Port Mirroring (SPAN)

(Distributed Port Mirroring ou SPAN) permite replicar uma porta virtual dentro de um dvSwitch para outra porta dentro do mesmo dvSwitch; Ambas as VMs devem ser executadas no mesmo host. 

Remote Mirroring Source and Remote Mirroring Destination (RSPAN)

Uma sessão de espelhamento remoto é usada quando a origem e o destino estão sendo executados em diferentes hosts ESXi, dvSwitch ou switch físico (se a origem ou o destino forem físicos). Uma sessão RSPAN ainda é um protocolo L2, o que significa que ele não pode atravessar dispositivos L3

Encapsulated Remote Mirroring (L3) Source (ERSPAN)

Uma sessão encapsulada de espelhamento remoto é usada quando a origem eo destino estão sendo executados em diferentes redes L3. 

SPAN local:

Espelha o tráfego de uma ou mais interfaces no switch para uma ou mais interfaces no mesmo comutador.

Remote SPAN (RSPAN): 

Uma extensão do SPAN chamado SPAN remoto ou RSPAN. O RSPAN permite monitorar o tráfego de portas de origem distribuídas em vários switches, o que significa que você pode centralizar os dispositivos de captura de rede. RSPAN funciona espelhando o tráfego das portas de origem de uma sessão RSPAN para uma VLAN que é dedicada para a sessão RSPAN. Esta VLAN é então trunked para outros switches, permitindo que o tráfego de sessão RSPAN seja transportado através de vários switches. No switch que contém a porta de destino para a sessão, o tráfego da sessão RSPAN VLAN é simplesmente espelhado para fora a porta de destino.

SPAN remoto encapsulado (ERSPAN): 

Encapsulated Remote SPAN (ERSPAN), como o nome diz, traz encapsulamento de roteamento genérico (GRE) para todo o tráfego capturado e permite que ele seja estendido em domínios de Camada 3.

NSX - Controller

O controlador NSX é uma VM que é implantada pelo NSX Manager. É um dos componentes centrais do NSX. Ele fornece um plano de controle para distribuir informações de rede para hosts. Para alcançar um alto nível de resiliência, o controlador NSX é agrupado para escala e HA.

O controlador NSX contém três tabelas primárias. 

Tabela de endereço MAC, tabela ARP e uma tabela VTEP. Essas tabelas agrupam informações de VM e host em conjunto para cada três tabelas e replicam isso em todo o domínio NSX. O benefício de tal ação é habilitar multi-cast free VXLAN no underlay. As versões anteriores do vCNS e outras soluções habilitadas para VXLAN exigiam o VXLAN ativado na parte superior dos switches de rack ou em todo o tecido físico. Isso proporcionou uma sobrecarga administrativa significativa e remover isso alivia muito a complexidade.

Mantendo estas tabelas um benefício adicional é a supressão de ARP. A supressão de ARP permitirá a redução das solicitações ARP em todo o ambiente. Isto é importante quando os segmentos da camada dois se estendem através de vários domínios L3. Se um segmento solicitar o IP de um endereço MAC que não esteja em um segmento local, o host terá as informações replicadas em suas tabelas empurradas para ele pelo controlador.

O NSX Controller tem cinco funções:

• API Provider:  Mantém os  API de Web-service que são consumidos pelo NSX Manager;

• Persistence Server:  Garante a proteção e preservação dos dados entre os hosts;

• Logical Manager: Lida com a política e a topologia de rede.

• Switch Manager:  Gerencia os hypervisors e envia a configuração relevante para o host.

• Directory server: Se concentra na VXLAN e no diretório de informações de roteamento lógico distribuído;

Embora cada função precise de um "master" diferente, cada função pode ser eleita para se aplicar no mesmo ou em um host diferente. Se ocorrer uma falha de um host e não houver um master para uma função eleita, um novo host será promovido para master após o processo de eleição.

A maioria dos cenários de implementação vê três, cinco ou sete controladores implantados. Isto é devido ao controlador ser executado Zoo Keeper.
Um cluster Zoo Keeper, conhecido como um conjunto, requer uma maioria para funcionar e isso é melhor configurado através de um número ímpar de máquinas. Esse cenário de desempate é usado em muitos casos e condições de HA durante o NSX para operações vSphere.

Slicing/Fatiamento:

Em um ambiente dinâmico que pode ter várias mudanças por segundo, é necesário distribui r dinamicamente a carga de trabalho entre os clusters disponíveis, que  reorganiza as cargas de trabalho quando novos membros do cluster são adicionados e mantém sem impacto enquanto isso ocorre internaemente.

Uma role é feita para criar um número de fatias de si mesmo. Um aplicativo agrupa suas fatias e atribuirá o objeto a uma fatia. Isso garante que nenhum nó individual possa causar uma falha da função do NSX Controller;

Quando uma falha de um host do NSX controller ocorre as fatias que o controlador é responsável será replicado e reproduzido através dos outros controladores existentes. Isso garante ainformações de rede consistente e continuo.

Comandos:

# show controller-cluster status
# show controller-cluster startup-nodes
# show controller-cluster role
# show controller-cluster connections

NSX - Distributed Firewall (DFW)

As soluções de segurança tradicionais não são otimizadas para SDDC (Software Defined Data Center), resultando em um impacto negativo na agilidade e nos custos.

Os Firewalls tadicionais de perimetro e os sistemas de detecção e prevenção de intrusos não são suficientes para proteger o o datacenter inteiro.

o NSX DFW (Distributed Firewall) fornece serviços de firewall stateful, para qualquer carga do ambiente NSX sendo executado diretamente no kernel;

O DFW é ativado assim que o processo de preparação do host estiver concluído;

Se uma VM não requer serviço DFW, ela pode ser adicionada em uma lista de exclusão.

Por padrão, os gateways NSX Manager, NSX Controllers e Edge são automaticamente excluídos da função DFW.

Uma instância DFW é criada por VM vNIC:

Por exemplo, se uma nova VM com 3(três) VNICs for criado, as 3 instâncias de DFW serão alocadas a esta VM. A configuração destas instâncias DFW podem ser idênticas ou diferentes com base no "aplicar a" configuração. Quando uma regra DFW é criada, o usuário pode selecionar um ponto de aplicação (PEP) para esta regra, com opções que variam de Chave Lógica para vNIC. 

Por padrão,"Apply to" não é selecionada, portanto, as regras DFW são propagadas para todos os ESXi Hosts que fazem parte do domínio NSX que foram preparados para ser aplicada a todas as máquinas virtuais conectadas.

Visão das funcionalidades do NSX:

O firewall lógico pertence ao Data Plane:

Recursos do DFW:

• Firewall no nível da vNIC;
• Tratamento de sessão com estado(stateful);
• Os estados de conexão migram durante o vMotion;
• Firewall distribuído - escala bem com os datacenters sempre em expansão;
• Micro visibilidade e controle de nível de fluxo;
• Capacidade de ativar os fluxos em tempo real para depuração;
• Regras baseadas em conteiners;
• Regras de firewall segmentadas por NIC virtual;
• Nenhuma cópia de pacote está envolvida, como no caso de firewalls baseados em máquinas virtuais;
• Suporte ALG (Application Level Gateway); 
• Regras criadas automaticamente para portas dinâmicas;
• O processamento de regras distribuídas evita a duplicação de regras nas NICs virtuais;
• Suporte autoritário de Spoof Guard;
• As regras de política do DFW podem ser escritas de 2 maneiras, usando regras L2 (Ethernet) ou L3 / L4;

• O Firewall Lógico Distribuído aplica regras de firewall diretamente na placa de interface de rede virtual da máquina virtual (vNIC).

• MAC Set não é uma opção de destino válido para uma regra de fiewall geral.

• Regras de firewall lógico aplicadas a máquinas virtuais afetadas são aplicadas pelo NSX Manager para os hosts ESXi executando as máquinas virtuais de origem e / ou destino.

• Uma Máquina Virtual conectada a um switch lógico rodando em um host ESXi 5.1.
•  não pode ser protegido pelo Firewall Distribuído.

• Os Logs dos firewalls lógicos são salvos no host ESXi;

• Firewall Distribuído não gera log durante a criação das regras;

Benefícios:

• Distribuído no nível do hipervisor;
• Configuração dinâmica baseada em API;
• Nome da VM, objetos do VMware vCenter, regras baseadas na identidade;
• Line rate  ~ 20 Gbps por host;
• Visibilidade total do tráfego encapsulado;

Nível de atuação do DFW dentro da camada OSI:

O firewall NSX DFW oferece recursos de proteção até a camada 4 do modelo OSI e para as demais camadas de 5 a 7 é necessário um firewall de parceiros como por exemplo a Palo Alto.

Considera-se que apenas entre 10 e 20% do tráfego do Datacenter necessita de serviços L5 - L7;

Diferenças entre Firewall Virtual e Físico:

Firewall baseado em hardware são elaborados para entregar alta performance, alta capacidade de throughpout, tipicamente possuem um range de 2 e 30 Gbps, com alguns chassis excedendo 100Gbps.

Firewalls Virtuais possuem efetivamente uma operação no mesmo ponto de vista de um firewall físico, no entanto reduz os conjuntos de recursos e entregam bem menos capacidade de throughput com um range ntre 1 e 3 Gbps;

Firewall distribuidos são instalados diretamente no hypervisor do kernel e entregam 30Gbps per hypervisor. Sendo assim quanto mais hosts hypervisors tiver no ambiente, maior capacidade de firewall leste-oeste o ambinte possuíra;

Informações sobre Regras:

• As regras L2 são mapeadas para L2 no modelo OSI; Somente endereços MAC podem ser utilizados nos campos de origem e de destino e apenas os protocolos L2 usado nos campos de serviço (por exemplo, ARP).

• As regras L3 / L4 são mapeadas para L3 / L4 no modelo OSI; Regras de política podem ser escritos usando endereços IP e portas TCP / UDP.

• É importante lembrar que as regras L2 sempre são aplicadas antes das regras L3 / L4.
• Se a regra de política predefinida L2 for modificada para 'bloco', e então todo o tráfego L3 / L4 será bloqueado por DFW (por exemplo, pings falhariam).
• O DFW é um componente NSX projetado para proteger a carga de trabalho para a do tráfego de rede virtual-para-virtual ou virtual-para-físico (isto é, o tráfego leste-oeste)

Uma vez que a aplicação da política é aplicada as vNICs das VMs, também poderia ser utilizado para impedir a comunicação entre as máquinas virtuais e a infraestrutura de rede. O DFW é totalmente complementar aos serviços NSX Edge Gateway que fornece capacidade de firewall centralizado. O ESG é tipicamente usado para proteger o tráfego norte-sul e, como tal, é o primeiro ponto de entrada para o SDDC;

O  DFW opera no nível da vNIC; Portanto, uma VM está sempre protegida independentemente da topologia. As VMs podem ser conectadas a um grupo de portas VDS VLAN ou a um Switch Lógico (isto é, grupo de portas com suporte VXLAN). O ESG Firewall pode também ser usado para proteger cargas de trabalho  em servidores físicos e appliances (Por exemplo, NAS).

A arquitetura do sistema DFW é baseada em 3 entidades distintas, cada uma com um papel definido:

• vCenter Server:

vCenter Server é o plano de gerenciamento da solução. As regras de diretiva DFW são criadas no cliente Web vSphere. Qualquer contêiner vCenter pode ser usado no campo de origem / destino da diretiva Regra: cluster, VDS grupo de portas, Switch lógico, VM, vNIC, pool de recursos, Etc

• NSX Manager:

NSX manager é o plano de controle da solução. isto é, recebe regras do vCenter Server e as armazena a base de dados. NSX manager, em seguida, aplica as regras DFW regras para todos os ESXi hosts que foram preparadas para execução. Uma cópia de segurança da política de segurança DFW de regras é executada sempre que a tabela é modificada e publicada. NSX Manager também pode receber regras DFW diretamente de chamadas REST API em implantações onde um sistema de gerenciamento de nuvem é usado para segurança de automação.

• ESXi Host: 

ESXi host é o plano de dados da solução. As regras do DFW são recebidas do NSX Manager e traduzido para o espaço do kernel para tempo real de execução. O tráfego de rede VM é inspecionado e aplicado por ESXi. Como exemplo, VM1 está localizado no host ESXi 1 e envia pacotes para VM2 que está localizado no host ESXi 2. A execução da política é feita no ESXi
Host 1 para saída de tráfego quando os pacotes deixam VM1 e, em seguida, no ESXi host 2
para tráfego de entrada destinado a VM2.

Quando os containers vCenter são usados nas regras de diretiva DFW, VMtools deve ser instalado nas VMs guest. VMtools tem visibilidade do endereço IP do VM - dinamicamente fornecido através de DHCP ou configurado estaticamente na VM pelo administrador - e fornece estas informações para o motor DFW que opera com base nos campos de porta MAC, IP e TCP / UDP.
Se as regras de diretiva DFW usarem apenas informações de IP (por exemplo, IP do host, IP de sub-rede ou conjuntos IP), então a presença de VMtools na VM guest não é necessária.


A função DFW é ativada quando um host está preparado para execução. Durante esta operação, um VIB do kernel é carregado no hypervisor. Este VIB é conhecido como O VMware Internetworking Service Insertion Platform (VSIP). VSIP é responsável por toda a proteção de tráfego de plano de dados.

Uma instância DFW é criada por VM vNIC. Esta instância está localizada entre o VM e o Virtual Switch (ou seja, VDS port-group VLAN-backed ou Logical Switch).

DVfilter slot 2 é alocado para a instância DFW. Todos os pacotes de entrada e saída para e a partir desta VM tem de passar através do DFW.

Um conjunto de daemons chamado vsfwd é executado permanentemente no host ESXi e executa as seguintes tarefas:

• Interagir com o NSX Manager para recuperar regras de diretiva DFW.
• Reunir as informações estatísticas de DFW e enviá-las para o gerente NSX.
• Enviar informações de logs de auditoria para o gerenciador NSX.

O caminho de comunicação entre o vCenter Server e o host ESXi, o processo vpxa no host ESXi. Isto é usado apenas para vSphere relacionado, incluindo criação de VM, modificação de armazenamento e gerenciamento de IP do NSX e distribuição de endereços. Esta comunicação não é utilizada para o funcionamento geral DFW.

O módulo do kernel VSIP não melhora simplesmente a funcionalidade do DFW, esta plataforma de inserção de serviços adiciona serviços complementares como SpoofGuard e redirecionamento de tráfego de terceiros parceiros, incluindo a Palo Alto Networks, CheckPoint, Fortinet, Security Intel, Symantec, RAPID7 e Tend Micro).

SpoofGuard protege contra spoofing IP mantendo uma tabela de referência de VM, nome e endereço IP, preenchendo-o com informações recuperadas do VMtools durante a inicialização inicial da VM. O SpoofGuard está inativo por padrão e deve ser explicitamente habilitado por Switch Lógico ou VDS ou grupo de portas. Quando um endereço IP de VM  identifica um alteração detectada, o tráfego de / para esta VM pode ser bloqueado pelo DFW até o administrador NSX aprovar este novo endereço IP.

O redirecionamento de tráfego para fornecedores terceirizados fornece a capacidade do tipo de tráfego para um VM de serviços de parceiro selecionado. Por exemplo, o tráfego

Internet para um conjunto de servidores Apache ou Tomcat pode ser redirecionado para um L4-L7 Deep Firewall de inspeção de pacotes para proteção avançada.

O redirecionamento de tráfego é definido no Service Composer / Security Policy for NSX Versão 6.0 ou na guia Serviços de segurança do parceiro do menu DFW no NSX Versão 6.1. A guia Serviços de Segurança de Parceiros fornece um recurso poderoso e fácil de usar.

Interface para definir que tipo de tráfego precisa ser redirecionado para qual parceiro Serviços. Segue a mesma construção de definição de política que o DFW, mesmas opções para campo de origem, campo de destino e campo de serviços. A única diferença está no campo de ação; Em vez de Bloquear / Permitir / Rejeitar, um usuário pode selecionar entre redirecionamento / sem redirecionamento seguido por uma lista de parceiros. Qualquer parceiro que tenha sido registrado com o NSX pode ser implantado com sucesso na plataforma. Além disso, as opções de log podem ser ativadas para esta regra de redirecionamento de tráfego.

A instância DFW em um host ESXi contém 2 tabelas separadas. A tabela de regras é usada para armazenar todas as regras de política, enquanto a tabela de rastreador de conexão armazena em cache o fluxo entradas para regras com ações de permissão. Uma instância DFW é permitida por VM VNIC.

Um fluxo específico é identificado pela informação de 5-tuplas que consiste em IP de origem Endereço de destino, endereço IP de destino, protocolos, porta de origem L4 e destino L4 Campos de porta. Por predefinição, o DFW não efetua uma pesquisa em porta de origem L4, mas pode ser configurado para fazê-lo definindo uma regra de política específica.

Firewall Distribuído SpoofGuard

O SpoofGuard permite que o NSX garanta que o IP associado a um endpoint esteja correto no tempo e no bloco especificados se uma alteração não autorizada for detectada. Oaplicação no nível vNIC fornece um local na rede onde a segurança adicional da conexão de rede pode ser entregue.

O SpoofGuard permitirá ao administrador reconhecer e validar uma alteração de IP em uma Máquina Virtual. Sem esse reconhecimento, a Máquina Virtual não poderá se comunicar na rede.

O NSX Manager coleta e aprende endereços IP de todas as máquinas virtuais. A associação vNIC para IP são as informações coletadas - não o endereço MAC da VM;