[GTER] Escalar OSPF / iBGP

[Shine]

Oi Bruno,

Sim, claramente neste caso o summary traz vantagens. Mas veja que uma coisa
é tabela de rotas, outra é OSPF LSDB. O escopo da discussão é escalar OSPF
e entender seus limites.

Vamos supor que existam três concentradores, cada um com 3000 links PPP
virtuais dentro do OSPF, sendo que você escolhe a rota /32 do link virtual
PPP (vamos dizer que vc use framed-ip no radius e atribua dinamicamente).
Vamos supor que esses /32 vão para um roteador de borda na mesma área do
OSPF, que recebe todos os 9000 links da mesma área (quando estiver em
capacidade máxima) e daí faça o summary para a backbone area e passe
adiante. Você não pode fazer o summary nos três concentradores pq o IP fica
"flutuando" neles, certo? Mas no caso do roteador concentrador você pode
fazer o summary route, já que ele recebe todas as rotas e pode decidir para
qual concentrador enviar o pacote.
OK, você então faz um tuning bem agressivo, coloca BFD para detectar uma
queda de algum concentrador ou do próprio roteador (que aliás você pode
duplicar e fazer um esquema de originate-default ou coisa do gênero para
balancear o tráfego), coloca o LSA throttle timer em valores bem medíocres
para recalcular rápido o SPF.
Supondo que um dos concentradores morra, será que teremos algum impacto em
algum equipamento?

Sei que é a teoria do absurdo na vida prática, mas é algo para pensar se
summary realmente resolve a escala do OSPF. Poderia ser um outro exemplo,
por exemplo 10 concentradores com 1000 virtual PPP links em cada - tudo na
mesma área. Mas continua fazendo o mesmo summary no ASBR, será que isso
muda em algo?

[]s!



Em 18 de novembro de 2014 14:22, Bruno Cabral <bruno at openline.com.br>
escreveu:

> Olá Edgar
> obrigado pelos esclarecimentos
> sobre a sumarização, faz sentido distribuir o range local do concentrador
> (pro minimo de usuários sempre conectados) e um range adicional via /32s
> para os IPs que excedam esse mínimo. A depender do concentrador a
> quantidade de IPs a convergir pode cair absurdamente
> []s, !3runo Cabral
>
> --Cursos e Consultoria BGP
>
>
> > Bruno, fui eu que afirmei que em geral iBGP precisa fazer full mesh. O
> > motivo é justamente por causa do split horizon.
> > Concordo com você não necessariamente é obrigatório, mas usar ou não usar
> > loop prevention é inerente ao projeto da rede. Se ter um mecanismo de
> > prevenção de loop faz sentido, é bem mais fácil ter um router-reflector
> do
> > que ficar tunando as bordas. Se o split-horizon, que é um comportamento
> > padrão estiver habilitado, mesmo que hajam dois peerings iBGP com a
> borda,
> > a borda não irá passar as rotas aprendidas de um iBGP para outro iBGP se
> > eles estiverem no mesmo AS.
> > Mas enfim, depende do projeto da rede. Não há uma regra rígida, o que
> pode
> > ser bom em um caso, pode não ser adequado em outro.
> >
> > Quanto a sumarizar, se a rede ficar grande e espalhada, fica difícil
> > controlar a distribuição homogênea e assim podem aparecer black holes de
> > rotas, que são chatos para se depurar.
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>