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