---
titre: MAN concepts (Cours 1)
description: LAN concepts (Cours 1), 13/03/2020
tags: RESEAU, MAN, jerome.tchan
author: Jérôme Tchan
---

# MAN concepts (Cours 1)

:::success
Pour certains diagrammes (exercices notamment), vous pouvez cliquer sur l'image pour ouvrir le diagramme dans draw.io si vous souhaitez le modifier!
:::

## Etude de cas

Mail hebdomadaire:
- Valentine Labosse: [e-mail]
- Valérie Techeresse: [e-mail]
- Henri Tatillons (Architecte des monuments historiques): [e-mail]
- Jean-Antoine Deshsi: [e-mail]
- "Le prof": [e-mail]

Choisir un espace collaboratif, **le prof sera invité dans cet espace collaboratif**

**Premier mail au prof:**
Nom des étudiants dans le groupe + mail, leader, espace collaboratif choisi

3 sites:
- Paris: Rue de Rivoli (classé au patrimoine historique) => site historique, Zoglu est propriétaire
- Rochefort-sur-Mer (Charente-Maritime) => scientifique
- Clichy, le plus important

**Objectif:** Refondre l'infrastructure réseaux et télécoms de l'entreprise Zoglu
Positionner Zoglu dans le haut du marché => nécessité de refondre le SI

250 collaborateurs

Zoglu => proposer des sites d'enfouissement de résidus pétrochimiques à des entreprises pétrolières et chimiques, parcourir le monde à la recherche de ces sites
=> population nomade: géologues, commerciaux, etc.
10 nomades

Pas de prestataires externes, sauf pour la maintenance du parc

SI de Zoglu décomposé en 3 grands domaines:
- Gestion (Paye, etc.)
- Scientifique (Géologue, etc.)
- Bureautique (Tout le monde)

Pas de budget fourni pour le moment

L'informatique est au coeur de la performance de l'entreprise

