La Fibre
Télécom => Logiciels et systèmes d'exploitation => Tutoriels pour Ubuntu server => Discussion démarrée par: vivien le 27 janvier 2021 à 22:23:30
-
Bonding (agrégation de liens) avec Netplan
J'ai déjà fait un message en 2012 qui explique le Bonding, l'agrégation de lien sous Linux :
Etherchannel - Bonding :
Coté Linux, Etherchannel s'appelle bondind et se matérialise sous la forme d'un module disponible en standard dans le noyau. Comme pour le switch, on regroupe plusieurs interfaces physiques (ethx) sur une interface logique (nommée bondx, x est le numéro de l'interface). Les solutions offertes par le bonding sont nombreuses :
- Mode 0 : Round Robin (équilibrage de charge) : Ce mode augmente la bande passante et gère la tolérance de panne. Groupement de ports pour load balancing et Failover : Le trafic sortant de l'interface est émis alternativement sur chacune des interfaces. Les ports du switch sont groupés avec Etherchannel. Par contre la configuration est statique sans protocole PagP ou LACP (802.3ad).
- Mode 1 : Active - passive / Active backup : Failover seulement : Seule une des interfaces physique est active et répond au requêtes arp. Pas de propriétés particulière sur le switch.
- Mode 2 : Balance-XOR : Groupement de ports pour load balancing et Failover : Le switch est configuré en Etherchannel. Dans le sens sortant, le serveur Linux choisit l'interface physique en fonction de l'adresse mac (source ou destination, ou XOR sur les deux). Sur le switch Cisco, Etherchannel fonctionne aussi sur ce principe (le load balancing effectué sur le switch concerne le trafic entrant sur le serveur Linux). Ainsi les transferts sont parallélisés et le choix de l'interface suit la règle : (Adresse MAC de la source XOR Adresse MAC de la destination) modulo nombre d'interfaces.
- Mode 3 : Broadcast : Failover seulement : Le trafic est transmis sur toutes les interfaces physiques.
- Mode 4 : IEEE 802.3ad (https://fr.wikipedia.org/wiki/IEEE_802.3ad) : Groupement de ports pour load balancing et Failover : Fonctionne les switchs Ethernet qui supportent cette norme. Le mécanisme de load blancing est similaire à celui du mode Balance-XOR.Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. Cela implique que le switch gère le 802.ad et que les interfaces soient compatibles mii-tool et/ou ethtool.
La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments sélectionnables suivants :
- niveau 2 (adresses MAC source et adresses MAC destination) ;
- niveau 3 (IP source et IP destination) ;
- niveau 4 (port source et port destination).
Tous les ports d'un groupe doivent obligatoirement être paramétrés à la même vitesse, même duplex (full/half), même VLAN, même mode (access/trunk).
- Mode 5 : Adaptive transmit load balancing (balance-tlb) : Load balancing dans le sens sortant uniquement : Le trafic sortant de l'interface est émis de sur l'une ou l'autre des interfaces physique en fonction de le charge. Dans le sens entrant, une seule des interfaces physique répond au requêtes ARP. Aucune configuration particulière n'est nécessaire sur le switch. Les drivers de la carte ethernet sur le serveur Linux doivent être compatibles ethool.
- Mode 6 : Adaptative load balancing (balance-alb) : Load balancing dans les deux sens. Reprend le mécanisme balance-tlb dans le sens sortant. Dans le sens entrant, le bonding intercepte les requêtes ARP pour renvoyer alternativement l'adresse des interfaces physiques.
Adaptive load balancing : ce mode inclut en plus du tlb un load balancing sur le flux entrant et seulement pour un trafic IPV4. L'équilibrage est réalisé au niveau ARP. Le module intercepte les réponses pour y réécrire l'adresse MAC de l'une des interfaces du bond tout en tenant compte des spécificités du protocole ARP. La répartition entre les différentes interfaces, se fait de façon séquentielle ( round robin ).
Tous ces modes sont listés et expliqués dans la documentation du module bonding qui est livrée avec les sources du noyau.
Le mode 4 IEEE 802.3ad est conseillé avec des switch Cisco.
Exemple de fichier de configuration en mode IEEE 802.3ad avec Ubuntu :
(mode 4 - conseillé avec un switch Cisco)
- Vérifier que le paquet pour gérer le bonding est bien installé (c'est généralement le cas avec les distributions serveur) :
apt install ifenslave-2.6
- Définition du type de bonding a utiliser :
nano -w /etc/modprobe.d/aliase-bond.conf
alias bond0 bonding
options bonding mode=4 xmit_hash_policy=layer3+4 miimon=100 downdelay=200 updelay=200
mode=4 : signifie que nous utilisons le mode 802.3ad
xmit_hash_policy=layer3+4 : choix de l'interface en upload via les info niveau 3 (IP source et IP destination) et 4 (port source et port destination). Par défaut c'est le niveau 2 (adresse mac) => Dans la cas d'un serveur avec une passerelle par défaut, tout le trafic hors du réseau local part via la même interface. Cela ne concerne que l'upload. Pour le download, la configuration se fait sur le switch.
miimon=100 : une vérification de l'état des interfaces physiques est effectuée toutes les 100ms.
- Définition de l'interface réseau :
nano -w /etc/network/interfaces
# The primary network interface
#auto eth0
#iface eth0 inet dhcp
auto eth0
auto eth1
auto bond0
iface bond0 inet static
address 138.21.127.54
netmask 255.255.255.240
network 138.21.127.48
broadcast 138.21.127.63
gateway 138.21.127.62
up /sbin/ifenslave bond0 eth0 eth1
down /sbin/ifenslave -d bond0 eth0 eth1
Certaines machines vont utiliser eth0 et d'autres eth1. A noter qu'un même PC, même protocole et même port peut utiliser eth0 en download et eth1 en upload.
En cas de panne d'une des deux liaisons, le trafic passe intégralement par l'autre.
En cas de ré-installation du serveur : l'accès internet est possible dès l'installation sans le bonding et sans reconfiguration du routeur.
-
Et le bonding avec Netplan, c'est comment ?
Maintenant, c'est Netplan qui configure le réseau depuis Ubuntu server 17.10, à la place de ifupdown et de son fichier de configuration /etc/network/interfaces
La documentation de Netplan est disponible sur https://netplan.io/reference/
Voici une configuration pour faire un bonding 802.3ad (le mode 4 dans mon explication précédente) des interfaces physique eno1 et eno2.
On va faire une répartition du trafic par un hash OU exclusif en fonction du niveau 3 (IP source et IP destination) et du niveau 4 (port source et port destination), ce qui se traduit dans netplan par transmit-hash-policy: encap3+4
On va éditer le fichier .yaml existant :
sudo nano /etc/netplan/00-installer-config.yaml
Voici une configuration qui fonctionne (configuration sur un serveur proposé par Appliwave) :
network:
bonds:
bond0:
addresses:
- 45.85.134.186/29
- "2a05:46c0:100:1007::2/64"
accept-ra: false
gateway4: 45.85.134.185
gateway6: "2a05:46c0:100:1007::1"
interfaces:
- eno1
- eno2
nameservers:
addresses:
- 185.73.206.93
- 185.73.206.94
parameters:
lacp-rate: fast
mode: 802.3ad
transmit-hash-policy: encap3+4
ethernets:
eno1: {}
eno2: {}
version: 2
Une fois votre fichier modifié, il suffit de faire
sudo netplan apply
pour appliquer les changements.
Le accept-ra: false est nécessaire pour ne pas se récupérer des IPv6 issue des Router Advertisements (qui va donc changer régulièrement, ce qui est problématique pour un serveur). SI vous définissez une IPv6 fixe sans accept-ra: false, vous aurez deux IPv6 : celle défini manuellement, utilisable pour les flux entrant et les réponses aux flux entrants sur cette IPv6 et une autre IPv6 dynamique, utilisée pour les flux sortants.
Pour rappel, pour les nostalgiques de ifupdown et de son fichier de configuration /etc/network/interfaces, vous avez beau mettre les lignes suivantes dans sysctl
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_dad = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_dad = 0
Au démarrage avec ifupdown, il y a un tout petit temps avant que la configuration ne soit appliquée ou le serveur va récupérer une IPv6 via le Router Advertisement, ce qui peut être vraiment problématique quand le Router Advertisement est mal paramétré coté routeur. Cf Ubuntu serveur utilise l'IPv6 HS du RA (Router Advertisement), à la place de celle indiquée dans /etc/network/interfaces (https://lafibre.info/serveur-linux/perte-ipv6/).
Les configurations complexes sont aussi plus simple avec Netplan, toutefois cela demande un peu de travail quand on a une configuration complexe qui fonctionne bien avec ifupdown que lon souhaite adapter avec Netplan.
-
Pour afficher les IP, oubliez ifconfig (il est possible de l'installer - sudo apt install net-tools - mais franchement il ne sait pas montrer toutes les IPv6 d'une configuration complexe)
ip demande de s'habituer, mais il a même une option "-c" pour colorer la sortie et la rendre plus lisible.
Voici ce que cela donne pour le bonding configuré dans le message précédent :
ip -4 -c addr show
(https://lafibre.info/testdebit/ubuntu/202101_netplan_afficher_ip_1.png)
ip -6 -c addr show
(https://lafibre.info/testdebit/ubuntu/202101_netplan_afficher_ip_2.png)
Pour la passerelle, oubliez l'utilitaire route :
ip -4 -c route show
(https://lafibre.info/testdebit/ubuntu/202101_netplan_afficher_ip_3.png)
ip -6 -c route show
(https://lafibre.info/testdebit/ubuntu/202101_netplan_afficher_ip_4.png)
Pour voir le trafic échangé en octets et en nombre de paquets depuis le démarrage de Linux par interface :
ip -h -s link
$ ip -h -s link
1: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:1a:1d:e0 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
941G 11.4G 0 15.8k 0 16
TX: bytes packets errors dropped carrier collsns
46.3T 31.1G 0 0 0 0
Ici on a 941 Go reçus et 46,3 To émis.
Autre exemple :
1: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:1d:90:20 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
86.8T 81.0G 0 560k 0 4.17k
TX: bytes packets errors dropped carrier collsns
178T 131G 0 0 0 0
-
Petite illustration du caractère sympathique de Netplan :
On peut activer / supprimer l’utilisation des Router Advertisements et appliquer la chose sans redémarrer.
Ci-dessous, j'ai juste commenté la ligne accept-ra: false du fichier .yaml
Après un simple sudo netplan apply mon système à récupérer une IPv6 via RA qui est utilisé pour sortir sur Internet.
J’enlève le commentaire, netplan apply et l'IPv6 disparaît.
J'ai entouré en vert les commandes passées et en rouge les lignes liés au Router Advertisements.
(https://lafibre.info/testdebit/ubuntu/202101_netplan_afficher_ip_5.png)
-
Pour moi ça ne marche pas, j'ai du mettre les lignes sysctl à la main
-
Tu parles bien de bloquer les IPv6 via Router Advertisements ?
(car on parle aussi de Bonding dans ce sujet)
-
Oui, y'a pas de règles sysctl pour le RA :P
-
c est super interessant je viens de monter un serveur derriere une lb5.
Le mode 0 ou 6 permettrais d atteindre les 2gb en multiflux (torrent) sans se prendre la tete avec le software ?
Par contre ca boufferais pas trop en cpu vi que c'est gere par le kernel et non le hardware ?
-
Comme l'explique iMot3k dans la seconde partie de cette vidéo, l'agrégation n'est pas activé coté Livebox, or toi tu ne souhaites pas envoyer les paquets vers deux canaux différents à la Livebox (upload) mais les recevoir.
https://lafibre.info/videos/free/202007_iMot3k_saturation_le_soir_free.mp4
On parle des solutions possibles sur Livebox 5: 2 Gb/s sur un seul PC équipé de deux ports Ethernet (https://lafibre.info/orange-les-news/livebox-5-2-gbs-sur-un-seul-pc/)
-
je vois pas où il a dit qu'il aurait essayer le bonding mode 0 ou 6. Il dit juste que le mode 4 n'est pas supporté par la livebox 5 et qu'il veut passer par un switch 10gb, moi je veux bien mettre 2 cable rj45 directement entre le serveur et la livebox 5.
Idem dans le topic livebox me semble que personne a tenter ?
Mais avant de tenter j'aurais voulu savoir si en théorie ca peut fonctionner :o
-
je vois pas où il a dit qu'il aurait essayer le bonding mode 0 ou 6. Il dit juste que le mode 4 n'est pas supporté par la livebox 5 et qu'il veut passer par un switch 10gb, moi je veux bien mettre 2 cable rj45 directement entre le serveur et la livebox 5.
Idem dans le topic livebox me semble que personne a tenter ?
Mais avant de tenter j'aurais voulu savoir si en théorie ca peut fonctionner :o
Bon j ai tester le mode 0 et mode 6 ca change rien. Ca fait même chuter le débit un peu au début. Par contre le failover est impressionant, totalement invisible en ssh par exemple. Mais bon c'est mieux sans le bonding donc je le retire :)
-
OVH est passé à Netplan : quand on ré-installe un VPS avec Ubuntu 20.04 c'est Netplan qui est utilisé.
Par contre ce qui est impardonnable, c'est que l'IPv6 n'est pas proposé !
Le client doit se débrouiller pour configurer son /128 IPv6 (oui, un /128, une seule IPv6). Triste en 2021.
le dossier /etc/netplan n'a qu'un seul fichier : 50-cloud-init.yaml
cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: fa:16:3e:57:01:42
mtu: 1500
set-name: ens3
La solution préconisée est de créer un second fichier de configuration pour IPv6 :
sudo nano /etc/netplan/51-cloud-init-ipv6.yaml
network:
version: 2
ethernets:
ens3:
dhcp6: no
match:
macaddress: fa:16:3e:57:01:42
addresses:
- 2001:41d0:305:2100::52/128
gateway6: 2001:41d0:305:2100::1
routes:
- to: 2001:41d0:305:2100::1
scope: link
Configuration NetPlan de Scaleway (Dedibox) : DHCP
# This is the network config written by 'subiquity'
network:
ethernets:
enp193s0f0:
critical: true
dhcp-identifier: mac
dhcp4: true
nameservers:
addresses:
- 62.210.16.6
- 62.210.16.7
search:
- online.net
enp193s0f1:
dhcp4: true
version: 2
-
Oui, je confirme, j’ai du configurer IPv6 dans netplan à la main sur mon vps Ubuntu 20.04 souscrit en mai 2020 (et qui a cramé à SBG2), ainsi que sur son remplaçant souscrit récemment à Gravelines.
Je ne comprends pas ce qui les empêche de le faire automatiquement avec cloudinit... Dans mon cas je maîtrise à peu près netplan donc pas trop de difficultés, mais en pratique j’imagine que plein de leurs clients VPS ne proposent pas leurs services en IPv6 uniquement par simple manque d’un fichier de configuration...
-
sudo netplan apply est la commande pour appliquer les changements.
sudo netplan try –config-file CONFIG_FILE est une alternative qui permet d'appliquer la configuration d'un fichier spécifique et de faire un retour arrière si vous avez perdu la main : netplan va attendre 120 secondes que vous confirmiez que c'est ok et en absence de confirmation fera un retour arrière.
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 113 seconds
Configuration accepted.
En cas de problème, la commande sudo netplan --debug generate permet dans certains cas de comprendre le problème.
journalctl --no-pager -lu systemd-networkd permet d'afficher des logs.
networkctl permet d'afficher les états des différentes interfaces:
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eno1 ether routable configured
3 eno2 ether no-carrier configuring
4 enp1s0 ether routable configured
Pour ne pas ralentir le démarrage de 120 secondes, une interface non utilisée, eno2 juste au-desus, ne doit pas être configuré dans Netplan.
Mettre dhcp4 et dhcp6 à "no" + accept-ra: false est insufisant : Netplan va attendre 120 secondes au démarrage.
Ce qu'il ne faut pas faire pour une interface Ethernet inutilisée :
eno2:
dhcp4: no
dhcp6: no
accept-ra: false
La solution ? il suffit de supprimer toutes les lignes faisant référence à cette interface.
-
Le fichier /etc/netplan/50-cloud-init.yaml proposé par OVH sur ses serveurs.... c'est une horreur !
A noter que j'ai caché une partie du préfixe IPv6 avec de xxxx : (2001:41d0:xxxx:b2b8::/56)
C'est un serveur OVH livré avec Ubuntu 20.04 LTS.
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
version: 2
ethernets:
enp3s0f0:
accept-ra: false
addresses:
- 2001:41d0:xxxx:b2b8::/56
dhcp4: true
gateway6: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
match:
macaddress: d4:5d:64:40:53:9c
nameservers:
addresses:
- 2001:41d0:3:163::1
routes:
- to: 2001:41d0:xxxx:b200::/57
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b280::/59
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2c0::/59
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2a0::/60
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2e0::/60
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b0::/61
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2f0::/61
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2bc::/62
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2f8::/62
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ba::/63
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2fc::/63
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b9::/64
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2fe::/64
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:8000::/65
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:8000::/65
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:4000::/66
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:4000::/66
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:2000::/67
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:2000::/67
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:1000::/68
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:1000::/68
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:800::/69
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:800::/69
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:400::/70
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:400::/70
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:200::/71
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:200::/71
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:100::/72
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:100::/72
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:80::/73
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff::/73
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:40::/74
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:80::/74
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:20::/75
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:c0::/75
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:10::/76
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:e0::/76
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:8::/77
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:f0::/77
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:4::/78
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:f8::/78
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:2::/79
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:fc::/79
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:1::/80
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:fe::/80
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:8000::/81
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:8000::/81
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:4000::/82
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:4000::/82
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:2000::/83
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:2000::/83
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:1000::/84
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:1000::/84
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:800::/85
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:800::/85
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:400::/86
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:400::/86
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:200::/87
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:200::/87
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:100::/88
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:100::/88
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:80::/89
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff::/89
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:40::/90
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:80::/90
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:20::/91
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:c0::/91
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:10::/92
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:e0::/92
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:8::/93
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:f0::/93
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:4::/94
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:f8::/94
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:2::/95
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:fc::/95
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8:0:1::/96
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:fe::/96
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::8000:0/97
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:8000:0/97
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::4000:0/98
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:4000:0/98
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::2000:0/99
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:2000:0/99
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::1000:0/100
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:1000:0/100
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::800:0/101
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:800:0/101
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::400:0/102
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:400:0/102
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::200:0/103
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:200:0/103
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::100:0/104
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:100:0/104
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::80:0/105
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff::/105
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::40:0/106
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:80:0/106
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::20:0/107
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:c0:0/107
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::10:0/108
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:e0:0/108
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::8:0/109
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:f0:0/109
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::4:0/110
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:f8:0/110
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::2:0/111
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:fc:0/111
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::1:0/112
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:fe:0/112
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::8000/113
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:8000/113
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::4000/114
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:4000/114
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::2000/115
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:2000/115
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::1000/116
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:1000/116
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::800/117
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:800/117
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::400/118
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:400/118
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::200/119
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:200/119
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::100/120
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:100/120
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::80/121
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:0/121
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::40/122
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:80/122
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::20/123
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:c0/123
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::10/124
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:e0/124
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::8/125
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:f0/125
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::4/126
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:f8/126
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::2/127
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:fc/127
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2b8::1/128
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
- to: 2001:41d0:xxxx:b2ff:ff:ff:ff:fe/128
via: 2001:41d0:xxxx:b2ff:ff:ff:ff:ff
set-name: enp3s0f0