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

[Bruno Cabral]

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