[GTER] Firewall no ASN

Thu Sep 20 16:48:28 -03 2018

Bacana o seu relato Gondim, obrigado por compartilhar conosco.

Quando for possível retirar as qeues do BRAS e controlar na OLT de forma 
automatizada no provisionamento isso escala ainda mais hein !

Duas perguntas:
1) como fica o tratamento do pacote se o destino for dentro do seu 
backbone (Servidor, outro cliente de CGNAT, Servidores de CDN) ? Você 
manda pra caixa que faz o CGNAT mesmo assim baseando-se apenas no 
source-address 100.64.0.0/10 ou verifica também o destino ?
2) Esse servidor que faz o CGNAT faz determinístico ou chegaram a 
implementar algum tipo de bulk allocation dinâmico ? Se sim, no caso de 
bulk allocation como fica a parte de logs ?

Agora entendi porque o IPv6 funciona redondinho ai. Firmware baseado em 
OpenWRT é outro nível !

Fernando

On 20/09/2018 00:35, Marcelo Gondim wrote:
> 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
>>>>> -- 
>
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter