> Le 22 juin 2016 à 20:59, Jean-Daniel Dupas <jddu...@xooloo.com> a écrit : > >> Le 22 juin 2016 à 20:56, rizz2pro . <rizzz2...@gmail.com> a écrit : >> >> >> On Jun 22, 2016 12:19 PM, "Jean-Daniel Dupas" <jddu...@xooloo.com > <mailto:jddu...@xooloo.com>> wrote: >>> >>> Hello, >>> >>> I'm trying to configure a basic router with carp enabled (as describe in > the >>> OpenBSD manual). >>> >>> My server has one primary interface (vio0) with an IP used to access it >>> directly (whatever the CARP interface status is): 10.0.11.1/16 > <http://10.0.11.1/16> >>> >>> It provides a shared interface on carp0 with the IP: 10.0.10.1/16 > <http://10.0.10.1/16> >>> >>> I want to set the default route on the carp iface, so the public IP when >>> connecting a remote host is the carp IP. >>> >>> The problem is when I do that, the system completely ignore the default > route >>> and always return a "no route to host" error when I try to access the >>> network. >>> >>> My config is as follow: >>> >>> ---- ifconfig >>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768 >>> priority: 0 >>> groups: lo >>> inet6 ::1 prefixlen 128 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6 >>> inet 127.0.0.1 netmask 0xff000000 >>> vio0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> > mtu >>> 1500 >>> lladdr 52:54:00:60:00:a2 >>> priority: 0 >>> media: Ethernet autoselect >>> status: active >>> inet 10.0.11.1 netmask 0xffff0000 broadcast 10.0.255.255 >>> carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 >>> lladdr 00:00:5e:00:01:f3 >>> priority: 15 >>> carp: MASTER carpdev vio0 vhid 243 advbase 1 advskew 0 >>> groups: carp egress >>> status: master >>> inet 10.0.10.1 netmask 0xffff0000 broadcast 10.0.255.255 >>> >>> ---- netstat -rn >>> Routing tables >>> >>> Internet: >>> Destination Gateway Flags Refs Use Mtu Prio > Iface >>> default 10.0.0.1 UGS 4 8 - 23 > carp0 >>> 10.0/16 10.0.11.1 UCP 2 396 - 4 > vio0 >>> 10.0/16 10.0.10.1 UCP 0 0 - 4 > carp0 >>> 10.0.0.1 00:00:5e:00:01:01 UHLc 0 129 - 4 > vio0 >>> 10.0.3.10 ac:87:a3:1d:3f:9d UHLc 1 50 - 4 > vio0 >>> 10.0.10.1 00:00:5e:00:01:f3 UHLl 0 444 - 1 > carp0 >>> 10.0.11.1 52:54:00:60:00:a2 UHLl 0 118 - 1 > vio0 >>> 10.0.255.255 10.0.11.1 UHPb 0 40 - 1 > vio0 >>> 10.0.255.255 10.0.10.1 UHPb 0 0 - 1 > carp0 >>> 127/8 127.0.0.1 UGRS 0 0 32768 8 > lo0 >>> 127.0.0.1 127.0.0.1 UHl 0 0 32768 1 > lo0 >>> 224/4 127.0.0.1 URS 0 976 32768 8 > lo0 >>> >>> ---- ping 8.8.8.8 >>> PING 8.8.8.8 (8.8.8.8): 56 data bytes >>> ping: sendto: No route to host >>> >>> -- uname -a >>> OpenBSD hostname 6.0 GENERIC.MP#2208 <http://generic.mp/#2208> amd64 >>> >>> Note: that config work perfectly on OpenBSD 5.7 but fails on OpenBSD 5.9 > and >>> current >>> >> Can you post your pf.conf? >> > pf is disabled. I did that to remove it from the equation until I solve that > issue.
It look likes the kernel behavior did change between 5.7 and now. On 5.7, I have a configuration where the default route is configured to use carp0, and I have a single matching network entry (10.0/16) for vio0, and everything works (there is no 10.0/16 route entry for carp0). The same configuration on current does not works (no route to host errors). -- default 10.0.0.1 UGS 4 8 - 23 carp0 10.0/16 10.0.0.1 UC 4 8 - 4 vio0 … --- On current kernel, it is impossible to have a mismatch between the default route and the network route. Moreover, if there is 2 networks route with the same priority, it only try the first one, and fails if it does not match (even if using the second route would work). That configuration fails. -- default 10.0.0.1 UGS 4 8 - 23 carp0 10.0/16 10.0.0.1 UC 4 8 - 4 vio0 10.0/16 10.0.0.1 UC 4 8 - 4 carp0 … --- It can be workaround either by: removing the vio0 network route -- default 10.0.0.1 UGS 4 8 - 23 carp0 10.0/16 10.0.0.1 UC 4 8 - 4 carp0 … --- increasing the carp0 route priority (so it is checked first) -- default 10.0.0.1 UGS 4 8 - 23 carp0 10.0/16 10.0.0.1 UC 4 8 - 4 vio0 10.0/16 10.0.0.1 UC 4 8 - 2 carp0 … --- So to be able to have the default route using carp0, the matching network route used to reach the gateway MUST be a route that use the same interface. That mean that every-time the carp status change, we have to change both the default route entry, and the network route entry. Is it something expected ? If this is the expected new behavior, I think it should be documented in the CARP networking guide, as this is not only confusing, but also hard to get it working in the first place. Moreover, by default, the system generate both network route automatically, which is pointless as the second one is always ignored.
