LEIAM e postem alguma coisa...

adircastro
(usa Debian)

Enviado em 10/09/2007 - 18:18h

matrix,

Na verdade, dos 8 scripts que copiei na internet e usei pra teste, nenhum satisfez minhas necessidades, principalmente no tempo de entrada do link secundário. O tempo de entrada do link reserva, se tornou maior do que quando eu faço manualmente, reiniciando um brazilFW que tenho com o HD no link principal e o disquete no link secundário.

A única coisa que estou usando é isso, no iptables:
------------------------------------------
# Compartilhando a internet na interface ethx - rede externa
#iptables -t nat -A POSTROUTING -s 192.168.100.0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

Redundância via linux - embora seja iniciante no sistema - acho que não é tão simples e fácil, como vemos sendo divulgado nesses foruns.

Não estou desmerecendo ninguém que tenha feito algum script com essa finalidad. Pode até ser que tenha funcionado nalguma outra distribuição, mas não em conectiva 7.0 e Debia 4.0.

Estou no Debian, tentando isso há mais de 60 dias. No Conectiva 7.0, nem me lembro quantos meses foram... e usando os mesmos scripts.

E olha, usando dessa forma, pra você ter uma idéia, quando troco de link, o máximo de pacotes perdidos até a navegação na rede restabelecer, ainda não passou de 8 pacotes.

Por isso optei por esse esquema, que é trabalhoso, mas é mais interessante. Não fosse esse pequeno detalhe, já estaria com os dois links em uso.

adircastro
(usa Debian)

Enviado em 10/09/2007 - 18:24h

matrix,

Creio que dizendo isso: "por algum motivo a rede 192.168.100.0/24 ainda ta tentando sair pelo link que ta com o cabo desconectado", você chegou no "xis" da questão... risos.

E quanto a esses comandos:
#route del default gw 172.16.130.217
#route add 192.168.100.0/24 gw 10.10.0.185

Me preocupa usar esses comandos, pelo fato de que quando o reserva cair, o problema de "sair pelo link que tá com o cabo desconectado", vai acontecer novamente, agora com o link principal. Ou na sua opinião não vai acontecer?

adircastro
(usa Debian)

Enviado em 10/09/2007 - 18:47h

Vejam só, quando faço a inversão no interfaces, colocando o link primário na eth1 e o secundário na eth2, o problema com a sala de bate papo, passa a acontecer no link principal, e o reserva fica normal. Tanto na sala quanto nos pings a partir da estação.

Já fiz essa inversão várias vezes...

m4tri_x
(usa Ubuntu)

Enviado em 11/09/2007 - 00:54h

amigao, com certeza, qualquer link pode vir a falhar a qualquer hora, com meu conhecimento limitado eu acho que poderia dar certo se voce fizer um script no linux que fika pingando um ip qualquer e no momento que parar de responder o ping, ele atribui outro gw no lugar do default, acho que isso poderia dar certo, assim voce pode deixar apenas 1 default gw. porem se o caso for de transformar ambos os links em 1, dai nao sei nem por onde começar.

[]'s

adircastro
(usa Debian)

Enviado em 11/09/2007 - 08:35h

Olá,

Ontem a noite fiz algumas observações durante a troca de link. Veja isso:
Logo que tirei o link principal e deixei o reserva, fiz o traceroute e ele me reportou esse resultado:

traceroute to globo.com (201.7.176.59), 30 hops max, 40 byte packets
1 172.16.130.218 (172.16.130.218) 2832.578 ms !H 2894.907 ms !H 3004.057 ms !H

Isso raramente acontece e quando acontece é por pouco tempo, e nem impede a navegãção. Em seguida, com o mesmo traceroute, a resposta foi essa:

traceroute to globo.com (201.7.176.59), 30 hops max, 40 byte packets
1 10.10.0.185 (10.10.0.185) 31.083 ms 33.924 ms 11.130 ms
2 * * *
3 gateway.leolar.com.br (200.228.94.129) 20.160 ms 93.486 ms 31.667 ms
-------------------------------------------
Antes de tirar o link principal, essa era a resposta ao ping, fazendo direto da estação:

Resposta de 64.233.161.104: bytes=0 tempo=331ms TTL=238
Resposta de 64.233.161.104: bytes=0 tempo=355ms TTL=238

Quando fiz a troca, o ping passou a ficar assim:
Esgotado o tempo limite do pedido...
Essa mensagem se repete entre 3 e 8 vezes, aí muda para essa:

