[GTER] Escalar OSPF / iBGP

[Shine]

Não digo bem iBGP, mas BGP em geral, isso inclui eBGP.
Pode ser uma questão de gosto pessoal, definir um protocolo também tem esse
fator de conforto operacional e de desenvolvimento que deve ser
considerado, fora entender se a curva de aprendizado não vai ser um
obstáculo no decorrer do tempo. Mas definitivamente BGP e OSPF são
protocolos com princípios distintos, se fosse uma comparação OSPF com ISIS
seria algo ao menos mais próximo.

Vamos pegar OSPF e BGP para você poder ter uma idéia.
Com OSPF, qual a sua opção para manipular o tráfego além de cost? E indo
além, como controlar o que é ECMP, o que não deveria ser?
Agora vamos ao BGP. Você consegue balancear por faixas de prefixos IP? Como
controlar ECMP? Como manipular os prefixos para ter maior peso ou menor
peso entre as faixas?
Quando você observa as características de como funciona o path selection do
BGP e do OSPF, então acho que a questão de manuseabilidade do tráfego fica
evidente.

Deixando claro que não existe protocolo "melhor" ou uma receita pronta para
todos os casos, o uso é muito dependente das características da rede e das
aplicações em cima dessa rede. Tanto BGP como OSPF têm pontos positivos
como negativos.

Um outro ponto muito válido que o Bruno colocou é que o uso de um protocolo
não inviabiliza o uso de outro, é possível usar overlay de protocolos e se
beneficiar de ambos, fazendo uso complementares deles na rede em alguns
casos.

Em 24 de novembro de 2014 14:08, Jonatas M. Victor <jonatasmv at gmail.com>
escreveu:

>  Obrigado a todos pelos depoimentos. E usando iBGP se tem uma flexibilidade
> melhor de filtros que OSPF? Permitindo manobrar por links difernetes
> conforme a necessidade?
> Mas pode ser mais uma questão de gosto que realmente utilizar 1 ou outro?
>
> 2014-11-21 1:49 GMT-02:00 Shine <eshine at gmail.com>:
>
> > Essa é uma questão interessante.
> > Os tempos de convergência são muito parecidos. Pelo que entendi, o OSPFv3
> > não leva em conta o endereço IP no cálculo do SPF, apenas o link mesmo. E
> > faz sentido, pq o IPv6 tem uma amarração mais coerente com a interface do
> > que o IPv4.
> >
> > Agora, que o tamanho das tabelas de endereços aumenta, isso não há
> dúvida.
> > Tanto que a maior limitação para IPv6 vem em tabelas mac, listas de
> > filtragem, tabela de encaminhamento. Mesmo com a lógica de flexibilização
> > de endereçamento, montar uma tabela lógica flexível indexada com
> endereços
> > IPv6 não é das tarefas mais fáceis.
> >
> > Mas a necessidade é a mãe das invenções, vamos ver o que acontecerá
> > adiante...
> >
> > Em 19 de novembro de 2014 09:22, Lucas Willian Bocchi <
> > lucas.bocchi at gmail.com> escreveu:
> >
> > > Veja que ainda estamos falando sem pensar no IPv6, que vai aumentar
> > > ainda mais a questão de tabelas de roteamento. Pensem num pop com 1000
> > > sessões PPP, e nessas mil sessões mais mil classes /64 sendo
> > > distribuídas nestas sessões. Uma queda ou intermitência nesse
> > > equipamento com convergência baixa vai fazer seus companheiros
> > > sofrerem bastante.
> > >
> > > É algo que realmente temos que pensar para bolar uma idéia que seja
> > > eficiente.
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> .:Abraços:.
>
> <<< Jonatas M. Victor >>>
> jonatas at jmv.eti.br
> jonatasmv at gmail.com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>