CCNA 4 CH2

Chapitre 2 - Protocole PPP Page 1 sur 29

CCNA 4 Version 4.0 By NSK

CCNA Exploration - Commutation de réseau local et sans fil

Chapitre 2 - Protocole PPP

2.0-Présentation du Chapitre

Pour entamer la découverte des technologies de réseau étendu, ce chapitre aborde les communications point à point et le protocole point

à point (PPP).

L’une des connexions de réseau étendu les plus répandues est la connexion point à point. Ce type de connexion est utilisé pour connecter

des réseaux locaux à des réseaux étendus de fournisseur de services, et pour connecter des segments de réseau local au sein d’un réseau

d’entreprise. Une connexion point à point réseau local vers réseau étendu est également appelée une connexion série ou une connexion

par ligne louée, car les lignes sont louées auprès d’un opérateur (généralement une compagnie de téléphone) et sont dédiées pour être

utilisées par la société qui loue les lignes. Les entreprises paient pour bénéficier d’une connexion continue entre deux sites distants, et la

ligne est active et disponible en permanence. Les participants doivent parfaitement comprendre comment fonctionnent les liaisons de

communication point à point pour fournir l’accès à un réseau étendu, afin de mieux comprendre, de manière générale, le fonctionnement

des réseaux étendus.

Le protocole PPP fournit des connexions réseau local vers réseau étendu multiprotocoles gérant simultanément les protocoles TCP/IP, IPX

et AppleTalk. Il peut être utilisé sur une paire torsadée, des lignes à fibre optique et des transmissions par satellite. Le protocole PPP assure

le transport sur des liaisons ATM, de relais de trames, RNIS et optiques. Dans des réseaux modernes, la sécurité est une priorité essentielle.

Le protocole PPP vous permet d’authentifier des connexions en utilisant le protocole d’authentification du mot de passe (PAP) ou le

protocole d’authentification à échanges confirmés (Challenge Handshake Authentication Protocol, CHAP), ce dernier étant plus efficace.

Ces protocoles sont présentés dans la quatrième section.

Dans ce chapitre, vous découvrirez également les principaux concepts des communications série et apprendrez comment configurer et

dépanner une connexion série PPP sur un routeur Cisco.

2.1-Liaisons Série Point-à-Point

2.1.1-Présentation des Communications Série

Page 1 :

Comment une communication série fonctionne-t-elle ?

Vous devez savoir que la plupart des ordinateurs possèdent à la fois des ports

série et des ports parallèles. Vous savez également que l’électricité peut se

déplacer selon un débit unique. Pour accélérer le déplacement des bits dans un

fil, il est possible de compresser les données afin de limiter le nombre de bits

nécessaires et donc la durée du déplacement dans le fil, ou de transmettre des

bits simultanément. Les ordinateurs utilisent des connexions parallèles

relativement courtes pour relier des composants internes, mais requièrent des

bus série pour convertir des signaux pour la plupart des communications

externes.Comparons les communications parallèles et les communications série.

Cliquez sur le bouton Série et parallèle pour lancer l’animation.



• Avec une connexion série, les informations circulent sur un fil, un bit de données à la fois. Le connecteur série à 9 broches

présent sur la plupart des PC utilise deux boucles de fil, une dans chaque direction, pour la communication des données, ainsi

que des fils supplémentaires pour contrôler le flux d’informations. Quelle que soit la direction des données, celles-ci circulent

toujours sur un seul fil.

• Une connexion parallèle envoie les bits sur plusieurs fils simultanément. Avec le port parallèle à 25 broches de votre PC, huit fils

porteurs de données acheminent 8 bits simultanément. Étant donné que huit fils peuvent transporter les données, le transfert de

données sur une liaison parallèle est en théorie huit fois plus rapide que sur une connexion série. Ainsi, toujours d’après cette

théorie, une connexion parallèle envoie un octet pendant qu’une connexion série envoie un seul bit.

Cette explication suscite plusieurs questions. Que signifie l’expression « plus rapide en théorie » ? Si la connexion parallèle est plus rapide

que la connexion série, est-elle plus adaptée à la connexion à un réseau étendu ? En réalité, il arrive souvent que des liaisons série puissent

être synchronisées beaucoup plus rapidement que des liaisons parallèles, ce qui leur permet de fournir un débit de données plus élevé, car

deux facteurs affectent les communications parallèles : la distorsion d’horloge et les perturbations.

Cliquez sur le bouton Distorsion d’horloge dans la figure.

Dans une connexion parallèle, il est faux de penser que lorsque 8 bits

quittent un expéditeur au même moment, ils atteindront en même

temps le récepteur. En effet, certains bits arrivent à destination plus

tard que les autres. C’est ce qu’on appelle la distorsion d’horloge.

Contourner ce problème n’est pas chose facile. L’extrémité réceptrice

doit se synchroniser avec l’émetteur, puis attendre que tous les bits

soient arrivés. Le temps requis par le processus de lecture, d’attente,

de verrouillage, d’attente du signal d’horloge et de transmission des

8 bits s’ajoute à la durée totale de la transmission. Dans le cadre des

communications parallèles, un verrou est un système de stockage de

données servant à stocker des informations dans des systèmes

logiques séquentiels. Plus le nombre de fils utilisés est important et la

connexion distante, plus le problème est complexe et le retard long.

Cette étape de verrouillage ralentit la transmission parallèle bien au-delà des valeurs escomptées.

Ce facteur ne s’applique pas aux liaisons série, car la plupart de ces liaisons ne requièrent pas de verrouillage. Les connexions série

nécessitent moins de fils et de câbles. Elles occupent également moins de place et peuvent être plus efficacement isolées des interférences

dues à d’autres fils et câbles.

Cliquez sur le bouton Interférences dans la figure.

Les fils parallèles sont regroupés physiquement dans un câble

parallèle, et les signaux peuvent se perturber mutuellement. Pour

éviter que des interférences ne se produisent sur les fils, des mesures

supplémentaires devront être prises, notamment à des fréquences

plus élevées. Les bus série sur des ordinateurs, y compris des routeurs,

permettent de compenser les interférences avant la transmission des

bits. Parce qu’ils possèdent moins de fils, les câbles série produisent

moins d’interférences et les périphériques réseau transmettent des

communications série à des fréquences plus élevées et plus efficaces.

Dans la plupart des cas, l’implémentation des communications série

est sensiblement moins chère. Elles utilisent en effet moins de fils, des

câbles moins onéreux et moins de broches de connecteur.



Page 2 :

Normes de communication série

Toutes les communications grande distance et la plupart des

réseaux informatiques utilisent des connexions série, car le coût

élevé des câbles et les problèmes de synchronisation rendent les

connexions parallèles peu désirables. L’avantage le plus attrayant

est la simplicité du câblage. Par ailleurs, les câbles série peuvent

être plus longs que les câbles parallèles, car le niveau d’interaction

(interférences) entre les conducteurs du câble est moins

important. Dans ce chapitre, nous limiterons notre étude aux

communications série utilisées pour connecter des réseaux locaux

à des réseaux étendus.

La figure ci-contre est une représentation simple d’une

communication série. Des données sont encapsulées par le

protocole de communications utilisé par le routeur expéditeur. La

trame encapsulée est envoyée sur un support de transmission physique vers le réseau étendu. Plusieurs méthodes permettent de traverser

le réseau étendu, mais le routeur récepteur utilise le même protocole de communications pour désencapsuler la trame à son arrivée.

Il existe plusieurs normes de communication série, chacune utilisant une méthode de transmission différente. Trois normes principales de

communication série affectent les connexions réseau local vers réseau étendu :

• RS-232 - La plupart des ports série d’ordinateurs personnels sont conformes à la norme RS-232C ou aux normes plus récentes RS-

422 et RS-423. Des connecteurs à 9 broches et à 25 broches sont utilisés. Un port série est une interface multifonction qui peut

être utilisée pour la plupart des périphériques, y compris des modems, des souris et des imprimantes. De nombreux

périphériques réseau utilisent des connecteurs RJ-45 qui respectent également la norme RS-232. La figure ci-contre affiche un

exemple de connecteur RS-232.

• V.35 - Utilisée généralement pour des communications modem vers multiplexeur, cette norme de l’UIT pour les échanges de

données synchrones et à haut débit combine la bande passante de plusieurs circuits téléphoniques. Aux États-Unis, V.35 est la

norme d’interface utilisée par la plupart des routeurs et des unités DSU connectés à des opérateurs T1. Les câbles V.35 sont des

assemblages série à haut débit conçus pour prendre en charge des débits de données et une connectivité plus élevés entre des

équipements terminal de traitement de données (ETTD) et des équipements de communication de données (DCE), sur des lignes

numériques. Vous trouverez plus d’informations sur les ETTD et les DCE plus loin dans cette section.

• HSSI - La norme HSSI (High-Speed Serial Interface, interface série à haut débit) prend en charge des débits de transmission allant

jusqu’à 52 Mbits/s. Les ingénieurs utilisent cette norme pour connecter des routeurs sur des réseaux locaux à des réseaux

étendus, sur des lignes à haut débit telles que des lignes T3. Ils utilisent également cette norme pour fournir une connectivité à

haut débit entre des réseaux locaux, grâce à Token Ring ou Ethernet. HSSI est une interface ETTD/DCE développée par Cisco

Systems et T3plus Networking pour répondre à un besoin en communications à haut débit sur des liaisons de réseau étendu.

Cliquez sur le bouton RS-232 dans la figure.

Outre le fait d’utiliser des méthodes de transmission

différentes, chacune de ces normes utilise des types de

câbles et de connecteurs différents. Chaque norme

joue un rôle différent dans une topologie réseau local

vers réseau étendu. Bien que ce cours n’aborde pas en

détail les systèmes de broches des normes V.35 et HSSI,

un coup d’œil rapide à un connecteur RS-232 à

9 broches utilisé pour connecter un PC à un modem

permet d’illustrer le concept. Les câbles V.35 et HSSI

sont évoqués plus en détail dans une rubrique

ultérieure.



• Broche 1 - Détection du porteur de données (DCD) indique que le porteur des données de transmission est activé (ON).

• Broche 2 - La broche de réception (RXD) transporte des données à partir d’un périphérique série vers l’ordinateur.

• Broche 3 - La broche de transmission (TxD) transporte des données à partir de l’ordinateur vers le périphérique série.

• Broche 4 - Terminal de données prêt (DTR) indique au modem que l’ordinateur est prêt pour la transmission.

