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

Thu May 17 18:02:06 -03 2018

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