Bad gateway and nameserver in link failover mode

S

strontium90

Hello

I am trying to implement a link failover scenario between wired and wireless interfaces on my laptop following instructions given in Example 32-3.

Wired (em0) and wireless (iwn0) interfaces have been tested separately and are functioning. With the current setup, once the network cable is disconnected, the lagg0 interface falls back on wlan0, as evidenced by ifconfig, however client applications, such as Firefox, cannot access the Internet. Naturally, reconnecting the cable returns lagg0 on em0 and client applications function again.

I have found that upon falling back on wlan0, gateway and nameserver information were not being modified, as evidenced by issuing netstat -nr and cat /etc/resolv.conf, hence my speculation on the possible cause of the problem. Configuration file contents follow.

Thank you.


Relevant section of /etc/rc.conf:
Code: 
hostname="laptop-11.some-real-domain-name.fr"

ifconfig_em0="up"
ifconfig_iwn0="ether et:hm:ac:ad:dr:es"
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA"
cloned_interfaces="lagg0"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP"

/etc/wpa_supplicant.conf:
Code: 
network={
    ssid="Warrior"
    psk="somepassword"
}
 
Thanks for the tip, @Dies_Irae. I did try appending the keyword up to the ifconfig value strings for the interfaces wlan0 and lagg0 in /etc/rc.conf to no avail. Honestly, I don't think the solution you mentioned applies: invoking ifconfig with the configuration I outlined in the original post returns the output below. Please take note of the UP state of each of the interfaces involved in the link failover setup.

As I mentioned previously, I need a solution to ensure that gateway and nameserver information of the wireless connection are taken into account when lagg0 falls back on wlan0. Currently, those of the wired connection persist.
Code: 
% ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether b8:ca:etc
	[...]
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
iwn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
        ether b8:ca:etc
	[...]
        media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng
        status: associated
lo0: 	[...]
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether b8:ca:etc
	[...]
        media: Ethernet autoselect
        status: active
        laggproto failover lagghash l2,l3,l4
        laggport: wlan0 flags=0<>
        laggport: em0 flags=5<MASTER,ACTIVE>
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether b8:ca:etc
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11ng
        status: associated
        ssid Warrior channel 6 (2437 MHz 11g ht/20) [...]
 
Last edited by a moderator:
LAGG failover expects both em0 and wlan0 to be in the same network/broadcast domain. That is why your default gateway and resolv.conf are not changing.
 
Thanks for putting me on the right track, @KernelPanic. Indeed, I found out that the configuration is functional in my home WiFi/ethernet environment built around the same Internet access point.

The natural question that arises at this point, is how could lagg0 interface switches between the ethernet em0 and wireless wlan0 intefaces be intercepted by some automated means in order to apply the correct gateway and nameserver configuration in each case without having to hardcode respective IP addresses?
 
Last edited by a moderator:
lagg is about Layer 2 connectivity. As such it's "high availability" capability (failover) is limited to a port being up or down.

To do something you're describing is Layer 3 "high availability". It would probably involved a daemon that monitors Layer 3 connectivity on em0. (i.e. ping the default gateway or some nearby hop) If it detects a failure the daemon would modify the appropriate network settings to use the Layer 3 settings of wlan0 instead. If DHCP is involved (since you mentioned resolv.conf) that would probably involve killing the old dhclient em0 process and starting dhclient wlan0
 
There is a way to automate the lagg0 failover transition to a different subnet, by restarting the lagg0 interface.

To do this automatically right after a LINK_UP or LINK_DOWN event on either the lan or the wifi interface:

edit /etc/devd.conf

Find and edit the section for the LAN interface.
Code: 
notify 0 {
            match "system"                       "IFNET";
            match "type"                         "LINK_UP";
            media-type                           "ethernet";
            action "etc/rc.d/[FILE]netif restart lagg0[/FILE]";
};
By default there is no rule for the LINK_DOWN event. However we need it because that's when lagg0 failover to wifi occurs.

So let's add the rule.
Code: 
notify 0 {
            match "system"                       "IFNET";
            match "type"                         "LINK_DOWN";
            media-type                           "ethernet";
            action "etc/rc.d/[FILE]netif restart lagg0[/FILE]";
};
Edit the event for WIFI interface.
Code: 
notify 0 {
            match "system"                       "IFNET";
            match "type"                         "LINK_UP";
            media-type                           "802.11";
            action "etc/rc.d/[FILE]netif restart lagg0[/FILE]";
};
Lastly...
Edit /etc/rc.conf

Add the following
Code: 
synchronous_dhclient="YES"
or change
Code: 
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 [FILE]SYNC[/FILE]DHCP"
 
You must log in or register to reply here.
Back
Top