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