Olá Pessoal,
posso explicar porque nao funciona em alguns casos.
Algumas informações:
- o linux limpa de tempos em tempo o cache, remove rotas problematicas entre outras opcoes, tudo isso pode ser configurado (o tempo) nos arquivos em /proc/sys/net/ipv4/route
- o linux realmente balancea entre dois ou mais link com peso e outra opcoes.
- não é necessário nenhum patch, basta que tenha total suporte a iproute2 e suas opcoes de roteamento avançado no kernel.
Caso:
tenho um laboratorio completo aqui, fiz testes com 6 roteadores e 1 linux pra balancear, e o problema surgiu quando o NAT entrou no cenário, fora isso, tudo funcionou.
O problema aconteceu porque o NAT é uma técnica orientada a portas de conexoes UDP e TCP, e o que realmente acontece não é uma simples troca de endereço de origem/destino.
Quando um cliente 192.168.0.20 abre uma porta local alta (ex.: 9812) e se conecta em uma porta remota 80 na web, o linux faz uma assimilação da porta alta do cliente com uma porta alta local no ip da interface por onde o pacote sai, isso pode ser visto no iptraf, ou seja, o que acontece é isso:
192.168.0.20:9812 -----(linux 200.0.0.2:19218)-------> 200.160.2.3:80
Assim, quando um pacote da web retorna para a porta alta do linux aberta para um NAT, ele sabe que pode reescrever o destino e entregar para o cliente daquele NAT.
A porta alta do linux é escolhida aleatoriamente.
Agora suponha que o linux tem duas interfaces web (eth0 e eth1) e uma local (eth2) onde estão os clientes. na eth0 vc tem 200.0.0.2 e na eth1 201.20.0.3, se o cliente sobre NAT, quando ele for balanceado para a eth0 ele vai sofrer NAT com o ip 200.0.0.2 e uma porta local aleatoria, se sair pela eth1, vai sair com 201.20.0.3 com OUTRA PORTA aleatoria.
Problema: Se o host web 200.160.2.3:80 sabe que tem uma conexao estabelecida com 200.0.0.2:10284, ele só vai trocar informações nesse "tunel", ou seja, quando o cliente mudar de link e o pacote chegar da porta 201.20.0.3:49244 para 200.160.2.3, não haverá negociação porque o 200.160.2.3 não estabeleceu nenhuma conexão com esse ip nessa porta alta.
Agora, sempre que um cliente inicia uma conexão, o linux cria um cache da rota seguida da origem e do destino, esse cache tem um limite de registros e um tempo de vida (veja /proc/sys/net/ipv4/route/*). No caso do balanceamento, ele inicia efetivamente, mas quando o cache é limpo e o linux refaz o algoritmo de balanceamento, se o cliente mudar de interface de saida a conexao será perdida, o resultado disso é:
- downloads serão quebrados
- msn cai
- skype cai
- etc....
Solução:
1 - não usar NAT e balancear clientes com IP válido entre dois links de ip fixo contratado e totalmente roteados na internet (rotas conhecidas).
2 - balancear por serviços e não dinamicamente se for usar NAT.
3 - fazer a zona do balanceamento com NAT e aumentar o tempo de limpeza do cache para um valor muito alto.
entenderam?