• Broche 5- Terre.

• Broche 6 - Modem prêt (DSR) est similaire à DTR. Il indique que le modem est activé (ON).

• Broche 7 - La broche RTS demande l’autorisation d’envoyer des données à un modem.

• Broche 8 - Le périphérique série utilise la broche Clear to Send (Prêt à émettre, PAE) pour accuser réception du signal RTS en

provenance de l’ordinateur. Dans la plupart des cas, les broches RTS et CTS sont activées (ON) en permanence lors de la session

de communication.

• Broche 9 - Un modem de réponse automatique utilise l’indicateur d’appel (RI) pour signaler la réception d’un signal d’appel

téléphonique.

Les broches DCD et RI sont disponibles uniquement lors des connexions à un modem. Ces deux lignes sont rarement utilisées car la plupart

des modems transmettent des informations d’état à un PC lorsqu’un signal porteur est détecté (si une connexion est établie à un autre

modem) ou lorsque le modem reçoit un signal d’appel en provenance de la ligne téléphonique.

2.1.2-Multiplexage Temporel

Page 1 :

Multiplexage temporel

Les Laboratoires Bell ont inventé le multiplexage temporel (TDM)

afin de maximiser la quantité de trafic vocal transporté sur un

support. Avant l’arrivée du multiplexage, chaque appel

téléphonique devait disposer de sa propre liaison physique. Cette

solution était donc coûteuse et limitée en termes d’évolutivité. Le

multiplexage temporel divise la bande passante d’une liaison unique

en canaux séparés ou tranches de temps. Il transmet deux ou

plusieurs canaux sur la même liaison en allouant un intervalle de

temps différent (tranche de temps) pour la transmission de chaque

canal. Ainsi, les canaux utilisent la liaison à tour de rôle.

Le multiplexage temporel est un concept relatif à la couche physique. Il ne tient pas compte de la nature des informations multiplexées sur

le canal de sortie. Le multiplexage temporel est indépendant du protocole de couche 2 qui a été utilisé par les canaux d’entrée.

Pour expliquer le multiplexage temporel, effectuons une analogie avec le trafic circulant sur une autoroute. Pour acheminer vers une ville

spécifique le trafic circulant sur quatre routes distinctes, vous pouvez envoyer tout le trafic sur une voie si les routes desservant l’autoroute

offrent les mêmes conditions et que le trafic soit synchronisé. Ainsi, si chacune des quatre routes amène une automobile sur l’autoroute

principale toutes les quatre secondes, une automobile arrive sur l’autoroute toutes les secondes. Tant que la vitesse de toutes les

automobiles est synchronisée, aucune collision ne se produit. À la destination, l’inverse se produit et les automobiles quittent l’autoroute

et sont acheminées vers les routes locales par le même mécanisme synchrone.

Le même principe est utilisé dans le multiplexage temporel lors de l’envoi de données sur une liaison. Le multiplexage temporel augmente

la capacité de la liaison de transmission en fractionnant le temps en intervalles plus petits afin que la liaison transporte les bits en

provenance de plusieurs sources d’entrée, ce qui a pour effet d’augmenter le nombre de bits transmis par seconde. Grâce au multiplexage

temporel, l’expéditeur et le récepteur savent tous les deux exactement quel signal est envoyé.

Dans notre exemple, un multiplexeur (MUX) situé au niveau du transmetteur accepte trois signaux distincts. Le multiplexeur fractionne

chaque signal en segments. Il place ensuite chaque segment dans un canal unique en insérant chaque segment dans une tranche de temps.

Un multiplexeur situé à l’extrémité réceptrice assemble le flux de multiplexage temporel pour reconstituer les trois flux de données

distincts, en se basant uniquement sur la durée d’arrivée de chaque bit. Une technique appelée entrelacement de bits conserve le nombre

et la séquence de bits pour chaque transmission spécifique, de sorte qu’ils puissent être de nouveau assemblés rapidement et

efficacement pour reprendre leur format initial à leur arrivée. L’entrelacement d’octets offre les mêmes fonctions, mais chaque octet

comprenant huit bits, le processus requiert une tranche de temps plus grande ou plus longue.



Page 2 :

Multiplexage temporel statistique

Dans une autre analogie, comparons le multiplexage temporel à un

train de 32 wagons. Chacun d’entre eux appartient à une société de

routage différente et chaque jour, le train part avec ses 32 wagons.

Si l’une des sociétés a des produits à expédier, le wagon est chargé.

Si la société n’a rien à envoyer, le wagon reste vide, mais fait

toujours partie du train. Le transport de conteneurs vides n’est pas

très efficace. Le multiplexage temporel présente la même lacune

lorsque le trafic est intermittent, car la tranche de temps est allouée

même si le canal n’a pas de données à transmettre.

Le multiplexage temporel statistique (STDM) a été développé pour

combler cette lacune. Il utilise une longueur de tranche de temps variable permettant à des canaux de convoiter les espaces disponibles. Il

utilise une mémoire tampon qui stocke temporairement les données lors des périodes de trafic intense. Grâce à ce système, le

multiplexage temporel statistique ne gaspille pas de temps de ligne à haut débit avec des canaux inactifs. Cette technique requiert que

chaque transmission transporte des informations d’identification (un identificateur de canal).

Page 3 :

Exemples de multiplexage temporel - RNIS et SONET

RNIS est un exemple de technologie utilisant le multiplexage temporel

synchrone. RNIS accès de base (BRI) comporte trois canaux, à savoir

deux canaux B à 64 Kbits/s (B1 et B2) et un canal D à 16 Kbits/s. Le

multiplexage temporel présente neuf tranches de temps, reprises dans

la séquence illustrée dans la figure.

À une plus grande échelle, le secteur des télécommunications utilise les

normes SONET ou SDH pour le transport optique de données de

multiplexage temporel. La norme SONET utilisée en Amérique du Nord,

et la norme SDH utilisée partout ailleurs, sont deux normes étroitement

liées qui spécifient des paramètres d’interface, des débits, des formats

de tramage, des méthodes de multiplexage et une gestion pour le

multiplexage temporel synchrone via des fibres.

Cliquez sur le bouton SONET dans la figure.

La figure affiche un exemple de multiplexage temporal statistique.

SONET/SDH accepte n flux de bits, les multiplexe et module le signal de

manière optique en l’envoyant au moyen d’un dispositif émettant un

signal lumineux, via la fibre à un débit de données équivalent à (débit

entrant) x n. Le trafic arrivant sur le multiplexeur SONET en provenance

des quatre emplacements à 2,5 Gbits/s est envoyé sous forme de flux

unique à un débit de 4 x 2,5 Gbits/s, soit 10 Gbits/s. Ce principe est

démontré dans la figure, qui illustre une augmentation du débit par un

facteur de quatre par tranche de temps T.



Cliquez sur le bouton DS0 dans la figure.

L’unité d’origine utilisée pour multiplexer des appels téléphoniques est

64 Kbits/s, ce qui représente un appel téléphonique. On parle de DS0

(Digital Signal Level Zero, ligne logique DS-0). En Amérique du Nord, 24

unités DS0 sont multiplexées grâce au multiplexage temporel en un signal

de débit plus élevé avec une vitesse agrégée de 1,544 Mbits/s pour la

transmission sur des lignes T1. Partout ailleurs, 32 unités DS0 sont

multiplexées pour la transmission E1 à 2,048 Mbits/s.

La hiérarchie de niveau de signal pour le multiplexage d’appels

téléphoniques est illustrée dans le tableau. Notez que même s’il

est courant de désigner une transmission à 1,544 Mbits/s par le

terme T1, il est plus correct de parler de DS1.

Cliquez sur le bouton Hiérarchie porteuse T dans la figure.

La porteuse T désigne le groupement de plusieurs DS0. Par

exemple, un T1 = 24 DS0, un T1C = 48 DS0 (ou 2 T1), etc. La figure

illustre un exemple de hiérarchie d’infrastructure porteuse T. La

hiérarchie porteuse E est similaire.

2.1.3- Point de démarcation

Point de démarcation

Avant la déréglementation appliquée en Amérique de Nord et

dans d’autres pays, les compagnies de téléphone détenaient une

boucle locale, qui comprenait le câblage et l’équipement dans les

locaux des clients. Or, la déréglementation oblige désormais les

compagnies de téléphone à dégrouper leur infrastructure de

boucle locale pour permettre à d’autres fournisseurs d’offrir des

équipements et des services. Il s’est alors avéré nécessaire de

délimiter la partie du réseau appartenant à la compagnie de

téléphone et celle appartenant au client. Ce point de délimitation

est le point de démarcation. Le point de démarcation désigne

l’endroit où votre réseau communique avec le réseau détenu par

une autre organisation. Dans la terminologie téléphonique, il s’agit

de l’interface située entre des équipements d’abonné (CPE) et des

équipements de fournisseur de services réseau. Le point de démarcation est le point sur le réseau où la responsabilité du fournisseur de

services prend fin.

L’exemple ci-contre présente un scénario RNIS. Aux États-Unis, un fournisseur de services fournit la boucle locale dans les locaux du client

et le client fournit l’équipement actif, tel que l’unité CSU/DSU (Channel Service Unit/Data Service Unit) sur laquelle la boucle locale se

termine. Cette terminaison est souvent située dans une armoire de télécommunications, le client étant responsable de la maintenance, du

remplacement ou de la réparation de l’équipement. Dans les autres pays du monde, l’unité de terminaison de réseau (NTU,Network

Terminating Unit) est fournie et gérée par le fournisseur de services. Ceci permet au fournisseur de services de gérer et de dépanner la

boucle locale de façon réactive, car le point de démarcation se situe après l’unité de terminaison de réseau. Le client connecte un

équipement d’abonné, tel qu’un routeur ou un équipement d’accès au réseau Frame Relay, à l’unité de terminaison de réseau par

l’intermédiaire d’une interface série V.35 ou RS-232.



2.1.4-ETTD et DCE

Page 1 :

ETTD-DCE

Dans le cadre de la connexion au réseau étendu, une connexion

série possède un périphérique ETTD à une extrémité de la

connexion et un périphérique DCE à l’autre extrémité. La

connexion entre les deux périphériques DCE est le réseau de

transmission du fournisseur du réseau étendu. Dans le cas

présent :

• L’équipement d’abonné, généralement un routeur, constitue l’ETTD. Il peut s’agir également d’un terminal, d’un ordinateur,

d’une imprimante ou d’un télécopieur s’il se connecte directement au réseau du fournisseur de services.

