contexto
Existem 2 servidores:
servidor1 - eth0 10.129.76.16 eth0.2 192.168.0.103
servidor2 - eth0 10.129.79.1 eth0.2 192.168.62.101
Os endereços 192.xxx estão conectados à mesma vlan (vlan2) e podem se ver. Os endereços 10.xxx estão conectados a diferentes vlans que não conseguem se ver.
a pedido de David Swartz: a tabela de roteamento no servidor 1 é:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
a tabela de roteamento no servidor 2 é:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
Problema:
Quando faço ping do servidor 1 para o servidor 2, parece que nenhum pacote está chegando e vice-versa. Quando verifico as rotas (route -n), vejo que o gw padrão usa eth0.2 em ambos os servidores. Mas quando uso arping, recebo uma resposta unilateral (do servidor 2 para o servidor 1), mas nenhuma resposta vice-versa.
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
Como você pode ver, ele usa o endereço 10.xxx em vez de 192.xxx. E como eu disse antes, o endereço 10.xxx está inacessível no outro servidor.
Quando forço o arping a usar eth0.2, ele funciona.
Não tenho problemas em fazer ping em outros servidores de nenhum desses 2 servidores.
Eu vi isso nas tabelas arp:
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
e
~# arp -n | grep 192.168.62.101
Pergunta
bastante óbvio... Como posso fazer com que esses servidores se vejam novamente?
Coisas que amarrei
limpe as entradas apropriadas no arptable e tente se livrar do (incompleto) Mas acho que o maior problema é que eth0 é usado em vez de eth0.2 para os pacotes do servidor 1 para o servidor 2
Por causa da observação de David Swartz sobre as tabelas de roteamento, adicionei uma rota definindo o host. Eu adicionei
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
e
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
para os servidores apropriados, mas isso não resolveu o problema, então presumo que o problema não esteja no roteamento.
Meu palpite
Acho que o problema está no seguinte.
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
mas não consigo remover esta entrada. (arp -d 192.168.0.103 não tem efeito)
Obrigado pela leitura e ainda mais obrigado por responder!
Responder1
Aqui está um trecho:
arpping não respeita a tabela de roteamento local:
== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess
use icmp para testar:
[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem
suas vlans estão bem?
[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
Responder2
Você não mencionou qual kernel está usando ou qual versão do arping, e existe a possibilidade de um bug em um ou outro. O fato de você poder arpingespecificar a subinterface com êxito indica que toda a rede da camada 2 está se comportando corretamente.
Tente usar ip route get 192.168.62.101no server1 para perguntar diretamente ao kernel como ele enviaria seu tráfego. Com base nas tabelas de roteamento que você postou, enviar via eth0.2 é claramente o comportamento correto e, se ip route getretornar uma resposta diferente, você pode estar diante de um bug do kernel. Se retornar a resposta correta, a culpa arpingé da culpa, mas isso parece improvável.
A (incomplete)entrada não precisa ser removida; é um espaço reservado que permite ao kernel saber que ele tentou ARP aquele IP, de modo que uma resposta ARP deve ser considerada válida e nãoum ataque de veneno ARP, mas que não obteve resposta. O tempo acabará.