Re: per-FIB socket binding
On Tue, 17 Dec 2024, Mark Johnston wrote: Lately I've been working on adding FIB awareness to bind(2) and inpcb lookup. Below I'll describe the project a bit. Any feedback/comments/suggestions would be appreciated. Today, a TCP or UDP socket can receive connections or datagrams from any FIB. SCTP? Any thoughts/comments? How much use are FIBs still these days? Half of the original use cases I can think of could easily and better be overcome by using vnet jails with a physical or virtual interface (e.g, vcc) being delegated to the vnet. I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB forwardig but that very little touches your use case apart from the mgmt which again can be factored out better (or inversely, factoring out the forwarding). I would honestly know who and how FIBs are still in use today or if they should be put on a list to be removed for 16 (I assume I might be surprised). That all said with your opt-in approach if the code itself doesn't bring too many new complications I'd be happy with it (assuming FIBs still have a use case). /bz -- Bjoern A. Zeeb r15:7
Re: per-FIB socket binding
W dniu 21.12.2024 o 17:34, Bjoern A. Zeeb pisze: On Tue, 17 Dec 2024, Mark Johnston wrote: Lately I've been working on adding FIB awareness to bind(2) and inpcb lookup. Below I'll describe the project a bit. Any feedback/comments/suggestions would be appreciated. Today, a TCP or UDP socket can receive connections or datagrams from any FIB. And that's probably the best solution. Please keep it as the default behaviour. If you are going to implement isolation on the socket level, then it should probably be explicitly enabled, like for example MD5 signatures on the socket IMHO. Any thoughts/comments? How much use are FIBs still these days? Half of the original use cases I can think of could easily and better be overcome by using vnet jails with a physical or virtual interface (e.g, vcc) being delegated to the vnet. I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB forwardig but that very little touches your use case apart from the mgmt which again can be factored out better (or inversely, factoring out the forwarding). Thank you for this trolling and provoking inquiry! For a long time, I have been using FIBs for non-vnet jails facing the intranet (default gw in LAN) while the host is facing mostly the Internet (default gw in WAN). Migrating these jails to VNET will not only increase the complexity and overhead but will probably degrade the network performance inside the jails too. Another use case could be VPN (nowadays it works fine with Wireguard, but it used to work for OpenVPN too). The VPN server runs on the machine using two public IP addresses from different ASNs and ISPs. To access the network behind the VPN, the client can connect to either of these addresses. FIBs are also convenient and flexible enough to secure basic network services by running them on FIB isolated from the Internet. I used it to secure NFS, SNMP daemons and a few others. Last but not least use case which comes to mind is routing. Routing daemons like net/bird2 and upcoming net/bird3 are also 100% FIB aware and still some enthusiasts who want to run them on FreeBSD instead of Linux do exist. Unfortunately, more advanced scenarios will no longer be deployable on the OS without FIB support. Cheers -- Marek Zarychta
[Bug 283380] FreeBSD accepts and processes IPv4 packets destined to non-local MAC addresses instead of dropping them
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283380 --- Comment #8 from Chris Hutchinson --- (In reply to Joerg Goltermann from comment #7) We've been using pf(4) on all our servers for about a decade and don't experience this problem with the following pf.conf entry: set block-policy drop I can't speak to other filters, as I've found pf meets all our needs. But maybe your chosen filter has a similar function/option? -- You are receiving this mail because: You are the assignee for the bug.
sa6_recoverscope: embedded scope mismatch: ...
Hi, having a machine currently getting two different routers on vtnet vs. wlan I started to get on main from a few days ago: kernel: [93592.190339] sa6_recoverscope: embedded scope mismatch: fe80:3::abcd:6fff:fe0c:1234%1. sin6_scope_id was overridden scope 0x1 is vtnet scope 0x3 is wlan How do I debug where thhing are going wrong. What broke this? /bz -- Bjoern A. Zeeb r15:7
Re: per-FIB socket binding
On Sat, Dec 21, 2024 at 04:34:25PM +, Bjoern A. Zeeb wrote: > On Tue, 17 Dec 2024, Mark Johnston wrote: > > > Lately I've been working on adding FIB awareness to bind(2) and inpcb > > lookup. > > Below I'll describe the project a bit. Any feedback/comments/suggestions > > would > > be appreciated. > > > > Today, a TCP or UDP socket can receive connections or datagrams from any > > FIB. > > SCTP? > > > Any thoughts/comments? > > How much use are FIBs still these days? Half of the original use cases > I can think of could easily and better be overcome by using vnet jails > with a physical or virtual interface (e.g, vcc) being delegated to the > vnet. > > I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB > forwardig but that very little touches your use case apart from the mgmt > which again can be factored out better (or inversely, factoring out the > forwarding). nginx is aware of FIBs, and I use it to have one machine behind two routers on same local net to present two different https sites, avoiding virtual hosts. Fib 0 and 1 are configured with different default routers. Having to run whole vnet jail would mean much higher (admin) overhead for this case without adding any useful functionality. > > I would honestly know who and how FIBs are still in use today or if they > should be put on a list to be removed for 16 (I assume I might be > surprised). > > > That all said with your opt-in approach if the code itself doesn't bring > too many new complications I'd be happy with it (assuming FIBs still > have a use case). > > /bz > > -- > Bjoern A. Zeeb r15:7
Re: per-FIB socket binding
On Sat, Dec 21, 2024 at 04:34:25PM +, Bjoern A. Zeeb wrote: > On Tue, 17 Dec 2024, Mark Johnston wrote: > > > Lately I've been working on adding FIB awareness to bind(2) and inpcb > > lookup. > > Below I'll describe the project a bit. Any feedback/comments/suggestions > > would > > be appreciated. > > > > Today, a TCP or UDP socket can receive connections or datagrams from any > > FIB. > > SCTP? SCTP has its own notion of a routing table index, the VRF, which is already supported in some form by our implementation. I don't know much about the details. It might be that SCTP already provides similar functionality. > > Any thoughts/comments? > > How much use are FIBs still these days? Half of the original use cases > I can think of could easily and better be overcome by using vnet jails > with a physical or virtual interface (e.g, vcc) being delegated to the > vnet. Certainly VNET jails provide equivalent functionality, but they have considerably higher overhead than separate FIBs. Moreover, they're less flexible than FIBs in that an application can only exist within a single VNET, whereas different sockets can be attached to different FIBs. > I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB > forwardig but that very little touches your use case apart from the mgmt > which again can be factored out better (or inversely, factoring out the > forwarding). > > I would honestly know who and how FIBs are still in use today or if they > should be put on a list to be removed for 16 (I assume I might be > surprised). FIBs are certainly in use by at least one FreeBSD-using company, but I don't have any real details. Removing them is probably not on the table in the near to medium-term future. > That all said with your opt-in approach if the code itself doesn't bring > too many new complications I'd be happy with it (assuming FIBs still > have a use case). > > /bz > > -- > Bjoern A. Zeeb r15:7
Re: per-FIB socket binding
On Sat, 21 Dec 2024 16:34:25 + (UTC) "Bjoern A. Zeeb" wrote: > On Tue, 17 Dec 2024, Mark Johnston wrote: > > > Lately I've been working on adding FIB awareness to bind(2) and > > inpcb lookup. Below I'll describe the project a bit. Any > > feedback/comments/suggestions would be appreciated. > > > > Today, a TCP or UDP socket can receive connections or datagrams > > from any FIB. > > SCTP? > > > Any thoughts/comments? > > How much use are FIBs still these days? Half of the original use > cases I can think of could easily and better be overcome by using > vnet jails with a physical or virtual interface (e.g, vcc) being > delegated to the vnet. > > I wonder if anyone on FreeBSD is using FIBs to actually have > multi-FIB forwardig but that very little touches your use case apart > from the mgmt which again can be factored out better (or inversely, > factoring out the forwarding). > > I would honestly know who and how FIBs are still in use today or if > they should be put on a list to be removed for 16 (I assume I might be > surprised). That sounds pretty strange. The main FIB utilization is in routing area and has nothing to do with jails at all (a router/firewall don't need jails). (not that I'm fine with FIB concept at all, but unfortunately that's routing industry standard concept, and removing FIBs will make FreeBSD lacking behind competitors here as it was before 6.x) -- WBR, @nuclight
Re: per-FIB socket binding
"Bjoern A. Zeeb" wrote: > I wonder if anyone on FreeBSD is using FIBs to actually have multi-FIB > forwardig but that very little touches your use case apart from the mgmt > which again can be factored out better (or inversely, factoring out the > forwarding). > > I would honestly know who and how FIBs are still in use today or if they > should be put on a list to be removed for 16 (I assume I might be > surprised). I hope that is a joke! FIBs are a must have for certain routing environments, and forcing them into a VNET jail would add to overheads, and not even work for applications that work with 2 or more FIBs in the same instance!
[Bug 283450] ARP problem. Request transmission does not work (proxied arp) in varios virtual interface
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283450 DYM changed: What|Removed |Added Summary|ARP problem |ARP problem. Request ||transmission does not work ||(proxied arp) in varios ||virtual interface -- You are receiving this mail because: You are the assignee for the bug.
[Bug 252165] usb network and mii bus media status race condition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165 --- Comment #54 from m...@netfence.it --- (In reply to Ali Abdallah from comment #45) I ditched the patch I was using and applied your latest patch to 14.1 and 14.2. After brief testing, it seems to be working (better than the former), but, as this is a laptop and I'm not using USB LAN frequently, time will tell. I'll get back if/when I encounter further problems. Thanks a lot. -- You are receiving this mail because: You are the assignee for the bug.
