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

[Douglas Fischer]

Confesso que não vi tanta vantagem nessa abordagem.

Mas vou pensar nisso quando estiver com a mente mais limpa.

Agora já dia da maldade.

Em sex, 18 de mai de 2018 19:19, Fernando Frediani <fhfrediani at gmail.com>
escreveu:

> 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
> >>
> >
> >
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>