Como posso obter o linux para homenagear a nova máscara de rede sem reiniciar o subsistema de rede?

Question

Eu não tenho certeza de que "honra" é a palavra certa para isso, mas é o melhor que eu poderia fazer. Eu tenho um cenário em que tenho dois servidores na mesma rede. Eles têm IPs primário e secundário, todos na mesma sub-rede. Por uma questão de discussão, eles se parecem com isso:

server1    eth0    172.16.45.3/24
server1-A  eth0:11 172.16.45.21/27
server1-B  eth0:12 172.16.45.22/27

server2    eth0    172.16.45.4/27

Sim, o servidor1 está definido como / 24 e sim, é um erro.

Eu notei esse problema porque as conexões do server1- > server2 tinham um IP de origem de 172.16.45.21 em vez de 172.16.45.3. Como o aplicativo que originou a conexão não especifica um IP de origem, fiquei chocado por não estar usando 172.16.45.3.

Foi quando notei a máscara de rede incorreta. Como o IP de destino está em uma rede menor conhecida, ele usa um IP do mesmo / 27 em vez do IP que acha que é de um / 24. Opa.

Então, eu consertei a netmask no server1: eth0 executando o seguinte comando:

ifconfig eth0 netmask 255.255.255.224

ifconfig parecia feliz também:

eth0      Link encap:Ethernet  HWaddr 00:22:19:54:EF:11  
          inet addr:172.16.45.3  Bcast:172.16.45.31  Mask:255.255.255.224
          inet6 addr: fe80::222:19ff:fe54:ef11/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1085587580 errors:0 dropped:1355 overruns:0 frame:0
          TX packets:1208356392 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:365708046601 (340.5 GiB)  TX bytes:667099868812 (621.2 GiB)
          Interrupt:169 Memory:f8000000-f8012100 

Além disso, a tabela de roteamento se limpou.

Antes:

server1 0 /home/jj33 ># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.45.0     0.0.0.0         255.255.255.224 U     0      0        0 eth0
172.16.45.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         172.16.45.1     0.0.0.0         UG    0      0        0 eth0

Depois:

server1 0 /home/jj33 ># route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.45.0     0.0.0.0         255.255.255.224 U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         172.16.45.1     0.0.0.0         UG    0      0        0 eth0

O único problema é, depois de tudo isso, o sistema operacional ainda parece escolher 172.16.45.21 como o endereço de origem para conexões de saída para a mesma rede (SMTP não figura diretamente neste problema, apenas uma forma conveniente de mostrar o IP de origem de uma conexão):

server1 0 /home/jj33 ># telnet server2 25
Trying 172.16.45.4...
Connected to 172.16.45.4.
Escape character is '^]'.
220 server2.example.com ESMTP mailer ready at Wed, 23 Dec 2009 12:18:28 -0600
ehlo foo
250-server2.qcommcorp.com Hello server1-A.example.com [172.16.45.21]
250 HELP

(caso não seja óbvio, eu esperaria que o mailer dissesse "Hello server1.example.com [172.16.45.3]" em resposta ao meu ehlo se tudo estivesse funcionando corretamente).

Então, agora a minha pergunta. Como posso fazer com que meu SO perceba que a máscara de rede em eth0 foi alterada, de modo que é uma opção melhor para conexões de saída para meu local / 27? Eu presumo reiniciar o servidor ou reiniciar serviços de rede faria isso, mas eu teria que esperar uma semana até a próxima janela de manutenção e parece algo que eu poderia fazer sem interromper o serviço (este é um sistema de produção e este IP de origem incorreto é um pequeno problema tangencial - o aplicativo principal está funcionando bem).

Qualquer ajuda muito apreciada. Obrigado!

ATUALIZAÇÃO em 1/8/2010:

Portanto, esse problema chamou mais a atenção do que eu esperava e acabei conseguindo permissão para fazer o failover do aplicativo no silo de espera e reiniciar os serviços de rede no servidor afetado fora de nossa janela padrão, ou seja, não posso testar nenhum das teorias abaixo.

Em geral, acredito que A resposta de Juliano cobriu o maior detalhe. Eu não copiei e colei, mas ao jogar com ip, geralmente parecia corroborar o que ele postulava.

