[GTER] IPv6 Prefix Delegation Residencial - Fixo ou Dinâmico ?
Fernando Frediani
fhfrediani at gmail.com
Mon May 21 15:39:23 -03 2018
Sobre a questão do número de rotas Fixo ou Dinâmico vai ter o número de
rotas iguais ao número de usuários conectados aos quais foram atribuídos
um prefixo por Prefix Delegation. O que muda em ambos os cenários é como
isso será agregado e como você citou uma das soluções é ter uma pool
para cada concentrador.
Fernando
On 21/05/2018 13:37, Vinícius Dalcin wrote:
> Ate onde entendi o mais sensato seria isso ?
>
> Ajusta a documentação (PHPIPAM ou outro) dos prefixos v4 ou v6
> para que fiquem sumarizado em cada Concentrador. No caso v4 deixar sobra de
> cgnat para "expanção" (ideia é v4 diminuir assim que subir v6) e no v6
> também documentar certinho com as devidas reservar para expansão. Sumariza
> como colega já explicou acima.
> Caso a entrega seja por Radius crie um pool para cada
> Concentrador seguindo a sequencia para sumarizar.
> Acho que com isso se diminui muito a tabela..
> Quando possível deixar prefixos para que sejam entregues fixo
> (pppoe /30 /29 etc..).
> Não é necessário fixar prefixo ao cliente e sim pool de prefixo
> sequenciais ao Concentrador.
> Com isso certinho segue o que o colega falou rota null e
> sumariza com bgp mesmo ou ospf.. ai depende da topologia de roteamento.
>
> Atte;
> Vinícius
>
>
>
>
> Em 19 de maio de 2018 09:40, Paulo Henrique <paulohenriquef at gmail.com>
> escreveu:
>
>> Você está certo, neste cenário (com prefixos fixos) o número de entradas na
>> FIB será alto.
>>
>> Em 17 de maio de 2018 18:02, Douglas Fischer <fischerdouglas at gmail.com>
>> escreveu:
>>
>>> 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
>>>>
>>>
>>>
>>> --
>>> Douglas Fernando Fischer
>>> Engº de Controle e Automação
>>> --
>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>> --
>> Paulo Henrique Fonseca
>> paulohenriquef at gmail.com
>> --
>> gter list https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list