[FUG-BR] RES: Redundancia e Balanceamento
Renato Frederick
frederick em dahype.org
Quarta Janeiro 28 21:38:12 BRST 2009
Renata,
Antes de tudo, Sugiro usar o 1o ip do bloco CIDR obtido como neighbor.
Exemplo, se você ganhou um 100.100.0.0/20, usar o 100.100.0.1 como peer.
Aliás, é o recomendado por diversas operadoras nos formulários de inclusão.
Um dos motivos mais fortes que vejo para tanto é: caso seu circuito algum
dia mude até fisicamente, sua sessão BGP não necessitara reconfiguração. Ao
passo que o endereço /30 do router pode ser alterado ao mudar de tipo de
enlace, ponta "B" na operadora, e por aí vai.
Por experiência própria, quando mudamos de endereço, o tipo de protocolo de
enlace foi alterado e a operadora não pôde manter o mesmo endereço entre as
WAN dos roteadores, e ainda houve burocracia de manter o mesmo range /25 na
época. Creio que houve também um pouco de negligencia da operadora mas
enfim, é bom evitar isto.
Feito isto, você vai ligar para a Embratel e pedir a ativação do BGP. Ela
lhe enviara um formulário e você preenchera seu ASN, seu bloco CIDR, o IP da
sua ponta que fechará a sessão BGP, contatos técnicos e por aí vai.
Fará o mesmo para a operadora B.
Você pedirá fullrouting, pois com fullrouting você pode ter controle
granular sobre como e para quem a saída se originará, baseado no ASN de
destino, coisa impossível com partial routing.
Exemplo, para o ASN9999 sair pela Embratel, para o ASN8888 sair pela
operadora B, fazer um Black role para o ASN4444 e tal.
Enquanto a operadora faz os tramites internos, você já pode configurar em
seu firewall, ou em seu rotador a sessão BGP. Já postei aqui e na GTER um
"show running" de minha sessão, mas enviarei abaixo de novo.
Lembre-se que fullrouting exige memória RAM, então, caso seu roteador seja
obsoleto, ou com pouca RAM ou ainda já esteja chegando no limite de
processamento, você pode rodar o BGP em cima do zebra(obsoleto) ou do
quagga(recomendado), em cima do Freebsd. Ou ainda utilizar Mikrotik ou
qualquer Linux com o quagga.
Com o BGP configurado no router ou freebsd, você deixa ele desligado e
quando a operadora te ligar, você sobe a sessão BGP e juntamente com o
técnico deles, verifica se recebeu a tabela de rotas dos parceiros e se a
operadora recebeu seu anuncio de bloco. Lembre-se que caso haja algum filtro
de portas, é necessário abrir excessoes para o protocolo BGP.
Terminado isto, é só colocar o IP de seu bloco CIDR em seus servidores da
DMZ e, se for o caso, definir políticas de saída, que é algo bem poderoso.
Por exemplo, pode-se definir que uma rede /24 sairá por um link e utilizará
o outro como backup, pode-se definir que todas as redes usarão somente um
link e que o outro ficará redundante, ou ainda pode-se fazer rotas baseadas
em destino e por aí vai.
Isto não compete á operadora, somente a você. Então, sugiro que primeiro
suba-se a sessão BGP, para que a operadora possa terminar o chamado e só
depois você comece a pensar nas políticas de divisão de tráfego/redundância.
Abaixo um exemplo de configuração bgp com 2 operadoras, ignorando
prefix-list e route-map, para simplificar:
router bgp 28XXX
no synchronization
bgp router-id 187.X.X.1
bgp log-neighbor-changes
bgp dampening
network 187.X.128.0 mask 255.255.248.0
network 187.X.136.0 mask 255.255.248.0
neighbor 200.X.0.X remote-as 6XXX
neighbor 200.X.0.X description Transito BGP OPERADORA1
neighbor 200.X.0.X ebgp-multihop 2
neighbor 200.X.0.X update-source lo0
neighbor 200.X.0.X soft-reconfiguration inbound
neighbor 200.X.0.X prefix-list BOGONS in
neighbor 200.X.0.X prefix-list ANUNCIAR out
neighbor 200.Z.123.Z remote-as 1ZZZZ
neighbor 200.Z.123.Z description Transito BGP OPERADORA2
neighbor 200.Z.123.Z ebgp-multihop 6
neighbor 200.Z.123.Z update-source lo0
neighbor 200.Z.123.Z send-community both
neighbor 200.Z.123.Z soft-reconfiguration inbound
neighbor 200.Z.123.Z prefix-list BOGONS in
neighbor 200.Z.123.Z prefix-list ANUNCIAR out
no auto-summary
!
ip prefix-list ANUNCIAR description Blocos a serem anunciados
ip prefix-list ANUNCIAR seq 5 permit 187.X.128.0/21
ip prefix-list ANUNCIAR seq 10 permit 187.X.136.0/21
!
ip prefix-list BOGONS seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 20 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 25 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 30 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS seq 35 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 40 deny 224.0.0.0/3 le 32
ip prefix-list BOGONS seq 1000 deny 187.X.128.0/20 le 32
ip prefix-list BOGONS seq 9999 permit 0.0.0.0/0 le 22
para verificar se está OK, a saída do comando:
# sh ip bgp summary
Deverar ser algo assim:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
200.X.0.X 4 6XXX 5656318 100918 0 0 0 04:56:41 103127
200.Z.123.Z 4 1ZZZZ 4703616 101268 0 0 0 04:56:54 104552
Note que a ultima coluna não deve ser 0. Caso contrário, indica que não está
havendo recebimento de rotas.
O estado também não pode estar como active. Ele precisa estar contando o
tempo que a sessão esta estabelecida. O estado como active indica que a
negociação começou mas não terminou.
Bem, basicamente é isto, parece meio complexo no inicio mas é porque há
muita informação desencontrada na NET.
Abraços
> -----Mensagem original-----
> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> nome de Renata Dias
> Enviada em: quarta-feira, 28 de janeiro de 2009 17:29
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] Redundancia e Balanceamento
>
> Caros,
>
> Ja consegui esclarecer a questão de como fazer a replicação dos
> dados,
> porém tenho agora uma outra missão:
>
> Consegui com a operadora que meus dois circuitos de internet sejam
> redundantes, mas para isso preciso configurar BGP nos dois roteadores
> de
> borda (atualmente FreeBSD).
>
> Recebi da operadora o seguinte email:
>
> -ASN a ser usado pelo cliente: 11111
> -ASN da Embratel: 2222
> -em cada BGP de cada circuito, cada um usará o ip de wan do outro como
> neighbor BGP
> -os PEs originarão, conforme pedido, a rota-default no BGP para os CPEs
>
> Encontrei no google diversos sites com documentos sobre o assunto e
> estou
> estudando, mas se alguem puder me dar uma ajuda mais prática sobre o
> que
> devo fazer nos meus servidores de borda já posso ativar o sistema
> enquanto
> entendo melhor como funciona.
>
> Obrigada!
>
>
> 2009/1/21 Daniel Kühl <dklima em gmail.com>
>
> > Você pode fazer com NFS ou com storage, certamente a solução com
> storage é
> > muito mais elegante.
> > O servidor MySQL suporta replicação.
> >
> >
> > 2009/1/19 Renata Dias <renatchinha em gmail.com>
> >
> > > Caros,
> > >
> > > Necessito de auxilio para escolher o melhor conjunto de soluções
> para
> > > ativar um sistema de redundancia de servidores (podendo ou não
> funcionar
> > > com
> > >
> > > balanceamento de carga).
> > > Os servidores são WEB e estão em locais distintos
> geograficamente.
> > >
> > > A principio configurei o CARP para redundancia e PF para
> balanceamento
> > > round-robin, porém tenho a seguinte dúvida:
> > >
> > > 1) Caso o servidor BACKUP só tenha que assumir a função do MASTER
> em caso
> > > de
> > >
> > > queda no link, ou seja, sem balanceamento de carga, qual a melhor
> forma
> > do
> > > servidor SLAVE manter-se atualizado com relação aos arquivos PHP
> > > (/home/cliente) e a base de dados (mysql) ?
> > > Quando o servidor MASTER ficar UP novamente e assumir as
> atividades,
> > como
> > >
> > > pegar de volta o que mudou enquanto ele estava DOWN?
> > >
> > > 2) Caso os dois servidores façam balanceamento (com PF round-
> robin), como
> > > manter o sincronismo do /home e da base de dados?
> > >
> > > Lembrando que as duas máquinas estão em locais diferentes e o
> tempo de
> > > latencia entre elas é em média de 20ms.
> > >
> > > Storage? raid+nfs ?
> > >
> > > Alguma luz???
> > >
> > > Obrigada!!
> > > -------------------------
> > > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> > >
> > -------------------------
> > Histórico: http://www.fug.com.br/historico/html/freebsd/
> > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
> >
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Mais detalhes sobre a lista de discussão freebsd