Esta secção fornece uma visão geral da funcionalidade de routing do VMware SASE, incluindo tipos de caminho, caminhos ligados e estáticos, caminhos dinâmicos com cenários de desempate e valores preferenciais no Controlo de fluxo de overlay (OFC) com cálculo de custos distribuídos (DCC).
Visão geral
O routing do VMware SASE assenta num protocolo proprietário chamado VCRP, com capacidade multicaminho e protegido através do transporte VCMP. Os pontos finais do SD-WAN são ligados através de VCRP de uma forma semelhante à malha total iBGP. O SD-WAN Gateway funciona como um refletor de caminho BGP que reflete os caminhos de um SD-WAN Edge para outro SD-WAN Edge dentro da empresa do cliente com base nas definições de perfil.
O diagrama a seguir ilustra uma implementação típica do SD-WAN com Destinos Não-SD-WAN Multi-Cloud, em que o Orchestrator executa o cálculo do caminho, em contraste com o método mais recente e preferido que utiliza o Cálculo de custo dinâmico (DCC).
Componentes do SD-WAN para fins de routing
- O SD-WAN Edge é um dispositivo de classe empresarial ou uma instância de cloud virtualizada que proporciona conectividade segura e otimizada para aplicações privadas, públicas e híbridas e serviços virtualizados. No routing do SD-WAN, o Edge é um Border Gateway. Um Edge pode funcionar como um Edge normal (sem configuração do Hub), como um Hub por si só ou como parte de um cluster, ou como um Spoke (quando os Hubs estão configurados).
- O SD-WAN Gateway é autónomo, sem estado, horizontalmente escalável e fornecido na cloud aos Edges aos quais podem ser ligados vários inquilinos. Para qualquer implementação do SD-WAN, são implementados vários SD-WAN Gateways como uma rede geograficamente distribuída (para menor latência) e horizontalmente escalável (por motivos de capacidade) com cada Gateway a atuar como um Refletor de caminho para os Edges ligados.
Todos os caminhos que são aprendidos localmente num Edge são enviados para o Gateway com base na configuração. O Gateway reflete então estes caminhos para outros Edges da empresa, permitindo uma conectividade VPN de malha total eficiente sem criar uma malha total de túneis.
- O SASE Orchestrator é um portal de configuração e monitorização baseado na cloud multi-inquilino. No routing SD-WAN, o Orchestrator gere os caminhos de todas as empresas e pode sobrepor o comportamento de routing padrão.
Veja na imagem abaixo uma ilustração dos componentes do VMware SD-WAN para fins de routing.
Tipos de caminhos
- Caminhos locais: qualquer caminho aprendido localmente num SD-WAN Edge. Pode ser uma sub-rede ligada, um caminho estático configurado ou qualquer caminho aprendido via BGP ou OSPF.
- Caminhos remotos: qualquer caminho aprendido do VCRP, ou seja, um caminho que não esteja presente localmente num Edge é um caminho remoto. Este caminho teve origem num Edge diferente e é refletido pelo Gateway para outros Edges na empresa do cliente com base na configuração.
O SD-WAN utiliza uma ordem rigorosa para encaminhar o tráfego para caminhos não dinâmicos (BGP e OSPF), que não pode ser alterada. No entanto, em certos cenários, pode utilizar a técnica de Correspondência de prefixo mais longo para manipular a forma como o routing flui.
- Comprimento do prefixo mais longo.
- Ligado local.
- Estático local se a opção preferida estiver ativada (LAN estática < WAN estática).
- Se a opção preferida não estiver ativada, recomendam-se os caminhos de overlay.
- Caminhos NSD estáticos locais.
- O NSD IPsec ganha ao NSD GRE.
- NSD estático remoto.
- Edge remoto ligado.
- LAN/WAN estática do Edge remoto.
- PG estático.
- PG estático seguro > PG estático não seguro.
- Caminhos dinâmicos (ordem de caminhos baseada no Controlo de fluxo de overlay (OFC) ou no Cálculo de custos distribuídos).
- O site local (OSPF Inter/Intra, BGP não uplink) é preferível a caminhos dinâmicos de overlay.
- Os caminhos OSPF inter/intra locais ganham ao BGP local.
- O BGP local ganha ao OSPF externo local (OE1/OE2).
- Os caminhos remotos com custo preferencial ganham ao caminho local não preferencial (OE1, OE2, BGP UPLINK).
- Dentro dos caminhos dinâmicos remotos, a preferência é considerada (a menor preferência ganha).
- Se a preferência for a mesma, os atributos BGP e as métricas OSPF são comparados.
- OSPF INTRA > INTER > OE1 > OE2
- BGP
- Maior preferência local
- Comprimento do AS_PATH mais reduzido
- Métrica BGP mais pequena
- Para mais informações sobre o cálculo de preferências, consulte a secção DCC.
Caminhos ligados e estáticos
Esta secção inclui informações essenciais sobre os caminhos ligados e estáticos. Um caminho ligado é um caminho configurado para uma rede que é diretamente ligada à interface. Um caminho estático é útil para casos especiais em que são necessários caminhos estáticos para os dispositivos ligados à rede existentes, como impressoras. Pode obter informações sobre os caminhos estáticos em Configurar as definições de caminho estático.
Caminhos ligados
- Para que um caminho ligado seja visível no SD-WAN, configure as seguintes definições no Orchestrator:
- VPN de Cloud (Cloud VPN) tem de estar ativado.
- O caminho ligado tem de ser configurado com um endereço IP válido.
- A interface do Edge para este caminho tem de estar na Camada 1 e funcional nas Camadas 2 e 3.
- As VLANs associadas a esta interface do Edge também têm de estar ativas.
- A flag Anunciar (Advertise) tem de estar definida na interface do Edge em Definições de IP de interface (Interface IP settings) para o caminho ligado configurado.
- Para que um caminho estático seja visível no SD-WAN, configure as seguintes definições no Orchestrator:
- VPN de Cloud (Cloud VPN) tem de estar ativado.
- A configuração do caminho estático tem de ter selecionada a opção Anunciado (Advertised).
- Os caminhos estáticos podem encaminhar o tráfego para o underlay WAN ou para a LAN.
- A adição de um caminho estático contorna o NAT na interface Edge.
- O ECMP (routing multicaminho de custo igual) com um caminho estático não é suportado, e apenas pode ser utilizado o primeiro caminho estático.
- Utilize uma pesquisa ICMP para evitar o blackholing do tráfego em caso de falha no próximo hop.
- Um caminho estático com o sinalizador Preferido (Preferred) é preferido em detrimento de qualquer caminho VPN aprendido através de Overlay.
Quando a caixa de verificação Preferido (Preferred) está selecionada, o caminho estático será a primeira correspondência, mesmo que um caminho VPN com um custo inferior esteja disponível.
Não selecionar esta opção significa que qualquer caminho VPN disponível terá correspondência em relação ao caminho estático, mesmo que o caminho VPN tenha um custo mais elevado do que o caminho estático. Só é feita a correspondência com o caminho estático quando não estiverem disponíveis caminhos VPN correspondentes.
Quando a caixa de verificação Anunciar (Advertise) está selecionada, o caminho estático é anunciado através de VPN e outros SD-WAN Edges na rede terão acesso ao recurso. Isto também permite a redistribuição de caminhos estáticos para um protocolo de routing como o BGP/OSPF local.
Não selecione esta opção quando um recurso privado, como a impressora pessoal de um trabalhador remoto, for configurado como caminho estático e outros utilizadores devam ser impedidos de aceder ao recurso.
As Flags de anúncio global do OFC controlam quais os caminhos que são adicionados ao overlay. Por predefinição, os seguintes tipos de caminhos não são anunciados no overlay: OSPF externo e iBGP de Destino Não-SD-WAN. Além disso, se um Edge estiver a funcionar como Hub e Ramo, serão utilizadas as Flags de anúncio global configuradas para o Ramo, não o Hub.
Um Caminho próprio (Self Route) refere-se a um prefixo baseado na interface utilizando uma correspondência de prefixo mais longo de IP (LPM) (por exemplo: 172.16.1.10/32), que é instalado localmente no Edge, mas que não é anunciado para Edges remotos. Outro termo para Caminhos próprios é “Caminhos da interface”. Nos registos do Edge, os caminhos próprios são apresentados com a flag de caminho “s”.
Um caminho próprio distingue-se de um caminho ligado pelo facto de um caminho ligado poder ser anunciado no overlay, para que os clientes Edge remotos possam alcançar os clientes que pertencem ao caminho ligado do lado do Edge de origem. Os caminhos próprios são estritamente locais em relação ao Edge propriamente dito.
Um Caminho da cloud (Cloud Route) tem a flag “v” e refere-se a um caminho instalado num Edge que aponta para um VMware SD-WAN Gateway principal para tráfego multicaminho destinado à Internet (por outras palavras, tráfego da Internet que utiliza a Otimização dinâmica de vários caminhos (DMPO), que aproveita um Gateway antes de alcançar a Internet).O Edge também utiliza um caminho da cloud através de um Gateway correspondente para tráfego de gestão destinado a um VMware Orchestrator alojado na cloud pública.
Controlo de fluxo de overlay (OFC) com cálculo de custos distribuídos (DCC)
Visão geral do Cálculo de custos distribuídos
O Cálculo de custos distribuídos (DCC) é uma funcionalidade que utiliza os SD-WAN Edges e Gateways para o cálculo da preferência de caminho em vez de se basear no SASE Orchestrator. O Edge e o Gateway inserem os caminhos instantaneamente após os aprenderem e transmitem essas preferências ao Orchestrator.
O DCC resolve um problema presente em implementações de grande escala em que a confiança exclusiva no Orchestrator pode impedir atualizações atempadas de preferências de caminhos, seja por não ser alcançado por um Edge ou Gateway para receber preferências de routing atualizadas ou porque o Orchestrator não consegue fornecer atualizações de caminho rapidamente quando está a calcular um grande número de atualizações ao mesmo tempo. Distribuir as responsabilidades pelo cálculo de preferência de caminhos para os Edges e Gateways garante atualizações de caminho rápidas e fiáveis.
Como é obtida a preferência de cálculo de custos distribuídos
| Edge | Gateway parceiro/Gateway alojado |
|---|---|
| NSD E BGP | NSD E/I BGP |
| NSD I BGP | E/I BGP |
| NSD Uplink BGP | |
| OSPF O | |
| OSPF IA | |
| E BGP | |
| I BGP | |
| OSPF OE1 | |
| OSPF OE2 | |
| Uplink BGP |
| O = OSPF intra-área |
| IA = OSPF interárea |
| OE1 = OSPF externo Tipo-1 |
| OE2 = OSPF externo Tipo-2 |
| E BGP = BGP externo |
| I BGP = BGP interno |
| NSD = Destino Não-SD-WAN |
Cada tipo de caminho tem um valor de preferência (considere a preferência como o custo neste documento) e a cada caminho aprendido é atribuído um valor de preferência com base no tipo de caminho. Quanto menor for o valor de preferência, maior é a prioridade. A tabela 1-3 lista o valor de preferência predefinido para cada tipo de caminho.
| Dispositivo (Device) | Tipo de caminho (Route Type) | Preferência predefinida (Default Preference) |
| Edge/Hub | NSD E BGP | 997 |
| Edge/Hub | NSD I BGP | 998 |
| Gateway | NSD E/I BGP | 999 |
| Edge/Hub | NSD Uplink BGP | 1000 |
| Edge/Hub | OSPF O | 1001 |
| Edge/Hub | OSPF IA | 1002 |
| Edge/Hub | E BGP | 1003 |
| Edge/Hub | I BGP | 1004 |
| Gateway de parceiro | E/I BGP | 1005 |
| Edge/Hub | OSFP OE1 | 1001006 |
| Edge/Hub | OSPF OE2 | 1001007 |
| Hub/Edge | BGP Uplink | 1001008 |
Os valores de preferência apresentados na tabela acima baseiam-se na ordem de prioridade predefinida na configuração do controlo de fluxo de overlay. Os valores serão ajustados em conformidade se a ordem predefinida for alterada.
Fluxo de trabalho do caminho dinâmico
- O Edge ou Gateway aprende um caminho dinâmico.
- O SD-WAN identifica internamente o tipo de caminho e o seu valor de preferência predefinido.
- O SD-WAN atribui o valor de preferência correto e instala o caminho na base de informação de routing (RIB) e na base de informação de encaminhamento (FIB).
- O SD-WAN considera a ação de anúncio predefinida configurada para este caminho. Com base na ação de anúncio, o SD-WAN anuncia o caminho na empresa do cliente (anunciado) ou não realiza qualquer ação para além de adicionar o caminho localmente na RIB e FIB (não anunciado).
- Em seguida, o SD-WAN sincroniza este caminho com o Orchestrator que o apresenta no Orchestrator.
Pontos de saída VPN preferidos
Esta secção aborda os Pontos de saída VPN preferidos: o que são, que caminhos são classificados em que categorias, e a utilização da fixação de caminho para sobrepor valores predefinidos.
No serviço SD-WAN do portal da empresa, ao navegar para , pode ver uma secção intitulada Saídas VPN preferidas (Preferred VPN Exits). Esta secção apresenta as prioridades predefinidas e assinala algumas categorias de caminho como preferenciais em relação a outras.
- Edge: qualquer caminho interno que possa ser aprendido num Hub ou Spoke Edge insere-se nesta categoria e é assinalado com a prioridade mais alta. Um caminho interno não pode ser um caminho do tipo OSPF OE 1/OE 2 ou BGP Uplink.
- Hub: qualquer caminho externo que seja aprendido num Edge/Hub insere-se na categoria Hub e tem, tipicamente, prioridade mais baixa. Os caminhos do Hub incluem OSPF OE1/2 e BGP Uplink.
- Gateway de parceiro: qualquer caminho aprendido num Gateway de parceiro.
- Router: um router representa qualquer prefixo de caminho aprendido por um Edge com um BGP ou OSPF e determina a preferência que é atribuída a um caminho dinâmico. Normalmente, é atribuído a todos os pontos de saída acima do Router na Saída de VPN um valor de preferência baixo (custo preferido) e estes são os preferenciais, sendo atribuído a todos os pontos de saída abaixo do Router um valor de preferência mais alto e estes são menos preferidos.
- Por exemplo: quando DCC está ativado, todos os caminhos que pertencem aos Pontos de saída de VPN (Edge, Partner Gateway ou Hub) que estão acima de Router recebem um valor de preferência inferior a 1 000 000 e os caminhos que estão abaixo de Router recebem um valor de preferência superior a 1 000 000.
- No exemplo abaixo, os Pontos de saída de VPN acima de Router, que são NSD, Edge e Partner Gateway recebem um valor de preferência inferior a 1 000 000 e o Hub recebe um valor de preferência superior a 1 000 000.
Fixar um caminho para sobrepor um valor de preferência predefinido
- Um utilizador fixa um caminho na página Controlo de fluxo de overlay (Overlay Flow Control) da seguinte forma:
- Na Lista de caminhos (Routes List), selecione um ou mais caminhos e, em seguida, clique na opção Fixar preferência de caminho aprendido (Pin Learned Route Preference).
- Modifique a ordem das Saídas de VPN preferidas (Preferred VPN Exits) clicando em Editar (Edit) por baixo da tabela.
- O Orchestrator envia este evento de routing para os Edges relevantes na empresa do cliente.
- Os Edges sobrepõem o valor de preferência anterior de forma a corresponder à ordem afixada.
- Os valores de preferência que são atribuídos a caminhos fixos começam a partir de 1, 2, 3, e assim por diante (os valores mais baixos e, portanto, as preferências mais altas), e isto corresponde à ordem dos caminhos na página Controlo de fluxo de overlay (Overlay Flow Control).
Nota: Para obter mais informações sobre a fixação de um caminho, consulte Configurar sub-redes.
Cenários de desempate para todos os tipos de caminhos
O que acontece quando um Edge recebe o mesmo prefixo para duas ou mais origens/vizinhos?
Um cenário potencial nas configurações SD-WAN é que o mesmo prefixo seja anunciado a partir de dois Edges ou Gateways de Parceiro diferentes. Com o VMware SD-WAN, se as sub-redes estiverem na mesma categoria (Edge, Hub ou Gateway de parceiro) e tiverem o mesmo valor de preferência, os atributos BGP ou a métrica OSPF serão considerados em primeiro lugar para a ordenação dos caminhos.
Se ainda existir um empate, o SD-WAN utiliza o ID lógico (que é derivado do Identificador exclusivo universal (UUID) do Edge ou Gateway) do dispositivo de próximo hop para obter um desempate. O dispositivo de próximo hop pode ser um Gateway ou um Hub Edge, dependendo do tipo de VPN Ramo a Ramo que está a ser utilizado. Se a empresa do cliente estiver a utilizar o método Ramo a Ramo via Gateway, o próximo hop é um Gateway, enquanto um cliente que utilize o método Ramo a Hub terá um Hub Edge como próximo hop.
Há um critério de desempate final se vários Gateways anunciarem exatamente o mesmo tipo de caminho e de preferência. Este desempate final prefere o caminho mais antigo aprendido. Para garantir o resultado de routing desejado, pode fixar determinados caminhos ou configurar os custos e atributos do BGP para favorecer alguns caminhos em detrimento de outros.
Consulte a imagem abaixo para ver uma ilustração do cálculo de preferências e da ordenação de caminhos para caminhos dinâmicos.
- O Spoke1 e o Spoke2 aprendem o caminho como caminhos BGP (não uplink).
- O Hub1 e o Hub2 aprendem os caminhos como caminhos BGP uplink.
- O PG1 também aprende o mesmo caminho.
- A opção Ramo a ramo através do Hub1 e do Hub2 está ativada no perfil do Spoke.
- Uma vez que o Spoke1 e o Spoke2 aprendem o caminho como BGP, escolhem o valor de custo preferencial (o valor de preferência é referido como custo nesta secção) de 1003, de acordo com a tabela de mapeamento de preferências DCC.
- O caminho 9.9.9.9/32 será instalado na FIB do Spoke1 e do Spoke2 com um custo de referência de 1000000. Como sempre, o caminho underlay será instalado na FIB apenas com um custo de referência. O custo/preferência derivado da tabela de preferências DCC destina-se a ser utilizado pelas entidades SD-WAN remotas (Edges/Gateway) para a ordenação de caminhos.
- O Spoke1 e o Spoke2 redistribuem o caminho através do VCRP com um custo derivado de 1003 para o Gateway e os Edges/Hubs remotos. A imagem de saída abaixo mostra o custo/preferência derivado nos Spokes.
- Da mesma forma, o Hub1 e o Hub2 aprendem o caminho e obtêm o custo não preferencial (1001008), uma vez que aprendem o caminho como um caminho uplink. Os Hubs redistribuem o caminho para Gateways e outros Edges com este custo. A saída abaixo mostra o custo/preferência derivado nos Hubs.
- O PG1 aprende o mesmo caminho do BGP, utiliza o custo 1005 e redistribui-o para os Edges. A saída abaixo mostra o custo/preferência derivado no PG.
- O Spoke1 recebe o caminho do Hub1 e do Hub2 com o custo não preferencial de 1001008. O Spoke1 tem o custo preferencial de 003. Assim, o próprio caminho underlay do Spoke1 será o preferencial e os caminhos do Hub serão instalados abaixo do caminho underlay (SB). Dentro dos caminhos do Hub, se a preferência (custo) for a mesma, os atributos BGP serão comparados para ordenar os caminhos. Se os atributos BGP também forem os mesmos, a ordem dos Hubs será utilizada para instalar os caminhos.
- O Spoke1 recebe um caminho do Spoke2 e do PG1 com os custos 1003 e 1005, respetivamente. Uma vez que o Spoke1 tem um custo preferencial 1003 e recebe caminhos do Spoke2 e do PG1 com um custo preferencial (<100000), o Spoke1 adiciona o custo de referência 1000000 ao custo preferencial de entrada e instala os caminhos na FIB. Neste caso, o caminho do Spoke2 será instalado com um custo de 1001003 e o caminho do PG1 será instalado com um custo de 1001005.
- A mesma lógica de ordenação de caminhos é aplicada ao Spoke2 ou mesmo aos Hubs, se estes aprenderem o caminho como um caminho não uplink.
- Se não houver nenhum caminho underlay aprendido em qualquer entidade, não haverá qualquer correção à preferência/custo do caminho recebido. Os caminhos serão instalados de acordo com a preferência/custo recebidos.
- Os Hubs instalam o seu próprio caminho underlay (SB) com um custo de referência de 1000000 na FIB.
- Os Hubs recebem caminhos do Spoke com um custo preferencial de 1003. Uma vez que o custo é o mesmo entre os Spokes, os atributos BGP serão comparados e ordenados com base nisso. Se os atributos BGP também forem os mesmos, o ID lógico do Spoke será utilizado para ordenar (o ID lógico de destino mais baixo ganha o desempate). Os caminhos do Spoke serão instalados com o custo recebido tal como está.
- O Hub recebe o caminho do PG1 com o custo preferencial. Por conseguinte, instala-se com esse custo tal como está.
- O PG1 instala o seu próprio caminho underlay (PB) com a preferência 100000.
- O PG1 recebe os caminhos do Spoke e o caminho do Hub com a preferência correspondente. Os caminhos são colocados na FIB com base no valor de preferência. Se as preferências forem as mesmas, são considerados os atributos BGP. Se também forem iguais, o ID lógico será utilizado para a ordenação.
- No PG, não há correção de preferências/custos.
- Se o DCC não estiver ativado, o veredito do anúncio e o cálculo de preferências são efetuados pelo Orchestrator. Cada entidade (Edge ou Gateway) envia os caminhos aprendidos para o Orchestrator e espera receber uma resposta do Orchestrator. Ao receber a resposta do Orchestrator, o Edge ou o Gateway começará a redistribuir os caminhos para outras entidades SD-WAN se a flag de anúncio for “true” (verdadeiro) na resposta.
- A ordenação dos caminhos permanece a mesma, tal como no caso de o DCC estar ativado, mas os valores de preferência não são fixos neste cenário de desativação do DCC.
- A preferência/custo de referência é 512 para o cálculo de preferência baseado no Orchestrator. A preferência/custo < 512 é o custo preferencial, enquanto > 512 é atribuído a caminhos não preferenciais (caminhos UPLINK, caminhos OSPF externos). A lógica de ordenação de outros caminhos permanece a mesma quando o DCC está ativado.
- Se o Spoke2 aprender o caminho primeiro e o enviar para o Orchestrator, o Orchestrator começa a atribuir a preferência com base na entidade e no tipo de caminho. Uma vez que o Spoke2 aprende como não uplink, o Orchestrator atribui o valor de preferência (por exemplo, 64). Mais tarde, quando o Spoke1 enviar o mesmo caminho para o Orchestrator, este compara a entidade, o tipo de caminho e os atributos do caminho. Se for melhor, atribui a preferência a < 64. Se for pior, atribui a preferência a > 64.
- Os Hubs aprendem os caminhos como caminhos uplink e enviam-nos para o Orchestrator. O Orchestrator atribui um custo não preferencial (> 512); neste exemplo, é 4096. Se a preferência for a mesma, a ordem dos Hubs será utilizada para ordenar os caminhos nos Spokes.
- Quando o DCC está desativado, a ordem dos caminhos no Spoke1 (com um caminho não uplink) será semelhante à seguinte imagem.
- A ordem dos caminhos nos Hubs com um caminho uplink será semelhante à seguinte imagem.
- A ordem dos caminhos no PG será semelhante à seguinte imagem.
- Comprimento do prefixo mais longo.
- Caminhos NSD estáticos locais.
- NSD estático remoto.
- PG estático seguro.
- O caminho estático do PG de nível empresarial ganha ao PG estático de nível global.
- Ligado remotamente/estático.
- O logical_id do Edge será o fator de desempate (o ID lógico mais elevado ganha).
- Caminhos dinâmicos (ordem de caminhos baseada no Controlo de fluxo de overlay (OFC) ou no Cálculo de custos distribuídos).
- A ordenação dinâmica de caminhos basear-se-á no valor de preferência. A preferência mais baixa ganha.
- Ao contrário de um Edge, não existe preferência na correção automática no Gateway. Para caminhos dinâmicos, o Gateway instala os caminhos com a preferência recebida. O caminho local será sempre instalado com a preferência de referência de 1000000.
Nota: Para obter mais informações sobre o cálculo de preferências, consulte a secção “Controlo de fluxo de overlay (OFC) com cálculo de custos distribuídos (DCC)”. - PG estático não seguro.
