Esta secção descreve os passos de verificação de instalação e pós-instalação.
Se tudo tiver funcionado como esperado na instalação, poderá agora iniciar sessão na VM.
- Se tudo funcionar como esperado, deverá ver o pedido de início de sessão na consola. Deve ver o nome da solicitação como especificado em cloud-init.
- Também pode consultar /run/cloud-init/result.json. Se vir a mensagem abaixo, é provável que o cloud-init seja executado com sucesso.
- Verifique se o Gateway está registado com o SASE Orchestrator.
- Verifique a conectividade externa.
- Verifique se o VRF MGMT está a responder a ARPs.
- Opcional: desative o cloud-init para que não seja executado em todos os arranques.
Nota: Se implementou o OVA no VMware vSphere com propriedades vAPP, terá de desativar o cloud-init antes de atualizar para as versões 4.0.1 ou 4.1.0. Isto é para garantir que as definições de personalização, tais como a configuração de rede ou de palavra-passe, não se perdem durante a atualização.
touch /etc/cloud/cloud-init.disabled
- Associe o novo conjunto de gateways ao cliente.
- Associe o gateway a um Edge. Para obter mais informações, consulte a secção “Atribuir o handoff de gateway de parceiro” no Guia de administração do VMware SD-WAN.
- Verifique se o Edge consegue estabelecer um túnel com o gateway no lado da Internet. No SASE Orchestrator, aceda a .
No SASE Orchestrator, aceda a e clique em Executar (Run) para ver a lista de caminhos ativos.
- Configure a interface de handoff. Consulte Configurar handoff de parceiro.
- Verifique se a sessão BGP está ativa.
- Altere a configuração da rede.
Os ficheiros de configuração da rede estão localizados em /etc/netplan.
Exemplo de configuração de rede (o espaço em branco é importante!) - /etc/netplan/50-cloud-init.yaml:network: version: 2 ethernets: eth0: addresses: - 192.168.151.253/24 gateway4: 192.168.151.1 nameservers: addresses: - 8.8.8.8 - 8.8.4.4 search: [] routes: - to: 192.168.0.0/16 via: 192.168.151.254 metric: 100 eth1: addresses: - 192.168.152.251/24 gateway4: 192.168.152.1 nameservers: addresses: - 8.8.8.8 search: []
echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
Configurar a interface de handoff no plano de dados
Configuração da rede do VMware SD-WAN Gateway
No exemplo com a imagem abaixo (handoff do VRF/VLAN para PE), assumimos que eth0 é a interface voltada para a rede pública (Internet) e eth1 é a interface voltada para a rede interna (VRF do cliente através do PE). A configuração de pares BGP é gerida no VCO por cliente/VRF em “Configurar > Cliente” (Configure > Customer). Note que o endereço IP de cada VRF é configurável por cliente. O endereço IP do VRF de gestão herda o endereço IP configurado na interface do SD-WAN Gateway no Linux.
É criado um VRF de gestão no SD-WAN Gateway e este é utilizado para enviar uma atualização periódica do ARP para o IP do Gateway predefinido para determinar o MAC de próximo hop. Recomenda-se que seja criado um VRF dedicado no router PE para este fim. O mesmo VRF de gestão também pode ser utilizado pelo router PE para enviar uma pesquisa SLA IP para o SD-WAN Gateway para verificar o estado do SD-WAN Gateway (o SD-WAN Gateway tem um respondedor CMP com estado que responderá ao ping apenas quando o serviço estiver em funcionamento). Os pares BGP não são necessários no VRF de gestão. Se não estiver configurado um VRF de gestão, pode utilizar um dos VRFs do cliente como VRF gestão, embora isto não seja recomendado.
"vcmp.interfaces":[
"eth0"
],
(..snip..)
"wan": [
"eth1"
],
Passo 2: configure o VRF de gestão. Este VRF é utilizado pelo SD-WAN Gateway para o ARP para o MAC de próximo hop (router PE). O mesmo MAC de próximo hop será utilizado por todos os VRFs criados pelo SD-WAN Gateway. É necessário configurar o parâmetro do VRF de gestão em /etc/config/gatewayd.
O VRF de gestão é o mesmo VRF utilizado pelo router PE para enviar a pesquisa SLA IP. O SD-WAN Gateway só responderá à pesquisa ICMP se o serviço estiver ativo e se existirem edges ligados ao mesmo. A tabela abaixo explica cada parâmetro que tem de ser definido. Este exemplo tem o VRF de gestão no ID de VLAN 802.1q de 1000.
| modo | QinQ (0x8100), QinQ (0x9100), nenhum, 802.1Q, 802.1ad |
| c_tag | Valor de c-tag para o encapsulamento QinQ ou encapsulamento for802.1Q ID de VLAN 802.1Q |
| s_tag | Valor de s-tag para o encapsulamento QinQ |
| interface | Interface de handoff, tipicamente eth1 |
"vrf_vlan": {
"tag_info": [
{
"resp_mode": 0,
"proxy_arp": 0,
"c_tag": 1000,
"mode": "802.1Q",
"interface": "eth1",
"s_tag": 0
}
]
},
Passo 3: edite /etc/config/gatewayd-tunnel para incluir ambas as interfaces no parâmetro wan. Guarde a alteração.
wan="eth0 eth1"
Remover sub-redes bloqueadas
Por predefinição, o SD-WAN Gateway bloqueia o tráfego para 10.0.0.0/8 e 172.16.0.0/14. Teremos de as remover antes de utilizar este SD-WAN Gateway porque esperamos que o SD-WAN Gateway também envie tráfego para sub-redes privadas. Se não editar este ficheiro, quando tentar enviar tráfego para sub-redes bloqueadas, encontrará as seguintes mensagens em /var/log/gwd.log
2015-12-18T12:49:55.639 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.254, which is a blocked subnet. 2015-12-18T12:52:27.764 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.254, which is a blocked subnet. [message repeated 48 times] 2015-12-18T12:52:27.764 ERR [NET] proto_ip_recv_handler:494 Dropping packet destined for 10.10.150.10, which is a blocked subnet.
[
{
"network_addr": "10.0.0.0",
"subnet_mask": "255.0.0.0"
},
{
"network_addr": "172.16.0.0",
"subnet_mask": "255.255.0.0"
}
]
[ ]
Passo 3: reinicie o processo do SD-WAN Gateway através do reinício de sudo /opt/vc/bin/vc_procmon.
