Hi guys, I'm using the very undocumented command setfib to play with several routing tables for test purposes before production release. This command has at least 2 problems : The kernel I'm running have the followings running settings : net.my_fibnum: 0 net.add_addr_allfibs: 0 net.fibs: 2 I'm currently testing very simple things : I boot my machine, and I enter those commands : #Configure interface em4 testQOS# ifconfig em4 10.10.10.0/24 up #Delete automatically added route (btw is there any parameter to prevent this behavior?) testQOS# route delete 10.10.10.0/24 delete net 10.10.10.0 #Populate FIB#1 context. We have net.add_addr_allfibs set to 0, so this is not done automatically testQOS# setfib 1 route add 10.10.10.0/24 -interface em4 add net 10.10.10.0: gateway em4 #Try a ping to a host(it's alive) in FIB#1 context testQOS# setfib 1 ping 10.10.10.11 PING 10.10.10.11 (10.10.10.11): 56 data bytes ping: sendto: Invalid argument If I do the following : testQOS# ifconfig em4 10.10.10.0/24 up testQOS# setfib 1 route add 10.10.10.0/24 -interface em4 testQOS# setfib 1 ping 10.10.10.11 PING 10.10.10.11 (10.10.10.11): 56 data bytes 64 bytes from 10.10.10.11: icmp_seq=0 ttl=64 time=1.561 ms The only difference is that I'm not deleting the route from FIB#0 context. Second problem : #Configuring an interface from FIB#1 context then trying to ping testQOS# setfib 1 sh # ifconfig em4 10.10.10.72/24 up # ping 10.10.10.11 PING 10.10.10.11 (10.10.10.11): 56 data bytes ping: sendto: Invalid argument #Doing the same thing in FIB#0 context testQOS# setfib 0 sh # ifconfig em4 10.10.10.72/24 up # ping 10.10.10.11 PING 10.10.10.11 (10.10.10.11): 56 data bytes 64 bytes from 10.10.10.11: icmp_seq=0 ttl=64 time=1.481 ms So it seems FIB#1 context depends on FIB#0 context. Maybe I've missed something, but it seems to be a bug. Thank you How-To-Repeat: Install a FreeBSD 8.2 AMD64, compile kernel with options : options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=250 options IPDIVERT options DUMMYNET options HZ=1000 options ROUTETABLES=2 Boot your machine Run commands given in "description"
vmiszczak, it looks like you encountered several bugs that I've recently fixed. The net route appeared in the wrong fib due to PR 187549. Ping failed, in the first case, probably due to PR 167947. Please retest using CURRENT, stable/10 greater than 267193, stable/9 greater than 271825, or 10.1-BETA1.
Timeout waiting for response from the submitter. I'm pretty sure that this PR is a duplicate of both 187549 and 167947. *** This bug has been marked as a duplicate of bug 187549 ***