[GTER] Firewall no ASN
Marcelo Gondim
gondim at bsdinfo.com.br
Thu Sep 20 18:21:09 -03 2018
Estamos tentando jogar o controle pras ONUs mas estamos com problemas no
controle da banda. Nos testes não tem controlado a banda corretamente e
aqui as ONUs tem vlan de Internet e vlan de IPTV nossa. Se fosse um
serviço só dava pra fazer o controle na PON sem problemas mas precisamos
controlar a banda por serviço. Pelo menos na FiberHome isso tá sendo uma
desgraça aqui mas a hora que conseguirmos, aí sim as caixas PPPoE vão
ficar levíssimas.
Estamos implantando o UNM2000 aqui ou pelo menos tentando. rsrsrsrs
Em 20/09/2018 17:00, Douglas Fischer escreveu:
> Coloca o cara do sistema para fazer ele integrar com a gerência das OLTs!
>
> Como eu disse, tem uns caras que prometem que isso acontece.
> Nas que são SSH, isso com ansible é "mole para o vasco" como diria o
> Eurico...
> Mas naquele troço chamado ANM-2000, grrrrr...
>
>
>
> Em qui, 20 de set de 2018 às 14:57, Marcelo Gondim <gondim at bsdinfo.com.br>
> escreveu:
>
>> 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
More information about the gter
mailing list