Mudanças entre as edições de "CGNAT Bulk Port Allocation com DPDK"
Linha 60: | Linha 60: | ||
<code>'''# set interfaces dataplane dp0p2s0f1 bond-group dp0bond1'''</code> | <code>'''# set interfaces dataplane dp0p2s0f1 bond-group dp0bond1'''</code> | ||
+ | |||
+ | <code>'''# set protocols static route6 '::/0' next-hop '2804:XXXX:XXXX:faca::3''''</code> | ||
Estamos definindo 2 bondings, sendo 1 pra cada interface de rede. Não faça bonding entre portas de interfaces de rede diferentes, isso prejudica o cpu affinity. Os nomes utilizados também possuem uma certa regra de criação e que pode ser vista digitando um "?" por exemplo: | Estamos definindo 2 bondings, sendo 1 pra cada interface de rede. Não faça bonding entre portas de interfaces de rede diferentes, isso prejudica o cpu affinity. Os nomes utilizados também possuem uma certa regra de criação e que pode ser vista digitando um "?" por exemplo: | ||
Linha 69: | Linha 71: | ||
<code>'''> <dpFbondN> Bonding interface name'''</code> | <code>'''> <dpFbondN> Bonding interface name'''</code> | ||
− | As 5 primeiras linhas criamos os bondings, definimos o mode lacp e colocamos os IPs. As 4 últimas linhas dizemos quais interfaces de rede fazem parte desse bonding. | + | As 5 primeiras linhas criamos os bondings, definimos o mode lacp e colocamos os IPs. As 4 últimas linhas dizemos quais interfaces de rede fazem parte desse bonding e a última linha definindo o gateway default para o meu acesso IPv6 ao sistema. |
== <big>Configuração do iBGP:</big> == | == <big>Configuração do iBGP:</big> == |
Edição das 17h42min de 9 de novembro de 2020
Objetivo:
Mostrar a configuração do projeto DANOS para funcionar como um CGNAT Bulk Port Allocation utilizando um hardware de baixo custo e proporcionando uma enorme economia de IPv4 público, pois trabalha com alocação de portas TCP/UDP dinamicamente e não da forma Determinística onde pré-fixamos uma quantidade de portas por assinante. Temos que ter sempre em mente que a implantação e o uso do IPv6 é importantíssimo, porque o CGNAT não irá resolver todos os problemas da Internet. O CGNAT ajudará à manter a rede funcionando enquanto o IPv6 não for 100% utilizado no Mundo. O fato do projeto DANOS utilizar o DPDK, permite que consigamos usar um equipamento mais simples para gerenciar tráfegos bem maiores em Gbps/PPS.
Diagrama:
O BNG é o responsável por gerenciar as conexões PPPoE/IPoE e no nosso artigo fará o encaminhamento de todos os pacotes do pool CGNAT 100.64.0.0/10 via PBR (Policy Based Routing) para a caixa DANOS CGNAT. O DANOS CGNAT estará conectado via iBGP com o Router Borda e fará a tradução e alocação dinâmica das portas TCP/UDP usando como exemplo de saída o prefixo 198.51.100.0/24.Clientes conectados no BNG com IPv4 público e IPv6 não devem ser encaminhados para a caixa CGNAT.
Teremos uma rede lógica 192.168.254.0/24 entre os BNGs e o DANOS CGNAT e outra rede lógica 10.69.0.8/30 entre o DANOS CGNAT e o Router Borda. Usaremos os IPs das loopbacks para fecharmos o iBGP. O iBGP está sendo fechado somente de um lado para facilitar o artigo, mas cabe à você decidir a melhor forma de implementar em seu cenário.
Também usaremos nessa configuração um bonding (LACP) de duas portas de 10GbE para entrada de dados provenientes do Router Borda e outro bonding também com duas portas de 10GbE para a saída do tráfego em direção aos BNGs.
Embora esteja no diagrama, não falaremos sobre BNG e nem o Router Borda nesse artigo e por isso deve-se estudar como fazer o PBR em seu equipamento concentrador e também a configuração do iBGP no seu router pois será muito importante para o funcionamento da nossa caixa CGNAT.
Você pode adicionar outras caixas CGNAT basta seguir a mesma lógica apresentada aqui nesse artigo.
Descritivo sobre o DANOS:
É um projeto desenvolvido pelo pessoal da AT&T, que está atualmente na versão 2009, que utiliza o Vyatta como interface de configuração. A syntax me lembra bastante a configuração de um JunOS, possui diversos recursos semelhantes como commit, commit-confirm, validate para validar uma alteração dentre outras características. Por baixo do capô temos um sistema GNU/Linux Debian 10, Linux Kernel 5.4, FRR 7.3.1 e DPDK 19.11. O projeto possui utilidade inclusive para roteamento mas nesse artigo falaremos sobre CGNAT. Embora o sistema seja um Debian, não é disponibilizado uma atualização via apt, pois poderia quebrá-lo já que este possui partes não Debian incluídas no sistema como o DPDK. A atualização pode ser feita sempre que sai uma nova ISO do DANOS, através de comandos simples e salvando sua configuração atual.
Equipamento utilizado no artigo e em produção atualmente:
- Dell PowerEdge R230 - Quad Core Intel(R) Xeon(R) CPU E3-1240 v6 @ 3.70GHz.
- 16G ram.
- 2x Intel X520-SR2.
- SSD 120Gb.
Dados estatísticos desse equipamento em produção:
Atualmente passando 24Gbps agregado com mais de 1.5Mpps. Esse sistema tem 382 IPv4 públicos, 9980 clientes utilizando e mais de 50% dos IPs públicos ainda livres no CGNAT. Como o sistema utiliza DPDK, não temos como acompanhar visualmente a utilização dos processadores pois o dataplane ocupa todos eles ou quase todos durante seu uso mas essa é uma característica dele. Por isso temos que observar o comportamento do tráfego e erros que possam aparecer nas portas da switch e perdas de pacotes. Dessa forma estamos documentando o hardware utilizado em produção e quanto está suportando para usarmos de referência futura:
Instalação do DANOS:
Não vou falar sobre a instalação do sistema porque é extremamente simples. Não tem muitas opções durante a instalação, é feita através de um simples boot com um pendrive já com a ISO nele.
O passo à passo da instalação pode ser vista aqui. Basicamente é iniciar o boot e ao final dele executar: install image e responder as perguntas. Depois disso vamos para o nosso "mão na massa".
Começando a configuração:
Bem a primeira coisa é colocarmos os IPs nas interfaces para inclusive podermos acessar remotamente via ssh e também habilitar o serviço ssh. Vou utilizar uma configuração com IPv6 para fazer meu acesso remoto à esse sistema. Se você tiver outra interface reconhecida pelo sistema, você pode configurar um IP de gerência nela também e acessar por ali. No DANOS nem todas as interfaces de rede são reconhecidas e por isso você precisa consultar essa página e checar as suportadas. Também vamos configurar o bonding antes de configurarmos os IPs:
Após se logar com o usuário e senha que escolheu na instalação, basta executar o comando abaixo e passar os sets. Lembrando que os IPs que estou utilizando você deve alterar para o seu ambiente.:
$ configure
# set interfaces bonding dp0bond0 address '2804:XXXX:XXXX:faca:192:168:255:2/64'
# set interfaces bonding dp0bond0 address 10.69.0.10/30
# set interfaces bonding dp0bond0 mode lacp
# set interfaces bonding dp0bond1 address 192.168.254.1/24
# set interfaces bonding dp0bond1 mode lacp
# set interfaces dataplane dp0p1s0f0 bond-group dp0bond0
# set interfaces dataplane dp0p1s0f1 bond-group dp0bond0
# set interfaces dataplane dp0p2s0f0 bond-group dp0bond1
# set interfaces dataplane dp0p2s0f1 bond-group dp0bond1
# set protocols static route6 '::/0' next-hop '2804:XXXX:XXXX:faca::3'
Estamos definindo 2 bondings, sendo 1 pra cada interface de rede. Não faça bonding entre portas de interfaces de rede diferentes, isso prejudica o cpu affinity. Os nomes utilizados também possuem uma certa regra de criação e que pode ser vista digitando um "?" por exemplo:
# set interfaces bonding ?
Possible Completions:
> <dpFbondN> Bonding interface name
As 5 primeiras linhas criamos os bondings, definimos o mode lacp e colocamos os IPs. As 4 últimas linhas dizemos quais interfaces de rede fazem parte desse bonding e a última linha definindo o gateway default para o meu acesso IPv6 ao sistema.
Configuração do iBGP:
Vamos definir nosso endereço de loopback para usar no nosso iBGP com o Router Borda e setar uma rota apontando pro IP da loopback do Router Borda:
# set interfaces loopback lo address 186.xxx.xxx.163/32
# set protocols static route 186.xxx.xxx.160/32 next-hop 10.69.0.9
Agora vamos definir uma policy prefix-list para o prefixo que vamos anunciar no iBGP e outra prefix-list de rota default que só aceitaremos vindo do Router Borda:
# set policy route prefix-list bloco-publico rule 5 action permit
# set policy route prefix-list bloco-publico rule 5 prefix 198.51.100.0/24
# set policy route prefix-list rota-default rule 5 action permit
# set policy route prefix-list rota-default rule 5 prefix 0.0.0.0/0
Definição do policy route-map que usaremos:
# set policy route route-map router-IN rule 5 action permit
# set policy route route-map router-IN rule 5 match ip address prefix-list rota-default
# set policy route route-map router-IN rule 10 action deny
# set policy route route-map router-OUT rule 5 action permit
# set policy route route-map router-OUT rule 5 match ip address prefix-list bloco-publico
# set policy route route-map router-OUT rule 10 action deny
O que queremos é anunciar o prefixo público 198.51.100.0/24 para o Router e só aceitar receber dele o prefixo 0.0.0.0/0 assim:
# set protocols bgp 53XXX address-family ipv4-unicast network 198.51.100.0/24
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 address-family ipv4-unicast route-map export router-OUT
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 address-family ipv4-unicast route-map import router-IN
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 remote-as 53XXX
# set protocols bgp 53XXX neighbor 186.xxx.xxx.160 update-source lo
# set protocols bgp 53XXX parameters router-id 186.xxx.xxx.163