Project

General

Profile

Actions

Feature #9544

closed

Enable ``ROUTE_MPATH`` multipath routing

Added by Jim Pingle over 3 years ago. Updated 6 days ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Routing
Target version:
Start date:
05/22/2019
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
23.01
Release Notes:

Description

Add ROUTE_MPATH to the kernel, assuming it does not cause any conflicts with existing options we need.

Actions #1

Updated by Renato Botelho over 3 years ago

  • Status changed from New to Feedback
  • Assignee set to Renato Botelho

option added to amd64/arm/arm64 kernels

Actions #2

Updated by Jim Pingle about 3 years ago

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)

Actions #3

Updated by Jim Pingle almost 3 years ago

See also: #10397

Actions #4

Updated by Jim Pingle over 2 years ago

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
Actions #5

Updated by Jim Pingle over 2 years ago

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

Actions #6

Updated by Jim Pingle over 2 years ago

  • Status changed from Feedback to New
  • Target version changed from 2.5.0 to Future

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.

Actions #7

Updated by Viktor Gurov about 1 year ago

Actions #8

Updated by Alexander Chernikov about 1 year ago

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.

Actions #9

Updated by Jim Pingle about 1 year ago

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

Actions #10

Updated by Alexander Deca 10 months ago

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

Actions #11

Updated by Renato Botelho 10 months ago

  • Assignee deleted (Renato Botelho)
Actions #12

Updated by Jim Pingle 6 days ago

  • Subject changed from Enable RADIX_MPATH to Enable ROUTE_MPATH
  • Description updated (diff)
  • Status changed from New to Closed
  • Target version changed from Future to 2.7.0
  • Plus Target Version set to 23.01

FreeBSD retired RAXIX_MPATH and replaced it with ROUTE_MPATH which is in the default kernel used on FreeBSD 14-based builds (Plus 23.01, CE 2.7.0 snapshots). It's also enabled by default (net.route.multipath is 1).

Actions #13

Updated by Jim Pingle 6 days ago

  • Subject changed from Enable ROUTE_MPATH to Enable ``ROUTE_MPATH`` multipath routing

Updating subject for release notes.

Actions

Also available in: Atom PDF