Policy Based Routing (PBR)

De ISPUP!
Revisão de 23h10min de 29 de janeiro de 2023 por Gondim (discussão | contribs)
Ir para navegação Ir para pesquisar

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/10 to 100.64.0.0/10 priority 5 lookup main
# ip rule add from 100.64.0.0/22 priority 10 lookup cgnat01
# ip rule add from 100.64.4.0/22 priority 20 lookup cgnat02

Com as regras acima estamos dizendo para o sistema não enviarem para as caixas CGNAT quando origem e destino forem 100.64.0.0/10 e 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/10 to 100.64.0.0/10 lookup main
10:     from 100.64.0.0/22 lookup cgnat01
20:     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 distance=1 gateway=172.20.10.1 routing-mark=cgnat01 
add distance=1 gateway=172.20.10.5 routing-mark=cgnat02
 
/ip route rule 
add action=lookup-only-in-table comment=semcgnat dst-address=100.64.0.0/10 src-address=100.64.0.0/10 table=main
add action=lookup-only-in-table comment=cgnat01 src-address=100.64.0.0/22 table=cgnat01
add action=lookup-only-in-table comment=cgnat02 src-address=100.64.4.0/22 table=cgnat02

PBR no BNG Huawei

Contribuição de um amigo, Ritielle Tobias Fernandes. Um exemplo em Huawei: 

acl name CGNAT-01 number 3001
 rule 10 permit ip source 100.64.0.0 0.0.3.255
#
acl name CGNAT-02 number 3002
 rule 10 permit ip source 100.64.4.0 0.0.3.255
#
acl name ACL-SEM-CGNAT number 3000
 rule 10 permit ip source 100.64.0.0 0.63.255.255 destination 10.0.0.0 0.255.255.255
 rule 20 permit ip source 100.64.0.0 0.63.255.255 destination 172.16.0.0 0.15.255.255
 rule 30 permit ip source 100.64.0.0 0.63.255.255 destination 100.64.0.0 0.63.255.255
 rule 40 permit ip source 100.64.0.0 0.63.255.255 destination 192.168.0.0 0.0.255.255
 rule 50 permit ip source 100.64.0.0 0.63.255.255 destination X.X.X.X 0.0.0.255 (Bloco Publico local)
#
traffic classifier TC-CGNAT-01 operator and
 description DIRECIONA-CGNAT-01
 if-match acl name ACL-CGNAT-01
#
traffic classifier TC-CGNAT-02 operator and
 description DIRECIONA-CGNAT-02
 if-match acl name ACL-CGNAT-02
#
traffic classifier TC-SEM-CGNAT operator and
 if-match acl name ACL-SEM-CGNAT
#
traffic behavior TB-CGNAT-01
 redirect ip-nexthop 172.20.10.1
#
traffic behavior TB-CGNAT-02
 redirect ip-nexthop 172.20.10.5
#
traffic behavior TB-SEM-CGNAT
 description nao passam pelo NAT # Mantem o trafego com rota default para o BGP
#
traffic policy PBR-CGNAT
 share-mode
 classifier TC-SEM-CGNAT behavior TB-SEM-CGNAT precedence 10
 classifier TC-CGNAT-01 behavior TB-CGNAT-01 precedence 20
 classifier TC-CGNAT-02 behavior TB-CGNAT-02 precedence 30
#
traffic-policy PBR-CGNAT inbound global-acl

PBR no BNG Juniper

No Juniper pode ser feito nas queues de upload de cada banda. Abaixo um pequeno trecho de exemplo. 

set policy-options prefix-list BLOCOS_CGNAT01 100.64.0.0/22
set policy-options prefix-list BLOCOS_CGNAT02 100.64.4.0/22

Dentro das queues temos os TERMs que fazem o PBR quando for para os CGNATs. 

set firewall family inet filter QUEUE500M_UP interface-specific
set firewall family inet filter QUEUE500M_UP term CGNAT1 from source-prefix-list BLOCOS_CGNAT01
set firewall family inet filter QUEUE500M_UP term CGNAT1 then policer 500Mbps
set firewall family inet filter QUEUE500M_UP term CGNAT1 then next-ip 172.20.10.1/32
set firewall family inet filter QUEUE500M_UP term CGNAT2 from source-prefix-list BLOCOS_CGNAT02
set firewall family inet filter QUEUE500M_UP term CGNAT2 then policer 500Mbps
set firewall family inet filter QUEUE500M_UP term CGNAT2 then next-ip 172.20.10.5/32
set firewall family inet filter QUEUE500M_UP term PUBLICO then policer 500Mbps
set firewall family inet filter QUEUE500M_UP term PUBLICO then accept

Finalizando

Todo bom BNG que se preze, possuirá uma maneira de aplicar um PBR na caixa. Procure no manual do fabricante, estude e aplique esse recurso para que você possa tirar vantagens e poder projetar melhor sua infraestrutura.

Eu escolhi por não usar o modelo All in One na infraestrutura que ajudei a construir, isso se mostrou escalável e funcionou muito bem. Não estou dizendo que não existem sistemas com essa capacidade, apenas que eu não optaria por usá-los.

Essa documentação foi útil? Compartilhe, divulgue e ajude outras pessoas. Meus contatos podem ser vistos aqui.

Disponível em “https://wiki.ispup.com.br/w/index.php?title=Policy_Based_Routing&oldid=436”