0

Please excuse the long description here, but I think it's worth explaining the setup before asking the question:

I have 2 usb Ethernet devices connected to my machine (debian) which configure themselves through avahi with 169.254.x.x addresses.

Connected to the other side of each usb ethernet device is a ssh host (host1 and host2)

When either host1 or host2 is connected via its device I can ssh to to host1.local or host2.local fine.

When both are connected I can only connect to host1.local OR host2.local (I get host unknown/unreachable and similar messages)

If I run 

ifconfig

I see that both interfaces are up and have IP addresses

If I run 

ip route show

I see that there are two matching routes setup as follows

169.254.0.0/16 dev eth0 scope link src 169.254.3.232 metric 212 169.254.0.0/16 dev eth1 scope link src 169.254.79.120 metric 213

So I think what's happening here is that one of these routes is picking up all traffic in the zeroconf range and sending it to one of the devices, meaning that when both are plugged in only one responds as the traffic is only right for host at the end of that device.

To test this I try deleting the route to the device that is working to allow the other route to take over and send traffic to the other device BUT all variants of the route delete command I've tried seem to do nothing, the route stays in place.

Instead, if I run this the route to eth0 (which host1 is connected to) does go (get deleted) along with all other settings for the device (such as ip, which is expected). host1.local stops responding and host2.local starts responding where it wasn't before proving the theory.

ip addr flush dev eth0

So my solution is then to try and delete these auto-created generic routes that are trumping everything, and to put in more specific routes to the devices (I should add each host does have a fixed IP).

So something like

ip route add 169.254.102.0/24 dev eth0 ip route add 169.254.116.0/24 dev eth1

or even

ip route add 169.254.102.23/32 dev eth0 ip route add 169.254.116.74/32 dev eth1

BUT this doesn't quite work as doing ip addr flush as a way of forcing the route to be removed is too harsh - the routes go in but the interfaces are very much down due to being flushed.

So my question(s) are:

  • Why might all variants of ip route del NOT remove the bad routes?

  • Is there another way of removing routes other than using the ip command?

How else might I solve this problem:

  • Would bridging the interfaces so they work somewhat like a loadbalancer make more sense as a solution?

  • Have I totally missed something else I should try in order to make routing more specific (maybe in terms of how zeroconf/avahi sets up these connections)?

Improve this question
0

1 Answer 1

Reset to default
0

It is not recommendable changing the network of those routes; they will also will be refresh again by avahi, and at best will return to the latter masks, at worst, there will be a mess of routes/masks.

Also, I would advise stopping to obsess about routing zeroconf/Automatic Private addresses. They are local to a network, and are not routable by definition.

I would advise doing it by the book, and using private RFC 1918 IP addresses.

Improve this answer
3
  • On the first point - these devices are not constantly disconnected and reconnected so avahi will not refresh them, so that is not an issue for me. On the second point I'm not looking to route these beyond the private network, there is no obsession for such there. I'm just trying to get traffic from the machine they are plugged into to them, but these default routes get in the way of communicating to both devices. Commented Nov 2, 2019 at 11:41
  • I would stop trying to rationalize abusing those automatic addresses and do as the rest world does, setting up proper private IP RFC 1918 addresses. Commented Nov 2, 2019 at 11:47
  • You're right. What I hadn't quite considered was that zeroconf/avahi or not these devices are still regarded as just ethernet devices so it is possible to configure them statically as needed, as you would any other interface (so long as zeroconf is blocked from trying to configure them first (deny interfaces in dhcpcd) or dhcpcd is off). I had it in my head that zeroconf was required for these to be recognized at all but that is not the case. Commented Nov 4, 2019 at 11:00

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.