feat: add network layer course
This commit is contained in:
parent
cde393c033
commit
6d608a1f27
1 changed files with 443 additions and 0 deletions
443
content/reseaux_protocoles/4_couche_reseau/index.md
Normal file
443
content/reseaux_protocoles/4_couche_reseau/index.md
Normal file
|
|
@ -0,0 +1,443 @@
|
|||
---
|
||||
title: "Réseaux et Protocole: couche réseau"
|
||||
date: 2024-02-21
|
||||
tags: ["OSI", "reseau", "control plane", "data plane"]
|
||||
categories: ["Réseaux et protocoles", "Cours"]
|
||||
mathjax: true
|
||||
---
|
||||
|
||||
Le but de cette partie et de comprendre ce qui se passe dans la couche réseaux
|
||||
matérialisée la quasi-totalité du temps par le **protocole IP**. Comme pour les
|
||||
autres couches vue jusqu'à présent, il est encore question **d'encapsulation**
|
||||
et de **décapsulation**.
|
||||
|
||||
C'est la couche qui se trouve dans les équipements *Internet* pour faire du
|
||||
**routage**: le *routeur* examine les entêtes des *paquets IP* afin de
|
||||
déterminer leur destination. Deux notions apparaissent alors:
|
||||
|
||||
* le **forwarding** qui consiste à récupérer les paquets sur une *interface* et
|
||||
les renvoyer vers une autre;
|
||||
* le **routage** qui consiste à déterminer la route de la source vers la
|
||||
destination (le chemin complet donc).
|
||||
|
||||
Dans ce chapitre nous aborderons les notions de **data plane**, **control plan**
|
||||
ou encore de **software defined network** (*SDN*).
|
||||
|
||||
## Le *data plane*
|
||||
|
||||
C'est la partie responsable du mouvement "réel" des données à travers les
|
||||
périphériques réseaux. La logique de routage est implémenter dans chacun des
|
||||
périphérique composant le réseau.
|
||||
|
||||
### Les routeurs
|
||||
|
||||
Pierre angulaire de l'acheminement des paquets. ils prenne des pacquets sur des
|
||||
interfaces en entrée qu'il redirigent vers des interfaces en corties en fonction
|
||||
de critères établis. En définitive chaque routeur est indépendant et composé
|
||||
d'un *data plane* et d'un *control plane* contenant la **table de routage**.
|
||||
|
||||
Pour schématiser, le *control plane* représente le logiciel et le *data plane*
|
||||
le matériel.
|
||||
|
||||
### Switch fabric
|
||||
|
||||
Le *data plane* se compose des ports en entrée et en sortie, au milieu se
|
||||
trouve la **switch fabric**. C'est cette partie qui est charger d'acheminer les
|
||||
paquets des entrées vers les sorties en fonction de ce que le *control plane*
|
||||
veut. Le temps de traitement d'un *datagramme* est de l'ordre de la nanoseconde
|
||||
[^traitement].
|
||||
|
||||
|
||||
[^traitement]: là ou pour le *control plane* c'est de l'ordre de la
|
||||
milliseconde. Chaque routeur est aussi responsable de son algorithme de
|
||||
routage.
|
||||
|
||||
#### ports d'entrée
|
||||
|
||||
|
||||
Ils reçoivent les *trames* de la couche liaison. Les entêtes de la couche
|
||||
reseaux sont extraites. Deux traitements sont alors possibles:
|
||||
|
||||
* forwarding basé sur **la destination** basé uniquement sur l'adresse de
|
||||
destination;
|
||||
* forwarding **généralisé** basé sur les valeurs de l'entête (une, quelques
|
||||
unes ou toutes).
|
||||
|
||||
Pour les correspondances sur les adresses, la règle du *longuest prefix match*
|
||||
s'applique. La correspondance se fait sur le prefixe le plus détaillé.
|
||||
|
||||
Le *switching rate* est donné par le rapport entre le nombre de paquet en entrée
|
||||
et en sorties. Idéaliement il est de 1 ou plus, ce qui signifie que les
|
||||
*datagrammes* en entrée sont traités directement. si ce nombre est inférieur à 1
|
||||
alors il y a engorgement à l'entrée. Dans ce cas les paquets sont mis en file
|
||||
d'attente dans un *buffer* (à l'entrée).
|
||||
|
||||
Il peuvent l'être aussi si les paquets reste bloqués pour diverses raison comme
|
||||
par exemple un *buffer* de sortie plein.
|
||||
|
||||
En cas de remplissage du *buffer* alors des **paquets peuvent être perdus**.
|
||||
|
||||
#### ports de sortie
|
||||
|
||||
Ils reçoivent les *datagrammes* en provenance de la *switch fabric* et les
|
||||
acheminent vers leur destination. Là encore nous avons un *buffer** où les
|
||||
paquets en attente sont stocké par exemple si les paquets arrivent plus vite que
|
||||
le lien ne peut les transmettre.
|
||||
|
||||
Ici encore des paquets pevent être perdus en cas de **buffer overflow**.
|
||||
|
||||
Les paquets évincés dépendent alors de la stratégie définie :
|
||||
|
||||
* `tail drop` pour refuser les nouveaux datagrammes qui arrivent;
|
||||
* `priority` pour supprimer des datagrammes en fonction des priorités.
|
||||
|
||||
#### Ordonnancement
|
||||
|
||||
Il est possible de définir l'ordonnancement des datagrammes et ainsi d;organiser
|
||||
une stratégie de priorisation en fonction des besoins. Le plus simple reste
|
||||
*FIFO* pour *First In First Out*[^FCFS] où ils sont acheminés en fonction de
|
||||
leur ordre d'arrivé.
|
||||
|
||||
Il est aussi possible d'ordonnancer suivant la priorité, par *round-robbin*, par
|
||||
poids attribués aux paquets ...
|
||||
|
||||
[^FCFS]: aussi appelle *First Come First Serve*.
|
||||
|
||||
### Le protocole IP
|
||||
|
||||
C'est un ensemble de règle définissant:
|
||||
|
||||
* un format de *datagrammes*;
|
||||
* l'adressage;
|
||||
* les conventions d'action sur les paquets;
|
||||
* le protocole ICMP (report d'erreur et signalement de routeurs);
|
||||
* les algorithme de sélection de chemins pour router les paquets (BGP, OSPF).
|
||||
|
||||
L'entête d'un datagramme IP fait 20 octets pour sa version v4, elle se compose:
|
||||
|
||||
* *version* du protocole (4 bits);
|
||||
* *longueur de l'entête* -- nombre de mots de 32 bits -- par défaut 5 (4 bits);
|
||||
* *type de services* (8bits);
|
||||
* *longueur totale du datagramme* en octets (16 bits);
|
||||
* données utilisé pour la fragmentation :
|
||||
* *identifiant* ( 16 bits);
|
||||
* *drapeau* (4 bits);
|
||||
* *décallage* (12 bits);
|
||||
* adresse *source* (32 bits);
|
||||
* adresse *destination* (32 bits);
|
||||
* *options* si besoin (32 bits);
|
||||
|
||||
#### L'adresse IP
|
||||
|
||||
C'est un identifiant codé sur 32 bits et attribué à chacune des interface des
|
||||
hôtes connectés au réseau. Une *interface* représente une connexion entre un
|
||||
hôte (ou un routeur) et un lien physique (issu de la couche liaison que nous
|
||||
verrons plus tard)
|
||||
|
||||
Il existe deux façons de classifier les adresse IP:
|
||||
|
||||
* L'adressage par classes représenté par des classes d'adresses allant de *A* à
|
||||
*E* en fonction des préfixes (1.0.0.0 - 126.255.255.255 pour la classe A par
|
||||
exemple);
|
||||
* *CIDR* pour *Classless Inter Domain Routing* ou les sous-réseaux peuvent
|
||||
avoir des adresses d'une taille arbitraire.
|
||||
|
||||
Dasn le second cas, les adresses sont découpés entre le préfixe de sous-réseau
|
||||
et la part réserver aux hôtes, par exemple
|
||||
|
||||
```text
|
||||
192.168.23.0/23
|
||||
```
|
||||
|
||||
Il existe aussi les adresses publiques et privées (utilisable dans un réseaux
|
||||
local). Pour ces dernière 3 classes sont disponibles:
|
||||
|
||||
* 10.0.0.0/8
|
||||
* 172.16.0.0/12
|
||||
* 192.168.0.0/16
|
||||
|
||||
##### le sous-réseau
|
||||
|
||||
Nous avons parlé de sous-réseaux, c'est la portion d'un réseau ou les hôtes
|
||||
peuvent se contacter les uns les autres sans que les datagrammes passent par
|
||||
un routeur. Ainsi chaque portion isolée d'un réseau est un sous-réseau. NMous
|
||||
pouvons alors créer des "îles".
|
||||
|
||||
|
||||
#### Obtenir une adresse IP
|
||||
|
||||
Plusieurs moyens sont à la disponision des administrateurs réseaux afin
|
||||
d'assigner une adresse IP à une interface.
|
||||
|
||||
* Adresse codée directement "en dur" sur l'interface via, par exemple, le
|
||||
fichier `/etc/network/interfaces`.
|
||||
* Assignée dynamiquement par un serveur *DHCP* *Dynamic Host Configuration
|
||||
Protocol*.
|
||||
|
||||
Pour ce dernier, voici les étapes:
|
||||
|
||||
1. l'hôte envoie un message de *broadcast* de type `DHCP discover`;
|
||||
2. les serveurs *DHCP* disponibles répondent avec le message `DHCP Offer` et
|
||||
fait une proposition;
|
||||
3. l'hôte répond avec avec un message `DHCP request` au serveur qu'il a retennu
|
||||
avec comme charge utile l'adresse IP qui lui a été proposée;
|
||||
4. le serveur retenu répond alors avec un message `DHCP ack`.
|
||||
|
||||
Le DHCP fait bien plus qu'assigner des adresses IP, il peut aussi définit
|
||||
l'adresse de la passerelle (routeur de premier niveau), les adresses des
|
||||
serveurs de nom, le masque de réseau etc.
|
||||
|
||||
### NAT, *Network Address Translation*
|
||||
|
||||
Il est question ici de *"partager"* une adresse IP **publique**. L'agent
|
||||
responsable de la translation d'adresse. Il est question de remplacer le port et
|
||||
l'adresse IP source. Notre agent responsable -- équipement effectuant la
|
||||
translation -- une table de translation est disponible afin de connaitre l'état
|
||||
des connexions en cours.
|
||||
|
||||
Le NAT n'est utile que pour l'IP v4 dont les adresses routables sont au bord de
|
||||
l'epuisement. Il est utilisé intensivement pour les connexions domestiques et
|
||||
les réseaux cellulaires. Cependant les problèmes de pénurie ont leur solution:
|
||||
IPV6.
|
||||
|
||||
Problème supplémentaire, c'est le routeur qui se charge de faire le *NAT*,
|
||||
cependant il ne ddevrai pas aller farfouller dans la couche 4 du modèle OSI et
|
||||
se cantonner **sa couche 3**.
|
||||
|
||||
### Forwarding généralisé (SDN)
|
||||
|
||||
Chaque routeur contient une **table de forwarding**. Lors du forwarding
|
||||
généralisé, la correspondance ne se fait pas seulement sur l'adresse de
|
||||
destination mais sur l'ensemble de l'entête. Le routeur utilise alors la
|
||||
correspondance (*match*), les *actions* et la *priorité*.
|
||||
|
||||
* Les *match* se font sur les couches *lien*, *réseau* et * transport.
|
||||
* Les actions possibles sur les paquets sont *drop*, *copy*, *modify* et *log*.
|
||||
* Les priorité afin de savoir *quoi faire* lorsque plusieurs *match* arrivent.
|
||||
* Enfin, les couteurs sont là afin d'acoir des metriques sur *les bits* et les
|
||||
*paquets* qui passent.
|
||||
|
||||
Le principe du SDN est d'unifier **routage**, **pare-feu**, **NAT**,
|
||||
**switching** en allant chercher dans toutes les entêtes de ces couches.
|
||||
|
||||
## Control plane
|
||||
|
||||
Comme nous l'avons vu au début de cette partie, le **control plane** est
|
||||
responsable du routage : il détermine le chemin pris par les paquets. Deux
|
||||
possibilités s'offre alors à nous:
|
||||
|
||||
1. un *control plane* dans chaque routeur (ce que nous avons jusqu'ici);
|
||||
2. un *control plane* centralisé qui pilote un ensemble de routeurs.
|
||||
|
||||
Dans le premier cas il est nécessaire d'implémenter le routage par équipement
|
||||
individuellement, ce qui peut vite se réveller fastidieux. Dans le second cas,
|
||||
les routeurs utilisent un control place distant définis par logiciel. ainsi la
|
||||
configuration de tous les routeurs **est unifiée**.
|
||||
|
||||
Pour rappel, le routage a pour objectif de déterminer le meilleur chemin à
|
||||
prendre pour un paquet donné. Le chemin est en fait un ensemble de routeur par
|
||||
lequel le paquet va passer. Le meilleur chemin peut avoir plusieurs sens,
|
||||
parlons nous de *moins cher*, de *plus rapide*, *moins congestionné*?
|
||||
|
||||
### Algorithme de routage
|
||||
|
||||
Il existe bien évidemment plusieurs algorithme de routage avec chacuns
|
||||
avantages et inconvénients par exemple :
|
||||
|
||||
* *statique*, les routes changent peu et lentement
|
||||
* *dynamique*, les routes changent rapidement soit périodiquement soit en
|
||||
réponse à des incidents;
|
||||
* algorithme *link-state* ou chaque routeur voit la topologie complète avec les
|
||||
coûts des différents liens;
|
||||
* algorithme décentralisé *distant vector* ou les routeurs ne connaissent au
|
||||
départ que les coûts des liens vers leurs voisins directs. C'est un
|
||||
algorithme dynamique basé sur le calcul, et l'échange d'informations entre
|
||||
routeurs voisins.
|
||||
|
||||
|
||||
#### Algorithme de Dijkstra
|
||||
|
||||
C'est un algorithme centralisé ou les coûts vers tous les nœuds sont connus à
|
||||
l'avance via des messages de type `link-state broadcast`. Tous les nœuds
|
||||
détiennent **les mêmes informations**.
|
||||
|
||||
Avec ces informations, nous pouvons alors calculer les chemins les *moins
|
||||
chers*" depuis un nœud vers tous les autres. Nous obtenons alors une table de
|
||||
*forwarding* complète.
|
||||
|
||||
Le processus est **itératif*, ainsi après un nombre \\(K\\) d'itérations., nous
|
||||
connaissons le meilleurs chemin vers \\(k\\) destinations. Voici cet algorithme:
|
||||
|
||||
```
|
||||
// c(x,y) coût entre lien direct entre x et y
|
||||
// D[v] estimation du coût du meilleur chemin vers v depuis la source
|
||||
// p(v) nœud précédent sur le chemin de la source vers v
|
||||
// N`` ensemble de nœuds que notre algorithme connais via least-cost path
|
||||
|
||||
/* Init */
|
||||
N` = u; //compute least-cost path from u to all others nodes}
|
||||
for all_node v
|
||||
if v in all_node()
|
||||
D[v] = c(u,v);
|
||||
else
|
||||
D[v] = INFINITE;
|
||||
|
||||
do
|
||||
find w not_in N` such D[w] is minimal
|
||||
add w to N`
|
||||
update D[v] for all v adjacent tow and not in N`:
|
||||
D[v] = min(D[v], D[w] + c(w,v))
|
||||
until all node in N`
|
||||
```
|
||||
|
||||
#### Algorithme de Bellman-Ford
|
||||
|
||||
Chaque nœud envoie régulièrement sa table de vecteur de distance et leurs coûts
|
||||
associés à ses voisins. Lorsque notre nœud reçoit les information de ses
|
||||
voisins, il mets à jour sa propre table de vecteurs de distances en réalisant
|
||||
des calculs. C'est un algorithme asynchrone, itératif et sans notification de
|
||||
l'extérieur.
|
||||
|
||||
### Routage intra-ISP: OSPF
|
||||
|
||||
Pour l'instant, tout ce que nous avons vu relève du **monde idéal** et ne passe
|
||||
pas à l'échelle pour *Internet*:
|
||||
|
||||
* tout le réseau est **identique**;
|
||||
* le réseau est "**plat**".
|
||||
|
||||
Dans la vrai vie l existe des **milliards** de destinations et tout un tas de
|
||||
**réseaux autonomes**. Il est donc impossible de stocker toutes ces information
|
||||
dans une sable de routage ni de gérer de façon unifiés tout ce beau monde. Il
|
||||
est donc nécessaire d'agréger des régions appelées **systèmes autonomes** abrégé
|
||||
*AS*. nous avons alors deux types de routages:
|
||||
|
||||
* **intra-AS** ou *intra-domaine* pour tout ce qui se trouve dans notre système
|
||||
autonome, le protocole utilisé est forcément le même sur tous les routeurs de
|
||||
notre domaine
|
||||
* **inter-AS** ou *inter-domaine* qui représentens les liens entre différents
|
||||
*AS*
|
||||
|
||||
Les liens entre les *AS* sont réalisés par les routeurs de bordures.
|
||||
|
||||
#### Protocoles intra-AS
|
||||
|
||||
Les protocoles les plus communs sont:
|
||||
|
||||
* **RIP** pour *Routing Information Protocol*, les routeurs échange des
|
||||
*distant vectors* classique toutes les 30 secondes -- n'est plus utilisé
|
||||
aujourd'hui;
|
||||
* **EIGRP** pour *Enhanced Interior Gateway Procolol* qui est lui aussi basé
|
||||
sur les *distant vectors*, c'est à l'origine un protocole propriétaire de
|
||||
Cisco mais ouvert en 2013;
|
||||
* **OSPF** pour *Open Short Path First* qui est un protocole de type
|
||||
*link-state*
|
||||
|
||||
Dans le cadre de ce cours nous ne verrons qu'*OSPF* qui est le plus utilisé
|
||||
aujourd'hui.Chaque routeur annonce l'état de ces liens directement en utilisant
|
||||
le protocole IP (pas d'encapsulation de segment de la couche transport) à tous
|
||||
les autre routeur de l'*AS*. Les informations de coûts peuvent provenir de
|
||||
différentes métriques comme la bande passante, la latence etc.
|
||||
|
||||
Au niveau sécurité ds échanges, tous les messages *OSPF* peuvent être
|
||||
authentifiés.
|
||||
|
||||
*OSPF* propose deux niveau de **hiérarchie** :
|
||||
|
||||
* *backbone* interconnectant plusieurs zones;
|
||||
* *local area* représentant une zone en particulier, plus localisée.
|
||||
|
||||
L'état des liens, comprenant le couple *IP/masque* est enregistré dans une base
|
||||
de données. Cette ase est ensuite utilisée pour les calculs. La mise à jour se
|
||||
fait par des messages multicasts `link-state-advertisement`. Plusieurs types de
|
||||
paquets existent.
|
||||
|
||||
* `hello` pour la découverte des voisins, l'entetien des relations de
|
||||
voisinages. Ces paquets sont envoyés toutes les 10 secondes, si aucune de
|
||||
reponse n'est effectuées au bouts de 4 `hello`, alors l'hote est considéré
|
||||
comme *downn*.
|
||||
* `database description` pour synchroniser les bases de données avec ses
|
||||
voisins.
|
||||
* `link-state-request` pour demander des informations aux voisins.
|
||||
* `link-state-advertisement` pour mettre à jour l'état des liens, il en existe
|
||||
11 types différents de paquets:
|
||||
* type 1: décrire les interfaces du routeur;
|
||||
* type 2: décription ds routeur conectés à un segment (dans une même *area
|
||||
OSPF);
|
||||
* type 3: résumés des information envoyées depuis une autre *area*.
|
||||
* etc.
|
||||
* `link-state-update` qui contient plusieurs `LSA`
|
||||
* `link-state-ack` pour l'acquitement d'un `LSR` ou d'un `LSA`
|
||||
|
||||
OSPF est basé sur l'algorithme de Dijkstra: le plus court chemin. Il est calculé
|
||||
en fonction de la bande passante du lien. 100Mbit/s a un poind de 1, 10Mbit/s un
|
||||
poid de 10 (100/10) et 1000Mbit/s 0.1 (100/1000). Cependant le poind ne peut
|
||||
être inférieur à 1, donc 0,1 devient 1. Pour poivoir profiter des poids sur les
|
||||
liens suppieur à 100Mbit/s, il faut alors **modifier manuellement la valeur de
|
||||
base**.
|
||||
|
||||
#### Protocole inter-AS: BGP
|
||||
|
||||
BGP pour *Border Gateway Protocol* annonce l'existance d'un réseau, d'une
|
||||
destination. Il permet d'obtenir des informations de routage de ses voisins via
|
||||
**eBGP**, de déterminer les routes vers les autres réseaux en fonction des
|
||||
information de disponibilités et des politiques ou encore d'avertir ses voisins
|
||||
de ses propres réseaux / disponibilités. Par le biais **d'iBGP** il propage les
|
||||
information obtenues de ses voisins à tous les routeur *intra-domaine*.
|
||||
|
||||
*BGP** utilise les sessions établies via TCP pour communiquer. Plusieurs type de
|
||||
messages sont disponibles:
|
||||
|
||||
* **open** pour ouvrir une connexion TCP vers un hôte BGP distant et
|
||||
s'authentifier;
|
||||
* **update** pour avertir de changement que se soit suppression, ajout ou
|
||||
modification;
|
||||
* **keepalive** pour maintenir la session ouverte;
|
||||
* **notification** pour notifier d'une erreur ou fermer une session.
|
||||
|
||||
Une annonce contient un *préfixe* plus un *attribut*. Les deux attributs les
|
||||
plus importants sont:
|
||||
|
||||
* *as-path* qui représente le chemin;
|
||||
* *next-hop* qui indique le routeur spécifique pour arriver à une destination
|
||||
définie.
|
||||
|
||||
BGP utilise des politique de routage pour déterminer les chemins à annoncer.
|
||||
|
||||
Principe de la **patate chaude**: BGP choisira de faire sortir le paquet le plus
|
||||
vite possible de son infrastructure, ne prenant pas en comptes les coûts
|
||||
intra=domaines
|
||||
|
||||
|
||||
### SDN *Software Defined Network
|
||||
|
||||
Depuis 2005, des recherches sont menées afin de trouvwr de nouvelles approches
|
||||
réseaux. Le *control plane* et le *data plane* se faisaient traditionnellement
|
||||
sur les routeurs. Maintenant le controle est éloigné et installe à distance les
|
||||
tables de routages. Ainsi la gestion du réseau est facilitée (configuration en
|
||||
un seul point, plus de flexibilité, contrôle *openflow* et architcture
|
||||
indépendate du vendeur --interopérable).
|
||||
|
||||
Le *SDN controller* prend alors trois fonctions:
|
||||
|
||||
* *interface layer* offrant l'accès aux API;
|
||||
* *network state management* prenant en compte les information des liens, du
|
||||
*switching;
|
||||
* les communication via les API (Openflow, SNMP).
|
||||
|
||||
#### le protocole Openflow
|
||||
|
||||
Il s'intercate entre les controlleurs et les *switches* et utilise TCP. Il
|
||||
comporte trois types de messages:
|
||||
|
||||
* `controller` vers les `switch` pour demander des information, envoyer des
|
||||
configurations etc.;
|
||||
* asynchrone avec par exemple les paquets à traiter par le conrolleurs,
|
||||
notifier la suppression d'une entrée dans la *table de forwarding*
|
||||
* symetrique
|
||||
|
||||
#### ICMP *Internet Control Message Protocol*
|
||||
|
||||
C'est un protoboe de contrôle utilisé pour obtenir des informations au niveau du
|
||||
réseau (*unreachable host|protocol|port*, *ping*). Il s'intercate entre les
|
||||
couches réseau et transport.
|
||||
Loading…
Add table
Add a link
Reference in a new issue