Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
09 juin 2010

htmlpdflatexmanmd




rfc951

rfc951

bootp

   BOOTP est un protocole d'amorçage permettant à une machine sans disque dur de découvrir sa propre adresse IP, l'adresse d'un hôte serveur, et le nom d'un fichier à charger en mémoire pour exécution. Une telle opération d'amorçage se déroule en 2 phases. La première permet de déterminer l'adresse puis le fichier à télécharger, et la 2eme phase consiste à transférer ce fichier via TFTP généralement, mais n'est pas une obligation, il est possible d'utiliser FTP ou SFTP. TFTP est préféré puisque les 2 phases résident dans la PROM du client. Le logiciel PROM devrait fournit un moyen d'effectuer un amorçage complet sans intervention de l'utilisateur. Un mécanisme devrait cependant permettre à l'utilisateur de fournir manuellement l'adresse et le nom de fichier, permettant de passer outre le protocole BOOTP et d'entrer directement dans la phase de transfert de fichier.

Aperçu du protocole

- Un seul échange de paquets est effectué. Des temporisateurs sont utilisés pour la retransmission jusqu'à la réception d'une réponse. La même composition de paquet est utilisée dans les 2 directions. Des champs de longueur fixée à un maximum raisonnable sont utilisés pour simplifier la définition de structure et l'analyse syntaxique.
- Un champ Opcode existe et comprend 2 valeurs. Le client diffuse un paquet bootrequest, le serveur répond avec un paquet bootreply. La requête d'amorçage contient l'adresse matérielle du client et son IP, s'il la connait.
- La requête peut optionnellement contenir le nom du serveur à partir duquel le client veut obtenir une réponse. C'est prévu afin que le client puisse exiger l'amorçage depuis un hôte spécifique.
- La requête peut optionnellement contenir le nom de fichier « générique » à partir duquel démarrer.
- Dans le cas d'un client qui ne connait pas son adresse IP, le serveur doit également disposer d'une base de données associant adresses matérielles et adresses IP. Cette IP est ensuite placée dans un champ de la requête d'amorçage.
- Il est possible d'utiliser des agents relai, permettant aux clients de démarrer depuis des serveurs situés sur une autre réseau.

Format des paquets

   Un paquet BOOTP est encapsulé dans un datagramme UDP. Dans l'en-tête IP d'une requête d'amorçage, le client fournit sa propre adresse IP s'il la connaît, ou zéro sinon. Quand l'adresse du serveur est inconnue, l'adresse IP destination sera l'adresse de diffusion 255.255.255.255. L'en-tête UDP contient les numéros de port source et destination. Le protocole BOOTP utilise le port 68 « client BOOTP » et le port 67 « serveur BOOTP ». Le client envoie une requête en utilisant le port 67 en port de destination et 68 en port source.

op (1 octet) Type de message/code opératoire du paquet: 1= BOOTREQUEST, 2= BOOTREPLY
htype (1 octet) Type d'adresse matérielle voir la RFC « Assigned Numbers » section ARP.
hlen (1 octet) Longueur de l'adresse matérielle (ex : 6 pour Ethernet)
hops (1 octet) Fixé par le client à 0 ; peut être utilisé par des passerelles lors d'amorçages au travers de passerelles
xid (4 octets) ID de transaction : nombre aléatoire utilisé pour associer cette requête de démarrage avec la réponse qu'elle génère.
secs (2 octets) Rempli par le client, secondes aléatoire utilisé pour associer cette requête de démarrage avec la réponse qu'elle génère.
ciaddr (4 octets) Adresse IP du client ; remplie par le client dans la requête d'amorçage si elle est connue
yaddr (4 octets) Votre adresse IP (Client) ; remplie par le serveur si le client ne connait pas sa propre adresse (si ciaddr valait 0)
siaddr (4 octets) Adresse IP du serveur ; renvoyée dans une réponse d'amorçage par le serveur.
giaddr (4 octets) Adresse IP de la passerelle utilisée dans l'amorçage au travers de passerelles optionnel
chaddr (16 octets) Adresse matérielle du client ; remplie par le client
sname (64 octets) Nom de l'hôte serveur
file (128 octets) Nom du fichier de démarrage
vend (64 octets) Zone optionnelle spécifique au vendeur.

   Si aucune réponse n'est reçue durant une certaine période de temps, le client devrait retransmettre la requête.

