[GTER] Questão sobre IPv6 Pools e Alocações estáticas

Thu Apr 4 11:01:27 -03 2019

Olá Bruno e demais

Creio que a utilização de iBGP neste cenário não mude muita coisa com 
relação à questão de desagregação. Se houver um número grande de 
prefixos únicos de clientes eles serão enviados da mesma forma para a 
Borda, o que não seria desejável a depender do número de prefixos. A 
ideia passa por agregá-los em algum nível da rede, seja para não enviar 
todos para a Borda ou para o OSPF e neste último caso onde possa causar 
problemas em equipamentos mais limitados em questão de rotas mas que 
desempenham um papel importante na arquitetura da rede como encaminhar o 
tráfego de uma maneira mais ótima e sem dar voltas.

A questão do sistema de gerência acredito que não faz muita diferença 
como isso é gerenciado. É interessante que ele aloque um prefixo fixo no 
cadastro do cliente (não sei se todos os softwares de gestão já pensaram 
nisso para IPv6), porém ao final o que importa é o atributo Radius que 
ele vai enviar seja Delegated-IPv6-Prefix-Pool ou Delegated-IPv6-Prefix 
e que vão definir o quão desagregado ou não será. Ai que entra a questão 
principal: como e onde agregar para que seja escalável.

Fernando

On 03/04/2019 19:28, Bruno Cabral wrote:
> A solução me parece simples, ao invés de incluir os prefixos dos clientes no OSPF, se usa outro protocolo (iBGP) "por cima" para repassar essas redes do BRAS até a borda
>
> Ou MPLS
>
> !3runo
>
> --
> Cursos e Consultoria BGP e OSPF
> ________________________________
> De: gter <gter-bounces at eng.registro.br> em nome de Lucas Willian Bocchi <lucas.bocchi at gmail.com>
> Enviado: quarta-feira, 3 de abril de 2019 18:51
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] Questão sobre IPv6 Pools e Alocações estáticas
>
> Cara, sinceridade eu não vejo problema desde que o ERP gerencie a delegação
> de prefixos. No caso desse sistema do cara ele gerencia de boa. O resto,
> parte de roteamento (da nossa rede, rede do cliente é outra história) vejo
> que é tranquilo com o ospf. Agora, a questão é o sistema não gerenciar essa
> alocação / desalocação de blocos (quando o cliente cancela por exemplo)
> para os clientes, que aí fica bicho feio. No caso esse sistema ficou tão
> legal que até o apontamento do reverso ipv6 já aponta pro número do
> contrato do cliente e o nome do bicho.
>
> Em qua, 3 de abr de 2019 às 18:10, Fernando Frediani <fhfrediani at gmail.com>
> escreveu:
>
>> Então, a questão é justamente como fazer esse balanceamento e que seja
>> escalável para que uma vez definido o modo de trabalho ela seja o mesmo
>> para 2 mil ou 200 mil clientes.
>> Talvez não tenha colocado todas as perguntas, mas caberia perguntar
>> também: quantas rotas dessas de clientes seria razoável jogar pra uma
>> área da rede no caso de uso de Prefixos Fixos ? Tem que levar e conta
>> outros equipamentos possivelmente utilizados localmente que podem
>> receber todas essas rotas desagregadas e qual o impacto neles (ex: tem
>> gente que utiliza switch Layer 3 para fechar sessão com servidores de
>> VPN e direcionar o tráfego do cliente direto sem passar por roteador.
>> Nesse caso a quantidade de rotas que esse equipamento irá receber pode
>> ser razão de preocupação dependendo das especificações).
>> Possivelmente seja o caso de isolar essas rotas desagregadas em áreas do
>> backbone (região ou cidade) o que dá alguma flexibilidade e se o cliente
>> mudar de localidade atribuir um novo Prefixo Fixo pra ele.
>>
>> A solução de alocar um prefixo por BRAS com o mesmo nome de pool parece
>> bem redonda para a questão de agregação, porém vai no sentido contrário
>> da ideia de quem deseja trabalhar com alocações fixas.
>>
>> Colocando em números  foi citado 16 mil e 4 mil clientes. Aparentemente
>> são números tranquilos de se trabalhar no pior dos cenários de
>> desagregação, mas e se subirmos isso para 30 mil, 50 mil, etc, como
>> ficaria ?
>>
>> Fernando
>>
>> On 03/04/2019 16:35, Lucas Willian Bocchi wrote:
>>> Isso vai muito do sistema.
>>> Tenho um cliente que desenvolveu sistema próprio que já no cadastro do
>>> cliente você define o tamanho da faixa ipv6 que vai pro cliente e ele já
>>> tem um pool pré-cadastrado que joga isso direto pro cara. Quanto a
>> questão
>>> do ipv6 que ele pega no momento da conexão também é um pool separado
>>> especialmente para este quesito. As rotas trocamos via OSPF e até agora
>> não
>>> tive problema. O número de clientes nesse cenário é pequeno (4 mil), com
>> 4
>>> equipamentos accel-ppp, e até agora tem se mostrado satisfatório. Não sei
>>> como isso ficaria num juniper, etc.
>>>
>>> Em qua, 3 de abr de 2019 às 10:19, Fernando Frediani <
>> fhfrediani at gmail.com>
>>> escreveu:
>>>
>>>> Olá a todos.
>>>>
>>>> A questão que eu vou colocar acredito que possivelmente não exista uma
>>>> resposta única porém gostaria de ler os comentários e opiniões à
>>>> respeito do assunto.
>>>>
>>>> Pessoalmente eu gosto da ideia de entregar uma alocação IPv6 Fixa por
>>>> Prefix Delegation para o usuário na autenticação. Isso facilita ainda
>>>> mais a questão de registros(menos log), identificação fácil quando
>>>> necessário e acaba com a necessidade de uso de DNS Dinâmico.
>>>>
>>>> Porém isso vai bem aonde exista apenas 1 BRAS ou uma quantidade
>>>> razoavelmente pequena de clientes, caso contrário em uma arquitetura com
>>>> múltiplos BRAS aquelas várias rotas para cada cliente podem começar a
>>>> causar desagregação e poluir o OSPF.
>>>>
>>>> Por outro lado em um cenário de múltiplos BRAS aonde não exista entrega
>>>> de prefixo IPv6 fixo pode-se ter 1 pool de mesmo nome com um prefixo
>>>> agregado por BRAS e na autenticação enviar apenas o nome da pool através
>>>> do atributo Radius Delegated-IPv6-Prefix-Pool, então à depender de qual
>>>> BRAS ele cair ele receberia um endereço daquela faixa mas a única rota
>>>> anunciada para o restante da rede é aquela do prefixo agregado para
>>>> aquele BRAS.
>>>> No caso de clientes que realmente necessitem de Prefixo Fixo pode-se
>>>> usar o atributo Delegated-IPv6-Prefix que acredito se sobrepõe ao
>>>> atributo com o nome da pool, porém causando alguma desagregação embora
>>>> muito menor nesta combinação.
>>>>
>>>> Alguém vê como possível trabalhar com Prefixos IPv6 Fixos e o atributo
>>>> Delegated-IPv6-Prefix em um cenário com múltiplos BRAS e um número
>>>> médio/grande de clientes sem causar demasiada desagregação ? Alguma
>>>> maneira bem balanceada de se agregar um grupo de BRAS para reduzir essa
>>>> poluição par ao restante da rede ?
>>>>
>>>> Obrigado
>>>> Fernando Frediani
>>>>
>>>> --
>>>> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter