[GTER] PBR Huawei

Wed Jan 15 10:03:56 -03 2020

Renan, src-nat em CCR não usa alocação dinâmica de portas, isso existe
em Cisco e Huawei que eu saiba, e neste caso vc tem que obter logs
(normalmente via flows) para indentificar qual porta/range de portas
estava em uso por qual ip de origem em dado momento. 

O uso do src-nat funciona da mesma forma, porém eleva-se muito o número
de regras, fazendo assim necessário os jumps.  

A lógica é a mesma do netmat, porém vc que faz todas as regras, eu optei
no meu cenário por pegar os pacotes dos blocos /24, pular para os /27 e
depois para os /32. 

/ip firewall nat
add action=jump chain=srcnat jump-target=100.80.0.0_24
src-address=100.80.0.0/24
...
add action=jump chain=100.80.0.0_24 jump-target=100.80.0.0_27
src-address=100.80.0.0/27
...
add action=jump chain=100.80.0.0_24 jump-target=100.80.0.0_27
src-address=100.80.0.0/27
...
add action=src-nat chain=100.80.0.0_27 protocol=tcp
src-address=100.80.0.0 to-addresses=SEU-IP-PUBLICO1 to-ports=1024-3039
add action=src-nat chain=100.80.0.0_27 protocol=udp
src-address=100.80.0.0 to-addresses=SEU-IP-PUBLICO1 to-ports=1024-3039
add action=src-nat chain=100.80.0.0_27 log=yes log-prefix="IP:
100.80.0.0" src-address=100.80.0.0 to-addresses=SEU-IP-PUBLICO2
add action=src-nat chain=100.80.0.0_27 protocol=tcp
src-address=100.80.0.1 to-addresses=SEU-IP-PUBLICO2 to-ports=3040-5055
add action=src-nat chain=100.80.0.0_27 protocol=udp
src-address=100.80.0.1 to-addresses=SEU-IP-PUBLICO1 to-ports=3040-5055
add action=src-nat chain=100.80.0.0_27 log=yes log-prefix="IP:
100.80.0.1" src-address=100.80.0.1 to-addresses=SEU-IP-PUBLICO2 

mais ou menos assim...  

Em 2020-01-14 18:53, Renan Batista escreveu:

> Nesta outra logica de Jump eu não consegui entender como se consegue
> saber qual assinante estava navegando por determinada porta.  
> 
> Exemplo com netmap: 
> 
> _add action=netmap chain=srcnat out-interface=sfp-sfpplus1 protocol=tcp
> src-address=100.112.96.32/28 to-addresses=X.X.96.32/28
> to-ports=62001-64000_ 
> 
> Ou seja quando chegar uma solicitação me pedindo o log do assinante que
> estava navegando com o IP x.x.96.32 eu peço a porta de origem, se ela
> estiver entre a o range 62001-64000 eu procuro no relatorio do Radius
> qual assinante usava o IP 100.112.96.32, e assim aplico para todos os
> ips mapeados pelas portas.
> 
> Agora neste outro modelo de CGNAT onde as portas são alocadas
> dinamicamente como indicar o assinante? afinal a porta de origem foi
> alocada dinamicamente e pode ter sido usado por qlq um.... 
> 
> Em 14/01/2020 17:41, Davi Nunes de França escreveu:
> 
>> Então vc acredita que netmap prejudica a performance?
>> 
>> Em ter, 14 de jan de 2020 5:32 PM, Fernando Frediani <fhfrediani at gmail.com>
>> escreveu:
>> 
>> Corroboro com o Márcio.
>> 
>> Nunca entendi bem por que o pessoal usa netmap pra fazer CGNAT em CCR.
>> Apesar de funcionar a lógica muda bastante e talvez possa dar margem
>> para ocorrer esses episódios que parecem falta de otimização, mais
>> especificamente falando falta de jumps no lugar certo. Sem os jumps
>> colocados no lugar certo qualquer CPU vai sentar.
>> 
>> Também considero 1:64 demais e pouca porta principalmente para aqueles
>> usuários que tem um uso mais intenso (escritórios ou gamers). 1:32 é o
>> mínimo razoável, na minha visão, para ajudar evitar problemas
>> decorrentes e se traduz em uma boa economia de endereços IPv4 públicos.
>> Claro se você tiver IPv6 100% sendo entregue para os usuários, caso
>> contrário pode não ser o caso.
>> Já vi caso de CCR que não era nem 1072 nem 1036 fazendo muita coisa com
>> as regras bem colocadas.
>> 
>> Huawei nem NE20 nem NE40 não fazem CGNAT, pode esquecer. Não tem segredo
>> nem nada alternativo para ser feito. Simplesmente a arquitetura do
>> hardware não é pra isso.
>> Neste caso coloque o CGNAT em uma caixa separada e dedicada para isso.
>> 
>> Fernando
>> 
>> On 14/01/2020 17:21, Márcio Elias Hahn do Nascimento wrote:
>> 
>> Bom com 1 CCR 1072, estou passando 14G de banda, planos dos mais
>> variados, de 1M a 500M.
>> 
>> CPU no horário de pico é de 22%.
>> 
>> Estou aplicando 1:32, e não uso netmap, src-nat mesmo!!
>> 
>> Aplico alguns jumps para limitar o número de regras que os pacotes
>> batem, e olha que tenho regras nessa CCR, precisamente 49730 regras de
>> NAT!
>> 
>> 1:64 eu acho um pouco exagerado, sai do 1:16 para o 1:32.. o legal dessa
>> técnica de aplicação de CGNAT tantodo Huawei, quando dos ASR da Cisco, é
>> vc poder alocar portas dinamicamente on-demand para os usuários de
>> acordo com a necessidade... sendo assim, vc pode em algum momento ter
>> até mais de 64 clientes atrás do mesmo IPv4 público, e não vai faltar
>> portas... (Claro que depende das políticas de alocação de portas que
>> forem aplicadas a caixa).
>> 
>> Renata, a sua dúvida foi respondida neste mesmo tópico,
>> 
>> Facebook: https://www.facebook.com/outsourceitnow/posts/434853920802173
>> 
>> Linkedin:
> 
> https://www.linkedin.com/pulse/policy-based-routing-para-tr%C3%A1fego-de-cgnat-interfaces-alves-pereira/
> 
> O Evandro deu o mapa do caminho das pedras...
> 
> Em 2020-01-14 12:15, Davi Nunes de França escreveu:
> 
> Aqui é 1036 e é baseado em netmap, bate 80% de processamento. Deve ter
  algo 