Utilisation du serveur bootpd

En général boopd est lancé par /etc/inetd, grâce aux lignes suivante du fichier /etc/inetd.conf :
bootps dgram udp wait root /etc/bootpd bootpd
bootpd est alors lancé uniquement lorsqu'une requête de démarrage arrive. A son démarrage, bootpd lit le fichier de configuration ( par défaut /etc/bootptab). Les ports utilisés sont spécifiés dans /etc/services
-c répertoire
Force bootpd à travailler dans le répertoire

Configuration

   Le fichier de configuration de bootpd a un format dans lequel des symboles sensibles à la casse de deux caractères sont utilisé pour représenter les paramètres des hôtes. Ces déclarations de paramètres sont séparés par des « : ». Le format général est:

  hôte:tg=valeur:tg=valeur:tg=valeur

bf Fichier de démarrage
bs Taille du fichier de démarrage en bloc de 512 octets
bc Liste des adresse des serveurs de cookies
ds Liste des serveurs de nom de domaine
gw Liste des adresses de passerelles
ha Adresse matérielle de l'hôte
hd Répertoire racine du fichier de démarrage
hn Envoi le nom de l'hôte
ht Type de matériel de l'hôte
im Liste des adresses des serveurs d'impression
ip Adresse IP de l'hôte
ig Liste des adresses des serveurs de journalisation
lp Liste des adresses lpr
ns Liste des adresses des serveurs de noms IEN-116
rl Liste des adresses des serveurs de protocole de localisation des ressources
sm Masque de sous-réseau de l'hôte
tc Suite de table
to Décalage horaire en secondes par rapport à UTC
ts Liste d'adresses de serveurs d'heure
vm Sélecteur de cookie magique du revendeur.

   Il existe également le relai bootp: bootpgw qui utilise les même options sauf -c. bootptest est un utilitaire permettant de tester bootpd et bootpgw.
^
08 juin 2010

htmlpdflatexmanmd




rfc2131

rfc2131

