[GTER] PBR Huawei

Wed Jan 15 02:45:42 -03 2020

bom dia.

"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. "

Utilizo este mesmo processo.

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....
Esta também é uma dúvida para mim, quanto ao uso do src-nat no routerOS.
-
Raphael Rodrigues
Eng de Redes/Sistemas
<http://pdscursos.com.br/>http://raphaelisp.com.br/
https://www.instagram.com/raphaelisp.connect/
https://www.facebook.com/raphaelisp

INFORMAÇÕES CONFIDENCIAIS - SIGILO COM PROTEÇÃO LEGAL

As informações contidas nesta mensagem são CONFIDENCIAIS e protegidas pelo
sigilo legal. A divulgação, distribuição, reprodução ou qualquer forma de
utilização deste documento, depende de autorização do emissor.
Caso V. Sa. não seja o destinatário, preposto, ou a pessoa responsável pela
entrega desta mensagem, fica, desde já, notificado que qualquer divulgação,
distribuição ou reprodução é estritamente proibida, sujeitando o infrator
às sanções legais, cíveis e criminais.
Caso esta comunicação tenha sido recebida por engano, favor nos avisar
imediatamente, respondendo esta mensagem.

“Tenha a coragem para seguir o seu coração e sua intuição. Ele, de alguma
forma, já sabe o que você quer se tornar”. Steve Jobs

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
>