[GTER] Servidor PPPoE - Accel-PPP

Thu Nov 30 19:18:56 -02 2017

Cria um tabela de rotas para o cgnat:

cat /etc/iproute2/rt_tables
#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
12    cgnat

No exemplo criei uma tabela de número 12 e nome cgnat.

Coloca um ip na interface com o mikrotik (ou qualquer outro servidor de
nat):

ex:
eth0.10
172.31.0.2/30

Coloca uma rota default na tabela cgnat apontando para o mikrotik:
ip route add table cgnat default nexthop via 172.31.0.1 dev eth0.10

Redireciona a range de ips cgnat para a tabela de rotas cgnat:
ip rule add from 100.64.0.0/10 lookup cgnat

## Mikrotik:

No mikrotik colocar um ip na interface que comunica com o accel:
ether1.10
172.31.0.1/30

No mikrotik também criar uma rota estática para a range cgnat voltar para o
accel:
add distance=1 dst-address=100.64.0.0/10 gateway=172.31.0.2

Agora é só fazer o nat de 100.64.0.0/10 no mikrotik.
/ip firewall nat
add action=src-nat chain=srcnat src-address=100.64.0.0/16
to-addresses=um_ip_publico (trocar essa regra para as regras mais avançadas
de cgnat que registram o log)

2017-11-29 10:26 GMT-02:00 Caiu <caiu at fbnet.com.br>:

> Boa dia HugLeo,
>
> por favor, conte-me mais sobre redirecionar as rotas de nat.
>
> Seria uma dádiva pra mim aqui.
>
>
> Att,
>
> Darlan Ullmann
>
>
>
> Em 29/11/2017 10:05, HugLeo escreveu:
>
>> Dica:
>> rps ativado
>> firewall stateless (se precisar de nat basta redirecionar as rotas de nat
>> pra um mikrotik e fazer por lá,  funciona perfeito)
>>
>> Aguenta muito mais que 2000 sessões.
>> Roda perfeitamente umas 5000 sessões e 4 GB de tráfego e pede por mais.
>>
>> O próprio mikrotik rodando em x86 chega perto disso.
>>
>> 2017-11-28 22:14 GMT-02:00 André Carlim <andre at stubnet.info>:
>>
>> Meu irmão, você não faz a menor ideia do que está falando. Eu tenho
>>> servidores PPPoE com 2000 sessões com controle de banda, cgnat, IPv6,
>>> controle de banda e ospf, com processador core i5 com trânsito de 1.2gbit
>>> em horário de pico que não usa mais que 15% dos núcleos...
>>>
>>> Eu acho que você não tá por dentro do hardware x86...
>>>
>>>
>>>
>>>
>>> Em 28 de novembro de 2017 18:20:36 BRST, Rubens Marins Schner <
>>> rubens.marins at gmail.com> escreveu:
>>>
>>>> 2017-11-28 14:53 GMT-03:00 André Carlim <andre at stubnet.info>:
>>>>
>>>> Antes de mais nada, só quero saber se o amigo aqui já teve
>>>>>
>>>> experiência com
>>>>
>>>>> linux e pppoe em larga escala?
>>>>>
>>>>>
>>>>> Concordo plenamente, se estiver usando placa de rede "realtreco" ou
>>>>> aquelas intel pro/1000! Com boas placas de rede isso é eliminado.
>>>>>
>>>>
>>>> Claro que já é implicito que para isso você vai usar um placa de rede
>>>> "boa".
>>>> O problema não é placa de rede, e sim a velocidade de copia do
>>>> cabeçalho da
>>>> placa de rede para a CPU, e a velocidade que a CPU demora para decidir
>>>> o
>>>> que fazer com o pacote.
>>>>
>>>> Com placas de rede que usam o driver igb ou tg3 é só NÃO usar o
>>>> irqbalance
>>>>
>>>>> e fazer o irq affinity manualmente que vai funcionar perfeitamente!
>>>>>
>>>>> Vai funcionar perfeitamente até o limite de processamento de 1 Core, o
>>>> que
>>>> nesse caso, não é um limite lá muito alto.
>>>>
>>>> Bom, aqui não pude entender mesmo o objetivo do comentário, com um
>>>> pouco de
>>>>
>>>>> tempo qualquer um faz CGNAT (ou seja lá qual for) usando iptables...
>>>>>>
>>>>>> O problema não é saber o comando de Iptables, é a caixa que já esta no
>>>> gargalo fazendo controle de banda, agora precisar fazer NAT, que também
>>>> é
>>>> feito em CPU.
>>>>
>>>> E você não consegue fazer o controle de banda em um core e NAT em outro
>>>> core, depois que setou o CPU affinity já era.
>>>> Até por que o NAT precisa esperar o controle de banda decidir se vai
>>>> transmitir o pacote ou não, antes de operar o mascaramento. Esse baile
>>>> não
>>>> da para dançar em dois cores separados.
>>>> Não dá para fazer a divisão de pacotes por cores, os pacotes da mesma
>>>> conexão precisam sair mais na mesma ordem que chegaram, pacotes fora de
>>>> ordem vai tornar Voip e Jogos online inviaveis.
>>>>
>>>> O problema é Hardware
>>>>
>>>>
>>>> Rubens Marins
>>>> Administrador de Sistemas
>>>> rubens.marins at gmail dot com
>>>>
>>>>
>>>> 2017-11-27 20:46 GMT-03:00 André Carlim <andre at stubnet.info>:
>>>>
>>>> Pessoal sei que é meio contra producente o que vou fazer aqui, mas eu
>>>>
>>>>> limitado a recursos para testar o potencial das ultimas mudanças que
>>>>>
>>>> fiz no
>>>>
>>>>> meu esquema de PPPoE. Alguns clientes grandes que estava atendendo
>>>>>
>>>> acabaram
>>>>
>>>>> migrando para Cisco/Juniper e fiquei na mão! Todavia, queria saber se
>>>>> alguém topa usar e medir o quanto pode ser útil essa estrutura. Eu
>>>>>
>>>> penso na
>>>>
>>>>> faixa que fica entre as CCRs e um Juniper, nos provedor que tem algo
>>>>>
>>>> em
>>>>
>>>>> torno de 6000 ~ 9000 clientes. Sei que com essa quantidade já da pra
>>>>>
>>>> pensar
>>>>
>>>>> nessas caixas, mas acho atrativo o baixo custo que o Debian +
>>>>>
>>>> Accel-PPP
>>>>
>>>>> podem trazer para quem quer atender umas 7000 sessões PPPoE em no
>>>>>
>>>> máximo
>>>>
>>>>> dois servidores (que nem precisa ser servidor mesmo). Eu já tive por
>>>>> algumas vezes experiência de rodar até 2200 sessões PPPoE sobre um
>>>>>
>>>> Core i3
>>>>
>>>>> com uso de processador abaixo de 15% e banda próxima a 1Gbit. Se
>>>>>
>>>> alguém se
>>>>
>>>>> interessar estou a disposição!
>>>>>
>>>>> --
>>>>>
>>>>> Atenciosamente,
>>>>> André Carlim
>>>>> StubNetwork
>>>>> --
>>>>> 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
>>>>
>>> --
>>> Enviado de meu dispositivo Android com Open Mailmail. Desculpe-me pela
>>> brevidade.
>>> --
>>> 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
>