[GTER] IPv6 Prefix Delegation Residencial - Fixo ou Dinâmico ?
Vinícius Dalcin
viniciusdalcin at gmail.com
Mon May 21 13:37:04 -03 2018
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
>
More information about the gter
mailing list