Re: netif userland API
28.10.2023 23:43, Roy Marples wrote: > Using netlink rather than route on a modern FreeBSD kernel may allow you do > do the same thing > but install a kernel filter on the socket just to receive interface changes. > > That should match your requirements. This scales bad still. More new vlans under single parent we have, more system calls to list them, longer wall clock time util listing completition and more burden for the system as a whole. I'm talking about *efficient* API. Eugene
Re: netif userland API
28.10.2023 23:21, Roy Marples wrote: > What you would do is open a route socket, then call getifaddrs and then > listen on the route socket for new interfaces. > > Then you can maintain a list of current vlans and take action accordingly. I'd like to be able to make a couple of system calls only to get a list of pre-created vlans for a moment. Efficiently and scalable. Not making thousands of reads (syscalls) from routing sockets and not syncing with the kernel. Eugene
netif userland API
Hi! Assume we run some FreeBSD-based broadband remote access server for PPPoE (net/mpd5 for example). The server has hundreds or thousands vlan interfaces and even more ngXXX interfaces, one per user PPPoE session. The server software may need to enable its PPPoE service for all newly created vlans over another "physical" parent interface just configured in addition to already running ones. I see no effective userland API for the software to list vlan interfaces under specific parent one. The only option I see is getifaddrs(3) function to get list of ALL interfaces in the system then iterate over the list calling ioctl SIOCGETVLAN and if there is no error, compare returned vlr_parent name with the name of needed parent interface. Not efficient at all, while serving new PPPoE connection attempts simultaneously, collecting traffic stats for RADIUS accounting etc. Do I miss something? Eugene
Re: IPSEC problems with pf
26.09.2021 10:12, Peter Jeremy wrote: > I'm confident that the last point is because the IPSEC processing preceeds > the pfil processing on outbound packets, so they aren't seen as eligible > because IPSEC is seeing the internal, rather than external, address. I found it much suitable to keep IPSec transport mode but also create gif(4) tunnel between "firewal" and "VPS" with its own pair of internal IP addresses, so traffic can be encapsulated into the tunnel first and then encrypted. So it does not need to be NAT-ed.
Re: IPSEC problems with pf
CC'ing more knowledgeable developers. 25.09.2021 6:03, Peter Jeremy wrote: > I don't understand: > a) Why outgoing ICMP packets from firewall to VPS aren't going through >the IPSEC transport. > b) Why firewall is ignoring incoming IPSEC esp packets. > > Is anyone able to help? I know three main reasons that may prevent firewall+IPSec from working as expected: 1) for incoming packets: kernel could drop incoming packet withing ipsec code incrementing one of counters shown with "netstat -sp ipsec" command, so you should check it out first; 2) for both outgoing and incoming packets there could be processing order problem: packets processed first by pfil(9) framework (so pf/ipfw have a chance to do NAT etc.) and only then sent to ipsec(4) to transform (in FreeBSD 11 at least), not vice versa. 3) also read if_enc(4) manual page to make familiar with net.enc.out.* and net.enc.in.* sysctl family, as it may affect, too. If you do not use enc(4) pseudo-interface, make sure you changed defaults to: net.enc.in.ipsec_filter_mask=0 net.enc.out.ipsec_filter_mask=0
Re: Performance of PPPOE in FreeBSD
21.09.2021 2:32, driesm.michi...@gmail.com wrote: > I have also found some mentions of net/mpd5, is this a better > implementation? Basically, it all depends on available CPU horsepower and if you have plenty of it unused, you can stick with base ppp(8). But in any case, net/mpd5 provides huge CPU usage decrease and it will give you more speed if the router found CPU-bound.
Re: TCP connection ignore RST
04.09.2021 6:37, Rozhuk Ivan wrote: > Hi! > > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host and > continue retransmitting packets. > sockstat show that socket connected even after many tcp rst packets received. > > Any ideas how to fix it? First make sure your packet filter does not drop RST packet.
Re: Creating/destroying bulk VLAN interfaces takes too long
30.08.2021 14:13, Özkan KIRIK wrote: > Any suggestions? 1) Try stopping devd before test to see if it helps. devd runs LOTS of shell code upon interface creation. 2) Try "ifconfig em1 down" before test and "ifconfig em1 up" after. Also, look at kernel logs with timestamps to see how much time it takes for kernel to respond on new vlan arrival.
Re: How to run script on network address change?
20.06.2021 20:52, Rozhuk Ivan wrote
> Hi!
>
>
> I have FreeBSD 13@amd64 router with DHCP client on uplink.
>
> How to run script on IP address change?
Here is my /etc/dhclient-enter-hooks I use with FreeBSD 11 and stock dhclient
for a system with two distinct ISP uplinks. It replaces some of default hooks:
#!/bin/sh
# Ignore ISP DNS servers as we run our own resolver
add_new_resolv_conf() {
return 0
}
add_new_address() {
# Perform interface configuration
eval "$IFCONFIG $interface \
inet $new_ip_address \
netmask $new_subnet_mask \
broadcast $new_broadcast_address \
$medium"
# Save ISP gateway address with interface description for easy access
eval '$IFCONFIG $interface description "gw $new_routers"'
# Generate nice logs
$LOGGER "New IP Address ($interface): $new_ip_address"
$LOGGER "New Subnet Mask ($interface): $new_subnet_mask"
$LOGGER "New Broadcast Address ($interface): $new_broadcast_address"
$LOGGER "New Routers ($interface): $new_routers"
# Some additional logic may be added here like switching default route
return 0
}
# EOF
Re: Src IP 0.0.0.0 for outgoing off-net ping & SSH packets
21.04.2021 23:35, gfoster...@charter.net wrote: > Do you have any tips or specific areas of the routing code I should be > looking into ? ping using 0.0.0.0 as source address means you have an inteface without any IP address assigned, indeed. And this is the interface selected as outgoing for requests. If you have such interfaces and observe 0.0.0.0 as source, you should stop relying on automatic source IP selection and supply some IP manually, instead: ping -S $myip $destination Same with ssh -b etc. I have similar setups with vlan interfaces without IP that generally used to route /32 prefixes into, so I have to use ping -S in such cases, it helps. ___ 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: TCP Connection hang - MSS again
06.04.2021 19:54, Rodney W. Grimes wrote: >> 05.04.2021 19:44, Rozhuk Ivan wrote: >> > As I understand, in some cases remote host does not reply with MSS > option, and host behind router continue use mss 8960, that dropped > by router. If the peer does not provide an MSS option, your local FreeBSD based host should use an MSS of net.inet.tcp.mssdflt bytes. The default is 536. So I don't think this should be a problem. >>> >>> Thats it! >>> Thanks, it was ~64k in mine config. >> >> This is also per-host setting, you know :-) >> >> It is generally bad idea using MTU over 1500 for an interface facing public >> network >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is >> also UDP >> that happily produces oversized datagramms for DNS or RTP or NFS or >> tunneling like L2TP or OpenVPN etc. >> relying on IP fragmentation. >> >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > I do not recommend such a setting. That would defeat any jumbo frame usage > locally! Why? Default route should not be used for local delivery. > The gateway/router that is forwarding packets to the internet connection > needs its upstream interface mtu set properly, and configured to properly > return icmp need fragement messages on the interfaces towards the > internal network. This results in extra delays and retransmission during outgoing data transfer, not good. The mechanics is much more fragile than default route's mtu attribute. ___ 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: TCP Connection hang - MSS again
05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is >> 536. So I don't think this should be a problem. > > Thats it! > Thanks, it was ~64k in mine config. This is also per-host setting, you know :-) It is generally bad idea using MTU over 1500 for an interface facing public network without -mtu 1500. You see, because TCP MSS affects only TCP and there is also UDP that happily produces oversized datagramms for DNS or RTP or NFS or tunneling like L2TP or OpenVPN etc. relying on IP fragmentation. I still recommend using -mtu 1500 in addition to mssdflt in your case. ___ 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: TCP Connection hang - MSS again
05.04.2021 16:44, Rozhuk Ivan wrote: > Is any other other options to work around this? Yes. Each entry in the routing table has "mtu" attribute limiting TCP MSS, too. You should use default route with -mtu 1500 attribute. For example, in /etc/rc.conf: defaultroute="X.X.X.X -mtu 1500" ___ 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: How to not send traffic to TCP/IP stack
29.01.2021 22:15, Kajetan Staszkiewicz wrote: > So far so good. But what if a LB wants to access the service? > > SYN: > 1. LB sends out a packet through public interface becuase that's where > the default gateway points. > 2. Core router sends the packet to one of LBs, in this case the same one > who originated the packet. > 3. It arrives at the public interface of LB where it is matched against > a route-to pf rule. A public-side pf state is created, a tag is assigned. > 4. pf's rout-to routes it to a LB Node / target. > 5. Leaves the LB over internal interface, matches the tag, another state > is created. > > ACK: > 1. From LB Node > 2. Hits internal interface of LB, the state is already there. > 3. Normal routing decision of LB decides to send the packet to IP stack. > 4. The packet never hits the pf state on the public side of LB. > 5. The public side pf state never sees ACK from the LB Node, the state > times out very fast. > > My goal is to have loadbalanced connections to *always* behave like they > come from the Internet, that is to leave the LB and bounce off the core > router. I'm not a pf user, so I wonder: why do you need to create any firewall state for such traffic at all? Can't you route such packets in stateless mode? I don't see any value in pf states for such packets. ___ 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: 'dropped due to full socket buffers' by SNMP
22.01.2021 20:26, Victor Gamov wrote:
What FreeBSD version do you use currently? Do you use IPv6 for UDP or
IPv4 only?
>>>
>>>
>>> FreeBSD 12.2-STABLE r366543 GENERIC amd64
>>>
>>> UDP-4 only
>>
>> In case of IPv4 UDP the counter "dropped due to full socket buffers"
>> is increased for incoming packets only. Therefore, the problem is in a code
>> processing incoming stream(s): either it locks for long time on something,
>> or it just has no enough raw CPU horsepower to deal with incoming stream.
>>
>> Look at "top -SHPI" CPU counters, if your CPU cores are loaded evenly;
>
> it's CPU E3-1270 v6 @ 3.80GHz with WCPU about 60% idle + 9%
> kernel{if_io_tqg_X) + 5% intr{swi1: netisr X). And many processes about 1%
> WCPU for multicast receive/resend (one for every multicast)
>
> Also "netstat -na -p udp" shows me zero or very small Recv-Q
>
>> if some of cores became overloaded sometimes. You should also draw per-cpu
>> load graphs.
>> (f.e. sysctl kern.cp_times)
>
> I have SNMP stats and it show me about 40% load
There is no standard MIBs to show per-core load. You get only an average via
standard SNMP MIBs
and average can be misleading and hide 100% load of some cores.
If you really have no overloaded cores, then this should be locking problem
that prevents processing code
to do its job timely.
___
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: 'dropped due to full socket buffers' by SNMP
22.01.2021 19:28, Victor Gamov wrote: > On 22.01.2021 13:21, Eugene Grosbein wrote: >> 22.01.2021 17:02, Victor Gamov wrote: >> >>> No link overload: this host attached to network via 10G ix0, many >>> VLANs on this ix0 and some sender on every VLAN sends multicast >>> traffic to this host. Total input traffic about 1Gbit/s >> >> What FreeBSD version do you use currently? Do you use IPv6 for UDP or >> IPv4 only? > > > FreeBSD 12.2-STABLE r366543 GENERIC amd64 > > UDP-4 only In case of IPv4 UDP the counter "dropped due to full socket buffers" is increased for incoming packets only. Therefore, the problem is in a code processing incoming stream(s): either it locks for long time on something, or it just has no enough raw CPU horsepower to deal with incoming stream. Look at "top -SHPI" CPU counters, if your CPU cores are loaded evenly; if some of cores became overloaded sometimes. You should also draw per-cpu load graphs. (f.e. sysctl kern.cp_times) ___ 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: 'dropped due to full socket buffers' by SNMP
22.01.2021 17:02, Victor Gamov wrote: > No link overload: this host attached to network via 10G ix0, many VLANs on > this ix0 and some sender on every VLAN sends multicast traffic to this host. > Total input traffic about 1Gbit/s What FreeBSD version do you use currently? Do you use IPv6 for UDP or IPv4 only? ___ 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: 'dropped due to full socket buffers' by SNMP
22.01.2021 16:27, Victor Gamov wrote: > I increase kern.ipc.maxsockbuf from 2097152 -> 2597152 -> 3145728 but > netstat -sn -p udp | grep 'dropped due to full socket buffers' still show > dropped packets. > > Then I increase net.inet.udp.recvspace 84160 -> 105200 but 'dropped due to > full socket buffers' packets still here. > > Do I need to try to increase something else? Increase of various buffers may help against very short traffic bursts or limited time interface congestion. It won't help in case you have permanent (or nearly permanent) link overload. ___ 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: 'dropped due to full socket buffers' by SNMP
05.01.2021 16:39, Victor Gamov wrote:
>>> As I understand hw.ix.flow_control=3 to allow flow-control for negotiation.
>>> Real PAUSE setting will be set during negotiation.
>>
>> At the moment of congestion.
>
> As I understand PAUSE feature negotiated during auto-negotiation process. If
> flow-control disabled on one side (switch for example) then other side (host)
> will not to use this feature too. Is it right?
Modulo firmware bugs.
>>> So where I can find active flow-control setting for host interface?
>> Can't check for ix just now, but for em(4) there is sysctl dev.em.0.fc.
>> It should be similar for ix.
> I have hw.ix.flow_control=3 (what does is it means ?) and dev.ix.0.fc=3 (and
> what does is it means?)
/* Flow Control Settings */
enum ixgbe_fc_mode {
ixgbe_fc_none = 0,
ixgbe_fc_rx_pause,
ixgbe_fc_tx_pause,
ixgbe_fc_full,
ixgbe_fc_default
};
So, ixgbe_fc_full = 3 (full rx/tx flow control enabled, see
sys/dev/ixgbe/ixgbe_type.h).
> Back to my original question: is it possible to monitor `netstat -n -p udp -f
> inet -s` counters by SNMP?
There is no standard MIB for these counters but you may always export it with
net-mgmt/bsnmp-ucd port
and custom OIDs if you use stock bsnmpd (bsnmp-ucd man page has an example).
There is similar possibility for net-snmpd.
___
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: 'dropped due to full socket buffers' by SNMP
30.12.2020 23:08, Victor Gamov wrote: > As I understand hw.ix.flow_control=3 to allow flow-control for negotiation. > Real PAUSE setting will be set during negotiation. At the moment of congestion. > So where I can find active flow-control setting for host interface? Can't check for ix just now, but for em(4) there is sysctl dev.em.0.fc. It should be similar for ix. >> maybe increase kern.ipc.maxsockbuf and then net.inet.udp.recvspace. > Eugene, at first message you suppose Host-A (sender) "outgoing link for that > UDP packets is congested" > because this host shows non-zero "dropped due to full socket buffers". > So is net.inet.udp.recvspace increasing on Host-B (mainly receiver) will be > affected for this congestion? Can't tell in details without going deep into your setup :-) You can try it yourself and verify quickly. > Or I need to try to increase both kern.ipc.maxsockbuf and > net.inet.udp.recvspace on both hosts? Tune one that drops UDP. > Also how I can check current sockbuf usage? netstat -xn ___ 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: 'dropped due to full socket buffers' by SNMP
30.12.2020 16:44, Victor Gamov wrote: > Currently I'm thinking about ethernet flow control: Host-B connected to > VLAN-750 on the third switch has 1G link (via igb driver) > and both Host-A and Host-B has fc=3. So when Host-B get microburst it can > send PAUSE and Host-A start to fill queue. > But FC disabled for all switches and I'm not sure about PAUSE can be > propagated from Host-A to Host-B AFAIK, pause frames are not forwarded. For short term you should make flow control settings consistent between link partners, maybe increase kern.ipc.maxsockbuf and then net.inet.udp.recvspace. But for long term you should consider adding more links and create LACP aggregate so not input nor output link be close to congestion. ___ 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: 'dropped due to full socket buffers' by SNMP
29.12.2020 23:36, Victor Gamov wrote: Please do not top-post. > Thanks. > > > On 30/11/2020 18:33, Victor Gamov wrote: >> Hi All >> >> Can somebody help me to get UDP 'dropped due to full socket buffers' by >> SNMP? Is it possible? Now I'm getting it with >> `netstat -n -p udp -f inet -s` >> but SNMP will be more useful for remote monitoring. >> > And one more question about 'dropped due to full socket buffers': how to > avoid it? Which params must be tuned? Both problems generally mean that outgoing link for that UDP packets is congested, so socket buffers start to fill until they are full. What is "media" for that UDP data - some syntetic tunnel or plain ethernet link or something else? You may find useful this old thread dealing with similar problem: http://freebsd.1045724.x6.nabble.com/SNMP-No-Bufferspace-td6333081.html ___ 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: ipfw nat bug
30.11.2020 16:10, Eugene Grosbein wrote: > Hi! > > It seems I'm facing a bug in NAT44 ipfw nat/libalias implementation. > > Suppose we have a LAN 192.168.0.0/24 and two WAN channels with public IP > addresses > and internal server 192.168.0.100 that serves connection to the port 5060, > both TCP and UDP, > so we configure redirects: > > nat 1 config if vlan1 reset same_ports \ > redirect_port tcp 192.168.0.100:5060 5060 > redirect_port udp 192.168.0.100:5060 5060 > > Same for nat 2 and vlan 2. And it works just fine. > > Then, this server 192.168.0.100 makes *outgoing* connection to external host > A and udp port 5060, to destination port 5060 and uses *source* port 5060, too > same_ports keeps outgoing port 5060 and it works fine, too. same_ports keeps *source* port 5060 for outgoing aliasing state > Now, this server 192.168.0.100 makes second outgoing UDP connection over same > WAN > to different external IP address using same NAT instance. > > The source port get changed to dynamic one and here we have a problem: > incoming UDP response is NOT translated with a rule: > > nat 1 ip from any to any in recv vlan1 > > So, this UDP packet is not delivered to 192.168.0.100 but local delivery is > performed > resulting in ICMP port unreachable. > > 16:06:23.232792 IP X.X.X.X.60949 > Y.Y.Y.Y.5060: SIP: OPTIONS sip:AAA@BBB > SIP/2.0 > 16:06:23.249020 IP Y.Y.Y.Y.5060 > X.X.X.X.60949: SIP: SIP/2.0 200 OK > 16:06:23.249062 IP X.X.X.X > Y.Y.Y.Y: ICMP X.X.X.X udp port 60949 > unreachable, length 36 > > Two questions: is it right that dynamic port is used for second connection to > different host > and how do I fix 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: How to connect to a Wifi AP w/o much information from its provider
15.10.2020 13:02, Matthias Apitz wrote: > > Hello, > > The school of my son offers Wifi to the pupil. The SSID is "Schueler" > and each of the kids has a login and password assigned from the school. Not > more > information. An iPhone connects out of the box by just asking for the > two values (login/password). With our wpa_supplicant I couldn't get how to > set accepted values. > > I have here what the ifconfig command on my laptops says about the AP values: > > > # ifconfig -v wlan0 list ap | egrep 'SSID/MESH|Schueler' > > Schueler 20:a6:cd:04:d8:636 54M -73:-96 100 EPS > SSID RATES DSPARMS<6> TIM<05040001> ERP<0x0> > RSN HTCAP mcsset[0-15] extcap 0x0 txbf 0x0 antenna 0x0> HTINFO basicmcs[]> ???<7f0804000840> WME cwmax 10 txop 0] BK[aifsn 7 cwmin 4 cwmax 10 txop 0] VO[aifsn 2 cwmin 3 cwmax > 4 txop 94] VI[aifsn 2 cwmin 2 cwmax 3 txop 47]> VEN This looks like "WPA-Enterprise" authentication method, see section 31.3.4.1.3.2 of the Handbook: https://www.freebsd.org/doc/handbook/network-wireless.html ___ 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"
IP reassembly
Hi! Is our IP reassembly facility supposed to handle incoming out-of-order fragments? For example, IPIP packet created with gif(4) interface is fragmented with two parts, and parts are delivered out of order, last fragment comes first. In fact, I see this results in broken reassembly. ___ 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: sshd on two fibs
21.09.2020 14:21, Grzegorz Junka wrote: >> All you need is telling kernel to use right gateway based on source IP >> address despite of default route, >> this is called policy-based routing and you can achieve that with single >> ipfw rule: >> >> ipfw add 2000 fwd $gateway2 ip from $wan2ip to any out xmit $wan1 >> >> That is: redirect IP packets with source of second WAN interface ($wan2ip) >> to right gateway of that WAN ($gateway2) >> if they are going using (wrong) route to WAN1. That's all. > > Thanks Eugene. I am reluctant to add firewall rules because the second > interface is configured as being in fib 1. Existance of the fib 1 does not matter for your case, at all. > This is so that jails, which are also started with fib 1, can use the proper > routing table. Exactly. > I don't want to add complexity where it isn't necessary, unless there is no > other option. Me too. And single ipfw rule is minimal possible addition, all other solutions are more complex. > Is it possible to somehow configure sshd to use the proper routing table? It is possible but it won't help you because every routing table contains routes that do NOT depend on source IP address of the packet and you need such policy-based routing. Standard routing tables do not offer policy-based routing, so they are useless for you. You could read rc.conf(5) manual page to learn about _fib knob (f.e. sshd_fib="1") but it won't solve your problem. You could also add your own startup script to run second copy of sshd with its own PID file and listening IP address and FIB but that would be much more complex solution. Just tell kernel you need policy-based routing with ipfw. This just works. No need to utilize second FIB just because you already have it. ___ 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: sshd on two fibs
21.09.2020 6:20, Grzegorz Junka wrote: > I have two WANs and a server with two interfaces, each interface reaching > different WAN. The server is configured with two routing tables, fib0 and > fib1, one per the corresponding interface. > > I would like sshd to listen on both interfaces but on different fibs, so that > returning packets are sent to the proper gateway. Can I do it with one sshd? > Do I need to run two separate sshd's? Can I run two separate sshd's on the > same box? sshd listens for all IPs by default. Also, sshd runs over TCP and this guarantees that it responds from same IP address which was used by initial client's request, too. You need not worry about that. Also, you already have static link between source IP address of sshd response, corresponding WAN interface and gateway IP address of that WAN interface. All you need is telling kernel to use right gateway based on source IP address despite of default route, this is called policy-based routing and you can achieve that with single ipfw rule: ipfw add 2000 fwd $gateway2 ip from $wan2ip to any out xmit $wan1 That is: redirect IP packets with source of second WAN interface ($wan2ip) to right gateway of that WAN ($gateway2) if they are going using (wrong) route to WAN1. That's all. ___ 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: BCM57810 networkd card with SR-IOV : No driver detected
19.09.2020 5:10, Trevelian wrote: > I have a HP network card "533FLR-T" its based on "NetXtreme II BCM57810" > This card is capable to be used with SR-IOV, so I can have 64 NIC on each > physical port that I can passthrough from my Linux hypervisor to my Linux and > BSD guest VM. > > On Linux guest VM no problem I see the NIC on my VM and I can use it : > > |# lspci 01:00.0 Ethernet controller: Broadcom Inc. and subsidiaries > NetXtreme II BCM57810 10 Gigabit Ethernet Virtual Function| > > On BSD guest VM (I tested 11.3 and 12.1) the card seems to be not detected : > > |# dmesg pci0: at device 8.0 (no driver attached) # > pciconf -lv none0@pci0:0:8:0: class=0x02 card=0x3382103c chip=0x16af14e4 > rev=0x00 hdr=0x00 vendor = 'Broadcom Inc. and subsidiaries' device = > 'NetXtreme II BCM57810 10 Gigabit Ethernet Virtual Function' class = network > subclass = ethernet ||# kldload if_bxe kldload: can't load if_bxe: module > already loaded or in kernel| > || > > I try to force the driver with : > > |#devctl set driver pci0:0:8:0 bxe| > | > | > But it don't gave me any new network interface. > > Do you have any idea if its possible to make it work or the BXE driver is > just not compatible with the Virtual Function of this card ? It seems bxe(4) does not implement attaching to Virtual Function. Can't tell if it's by mistake or intentionally. CC'ing author of the driver davidch@ ___ 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: ifconfig_*="DHCP" in absence of server
18.09.2020 20:05, Gleb Popov wrote: > However, the networking on FreeBSD machines started to come up even longer. > I suspect this is because dhclient gradually increases the interval between > DHCP requests if it doesn't get an answer. Our dhclient does logging via syslog, so you should setup syslog.conf: !dhclient *.* /var/log/dhclient.log You'll know exactly what is happening. ___ 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: ifconfig_*="DHCP" in absence of server
18.09.2020 20:05, Gleb Popov wrote:
>> Look for "background_dhclient" in the rc.conf manual page, it merely adds
>> "-b"
>> to dhclient flags.
>>
>>
> Thanks, this indeed improved things for the "netif" part of the problem.
> But it still waited 30s for "default route interface". I found the
> ${defaultroute_delay} variable in /etc/rc.d/defaultroute, which isn't
> documented, and set it to "1s" in /etc/rc.conf. This finally did the trick.
>
> However, the networking on FreeBSD machines started to come up even longer.
> I suspect this is because dhclient gradually increases the interval between
> DHCP requests if it doesn't get an answer. I haven't found a way to
> circumvent this. Any suggestions are welcome.
Read dhclient.conf(5) manual page :-)
___
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: ifconfig_*="DHCP" in absence of server
17.09.2020 22:07, Gleb Popov wrote: > At $WORK I'm running a bunch of similar FreeBSD machines, all of them have > > ifconfig_DEFAULT="DHCP" > > in their /etc/rc.conf > > The DHCP server runs on some old Cisco router. > > At the start of the working day the power switch gets turned on and both > the router and FreeBSD machines start simultaneously. FreeBSD boots faster > than Cisco, but then hangs on "netif" rc script trying to acquire an IP > from the router. It waits for more than 30 seconds before giving up and > proceeding, and even after that the "routing" script blocks for another 30 > second with "waiting for default route". This delays the time needed to > reach the X graphics stage for too long. > > Funny enough, "SYNCDHCP" option shortens this time, but it is still visible. > > Is there any way to make DHCP acquisition asynchronous, or something else > to speed things up? Look for "background_dhclient" in the rc.conf manual page, it merely adds "-b" to dhclient flags. ___ 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: How change RSS Hash function for igb ?
13.09.2020 12:28, Özkan KIRIK wrote: > I'm using FreeBSD stable/12. Is it possible ? > > On Fri, Aug 28, 2020 at 10:56 PM Özkan KIRIK wrote: > >> Hi, >> >> I need to change RSS Hash function to 2-tuple for igb driver. >> How can I do it ? >> I didn't see any sysctl. >> If there is any way even by modifying driver code I want to try. I believe it's not possible. Are you sure your card supports changing RSS Hash? I'm not aware of any igb-supported card that can do that. ___ 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: IP "routing" issue
10.09.2020 23:54, Abelenda Diego wrote: > Thank you for pointing route "-iface" however I can't seem to manage what I > want. > > When I use: > "route add -host $IP_NOT_IN_SUBNET -iface bce0" > > I get "netstat -rn" to say someting like: > > Internet: > DestinationGateway Flags Netif Expire > default$UPSTREAM_GW UGSbce0 > 10.0.0.1 link#7UHS lo0 > $IP_NO_IN_SUBNET $MAC_ADDRESS_OF_BCE0 UHSbce0 > > > Which seem somehow appropriate, so I try to ping $IP_NOT_IN_SUBNET and I get: > > root@opnsense2:~ # ping $IP_NOT_IN_SUBNET > PING $IP_NOT_IN_SUBNET ($IP_NOT_IN_SUBNET): 56 data bytes > 36 bytes from $UPSTREAM_GW: Redirect Host(New addr: $PUBLIC_IP_OF_BCE0). > > Which doesn't seem appropriate at all wrt the routing table... Such route means that an attempt to send any packet to the IP in question results in broadcast ARP query for destination IP sent out of bce0. It seems your upstream has arp proxy enabled, so it sends ARP reply with its MAC address making your host send IP packet to $UPSTREAM_GW, but its routing table points back to your $PUBLIC_IP_OF_BCE0, hence redirection is generated. You should not use "-iface bce0" but right interface name pointing to host having target IP address. And if your own host has it, you do not need to add any route at all, but assign additional IP as alias to bce0. ___ 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: IP "routing" issue
09.09.2020 21:42, Abelenda Diego wrote: > I've got a FreeBSD installation in a DataCenter that provided me with a single > address IPv4 with an upstream gateway (cidr is fine the upstream gateway works > everything is nice and running). I use this machine for Masquerading an > private > infrastructure. > > Now I need other machines with public IPv4 and when I requested the additional > IPv4 to the DataCenter, they gave me a bunch of /32 addresses saying that > my previous IPv4 MUST be configured as next-hop on their side. > From my understanding in FreeBSD the route command is unable to perform this > kind of configuration where you tell that the IPv4 /32 is available without > next-hop (no via) on a specific link. I know the linux "ip route add $IP dev > $LINK" configures this, but I cannot seem to map this knowledge to FreeBSD. > > Is it possible to perform this very special setup with any command on FreeBSD? > If yes what is that command? This setup is not special and FreeBSD can do it, of course. route add 1.1.1.1/32 2.2.2.2 route add 1.1.2.1/32 -iface vtnet0 In this example 2.2.2.2 plays role of your old public IP and 1.1.X.X are for new addresses routed via 2.2.2.2 or directly to interface vtnet0. And there is rc.conf settings "static_routes" to create such setup: static_routes="host1 host2 host3" route_host1="1.1.1.1/32 2.2.2.2" route_host2="1.1.2.1/32 -iface vtnet0" This is documented with route(8) and rc.conf(5) manual pages. In case of P2P interface such variants have no real difference other than used way to specify outgoing interface: by next-hop address or by interface name. P2P interface may have no address assigned for remote side. In case of Ethernet-link interface the difference is related to underlying ARP protocol cache, will it be asked for MAC address of specified next-hop or directly for MAC address of target like 1.1.2.1. ___ 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: Is anybody using ng_pipe?
19.08.2020 0:17, Ryan Stone wrote: > where dummynet wasn't possible Sorry, missed that. But why wasn't possible? If you could use ng_pipe, you could probably use ng_ipfw too, or maybe create small node ng_dummynet to connect NETGRAPH network with kernel-side dummynet directly. ___ 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: Is anybody using ng_pipe?
19.08.2020 0:17, Ryan Stone wrote: > I'd like to dump all of this and just implement a packet loss rate, > which would simplify all this immensely. Is anybody using ng_pipe > with a non-zero BER who would object to this? Given this litany of > issues I doubt it, but I thought that I'd be sure. Take a look at dummynet(4): kldload dummynet # adds (optional) queueing delay plus 10 ms additional delay ipfw pipe 1 config bw 100Mbit/s delay 10 # add packet drop probability ipfw add 3000 prob 0.05 deny ip from any to any in # apply bandwidth limit/delay ipfw add 3010 pipe 1 ip from any to any in ___ 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: poor performance with Intel X520 card
16.07.2020 16:03, Eugene Grosbein wrote: > 16.07.2020 14:57, Patrick Lamaiziere wrote: > >>> I'm sure pf is the bottle-neck. Try testing such card without any >>> packet filter enabled and you'll see great difference definitely. >> >> That's not a good news as I don't see how to simplify the ruleset :( >> But thanks anyway :) ix0: netmap queues/slots: TX 8/2048, RX 8/2048 Also, there are no reasons to use default rxd/txd slot values (2048), you should max it out with /boot/loader.conf, too: hw.ix.rxd=4096 hw.ix.txd=4096 Assuming you run 64 bit system with 1GB memory or more. ___ 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: poor performance with Intel X520 card
16.07.2020 14:57, Patrick Lamaiziere wrote: >> I'm sure pf is the bottle-neck. Try testing such card without any >> packet filter enabled and you'll see great difference definitely. > > That's not a good news as I don't see how to simplify the ruleset :( > But thanks anyway :) First, you need to determine if all your CPU cores loaded evenly or not. Use top -SHPI to check it out. It's possible that they are not because defaults could be not optimal for your hardware and you have bottle-neck just because of wrong settings for hardware receiving queues of the NIC: FreeBSD/SMP: 2 package(s) x 6 core(s) ix0: Using MSI-X interrupts with 9 vectors This means 8 RX/TX queues (plus one link queue) for your 12 cores, not good. 8 is driver's default for systems with 8 cores or more unless you override it with hw.ix.num_queues=12 in /boot/loader.conf, do it. Also you should monitor interrupt counters for receiving queues for the card with "systat -vm 3" (in real time) and with vmstat -ai | grep ix0 (cumulative). If you have interrupts evenly distributed over receiving queues but still uneven CPU cores load, that would be next problem to deal with. Maybe you'll need to (re-)bind queues to cores with cpuset(1). Or maybe your received queues are loaded not evenly due to nature of Ethernet frames you work with, f.e. non-IP ethernet traffic (PPPoE frames) or many non-TCP/UDP IP packets (GRE, ESP etc.) cpuset will be your friend for that case, too. ___ 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: [Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
16.07.2020 14:12, lutz_donnerhacke.de (Lutz Donnerhacke) wrote: > > ce(4) for PCI G.703/E1 card, > > cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards, > > and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 > anymore, > > removed by emaste@ recently. > > > > Both ce(4) and cp(4) are i386-only drivers at present. > > Such synchronous lines are still in use (here): > > - G.703 is common in phone systems. > - X.21 for leased lines (with old contracts), > - E1/E3 for SDH (carrier grade) leases lines. > - RS-232 is the ordinary serial port, the other RS- are industry specific > serials (mainly other voltages) This is not about lines and protocols, this is about old PCI cards for PCs manufactured 15+ years ago. > But you are right: Do we really need a specialized PPP hardware support > these days? > Do we really want to run a recent kernel on this antique hardware? It would > be a sacrilege. > > Normal PPP over serial lines (currently available) does work using ppp(4) ___ 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"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net removed subscribers: freebsd-net-list, emaste. eugen_grosbein.net added a comment. Sorry for the mess, my latest actions on this differential were unintentional, some problems with old Firefox. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, freebsd-net-list, emaste, krzysztof.galazka_intel.com ___ 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"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net reclaimed this revision. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, freebsd-net-list, emaste, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, krzysztof.galazka_intel.com ___ 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"
[Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
eugen_grosbein.net commandeered this revision. eugen_grosbein.net added a reviewer: neel_neelc.org. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D25681/new/ REVISION DETAIL https://reviews.freebsd.org/D25681 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: eugen_grosbein.net, neel_neelc.org Cc: eugen_grosbein.net, freebsd-net-list, emaste, imp, ae, melifaro, #contributor_reviews_base, #network, #transport, mmacy, kpraveen.lkml_gmail.com, marcnarc_gmail.com, simonvella_gmail.com, novice_techie.com, christianchristensen_gmail.com, tommi.pernila_iki.fi, krzysztof.galazka_intel.com ___ 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: [Differential] D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options
CCing Roman Kurakin (ce(4)) and Serge Vakulenko (cp(4)), see later. 16.07.2020 9:23, neel_neelc.org (Neel Chauhan) wrote: > neel_neelc.org abandoned this revision. > > REPOSITORY > rS FreeBSD src repository > > CHANGES SINCE LAST ACTION > https://reviews.freebsd.org/D25681/new/ > > REVISION DETAIL > https://reviews.freebsd.org/D25681 I wonder if we really have use cases for sppp(4)/ng_sppp(4) these days. This code was created in 199x to support some synchronous Cronyx adapters and their drivers: ce(4) for PCI G.703/E1 card, cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards, and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore, removed by emaste@ recently. Both ce(4) and cp(4) are i386-only drivers at present. I could not find any other consumers of sppp code in base system and I doubt there are outside base, but I may be wrong. I'd like to see some comments from rik and vak, though. ___ 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: poor performance with Intel X520 card
10.07.2020 13:45, Patrick Lamaiziere wrote: > Hello, > > That is mostly for the record but it looks like the intel X520 is not > very good and generates a high level of interrupts. > > On a router / firewall with 500 Kpps in input (dropped by pf) is enough to > put the CPUs at > 100% busy. [skip] > Well, do you think another NIC cards can help to reach a better pps rate ? I > think 500 Kpps is quite low for such a machine. I'm sure pf is the bottle-neck. Try testing such card without any packet filter enabled and you'll see great difference definitely. ___ 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: making SCTP loadable and removing it from GENERIC
10.07.2020 2:44, Doug Hardie wrote:
>> On 9 July 2020, at 08:13, Mark Johnston wrote:
>>
>> Hi,
>>
>> I spent some time working on making it possible to load the SCTP stack
>> as a kernel module, the same as we do today with IPSec. There is one
>> patch remaining to be committed before that can be done in head. One
>> caveat is that the module can't be unloaded, as some work is needed to
>> make this safe. However, this obviously isn't a regression.
>>
>> The work is based on the observations that:
>> 1) the in-kernel SCTP stack is not widely used (I know that the same
>> code is used in some userland applications), and
>> 2) the SCTP stack is quite large, most FreeBSD kernel developers are
>> unfamiliar with it, and bugs in it can easily lead to security holes.
>>
>> Michael has done a lot of work to fix issues in the SCTP code,
>> particularly those found by syzkaller, but given that in-kernel SCTP has
>> few users (almost certainly fewer than IPSec), it seems reasonable to
>> require users to opt in to having an SCTP stack with a simple "kldload
>> sctp". Thus, once the last patch is committed I would like to propose
>> removing "options SCTP" from GENERIC kernel configs in head, replacing
>> it with "options SCTP_SUPPORT" to enable sctp.ko to be loaded.
>>
>> I am wondering if anyone has any objections to or concerns about this
>> proposal. Any feedback is appreciated.
>
> I have a number of systems using SCTP. It is a key part of a distributed
> application. As a user of SCTP, I have a slight objection to removing it
> from the kernel. It would require me to remember when setting up a new
> system to enable that. I am not likely to remember. What is going to happen
> if you run an application that uses SCTP and the module is not loaded? What
> will remind me how to fix the issue? I am not likely to remember about this
> 6 months from now.
If an application starts with superuser privileges (as root), it is allowed to
perform the check
and load the module if needed:
int
modload(const char *name)
{
if (modfind(name) < 0)
if (kldload(name) < 0 || modfind(name) < 0) {
warn("%s: module not found", name);
return 0;
}
return 1;
}
...
modload("sctp");
This works for both cases of sctp built into the kernel and already loaded as
module.
Alternatively, if an application already has rc.d startup script, you don't
even need to change
application source code but add required_modules="sctp" to the script, see
rc.subr(8),
then sctp.ko would be loaded automagically if it was not loaded yet and not
present in the kernel.
___
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: making SCTP loadable and removing it from GENERIC
09.07.2020 23:59, Michael Tuexen wrote: >> This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new startup >> script >> /etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if sctp.ko already loaded >> and load it as needed; >> c) applies sctp sysctl tuning from /etc/sysctl.conf for values that differ. > The only difference between this and loading it from /boot/loader.conf I see > is that the above also works on some PPC platforms. Am I missing something? This is mostly optimization issue as kld_list from /etc/rc.conf is processed when kernel is up and running so file system cache is engaged to cache directories etc. Loader reads modules much slower especially for slow media like CompactFlash. Also, some platforms like MIPS32 using U-Boot have no loader at all. U-Boot may start kernel directly. ___ 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: making SCTP loadable and removing it from GENERIC
09.07.2020 22:41, Michael Tuexen wrote: >> I am wondering if anyone has any objections to or concerns about this >> proposal. Any feedback is appreciated. I'm for it. > maybe it is acceptable to document user visible changes. This could include > * parameter tunings in /etc/sysctl.conf are only applied if the SCTP module > is loaded from /etc/loader.conf. You mean /boot/loader.conf. This may be relaxed with "sctp_enable" knob for /etc/rc.conf and new startup script /etc/rc.d/sctp that: a) REQUIRE: kld; b) checks if sctp.ko already loaded and load it as needed; c) applies sctp sysctl tuning from /etc/sysctl.conf for values that differ. > * If the module is not loaded yet, a user must have root privileges to run > a program using SCTP sockets. ___ 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: Specifying link-local address in rc.conf
06.07.2020 18:05, Niclas Zeising wrote: > Hi! > Is it possible to specify a link-local address in rc.conf, and get only that > link-local address? > > When I add a specific link-local address, such as fe80::1/64, to an interface > from the command line, > and then add a global uincast address, it works as expected, I do not get an > additional link-local address. What is exact syntax what works for you manually? > When I try to do the same in rc.conf however, it does not work. > I have added the following: > ifconfig_vtnet0_inet6="inet6 fe80::1/64" > ifconfig_vtnet0_alias0="2001:6b8::1/64" You missed "inet6 " address family prefix for the last line. Does adding it help? ___ 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: routed && route6d removal proposal
24.06.2020 15:20, Alexander V. Chernikov wrote: > Different people have different opinions :-) > Let me rephrase the point I'm trying to make: RIP original design was created > a long time ago. The current landscape is different: there are multiple > protocols that are superset of RIP. There are multiple implementations of > these protocols that are easily available. The configuration is not non-zero, > but simple. > Even further, more and more want their protocol daemon to have an api - and > that makes implementations like goBGP extremely popular, moving people from > "traditional" routing suites/daemons. > With all that in mind, I see RIP popularity and usage going in only one > direction. Btw, I do use RIPv2 in production these days (but with ripd, not routed) and I have several reasons to do so. First, RIPv2 is distance-vector protocol and has some advantages over OSPF for small-diameter but geographically distributed network (dictinct cities inter-connected with tunnels) as it does not require existence of "inseparable" backbone. RIPv2 offers richer ways to route filtering and/or preferring that you can achieve with OSPF only if you create distinct area for each router :-) Next, with years I came to decision running both OSPF and RIPv2 in parallel without route redistribution. This doubles my work initially at configuration stage but provides me with some protection against software failures. I can easily stop, debug and restart one of routing daemons while another one still runs so network has connectivity. ___ 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: routed && route6d removal proposal
23.06.2020 12:33, Rodney W. Grimes wrote: > Can you agree with that logic Eugene? I'm not against keeping routed(8) in the base while it has happy users raising voice for it. ___ 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: routed && route6d removal proposal
23.06.2020 2:26, Rodney W. Grimes wrote: >> 22.06.2020 19:49, Rodney W. Grimes wrote: >>> Whats unmaintained about code that has no need to change cause it just >>> pretty much works? >> Have you actually tried running routed(8) as base for real network with >> loops, >> mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lists >> and >> with diameter about 6 hops? > > As I said I know of people that are running and it is working, and > Hiroko's post clearly establishes that as fact in evidence. > > I am not even sure that RIP* has loop detection in the protocol, It has, of course. > as the prefered routing protocol for anything multipath (which > is what loops are in effect) is OSPF. RIPv2 may be used for failover, not for multipath. Any redundant route creates L3 "multipath". >> I'm not talking about RIPv2 inherent deficiencies. >> Our routed just glitches where quagga's ripd just works. > > And your PR# for reporting the bug is? Was. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=51927 Never had a chance to verify if it was really fixed in HEAD because it was not for RELENG_4, so I moved to ripd. As you may remeber, RELENG_5 needed much time to become ready for production. ___ 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: routed && route6d removal proposal
22.06.2020 19:49, Rodney W. Grimes wrote: > Whats unmaintained about code that has no need to change cause it just pretty > much works? Have you actually tried running routed(8) as base for real network with loops, mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lists and with diameter about 6 hops? I'm not talking about RIPv2 inherent deficiencies. Our routed just glitches where quagga's ripd just works. ___ 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: routed && route6d removal proposal
22.06.2020 6:05, Alexander V. Chernikov wrote: > To summarise: RIP protocol is obsolete, implementations for newer protocols > exists in ports, implementation in base is unmaintained. Too many reasons but one real one: it's broken since FreeBSD 4 at least when I tried to use it in production and was forced to move to quagga that was actively maintained that time. Go with removal. ___ 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: Regarding IP fragmentation
16.06.2020 17:37, hiral s shah wrote: > I am currently pursuing MTECH and doing research on IP fragmentation. > I came across a vulnerability that I am facing in my project. > > Can you please provide me some insight on "How freeBSD is handling ip > fragmentation" ? https://www.freebsd.org/security/advisories/FreeBSD-SA-18:10.ip.asc https://svnweb.freebsd.org/base/head/sys/netinet/ip_reass.c?view=markup#l171 ___ 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: unbound and (isc) dhcpd startup order
15.06.2020 13:10, Andriy Gapon wrote: > I am configuring a small LAN -- mostly a gateway / router for it -- and I am > using unbound for a local DNS and isc-dhcp44-server for DHCP. > I have a few hosts with static IP addresses (for various reasons). > So, in unbound.conf I have an entry like > local-data: "hipster.home.arpa. IN A 192.168.0.222" Consider using /etc/hosts in addition to DNS to solve chicken/egg problem. ___ 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: On Netgraph
10.06.2020 6:48, John-Mark Gurney wrote: > Tom Marcoen wrote this message on Tue, Jun 09, 2020 at 12:53 +0200: >> That is what I had in mind. Though I was hoping I could put the encryption >> in NetGraph too so that I would not see that interface on my host where I >> do not need to see it. > > You wouldn't see any interface if you're encrypting and authenticating > a UDP tunnel with IPsec... the Security Association (SA) is transparent > and does not appear on the interface list of your host.. This is only partially true these days: https://www.freebsd.org/cgi/man.cgi?query=if_ipsec ___ 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: On Netgraph
06.06.2020 2:13, Tom Marcoen wrote: > Hey Eugen, > > For some reason I did not receive your email. But I found your reply in the > archives. Just look at your gmail spam folder. Gmail's antispam policy in not quite adequate. > Anyway, the goal is to have two computers, each with a Netgraph bridge node > and jails connecting to these bridges. I want to connect both bridges over > the Internet securely. Using a UDP tunnel and encrypting that with IPsec or > wireguard or would be an option, but it would be nicer if I could use > a Netgraph-native option. Just create ordinary gif(4) or gre(4) tunnel between your two hosts and encrypt it with IPSec, that will me more secure and much easier same time. Or, if you don't like gif/gre, you maybe would like to use if_ipsec(4) native encapsulation for IPSec. These *are* native options for FreeBSD. No reason to use more complex NETGRAPH schemes. ___ 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: On Netgraph
27.05.2020 15:06, Tom Marcoen wrote: > Hey all, > > I'm new to this mailing list and also quite new to FreeBSD (huray, welcome > to me!) so bare with me, please. > > I'm reading up on Netgraph on how I can integrate it with FreeBSD jails and > I was looking at some of the examples provided in > /usr/share/examples/netgraph and now have the following question. > The udp.tunnel example shows an iface point-to-point connection but it is > unencrypted. Of course I could encrypt it with an IPsec tunnel on the host > or tunnel it through SSH, but I was wondering whether there exists a nice > Netgraph solution, e.g. a node with two hooks, receiving unencrypted > traffic on the inside hook and sending out encrypted traffic on the outside > hook. There is ng_mppc(4) netgraph node capable to perform relatively weak MPPE encryption (and/or compression) but it is designed to work with ng_ppp(4) node encapsulating IP packets into PPP frames. I doubt it's very efficient for inter-jail traffic. Why do you need encryption for inter-jails traffic in first place? Encryption is needed for traffic passing untrusted channels where data interception is possible but inter-jail traffic does not leave the kernel at all until it hits destination jail. ___ 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: BSNMPD crashing
29.03.2020 1:53, Andrea Brancatelli via freebsd-stable wrote: > If anyone is interested please feel free to contact me otherwise I'll > just delete it :-) What is most recent version of FreeBSD that has this problem with bsnmpd crashing? Please rebuild bsnmpd with debugging enabled, if you have sources installed: cd /usr/src/usr.sbin/bsnmpd make clean make cleandir make obj depend make WITH_DEBUG=yes install /usr/obj/usr/local/src/usr.sbin/bsnmpd/bsnmpd/bsnmpd /usr/sbin Restart bsnmpd and wait for next crash. Then you could obtain meaningfull backtrace. ___ 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: IPFW In-Kernel NAT vs PF NAT Performance
19.03.2020 18:19, Lev Serebryakov wrote: >> Don't you think that now as ipfw nat builds libalias in kernel context, >> it could scale with maxusers (sys/systm.h) ? >> >> Something like (4001 + (maxusers-32)*8) so it grows with amount of physical >> memory >> and is kept small for low-memory systems. > IMHO, "maxusers" us useless now. It must be sysctl, as size of dynamic > state table of IPFW itself. I have low-memory system where WHOLE memory > is dedicated to firewall/nat, for example. I need really huge tables > (131101) to make it work "bad" and not "terrible". Sure, dedicated sysctl. I mean, its default value should be auto-tuned based on maxusers that grows with installed RAM by default. ___ 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: IPFW In-Kernel NAT vs PF NAT Performance
19.03.2020 13:42, Eugene Grosbein wrote: > It's really 4001 that is (and sould be) prime number. If we decide to auto-tune this, here is small table of prime numbers to stick with: 4001 8011 12011 16001 24001 32003 48017 64007 ___ 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: IPFW In-Kernel NAT vs PF NAT Performance
18.03.2020 21:25, Lev Serebryakov wrote: > On 18.03.2020 9:17, Kristof Provost wrote: > >>> Which firewall gives better performance, IPFW's In-Kernel NAT or PF NAT? I >>> am dealing with 1000s of concurrent connections but >>> browsing-level-bandwidth at once with Tor. >>> >> I’d expect both ipfw and pf to happily saturate gigabit links with NAT, even >> on quite modest hardware. >> Are you sure the NAT code is the bottleneck? > ipfw nat is very slow, really. There are many reasons, and one of them > (easy fixable, but you need patch sources and rebuild kernel/module) is > that `libalias` uses only 4096 buckets in state hashtable by default. So > it could saturate 1GBps link if you have 10 TCP connections, but it > could not saturate 100Mbit if your have, say, 100K UDP streams. It's really 4001 that is (and sould be) prime number. Don't you think that now as ipfw nat builds libalias in kernel context, it could scale with maxusers (sys/systm.h) ? Something like (4001 + (maxusers-32)*8) so it grows with amount of physical memory and is kept small for low-memory systems. ___ 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: IPSec transport mode, mtu, fragmentation...
19.01.2020 14:12, Victor Sudakov wrote:
> So this is most probably the artifact of if_enc. What is then the
> correct way to capture data with it?
This is documented behaviour of enc(4), see its manual page for description
of sysctl net.enc.{in|out}.ipsec_bpf_mask
___
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: IPSec transport mode, mtu, fragmentation...
18.01.2020 17:55, Victor Sudakov wrote: > Back to the point. I've figured out that both encrypted (in transport > mode) and unencrypted TCP segments have the same MSS=1460. Then I'm > completely at a loss how the encrypted packets avoid being fragmented. > TCP has no way to know in advance that encryption overhead will be > added. > > Here: http://admin.sibptus.ru/~vas/ftp-pcap.tar.gz you can find two > identical FTP sessions, the only difference being ipsec=off during one > session and ipsec=on during the other one. > > As I said, in both the sessions MSS=1460 which is already odd, and I > can't explain to myself why file transfer still works without MSS > ajustment. > > Moreover, something fishy is happening in the encrypted session: there > are many TCP retransmissions (I was capturing on the FTP server's side, > so there are many segments with the same sequence number). How would you > explain this? There are almost no retransmissions in the unencrypted session. > > All this is happening in a lab environment (one bhyve VM is an FTP > server and the other downloads a file from the first), both VMs are on > the same bridge interface. There are almost 19,000 packets in the > encrypted file vs 12,000 in the plain file, I think because of those > excessive retransmissions. > > Could the retransmissions be some artifact of the enc(4) interface I was > capturing the encrypted session on? I doubt it. And I can't explain this, but maybe it's work of PMTUD Blackhole detection? Look at sysctl net.inet.tcp | fgrep blackhole_ ___ 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: IPSec transport mode, mtu, fragmentation...
17.01.2020 22:09, Victor Sudakov wrote: >>> Back to the point. I've figured out that both encrypted (in transport >>> mode) and unencrypted TCP segments have the same MSS=1460. Then I'm >>> completely at a loss how the encrypted packets avoid being fragmented. >>> TCP has no way to know in advance that encryption overhead will be >>> added. >> >> If outgoing route (f.e. default route) has lower MTU, kernel should respond >> with EMSGSIZE >> to TCP's attempt to send oversized packet when PMTUD is enabled. >> >> If PMTUD discovers that path mtu is low, it should store this information in >> the hostcache >> (see sysctl net.inet.tcp.hostcache.list) and use hostcache's MTU for same >> goal. > > Should this result in a smaller MSS in TCP to such hosts? > > PS "sysctl net.inet.tcp.hostcache.list | grep 192.168.246.11" yields > nothing, and yet 192.168.246.11 is the VM with which I have a transport > mode SA. I guess that Path MTU in such case is 1500, so PMTUD won't help here. ___ 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: IPSec transport mode, mtu, fragmentation...
17.01.2020 16:36, Victor Sudakov пишет: > Back to the point. I've figured out that both encrypted (in transport > mode) and unencrypted TCP segments have the same MSS=1460. Then I'm > completely at a loss how the encrypted packets avoid being fragmented. > TCP has no way to know in advance that encryption overhead will be > added. If outgoing route (f.e. default route) has lower MTU, kernel should respond with EMSGSIZE to TCP's attempt to send oversized packet when PMTUD is enabled. If PMTUD discovers that path mtu is low, it should store this information in the hostcache (see sysctl net.inet.tcp.hostcache.list) and use hostcache's MTU for same goal. ___ 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: IPSec transport mode, mtu, fragmentation...
16.01.2020 23:07, Victor Sudakov wrote: >>> What beats me is that I cannot reproduce this problem in bhyve. In this >>> packet dump: http://admin.sibptus.ru/~vas/ipsec1.pcap.gz I'm scp-ing a >>> 50M file from 192.168.246.10 (bhyve guest) to 192.168.246.1 (bhyve >>> host), and I see no fragments, and the largets packet is 1466 bytes, and >>> the scp never stalls nor fails. >>> >>> Why is it NOT broken this time? >>> >>> Both hosts are 12.1-RELEASE-p1. >> >> I could not reproduce the problem with unpatched recent stable/11, either :-) > > Is there a way to view the MSS in the TCP segments before encryption or > after decryption? I want to compare them in situations with IPSec > enabled and disabled. > > I've never been able to see anything in "tcpdump -i enc0", probably it > cannot do transport mode IPSec because the man page talks about "outer > and inner header." enc0 does what you need but before you use it, remember: 1) before starting, you better change sysctls to: net.enc.in.ipsec_filter_mask=0 net.enc.out.ipsec_filter_mask=0 so using enc0 does not pass packets over netpfilter rules extra time; 2) don't forget: ifconfig enc0 up 3) tcpdump has no means to filter by inner attributes in case of tunnel mode; it still shows decoded IPSec transport mode packets correctly. ___ 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: IPSec transport mode, mtu, fragmentation...
16.01.2020 22:53, Victor Sudakov wrote: > What beats me is that I cannot reproduce this problem in bhyve. In this > packet dump: http://admin.sibptus.ru/~vas/ipsec1.pcap.gz I'm scp-ing a > 50M file from 192.168.246.10 (bhyve guest) to 192.168.246.1 (bhyve > host), and I see no fragments, and the largets packet is 1466 bytes, and > the scp never stalls nor fails. > > Why is it NOT broken this time? > > Both hosts are 12.1-RELEASE-p1. I could not reproduce the problem with unpatched recent stable/11, either :-) ___ 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: IPSec transport mode, mtu, fragmentation...
16.01.2020 20:39, Andrey V. Elsukov wrote: > I prepared the PoC patch that should fix the problem with TCP and > transport mode IPsec. But I have not free time currently to properly > test and debug it. It is only compile-tested. But If you want, you can > try :) > Currently only IPv4 support is implemented. > > https://people.freebsd.org/~ae/ipsec_transport_mode_ctlinput.diff In fact, I've faced this problem long time ago too and I work around it with different approaches like "ipfw tcp-setmss" (MSS adjust) or by using IPSec transport mode with gif(4) interface removing DF bit out of encapsulated packets. I was going to test your patch with my home router but the patch does not apply to stable/11, at all. Do you have time to adjust it to stable/11 ? ___ 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: [Bug 240825] Possible race between vlan interfaces and lagg(4) w/ em0/em1 post-EPOCH
On 09.01.2020 18:58, bugzilla-nore...@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240825 > > --- Comment #10 from commit-h...@freebsd.org --- > A commit references this bug: > > Author: eugen > Date: Thu Jan 9 11:58:26 UTC 2020 > New revision: 356551 > URL: https://svnweb.freebsd.org/changeset/base/356551 > > Log: > arp(8): avoid segfaulting due to out-of-bounds memory access > > Fix obvious mistake that sometimes results in reading memory > past end of an array. > > PR: 240825 Sorry, this should've been PR: 242784 ___ 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: lagg interface
06.01.2020 22:46, Eugene Grosbein wrote: > So, you need L3 traffic sharing. One example is using ipfw tables. > For N external links (phones) you'd need (N-1) tables, one table for a link > excluding first one. > With two links, you need only one table listing clients using second link: > > lan="10.0.0.0/8,192.168.0.0/16" > ipfw disable one_pass > ipfw table 1 add 10.0.10.200 # a client using second link > ipfw table 1 add 192.168.0.5 # another client for second link > > # translate incoming traffic > ipfw delete 50 > ipfw add 50 nat 123 ip from any to any in recv ipheth0 > ipfw add 50 nat 123 ip from any to any in recv ipheth1 Correction: latest rule should use "nat 124" instead of "nat 123" assuming there are two NAT instances configured each for its own link: nat 123 for ipheth0, nat 124 for ipheth1. > # insert your filtering rules between 50 and 5 > > # translate and forward outgoing traffic > # clients of second link processed later with rules 50110 etc. > ipfw add 5 skipto 50110 ip from not 'table(1)' to not $lan out > > # other clients not mentioned in the table are NAT-ed and forwarded here > ipfw add 50010 nat 123 ip from $lan to not $lan out > ipfw add 50020 fwd $gw1 ip from $nat123_extip to any out > > # clients using second link are NAT-ed and forwarded here > ipfw add 50110 nat 124 ip from $lan to not $lan out > ipfw add 50120 fwd $gw2 ip from $nat124_extip to any out ___ 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: lagg interface
06.01.2020 17:56, Daniel Morandini via freebsd-net wrote: > Dear FreeBSD community, > I am building a prototype router which provides a network access point to its > client through a wireless interface > (rtwn0: Realtek 802.11n WLAN Adapter, class 0/0, rev 2.00/2.00, addr 4). > Currently the packets received from the wlan0 interface are NATed through my > phone attached via usb cable, > tethering mode enabled (ipheth1: 2.00/8.01, addr 6>). > > What I would to do is to improve the network throughput by exploiting two > phones instead of one. > For that I was testing the lagg(4) interface, but I have troubles debugging > why the link does not get up > (I never managed to have at least a laggport ). > >>From what I got from the docs, I cannot expect to be able to use “ acp” as >>distribution algo, > as it requires the other side of the links (the phones in this case), to > implement the proto too, Correct. > and it is not the case. I would expect to see “failover”, “loadbalance” and > “roundrobin” to work though. Lagg cannot be used in your case at all, because lagg deals with traffic at layer2 but your setup involves NAT (layer3) that prevents usage of lagg. Also, you better distribute traffic so that all traffic of same client (internal IP) is translated to same external IP address or else clients could have difficulties with some internet services (sites). At very least, traffic from single client to distinct service must be translated to same external IP address. So, you need L3 traffic sharing. One example is using ipfw tables. For N external links (phones) you'd need (N-1) tables, one table for a link excluding first one. With two links, you need only one table listing clients using second link: lan="10.0.0.0/8,192.168.0.0/16" ipfw disable one_pass ipfw table 1 add 10.0.10.200 # a client using second link ipfw table 1 add 192.168.0.5 # another client for second link # translate incoming traffic ipfw delete 50 ipfw add 50 nat 123 ip from any to any in recv ipheth0 ipfw add 50 nat 123 ip from any to any in recv ipheth1 # insert your filtering rules between 50 and 5 # translate and forward outgoing traffic # clients of second link processed later with rules 50110 etc. ipfw add 5 skipto 50110 ip from not 'table(1)' to not $lan out # other clients not mentioned in the table are NAT-ed and forwarded here ipfw add 50010 nat 123 ip from $lan to not $lan out ipfw add 50020 fwd $gw1 ip from $nat123_extip to any out # clients using second link are NAT-ed and forwarded here ipfw add 50110 nat 124 ip from $lan to not $lan out ipfw add 50120 fwd $gw2 ip from $nat124_extip to any out ___ 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: IPSec transport mode, mtu, fragmentation...
23.12.2019 19:00, Andrey V. Elsukov wrote: > I think the silence from ping is due to IPsec works asynchronously. > I.e. when application sends data to the stack, it receives good feedback > and thinks that data was send successful then it waits for reply. > But IPsec consumes the data and then encrypted data will be send from > crypto thread via callback. And now they can not be fragmented due to > IP_DF bit, but there are no app waiting for this error code. > > Similar problem is with TCP. Probably we can try to send PRC_MSGSIZE > notify when EMSGSIZE is returned from ip_output(). At least for TCP. What is "an application" in this case? Userland app dealing with sockets? Another part of the kernel? Some system daemon similar to natd? ___ 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: IPSec transport mode, mtu, fragmentation...
23.12.2019 18:00, Andrey V. Elsukov wrote: > On 23.12.2019 13:55, Eugene Grosbein wrote: >>> I think the real problem is that PMTUD doesn't work correctly with >>> IPsec. Linux has special sysctl variabl ip_no_pmtu_disc and flag >>> SADB_SAFLAGS_NOPMTUDISC for SA that can disable PMTUD for IPv4 and IP_DF >>> flag will not be set. We can add some similar quirks, but it would be >>> better to fix PMTUD. We already have hundreds sysctl in our system and >>> remembering all them is a problem too. >> >> It's true that PMTUD does not work with IPSec transport mode. >> >> I think we could just clear DF bit off encapsulated transport mode packets >> unconditionally, >> please take a look at last chunk of sample patch in the PR 242744: >> https://bz-attachments.freebsd.org/attachment.cgi?id=210122 >> >> Sample patch creates another sysctl but we should do it unconditionally, >> don't we? > > As I said I didn't find that other OSes do this. Linux has enabled by > PMTUD by default, strongswan doesn't set SADB_SAFLAGS_NOPMTUDISC flag, > OpenBSD hasn't such quirk. Why should we add this instead of try to fix > PMTUD? RFC 2401 Appendix B https://tools.ietf.org/html/rfc2401#page-1-48 states that packets generated by IPSec transport mode must be "fragmentable" over the path and this is incompatible with DF=1. ___ 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: IPSec transport mode, mtu, fragmentation...
23.12.2019 17:45, Andrey V. Elsukov wrote: > On 23.12.2019 13:06, Victor Sudakov wrote: >>> ESP xform for transport mode just replaces protocol in IP header and >>> adds some info to the end of a packet. >> >> It is rather easy to verify your theory. If you are right, then >> disabling net.inet.tcp.path_mtu_discovery globally should remove the DF >> flags from the ESP packets too, right? >> >> Of course, net.inet.tcp.path_mtu_discovery=0 is not a solution, it's just >> a way to check the origin of the DF flag. >> >> And if you are right, what does it mean to us? Did you see >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 already ? >> >> My ultimate wish is to make transport mode work out of the box, without >> any workarounds like additional host routes or firewall rules. > > I think the real problem is that PMTUD doesn't work correctly with > IPsec. Linux has special sysctl variabl ip_no_pmtu_disc and flag > SADB_SAFLAGS_NOPMTUDISC for SA that can disable PMTUD for IPv4 and IP_DF > flag will not be set. We can add some similar quirks, but it would be > better to fix PMTUD. We already have hundreds sysctl in our system and > remembering all them is a problem too. It's true that PMTUD does not work with IPSec transport mode. I think we could just clear DF bit off encapsulated transport mode packets unconditionally, please take a look at last chunk of sample patch in the PR 242744: https://bz-attachments.freebsd.org/attachment.cgi?id=210122 Sample patch creates another sysctl but we should do it unconditionally, don't we? ___ 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: IPSec transport mode, mtu, fragmentation...
23.12.2019 16:44, Andrey V. Elsukov wrote: > On 23.12.2019 12:39, Andrey V. Elsukov wrote: >> On 20.12.2019 19:22, Victor Sudakov wrote: What's the root of the problem? ESP packets cannot get fragmented or what? >>> >>> Wireshark has shown that the "Don't Fragment" flag is set on all ESP >>> (protocol 50) packets. Who does this, why, and how can I switch it off >>> globally? >> >> Hi, >> >> I think this DF flag is originally from TCP packet. >> ESP xform for transport mode just replaces protocol in IP header and >> adds some info to the end of a packet. > > This is controlled by net.inet.tcp.path_mtu_discovery variable. > TCP won't set IP_DF flag if you disable this feature. Disabling PMTUD globally results in small outgoing TCP packets for all connections, encrypted or not. Performance may degrade. ___ 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: NAT64 return traffic vanishes after successful de-alias
15.12.2019 2:54, John W. O'Brien пишет: > Hello FreeBSD Networking, > > As the subject summarizes, I have a mostly-working NAT64 rig, but return > traffic is disappearing, and I haven't been able to figure out why. I > observe the post-translation (4-to-6) packets via ipfwlog0, but a simple > ipfw counter rule ipfw matches nothing. Have you read NETWORK ADDRESS TRANSLATION (NAT) section of ipfw(8) manual page carefully? It tells: > To let the packet continue after being (de)aliased, set the sysctl > variable net.inet.ip.fw.one_pass to 0. Did you set sysctl net.inet.ip.fw.one_pass=0 ? ___ 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: Several hosts behind a caching resolver
24.11.2019 23:02, Victor Sudakov wrote: > If there are multiple recursive queries for MS domains only, do you think > the operator of Resolver B can tell if there are 10 or 100 MS clients > behind Resolver A? I guess so, because different Windows versions may behave differently (including erratic behaviour) and volume of DNS traffic may give some hints, too. This seems as XY-problem for me :-) What is your X problem? ___ 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: Several hosts behind a caching resolver
24.11.2019 19:34, Victor Sudakov wrote: > Dear Colleagues, > > Several hosts of the local network use a FreeBSD server with BIND or > local-unbound as a caching resolver. Let's call it "Resolver A." > Resolver A forwards all queries to another resolver, e.g. 8.8.8.8 or > some other, let's call it "Resolver B." > > Can the operator of Resolver B figure out how many clients there are > behind Resolver A, or obtain any other information about the hosts on > the said local network (like their operating system etc)? In other > words, does Resolver A effectively anonymize the queries, or is some > information about the internal network leaking? No anonymization via unencrypted DNS. The query itself reveals most data about clients. Windows OSes send queries for MS-specific domains periodically, Android for its domains, FreeBSD for pkg.freebsd.org or svn.freebsd.org etc. If a there are multiple recursive queries for both of MS/Androis/MacOS-specific domains, this means there are many clients behind this local resolver. ___ 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: net.inet.tcp.pmtud_blackhole_detection
14.11.2019 4:28, Andrea Venturoli wrote: > Running 11.3, is there any risk or downside in enabling this? > > I cannot reach my homebanking otherwise; I think either the bank has > completely disabled ICMP or some router in between filters it. > > I see it's not enabled by default: is it just out of precaution? I guess it's a misfeature. It should be enabled by default. Feel free to enable it locally. Note I have not said it should be enabled unconditionally as there may be edge cases (high-load servers) when extra processing may be undesirable. ___ 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 as multicast router
08.11.2019 19:10, Victor Gamov wrote: >> I'm not familiar with multicast routing in FreeBSD. >> Multicast routing has its rules in general, though. >> >> For example, Cisco routers never process incoming multicast UDP flows if >> unicast route >> to source IP address of UDP packets points to interface that differs from >> real incoming interface. >> This is "reverse path filtering" embedded in multicast routing >> unconditionally. > > Yes, but FreeBSD can ping source and client in my tests (see my new later at > this thread with network scheme) It does not matter if source is reachable with unicasts (ping). "Reverse" unicast routes should match incoming interface for multicast UDP. ___ 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 as multicast router
07.11.2019 21:17, Victor Gamov wrote: > I still have misunderstood here. Pimd installs multicast routes and this > routes displayed by `netstat -g`. > So, the system knows interface where multicast received. > When Join received via interface 2 (vlan299) who must resend multicast from > input interface 3 (vlan750) > to output interface 2 (vlan299)? I guess it kernel-specific task and kernel > must resend multicast > without any other helpers. Is it wrong? I'm not familiar with multicast routing in FreeBSD. Multicast routing has its rules in general, though. For example, Cisco routers never process incoming multicast UDP flows if unicast route to source IP address of UDP packets points to interface that differs from real incoming interface. This is "reverse path filtering" embedded in multicast routing unconditionally. ___ 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: 10g IPsec ?
07.11.2019 14:32, John-Mark Gurney wrote: > Don't we have the option of doing soft re-classification? Where we > recalculate the hash, and then do a netisr defer? I mean that'd burn > a bunch of extra cpu cycles, but you gotta do what you gotta do. If the host got a packet already, it can just process it without extra re-classification. The only case I know when such re-classification can be useful is assigning M_FLOWID to the mbuf so that lagg(4) using LACP could send it further using such M_FLOWID and maybe distribute distinct IPsec flows over distinct ports of LAGG group. I doubt this has much practical use :-) Generally we terminate IPsec locally or route packets to other hosts without need to differ them from other transit traffic. ___ 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: 10g IPsec ?
07.11.2019 8:36, Lawrence Stewart wrote: >>> AES-GCM can run at over 1GB/sec on a single core, so as long as the >>> traffic can be processed by multiple threads (via multiple queues >>> for example), it should be doable. >>> >>> >> I didn't bench this setup (10Gb/s IPSec) but I believe we will have the >> same problem with IPSec as with all VPN setups (like PPPoE or GRE): the >> IPSec tunnel will generate one IP flow preventing load sharing between all >> the NIC's RSS queues. >> I'm not aware of improvement to remove this limitation. > > I never understood why the IPsec SPI couldn't be used to shard > traffic... does anyone know if there is a technical reason why doing so > would be problematic? Generic way do distribute load over CPUs is distinct hardware receive queues of NIC using distinct interrupts to deliver packets to the host while interrupts are bound to distinct CPU cores. It needs hardware capable of splitting packet stream by IPsec SPI and I'm aware of only some 40Gpbs Intel NICs that can be programmed to do so. ___ 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: 10g IPsec ?
06.11.2019 18:29, Muenz, Michael wrote: > Am 06.11.2019 um 01:21 schrieb Eugene Grosbein: >> 06.11.2019 4:55, Muenz, Michael wrote: >> >>> These were my short results via OPNsense on 4 year old XEONs. >>> So its 11.2, mostly untuned and strongswan as IPsec implementation. >>> If you need more detailed specs just drop me a line. >>> >>> https://www.routerperformance.net/comparing-opnsense-vpn-performance/ >> Was it strongswan in user-level IPsec processing mode or kernel-level? >> > > Not really sure if I understand you right, encryption and ESP should run in > kernel space, only IKE packets for SA handling run in user space. AFAIK strongswan may process all traffic in user-land via tun(4) interface for some setups. It differs from racoon that never processes payload by itself. ___ 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: 10g IPsec ?
06.11.2019 5:45, Olivier Cochard-Labbé wrote: > On Tue, Nov 5, 2019 at 8:15 PM John-Mark Gurney wrote: > >> AES-GCM can run at over 1GB/sec on a single core, so as long as the >> traffic can be processed by multiple threads (via multiple queues >> for example), it should be doable. >> >> > I didn't bench this setup (10Gb/s IPSec) but I believe we will have the > same problem with IPSec as with all VPN setups (like PPPoE or GRE): the > IPSec tunnel will generate one IP flow preventing load sharing between all > the NIC's RSS queues. > I'm not aware of improvement to remove this limitation. Some speedup may be achieved switching from direct NETISR mode to deferred mode, so interrupt processing merely places traffic to the ISR queue. Several (net.isr.numthreads) other kernel threads will process incoming traffic later including bpf, IPSEC, filtering, routing lookups, NETGRAPH etc. ___ 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: 10g IPsec ?
06.11.2019 4:55, Muenz, Michael wrote: > These were my short results via OPNsense on 4 year old XEONs. > So its 11.2, mostly untuned and strongswan as IPsec implementation. > If you need more detailed specs just drop me a line. > > https://www.routerperformance.net/comparing-opnsense-vpn-performance/ Was it strongswan in user-level IPsec processing mode or kernel-level? ___ 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: ipsec on multicore VM
09.10.2019 2:05, Victor Gamov wrote: > I have FreeBSD 11.2-STABLE #0 r343863 VM with 2 CPU and vxnet3 NIC. This host > uses many if_ipsec and strongswan-5.7.2 to make site-to-site ipsec > connections. > > When I use `tcpdump -nn -i src and esp` then I got > many reordered IPsec packets. > > Does tcpdump give me a real picture and I have reordering somewhere "on the > wire" or packets may be reordered due more then one CPU read packets from NIC > ? You may easily verify your suspiction disabling SMP inside the guest system temporary: nextboot -k kernel echo kern.smp.disabled=1 >> /boot/nextboot.conf shutdown -r now This way, the system will perform one-time boot with all cores but one disabled. Should it experience any problems booting this way, another reset of the VM will boot it normally, otherwise try running tcpdump while single CPU is used by kernel. ___ 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: dummynet: bandwidth is limited to 2 Gbit/s ?
On 25.09.2019 20:53, Andrey V. Elsukov wrote: > On 25.09.2019 16:51, Eugene Grosbein wrote: >>> Will this break upgrades with freebsd-update? On a major upgrade, >>> it will first install the new kernel and require a reboot before >>> you run freebsd-update again to install the rest. >> >> So it will run without dummynet pipes (traffic shaping) configured >> meantime. Is it big deal? > > Note, that if you have ipfw rule with pipe, that does not exist, all > matched traffic will be dropped. :-) Nice catch. Maybe we should introduce new sysctl kern.features.dummynet64 knob for new kernels only but teach /sbin/ipfw for all supported branches to check it. So /sbin/ipfw would refuse to process any dummynet-related rules if knob is present and the binary has no 64-bit dummynet support. ___ 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: dummynet: bandwidth is limited to 2 Gbit/s ?
On 25.09.2019 17:27, John Hay wrote: > > > On Wed, 25 Sep 2019 at 11:16, Eugene Grosbein <mailto:eu...@grosbein.net>> wrote: > > On 25.09.2019 05:19, Rodney W. Grimes wrote: > > >> AFAIK, we never had any public ABI or stable KBI interface announced > to userland or in-kernel consumers > >> and had no consumers of dummynet other than ipfw(8) binary. Just > increase type. > > > > Any attempt to mfc this would break KABI/userland and that is never > > a good thing to do. It may not be a public ABI, but it is an ABI, > > and stability of that and backwards compatibility are always a good > > thing to strive for. > > Agreed. So, no MFC for this. > > > Will this break upgrades with freebsd-update? On a major upgrade, it will > first install the new kernel and require a reboot before you run > freebsd-update again to install the rest. So it will run without dummynet pipes (traffic shaping) configured meantime. Is it big deal? ___ 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: dummynet: bandwidth is limited to 2 Gbit/s ?
On 25.09.2019 05:19, Rodney W. Grimes wrote: >> AFAIK, we never had any public ABI or stable KBI interface announced to >> userland or in-kernel consumers >> and had no consumers of dummynet other than ipfw(8) binary. Just increase >> type. > > Any attempt to mfc this would break KABI/userland and that is never > a good thing to do. It may not be a public ABI, but it is an ABI, > and stability of that and backwards compatibility are always a good > thing to strive for. Agreed. So, no MFC for 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: dummynet: bandwidth is limited to 2 Gbit/s ?
On 24.09.2019 12:42, Andriy Gapon wrote: > It seems that the userland component of ipfw/dummynet uses int for the > bandwidth > represented in bit/s. Also, int is used for passing that value from the > userland to the kernel. > > What would be the best way to extend this? > Just use a larger type? > Or maybe add another field to try to preserve KBI backward compatibility? > > Thank you. AFAIK, we never had any public ABI or stable KBI interface announced to userland or in-kernel consumers and had no consumers of dummynet other than ipfw(8) binary. Just increase type. ___ 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: Difficulty using more than a 2 port NIC
31.08.2019 8:56, bsd.li...@h8spam.org wrote: > I lease 7 public addresses. > I'm running into a strange problem setting up a NIC > with more than 2 (public) addresses. > I initially did some research, and found an re(4) 2 > port NIC that was well supported (RTL8169S). > The host (box) I'm attempting all this on manages 3 > addresses. So I simply set it up as follows ( rc.conf(5) ): > > hostname="sum.host-n.ame" > # re0 > ifconfig_re0="inet AA.BB.CC.83 netmask 255.255.255.0" > # re1 > ifconfig_re1="inet AA.BB.CC.82 netmask 255.255.255.0" > ifconfig_re1_alias0="inet AA.BB.CC.86 netmask 255.255.255.0" > > defaultrouter="AA.BB.CC.1" > ifconfig_re0_ipv6="inet6 accept_rtadv" > ifconfig_re1_ipv6="inet6 accept_rtadv" > > And all worked as intended. You was a bit lucky. It is not supposed to work this way. Generally, you should not have more than single network interface attached to single IP subnet. Instead, you assign one of IPs as primary address and others as secondary addresses with mask /32. So you don't need additional physical ports to utilize any number of addresses. There are some cases when you use port aggregation for ports connected to same switch and subnet but then you still use single lagg(4) logical network interface to assign all your IPs. ___ 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: (11.3) bsnmpd and trap
30.08.2019 19:37, Patrick Lamaiziere пишет: > On Fri, 30 Aug 2019 19:18:35 +0700 > Eugene Grosbein wrote: > >>> bsnmpd sends a trap when an interface link goes up but not when the >>> link goes down. >>> >>> Is there a way to have a trap when the link is down? >> >> Are you sure you not trying to send a trap for broken link over same >> link? :-) > > Yes I'm sure :-) > The interface to the snmp trap server is ix2 and i tried with the > link of ibg0 (a link to a DMZ) Does your kernel write a notification to dmesg for this event? Have you verified that devd(8) is running meantime? ___ 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: (11.3) bsnmpd and trap
30.08.2019 19:37, Patrick Lamaiziere wrote: > On Fri, 30 Aug 2019 19:18:35 +0700 > Eugene Grosbein wrote: > >>> bsnmpd sends a trap when an interface link goes up but not when the >>> link goes down. >>> >>> Is there a way to have a trap when the link is down? >> >> Are you sure you not trying to send a trap for broken link over same >> link? :-) > > Yes I'm sure :-) > The interface to the snmp trap server is ix2 and i tried with the > link of ibg0 (a link to a DMZ) Does your kernel write a notification to dmesg for this event? Have you verified that devd(8) is running meantime? ___ 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: (11.3) bsnmpd and trap
30.08.2019 18:48, Patrick Lamaiziere wrote: > bsnmpd sends a trap when an interface link goes up but not when the > link goes down. > > Is there a way to have a trap when the link is down? Are you sure you not trying to send a trap for broken link over same link? :-) ___ 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: finding optimal ipfw strategy
30.08.2019 1:39, Rodney W. Grimes wrote:
> One of the things I do when writting a firewall is very early break
> up the traffic based on which interface(s) it is coming in/out of
> and do a skipto based on that, then further classify based on layers
> so that I am usually only doing 1 compare as it traverse down what
> is in effect a trie.
>
> dispatch on interface(s)
> dispatch on protocol (IP, ESP, OSPF, IGMP, ICMP, etc)
> IP: dispatch on transport (TCP, UDP, SCTP...)
> IPTCP: dispatch on setup, established..
> IPTCPsetup: dispatch on ports
> IPUDP: ...
>
> I try to write my sets so that I never do the same comparison on
> a packet at any point in the firewall. Ie, once your in the IPTCP
> set of rules I no longer check for tcp, only check port numbers
> and flags (setup, established, etc)
>
> Does this seem like a reasonable and efficient approach?
Correct but that's important for high-load scenario only and
when firewall processing constitutes most or significant part of work performed
by the box.
If userland work's much heavier, this could be unimportant complication :-)
>>> I hope I can place such rule at top of ruleset and only allowed multicast
>>> packets outgoing via VLANs interfaces will hit this rule.
>>> and second:
>>> allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 }
>>> or
>>> allow udp from src1 to 239.1.2.0/24{55,56}
>> Last one should me much more efficient as it just needs to perform a couple
>> of 32-bit masking operations
>> and previous one is more general (IP addresses may belong to different
>> networks) and requires slower search.
> I disagree, the first one should be 2 simple 32 bit compares,
> the second one is a 32 bit AND (mask), and then 2 8 bit compares,
> and actually probably actually 32 bit compares due to data type promotion.
That's an example only and I've answered considering scaled picture where there
are many more IPs to check for.
___
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: finding optimal ipfw strategy
28.08.2019 23:58, Victor Gamov wrote:
> P.S. Two questions about rules syntax optimization. What is more effective:
> skipto tablearg udp from any to table(AllMcast_out)
> or
> skipto tablearg udp from any to table(AllMcast_out) out xmit vlan*
Can't tell, this heavily depends on table contents and internal order of checks
in kernel part of ipfw but general rule should still apply: less checks, better
performance.
> I hope I can place such rule at top of ruleset and only allowed multicast
> packets outgoing via VLANs interfaces will hit this rule.
>
> and second:
> allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 }
> or
> allow udp from src1 to 239.1.2.0/24{55,56}
Last one should me much more efficient as it just needs to perform a couple of
32-bit masking operations
and previous one is more general (IP addresses may belong to different
networks) and requires slower search.
___
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: finding optimal ipfw strategy
28.08.2019 17:18, Victor Gamov wrote:
>> Why do you need to filter ARP on bridge? That's unusial. VLANs are
>> isolated by default and by definition, unless you explicitly enable
>> inter-vlan routing and setup your routing table.
>
> May be I have some misunderstood here but...
> If I have many VLANs bridged via bridge interface then ARP received
> from one VLAN will be send to all bridge members. So it will be send
> to all unwanted VLANs. Is it correct?
Yes. So, you really do not want any kind of unicast bridging at all
and use bridge as "poor man's" replacement for inter-vlan multicast routing,
right?
In such case you could benefit from small patch that allows you to block ARP
packets unconditionally
as if they were filtered by ipfw without really passing them through the
ruleset.
Use sysctl net.link.bridge.ipfw_arp=-1 with the patch (untested):
--- if_bridge.c.orig2019-04-19 17:20:09.724804000 +0700
+++ if_bridge.c 2019-08-28 22:35:14.788891000 +0700
@@ -3153,6 +3153,10 @@ bridge_pfil(struct mbuf **mp, struct ifn
switch (ether_type) {
case ETHERTYPE_ARP:
case ETHERTYPE_REVARP:
+ if (V_pfil_ipfw_arp == -1) {
+ error = 0;
+ goto bad; /* Automatically drop */
+ }
if (V_pfil_ipfw_arp == 0)
return (0); /* Automatically pass */
break;
>> Anyway, you can skip entire ipfw pass over a bridge because you
>> filter its members anyway, so just drop ARP coming from any vlan with
>> exception of controlling one:
>>
>> allow ip from any to any layer2 mac-type 0x0806 in recv $controlvlan deny ip
>> from any to any layer2 mac-type 0x0806 in allow ip from any
>> to any layer2
>>
>> And then disable filtering for bridge itself altogether. Decreasing
>> number of passes over ipfw should be your top priority because that's
>> what can provide you with most benefit. You should even rewrite your
>> ruleset if that is needed to achieve this goal.
>
> If I set net.link.bridge.ipfw=0 but net.link.ether.ipfw and
> net.link.bridge.ipfw still set to 1
> is it still possible block unwanted ARP received from one VLAN and bridged to
> other on outgoing VLAN like
>
> deny ip from any to any layer2 mac-type 0x0806 out xmit MAC not $mymac any
>
> Is it correct and more effective than net.link.bridge.ipfw=1 if I have "deny
> mac-type 0x0806 via bridge" at rules top?
Yes. And anything decreasing number of traffic passes over entire ipfw ruleset
is efficient.
___
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: finding optimal ipfw strategy
28.08.2019 3:20, Victor Gamov wrote: hw.igb.max_interrupt_rate=32000 >>> >>> It's about 5000-7000 per rxq >> >> 7000 is quite close considering it is average for quite long period (a >> second or seconds). >> It can hit 8000 for some ticks easily in your case. > > Eugene, can you explain me what max_interrupt_rate means? Calomel explain > it as "# maximum number of interrupts per second generated by single igb". > So if I increase it then more irq per sec will be generated and more context > switch produced. Why I need to increase it? Already did in another post. >> You should raise the limit as soon as possible. I'd advise to double it upto >> 16000 first >> but if you cannot afford extra reboot better use 32000 as it's just fine for >> 1Gbps link. > # sysctl hw.igb.max_interrupt_rate > sysctl: unknown oid 'hw.igb.max_interrupt_rate' > # > Is it possible to set it at boot time only? Yes, unless you patched igb(4) sources with a patch as described in by blog: http://www.grosbein.net/freebsd/patches/igb_sysctl-11.0.diff.gz It adds per-interface sysctls to change this on-the-fly: dev.igb.0.max_interrupt_rate=32000 dev.igb.1.max_interrupt_rate=32000 Be warned that you still need to re-initialize the NIC to write changed value to the chip and this will temporary stop traffic. Easiest way is to bring the interface down/up: ifconfig igb0 down; ifconfig igb0 up hw.igb.max_interrupt_rate is used as default value for sysctls so if you raise the limit in loader.conf, it is used by chip on first "up" of interface at boot time. ___ 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"
