O balanceamento de links com o Iproute 2 tem alguns inconvenientes, quando a coisa entra no campo da alta disponibilidade dado ao fato que o cache de rotas é vinculado a cada uma das interfaces de rede lógicas, então faz-se necessário o emprego de scripts para testar o estado das conexões, excluir rotas inoperantes, limpar o cache e conforme o caso alterar marcas de pacotes, o resultado além de ser uma gambiara muito deselegante é pouco eficiente.

O Bonding Driver por sua vez é excelente no balanceamento e redundância, porém não é usado para manipular rotas, visto que trabalha unicamente na camada 2, semelhante as bridges, na verdade foi desenvolvido para aumentar a largura de banda de conexões de controle em Clusters Beowulf e o seu criador não pensava em aplica-lo para a finalidade que proponho.

A Necessidade

Durante um bom tempo empreguei o balanceamento de carga com Iproute 2 e marca de pacotes, desviando o tráfego por cada rota de acordo com a conveniência de cada cliente, mas de uns anos para cá o perfil de utilização da internet mudou muito.

A alguns anos eu atribuía uma marca para o tráfego podre (P2P, etc. Na verdade tudo) com uma exceção para o tráfego nobre (http, https e DNS), para que saísse pela rota default, a coisa as vezes mudava um pouco dependendo de número de links e tipos de serviço mas basicamente era a mesma coisa.

Mas o perfil de uso da internet mudou, e o que era nobre acabou apodrecendo, principalmente por conta do conteúdo dinâmico de sites como o Youtube que quase tornaram o bom e velho Squid obsoleto, sendo necessário o emprego de soluções de url rewriter que trabalham em conjunto com o Squid, tais como o Thundercache e o InComum (este último é excelente e muito fácil de implementar, venho usando ele a mais de 1 ano com muita satisfação! Recomendo! http://incomum.sourceforge.net).

Recentemente tive que rever a política de balanceamento de carga de um de meus clientes e deparei-me com os problemas que mencionei acima então resolvi contorná-lo com o emprego do iproute2 usando uma única interface de rede, o resultado foi sofrível.

Embora conceitualmente correto, e até funcionou muito bem em testes com máquinas virtuais, as causas não tive tempo nem recursos para avaliar. Até suspeito de alguma implementação em um de seus roteadores algo como um rp_filter ou algum mecanismo anti-spoof, mas não foi possível constatar visto que seus roteadores estão sob regime de comodato e não tenho acesso a eles.

Então parti para uma bridge agregando as interfaces de rede de saída, funcionou relativamente bem, entretanto a rede apresentava latência alta e alguma instabilidade quando o tráfego aumentava e a redundância não funcionou.

Foi aí que me ocorreu ao invés de empregar uma bridge empregar o Bonding Driver nativo do Kernel, afinal ele foi feito para isso! Para alegria de todos os resultados foram excelentes tanto para o balanceamento quanto para a redundância!