Bon après, faut pas non plus en faire une usine à gaz….

Perso, j’ai mon ONU dans un petit switch CRS310 Mikrotik, il fait la COS sur les paquets qui vont bien, et je gère le DHCP client sur mon routeur.

Le switch Mikrotik fait la COS au niveau hardware. De tout manière, il faut bien un slot pour accueillir l’ONU…

#!/bin/bash

NFT=/usr/bin/nft

rnd=$(mktemp -u XXXXXXXX)
ns1="nft1ifname-$rnd"
ns2="nft2ifname-$rnd"

cleanup()
{
ip netns del "$ns1"
ip netns del "$ns2"
}

trap cleanup EXIT

set -e

ip netns add "$ns1"
ip netns add "$ns2"
ip -net "$ns1" link set lo up
ip -net "$ns2" link set lo up

ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2

ip -net "$ns1" link set veth0 addr da:d3:00:01:02:03

ip -net "$ns1" link add vlan1 link veth0 type vlan id 123
ip -net "$ns2" link add vlan2 link veth0 type vlan id 123


for dev in veth0 ; do
ip -net "$ns1" link set $dev up
ip -net "$ns2" link set $dev up
done
ip -net "$ns1" link set vlan1 up
ip -net "$ns2" link set vlan2 up

ip -net "$ns1" addr add 10.1.1.1/24 dev vlan1
ip -net "$ns2" addr add 10.1.1.2/24 dev vlan2

ip netns exec "$ns2" $NFT -f /dev/stdin <<"EOF"
table netdev t {
chain in_update_vlan {
vlan type arp vlan pcp set 6 counter
ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter
}

chain in {
type filter hook ingress device veth0 priority filter;
ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
}

chain out_update_vlan {
vlan type arp vlan pcp set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter
}

chain out {
type filter hook egress device veth0 priority filter;
ether daddr da:d3:00:01:02:03 vlan id 123 jump out_update_vlan
}
}
EOF

ip netns exec "$ns1" ping -c 1 10.1.1.2

set +e

ip netns exec "$ns2" $NFT list ruleset
ip netns exec "$ns2" $NFT list table netdev t | grep 'counter packets' | grep 'counter packets 0 bytes 0'
if [ $? -eq 1 ]
then
exit 0
fi

exit 1


En modifiant le code, j'ai commis une erreur.

chain out_update_vlan {
vlan type arp vlan pcp set 123 counter
ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter
}


/dev/stdin:13:30-32: Error: Value 123 exceeds valid range 0-7
                vlan type arp vlan pcp set 123 counter
                                           ^^^

Cela semblerait indiquer que l'on puisse modifier le PCP.

Mais on voit bien que le résultat est négatif.

PING 10.1.1.2 (10.1.1.2) 56(84) octets de données.
64 octets de 10.1.1.2 : icmp_seq=1 ttl=64 temps=0.033 ms

--- statistiques ping 10.1.1.2 ---
1 paquets transmis, 1 reçus, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.033/0.033/0.033/0.000 ms
table netdev t {
        chain in_update_vlan {
                vlan type arp vlan pcp set 6 counter packets 0 bytes 0
                ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter packets 0 bytes 0
        }

        chain in {
                type filter hook ingress device "veth0" priority filter; policy accept;
                ether saddr da:d3:00:01:02:03 vlan id 123 jump in_update_vlan
        }

        chain out_update_vlan {
                vlan type arp vlan pcp set 6 counter packets 0 bytes 0
                ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter packets 0 bytes 0
        }

        chain out {
                type filter hook egress device "veth0" priority filter; policy accept;
                ether daddr da:d3:00:01:02:03 vlan id 123 jump out_update_vlan
        }
}
                vlan type arp vlan pcp set 6 counter packets 0 bytes 0
                ip saddr 10.1.1.1 icmp type echo-request vlan pcp set 6 counter packets 0 bytes 0
                vlan type arp vlan pcp set 6 counter packets 0 bytes 0
                ip daddr 10.1.1.1 icmp type echo-reply vlan pcp set 6 counter packets 0 bytes 0

De toute manière nftable 1.1.x ne sera pas dispo avant plusieurs mois/années. C'est même pas une solution à envisager pour le moment, en tout cas pas de cette manière.

Celle que j'utilise fonctionne parfaitement, via une injection de règles et ça colle parfaitement dans un cycle de up/down d'une interface. Il suffit simplement d'ajouter une étape, simple de surcroit, juste avant de lancer les daemons DHCP (v4/v6).

C'est aussi pour cette raison que j'ai arrêter d'utiliser des distrib de routeur (pfsense, opnsense, wrt, ...) sur des "vrai" router que je veux stable et facilement configurable.
opnsense et pfsense passent leur temps à péter les config existantes, surtout lorsque la config devient un peu exotique. Et wrt pas bcp mieux ...


Je suis sur debian depuis plus de 6mois maintenant. Aucun update, maj, reboot, crash n'a encore tué la config. Niveau confort de config c'est aussi bcp plus simple.
J'utilisais cgroup, on a vu qu'il était possible d'utiliser nftable. Ça été mi en place en moins de 15mins, sans erreurs.

Oui, de mon coté j'utilise un archlinux avec systemd-networkd, il faut jouer avec les dépendances mais ça se fait bien aussi. Et le seul truc un peu tricky, c'est au boot. Une fois que l'interface est créé, les renew/release passent sans problème (les rules nftables définitives étant chargées).

Le truc que je trouve chiant avec systemd c'est la complexité de mise en place d'un arbre de dépendance de service et vérifier qu'il fonctionne vraiment correctement. C'est un enfer a debug.
Et pourtant j'aime systemd, c'est un foutu bon gestionnaire de service.

D'ailleurs dans networkd, les pre-script sont aussi dispo ?

Malheureusement non...
D'où la nécessité de jouer avec les dépendances (voir mon précédent post).
Perso, je déteste systemd, je regrette la bonne vieille époque de rc.conf héritée de *BSD (sous archlinux).

Wé non ... l'ordre naturel séquentiel pour démarrer des services ... l'enfer. Sans moi