| 17 Aug 2021 |
eyJhb | Also recommend looking at nftables instead of iptables. I still do suck at it, but there are some experts in here, as well as some people in #netfilter on Libera that are very nice! | 15:28:26 |
hexa | I do love ferm, but it's "stuck" with iptables | 15:52:22 |
hexa | It has the most convenient syntactic sugar | 15:52:45 |
hexa | I am using plain nft these days and it has lots of rough edges | 15:53:29 |
hexa | Not really sure if my only benefit is learning nft π
| 15:54:25 |
andi- | Testing nft is a pain. The whole story around verifying your file is syntactically correct already sucks. | 15:55:36 |
CRTified | Just for clarification: it looks like nftables is intended to replace iptables/arptables and more in the long run, correct? If that's the case, it's probably a good idea to start using it and to get used to it | 15:56:30 |
hexa | Composing it in nixos is also not straight-forward, the module is lacking | 15:56:49 |
andi- | In reply to @schnecfk:ruhr-uni-bochum.de Just for clarification: it looks like nftables is intended to replace iptables/arptables and more in the long run, correct? If that's the case, it's probably a good idea to start using it and to get used to it iptables is already using it under the hood. | 15:56:50 |
hexa | There is the iptables-nft wrapper ^ | 15:57:19 |
CRTified | In reply to @andi:kack.it iptables is already using it under the hood. THen the question is whether that compatibility layer is intended to stay, or whether it'll be deprecated some day | 16:05:53 |
andi- | I am sure it'll stay for some 10 years.. | 16:06:25 |
andi- | Or a RHEL lifecycle | 16:06:34 |
CRTified | Yes, that's likely the case, but on the other hand it's probably a good idea to start early so that the transition won't be in a hurry (or one has at least a small bit of experience with it) | 16:07:49 |
eyJhb | andi-: wasn't it you that provided the checking of nftables ? | 16:12:13 |
eyJhb | verifiedNetfilter = { text, modules ? [ ] }:
let
file = pkgs.writeText "netfilter" text;
vmTools = pkgs.vmTools.override {
rootModules =
[
"virtio_pci"
"virtio_mmio"
"virtio_blk"
"virtio_balloon"
"virtio_rng"
"ext4"
"unix"
"9p"
"9pnet_virtio"
"crc32c_generic"
] ++ modules;
};
check = vmTools.runInLinuxVM (
pkgs.runCommand "nft-check"
{
buildInputs = [ pkgs.nftables ];
inherit file;
} ''
set -ex
# make sure protocols & services are known
ln -s ${pkgs.iana-etc}/etc/protocol /etc/protocol
ln -s ${pkgs.iana-etc}/etc/services /etc/services
# test the configuration
nft --file $file
set +x
''
);
in
"#checked with ${check}\n" + text;
this beauty
| 16:12:41 |
andi- | yeah | 16:18:57 |
| das_j joined the room. | 16:25:23 |
das_j | oof is this really the only way? :/ | 16:25:57 |
| das_j changed their display name from Janne HeΓ to das_j. | 16:26:13 |
andi- | Another reason to use nft: It does support hardware offloading of rules via TC flower | 16:30:24 |
andi- | and a surprising amount of nics seem to support that at least partially | 16:30:35 |
andi- | mlx5 and some random mediatek device support flow table offloading | 16:32:14 |
Linux Hackerman | oh wow | 16:32:21 |
Linux Hackerman | On the one hand, I love that we have stuff like runInLinuxVM. On the other, I hate that it's necessary for this π
| 16:32:51 |
andi- | I think you can remove the kernel modules part above but then the closure is bigger. IIRC I copied the modules from our VM tests | 16:33:15 |
andi- | Unfortunately the code looks like it aborts if you request hw offloading instead of falling back to the software implementation | 16:43:42 |
andi- | so, I kinda want to replace my APU2 with something that has an mlx5 now. | 16:46:48 |
das_j | Ah can you tell me when you find something good? Because I have an APU2 as well and I would also prefer something with offloading | 16:48:23 |
nixinator | where can i read about flow offloading? | 16:48:37 |