[GTER] PPPoE centralizado ou não?

[Shine]

Isso vai salvar algum cálculo do LSDB somente nos roteadores de borda.
Nos agregadores vai continuar a ser full SPF. Tenho minhas dúvidas se
esses agregadores vão escalar.

sd,
Edgar

2009/5/22 Igor Giangrossi <igiangrossi at yahoo.com>:
>
> Para evitar que toda a LSDB seja recalculada existe a funcionalidade de Incremental SPF, que recalcula somente as mudanças ocorridas. Para roteadores Cisco, basta um comando no processo OSPF:
> http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_ospf_incre_spf_ps6441_TSD_Products_Configuration_Guide_Chapter.html
>
> Mesmo assim, um princípio básico de design é manter o IGP o mais estável possível. Por isso, talvez valeria a pena gastar algum tempo para garantir que realmente esta solução de anunciar prefixos /32 é a única possível, você não irá se arrepender mais tarde.
>
> Abraços,
> Igor
>
>
>
> ----- Original Message ----
> From: Shine <eshine at gmail.com>
> To: Grupo de Trabalho de Engenharia e Operacao de Redes <gter at eng.registro.br>
> Sent: Thursday, May 21, 2009 11:25:51 PM
> Subject: Re: [GTER] PPPoE centralizado ou não?
>
> Oi Alfredo,
>
> Na verdade todos os roteadores de uma área OSPF compartilham a base de
> links de todos. Então um update altera a base que é redistribuída e
> assim é feito o recalculo do SP dessa base.
> O problema em si não é a memória, mas o processamento requerido para o
> recalculo. Os roteadores atualmente são bem otimizados para rodar esse
> algoritmo, mas mesmo assim um constante processo de recalculo de SP
> deve consumir bem uma CPU. OSPF não foi projetado para esse fim e eu
> tendo a desconfiar que não é uma solução escalável.
>
> sd,
> Edgar
>
> 2009/5/21 Alfredo Dal´Ava Júnior <alfredo.dalava at gmail.com>:
>> Bom dia pessoal,
>>
>> a discussão está ficando boa!
>> Realmente a ideia do OSPF distribuindo o /32 é muito atrativa, pois facilita
>> e otimiza a distribuição dos IPs, conforme o Eduardo escreveu.
>> A cada mudança de estado (cliente entrando e saindo) gera um update no
>> OSPF... mas o OSPF dá update na tabela inteira quando há mudanças ou ele
>> somente atualiza as rotas que alteraram? Se forem só as que se alteraram,
>> acredito que a perda de performance é irrisória, pois apenas alguns poucos
>> ciclos de CPU seriam perdidos adicionando aquela rota na tabela (exceto em
>> casos extremos de uma grande pane). De qualquer forma, será que isso seria
>> mesmo danoso à performance?
>> Quanto ao consumo de memória, será que cada rota consumiria mais do que 32
>> bytes ? (calculo superfaturado e chutado, considerando
>> IP+Mascara+Interface+gateway). Neste caso 1MB de RAM suportaria algo em
>> torno de 32.000 rotas /32....
>> Estou apenas especulando, me corrijam por favor.
>>
>> []'s
>> Alfredo
>>
>>
>> 2009/5/20 Shine <eshine at gmail.com>
>>
>>> Alfredo,
>>>
>>> A princípio OSPF pode ser uma idéia. O único porém é que a
>>> distribuição dos IPs em base /32 aumenta demais a base, além de trocas
>>> intensas por causa de mudanças frequentes de link-state. Pode ser que
>>> em algumas redes de acesso essas mudanças sejam menores (o assinante
>>> mantém a conexão por longo tempo), mas em outras poderia ter um perfil
>>> diferente.
>>> Em termos de escalabilidade pensei em diminuir a base usando áreas
>>> menores, mas vc acaba caindo que vai ter que limitar o range de pools
>>> para essas áreas.
>>>
>>> sd,
>>> Edgar
>>>
>>> 2009/5/19 Alfredo Dal´Ava Júnior <alfredo.dalava at gmail.com>:
>>> > Bom dia Michel,
>>> >
>>> > aqui nós temos uma rede mista. Alguns locais concentra-se varias redes em
>>> > mais de 1 servidor PPPoE, em outros locais está distribuido nos APs....
>>> > Estamos passando por esta mesma questão (divisao dos IPs) e creio que a
>>> > melhor tática para solucionar isto seria o RADIUS gerenciar o Pool de
>>> IPs, e
>>> > não os concentradores. O roteamento /32 seria feito dinamicamente através
>>> de
>>> > BGP ou OSPF dentro de nossa rede. Penso que assim evitaremos desperdicio
>>> de
>>> > IPs na divisao de subclasses e IPs ociosos nos concentradores.
>>> > Ainda não implementei esta ideia porque preciso habilitar o BGP em toda a
>>> > estrutura e treinar a equipe de suporte de rede para dar manutenção.
>>> >
>>> > Aproveito esta discussão para também para trocar
>>> idéias/sugestões/críticas
>>> > com os colegas.
>>> >
>>> > Obrigado,
>>> > []'s
>>> > Alfredo
>>> >
>>> > 2009/5/19 Michell <bill.cvel at gmail.com>
>>> >
>>> >> Bom dia pessoal,
>>> >>
>>> >> dos nobres colegas da lista que utilizam o PPPoE para seus clientes
>>> >> Wireless
>>> >> qual seria a melhor prática. Concentrador PPPoE centralizado, ou
>>> >> distribuído
>>> >> (nas AP's)?
>>> >>
>>> >> Hoje tenho concentradores distribuídos, porem estou começando a ter
>>> >> dificuldades na questão de roteamento, visto que a rede esta em
>>> constante
>>> >> expansão e a criação de rotas estáticas e a divisão dos IP's está
>>> começando
>>> >> a ficar complicada.
>>> >>
>>> >> Dos que já passaram por situação semelhante, qual a opinião (conclusão)?
>>> >>
>>> >> [[]]'s e desde já agradeço.
>>> >>
>>> >> Michell
>>> >> --
>>> >> gter list    https://eng.registro.br/mailman/listinfo/gter
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > []'s
>>> > Alfredo
>>> > P. J. O'Rourke<
>>> http://www.brainyquote.com/quotes/authors/p/p_j_orourke.html>
>>> > - "Never fight an inanimate object."
>>> > --
>>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>>> >
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>>
>>
>>
>> --
>> []'s
>> Alfredo
>> George Carlin<http://www.brainyquote.com/quotes/authors/g/george_carlin.html>
>> - "Electricity is really just organized lightning."
>> --
>> 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
>