L'overlays avec le frère (FRRouting)

Publier le 10 octobre 2021 15:00

Les sources

Pas d'IPv6 dans ma scène, mais elle s'est beaucoup aidée de l'article ci-dessous.

VxLAN: BGP EVPN avec FRR de Vincent Bernat

HP ? Cisco ? Non... FRRouting !

Installez-vous confortablement prenez-vous à boire et restez calme ! Aujourd'hui ça va parler réseau et plus particulièrement routage. Pour les curieux, je vous fournirai quelques traces à la fin pour analyser notre configuration.

L'objectif de cette scène est de construire un petit réseau overlay avec FRRouting qui ressemblera à ça :

Deux machines distantes joueront le rôle de serveur ET VTEP (point d'entrée d'un tunnel VxLAN) et une troisième machine incarnera le rôle de routeur en redistribuant les routes (RR).

Mais... pourquoi le VxLAN ? Le VLAN n'est pas suffisant ?

Le cas que nous allons réaliser n'est pas flagrant et on aurait très bien pu avoir un switch plutôt qu'un routeur pour réaliser la même architecture sans le VxLAN et seulement des VLAN.

Maintenant, imaginez les cas suivants :

  • les deux serveurs sont distants physiquement (un bon trajet Paris-Marseille).

  • le routeur représente un réseau maillé avec pleins de routeurs redistribuant les routes.

Ouais, j'ai rendu cela beaucoup trop abstrait avec mes trois machines, mais croyez-moi, en entreprise on retrouve ce genre de technologie (avec un mixte de BGP et d'OSPF en termes de protocole de routage).

J'en profite également pour vous fournir un petit récapitulatif entre le VLAN et le VxLAN avec les termes d'overlay et d'underlay :

Un VLAN permet d'isoler les flux dans un réseau local. Un tunnel VxLAN permet de transporter ces VLAN à l'extérieur de ces réseaux locaux.

Dans mon image, on voit que les VLAN sont dans l'underlay et le VxLAN dans l'overlay. Ce sont deux types de réseaux différents :

  • l'underlay est le réseau "client". Dans notre cas les VLAN sont de simple trame Ethernet 802.1q.

  • l'overlay est le réseau du "fournisseur". Elle transporte les trames "clientes" à travers son réseau. Dans notre cas, on utilisera la technologie d'overlay VxLAN pour transporter les trames 802.1q clientes.

L'avantage de l'overlay est également de séparer les flux. Si vous regardez mon image :

  • le tunnel VxLAN 1 prend les Vlan 1 et 2.

  • le tunnel VxLAN 2 prend le Vlan 3.

Le réseau overlay est transparent pour les sites underlay : un traceroute de l'underlay ne verra pas les équipements de l'overlay.

Bon aller, traite de bavardage, rentrons dans le vif du sujet !

Préparation des VM

Pour réaliser cette architecture, j'ai utilisé :

Sur VirtualBox, j'ai créé un réseau hôtes (Fichier -> gestionnaire de réseau hôte...) qui offre la possibilité aux machines virtuelles de communiquer entre-elles. Le réseau qui m'a été attribué par VirtualBox est le réseau 192.168.85.0/24.

Les VMs ont la même configuration à savoir :

  • Ubuntu Server 20.04.3 (Ubuntu 64bit) et tout par défaut lors d'une création d'une VM VirtualBox.

  • dans les configurations de la VM, ajout d'un adapteur réseau de type "réseau privé hôte" avec le mode de promiscuité "Allow VM".

Ensuite je lance les VMs pour installer Ubuntu en Français et j'installe FRRouting sur chaque machine.

Enfin, il reste un paramètre à installer sur les équipements pour qu'ils jouent leur rôle de "serveur" et de "routeur".

Pour le routeur, il faut autoriser le transfert de paquet IPv4 / IPv6 sinon notre tunnel VxLAN ne pourra pas se propager (la redistribution de route ne se fera pas). Donc, dans /etc/sysctl.conf, il faut documenter les lignes net.ipv4.ip_forward et/ou net.ipv6.ip_forward.

Pour les serveurs, il faut installer le package "bridge-utils" (on utilisera la commande brctl plus tard) et charger le module 8021q avec la commande "modprobe 8021q" pour utiliser les VLAN sur Ubuntu.

Aller, on attaque la configuration de FRRouting et des interfaces des serveurs !

FRRouting et script custom

Je vous remets la configuration que nous allons réaliser ci-dessous :

Bien, alors qu'est-ce qu'on a ? Deux serveurs qui ont une IP appartenant au VLAN 10 et au réseau 10.0.0.0/24. Ces deux serveurs ont également un VxLAN identifié par le numéro 10. Enfin, ils ont chacun une IP appartenant au réseau 192.168.85.0/24 (192.168.85.22 pour server1 et .23 pour server2). On pourra remercier le DHCP pour ça !

Pour le routeur, c'est plus simple, il n'y a qu'une adresse IP dans le réseau 192.168.85.0/24 : 192.168.85.24. Ne vous trompez pas sur le schéma, j'ai volontairement mis 2 fois le .24, mais c'est bien une seule et unique interface.

