O VMware SASE permite a interligação de vários Edges Hub ou Cluster de Hub para aumentar a gama de Spoke Edges que podem comunicar entre si. Esta funcionalidade permite a comunicação entre os Spoke Edges ligados a um Edge Hub/Cluster de Hub e os Spoke Edges ligados a outro Edge Hub/Cluster de Hub, utilizando várias ligações overlay e underlay.
Quando um Spoke Edge tenta ligar-se a um Cluster de Hub, um dos membros do Cluster de Hub é selecionado como Hub para o Spoke Edge. Se este Hub ficar inativo, outro membro do mesmo Cluster de Hub é automaticamente selecionado para servir o Spoke Edge, sem qualquer configuração do utilizador. Os membros do Cluster de Hub estão ligados uns aos outros através de underlay (BGP) e podem trocar caminhos e dados utilizando esta ligação underlay. Os Spoke Edges ligados a diferentes membros do mesmo Cluster de Hub podem então comunicar entre si utilizando esta ligação underlay. Esta solução oferece uma melhor resiliência.
- A funcionalidade Hub ou Cluster Interconnect (Hub or Cluster Interconnect) tem de estar ativada.
- A caixa de seleção Site Ramo a Hub (VPN permanente) [Branch to Hub Site (Permanent VPN)] tem de estar selecionada. Os dois nós de Hub interligados têm de ser configurados como Hubs entre si, conforme explicado na tabela abaixo.
Perfil | Designação de Hubs |
---|---|
hub_profile1 | hub2 |
hub_profile2 | hub1 e hub3 |
hub_profile3 | hub2 |
Quando a funcionalidade Hub ou Cluster Interconnect (Hub or Cluster Interconnect) está ativada, os túneis são formados de um Cluster para outro Cluster com, pelo menos, um par noutro Cluster. Com base na condição, dois membros de um Cluster podem formar túneis para os mesmos membros noutro Cluster. No caso de interligação de Hub individual e Cluster de Hub, todos os membros do Cluster formam túneis para esse Hub individual. Os Edges Spoke finais ligados a estes Clusters de Hub podem comunicar entre si através destes dois Clusters de Hub e dos hops do protocolo de routing do VMware SD-WAN intermediários.
Os caminhos dentro do Cluster são anunciados com uma comunidade BGP estendida especial, em que os últimos quatro bytes do ID do Cluster são incorporados na comunidade estendida. Por exemplo, se o ID do Cluster for fee2f589-eab6-4738-88f2-8af84b1a3d9c
, serão revertidos e utilizados 4b1a3d9c
para derivar a comunidade do Cluster como 9c3d1a4b00000003
. Com base nesta etiqueta da comunidade, os caminhos dentro do Cluster são filtrados em direção ao controlador. Isto evita refletir caminhos redundantes de vários membros do Cluster.
- Ligação overlay entre S1 e C1.
- Ligação overlay entre S2 e C2.
- Ligação overlay entre C1 e C2.
- Ligação underlay dentro de C1.
- Ligação underlay dentro de C2.
Desta forma, os Clusters de Hub podem trocar caminhos entre si, proporcionando uma forma de os pacotes fluírem entre Spoke Edges ligados a diferentes Clusters de Hub.
- A opção Ramo a ramo dinâmica é suportada entre Spokes ligados a dois Clusters diferentes ou iguais.
- O isolamento de perfil no perfil Spoke é suportado.
- O Backhaul de Internet via Cluster é suportado.
Limitações:
- O Hub ou Cluster Interconnect através de Gateway não é suportado.
- A troca de caminhos entre membros do Cluster de Hub utilizando OSPF não é suportada.
- O routing assimétrico pode ocorrer quando dois clusters estão interligados. Os serviços de firewall melhorados ou a firewall com estado não podem estar ativados, uma vez que podem bloquear o tráfego devido ao routing assimétrico.
- Quando todos os túneis de overlay ficam inativos entre dois membros do Cluster, a queda de tráfego é esperada até que estes formem um túnel com outros membros no Cluster do par.
- Se existir mais de um router LAN/WAN a executar o BGP com o Cluster, a caixa de seleção Fonte fidedigna (Trusted Source) terá de estar selecionada e o valor de Encaminhamento de caminho inverso (Reverse Path Forwarding) terá de ser Não ativado (Not enabled) nas interfaces do Edge de Cluster a ligar os routers BGP. Para obter mais informações, consulte Configurar as definições da interface para os Edges.
- Sem a funcionalidade Hub ou Cluster Interconnect (Hub or Cluster Interconnect) um perfil de Hub de Cluster não pode ter outro Cluster ou Hub configurado como Hub.
Configurar o Hub ou Cluster Interconnect
Pré-requisitos
- Certifique-se de que atualiza o Orchestrator, os Gateways e os Hubs ou Clusters de Hub para a versão 5.4.0.0 ou superior.
- O serviço VPN de cloud (Cloud VPN) tem de ser ativado para o perfil de cluster associado aos Clusters ou Hubs Edge.
- A caixa de seleção VPN ramo a ramo (Trânsito e Dinâmica) [Branch to Branch VPN (Transit & Dynamic)] não pode estar selecionada nos perfis de Hub de interligação, conforme mostrado abaixo.
A configuração da Designação de Hubs (Hubs Designation) em perfis de interligação é suficiente para a comunicação de ponta a ponta com todos os nós. Pode configurar a opção Ramo a ramo via Hubs (Branch to Branch via Hubs) para perfis Spoke.
- A funcionalidade Hub ou Cluster Interconnect (Hub or Cluster Interconnect) tem de estar ativada em todos os perfis de Hub envolvidos no processo de interligação.
- Os membros do cluster têm de executar o BGP com o router LAN/L3 e o router tem de ser configurado para encaminhar as comunidades BGP estendidas.
- Tem de haver, pelo menos, um Gateway comum para todos os Edges (Spokes e Hubs) no caso de atribuição de Gateways de parceiro. A ordem de atribuição dos Gateways de parceiro deve ser a mesma em todos os perfis de Hub/Cluster.
Procedimento
Como proceder a seguir
- Atribuir perfis a Edges: navegue para para atribuir perfis aos Edges disponíveis.
- Pode monitorizar os eventos ao navegar para Hub ou Cluster Interconnect (Hub or Cluster Interconnect)
Evento Nível Descrição CLUSTER_IC_ENABLED Informações Este evento é gerado sempre que um Edge é associado a um serviço de Cluster. CLUSTER_IC_DISABLED Informações Este evento é gerado sempre que um Edge é desassociado de um serviço de Cluster. CLUSTER_IC_PEER_UP Aviso Este evento é gerado sempre que o primeiro túnel de interligação entre dois nós do Hub de Cluster fica ativo. CLUSTER_IC_PEER_DOWN Aviso Este evento é gerado sempre que o último túnel de interligação entre dois nós do Hub de Cluster fica inativo. CLUSTER_IC_TUNNEL_UP Aviso Este evento é gerado sempre que os túneis de interligação entre os Clusters ficam ativos. CLUSTER_IC_TUNNEL_DOWN Aviso Este evento é gerado sempre que os túneis de interligação entre os Clusters ficam inativos. HUB_CLUSTER_REBALANCE Aviso Este evento é gerado sempre que uma ação de reequilíbrio do Cluster é acionada.
. A tabela seguinte lista os novos eventos do Orchestrator adicionados para a funcionalidade
- Depois de a funcionalidade Hub ou Cluster Interconnect (Hub or Cluster Interconnect) ter sido ativada, remover ou adicionar um membro do Cluster em Serviços de rede (Network Services) aciona a reinicialização do serviço nesse Edge específico. É aconselhável executar tais ações durante a janela de manutenção.
- Quando um Spoke está ligado ao Cluster de Hub principal e secundário e aprende o mesmo caminho com ambos, a ordem dos caminhos baseia-se nos atributos do BGP. Se os atributos de routing forem os mesmos, a ordem dos caminhos ocorrerá com base na configuração do pedido do Hub VPN. Por outro lado, as sub-redes do Spoke são redistribuídas pelo Hub ou Cluster de Hub principal e secundário para o vizinho com a métrica (MED) 33 e 34 respetivamente. Tem de configurar “bgp always-compare-med” no router vizinho para o routing simétrico.
- Quando o Hub ou Clusters de Hub estiverem ligados ao núcleo MPLS através do CE, tem de configurar a etiqueta UPLINK nesses vizinhos BGP.