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

[Fernando Frediani]

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