Pendant mon travail d'étude pratique de IPv6, #JaiDécouvert le projet Containerlab :

Containerlab was meant to be a tool for provisioning networking labs built with containers. It is free, open and ubiquitous. No software apart from Docker is required! As with any lab environment it allows the users to validate features, topologies, perform interop testing, datapath testing, etc. It is also a perfect companion for your next demo. Deploy the lab fast, with all its configuration stored as a code -> destroy when done.

source

Projet qui a commencé en 2020 et semble principalement développé par un développeur de chez Nokia.

D'après ce que j'ai compris, Containerlab me permet de facilement créer des réseaux dans un simulateur.

Je me souviens que je cherchais ce type d'outil en 2018, quand je travaillais sur un projet baremetal as service chez Scaleway.

Voici un exemple de fichier créé par Claude.ia pour simuler un environnement composé de deux réseaux IPv6 connectés entre eux : 3 serveurs sur le premier réseau et 2 serveurs sur le second.

Je précise que je n'ai pas encore testé ce fichier. J'ignore donc s'il fonctionne correctement.

name: dual-network-ipv6-lab
topology:
  nodes:
    # Routeur avec IPv6
    router:
      kind: linux
      image: alpine:latest
      exec:
        # Activer IPv6
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - sysctl -w net.ipv6.conf.all.forwarding=1
        # Adresses IPv6 sur les interfaces
        - ip -6 addr add 2001:db8:1::1/64 dev eth1
        - ip -6 addr add 2001:db8:2::1/64 dev eth2
        # IPv4 en parallèle (dual-stack)
        - ip addr add 192.168.1.1/24 dev eth1
        - ip addr add 192.168.2.1/24 dev eth2
        - echo 1 > /proc/sys/net/ipv4/ip_forward
    
    # Réseau A (2001:db8:1::/64)
    vm-a1:
      kind: linux  
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::10/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.10/24 dev eth1
        - ip route add default via 192.168.1.1
        
    vm-a2:
      kind: linux
      image: alpine:latest  
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::11/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.11/24 dev eth1
        - ip route add default via 192.168.1.1
        
    vm-a3:
      kind: linux
      image: alpine:latest
      exec: 
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:1::12/64 dev eth1
        - ip -6 route add default via 2001:db8:1::1
        - ip addr add 192.168.1.12/24 dev eth1
        - ip route add default via 192.168.1.1
    
    # Réseau B (2001:db8:2::/64)
    vm-b1:
      kind: linux
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:2::10/64 dev eth1  
        - ip -6 route add default via 2001:db8:2::1
        - ip addr add 192.168.2.10/24 dev eth1
        - ip route add default via 192.168.2.1
        
    vm-b2:
      kind: linux
      image: alpine:latest
      exec:
        - sysctl -w net.ipv6.conf.all.disable_ipv6=0
        - ip -6 addr add 2001:db8:2::11/64 dev eth1
        - ip -6 route add default via 2001:db8:2::1
        - ip addr add 192.168.2.11/24 dev eth1
        - ip route add default via 192.168.2.1

  links:
    # Réseau A
    - endpoints: ["router:eth1", "vm-a1:eth1"]  
    - endpoints: ["router:eth1", "vm-a2:eth1"]
    - endpoints: ["router:eth1", "vm-a3:eth1"]
    
    # Réseau B
    - endpoints: ["router:eth2", "vm-b1:eth1"]
    - endpoints: ["router:eth2", "vm-b2:eth1"]

En étudiant IPv6 et Linux bridge, j'ai découvert que le projet bridge-utils est déprécié. À la place, il faut utiliser iproute2.

Ce qui signifie que je ne dois plus utiliser la commande brctl, chose que j'ignorais jusqu'à ce matin.

iproute2 remplace aussi le projet net-tools. Par exemple, les commandes suivantes sont aussi dépréciées :

• ifconfig remplacé par ip addr et ip link
• route remplacé par ip route
• arp remplacé par ip neigh
• brctl remplacé par ip link
• iptunnel remplacé par ip tunnel
• nameif remplacé par ip link set name
• ipmaddr remplacé par ip maddr

Au-delà des aspects techniques — iproute2 utilise Netlink plutôt que ioctl — l'expérience utilisateur me semble plus cohérente.
J'ai une préférence pour une commande unique ip accompagnée de sous-commandes plutôt que pour un ensemble de commandes disparates.
Cette logique de sous-commandes s'inscrit dans une tendance générale de l'écosystème Linux, et je pense que c'est une bonne direction.
Je pense notamment à systemctl, timedatectl, hostnamectl, localectl, loginctl, apt, etc.