Dynamic Host Configuration Protocole

   DHCP (Dynamic Host Configuration Protocole) est un protocole faisant lui même partie de la suite de protocole BOOTP. Protocole de niveau application de type client-serveur, il permet à un hôte n'ayant pas de configuration réseau (adresse IP, masque, adresse dns, passerelle etc...), d'en obtenir une afin de pouvoir communiquer sur le réseau.

   DHCP permet l'allocation dynamique d'adresse IP mais peut également réserver certaines adresses à des clients spécifiques. On distingue 3 types d'allocations. L'allocation dynamique attribue une adresse IP à une machine parmi le pool d'adresse disponible. L'allocation automatique fonctionne de la même manière, mais fournit un baille infini, réservant ainsi l'IP de manière permanente. L'allocation manuelle, consiste à réserver une IP associée à une adresse MAC, garantissant à une machine de toujours obtenir la même adresse.

   Grâce à l'allocation dynamique d'adresse IP, une adresse IP peut être réutilisée sur le réseau lorsqu'une machine n'est plus connectée, permettant ainsi de profiter au mieux de la plage d'adresse disponible. De plus la configuration manuelle de chaque client peut être longue et source d'erreur, et en cas de modification du réseau (changement de l'adresse du dns ou de la passerelle par exemple) il est nécessaire de reconfigurer chaque client. Grâce à DHCP, les modifications sont apportées uniquement au serveur DHCP, propageant ainsi la mise à jour de la configuration à tous les clients.

   Il est possible d'avoir plusieurs serveurs DHCP sur un réseau, les clients DHCP doivent attendre un certains temps lors d'une demande de configuration, afin de recevoir plusieurs offres, et de pouvoir choisir celle qui lui convint le mieux.

   Un client peut également demander à utiliser certains paramètres spécifique, comme une adresse réseau particulière ou une durée de bail.

   Un serveur DHCP s'assure qu'une adresse IP n'est pas utilisée 2 fois sur le même réseau. Il mémorise les configurations client de manière à redonner, dans la mesure du possible, la même configuration au même client.

Format d'un message DHCP


_op (1)____|_Htype (1)____|_Hlen (1)____|_Hops (1)
________________________xid (4)___________________
_____________Secs (2)____|_flags (2)______________
_______________________ciaddr (4)_________________
_______________________yiaddr (4)_________________
_______________________siaddr (4)_________________
_______________________giaddr (4)_________________
_______________________chaddr (16)________________
_______________________sname (64)_________________
______________________fichier (128)_______________
____________________options (variable)____________

Description des champs

op (1 octet) Code opération du message / type du message. 1 = BOOTREQUEST, 2 = BOOTREPLY
htype (1 octet) Adresse matérielle, voir la section ARP dans le RFC "Assigned Numbers" ; par ex., '1' = Ethernet 10Mb.
hlen (1 octet) Longueur de l'adresse matérielle (par ex. '6' for Ethernet 10Mb).
hops (1 octet) Mis à zéro par le client, utilisé de manière optionnelle par les agents de relais quand on démarre via un agent de relais
xid (4 octets) Identifiant de transaction, un nombre aléatoire choisit par le client, utilisé par le client et le serveur pour associer les messages et les réponses entre un client et un serveur
secs (2 octets) Rempli par le client, les secondes s'écoulent depuis le processus d'acquisition ou de renouvellement d'adresse du client
flags (2 octets) Drapeaux (voir figure 2).
ciaddr (4 octets) Adresse IP des clients, rempli seulement si le client est dans un état AFFECTÉ, RENOUVELLEMENT ou REAFFECTATION et peut répondre aux requêtes ARP
yiaddr (4 octets) 'votre' (client) adresse IP.
siaddr (4 octets) Adresse IP du prochain serveur à utiliser pour le processus de démarrage ; retournée par le serveur dans DHCPOFFER et DHCPACK.
giaddr (4 octets) Adresse IP de l'agent de relais, utilisée pour démarrer via un agent de relais.
chaddr (16 octets) Adresse matérielle des clients.
sname (64 octets) Nom d'hôte du serveur optionnel, chaîne de caractères terminée par un caractère nul.
fichier (128 octets) Nom du fichier de démarrage, chaîne terminée par un nul ; nom "generic" ou nul dans le DHCPDISCOVER, nom du répertoire explicite dans DHCPOFFER.
options (variable) Champ de paramètres optionnels. Voir le document d'options pour une liste des options définies.

Alloctation d'une adresse réseau

1) le client diffuse un message DHCPDISCOVER sur son réseau local physique. Ce message peut inclure des options qui suggèrent des valeurs pour les adresses réseau et la durée du bail.
2) chaque serveur DHCP peut répondre avec un message DHCPOFFER, qui inclut une adresse réseau valide dans le champ yiadrr, ainsi que d'autres paramètres de configuration.
3) le client choisit parmi les propositions DHCPOFFER reçu par les serveur DHCP celle qui lui convient le mieux, puis diffuse un DHCPREQUEST, en re-spécifiant l'adresse IP choisie et les options de configurations.
4) le serveur répond par un DHCPACK en re-spécifiant l'adresse et les paramètres de configuration pour valider la demande du client.
5) Le client DEVRAIT faire une vérification finale sur les paramètres (généralement un ARP). Si le client détecte que l'adresse est déjà utilisée, il DOIT envoyer un DHCPDECLINE au serveur et relancer le processus de configuration. Le client DEVRAIT attendre un minimum de dix secondes avant de relancer la configuration pour éviter un trafic réseau excessif dans le cas d'un bouclage.

En cas de requête invalide, par exemple un DHCPREQUEST contenant une adresse IP invalide ou que le bail a expiré, le serveur peut diffuser un DHCPNACK.
Si l'adresse IP reçu par un client est déjà utilisée par un autre client du réseau, le client peut envoyer un DHCPDECLINE pour prévenir le serveur DHCP.
Lorsque le client désire libérer l'adresse réseau, il envoie un DHCPRELEASE au serveur.
Le client peut seulement demander les paramètres de configuration locaux avec un message DHCPINFORM. Dans ce cas le client possède déjà une adresse réseau attribuée de manière externe.

