Hi @0mp , do you have any objections ?

@brooks Thanks !

Ping @pauamma_gundo.com since the parent D35409 has been merged.

Hi @brooks , I do not have direct access to src repository, may you please commit this?

In D35384#803849, @pauamma_gundo.com wrote:

In D35384#803753, @pauamma_gundo.com wrote:

Ooops, right. Remove FDDI too, then. I only remember FreeBSD TR support going away because I used to ride herd on a several thousand workstations TR network back when 8228s were the latest and greatest.

Or are you planning to do that in D35409 instead?

@pauamma_gundo.com And what about the support status of FDDI ? It has been removed via D15170 .

See also D35304

In D34563#799891, @me_igalic.co wrote:

In D34563#784083, @markj wrote:

Seems reasonable. I think /dev/log is legacy anyway.

does that mean i don't have to change anything about D27411 once this gets committed?

I do not have direct access to the repository, @markj may you please commit this?

Ping .

Ping

In D34934#795609, @ngie wrote:

In retrospect, I should have removed/edited the metadata in the commit message. It looks nice on Phabricator, but it looks less nice in raw git/email form.

Protect from concurrent ioctls, and rebase on latest main branch

And for VNET(9) jail, it seems the loopback interface is always configured first.
The behavior is inconsistent with the host.

Hi,
I tested this patch with stable/13 in my home lab for about two weeks without any problems. Any progress will this be merge into stable/13 ?

In D33210#750542, @kp wrote:

That was done in 3dd5760aa5f876f8a3f0735afeebdf9ee414e1f5, so I'm a little confused where this comes from.

What if usr.sbin/jail process exit before a non-persistent jail exit ?

Sorry my bad, resubmit diff as last one include local WIP stashes.

@bryanv

1. Removed redundant error initialization.
2. Moved M_SETFIB(m, sc->vxl_fibnum) out of read lock

In D32820#741027, @kp wrote:

I'm not familiar with the vxlan code but this does look sane.

Let's give Bryan a few more days, but if he's not had the time for this by let's say Monday ping me to commit this.

Also, if someone would feel called to write a regression test for vxlan in general and this new feature specifically I'd love to see it. Something like the basic test in tests/sys/net/if_vlan.sh would already be valuable. (In fact, when I wrote that test it found a panic in the if_vlan code).

I'm glad to do it, but currently if_vxlan is not VNETified and IIUC it is hard to write a regression test for vxlan right now.

In D32820#741028, @melifaro wrote:

LGTM, ty!
Any chance you can fill in the "testing" section?

Abandoned since it works as intended.

I'm still investing on this issue. As the following case

In D31630#713490, @melifaro wrote:

I'd rather not touch it now - there is something WIP that will change this part of the code anyway.

@melifaro Thanks very much!

Done.

Rebased on latest main branch.
Moved down RO_GET_FAMILY()

In D30398#713041, @melifaro wrote:

Also: will you write a commit message, or do you prefer me doing it?

In D30398#713040, @melifaro wrote:

You also need to add a bit of family wrapping logic inside fill_nhop_from_info(), so we get a proper family for the nexthop.

LGTM

.

Pass correct AF to nd6_resolve()

In D30398#712308, @melifaro wrote:

In D30398#712270, @zlei.huang_gmail.com wrote:

@melifaro Sorry for late response ;)

I removed the LLE part, it should be easy to apply D31379 .

It should be the other way round :-) e.g. D31379 is a pre-requisite.
Could you try to apply it first, build on top and test?

In D30398#712308, @melifaro wrote:

In D30398#712270, @zlei.huang_gmail.com wrote:

@melifaro Sorry for late response ;)

I removed the LLE part, it should be easy to apply D31379 .

It should be the other way round :-) e.g. D31379 is a pre-requisite.
Could you try to apply it first, build on top and test?

Added feature(3) knob.

Cleaned up some comments.

.

@melifaro Sorry for late response ;)

Rebased on latest main branch

Update to 17.17.3 (as new www/kibana7 requires this version).

In D30398#708795, @melifaro wrote:

I've updated the aforementioned D31379 to reflect the committed parts.
If you could update this review to use the new functionality (e.g. nd6_resolve() returning lle with the proper encap) , that would be awesome.

Rework sending queued LLE packets.

In D30398#691776, @melifaro wrote:

LGTM, I guess the biggest remaining piece now is lle handling, especially sending queued LLE packets upon successful resolution.

In D30398#691776, @melifaro wrote:

LGTM, I guess the biggest remaining piece now is lle handling, especially sending queued LLE packets upon successful resolution.

I think I hit the issue that the useloopback was trying to resolve.

In D30811#692900, @donner wrote:

I'm surprised. There was a discussion about not redirecting /32 on interfaces to loopback. So we see the consequence.

Updated as @melifaro suggested.

Reuse route.ro_dst to get the address family of outbound / forwarded packets.

Hi Mark,

In D30398#682930, @melifaro wrote:

First of all, thanks for working on this! This is the important feature we need to have in base, preferably turned on by default.
I'd love to land this.

Glad to get your response !
I'm interested with scalable network, and recently exploring the CLOS network architecture described by RFC 7938. It need large number of IPs and configuration
and BGP unnumbered seems to rescue (RFC 5549).
Thanks your effort on FreeBSD's routing component, it is not too hard to implement such feature in the dataplane :)

I spent some time thinking about the potential implementation option some time ago. Let me try to summarise my thoughts below.

FreeBSD src repository favors detailed commit message. I'm not sure if it is sufficient. Suggestions are welcomed :)

Thanks @donner :)

Hi, since I do not have access to the src repository, could someone check in the diff please ?

Friendly ping @donner , there're changes since your first acceptance, do you have any objections?