À la fin de notre configuration, les deux serveurs seront capables de se voir sur le réseau 10.0.0.0/24 avec leur adresse IP respective.

On remarque que le réseau 192.168.85.0/24 est commun aux trois machines et fait partie du système autonome (AS) 10. C'est là que le BGP rentre en jeu avec FRRouting. D'ailleurs, c'est par ce dernier que nous allons commencer.

FRRouting met à notre disposition des daemons Linux qui sont trouvable dans le fichier /etc/frr/daemons (droit administrateur requis). Le daemon qui nous intéresse est, sans surprise, bgpd que nous allons mettre à "yes" au sein de nos différents équipements (serveurs et routeur).

Il est temps de mettre en place la configuration FRRouting. Tout se passe dans /etc/frr/frr.conf. En suivant la documentation, on peut également remplir la configuration bgp dans un fichier /etc/frr/bgpd.conf, mais j'ai préféré tout mettre dans /etc/frr/frr.conf. Voici ce que ça donne pour les trois machines.

Server1

log syslog informational
hostname server1
username leparefou nopassword
!
router bgp 10
    bgp router-id 192.168.85.22
    neighbor mypeer peer-group
    neighbor mypeer remote-as 10
    neighbor 192.168.85.24 peer-group mypeer
    !
    address-family l2vpn evpn
        neighbor mypeer activate
        advertise-all-vni
    exit-address-family
    !
!

Server2

log syslog informational
hostname server2
username leparefou nopassword
!
router bgp 10
    bgp router-id 192.168.85.23
    neighbor mypeer peer-group
    neighbor mypeer remote-as 10
    neighbor 192.168.85.24 peer-group mypeer
    !
    address-family l2vpn evpn
        neighbor mypeer activate
        advertise-all-vni
    exit-address-family
    !
!