Além disso, muitas pessoas empilharam sobre o uso do ip em preferência ao ifconfig que eu passei algum tempo jogando com ele e inclino o meu chapéu para todos vocês, eu certamente deveria estar usando o ip. Obrigado pelos ponteiros.

    

Answer 1

Primeiramente, não use ifconfig e route . Esses comandos são geralmente considerados obsoletos hoje em dia; eles foram escritos há muito tempo atrás quando o Linux tinha uma pilha de rede muito diferente, e foram corrigidos desde então. A própria idéia de aliases de interface (por exemplo, ethX: YY ) para ter vários endereços está obsoleta hoje, eles ainda existem principalmente para agradar ao ifconfig. Hoje, o comando ip deve satisfazer todas as suas necessidades.

Agora, entenda sua situação original: Sua interface eth0 originalmente tinha dois escopos ativos: / 24 e / 27. 172.16.45.3 era o endereço principal para o escopo / 24, enquanto 172.16.45.21 era o endereço principal do escopo / 27 (porque é listado primeiro). Quando você emitiu o comando ifconfig para alterar o prefixo do primeiro endereço, ele foi excluído e reinserido como um endereço secundário no escopo / 27. Então agora você deve ter algo assim:

inet 172.16.45.21/27 brd 172.16.45.31 primary   eth0:11
inet 172.16.45.22/27 brd 172.16.45.31 secondary eth0:12
inet 172.16.45.3/27  brd 172.16.45.31 secondary eth0

Não importa que a eth0 deva ser primária, ou que pareça que deve ser primária (outra razão para não usar o ifconfig). Foi inserido posteriormente no escopo / 27, portanto, é um endereço secundário. Isso também significa que os pacotes de saída serão endereçados 172.16.45.21, e que se você reduzir eth0: 11 usando ifconfig, all seus endereços serão removidos juntos. É assim que funciona.

A única maneira de corrigir isso é remover todos os endereços da interface e reinseri-los na ordem correta. Em seguida, o primeiro endereço adicionado (no escopo / 27) será o endereço principal nesse escopo, e os demais endereços serão secundários.

O endereçamento já estava quebrado desde o começo, não havia muito o que você poderia fazer nessa situação. Sua melhor solução é apenas reiniciar o serviço de rede.

Uma solução possível é alterar o endereço de roteamento de origem. Isso terá quase o mesmo efeito de alterar o endereço principal. No seu caso:

ip route change 172.16.45.0/27 dev eth0 src 172.16.45.3

Neste caso, os pacotes enviados para 172.16.45.0/27 terão o endereço de origem configurado para 172.16.45.3. Você precisará de outro comando se também quiser alterar a origem dos pacotes que passam pelo gateway.

    

Answer 2

Eu tive um problema semelhante (dois servidores com eth0 e eth1 no mesmo segmento de ethernet) e não consegui descobrir como forçar uma fonte no meu caso. No entanto, você pode tentar esse tipo de abordagem para forçar o ip de origem no seu caso:

ip route add dev eth0 src 172.16.45.3 172.16.45.4 metric 2

Trata-se de métrica novamente, mas incluindo a fonte na equação. Na minha configuração inicial, permitia-me escolher um ip diferente para se conectar ao meu servidor em comparação com o que o kernel escolheria por padrão.

    

Answer 3

Você não disse qual distribuição está usando. Você deve alterar os arquivos de configuração e usar algum tipo de script para recarregar as configurações de rede. (Se você pular esta etapa, suas configurações serão perdidas após a reinicialização).

A segunda coisa é que hoje em dia a ferramenta ip é preferida ao ifconfig no linux. Com ip você pode adicionar e remover endereços IP on-the-fly.

    

Answer 4

Já tentou definir as métricas com ifconfig?

metric n Set the routing metric of the interface to n, default 0. The routing metric is used by the routing protocol. Higher metrics have the effect of making a route less favorable; metrics are counted as addition hops to the destination network or host.

Link

Basicamente, você prefere usar um NIC em vez de outro. Tente definir os links A e B para ter uma métrica de 1.

    

Answer 5

Não tenho certeza se eu entendi, mas talvez você possa fazer algo como

route add -net 172.16.45.0/27 dev eth0

Isso força todas as conexões a essa sub-rede a passarem pela eth0 que possui o endereço IP que você mencionou.