• Le DCE, généralement un modem ou une unité CSU/DSU, est l’équipement servant à convertir les données utilisateur de l’ETTD

en une forme compatible avec la liaison de transmission du fournisseur de services de réseau étendu. Le signal est reçu par le

DCE distant, qui le décode en une séquence de bits. Le DCE distant signale ensuite cette séquence à l’ETTD distant.

L’EIA (Electronics Industry Association) et l’ITU-T (International Telecommunication Union Telecommunications Standardization Sector) ont

été les plus actifs dans le développement de normes qui permettent à des ETTD de communiquer avec des DCE. L’EIA désigne le DCE

comme l’équipement de communication de données, tandis que l’ITU-T désigne le DCE comme l’équipement de terminaison de circuit de

données.

Page 2 :

Normes de câble

À l’origine, le concept de DCE et de ETTD était basé sur deux types

d’équipement : l’équipement de terminal qui a généré ou reçu des

données et l’équipement de communication qui a simplement relayé les

données. Lors du développement de la norme RS-232, plusieurs raisons

ont justifié la nécessité de câbler différemment des connecteurs RS-232

à 25 broches sur ces deux types d’équipement. Même si ces raisons ne

s’appliquent plus, deux types de câbles existent encore aujourd’hui : un

pour la connexion reliant un ETTD à un DCE, et un autre pour la

connexion de deux ETTD directement entre eux.

L’interface ETTD/DCE d’une norme particulière définit les spécifications ci-dessous :

• Mécanique/physique - Nombre de broches et type de

connecteur

• Électrique - Définit les niveaux de tension pour 0 et 1

• Fonctionnelle - Spécifie les fonctions exécutées en

attribuant des significations à chacune des lignes de

transmission de l’interface

• Procédurale - Spécifie la séquence d’événements pour la

transmission des données

Cliquez sur le bouton Câbles série dans la figure.

La norme RS-232 d’origine a uniquement défini la connexion

d’ETTD à des DCE, qui étaient des modems. Cependant, si vous

connectez deux ETTD, par exemple deux ordinateurs ou deux

routeurs dans le TP, un câble spécial appelé un null-modem

élimine la nécessité d’utiliser un DCE. En d’autres termes, les deux périphériques peuvent être connectés sans modem. Une connexion null-

modem est une méthode de communication permettant de connecter directement deux ETTD, tels qu’un ordinateur, un terminal ou une



imprimante, grâce à un câble série RS-232. Avec une connexion par câble null-modem, les lignes de transmission (Tx) et de réception (Rx)

sont croisées, comme illustré dans la figure.

Cliquez sur le bouton DB-60 dans la figure.

Le câble de connexion de l’ETTD au DCE est un câble de

transition série blindé. L’extrémité routeur du câble de transition

série blindé peut être un connecteur DB-60, qui se branche dans

le port DB-60 d’une carte d’interface de réseau étendu série.

L’autre extrémité du câble peut ensuite recevoir le connecteur

approprié à la norme utilisée. Le fournisseur du réseau étendu

ou l’unité CSU/DSU dicte généralement le type de câble requis.

Les équipements Cisco prennent en charge les normes série

EIA/TIA-232, EIA/TIA-449, V.35, X.21 et EIA/TIA-530.

Cliquez sur le bouton Smart Serial dans la figure.

Pour prendre en charge des densités de port plus élevées avec un

facteur de forme réduit, Cisco a créé le câble Smart Serial (série

intelligent). L’extrémité routeur du câble Smart Serial est un

connecteur à 26 broches considérablement plus compact que le

connecteur DB-60.

Cliquez sur le bouton Entre des routeurs dans la figure.

Lorsqu’un câble null-modem est utilisé, gardez à l’esprit que les

connexions synchrones requièrent un signal d’horloge. Un

périphérique externe peut générer le signal, ou l’un des ETTD

peut générer le signal d’horloge. Lorsque qu’un ETTD et un DCE

sont connectés, le port série sur un routeur est l’extrémité ETTD

de la connexion par défaut, et le signal d’horloge est

généralement fourni par une unité CSU/DSU ou un DCE similaire.

Cependant, lorsqu’un câble null-modem est utilisé dans une

connexion entre des routeurs, l’une des interfaces série doit être

configurée en tant qu’extrémité de DCE pour fournir le signal

d’horloge pour la connexion.

Page 3 :

Conversion parallèle vers série

L’utilisation des termes ETTD et DCE dépend de la partie du

réseau observée. RS-232C est la norme recommandée décrivant

l’interface physique et le protocole pour des communications de

données série à bas débit, entre des ordinateurs et des

périphériques associés. L’EIA avait à l’origine défini la norme RS-

232C pour des téléscripteurs. L’ETTD est l’interface RS-232C

qu’un ordinateur utilise pour échanger des données avec un

modem ou un autre périphérique série. Le DCE est l’interface

RS-232C qu’un modem ou un périphérique série similaire utilise

pour échanger des données avec l’ordinateur.



Par exemple, votre PC utilise généralement une interface RS-232C pour communiquer et échanger des données avec des périphériques

série connectés tels qu’un modem. La carte-mère de votre PC possède également une puce UART (Universal Asynchronous

Receiver/Transmitter, émetteur-récepteur asynchrone universel). Les données de votre PC circulant le long de circuits parallèles, la puce

UART convertit les groupes de bits parallèles en flux de bits série. Pour travailler plus rapidement, une puce UART possède des tampons qui

lui permettent de mettre en mémoire des données lors du traitement de données quittant le port série. La puce UART est l’agent ETTD de

votre PC et communique avec le modem ou un autre périphérique série, qui, selon la norme RS-232C, comporte une interface

complémentaire appelée interface DCE.

2.1.5-Encapsulation HDLC

Page 1 :

Protocoles d’encapsulation de réseau étendu

Sur chaque connexion de réseau étendu, des données sont encapsulées

dans des trames avant d’atteindre la liaison de réseau étendu. Pour

s’assurer que le protocole correct est utilisé, vous devez configurer le

type d’encapsulation de couche 2 approprié. Le choix du protocole

dépend de la technologie de réseau étendu et de l’équipement de

communication. La figure ci-contre affiche les protocoles de réseau

étendu les plus utilisés et les situations dans lesquelles ils sont utilisés.

Voici une description rapide de chacun d’eux :

• HDLC - Type d’encapsulation par défaut sur des connexions point à point, des liaisons dédiées et des connexions à commutation

de circuits lorsque la liaison utilise deux périphériques Cisco. HDLC sert maintenant de base au protocole PPP synchrone utilisé

par de nombreux serveurs pour se connecter à un réseau étendu, le plus souvent Internet.

• PPP - Fournit des connexions entre des routeurs et entre un hôte et un réseau au moyen de circuits synchrones et asynchrones.

Le protocole PPP fonctionne avec plusieurs protocoles de couche réseau, tels qu’IP et le protocole IPX (Internetwork Packet

Exchange, échange de paquets entre réseaux). Le protocole PPP possède également des mécanismes intégrés de sécurité, tels

que PAP et CHAP. Ce chapitre est quasiment entièrement consacré au protocole PPP.

• Serial Line Internet Protocol (SLIP) - Protocole standard pour les connexions série point à point, qui utilise TCP/IP. SLIP a été

largement remplacé par PPP.

• X.25/Procédure d’accès en mode équilibré (Link Access Procedure, Balanced, LAPB) - Norme d’ITU-T qui définit comment

maintenir des connexions entre ETTD et DCE pour permettre l’accès à distance à des terminaux et la communication entre

ordinateurs dans un réseau public de données. X.25 spécifie le protocole LAPB, un protocole de couche liaison de données. X.25 a

précédé le relais de trames.

• Frame Relay - Protocole standard commuté de commutation de couche liaison de données qui gère de multiples circuits virtuels.

Le relais de trames est la génération suivante après X.25. Le relais de trames élimine certains des processus fastidieux (tels que la

correction des erreurs et le contrôle de flux) employés dans X.25. Le chapitre suivant est consacré au relais de trames.

• ATM - Norme internationale en matière de relais de cellules, selon laquelle des périphériques envoient des types de services

multiples (tels que la transmission de la voix, des données ou des vidéos) dans des cellules de longueur fixe (53 octets). Les

cellules de longueur fixe permettent au traitement d’avoir lieu au niveau matériel, réduisant ainsi les délais d’acheminement. Le

mode ATM exploite les supports de transmission à haut débit, tels que E3, SONET et T3.

Page 2 :

Encapsulation HLDC

HDLC est un protocole de couche liaison de données synchrone orienté-binaire développé par l’ISO (Organisation internationale de

normalisation). La norme actuelle pour HDLC est ISO 13239. HDLC a été développé à partir de la norme SDLC (Synchronous Data Link

Control, contrôle de liaisons de données synchrones) proposée dans les années 1970. HDLC fournit des services avec connexion et sans

connexion.

Il utilise une transmission série synchrone offrant des communications sans erreurs entre deux points. Il définit une structure de tramage

de couche 2 permettant un contrôle de flux et des erreurs, au moyen d’accusés de réception. Chaque trame présente le même format,

qu’il s’agisse d’une trame de données ou d’une trame de contrôle.



Lorsque vous souhaitez transmettre des trames sur des liaisons

synchrones ou asynchrones, gardez à l’esprit que ces liaisons ne

disposent pas de mécanismes permettant de marquer la fin ou le

début des trames. HDLC utilise un délimiteur de trame, ou

indicateur, pour marquer le début et la fin de chaque trame.

Cisco a développé une extension du protocole HLDC visant à

résoudre l’incapacité de prendre en charge plusieurs protocoles.

Bien que Cisco HLDC (également appelé cHDLC) soit une norme

propriétaire, Cisco a permis à de nombreux fournisseurs

d’équipement de l’implémenter. Les trames Cisco HDLC

comprennent un champ permettant d’identifier le protocole

réseau encapsulé. La figure ci-contre compare le protocole HLDC

au protocole Cisco HLDC.

Cliquez sur le bouton Types de trame HLDC dans la figure.

HDLC définit trois types de trame, chacune présentant un format

de champ de contrôle différent. Les descriptions suivantes

résument les champs illustrés dans la figure.

Indicateur - Le champ d’indicateur initie le contrôle des erreurs

et y met fin. La trame démarre et se termine toujours par un

champ d’indicateur à 8 bits. La configuration binaire est

01111110. Comme ce motif est susceptible de survenir dans les