Pour les serveurs, on crée un système autonome BGP qui a pour numéro 10 et qui a pour identifiant de routeur l'adresse IP de l'équipement. On déclare un groupe de voisin appelé "mypeer" (on peut l'appeler comme on veut) qui est dans le système autonome 10. Dans le groupe de voisin, on ajoute l'adresse IP de l'équipement "router".

BGP va également gérer notre réseau overlay avec L2VPN EVPN. Alors, ça fait peur dis comme ça, mais pour faire au plus simple : c'est ce qui va nous permettre de propager notre tunnel VxLAN. Dans cette configuration L2VPN EVPN, on active notre voisin sous-entendu on dit à notre serveur qu'il peut propager un tunnel vers notre routeur. Ensuite on avertit à tous nos voisins activés que nous avons des VNI (identifiant VxLAN) sous le coude. Dans notre cas, c'est le VxLAN 10 que nous configurerons plus tard.

Router

log syslog informational
hostname router
username leparefou nopassword
!
router bgp 10
    bgp router-id 192.168.85.24
    neighbor mypeers peer-group
    neighbor mypeers remote-as 10
    bgp listen range 192.168.85.0/24 peer-group mypeers
    !
    address-family l2vpn evpn
        neighbor mypeers activate
        neighbor mypeers route-reflector-client
    exit-address-family
    !
!

On retrouve la même idée qu'avec les serveurs : AS 10, identifiant de routeur son adresse IP (192.168.85.24), création d'un groupe de voisin qui est sur l'AS 10. La directive "bgp listen..." permet d'ajouter tout le réseau 192.168.85.0/24 dans le groupe de voisins mypeers. La directive "route-reflector-client" permet de refléter les routes annoncées par les pairs configurés en tant que clients : ici ça sera nos deux serveurs.

Maintenant qu'on a notre réseau overlay qui est configuré sur nos équipements avec FRRouting, que diriez-vous de créer un petit script bash pour ajouter les interfaces sur nos deux serveurs ? Créons donc un fichier interfaces.sh que nous allons compléter de la manière suivante.

Server1

# Configuration VxLAN
ip link add vxlan10 type vxlan id 10 dstport 4789 local 192.168.85.22 nolearning
brctl addbr br10
brctl addif br10 vxlan10

# Configuration des interfaces virtuelles
ip link add veth0 type veth peer name veth1
ip link add link veth0 name veth0.5 type vlan id 5
ip addr add 10.0.0.1/24 dev veth0.5
brctl addif br10 veth1

# Activation des interfaces virtuelles - bridge - vxlan
ip link set up dev veth1
ip link set up veth0
ip link set up dev br10
ip link set up dev vxlan10

Server2

# Configuration VxLAN
ip link add vxlan10 type vxlan id 10 dstport 4789 local 192.168.85.23 nolearning # diff de Server1
brctl addbr br10 
brctl addif br10 vxlan10

# Configuration des interfaces virtuelles
ip link add veth0 type veth peer name veth1
ip link add link veth0 name veth0.5 type vlan id 5 
ip addr add 10.0.0.2/24 dev veth0.5 # diff de Server1
brctl addif br10 veth1

# Activation des interfaces virtuelles - bridge - vxlan
ip link set up dev veth1
ip link set up dev veth0
ip link set up dev br10
ip link set up dev vxlan10

Dans ce script on crée une interface VxLAN d'identifiant 10 qui écoute sur le port 4789 (port par défaut de la technologie VxLAN) avec comme IP local celui de notre réseau 192.168.85.0/24. Ensuite on crée une interface pont (br10) et on associe l'interface VxLAN à cette interface. Enfin, on crée une interface virtuelle (avec son interface peer) dans laquelle on attribue l'interface du réseau 10.0.0.0/24.

Pour les plus attentifs d'entre-vous, j'ai mis un numéro de VLAN à 5 sur l'interface virtuelle (et non pas 10 comme sur mon schéma). Ça sera beaucoup plus simple pour analyser les trames après. J'ajoute également le fait que la seule différence du script interface.sh sur le Server1 et le Server2 est leur IP (voir les lignes "# diff de Server1").

Pour lancer le script, rien de plus simple :

sudo bash interface.sh

Et à partir de là, la magie opère.

Server1

ping 10.0.0.2

Server2

ping 10.0.0.1

Phase de vérification

Si vous souhaitez faire plus de tests, je vous recommande vivement d'aller voir dans mes sources (au début de cette scène).

Server1

leparefou@server1:~$ sudo vtysh

Hello, this is FRRouting (version 8.0.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

server1# show interface vxlan10
Interface vxlan10 is up, line protocol is up
    Link ups:       1    last: 2021/10/09 17:29:17.43
    Link downs:     2    last: 2021/10/09 17:29:17.37
    vrf: default
    index 4 metric 0 mtu 1500 speed 0 
    flags: 
    Type: Unknown
    HWaddr: 4e:ea:c4:68:61:95
    inet6 fe80::4cea:c4ff:fe68:6195/64
    Interface Type Vxlan
    Interface Slave Type Bridge
    VxLAN Id 10 VTEP IP: 192.168.85.22 Access VLAN Id 1

    Master interface: br10
    protodown: off 
server1# show evpn mac vni 10
Number of MACs (local and remote) known for this VNI: 2
Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy
MAC               Type   Flags Intf/Remote ES/VTEP            VLAN  Seq #'s
02:cf:ac:8c:92:95 remote       192.168.85.23                        0/0
ca:bb:5a:69:65:93 local        veth1                                0/0

Server2

leparefou@server2:~$ sudo vtysh

Hello, this is FRRouting (version 8.0.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

server2# show interface vxlan10
Interface vxlan10 is up, line protocol is up
    Link ups:       1    last: 2021/10/09 17:29:24.30
    Link downs:     2    last: 2021/10/09 17:29:24.28
    vrf: default
    index 4 metric 0 mtu 1500 speed 0 
    flags: 
    Type: Unknown
    HWaddr: 66:57:74:3e:9f:d1
    inet6 fe80::6457:74ff:fe3e:9fd1/64
    Interface Type Vxlan
    Interface Slave Type Bridge
    VxLAN Id 10 VTEP IP: 192.168.85.23 Access VLAN Id 1

    Master interface: br10
    protodown: off 
server2# show evpn mac vni 10
Number of MACs (local and remote) known for this VNI: 2
Flags: N=sync-neighs, I=local-inactive, P=peer-active, X=peer-proxy
MAC               Type   Flags Intf/Remote ES/VTEP            VLAN  Seq #'s
02:cf:ac:8c:92:95 local        veth1                                0/0
ca:bb:5a:69:65:93 remote       192.168.85.22                        0/0

Un petit dernier pour la route. Installez le package traceroute sur les serveurs, et voyons combien de saut on aura fait entre les serveurs. Rappelez-vous du concept d'underlay et d'overlay et vous devriez anticiper la réponse.

sudo apt install traceroute

Server1

leparefou@server1:~$ traceroute 10.0.0.2
traceroute to 10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets
 1  10.0.0.2 (10.0.0.2)  0.487 ms  0.375 ms  0.362 ms

Server2

leparefou@server2:~$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  0.346 ms  0.316 ms  0.289 ms

Et oui ! Comme vous pouvez le constater, nous n'avons fait qu'un seul saut pour atteindre notre serveur. Autremement dit, nous n'avons pas vu le routeur lors de notre traceroute.

Par contre, si vous analysez la trame à l'arrivée, le champs Time To Live (TTL) a bien été mise à jours. Si on suppose que notre trame à un TTL de 255, qu'arrivera-t'il si nous mettons 255 routeurs dans le réseau overlay ? Aller je vous donne la réponse : le ping ne se fera pas.

D'autres tests peuvent être fait comme :

  • éteindre le routeur.

  • éteindre interface d'un équipement.

  • éteindre le service FRRouting.

Voilà ce qui conclu notre scène orientée réseau, bravo pour être arrivé jusque là ! Si le réseau vous intéresse, je vous conseille le site de ilearned.eu.org et d'aller faire un tour chez les contributeurs !