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.
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.
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:
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.
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.
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 |
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)
- 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
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:
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.
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.
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:
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.
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:
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 .
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.
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;
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 |
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;
- 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 |
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;
- 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)
- 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)
- 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”)
Nenhum comentário:
Postar um comentário
Deixe seu comentário!