---
# System prepended metadata

title: R201 - TP5 - Routage OSPF et RIP - redistribution de routes
tags: [Routage, RIPv2, OSPF]

---

# Nohan VIOT et Théo RIVIÈRE

## R201 - TP5 Routage OSPF et RIP - redistribution de routes

### Plan d’adressage VLSM du réseau
Pour le LAN 1, LAN 2, LAN 3, WAN 1, nous avons a disposition l'espace d'adressage suivant : **172.22.32.0 /19**

En utilisant la technique du VLSM nous obtenons le tableau suivant : 

| Nom du réseau      | @ Réseau     | Plage d'adresse             | @ de broadcast | Masque de sous-réseau  |
| ------------------ | ------------ | --------------------------- | -------------- | ---------------------- |
| LAN 1 (2000 hôtes) | 172.22.32.0  | 172.22.32.1 - 172.22.39.254 | 172.22.39.255  | 255.255.248.0   (/21)  |
| LAN 2 (800 hôtes)  | 172.22.40.0  | 172.22.40.1 - 172.22.43.254 | 172.22.43.255  | 255.255.252.0   (/22)  |
| LAN 3 (62 hôtes)   | 172.22.44.0  | 172.22.44.1 - 172.22.44.62  | 172.22.44.63   | 255.255.255.192 (/26)  |
| WAN 1 (2 hôtes)    | 172.22.44.64 | 172.22.44.65 - 172.22.44.66 | 172.22.44.67   | 255.255.255.252 (/30)  |

Par la suite, pour les LAN 4, LAN 5, LAN 6 et WAN 2, nous utilisons l'espace d'adressage **10.12.32.0 /24**

En utilisant la technique du VLSM, nous obtenons le tableau suivant : 

| Nom du réseau      | @ Réseau     | Plage d'adresse             | @ de broadcast | Masque de sous-réseau  |
| ------------------ | ------------ | --------------------------- | -------------- | ---------------------- |
| LAN 4 (64 hôtes)   | 10.12.32.0   | 10.12.32.1 - 10.12.32.126   | 10.12.32.127   | 255.255.255.128 (/25)  |
| LAN 5 (60 hôtes)   | 10.12.32.128 | 10.12.32.129 - 10.12.32.190 | 10.12.32.191   | 255.255.255.192 (/26)  |
| LAN 6 (28 hôtes)   | 10.12.32.192 | 10.12.32.193 - 10.12.32.222 | 10.12.32.223   | 255.255.255.224 (/27)  |
| WAN 2 (2 hôtes)    | 10.12.32.224 | 10.12.32.225 - 10.12.32.226 | 10.12.32.227   | 255.255.255.252 (/30)  |


## Schéma Topologique du réseau

:::info
La convention adoptée pour l'adressage des LAN est la suivante : 
* la 1ère adresse d'hôte disponible sera attribuée à l'interface des PC
* la dernière adresse d'hôte disponible sera attribuée à l'interface des routeurs
* pour les réseaux étendus, la 1ère adresse d'hôte disponible sera attribuée à l'interface du routeur jouant le rôle de DCE
:::

