[GTER] Firewall no ASN

Thu Sep 20 14:36:15 -03 2018

Aqui as queues são feitas nas CCRs mesmo mas com o conntrack habilitado 
a performance cai e começa à ter problemas inclusive com perdas. Eu sei 
porque passamos já por isso e resolvemos não usar mais e tem funcionado 
muito bem.
Hoje estamos tranquilos já tive caixa com 2200 assinantes conectados e 
sem problema mas preferimos manter na média dos 2000.
O dia que tirarmos as queues das caixas aí você pode ter certeza que vou 
colocar pelo menos uns 10.000 conectados numa mesma caixa rsrsrsrs

Em 20/09/2018 09:05, Douglas Fischer escreveu:
>   Quem mata a performance da caixa de verdade não é nem tanto ACL, Firewall,
> Contrack...
>
> Para conseguir colocar esses número de sessões/PPS/Banda nessas caixas deve
> estar sem filas...
>
> Controle de banda todo por conta da OLT?
> Integrou sistema de Gestão na definição da porta na OLT?
>
> Teve um brasiguaio que me disse que tem um sistema de gestão milagroso que
> faz esse provisionamento lindamente.
> Estou curioso!
>
> Em qui, 20 de set de 2018 às 07:16, Marcelo Gondim <gondim at bsdinfo.com.br>
> escreveu:
>
>> Oi Douglas,
>>
>> Então aqui em uma das cidades que atendemos, a principal tenho 6 CCRs
>> sendo 5 com 2000 assinantes conectados e planos que variam entre 10Mbps
>> e 50Mbps. Nessa cidade o tráfego total no pico é de quase 9Gbps. Tráfego
>> em cada CCR dessa perto dos 2Gbps. Uma outra CCR aqui só para clientes
>> corporativos. Aqui trabalhamos para que o IPv6 seja o mais adotado
>> possível pois nossos técnicos na instalação do assinante habilitam o
>> dual stack. O novo sistema que estamos usando inclusive o router que
>> levamos para o assinante já se auto provisiona e configura IPv4 e IPv6
>> sem intervenção do técnico. Para nós ficou muito melhor montar um
>> servidor Linux com 2 interfaces Intel X520-SR2 com 4 portas de 10GbE e
>> direcionar apenas os clientes de CGNAT (100.64.0.0/10) para ele. Nosso
>> objetivo aqui é um dia nem precisar mais do CGNAT e por isso contamos
>> com a intensificação do uso do IPv6. Tudo é uma questão de planejamento.
>> Como nós aqui fazemos FTTH, o router colocado no assinante é de nossa
>> responsabilidade e com o recurso de auto provisionamento, acreditamos
>> que cada vez mais o CGNAT será menos utilizado e não o contrário.  :)
>> Veja eu tenho 1 servidor de CGNAT atendendo 5 CCRs e não 1 pra cada CCR.
>>
>> Uma outra cidade que atendemos aqui o tráfego é menor, 6Gbps e só de
>> CGNAT o consumo é de uns 300Mbps. Nessa cidade são 5 CCRs e o restante
>> dos acessos são IPv4 público e IPv6 e também fazemos a mesma coisa, um
>> Linux fazendo o papel de CGNAT sendo que com 1 Intel X520-SR2.
>>
>> Mas é como você colocou, cada um faz a abordagem que melhor se enquadra
>> ao seu cenário sem aquilo de certo ou errado, apenas a maneira que acha
>> melhor.
>>
>> Em 19/09/2018 16:29, Douglas Fischer escreveu:
>>> Opa Marcelo!
>>> Eu pessoalmente não gosto dessa metodologia de separar o CG-NAT do B-RAS.
>>>
>>> Prefiro tratar todas essas questões de filtragem e CG-NAT no próprio
>> B-RAS.
>>> Perder um pouco em performance, ganha em resiliência e escalabilidade.
>>>
>>>
>>> Falando de CCR, jogando CG-NAT no B-RAS(PPPoE server) você acaba
>> "perdendo"
>>> um pouco de capacidade nominal em número de clientes em banda.
>>> Se conseguia colocar 1500-1600 clientes, vai passar a colocar uns
>>> 1100-1200(talvez nem isso dependendo do perfil de cliente).
>>>
>>> Mas se estiver considerando um cenário com 2 B-RAS com 1500 clientes,
>>> e precisaria de uma 3ª e 4ª caixas só para fazer CG-NAT e sua respectiva
>>> redundância...
>>> Pegue essas 4 caixas e coloque as 4 para fazer B-RAS+CG-NAT+Filtragens
>>> simples.
>>> Isso dá 750 clientes por caixa, ou 1000 clientes em caso de falha de uma
>>> das caixas...
>>>
>>> Pro CG-NAT, já vai ter que está com o Contrack ligado mesmo!
>>> Então fazer algumas filtragens(Ex.: TCP/25, SSDP, etc) ali, não vai te
>>> tomar tantos ciclos de processamento a mais do que já está usando...
>>> (FastTrack pode ajudar bem a by-passar algumas coisas. RAW também.)
>>>
>>>
>>>
>>>
>>> Em ter, 18 de set de 2018 às 22:34, Marcelo Gondim <
>> gondim at bsdinfo.com.br>
>>> escreveu:
>>>
>>>> Essa abordagem que o Rubens colocou é a melhor mesmo. Aqui usamos assim:
>>>>
>>>>
>>>> BRAS ----- CGNAT ----- Router/Firewall --- Borda
>>>>     |                                      |
>>>>     +------------------------------+
>>>>                 IPv6
>>>>
>>>> Em 18/09/2018 22:16, Rubens Kuhl escreveu:
>>>>> O recomendável é um terceiro equipamento entre esses dois, em
>>>> configuração
>>>>> não redundante.
>>>>>
>>>>> BRAS - Firewall - Borda
>>>>> +------------------------+
>>>>>
>>>>> Essa conexão direta entre BRAS e Borda é a que já existe hoje, e seria
>>>>> contingência caso o firewall pife.
>>>>> Dá para fazer isso em L2 ou L3 à sua escolha... se for L2 com
>>>> spanning-tree
>>>>> de redundância, se for L3 com OSPF de redundância. Se for L2 com
>> firewall
>>>>> bridge, se for L3 com firewall roteado.
>>>>>
>>>>> Um servidor x86, rodando RouterOS, Linux ou FreeBSD seria um bom
>>>> candidato.
>>>>> Rubens
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 18, 2018 at 9:04 PM Tárcio Dutra <tarcio_dutra at hotmail.com
>>>>> wrote:
>>>>>
>>>>>> Boa tarde, Turma.
>>>>>>
>>>>>>
>>>>>> Recentemente recebemos alguns avisos de "Os IPs abaixo são origem de
>>>>>> ataques DDoS", tais IPs são de alguns clientes, somos um ISP.
>>>>>>
>>>>>> Ele pedem para bloquearmos, a exemplo, o trafego que sai através de
>> uma
>>>>>> porta X.
>>>>>>
>>>>>>
>>>>>> Bem, devemos sempre colaborar...
>>>>>>
>>>>>>
>>>>>> Tenho equipamentos Cisco e Mikrotik. O que vocês recomendam?
>>>>>>
>>>>>>
>>>>>> Configurar um Firewall Foward no Router BGP, nos Concentradores PPPoE?
>>>> Se
>>>>>> eu subir um FIREWALL eu vou ter um aumento considerável no
>> processamento
>>>>>> dos meus equipamentos.  😖  :(
>>>>>>
>>>>>>
>>>>>> Realmente gostaria de ler a experiência de vocês. Agradeço a quem me
>>>>>> ajudar.
>>>>>>
>>>>>>
>>>>>> Att,
>>>>>>
>>>>>> Tárcio
>>>>>> --