Format des messages DHCP

   DHCP utilise UDP comme protocole de transport des messages.

   Un message DHCPDISCOVER contient l'adresse MAC source du client et l'adresse MAC de diffusion en destination (FF:FF:FF:FF:FF:FF). L'adresse IP source est 0.0.0.0 et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Le port source est 68 et le port de destination est 67. Cette diffusion est nécessaire puisque le client ne connait pas le ou les adresses des serveur DHCP.

   Un message DHCPOFFER contient l'adresse MAC source du serveur, l'adresse MAC de destination du client. L'adresse IP source est celle du serveur DHCP, et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Port source 67 et port destination 68. Ce message contient les paramètre de configuration.

   Un message DHCPREQUEST contient l'adresse MAC source du client et l'adresse MAC de diffusion en destination (FF:FF:FF:FF:FF:FF). L'adresse IP source est 0.0.0.0 et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Le port source est 68 et le port de destination est 67. Ce message est toujours en diffusion puisque cela permet à tous les serveur DHCP de recevoir le DHCPREQUEST. Le champ Server Identifier permet de spécifier à quel serveur DHCP est destiné le DHCPREQUEST. La diffusion permet aux autres serveur DHCP d'être avertit que le client décline leur DHCPOFFER. Ce message contient également les paramètres de configuration.

   Un message DHCPACK contient l'adresse MAC source du serveur, l'adresse MAC de destination du client. L'adresse IP source est celle du serveur DHCP, et l'adresse de destination est l'adresse de diffusion 255.255.255.255. Port source 67 et port destination 68. Ce message contient de nouveau les paramètres de configuration. Il permet de confirmer l'attribution de l'adresse réseau. Un client qui se souvient de l'adresse réseau qui lui a déjà été attribuée, peut ignorer l'envoie d'un DHCPDISCOVER et envoie directement un DHCPREQUEST. Lors du renouvellement d'un bail, le client envoie un DHCPREQUEST, mais en unicast, le serveur DHCP lui envoie un DHCPACK confirmant le renouvellement du bail.

Durée et renouvellement du bail

   Le client maintient deux temporisateurs, T1 et T2 qui spécifient les temps auxquels le client essaie d'étendre son bail sur son adresse réseau. T1 est le temps au bout duquel le client entre en état RENOUVELLEMENT et tente de contacter le serveur qui a émis l'adresse réseau du client. T2 est le temps au bout duquel le client entre en état REAFFECTATION et tente de contacter un serveur. T1 DOIT être plus récent que T2, qui doit être plus récent que la date à laquelle expire le bail.

   Au temp T1 ( 0,5*durée_du_bail) le client envoie un message DHCPREQUEST. Si aucun DHCPACK n'arrive avant T2 (0,875*durée_du_bail) le client envoie un DHCPREQUEST. En cas de non réponse le client peut re-émettre un DHCPREQUEST à la moitié du temps restant, jusqu'à un minimum de 60sec.

   Si le bail expire avant que le client ne reçoive un DHCPACK, le client passe en état INIT, il DOIT alors immédiatement stopper tout processus réseau et nécessite une initialisation des paramètres réseau comme si le client n'était pas initialisé.

Relay DHCP

   Comme les clients contactent les serveurs DHCP à l'aide d'une diffusion, dans un inter-réseau, vous devrez théoriquement installer un serveur DHCP par sous-réseau. Si votre routeur prend en charge la RFC 1542, il peut faire office d'agent de relais DHCP, et ainsi relayer les diffusions de demande d'adresse IP des clients DHCP dans chaque sous-réseau.

   Si votre routeur ne prend pas en charge la RFC 1542, une machine serveur peut être configurée comme agent de relais DHCP, il suffira de lui spécifier l'adresse du serveur DHCP. Les demandes des clients DHCP seront relayées vers le serveur DHCP par l'agent de relais DHCP qui transmettra les offres aux clients.

   Après avoir envoyé une trame de broadcast, le client DHCP dialoque avec l'agent de relai DHCP en unicast. L'agent demande une adresse au serveur DHCP dont il connaît l'adresse (2). Le serveur retourne à l'agent une adresse (3) qui est donnée au client DHCP par l'agent (4).

   Le principal problème du service DHCP est la mise à jour des serveurs de noms d'hôtes. Bind sous Linux permet la mise à jour dynamique (RFC 2136) grâce à un serveur "updater" qui peut ajouter ou supprimer dynamiquement des enregistrements de ressources. Il faut pour corriger cela installer un serveur DNS dynamique ( DDNS) qui accepte les inscriptions des clients DHCP.
^
17 mars 2010

htmlpdflatexmanmd




rfc768

rfc768

