ETH1:2 não responde ao meu IP da rede

kayk
(usa Outra)

Enviado em 12/09/2025 - 21:37h

Pessoal, gostaria de uma ajuda com um caso peculiar que estou tendo...Estou fazendo a configuração de um servidor CentOS 7.9.2009 para minha máquina que seja meu sbc. Neste servidor, tenho 5 interfaces, onde todas conseguem se comunicar com outros IP's da rede e tem os seus gateways em um mesmo equipamento. Entretanto, uma das interfaces, que é um PTP, não responde para o meu switch, e nem vice-versa.
Estou pegando ARP nos IP, mas não há resposta somente em uma das interfaces. O que pode estar ocorrendo? Já refiz alguma vezes as config das interfaces, mas mesmo assim não há comunicação.
Como teste, tirei o IP do server, e coloquei em windows server, e houve comunicação normalmente... O que será pode estar ocorrendo ?

alexabolada
(usa Debian)

Enviado em 12/09/2025 - 21:38h

Entendi. Vou ser objetiva. Suspeita forte: a interface foi configurada como PTP / sem ARP. Isso impede respostas ARP no link Ethernet. Vou listar checagens e correções.

Verifique estado e endereços da interface. Olhe se há "peer" ou /32 ou label PTP.

$ ip addr show dev eth1


Verifique vizinhança ARP na interface.

$ ip neigh show dev eth1


Capture pacotes ARP para ver se o servidor recebe requisições e se responde.

# tcpdump -n -i eth1 arp


Teste ARP ativo do servidor para o IP remoto.

# arping -I eth1 -c 4 <IP_do_switch_ou_peer></b>


Cheque link físico e velocidade/duplex.

[b]$ ethtool eth1


Verifique arquivos de config do CentOS (Network-Scripts). Procure por NOARP, POINTTOPOINT, ou máscara /32.

# cat /etc/sysconfig/network-scripts/ifcfg-eth1*</b>


Exemplo de configuração que quebra ARP. Se encontrar algo assim, é o problema:

DEVICE=eth1:2

IPADDR=192.168.1.10

NETMASK=255.255.255.255

NOARP=yes

 

Checar se há filtro L2 para ARP (ebtables) ou regras brutas.

[b]# ebtables -L</b]


Cheque políticas de sysctl que afetem ARP e roteamento (rp_filter, arp_ignore, arp_announce).

[b]# sysctl net.ipv4.conf.all.arp_ignore net.ipv4.conf.all.arp_announce net.ipv4.conf.all.rp_filter</b>


Possíveis causas e soluções rápidas.
- NOARP=yes ou configuração ponto-a-ponto.
Remova NOARP ou POINTTOPOINT. A interface precisa responder ARP.
Edite o ifcfg correspondente e reinicie rede.

[b]# vi /etc/sysconfig/network-scripts/ifcfg-eth1:2</b]


- Máscara /32 ou peer configurado.
Use máscara adequada (/24, /30 ou /31 conforme topologia).
Re-adicione o IP sem flag point-to-point.

[b]# ip addr add 192.168.1.10/24 dev eth1 label eth1:2</b]


- rp_filter (reverse path filter) bloqueando respostas em host multihomed.
Se for multihomed, tente desabilitar para a interface afetada.

[b]# sysctl -w net.ipv4.conf.eth1.rp_filter=0</b]


- arp_ignore/arp_announce mal configurados. Volte aos valores padrão (0).

[b]# sysctl -w net.ipv4.conf.all.arp_ignore=0</b]


- Ebtables ou outro filtro L2 bloqueando ARP. Limpe para testar.

[b]# ebtables -F</b]


Depois de ajustar, teste ARP com arping e capture com tcpdump.
Se o Windows com o mesmo IP funcionou, a camada física e o switch estão OK. Então a causa é configuração no CentOS (NOARP/PTP/netmask/sysctl/ebtables).

Se quiser, cole aqui o output de:

[b]$ ip addr show dev eth1


# cat /etc/sysconfig/network-scripts/ifcfg-eth1*


[b]# tcpdump -n -i eth1 arp -c 20</b>

Eu analiso e digo o que ajustar.