Quand j'ai débuté sous Linux en 1999, j'ai été habitué à utiliser les commande ifup et ifdown qui sont en réalité des scripts bash qui appellent entre autre ifconfig.
Ces scripts ont été abandonnés par les distributions Linux qui sont passées à systemd et NetworkManager.

En simplifiant, l'équivalent des commandes suivantes avec NetworkManager :

$ ifconfig
$ ifup eth0
$ ifdown eth0

est :

$ nmcli device status
$ nmcli connection up <nom_de_connexion>
$ nmcli connection down <nom_de_connexion>

Contrairement à mon intuition initiale, NetworkManager n'est pas un simple "wrapper" de la commande ip d'iproute2.

En fait, nmcli fonctionne de manière totalement indépendante d'iproute2, il utilise l'interface Netlink comme l'illustre cet exemple de la commande nmcli device show :

nmcli device show
    ↓ (Method call via D-Bus)
org.freedesktop.NetworkManager.Device.GetProperties()
    ↓ (NetworkManager traite la requête)
nl_send_simple(sock, RTM_GETLINK, ...)
    ↓ (Socket netlink vers kernel)
Kernel: netlink_rcv() → rtnetlink_rcv()
    ↓ (Retour des données)
RTM_NEWLINK response
    ↓ (libnl parse la réponse)
NetworkManager met à jour ses structures
    ↓ (Réponse D-Bus)
nmcli formate et affiche les données

Autre différence, contrairement à iproute2, les changements effectués par NetworkManager sont automatiquement persistants et il peut réagir à des événements, tel que le branchement d'un câble réseau et la présence d'un réseau WiFi connu.

Les paramètres de configuration de NetworkManager se trouvent dans les fichiers suivants :

• Fichiers de configuration globale de NetworkManager :

# Fichier principal
/etc/NetworkManager/NetworkManager.conf