![topo1](https://hackmd.io/_uploads/r1wGmR-eA.png)
Tableau de la topologie

![topo](https://hackmd.io/_uploads/H1f7X0ZgC.png)
Schéma de la topologie


## Configuration des routeurs

Pour la configuration de base de R1 : 
```
en
erase startup-config
reload

en
conf t
hostname R1
no ip domain-lookup
int Gi0/0
ip address 193.0.0.254 255.255.255.0
no shutdown
int lo1
ip address 172.22.32.1 255.255.248.0
no shutdown
int s0/0/0
clock rate 128000
ip address 172.22.44.65 255.255.255.252
no shutdown
end
sh ip int br
```

Pour la configuration de base de R2 : 
```
en
erase startup-config
reload

en
conf t
hostname R2
no ip domain-lookup
int Gi0/0
ip address 172.22.44.62 255.255.255.192
no shutdown
int lo2
ip address 172.22.40.1 255.255.252.0
no shutdown
int s0/0/0
ip address 172.22.44.66 255.255.255.252
no shutdown
int s0/0/1
clock rate 128000
ip address 10.12.32.225 255.255.255.252
no shutdown

end
sh ip int br
```

Pour la configuration de base de R3 : 
```
en
erase startup-config
reload

en
conf t
hostname R3
no ip domain-lookup
int Gi0/0
ip address 10.12.32.222 255.255.255.224
no shutdown
int lo4
ip address 10.12.32.1 255.255.255.128
no shutdown
int lo5
ip address 10.12.32.129 255.255.255.192
no shutdown
int s0/1/1
ip address 10.12.32.226 255.255.255.252
no shutdown

end
sh ip int br
```

### Schéma de la topologie avec les fonctions de routage

![topo_routage](https://hackmd.io/_uploads/BylHVR-x0.png)

## Routage RIPv2

Configuration du protocole RIPv2 sur R2 : 
```
conf t
router rip
version 2
passive-interface lo2
passive-interface Gi0/0
network 10.12.32.0
```

Configuration du protocole RIPv2 sur R3 : 
```
conf t
router rip
version 2
passive-interface lo4
passive-interface lo5
passive-interface Gi0/0
network 10.12.32.0
```

Il n'y aura pas de routes découvertes par RIP dans le table de R3 car il ne dispose que de routes directement connectées.

La désactivation du résumé automatique de route n'est pas nécessaire dans une topologie de routage RIPv2 lorsque tous les réseaux à annoncer sont des sous-réseaux d'une adresse IP principale configurée sur une interface de routeur.

On vérifie les connectivités entre les hôtes de la zone de routage RIP à l'aide de ping : 

```
root@debian:~# ping 10.12.32.129 -c 4
PING 10.12.32.129 (10.12.32.129) 56(84) bytes of data.
64 bytes from 10.12.32.129: icmp_seq=1 ttl=255 time=2.01 ms
64 bytes from 10.12.32.129: icmp_seq=2 ttl=255 time=2.26 ms
64 bytes from 10.12.32.129: icmp_seq=3 ttl=255 time=1.56 ms
64 bytes from 10.12.32.129: icmp_seq=4 ttl=255 time=1.54 ms

--- 10.12.32.129 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.541/1.843/2.264/0.306 ms


root@debian:~# ping 10.12.32.1 -c 4
PING 10.12.32.1 (10.12.32.1) 56(84) bytes of data.
64 bytes from 10.12.32.1: icmp_seq=1 ttl=255 time=1.86 ms
64 bytes from 10.12.32.1: icmp_seq=2 ttl=255 time=1.78 ms
64 bytes from 10.12.32.1: icmp_seq=3 ttl=255 time=1.53 ms
64 bytes from 10.12.32.1: icmp_seq=4 ttl=255 time=1.64 ms

--- 10.12.32.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.532/1.700/1.856/0.124 ms


root@debian:~# ping 10.12.32.225 -c 4
PING 10.12.32.225 (10.12.32.225) 56(84) bytes of data.
64 bytes from 10.12.32.225: icmp_seq=1 ttl=254 time=3.39 ms
64 bytes from 10.12.32.225: icmp_seq=2 ttl=254 time=2.41 ms
64 bytes from 10.12.32.225: icmp_seq=3 ttl=254 time=2.71 ms
64 bytes from 10.12.32.225: icmp_seq=4 ttl=254 time=2.29 ms

--- 10.12.32.225 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 2.285/2.699/3.388/0.426 ms

```


## Routage OSPF

:::info
Une interface de loopback est considérée comme l’adresse d’un hôte et est donc annoncée en /32 par OSPF, quelle que soit le masque indiqué avec l’adresse IP. Si on veut que le masque soit pris en compte dans OSPF on doit rajouter la commande ```ip ospf network point-to-point```.
:::

Avant de commencer à écrire la configuration des routeurs, on va adopter une convention pour les routeurs-id, qui est la suivante : 
- R1 : 1.1.1.1
- R2 : 2.2.2.2

Ensuite pour le routeur R1, pour accéder à internet, on créer une route par défaut (0.0.0.0 0.0.0.0 Gi0/0), il ne faudra pas oublier de la diffuser aux autres routeurs à l'aide de la commande : ```default-information originate```.

Configuration du protocole OSPF sur R1 : 
```
conf t
ip route 0.0.0.0 0.0.0.0 Gi0/0
int lo1
ip ospf network point-to-point
exit
router ospf 1
router-id 1.1.1.1
passive-interface Gi0/0
passive-interface lo1
network 172.22.0.0 0.0.255.255 area 0
default-information originate
```

Configuration du protocole OSPF sur R2 : 
```
conf t
int lo2
ip ospf network point-to-point
exit
router ospf 1
router-id 2.2.2.2
passive-interface Gi0/0
passive-interface lo2
network 172.22.0.0 0.0.255.255 area 0
```

:::danger
Pour désactiver le SLARP (Serial Line Address Resolution Protocol), il faut faire un 'no ip addr'
:::

### Table de routage

Table de routage de R1 : 

```
S*    0.0.0.0/0 is directly connected, GigabitEthernet0/0
      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
O E2     10.12.32.0/25 [110/1] via 172.22.44.66, 00:00:30, Serial0/0/0
O E2     10.12.32.128/26 [110/1] via 172.22.44.66, 00:00:30, Serial0/0/0
O E2     10.12.32.192/27 [110/1] via 172.22.44.66, 00:00:30, Serial0/0/0
O E2     10.12.32.224/30 [110/1] via 172.22.44.66, 00:00:30, Serial0/0/0
      172.22.0.0/16 is variably subnetted, 6 subnets, 5 masks
C        172.22.32.0/21 is directly connected, Loopback1
L        172.22.32.1/32 is directly connected, Loopback1
O        172.22.40.0/22 [110/65] via 172.22.44.66, 00:28:43, Serial0/0/0
O        172.22.44.0/26 [110/74] via 172.22.44.66, 00:19:34, Serial0/0/0
C        172.22.44.64/30 is directly connected, Serial0/0/0
L        172.22.44.65/32 is directly connected, Serial0/0/0
      193.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        193.0.0.0/24 is directly connected, GigabitEthernet0/0
L        193.0.0.254/32 is directly connected, GigabitEthernet0/0
```

```
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:37    172.22.44.66    Serial0/0/0
```

Table de routage de R2 : 
```
O*E2  0.0.0.0/0 [110/1] via 172.22.44.65, 00:28:26, Serial0/0/0
      10.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
R        10.12.32.0/25 [120/1] via 10.12.32.226, 00:00:03, Serial0/0/1
R        10.12.32.128/26 [120/1] via 10.12.32.226, 00:00:03, Serial0/0/1
R        10.12.32.192/27 [120/1] via 10.12.32.226, 00:00:03, Serial0/0/1
C        10.12.32.224/30 is directly connected, Serial0/0/1
L        10.12.32.225/32 is directly connected, Serial0/0/1
      172.22.0.0/16 is variably subnetted, 7 subnets, 5 masks
O        172.22.32.0/21 [110/65] via 172.22.44.65, 00:28:26, Serial0/0/0
C        172.22.40.0/22 is directly connected, Loopback2
L        172.22.40.1/32 is directly connected, Loopback2
C        172.22.44.0/26 is directly connected, GigabitEthernet0/0
L        172.22.44.62/32 is directly connected, GigabitEthernet0/0
C        172.22.44.64/30 is directly connected, Serial0/0/0
L        172.22.44.66/32 is directly connected, Serial0/0/0
```

```
Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:31    172.22.44.65    Serial0/0/0
```

Table de routage de R3 : 
```
R*    0.0.0.0/0 [120/1] via 10.12.32.225, 00:00:13, Serial0/0/1
      10.0.0.0/8 is variably subnetted, 8 subnets, 5 masks
C        10.12.32.0/25 is directly connected, Loopback4
L        10.12.32.1/32 is directly connected, Loopback4
C        10.12.32.128/26 is directly connected, Loopback5
L        10.12.32.129/32 is directly connected, Loopback5
C        10.12.32.192/27 is directly connected, GigabitEthernet0/0
L        10.12.32.222/32 is directly connected, GigabitEthernet0/0
C        10.12.32.224/30 is directly connected, Serial0/0/1
L        10.12.32.226/32 is directly connected, Serial0/0/1
R     172.22.0.0/16 [120/1] via 10.12.32.225, 00:00:13, Serial0/0/1
```

:::success
Les adjacences et les routes ont bien été apprises par OSPF.
:::

**O**: signifie OSPF, ce qui indique que la route est apprise via le protocole OSPF.

**E2** : Ce symbole indique le type de route au sein de l'OSPF. E2 signifie route OSPF externe de type 2. Les routes externes OSPF sont utilisées pour représenter les routes qui ont été redistribuées dans OSPF à partir d'autres protocoles de routage ou de routes statiques.

Une route E2, en particulier, signifie que la métrique utilisée pour déterminer la route reste constante, quel que soit le coût interne de l'OSPF pour atteindre l'ASBR (Autonomous System Boundary Router). Cela contraste avec une route E1, où la métrique inclut à la fois le coût externe et le coût interne OSPF pour atteindre l'ASBR.

**O*E2** indique donc une route OSPF **externe** de **type 2** préférée dans la table de routage.


On va à présent vérifier les connectivités entre les hôtes de la zone de routage OSPF, à l'aide de ping : 

```
root@debian:~# ping 172.22.32.1 -c 4
PING 172.22.32.1 (172.22.32.1) 56(84) bytes of data.
64 bytes from 172.22.32.1: icmp_seq=2 ttl=254 time=2.37 ms
64 bytes from 172.22.32.1: icmp_seq=3 ttl=254 time=2.34 ms
64 bytes from 172.22.32.1: icmp_seq=4 ttl=254 time=2.27 ms

--- 172.22.32.1 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.273/2.324/2.366/0.038 ms


root@debian:~# ping 172.22.40.1 -c 4
PING 172.22.40.1 (172.22.40.1) 56(84) bytes of data.
64 bytes from 172.22.40.1: icmp_seq=1 ttl=255 time=1.69 ms
64 bytes from 172.22.40.1: icmp_seq=2 ttl=255 time=1.51 ms
64 bytes from 172.22.40.1: icmp_seq=3 ttl=255 time=1.55 ms
64 bytes from 172.22.40.1: icmp_seq=4 ttl=255 time=1.54 ms

--- 172.22.40.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3007ms
rtt min/avg/max/mdev = 1.507/1.572/1.694/0.072 ms
```

:::success
Les tests sont concluants, les hôtes de la zone de routage OSPF communiquent bien ensemble.
:::

## Synthèse des tests de connectivités

Actuellement, un PC configuré dans LAN 3 (172.22.44.0/26) ne peut pas communiquer avec un PC dans LAN 6 (10.12.32.192/27) dans la configuration actuelle.

### Problème de Communication Inter-protocoles

Les deux protocoles de routage (OSPF et RIPv2) ne sont pas redistribués entre eux. Cela signifie que :
- Routes OSPF (sur R1 et R2) ne sont pas connues par R3.
- Routes RIP (sur R2 et R3) ne sont pas connues par R1.

### Routes Connues par Chaque Routeur
- R1 connaît les réseaux : 172.22.32.0/21 (LAN 1) et 172.22.44.0/26 (LAN 3) via OSPF.
- R2 connaît les réseaux : 172.22.32.0/21 (LAN 1), 172.22.44.0/26 (LAN 3), 172.22.40.0/22 (LAN 2) via OSPF, et 10.12.32.0/25 (LAN 4), 10.12.32.128/26 (LAN 5), 10.12.32.192/27 (LAN 6) via RIP.
- R3 connaît les réseaux : 10.12.32.0/25 (LAN 4), 10.12.32.128/26 (LAN 5), 10.12.32.192/27 (LAN 6) via RIP.

### Impact de la Non-redistribution
- R3 ne connaît pas le réseau 172.22.44.0/26 (LAN 3) car il n'y a pas de redistribution des routes OSPF vers RIP sur R2.
- R2 ne redistribue pas les routes RIP vers OSPF, donc R1 ne connaît pas les réseaux 10.12.32.0/25, 10.12.32.128/26, et 10.12.32.192/27.

Autre problème, un PC configuré dans le LAN 6 (10.12.32.192/27) ne peut pas communiquer avec le serveur WEB dans la configuration actuelle.

### Problème de route par défaut

Le protocole OSPF n'étant toujours redistibué, la route par défaut n'est pas transmise à R3.
- R3 ne connaît donc pas la route par défaut à emprunter.

## Redistribution de routes

### Redistribution de routes RIP à partir de OSPF

Afin que que le routeur R2 soit capable de redistribuer les routes apprises avec RIP dans la zone OSPF. On utilise la commande : ```redistribute rip subnets``` : 

On regarde la table de routage de R2 après avoir rentrée la commande : 

```
Gateway of last resort is 172.22.44.65 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 172.22.44.65, 01:10:51, Serial0/0/0
      10.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
R        10.12.32.0/25 [120/1] via 10.12.32.226, 00:00:00, Serial0/0/1
R        10.12.32.128/26
           [120/1] via 10.12.32.226, 00:00:00, Serial0/0/1
R        10.12.32.192/27
           [120/1] via 10.12.32.226, 00:00:00, Serial0/0/1
C        10.12.32.224/30 is directly connected, Serial0/0/1
L        10.12.32.225/32 is directly connected, Serial0/0/1
      172.22.0.0/16 is variably subnetted, 7 subnets, 5 masks
O        172.22.32.0/21 [110/2] via 172.22.44.65, 01:10:51, Serial0/0/0
C        172.22.40.0/22 is directly connected, Loopback2
L        172.22.40.1/32 is directly connected, Loopback2
C        172.22.44.0/26 is directly connected, GigabitEthernet0/0
L        172.22.44.62/32 is directly connected, GigabitEthernet0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.66/32 is directly connected, GigabitEthernet0/1
```

:::success
La table de routage de R2 montre que les réseaux RIP suivants sont appris via RIP avec une métrique de 1 :

- 10.12.32.0/25
- 10.12.32.128/26
- 10.12.32.192/27
- 10.12.32.224/30
:::

Table de routage de R1 : 

```

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, GigabitEthernet0/0
      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
O E2     10.12.32.0/25 [110/20] via 172.22.44.66, 00:04:48, Serial0/0/0
O E2     10.12.32.128/26
           [110/20] via 172.22.44.66, 00:04:48, Serial0/0/0
O E2     10.12.32.192/27
           [110/20] via 172.22.44.66, 00:04:48, Serial0/0/0
O E2     10.12.32.224/30
           [110/20] via 172.22.44.66, 00:04:48, Serial0/0/0
      172.22.0.0/16 is variably subnetted, 6 subnets, 5 masks
C        172.22.32.0/21 is directly connected, Loopback1
L        172.22.32.1/32 is directly connected, Loopback1
O        172.22.40.0/22 [110/2] via 172.22.44.66, 01:15:31, Serial0/0/0
O        172.22.44.0/26 [110/2] via 172.22.44.66, 01:15:31, Serial0/0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.65/32 is directly connected, GigabitEthernet0/1
      193.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        193.0.0.0/24 is directly connected, GigabitEthernet0/0
L        193.0.0.254/32 is directly connected, GigabitEthernet0/0
```

:::success
La table de routage de R1 montre que ces réseaux sont redistribués dans OSPF avec un coût de 20 :

- 10.12.32.0/25 [110/20]
- 10.12.32.128/26 [110/20]
- 10.12.32.192/27 [110/20]
- 10.12.32.224/30 [110/20]
:::

### Préfixes et Métriques

**Préfixe Utilisé**
Les réseaux appris via RIP sont redistribués dans OSPF avec le préfixe **E2 (External Type 2)**.

**Valeur de la Métrique**
Les routes redistribuées apparaissent avec une métrique de **20** dans OSPF.

### Coût Réel et Comparaison

**Coût Réel avec OSPF**
Pour calculer le coût réel si OSPF avait été utilisé sur toute la route, nous devons additionner les coûts des liens basés sur les valeurs de coût d'OSPF.

- **Lien R1 à R2 (172.22.44.64/30)**:
    - Coût OSPF par défaut pour une liaison série : 64
- **Lien R2 à R3 (10.12.32.224/30)**:
    - Coût OSPF par défaut pour une liaison série : 64

Le coût total pour atteindre les réseaux de R3 à partir de R1 en utilisant uniquement OSPF serait la somme des coûts des deux liaisons : 

**Coût total = 64 + 64 = 128**

Donc la métrique OSPF de 20 pour les routes redistribuées de RIP ne reflète pas le coût réel si OSPF avait été utilisé sur toute la route. Le coût de 20 est beaucoup plus bas que le coût réel de 128.

### Autre méthode

Une autre méthode pour que R2 redistribue les routes apprises par RIP dans la zone OSPF est d'utiliser la commande suivante : **```redistribute rip metric-type 1 subnets```**

Table de routage de R2 avec l'usage de la nouvelle méthode : 

```

Gateway of last resort is 172.22.44.65 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 172.22.44.65, 01:26:20, Serial0/0/0
      10.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
R        10.12.32.0/25 [120/1] via 10.12.32.226, 00:00:22, Serial0/0/1
R        10.12.32.128/26
           [120/1] via 10.12.32.226, 00:00:22, Serial0/0/1
R        10.12.32.192/27
           [120/1] via 10.12.32.226, 00:00:22, Serial0/0/1
C        10.12.32.224/30 is directly connected, Serial0/0/1
L        10.12.32.225/32 is directly connected, Serial0/0/1
      172.22.0.0/16 is variably subnetted, 7 subnets, 5 masks
O        172.22.32.0/21 [110/2] via 172.22.44.65, 01:26:20, GigabitEthernet0/1
C        172.22.40.0/22 is directly connected, Loopback2
L        172.22.40.1/32 is directly connected, Loopback2
C        172.22.44.0/26 is directly connected, GigabitEthernet0/0
L        172.22.44.62/32 is directly connected, GigabitEthernet0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.66/32 is directly connected, GigabitEthernet0/1
```

Table de routage de R1 : 

```
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, GigabitEthernet0/0
      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
O E1     10.12.32.0/25 [110/21] via 172.22.44.66, 01:05:12, Serial0/0/0
O E1     10.12.32.128/26
           [110/65] via 172.22.44.66, 01:05:12, Serial0/0/0
O E1     10.12.32.192/27
           [110/65] via 172.22.44.66, 01:05:12, Serial0/0/0
O E1     10.12.32.224/30
           [110/65] via 172.22.44.66, 01:05:12, Serial0/0/0
      172.22.0.0/16 is variably subnetted, 6 subnets, 5 masks
C        172.22.32.0/21 is directly connected, Loopback1
L        172.22.32.1/32 is directly connected, Loopback1
O        172.22.40.0/22 [110/2] via 172.22.44.66, 02:31:33, Serial0/0/0
O        172.22.44.0/26 [110/2] via 172.22.44.66, 02:31:33, Serial0/0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.65/32 is directly connected, GigabitEthernet0/1
      193.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        193.0.0.0/24 is directly connected, GigabitEthernet0/0
L        193.0.0.254/32 is directly connected, GigabitEthernet0/0
```

:::info
Le « metric-type » permet de définir si la métrique doit grandir après redistribution.

Un « metric-type » de 1 signifie que la métrique augmente après la redistribution (à chaque fois qu’un routeur annonce cette route)

Un « metric-type » de 2 signifie que la métrique reste la même après redistribution
:::

### Préfixe Utilisé et Métrique des Réseaux Redistribués

#### Préfixe Utilisé

Les routes issues de RIP redistribuées dans OSPF sont annoncées avec le préfixe **E1 (External Type 1)**.

#### Valeur de la Métrique

La valeur de la métrique pour ces réseaux dans la table de routage de R1 est 21. Voici les routes concernées :

- 10.12.32.0/25 [110/65] via 172.22.44.66
- 10.12.32.128/26 [110/65] via 172.22.44.66
- 10.12.32.192/27 [110/65] via 172.22.44.66
- 10.12.32.224/30 [110/65] via 172.22.44.66

### Justification par rapport au Coût Réel avec OSPF

#### Coût avec Redistribution de Type 1 (E1)

Les routes redistribuées de RIP à OSPF avec le type E1 incluent le coût interne OSPF et la métrique RIP. La commande utilisée est ```redistribute rip metric-type 1 subnets```. Cela signifie que le coût total pour atteindre ces destinations redistribuées comprend :

1. **Métrique RIP** : 1
2. **Coût interne OSPF de R2 à R1** :
    - Coût de la liaison série entre R1 et R2 : 64 (valeur par défaut pour une liaison série OSPF)

### Redistribution de routes OSPF à partir de RIP

Dans cette partie, on va configurer la redistribution des routes apprises par OSPF dans la zone de routage RIP.

Pour cela, on configure la redistribution des routes OSPF en utilisant la commande : **```redistribute ospf proccess_id metric 5```** sur R2 : 

On vérifie maintenant, que la redistribution est bien effective pour le protocole RIP, en regardant dans la table de routage de R3 : 

```
Gateway of last resort is 10.12.32.225 to network 0.0.0.0

R*    0.0.0.0/0 [120/5] via 10.12.32.225, 00:00:14, Serial0/0/1
      10.0.0.0/8 is variably subnetted, 8 subnets, 5 masks
C        10.12.32.0/25 is directly connected, Loopback4
L        10.12.32.1/32 is directly connected, Loopback4
C        10.12.32.128/26 is directly connected, Loopback5
L        10.12.32.129/32 is directly connected, Loopback5
C        10.12.32.192/27 is directly connected, GigabitEthernet0/0
L        10.12.32.222/32 is directly connected, GigabitEthernet0/0
C        10.12.32.224/30 is directly connected, GigabitEthernet0/3
L        10.12.32.226/32 is directly connected, GigabitEthernet0/3
!!* R     172.22.0.0/16 [120/5] via 10.12.32.225, 00:00:14, Serial0/0/1 *!!
```

:::success
Les routes OSPF ont bien été apprises par le protocol RIP avec une métrique de 5, comme voulu.
:::

### Préfixe Utilisé et Valeur de la Métrique pour les Réseaux Redistribués

#### Préfixe Utilisé
Les routes issues d'OSPF redistribuées dans RIP sont annoncées avec le préfixe R (RIP).

#### Valeur de la Métrique
La valeur de la métrique pour les réseaux redistribués de OSPF à RIP, comme indiqué dans la table de routage de R3, est **5**. Les routes concernées :
- 0.0.0.0/0 [120/5] via 10.12.32.225
- 172.22.0.0/16 [120/5] via 10.12.32.225

## Analyse de la Connectivité
### Connexion de LAN 5 et LAN 6 au Serveur Web
#### Analyse de la table de routage de R3

```
Gateway of last resort is 10.12.32.225 to network 0.0.0.0

R*    0.0.0.0/0 [120/5] via 10.12.32.225, 00:00:14, Serial0/0/1
10.0.0.0/8 is variably subnetted, 8 subnets, 5 masks
C        10.12.32.0/25 is directly connected, Loopback4
L        10.12.32.1/32 is directly connected, Loopback4
C        10.12.32.128/26 is directly connected, Loopback5
L        10.12.32.129/32 is directly connected, Loopback5
C        10.12.32.192/27 is directly connected, GigabitEthernet0/0
L        10.12.32.222/32 is directly connected, GigabitEthernet0/0
C        10.12.32.224/30 is directly connected, GigabitEthernet0/3
L        10.12.32.226/32 is directly connected, GigabitEthernet0/3
R     172.22.0.0/16 [120/5] via 10.12.32.225, 00:00:14, Serial0/0/1
```

Dans la table de routage de R3, nous voyons les informations suivantes :

- **0.0.0.0/0 [120/5]** : Cela indique une route par défaut vers 10.12.32.225, ce qui signifie que R3 utilise cette adresse comme passerelle par défaut pour atteindre les réseaux hors de ses réseaux locaux.
- **10.12.32.128/26** et **10.12.32.192/27** sont directement connectés à R3 via GigabitEthernet0/0.

#### Analyse de la table de routage de R2

```
Gateway of last resort is 172.22.44.65 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 172.22.44.65, 02:45:32, Serial0/0/0
      10.0.0.0/8 is variably subnetted, 5 subnets, 5 masks
R        10.12.32.0/25 [120/1] via 10.12.32.226, 00:00:02, Serial0/0/1
R        10.12.32.128/26
           [120/1] via 10.12.32.226, 00:00:02, Serial0/0/1
R        10.12.32.192/27
           [120/1] via 10.12.32.226, 00:00:02, Serial0/0/1
C        10.12.32.224/30 is directly connected, GigabitEthernet0/3
L        10.12.32.225/32 is directly connected, GigabitEthernet0/3
      172.22.0.0/16 is variably subnetted, 7 subnets, 5 masks
O        172.22.32.0/21 [110/2] via 172.22.44.65, 02:45:32, Serial0/0/0
C        172.22.40.0/22 is directly connected, Loopback2
L        172.22.40.1/32 is directly connected, Loopback2
C        172.22.44.0/26 is directly connected, GigabitEthernet0/0
L        172.22.44.62/32 is directly connected, GigabitEthernet0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.66/32 is directly connected, GigabitEthernet0/1
```

Dans la table de routage de R2, nous voyons les informations suivantes :

- **0.0.0.0/0 [120/5]** : Cela indique une route par défaut vers 172.22.44.65, ce qui signifie que R2 utilise cette adresse comme passerelle par défaut pour atteindre les réseaux hors de ses réseaux locaux.
- **10.12.32.128/26** et **10.12.32.192/27** : R2 connaît l'emplacement des ses réseaux grâce à la redistribution de route et les renvoies vers 10.12.32.226 (R3).

#### Analyse de la table de routage de R1

```
Gateway of last resort is 0.0.0.0 to network 0.0.0.0

S*    0.0.0.0/0 is directly connected, GigabitEthernet0/0
      10.0.0.0/8 is variably subnetted, 4 subnets, 4 masks
O E1     10.12.32.0/25 [110/21] via 172.22.44.66, 01:40:36, Serial0/0/0
O E1     10.12.32.128/26
           [110/21] via 172.22.44.66, 01:40:36, Serial0/0/0
O E1     10.12.32.192/27
           [110/21] via 172.22.44.66, 01:40:36, Serial0/0/0
O E1     10.12.32.224/30
           [110/21] via 172.22.44.66, 01:40:36, Serial0/0/0
      172.22.0.0/16 is variably subnetted, 6 subnets, 5 masks
C        172.22.32.0/21 is directly connected, Loopback1
L        172.22.32.1/32 is directly connected, Loopback1
O        172.22.40.0/22 [110/2] via 172.22.44.66, 03:06:57, Serial0/0/0
O        172.22.44.0/26 [110/2] via 172.22.44.66, 03:06:57, Serial0/0/0
C        172.22.44.64/30 is directly connected, GigabitEthernet0/1
L        172.22.44.65/32 is directly connected, GigabitEthernet0/1
      193.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        193.0.0.0/24 is directly connected, GigabitEthernet0/0
L        193.0.0.254/32 is directly connected, GigabitEthernet0/0
```

Dans la table de routage de R2, nous voyons les informations suivantes :

- **0.0.0.0/0** : Cela indique une route par défaut directement connecté, ce qui signifie que R1 utilise cette adresse comme passerelle par défaut pour atteindre les réseaux hors de ses réseaux locaux.
- **10.12.32.128/26** et **10.12.32.192/27** : R1 connaît l'emplacement des ses réseaux grâce à la redistribution de route et les renvoies vers 172.22.44.66 (R2).

:::success
D'après toutes les tables de routage, un PC situé dans le LAN 5 ou LAN 6 peut communiquer avec le serveur WEB, puisque toutes les routes sont connus des routeurs.
:::

Vérifions cela avec un test de connectivité ping entre LAN6 et le serveur WEB : 

```
root@debian:~# ping 193.0.0.1 -c 4
PING 193.0.0.1 (193.0.0.1) 56(84) bytes of data.
64 bytes from 193.0.0.1: icmp_seq=1 ttl=61 time=3.87 ms
64 bytes from 193.0.0.1: icmp_seq=2 ttl=61 time=3.45 ms
64 bytes from 193.0.0.1: icmp_seq=3 ttl=61 time=2.77 ms
64 bytes from 193.0.0.1: icmp_seq=4 ttl=61 time=2.88 ms

--- 193.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.769/3.239/3.869/0.445 ms
```

Le test est concluant comme prévu.

## Authentification

L’authentification de l’échange des informations de routage constitue une mesure de sécurité importante dans un réseau. Vous allez mettre en place une authentification entre les différents routeurs.

L’authentification pour le protocole RIP se déroule en 3 étapes :
- Définir une clé à partir d’une chaîne
    - ```(config)# key chain name-of-chain```
- Définir le numéro et le contenu
    - ```(config-keychain) # key key-id```
    - ```(config-keychain) # key-string text```
- Spécifier l’interface d’échange qui utilise l’authentification
    - ```(config-if)# ip rip authentication key-chain name-of-chain```
    - ```(config-if)# ip rip authentication mode md5 name-of-chain```

On configure donc l'authentification pour le protocole RIP avec les trois étapes pour les routeurs R2 et R3: 

1. ```key chain cisco```
2. - ```key 1```
    - ```key-string gtrnet```
3. - ```ip rip authentication key-chain cisco```
    - ```ip rip authentication mode md5```

Pour l'authentification OSPF, on procède comme pour RIP et spécifier l'interface d'échange qui utilise l'authentification par la commande : ```ip ospf authentication-key name-of-chain```.

On configure donc l'authentification pour le protocole OSPF avec les trois étapes pour les routeurs R1 et R2: 

1. ```key chain cisco```
2. - ```key 1```
    - ```key-string gtrnet```
3. - ``` ip ospf authentication-key cisco```

Pour vérifier si l'authentification fonctionne, on utilise la commande **```debug ip rip```**, qui permet de reçevoir les informations de RIP : 

```
*May 19 20:14:19.943: RIP: received packet with MD5 authentication
*May 19 20:14:19.943: RIP: received v2 update from 10.12.32.226 on Serial0/0/1
*May 19 20:14:19.943:      10.12.32.0/25 via 0.0.0.0 in 1 hops
*May 19 20:14:19.943:      10.12.32.128/26 via 0.0.0.0 in 1 hops
*May 19 20:14:19.944:      10.12.32.192/27 via 0.0.0.0 in 1 hops
```

Il a donc bien une présence de chiffrage : **```RIP: received packet with MD5 authentication```**

### Comment les routeurs intègre les données dans leurs tables de routage
1. **Émission de Mises à Jour RIP** :

- Chaque routeur envoie des mises à jour RIP contenant des informations de routage périodiquement et à la réception d'une mise à jour.
- Avec l’authentification MD5 configurée, les mises à jour RIP incluent un hash MD5 de l’ensemble des données RIP plus une clé secrète. Cette clé et le hash garantissent que la mise à jour provient d'une source authentique.

2. **Réception de Mises à Jour RIP** :

- Lorsqu’un routeur reçoit une mise à jour RIP, il utilise la clé définie (MySecretKey) pour vérifier le hash MD5.
- Si la vérification du hash réussit, cela signifie que la mise à jour provient d'un routeur autorisé.
- Si la vérification échoue, la mise à jour est ignorée et n'est pas intégrée à la table de routage.

3. **Mise à Jour de la Table de Routage** :

- Si l'authentification réussit, le routeur traite les informations de la mise à jour comme d'habitude.
- Il compare les nouvelles informations de routage avec sa table de routage existante.
- Les routes sont mises à jour en fonction des métriques, des distances administratives et des autres critères de sélection de route.
- Les nouvelles routes apprises sont alors intégrées dans la table de routage du routeur.