[GTER] PBR Huawei

Wed Jan 15 11:06:58 -03 2020

Errata do meu texto:

"Nos modelos de CGNAT que uso com netmap no Mikrotik, para cada /19
privado( em 1:64 ) consigo 192 regras com jump.

Nos testes que fiz, é bem mais eficiente que o modelo com src-nat. Em um
dos cenários de produção aqui conseguimos 16 a 18gb agregados com pico de
CPU em 20% e média de CPU em 9%, é uma 1072 em bonding ( 3 portas de 10Gb )
e a mesma com uptime de 162 dias até o momento."

Pronto.

Em qua., 15 de jan. de 2020 às 10:42, Davi Nunes de França <
davi.nunes at gmail.com> escreveu:

> Então eu vou reescrever o meu CGNat baseado em SRC e comparar o desempenho.
> Eu conheço CCR1036 configurada com netmap que não passa de 16% de CPU...
>
> Enfim, vou comparar o desempenho da Mesma CCR com as duas técnicas pra
> comparar o desempenho e posto o resultado mais tarde.
>
>
> ---------------------------------------------------------
> Atenciosamente,
> *Davi Nunes*
> *Tecnologia da Informação*
>
>
> Em qua., 15 de jan. de 2020 às 10:07, Márcio Elias Hahn do Nascimento <
> marcio at sulonline.net> escreveu:
>
> > Exatamente Davi,
> >
> > agora por que o pessoal usando netmap reporta um uso tão alto de CPU,
> > quando usando src-nat não tenho o mesmo consumo?
> >
> > E sim, o número de regras quando usado src-nat é expressivo, escreve-las
> > a mão está fora de cogitação, tem que usar algum script/software para
> > gerar essas regras...
> >
> > Em 2020-01-14 19:40, Davi Nunes de França escreveu:
> >
> > > Netmap aloca as portas dinamicamente somente se vc não especificar um
> > range.
> > >
> > > A técnica do netmap é mais organizada porque vc só vai precisar de uma
> > > unica linha para cada GRUPO de portas.
> > >
> > > Considere esse seu exemplo mesmo:
> > > src-address=100.112.96.32/28 to-addresses=X.X.96.32/28 portas
> > 62001-64000
> > >
> > > Essa linha vai fazer com que o ip 100.112.96.32  seja traduzido para o
> ip
> > > X.X.96.32 especificamente nas portas de origem  62001-64000. TODAS as
> > > portas deste range especifico são do IP   100.112.96.32.
> > > Em consequência, o ip  100.112.96.33 será traduzido para o ip
> X.X.96.33
> > > com o MESMO range de portas.
> > > Isso se repete até percorrer todos os ips do bloco.
> > >
> > > Então na próxima regra vc simplesmente altera o range de portas e
> aponta
> > > para o próximo /28 privado.
> > > Deu pra entender?
> > >
> > > ---------------------------------------------------------
> > > Atenciosamente,
> > > *Davi Nunes*
> > > *Tecnologia da Informação*
> > >
> > > Em ter., 14 de jan. de 2020 às 17:53, Renan Batista <
> > renan at trixnet.com.br>
> > > 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
> >
> > --
> > Renan Batista
> > Gerente TI
> > Trixnet
> > --
> > 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
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>