# Fichiers de configuration additionnels
/etc/NetworkManager/conf.d/*.conf

• Fichiers de configuration des connexions NetworkManager :

# Configurations système (root)
/etc/NetworkManager/system-connections/

# Configurations utilisateur
~/.config/NetworkManager/user-connections/

Comme souvent, Ubuntu propose un outil "maison", nommé netplan qui propose un autre format de configuration. Mais je préfère utiliser nmcli qui est plus complet et a l'avantage d'être la solution mainstream supportée par toutes les distributions Linux.

En étudiant IPv6 et Linux bridge, j'ai découvert que Netlink a été introduit pour remplacer ioctl et procfs.

Netlink permet à des programmes user-land de communiquer avec le kernel via une API asynchrone. C'est une technologie de type inter-process communication (IPC).

La partie "Net" de "Netlink" s'explique par l'histoire : au départ, Netlink servait exclusivement à iproute2 pour la configuration réseau.
L'usage de Netlink s'est ensuite généralisé à d'autres aspects du kernel.

En rédigeant la note 2025-02-12_1044, je me suis demandé quelle est la différence de performance entre un Unix Socket et un INET socket.

Durant mes recherches, j'ai découvert qu'Unix Socket est plus rapide que INET sockets. Je n'ai pas été surpris, j'avais cette intuition.

Toutefois, j'ai été surpris d'apprendre que le gain est non négligeable, de 30% à 50% de gains !

Exemple :

On my machine, Ryzen 3900X, Ubuntu 22,

A basic C++ TCP server app that only sends 64K packets, and a basic c++ receiver that pulls 100GB of these packets and copies them to it's internal buffer only, single-threaded:

• achieves ~30-33 GBit/sec for TCP connection (~4.0GB/sec) (not MBit)
• and ~55-58GBit/sec for a socket connection, (~7.3 GB/sec)
• and ~492Gbit/sec for in-process memcopy (~61GB /sec)

source

Conséquence : je vais essayer d'utiliser des Unix sockets autant que je peux.

En étudiant Pi-hole, je découvre le terme "DNS sinkhole" :

A DNS sinkhole, also known as a sinkhole server, Internet sinkhole, or Blackhole DNS is a Domain Name System (DNS) server that has been configured to hand out non-routable addresses for a certain set of domain names.

...

Another use is to block ad serving sites, either using a host's file-based sinkhole or by locally running a DNS server (e.g., using a Pi-hole). Local DNS servers effectively block ads for all devices on the network.

source

#JaiDécouvert LibreSpeed que je vais utiliser à la place de https://fast.com/.

Il me propose une information supplémentaire à Fast.com : jitter.

Ma première mesure, en étant connecté en wifi :

• ping 17.0ms
• jitter : 120ms

La valeur jitter était anormalement élevée. J'ai relancé mon interface wifi radio 1 de mon Xiaomi Mi Router 4A Gigabit Edition sur un autre canal :

Maintenant, j'ai de bien meilleures performances :

Voici le même test quand mon laptop est connecté en câble Ethernet :

Les valeurs du ping et du jitter sont comparables, seul le débit est supérieur.

#JaiDécouvert le projet "Falling-Sky project" qui propulse, par exemple, l'instance test-IPv6.com.

Résultat de http://test-ipv6.com/index.html.fr_FR quand je suis connecté à mon réseau domestique :

J'ai vérifié, tous mes devices ont bien une IPv6 spécifique.

#JaiDécouvert le thread TUTO - Remplacement BBox Fibre par Mikrotik (IPv4, IPv6 et TV/Replay).

#JaiDécouvert la section "remplacer-bbox" du forum lafibre.info.

J'ai étudié les connecteurs SFP+.

#JaiDécouvert le site https://hack-gpon.org

#JaiDécouvert les termes ONT (Optical Network Terminal), GPON (Gigabit Passive Optical Network), OLT (Optical Line Terminal), Fiber-optic splitter, PLOAM.

J'ai apprécié la lecture de ce schéma :

Bien que je pense que les débits ne sont pas à jour.

Voici le matériel listé dans TUTO - Remplacement BBox Fibre par Mikrotik (IPv4, IPv6 et TV/Replay) :

• Module ONU SFP GPON avec Mac à 70 € TTC
• Mikrotik CCR2116-12G-4S+ à 937 € 😮
• Mikrotik CRS310-1G-5S-4S+IN à 200 €
• TPLink TP-MC22L à 20 €

CRS310-1G-5S-4S+IN permet d'insérer 4 SFP+, je pense qu'il est possible d'utiliser soit ce routeur, soit le CCR2116-12G-4S+.

Afin de faciliter le paramétrage du module SFP GPON : 1x convertisseur de media (par exemple TPLink TP-MC22L)

J'ai des difficultés à comprendre, j'ai l'impression que l'article liste beaucoup de matériel redondant 🤔.

En étudiant le sujet, je suppose que la configuration matérielle minimale est : TP-MC22L à 20 € + Module ONU SFP GPON avec Mac à 70 € TTC.

Je compends que le ONT a besoin des paramètres suivants pour se connecter au réseau (GPON) Bouygues :

• Dans l'interface de la BBox, le SN du SFP commençant par SMB : SMBA0000X000, qui semble être utilisé en tant qu'identifiant
• Sur l'étiquette arrière de la BBox :
  • L'adresse MAC : 48:29:FF:FF:FF:FF
  • L'IMEI : 123456789012345 converti en 0000123456789012345 qui est utilisé en tant que "password"

Ce commentaire liste le matériel suivant :

• Netgear GS724Tv4 - Smart Switch Ethernet 24 Ports RJ45 Gigabit (10/100/1000), Web Manageable Professionnel - switch RJ45 avec 2 Ports SFP 1 Gigabit, Bureau ou en Rack et Protection à Vie ProSafe à 256 €
• Mikrotik RB3011UiAS-RM à 175 €

#JaiDécouvert la signification de iNIC (from).

En explorant la console de Scaleway, je viens de tomber sur la fonctionnalité suivante :

Scaleway Domains and DNS provides advanced features for traffic management using your DNS zone. It allows you to redirect users based on their geolocation, the load on your different servers, and more.

Je viens de réaliser que cela répond à une question que je me posais souvent entre 2000 et 2010 : comment les sites à portée mondiale parviennent-ils à répartir le trafic entre différents datacenters avec une URL unique, comme google.com ?

À l’époque, j’imaginais que ces acteurs utilisaient principalement le Round-robin DNS ou des algorithmes de répartition de charge avec HAProxy. mais je n'avais pas pensé à la possibilité que le serveur DNS puisse donner une réponse différente en fonction de l'IP de la personne qui fait la requête.
De plus, cette réponse peut dépendre de la localisation de l'IP (GeoIP).

Par exemple, depuis 2014, le serveur DNS Bind propose nativement la fonctionnalité "GeoIP Features".

J'ai lu aussi que les gros acteurs utilisent la méthode Anycast, mais cette méthode nécessite de gérer son propre Autonomous System.