Policy Based Routing (PBR)
Introdução
O PBR (Policy Based Routing) é muito importante na estratégia de crescimento do provedor quando falamos no uso do CGNAT. Já vi diversos provedores fazerem o famoso: All in One onde na mesma caixa colocam a borda com BGP, BNG e CGNAT. Sei que você pode estar pensando em economia financeira e simplicidade na operação, mas pode, na minha opinião e experiência de anos com ISP, estar engessando seu crescimento. Você pode ser pequeno mas precisa pensar como grande. Sempre fui adepto da filosofia KISS (Keep It Simple Stupid), ou seja, sempre manter as coisas o mais simples possível porque quanto mais complexo for seu ambiente, mais difíceis serão os troubleshootings.
Ter as funções bem separadas e estruturadas na sua Operação, pode facilitar em muito seu crescimento e em novas estratégias. Por exemplo: tenha bem definido quem fará sua borda, quais equipamentos serão seus BNGs (Broadband Network Gateway), e suas caixas de CGNAT (Carrier-Grade Network Address Translation). Alguns utilizam o modelo All in One em equipamentos que nem foram construídos para essa finalidade e acabam colhendo diversos problemas em sua Operação.
Pensando na separação de funções, utilizaremos um recurso chamado PBR para auxiliar no funcionamento do roteamento e podermos separar nossos serviços.
Diagrama exemplo
Objetivo
Nesse artigo vamos ter exemplos de configuração fazendo PBR e encaminhando os pacotes que vierem do prefixo 100.64.0.0/22 para o CGNAT01 em 172.20.10.1 e outro PBR fazendo o mesmo com os pacotes de origem 100.64.4.0/22 e encaminhando para o CGNAT02 em 172.20.10.5. Perceba que dessa forma podemos crescer e expandir nossa rede de maneira mais estruturada e sem sobrecarregar os recursos de um determinado ativo de Rede. Foi pensando desta maneira, que o ISP que participei da administração entre 2003 e 2021, alcançou a marca de 42.000 assinantes e isso com estabilidade, qualidade, segurança e resiliência.
Podemos pensar em outras utilidades também para esse cenário como por exemplo: se tiver acontecendo um ataque DDoS pequeno para alguns IPs do 198.51.100.0/27, você poderia desviar os clientes da caixa CGNAT01 para a caixa CGNAT02. Logicamente que a caixa precisará ter recursos IP, capacidade de Rede e hardware, para suportar os clientes desviados naquele momento de crise.
PBR no BNG GNU/Linux
O PBR aqui é bem simples e pode ser útil em BNGs que usam GNU/Linux como por exemplo um sistema ACCEL-PPP que trabalha com IPoE (Internet Protocol over Ethernet) no lugar de PPPoE (Point-to-Point Protocol over Ethernet) que é convencionalmente mais utilizado em nosso ramo. O exemplo abaixo é baseado no nosso diagrama; entenda que no Linux temos uma FIB (Forwarding Information Base) principal chamada de main e que é sempre examinada quando existe a necessidade de encaminhar um pacote para algum destino. O que faremos é criar 2 novas FIBs que serão tabelas de rotas independentes da tabela main e criaremos as regras que encaminharão os pacotes conforme o prefixo de origem. Abaixo criaremos as tabelas nomeadas de cgnat01 e a cgnat02; onde os valores 200 e 201 serão identificadores numéricos das tabelas e deverão estar abaixo de 253, porque 255, 254, 253, 0 e 1 são reservados.
# echo 200 cgnat01 > /etc/iproute2/rt_tables.d/cgnat01.conf # echo 201 cgnat02 > /etc/iproute2/rt_tables.d/cgnat02.conf
Estas tabelas cgnat01 e cgnat02 ainda não existem, porque não existe qualquer rota criada nelas ainda. Então vamos adicionar uma rota default.
# ip route add default via 172.20.10.1 dev ens19 table cgnat01 # ip route add default via 172.20.10.5 dev ens20 table cgnat02
Para vermos o conteúdo dessas tabelas:
# ip route list table cgnat01 default via 172.20.10.1 dev ens19 # ip route list table cgnat02 default via 172.20.10.5 dev ens20
Nesse momento temos 2 tabelas FIB novas criadas, uma rota default em cada e prontas para serem usadas. Por enquanto elas não servem para nada, porque por padrão todos os pacotes são examinados na tabela main do sistema. Para que mudemos esse comportamento precisamos criar as rules com suas prioridades. Vejamos quais rules existem por padrão no sistema.
# ip rule 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
O valor na esquerda é o priority (prioridade) e quanto menor ele for, maior será a prioridade. Por padrão quando criamos uma rule nova, o sistema já seta como priority um valor menor que 32766 mas vamos fazer nossas regras setando nossas prioridades.
# ip rule add from 100.64.0.0/22 priority 5 lookup cgnat01 # ip rule add from 100.64.4.0/22 priority 10 lookup cgnat02
Com as regras acima estamos dizendo para o sistema que quando vieram pacotes origem do prefixo 100.64.0.0/22, que seja examinada a tabela cgnat01 para o caso de roteamento desses pacotes e quando forem origem 100.64.4.0/22 que seja examinada a tabela cgnat02. Vamos ver como ficaram nossas rules.
# ip rule 0: from all lookup local 5: from 100.64.0.0/22 lookup cgnat01 10: from 100.64.4.0/22 lookup cgnat02 32766: from all lookup main 32767: from all lookup default
Para remover a regra basta trocar o add pelo del no comando, que a regra será removida. Não esqueçam que nas caixas CGNATs precisa existir uma rota de retorno para cada prefixo, senão nada funcionará e já vi isso acontecer em muitos casos.
Um outro detalhe interessante é que esse tipo de abordagem usando PBR não causa problemas quando habilitamos o uRPF (Unicast Reverse Path Forwarding) em modo strict no BNG. Mas abordagens que usam marcação de pacotes para forçarem encaminhamentos, essas sim costumam dar problemas e inclusive consumo de processamento sem necessidade. O PBR é mais efetivo e leve para o sistema.
PBR no BNG Mikrotik
No RouterOS da Mikrotik é bem simples também.
/ip route add check-gateway=ping distance=1 gateway=172.20.10.1 routing-mark=cgnat01 add check-gateway=ping distance=1 gateway=172.20.10.5 routing-mark=cgnat02 /ip route rule add action=lookup-only-in-table src-address=100.64.0.0/22 table=cgnat01 add action=lookup-only-in-table src-address=100.64.4.0/22 table=cgnat02