[GTER] Bgp com operadora usando /29

[Shine]

Douglas,

Eu não tenho uma opinião muito rígida, se tecnicamente a solução se
justifica o uso pode ser recomendado. Não acho que tudo deva ser separado
em "boa prática" ou não.

Mas tenho minhas dúvidas e é interessante discutirmos os pontos técnicos
para entender melhor o escopo e sua aplicação. Vou colocar as minhas
opiniões inline.

Em 22 de agosto de 2014 09:34, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> Nos 3 ambientes que coloquei em produção, um inclusive foi um Datacenter em
> que trabalhei, o cenário físico era o mesmo.
> - 2 CPDs em pontos físicos distintos
> - Uma operadora chegando em cada CPD
> - 1 Switch Layer2 em cada CPD, aonde chegavam os links das operadoras
> - Os switchs interligados por fibra apagada
> - 1 firewall em cada lada, trabalhando em statefull-failover
> - Um roteador de borda em cada CPD
> - Tanto nos caso dos Roteadores, quanto dos Firewalls, o par estava em
> Active/Standby.

Bom, pelo que entendi, você tem redundância de operadora em links
distintos, então em caso de falha da operadora você tem outro caminho. Ou
seja, da falha da operadora você estava coberto, independente de ser no seu
roteador/switch ou no dela ou cair o link de conexão.


> Vantagens desse cenário?
> - Tempo médio entre falhas de Switchs é consideravelmente maior que
> Roteadores ou Servers que operem como soft-routers.
>
Em software sim, mas em hardware, não. Roteadores usam algoritmos mais
complexos no control-plane.


> - Elemento redundante para cada ponto do conjunto
>   - Se uma das operadoras falhar, tem a outra.
>
Sim, mesmo que falhe tudo.

  - Se um dos switchs de borda falhar, tem o outro.

  - Se um dos firewalls falhar, tem o outro.
>   - Se um dos roteadores falhar, tem o outro.
>   - Se um CPD inteiro falhar, o ASN continua alcançável pelo outro.

Mas isso pode ser feito usando uma abordagem em cada site e redistribuindo
adequadamente o acesso no IGP, não é exclusivo dessa abordagem de solução,
não?


> - E essa redundância foi pensada não somente para as falhas...
>   Ex.: 10:00 e eu quero remover um dos roteadores para "passar um
> aspirador"...
>        Nesse cenário você pode fazer isso, se perder largura de banda com a
> Internet.
>
Sim, mas você perde em agilidade. Mesmo que seja por segundos, há uma maior
interrupção de tráfego.

Interessantemente eu acabei fazendo cada um dos 3 ambientes de um jeito
> diferente.
> A - Com a Oi, consegui com muita miséria um /29 na WAN, coloquei os dois
> routers na borda.
>     Como a Oi não liberava 2 sessões simultâneas nem com reza-brava, usei
> eBGP-Multihop e VRRP e fechei a sessão BGP na Loopback do Router que estava
> ativo.
>     Há quase 2 anos atrás eu encaminhei a essa lista um roteirinho sobre
> como fazer isso.
>     Segue o link para a thread ->
> http://eng.registro.br/pipermail/gter/2012-December/040841.html

Veja, aqui foi usado EEM, o ambiente não tem um mecanismo de fast
convergence e se o next-hop cair para o blackhole a convergência não
funciona adequadamente. No seu caso funcionou porque são operadoras
distintas e uma vai bloquear o acesso do bloco de outra por políticas de
proteção de trânsito, impedindo um loop de peering.
De qualquer forma o que você faz é: derrubar o peering e refazer ele por
script em caso de uma falha - script que é dependente da plataforma e
amarrada ao desenvolvedor (mesmo que seja um simples shut - no-shut).


> B - Com a GVT, consegui dois /30 no mesmo barramento de rede e fechei duas
> sessões BGP.
>     Usei Metric e community para definir o ativo e o standby.

Se cair o barramento inteiro dessa rede na operadora conseguiremos fazer a
redundância? Não seria melhor duas sessões em dois roteadores distintos?


>  C - Com um ISP do centro do Paraná, ele me entregou 2 Vlans, /31 em cada

Vlans e 2 sessões BGP.
>     Ele disse que se apurou para fazer o controle de banda(pois ele
> geralmente fazia por Vlan e teve que fazer por porta).
>     P.S.: Esse foi o que eu achei mais elegante!
>
Cai o router peer que você fechou a sessão e aí cai as duas pontas... não?

Você tem uma sessão que é controlada por um script, chegou a medir o tempo
de convergência e comparar com outros que usam BFD e timers mais agressivos?