Plusieurs chantiers:
- Réseaux & télécoms (c'est nous)
- Postes de travail (Mme Labosse avec Mme Techeresse)
- Applicatif (Mme Labosse)
- Salles Machines (Mr Deshsi)
- Serveur Stockage (Mme Techeresse)

Objectif de Mme Labosse: Mettre en place une structure commerciale décomposée par continent avec recrutement de commerciaux ad-hoc

Pas de datacenter

Mme Labosse a en vue plusieurs startups en Irlande et en Argentine notamment. (mini coop, max rachat)

On a globalement carte blanche

Ce n'est pas parce qu'on a le droit a un mail hebdomadaire qu'on aura une réponse hebdomadaire
**La relance ne compte pas comme un mail hebdo**

- Labosse: MBA au USA, 40 ans, école de commerce, a déjà redressé plusieurs entreprises,
- Techeresse: Géologue de formation, beaucoup d'intérêt pour l'informatique, a contribué au réseau scientifique
- Tatillons: respectable, 60aine d'années, historien d'art de formation, ne comprend absolument rien à l'informatique, tient beaucoup au site de Rivoli
- Deshsi: 60aine d'années, informaticien, nommé DSI par Mr Zoglu, n'est pas très chaud à l'idée de refondre SON SI, personne à l'ancienne

Mr Tatillons et Mr Deshsi sont plutôt proches
Mr Tatillons n'appartient **pas** à l'entreprise, veille à la préservation des sites historiques

Rapport intermédiaire
Rapport final: rapport pro type ingénieur, que de l'info utile

Mme Labosse peut envoyer des mails non sollicités

La qualité des interactions est prise en compte dans la note

Sites d'enfouissement intéressants: République kirghize (Kirghizistan), Mongolie (en particulier la province du sud est)

Ouverture d'un bureau commercial asie / pacifique
3 cibles:
- Singapour
- Kuala Lumpur
- Shanghai

---

## IPv4

IPv4:

- L3
- Protocole non connecté
- Pas de reprise d'erreur
- Paquet / Datagramme IPv4

| Header IPv4 | Payload |
| ----------- | ------- |

- En-tête de taille **variable**

### En-tête IPv4

>
> [name=http://arsene.perez-mas.pagesperso-orange.fr/reseaux/tcpip/entete_ip.htm][color=#907bf7]

- Version (4 bits) => 4 (IPv4) ou 6 (IPv6)
- IHL: Internet Header Length (4 bits) => en mots de 32 bits, minimum **5** mots de 32 bits => 20 octets
- DS: Differenciated Services, anciennement Type of Service (8 bits) => 0 = best effort
- LT: Total length (16 bits) => longueur du payload + IHL, exprimée en **octets**. Longueur totale max = 65535 octets (2^16-1), longueur max payload = longueur totale max - IHL min (20 octets) = 65515 octets
- ID: Identification (16 bits) => utilisé pour la fragmentation des paquets
- Un bit à 0
- DF: Don't Fragment (1 bit) => 0 = fragmentation autorisée (valeur par défaut), 1 = fragmentation interdite
- MF: More Fragment (1 bit) => 0 = pas ou plus de fragment, 1 = il y a un fragment suivant
- Offset (13 bits) => position des données fragmentées en mots de 8 octets
- TTL (8 bits) => Time to live, décrémenté de 1 à chaque routeur (hop count), détruit quand on arrive à 0, valeur par défaut dépendante de l'implémentation
- Protocole (8 bits) => Identifie la nature du payload IP: 6 = TCP, 11 = UDP, 1 = ICMP, etc. (valeurs en hexa)
- Checksum (16 bits) => sommation des compléments à un des mots de 16 bits du header (= découpage du header en mots de 16 bits, complément à un de chaque mot puis sommation de tous les mots)
- Addresse source (32 bits)
- Addresse destination (32 bits)
- Options

### Fragmentation

Si Header + Payload <= MTU sous-jacente (ex: Ethernet): OK
Si Header + Payload > MTU sous-jacente (ex: Ethernet): fragmentation nécessaire

On fragmente le payload en plusieurs petits bouts pour qu'ils soient en accord avec la MTU sous-jacente et on envoie chaque bout dans des paquets IP différents

>
> [name=https://en.wikipedia.org/wiki/IP_fragmentation][color=#907bf7]

Ex: payload séparé en 3
- 1er fragment: DF = 0, MF = 1, offset = 0
- 2e fragment: DF = 0, MF = 1,
- 3e fragment: DF = 0, MF = 0

**Il faut que la taille du payload soit divisible par 8 si ce n'est pas le dernier fragment => si non divisible par 8, on ajoute du padding**

Il est possible d'avoir un offset qui soit au delà de la taille maximum d'un payload (2^13 - 1 = 8191 => 65528 > 65515) => ping de la mort (offset = 8191 ou 8190)

Réassamblage à la réception => c'est toujours le destinataire final qui réassemble le paquet
Cependant, il peut y avoir de multiples fragmentations durant le transfert

---

### Exercice

[](https://www.draw.io/#Uhttp%3A%2F%2Fnagisanokoakuma.lovelyrad.io%2F77lnBdNb)

:::info
Etant donné un paquet IP de A vers B $P_{AB}$ sans options et d'une taille totale de 1494, donner pour chaque payload la valeur des champs
:::

| | IHL | LT | Longueur payload | DF | MF | Offset | ID | TTL |
| -------------- | ------------- | ---- | ---------------- | --- | --- | ------ | ----- | --- |
| $$P_{AB}$$ | 5 (20 octets) | 1494 | 1474 | 0 | 0 | 0 | 42523 | 32 |
| $$P_{AB_{1}}$$ | 5 (20 octets) | 404 | 384 | 0 | 1 | 0 | 42523 | 31 |
| $$P_{AB_{2}}$$ | 5 (20 octets) | 404 | 384 | 0 | 1 | 48 | 42523 | 31 |
| $$P_{AB_{3}}$$ | 5 (20 octets) | 404 | 384 | 0 | 1 | 96 | 42523 | 31 |
| $$P_{AB_{4}}$$ | 5 (20 octets) | 342 | 322 | 0 | 0 | 144 | 42523 | 31 |

[](https://www.draw.io/#Uhttp%3A%2F%2Fnagisanokoakuma.lovelyrad.io%2F10zJ46kQ)

| | IHL | LT | Longueur payload | DF | MF | Offset | ID | TTL |
| ------------------ | ------------- | --- | ---------------- | --- | --- | ------ | ----- | --- |
| ... | | | | | | | | |
| $$P_{AB_{1_{1}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 0 | 42523 | 30 |
| $$P_{AB_{1_{2}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 21 | 42523 | 30 |
| $$P_{AB_{1_{3}}}$$ | 5 (20 octets) | 68 | 48 | 0 | 1 | 42 | 42523 | 30 |
| $$P_{AB_{2_{1}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 48 | 42523 | 30 |
| $$P_{AB_{2_{2}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 69 | 42523 | 30 |
| $$P_{AB_{2_{3}}}$$ | 5 (20 octets) | 68 | 48 | 0 | 1 | 90 | 42523 | 30 |
| $$P_{AB_{3_{1}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 96 | 42523 | 30 |
| $$P_{AB_{3_{2}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 117 | 42523 | 30 |
| $$P_{AB_{3_{3}}}$$ | 5 (20 octets) | 68 | 48 | 0 | 1 | 138 | 42523 | 30 |
| $$P_{AB_{4_{1}}}$$ | 5 (20 octets) | 188 | 168 | 0 | 1 | 144 | 42523 | 30 |
| $$P_{AB_{4_{2}}}$$ | 5 (20 octets) | 174 | 154 | 0 | 0 | 165 | 42523 | 30 |

---

Problème de la fragmentation: c'est lent
Pour y remédier: **MTU path discovery** (créé par Cisco) => évitement de fragmentation

>
> [name=https://www.cisco.com/c/fr_ca/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html][color=#907bf7]

On cherche la MTU la plus petite pour adapter les paquets envoyés à celle-ci: DF à 1, si paquet > MTU, le routeur enverra un paquet ICMP avec la MTU

### Adressage IPv4

- 32 bits
- Classes
- Unicast
- Classes A, B, C
- Multicast
- Classe D
- Réservée (classe E) => 240 à 254
- Broadcast: 255.255.255.255

#### Unicast

| Net | Host |
| --- | ---- |

CIDR: / notation

##### Classe A

 1    7               24
[0|  Net  |          Host          ] /8

=> $2^7$ réseaux de classe A => $2^{25} - 2$ hosts / classe A

Adresses réservées
- 0.hhh.hhh.hhh (notamment 0.0.0.0)
- 127.hhh.hhh.hhh (adresses de loopback)

Pour 1.hhh.hhh.hhh/8, on a les adresses de 1.0.0.1 (1.0.0.0 est l'addresse du sous-réseau) à 1.255.255.254 (1.255.255.255 est une adresse de broadcast sur le sous-réseau)

**Adresses de classe A attribuables: de 1.hhh.hhh.hhh/8 à 126.hhh.hhh.hhh/8**

RFC 1918: Adresses privées:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16

##### Classe B

 1 1       14              16
[1|0|     Net      |      Host      ] /16

=> $2^{14}$ réseaux de classe B
=> 128.0.hhh.hhh à 191.255.hhh.hhh

172.16.hhh.hhh à 172.31.hhh.hhh réservé (RFC 1918)

##### Classe C

 1 1 1           21              8
[1|1|0|         Net         |  Host  ] /24

=> $2^{21}$ réseaux de classe C
=> 192.0.0.hhh à 223.255.255.hhh

Il n'y a plus de réseaux de classe C publics

#### Multicast

 1 1 1 1              28
[1|1|1|0|          Group ID          ] /24

=> $2^{28}$ réseaux de classe D
=> 224.0.0.0 à 239.255.255.255

---

### Exercice

:::info
Pour les adresses suivantes, donner:
- Classe
- Subnet mask par défaut (CIDR et décimal)
- Adresse de diffusion
- Réseau

a. 150.1.200.10
b. 11.11.250.197
c. 240.12.127.0
d. 220.255.255.197
:::

a.
- Classe: B
- Subnet mask: /16, 255.255.0.0
- Adresse de diffusion: 150.1.255.255
- Réseau: 150.1.0.0

b.
- Classe: A
- Subnet mask: /8, 255.0.0.0
- Adresse de diffusion: 11.255.255.255
- Réseau: 11.0.0.0

c.
- Classe: E
=> Hors-sujet

d.
- Classe: C
- Subnet mask: /24, 255.255.255.0
- Adresse de diffusion: 220.255.255.255
- Réseau: 220.255.255.0

---