[GTER] IPv6 Prefix Delegation Residencial - Fixo ou Dinâmico ?
Paulo Henrique
paulohenriquef at gmail.com
Thu May 24 11:40:29 -03 2018
RouterOS tem seus problemas com DHCP-PD, por isso uma opção é utilizar
prefixos fixos por assinante, porém, caímos no problema citado pelo
Douglas, que DEPENDENDO da situação pode ser tolerado, mas em outros casos
vai causar dor de cabeça
Att.
Em 24 de maio de 2018 08:27, Antonio Modesto <modesto at isimples.com.br>
escreveu:
> Aproveitando o assunto. Nosso ERP (Hubsoft) já possui suporte à essa
> funcionalidade integrada ao Freeradius 3. Porém o RouterOS ainda não
> suporta pelo que eu sei.
>
> > On 21 May 2018, at 15:39, Fernando Frediani <fhfrediani at gmail.com>
> wrote:
> >
> > 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
> >
> > --
> > gter list https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
>
--
Paulo Henrique Fonseca
paulohenriquef at gmail.com
More information about the gter
mailing list