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 usando 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 descreve 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
- 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.
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.
Existe uma ordem rigorosa que o SD-WAN utiliza 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.
| 1. Correspondência de prefixo mais longo |
| 2. Local ligado |
| 3. LAN estática/WAN local |
| 4. Remoto conectado |
| 5. LAN estática/WAN remota |
| 6. Destino Não-SD-WAN estático |
| 7. Gateway de parceiro estático |
| 8. Ordem dos caminhos baseada no controlo de fluxo de overlay (OFC) |
Caminhos ligados e estáticos
Esta secção inclui informações essenciais sobre os caminhos ligados e estáticos. Um caminho ligado é um caminho para uma rede que é diretamente ligada à interface. 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.
- O sinalizador Anunciar (Advertise) tem de estar definido na interface do Edge em Definições de IP de interface (Interface IP settings) para a qual 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.
- O sinalizador Anunciar (Advertise) tem de estar definido na interface Edge para a qual o caminho estático é configurado.
- A configuração do caminho estático tem de ter selecionadas as opções Preferido (Preferred) e Anunciado (Advertised).
- Os caminhos estáticos podem encaminhar o tráfego para o underlay WAN para segmentos globais e para o underlay LAN ou WAN para segmentos não globais.
- 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 sonda ICMP para evitar o tráfego de blackholing.
- 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.
A opção Preferido (Preferred) não está disponível para um tipo de endereço IPv6.
Quando a caixa de verificação Anunciar (Advertise) está selecionada, o caminho estático é anunciado através de caminhos VPN e outros SD-WAN Edges na rede terão acesso ao recurso.
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.
A opção Anunciar (Advertise) não está disponível para um tipo de endereço IPv6.
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”. Ao observar os registos de um Edge, um utilizador vê estes caminhos próprios com o sinalizador 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 o sinalizador “v” e refere-se a um caminho instalado num Edge que aponta para um VMware SD-WAN Gateway para tráfego multicaminho destinado à Internet (por outras palavras, tráfego da Internet que utiliza a Otimização multicaminho dinâmica (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 |
| Dispositivo | Tipo de caminho | Preferência predefinida |
|---|---|---|
| Edge | NSD E BGP | 997 |
| Edge | NSD I BGP | 998 |
| Gateway | NSD E/I BGP | 999 |
| Edge | NSD Uplink BGP | 1000 |
| Edge | OSPF O | 1001 |
| Edge | OSPF IA | 1002 |
| Edge | E BGP | 1003 |
| Edge | I BGP | 1004 |
| Gateway de parceiro | E/I BGP | 1005 |
| Hub | OSFP OE1 | 1001006 |
| Hub | OSPF OE2 | 1001007 |
| Hub | BGP Uplink | 1001008 |
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/2 ou BGP Uplink.
- Hub: qualquer local externo que seja aprendido num Edge 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: o router representa qualquer prefixo de caminho aprendido por um Edge com 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 de Router na Saída de VPN um valor de preferência baixo e, portanto, são os preferenciais, sendo atribuído a todos os pontos de saída abaixo de Router um valor de preferência mais alto e, portanto, 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 de caminhos dinâmicos
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.
