Allowing a local subnet route to change to a different ifnet
Bjoern A. Zeeb
bzeeb-lists at lists.zabbadoz.net
Thu Jan 18 00:31:15 UTC 2018
On 18 Jan 2018, at 0:09, Rodney W. Grimes wrote:
>> I have a customer that has configured two different IPs on the same
>> subnet on two different interfaces. The behaviour that they want is
>> that if the link on one of the two interfaces goes down, the route to
>> that subnet will migrate to the other IP on the other interface as a
>> quasi-failover behaviour. Under FreeBSD 7, we had a daemon that
>> accomplished this by detecting the link loss and then using "route
>> change" to move the route to the up interface. If the subnet in
>> question was 192.168.1.0/24, for example, we could run "route change
>> 192.1.68.1.0/24 -ifp em1" to migrate the route.
>
> "route change 192.1.68.1.0/24 -ifp em1" does not appear to be
> valid syntax to me, -ifp is not a route option?
> Did you mean -interface?
The proper syntax should be route change -ifp <if_name> <network>
but that’s not the issue (the other syntax works or used to work but
not according to specification).
>> Running on -head I run into two issues. The first comes out of
>> r264986, which changes the behaviour of RTM_CHANGE. The code path
>> changed significantly, but the part that impacts me is that now any
>> RTM_CHANGE command with the gateway set NULL gets EINVAL immediately
>> where previously it was allowed. I've hacked around this problem
>> locally for testing purposes but I really don't understand the code
>> well enough at this point to see what a real fix would look like.
Running route -n monitor & while doing the change I get very weird
results (without your patch).
[ignore the patch for the moment]
>> My first, and most important question, is whether a patch that would
>> allow a subnet route to be migrated to a different interface be
>> something that would be acceptable in FreeBSD?
Yes.
>> If so, I need guidance
>> on what a proper fix for both issues would look like so that I can
>> implement fixes that I can upstream.
>
> From a fundemental standpoint this should work,
> that it is now broken is a regression that needs fixed.
+1
/bz
More information about the freebsd-net
mailing list