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
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
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
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
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
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
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
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
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
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
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,
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
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"
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
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
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 m
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
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
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
>
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
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.
>
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`
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 t
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
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.
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
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
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
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
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
>
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
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
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
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
>
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.
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.
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
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
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@
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
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 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
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/
>
>
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.
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
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
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
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,
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
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
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
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
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
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" ?
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
>
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.
>
>
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
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
>
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
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
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-
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
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
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
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
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
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,
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
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
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:
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 li
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
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
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 t
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
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
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
>
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
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
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
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
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
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
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
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 imp
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
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.
>
>
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.
>
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
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 a
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
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
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
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
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 wh
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? :-)
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
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
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
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
1 - 100 of 756 matches
Mail list logo
