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: [email protected] [mailto:[email protected]] 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 <[email protected]> > > > 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 <[email protected]> > > > > > 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
