Re: LibAlias in FreeBSD
On Fri, May 27, 2022 at 04:18:54PM +0300, Michael Pounov wrote: > Hello Charles Mott > > I wrote this mail about my work with IPFW firewall. > I am started my work over IPFW Sync driver and protocol similar like in PF > firewall. > My primery goal is to do sync on NAT states in firewall router cluster. About > it, I need to know when NAT driver add, readd or delete alias to be notify > from libalias > I see one good approach to achieve this, but I must to asking if existing > hidden drawbacks for such approach the author of libalias. As long as the callback is internal to the kernel, it might work. libalias is CPU bound, any additional work will slow down the system, especially when libalias is called from the interrupt level of network drivers. > What are you thinking about such approach, change and hook of the existing > code? One can think about a ringbuffer which is filled by libalias and read by a different type of code. If the other code is too slow, the ringbuffer will override the entries. Please do not consider a dynamically allocated buffer.
Re: How does FreeBSD expect to compete in a DPDK/VPP world?
On Wed, Jul 20, 2022 at 12:14:36PM -0700, Neel Chauhan wrote: > FreeBSD doesn't have an effective software-based router, lacks MPLS, mpd5 > lacks native IPv6 without many shell script hacks, etc. mpd5 does provide IPv6 out of the box. May you contact me in private to discuss this a bit more in detail? > Not that I work at an ISP or tech company in a networking role, I don't. > Heck, adding even MPLS support has been on my bucket list for a while, but > am too lazy to get started. I do want to move to a networking-based role at > $DAYJOB, but we'll see about that. MPLS is outdated (performance-wise) and (functionally) replaced by vxLan, or do I miss something?
Re: IPFW NAT intermittently fails to redirect UDP packets; seeking DTrace scripts or other advice
On Mon, Aug 29, 2022 at 06:36:26PM +, tt78347 wrote: > ipfw -q nat 1 config if $extif unreg_only reset \ > redirect_port udp 192.168.21.4:500 500 \ > redirect_port udp 192.168.21.4:4500 4500 > $add 450 nat 1 udp from any to any 500,4500 in via $extif > $add 451 nat 1 udp from any to any 500,4500 out via $extif > $add 500 nat 1 ip from any to any via $extif in > $add 65000 nat 1 ip from any to any via $extif out Only a quick look ... There is no guarantee, that the ports of the UDP packets are not modified by libalias (NAT is designed to do exactly this modification). So some of the matches seems to be a bit optimistic, > - This system has net.inet.ip.fw.one_pass=0 man ipfw To let the packet continue after being (de)aliased, set the sysctl variable net.inet.ip.fw.one_pass to 0. For more information about aliasing modes, refer to libalias(3). Hence the NAT is applied multiple times if the path through the rules is a bit unlucky. The traces show, that the problematic cases are those where the packets are not (de)aliased. This can be the case, when libalias has no more free ports available for aliasing. In such a case, the packet is returned unmodified (unaliased) with an error code. I'm not sure, if this will cause a packet drop or not, especially in the one_pass=0 case. It might be possible, that duplicate packets (or quickly repeated ones) trigger an unintended aliasing of the source port. This will create an flow in the NAT table which is handled before the port redirection. And it might miss the rules with explicit port numbers. But this will be probably the wrong idea.
Re: Lagg and multi-gigabit questions/proablems
On Tue, Nov 08, 2022 at 12:38:54AM -0500, Chris Ross wrote: > Tl;dr; I have two FreeBSD systems attached to a Cisco switch, there should be > multi-gigabit connectivity, but only seeing 1Gpbs. Each system is trunked, > vlan interfaces on the underlying interface. I can add another data point: - stable trains in 12/13 - 10g ixl cards (with 1G and 10G ports) - without LACP cpu load correlates linearly with the throughput - with LACP cpu load rise sharply to 100% at about 40-50% input bandwidth - if this happens, the packet drop rate spikes to about 10 kp/s in the kernel input handling queues, throughput falls to some Mbps Unfortunately I did not have time to digg deeper, bringing the production network back to work had priority. (The BSD machines in question work as cantral Carrier Grade NAT devices.)
Re: Bridging LACP PDUs ?
On Tue, Nov 08, 2022 at 04:44:38PM +0300, Özkan KIRIK wrote: > Topology is below: > [switch1 - lacp] <---> [ freebsd bridge ] <---> [switch2 - lacp] > > Is there a way to pass LACP PDUs ? LACP packets are more layer1 than layer2, they must not be forwarded at layer2 to different endpoints. Does you setting allow the following? [switch1 - lacp] <---> [ freebsd bridge ] <---> [switch2 - lacp] ^ | | v [ switch 3 - lacp ] If not, why you are using a bridge? A typical solution is to have multiple LACPs: switch1 --lacp-- lagg1 | freebsd bridge | lagg2 --lacp-- switch2
Re: Bridging LACP PDUs ?
On Thu, Nov 10, 2022 at 04:28:50PM +0300, Özkan KIRIK wrote: > I'm trying to filter traffic through an uplink cable between two > switches. (similar to virtual wire behaviour). > So all broadcast & multicast packages should pass to the other port. > But pf or ipfw should work for L3+ packages. So I'd suggest to set up a cross-connect between the interfaces: # ngctl connect eth0: eth1: lower lower If you like to filter: # ngctl mkpeer eth0: bpf lower left # ngctl connect eth0:lower eth1: right lower Then you can apply any filtering using ng_bpf (by throwing away (non)matching traffic to an unconnected hook)
AW: dummynet performance
> In my production environment there are many schedulers and pipes & > queues belongs to this scheds. > dummynet uses %90-100 percent of single cpu. (ie. 20 scheds, 30 pipes, > 35 queues total. Each pipe has max 30-100Mbps) If the perfomance issue is urgent, you may give netgraph (ng_car, ng_pipe) a try. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FreeBSD does not reply to IPv6 Neighbor Solicitations
> Victor Sudakov wrote: > > Dear Colleagues, > > > > Why could it be that a FreeBSD 12.2 host does not reply to ICMPv6 > > Neighbor Solicitations from the router? > > Any ideas please? Thank you for pointing this out. I do have an similar effect, after upgrading, and you point me to a good direction. I'll investigate and report back. Lutz Donnerhacke ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AW: FreeBSD does not reply to IPv6 Neighbor Solicitations
> I’d start by checking netstat -s -p icmp6 and netstat -s -p ip6 for > any suspicious counter updates. Great idea. It points me tot he most stupid error I could make. Instead of ifconfig_lagg140_aliases="inet6 2a01:75c0:1000:140::/64 anycast" I wrote ifconfig_vlan140_aliases="inet6 2a01:75c0:1000:140::/64 anycast" so the IPv6 address was not set after reboot. This fails to get noticed, due the long lifetime of the announced prefix. (the error has been visible since a few days only, I had no time to investigate) So I can confess, plain 12.2-STABLE is no broken. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AW: FreeBSD does not reply to IPv6 Neighbor Solicitations
Victor Sudakov wrote: > Paul Mather wrote: > > Why could it be that a FreeBSD 12.2 host does not reply to ICMPv6 > > Neighbor Solicitations from the router? > > Well, Neighbor Solicitations (ICMPv6 type 135) and Neighbor > Advertisements (ICMPv6 type 136) are not exactly routing messages, they > are the equivalent of the ARP protocol in IPv6, and AFAIK should work > between any two IPv6 nodes to map L3 addresses to L2 addresses, even if > there are no routers on the segment. Correct me if I'm wrong. Correct. > You may be right but then it is certainly a bug. Unfortunately I cannot > reproduce the problem with any reliability, this thing works more often > than not. May you be able to capture the icmp6 traffic of this interface with respect to ND? I'm really interested in seeing, that the box does not respond to a given NS query. There are various reasons, why this may happen, i.e. sender IP in the NS is out of prefix of the target IP. This may happen, if multiple prefixes are added to the interface. Some devices (like Cisco ASA) are very picky on matching source/target IPs. So it might be possible, that the problem is not the the FreeBSD box, but the querying device (Mircotik?) > > My interface ifconfig shows "nd6 > > options=23" [...] > > [*] As well as a static IPv6 address I also enable SLAAC to get > > autoconfigured and privacy addresses on the interface. > > I see your point, this makes sense, but I would like to try and isolate > the problem. There is no problem with neighbour discovery without the ACCEPT_RTADV option. It simply works. # uname -a FreeBSD ... 12.2-STABLE FreeBSD 12.2-STABLE r368820 ENCOLINE-NAT amd64 # ifconfig vlan vlan: flags=8843 metric 0 mtu 1500 options=63 ether 48:df:37:3c:d3:50 inet6 fe80::4adf:37ff:fe3c:d350%vlan prefixlen 64 scopeid 0x1e inet6 2a01:75c0:1000::5:102:160:146 prefixlen 64 inet 5.102.160.146 netmask 0xfff0 broadcast 5.102.160.159 groups: vlan vlan: vlanpcp: 0 parent interface: ixl0 media: Ethernet autoselect (10Gbase-SR ) status: active nd6 options=21 # tcpdump -ni vlan icmp6 | fgrep neighbor tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan, link-type EN10MB (Ethernet), capture size 262144 bytes 09:06:17.823698 IP6 fe80::50: > 2a01:75c0:1000::5:102:160:146: ICMP6, neighbor solicitation, who has 2a01:75c0:1000::5:102:160:146, length 32 09:06:17.823708 IP6 fe80::4adf:37ff:fe3c:d350 > fe80::50:: ICMP6, neighbor advertisement, tgt is 2a01:75c0:1000::5:102:160:146, length 24 09:06:22.782809 IP6 fe80::4adf:37ff:fe3c:d350 > fe80::50:: ICMP6, neighbor solicitation, who has fe80::50:, length 32 09:06:22.787620 IP6 fe80::50: > fe80::4adf:37ff:fe3c:d350: ICMP6, neighbor advertisement, tgt is fe80::50:, length 24 ^C271 packets captured 5149447 packets received by filter 0 packets dropped by kernel So it works in both directions. Please note, that the first NS query is coming from a link-local address and requesting a global IP. This will not always be answered by any device out there (especially if the roles are reversed) ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AW: FreeBSD does not reply to IPv6 Neighbor Solicitations
> > May you be able to capture the icmp6 traffic of this interface with > > respect to ND? I'm really interested in seeing, that the box does > > not respond to a given NS query. > > Here you are http://admin.sibptus.ru/~vas/nd1.pcapng The device, where the capture was taken does not respond tot he NS packet. This might be caused by: a) the device has a different configured IP address, than requested b) the network card does not listen to the multicast group, which is used by the request (you see it only due to the promisc mode of the capture). But this is unlikely (due to the promisc mode) c) your system is broken ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AW: FreeBSD does not reply to IPv6 Neighbor SolicitationsNUD
> $ ifconfig re1 > re1: flags=8843 metric 0 mtu 1500 > options=8209b > ether c4:12:f5:33:c9:7c > inet 192.168.170.5/24 broadcast 192.168.170.255 > inet6 fe80::c612:f5ff:fe33:c97c%re1/64 scopeid 0x2 > inet6 2001:470:ecba:3::5/64 > media: Ethernet autoselect (1000baseT ) > status: active > nd6 options=21 There is another possibility: The address could be in a tentative or duplicate state. In such a state the device SHOULD/MUST NOT respond to solicitation messages. This can be caused by a "proxy arp/nd" device, which responds to an address in the local neighbour cache with its own solication message. It might be even a loop. We had such cases in the past, so that the device does not activate the IPv6 address without disabling the NUD (was a windows server). For fixed addresses it should be save to disable the flag. But this state should be reported by ifconfig. So, did you try the latest stable? ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netgraph with ng_netflow and ng_gridge nodes
On Tue, Feb 02, 2021 at 10:05:15AM -0500, petru garstea wrote: > Hi, > > I need help to unify 2 netgraphs > > 1st ng_bridge netgraph > > ngctl mkpeer fxp0: bridge lower link0 > ngctl connect fxp0: em0:lower upper link1 > ngctl name fxp0:lower em0Bridge > ngctl mkpeer fxp0:lower eiface link3 ether So you tap the fxp0 with a bridge and attach an virtual interface. > 2nd ng_netflow netgraph > > mkpeer fxp0: netflow lower iface0 > name fxp0:lower netflow > connect fxp0: netflow: upper out0 > mkpeer netflow: ksocket export inet/dgram/udp > msg netflow:export connect inet/10.0.0.1: So you inject a bidirectional netflow analyser into the fxp0 interface. > I cannot run both graphs at the same time because both of them are trying to > use fxp0 interface lower and upper hooks. > I believe it is necessary to introduce an extra node but I am not sure. You need to define which communication you want to analyse with netflow. I.e. you want to analyze the traffic on the wire: fxp0.lower -- iface0.netgraph.out0 -- link1.bridge.link2 -- upper.fxp0 \.link3 -- ether.eiface This will exclude the traffic between the eiface and the fxp0 IP-stack. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netgraph with ng_netflow and ng_gridge nodes
On Tue, Feb 02, 2021 at 09:16:49PM +0100, Lutz Donnerhacke wrote: > fxp0.lower -- iface0.netgraph.out0 -- link1.bridge.link2 -- upper.fxp0 > \.link3 -- ether.eiface The strange thing is, that both fxp0 and eiface provide an interface to the kernel IP stack. This is confusing (for the kernel). I'd like to point you to ng_tee instead of ng_bridge for a read only access to the communitcation (depending on the direction). Even ng_one2many or ng_hub might be a better solution. If you only need the eiface to attach tcpdump, you can omit it completely, because tcpdump is able to sniff on the fxp0 even if the netgraph hooks are set. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: netgraph with ng_netflow and ng_gridge nodes
On Sat, Feb 06, 2021 at 11:10:29AM -0500, petru garstea wrote:
> Greetings,
>
> I have come up with a graph with no use of ng_tee, ng_hub or ng_one2many.
>
> Also I validated the flows on a collector
>
> In case anybody has the same use case I am sharing the graph
>
> mkpeer re0: netflow lower iface0
> name re0:lower netflow
> connect re0: netflow: upper out1
> mkpeer netflow: bridge out0 link0
> name netflow:out0 re0bridge
> connect re0bridge: netflow: link1 iface1
> mkpeer re0bridge: eiface link2 ether
> name re0bridge:link2 ng0
> mkpeer netflow: ksocket export9 inet/dgram/udp
> msg re0: setpromisc 1
> msg re0: setautosrc 0
> msg netflow: setconfig {iface=0 conf=11}
> msg netflow: setconfig {iface=1 conf=11}
> msg netflow:export9 connect inet/${collector_ip}:${port}
bridge.link0 - out0.netflow.iface0 --- lower.re0
\.link1 --- iface1./ \.out1 - upper./
\.link2 - ether.ng0
So you collect the data from the outside world to the re0 interface (IP
stack) twice, but you can catch the data from the ng0 interface to re0
separate from the data to outside.
If this is your desired setup, fine.
If you like to understand your network, try:
# ngctl dot [-c]
and paste the output to http://www.webgraphviz.com/
HTH
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: CARP interface
On Thu, Feb 11, 2021 at 10:27:44AM -0300, Cristian Cardoso wrote:
> I would like to clarify a doubt, if someone has this scenario in the
> use of CARP for the use of virtual ips in interfaces in FreeBSD.
> I have an interface where I have the 10.19.254.2/24 network and I am
> placing the virtual IP 10.19.254.3/32 in the CARP, this interface does
> not have a default gateway, but a static route "10.0.0.0/8 gw
> 10.19.254.1".
> When I activate CARP, the interface stops communicating with IP
> 10.19.254.1 and with that I have no external access on the machine.
> Could anyone tell me if this is the normal behavior of CARP or is it
> not even for scenarios where the interface has static routes?
> I checked the handbook and several manuals over the internet, I didn't
> find anything related to validate my scenario.
That's quite unusal and should not happen. Can you please send me the
relevant rc.conf lines?
Working example here:
cloned_interfaces="${cloned_interfaces} vlan100"
create_args_vlan100="vlan 100 vlandev ixl1"
ifconfig_vlan100="up"
ifconfig_vlan100_aliases="inet 100.115.0.26/17"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 103 advskew 10
pass 100.115.0.60/32"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 104 advskew 20
pass 100.115.0.61/32"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 105 advskew 30
pass 100.115.0.62/32"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 106 advskew 30
pass 100.115.0.63/32"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 107 advskew 30
pass 100.115.0.64/32"
ifconfig_vlan100_aliases="${ifconfig_vlan100_aliases} inet vhid 108 advskew 30
pass 100.115.0.65/32"
resulting in:
vlan100: flags=8943 metric 0
mtu 1500
options=600703
ether d4:f5:ef:26:2f:58
inet 100.115.0.26 netmask 0x8000 broadcast 100.115.127.255
inet 100.115.0.60 netmask 0x broadcast 100.115.0.60 vhid 103
inet 100.115.0.61 netmask 0x broadcast 100.115.0.61 vhid 104
inet 100.115.0.62 netmask 0x broadcast 100.115.0.62 vhid 105
inet 100.115.0.63 netmask 0x broadcast 100.115.0.63 vhid 106
inet 100.115.0.64 netmask 0x broadcast 100.115.0.64 vhid 107
inet 100.115.0.65 netmask 0x broadcast 100.115.0.65 vhid 108
groups: vlan
carp: MASTER vhid 103 advbase 1 advskew 10
carp: BACKUP vhid 104 advbase 1 advskew 20
carp: BACKUP vhid 105 advbase 1 advskew 30
carp: BACKUP vhid 106 advbase 1 advskew 30
carp: BACKUP vhid 107 advbase 1 advskew 30
carp: BACKUP vhid 108 advbase 1 advskew 30
vlan: 100 vlanpcp: 0 parent interface: ixl1
media: Ethernet autoselect (10Gbase-LR )
status: active
nd6 options=29
Routing is done via bird.
Which version of FreeBSD are you using?
FreeBSD ... 12.2-STABLE FreeBSD 12.2-STABLE stable/12-c243266-gd970a8218e1
GENERIC amd64
I had a similar problem like you with 13-STABLE but was not able to
investigate further. I suspect, that the new routing code is causing this.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: accept_rtadv
On Sat, Feb 27, 2021 at 12:34:56PM -0800, Doug Hardie wrote:
> Ahh. The handbook is needing a note about that. There should be something
> similar to what was done for IPv4 where it shows adding additional addresses
> using:
>
> Ifconfig_bge0_alias0 ...
> Ifconfig_bge0_alias1 ...
>
> That would be very helpful. Thanks for the explinations.
That's a bad idea. You can't comment out some intermediate line.
ifconfig_bge0_alias0="inet xxx"
# ifconfig_bge0_alias1="inet yyy"
ifconfig_bge0_alias2="inet zzz"
will result in applying "xxx" only.
but this is even worse:
ifconfig_bge0_aliases=" \
inet xxx \
# inet yyy \
inet zzz \
"
It results in an syntax error.
So I do use:
ifconfig_bge0_aliases="${ifconfig_bge0_aliases} inet xxx"
# ifconfig_bge0_aliases="${ifconfig_bge0_aliases} inet yyy"
ifconfig_bge0_aliases="${ifconfig_bge0_aliases} inet zzz"
For _ipv6 it's different, because you need at least one _ipv6.
ifconfig_bge0_ipv6="inet6 xxx"
ifconfig_bge0_aliases="inet6 yyy"
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: IPv6 Startup
On Mon, Mar 15, 2021 at 05:29:55PM -0700, Doug Hardie wrote: > I reduced the configuration to the host settings: > ifconfig_bge0_ipv6="inet6 accept_rtadv" > > The router to: > ifconfig_ue0_ipv6="up" > > Ran tcpdump on the router (obviously not acting as a router) and restarted > the host. Got the following: > > tcpdump: listening on ue0, link-type EN10MB (Ethernet), capture size 262144 > bytes The device is using a EUI-64 link local address, which is unique by definition. Therefore no DAD is necessary, the address can be used immediatly. If you use a manually generated address, even if it has a EUI-64 form, DAD is required. DAD consists of Neighbour Solication messages. I understand your point, questioning if DAD should be done in any case or not. That's a complicated topic, which requires a lot of RFC exegesis, studying interop tests results from the IETF and IPv6 certificate organisations, and practical market dominance. > 19:05:00.048637 IP6 (hlim 1, next-header Options (0) payload length: 56) > fe80::aa60:b6ff:fe1d:8dbc > ff02::16: HBH (padn)(rtalert: 0x) [icmp6 sum > ok] ICMP6, multicast listener report v2, 2 group record(s) [gaddr > ff02::2:ec7d:574c to_ex, 0 source(s)] [gaddr ff02::2:ffec:7d57 to_ex, 0 > source(s)] Because IPv6 uses unicast and multicast only, the device registers itself for the necessary link local multicast groups. > 19:05:00.171029 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) > fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router > solicitation, length 16 > source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc The device will use SLAAC for address configuration, but do not want to wait for the next Router Advertisement, so it asks for an immediate response from the router. > 19:05:04.198640 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) > fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router > solicitation, length 16 > source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc No router answered, maybe the packet was lost. So the device ask again for a router in order to complete SLAAC. > 19:05:08.449844 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) > fe80::aa60:b6ff:fe1d:8dbc > ff02::2: [icmp6 sum ok] ICMP6, router > solicitation, length 16 > source link-address option (1), length 8 (1): a8:60:b6:1d:8d:bc No router answered, maybe the packet was lost. So the device ask again for a router in order to complete SLAAC. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: sender source IP address on UDP socket bound to INADDR_ANY in golang
On Sun, May 16, 2021 at 09:18:55PM +1000, Peter Jeremy via freebsd-net wrote: > This is getting outside my expertise but my understanding is that > the idea behind using IPv4-mapped addressed is to simplify building > dual-stack applications, particularly during the early introduction > of IPv6. The main benefit is that it made it possible to support > both IPv4 and IPv6 without needing 2 sockets - which means you > can stick to doing an accept() on a blocking socket, rather than > needing to use poll() or select() etc with a pair of non-blocking > sockets. Correct. IPv4-mapped addresses exists only for this purpose, they do not have any meaning outside of this API. Unfortunatly the API is incomplete, but still heavily used. For this purpose the API might be stretched over its limits. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
May you have some spare time to review?
Hi everybody, instead of adding some people, who will already do a lot of cooperative work for others, to each of the reviews, I'd ask with a single message to the list for some of your valuable time. The whole project is about a better performance in natting (libalias). Because there is a larger pile of mature code to rethink and redesign before coming up with efficient data structures, the review is split in some semantically coherent pieces. But it's all a single stacked review. So if you had read up to this point, may you consider yourself as a reviewer. D30536 libalias: Switch to efficient data structure for incoming traffic D30516 libalias: Switch to efficient data structure for outgoing traffic D30582 libalias: Restructure - Finalize D30581 libalias: Restructure - Use AliasRange instead of PORT_BASE D30580 libalias: Restructure - Table for PPTP D30575 libalias: Restructure - Group expire handling entries D30574 libalias: Restructure - Group incoming links D30573 libalias: Restructure - Cleanup and Use for links D30572 libalias: Restructure - Outgoing search D30571 libalias: Restructure - Cleanup _FindLinkIn D30570 libalias: Restructure - Table for partially links D30569 libalias: Restructure - Separate fully qualified search D30568 libalias: Restructure - Common search terms D30566 libalias: Promote per instance global variable timeStamp D30277 libalias: tidy up housekeeping D30587 libalias: Stats are unsigned Thank you
ISC DHCP client/relay end of maintenance
https://lists.isc.org/pipermail/dhcp-users/2021-June/022495.html ISC would like to end maintenance of the ISC DHCP *client and relay* by the end of 2021. We plan to continue maintaining the DHCP *server*, and any code that is common between the server, client and relay for a couple more years at least. Our January 2020 release of ISC DHCP incorporated a number of submitted patches, mostly for the client, but otherwise we have done little maintenance on the client or relay. To be honest, the client and relay have simply not been a focus of ours for several years. As a small non-profit organization, we have to allocate our limited resources carefully and we think the ISC DHCP server, and Kea have more future value for users.
Re: RFC: NFS trunking (multiple TCP connections for a mount
On Tue, Jun 29, 2021 at 12:23:21AM +, Rick Macklem wrote: > I don't understand how multiple TCP connections to the same > server IP address will distribute the load across multiple network > interfaces? Sounds like a bandwith-latency-product issue. TCP is prone to stalling at the end of a buffer window (in addition to reassembly and RPC waits). Multiple TCP streams scale linear with the available bandwidth over them. Single RPC messages should not split over multiple streams (causes reorder of segments), but different messages can go in round robin fashion. There is no need to ensure a symmetric path, so that the response comes back on the same stream.
Re: Porting OpenBSD MPLS to FreeBSD
On Fri, Nov 19, 2021 at 11:17:42AM -0800, Neel Chauhan wrote: > * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off doing > a from-scratch implementation based on netgraph? I'd prefer a netgraph approach, if possible. It helps to concentrate on the important things. > * Would some of the other committers here be willing to mentor/help me if > needed? For the netgraph part ...
Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?
On Sun, Dec 05, 2021 at 08:20:08PM +0200, John Hay wrote: > Something I have observed is that if you use FreeBSD 13 as a router with 2 > subnets on the same interface, it will generate redirects when hosts send > packets to the other subnet via the FreeBSD router. I think it is wrong. No, it's correct. > The host does not have a more direct way to get to the other subnet. The other host can arp for an address in a non-connected network on the interface because it's the same L2 domain. Hence the ICMP redirect is send out to provide the shortcut (skipping the router). > RFC792 > on page 13 does not talk about interfaces, but networks, "If G2 and the > host identified by the internet source address of the datagram are on the > same network...". "network" == "layer 2 domain".
Re: Porting OpenBSD MPLS to FreeBSD
On Mon, Dec 06, 2021 at 11:41:27PM +0300, Lev Serebryakov wrote: > On 19.11.2021 23:16, Lutz Donnerhacke wrote: >>> * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off doing >>> a from-scratch implementation based on netgraph? >> >> I'd prefer a netgraph approach, if possible. >> It helps to concentrate on the important things. > > Isn't netgraph is very PPS-limited due to excessive logging? No. > I thought, MPLS is carrier-grade stuff, and netgraph is very limited now. I do use netgraph for carrier-grade stuff. Yes, ng_bridge was limited, but this is fixed.
Re: Porting OpenBSD MPLS to FreeBSD
On Wed, Dec 08, 2021 at 11:08:38AM +0300, Lev Serebryakov wrote: > On 07.12.2021 17:28, Lutz Donnerhacke wrote: >> I do use netgraph for carrier-grade stuff. >> Yes, ng_bridge was limited, but this is fixed. > Doesn't it take separate lock for each packet passed though hook? I'm sure, > it was true some time ago... It's a read lock for each packet on each, which can be shared by CPUs. I'm not aware that there are a major perfomace penalty, so I'd assume the lock is lightweight.
Re: IPv6 - NS, DAD and MLDv2 interaction
On Wed, Feb 23, 2022 at 01:46:32PM +, Scheffenegger, Richard wrote: > As far as I know, an IPv6 host initially tries to perform Duplicate > Address Detection, as well as Neighbor Discovery / Neighbor Solicitation. > All of this typically works on Ethernet, by mapping into a well-known > Ethernet multicast destination MAC “33-33-xx-xx-xx-xx”. Yup. IPv6 replaced broadcast by multicast on the link layer. > It appears that some vendors of switches have started to become overly > restrictive in forwarding Ethernet Multicast, and only deliver these *after* > a Host has registered itself to receive / participate in specific IPv6 > Multicast groups. May you please drop an information about the vendor? So that we can warn the community to buy those broken products. > So far, I could not find any guidance (and with my lack of depth into > IPv6, it is also unclear to me, if this would even be possible) if > registering a host into a IPv6 MC group via MLDv2 in order for it to receive > NS, ND, DAD is something that would be expected… https://datatracker.ietf.org/doc/html/rfc4861#section-7.2.1 The host must join (using MLDv2) the multicast groups for all of its own addresses to be reachable by Neighbor Discovery. This does not include the standard RD group (IIRC).
Re: em(4) does not autonegotiate when fixed media is set
On Wed, Mar 02, 2022 at 04:40:38PM +0100, tue...@freebsd.org wrote: > Is that what is expected? When using the above command I would expect > that 100MBit/sec is used, not that the card negotiates with the peer > something else. But my expectations might be wrong... Negotation of a given subset is useful. Some devices do not work without negotiation enabled, others refuse to work in this case. Standard requires autonegotiation for 1000TX, recommends it for lower speeds (otherwise assume half duplex). For 1000FX the situation is unclear, depends on the year the device was manufactured ... Today autoneg is expected on all interfaces even with a limited subset of capabilies.
Re: With mpd5 dynamic interfaces, will rtadvd automatically listen?
On Mon, Mar 07, 2022 at 11:09:14AM -0800, Neel Chauhan wrote: > I'm thinking about setting up a dual-stack L2TP server for VPN purposes, > and found that mpd5 lacks good dual-stack support outside of IPv6CP, so we > have to do a makeshift approach. We do use mpd5 for years as PPPoE/L2TP termination (LNS). The IPv6CP is completely sufficient for IPv6 over PPP. > Will rtadvd automatically listen on the mpd5 ng* interface if the said > interface has a public IPv6 address and a user connects (w/ default > config)? Or will I need to trigger rtadvd manually? You can mount a rtavd on the ng* interfaces, but for other routing issues I already deployed Quagga (long time ago), which is able to provide RA to ng* interfaces, too.
Re: how to bridge "native" vlan?
On Thu, Apr 21, 2022 at 02:11:54PM +0200, Patrick M. Hausen wrote:
> > Am 21.04.2022 um 11:29 schrieb Benoit Chesneau :
> > I have an interface on which multiple vlans are connected. I would like to
> > bridge the vlan 100 and 200 but also have a bridge for the "native" vlan 1.
> > I Can setup a bridge for vlan 100 and 200 the way below I think but how to
> > create a bridge for the "native" vlan?
>
> I don't have any experience with netgraph but I do know that
> you cannot do that with if_bridge(4). If you make the physical
> interface the member of a bridge, you cannot use additional
> VLANs on that interface, anymore.
>
> Does anybody know if the same restriction applies to ng_bridge(4)?
ng_bridge does not inspect the ethertypes only the mac addresses of the frames.
So you can split the VLANs using ng_vlan and connect them to the three bridges:
: mkpeer em0: vlan lower downstream
: name em0:lower vlan0
: mkpeer vlan0: bridge 100 0
: mkpeer vlan0: bridge 200 0
: mkpeer vlan0: bridge nomatch 0
: msg vlan0: addfilter { vid=100 hook="100" }
: msg vlan0: addfilter { vid=200 hook="200" }
: name vlan0:100 bridge100
: name vlan0:200 bridge200
: mkpeer em1: vlan lower downstream
: name em1:lower vlan1
: connect vlan1: bridge100: 100 1
: connect vlan1: bridge200: 200 1
: connect vlan1: bridge_untagged: nomatch 1
: msg vlan1: addfilter { vid=100 hook="100" }
: msg vlan1: addfilter { vid=200 hook="200" }
: mkpeer em2: vlan lower downstream
: name em2:lower vlan2
: connect vlan2: bridge100: 100 2
: connect vlan2: bridge200: 200 2
: connect vlan2: bridge_untagged: nomatch 2
: msg vlan2: addfilter { vid=100 hook="100" }
: msg vlan2: addfilter { vid=200 hook="200" }
