Hello t...@!
I've noticed an interesting routing behaviour, now curious of how it
should perform in reality:
Situation: two interfaces (uplinks), which receive default routes via dhcp
(net.inet.ip.multipath=1)
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0d:60:cb:54:f7
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 172.30.1.14 netmask 0xffffff00 broadcast 172.30.1.255
ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:1a:4d:28:e0:3a
priority: 4
groups: wlan
media: IEEE802.11 autoselect (OFDM54 mode 11g)
status: active
ieee80211: nwid wilab chan 11 bssid 00:08:54:af:19:c8 46dB wpapsk <not
displayed> wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher
tkip 100dBm
inet 172.30.5.11 netmask 0xffffff00 broadcast 172.30.5.255
Current routing table status:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 172.30.1.1 UGS 2 1046 - 8 em0
default 172.30.5.1 UGS 1 668 - 12 ral0
127.0.0.1 127.0.0.1 UH 6 1595227 33200 4 lo0
172.30.1/24 link#1 UC 1 0 - 4 em0
172.30.1.1 00:00:24:c8:ed:05 UHLc 2 476 - 4 em0
172.30.1.14 127.0.0.1 UGHS 0 0 33200 8 lo0
172.30.5/24 link#2 UC 1 0 - 4 ral0
172.30.5.1 00:08:54:af:19:c8 UHLc 2 0 - 4 ral0
172.30.5.11 127.0.0.1 UGHS 0 0 33200 8 lo0
Pulling the jack out of em0:
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 172.30.5.1 UGS 2 124 - 12 ral0
default 172.30.1.1 GS 0 49 - 8 em0
127.0.0.1 127.0.0.1 UH 6 1592873 33200 4 lo0
172.30.1/24 link#1 C 1 0 - 4 em0
172.30.1.1 00:00:24:c8:ed:05 HLc 3 36 - 4 em0
172.30.1.14 127.0.0.1 UGHS 0 0 33200 8 lo0
172.30.5/24 link#2 UC 1 0 - 4 ral0
172.30.5.1 00:08:54:af:19:c8 UHLc 3 0 - 4 ral0
172.30.5.11 127.0.0.1 UGHS 0 0 33200 8 lo0
216.239.59.109 172.30.5.1 UGHD 1 125 - L 56 ral0
Note, that em0 routes lose RTF_UP (U) flag.
The network seems to continue working through the second up default route:
proger ~ 0 % traceroute -n 93.73.112.1 # ip of my ISP's gw
traceroute to 93.73.112.1 (93.73.112.1), 64 hops max, 40 byte packets
1 172.30.5.1 0.832 ms 0.745 ms 0.994 ms
^C
but the acccess to network 172.30.1/24 still lies through routes which
are down:
(and not the working second default route)
proger ~ 130 % traceroute -n 172.30.1.1
traceroute to 172.30.1.1 (172.30.1.1), 64 hops max, 40 byte packets
1 *^C
I know this can be worked around with several ifstated/relayd setups
(where we should know the default routes from the start, so
theoretically we should hook into dhclient-script if we want some
dynamic routes establishing (i.e. often travelling through such
networks), etcetc), but looking into the kernel routing ways.
Is such routing behavior considered normal? Or what is the desirable
behavior of networking stack developers?
I wonder if it is possible to change such routing behavior to pass
all traffic through working routes by observing the if/link state
and whether it isn't restricted by other routing stuff/standards/etc..
Thank you.
ps.
pf is enabled, i have only no-df scrub and pass keep state
running -current