données mêmes, le système HDLC expéditeur insère toujours un

bit 0 tous les cinq 1 du champ de données, de telle sorte qu’en

pratique, la séquence de l’indicateur peut seulement survenir aux

extrémités de la trame. Le système récepteur supprime les bits

insérés. Quand les trames sont transmises de façon consécutive,

l’indicateur de fin de la première trame sert d’indicateur de début de la suivante.

Adresse - Le champ d’adresse comprend l’adresse HDLC de la station secondaire. Cette adresse peut contenir une adresse spécifique, une

adresse de groupe ou une adresse de diffusion. Une adresse principale est une source ou une destination de communication, qui élimine le

besoin d’inclure l’adresse de la station primaire.

Contrôle - Le champ de contrôle utilise trois formats différents, selon le type de trame HDLC utilisé :

• Trame d’information (I) : les trames d’information transportent des informations de couche supérieure et certaines informations

de contrôle. Cette trame envoie et reçoit des numéros d’ordre, et le bit d’interrogation effectue le contrôle de flux et des erreurs.

Le numéro d’ordre d’envoi désigne le numéro de la trame suivante à envoyer. Le numéro d’ordre de réception fournit le numéro

de la trame suivante à recevoir. L’expéditeur et le récepteur s’occupent de la maintenance des numéros d’ordre d’envoi et de

réception. Une station primaire utilise le bit d’interrogation pour indiquer à la station secondaire si une réponse immédiate est

requise. Une station secondaire utilise le bit d’interrogation pour indiquer à la station primaire si la trame actuelle est la dernière

de sa réponse en cours.

• Trame de supervision (trame S) : les trames S fournissent des informations de contrôle. Une trame S peut demander et suspendre

la transmission, signaler un état et accuser réception de trames d’information. Les trames S ne présentent pas de champ

d’informations.

• Trame non-numérotée (trame U) : les trames U prennent en charge des fonctions de contrôle et ne sont pas séquencées. Une

trame U peut être utilisée pour initialiser des stations secondaires. Selon la fonction de la trame U, son champ de contrôle

comporte 1 ou 2 octets. Certaines trames U présentent un champ d’informations.

Protocole (utilisé uniquement dans Cisco HDLC) - Ce champ spécifie le type de protocole encapsulé dans la trame (par exemple 0x0800

pour IP).

Données - Le champ de données comprend une unité d’informations de chemin (PIU) ou des informations d’identification d’échange (XID).



Séquence de contrôle de trame (FCS) - La séquence de contrôle de trame précède le délimiteur d’indicateur de fin, il s'agit généralement

d'un calcul de contrôle par redondance cyclique (CRC). Le calcul CRC est de nouveau effectué dans le récepteur. Si le résultat est différent

de la valeur contenue dans la trame d’origine, on suppose qu’une erreur s’est produite.

2.1.6- Configuration de l’encapsulation HDLC

Configuration de l’encapsulation HDLC

Cisco HDLC est la méthode d’encapsulation par défaut utilisée par les

périphériques Cisco sur des lignes série synchrones.

Vous utilisez Cisco HDLC en tant que protocole point à point sur des

lignes louées entre deux périphériques Cisco. Si vous vous connectez à

un périphérique non Cisco, utilisez le protocole PPP synchrone.

Si la méthode d’encapsulation par défaut a été modifiée, utilisez la commande encapsulation hdlc en mode privilégié pour réactiver HDLC.

Deux étapes sont nécessaires pour activer l’encapsulation HDLC :

Étape 1. Passez en mode de configuration d’interface de l’interface série.

Étape 2. Entrez la commande encapsulation hdlc pour spécifier le protocole d’encapsulation de l’interface.

2.1.7-Dépannage d’une interface Série

Page 1 :

La sortie de la commande show interfaces serial présente des

informations spécifiques des interfaces série. Quand HDLC est

configuré, « Encapsulation HDLC » doit apparaître dans la sortie,

comme indiqué dans la figure.

Cliquez sur le bouton États possibles dans la figure.

La commande show interface serial renvoie un des cinq états

possibles. Vous pouvez identifier l’un des cinq états suivants

signalant un problème dans la ligne d’état de l’interface :

Cliquez sur le bouton État dans la figure.

• L’interface série x est désactivée et le protocole de ligne

est désactivé (Serial x is down, line protocol is down)

• L’interface série x est activée et le protocole de ligne est

désactivé (Serial x is up, line protocol is down)

• L’interface série x est activée et le protocole de ligne est

activé (en boucle) (Serial x is up, line protocol is up

(looped))

• L’interface série x est activée et le protocole de ligne

désactivé (Serial x is up, line protocol is down (disabled))

• L’interface série x est désactivée pour des raisons

d’administration (administratively down) et le protocole de

ligne est désactivé (Serial x is administratively down, line

protocol is down)



Cliquez sur le bouton Contrôleurs dans la figure.

La commande show controllers est un autre outil de diagnostic

important pour le dépannage des lignes série. La sortie

renvoyée indique l’état des canaux de l’interface et signale la

présence ou l’absence d’un câble. Dans la figure, un câble DCE

V.35 est relié à l’interface série 0/0. La syntaxe de la commande

est variable, en fonction de la plateforme. Les routeurs de la

série Cisco 7000 utilisent une carte contrôleur cBus pour

connecter des liaisons série. Avec ces routeurs, utilisez la

commande show controllers cbus.

Si la sortie de l’interface électrique apparaît comme UNKNOWN,

au lieu de V.35, EIA/TIA-449, ou un autre type d’interface

électrique, un câble mal connecté est probablement à l’origine

du problème. Il est également possible que le câblage interne

de la carte présente un problème. Si l’interface électrique est

inconnue, l’écran correspondant à la commande show interfaces serial<x> montre que l’interface et le protocole de ligne sont désactivés.

2.2-Concepts du Protocole PPP

2.2.1-Présentation du Protocole PPP

Qu’est-ce que le protocole PPP ?

HDLC est la méthode d’encapsulation série par défaut lorsque vous

connectez deux routeurs Cisco. Avec un champ de type de protocole

supplémentaire, la version Cisco de HDLC est propriétaire. Par

conséquent, Cisco HDLC fonctionne uniquement avec d’autres

périphériques Cisco. Cependant, lorsque vous souhaitez vous connecter à

un routeur non Cisco, vous devez utiliser l’encapsulation PPP.

L’encapsulation PPP a été conçue soigneusement pour garantir la

compatibilité avec la plupart du matériel de prise en charge utilisé. PPP

encapsule des trames de données pour les transmettre sur des liaisons

physiques de couche 2. Il établit une connexion directe au moyen de

câbles série, de lignes téléphoniques, de lignes agrégées, de téléphones

portables, de liaisons radio spécialisées ou de liaisons à fibres optiques.

L’utilisation du protocole PPP présente de nombreux avantages, notamment le fait qu’il n’est pas propriétaire. Il inclut en outre de

nombreuses fonctionnalités qui ne sont pas disponibles dans HDLC :

• La fonctionnalité de gestion de qualité de la liaison contrôle la qualité de la liaison. Si un nombre trop important d’erreurs est

détecté, le protocole PPP désactive la liaison.

• Le protocole PPP prend en charge l’authentification PAP et CHAP. Cette fonctionnalité est décrite et mise en pratique dans une

section ultérieure.

PPP comprend trois composants principaux :

• Le protocole HDLC pour l’encapsulation de datagrammes sur des liaisons point à point.

• Le protocole de contrôle de liaison extensible (LCP, Link Control Protocol) pour établir, configurer et tester la connexion des

liaisons de données.

• Une famille de protocoles de contrôle réseau (NCP, Network Control Protocol) pour établir et configurer différents protocoles de

couche réseau. PPP permet l’utilisation simultanée de plusieurs protocoles de couche réseau. Certains des protocoles NCP les

plus courants sont TCP/IP (Transmission Control Protocol/Internet Protocol), le protocole de contrôle Appletalk (Appletalk

Control Protocol), le protocole de contrôle Novell IPX (Novell IPX Control Protocol), le protocole de contrôle Cisco Systems (Cisco

Systems Control Protocol), le protocole de contrôle SNA (SNA Control Protocol) et le protocole de contrôle de compression

(Compression Control Protocol).



2.2.2-Architecture en Couches PPP

Page 1 :

Architecture PPP

Une architecture en couches est un modèle, une conception ou un plan

d’action logique facilitant la communication entre des couches

interconnectées. La figure ci-contre associe l’architecture en couches du

protocole PPP au modèle OSI (Open System Interconnection). PPP et

OSI partagent la même couche physique, mais le protocole PPP répartit

différemment les fonctions LCP et NCP.

Au niveau de la couche physique, vous pouvez configurer le protocole

PPP sur une plage d’interfaces diverses, notamment :

• série asynchrone ;

• série synchrone ;

• HSSI ;

• RNIS.

PPP fonctionne sur toutes les interfaces ETTD/DCE (RS-232-C, RS-422, RS-423 ou V.35). La seule obligation imposée par le protocole PPP est

un circuit bidirectionnel, dédié ou commuté, qui fonctionne en mode série de bit asynchrone ou synchrone, et est transparent pour les

trames de la couche de liaison PPP. PPP n’impose aucune restriction quant au débit de transmission autre que celles imposées par

l’interface ETTD/DCE utilisée.

La plupart des tâches réalisées par le protocole PPP sont effectuées au niveau des couches liaison de données et réseau par les protocoles

LCP et NCP. Le protocole LCP configure la connexion PPP et ses paramètres, les protocoles NCP gèrent des configurations de protocole de

couche plus élevée, et le protocole LCP met fin à la connexion PPP.

Page 2 :

Architecture PPP - Couche LCP

La couche LCP (Link Control Protocol, protocole de contrôle de liaison) est

la partie active de PPP. Le protocole LCP est situé au-dessus de la couche

physique et permet d’établir, de configurer et de tester la connexion de

liaison de données. Il établit la liaison point à point. Il négocie également

et configure des options de contrôle sur la liaison de données de réseau

étendu, qui sont gérées par les protocoles NCP.

Il fournit d’autre part la configuration automatique des interfaces à

chaque extrémité, notamment les tâches suivantes :

• gérer les limites variables de taille de paquets ;

• détecter les erreurs de configuration courantes ;

• mettre fin à la liaison ;

• déterminer si une liaison fonctionne correctement ou présente des défaillances.

