There is a possible race condition in _add_route that is causing"ip route add" to add a route before the "ip addr add" command takes effect. It appears to happen at random on multi-homed hosts. When it does happen, the affected interface has an address, but no default route.
I need a LOT more context on where you're seeing this. _add_address calls 'ip addr add' and does check the return code. From net.lo, _add_route is called much later than _add_address.
A similar thing just happened to me on a multi-homed system, though specifically with multiple IPv6 addresses and a preferred source address in ip route. Since the kernel checks whether a source address is actually configured on an interface (I'm assuming tentative addresses don't count), ip route should possibly wait until DAD is done on all addresses. Of course I cannot say whether this was the original issue, though this bug seems to describe my issue well.
(In reply to Wynn Wolf Arbor from comment #2) > A similar thing just happened to me on a multi-homed system, though > specifically with multiple IPv6 addresses and a preferred source address in > ip route. > > Since the kernel checks whether a source address is actually configured on > an interface (I'm assuming tentative addresses don't count), ip route should > possibly wait until DAD is done on all addresses. > > Of course I cannot say whether this was the original issue, though this bug > seems to describe my issue well. Having seen lots of systems where DAD never finishes (the reason I added the dad_timeout knob), I feel there's a lot of risk to doing this by default. whubbs: was your original case on v4 (where this is no DAD) or v6
Wynn: you were not on the CC list, can you please see my comment 3?
I have to admit that I completely forgot this bug existed, since I solved it by adding "nodad" to the affected IPv6 addresses in conf.d/net. For this particular setup I do not have a need for DAD anyway. > Having seen lots of systems where DAD never finishes (the reason I added the > dad_timeout knob), I feel there's a lot of risk to doing this by default. I definitely agree with this. I haven't seen such systems yet myself, but if this is anything anyone is consistently seeing, we should not rely on DAD finishing consistently. I don't know when exactly dad_timeout was added, but having ip route wait for a maximum of dad_timeout seems like a decent workaround. Note that I have not looked at netifrc in quite a while now, though. I have not seen any issue like this with v4 addresses in all my years. If there's anything else I can do to help, do let me know.
