Introduction au routage dynamique OSPF avec BirdIntroduction au routage dynamique OSPF avec Bird 2.1. Plan d'adressage salle 211 Tableau#2.#A

Introduction au routage dynamique OSPF avec BirdPhilippe Latu

philippe.latu(at)inetdoc.net

https://www.inetdoc.net

Résumé

L'objectif de ce support de travaux pratiques est d'étudier le protocole deroutage dynamique OSPF. Cette illustration s'appuie sur une topologieminimale très classique : le triangle. L'originalité consiste à utiliser lesVLANs pour distinguer la topologie physique (l'étoile) de la topologielogique (le triangle). Cette version du support utilise le logiciel Bird.

Table des matières

1. Copyright et Licence .............................................................................................................................. 21.1. Méta-information ........................................................................................................................ 21.2. Conventions typographiques ....................................................................................................... 2

2. Topologie réseau étudiée ....................................................................................................................... 32.1. Plan d'adressage salle 211 ........................................................................................................... 42.2. Plan d'adressage salle 213 ........................................................................................................... 8

3. Préparer les systèmes pour le routage IPv4 et IPv6 ................................................................................. 124. Valider les communications entre routeurs ............................................................................................ 145. Configurer les démons OSPF Bird ......................................................................................................... 166. Échanger les routes entre Bird et le système ......................................................................................... 237. Publier les routes par défaut via OSPF .................................................................................................. 258. Ajouter des réseaux fictifs ..................................................................................................................... 299. Créer des interfaces de type dummy ..................................................................................................... 2910. Créer des interfaces de type veth ........................................................................................................ 3111. E<ectuer les manipulations sur machines virtuelles ............................................................................. 37

11.1. Préparation du commutateur Open vSwitch .............................................................................. 3811.2. Préparation des routeurs ......................................................................................................... 3911.3. Table de routage du système hôte ............................................................................................ 40

12. Consulter les documents de référence ................................................................................................ 41

Introduction au routage dynamique OSPF avec Bird 1

Introduction au routage dynamique OSPF avec Bird

1. Copyright et Licence

Copyright (c) 2000,2020 Philippe Latu.Permission is granted to copy, distribute and/or modify this document under theterms of the GNU Free Documentation License, Version 1.3 or any later versionpublished by the Free Software Foundation; with no Invariant Sections, noFront-Cover Texts, and no Back-Cover Texts. A copy of the license is includedin the section entitled "GNU Free Documentation License".

Copyright (c) 2000,2020 Philippe Latu.Permission est accordée de copier, distribuer et/ou modifier ce document selonles termes de la Licence de Documentation Libre GNU (GNU Free DocumentationLicense), version 1.3 ou toute version ultérieure publiée par la Free SoftwareFoundation ; sans Sections Invariables ; sans Texte de Première de Couverture,et sans Texte de Quatrième de Couverture. Une copie de la présente Licence estincluse dans la section intitulée « Licence de Documentation Libre GNU ».

1.1. Méta-information

Ce document est écrit avec DocBook XML sur un système Debian GNU/Linux. Il est disponible en versionimprimable au format PDF : interco.ospf-bird.qa.pdf.

Toutes les commandes utilisées dans ce document ne sont pas spécifiques à une version particulière dessystèmes UNIX ou GNU/Linux. C'est la distribution Debian GNU/Linux qui est utilisée pour les tests présentés. Voiciune liste des paquets contenant les commandes :

• procps - Utilitaires pour le système de fichiers /proc

• iproute2 - Outils de contrôle du trafic et du réseau

• ifupdown - Outils de haut niveau pour configurer les interfaces réseau

• iputils-ping - Outils pour tester l'accessibilité de noeuds réseaux

• bird - Internet Routing Daemon

1.2. Conventions typographiques

Tous les exemples d'exécution des commandes sont précédés d'une invite utilisateur ou prompt spécifique auniveau des droits utilisateurs nécessaires sur le système.

• Toute commande précédée de l'invite $ ne nécessite aucun privilège particulier et peut être utilisée au niveauutilisateur simple.

• Toute commande précédée de l'invite # nécessite les privilèges du super-utilisateur.


http://www.docbook.org

https://www.debian.org

https://www.inetdoc.net/pdf/interco.ospf-bird.qa.pdf


2. Topologie réseau étudiée

La topologie réseau étudiée peut être présentée sous deux formes distinctes : logique et physique.

Topologie logique

On retrouve un grand classique dans l'introduction aux protocoles de routage dynamiques : le triangle. Tousles liens sont de type LAN.

Topologie physique

On s'appuie sur le support Routage Inter-VLAN pour constituer une topologie physique à base de réseauxlocaux virtuels ou VLANs. On fait correspondre à chaque lien de la topologie logique en triangle un numérode VLAN défini.

Tableau 1. Topologies type

Topologie logique Topologie physique

Après avoir mis en œuvre la topologie physique en s'appuyant sur le support de la séance de travaux pratiquesprécédente : Routage Inter-VLAN, on implante les démons de routage OSPF sur les trois routeurs R1, R2 et R3.

Cette séance se limite à l'étude du routage dynamique à l'intérieur d'une aire unique. La seule «frontière» decommunication inter-aires visible est constituée par le lien vers l'Internet. Cette route par défaut sera redistribuéevia OSPF par le routeur R1 aux autres routeurs. On verra alors un exemple de route externe dans les bases dedonnées OSPF.

On profite aussi de cette introduction pour employer une technique très répandue pour ajouter «artificiellement»des entrées de tables de routage en s'appuyant sur des interfaces virtuelles de type dummy équivalentes à desinterfaces de boucle locale.

Pour les besoins de rédaction des questions et réponses de ce support, la topologie a été mise en œuvre surdes machines virtuelles KVM avec le commutateur Open vSwitch. Les éléments de correction des questionsdépendent donc de cette mise en œuvre. Pour la séance de travaux pratiques «réelle», il faut se conformerstrictement au plan d'adressage fourni ci-après.

Dans les manipulations à suivre, le raccordement au réseau d'interconnexion avec les routeurs de l'infrastructurede travaux pratiques est imposé. Le raccordement au commutateur de la couche distribution de la salle utilisele port «de numéro le plus élevé» de chaque commutateur de couche accès. Ces liens montants doivent êtreconfigurés en modetrunk en utilisant le VLAN natif numéro 1.

Point important, la lecture de la section «Plan d'adressage» du document Architecture réseau des travauxpratiques donne l'adresse des deux routeurs connectés à l'Internet.

• Routeur cooper.stri : 172.16.16.1/20 et 2001:678:3fc:4::1/64

• Routeur casper.stri : 172.16.16.2/20 et 2001:678:3fc:4::2/64


https://inetdoc.net/articles/inter-vlan-routing/


https://inetdoc.net/travaux_pratiques/infra.tp/



2.1. Plan d'adressage salle 211

Tableau 2. A<ectation d'un commutateur par groupe de 3 routeurs - salle 211

Groupe Commutateur

1 asw04-211.infra.stri




Voici, pour chaque groupe de trois routeurs, le tableau d'a<ectation des rôles, des numéros de VLANs et desadresses IP.

Tableau 3. Salle 211 - Groupe 1

Poste Rôle OSPF router-id VLAN Interface Réseau

172.16.17.10/20

4 eth0.42001:678:3fc:4::6ae/64

10.1.201.1/26

401 eth0.4012001:678:3fc:191::1/64

10.1.205.1/26

405 eth0.4052001:678:3fc:195::1/64

10.1.200.1/29

christophsis R1

OSPFv2 :0.211.4.11

OSPFv3 :0.211.6.11

- dummy02001:678:3fc:190::1/64

10.1.201.2/26

401 eth0.4012001:678:3fc:191::2/64

10.1.203.2/26

403 eth0.4032001:678:3fc:193::2/64

10.1.202.1/30: 10.1.202.2/30

corellia R2

OSPFv2 :0.211.4.12

OSPFv3 :0.211.6.12

- veth0:veth12001:678:3fc:192::1/64 ->2001:678:3fc:192::2/64

10.1.205.3/26

405 eth0.4052001:678:3fc:195::3/64

10.1.203.3/26

403 eth0.4032001:678:3fc:193::3/64

10.1.204.1/30: 10.1.204.2/30

delaya R3

OSPFv2 :0.211.4.13

OSPFv3 :0.211.6.13

- veth0:veth12001:678:3fc:194::1/64 ->2001:678:3fc:194::2/64





172.16.17.11/20

4 eth0.42001:678:3fc:4::6af/64

10.2.211.1/26

411 eth0.4112001:678:3fc:19b::1/64

10.2.215.1/26

415 eth0.4152001:678:3fc:19f::1/64

10.2.210.1/29

kashyyyk R1

OSPFv2 :0.211.4.21

OSPFv3 :0.211.6.21

- dummy02001:678:3fc:19a::1/64

10.2.211.2/26

411 eth0.4112001:678:3fc:19b::2/64

10.2.213.2/26

413 eth0.4132001:678:3fc:19d::2/64

10.2.212.1/30: 10.2.212.2/30

korriban R2

OSPFv2 :0.211.4.22

OSPFv3 :0.211.6.22

- veth0:veth12001:678:3fc:19c::1/64 ->2001:678:3fc:19c::2/64

10.2.215.3/26

415 eth0.4152001:678:3fc:19f::3/64

10.2.213.3/26

413 eth0.4132001:678:3fc:19d::3/64

10.2.214.1/30: 10.2.214.2/30

kessel R3

OSPFv2 :0.211.4.23

OSPFv3 :0.211.6.23

- veth0:veth12001:678:3fc:19e::1/64 ->2001:678:3fc:19e::2/64





172.16.17.12/20

4 eth0.42001:678:3fc:4::6b0/64

10.3.221.1/26

421 eth0.4212001:678:3fc:1a5::1/64

10.3.225.1/26

425 eth0.4252001:678:3fc:1a9::1/64

10.3.220.1/29

mygeeto R1

OSPFv2 :0.211.4.31

OSPFv3 :0.211.6.31

- dummy02001:678:3fc:1a4::1/64

10.3.221.2/26

421 eth0.4212001:678:3fc:1a5::2/64

10.3.223.2/26

423 eth0.4232001:678:3fc:1a7::2/64

10.3.222.1/30: 10.3.222.2/30

nelvaan R2

OSPFv2 :0.211.4.32

OSPFv3 :0.211.6.32

- veth0:veth12001:678:3fc:1a6::1/64 ->2001:678:3fc:1a6::2/64

10.3.225.3/26

425 eth0.4252001:678:3fc:1a9::3/64

10.3.223.3/26

423 eth0.4232001:678:3fc:1a7::3/64

10.3.224.1/30: 10.3.224.2/30

rattatak R3

OSPFv2 :0.211.4.33

OSPFv3 :0.211.6.33

- veth0:veth12001:678:3fc:1a8::1/64 ->2001:678:3fc:1a8::2/64





172.16.17.13/20

4 eth0.42001:678:3fc:4::6b1/64

10.4.231.1/26

431 eth0.4312001:678:3fc:1af::1/64

10.4.235.1/26

435 eth0.4352001:678:3fc:1b3::1/64

10.4.230.1/29

saleucami R1

OSPFv2 :0.211.4.41

OSPFv3 :0.211.6.41

- dummy02001:678:3fc:1ae::1/64

10.4.231.2/26

431 eth0.4312001:678:3fc:1af::2/64

10.4.233.2/26

433 eth0.4332001:678:3fc:1b1::2/64

10.4.232.1/30: 10.4.232.2/30

taris R2

OSPFv2 :0.211.4.42

OSPFv3 :0.211.6.42

- veth0:veth12001:678:3fc:1b0::1/64 ->2001:678:3fc:1b0::2/64

10.4.235.3/26

435 eth0.4352001:678:3fc:1b3::3/64

10.4.233.3/26

433 eth0.4332001:678:3fc:1b1::3/64

10.4.234.1/30: 10.4.234.2/30

teth R3

OSPFv2 :0.211.4.43

OSPFv3 :0.211.6.43

- veth0:veth12001:678:3fc:1b2::1/64 ->2001:678:3fc:1b2::2/64



2.2. Plan d'adressage salle 213

Tableau 7. A<ectation d'un commutateur par groupe de 3 routeurs - salle 213

Groupe Commutateur





Voici, pour chaque groupe de trois routeurs, le tableau d'a<ectation des rôles, des numéros de VLANs et desadresses IP.



172.16.17.1/20

4 eth0.42001:678:3fc:4::6a5/64

10.1.21.1/26

221 eth0.2212001:678:3fc:dd::1/64

10.1.31.1/26

231 eth0.2312001:678:3fc:e7::1/64

10.1.10.1/29

alderaan R1

OSPFv2 :0.213.4.11

OSPFv3 :0.213.6.11

- dummy02001:678:3fc:da::1/64

10.1.21.2/26

221 eth0.2212001:678:3fc:dd::2/64

10.1.32.2/26

232 eth0.2322001:678:3fc:e8::2/64

10.1.20.1/30: 10.1.20.2/30

bespin R2

OSPFv2 :0.213.4.12

OSPFv3 :0.213.6.12

- veth0:veth12001:678:3fc:db::1/64 ->2001:678:3fc:db::2/64

10.1.31.3/26

231 eth0.2312001:678:3fc:e7::3/64

10.1.32.3/26

232 eth0.2322001:678:3fc:e8::3/64

10.1.30.1/30: 10.1.30.2/30

centares R3

OSPFv2 :0.213.4.13

OSPFv3 :0.213.6.13

- veth0:veth12001:678:3fc:dc::1/64 ->2001:678:3fc:dc::2/64





172.16.17.2/20

4 eth0.42001:678:3fc:4::6a6/64

10.2.41.1/26

241 eth0.2412001:678:3fc:f1::1/64

10.2.51.1/26

251 eth0.2512001:678:3fc:fb::1/64

10.2.40.1/29

coruscant R1

OSPFv2 :0.213.4.21

OSPFv3 :0.213.6.21

- dummy02001:678:3fc:ee::1/64

10.2.41.2/26

241 eth0.2412001:678:3fc:f1::2/64

10.2.54.2/26

254 eth0.2542001:678:3fc:fe::2/64

10.2.50.1/30: 10.2.50.2/30

dagobah R2

OSPFv2 :0.213.4.22

OSPFv3 :0.213.6.22

- veth0:veth12001:678:3fc:ef::1/64 ->2001:678:3fc:ef::2/64

10.2.51.3/26

251 eth0.2512001:678:3fc:fb::3/64

10.2.54.3/26

254 eth0.2542001:678:3fc:fe::3/64

10.2.60.1/30: 10.2.60.2/30

endor R3

OSPFv2 :0.213.4.23

OSPFv3 :0.213.6.23

- veth0:veth12001:678:3fc:f0::1/64 ->2001:678:3fc:f0::2/64





172.16.17.3/20

4 eth0.42001:678:3fc:4::6a7/64

10.3.61.1/26

261 eth0.2612001:678:3fc:105::1/64

10.3.71.1/26

271 eth0.2712001:678:3fc:10f::1/64

10.3.70.1/29

felucia R1

OSPFv2 :0.213.4.31

OSPFv3 :0.213.6.31

- dummy02001:678:3fc:102::1/64

10.3.61.2/26

261 eth0.2612001:678:3fc:105::2/64

10.3.76.2/26

276 eth0.2762001:678:3fc:114::2/64

10.3.80.1/30: 10.3.80.2/30

geonosis R2

OSPFv2 :0.213.4.32

OSPFv3 :0.213.6.32

- veth0:veth12001:678:3fc:103::1/64 ->2001:678:3fc:103::2/64

10.3.71.3/26

271 eth0.2712001:678:3fc:10f::3/64

10.3.76.3/26

276 eth0.2762001:678:3fc:114::3/64

10.3.90.1/30: 10.3.90.2/30

hoth R3

OSPFv2 :0.213.4.33

OSPFv3 :0.213.6.33

- veth0:veth12001:678:3fc:104::1/64 ->2001:678:3fc:104::2/64





172.16.17.4/20

4 eth0.42001:678:3fc:4::6a8/64

10.4.81.1/26

281 eth0.2812001:678:3fc:119::1/64

10.4.91.1/26

291 eth0.2912001:678:3fc:123::1/64

10.4.100.1/29

mustafar R1

OSPFv2 :0.213.4.41

OSPFv3 :0.213.6.41

- dummy02001:678:3fc:116::1/64

10.4.81.2/26

281 eth0.2812001:678:3fc:119::2/64

10.4.98.2/26

298 eth0.2982001:678:3fc:12a::2/64

10.4.110.1/30: 10.4.110.2/30

naboo R2

OSPFv2 :0.213.4.42

OSPFv3 :0.213.6.42

- veth0:veth12001:678:3fc:117::1/64 ->2001:678:3fc:117::2/64

10.4.91.3/26

291 eth0.2912001:678:3fc:123::3/64

10.4.98.3/26

298 eth0.2982001:678:3fc:12a::3/64

10.4.120.1/30: 10.4.120.2/30

tatooine R3

OSPFv2 :0.213.4.43

OSPFv3 :0.213.6.43

- veth0:veth12001:678:3fc:118::1/64 ->2001:678:3fc:118::2/64



3. Préparer les systèmes pour le routage IPv4 et IPv6

La première étape consiste à installer les outils sur les trois routeurs, à appliquer une configuration commune età mettre en place la topologie physique.

1. Installer le paquet bird avant de brasser les postes sur les commutateurs attribués avec le plan d'adressagede la salle de travaux pratiques.

$ aptitude search ~ibirdi bird - démon de routage internet

Sans configuration particulière, les services bird et bird6 sont lancés.

R1:~# systemctl status bird● bird.service - BIRD Internet Routing Daemon (IPv4) Loaded: loaded (/lib/systemd/system/bird.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-10-20 12:58:52 UTC; 2min 23s ago Main PID: 751 (bird) Memory: 632.0K CGroup: /system.slice/bird.service └─751 /usr/sbin/bird -f -u bird -g bird

oct. 20 12:58:52 R1 systemd[1]: Starting BIRD Internet Routing Daemon (IPv4)...oct. 20 12:58:52 R1 systemd[1]: Started BIRD Internet Routing Daemon (IPv4).oct. 20 12:58:52 R1 bird[751]: Started

R1:~# systemctl status bird6● bird6.service - BIRD Internet Routing Daemon (IPv6) Loaded: loaded (/lib/systemd/system/bird6.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-10-20 17:18:50 UTC; 3h 9min ago Process: 1728 ExecStartPre=/usr/sbin/bird6 -p (code=exited, status=0/SUCCESS) Process: 1722 ExecStartPre=/usr/lib/bird/prepare-environment (code=exited, status=0/SUCCESS) Main PID: 1729 (bird6) Memory: 788.0K CGroup: /system.slice/bird6.service └─1729 /usr/sbin/bird6 -f -u bird -g bird

oct. 20 17:18:50 R1 systemd[1]: Starting BIRD Internet Routing Daemon (IPv6)...oct. 20 17:18:50 R1 systemd[1]: Started BIRD Internet Routing Daemon (IPv6).oct. 20 17:18:50 R1 bird6[1729]: Started

2. Activer le routage IPv4 et IPv6 au niveau noyau.

Il faut éditer le fichier /etc/sysctl.conf pour fixer les valeurs des paramètres de configuration du routage.Voir la section Fonctions réseau d'une interface du support Configuration d'une interface de réseau local.

#sysctl -pnet.ipv4.conf.default.rp_filter = 1net.ipv4.conf.all.rp_filter = 1net.ipv4.ip_forward = 1net.ipv6.conf.all.forwarding = 1net.ipv4.conf.all.secure_redirects = 1net.ipv4.conf.all.log_martians = 1

3. Créer les sous-interfaces associées aux VLANs sur chacun des routeurs R1, R2 et R3 à l'aide du script suivant :

#!/bin/bash

for vlan in $*do ip link add link eth0 name eth0.$vlan type vlan id $vlan ip link set dev eth0.$vlan updone

Sur le routeur R1, on utilise le script avec les numéros de VLANs 12 et 13 par exemple.

R1:~# sh ./subinterfaces.sh 12 13

On adapte l'utilisation du même script aux routeurs R2 et R3 avec les numéros de VLANs concernés.

Il est aussi possible d'éditer le fichier /etc/network/interfaces de façon à rendre cette configurationpermanente. Voici une copie de ce fichier pour le routeur R1.

# The loopback network interfaceauto loiface lo inet loopback

auto eth0iface eth0 inet static


https://inetdoc.net/travaux_pratiques/config.interface.lan/


address 192.0.2.7/27 gateway 192.0.2.1 dns-nameservers 192.0.2.1 9.9.9.9

iface eth0 inet6 static address 2001:678:3fc:a::7/64 gateway fe80::dc02:44ff:fe64:4834 dns-nameservers 2001:678:3fc:a::1 2620:fe::fe

auto eth0.12iface eth0.12 inet static address 10.1.12.1/26

iface eth0.12 inet6 static address 2001:678:3fc:c::1/64

auto eth0.13iface eth0.13 inet static address 10.1.13.1/26

iface eth0.13 inet6 static address 2001:678:3fc:d::1/64



4. Valider les communications entre routeurs

Avant d'aborder le déploiement du protocole de routage dynamique, il est nécessaire de valider le raccordementdes routeurs aux commutateurs désignés, les communications entre chaque routeur et la visualisation des tablesde routage pour les interfaces réseau configurées.

Q1. Quelles sont les opérations à e<ectuer pour implanter les adresses IPv4 et IPv6 des interfacescorrespondant à chacun des VLANs routés ?

Au niveau liaison, les sous-interfaces ont déjà été configurées avec le script subinterfaces.sh. Il reste àparamétrer les adresses de ces sous-interfaces.

Routeur R1

R1:~# ip addr add 10.1.12.1/26 brd + dev eth0.12R1:~# ip -6 addr add 2001:678:3fc:c::1/64 dev eth0.12R1:~# ip addr add 10.1.13.1/26 brd + dev eth0.13R1:~# ip -6 addr add 2001:678:3fc:d::1/64 dev eth0.13

Routeur R2

R2:~# ip addr add 10.1.12.2/26 brd + dev eth0.12R2:~# ip -6 addr add 2001:678:3fc:c::2/64 dev eth0.12R2:~# ip addr add 10.1.23.2/26 brd + dev eth0.23R2:~# ip -6 addr add 2001:678:3fc:17::2/64 dev eth0.23

Routeur R3

R3:~# ip addr add 10.1.13.3/26 brd + dev eth0.13R3:~# ip -6 addr add 2001:678:3fc:d::3/64 dev eth0.13R3:~# ip addr add 10.1.23.3/26 brd + dev eth0.23R3:~# ip -6 addr add 2001:678:3fc:17::3/64 dev eth0.23

Q2. Quelles sont les opérations à e<ectuer pour valider les communications IP entre routeurs ?

Lancer les tests ICMP usuels entre chaque routeur sur chaque lien actif.

Exemple entre R1 et R2

R1:~# ping -qc2 10.1.12.2PING 10.1.12.2 (10.1.12.2) 56(84) bytes of data.

--- 10.1.12.2 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 6msrtt min/avg/max/mdev = 0.068/0.309/0.551/0.242 ms

R1:~# ping -qc2 2001:678:3fc:c::2PING 2001:678:3fc:c::2(2001:678:3fc:c::2) 56 data bytes

--- 2001:678:3fc:c::2 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 19msrtt min/avg/max/mdev = 0.070/0.295/0.521/0.226 ms

L'opération est à répéter sur chaque lien entre deux routeurs reliés sur le même VLAN.

Q3. Comment visualiser la table de routage au niveau système ?

Utiliser la commande ip pour visualiser la table de routage

Toutes les routes a<ichées correspondent à des réseaux IPv4 et IPv6 sur lesquels le routeur est directementconnecté via une interface active correctement configurée.

Routeur R1 - niveau système

R1:~# ip route lsdefault via 192.0.2.1 dev eth0 onlink10.1.12.0/26 dev eth0.12 proto kernel scope link src 10.1.12.110.1.13.0/26 dev eth0.13 proto kernel scope link src 10.1.13.1192.0.2.0/27 dev eth0 proto kernel scope link src 192.0.2.7



R1:~# ip -6 route ls2001:678:3fc:a::/64 dev eth0 proto kernel metric 256 pref medium2001:678:3fc:c::/64 dev eth0.12 proto kernel metric 256 pref medium2001:678:3fc:d::/64 dev eth0.13 proto kernel metric 256 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev eth0.12 proto kernel metric 256 pref mediumfe80::/64 dev eth0.13 proto kernel metric 256 pref mediumdefault via fe80::dc02:44ff:fe64:4834 dev eth0 metric 1024 onlink pref medium


R2:~# ip route ls10.1.12.0/26 dev eth0.12 proto kernel scope link src 10.1.12.210.1.23.0/26 dev eth0.23 proto kernel scope link src 10.1.23.2

R2:~# ip -6 route ls2001:678:3fc:c::/64 dev eth0.12 proto kernel metric 256 pref medium2001:678:3fc:17::/64 dev eth0.23 proto kernel metric 256 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev eth0.12 proto kernel metric 256 pref mediumfe80::/64 dev eth0.23 proto kernel metric 256 pref medium


R3:~# ip route ls10.1.13.0/26 dev eth0.13 proto kernel scope link src 10.1.13.310.1.23.0/26 dev eth0.23 proto kernel scope link src 10.1.23.3

R3:~# ip -6 route ls2001:678:3fc:d::/64 dev eth0.13 proto kernel metric 256 pref medium2001:678:3fc:17::/64 dev eth0.23 proto kernel metric 256 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev eth0.13 proto kernel metric 256 pref mediumfe80::/64 dev eth0.23 proto kernel metric 256 pref medium

Q4. Comment activer la fonction routage du noyau Linux ?

Reprendre l'instruction présentée dans le document Configuration d'une interface de réseau local :activation du routage.

L'opération doit être répétée sur chacun des trois routeurs pour que le protocole de routage dynamiquepuisse fonctionner normalement.

Si cette fonction n'est pas active dans le noyau Linux, aucune décision d'acheminement d'un paquet d'uneinterface vers l'autre ne sera prise. Les paquets à router sont simplement jetés.

Les instructions d'activation de la fonction de routage sont données dans la section Préparation desrouteurs.


https://inetdoc.net/travaux_pratiques/config.interface.lan/conf-intf-lan.procfs.html

https://inetdoc.net/travaux_pratiques/config.interface.lan/conf-intf-lan.procfs.html


5. Con+gurer les démons OSPF Bird

Dans cette section, on introduit les premières commandes de configuration du protocole de routage dynamiqueOSPF qui permettent d'activer le protocole puis d'ajouter des entrées de réseau dans la base de données de ceprotocole.

Q5. Quels sont les fichiers de configuration à éditer pour activer les protocoles OSPFv2 et OSPFv3 sur lerouteur ?

Une fois le paquet bird installé, deux démons distincts sont lancés : bird pour IPv4 et bird6 pour IPv6.Rechercher dans la liste des fichiers fournis avec le paquet, les exemples de fichiers de configuration.

Les fichiers de configuration sont au nombre de deux. Ils sont placés dans le dossier /etc/bird/. Deuxexemples de ces fichiers sont données dans le dossier de documentation du paquet.

R1:~# dpkg -L bird | grep example/usr/share/doc/bird/examples/usr/share/doc/bird/examples/bird.conf.gz/usr/share/doc/bird/examples/bird6.conf.gz

Q6. Comment accéder à l'état des di<érents protocoles actifs pour chaque démon ?

À chaque édition d'un fichier de configuration, il faut relancer le démon correspondant. C'est à nouveaudans la liste des fichiers du paquet que l'on identifie les outils d'accès à la configuration active des deuxdémons.

Il faut consulter la section Remote control de la documentation Bird. Les commandes utiles pour cettequestion sont les suivantes.

show statusshow protocols

Chaque démon dispose d'une console propre avec les outils birdc et birdc6. Ce sont ces deux consolesqui permettent de connaître le statut du démon, la liste des protocoles actifs et les informations relativesau fonctionnement de ces protocoles.

R1:~# birdcBIRD 1.6.4 ready.bird> sh statusBIRD 1.6.4Router ID is 0.0.4.1Current server time is 2018-10-20 20:59:04Last reboot on 2018-10-20 16:54:04Last reconfiguration on 2018-10-20 20:58:58Daemon is up and running

R1:~# birdc6BIRD 1.6.4 ready.bird> sh statusBIRD 1.6.4Router ID is 0.0.6.1Current server time is 2018-10-20 21:00:22Last reboot on 2018-10-20 17:18:49Last reconfiguration on 2018-10-20 17:18:49Daemon is up and running

De la même façon, on peut connaître la liste des protocoles actifs de chaque démon.

bird> sh protocolsname proto table state since infodevice1 Device master up 16:54:04kernel1 Kernel master up 20:58:58

Q7. Comment activer le protocole de routage OSPF et attribuer l'identifiant du routeur ?

Consulter le document BIRD User's Guide à la section OSPF pour activer le protocole. Consulter lestableaux des plans d'adressage pour obtenir la valeur de l'identifiant du routeur à configurer.

On édite les fichiers /etc/bird.conf et /etc/bird6.conf avec les paramètres suivants.

router id IPv4 addressprotocol ospf <name>area <id>


https://bird.network.cz/?get_doc&v=16&f=bird-4.html

https://bird.network.cz/?get_doc&f=bird.html&v=16


Voici une copie des fichiers du routeur R1.

R1:~# grep -v ^# /etc/bird/bird.conf

router id 0.0.1.4;

protocol kernel { scan time 10; import none;}

protocol device { scan time 10;}

protocol ospf OSPFv2R1 { area 0 { };}

R1:~# grep -v ^# /etc/bird/bird6.conf

router id 0.0.1.6;



protocol ospf OSPFv3R1 { area 0 { };}

Une fois les deux services relancés, on peut vérifier que les éléments demandés sont bien présents dansla configuration des démons de routage OSPF.

R1:~# systemctl restart bird

R1:~# birdc sh protocolsBIRD 1.6.4 ready.name proto table state since infokernel1 Kernel master up 09:38:34device1 Device master up 09:38:34OSPFv2R1 OSPF master up 09:38:34 Alone

R1:~# birdc sh ospf stateBIRD 1.6.4 ready.

area 0.0.0.0

router 0.0.1.4 distance 0

R1:~# systemctl restart bird6

R1:~# birdc6 sh protocolsBIRD 1.6.4 ready.name proto table state since infokernel1 Kernel master up 09:42:33device1 Device master up 09:42:33OSPFv3R1 OSPF master up 09:42:33 Alone

R1:~# birdc6 sh ospf stateBIRD 1.6.4 ready.

area 0.0.0.0

router 0.0.1.6 distance 0

Q8. Comment activer et valider le protocole de routage OSPF pour les réseaux IPv4 et IPv6 connus de chaquerouteur ?

Consulter la section OSPF de la documentation BIRD User's Guide ainsi que l'exemple OSPF example. Ilsu<it d'adapter les exemples avec les noms d'interfaces en fonction du contexte.

On édite les fichiers /etc/bird.conf et /etc/bird6.conf avec les paramètres suivants.



https://gitlab.labs.nic.cz/labs/bird/wikis/OSPF_example


interface <interface pattern>authentication none|simple|cryptographic;

On vérifie au niveau console (Voir Remote control) l'état de la base de connaissance des deux processusOSPF avec la commande suivante.

show ospf state

Routeur R1 : OSPFv2 & interfaces

R1:~# grep -v ^# /etc/bird/bird.conf

router id 0.0.1.4;



protocol ospf OSPFv2R1 { rfc1583compat yes; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

Routeur R1 : base de connaissance OSPFv2

Dans la copie d'écran ci-dessous, on relève les deux routeurs voisins de R1 ainsi que le réseau distant10.1.23.0/26.

R1:~# birdc sh ospf stateBIRD 1.6.4 ready.

area 0.0.0.0

router 0.0.1.4 distance 0 network 10.1.12.0/26 metric 10 network 10.1.13.0/26 metric 10



network 10.1.12.0/26 dr 0.0.2.4 distance 10 router 0.0.2.4 router 0.0.1.4




R1:~# grep -v ^# /etc/bird/bird6.conf

router id 0.0.1.6;






protocol ospf OSPFv3R1 { area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

Routeur R1 : base de connaissance OSPFv3

Dans la copie d'écran ci-dessous, on relève les deux routeurs voisins de R1 ainsi que le réseau distant2001:678:3fc:17::/64.

R1:~# birdc6 sh ospf stateBIRD 1.6.4 ready.

area 0.0.0.0

router 0.0.1.6 distance 0 network [0.0.1.6-2] metric 10 network [0.0.1.6-3] metric 10



network [0.0.1.6-2] distance 10 router 0.0.1.6 router 0.0.2.6 address 2001:678:3fc:c::/64

network [0.0.1.6-3] distance 10 router 0.0.1.6 router 0.0.3.6 address 2001:678:3fc:d::/64

network [0.0.3.6-3] distance 20 router 0.0.3.6 router 0.0.2.6 address 2001:678:3fc:17::/64

Q9. Comment identifier le type de réseau des interfaces actives d'un routeur pour chaque version du protocolede routage OSPF ?

La question précédente montre que la configuration des deux processus bird et bird6 est basée surl'activation du protocole par interface. Il faut donc rechercher dans la section Remote control l'instructionqui donne l'état des interfaces actives.

show ospf interface

Comme on utilise uniquement des liens Ethernet dans ce contexte de travaux pratiques, le type de réseauest nécessairement di<usion.


R1:~# birdc sh ospf interfaceBIRD 1.6.4 ready.OSPFv2R1:Interface eth0.12 (10.1.12.0/26)




Type: broadcast Area: 0.0.0.0 (0) State: Backup Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.2.4 Designated router (IP): 10.1.12.2 Backup designated router (ID): 0.0.1.4 Backup designated router (IP): 10.1.12.1Interface eth0.13 (10.1.13.0/26) Type: broadcast Area: 0.0.0.0 (0) State: Backup Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.3.4 Designated router (IP): 10.1.13.3 Backup designated router (ID): 0.0.1.4 Backup designated router (IP): 10.1.13.1


R1:~# birdc6 sh ospf interfaceBIRD 1.6.4 ready.OSPFv3R1:Interface eth0.12 (IID 0) Type: broadcast Area: 0.0.0.0 (0) State: DR Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.1.6 Designated router (IP): fe80::70de:4fff:fe1d:68b4 Backup designated router (ID): 0.0.2.6 Backup designated router (IP): fe80::943a:41ff:fe65:7307Interface eth0.13 (IID 0) Type: broadcast Area: 0.0.0.0 (0) State: DR Priority: 1 Cost: 10 Hello timer: 10 Wait timer: 40 Dead timer: 40 Retransmit timer: 5 Designated router (ID): 0.0.1.6 Designated router (IP): fe80::70de:4fff:fe1d:68b4 Backup designated router (ID): 0.0.3.6 Backup designated router (IP): fe80::3032:e9ff:fe73:6322

Q10. Comment obtenir la liste du ou des routeurs voisins pour chaque processus de protocole de routagedynamique OSPFv2 ou OSPFv3 ?

Dès qu'une interface est active, il y a émission de paquets HELLO et si un routeur avec un démon OSPFenvoie aussi des paquets HELLO dans le même VLAN, les deux routeurs cherchent à former une adjacence.

La commande utile de la section Remote control est la suivante.

show ospf neighbors

À nouveau sur le routeur R1, voici un exemple de liste de routeurs OSPF voisins dans laquelle on reconnaîtles identifiants des routeurs R2 et R3.

R1:~# birdc sh ospf neighborsBIRD 1.6.4 ready.OSPFv2R1:Router ID Pri State DTime Interface Router IP0.0.2.4 1 Full/DR 00:31 eth0.12 10.1.12.20.0.3.4 1 Full/DR 00:34 eth0.13 10.1.13.3




R1:~# birdc6 sh ospf neighborsBIRD 1.6.4 ready.OSPFv3R1:Router ID Pri State DTime Interface Router IP0.0.2.6 1 Full/BDR 00:33 eth0.12 fe80::943a:41ff:fe65:73070.0.3.6 1 Full/BDR 00:36 eth0.13 fe80::3032:e9ff:fe73:6322

Q11. Comment identifier le rôle des di<érentes interfaces des routeurs pour chacun des liens du triangle de latopologie logique ?

Avertissement

La réponse à cette question suppose que les démons OSPF des trois routeurs de la topologie logiqueen triangle aient convergé. On doit repérer l'état Full pour les listes de routeurs voisins.

De plus, la réponse varie en fonction de l'ordre d'activation des démons OSPF des di<érents routeurs.En e<et, un routeur peut être élu routeur désigné (DR) en l'absence de routeurs voisins. Cette électionn'est pas remise en cause tant qu'il n'y pas de changement d'état de lien.

À partir des résultats des questions précédentes sur les interfaces actives, il est possible de compléter leschéma de la topologie étudiée avec l'état des interfaces pour chacun des trois liens.

Sur un même réseau de di<usion, il est possible de trouver plusieurs routeurs OSPF. Établir une relationde voisinage et procéder aux échanges de bases de données topologiques entre chaque routeur revientà constituer un réseau de relations complètement maillé. À chaque recalcul de topologie, ce réseaucomplètement maillé est ine<icace. C'est la raison pour laquelle la notion de routeur référent ouDesignated Router a été introduite. Lors d'un recalcul de topologie, tous les routeurs s'adressent auréférent qui correspond au cœur d'un réseau en topologie étoile.

Dans le contexte de la topologie triangle étudiée, il y a bien élection d'un routeur référent et d'un routeurréférent de secours. Cependant, comme il n'y a que deux routeurs par domaine de di<usion ou VLAN, onne peut pas caractériser l'utilité de cette élection.

Q12. Quelles sont les réseaux IPv4 et IPv6 présents dans la base calcul du protocole OSPF ?

On cherche a visualiser la liste des préfixes des réseaux connus des deux démons OSPF.

La commande utile dans les deux consoles est la suivante.

show route

Une fois que les trois routeurs de la topologie ont convergé, chaque démon connaît les trois préfixesqui correspondent aux trois côtés du triangle. Un routeur correspond à un sommet du triangle et il doitapprendre le préfixe réseau du côté opposé via ses deux routeurs voisins.

Voici la vue depuis le routeur R1.



R1:~# birdc sh routeBIRD 1.6.4 ready.10.1.12.0/26 dev eth0.12 [OSPFv2R1 16:47:15] * I (150/10) [0.0.2.4]10.1.13.0/26 dev eth0.13 [OSPFv2R1 16:47:10] * I (150/10) [0.0.3.4]10.1.23.0/26 via 10.1.13.3 on eth0.13 [OSPFv2R1 16:47:10] * I (150/20) [0.0.2.4]

Les valeurs notées entre parenthèses correspondent à la métrique du lien pour joindre le réseau noté àgauche. Pour le protocole OSPF, le calcul de métrique se fait à partir du coût de lien par défaut pour chaqueinterface active. La valeur par défaut est 10

Les deux premiers réseaux de la table sont joignable via un lien direct ; soit une métrique de 10. Le troisièmeréseau est joignable via deux liens Ethernet ; d'où la métrique de 20.

Pour les réseaux IPv6, on retrouve les mêmes métriques puisque la topologie est identique pour les deuxversion du protocole IP.

R1:~# birdc6 sh routeBIRD 1.6.4 ready.2001:678:3fc:d::/64 dev eth0.13 [OSPFv3R1 10:01:30] * I (150/10) [0.0.1.6]2001:678:3fc:c::/64 dev eth0.12 [OSPFv3R1 10:05:36] * I (150/10) [0.0.1.6]2001:678:3fc:17::/64 via fe80::3032:e9ff:fe73:6322 on eth0.13 [OSPFv3R1 10:05:38] * I (150/20) [0.0.3.6]

Avec OSPFv3, les relations de voisinage entre routeurs utilisent nécessairement les adresses de lien localappartenant au préfixe fe80::/10.

Q13. Comment utiliser toutes les solutions disponibles pour joindre le réseau distant depuis chacun dessommets de la topologie triangle ?

Avec la topologie logique triangle, le réseau du côté opposé à un sommet (au routeur) doit être joignabledepuis les deux réseaux locaux raccordés à ce routeur. Nous sommes donc dans un contexte multichemins.

Consulter la section OSPF de la documentation BIRD User's Guide et rechercher l'intsruction qui permetl'utilisation de plusieurs chemins à coût égal.

ecmp switch [limit number]

La fonction réseau du noyau Linux recherchée est connue sous le nom Equal Cost Multi Path ou ECMP.

Sur le routeur R1, la configuration du bloc d'instructions OSPF de chaque processus est la suivante.

R1:~# sed -n '/protocol ospf/,//p' /etc/bird/bird.confprotocol ospf OSPFv2R1 { rfc1583compat yes; ecmp yes; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

R1:~# sed -n '/protocol ospf/,//p' /etc/bird/bird6.confprotocol ospf OSPFv3R1 { ecmp yes; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

Relativement aux questions précédentes, les tables de routage proposées par les processus bird et bird6font apparaître les deux chemins disponibles pour joindre le réseau distant du sommet de la topologietriangle.

R1:~# birdc sh routeBIRD 1.6.4 ready.10.1.12.0/26 dev eth0.12 [OSPFv2R1 19:49:42] * I (150/10) [0.0.1.4]10.1.13.0/26 dev eth0.13 [OSPFv2R1 19:50:37] * I (150/10) [0.0.1.4]10.1.23.0/26 multipath [OSPFv2R1 19:50:48] * I (150/20) [0.0.2.4] via 10.1.12.2 on eth0.12 weight 1 via 10.1.13.3 on eth0.13 weight 1




R1:~# birdc6 sh routeBIRD 1.6.4 ready.2001:678:3fc:d::/64 dev eth0.13 [OSPFv3R1 19:50:38] * I (150/10) [0.0.1.6]2001:678:3fc:c::/64 dev eth0.12 [OSPFv3R1 19:49:44] * I (150/10) [0.0.1.6]2001:678:3fc:17::/64 multipath [OSPFv3R1 19:50:50] * I (150/20) [0.0.2.6] via fe80::3032:e9ff:fe73:6322 on eth0.13 weight 1 via fe80::943a:41ff:fe65:7307 on eth0.12 weight 1

6. Échanger les routes entre Bird et le système

Dans la section précédente, tous les échanges de préfixes réseau IPv4 et IPv6 se font entre les démons Birdinstallés sur les trois routeurs de la topologie étudiée. Il faut maintenant être capable d'échanger les résultats destraitements OSPFv2 et OSPFv3 avec le sous-système réseau du noyau de chaque routeur.

• Sur R1, les deux démons Bird doivent importer la route par défaut déjà connue au niveau système. De plus, lesroutes vers les réseaux fictifs de R2 et R3 apprise via OSPF doivent être exportées vers le sous-système réseaudu noyau de R1.

• Sur les routeurs R2 et R3, les routes par défaut apprises via OSPF doivent être exportées vers le sous-systèmeréseau du noyau. De plus les routes des réseaux fictifs doivent être importées dans les démons Bird pour êtrepubliées via OSPF.

Avertissement

Les résultats des questions de cette section ne sont visibles que si les routes sont déjà présentes, soitdans les démons de routage Bird, soit au niveau système.

Q14. Comment faire pour que les routes connues du sous-système réseau du noyau Linux soient importéesdans les deux démons bird et bird6 ?

Consulter la section kernel de la documentation BIRD User's Guide à la recherche des paramètresd'importation. Les commandes utiles pour cette question sont les suivantes.

importlearn switch

Pour cette question, les configurations des démons bird et bird6 sont identiques quel que soit le routeurconsidéré. Voici un extrait de fichier de configuration.

R1:~# sed -n '/protocol kernel/,/^}/p' /etc/bird/bird.confprotocol kernel { scan time 10; import all; learn yes;# export all; # Actually insert routes into the kernel routing table}

Tant que les questions sur l'ajout de réseaux fictifs ne sont pas traitées, seul les démons du routeur R1 ontun résultat observable. Les routes par défaut sont importées dans les démons Bird.

R1:~# birdc show route 0.0.0.0/0BIRD 1.6.4 ready.0.0.0.0/0 via 192.0.2.1 on eth0 [kernel1 13:47:04] * (10)

R1:~# birdc6 show route ::/0BIRD 1.6.4 ready.::/0 via fe80::dc02:44ff:fe64:4834 on eth0 [kernel1 2018-10-21] * (10)

Q15. Comment faire pour que les routes calculées par les processus bird et bird6 soient soumises au sous-système réseau du noyau Linux ?

Consulter la section kernel de la documentation BIRD User's Guide à la recherche des paramètresd'exportation. La commande utile pour cette question est la suivante.

export

En reprenant l'exemple du routeur R1, la configuration des blocs d'instructions kernel de chaque processusdevient :





R1:~# sed -n '/protocol kernel/,/^}/p' /etc/bird/bird.confprotocol kernel { scan time 10; import all; learn yes; export all; # Actually insert routes into the kernel routing table}

Avec la commande ip au niveau système, on voit apparaître les «sources» d'alimentation de la table deroutage du système en question : kernel et bird.

R1:~# ip route lsdefault via 192.0.2.1 dev eth0 onlink10.1.12.0/26 dev eth0.12 proto kernel scope link src 10.1.12.110.1.13.0/26 dev eth0.13 proto kernel scope link src 10.1.13.110.1.23.0/26 proto bird nexthop via 10.1.12.2 dev eth0.12 weight 1 nexthop via 10.1.13.3 dev eth0.13 weight 1192.0.2.0/27 dev eth0 proto kernel scope link src 192.0.2.7

R1:~# ip -6 route ls2001:678:3fc:a::/64 dev eth0 proto kernel metric 256 pref medium2001:678:3fc:c::/64 dev eth0.12 proto kernel metric 256 pref medium2001:678:3fc:d::/64 dev eth0.13 proto kernel metric 256 pref medium2001:678:3fc:17::/64 proto bird metric 1024 nexthop via fe80::3032:e9ff:fe73:6322 dev eth0.13 weight 1 nexthop via fe80::943a:41ff:fe65:7307 dev eth0.12 weight 1 pref mediumfe80::/64 dev eth0 proto kernel metric 256 pref mediumfe80::/64 dev eth0.12 proto kernel metric 256 pref mediumfe80::/64 dev eth0.13 proto kernel metric 256 pref mediumdefault via fe80::dc02:44ff:fe64:4834 dev eth0 metric 1024 onlink pref medium



7. Publier les routes par défaut via OSPF

Dans la topologie logique étudiée, le routeur R1 dispose d'un lien vers l'Internet. On considère ce lien comme laroute par défaut vers tous les réseaux non connus de l'aire OSPF contenant les trois routeurs.

Il est possible de publier une route par défaut via le protocole OSPF depuis le routeur R1 vers les deux routeursR2 et R3.

Avant publication de la route par défaut depuis le routeur R1, les démons OSPF n'utilisent que des annonces LSA(Link State Advertisement) de type 1 et 2. Voici un tableau de référence pour le codage des LSAs.

Tableau 12. Codage des annonces OSPF

OSPFv2 Description OSPFv3 Description

1 Router LSA 0x2001 Router LSA

2 Network LSA 0x2002 Network LSA

3 Network Summary LSA 0x2003 Inter-Area Prefix LSA for ABRs

4 ASBR Summary LSA 0x2004 Inter-Area Router LSA for ABRs

5 AS-external LSA 0x4005 AS-external LSA

6 Group Membership LSA 0x2006 Group Membership LSA

7 Not So Stubby Area LSA 0x2007 Type-7 LSA

8 0x2008 Link LSA

9 0x2009 Intra-Area Prefix LSA

• ABR : Area Border Router

• ASBR : Autonomous System Border Router

Les listes des annonces connues du routeur R1 avant publication des routes par défaut sont données dans lescopies d'écran ci-dessous.

R1:~# birdc show ospf lsadbBIRD 1.6.4 ready.

Area 0.0.0.0

Type LS ID Router Sequence Age Checksum 0001 0.0.1.4 0.0.1.4 80000148 1465 88f0 0001 0.0.2.4 0.0.2.4 80000146 1466 70f2 0002 10.1.12.2 0.0.2.4 80000003 1466 3439 0001 0.0.3.4 0.0.3.4 80000147 1469 a4b6 0002 10.1.13.3 0.0.3.4 80000003 1470 2148 0002 10.1.23.3 0.0.3.4 80000003 375 bf9e

R1:~# birdc6 show ospf lsadbBIRD 1.6.4 ready.

Area 0.0.0.0

Type LS ID Router Sequence Age Checksum 2001 0.0.0.0 0.0.1.6 8000015c 1643 116b 2009 0.0.0.0 0.0.1.6 8000015c 1643 7e2b 2001 0.0.0.0 0.0.2.6 80000151 1647 4243 2009 0.0.0.0 0.0.2.6 80000151 1647 9a18 2002 0.0.0.2 0.0.2.6 80000001 1647 9976 2009 0.0.0.2 0.0.2.6 80000001 1647 a95c 2001 0.0.0.0 0.0.3.6 80000153 1646 4c35 2009 0.0.0.0 0.0.3.6 80000153 1646 9c12 2002 0.0.0.2 0.0.3.6 80000001 1646 9b72 2009 0.0.0.2 0.0.3.6 80000001 1646 c939 2002 0.0.0.3 0.0.3.6 80000003 575 9a6f 2009 0.0.0.3 0.0.3.6 80000003 575 ca2a



Link eth0.12

Type LS ID Router Sequence Age Checksum 0008 0.0.0.2 0.0.1.6 80000137 1648 c5df 0008 0.0.0.2 0.0.2.6 8000012e 575 5640

Link eth0.13

Type LS ID Router Sequence Age Checksum 0008 0.0.0.3 0.0.1.6 80000137 1646 e1c1 0008 0.0.0.2 0.0.3.6 8000012e 610 62dc

Q16. Quelle est la condition préalable à respecter pour que le routeur R1 soit en mesure de publier une routepar défaut via OSPF ?

Avant de procéder à l'importation de route dans les démons Bird, on doit s'assurer de la présence desdeux routes par défaut IPv4 et IPv6 dans les tables de routage au niveau système.

Sur le routeur R1 uniquement, on valide la présence des routes par défaut.

R1:~# ip route ls defaultdefault via 192.0.2.1 dev eth0 onlink

R1:~# ip -6 route ls defaultdefault via fe80::dc02:44ff:fe64:4834 dev eth0 metric 1024 onlink pref medium

Q17. Comment valider l'importation des routes par défaut dans les deux démons bird et bird6 ?

L'importation des routes depuis le niveau système dans les démons Bird a été traitée à la Section 6,« Échanger les routes entre Bird et le système ». Ici, on se contente de vérifier la présence des routes pardéfaut au niveau des consoles de chaque démon.

On peut spécifier le préfixe réseau directement dans l'a<ichage de la table de routage de chaque démon.

R1:~# birdc show route 0.0.0.0/0BIRD 1.6.4 ready.0.0.0.0/0 via 192.0.2.1 on eth0 [kernel1 2018-10-27] * (10)

R1:~# birdc6 show route ::/0BIRD 1.6.4 ready.::/0 via fe80::dc02:44ff:fe64:4834 on eth0 [kernel1 2018-10-27] * (10)

Q18. Comment créer les filtres qui serviront à exporter les routes par défaut dans la configuration de chaquedémon pour les protocoles OSPFv2 et OSPFv3 ?

Il faut consulter la documentation BIRD User's Guide aux sections Filters et OSPF pour trouver desexemples de syntaxe.

Voici une copie d'écran pour chaque démon.

R1:~# sed -n '/^filter export_OSPF/,/^}/p' /etc/bird/bird.conffilter export_OSPF { if ( net = 0.0.0.0/0 ) then { ospf_metric2 = 100; accept; } reject;}

R1:~# sed -n '/^filter export_OSPF/,/^}/p' /etc/bird/bird6.conffilter export_OSPF { if ( net = ::/0 ) then { ospf_metric2 = 100; accept; } reject;}

Q19. Comment appliquer les filtres de la question précédente pour que les routes par défaut soient exportéesvia OSPF à destination des autres routeurs ?

Il faut consulter la documentation BIRD User's Guide à la section OSPF et rechercher un exemple de ladirective suivante.

export





Voici une copie d'écran pour chaque démon avec l'exportation dans le processus OSPF en fonction dufiltre défini préalablement.

R1:~# sed -n '/^protocol ospf/,/^}/p' /etc/bird/bird.confprotocol ospf OSPFv2R1 { rfc1583compat yes; ecmp yes; export filter export_OSPF; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

R1:~# sed -n '/^protocol ospf/,/^}/p' /etc/bird/bird6.confprotocol ospf OSPFv3R1 { ecmp yes; export filter export_OSPF; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; };}

Q20. Quelles sont les nouvelles annonces LSA apparues après exportation des routes par défaut depuis R1 versles deux autres routeurs de la topologie triangle ?

À partir du Tableau 12, « Codage des annonces OSPF » donné en début de section, donner le nouveaurôle du routeur R1.

Une fois que l'exportation des routes par défaut dans OSPF est e<ective sur R1, ce routeur devientAutonomous System Border Router ou ASBR. Dès lors, il émet des annonces de type 5 que l'on peutidentifier dans les bases de chaun des trois routeurs de l'aire OSPF.

Par exemple, on obtient les résultats suivants sur le routeur R2.

R2:~# birdc show ospf lsadb type 5BIRD 1.6.4 ready.

Global

Type LS ID Router Sequence Age Checksum 0005 0.0.0.0 0.0.1.4 80000001 1570 afb9

R2:~# birdc6 show ospf lsadb type 5BIRD 1.6.4 ready.

Global

Type LS ID Router Sequence Age Checksum 4005 0.0.0.0 0.0.1.6 80000001 1574 e4c8

Q21. Comment valider l'exportation des routes par défaut depuis les deux démons bird et bird6 vers le niveausystème sur les routeurs R2 et R3 ?

L'exportation des routes depuis les démons Bird vers le système a été traitée à la Section 6, « Échangerles routes entre Bird et le système ». Ici, on se contente de vérifier la présence des routes par défaut auniveau système sur R2 et R3.

Voici une copie d'écran pour le routeur R2 qui caractérise le fait que les routes par défaut ont été apprisesvia Bird.

R2:~# ip route ls defaultdefault via 10.1.12.1 dev eth0.12 proto bird

R2:~# ip -6 route ls defaultdefault via fe80::70de:4fff:fe1d:68b4 dev eth0.12 proto bird metric 1024 pref medium

Si la table de routage du routeur d'accès à Internet contient les routes statiques vers les réseaux de l'aireOSPF, il est possible de lancer les tests ICMP classiques. Voici deux exemples depuis le routeur R2.





R2:~# ping -qc2 2620:fe::fePING 2620:fe::fe(2620:fe::fe) 56 data bytes

--- 2620:fe::fe ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 3msrtt min/avg/max/mdev = 43.986/44.802/45.618/0.816 ms



8. Ajouter des réseaux +ctifs

L'introduction de nouvelles entrées fictives dans les tables de routage est une pratique très répandue. Elle permetde qualifier le bon fonctionnement du filtrage réseau ou d'un service Internet sans ajouter de matériel. Cettesection décrit justement la mise en place d'un service Web de test.

Pour réaliser ces manipulations, on dispose de deux techniques distinctes.

• Historiquement, la première solution consiste à utiliser des interfaces de boucles locales comme sur leséquipements Cisco™ par exemple. Sur un système GNU/Linux les interfaces de type dummy correspondentà cet usage.

Cette solution est satisfaisante du point de vue protocole de routage, mais ces interfaces ne participent pas auroutage sur le système sur lequel elles sont implantées. Elles servent aux annonces émises par les protocolesde routage dynamique.

Ce type d'interface est utilisé sur le routeur R1 dans la Section 9, « Créer des interfaces de type dummy ».

• Avec le recours de plus en plus fréquent à la virtualisation et aux conteneurs, de nouveaux types d'interfacesvirtuelles ont été introduits : tap et veth. Pour simplifier au maximum, les interfaces tap sont des cordons debrassage et les interfaces veth sont des liens point à point qui peuvent être isolés dans un espace de nomsparticulier.

Dans notre contexte, chaque paire d'interfaces veth nous sert à introduire nouveau réseau fictif sans ajouter unseul équipement matériel supplémentaire.

Relativement aux interface de type dummy, l'utilisation d'un lien point à point provoque e<ectivement unedécision de routage au sein du noyau sur lequel ce lien est implanté.

Pour compléter un peu plus le scénario du réseau factice, on peut utiliser les espaces de noms réseau (networknamespaces). Un espace de nom réseau désigne un ensemble d'interfaces associées à une table de routageindépendante. Dans notre contexte, on place une extrémité du lien point à point, c'est à dire une interface veth,dans un espace de nom di<érent.

Cet espace de nom réseau et le type d'interface veth sont utilisés sur les routeurs R2 et R3 dans la Section 10,« Créer des interfaces de type veth ».

9. Créer des interfaces de type dummy

Q22. Comment créer et configurer une interface réseau virtuelle de type dummy ?

Consulter les pages de manuels de la commande ip au niveau liaison man ip-link et rechercher lesinformation sur le type dummy.

Vérifier la présence d'une nouvelle entrée dans la table de routage au niveau système.

Sur le routeur R1, on créé une nouvelle interface avec des adresses appartenant à deux nouveaux préfixesréseau définis les tableaux du plan d'adressage.

# ip link add dummy0 type dummy# ip link set dev dummy0 up# ip addr add 10.1.1.1/29 brd + dev dummy0# ip -6 addr add 2001:678:3fc:b::1/64 dev dummy0

R1:~# ip route ls dev dummy010.1.1.0/29 proto kernel scope link src 10.1.1.1

R1:~# ip -6 route ls dev dummy02001:678:3fc:b::/64 proto kernel metric 256 pref mediumfe80::/64 proto kernel metric 256 pref medium

Q23. Comment publier les deux nouveaux préfixes réseau correspondant à l'interface dummy0 dans l'aire OSPF ?

Il faut activer l'interface dummy0 dans la configuration des deux démons de routage OSPF : bird et bird6.

Il faut consulter la section OSPF du guide BIRD User's Guide. Les instructions utiles pour cette questionsont les suivantes.

interfacestub




La partie OSPFv2 du fichier de configuration sur R1 devient :

R1:~# sed -n '/protocol ospf OSPFv2R1 {/,/^}/p' /etc/bird/bird.confprotocol ospf OSPFv2R1 { rfc1583compat yes; ecmp yes; export filter export_OSPF; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; interface "dummy0" { stub yes; }; };}

Les mêmes instrcutions sont placées dans le fichier de configuration du protocole OSPFv3.

R1:~# sed -n '/protocol ospf OSPFv3R1 {/,/^}/p' /etc/bird/bird6.confprotocol ospf OSPFv3R1 { ecmp yes; export filter export_OSPF; area 0 { interface "eth0.12", "eth0.13" { authentication none; }; interface "dummy0" { stub yes; }; };}

On vérifie ensuite que les entrées sont bien intégrées dans les routes OSPF des deux démons.

R1:~# birdc show route 10.1.1.0/29BIRD 1.6.4 ready.10.1.1.0/29 dev dummy0 [OSPFv2R1 15:03:22] * I (150/10) [0.0.1.4]

R1:~# birdc6 show route 2001:678:3fc:b::/64BIRD 1.6.4 ready.2001:678:3fc:b::/64 dev dummy0 [OSPFv3R1 15:03:28] * I (150/10) [0.0.1.6]

Q24. Comment installer un service Web en écoute exclusivement sur les adresses IPv4 et IPv6 de l'interfacedummy0 ?

Installer le paquet lighttpd et modifier sa configuration pour que le service ne soit accessible que sur lesadresses de l'interface dummy0.

# aptitude install lighttpd<snipped/>

On modifie ensuite le fichier de configuration /etc/lighttpd/lighttpd.conf de façon à limiter l'accès auxadresses voulues.

--- lighttpd.conf.orig 2018-10-15 15:42:12.345480008 +0000+++ lighttpd.conf 2018-10-15 15:43:50.091036311 +0000@@ -22,6 +22,9 @@ compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port-include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port+#include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port include_shell "/usr/share/lighttpd/create-mime.assign.pl" include_shell "/usr/share/lighttpd/include-conf-enabled.pl"++server.bind = "10.1.1.1"+$SERVER["socket"] == "[2001:678:3fc:b::1]:80" { server.use-ipv6 = "enable" }

Après avoir redémarré l'instance de serveur Web, on vérifie que la nouvelle configuration est bien en place.

# systemctl restart lighttpd<snipped># ss -nlt '( src :80 )'State Recv-Q Send-Q Local Address:Port Peer Address:PortLISTEN 0 128 10.1.1.1:80 0.0.0.0:*LISTEN 0 128 [2001:678:3fc:b::1]:80 [::]:*

Q25. Comment valider l'accès à ce service Web depuis les autres réseaux ?



En respectant l'ordre des protocoles de la pile TCP/IP, on commence par valider la connectivité au niveauréseau avant de passer à la couche application.

À partir du routeur R2, on utilise la séquence suivante :

• Test ICMP au niveau réseau :



R2:~# ping -qc2 2001:678:3fc:b::1PING 2001:678:3fc:b::1(2001:678:3fc:b::1) 56 data bytes

--- 2001:678:3fc:b::1 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 2msrtt min/avg/max/mdev = 0.083/0.478/0.873/0.395 ms

• Test HTTP au niveau application :

R2:~# wget -O /dev/null http://10.1.1.1--2018-11-02 15:44:44-- http://10.1.1.1/Connexion à 10.1.1.1:80… connecté.requête HTTP transmise, en attente de la réponse… 200 OKTaille : 3378 (3,3K) [text/html]Sauvegarde en : « /dev/null »

/dev/null 100%[===============================>] 3,30K --.-KB/s ds 0s

2018-11-02 15:44:44 (116 MB/s) — « /dev/null » sauvegardé [3378/3378]

R2:~# wget -O /dev/null http://[2001:678:3fc:b::1]--2018-11-02 15:48:28-- http://[2001:678:3fc:b::1]/Connexion à [2001:678:3fc:b::1]:80… connecté.requête HTTP transmise, en attente de la réponse… 200 OKTaille : 3378 (3,3K) [text/html]Sauvegarde en : « /dev/null »

/dev/null 100%[===============================>] 3,30K --.-KB/s ds 0s


10. Créer des interfaces de type veth

L'introduction d'un nouvel espace de nom réseau revient à introduire une nouvelle table de routage dans unmême système. Dans la vue ci-dessous, le cadre vert illustre les éléments ajoutés au routeur R2 : un lien vers unespace de noms baptisé green avec un serveur web hébergé à l'intérieur.

Les manipulations présentées dans cette section doivent aussi être réalisées sur le routeur R3 en suivant le pland'adressage présenté à la Section 2, « Topologie réseau étudiée ».

Q26. Comment créer une paire d'interfaces réseau virtuelles de type veth sur un système GNU/Linux ?

Rechercher dans les pages de manuels la commande ip link la syntaxe qui permet de créer la paired'interfaces veth0 et veth1.



# ip link add veth1 type veth peer name veth0

# ip link ls dev veth04: veth0@veth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN \ mode DEFAULT group default qlen 1000 link/ether be:04:25:e8:cc:49 brd ff:ff:ff:ff:ff:ff

# ip link ls dev veth15: veth1@veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN \ mode DEFAULT group default qlen 1000 link/ether c2:05:0c:82:35:77 brd ff:ff:ff:ff:ff:ff

Q27. Comment créer un nouvel espace de noms réseau appelé green et a<ecter l'interface veth1 à cet espacede noms ?

Rechercher dans les pages de manuels ip-netns la syntaxe qui permet de créer un nouvel espace de nomsréseau.

# ip netns add green# ip netns lsgreen

L'a<ectation d'une interface à l'espace de noms se fait avec la commande suivante.

# ip link set veth1 netns green

Q28. Comment visualiser et modifier l'état des interfaces de type veth dans les deux espaces de noms réseau ?

Rechercher dans les pages de manuels ip-netns la syntaxe qui permet d'exécuter une commande dansun nouvel espace de noms réseau.

On active les deux interfaces et on a<iche les informations d'état.

# ip link set dev veth0 up

# ip link ls dev veth04: veth0@if5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue \ state LOWERLAYERDOWN mode DEFAULT group default qlen 1000 link/ether d6:63:10:30:b4:da brd ff:ff:ff:ff:ff:ff link-netns green

# ip netns exec green ip link set dev veth1 up

ip netns exec green ip link ls dev veth15: veth1@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue \ state UP mode DEFAULT group default qlen 1000 link/ether be:70:c4:17:19:54 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Q29. Comment valider les communications entre les deux espaces de noms réseau ?

Utiliser les adresses de lien local IPv6 pour faire un test ICMP avec l'adresse multicast de sollicitationd'hôte.

Le test avec la commande ping doit désigner l'interface du lien à utiliser.

# ping -c2 ff02::1%veth0PING ff02::1%veth0(ff02::1%veth0) 56 data bytes64 bytes from fe80::d463:10ff:fe30:b4da%veth0: icmp_seq=1 ttl=64 time=0.062 ms64 bytes from fe80::bc70:c4ff:fe17:1954%veth0: icmp_seq=1 ttl=64 time=0.149 ms (DUP!)64 bytes from fe80::d463:10ff:fe30:b4da%veth0: icmp_seq=2 ttl=64 time=0.058 ms

--- ff02::1%veth0 ping statistics ---2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 27msrtt min/avg/max/mdev = 0.058/0.089/0.149/0.043 ms

Le voisinage réseau de l'interface veth0 désigne l'adresse MAC de l'interface veth1 dans l'espace de nomsréseau green.

# ip nei ls dev veth0fe80::bc70:c4ff:fe17:1954 lladdr be:70:c4:17:19:54 STALE

Réciproquement, le voisinage réseau de l'interface veth1 désigne l'adresse MAC de l'interface veth0.

$ ip netns exec green ip nei ls dev veth1fe80::d463:10ff:fe30:b4da lladdr d6:63:10:30:b4:da router STALE

On peut donc conclure que le lien point à point entre les deux espaces de noms réseau est fonctionnel.



Q30. Comment ajouter deux préfixes réseau IPv4 et IPv6 sur la liaison point à point entre les deux interfacesde type veth ?

Comme lors des étapes précédentes, on reprend les commandes ip avec la désignation de l'espace denoms réseau pour l'interface à l'extrémité du lien point à point.

Dans notre exemple sur le routeur R2, on utilise les préfixes 10.1.2.0/30 et 2001:678:3fc:e::/64.

• Pour l'interface veth0 :

# ip addr add 10.1.2.1/30 brd + dev veth0# ip -6 addr add 2001:678:3fc:e::1/64 dev veth0

• Pour l'interface veth1 :

# ip netns exec green ip addr add 10.1.2.2/30 brd + dev veth1# ip netns exec green ip -6 addr add 2001:678:3fc:e::2/64 dev veth1

Comme dans la question précédente, on peut qualifier la communication entre les deux interfaces auniveau réseau à l'aide de la commande ping.

Voici une copie d'écran des tests e<ectués depuis l'espace de noms green.

# ip netns exec green ping -qc2 10.1.2.1PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.


# ip netns exec green ping -qc2 2001:678:3fc:e::1PING 2001:678:3fc:e::1(2001:678:3fc:e::1) 56 data bytes

--- 2001:678:3fc:e::1 ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 18msrtt min/avg/max/mdev = 0.070/0.112/0.155/0.043 ms

Q31. Comment publier les deux préfixes réseau correspondant à la nouvelle liaison point à point via OSPF ?

Il faut activer l'interface veth dans la configuration des deux démons de routage OSPF : bird et bird6.

Il faut consulter la section OSPF du guide BIRD User's Guide. Les instructions utiles pour cette questionsont les suivantes.

interfacestub

La partie OSPFv2 du fichier de configuration sur R2 devient :

R2:~# sed -n '/protocol ospf OSPFv2R2 {/,/^}/p' /etc/bird/bird.confprotocol ospf OSPFv2R2 { rfc1583compat yes; ecmp yes; area 0 { interface "eth0.12", "eth0.23" { authentication none; }; interface "veth0" { stub yes; }; };}

Les mêmes instrcutions sont placées dans le fichier de configuration du protocole OSPFv3.

R2:~# sed -n '/protocol ospf OSPFv3R2 {/,/^}/p' /etc/bird/bird6.confprotocol ospf OSPFv3R2 { ecmp yes; area 0 { interface "eth0.12", "eth0.23" { authentication none; }; interface "veth0" { stub yes; }; };}




On vérifie ensuite que les entrées sont bien intégrées dans les routes OSPF des deux démons.

R2:~# birdc show route 10.1.2.0/30BIRD 1.6.4 ready.10.1.2.0/30 dev veth0 [OSPFv2R2 13:49:32] * I (150/10) [0.0.2.4]

R2:~# birdc6 show route 2001:678:3fc:e::/64BIRD 1.6.4 ready.2001:678:3fc:e::/64 dev veth0 [OSPFv3R2 13:50:01] * I (150/10) [0.0.2.6]

Q32. Est-ce que les adresses IPv4 et IPv6 situées dans l'espace de noms green joiganbles depuis les réseauxdistants ?

Le fait d'avoir placé l'interface veth1 dans un espace de noms réseau distinct, impose l'utilisation d'unetable de routage propre à cet espace. Sur la base des opérations déjà e<ectuées, on s'interroge sur le faitque ces opérations su<isent pour que les communications soient fonctionnelles.

On fait des tests ICMP et ICMP6 depuis un autre routeur pour constater que si les flux parviennent bien àdestination, il n'existe pas de solution retour.

Dans l'exemple ci-dessous, on teste les communications entre le routeur R1 et l'interface veth1 située audelà du routeur R2

On lance une requête ICMP depuis R1.

R1:~# ping -c3 10.1.2.2PING 10.1.2.2 (10.1.2.2) 56(84) bytes of data.

--- 10.1.2.2 ping statistics ---3 packets transmitted, 0 received, 100% packet loss, time 56ms

On lance l'analyse réseau dans l'espace de noms réseau green.

R2:~# ip netns exec green /usr/bin/tshark -i veth1 -f icmp<snipped/>Capturing on 'veth1' 1 0.000000000 10.1.12.1 → 10.1.2.2 ICMP 98 Echo (ping) request id=0x63c9, seq=1/256, ttl=63 2 1.026937745 10.1.12.1 → 10.1.2.2 ICMP 98 Echo (ping) request id=0x63c9, seq=2/512, ttl=63 3 2.050936173 10.1.12.1 → 10.1.2.2 ICMP 98 Echo (ping) request id=0x63c9, seq=3/768, ttl=63

On relève bien l'arrivée des requêtes à destination. Il n'y a aucune réponse à ces requêtes.

En reprenant le même test avec ICMP6, on relève le même problème.

R1:~# ping -c3 2001:678:3fc:e::2PING 2001:678:3fc:e::2(2001:678:3fc:e::2) 56 data bytes

--- 2001:678:3fc:e::2 ping statistics ---3 packets transmitted, 0 received, 100% packet loss, time 47ms

L'analyse réseau ne montre que l'arrivée des requêtes à destination.

R2:~# ip netns exec green /usr/bin/tshark -i veth1 -f icmp6<snipped/>Capturing on 'veth1' 1 0.000000000 2001:678:3fc:c::1 → 2001:678:3fc:e::2 ICMPv6 118 Echo (ping) request id=0x63d0, seq=1, hop limit=63 2 1.004989685 2001:678:3fc:c::1 → 2001:678:3fc:e::2 ICMPv6 118 Echo (ping) request id=0x63d0, seq=2, hop limit=63 3 2.032992497 2001:678:3fc:c::1 → 2001:678:3fc:e::2 ICMPv6 118 Echo (ping) request id=0x63d0, seq=3, hop limit=63

Q33. Comment compléter les tables de routage IPv4 et IPv6 situées dans l'espace de noms green pour que letrafic initié depuis cet espace soit émis correctement ?

On complète les tables de routage avec une route par défaut pour joindre les réseaux distants depuisl'espace de noms green.

La lecture des tables de routage dans l'espace de noms réseau green explique tout. Ces tables necontiennent que l'entrée relative au lien point à point configuré entre les interfaces veth0 et veth1.

R2:~# ip netns exec green ip route ls10.1.2.0/30 dev veth1 proto kernel scope link src 10.1.2.2

R2:~# ip netns exec green ip -6 route ls2001:678:3fc:e::/64 dev veth1 proto kernel metric 256 pref mediumfe80::/64 dev veth1 proto kernel metric 256 pref medium

Il faut donc compléter ces tables de routage avec une route par défaut vers l'espace de noms réseau pardéfaut dans lequel est située l'interface veth0.



R2:~# ip netns exec green ip route add default via 10.1.2.1

R2:~# ip netns exec green ping -c1 ff02::2%veth1PING ff02::2%veth1(ff02::2%veth1) 56 data bytes64 bytes from fe80::d463:10ff:fe30:b4da%veth1: icmp_seq=1 ttl=64 time=0.099 ms

--- ff02::2%veth1 ping statistics ---1 packets transmitted, 1 received, 0% packet loss, time 0msrtt min/avg/max/mdev = 0.099/0.099/0.099/0.000 ms

R2:~# ip netns exec green ip -6 route add default via fe80::d463:10ff:fe30:b4da dev veth1

Les nouvelles tables de routage de l'espace de noms green font apparaître les routes par défaut

R2:~# ip netns exec green ip route lsdefault via 10.1.2.1 dev veth110.1.2.0/30 dev veth1 proto kernel scope link src 10.1.2.2

R2:~# ip netns exec green ip -6 route ls2001:678:3fc:e::/64 dev veth1 proto kernel metric 256 pref mediumfe80::/64 dev veth1 proto kernel metric 256 pref mediumdefault via fe80::d463:10ff:fe30:b4da dev veth1 metric 1024 pref medium

Les tests ICMP et ICMP6 de la question précédente montrent maintenant que les communications sontbien fonctionnelles. Les requêtes sont à nouveau émises depuis le routeur R1



R1:~# ping -qc3 2001:678:3fc:e::2PING 2001:678:3fc:e::2(2001:678:3fc:e::2) 56 data bytes

--- 2001:678:3fc:e::2 ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 55msrtt min/avg/max/mdev = 0.089/0.319/0.778/0.324 ms

Q34. Comment installer un service Web en écoute exclusivement sur les adresses IPv4 et IPv6 situées dansl'espace de noms réseau green ?

Pour aller au plus court, on installe le paquet lighttpd et on édite la configuration du service de façon àlimiter l'accès aux adresses IP voulues.

R2:~# aptitude install lighttpd

On modifie ensuite le fichier de configuration /etc/lighttpd/lighttpd.conf de façon à limiter l'accès auxadresses IPv4 et IPv6 de l'interface veth1.

Voici une copie du correctif correspondant au routeur R2.

--- /etc/lighttpd/lighttpd.conf.orig 2018-11-04 14:29:00.700077032 +0000+++ /etc/lighttpd/lighttpd.conf 2018-11-04 14:29:38.568699677 +0000@@ -22,6 +22,9 @@ compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port-include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port+#include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port include_shell "/usr/share/lighttpd/create-mime.assign.pl" include_shell "/usr/share/lighttpd/include-conf-enabled.pl"++server.bind = "10.1.2.2"+$SERVER["socket"] == "[2001:678:3fc:e::2]:80" { server.use-ipv6 = "enable" }

Relativement à une configuration classique, il faut lancer le serveur Web dans le contexte du nouvel espacede noms réseau. On commence donc par arrêter le démon lancé lors de l'installation du paquet.

R2:~# systemctl stop lighttpd

Là encore, pour aller au plus court on lance directement le démon dans le contexte de l'espace de nomsréseau green.



R2:~# ip netns exec green lighttpd -f /etc/lighttpd/lighttpd.conf

R2:~# ip netns exec green ss -nlt '( src :80 )'State Recv-Q Send-Q Local Address:Port Peer Address:PortLISTEN 0 128 10.1.2.2:80 0.0.0.0:*LISTEN 0 128 [2001:678:3fc:e::2]:80 [::]:*

Q35. Comment valider l'accès au service Web situé dans l'espace de noms réseau green depuis un réseaudistant ?

Comme la partie routage a été validée dans les questions précédentes, on passe directement à la coucheapplication avec le chargement de la page Web par défaut du serveur.

Depuis le routeur R1, on obtient le résultat suivant :

R1:~# wget -O /dev/null http://10.1.2.2--2018-11-04 14:34:37-- http://10.1.2.2/Connexion à 10.1.2.2:80… connecté.requête HTTP transmise, en attente de la réponse… 200 OKTaille : 3378 (3,3K) [text/html]Sauvegarde en : « /dev/null »

/dev/null 100%[=========================>] 3,30K --.-KB/s ds 0s


R1:~# wget -O /dev/null http://[2001:678:3fc:e::2]--2018-11-04 14:35:45-- http://[2001:678:3fc:e::2]/Connexion à [2001:678:3fc:e::2]:80… connecté.requête HTTP transmise, en attente de la réponse… 200 OKTaille : 3378 (3,3K) [text/html]Sauvegarde en : « /dev/null »

/dev/null 100%[==========================>] 3,30K --.-KB/s ds 0s

2018-11-04 14:35:45 (16,8 MB/s) — « /dev/null » sauvegardé [3378/3378]



11. E9ectuer les manipulations sur machines virtuelles

Il est possible de réaliser l'ensemble des manipulations de ce support à l'aide de trois machines virtuelles et ducommutateur Open vSwitch. Dans la figure ci-dessous, le routeur baptisé ISP correspond au système hôte surlequel les systèmes virtuels sont exécutés.

Tableau 13. A<ectation des rôles, des numéros de VLANs et des adresses IP

Routeur OSPF router-id VLAN Interface Réseau

192.0.2.9/27

0 eth02001:678:3fc:a::9/64

10.0.12.1/26

12 eth0.122001:678:3fc:c::1/64

10.0.13.1/26

13 eth0.132001:678:3fc:d::1/64

10.1.1.1/29

R1OSPFv2 -> 0.0.1.4

OSPFv3 -> 0.0.1.6

- dummy02001:678:3fc:b::1/64

10.1.21.2/26

12 eth0.122001:678:3fc:c::2/64

10.1.23.2/26

23 eth0.232001:678:3fc:17::2/64

10.1.2.1/30 -> 10.1.2.2/30

R2OSPFv2 -> 0.0.2.4

OSPFv3 -> 0.0.2.6

- veth0:veth12001:678:3fc:e::1/64 -> 2001:678:3fc:e::2/64

10.1.13.3/26

13 eth0.132001:678:3fc:d::3/64

10.1.23.3/26

23 eth0.232001:678:3fc:17::3/64

10.1.3.1/30 -> 10.1.3.2/30

R3OSPFv2 -> 0.0.3.4

OSPFv3 -> 0.0.3.6

- veth0:veth12001:678:3fc:f::1/64 -> 2001:678:3fc:f::2/64


http://openvswitch.org


11.1. Préparation du commutateur Open vSwitch

Vu du système hôte, on met en place la structure du graphique suivant.

On se réfère au guide Virtualisation système et enseignement dans lequel le lancement du commutateur virtuelOpen vSwitch est intégré à la configuration du système hôte. Voici un extrait du fichier /etc/network/interfacesrelatif à la configuration du commutateur dsw-host.

# The primary network interfaceallow-ovs dsw-hostiface dsw-host inet manual ovs_type OVSBridge ovs_ports eth0 vlan1

allow-dsw-host vlan1iface vlan1 inet static address 192.0.2.11/26 gateway 192.0.2.1 ovs_type OVSIntPort ovs_bridge dsw-host dns-nameservers 192.0.2.1

allow-dsw-host eth0iface eth0 inet manual up ip link set dev $IFACE up down ip link set dev $IFACE down ovs_bridge dsw-host ovs_type OVSPort ovs_options vlan_mode=access

Dans cette configuration, vlan1 est l'interface principale du système hôte. Elle sert à la fois au routage et à l'accèsaux instances de machines virtuelles depuis les autres réseaux.

La configuration de départ du commutateur sur le système hôte est la suivante :

$ sudo ovs-vsctl show0fb1e80b-37cf-4dce-9a19-17b9fb989610 Bridge dsw-host Port "eth0" Interface "eth0" Port "vlan1" Interface "vlan1" type: internal Port dsw-host Interface dsw-host type: internal ovs_version: "2.3.0"

Partant de cette configuration de départ, on créé 3 cordons de brassage ; un par routeur. On dispose d'un scriptpour répéter les opérations de base.

#!/bin/bash

for patchtap in $*do if [ -z "$(ip link ls | grep $patchtap)" ]; then echo setting $patchtap up sudo ip tuntap add mode tap dev $patchtap group kvm multi_queue sudo ip link set dev $patchtap up else echo $patchtap is already there! fidone

Avec cet outil, la création des cordons s'e<ectue comme suit :

$ sh ./patchcables.sh tap1 tap2 tap3


https://inetdoc.net/guides/vm/



Maintenant que les cordons sont disponibles, il faut les brasser sur le commutateur dsw-host. L'opération ci-dessous créé trois nouveaux ports sur le commutateur.

$ for port in tap1 tap2 tap3; do sudo ovs-vsctl add-port dsw-host $port; done

Pour respecter la topologie physique proposée dans l'énoncé, ces trois ports doivent être configurés en modetrunkde façon à ce que chaque routeur puisse router les VLANs qui le concernent. Avec Open vSwitch, lesparamètres de configuration sont les suivants :

$ sudo ovs-vsctl set port tap1 vlan_mode=trunk trunks=0,12,13$ sudo ovs-vsctl set port tap2 vlan_mode=trunk trunks=12,23$ sudo ovs-vsctl set port tap3 vlan_mode=trunk trunks=13,23

Note

La particularité du commutateur Open vSwitch est d'utiliser le numéro 0 comme VLAN par défaut. Dansnotre cas, ce VLAN 0 devient le VLAN natif dans lequel circulent les trames sans étiquettes IEEE802.1Q.

On aboutit à la représentation graphique suivante :

La table de correspondance entre VLAN et liaison devient :

VLAN numéro 0 Liaison R1 <-> ISP

VLAN numéro 12 Liaison R1 <-> R2



Une fois que les opérations des sections suivantes auront été e<ectuées, la consultation de la table CAM ducommutateur donnera les informations suivantes :

$ sudo ovs-appctl fdb/show dsw-host[sudo] password for latu: port VLAN MAC Age 11 12 ba:ad:ca:fe:00:02 10 12 23 ba:ad:ca:fe:00:03 9 12 13 ba:ad:ca:fe:00:03 9 10 13 ba:ad:ca:fe:0d:01 9 10 12 ba:ad:ca:fe:0c:01 4 11 23 ba:ad:ca:fe:00:02 1 1 0 de:56:80:40:1d:ed 0 2 0 42:d9:5d:6c:89:d8 0

11.2. Préparation des routeurs

Sachant que l'on dispose d'une image master sur laquelle est installée un système Debian GNU/Linux de base,on créé 3 images di<érentielles qui vont correspondre aux instances de routeurs. Voici un exemple de suite decommandes pour la mise en place des images.





:~$ mkdir -p ~/vm/ospf:~$ cd vm:~/vm$ wget http://www.stri/vm/vm0-debian-testing-i386-base.qed<snipped/>:~/vm$ cd ospf:~/vm/ospf$ ../scripts/diff-img.sh ../vm0-debian-testing-i386-base.qed r1.qed:~/vm/ospf$ ../scripts/diff-img.sh ../vm0-debian-testing-i386-base.qed r2.qed:~/vm/ospf$ ../scripts/diff-img.sh ../vm0-debian-testing-i386-base.qed r3.qed

Le code du script de création de fichier image di<érentiel est fourni dans le guide Virtualisation système etenseignement.

Ensuite, on créé un nouveau script shell de lancement des instances de «routeurs» dans lequel on fixe lesparamètres d'initialisation de ces mêmes «routeurs».

Avertissement

Ce script ne doit être lancé qu'après l'initialisation du commutateur virtuel pour que le brassage desrouteurs sur les ports du commutateur puisse se faire correctement.

$ cd ~/vm/ospf$ cat ospf-startup.sh #!/bin/bash

../scripts/ovs-startup.sh r1.qed 512 1



11.3. Table de routage du système hôte

Pour que les réseaux de l'aire OSPF puissent communiquer avec le système hôte et l'Internet, il est nécessaire decompléter la table de routage du système hôte. La technique usuelle employée pour répondre au besoin consisteà implanter une route statique avec un «super réseau» qui rassemble tous les réseaux de l'aire en une seule entrée.

L'aire OSPF étudiée contient tous les réseaux du Tableau 13, « A<ectation des rôles, des numéros de VLANs etdes adresses IP ». L'utilisation de l'outil ipcalc permet de vérifier qu'un masque de 19 bits permet d'englober cesréseaux en une seule entrée.

$ ipcalc 10.1.0.0/19Address: 10.1.0.0 00001010.00000001.000 00000.00000000Netmask: 255.255.224.0 = 19 11111111.11111111.111 00000.00000000Wildcard: 0.0.31.255 00000000.00000000.000 11111.11111111=>Network: 10.1.0.0/19 00001010.00000001.000 00000.00000000HostMin: 10.1.0.1 00001010.00000001.000 00000.00000001HostMax: 10.1.31.254 00001010.00000001.000 11111.11111110Broadcast: 10.1.31.255 00001010.00000001.000 11111.11111111Hosts/Net: 8190 Class A, Private Internet

On complète donc la table de routage du système hôte avec l'instruction suivante :

# ip route add 10.1.0.0/19 via 192.0.2.10


https://inetdoc.net/guides/vm/vm.appendix-diff-img.html




12. Consulter les documents de référence

Architecture réseau des travaux pratiques

Le support Architecture réseau des travaux pratiques présente la topologie physique des salles de travauxpratiques avec la Disposition des équipements dans l'armoire de brassage ainsi que les configurations pardéfaut des équipements. On y trouve aussi le plan d'adressage IP utilisé avec les autres supports de travauxpratiques, le plan de numérotations des VLANs et les a<ectations des groupes de ports des commutateurs.

Configuration d'une interface réseau

Le support Configuration d'une interface de réseau local présente les opérations de configuration d'uneinterface réseau et propose quelques manipulations sur les protocoles de la pile TCP/IP

Introduction au routage inter-VLAN

Le support Routage Inter-VLAN introduit le principe du routage inter-VLAN ainsi que ses conditionsd'utilisation. C'est aussi un support de travaux pratiques dans lequel on n'utilise que du routage statique etde la traduction d'adresses sources (S-NAT) pour acheminer le trafic utilisateur entre les di<érents réseaux.

Virtualisation système et enseignement

Le support Virtualisation système et enseignement présente la solution de virtualisation intégrée au noyauLinux : KVM. Associée au commutateur Open vSwitch, cette solution permet de construire des maquettesde travaux pratiques très complètes en o<rant de nombreuses fonctions réseau «réelles» dont une tableContent-addressable memory.



https://inetdoc.net/travaux_pratiques/infra.tp/infra.tp.interco.html#infra.tp.interco.cabling

https://inetdoc.net/travaux_pratiques/config.interface.lan/




https://en.wikipedia.org/wiki/Content-addressable_memory

Documents

Introduction au routage dynamique OSPF avec BirdIntroduction au routage dynamique OSPF avec Bird 2.1. Plan d'adressage salle 211 Tableau#2.#A