PPP utilise également le protocole LCP pour s’accorder automatiquement sur des formats d’encapsulation (authentification, compression,

détection des erreurs) dès que la liaison est établie.



Page 3 :

Architecture PPP - Couche NCP

Les liaisons point à point ont tendance à aggraver de nombreux

problèmes existants avec la famille actuelle de protocoles de réseau.

Ainsi, l’attribution et la gestion d’adresses IP, qui est un problème

même dans des environnements de réseau LAN, est particulièrement

difficile sur des liaisons point à point à commutation de circuits (tels

que des serveurs de modem commuté). Le protocole PPP permet de

résoudre ces problèmes, grâce aux couches NCP.

Avec PPP, plusieurs protocoles de couche réseau peuvent fonctionner

sur la même liaison de communications. Pour chaque protocole de

couche réseau utilisé, le protocole PPP utilise une couche NCP

distincte. Par exemple, le protocole IP utilise le protocole de contrôle IP

(IPCP), et IPX le protocole de contrôle Novell IPX (IPXCP).

Cliquez sur le bouton Couche réseau dans la figure.

Les couches NCP incluent des champs fonctionnels comprenant des

codes normalisés (numéros de champ de protocole PPP affichés dans la

figure) pour indiquer le protocole de couche réseau que PPP

encapsule. Chaque couche NCP gère les besoins spécifiques requis par

ses protocoles de couche réseau spécifiques. Les divers composants

NCP encapsulent et négocient des options pour des protocoles de

couche réseau multiples. L’utilisation de NCP pour configurer les divers

protocoles de couche réseau est présentée et mise en pratique plus

loin dans ce chapitre.

2.2.3- Structure de trame PPP

Structure de trame PPP

Une trame PPP comporte six champs comme illustré dans la

figure.

Placez votre pointeur sur chaque champ pour afficher une

explication de ce que chacun contient et fait.

Le protocole LCP peut négocier des modifications sur la structure

de trame PPP standard.



2.2.4- Établissement d’une session PPP

Établissement d’une session PPP

La figure ci-contre présente les trois phases d’établissement d’une session

PPP :

• Phase 1 : Établissement d’une liaison et négociation de la

configuration - Pour que des échanges de datagrammes de

couche réseau (par exemple, IP) par le protocole PPP soient

possibles, le protocole LCP doit d’abord ouvrir la connexion et

négocier les options de configuration. Cette phase se termine

lorsque le routeur récepteur renvoie une trame d’accusé de

réception de configuration vers le routeur établissant la

connexion.

• Phase 2 : Détermination de la qualité de la liaison (facultatif) - Le

protocole LCP teste la liaison afin de déterminer si sa qualité est

suffisante pour activer les protocoles de couche réseau. Le

protocole LCP peut retarder la transmission des informations du

protocole de couche réseau jusqu’à ce que cette phase soit

terminée.

• Phase 3 : Négociation de la configuration du protocole de couche réseau - Une fois la qualité de la liaison déterminée, le

protocole NCP approprié peut configurer séparément les protocoles de couche réseau, puis les activer et désactiver à tout

moment. Si le protocole LCP ferme la liaison, il en informe les protocoles de couche réseau afin qu’ils prennent les mesures qui

s’imposent.

La liaison reste configurée pour les communications jusqu’à ce que des trames LCP ou NCP explicites ferment la liaison ou qu’un

événement extérieur se produise (par exemple, expiration du délai d’inactivité ou intervention d’un utilisateur). Le protocole LCP peut

fermer la liaison à tout moment. Cela se produit généralement lorsqu’un des routeurs demande la fermeture, mais également en cas

d’événement physique tel que la perte d’un opérateur ou l’expiration d’un compteur de période d’inactivité.

2.2.5-Etablissement d’une liaison avec LCP

Fonctionnement de LCP

Le protocole LCP participe à l’établissement, la maintenance et la

fermeture d’une liaison. Il utilise trois classes de trames LCP pour

effectuer le travail de chaque phase LCP :

• les trames d’établissement de liaison ouvrent et configurent

une liaison (Configure-Request, Configure-Ack, Configure-Nak

et Configure-Reject) ;

• les trames de maintenance de liaison gèrent et déboguent une

liaison (Code-Reject, Protocol-Reject, Echo-Request, Echo-

Reply et Discard-Request) ;

• les trames de fermeture de liaison mettent fin à une liaison

(Terminate-Request et Terminate-Ack).

La première phase du fonctionnement LCP consiste à établir une liaison.

Cette phase doit être terminée pour que des paquets de couche réseau

puissent être échangés. Au cours de l’établissement d’une liaison, le

protocole LCP ouvre la connexion et négocie les paramètres de

configuration.



Cliquez sur le bouton Négociation de la liaison dans la figure.

Le processus d’établissement de la liaison commence par

l’envoi par le périphérique initiateur d’une trame Configure-

Request au répondeur. Cette trame inclut un nombre variable

d’options de configuration requises pour configurer la liaison.

En d’autres termes, le demandeur a envoyé une « liste de

souhaits » au répondeur.

Cette liste inclut des options sur la manière dont il souhaite

que la liaison soit créée, notamment les paramètres de

protocole ou d’authentification. Le répondeur traite la liste de

souhaits, et si celle-ci est acceptable répond en envoyant un

message Configure-Ack. Une fois le message Configure-Ack

reçu, le processus passe à l’étape d’authentification.

Si les options ne sont pas acceptables ou reconnues, le

répondeur envoie un message Configure-Nak ou Configure-

Reject. Si un message Configure-Ack est reçu, l’opération de

liaison est transférée au protocole NCP. Si un message Configure-Nak ou Configure-Reject est envoyé au demandeur, la liaison n’est pas

établie. Si la négociation échoue, le demandeur doit redémarrer le processus en utilisant de nouvelles options.

Lors de la maintenance de liaison, le protocole LCP peut utiliser des messages pour fournir un retour d’informations et tester la liaison.

• Code-Reject et Protocol-Reject - Ces types de trame fournissent un retour d’informations lorsqu’un périphérique reçoit une

trame non valide en raison d’un code LCP non reconnu (type de trame LCP) ou d’un identificateur de protocole incorrect. Par

exemple, si un paquet impossible à interpréter est reçu en provenance de l’homologue, un paquet Code-Reject est envoyé en

réponse.

• Echo-Request, Echo-Reply et Discard-Request - Ces trames peuvent être utilisées pour tester la liaison.

Une fois les données transférées au niveau de la couche réseau, le protocole LCP met fin à la liaison. Dans la figure ci-contre, notez que seul

le protocole NCP met fin à la liaison réseau et à la liaison NCP. La liaison reste ouverte jusqu’à ce que le protocole LCP la ferme. Si le

protocole LCP met fin à la liaison avant le protocole NCP, la session NCP est également fermée.

Le protocole PPP peut fermer la liaison à tout moment. Cela peut se produire en raison de la perte de l’opérateur, d’un échec

d’authentification, d’une défaillance de la qualité de la liaison, de l’expiration d’un compteur de période d’inactivité ou de la fermeture

administrative de la liaison. Le protocole LCP ferme la liaison en échangeant des paquets Terminate. Le périphérique demandant la

fermeture envoie un message Terminate-Request. L’autre périphérique répond en envoyant un message Terminate-Ack. Une demande de

fermeture indique que le périphérique l’envoyant doit fermer la liaison. Une fois la liaison fermée, le protocole PPP en informe les

protocoles de couche réseau afin qu’ils prennent les mesures qui s’imposent.

Page 2 :

Paquet LCP

La figure ci-contre affiche les champs dans un paquet LCP.

Placez votre pointeur sur chaque champ pour en lire la description.

Chaque paquet LCP est un message LCP unique comprenant un champ

de code LCP identifiant le type de paquet LCP, un champ

d’identificateur permettant d’associer les demandes à des réponses,

et un champ de longueur indiquant la taille du paquet LCP et des

données spécifiques du type de paquet LCP.



Cliquez sur le bouton Codes LCP dans la figure.

Chaque paquet LCP a un rôle spécifique lors de l’échange

d’informations de configuration, selon son type. Le champ de code

du paquet LCP identifie le type de paquet, comme spécifié dans le

tableau.

Page 3 :

Options de configuration PPP

Le protocole PPP peut être configuré pour prendre en charge

diverses fonctions notamment :

• authentification à l’aide de PAP ou CHAP ;

• compression à l’aide de Stacker ou Predictor ;

• multiliaison qui associe un ou plusieurs canaux en

vue d’augmenter la bande passante de réseau

étendu.

Ces options sont décrites plus en détail dans la section

suivante.

Cliquez sur le bouton Champ d’option LCP dans la figure.

Pour négocier l’utilisation de ces options PPP, les trames

d’établissement de liaison LCP comprennent des informations

d’option dans le champ de données de la trame LCP. Si une

option de configuration n’est pas comprise dans une trame

LCP, sa valeur par défaut est utilisée.

Cette phase se termine par l’envoi et la réception d’une trame

de reçu de la configuration.



2.2.6-Présentation de NCP

Page 1 :

Processus NCP

Une fois la liaison initiée, le protocole LCP passe le relais au protocole NCP approprié. Bien que conçu à l’origine pour des datagrammes IP,

le protocole PPP peut transporter des données à partir de nombreux types de protocole de couche réseau en adoptant une approche

modulaire lors de son implémentation. Il peut également acheminer deux ou plusieurs protocoles de couche 3 simultanément. Son modèle

modulaire permet au protocole LCP de configurer la liaison, puis de transmettre les détails d’un protocole réseau à un protocole NCP

spécifique. À chaque protocole réseau correspond un protocole NCP. De même, à chaque protocole NCP correspond un RFC. Il existe des

protocoles NCP pour IP, IPX, AppleTalk, etc. Les protocoles NCP utilisent le même format de paquet que les protocoles LCP.

Une fois que le LCP a configuré et authentifié la liaison de base, le NCP approprié est invoqué pour compléter la configuration spécifique du

protocole de couche réseau utilisé. Lorsque le NCP a configuré le protocole de couche réseau, le protocole réseau présente l’état ouvert

sur la liaison LCP établie. À ce stade, le protocole PPP peut transporter les paquets de protocole de couche réseau correspondants.

Exemple IPCP

Pour illustrer comment fonctionne la couche NCP, IP, le protocole de couche 3 le plus courant, est utilisé. Une fois que le protocole LCP a

établi la liaison, les routeurs échangent des messages IPCP, négociant les options propres au protocole. Le protocole IPCP est chargé de la

