Este documento fornece instruções sobre como atualizar o gateway de parceiro do VMware da versão 3.3.2 ou 3.4 para a versão 4.0.
O aplicação do SD-WAN Gateway inclui as seguintes alterações na versão 4.0:
- Um novo layout do disco do sistema baseado em LVM para permitir uma maior flexibilidade na gestão do volume
- Uma nova versão de kernel
- Pacotes de SO base novos e atualizados
- Proteção de segurança melhorada com base nas referências do centro de segurança da Internet
- ifupdown foi depreciado a favor de https://netplan.io/
- ifup e ifdown já não estão disponíveis
- A configuração da rede está agora em /etc/netplan vs /etc/network/
- etc/network/ifup.d e /etc/network/ifdown.d já não funcionam. As localizações do distribuidor de rede devem ser utilizadas /usr/lib/networkd-dispatcher (dormant.d, no-carrier.d, off.d, routable.d)
- Alterações substanciais no cloud-init. Os scripts de implementação do cloud-init devem ser revistos e testados quanto à compatibilidade
- As net-tools (ifconfig, netstat, etc) são consideradas “depreciadas” e podem ser removidas nas versões futuras
Configuração da rede
ifupdown foi depreciado a favor de https://netplan.io/. A configuração da rede foi movida de /etc/network to /etc/netplan.
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
Cloud-init
O Cloud-init foi atualizado para a versão 20.2. Poderá encontrar mais informações sobre o cloud-init aqui: https://cloudinit.readthedocs.io/en/stable/index.html
Exemplo 1: simples
metadados:
instance-id: vcg1
local-hostname: vcg1
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
Exemplo 2: configuração de rede de novo estilo (ficheiro configuração da rede)
instance-id: vcg1 local-hostname: vcg1
#cloud-config
hostname: vcg1
password: Velocloud123
chpasswd: {expire: False}
ssh_pwauth: True
ssh_authorized_keys:
- ssh-rsa … rsa-key
velocloud:
vcg:
vco: demo.velocloud.net
activation_code: F54F-GG4S-XGFI
vco_ignore_cert_errors: false
runcmd:
- 'echo “Welcome to VeloCloud”'
Exemplo 1 de configuração da rede:
version: 2
ethernets:
eth0:
addresses:
- 192.168.152.55/24
gateway4: 192.168.152.1
nameservers:
addresses:
- 192.168.152.1
eth1:
addresses:
- 192.168.151.55/24
gateway4: 192.168.151.1
nameservers:
addresses:
- 192.168.151.1
Exemplo 2 de configuração da rede:
NOTA: se várias interfaces estiverem presentes no gateway e for necessário que uma interface esteja selecionada como interface preferida para o gateway predefinido, a configuração abaixo (com o valor da métrica) poderá ser utilizada para selecionar a interface correta.
version: 2
ethernets:
eth0:
addresses: [192.168.82.1/24]
eth1:
addresses: [70.150.1.1/24]
routes:
- {metric: 1, to: 0.0.0.0/0, via: 70.150.1.254}
eth2:
addresses: [70.155.1.1/24]
routes:
- {metric: 2, to: 0.0.0.0/0, via: 70.155.1.254}
Net-tools
Os utilitários de net-tools como ifconfig, netstat, caminho, etc. são considerados “depreciados” As substituições sugeridas pelas net-tools são apresentadas na tabela abaixo. Estes comandos apresentam apenas informações para o anfitrião Linux e não para a rede de sobreposição SD-WAN. NOTA: para obter mais informações, digite: man ip.
| Utilitários de net-tools antigos | Novos utilitários de net-tools correspondentes |
|---|---|
| arp | ip n (ip vizinho) |
| ifconfig | ip a (endereço ip), ligação ip, ip-s (estatísticas ip) |
| nameif | ligação ip, ifrename |
| netstat | ss, caminho ip (para netstat-r), ligação ip-s (para netstat -i), ip maddr (para netstat-g) |
| caminho | ip r (caminho ip) |
Saída de comando de amostra para utilitários de net-tools
A saída da amostra é a confirmação de que o comando foi realizado com sucesso. As saídas de comando de amostra para ip n (ip vizinho), ip a (endereço ip) e ligação ip são mostradas abaixo.
root@SS-gateway-1:~# ip n 192.168.0.100 dev eth2 lladdr 00:50:56:84:85:d4 REACHABLE 192.168.0.250 dev eth2 lladdr 00:50:56:84:97:66 REACHABLE 13.1.1.2 dev eth0 lladdr 00:50:56:84:e7:fa REACHABLE root@SS-gateway-1:~#
root@SS-gateway-1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 4096
link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff
inet 13.1.1.1/24 brd 13.1.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:a009/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff
inet 101.101.101.1/24 brd 101.101.101.255 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:a6ab/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.201/24 brd 192.168.0.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe84:bc75/64 scope link
valid_lft forever preferred_lft forever
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 4096
link/none
inet 169.254.129.1/32 scope global gwd1
valid_lft forever preferred_lft forever
inet6 fe80::27d5:9e46:e7f7:7198/64 scope link stable-privacy
valid_lft forever preferred_lft forever
root@SS-gateway-1:~#
root@SS-gateway-1:~# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 4096
link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff
6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 4096
link/none
root@SS-gateway-1:~#
Considerações de atualização
Devido a alterações substanciais no layout do disco e nos ficheiros do sistema, não é possível uma atualização no local, desde as versões mais antigas até à versão 4.0. A migração exigirá a implementação de novos sistemas de SD-WAN Gateway 4.0 e sistemas de desmantelamento que executam códigos mais antigos.
No caso de SD-WAN Gateways VPN ou SD-WAN Gateways NAT com endereços IP públicos conhecidos, siga o procedimento abaixo se o IP público do SD-WAN Gateway tiver de ser preservado.
- Inicie o novo sistema SD-WAN Gateway com base na imagem da versão 4.0. Consulte o guia de implementação da sua plataforma para obter mais informações (Procedimentos de instalação do gateway).
- Desligue o antigo sistema SD-WAN Gateway. Inative o SD-WAN Gateway VM antigo (quer executando o comando
“sudo poweroff”na consola CLI ou desligando-se das opções disponíveis do Hipervisor). - Migre o IP público para o novo sistema: atualize o registo NAT para apontar para o novo sistema SD-WAN Gateway ou configure o IP público na nova interface de rede do SD-WAN Gateway. Implemente o novo gateway com os exemplos Cloud-int fornecidos acima utilizando o mesmo endereço IP que o SD-WAN Gateway anterior.
- Obtenha a chave de ativação no registo do SD-WAN Gateway existente no SD-WAN Orchestrator (conforme descrito nos passos abaixo).
- No SD-WAN Orchestrator, selecione Gateways no painel de navegação esquerdo.
- No ecrã Gateways, clique num SD-WAN Gateway para o selecionar.
- No ecrã do SD-WAN Gateway escolhido, clique na seta para baixo ao lado do nome do SD-WAN Gateway para abrir a caixa de informações.
- A chave de ativação está localizada na parte inferior da caixa de informações, conforme apresentado na imagem abaixo.
- Defina a seguinte propriedade do sistema “gateway.activation.validate.deviceId” como Falso (False), conforme apresentado na imagem abaixo. Ser necessário, consulte a secção Propriedades do sistema no guia do operador do VMware SD-WAN para obter mais informações.
- Reative o novo sistema SD-WAN Gateway: na consola da CLI, execute:
“sudo /opt/vc/bin/activate.py -s <vco_address> <activation_code>” - Restaure a seguinte propriedade do sistema “gateway.activation.validate.deviceId” para o valor original (se necessário).
O SD-WAN Gateway está agora registado e pronto para receber uma ligação dos Edges.
Saída de exemplo de ativação
root@gateway/opt/vc# /opt/vc/bin/activate.py FLM6-CSV6-REJS-XFR5 -i -s 169.254.8.2
Ativação realizada com sucesso, VCO anulado para 169.254.8.2 root@SS1-gateway-2:/opt/vc#
SD-WAN Gateways sem IPs públicos conhecidos
Esta secção é apenas para SD-WAN Gateways sem um IP público conhecido, como, por exemplo, SD-WAN Gateways VPN. Se este cenário se aplicar, siga o procedimento abaixo.
- Inicie um novo sistema SD-WAN Gateway. Se necessário, consulte o guia de implementação da sua plataforma (Procedimentos de instalação do gateway).
- Ative um novo sistema SD-WAN Gateway.
- Adicione um novo SD-WAN Gateway ao conjunto de SD-WAN Orchestrator SD-WAN Gateway. Consulte a secção “Gestão de gateway” no guia do operador do VMware SD-WAN para obter mais detalhes.
- O SD-WAN Gateway está agora registado e pronto para receber uma ligação dos Edges.
- Retire o SD-WAN Gateway antigo do conjunto de SD-WAN Orchestrator SD-WAN Gateway. Consulte a secção “Gestão de gateway” no guia do operador do VMware SD-WAN para obter mais informações.
- Desative a antiga VM do SD-WAN Gateway. (Retire o registo do SD-WAN Gateway do SD-WAN Orchestrator e desative a instância de VM).
Obtenção da chave de ativação do gateway via API
Para implementar utilizando o método API, utilize o seguinte: “network/getNetworkGateways”
Resposta de amostra:
{"jsonrpc":"2.0","result":[{"id":1, "activationKey":"69PX-YHY2-N5PZ-G3UW … Configurar a interface de handoff no dataplane
Configuração da rede do VMware SD-WAN Gateway
No exemplo com a figura abaixo (handoff de VRF/VLAN para PE), presumimos que eth0 é a interface virada para a rede pública (Internet) e eth1 é a interface virada para a rede interna (cliente VRF através do PE). A configuração de peering 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.
