[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 --- Comment #22 from Gregory Neil Shapiro --- Bug 278422 filed for dxr crash -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 --- Comment #21 from Gregory Neil Shapiro --- (In reply to Zhenlei Huang from comment #19) That is another good solution that I can appy generically to all tunnels that might end up giving a BGP route to the tunnel endpoint. Thanks! -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 --- Comment #20 from Gregory Neil Shapiro --- Funny thing happened when I put the config in place to work around the loop The sytem crashed with a panic in the dxr routing algorithm Marek recommended in comment 2. I'll file a new bug for that crash. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 --- Comment #19 from Zhenlei Huang --- @Gregory bird2 learned more precise route for remote end of the vxlan tunnel from the vxlan interface. When that route was installed into kernel FIB then it ended up recursive encapsulation. Unfortunately vxlan(4) does not handle the recursive correctly and thus results in kernel stack overflow. As a workaround, use a dedicated fib for vxlan tunnel. Assume x.x.x.x is your tunnel remote end, and y.y.y.y is original route for x.x.x.x . ``` # sysctl -n net.fibs=2 1 -> 2 # route add x.x.x.x y.y.y.y -fib 1 # ifconfig vxlan0 tunnelfib 1 ``` Now happy starting bird2 :) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394
--- Comment #18 from Gregory Neil Shapiro ---
Verified:
#23 ip_output (m=m@entry=0xf80007e3e000, opt=opt@entry=0x0, ro=, flags=flags@entry=0, imo=0x0, inp=inp@entry=0x0) at
./../../netinet/ip_output.c:699
699 switch (ip_output_pfil(, ifp, flags, inp, dst,
,
(kgdb) print *dst
$6 = {sin_len = 16 '\020', sin_family = 2 '\002', sin_port = 0, sin_addr =
{s_addr = 4017795422}, sin_zero = "\000\000\000\000\000\000\000"}
s_addr is 94.177.122.239, which is the vxlanremote IP for vxlan0.
Checking BGP route map:
94.177.122.0/24 unicast [4IXP4RS1 18:24:23.600 from 185.1.125.1] * (100)
[AS58057i]
via 185.1.125.5 on vxlan0
Once that route was exported to the kernel, routing to 94.177.122.239 went out
over vxlan0.
Configuration wise, I can avoid the crash with a static route for
94.177.122.239/32 out of the default gateway instead of the tunnel. However,
would be good to fix the crash.
Might even be interesting for all of the tunnel interfaces (not just vxlan) to
check if they are about to send a packet for the tunnel endpoint inside the
tunnel and realize that won't work (e.g., if dst == vxlanremote). Is that what
if_tunnel_check_nesting() does?
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Re: ixl(4) bhyve(8) SR-IOV with Transparent VLAN associated w/ VF's
Paul Procacci: > I'm assigning VF's to bhyve with pci passthru. [...] > Given this, I figured the best option would be to set the VLAN on the VF on > the host prior to handing it off to the bhyve instance effectively enabling > transparent vlans. [...] > Has anyone done this? Does anyone have any pointers to accomplish this? i looked into this a while ago and concluded that it's not supported, at least on Intel cards. my recollection is that someone was working on this at one point, but never finished it -- unfortunately, i can't remember who that was... you may be able to work around this by running vlan(4) on the VF on the host instead of passing the interface to the guest, but then you lose most of the benefits of using SR-IOV to begin with. i have run into some odd bugs with both SR-IOV and vlan(4) on ixgbe cards and would definitely recommend testing that thoroughly before deploying it. signature.asc Description: PGP signature
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 Zhenlei Huang changed: What|Removed |Added CC||z...@freebsd.org --- Comment #17 from Zhenlei Huang --- (In reply to Mark Johnston from comment #16) > I wonder if vxlan_transmit() should perhaps be calling > if_tunnel_check_nesting() somewhere? I think that's the right fix. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 Mark Johnston changed: What|Removed |Added Status|New |Open --- Comment #16 from Mark Johnston --- So we have a packet loop: ip_output() at ip_output+0xce7/frame 0xfe00517c4610 vxlan_transmit() at vxlan_transmit+0x591/frame 0xfe00517c4720 ether_output_frame() at ether_output_frame+0xf9/frame 0xfe00517c4750 ether_output() at ether_output+0x6fb/frame 0xfe00517c47e0 ip_output() at ip_output+0x1355/frame 0xfe00517c48e0 vxlan_transmit() at vxlan_transmit+0x591/frame 0xfe00517c49f0 ether_output_frame() at ether_output_frame+0xf9/frame 0xfe00517c4a20 ether_output() at ether_output+0x6fb/frame 0xfe00517c4ab0 ip_output() at ip_output+0x1355/frame 0xfe00517c4bb0 .. I wonder if vxlan_transmit() should perhaps be calling if_tunnel_check_nesting() somewhere? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
ixl(4) bhyve(8) SR-IOV with Transparent VLAN associated w/ VF's
Hey all,
Strange one here. Not much on the internet that I could find.
I'm assigning VF's to bhyve with pci passthru.
Doing this allows the bhyve instance maintainer to set their own vlan and
I'd like that not to be the case for various reasons. One being I don't
need/want their traffic to potentially hit/sniff other traffic on any other
vlan than the one assigned to them.
Given this, I figured the best option would be to set the VLAN on the VF on
the host prior to handing it off to the bhyve instance effectively enabling
transparent vlans.
Unless I misreading ixl(4) which is a real possibility, it supports 'VLAN
tag insertion/extraction'.
Has anyone done this? Does anyone have any pointers to accomplish this?
Thanks,
Paul
--
__
:(){ :|:& };:
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 Gregory Neil Shapiro changed: What|Removed |Added Attachment #250014|0 |1 is obsolete|| --- Comment #15 from Gregory Neil Shapiro --- Created attachment 250034 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250034=edit core.txt.6 The debug kernel was a great improvement in diagnostics. Attaching core.txt.6 which provides a full backtrace. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 278394] Reproducible kernel panic related to IPv4 routes populated by bird2 (BGP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278394 --- Comment #14 from Mark Johnston --- (In reply to Gregory Neil Shapiro from comment #10) So, if you're building a kernel from releng/14.0, GENERIC doesn't have debugging options enabled. DEBUG+=-g merely instructs the compiler to include debug symbols in the output, which helps debuggers but doesn't enable assertions, invariants checking, etc.. We don't include a debug kernel config on releng branches (this is a problem to be fixed). You can add the following lines (taken from GENERIC on main) to enable more checking which will hopefully catch a problem before the double fault occurs: # For full debugger support use (turn off in stable branch): options BUF_TRACKING# Track buffer history options DDB # Support DDB. options FULL_BUF_TRACKING # Track more buffer history options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options QUEUE_MACRO_DEBUG_TRASH # Trash queue(2) internal pointers on invalidation options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones options VERBOSE_SYSINIT=0 # Support debug.verbose_sysinit, off by default -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[iflib] Allow concurrent execution of admin tasks from different interfaces
Hi, In current iflib implementation there is a single task queue group used for all admin tasks, defined with: iflib.c:560 TASKQGROUP_DEFINE(if_config_tqg, 1, 1); This does not allow for concurrent processing of tasks. In systems with a large number of interfaces this may cause one long running task (e.g. related to FW update) to trigger timeouts of other tasks. Changing that to: TASKQGROUP_DEFINE(if_config_tqg, mp_cpu, 1); works, but might be an overkill. I don't see a way to dynamically add new threads/cpus to already defined taskqgroup though. I'll be grateful for any suggestions how to approach this issue. Thanks, Krzysiek
