0

This question already has an answer here:

Oracle Linux 7

I have several database hosts with interfaces on a "management" subnet and a "database" subnet. The default gateway for each is on the database subnet. I can talk to most hosts via the managment subnet, but one won't reply.

Let's say the DBASE subnet is 10.10.24.0/24 and the MGMT subnet is 10.10.35.0/24. The default gateway is 10.10.24.1 on the DBASE subnet. None of the hosts list the MGMT subnet router as a gateway, default or otherwise. Outside of multi-homed hosts like these, the two subnets can NOT talk to each other, and ip_forward is turned off on all hosts.

After a lot of experimentation, I found a great way to include interface names with tcpdump output.

What I found is that the GOOD hosts reply on the MGMT interface to packets coming in via the MGMT interface.

The BAD host replies on the DBASE interface with its MGMT IP address! So traffic comes in on the MGMT side and replies go out the DBASE side. But, they still go back out with the host's MGMT IP address. So, of course the routers drop the packet immediately.

I can't even think of how to phrase the Google search. Does a setting exist that forces the kernel to reply to packets via the same interface that it received the initial requests on?

UPDATE 1: The proposed duplicate/solution assumes that my working hosts are working because a customized route was created. That is not true. I have hosts working as intended without customized routes. I would like to find a solution that does not require customizing the routes for this exception.

UPDATE 2: Sample output

[MGMT] 14:30:53.743561 IP 10.10.DSK.TOP > 10.10.24.XXX: ICMP echo request, id 3926, seq 1, length 64
[DBASE] 14:30:53.743674 IP 10.10.24.XXX > 10.10.DSK.TOP: ICMP echo reply, id 3926, seq 1, length 64
[MGMT] 14:30:54.742998 IP 10.10.DSK.TOP > 10.10.24.XXX: ICMP echo request, id 3926, seq 2, length 64
[DBASE] 14:30:54.743039 IP 10.10.24.XXX > 10.10.DSK.TOP: ICMP echo reply, id 3926, seq 2, length 64
[DBASE] 14:30:55.743069 IP 10.10.24.XXX > 10.10.DSK.TOP: ICMP echo reply, id 3926, seq 3, length 64
[MGMT] 14:30:55.743024 IP 10.10.DSK.TOP > 10.10.24.XXX: ICMP echo request, id 3926, seq 3, length 64
[MGMT] 14:30:56.743009 IP 10.10.DSK.TOP > 10.10.24.XXX: ICMP echo request, id 3926, seq 4, length 64
[DBASE] 14:30:56.743058 IP 10.10.24.XXX > 10.10.DSK.TOP: ICMP echo reply, id 3926, seq 4, length 64
[MGMT] 14:30:57.742888 IP 10.10.DSK.TOP > 10.10.24.XXX: ICMP echo request, id 3926, seq 5, length 64
[DBASE] 14:30:57.742970 IP 10.10.24.XXX > 10.10.DSK.TOP: ICMP echo reply, id 3926, seq 5, length 64

UPDATE 3: I have found a difference in the details of the default routing. Here's the ip route output from a host that works:

default via 10.10.35.1 dev DBASE

Here's the one that fails

default via 10.10.35.1 dev DBASE proto static

Looking at the ip man page, I see that the static protocol "was installed by the administrator to override dynamic routing." At install time, I set ipv4.gateway 10.10.35.1 with nmcli on the DBASE interface, and ipv4.never-default true on the MGMT interface. (Incidentally, an interface cannot have an ipv4.gateway and ipv4.never-default. Setting the latter will unset the former.)

I'm going to guess that a reboot will be part of the solution to get back to proto kernel ("the route was installed by the kernel during autoconfiguration"). What settings do I need to verify so the kernel won't conclude the default route is still static?

marked as duplicate by Rui F Ribeiro, Jesse_b, Kiwy, schily, slm Aug 2 '18 at 16:48

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.