>> errado nessa nossa configuração então...
>> 
>> Em ter, 14 de jan de 2020 9:43 AM, Renan Batista <renan at trixnet.com.br>
>> escreveu:
>> 
>> Nossa! aqui uma 1072 e a CPU bate 60%, eu uso CGNAT netmap, qual tipo vc
>> usa, outra coisa vc entrega quantos megas para seus assinantes?
>> 
>> Em 14/01/2020 08:16, Evandro Alves escreveu:
>> 
>> Renan, faço 1/64 no cgnat  em uma 1036 apenas. cpu nunca passou de 15%
>> 
>> On Mon, Jan 13, 2020 at 3:46 PM Renan Batista <renan at trixnet.com.br>
  wrote: 

>> NE faz NAT, me parece que não CGNAT e pelo que o pessoal vem falando na
>> lista colocar na mesma caixa PPPoE + NAT comprometa bastante o
>> desempenho (apesar de ninguém ter quantificado um percentual), agora
>> falando em um ambiente que conheço quando estava trabalhando com apenas
>> uma caixa de CGNAT (uma CCR 1072), onde faço um mapeamento de 1:32 a
>> load CPU chegava a picos de 60% e sabemos que na estrutura das CCR
>> apesar de ter 72 core por algum motivo alguns processos ficam amarrados
>> em alguns cores apenas o que gerava CPUs com 100% e outras com 20% ou
>> 30%, na pratica o que acontecia era que eu tinha uplinks disponiveis,
>> mais meus assinantes sempre reclamavam de lentidao nos horarios de pico,
>> depois que distribui o serviço de CGNAT em 2 CCR1072, o load CPU não
>> passa de 35% e as reclamações de lentidao no periodo da noite sumiram. A
>> thread que levantei aqui é apenas se o NE faz PBR, ou seja, se ele
>> consegue olhar o src-address e decidir para qual gateway ira encaminhar
>> aquele packet, e se sim, como fizeram pois ainda não obtive sucesso em
>> meus testes.
>> 
>> Em 13/01/2020 14:53, Rubens Kuhl escreveu:
>> 
>> On Mon, Jan 13, 2020 at 11:08 AM Vagner Kaefer <
  vagner at empiretelecom.com.br> wrote: 

>> Bom dia pessoal,
>> 
>> A linha NE40 possui uma licença de NAT, mas não deve ser utilizada para
>> CGNAT.
>> 
>> Eu tenho uns valores aqui de capacidade de tráfego/pacotes em caso de
  NAT, 

>> mas em resumo, no melhor dos casos você conseguirá 13.4G de tráfego, se
>> considerar o padrão brasileiro, a caixa vai ficar limitada a uns 5G e
> 2.4K
> 
> clientes, bem longe dos 32k do PPPoE/IPoE e dos 960GB de throughput que
     o

>> equipamento suporta.
>> 
>> Um comentário bem interessante que recebemos foi esse: "CGNAT capacity
     is

>> not equal to Forwarding Capacity.  Usually in a Network we will put
     CGNAT

>> device in a core not in edge network. M2K-B is used in metro or edge
>> network. In core, we have NE40E-X8A and has special board to support
     CGNAT."

>> Em suma: A estrutura da caixa não tem foco em CGNAT, usem o NE40 para
>> borda ou PPPoE/IPoE.
> Mas qual a perda de performance causada por fazer PBR para um caixa de
     NAT,

> sem o próprio NE fazer NAT ?
> 
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
  --
Renan Batista
Gerente TI
Trixnet
--
gter list    https://eng.registro.br/mailman/listinfo/gter

--
Renan Batista
Gerente TI
Trixnet
--
gter list    https://eng.registro.br/mailman/listinfo/gter
  --
gter list    https://eng.registro.br/mailman/listinfo/gter

 --
gter list    https://eng.registro.br/mailman/listinfo/gter

 --
gter list    https://eng.registro.br/mailman/listinfo/gter 

-- 
Att 

Márcio Elias Hahn do Nascimento