[GTER] IPv6 Prefix Delegation Residencial - Fixo ou Dinâmico ?

Fri May 18 15:20:11 -03 2018

Acho que começo a conseguir entender o que você quer dizer. Vamos então 
imaginar 2 cenários simplificados:

Pequeno:
O número de rotas /32 (para IPv4) ou /56 (para IPv6) possivelmente não 
seja um problema para o OSPF daquele provedor.

Grande:
Não podemos considerar a agregação de prefixos por concentrador (e não 
individualmente) e no ERP, baseado em algum dado como endereço, área, 
OLT, BRAS que ele autentica, etc, atribuir àquele cliente um prefixo 
estático que só pode se entregue naquelas condições e atrás daquele 
prefixo maior que agrega toda aquela base de usuários daquela área ? 
Creio que para um ERP usado nesses casos não seja tão complexo de 
adaptar e com isso mantém o número de rotas no OSPF baixo. Ou me perdi 
em algum detalhe ?

Fernando Frediani

On 17/05/2018 18:02, Douglas Fischer wrote:
> A prática me faz discordar de você!
>
> Quem já apanhou com saturação de FIB de switch-router da rede interna,ou
> quem já teve problema na convergência dos prefixos internos,
> deve ter lembrado do que estou falando...
>
> Vou tentar construir um exemplo num cenário HIPOTÉTICO de alguns ISPs
> brasileiros:
>
> Vamos esquecer(por hora) o IPv6 e ficar só no IPv4.
> Também vamos deixar de lado o CG-NAT, para focar na questão do número de
> prefixos.
>
> 1 X Huawei 5720 ou 6720 como L3
>      (pode ser com o Nexus também)
>      - Vai bem até uns 4K prefixos
> 3 X CDNs
>      - 3X /29
> 4 X CCRs fazendo B-RAS, com 1500 cliente cada
>      - Vamos presumir todos na mesma vlan fazendo load balance com
> first-response.
>      - Digamos que o cara seja pré 2015 e tenha conseguido ip válido para
> todo mundo.
>
>
> Se a alocação do IP do cliente for feita pelo Radius(ERP/CRM/etc), não tem
> como assegurar que o cliente está nesse ou naquele B-RAS, então deixa por
> conta do IGP(Geralmente OSPF) ensinar os demais dispositivos de roteamento
> que aquele prefixo /32 está naquele router através do redistribute
> connected.
>
> Se são 1500 em 4 B-RAS, são 6K prefixos...
>   -> A FIB do Switch L3 não vai gostar!
> Aí o cara ativa a auto-summary do OSPF.
>   -> Convergência fica um coconut, CPU mono-núcle atola.
>   -> E aí começa as novelas do "IP-Preso ficou preso no outro concentrador".
>
> Como eu costumo resolver isso?
>   -> Deixa o B-RAS atribuir o IP pelo pool local
>   -> Mete uma rota /22 ou /23 para Null0 e coloca o OSPF fazer redistribute
> static[1].
> "Mas Douglas, e os cliente com IP-Fixo?"
>   -> Tenha o cuidado de deixar esses IPs num bloco diferente do restante.
>   -> Esses você continua atribuindo através do Radius.
>   -> E ativa o redistribute-connected[1] que aí desses 6k clientes, deverão
> ser uns 400-500 com IP Fixo.
> Nessa brincadeira o número de prefixos da rede interna vai ficar nesses
> 400-500 dos IPs fixos, e mais umas 30-40 rotas do restante.
>
> [1] OBVIAMENTE você vai colocar filtragem de prefixos anunciados no OSPF,
> né!?
>      NÉ?????????????????
>
> P.S.: Me lembrei da parte do:
> "Se uma dos meus concentradores cair, como o Pool é fixo, não vou ter IP
> para todo mundo."
>     - Para esse caso eu já fiz umas gambis bem loucas, usando:
>        - Rotas /dev/null(reditribuída) mais específicas no B-RAS preferido
>        - Rotas /dev/null(reditribuída) menos específicas no B-RAS
> não-preferido
>
>    Mas só essa pare levaria umas 40 linhas para explicar.
>
> ---
>
> História contada para IPv4, e o mesmo vale para IPv6!
> Só replicar e adaptar algumas coisinhas...
>
> Com os blocos do CG-NAT também é quase a mesma coisa.
>   -> Para os prefixos inválidos, aloca um range gordinho o suficiente para
> cada caixa.
>
> A única indefinição é para os Blocos Válidos usados no CG-NAT
> Aí entra a complexidade do "aonde fazer o NAT?".
>     - Outra Novela... Que não é o foco agora.
>
>
>
>
>
>
> Em 17 de maio de 2018 14:01, Fernando Frediani <fhfrediani at gmail.com>
> escreveu:
>
>> Olá Douglas
>>
>> Não sei se consegui entender bem a sua colocacão mas a princípio eu diria
>> que as rotas no OSPF serão em igual quantidade sejam os prefixos delegados
>> fixos ou dinâmicos afinal a rota só seria instalada quando o usuário
>> estiver conectado.
>>
>> A questão de sumarizar nos concentradores ainda sim é possível com algum
>> tipo de processo aonde o prefixo designado para detetminado usuário estará
>> disponivel no pool de concentradores que ele se autentica.
>>
>> Fernando
>>
>> On Thu, 17 May 2018, 10:13 Douglas Fischer, <fischerdouglas at gmail.com>
>> wrote:
>>
>>> Lado positivo já foi ressaltado por ti.
>>>
>>> No lado negativo me veio a cabeça a questão do número de prefixos nas
>>> tabelas de roteamento IGP(OSPF ou similares).
>>>
>>> No cenário atual brasileiro de ISPs é muito comum o uso de switch-routers
>>> com FIB limitada em torno de 5-20K rotas.
>>>
>>> O uso da delegação de prefixos baseada no pool do B-RAS viabiliza a
>>> sumarização desses blocos de prefixos.
>>> Ou seja, se tem 1K-1,5K clientes num B-RAS, ao invés de mil, mil e
>>> quinhentos prefixos, tem um só (nesse caso rota para Null0 e redistribute
>>> static ajuda muito). Isso vale para v4 e v6.
>>>
>>>
>>> Uma alternativa que eu acho que pode ajudar é aumentar a inteligência da
>>> parte de DHCP nisso. Aumentar o lease time para uma semana já ajudaria.
>>>
>>> Em qui, 17 de mai de 2018 05:30, Fernando Frediani <fhfrediani at gmail.com
>>>
>>> escreveu:
>>>
>>>> Olá pessoal, gostaria de saber a opinião de vocês a respeito deste
>>>> assunto como também daqueles que estão distribuindo IPv6 para usuários
>>>> de banda larga como estão preferindo fazer.
>>>>
>>>> Alguém já pensou em fazer ou já está fazendo distribuição sempre do
>>>> mesmo Prefixo no Prefix Delegation para cada cliente previamente
>>>> cadastrado no seu CRM/ERP ? O seu CRM/ERP suporta essa funcionalidade ?
>>>>
>>>> Assisti uma palestra do Luis Balbinot no último GTER [1] sobre este
>>>> assunto e achei muito interessante além de simpatizar com a ideia de
>>>> entregar sempre o mesmo prefixo por razões como:
>>>> - simplificação
>>>> -elimina a necessidade de DNS dinâmico, e
>>>> -facilidade na identificação do usuário por imposição legal.
>>>>
>>>> Além disso outro problema que desaparece nesse cenário é o de "CPE
>>>> Pendurada" (página 22) quando há queda na conexão da CPE (devido à
>> queda
>>>> de energia ou outra razão), ela recebe outro prefixo que acaba não
>> sendo
>>>> adequadamente passado para os devices atualizarem-se causando a quebra
>>>> da navegação em IPv6 forçando o failback para IPv4 até o refresh
>> daquela
>>>> conexão com a CPE.
>>>>
>>>> Quais os pontos negativos que vocês enxergam nessa prática ? O único
>>>> citado que eu me lembro e que é apenas uma hipótese é do cliente
>>>> reclamar de uma menor privacidade por ter que navegar sempre com o
>> mesmo
>>>> prefixo/IP, apesar de que esse "problema" já existe em outro cenários
>>>> similares mesmo em IPv4.
>>>>
>>>> A BCOP mencionada [2] nos slides está na URL abaixo.
>>>>
>>>> Qual a visão de vocês ?
>>>>
>>>> Obrigado
>>>> Fernando Frediani
>>>>
>>>> [1] -
>>>>
>>> ftp://ftp.registro.br/pub/gter/gter44/07-alocacao-IPv6-
>> clientes-finais.pdf
>>>> [2] - https://www.ripe.net/publications/docs/ripe-690
>>>>
>>>> --
>>>> 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
>>
>
>