[GTER] Implementação de VRRP com RouterOS
Douglas Fischer
fischerdouglas at gmail.com
Wed Sep 19 17:51:12 -03 2012
Até agora essa é a única implementação no nível de configuração que vi que
funciona.
As outras duas seriam:
- Virtual Machine com HA em dois servidores físicos
- Cisco Virtual Switch System
E essa ultimas duas não ficam nada baratas
Em 19 de setembro de 2012 17:10, Renato Frederick
<renato at frederick.eti.br>escreveu:
> Já tive um problema igual o seu, porém foi que:
>
> A operadora forneceu o /29, porém na hora de assumir pela minha 2a caixa,
> ela não divulgava as rotas desta 2o sessão para os upstreams, fazendo com
> que não adiantasse em nada. Ela não conseguiu manter 4 sessões BGP: caixa A
> com router A e B deles + caixa B com router A e B deles, somente com 2
> sessões ela conseguia propagar as rotas corretamente.
>
> A solução foi, usando openbgpd, usar carp eusar 3 IP: um para a caixa A,
> um para a caixa B e outro para o IP virtual do CARP.
>
> Daí, mandar o openbgpd subir a sessão bgp usando o IP virtual do CARP e
> usar a diretiva "depend on carpX", sendo carpX a interface CARP(normalmente
> carp0).
>
> A operadora por sua vez fecha duas sessões somente, usando o ip virtual do
> carp: Router A e B deles fecha uma sessão cada um, com o IP virtual do meu
> carp.
>
> quando a minha caixa A para, o meu CARP assume na B e a sessão BGP é
> resetada na operadora e sobe de novo.
>
> Divulgo para os 2 routers dele a mesma /20.
>
> Caso o CARP for usado em cima do OPENBSD, não é necessário usar um /29,
> pode-se deixar as interfaces que ligam á operadora sem IP e mandar o CARP
> assumir naquela interface física. No meu caso, como é FREEBSD, este recurso
> não tem na implementação dele, ele aprende em qual interface o CARP vai
> associar através da combinação IP + máscara.
>
> []s
>
>
>
>
> Em 19/09/2012 15:46, Douglas Fischer escreveu:
>
> Senhores,
>> existe uma situação onde eu estava "tentando" usar HSRP(VRRP-like) com o
>> BGP para conseguir redundância de Caixa de borda.
>>
>> Era uma solução de contorno para a inflexibilidade da minha querida
>> operadora não aceitar subir duas sessões BGP pelo mesmo link.
>> Fiz LABs virtuais e físicos e funciona muito bem.
>> Depende de:
>> - Rede de enlace com operadora ser /29
>> - e-BGP-Multihop numa loopback /32 com o mesmo IP nos dois roteadores(um
>> UP e o outro em Shut)
>> - Rota estática na operadora para o IP do PEERs BGP apontando para o IP
>> virtual do FHRP.
>> (para estabelecer a sessão do e-BGP-Multihop)
>>
>> Através de Embedded Evet Manager monitora-se o status do HSRP(no meu caso,
>> mas com VRRP funciona também).
>> - HSRP mudou para Active, 'no shudown' na loopback do e-BGP, e sobe o
>> peer
>> BGP.
>> - HSRP saiu de Active, 'shutdown' na loopback do e-bgp, e derruba o peer
>> BGP.
>>
>> O maior inconveniente é trocar toda a tabela nessa "virada de caixa".
>> Mas funcionou lindamente.
>>
>>
>>
>> P.S.: A solução funcionou MUITO BEM, e foi desenhada desse jeito pois a
>> engenharia da operadora havia me garantido que seria possível um /29 na
>> rede de enlace.
>> Porém na hora de ativar, apareceu a surpresa do Kinder ovo.
>> Se negaram a fornecer a rede de enlace em /29.
>>
>> A solução que eles levantaram chega a ser estúpida... "Vamos dividir
>> em dois links físicos com a metada da banda cada um..."
>>
>>
>>
>> Em 19 de setembro de 2012 14:46, Eduardo Schoedler <listas at esds.com.br
>> >escreveu:
>>
>> Em 19 de setembro de 2012 14:03, Michell <bill.cvel at gmail.com> escreveu:
>>>
>>> Eduardo chegou a implementar a redundância com VRRP? Usa VLAN com as
>>>> operadoras para fechar a seção BGP e OSPF para atender a sua rede
>>>>
>>> interna?
>>> VRRP funciona sim, mas como gateway para acesso.
>>> Não uso para BGP, até porque o certo é ter mais de um trânsito, então não
>>> tem porque usar VRRP.
>>>
>>> --
>>> Eduardo Schoedler
>>> --
>>> gter list https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>>
>>>
>>
>>
> --
> gter list https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>
--
Douglas Fernando Fischer
Engº de Controle e Automação
More information about the gter
mailing list