configuration, de l’activation et de la désactivation des modules IP aux deux extrémités de la liaison.

IPCP négocie deux options :

• Compression - Permet aux périphériques de négocier un algorithme pour compresser des en-têtes TCP et IP, et économiser de la

bande passante. La compression d’en-tête TCP/IP Van Jacobson réduit la taille des en-têtes TCP/IP à 3 octets minimum. Cela

représente une amélioration considérable sur les lignes série lentes, en particulier pour le trafic interactif.

• Adresse IP - Permet au périphérique demandeur de spécifier une adresse IP à utiliser pour le routage IP sur la liaison PPP, ou de

demander une adresse IP pour le répondeur. Les liaisons de réseau commuté utilisent souvent l’option d’adresse IP.

Une fois le processus NCP terminé, la liaison passe à l’état ouvert et le protocole LCP reprend le relais. Le trafic de liaison comprend toutes

les combinaisons possibles de paquets LCP, NCP et de protocole de couche réseau. La figure ci-contre démontre comment des messages

LCP peuvent être utilisés par des périphériques pour gérer ou déboguer la liaison.



2.3-Configuration du Protocole PPP

2.3.1- Options de configuration PPP

Options de configuration PPP

Dans la section précédente, nous avons découvert les options LCP

qu’il est possible de configurer pour répondre à des besoins

spécifiques en termes de connexion de réseau étendu. Le protocole

PPP peut inclure les options LCP suivantes :

• Authentification - Des routeurs homologues échangent des

messages d’authentification. Pour l’authentification, les

deux choix sont le protocole d’authentification du mot de

passe (PAP, Password Authentication Protocol) et le

protocole d’authentification à échanges confirmés (CHAP,

Challenge Handshake Authentication Protocol).

L’authentification est présentée à la section suivante.

• Compression - Augmente le débit effectif des connexions

PPP en réduisant la quantité de données dans la trame qui

doit être acheminée sur la liaison. Le protocole décompresse

la trame à l’arrivée. Les deux protocoles de compression

disponibles sur les routeurs Cisco sont Stacker et Predictor.

• Détection des erreurs - Identifie les conditions d’échec. Les

options Quality et Magic Number aident à assurer que la

liaison de données reste fiable et sans boucle. Le champ Magic Number permet de détecter les liaisons qui présentent une

boucle. Tant que la négociation de l’option de configuration Magic-Number n’a pas abouti, le champ Magic-Number doit être

transmis comme valeur zéro. Les numéros magiques sont générés de façon aléatoire à chaque extrémité de la connexion.

• Multiliaison - Cisco IOS version 11.1 et ultérieure prend en charge le protocole PPP multiliaison. Cette option fournit un

équilibrage de charge sur les interfaces de routeur utilisées par PPP. Le protocole PPP multiliaison (également appelé MP, MPPP,

MLP ou Multiliaison) fournit une méthode de répartition du trafic sur plusieurs liaisons physiques de réseau étendu tout en

assurant la fragmentation et le réassemblage de paquets, le séquençage adéquat, l’interopérabilité multiconstructeur et

l’équilibrage de la charge sur le trafic entrant et sortant. La multiliaison n’est pas couverte dans ce cours.

• Rappel PPP - Pour renforcer la sécurité, Cisco IOS version 11.1 et ultérieure offre des fonctions de rappel sur PPP. Grâce à cette

option LCP, un routeur Cisco peut servir de client ou de serveur de rappel. Le client effectue l’appel initial, demande à être

rappelé, puis met fin à son appel initial. Le routeur de rappel répond à l’appel initial et rappelle le client en s’appuyant sur ses

instructions de configuration. La commande est ppp callback [accept | request].

Lorsque des options sont configurées, un champ de valeur correspondant est inséré dans le champ d’option LCP.

2.3.2- Commandes de configuration PPP

Commandes de configuration PPP

Avant de configurer le protocole PPP sur une interface série, nous allons étudier les commandes et leur syntaxe, comme illustré dans la

figure. Les exemples qui suivent indiquent comment configurer le protocole PPP et certaines de ses options.

Exemple 1 : Activation du protocole PPP sur une interface

Pour définir la méthode d’encapsulation PPP utilisée par une interface série ou RNIS, utilisez la commande de configuration d’interface

encapsulation ppp.

L’exemple suivant active l’encapsulation PPP sur l’interface série 0/0 :

• R3#configure terminal

• R3(config)#interface serial 0/0

• R3(config-if)#encapsulation ppp



La commande encapsulation ppp ne comporte aucun argument. Cependant, vous devez configurer le routeur avec un protocole de routage

IP pour utiliser l’encapsulation PPP. Gardez à l’esprit que si vous ne configurez pas le protocole PPP sur un routeur Cisco, l’encapsulation

par défaut pour des interfaces série est HLDC.

Exemple 2 : Compression

Vous pouvez configurer une compression logicielle point à point sur des interfaces série une fois l’encapsulation PPP activée. Étant donné

que cette option invoque un processus de compression logicielle, elle risque d’affecter les performances du système. Si le trafic comprend

déjà des fichiers compressés (.zip, .tar ou .mpeg, par exemple),

n’utilisez pas cette option. La figure ci-contre affiche la syntaxe pour

la commande compress.

Pour configurer la compression sur PPP, entrez les commandes

suivantes :



• R3(config-if)#compress [predictor | stac]

Exemple 3 : Surveillance de la qualité de la liaison

Rappelons, comme nous l’avons évoqué dans notre discussion sur

les phases LCP, que le protocole LCP fournit une phase optionnelle

de détermination de la qualité de la liaison. Dans cette phase, le protocole LCP teste la liaison pour déterminer si la qualité de la liaison est

suffisante pour utiliser des protocoles de couche 3. La commande ppp quality percentage garantit que la liaison est conforme aux

exigences de qualité définies. Dans le cas contraire, la liaison est fermée.

Les pourcentages sont calculés pour le trafic entrant et sortant. La qualité en sortie est calculée en comparant le nombre total de paquets

et d’octets envoyés au nombre total de paquets et d’octets reçus par le nœud de destination. La qualité en entrée est calculée en

comparant le nombre total de paquets et d’octets reçus au nombre total de paquets et d’octets envoyés par le nœud de destination.

Si le pourcentage de qualité de la liaison n’est pas maintenu, la liaison est considérée comme étant de mauvaise qualité et est désactivée.

La surveillance de la qualité de la liaison (LQM, Link Quality Monitoring) implémente un décalage temporel afin que la ligne ne se mette pas

à basculer d'active à désactivée. Cet exemple de configuration contrôle les données ignorées sur la liaison et évite le bouclage de trames :



• R3(config-if)#ppp quality 80

Utilisez la commande no ppp quality pour désactiver LQM.

Exemple 4 : Équilibrage de la charge sur les liaisons

Le protocole PPP multiliaison fournit une méthode de répartition du trafic sur plusieurs liaisons physiques de réseau étendu tout en

assurant la fragmentation et l’assemblage de paquets, le séquençage adéquat, l’interopérabilité multiconstructeur et l’équilibrage de la

charge sur le trafic entrant et sortant.

MPPP permet de fragmenter des paquets et d’envoyer ces fragments simultanément sur plusieurs liaisons point à point vers la même

adresse distante. Les liaisons physiques multiples sont activées en réponse à un seuil de charge défini par l’utilisateur. MPPP peut mesurer

la charge sur le trafic entrant uniquement, sur le trafic sortant uniquement, mais pas sur les deux types de trafic.

Les commandes ci-dessous effectuent un équilibrage de la charge sur plusieurs liaisons :

• Router(config)#interface serial 0/0

• Router(config-if)#encapsulation ppp

• Router(config-if)#ppp multilink

La commande multilink ne présente aucun argument. Pour désactiver le protocole PPP multiliaison, utilisez la commande no ppp multilink.



2.3.3- Vérification d’une configuration de l’encapsulation PPP série

Vérification d’une configuration de l’encapsulation PPP série

Utilisez la commande show interfaces serial pour vérifier la

configuration de l’encapsulation HDLC ou PPP. La sortie de la

commande affichée dans la figure illustre une configuration PPP.

Lorsque vous configurez HDLC, la sortie de la commande show

interfaces serial doit afficher « encapsulation HDLC ». Lorsque vous

configurez le protocole PPP, vous pouvez vérifier ses états LCP et

NCP.

Cliquez sur le bouton Commandes dans la figure.

La figure résume les commandes utilisées lors de la vérification du

protocole PPP.

2.3.4- Dépannage de la configuration d’encapsulation série

Page 1 :

Dépannage de la configuration d’encapsulation série

Vous savez désormais que la commande debug est utilisée à des

fins de dépannage et est accessible à partir du mode d’exécution

privilégié (EXEC) de l’interface de ligne de commande. La

commande debug affiche des informations sur des opérations de

routeur variées et sur le trafic associé généré ou reçu par le

routeur, ainsi que d’éventuels messages d’erreur. C’est un outil

très utile et intéressant, mais vous devez garder à l’esprit que Cisco

IOS traite le débogage comme une tâche de priorité élevée. Il peut

par conséquent utiliser une grande quantité de ressources,

obligeant ainsi le routeur à commuter les paquets en cours de

débogage. Cette commande ne doit pas être utilisée comme un

outil de surveillance, car elle est conçue pour être utilisée pendant une courte période à des fins de débogage. Lors du dépannage d’une

connexion série, adoptez la même approche que pour toute autre tâche de configuration.

Utilisez la commande debug ppp pour afficher des informations sur le fonctionnement de PPP. La figure ci-contre affiche la syntaxe de la

commande. La forme no de cette commande désactive l’affichage du message de débogage.



Page 2 :

Sortie de la commande debug ppp packet

Une commande utile lors du dépannage de l’encapsulation d’une interface

série est debug ppp packet. La figure fournit un exemple de sortie de la

commande debug ppp packet comme affiché du côté de la gestion de la

qualité de la liaison (LQM) de la connexion. Cet exemple montre l’échange

de paquets dans des conditions normales de fonctionnement du protocole

PPP.

Bien que partielle seulement, cette liste vous permet de vous

préparer pour les travaux pratiques.

Observez chaque ligne de la sortie et associez-la à la signification du

champ. Utilisez la liste ci-dessous pour vous aider.

• PPP - Sortie de débogage PPP.

• Serial2 - Numéro d’interface associé aux informations de

débogage.

• (o), O - Le paquet détecté est un paquet de sortie.

• (i), I - Le paquet détecté est un paquet d’entrée.

