I don't know if this is related to a problem I have run into and posted elsewhere regarding 2 (or more) ethernet ports. But I encountered this while trying to solve the other problem (which I thought was Linux not setting correct routes for 2 interfaces).

As suggested by someone when trying to solve the other problem, I switched to using the same IP address (it's a secondary address) on BOTH interfaces. So thus I have configured 172.30.0.13 on both eth0:1 and eth1:1. I am running the NSD program (an authoritative-only name server) listening on port 53 of 172.30.0.13. Some computers are getting the MAC address of eth0 for their ARP requests. Others are getting the MAC address of eth1 for their ARP requests. So this is determining which ethernet port their DNS queries will arrive on.

Those that send their DNS queries to the eth0 MAC address work fine. The NSD process gets the requests and answers them. The answers get back to where the query was sent from.

HOWEVER ... those that send their DNS queries to the eth1 MAC address do not work. Using tcpdump, I see that the queries actually do arrive on the server. Using strace, I see that the NSD process never gets them. There are no iptables in effect.

Any idea why the kernel is deciding to not deliver the DNS query UDP datagram to the NSD process?

It sure seems that the kernel just doesn't handle more than 1 ethernet interface (at least in the same subnet) correctly.

IMHO, when an ARP request is received on 2 or more different interfaces, it should at least answer on both, each answer with the respective MAC address of that interface. It cannot know, and should not assume, any specific physical topology of the network beyond those interfaces.

Putting the same IP on multiple interfaces is generally a bad idea and makes strange things happen. ;^)

I know that doesn't help, but sounds like the packet is getting dropped for some reason, might be the kernel, or ???

Output from tcpdump may prove helpful here as well.

What was the other problem you were having that setting the same secondary IP on multiple interfaces solved? Perhaps there is a different solution that will cure this issue as well as the other one.

1 members found this post helpful.