[GTER] PBR Huawei
Fernando Frediani
fhfrediani at gmail.com
Tue Jan 14 17:32:29 -03 2020
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
>
More information about the gter
mailing list