[GTER] PBR Huawei

[Arthur Bernardes]

Foi esclarecedor, Davi. Muito obrigado.Enviado do meu smartphone Samsung Galaxy.
-------- Mensagem original --------De : Davi Nunes de França <davi.nunes at gmail.com> Data: 14/01/2020  18:40  (GMT-03:00) Para: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br> Assunto: Re: [GTER] PBR Huawei 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 umaunica 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-64000Essa linha vai fazer com que o ip 100.112.96.32  seja traduzido para o ipX.X.96.32 especificamente nas portas de origem  62001-64000. TODAS asportas 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.33com 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 apontapara 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