User Datagram Protocol

   User Datagram Protocol est un protocole de la couche transport. Le rôle de ce protocole est de transmettre des paquets de manière très simplement. Contrairement au protocole TCP, il travaille en mode non connecté. Il n'y a donc aucun moyen de vérifier le bon acheminement des paquets, ni l'ordre dans lequel ils arrivent. Il n'y a pas non plus de contrôle de flux ni de contrôle de congestion, il est considéré comme étant un protocole non fiable. Il possède cependant un checksum pour assurer la validité de chaque datagramme. Un datagramme UDP est encapsulé dans un paquet IP.

Structure d'un segment UDP


Port Source (16 bits)___Port destination (16 bits)
Longueur (16 bits)______Somme de contrôle (16 bits)
_______Données (longueur variable)________________

Port source Indique depuis quel port le paquet a été envoyé
Port de destination indique à quel port est destiné le paquet
Longueur Longueur totale du segment UDP (en-tête + données)). La longueur minimale est donc de 8 octets (taille de l'en-tête)
Somme de contrôle Permet de s'assurer de l'intégrité du paquet reçu. Calculé sur l'ensemble de l'en-tête UDP et des données, mais également sur un pseudo en-tête (extrait de l'en-tête IP)

   Champs utilisés pour le calcul de la somme de contrôle UDP. ( les champs en orange correspondent au pseudo en-tête IP), le tout additionné d'un octet nul, éventuellement, afin que le nombre total d'octets soit pair.


Bits | 0- 7____8 – 15____16 – 23____24 – 31
_____|_________Adresse Source______________
_____|_______Adresse Destination___________
_____|_Zéros_|_Protocole_|__Taille UDP_____
_____|____Port source____|_Port Destination
_____|_______Taille______|____Checksum_____
_____|_______________Data__________________

   UDP est généralement utilisé quand il est nécessaire de transmettre des données rapidement, et où la perte d'une partie de ces données n'a pas grande importance. Il est, par exemple, utilisé dans es transaction TFTP, communications DNS, VOIP etc.....
^
13 mars 2010

htmlpdflatexmanmd




Spanning-Tree Protocol

Spanning-Tree Protocol

Spanning-Tree Protocol and Algorithm

Introduction

   Le Spanning-Tree offre une solution de détection de boucles dans des LAN commutés, et offre également la possibilité de maintenir des redondance alternatives de lien pour prévenir d'éventuelle pannes.

  La première version du Spanning-Tree (STP, 802.1d) demandait un certain temps lors de la reconfiguration de la topologie, il a été remplacé par le Rapid Spanning-Tree Protocol (RSTP 802.1w) et le Multiple Spanning-Tree Protocol (MSTP, 802.1s).

  RSTP est donc une extension de STP, réduisant les temps de (re)configuration de la topologie active à 2sec contre 30 pour STP.

Bridge

   Par Bridge (= pont), on désigne tout appareil permettant de relier 2 segments d'un réseau, cela peut être un routeur, un concentrateur, un commutateur, etc. Étant donné que le STP s'utilise plus généralement sur un commutateur, j'utilise ici le terme commutateur pour représenter le terme Bridge.

Fonctionnement d'un commutateur

   Un commutateur est un appareil possédant au minimum 2 ports et qui permet de diriger les trames Ethernet.

  Chaque port du commutateur transmet et reçoit des trames depuis et vers le LAN sur lequel il est attaché. Un commutateur utilise une base de donnée appelée Filtering Database dans lequel sont enregistrées les adresses MAC associées à chaque port, c'est ce qui permet au commutateur de savoir ou diriger les trames dans un réseau.

  Lorsqu'une trame est reçue avec une adresse MAC de destination qui n'est pas incluse dans sa Filtering Database, le commutateur envoie la trame sur tous ses ports actifs. De même les trames émises en diffusion sont émise sur tous les ports actifs.

  Lorsqu'une boucle est présente, les trames sont re-émises et l'on obtient rapidement une tempête de diffusion. Afin de détecter ces boucles et d'éviter les tempêtes de diffusion, les commutateurs utilisent le protocole et l'algorithme Spanning-Tree.

Les boucles sur un réseau Ethernet

Exemple de boucles réseau

État et rôle des ports

   Chaque port d'un commutateur possède à un instant donné, un état, ainsi qu'un rôle.

  RSTP définit 3 états de port :

        Discarding indique que le port est exclu de la topologie active et n'enregistre pas d'adresse Mac. En fonction de son rôle il peut cependant rester en écoute pour intercepter les information STP.
        Learning est en mode écoute et enregistre les adresses MAC dans la Filtering Database.
        Forwarding correspond à un mode pleinement fonctionnel d'un port, il reçoit et émet des trames.

   RSTP définit également 4 rôle de port :

        Root un commutateur ne peut en avoir qu'un, il s'agit du chemin le plus court vers le commutateur Root. A noter qu'un commutateur Root n'en a pas.
        Designated Par défaut tout port qui n'est ni Root, Alternate ou Backup est un port Designated. Pour faire plus simple, un port Designated est un port qui envoie les trames en direction du port Root d'un commutateur.
        Alternate un port qui possède un chemin vers le port root, mais qui n'a pas été retenu, il s'agit d'une route alternative.
        Backup un port connecté au port Alternate d'un autre commutateur.

Principe du STP

   Pour qu'une topologie active soit construite, un commutateur va être élu Root, chaque commutateur utilisera le chemin le plus court vers ce commutateur pour propager les trames et éviter ainsi les boucles. Une fois la topologie active construite, les commutateurs vont s'envoyer des informations Spanning-Tree à intervalle régulier afin de garantir que la topologie active n'est pas modifiée. L'absence de réception d'informations Spanning-Tree de la part d'un commutateur peut signifier un lien coupé ou une panne, il sera alors nécessaire de redéfinir la topologie active.

  Les informations Spanning-Tree sont diffusées dans des RST BPDU (Bridge Protocol Data Unit). Ces trames sont émises en multicast à une adresse 01-80-C2-00-00-0[0 à F] suivant le type de protocole.

  Ces trames contiennent plusieurs informations :

Nb Octets Champ
2 Protocol Identifier
1 Protocol Version Identifier
1 BPDU Type
1 Flags
8 Root Identifier
4 Root Path Cost
8 Bridge Identifier
2 Port Identifier
2 Message Age
2 Max Age
2 Hello Time
2 Forward Delay
1 Version 1 Length

Protocol Identifier Il prend la valeur 0000 0000 0000 0000, qui identifie le RSTP et les versions antérieures de Spanning-Tree.
Protocol Version Identifier Prend la valeur 0000 0010 (0000 0000 pour les versions précédentes à RSTP)
BPDU Type Ce champ prend la valeur 0000 0010 qui dénote une configuration RST BPDU. (0000 0000 pour un configuration STP)
Flags Ces flags indiquent l'état de la topologie active ainsi que l'état et le rôle du port par lequel est envoyé le BPDU.

Flags STP
Note En jaune, ces flags ne sont disponible qu'à partir de RSTP, il sont inutilisés dans des BPDU compatible STP.
Version 1 Length Prend la valeur 0000 0000, il a été ajouté pour permettre de distinguer des versions future de STP qui pourraient inclure des informations supplémentaire.

Commutateur root

   Pour construire une topologie active sans boucle, un commutateur Racine doit être élu. Par défaut tous les commutateurs se considèrent root, il émettent alors leurs BPDU sur tout leur ports. Tous les commutateurs recevrons donc le BPDU de tous les commutateurs. Ainsi, chaque commutateur saura qui a été élu root. Pour déterminer le commutateur Root, chaque commutateur possède un identifiant. Celui ci est composé de l'adresse MAC du commutateur, plus un Identifiant de priorité, sur 2 octets (32768 par défaut, modifiable par pas de 4096). Cet identifiant est paramétrable et permet d'influencer l'élection du commutateur Root si on le souhaite.

  Cet identifiant est sous la forme ID : MAC

  Le commutateur ayant le plus petit identifiant est alors élu comme commutateur Root. Lorsqu'un commutateur reçoit un BPDU avec un Root Identifier plus petit que celui qu'il a enregistré, il le remplace et le mémorise. Tous les autres commutateurs vont alors converger leur trafic en direction de ce commutateur Root.

Root Path Cost

   Afin de déterminer le plus court chemin vers le commutateur Root, une valeur est calculée par chaque commutateur et transmises aux autres commutateurs directement reliés. Ainsi, chaque commutateur pourra déterminer son chemin le plus court.

  Le commutateur Root aura donc un Root Path Cost de 0. Les autres commutateurs vont donc calculer leur valeur en fonction du Root Path Cost reçu, plus le coût du port, permettant de déterminer quel sera le meilleur chemin vers le commutateur Root.

  Les valeurs correspondantes au niveau de priorité de port sont :

Bandes passante recommandées

Bridge Identifier

   L'identifiant du commutateur, comme nous l'avons vu, se compose d'une valeur de priorité suivie de l'adresse MAC du commutateur.

Port Identifier

   Chaque port possède un numéro unique sur un commutateur. Chaque port possède également un niveau de priorité. Ce niveau de priorité est paramétrable est permet donc de modifier la priorité d'un port administrativement.

  L'identifiant d'un port est donc la somme du niveau de priorité + le numéro du port.

  Le niveau de priorité d'un port va de 0 à 240 (128 par défaut), modifiable par pas de 16.

Message Age

   Ce champ est incrémenté à chaque commutateur traversé. Si ce champ devient supérieur au champ Max Age, le PBDU est détruit.Les 3 paramètres suivant servent à détecter les pannes :

Max Age Fixe le délai à partir duquel un commutateur n'ayant pas reçu de BPDU sur son port racine considère qu'un problème est posé.
Hello Time Lorsque la topologie active a atteint un état stable, le commutateur Root se met alors à émettre des BPDU à intervalle régulier. Ces BPDU sont ensuite retransmis de proche en proche vers tous les autres commutateurs. Ce mécanisme permet de garantir que la topologie active est toujours la même, et permet à un commutateur de détecter une panne lorsqu'il ne reçoit plus de BPDU sur un port au bout d'un temps donné.Par défaut le commutateur Root émet ces BPDU toutes les 2 secondes, il est possible de modifier cette valeur administrativement.
Forward Delay Fixe le délai à respecter pour que le port d'un commutateur passe d'un état bloqué à un état actif.

Cheminement de l'élection Root et de l'arbre

Vecteur de priorité

           Le vecteur de priorité est le vecteur de priorité Spanning-Tree maintenu pour un port donné. Il se présente sous la forme :

  Port priority vector = RootBrigeID : RootPathCost : DesignatedBridgeID : DesignatedPortID : BridgePortID

  Ce vecteur permet de déterminer le rôle de chaque port dont notamment le port root.

  Un commutateur A recevant un message de configuration sur un port PA d'un port désigné PB d'un commutateur B proclamant un Identifiant Root et un RootPathCost de RPCB :

  message priority vector = RB : RPCB : B : PB : A

Diffusion de son BPDU

           Le commutateur A va donc diffuser sur ses autres ports un BPDU en fonction des informations qu'il a reçu. Ainsi, si B est bien Root, il conservera son identifiant, va ajouter son Root Path Cost, son identifiant, et l'identifiant de son port d'émission. Ainsi un commutateur C qui reçoit son BPDU sur un port PC d'un port PA du commutateur A sera :

  message priority vector = RB : RPCB+PPCA : A : PA : PC

  Lorsqu'un commutateur B se proclame Root le vecteur de priorité root sera : B : 0 : B : 0 : 0

  donc son BPDU sera :

  message priority vector = B : 0 : B : PB : PB

Assignation du rôle des ports

   Grâce au vecteur de priorité root, un commutateur est en mesure de déterminer le port le plus proche du commutateur Root. Ce port sera donc son Port Root. Si ce commutateur a d'autres lien vers le commutateur root, mais qui n'ont pas été élus root, ces ports sont des Port Alternate. Ils seront à l'état Disabled.

  Un commutateur dont un port est relié à un port Root est un Port Designated, il est à l'état Forwarding.

  Un commutateur dont le port est relié à un port Alternate est un port Backup, il est à l'état Forwarding.

Détection et changement de la topologie

   Lorsqu'un changement dans la topologie est détectée, de nouveaux messages de type TCN (Topologie Change Notification) sont transmis au travers du réseau pour indiquer qu'il est nécessaire d'opérer les modifications de topologie.

Exemple

Exemple de topologie
   C1 étant le root, il émet toutes les 2sec des BPDU sur ses ports désignés. Ces paquets sont retransmis sur tous les ports désignés des autres commutateurs. Les PBDU sont également transmis sur les ports alternatifs pour indiquer que la connexion existe toujours.

  Si le lien entre C2 et C4 est rompu, les BPDU ne seront plus transmis. Ainsi après le délai MaxAge passé sans avoir reçu de BPDU, C4 va :

        - Considérer que sont port 2 n'est plus son port root.
        - Étant donné qu'il possède un port alternatif, il va le nommer port root.
        - Il vide sont cache MAC associé au port 2.
        - Ce port 2 devient un port désigné.

   puis C3 :

        - Après un délai MaxAge dépassé sans avoir reçu de BPDU, il va décider que sont port 2 ne remplis plus son rôle de port Backup.
        - Il va le passer en port désigné.
        - Il le passe d'abord à l'état d'écoute.
        - Il supprime les entrées MAC de son port Root.
        - Après un premier Forward Delay son port 2 passe à l'état d'apprentissage
        - Puis après un nouveau Forward Delay, le port devient actif.

   C3 ayant vidé son cache associé à son port Root, il transmet l'information à C1, qui à son tour va vider son port 2, et enfin C2 fera de même.

  Une fois fois la topologie active redéfinie, le commutateur Root recommence à émettre des BPDU à intervalle régulier.

Vidage des adresses MAC

   Lorsqu'un changement de topologie opère, certains commutateurs doivent vider les adresses MAC apprise sur certains ports. Ainsi, le port Root de C4, relié au port désigné C2, ne reçoit plus de BPDU, changera son port Root, il lui sera nécessaire de vider les adresse MAC apprise par son ancien port Root. Le port désigné du C2 devra également vider ses adresses MAC associés, puis remonter l'information en direction du commutateur Root, afin que tous les commutateurs intermédiaire vident leur adresses MAC associé à leur port désigné ou root qui menait vers le C4.

MSTP

   MSTP est une variante de RSTP. RSTP est unique sur un commutateur, ainsi lorsque plusieurs vlan existent, il n'est pas possible de mettre en place RSTP sur chaque vlan. MSTP a été conçu pour pouvoir disposer d'un Spanning-Tree par vlan.

Exemple mstp

Problèmes de sécurité lié à STP

   Plusieurs problèmes de sécurités ont été découvert avec STP. Il est ainsi très facile d'émettre des BPDU avec un identifiant de commutateur inférieur au Root, et de décrémenter l'identifiant de priorité toutes les secondes, une fois à 0, on repars à sa valeur initial et on recommence. On crée ainsi une reconfiguration permanente, certains port même, n'arriverons jamais à atteindre un état Forwading, Paralysant une partie du réseau.

   Il existe de nombreuses façon de détourner STP, une attaque des plus redoutable est de créer un MITM. Une machine attaquante est connecté d'un coté sur un commutateur A et de l'autre un commutateur B. Il émet un STP proclamant le Root, de nouvelles élections sont faite, il devient le root, tous les commutateurs convergents vers l'attaquant, il peut ainsi espionner le trafic qui passe entre 2 commutateurs.


        Illustration
----------------------------------------------------------
_______Clients_segment_________________Server_segment_____
.------------------------._________.----------------------.
|__Switch_w/_STP_#1__|------X_X--------|_Switch_w/_STP_#2_|
.____________________._________________'__________________'
__|________________|______________________|_|_____________
__|________________|______________________|_|___.___._____
__|________________|______________________|_|___|___|_____
__|.....___________|___.------.___________|_|___|_==|_____
_.------,__________|__|________|__________|_|___|_==|_____
_|Client_|'________|__|Attacking__________|__\_,|__-|_____
_|_PC____|_________\__|___PC___|_________/______|___|_____
_\------_/__________\_========_,________/_______|___|_____
__======/____________|_________|--------'______-------____
_______________________________________________Server_____

   Il est difficile de détecter des attaques de ce genre. On pourrait par exemple utiliser un IDS qui compare la topologie active avec une topologie de référence, mais cela impliquerai qu'on ne peut pas changer la topologie sans devoir modifier la topologie de référence, de plus une attaque pourrait être menée au même moment que la topologie change, ainsi la topologie de référence serait alors faussée.

   Spanning-Tree devrait donc être désactivé partout où il n'est pas nécessaire. De plus pour améliorer la sécurité, il est préférable d'utiliser des Routeurs, ou des switch/routeurs, de segmenter son réseau et d'utiliser des protocoles comme OSPF. Ce protocole gère bien mieux la topologie du réseau, et la segmentation adéquat du réseau en sous-réseau permet d'éviter de nombreuses attaques, notamment de type MITM.