Problema de roteamento de rede para o gateway - o ping não funciona a menos que a opção -R seja usada

1

Eu tenho um servidor de hardware, não uma VM. Instalou uma distro Linux proprietária (a distro proprietária do Linux é da minha própria empresa - é baseada no Centos 6.4).

Eu instalei a distro Linux em 10 servidores de hardware. Em 9 deles, a rede funciona bem - eu posso pingar outros hosts e o gateway (10.213.42.1)

Mas em um deles, não consigo fazer ping no gateway. Eu tentei editar o arquivo ifcfg-em4, excluído e adicionado a rota padrão, ifdown, em seguida, ifup a interface.

O problema é que não consigo fazer ping no gateway. Portanto, não consigo acessar hosts que não estão na sub-rede 10.213.42.X e os hosts que não estão na sub-rede 10.213.42.X não podem acessar este servidor.

Eu fiz um ping no gateway e ele falha:

[root@per730-22 ~]# ping -c 3 -I em4  10.213.42.1
PING 10.213.42.1 (10.213.42.1) from 10.213.42.107 em4: 56(84) bytes of data.
--- 10.213.42.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

No entanto, se eu usar a opção Rota para o ping, o ping para o gateway é bem-sucedido:

[root@per730-22 ~]# ping -c 3 -I em4 -R  10.213.42.1
PING 10.213.42.1 (10.213.42.1) from 10.213.42.107 em4: 56(124) bytes of data.
64 bytes from 10.213.42.1: icmp_seq=1 ttl=255 time=1.36 ms
RR:      10.213.42.107
         10.213.42.1
          10.213.42.107

64 bytes from 10.213.42.1: icmp_seq=2 ttl=255 time=1.48 ms        (same route)
64 bytes from 10.213.42.1: icmp_seq=3 ttl=255 time=1.38 ms        (same route)
--- 10.213.42.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.365/1.411/1.485/0.068 ms

Esta é minha tabela de rotas:

[root@per730-22 ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.213.42.1     0.0.0.0         UG    100    0        0 em4
10.213.42.0     0.0.0.0         255.255.255.0   U     100    0        0 em4
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

A tabela de rotas acima é a mesma que a tabela de rotas nos outros 9 hosts que não têm esse problema.

Existe alguma porta de rede ou processo que está inativo e, portanto, causando falha no ping? O firewall está desativado. Mas existe uma maneira (maneira Centos) de verificar se uma resposta de ping do gateway pode ser recebida nesse host problemático?

==== ADDENDUM ====

Consegui instalar o tcpdump no host do problema fazendo o download do RPM em um host e, em seguida, copiando-o para o host do problema usando um dispositivo USB.

Eu liguei o tcpdump enquanto fazia o ping. Como um assunto de controle, eu também tornei o tcpdump em um host que não tem problemas com o ping do gateway.

Este é o host de controle. Não tem problemas para acessar o gateway e você pode ver que o pedido ICMP sai e uma resposta volta.

[root@per730-20 ~]# tcpdump -i em4 host 10.213.42.1 -s0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em4, link-type EN10MB (Ethernet), capture size 262144 bytes
16:01:45.276511 ARP, Request who-has 10.213.42.92 (Broadcast) tell 10.213.42.1, length 46
16:01:45.276998 ARP, Request who-has 10.213.42.51 (Broadcast) tell 10.213.42.1, length 46
16:01:45.277412 ARP, Request who-has 10.213.42.73 (Broadcast) tell 10.213.42.1, length 46
16:01:46.189569 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 1, length 64
16:01:46.189714 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 1, length 64
16:01:46.281455 ARP, Request who-has 10.213.42.60 (Broadcast) tell 10.213.42.1, length 46
16:01:47.191247 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 2, length 64
16:01:47.191427 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 2, length 64
16:01:48.192302 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 3, length 64
16:01:48.192476 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 3, length 64
16:01:49.192285 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 4, length 64
16:01:49.192464 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 4, length 64
16:01:50.192285 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 5, length 64
16:01:50.192468 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 5, length 64
16:01:51.192909 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 6, length 64
16:01:51.193091 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 6, length 64
16:01:52.192288 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 7, length 64
16:01:52.192448 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 7, length 64
16:01:53.192285 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 8, length 64
16:01:53.192466 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 8, length 64
16:01:54.193412 IP per730-20-pub > 10.213.42.1: ICMP echo request, id 33554, seq 9, length 64
16:01:54.193594 IP 10.213.42.1 > per730-20-pub: ICMP echo reply, id 33554, seq 9, length 64

Este é o host do problema. Você pode ver que a solicitação ICMP é enviada, mas não há nenhuma resposta ICMP sendo recebida.

[root@per730xd-11 opt]# tcpdump -i em4 host 10.213.42.1 -s0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on em4, link-type EN10MB (Ethernet), capture size 262144 bytes
15:45:19.992715 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 1, length 64
15:45:20.991775 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 2, length 64
15:45:21.991799 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 3, length 64
15:45:22.991805 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 4, length 64
15:45:23.991835 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 5, length 64
15:45:24.991807 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 6, length 64
15:45:24.995807 ARP, Request who-has 10.213.42.1 tell per730xd-11-pub, length 28
15:45:24.997735 ARP, Reply 10.213.42.1 is-at 00:00:5e:00:01:01 (oui IANA), length 46
15:45:25.991793 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 7, length 64
15:45:26.991831 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 8, length 64
15:45:27.991800 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 9, length 64
15:45:28.991793 IP per730xd-11-pub > 10.213.42.1: ICMP echo request, id 49616, seq 10, length 64

Eu também executei o tcpdump com a opção '-e' para checar se o endereço MAC correto da interface (em4) estava sendo usado. Isto é. O MAC (o número de ether) da interface é aquele para o qual o pedido de ICMP está sendo enviado. O MAC do gateway também corresponde à entrada na tabela ARP.

Estou perdido porque não estou recebendo uma solicitação ICMP. O iptables foi liberado. Selinux desativado. firewalld desativado. Existe uma porta que devo configurar para o ping?

    
por SQA777 31.10.2018 / 03:23

0 respostas

Tags