Como ex-membro da equipe principal do projeto LVS, desaconselharei strongmente o uso dessa tecnologia para balancear múltiplas conexões de internet; na verdade, quase posso garantir que não funcionará como esperado.
Agora, o tratamento de links de provedor com falha é geralmente chamado de detecção de gateway inativo (DGD) e, às vezes, é chamado de detecção de inacessibilidade de vizinho (NUD). De acordo com RFC816 e RFC1122 existem várias maneiras de realizar DGD, no entanto eu só vi cerca de 3 dos que estão em estado selvagem (de um post antigo meu para a lista de discussão do LVS):
- As informações da camada de link que detectam e relatam falhas de host com segurança (por exemplo, mensagens ARPANET Destination Dead) devem ser usadas como conselhos negativos.
- Uma mensagem de redirecionamento ICMP de um determinado gateway deve ser usada como um conselho positivo sobre esse gateway.
- Os pacotes que chegam de um determinado endereço de camada de link são evidências de que o sistema nesse endereço está ativo. No entanto, transformar essas informações em conselhos sobre gateways exige o mapeamento do endereço da camada de links para um endereço IP e a verificação desse endereço IP em relação aos gateways apontados pelo cache da rota. Isso é provavelmente proibitivo.
Quando deixei o desenvolvimento ativo de redes de kernel do Linux em 2006, ainda não havia uma decisão definitiva sobre como implementar mudanças de estado do NUD. Um amigo meu e desenvolvedor principal do LVS, Julian Anastasov, precisou resolver seu desafio em 2002. Então, uma noite, ele sentou-se e escreveu uma versão funcional do DGD para roteamento estático, adicionando o estado NUD ao FIB. base). Você pode encontrar o patch aqui e a documentação aqui , aqui e aqui . Isso deve lhe dar muitas informações sobre sua missão adicional ao abordar essa tarefa não trivial. Eu vejo que os patches ainda são muito usados e, portanto, mantidos atualizados com kernels recentes. Você pode querer começar com um script como o seguinte (escrito por Robert Kurjata ):
#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way
# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping
#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------
# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=
# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=
#ROUTING PART
# removing old rules and routes
echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221
# setting new rules
echo "Setting new routing rules"
# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main
# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static
${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static
# mutipath
${IP} rule add prio 221 table 221
${IP} route add default table 221 proto static \
nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
nexthop via ${EXTGW2} dev ${EXTIF2} weight 3
${IP} route flush cache
while : ; do
${PING} -c 1 ${EXTGW1}
${PING} -c 1 ${EXTGW2}
sleep 60
done
Além disso, você pode verificar a opção de executar protocolos de roteamento dinâmico.