• lcp_slqr() - Nom de la procédure ; exécution de la gestion

de la qualité de la liaison (LQM), envoi d’un rapport sur la

qualité de la liaison (LQR).

• lcp_rlqr() - Nom de la procédure ; exécution de la gestion

de la qualité des liaisons (LQM), réception d’un rapport sur la qualité de la liaison (LQR).

• input (C021) - Le routeur a reçu un paquet du type spécifié (au format hexadécimal). La valeur C025 indique que le paquet est de

type LQM.

• state = OPEN - État PPP ; l’état normal est OPEN (ouvert).

• magic = D21B4 - Numéro magique pour le nœud spécifié ; lorsque la sortie est signalée, il s’agit du numéro magique du nœud sur

lequel le débogage est activé. Le numéro magique en cours varie si le paquet détecté est de type I ou O.

• datagramsize = 52 - Longueur du paquet, avec l’en-tête.

• code = ECHOREQ(9) - Identifie le type de paquet reçu sous forme chaîne et sous forme hexadécimale.

• len = 48 - Longueur du paquet, sans l’en-tête.

• id = 3 - Numéro d’ID par format de paquet LCP.

• pkt type 0xC025 - Type de paquet au format hexadécimal ; les types de paquet courants sont C025 pour LQM et C021 pour LCP.

• LCP ECHOREQ (9) - Demande d’écho ; la valeur entre parenthèses correspond à la représentation hexadécimale du type LCP.

• LCP ECHOREQ (A) - Réponse d’écho ; la valeur entre parenthèses correspond à la représentation hexadécimale du type LCP.

Page 3 :

Sortie de la commande debug ppp negotiation

La figure ci-contre affiche la sortie de la commande debug ppp negotiation lors d’une négociation normale, où les deux côtés s’accordent

sur des paramètres de programme de contrôle de réseau (NCP, Network Control Program). Le cas échéant, le type de protocole IP est

proposé et fait l’objet d’un accusé de réception. Étudions la sortie en détail :

Les deux premières lignes indiquent que le routeur tente d’activer le LCP et qu’il utilisera les options de négociation spécifiées (Quality

Protocol et Magic Number). Les champs de valeur correspondent aux valeurs des options elles-mêmes. C025/3E8 correspond au LQM de

l’option Quality Protocol. 3E8 est la période de génération de rapports (en centièmes de seconde). 3D56CAC est la valeur du numéro

magique (Magic Number) pour le routeur.

ppp: sending CONFREQ, type = 4 (CI_QUALITYTYPE), value = C025/3E8

ppp: sending CONFREQ, type = 5 (CI_MAGICNUMBER), value = 3D56CAC



Les deux lignes suivantes indiquent que l’autre côté a négocié les

options 4 et 5 et qu’il a demandé et accusé réception des deux. Si

l’extrémité répondeuse ne prend pas en charge les options, le

nœud répondeur envoie un message CONFREJ. Si l’extrémité

répondeuse n’accepte pas la valeur de l’option, elle envoie un

message CONFNAK avec le champ de valeur modifié.

ppp: received config for type = 4 (QUALITYTYPE) acked

ppp: received config for type = 5 (MAGICNUMBER) value =

3D567F8 acked (ok)

Les trois lignes suivantes indiquent que le routeur a reçu un

message CONFACK de la part du côté répondeur et affiche les

valeurs d’option acceptées. Utilisez le champ rcvd id pour vérifier

que les messages CONFREQ et CONFACK présentent le même

champ id.

PPP Serial4: state = ACKSENT fsm_rconfack(C021): rcvd id 5

ppp: config ACK received, type = 4 (CI_QUALITYTYPE), value = C025

ppp: config ACK received, type = 5 (CI_MAGICNUMBER), value = 3D56CAC

La ligne suivante indique que le routage IP est activé sur cette interface du routeur et que le protocole NPC IPCP a réussi la négociation.

ppp: ipcp_reqci: returning CONFACK

(ok)

Page 4 :

Sortie de la commande debug ppp error

Vous pouvez utiliser la commande debug ppp error pour

afficher des erreurs de protocole et des statistiques d’erreur

associées à la négociation et au fonctionnement de la

connexion. Ces messages peuvent s’afficher lorsque l’option

Quality Protocol est activée sur une interface qui exécute déjà le

protocole PPP. La figure ci-contre affiche un exemple.

Observez chaque ligne de la sortie et associez-la à la signification

du champ. Utilisez la liste ci-dessous pour vous aider.

• PPP - Sortie de débogage PPP.

• Serial3(i) - Numéro d’interface associé aux informations de débogage ; indique qu’il s’agit d’un paquet d’entrée.

• rlqr receive failure - Le récepteur n’a pas accepté la demande de négociation de l’option Quality Protocol.

• myrcvdiffp = 159 - Nombre de paquets reçus pendant la période spécifiée.

• peerxmitdiffp = 41091 - Nombre de paquets envoyés par le nœud distant pendant cette période.

• myrcvdiffo = 2183 - Nombre d’octets reçus pendant cette période.

• peerxmitdiffo = 1714439 - Nombre d’octets reçus par le nœud distant pendant cette période.

• threshold = 25 - Pourcentage d’erreur maximal acceptable sur cette interface. Pour calculer ce pourcentage, utilisez la valeur de

seuil entrée dans la commande de configuration d’interface ppp quality percentage. Pour obtenir le pourcentage maximal, retirez

ce nombre à la valeur 100. Dans ce cas, le nombre 75 a été entré. Cela signifie que le routeur local doit maintenir un pourcentage

de non erreur de 75 % minimum pour que la liaison PPP reste active.

• OutLQRs = 1 - Numéro actuel d’ordre LQR d’envoi du routeur local.

• LastOutLQRs = 1 - Dernier numéro d’ordre que le nœud distant a reçu depuis le nœud local.



2.4-Configuration de PPP avec Authentification

2.4.1- Protocole d’authentification PAP

Protocole d’authentification PAP

Le protocole PPP définit un protocole LCP extensible qui permet la

négociation d’un protocole d’authentification pour ses homologues

avant d’autoriser la transmission par des protocoles de couche réseau

sur la liaison. RFC 1334 définit deux protocoles pour l’authentification,

tel qu’illustré dans la figure.

PAP est un processus bidirectionnel très simple. Il ne présente pas de

chiffrement : les nom d’utilisateur et mot de passe sont envoyés en

texte clair. S’ils sont acceptés, la connexion est autorisée. CHAP est plus

sécurisé que le protocole PAP. Il implique un échange en trois étapes

d’un secret partagé. Ce processus est décrit plus loin dans cette section.

La phase d’authentification d’une session PPP est facultative. Si elle est

utilisée, vous pouvez authentifier l’homologue une fois que le protocole LCP a établi la liaison et choisir le protocole d’authentification.

L’authentification a lieu avant le début de la phase de configuration du protocole de couche réseau.

Les options d’authentification nécessitent que le côté appelant de la liaison entre des informations d’authentification. Cela permet de

garantir que l’administrateur réseau a autorisé l’utilisateur à passer l’appel. Les routeurs homologues échangent des messages

d’authentification.

2.4.2-Protocole d’Authentification du mot de Passe (PAP)

Le protocole PPP présente de nombreuses caractéristiques, dont

l’authentification de couche 2, en plus des autres couches d’authentification

qui sont le chiffrement, le contrôle d’accès et les procédures générales de

sécurité.

Initialisation du protocole PAP

Le protocole PAP procure une méthode simple permettant à un nœud

distant d’établir son identité à l’aide d’un échange en deux étapes. PAP n’est

pas interactif. Lorsque la commande ppp authentication pap est utilisée, les

nom d’utilisateur et mot de passe sont envoyés en tant que paquet de

données LCP unique, ce qui évite au serveur d’envoyer une invite de

connexion et de devoir attendre une réponse. La figure ci-contre montre

qu’une fois que le protocole PPP a établi la liaison, le nœud distant envoie

de façon répétitive une paire nom d’utilisateur-mot de passe sur la liaison

jusqu’à ce que le nœud expéditeur en accuse réception ou mette fin à la

connexion.

Cliquez sur le bouton Finalisation PAP dans la figure.

Sur le nœud récepteur, la combinaison nom d’utilisateur-mot de passe est

vérifiée par un serveur d’authentification qui peut autoriser ou refuser la

connexion. Un message d’acceptation ou de rejet est envoyé au demandeur.

Le protocole PAP n’est pas un protocole d’authentification très fort. En effet,

les mots de passe sont transmis en clair sur la liaison et PAP n’offre aucune

protection contre la lecture répétée des informations ou les attaques

répétées par essais et erreurs. Le nœud distant contrôle la fréquence et la

durée des tentatives de connexion.



Cependant, dans certains cas, l’utilisation du protocole PAP peut être justifiée. Ainsi, malgré ses lacunes, PAP peut être utilisé dans les

environnements suivants :

• une base étendue d’applications client qui ne prennent pas en charge CHAP ;

• lorsque des implémentations de CHAP par des fournisseurs multiples sont incompatibles ;

• dans les situations où le mot de passe en clair doit être disponible pour simuler une connexion sur un hôte distant.

2.4.3- Protocole d’authentification à échanges confirmés (CHAP)

Protocole d’authentification à échanges confirmés (CHAP)

Une fois l’authentification établie avec PAP, le protocole cesse de

fonctionner, exposant ainsi le réseau à d’éventuelles attaques. Alors que

le protocole PAP procède à une seule authentification, le protocole

d’authentification à échanges confirmés (CHAP) effectue des vérifications

régulières pour s’assurer que la valeur du mot de passe du nœud distant

est toujours valide. Cette valeur variable change de façon imprévisible

pendant l’existence de la liaison.

Une fois la phase d’établissement de la liaison PPP terminée, le routeur

local envoie un message de demande de confirmation au nœud distant.

Cliquez sur le bouton Réponse CHAP dans la figure.

Le nœud distant répond par une valeur calculée au moyen d’une fonction

de hachage unidirectionnelle, généralement l’algorithme Message Digest

5 (MD5), basé sur le mot de passe et le message de demande de

confirmation.

Cliquez sur le bouton Finalisation CHAP dans la figure.

Le routeur local compare la réponse à son propre calcul de la valeur

hachée attendue. Si les valeurs correspondent, le nœud demandeur

accuse réception de l’authentification. Dans le cas contraire, il met

immédiatement fin à la connexion.

Le protocole CHAP protège contre les attaques de lecture répétée en

