pfSense

There have been reports of instability with some routing scenarios since this was enabled. We shouldn't take any action on it until after base is shifted to 12-STABLE. If problems persist then we may want to back this out (and #9545)

See also: #10397

Still seeing reports of instability after moving to 12.1-STABLE. For example: https://forum.netgate.com/topic/153418/2020-05-report/2

<3>rn_delete: couldn't find our annotation

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address    = 0x70
fault code        = supervisor read data, page not present
instruction pointer    = 0x20:0xffffffff80ebbde6
stack pointer            = 0x28:0xfffffe0097fc44e0
frame pointer            = 0x28:0xfffffe0097fc45d0
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 52022 (zebra_dplane)
trap number        = 12
panic: page fault
cpuid = 0
time = 1589051672
KDB: enter: panic

Tracing pid 52022 tid 101001 td 0xfffff8042ce89740
kdb_enter() at kdb_enter+0x37/frame 0xfffffe0097fc4140
vpanic() at vpanic+0x19a/frame 0xfffffe0097fc41a0
panic() at panic+0x43/frame 0xfffffe0097fc4200
trap_pfault() at trap_pfault/frame 0xfffffe0097fc4270
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe0097fc42e0
trap() at trap+0x288/frame 0xfffffe0097fc4410
calltrap() at calltrap+0x8/frame 0xfffffe0097fc4410
--- trap 0xc, rip = 0xffffffff80ebbde6, rsp = 0xfffffe0097fc44e0, rbp = 0xfffffe0097fc45d0 ---
rtrequest1_fib() at rtrequest1_fib+0x296/frame 0xfffffe0097fc45d0
route_output() at route_output+0xd95/frame 0xfffffe0097fc4850
sosend_generic() at sosend_generic+0x4ea/frame 0xfffffe0097fc4900
sosend() at sosend+0x50/frame 0xfffffe0097fc4930
soo_write() at soo_write+0x32/frame 0xfffffe0097fc4970
dofilewrite() at dofilewrite+0xb0/frame 0xfffffe0097fc49c0
sys_write() at sys_write+0xc0/frame 0xfffffe0097fc4a30
amd64_syscall() at amd64_syscall+0x357/frame 0xfffffe0097fc4b70
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0097fc4b70

There are four known issues with RADIX_MPATH in FreeBSD, three of which can lead to a panic:

https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=radix_mpath&list_id=354350

The backtrace above appears to match the second screenshot on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241191

The current status of FreeBSD multipath:
https://www.freebsd.org/status/report-2020-10-2020-12.html#Scalable-routing-multipath-support

Jim Pingle wrote in #note62:

This was too unstable to keep for the time being. Retargeting to Future for now. Will revisit when stability issues in FreeBSD have been addressed.

Rewritten multipath routing (`ROUTE_MPATH` options) has been turned on by default on FreeBSD 13 and above.
There are no open bugs related to this functionality.

If that is the case, then we'll pick it up naturally when we rebase onto 13.x or later and we can close this at that time.

Using the link I posted above, I still see four open bugs, three of which are panics

Jim Pingle wrote in #note-9:

If that is the case, then we'll pick it up naturally when we rebase onto 13.x or later and we can close this at that time.

Using the link I posted above, I still see four open bugs, three of which are panics

Hey,

Any update on when the rebase will be done and that this feature will be available?

thanks