Resposta de 172.16.130.218: Host de destino inacessível.
Resposta de 172.16.130.218: Host de destino inacessível.

Quando muda para essa mensagem, a navegação já está acontecendo. Com exceção no bate papo da uol.

DETALHE: de dentro do servidor pinga normal com ambos os links.

Somente com o link reserva e sem proxy não navega, mas tem ping do servidor pra fora.

O traceroute abaixo foi feito quando estava no link principal:

traceroute to globo.com (201.7.176.59), 30 hops max, 40 byte packets
1 172.16.130.217 (172.16.130.217) 5.474 ms 7.237 ms 7.050 ms
2 200.213.117.30 (200.213.117.30) 6.943 ms 44.596 ms 54.379 ms
3 200.213.117.1 (200.213.117.1) 98.664 ms 16.930 ms 11.051 ms

A questão é como fazer com que o link reserva faça ping também das estações. Isso acontecendo, com certeza o problema da sala de bate papo será resolvido. Já tentei vários atalhos e não deram certo, ainda.

m4tri_x
(usa Ubuntu)

Enviado em 12/09/2007 - 14:55h

estranho se do servidor pinga com ambos os links intão aparentemente esta funcionando a redundancia, se isso estiver acontecendo vai ser problema de firewall. dai acho que minimiza o problema, já que pelo seu teste pingou uma vez por um link, e depois sem alterar nda pingou do outro link.


vai ser alguma regra de liberação do icmp no firewall.

[]´s

:D
acho que agora ta perto de resolver.
me informa por favor :D

adircastro
(usa Debian)

Enviado em 12/09/2007 - 18:28h

matrix,

Quando está no link principal o ping acontece normalmente a partir da estação. Veja:
Resposta de 64.233.161.104: bytes=0 tempo=331ms TTL=238
Resposta de 64.233.161.104: bytes=0 tempo=355ms TTL=238

Quando mudo para o link reserva, há uma perda de no máximo 8 pacotes para que a navegação seja restabelecida, mas aí o ping continua apontando para o IP 172.16.130.218, assim:
Resposta de 172.16.130.218: Host de destino inacessível.
Resposta de 172.16.130.218: Host de destino inacessível.

Nesse momento usei o comando ip addr del 172.16.130.218 dev eth2, aí o ping com o link reserva normaliza e fica assim:
Resposta de 64.233.161.104: bytes=0 tempo=325ms TTL=238
Resposta de 64.233.161.104: bytes=0 tempo=265ms TTL=238

Veja que foi manualmente que derrubei a rota default anterior.

Mas aí, quando volto ao link principal, a mensagem de ping dele fica assim:
Resposta de 10.10.0.186: Host de destino inacessível.
Resposta de 10.10.0.186: Host de destino inacessível.

Há uma inversão dos problemas. E isso só pára quando manualmente derrubo a rota 10.10.0.186 e adiciono a rota default do principal:
ip addr add 172.16.130.218/24 dev eth2

Muito artesanal, sem contar que tenho que ficar na frente do monitor olhando quando cair.

Creio que seria resolvido, se houvesse um meio de derrubar a rota principal e levantar a rota secundária. Quando o link principal voltar, novamente derrubaria a rota secundária e levantaria a principal.

adircastro
(usa Debian)

Enviado em 13/09/2007 - 12:39h

Matrix e demais participantes,

Creio que agora, depois de mais de 75 dias, tenho algo que poderá se aproximar do que se chama redundância de link.

Ontem a noite fiz vários testes e o problema da sala de bate papo foi solucionado, quase que completamente. Em alguns momentos o erro de sempre aparecia. Mas uma coisa está acontecendo: o proxy transparente está funcionando para ambas as redes, sem necessidade de ir até o navegador e indicá-lo, quando troco de link.

No momento estou usando o link principal, ele ainda não caiu sozinho, para que eu tenha certeza de que o secundário entrará.

Manualmente, simulando quedas, o secundário entra. E o que é melhor, também faz ping pra fora. No início quando fiz a troca dos links, a rota que ele mostrava como host de destino inacessível era: 192.168.100.100, que é o IP local do meu servidor.

Ainda estou em testes, nada está definitivo. Mas pelo menos houve um progresso.

adircastro
(usa Debian)

Enviado em 13/09/2007 - 14:36h

Pessoal,

Acaba de acontecer uma queda do link principal e o secundário não entrou.

Parece que ele só entra se a gente sacar fora o cabo de rede da placa.

Bom, é mais um erro que terei que procurar descobrir, com a ajuda de vocês.

Hoje a noite farei uma nova sequência de testes...