O Linux está enviando solicitações ARP para hosts em outras sub-redes?

2

Configuração

Host B <--> Router <--> Host A
  • Host A: IP = 192.168.1.10, Net = 192.168.1.0/24, VLAN = 1, Padrão GW = 192.168.1.1 (Roteador)
  • Host B: IP = 192.168.2.10, Net = 192.168.2.0/24, VLAN = 20, GW padrão = 192.168.2.1 (Roteador)
  • Roteador: IP = 192.168.1.1, 192.168.2.1, VLAN = 1, 20

Todos os dispositivos estão conectados a um switch com essas VLANs configuradas.

Teste de ping

Agora, se eu tentar fazer o ping do host A do host B, ocorrerá o seguinte: O host B faz uma solicitação ARP para descobrir o endereço MAC do roteador e envia a solicitação de ping ao roteador. O roteador também faz uma solicitação ARP para descobrir o endereço MAC do host A de destino e encaminha a solicitação Ping para o Host A. Tudo bem e isso funciona.

Solicitações ARP para outra sub-rede ??

Agora, a parte estranha: o Host A, é claro, tenta responder ao Ping, mas (!) ele não faz uma solicitação ARP para descobrir o endereço MAC do roteador para enviar a Resposta Ping para encaminhá-lo para o Host B. Em vez disso, ele envia um pedido ARP solicitando o endereço MAC do Host B diretamente. É claro que isso não funciona, não haverá resposta na sub-rede local, porque o domínio de broadcast está restrito à VLAN 1.

O cache ARP no host A (192.168.1.10) se parece com isto:

# arp -an
? (192.168.1.1) at 16:bc:aa:f2:bc:44 [ether] on eth0
? (192.168.2.10) at <incomplete> on eth0

Quando tento excluir a estranha tentativa de resolução de ARP, recebo esta mensagem e a tentativa falha de ARP ainda está no cache:

# arp -d 192.168.2.10
SIOCDARP(dontpub): Network is unreachable

Redirecionamentos ICMP do roteador

Portanto, nenhuma comunicação (bidirecional) entre o Host A e B é possível. E, em vez de Respostas Ping, o Host B recebe uma Solicitação de Redirecionamento ICMP do roteador: O Host B deve enviar pacotes diretamente para o Host A.

Minhas perguntas

  1. O que faz o Host B tentar enviar uma resposta do ARP resolvendo um host de outra sub-rede? Por que o Ping-Reply não é enviado ao roteador?
  2. Alguma idéia de qual papel o ICMP-Redirect desempenha?

Apêndice

Anfitrião A

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether ab:cd:a9:9a:cc:dc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether ab:cd:a9:9a:cc:dd brd ff:ff:ff:ff:ff:ff

# ip r s
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.10

Anfitrião B

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 40:7d:7a:a3:f5:dd brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.10/24 brd 192.168.2.255 scope global eth0
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 47:5e:33:a6:31:5e brd ff:ff:ff:ff:ff:ff

Roteador

Tabela de roteamento:
Destination-IP   Subnet mask      Default gateway   Hop count     Interface
<public-net>     255.255.255.224  *                 0             eth2   
<public-net>     255.255.255.224  *                 0             eth1   
192.168.1.0      255.255.255.0    *                 0             eth0   
192.168.2.0      255.255.255.0    *                 0             eth0   
default          0.0.0.0          <public-router>   15            eth1   
default          0.0.0.0          <public-router>   40            eth2   
default          0.0.0.0          <public-router>   40            eth1

public-net ...... Endereço da sub-rede pública (internet-uplink)

public-router ... Endereço do uplink-router

O roteador é um Cisco RV320 com interface web, isso é tudo que posso obter. PS: É uma configuração de dual uplink de balanceamento de carga, mas isso não deve fazer diferença para o problema ARP.

    
por Deputy Rock 07.01.2015 / 02:28

3 respostas

1

A tabela de roteamento no roteador parece incorreta. Parece que você está executando a VLAN desmarcada no roteador.

Eu não sei como o switch consegue entregar pacotes do roteador para A e B, quando o roteador aparentemente envia todos os pacotes para o switch sem nenhuma indicação de qual VLAN eles pertencem. O switch que estou usando não seria capaz de fazer isso. Mas talvez você esteja usando uma marca de switch que pode de alguma forma adivinhar corretamente para qual VLAN enviar os pacotes.

No entanto, do ponto de vista de roteadores, A e B estão no mesmo segmento de Ethernet, o que significa que o roteador deve instruir A e B a se comunicar diretamente sem envolver o roteador. E é aí que a comunicação é quebrada.

As entradas da tabela de roteamento com esta aparência:

192.168.1.0      255.255.255.0    *                 0             eth0   
192.168.2.0      255.255.255.0    *                 0             eth0   

Deveria estar de fato assim:

192.168.1.0      255.255.255.0    *                 0             eth0.1     
192.168.2.0      255.255.255.0    *                 0             eth0.20    

As interfaces virtuais eth0.1 e eth0.20 podem ser criadas com os comandos:

vconfig add eth0 1
vconfig add eth0 20
    
por 07.01.2015 / 10:15
1

Encontrei uma solução para mim: coloquei o Host A e a sub-rede 192.168.1.0/24 na nova VLAN com o ID 10. Agora está tudo bem. Está tudo bem para minha configuração geral, mas ainda estranho, que não estava funcionando com VLAN ID 1. Talvez o roteador seja o problema e ele trata a VLAN 1 de uma maneira especial. Mas como isso afetaria o comportamento do Linux ARP? Ainda uma pergunta.

    
por 07.01.2015 / 15:41
0

O comportamento que você está vendo com a VLAN-1 geralmente é porque essa vlan id é a vlan de gerenciamento no switch que está desmarcada.

    
por 25.07.2017 / 04:16