Especificando uma rota preferida quando houver vários links para a mesma rede

Question

Eu tenho um servidor com várias interfaces e endereços IP na mesma rede. Eu gostaria que o tráfego não-iSCSI utilizasse exclusivamente uma das interfaces e, para o tráfego iSCSI, utilizasse exclusivamente o restante das interfaces. Limitar o tráfego iSCSI a um subconjunto de minhas interfaces é fácil; Eu simplesmente não crio entradas em / var / lib / iscsi / ifaces / para as interfaces que eu não quero que ele use. No entanto, não tenho certeza sobre qual é uma boa abordagem para limitar o tráfego não-ISCSI a uma interface. No que diz respeito ao linux, as interfaces iSCSI e não-iSCSI são igualmente boas rotas para a rede.

Aqui está uma configuração de exemplo

O armazenamento iSCSI tem os endereços IP 172.16.50.70-78.

O servidor tem as seguintes interfaces, endereços e rotas.

$ ip route list
149.76.12.0/24 dev eth0  proto kernel  scope link  src 149.76.12.4
172.16.0.0/16 dev eth1  proto kernel  scope link  src 172.16.50.80 
172.16.0.0/16 dev eth2  proto kernel  scope link  src 172.16.50.81 
172.16.0.0/16 dev eth3  proto kernel  scope link  src 172.16.50.82
default via 149.76.12.1 dev eth0

A configuração desejada é que o eth3 seja usado para tráfego não-ISCSI e que eth1 e eth2 sejam usados para tráfego iSCSI. No entanto, o tráfego não-iSCSI atualmente sai da eth1.

$ ip route get to 172.16.50.90
172.16.50.90 dev eth1  src 172.16.50.80

(algumas edições desde a postagem original abaixo)

Com minha configuração atual, se eth1 e eth2 estiverem totalmente saturadas enviando tráfego iSCSI, meu tráfego não-iSCSI irá competir com o tráfego iSCSI na eth1 enquanto o eth3 permanecer inativo.

Como eu configuraria o linux para preferir enviar tráfego para a rede local usando eth3 em vez de eth1 ou eth2?

Já configurei net.ipv4.conf.all.arp_ignore para 1 e net.ipv4.conf.all.arp_announce para 2. Isso deve impedir que meus endereços IP flutuem entre as interfaces, por exemplo, arp flux. Eu acho que só preciso de ajuda com o roteamento.

(mais edições)

Graças a pfo comecei a olhar para as métricas. Se eu excluir as rotas e recriá-las com as interfaces iSCSI com uma métrica mais alta do que a interface não-iSCSI, as coisas parecem funcionar da maneira que eu quero. O tráfego iSCSI ainda usa as interfaces dedicadas sem que eu configure rotas estáticas para os endereços IP do iSCSI. Todo o outro tráfego local sai da eth3. Agora preciso descobrir a maneira correta de definir as métricas automaticamente quando as interfaces são ativadas. Isso está no RHEL 5.5.

ip route delete to 172.16.0.0/16 dev eth1
ip route delete to 172.16.0.0/16 dev eth2
ip route delete to 172.16.0.0/16 dev eth3
ip route add to 172.16.0.0/16 dev eth1 src 172.16.50.80 metric 1
ip route add to 172.16.0.0/16 dev eth2 src 172.16.50.81 metric 1
ip route add to 172.16.0.0/16 dev eth3 src 172.16.50.82 metric 0

(atualização final)

Atribuir uma métrica diferente usando os scripts de rede RHEL existentes parece impossível, link

    

Answer 1

Para resolver meu problema, eu escrevi nethook , um daemon que executa scripts quando as interfaces de rede mudam de estado nas distribuições baseadas no RHEL. Eu tenho que executar este script para interfaces cuja métrica da rota eu quero aumentar.

EDIT: Eu escrevi nethook antes de eu estar ciente de ifup-local e ifdown-local . Provavelmente você pode usá-los.

    

Answer 2

Existem algumas coisas para se ter em conta quando você é um host multi-homing. A primeira coisa é que você precisa estar ciente da maneira como a pilha TCP / IP do Linux lidará com várias interfaces que estão na mesma sub-rede em relação a consultas e respostas ARP - essa configuração é o valor arp_filter da interface que você pode consultar via sysctl(1) ou o sistema de arquivos /proc .

0 - (padrão) A pilha TCP / IP responderá às solicitações ARP com endereços de outras interfaces. Isso pode parecer errado, mas geralmente faz sentido, porque aumenta a chance de uma comunicação bem-sucedida. Os endereços IP são de propriedade do host completo no Linux, não por interfaces particulares.

1 - Permite que você tenha várias interfaces de rede na mesma sub-rede, e que os ARPs de cada interface sejam respondidos com base no fato de o kernel encaminhar ou não um pacote do ARP-IP para aquela interface. Em outras palavras, ele permite controlar quais NICs responderão a uma solicitação ARP e, finalmente, permitirão que seus fluxos TCP / IP sejam executados.

Você deve primeiro ativar o arp_filter em todas as interfaces que estão na mesma sub-rede e pode facilmente adicionar uma entrada à sua tabela de roteamento para o seu portal iSCSI para usar uma iface específica e ajustar a outra métrica de interfaces para que seja preferível um sobre o outro.

Outra opção é configurar o roteamento baseado em origem, já que o roteamento baseado em destino padrão funcionará exatamente como você descreveu em todos os ifaces que estão na mesma sub-rede.

A razão pela qual a eth1 é retirada é que o IP tem o menor valor numérico e é escolhido para comunicação com essa rede.