utilisant une valeur de confirmation variable, unique et imprévisible. La

demande de confirmation étant unique et aléatoire, la valeur hachée

obtenue l’est également. Les demandes de confirmation répétées

limitent la durée d’exposition à toute attaque. Le routeur local ou un

serveur d’authentification externe contrôle la fréquence et la durée des

demandes de confirmation.



2.4.4- Processus d’encapsulation et d’authentification PPP

Processus d’encapsulation et d’authentification PPP

Vous pouvez utiliser un organigramme pour mieux comprendre le

processus d’authentification PPP lors de la configuration PPP. Cet

organigramme fournit une représentation visuelle des décisions

logiques prises par le protocole PPP.

Par exemple, si une demande PPP entrante ne requiert pas

d’authentification, le protocole PPP passe au niveau suivant. Si une

demande PPP entrante requiert l’authentification, elle peut être

authentifiée à l’aide de la base de données locale ou d’un serveur de

sécurité. Comme illustré dans l’organigramme, si l’authentification a

réussi, le processus passe au niveau suivant, alors qu’en cas d’échec, la

liaison est déconnectée et la demande PPP entrante abandonnée.

Cliquez sur le bouton Exemple CHAP, puis cliquez sur le bouton Lire pour lancer un exemple animé.

Suivez les étapes décrites dans l’animation. Le routeur R1 souhaite

établir une connexion CHAP PPP authentifiée avec le routeur R2.

Étape 1. R1 négocie la connexion de la liaison à l’aide du protocole LCP

avec le routeur R2 et les deux systèmes s’accordent à utiliser

l’authentification CHAP lors de la négociation LCP PPP.

Étape 2. Le routeur R2 génère un ID et un numéro aléatoire, et envoie

ces informations ainsi qu’un nom d’utilisateur sous forme de paquet

de demande de confirmation CHAP à R1.

Étape 3. R1 utilisera le nom d’utilisateur du demandeur (R2) et le

comparera à sa base de données locale pour trouver le mot de passe

associé. R1 générera un numéro de hachage MD5 unique en utilisant

le nom d’utilisateur, l’ID, le numéro aléatoire et le mot de passe secret

partagé de R2.

Étape 4. Le routeur R1 envoie l’ID de demande de confirmation, la valeur hachée et son nom d’utilisateur (R1) à R2.

Étape 5. R2 génère sa propre valeur de hachage en utilisant l’ID, le mot de passe secret partagé et le numéro aléatoire envoyé à l’origine à

R1.

Étape 6. R2 compare sa valeur de hachage à la valeur envoyée par R1. Si ces valeurs sont identiques, R2 envoie une réponse

d’établissement de liaison à R1.

Si l’authentification échoue, un paquet d’échec CHAP est créé à partir des composants ci-dessous :

• 04 = Type de message d’échec CHAP

• id = Copié depuis le paquet de réponse

• « Authentication failure » (Échec de l’authentification) ou un message de texte similaire, censé être une explication lisible par

l’utilisateur

Notez que le mot de passe secret partagé doit être identique sur R1 et R2.



2.4.5-Configuration ppp Authentification

Page 1 :

Commande ppp authentication

Pour spécifier l’ordre selon lequel les protocoles CHAP ou PAP

sont demandés sur l’interface, utilisez la commande de

configuration d’interface ppp authentication, comme illustré

dans la figure. Utilisez la forme no de cette commande pour

désactiver l’authentification.

Une fois l’authentification CHAP et/ou PAP activée, le routeur

local demande au périphérique distant de prouver son

identité avant de permettre au trafic de données de circuler.

Cette procédure s’effectue de la façon suivante :

• L’authentification PAP demande au périphérique distant d’envoyer un nom et un mot de passe qui seront comparés à la base de

données locale de noms d’utilisateur ou à la base de donnés distante TACACS/TACACS+.

• L’authentification CHAP envoie une demande de confirmation au périphérique distant. Ce dernier doit chiffrer la valeur de

demande de confirmation à l’aide d’un secret partagé puis renvoyer la valeur chiffrée et son nom au routeur local dans un

message de réponse. Le routeur local utilise le nom du périphérique distant pour rechercher le secret approprié dans la base de

données de noms d’utilisateur locale ou distante TACACS/TACACS+. Il utilise le secret trouvé pour chiffrer la demande de

confirmation d’origine et vérifier que les valeurs chiffrées correspondent.

Remarque : AAA/TACACS est un serveur dédié utilisé pour authentifier des utilisateurs. AAA signifie « Authentication, Authorization and

Accounting » (authentification, autorisation et traçabilité). Les clients TACACS envoient une demande à un serveur d’authentification

TACACS. Le serveur peut authentifier l’utilisateur, l’autoriser à faire certaines choses et surveiller ce qu’il a fait.

Vous pouvez activer PAP et/ou CHAP. Si les deux méthodes sont activées, la première méthode spécifiée est sollicitée lors de la négociation

de liaison. Si l’homologue refuse la première méthode ou suggère la deuxième, c’est cette dernière qui est utilisée. Certains périphériques

distants prennent en charge le protocole CHAP uniquement, et d’autres le protocole PAP uniquement. L’ordre selon lequel les méthodes

sont spécifiées dépend de votre appréciation quant à la capacité du périphérique distant à négocier correctement la méthode appropriée,

ainsi que de vos préoccupations en termes de sécurité de la ligne de données. Les noms d’utilisateur et mot de passe PAP sont envoyés

sous forme de chaînes de texte clair et peuvent par conséquent être interceptés et réutilisés. CHAP a comblé la plupart des lacunes

connues en termes de sécurité.

Page 2 :

Configuration de l’authentification PPP

La procédure présentée dans le tableau décrit la

configuration de l’encapsulation PPP et des protocoles

d’authentification PAP/CHAP. Il est essentiel de procéder

à une configuration correcte, car PAP et CHAP s’appuient

sur ces paramètres pour leur authentification.

Cliquez sur le bouton Exemple PAP dans la figure.

La figure est un exemple de configuration de

l’authentification PAP bidirectionnelle. Les deux routeurs

authentifient et sont authentifiés, de telle sorte qu’un

effet de miroir se produit sur les commandes

d’authentification PAP. Le nom d’utilisateur et le mot de passe PAP que chaque routeur envoie doivent correspondre à ceux spécifiés à

l’aide de la commande username nom password mot de passe de l’autre routeur.



Le protocole PAP procure une méthode simple permettant à un

nœud distant d’établir son identité à l’aide d’un échange en

deux étapes. Ceci s’effectue uniquement à l’établissement

initial de la liaison. Le nom d’hôte d’un routeur doit

correspondre au nom d’utilisateur que l’autre routeur a

configuré. Les mots de passe doivent également correspondre.

Cliquez sur le bouton Exemple CHAP dans la figure.

Le protocole d’authentification à échanges confirmés (CHAP)

permet de vérifier régulièrement l’identité du nœud distant à

l’aide d’un échange en trois étapes. Le nom d’hôte d’un routeur

doit correspondre au nom d’utilisateur que l’autre routeur a

configuré. Les mots de passe doivent également correspondre.

La vérification a lieu lors de l’établissement initial de la liaison et

peut être répétée à tout moment une fois la liaison établie. La

figure ci-contre est un exemple de configuration CHAP.

2.4.6- Dépannage d’une configuration PPP avec authentification

Page 1 :

Dépannage d’une configuration PPP avec authentification

L’authentification est une fonctionnalité qui doit être

correctement implémentée si vous ne souhaitez pas que la

sécurité de votre connexion série soit compromise. Vérifiez

toujours votre configuration à l’aide de la commande show

interfaces serial, comme vous le feriez sans l’authentification.

Assurez-vous toujours de tester votre configuration

d’authentification pour vérifier qu’elle fonctionne. Le débogage

vous permet de vérifier votre configuration et de corriger les

éventuels défauts. La commande de débogage de

l’authentification PPP est debug ppp authentication.

La figure ci-contre affiche un exemple de sortie de la commande

debug ppp authentication. Voici une interprétation de la sortie :

La ligne 1 indique que le routeur ne peut pas s’authentifier sur l’interface série Serial0, car l’homologue n’a pas envoyé de nom.

La ligne 2 indique que le routeur n’a pas pu valider la réponse CHAP, car le nom d’utilisateur « pioneer » est introuvable.

La ligne 3 indique qu’aucun mot de passe n’a été trouvé pour « pioneer ». D’autres réponses possibles à cette ligne auraient pu être « no

name received to authenticate » (aucun nom à authentifier), « unknown name » (nom inconnu), « no secret for given name » (aucun secret

pour le nom donné), « short MD5 response received » (réponse MD5 courte reçue) ou « MD5 compare failed » (échec de la comparaison

MD5).

Dans la dernière ligne, le code = 4 signifie qu’une panne s’est produite. Les autres valeurs de code possibles sont :

• 1 = Demande de confirmation

• 2 = Réponse

• 3 = Réussite

• 4 = Échec

id = 3 est le numéro d’ID par format de paquet LCP.

len = 48 est la longueur de paquet sans l’en-tête.



2.6-Résumé

À la fin de ce chapitre, vous devez être capable de décrire en termes conceptuels et pratiques pourquoi des communications série point à

point sont utilisées pour connecter votre réseau local au réseau étendu de votre fournisseur de services, plutôt que d’utiliser des

connexions parallèles qui à priori peuvent sembler plus rapides. Vous pouvez expliquer comment le multiplexage permet des

communications efficaces et optimise la quantité de données qui peut circuler sur une liaison de communications. Vous avez appris les

fonctions des principaux composants et protocoles de communications série, et pouvez configurer une interface série avec l’encapsulation

HDLC sur un routeur Cisco.

Vous disposez ainsi d’une base solide pour comprendre le protocole PPP notamment ses fonctionnalités, composants et architectures.

Vous pouvez expliquer comment une session PPP est établie à l’aide des fonctions des protocoles LCP et NCP. Vous avez étudié la syntaxe

des commandes de configuration et utilisé des options diverses requises pour configurer une connexion PPP, et avez également découvert

comment utiliser PAP ou CHAP pour assurer une connexion sécurisée. Les étapes requises pour la vérification et le dépannage ont

également fait l’objet d’une description. Vous êtes maintenant prêt à vérifier vos connaissances dans les travaux pratiques où vous

configurerez votre routeur pour qu’il utilise le protocole PPP afin de se connecter à un réseau étendu.

Documents

CCNA 4 CH2