Etude et Implémentation d`une Téléphonie IP Mixte d

Transcription

Remerciements
Remerciements
Je tiens tout d’abord à remercier Robert Valkai, manager de la team CALO, pour nous
avoir permis de faire ce stage au sein de Cisco Systems Inc.
Je voudrais aussi remercier Régis Baudin, Sébastien Gigot et Jastaran Sran pour leur
aide, leurs conseils et leur patience.
Merci à Pierre De Fooz pour son aide et son dévouement au bon déroulement du stage.
Merci à Gauthier Brion, Nicolas Rolans et Anton Ryhlov pour les parties de kicker. Les
trajets en train me manqueront (peut-être).
Un grand merci à Apor Kurucz, Serge Yasmine, Xavier Mertens et Jérôme Paquay pour
leur aide et pour le matériel qu’ils ont bien voulu me prêter.
Merci à ma famille, à mes amis et à Frede pour leur soutien et leurs conseils.
HEPL – Informatique / Réseaux et Télécoms
TFE 2008 - 2009
1
2
Etude et Implémentation d'une Téléphonie IP Mixte d'Entreprise Basée sur UCME
TFE 2008 - 2009
Table des Matières
Table des Matières
REMERCIEMENTS ................................................................................................................................................... 1
TABLE DES MATIÈRES ............................................................................................................................................. 3
ICÔNES UTILISÉES DANS CE LIVRE .......................................................................................................................... 7
SYNTAXE DES COMMANDES .................................................................................................................................. 9
INTRODUCTION ................................................................................................................................................... 11
CHAPITRE 1 : CISCO SYSTEMS INC. ....................................................................................................................... 13
HISTORIQUE DE L’ENTREPRISE ........................................................................................................................................13
STRUCTURE INTERNE ....................................................................................................................................................15
Cisco.com ...........................................................................................................................................................16
Technical Assistance Center (TAC) ......................................................................................................................16
Advance Hardware Replacement .......................................................................................................................17
Software Support ...............................................................................................................................................18
LA TEAM CALO...........................................................................................................................................................18
Le Laboratoire ....................................................................................................................................................18
CHAPITRE 2 : LE TRAVAIL DE TOUS LES JOURS...................................................................................................... 23
LES CASES – OMNITOOL ................................................................................................................................................23
RÉSERVATION DU MATÉRIEL – CHECKOUT ........................................................................................................................26
TACHES ADMINISTRATIVES .............................................................................................................................................27
Lab Scanning ......................................................................................................................................................27
Cable Cleaning ....................................................................................................................................................27
CHAPITRE 3 : INTRODUCTION À LA VOIX SUR IP .................................................................................................. 29
LE SYSTÈME H.323 ......................................................................................................................................................30
Fonctionnement de H.323 ..................................................................................................................................31
LE PROTOCOLE SIP ......................................................................................................................................................32
Messages SIP ......................................................................................................................................................32
Fonctionnement de SIP .......................................................................................................................................33
CODECS AUDIO ...........................................................................................................................................................35
LA SOLUTION CISCO .....................................................................................................................................................36
Cisco Unified Communications ...........................................................................................................................36
Cisco UC Manager Express (UCME) ....................................................................................................................36
CHAPITRE 4 : PRISE EN MAIN D’UC MANAGER EXPRESS ...................................................................................... 37
PRÉSENTATION DU MATÉRIEL .........................................................................................................................................37
Cisco ISR 2801 ....................................................................................................................................................37
Cisco Catalyst 2960 ............................................................................................................................................37
Cisco Unified IP Phones ......................................................................................................................................38
PREMIÈRE TOPOLOGIE ..................................................................................................................................................38
SWITCHED PORT ANALYZER (SPAN) ...............................................................................................................................39
POWER OVER ETHERNET (POE) ......................................................................................................................................39
TFE 2008 - 2009
3
4
CONFIGURATION DE BASE DU 2801 ................................................................................................................................44
NTP .....................................................................................................................................................................44
DHCP ..................................................................................................................................................................44
CONFIGURATION DE UC MANAGER EXPRESS .....................................................................................................................45
Configuration Classique (Manuelle) ...................................................................................................................45
Configuration Automatique ...............................................................................................................................46
AJOUT DE TÉLÉPHONES À UC MANAGER EXPRESS ..............................................................................................................46
Ephones et Directory Numbers (DN) ..................................................................................................................46
Assignation Statique ..........................................................................................................................................46
Assignation Automatique ...................................................................................................................................48
Templates ...........................................................................................................................................................49
Mise à Jour du Firmware ....................................................................................................................................51
SKINNY CLIENT CONTROL PROTOCOL (SCCP) ....................................................................................................................55
Les Messages SCCP .............................................................................................................................................57
Fonctionnement de SCCP ...................................................................................................................................63
CHAPITRE 5 : FONCTIONNALITÉS SUPPLÉMENTAIRES .......................................................................................... 71
MESSAGE SYSTÈME ......................................................................................................................................................71
EXTENSION MOBILITY ...................................................................................................................................................71
Activation de l’Extension Mobility ......................................................................................................................71
Création d’un Logout-Profile ..............................................................................................................................72
Création d’un User-Profile ..................................................................................................................................72
Utilisation de l’Extension Mobility ......................................................................................................................72
SINGLE NUMBER REACH (SNR) ......................................................................................................................................74
INTERFACE GRAPHIQUE (GUI) ........................................................................................................................................76
Activation de l’Interface Graphique ...................................................................................................................76
Ajout d’un Utilisateur .........................................................................................................................................78
SERVICE DE NUIT .........................................................................................................................................................79
Configuration du Service de Nuit ........................................................................................................................79
CHAPITRE 6 : TÉLÉPHONES ANALOGIQUES ........................................................................................................... 83
FXS VS FXO ...............................................................................................................................................................83
Foreign eXchange Station (FXS) .........................................................................................................................84
Foreign eXchange Office (FXO) ...........................................................................................................................84
MODULE VIC2-2FXS ...................................................................................................................................................84
Installation du Module .......................................................................................................................................84
Configuration du Module ...................................................................................................................................85
MODULE VIC2-2FXO ..................................................................................................................................................89
Configuration du Module ...................................................................................................................................90
FEATURE ACCESS CODE (FAC) .......................................................................................................................................91
CHAPITRE 7 : LA TÉLÉPHONIE SANS-FIL ................................................................................................................ 93
CISCO AIRONET 1131 AG .............................................................................................................................................93
CISCO UNIFIED WIRELESS IP PHONE 7921G.....................................................................................................................94
SÉCURITÉ DES RÉSEAUX SANS-FIL ....................................................................................................................................94
WEP ....................................................................................................................................................................95
TFE 2008 - 2009
Table des Matières
WPA/WPA2 ........................................................................................................................................................95
IEEE 802.1X.........................................................................................................................................................96
Le Framework EAP .............................................................................................................................................96
EAP-FAST .................................................................................................................................................................99
Paquet EAP-FAST ................................................................................................................................................99
Fonctionnement de EAP-FAST ..........................................................................................................................100
Mise en Place de EAP-FAST ..............................................................................................................................102
EAP-TLS .................................................................................................................................................................106
Paquet EAP-TLS ................................................................................................................................................107
Fonctionnement de EAP-TLS .............................................................................................................................108
Mise en Place de EAP-TLS .................................................................................................................................110
CHAPITRE 8 : CONTRÔLEUR DE RÉSEAUX SANS-FIL ............................................................................................ 117
LE PROTOCOLE LWAPP ..............................................................................................................................................117
CISCO 2106 WIRELESS LAN CONTROLLER......................................................................................................................118
CONFIGURATION DE BASE............................................................................................................................................118
Mise à Jour de l’Image .....................................................................................................................................120
MISE EN PLACE DE EAP-TLS ........................................................................................................................................121
CHAPITRE 9 : CISCO SECURE ACS ........................................................................................................................ 123
CONFIGURATION DE CISCO SECURE ACS ........................................................................................................................123
Ajout d’un Compte Administrateur ..................................................................................................................123
Installation des Certificats ................................................................................................................................124
Ajout de Network Access Servers .....................................................................................................................125
Ajout d’Utilisateurs ..........................................................................................................................................127
Activation de EAP-TLS ......................................................................................................................................129
CHAPITRE 10 : CONCLUSION .............................................................................................................................. 131
ANNEXE A : INSTALLATION DE SERVICES WINDOWS .......................................................................................... 133
INTERNET SERVICES (IIS) .............................................................................................................................................133
AUTORITÉ DE CERTIFICATION........................................................................................................................................134
Installation .......................................................................................................................................................134
Création de Certificats ......................................................................................................................................137
ANNEXE B : INSTALLATION DE CISCO SECURE ACS ............................................................................................. 145
ANNEXE C : CONFIGURATIONS FINALES ............................................................................................................. 147
ROGUE-CME (CISCO ISR 2801) ....................................................................................................................................147
ROGUE-SW1 (CISCO CATALYST 2960) ...........................................................................................................................152
ROGUE-AP (CISCO AIRONET 1131) ...............................................................................................................................153
ACRONYMES UTILISÉS DANS CE LIVRE ............................................................................................................... 157
BIBLIOGRAPHIE .................................................................................................................................................. 159
TFE 2008 - 2009
5
6
TFE 2008 - 2009
Icônes Utilisées dans ce Livre
Icônes Utilisées dans ce Livre
Routeur
Switch
Ordinateur Portable
Access Point
Access Point Léger
Contrôleur Wireless
Téléphone IP
Téléphone IP sans-fil
UC Manager Express
Lien Ethernet
Connexion sans-fil
Serveur d’Authentification
TFE 2008 - 2009
7
8
TFE 2008 - 2009
Syntaxe des Commandes
Syntaxe des Commandes
Les conventions d’écriture utilisées pour présenter les commandes sont les mêmes que
celles utilisées dans l’IOS Command Reference. L’IOS Command Reference définit ces
conventions comme suit :

Gras indique des commandes et mots-clés. Dans des configurations d’exemple
ou dans des résultats de commandes, des mots en gras indiquent des commandes
entrées par l’utilisateur (comme une commande show par exemple).

Italique indique des arguments pour lesquels l’utilisateur fournit une valeur.

Des barres verticales ( | ) séparent des choix mutuellement exclusifs.

Des crochets [ ] indiquent des paramètres facultatifs.

Des accolades { } indiquent un choix obligatoire.

Des accolades dans des crochets [{ }] indiquent un choix obligatoire à l’intérieur
d’un paramètre facultatif.
TFE 2008 - 2009
9
10
TFE 2008 - 2009
Introduction
Introduction
Ce travail de fin d’étude représente les 14 semaines de stage passées chez Cisco Systems
Inc. Mon choix s’est porté sur cette entreprise tout simplement parce que je suis
passionné par les réseaux et que cette entreprise était pour moi l’opportunité de me
plonger dans un milieu qui me fascine. Ce document est découpé en trois parties :

Première Partie : « Présentation de l’Entreprise » - Cette partie présente
l’entreprise, ses services, ses produits et son activité dans le monde des réseaux.

Deuxième Partie : « La team CALO » - Cette partie décrit une journée type
en tant qu’ingénieur dans la team CALO.

Troisième Partie : « Voice over Wireless LAN » - Cette partie concerne
mon travail de fin d’étude. Le déploiement d’une configuration type est utilisé
pour expliquer les technologies sur lesquelles s’appuie ce modèle.
Le sujet que j’ai choisi comme travail de fin d’étude me tenait particulièrement à cœur
car j’avais déjà eu l’occasion auparavant de mettre en place des réseaux VoIP grâce à
l’IPBX open-source Asterisk. L’intérêt dans ce travail était donc d’avoir un aperçu d’une
des solutions concurrentes. Cette étude me permet par la même occasion d’étendre mes
connaissances dans ce domaine qui se développe encore un peu plus chaque jour.
TFE 2008 - 2009
11
12
TFE 2008 - 2009
Chapitre 1 : Cisco Systems Inc.
Historique de l’Entreprise
L'histoire de Cisco Systems s'inscrit dans la tradition des entreprises nées dans la Silicon
Valley californienne où son nom et son logo puisent l'inspiration dans la ville de San
Francisco et dans son Golden Gate Bridge.
Tout a commencé en 1984 à San Jose dans le salon du couple formé par Leonard Bosack
et Sandy Lerner. Les deux scientifiques travaillaient à l'Université de Stanford et
cherchaient un moyen de simplifier la mise en réseau des ordinateurs. Un objectif qui
nécessitait le développement de technologies totalement nouvelles. L'avancée décisive
vint de l'élaboration d'un routeur performant, capable de relier différents réseaux entre
eux. Pour ce routeur, présenté pour la première fois sur le marché en 1986, Cisco a
développé un logiciel d'exploitation réseau basé sur des protocoles de communication
ouverts largement acceptés.
Depuis, l'entreprise connaît une croissance exponentielle. Avec ses routeurs,
commutateurs (switch), réseaux d'accès et logiciels réseau, Cisco s'impose comme le
leader mondial des solutions "réseau" pour Internet: plus de 50% de toutes les
autoroutes de l'information utilisent du matériel Cisco, alors que plus de 80% de la
technologie de base d'Internet émane des laboratoires de recherche et développement
de l'entreprise californienne.
TFE 2008 - 2009
13
14
Figure 1-1 : les logos Cisco
Depuis février 1990, les actions de Cisco sont cotées au Nasdaq (CSCO). En terme de
capitalisation boursière, Cisco est l'une des plus importantes entreprises traitées par la
bourse électronique des valeurs technologiques. Elle s'est hissée au rang des plus
grandes entreprises au monde dans l'industrie IT et emploie aujourd'hui environ 67000
collaboratrices et collaborateurs répartis dans plus de 200 bureaux de vente et plus de
75 pays. Elle a réalisé au cours de l'exercice 2008 un chiffre d'affaires de 39,5 milliards
de dollars. L'entreprise a en outre racheté au cours des années plusieurs dizaines
d'entreprises ayant développé des technologies d'avant-garde. Elle investit aussi plus de
4,5 milliards de dollars chaque année dans la recherche et le développement afin d'être
capable d'innover sans cesse.
En outre, avec l'acquisition de Linksys, Cisco s'est introduit dans les plus petites
entreprises ainsi que dans nos maisons. Cela permet à tout le monde d'avoir du matériel
et un service de qualité !
Pour exemple, voici une liste non exhaustive de ses domaine d'activités :
Applications réseaux
Stockage réseaux
Sécurité réseaux : Firewalls, VPN, Intrusion p/d, Web ...
Médias digital : TelePresence
Sécurité IP : Vidéo, Contrôle d'accès ...
Mobilité : Cisco Unified Communication
TFE 2008 - 2009
Structure Interne
Figure 1-2 : la structure de l’entreprise
L'entreprise se décline en quatre branches principales :




Manufacturing
Sales
Customer Advocacy
Engineering
Customer Advocacy (CA), mieux connu sous le nom de Cisco Services, est la branche
de Cisco proposant le support sur tout produit Cisco vendu. Comme beaucoup
d'entreprises, la différence par rapport au concurrent réside souvent dans la qualité du
service après vente. En effet, Cisco propose différents types de contrats, allant de 25$ à
plusieurs millions. Ces supports sont gérés par deux sous-branches : Advanced
Services (AS), et Technical Support Services (TS).
Advanced Services s'occupe des réseaux les plus grands et les plus complexes dans le
monde. Sont concernées les grandes entreprises et les ISP. AS crée, implémente et
optimise ces réseaux. Les Network Consulting Engineers implémentent également de
nombreuses technologies avancées.
TFE 2008 - 2009
15
16
Technical Support Services fournit quant à lui quatre types de support end-to-end :
Cisco.com, le TAC, Advance Hardware Replacement et Software Support :
Cisco.com
Il s'agit non seulement d'une mine d’informations sur tous les produits Cisco, mais aussi
un moyen d’ouvrir des Service Requests. En effet, chaque mois, plus de 200.000
requêtes sont résolues online, ce qui correspond à environ 80% du support technique.
Cisco.com fournit également différents outils et ressources (manuels, datasheet, ...), des
trainings, ...
Service Request (SR)
Les Service Requests, demandes de résolution d’un problème hardware ou software d’un
client, peuvent être ouvertes via mail, téléphone, ou interface web. Suivant la sévérité de
celles-ci (impact sur le business, et impact sur l'état du réseau), le moyen utilisé sera
différent. En effet, là ou les requêtes de priorités 3 et 4 (low priority) peuvent être
ouvertes via Cisco.com, les SRs de priorités 1 et 2 doivent être ouverts via téléphone.
Figure 1-3 : impact des SRs
Technical Assistance Center (TAC)
Le Technical Assistance Center, ou TAC, emploie plus de 1000 ingénieurs (Customer
Support Engineer) excellant chacun dans un domaine particulier, dont plus de la moitié
sont CCIE. Le TAC a pour but de résoudre les SRs, grâce à leurs connaissances, à
différents outils, à une reproduction des problèmes en laboratoire, et aussi à l’aide des
développeurs. Chaque membre du TAC étant spécialisé dans un domaine, des équipes
ont été créées, représentant chacune une technologie. Il s’agit de TAC 1.0. Les
différentes équipes étaient :



Routing / Core
Lan Switching
Wireless
TFE 2008 - 2009






Security
Optical
Wireline (ISP)
SAN
Voice
...
Depuis le premier semestre 2008, TAC 2.0 est né. Les groupes précédemment cités ont
été regroupés en trois factions : ANG (Video, Streaming, TCP Acceleration, Security,
Wireless, Storage, ...), DNG (Couches 2 et 3 : Lan Switching, Routing, Multicast, Core,
...) et VNG (Voice).
Plusieurs TAC sont répartis dans le monde. Cela permet à Cisco d'offrir un support 24h
sur 24 tout au long de l'année, grâce au modèle “Follow the Sun”. Quand un centre
termine la journée, un autre la commence :
Figure 1-4 : méthode Follow the Sun
Advance Hardware Replacement
Le remplacement et la réparation des pièces Cisco dans des délais très courts sont
possibles grâce aux 900 stocks disséminés dans environ 120 pays. Cisco possède environ
TFE 2008 - 2009
17
18
4 milliards de dollars de pièces de remplacement. Chaque année, 700.000 machines
sont échangées, et 500.000 réparées.
Software Support
Ce département fournit au client des mises à jour logicielles, permettant l’ajout de
nouvelles fonctionnalités, une amélioration des performances, mais surtout une
augmentation de la durée de vie des machines sans changements hardwares.
La Team CALO
La team CALO, pour Customer Advocacy Lab Operations est l’équipe qui s’occupe de la
gestion du laboratoire. Auparavant, les ingénieurs souhaitant une reproduction de
topologie devaient se rendre dans le laboratoire pour construire eux-mêmes leur
topologie. Ceci présentait de nombreux désavantages. Tout d’abord, l’ordre et
l’organisation du laboratoire étaient assez mauvais étant donné que tout le monde y
avait accès… De plus, les ingénieurs travaillant à domicile n’avait évidemment pas
l’occasion de se rendre dans le laboratoire, ce qui était pénalisant pour eux ! Finalement,
chaque équipe possédait ses propres machines ; il n’était pas possible d’utiliser les
machines d’une autre équipe.
Après l’arrivée de la team CALO, cela a changé. En effet, ce sont maintenant quelques
ingénieurs qui sont chargés de créer les topologies des ingénieurs. Pour ce faire, les
ingénieurs doivent créer des cases – similaires au Service Requests. La team CALO se
charge aussi de la maintenance du laboratoire : installation, remplacement ou
suppression de matériel, cable cleaning (nettoyage des câbles non utilisés) et inventaire
du matériel font partie du quotidien des ingénieurs CALO. C’est dans cette équipe que
nous avons passé nos 14 semaines de stage.
Le Laboratoire
Le laboratoire de Diegem est le deuxième plus grand laboratoire du monde... rien que
ça ! Le premier est le laboratoire de RTP – celui qui se situe sur la côte est des EtatsUnis. Le laboratoire de Cisco Belgium comporte plus de 6000 machines (routeurs et
switchs) pour un total de plus de 40000 objets – cartes, sous-modules, etc. Ce
laboratoire est découpé en deux étapes. La grande majorité de la gamme des produits
Cisco y est représentée, mais du matériel d’autres constructeurs y est aussi présent.
Le Réseau
L’infrastructure du laboratoire est assez particulière : elle est basée sur le switching. En
effet, chaque équipe du TAC s’est vu assigner un VLAN. Nous retrouvons donc un réseau
de type Campus Switching :
TFE 2008 - 2009
Figure 1-5 : infrastructure du lab
La couche core est composée d’un Cisco Catalyst 6500 équipé d’un superviseur 720. Ce
switch joue le rôle de serveur VTP ; il distribue les VLANs de chaque team à la couche
distribution.
La couche distribution se compose de 2960G et de 3750. Chaque street du
laboratoire possède un de ces switchs. Ce sont ces switchs qui sont configurés en tant
que clients VTP.
Les switchs Matrix représentent la couche access du réseau. Ces switchs sont de type
5500, 6500 ou encore 2950. Des hubs équipent encore certaines streets – rassurezvous, ils devraient être remplacés sous peu !
TFE 2008 - 2009
19
20
Les Commservers
Figure 1-6 : commserver
L'accès aux différents devices est assuré par l'intermédiaire des commservers du
laboratoire. Ce sont généralement des routeurs Cisco 2500, 2600 ou 2800. La photo cidessous illustre un Cisco 2801 équipé d’une carte HWIC-16A permettant de connecter
16 autres consoles :
Figure 1-7 : module HWIC-16A
Un simple telnet sur le commserver en indiquant le port adéquat nous permet
d'accéder à la console du device ciblé. Pour plus de simplicité, tous les devices sont
enregistrés avec un ou plusieurs couples [nom commserver, port] permettant ainsi d'y
accéder plus simplement en utilisant le script ttelrout :
$ ttelrout [-k2] <device name>
L'option -k nous permet de fermer une éventuelle session qui n'aurait pas été fermée
proprement et -2 nous permet d'accéder à la deuxième console du routeur ou du switch
en question.
TFE 2008 - 2009
Les consoles provenant des commservers sont généralement regroupées sur des patchs
panels permettant ainsi de connecter la console d'un routeur sur le bon port du
commserver plus facilement qu'en suivant le câble de bout en bout :
Figure 1-8 : patch panel
Les Machines Virtuelles
Il arrive que, dans certaines reproductions de topologies, l'ingénieur demande une ou
plusieurs machines virtuelles. Ils en ont besoin pour installer des logiciels d'analyses,
pour générer du trafic spécifique ou tout simplement pour tester des cas de figures
problématiques en s'approchant le plus possible de la topologie complète du client.
Ces machines virtuelles permettent, en plus d'une économie d'argent et d'une plus
grande disponibilité, une facilité de maintenance que des machines classiques ne
peuvent apporter. En quelques clics, on peut ajouter des interfaces réseaux, les
connecter dans différents VLAN, réaliser des snapshots, réinitialiser la machine à son
état initial, ...
Le TAC à Diegem utilise VMWare ESX Server installé sur un Blade Center. Il y a
plusieurs sortes d'images déjà prêtes à l'emploi : Ubuntu, Windows XP, Windows Vista,
Windows Server, etc. La réservation d'une machine virtuelle s'effectue de la même façon
que pour les routeurs ou les switchs. Une fois une machine virtuelle associé à un case,
on la configure et on accorde à l'ingénieur les droits nécessaires pour qu'il puisse
l'utiliser.
TFE 2008 - 2009
21
22
Figure 1-9 : VMWare ESX Server
TFE 2008 - 2009
Chapitre 2 : Le Travail de Tous les Jours
L’Arrivée
Au cours de ces 14 semaines de stages chez Cisco, nous avons eu l’occasion de travailler
au sein de la team CALO. Dès notre arrivée, nous avons été accueilli par l’équipe. Nous
nous sommes ensuite installés à nos bureaux et avons commencé les quelques
démarches administratives nécessaires – activation des comptes utilisateurs pour avoir
accès à certains sites intranet.
Une réunion très brève a suivi. Durant cette réunion, l’organisation interne de Cisco a
été présentée et on nous a appris le rôle de la team CALO. Nous avons directement été
considérés en tant qu’employés : on nous a attribué des tâches presque immédiatement !
Les Cases – Omnitool
Lorsqu’un ingénieur reçoit un Service Request de la part d’un client et qu’il a besoin
d’une reproduction de topologie pour effectuer des tests, il doit ouvrir ce que l’on appelle
un case. Il fournit les informations nécessaires aux ingénieurs CALO afin qu’ils puissent
construire la topologie demandée. Les cases possèdent une priorité relative à la sévérité
du Service Request. Evidemment, un case avec une priorité P1 est plus important qu’un
case avec une priorité P4 :
Priorité
CAPS
P1
P2
P3
P4
Assignation
Dans les 10 minutes
Dans les 15 minutes
Dans les 4 heures
Dans les 24 heures
Dans les 24 heures
Résolution
Dans les 4 heures
Dans les 4 heures
Dans les 24 heures
Dans les 2 jours
Dans les 5 jours
Table 2-1 : priorités des cases
Il est possible de visualiser les cases ouverts grâce à un outil qui s’appelle Omnitool :
TFE 2008 - 2009
23
24
Figure 2-1 : Omnitool – vue globale des cases
Cette page affiche plusieurs informations intéressantes comme l’âge du case, sa priorité
ou encore son statut. Il existe pas mal de statut différents :







Open : le case a été ouvert mais n’a pas encore assigné à quelqu’un ;
Assigned : le case est assigné mais le propriétaire n’y travaille pas encore ;
Work in Progress : le propriétaire du case travaille sur le case ;
Pending Client : le propriétaire attend une réponse de l’ingénieur ;
Pending Approval : la topologie a été soumise à l’ingénieur ;
Pending Hardware : du matériel manquant empêche la résolution du case ;
Closed (Resolved) : le case est terminé et est fermé.
Lorsque l’on clique sur un case, une page plus détaillée fait son apparition. On y
retrouve beaucoup plus d’informations. Ainsi, on sait si l’ingénieur a besoin d’une
connexion au backbone, on peut également estimer le temps que le matériel doit être
réservé ou encore jeter un œil au Service Request associé au case :
TFE 2008 - 2009
Figure 2-2 : Omnitool – vue détaillée d’un case
Un description permet à l’ingénieur d’expliquer son problème et d’indiquer le matériel
dont il a besoin :
Figure 2-3 : Omnitool – vue détaillé d’un case (suite)
Dans ce cas-ci, on peut voir que l’ingénieur a besoin d’un Cisco 7600 équipé de trois
cartes spécifiques. Il demande également qu’une certaine image soit chargée sur le
7600 ; ceci arrive très fréquemment. Un deuxième périphérique quelconque doit y être
relié via trois liens – 2 Gigabit et 1 TenGig !
Le bas de la page est réservé aux éventuelles mises à jour et au dialogue avec l’ingénieur.
C’est ici qu’on prévient l’ingénieur lorsqu’une topologie est construite. C’est aussi ici que
TFE 2008 - 2009
25
26
l’on pose nos questions lorsqu’un détail n’est pas très clair, ceci évite de perdre du temps
inutilement !
Lorsqu’un case est achevé, l’ingénieur a la possibilité de laisser une appréciation –
appelée Bingo – allant de 1 à 5 et jugeant la qualité du travail de l’ingénieur CALO.
Quelques jours plus tard – voire des fois beaucoup plus tard, l’ingénieur nous informe
que le case peut être fermé ; il faut alors libérer le matériel utilisé.
Réservation du Matériel – Checkout
Le matériel ne peut pas être utilisé comme ça, il doit d’abord être réservé. C’est la
fonction de l’outil Checkout. Cet outil de recherche permet à l’ingénieur CALO d’entrer
des critères de recherche sur lesquels l’outil se base pour fournir une liste du matériel
qui correspond auxdits critères.
Par exemple, il est possible de rechercher un routeur 2811 disponible qui se situe près de
la street 16. Ce genre de critère peut éviter de devoir câbler un long parcours alors que
deux périphériques proches sont disponibles.
Figure 2-4 : Checkout – résultat d’une recherche
L’outil fonctionne avec un système de panier. On ajoute les routeurs ou switchs qui nous
intéressent et à la fin on passe « à la caisse ». Il faut alors fournir l’identifiant du case
ainsi que la période pour laquelle on souhaite réserver le matériel. Les cartes et modules
ne sont malheureusement pas réservées, il faut donc des fois passer 20 minutes à
chercher une carte parmi les deux étages du laboratoire !
TFE 2008 - 2009
Taches Administratives
Conjointement à la résolution de cases – qui restent la principale activité d’un ingénieur
CALO, nous nous occupions également de quelques tâches d’entretien du laboratoire –
également appelée tâches administratives. Elle sont supposées prendre 20% du temps
d’un étudiant chez CALO.
Lab Scanning
Tous les éléments dont le laboratoire dispose sont référencés dans une base de donnée à
l'aide de codes barres permettant de les identifier uniquement. Ces codes barres sont
appelés des EITMS (Enhanced Inventory Tracking & Management System). Ces EITMS
sont de petites étiquettes que l'on colle sur les nouvelles cartes ou châssis qui sont
destinés à être utilisé dans le laboratoire. Grâce à ces codes barres, on peut recenser tous
les éléments, avec un scanner de codes barres USB, permettant ainsi de connaître
l'emplacement exacte des cartes ou des châssis. On essaye de scanner chaque semaine
une partie du laboratoire (3-4 streets) pour actualiser suffisamment l'inventaire et
faciliter ainsi la recherche des différentes cartes dans cet immense laboratoire réparti
sur deux étages.
Pour savoir exactement où se situe la carte ou le routeur, il faut procéder dans cet ordreci lors du scanning d'une street :







Scanner le code barre du rack,
Scanner le code barre du premier châssis,
Scanner les codes barres des cartes que ce châssis contient,
re-scanner le code barre du châssis pour signaler qu'on quitte celui-ci,
scanner le code barre du nouveau châssis,
... ,
re-scanner le code barre du rack pour le fermer à son tour.
Cable Cleaning
Le cable cleaning est la deuxième tâche administrative et sans doute la plus
ennuyeuse et la plus longue de toutes. Elle consiste à enlever les câbles qui ne sont plus
utilisés dans le laboratoire. Ceci a deux avantages importants : tout d’abord, le
laboratoire est plus propre dans le sens où il est beaucoup moins bordélique qu’avant ;
ensuite, cela met à disposition des ingénieurs CALO beaucoup plus de câbles – il m’est
déjà arrivé de devoir parcourir le lab pour trouver un câble croisé.
Une tournante a été mise en place afin que chaque étudiant scanne une partie différente
du laboratoire chaque semaine. Sans cette tournante, il est évident que le laboratoire
serait un endroit où il est beaucoup moins agréable de travailler... Néanmoins cette
tâche peut être réalisée relativement vite si on l’exécute à deux : un étudiant déconnecte
TFE 2008 - 2009
27
28
le câble qui n’est plus utilisé (en vérifiant sur Checkout) et l’autre retire le câble – qui est
souvent emmêlé dans d’autres câbles.
TFE 2008 - 2009
Chapitre 3 : Introduction à la Voix sur IP
La voix sur IP définit un moyen de faire transiter des appels téléphoniques classiques
sur un réseau IP en convertissant ces appels en paquets de données. Le réseau IP utilisé
peut tout aussi bien être un réseau WAN (comme Internet) ou un réseau LAN (un
réseau local). La voix sur IP, que l’on appelle généralement VoIP (Voice over IP) utilise
des protocoles de session pour établir la communication ainsi que des codecs audio pour
encoder – et éventuellement compresser – le signal analogique, c'est-à-dire la voix, afin
qu’il puisse être transmis sur le réseau IP.
Les avantages de la voix sur IP sont nombreux. Premièrement, le coût est largement
réduit. En effet, la voix sur IP utilise le même média que les données : le réseau IP. De
plus, des fonctionnalités telles que l’IVR, le caller ID ou le call forwarding sont
généralement facturées par le fournisseur de la ligne analogique. Dans le cas de la voix
sur IP, ces fonctionnalités sont gratuites. Deuxièmement, la voix sur IP est beaucoup
plus flexible que le système téléphonique traditionnel. La sécurisation des appels peut
être faite très facilement, rajouter une ligne à un téléphone est un jeu d’enfant et un
téléphone IP peut être installé n’importe où, ne nécessitant qu’une connexion au réseau.
Plusieurs équipementiers réseaux fournissent des solutions VoIP. Nous pouvons citer
parmi eux Alcatel-Lucent et son OmniPCX ; Digium avec Asterisk et Cisco Systems Inc.
pour sa plateforme Unified Communications. Ces solutions fournissent généralement un
PABX IP, souvent abrégé IPBX.
Un IPBX (Internet Private Branch eXchange) désigne un autocommutateur
téléphonique privé, assumant ainsi l’acheminement des appels téléphoniques VoIP ou
non. Un IPBX peut très bien interagir avec une ligne téléphonique classique afin de
pouvoir émettre des appels externes. Il fournit également certaines fonctionnalités telles
que le transfert d’appel, la mise en garde, etc. L’IPBX développé par Cisco s’appelle
Unified Communications Manager.
La voix sur IP est une technologie relativement récente puisqu’elle fut standardisée en
1996 par l’ITU-T avec le standard H.323. Ce « système de communication multimédia
en mode paquet » regroupe un ensemble de protocoles qui gèrent la signalisation, la
voix, la vidéo et les données.
Cisco Systems se lança lui aussi dans la voix sur IP. Anciennement développé par Selsius
Corporation, SCCP (Skinny Client Control Protocol) fut racheté par Cisco en 1998. SCCP
est un protocole léger qui s’occupe de la signalisation entre un téléphone IP et l’Unified
Communications Manager de Cisco. Le flux de données repose quant à lui sur RTP.
En 1999, le protocole SIP (Session Initiation Protocol) fut inauguré. Défini par l’IETF
dans la RFC 3261, ce protocole reprend les meilleurs aspects du système H.323. En effet,
TFE 2008 - 2009
29
30
ce dernier souffrait d’une grosse lacune : chaque fabriquant implémentait H.323 à sa
manière, rendant ce système censé être interopérable assez difficile à mettre en place.
L’IPBX open-source Asterisk a également contribué à la popularisation du protocole
SIP.
Asterisk possède également son propre protocole, nommé IAX (Inter-Asterisk
eXchange). Bien que non standardisé, ce protocole présente un avantage intéressant : la
signalisation et les données (la voix) utilisent le même port. C’est une problème bien
connu des autres protocoles VoIP : il est en effet difficile de traverser du NAT ou un
firewall car les ports RTP sont choisis dynamiquement. Néanmoins, ce protocole n’est
que très peu répandu : les téléphones IP supportant ce protocole pourraient se compter
sur les doigts d’une main…
Le Système H.323
Le système H.323, dérivé du protocole H.320 utilisé sur RNIS, est une association de
différents protocoles que l’on peut regrouper en trois catégories : la signalisation, la
négociation de codec et le transport de l’information.
Parmi ces protocoles, on peut citer RAS qui s’occupe du contrôle de session. H.225 est le
protocole qui gère la signalisation des appels entre utilisateurs. Le protocole H.245 est
quant à lui responsable de la négociation des codecs, afin de s’assurer que les deux
participants puissent communiquer. Un troisième protocole important, RTP, gère
l’envoi et la réception des données multimédia – la voix, la vidéo ou encore du texte.
D’autres protocoles font partie du système H.323 et fournissent des services
supplémentaires comme la sécurité (H.235) ou bien la gestion de firewall (H.460).
Cependant, ces derniers ne sont pas essentiels au fonctionnement d’un système VoIP
classique.
Plusieurs éléments composent un système H.323 :

Terminal : ce terme décrit tout simplement l’équipement employé par l’utilisateur
final, que ce soit un téléphone IP classique ou un système de vidéoconférence
haute définition.

MCU : le MCU (Multipoint Control Unit) s’occupe des conférences multipoint. Ce
dispositif permet par exemple à un utilisateur de voir et d’étendre tous les
participants de la conférence en même temps.

Gateway : la passerelle permet la communication entre un réseau H.323 et des
réseaux d’autres types tels que ISDN ou PSTN. Les passerelles sont largement
utilisées pour interconnecter des réseaux VoIP avec des lignes téléphoniques
analogiques afin de pouvoir effectuer des appels vers l’extérieur.
TFE 2008 - 2009

Gatekeeper : le gatekeeper est optionnel et fournit des services aux terminaux,
MCU et passerelles : enregistrement, résolution d’adresse, authentification, etc.
Dans le contexte de H.323, c’est le gatekeeper qui joue le rôle de l’IPBX.
Fonctionnement de H.323
Le fonctionnement interne d’un système H.323 peut être très complexe dans certains
cas. J’ai donc décidé de le simplifier pour en expliquer les principes fondamentaux.
Considérons le cas où deux clients enregistrés auprès d’un gatekeeper souhaitent
communiquer.
Figure 3-1 : H.323
Premièrement, les deux utilisateurs doivent s’enregistrer auprès du gatekeeper en lui
fournissant leur ID H.323 ainsi que leur adresse IP. Le gatekeeper peut alors établir une
table de correspondance entre l’ID et l’adresse IP de l’utilisateur. Le client A demande
ensuite au gatekeeper l’autorisation de contacter le client B. Si le gatekeeper accepte, il
renvoie au client A l’adresse IP du client B, à condition que ce dernier ne soit pas déjà
occupé. Le gatekeeper prévient alors le client B qu’une communication avec le client A
va avoir lieu. Cette signalisation est effectuée grâce au protocole H.225. Il est important
de noter qu’à ce stade, les deux clients ne communiquent pas directement, ils passent
par le gatekeeper.
Ensuite, les deux clients peuvent commencer à négocier les codecs qu’ils vont utiliser.
Cette étape est importante, car si aucun accord n’est trouvé, la communication ne peut
pas s’effectuer. C’est le protocole H.245 qui est responsable de cette négociation.
Finalement, des ports destinés au transport RTP sont ouverts de chaque coté. La
communication proprement dite passe par ces ports. A la fin de la session, le gatekeeper
TFE 2008 - 2009
31
32
est informé de la fin de la connexion : les ports sont libérés et les transmissions de
contrôle arrêtées.
Le Protocole SIP
Le protocole SIP est depuis 2007 le protocole de signalisation VoIP le plus courant. Se
trouvant dans la couche Application du modèle TCP/IP, ce protocole a un
fonctionnement similaire à celui de HTTP (requête/réponse). Il en reprend d’ailleurs la
plupart des entêtes et des codes de retour.
SIP utilise généralement les ports 5060 et/ou 5061. Il encapsule SDP (Session
Description Protocol) qui décrit la session proprement dite. SIP est donc uniquement
un protocole de signalisation. Il utilise RTP pour le transfert de l’information, tout
comme son grand frère H.323.
Un réseau SIP est composé de trois grands types d’éléments :

User Agent : un User Agent (UA) peut émettre et recevoir des messages SIP. Un
UA joue à la fois le rôle de User Agent Client (UAC) – qui émet des messages SIP
et celui de User Agent Server (UAS), c'est-à-dire qu’il peut répondre à des
requêtes SIP. La plupart des périphériques SIP est capable de jouer ces deux
rôles. Ces UA sont identifiés par une URI de type sip:user:pass@host:port ;

Registrar : le registrar gère les requêtes de type REGISTER. A la manière du
gatekeeper d’un système H.323, il maintient une base de données contenant
l’adresse IP d’un utilisateur à laquelle il fait correspondre une URI ;

Proxy : un proxy SIP ne sert que d’intermédiaires entre deux UAs. Il relaye les
messages d’un coté ou de l’autre.
Messages SIP
Le protocole SIP définit plusieurs types de messages, regroupés en deux catégories : les
requêtes et les réponses. Rappelons que la syntaxe est identique à celle de HTTP.
Requêtes :






REGISTER : signale l’adresse IP et l’URI d’un User Agent ;
INVITE : demande l’établissement d’une nouvelle session ;
ACK : confirme l’établissement de cette session ;
CANCEL : termine une requête INVITE en attente ;
BYE : termine la session en cours ;
OPTIONS : demande les capacités de l’appelant.
Réponses :
TFE 2008 - 2009






Provisional (1xx) : requête reçue, en cours de traitement ;
Success (2xx) : requête reçue et acceptée ;
Redirection (3xx) : un action de l’utilisateur est nécessaire ;
Client Error (4xx) : la requête est invalide et ne peut donc pas être traitée par le
serveur ;
Server Error (5xx) : le serveur ne peut traiter la requête, erreur interne ;
Global Failure (6xx) : la requête ne peut être traitée par aucun serveur.
Parmi ces codes de retour, on en retrouve quelques uns qui nous sont déjà un peu
familiers : 100 TRYING, 200 OK, 4O4 NOT FOUND ou encore 500 SERVER ERROR.
Le protocole SIP a cependant quelques codes de retours qui lui sont propres : 180
RINGING, 486 BUSY ou plus généralement les codes x80.
Fonctionnement de SIP
Le protocole SIP est assez simple à comprendre dans le sens où c’est un protocole avec
une architecture requête/réponse dont les messages sont codés en ASCII, ce qui les rend
lisibles pour à peu près tout le monde. Le schéma suivant illustre une session SIP à
travers un proxy.
TFE 2008 - 2009
33
34
Figure 3-2 : session SIP
Ce schéma est assez explicite. Les deux clients étant auparavant enregistrés auprès du
registrar, le client A décide d’appeler le client B. Cette demande de session se traduit par
l’envoi d’une requête INVITE. Dans ce cas, le proxy ne sert qu’à retransmettre les
messages de part et d’autres, sont rôle n’est donc pas très important. Le client B reçoit la
requête INVITE et envoie le code de retour 100 TRYING pour prévenir le client A que la
requête a bien été reçue et qu’elle est actuellement traitée. Le téléphone du client B va
ensuite sonner, ce qui générera un message vers le client A suivi d’un 200 OK pour dire
que tout s’est bien passé. Le client A doit finalement confirmer l’établissement de la
session en envoyant au client B une requête ACK. La communication est maintenant
établie.
SIP n’interviendra plus durant l’échange vocal, c’est RTP qui va prendre la main pour
gérer les flux de données.
A la fin de la communication, le client A termine l’appel, ce qui engendre une requête
BYE. Le client B accepte et renvoie le code 200 OK. La session SIP est terminée.
TFE 2008 - 2009
Codecs Audio
Il existe une multitude de codecs audio. Ces derniers sont généralement négociés lors de
l’établissement de la session. Ils sont essentiels au bon fonctionnement d’un réseau
VoIP car deux clients ne pourraient pas communiquer s’ils n’utilisent pas le même codec
– que l’on pourrait associer à « parler le même langage ». Ces codecs ont des
caractéristiques différentes qui rendent leur utilisation préférable dans certains cas.
Voici un tableau reprenant la plupart des codecs actuels :
Codec
G.711
G.729
G.723.1
G.723.1
G.726
G.728
GSM
iLBC
Débit
64 Kbps
8 Kbps
6.3 Kbps
5.3 Kbps
32 Kbps
16 Kbps
13.2 Kbps
15.2 Kbps
Score MOS
4.45
3.92
3.9
3.65
3.85
3.61
3.5
4.14
BP 802.3
87.2 Kbps
31.2 Kbps
21.9 Kbps
20.8 Kbps
55.2 Kbps
31.5 Kbps
28.7 Kbps
30.83 Kbps
1 heure
38.3 MB
13.7 MB
9.6 MB
9.1 MB
24.2 MB
13.8 MB
12.6 MB
13.5 MB
Tableau 3-1 : codecs audio
La plupart des noms de codecs commencent par un G. et sont des codecs qui ont été
standardisé par l’ITU-T, l’organisation qui s’occupe également de H.323. Le codec GSM
est similaire à celui utilisé sur les appareils portant le même nom. Ces codecs peuvent
être différenciés par la bande passante qu’ils nécessitent, par la qualité du son qu’ils
fournissent ou encore par la puissance de calcul dont ils ont besoin pour coder le signal.
La quatrième colonne indique la bande passante utilisée par le codec lorsque celui-ci est
encapsulé dans une frame Ethernet 802.3. La dernière colonne se base sur ces données
pour donner une idée de la consommation après une heure d’utilisation. Le choix d’un
codec adéquat peut donc faire épargner jusque 30 MB par heure… ce n’est pas énorme,
mais pour une entreprise de 500 personnes, ce n’est pas négligeable (15 GB par heure !).
Evidemment, ces données ne sont pas représentatives mais permettent de plus ou moins
mesurer l’impact d’un choix de codec.
Le score MOS (Mean Opinion Score) représente la qualité de restitution sonore d’un
codec. Cette note peut varier de 0 à 5 – respectivement très mauvais et excellent. Les
tests MOS sont spécifiés par la recommandation P.800 de l’ITU-T. Ces tests sont très
souvent réalisés sur un certain panel de la population, auquel on fait écouter un son et
ensuite son équivalent codé. Les auditeurs doivent ensuite noter la qualité du son et ce
sont ces notes qui constituent le score MOS.
Tous ces codecs ont le même rôle :

Numériser le signal analogique entrant. Ce signal doit être converti sous forme
numérique suivant le format PCM (Pulse Code Modulation) à 64 Kbps ;
TFE 2008 - 2009
35
36

Compresser le signal numérique. Cette compression est le plus souvent réalisée
par un DSP (Digital Signal Processor). Le signal compressé est ensuite encapsulé
dans des paquets IP. Si la bande passante est suffisante, il est possible de
transférer le signal à 64 Kbps ;

Du coté du récepteur, c’est la démarche inverse qui doit être effectuée. Le signal
numérique est décompressé pour ensuite subir une reconversion analogique.
La Solution Cisco
Cisco Unified Communications
La plateforme Unified Communications (UC) de Cisco a pour principal but de simplifier
et de rassembler toutes formes de communications telles que les appels téléphoniques,
la vidéo, les e-mails ou encore la messagerie instantanée. Une vaste panoplie de logiciels
compose cette solution : Manager, Unity, MeetingPlace, Workspace, Mobile
Communicator, …
Le produit qui va nous intéresser tout au long de ce document est Communications
Manager, ou plutôt sa version allégée appelée Communications Manager Express.
Cisco UC Manager Express (UCME)
Cisco UC Manager Express (UCME) est un IPBX compatible H.323, MGCP, SIP et
SCCP. Il peut supporter jusqu’à 240 utilisateurs. Sa particularité par rapport à son
grand frère est qu’il tourne sur un routeur et non sur un serveur. Ceci a l’avantage de
limiter les coûts de l’installation si le nombre d’utilisateurs ne dépasse pas la limite fixée
par UC Manager Express.
Autrefois connu sous le nom de Call Manager Express, la version de UC Manager
Express a récemment été revue à la hausse afin que les numéros de version de tous les
produits Unified Communications soient alignés. La version actuelle est la 7.1.
TFE 2008 - 2009
Chapitre 4 : Prise en main d’UC Manager Express
Le lab final a été découpé en plusieurs étapes. Ce chapitre présente la première étape,
qui est relativement simple et basique puisqu’elle se contente de permettre aux
téléphones IP de s’appeler. Chaque chapitre qui suivra reprendra le lab du chapitre le
précédant et y rajoutera une fonctionnalité plus ou moins importante.
Présentation du Matériel
Cisco ISR 2801
Le Cisco Integrated Service Router 2801 est un routeur hautes-performances équipé de
deux interfaces 10/100 Mbps. Il peut contenir jusqu’à quatre modules VIC/WIC/HWIC.
La série 2800 ISR a été optimisée pour un transport rapide et sécurisé de données, voix
et vidéo, ce qui implique le support de UC Manager Express.
Figure 4-1 : Cisco 2801 ISR
Cisco Catalyst 2960
Le Catalyst 2960 est un switch 24 ports qui supporte Power over Ethernet et Quality of
Service. Ces deux fonctionnalités sont importantes dans notre cas car elles permettent
respectivement d’alimenter les téléphones IP et access points au travers du réseau,
supprimant le besoin d’adaptateurs secteurs supplémentaires ; et s’assurent que le trafic
réseau est correctement classifié, évitant de la meilleure manière possible tout
congestion.
Figure 4-2 : Cisco Catalyst 2960
TFE 2008 - 2009
37
38
Cisco Unified IP Phones
Les deux téléphones IP que j’ai utilisé dans les premiers labs sont des téléphones
“câblés”. J’ai choisi deux modèles différents : un 7960 et un 7941G-GE. Le suffixe –GE
veut simplement dire que le switch interne du téléphone IP supporte les liens Gigabit.
Ces deux téléphones IP possèdent un écran LCD assez large, ce qui le rend plutôt
confortable à utiliser. Il est intéressant de noter que le 7941G-GE utilise Java.
Figure 4-3 : Cisco Unified IP Phone 7941G-GE
Première Topologie
Voici ce à quoi ressemblera la topologie du premier lab :
Figure 4-4 : topologie du premier lab
TFE 2008 - 2009
Switched Port Analyzer (SPAN)
Le SPAN, également appelé Port Mirroring ou Port Monitoring, copie artificiellement les
paquets venant d’une ou plusieurs interfaces sources vers une interface de destination
où l’on y connecte généralement un sniffer ou tout autre analyseur réseau.
Figure 4-5 : SPAN
J’ai utilisé du SPAN dans les labs afin de voir le trafic passant par le switch. Cela m’a
permis d’observer des processus d’arrière-plan qui ne sont pas toujours visibles pour
l’utilisateur final.
La configuration qui suit copie simplement tout le trafic venant du port Fa0/1 vers le
port Fa0/23 auquel un ordinateur portable équipé de Wireshark est connecté.
(config)#monitor session 1 source interface FastEthernet0/1
(config)#monitor session 1 destination interface FastEthernet0/23
D’autres variantes du SPAN existent mais n’ont pas été utilisées dans mon cas. On y
retrouve RSPAN (Remote SPAN) et ERSPAN (Encapsulated Remote SPAN).
Power over Ethernet (PoE)
J’ai décidé de décrire cette technologie avant d’aborder la configuration de UC Manager
Express car je trouve que ces deux sujets n’ont pas grand-chose à voir l’un avec l’autre.
Cette partie est néanmoins importante car Power over Ethernet est une technologie très
utile. Examinons son fonctionnement d’un peu plus près…
Power over Ethernet est une technologie utilisée pour alimenter des périphériques
réseau tels que des access points, des téléphones IP ou encore des caméras. Deux
méthodes permettent d’exploiter la technologie PoE :


IEEE 802.3af
Cisco Inline Power (ILP)
TFE 2008 - 2009
39
40
La première méthode, 802.3af est standardisée et offre une interopérabilité entre
constructeurs. Cette norme fut ratifiée le 11 juin 2003 et publiée le 11 juillet 2003. Les
périphériques connectés sont détectés par le switch qui applique une tension sur
chacune des paires de données du câble UTP. Il peut ensuite mesurer la résistance sur
ces paires afin de détecter si oui ou non un périphérique consomme du courant. Une
résistance de 25 kOhm indique qu’un périphérique PoE est présent. 802.3af définit
également cinq classes correspondant chacune à une valeur de résistance. Ces classes
permettent de fournir au périphérique uniquement la puissance dont il a besoin. Le
tableau qui suit liste ces classes :
Classe
0 (par défaut)
1
2
3
4
Puissance Maximale
15.4 Watts
4.0 Watts
7.0 Watts
15.4 Watts
Réservé
Tableau 4-2 : les classes IEEE 802.3af
La classe par défaut est utilisée lorsque le périphérique ne supporte pas la
« découverte » des classes 802.3af.
La deuxième méthode est différente. Cisco Inline Power est, comme son nom l’indique,
une technologie propriétaire développée par Cisco. Cette méthode a été développée
avant la norme 802.3af. La détection du périphérique est réalisée par l’envoi d’une
signal de test à 340 KHz sur les paires de transmission (Tx). Un périphérique PoE
comme un téléphone IP boucle les paires Tx/Rx de son câble Ethernet lorsqu’il est
éteint. Dès qu’il est connecté à un switch PoE, le switch récupère son signal de test et
sait qu’il peut alors alimenter le périphérique.
Power over Ethernet fournit une tension de 48 Volts DC. Cisco ILP utilise les paires 2 et
3 (pins 1-2 et 3-6) tandis que 802.3af utilise soit les paires 2 et 3 ou les paires 1 et 4 (pins
4-5 et 7-8).
TFE 2008 - 2009
Figure 4-6 : pins Power over Ethernet
C’est la technologie Cisco ILP qui a été utilisée tout au long du lab car le matériel utilisé
est du matériel Cisco. Les deux méthodes sont supportées, cependant ILP est utilisé par
défaut.
Commençons par connecter un téléphone IP au switch. Les résultats suivants ont été
obtenus grâce à la commande show power inline :
rogue-sw1#show power inline
Available:370.0(w) Used:6.3(w)
Interface Admin
Oper
Remaining:363.7(w)
Power
(Watts)
--------- ------ ---------- ------Fa0/1
auto
on
6.3
Fa0/2
auto
off
0.0
Fa0/3
auto
off
0.0
Fa0/4
auto
off
0.0
Fa0/5
auto
off
0.0
Fa0/6
auto
off
0.0
Fa0/7
auto
off
0.0
...
Device
Class Max
------------------IP Phone 7960
n/a
n/a
n/a
n/a
n/a
n/a
----n/a
n/a
n/a
n/a
n/a
n/a
n/a
---15.4
15.4
15.4
15.4
15.4
15.4
15.4
Chaque port est configuré en mode auto par défaut. Il y a trois différents modes:

auto : détecte et alimente automatiquement le périphérique ;
TFE 2008 - 2009
41
42


static : applique une tension à un périphérique qui ne pourrait interagir ni avec
ILP ni avec 802.3af ;
never : Power over Ethernet est désactivé sur ce port.
Le mode peut être changé en utilisant la commande suivante :
rogue-sw1(config-if)#power inline {auto | static | never}
On peut constater que le switch connaît le modèle du téléphone IP connecté et la
puissance dont il a besoin. Ces informations sont envoyées par le téléphone IP via des
annonces CDP. On peut le vérifier en activant le debug pour ILP :
rogue-sw1#debug ilpower powerman
rogue-sw1#
*Mar 2 23:29:57.633: Ilpower PD device 1 class 2 from interface (Fa0/1)
*Mar 2 23:29:57.633: ilpower new power from pd discovery Fa0/1, power_status
ok
*Mar 2 23:29:57.633: Ilpower interface (Fa0/1) power status change,
allocated power 15400
*Mar 2 23:29:58.061: %ILPOWER-5-POWER_GRANTED: Interface Fa0/1: Power
granted
*Mar 2 23:30:01.534: ilpower_powerman_power_available_tlv: about sending
patlv on Fa0/1
*Mar 2 23:30:01.534:
req id 0, man id 1, pwr avail 15400, pwr man -1
*Mar 2 23:30:02.004: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed
state to up
*Mar 2 23:30:02.004: ilpower_powerman_power_available_tlv: about sending
patlv on Fa0/1
*Mar 2 23:30:02.004:
req id 0, man id 1, pwr avail 15400, pwr man -1
*Mar 2 23:30:03.010: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/1, changed state to up
*Mar 2 23:30:05.409: Interface(Fa0/1) - processing old tlv from cdp, request
6300, current allocated 15400
*Mar 2 23:30:05.409: Interface (Fa0/1) efficiency is 100
Les annonces CDP capturées par Wireshark nous démontrent exactement la même
chose :
TFE 2008 - 2009
Figure 4-7 : annonces CDP dans Wireshark
Dernière vérification, j’ai désactivé CDP sur l’interface F0/1 du switch. J’ai ensuite
débranché le téléphone IP, nettoyé la table CDP et rebranché le téléphone. La
commande show power inline affiche maintenant :
rogue-sw1(config)#interface FastEthernet0/1
rogue-sw1(config-if)#no cdp enable
rogue-sw1(config-if)#^Z
rogue-sw1#
rogue-sw1#clear cdp table
rogue-sw1#show power inline
Available:370.0(w) Used:15.4(w) Remaining:354.6(w)
Interface Admin
Oper
Power
(Watts)
--------- ------ ---------- ------Fa0/1
auto
on
15.4
Fa0/2
auto
off
0.0
Fa0/3
auto
off
0.0
Fa0/4
auto
off
0.0
Fa0/5
auto
off
0.0
Fa0/6
auto
off
0.0
Fa0/7
auto
off
0.0
...
Device
Class Max
------------------Cisco PD
n/a
n/a
n/a
n/a
n/a
n/a
----n/a
n/a
n/a
n/a
n/a
n/a
n/a
---15.4
15.4
15.4
15.4
15.4
15.4
15.4
Sans les annonces CDP, le switch fournit la puissance par défaut, c'est-à-dire 15.4 Watts
au périphérique qui s’appelle maintenant Cisco PD (Powered Device).
Une dernière remarque importante : lorsqu’un périphérique alimenté par PoE est
débranché, le port reste alimenté durant 4 secondes supplémentaires, dans le cas où le
périphérique serait rebranché. Si ce n’est pas le cas, la tension est supprimée du port. Il
n’est donc pas conseillé de brancher un périphérique réseau quelconque juste après
avoir déconnecté un périphérique PoE.
TFE 2008 - 2009
43
44
Configuration de Base du 2801
Avant de toucher à la configuration de UC Manager Express, une configuration basique
du routeur s’impose. L’image utilisée est une 12.4(22)YB1. Cette image requiert 64 MB
de Flash et 128 MB de DRAM mais elle supporte la dernière version de UC Manager
Express (la version 7.1) à l’heure où sont écrites ces lignes. Le feature set IP Voice
rajoute le support des cartes FXS, des clients SIP, etc.
Commençons par configurer l’accès au routeur :
Router#configure terminal
Router(config)#hostname rogue-cme
rogue-cme(config)#aaa new-model
rogue-cme(config)#aaa authentication login default local enable
rogue-cme(config)#username fred privilege 15 secret blah
rogue-cme(config)#enable secret ww
rogue-cme(config)#line console 0
rogue-cme(config-line)#login authentication default
rogue-cme(config-line)#logging synchronous
rogue-cme(config-line)#exit
NTP
La configuration de l’heure est importante, les téléphones IP se synchroniseront avec le
serveur NTP interne du routeur :
rogue-cme(config)#clock timezone CET +1
rogue-cme(config)#clock summer-time CEST recurring
rogue-cme(config)#^Z
rogue-cme#clock set 13:25:00 08 Apr 2009
rogue-cme#configure terminal
rogue-cme(config)#ntp master
N’oublions pas de configurer l’interface connectée au switch :
rogue-cme(config)#interface FastEthernet0/1
rogue-cme(config-if)#ip address 172.19.13.254 255.255.255.0
rogue-cme(config-if)#no shutdown
rogue-cme(config-if)#exit
DHCP
Le routeur jouera également le rôle de serveur DHCP. C’est lui qui distribuera les
adresses IP aux téléphones :
rogue-cme(config)#ip dhcp pool voicePool
rogue-cme(dhcp-config)#network 172.19.13.0 /24
rogue-cme(dhcp-config)#default-router 172.19.13.254
rogue-cme(dhcp-config)#option 150 ip 172.19.13.254
TFE 2008 - 2009
rogue-cme(dhcp-config)#exit
rogue-cme(config)#ip dhcp excluded-address 172.19.13.254
Deux remarques importantes. Tout d’abord, la commande option permet de spécifier
une option DHCP, dans notre cas l’option 150 qui correspond à l’adresse IP du serveur
TFTP. Les téléphones IP utilisent ce serveur TFTP pour récupérer tous les fichiers dont
ils ont besoin, comme leur fichier de configuration, sonneries, ... J’ai préféré utiliser le
serveur TFTP fourni par l’IOS, c’est pourquoi l’adresse IP spécifiée dans la commande
est celle du routeur. La deuxième commande importante est ip dhcp excludedaddress ; elle empêche au routeur de distribuer sa propre adresse IP.
DHCP Statique
Il est également possible de faire des assignations statiques d’adresses IP basée sur
l’adresse MAC du client. Dans ce cas, un pool DHCP doit être créé pour chaque client.
Voici un exemple de pool :
rogue-cme(config)#ip dhcp pool cp7960
rogue-cme(dhcp-config)#host 172.19.13.13 /24
rogue-cme(dhcp-config)#client-identifier 0030.94C2.5E19
rogue-cme(dhcp-config)#default-router 172.19.13.254
rogue-cme(dhcp-config)#option 150 ip 172.19.13.254
rogue-cme(dhcp-config)#exit
Configuration de UC Manager Express
Configuration Classique (Manuelle)
La configuration d’UC Manager Express se fait dans un mode de configuration dédié,
accessible par la commande telephony-service :
rogue-cme(config)#telephony-service
rogue-cme(config-telephony)#ip source-address 172.19.13.254 port 2000
La commande ip source-address permet de spécifier au routeur l’adresse et le port à
partir desquels il reçoit les messages des téléphones IP. Le port par défaut est le port
2000, il n’est donc pas obligatoire de le spécifier dans la commande.
rogue-cme(config-telephony)#date-format dd-mm-yy
rogue-cme(config-telephony)#time-format 24
rogue-cme(config-telephony)#time-zone 23
Ces trois commandes configurent le format de la date et de l’heure. J’ai utilisé le format
européen (jour/mois/année). Le 23ème time-zone correspond à Western Europe.
TFE 2008 - 2009
45
46
rogue-cme(config-telephony)#max-ephones 10
rogue-cme(config-telephony)#max-dn 10
rogue-cme(config-telephony)#exit
Les deux dernières commandes, max-ephones et max-dn indiquent le nombre
maximum de téléphones et de numéros que le routeur peut supporter.
Configuration Automatique
La configuration de UCME peut être faite via un assistant. Cet assistant, qui peut être
appelé par la commande telephony-service setup, n’effectue qu’une configuration
basique du système comme celle décrite ci-haut. Cette commande est néanmoins
dépréciée depuis la version 7.0 de UCME.
Ajout de Téléphones à UC Manager Express
Ephones et Directory Numbers (DN)
Un ephone (Ethernet Phone) est la représentation d’un téléphone physique dans UCME.
Cela peut être un téléphone IP ou un téléphone analogique. Chaque téléphone physique
doit être configuré en tant que ephone pour pouvoir effectuer des appels. Un tag ou
numéro de séquence est utilisé pour identifier chaque téléphone ; ceci empêche de
confondre deux téléphones entre eux lors de la configuration.
Un directory number, ou ephone-dn dans UCME, représente la ligne connectant le
téléphone à un canal vocal. Il peut être associé à un ou plusieurs numéros de téléphones.
Dans la plupart des cas, un DN peut être vu comme une ligne téléphonique.
Durant la configuration, plusieurs ephone-dns peuvent être associés à un ephone,
chacun d’entre eux étant généralement associé à un bouton du téléphone.
Figure 4-8: un Directory Number associé à un Ephone
Assignation Statique
Dans cet exemple, nous allons ajouter deux téléphones :


Sweeney Todd utilisera le 7960 et possèdera deux numéros (1001 et 1003) ;
Adolfo Pirelli utilisera le 7941G-GE et ne possèdera qu’un seul numéro (1002).
TFE 2008 - 2009
La première chose à faire est de créer les trois « lignes » ou numéros que l’on va
attribuer. Nous allons donc créer trois Directory Numbers ou ephone-dns :
rogue-cme(config)#ephone-dn 1
Le numéro passé en paramètre à la commande est le tag (numéro de séquence) qui
identifie le DN de façon unique.
rogue-cme(config-ephone-dn)#number 1001
Nous configurons ici le numéro que nous souhaitons attribuer à l’utilisateur. C’est ce
numéro qui sera utilisé par les autres utilisateurs souhaitant contacter cette personne.
rogue-cme(config-ephone-dn)#name Sweeney Todd
rogue-cme(config-ephone-dn)#exit
La commande name n’est pas obligatoire mais permet à UCME de construire un
directory local qui permettra par après de rechercher un numéro à partir du nom d’une
personne.
rogue-cme(config-ephone-dn)#name Adolfo Pirelli
rogue-cme(config-ephone-dn)#name Sweeney Todd
Nous avons nos trois numéros mais ceux-ci ne sont pas encore attribués à des
téléphones. Configurons maintenant les deux téléphones :
rogue-cme(config)#ephone 1
rogue-cme(config-ephone)#mac-address 0030.94C2.5E19
La démarche est la même : un numéro de séquence identifie le téléphone. L’adresse
MAC permet de reconnaître le téléphone lorsque celui-ci s’enregistre auprès de UCME.
rogue-cme(config-ephone)#type 7960
Nous pouvons également spécifier le type de téléphone que nous utilisons. UCME en
reconnait à peu près 30. Cette commande permet entre autres de limiter le nombre de
lignes assignable en fonction du nombre de boutons que le téléphone possède.
rogue-cme(config-ephone)#button 1:1 2s3
rogue-cme(config-ephone)#exit
TFE 2008 - 2009
47
48
Cette dernière commande associe les ephone-dns précédemment configurés au
téléphone. Ce sont des couples de nombres séparés par un caractère qui sont fournis en
paramètre à cette commande :
Le premier nombre représente l’index du bouton du téléphone. Le deuxième nombre
représente le numéro de séquence de l’ephone-dn correspondant. Le caractère les
séparant peut être un des caractères suivants :







– normal line : la sonnerie est normale ;
– silent ring : le téléphone ne sonne pas, ne bippe pas ;
– silent ring : le téléphone ne sonne pas mais il bippe ;
– feature ring : la cadence de la sonnerie change si c’est un appel interne ou un
appel externe ;
m – monitor line : affiche si la ligne est utilisée ou pas, mais ne peut pas recevoir
d’appels ;
w – watch line : affiche l’état de la ligne ;
o, c, x – overlay mode : ces modes permettent d’assigner plusieurs DNs à un seul
bouton du téléphone.
:
s
b
f
Dans l’exemple ci-dessus, button 1:1 2s3, le premier bouton est associé au DN 1
(numéro 1001) en mode normal tandis que le second bouton du téléphone est associé au
DN 3 (numéro 1003) en mode silencieux.
rogue-cme(config-ephone)#mac-address 0018.19B3.0224
rogue-cme(config-ephone)#type 7941GE
rogue-cme(config-ephone)#button 1:2
Une fois le téléphone connecté à UCME, il s’enregistre et le routeur nous le signale :
May 18 11:29:49.198: %IPPHONE-6-REGISTER: ephone-1:SEP003094C25E19
IP:172.19.13.11 Socket:2 DeviceType:Phone has registered.
On y retrouve quelques informations dont l’identifiant du téléphone (SEP...) et son
adresse IP. L’identifiant est en fait composé des trois lettres SEP (Selsius Ethernet
Phone) auxquelles a été ajouté l’adresse MAC du téléphone. Selsius est le nom de
l’entreprise qui fabriquait autrefois ces téléphones IP ; elle a ensuite été rachetée par
Cisco.
Assignation Automatique
Les deux téléphones que nous venons de configurer ont été configurés de manière
statique ; nous avons utilisé leur adresse MAC pour les identifier. Il est également
TFE 2008 - 2009
possible d’assigner des DN à des téléphones sans que ces derniers ne soient
préalablement configurés en tant que ephones.
Pour ce faire, seuls les DNs doivent être configurés. Par exemple :
rogue-cme(config-ephone-dn)#name Anonymous0
rogue-cme(config-ephone-dn)#name Anonymous1
L’assignation automatique se fait via la commande auto assign :
rogue-cme(config-telephony)#auto assign 10 to 11
Ainsi, lorsque des téléphones qui ne sont pas définis explicitement dans la configuration
s’enregistrent, UCME leur attribue un DN faisait partie du range spécifié dans la
commande. Un ephone est alors créé automatiquement pour ce téléphone et le DN y est
associé.
La commande auto assign permet aussi d’assigner des DNs uniquement à certains
types de téléphones. Il suffit d’ajouter le suffixe type à la commande :
rogue-cme(config-telephony)#auto assign 10 to 11 type 7960
Dans ce cas, seuls des téléphones IP de type 7960 recevront un DN.
Cette fonctionnalité est utile lorsqu’une grande quantité de téléphones doit être
déployée, cependant elle donne moins de contrôle à l’administrateur ; il ne peut pas
contrôler qui peut ou ne peut pas rejoindre le réseau VoIP.
Templates
La configuration de téléphones IP peut être simplifiée lorsque beaucoup de téléphones
doivent être configurés de façon semblable. Prenons pour exemple le cas où tous les
téléphones IP doivent utiliser un codec spécifique – disons ilbc – et disposer également
d’un bouton composant automatiquement le numéro de l’accueil.
L’utilisation d’un codec spécifique se fait grâce à la commande codec :
rogue-cme(config-ephone)#codec ilbc
TFE 2008 - 2009
49
50
La fonctionnalité qui permet d’associer la composition d’un numéro à un bouton
s’appelle speed-dial. La commande à utiliser est également très explicite :
rogue-cme(config-ephone)#speed-dial 1 1999 label Receptionist
Afin d’éviter de rajouter ces deux lignes dans la configuration de tous les téléphones, il
est possible de créer un template auquel on ajoutera ces deux lignes. Il suffira ensuite
d’appliquer ce template aux téléphones en question :
rogue-cme(config)#ephone-template 1
rogue-cme(config-ephone-template)#codec ilbc
rogue-cme(config-ephone-template)#speed-dial 1 1999 label Receptionist
rogue-cme(config-ephone-template)#exit
Le template est créé, il ne reste plus qu’à l’appliquer. On peut noter que les templates
sont identifiés eux aussi par un numéro de séquence.
rogue-cme(config-ephone)#ephone-template 1
The ephone template tag has been changed under this ephone, please restart or
reset ephone to take effect.
rogue-cme(config-ephone)#restart
restarting 0030.94C2.5E19
Une fois redémarré, le téléphone affiche le speed-dial configuré :
TFE 2008 - 2009
Figure 4-9 : template appliqué
Il est également possible de définir des templates pour les DNs. Ces templates peuvent
être définis avec la commande ephone-dn-template.
Mise à Jour du Firmware
Les téléphones IP utilisent un firmware qui peut être mis à jour, que ce soit pour des
raisons de sécurité ou encore pour bénéficier de nouvelles fonctionnalités. La version du
firmware utilisé peut être lue dans les paramètres du téléphone, plus précisent dans les
informations du modèle :
TFE 2008 - 2009
51
52
Figure 4-10 : informations du modèle
Le téléphone IP ci-dessus est évidemment un softphone (Cisco IP Communicator) mais
il reprend à quelques détails près les menus de vrais téléphones IP Cisco.
Un téléphone IP neuf possède un firmware SCCP par défaut. Lorsqu’il récupère son
fichier de configuration, il compare la version du firmware indiquée avec celle qu’il
possède. Si les deux version sont différentes, le téléphone IP contacte le serveur TFTP
pour récupérer la nouvelle version du firmware avant de s’enregistrer auprès de UCME.
Une convention est utilisée pour le nommage des firmwares. Pour un firmware SCCP, le
nom du fichier aura la forme P003xxyyzzww où x, y, z et w indiquent la version en
cours. Pour un firmware SIP, le format est P0S3-xx-y-zz. Il existe des exceptions : par
exemple, le nom des firmwares pour ATA commence par AT. Pour les téléphones IP
basés sur Java, le firmware est un ensemble de fichiers jar.
Téléchargement du Firmware
La première chose à faire est donc de télécharger le firmware, disponible sur le site de
Cisco (www.cisco.com). Une fois connecté, il suffit d’aller dans la section
téléchargements et ensuite dans la catégorie Voice and Unified Communications. Un
menu en arbre permet d’explorer les différents produits jusqu’à en arriver au téléphone
IP qui nous intéresse.
TFE 2008 - 2009
Figure 4-11 : l’arborescence des modèles de téléphones IP
La plupart des téléphones proposent un firmware SCCP et SIP. Un fichier zip
comprenant tous les fichiers nécessaires est alors proposé :
Figure 4-12 : téléchargement du firmware
Ajout du Firmware dans UC Manager Express
Le firmware doit être stocké sur le serveur TFTP afin qu’il soit accessible par les
téléphones IP. Je rappelle que dans notre cas, c’est le routeur – qui est aussi le UC
Manager Express – qui assume le rôle de serveur TFTP. Nous allons donc stocker le
firmware sur la flash du 2801. Il existe beaucoup de manières de récupérer le fichier que
nous venons de télécharger : SCP, TFTP, FTP, HTTP ou encore HTTPS !
TFE 2008 - 2009
53
54
Le fichier que nous avons téléchargé est une archive zip. Cependant, le routeur ne
pourra pas en extraire les fichiers... c’est pourquoi il est préférable de dézipper le fichier
et de placer les fichiers résultants dans une archive tarball. Rappelons qu’une archive
tarball (extension .tar) ne compresse aucun de ses fichiers, elle les regroupe simplement
afin qu’ils soient plus facilement transportables. De plus, le routeur est capable
d’extraire les fichiers contenus dans une archive tar.
Dans l’exemple ci-dessous, nous récupérons une archive tarball par SCP et nous
l’extrayons dans la flash du routeur :
rogue-cme#archive tar /xtract scp://fred:[email protected]/7941g.tar flash:
Loading 7941g.tar from 144.254.10.204 (via FastEthernet0/0): !
extracting apps41.8-4-3-16.sbn (2926641 bytes)!!!!!!!!!!!
extracting cnu41.8-4-3-16.sbn (482686 bytes)!!
extracting cvm41sccp.8-4-3-16.sbn (2702457 bytes)!!!!!!!!!!
extracting dsp41.8-4-3-16.sbn (537209 bytes)!!
extracting jar41sccp.8-4-3-16.sbn (447300 bytes)!!
extracting SCCP41.8-4-4S.loads (638 bytes)
extracting term41.default.loads (642 bytes)
extracting term61.default.loads (642 bytes)
[OK - 7106048 bytes]
Un show flash: nous prouve que le téléchargement s’est bien passé :
rogue-cme#show
-#- --length-[...]
18
2926641
19
482686
20
2702457
21
537209
22
447300
23
638
24
642
25
642
[...]
flash:
-----date/time------ path
May
May
May
May
May
May
May
May
20
20
20
20
20
20
20
20
2009
2009
2009
2009
2009
2009
2009
2009
07:38:20
07:38:24
07:38:42
07:38:46
07:38:52
07:38:52
07:38:52
07:38:54
apps41.8-4-3-16.sbn
cnu41.8-4-3-16.sbn
cvm41sccp.8-4-3-16.sbn
dsp41.8-4-3-16.sbn
jar41sccp.8-4-3-16.sbn
SCCP41.8-4-4S.loads
term41.default.loads
term61.default.loads
Il faut maintenant activer le partage de ces fichiers pour le serveur TFTP. La commande
à utiliser est tout simplement tftp-server.
rogue-cme(config)#tftp-server
flash:apps41.8-4-3-16.sbn
flash:cnu41.8-4-3-16.sbn
flash:cvm41sccp.8-4-3-16.sbn
flash:dsp41.8-4-3-16.sbn
flash:jar41sccp.8-4-3-16.sbn
flash:SCCP41.8-4-4S.loads
flash:term41.default.loads
TFE 2008 - 2009
La dernière chose à faire est d’indiquer aux téléphones qu’ils doivent utiliser ce
firmware. Ceci peut être réalisé grâce à la commande load :
rogue-cme(config-telephony)#load 7941GE SCCP41.8-4-4S
rogue-cme(config-telephony)#create cnf-files
Creating CNF files
La dernière commande, create cnf-files, reconstruit les fichiers de configuration
des téléphones. Il n’y a plus qu’à redémarrer le téléphone pour qu’il prenne en compte le
nouveau firmware.
Afin de vérifier si tout s’est bien passé, il est possible d’afficher le firmware utilisé par un
téléphone dans UCME :
rogue-cme#show ephone phone-load
DeviceName
CurrentPhoneload
PreviousPhoneload
LastReset
=====================================================================
SEP001819B30224
SCCP41.8-4-4S
SCCP41.8-4-4S
Reset-Restart
Skinny Client Control Protocol (SCCP)
Skinny Client Control Protocol (SCCP) – couramment abrégé Skinny – est un protocole
de contrôle qui fut autrefois développé par Selsius Corporation. Cisco Systems Inc. s’est
emparé de ce protocole en 1998 lors du rachat de Selsius Corp.
SCCP est un protocole léger qui permet aux clients Skinny de communiquer avec UC
Manager ou UC Manager Express. Il utilise le port TCP 2000 pour la signalisation et
RTP over UDP pour le trafic temps-réel (flux audio) avec les autres clients Skinny. SCCP
a été prévu pour des périphériques hardware et autres systèmes embarqués possédant
un CPU relativement important et des contraires au niveau de la mémoire. Il est
également réputé pour le peu de bande passante dont il a besoin.
Au cours de ce chapitre, nous avons configuré deux téléphones IP sans nous intéresser à
ce qui se passait en arrière-plan. Le sniffeur que j’ai connecté au switch m’a permis de
récupérer les paquets qui transitaient entre le UCME et un des deux téléphones IP. Voici
ce qu’on peut y retrouver :
TFE 2008 - 2009
55
56
Figure 4-13 : trafic d’un téléphone IP dans Wireshark
Beaucoup de protocoles sont présents :





CDP : le matériel Cisco envoie des messages CDP par défaut : ce sont ces
messages qui permettent de réguler la puissance fournie par le switch PoE ;
DHCP : le téléphone utilise DHCP pour acquérir une adresse IP ;
SKINNY : c’est ce protocole qui va nous intéresser : il gère la communication
entre notre téléphone et le UCME ;
ARP : ce protocole est utilisé pour récupérer l’adresse MAC d’un hôte à partir de
son adresse IP – dans ce cas-ci, le UCME ;
TFTP : le téléphone utilise ce protocole pour récupérer son fichier de
configuration, une éventuelle mise à jour de firmware, ...
Après l’application d’un filtre, nous nous retrouvons uniquement avec des paquets
SCCP :
TFE 2008 - 2009
Figure 4-14 : trafic SCCP
Nous avons donc une conversation entre notre téléphone IP (172.19.13.2) et le UC
Manager Express (172.19.13.254). On peut deviner le rôle de certains paquets : le
RegisterMessage enregistre le téléphone auprès de UCME qui répond à l’aide d’un
RegisterAckMessage. Le CapabilitiesReqMessage est sans doute une négociation
des fonctionnalités disponibles – le nombre de boutons ? les codecs ? Hélas, ces
suppositions ne suffiront pas à comprendre le fonctionnement de ce protocole... passons
en revue les différents types de messages – du moins, les plus importants.
Les Messages SCCP
Il existe beaucoup de messages SCCP différents. Pour des raisons de visibilité, le tableau
qui suit n’en reprend qu’une partie. Cependant, la liste complète peut être retrouvée en
annexe.
Message
StationKeepAliveMessage
StationKeepAliveAckMessage
StationAlarmMessage
StationRegisterMessage
StationRegisterAckMessage
StationRegisterRejectMessage
StationCapabilitiesReq
StationCapabilitiesRes
StationButtonTemplateReqMessage
StationButtonTemplateResMessage
StationTimeDateReqMessage
StationDefineTimeDateMessage
Vers UCME
X
X
X
De UCME
X
X
X
X
X
X
X
X
X
TFE 2008 - 2009
57
58
Attention : l’unité des paquets décrits ci-dessous est l’octet et non le bit...
Les paquets SCCP sont préfixés d’un entête fixe que voici :
Figure 4-15 : entête SCCP
La version est négociée entre le UCME et le téléphone. Tous les messages émis et/ou
reçus avant et durant l’enregistrement du téléphone ne possèdent pas de version. Dans
ce cas, le champ sccpVersion est mis à zéro.
Tous les messages SCCP possède un messageID qui les identifie de façon unique. Par
exemple, le messageID 0x00000094 correspond à StationDefineTimeDate.
StationKeepAliveMessage (messageID 0x00000000)
Ces messages sont envoyés par les téléphones IP pour prévenir le UCME que le lien est
toujours actif.
Figure 4-16 : KeepAlive
StationKeepAliveAckMessage (messageID 0x00000100)
Ces messages sont les réponses aux StationKeepAliveMessages. Cette fois, c’est le
téléphone qui est prévenu que le lien est toujours actif.
Figure 4-17 : KeepAliveAck
StationAlarmMessage (messageID 0x00000020)
Le téléphone utilise ce type de message pour prévenir UCME d’une alarme – d’un
problème. Le champ alarmSeverity est prévu pour indiquer la gravité de l’erreur.
TFE 2008 - 2009
Figure 4-18 : Alarm
Le champ Text fournit une description de l’erreur et il est possible d’y ajouter deux
paramètres. Un téléphone IP utilise généralement le deuxième paramètre pour y placer
son adresse IP.
StationRegisterMessage (messageID 0x00000001)
Ce message est envoyé par le téléphone afin de notifier sa présence auprès de UCME.
Dans les versions précédentes du protocole, le nom du device se basait sur l’adresse
MAC. Dans les dernières version de SCCP, l’adresse MAC est placée dans un autre
champ, ce qui facilite la maintenance.
Figure 4-19 : Register
TFE 2008 - 2009
59
60
Voici une brève explication des différents champs :











DeviceName : nom du téléphone – généralement SEP suivi de l’adresse MAC;
StationUserId : réservé pour plus tard – valeur à 0 ;
StationInstance : nombre d’instances de la station – normalement 1 ;
StationIpAddr : adresse IP du téléphone ;
DeviceType : type de périphérique ;
maxStreams : nombre de flux RTP simultanés que le téléphone peut gérer ;
activeStreams : nombre de flux RTP actifs ;
protocolVer : version du protocole SCCP utilisée par le téléphone ;
macAddress : adresse MAC du téléphone ;
maxNumberofLines : nombre de lignes que le téléphone supporte ;
IpV4AddressScope : définit le scope de l’adresse IP – administration,

signalisation ou les deux ;
firmwareLoadName : nom du firmware utilisé par le téléphone.
Malheureusement, le dissecteur SCCP actuel de Wireshark n’est pas très élaboré –
rappelons que SCCP est un protocole propriétaire. Tous les champs ne sont donc pas
accessibles...
Figure 4-20 : le message Register dans Wireshark
StationRegisterAckMessage (messageID 0x00000081)
Ce message est envoyé par UCME au téléphone IP pour lui indiquer que son
enregistrement a été effectué.
TFE 2008 - 2009
Figure 4-21 : RegisterAck




keepAliveInterval : indique le temps maximum (en secondes) entre deux
keep-alives venant du client SCCP vers le UCME primaire ;
dateTemplate : format de la date ;
secondaryKeepAliveInterval : indique le temps maximum (en secondes)
entre deux keep-alives venant du client SCCP vers le UCME secondaire ;
maxProtocolVersion : indique au client SCCP la version de Skinny supporté par
le UCME.
StationRegisterRejectMessage (messageID 0x0000009d)
Ce message est envoyé par UCME pour rejeter l’enregistrement d’un téléphone. Le
champ text fournit la description du rejet.
Figure 4-22 : RegisterReject
StationCapabilitiesReq (messageID 0x0000009b)
UCME envoie ce message au téléphone afin de lui demander la liste des codecs qu’il
supporte.
Figure 4-23 : CapabilitiesReq
StationCapabilitiesRes (messageID 0x00000010)
Ce message est la réponse à StationCapabilitesReq. Le champ caps est répeté un
nombre de fois égal à capCount.
TFE 2008 - 2009
61
62
Figure 4-24 : CapabilitiesRes
Le champ payloadCapability contient l’identifiant du codec (par exemple 4 pour
G.711u, 11 pour G.729, etc).
StationButtonTemplateReqMessage (messageID 0x0000000e)
Ce message est utilisé par le téléphone pour demander une mise à jour de ses boutons.
Figure 4-25 : ButtonTemplateReq
StationButtonTemplateMessage (messageID 0x00000097)
Ce message est envoyé par UCME pour indiquer au téléphone IP qu’il doit mettre ses
boutons à jour.
Figure 4-26 : ButtonTemplate
Le champ buttonOffset indique l’index du premier bouton défini dans le message. Le
champ buttonCount indique quant à lui le nombre de définitions valides présentes dans
le message. Le champ totalButtonCount représente le nombre total de boutons pour le
périphérique concerné (le téléphone). Pour chaque définition de bouton, un champ
Définition est envoyé. Ce champ est composé de deux octets : instanceNumber et
buttonDefinition.
TFE 2008 - 2009
StationTimeDateReqMessage (messageID 0x0000000d)
Le téléphone IP envoie ce message au UCME pour récupérer l’heure. Le UCME répond
par un message StationDefineTimeDateMessage.
Figure 4-27 : TimeDateReq
StationDefineTimeDateMessage (messageID 0x00000094)
Ce message, envoyé par UCME, contient la date et l’heure courante.
Figure 4-28 : DefineTimeDate
Le champ systemTime correspond à la définition de la date contenue dans la structure
StationTime (les champs grisés). Ce champ utilise le format Microsoft.
Fonctionnement de SCCP
Les diagrammes de séquence qui suivent illustrent le fonctionnement de SCCP.
Enregistrement
Dans un premier temps, nous allons nous attarder sur l’enregistrement d’un client
SCCP. Ce premier exemple montre le processus d’enregistrement d’un client Skinny
quelconque ; c’est le processus minimal aussi appelé « legacy » :
TFE 2008 - 2009
63
64
Figure 4-29 : processus d’enregistrement SCCP
L’enregistrement est composé de sept échanges :
1) Le téléphone et UCME s’assurent mutuellement que le lien est bien actif avant
d’entamer quoi que ce soit (StationKeepAlive / StationKeepAliveAck) ;
2) Le téléphone envoie ensuite à UCME ses messages d’erreurs, ses notifications
(StationAlarm) ;
3) Le processus d’enregistrement débute ensuite. UCME peut accepter ou rejeter la
demande ; s’il la rejete, l’échange est terminé (StationRegister /
StationRegisterAck / StationRegisterReject) ;
4) Le quatrième échange concerne le firmware que le téléphone IP doit utiliser. Si le
firmware proposé par UCME est plus récent, le client SCCP télécharge la nouvelle
version via TFTP (StationVersionReq / StationVersionRes) ;
TFE 2008 - 2009
5) Vient ensuite la négociation des codecs ; le téléphone IP énumère les codecs qu’il
supporte
auprès
de
UCME
(StationCapabilitiesReq
/
StationCapabilitiesRes) ;
6) Le téléphone demande ensuite à UCME de mettre à jour la définition de ses
boutons (StationButtonTemplateReq / StationButtonTemplateRes) ;
7) Finalement, UCME fournit la date locale au client SCCP ( StationTimeDateReq /
StatinDefineTimeDate).
Suite à l’arrivé de téléphones IP plus évolués comme le 7940 ou le 7960, la complexité
du processus d’enregistrement a augmenté. Beaucoup de nouveaux messages ont fait
leur apparition :
TFE 2008 - 2009
65
66
TFE 2008 - 2009
Figure 4-30 : processus avancé d’enregistrement
Parmi les nouveaux échanges, nous retrouvons :





Le message StationHeadsetStatus informe UCME du statut du headset du
téléphone IP ;
Suite à la demande du client SCCP (StationSoftKeyTemplateReq), UCME
l’informe via un message StationSoftKeyTemplateRes du template utilisé pour
les softkeys (touches raccourcis situées sous l’écran du téléphone) ;
Le message StationLineStat est utilisé par le téléphone pour récupérer les DNs
de ses différentes lignes. Ce message peut être utilisé plusieurs fois ;
Les messages StationSpeedDialStatReq et StationSpeedDialStatRes
indiquent au téléphone les speed dials qu’il doit utiliser ;
Le message StationRegisterAvailableLines enregistre les lignes du
téléphone auprès de UCME.
Appel
Lors d’un appel, la signalisation passe par le UC Manager Express. Une fois la connexion
établie, les deux clients communiquent directement par flux RTP. Les messages utilisés
dans ce processus sont complètement différents de ceux utilisés par l’enregistrement du
client. Voici le diagramme d’une demande d’appel entre deux clients Skinny :
TFE 2008 - 2009
67
68
Figure 4-31 : début d’un appel SCCP
Voici une description des messages qui sont utilisés :




Le message StationOffHook indique à UCME que le cornet du téléphone est
décroché ;
Le rôle du message StationDisplayText est, comme son nom l’indique,
d’afficher un message sur l’écran du téléphone ;
UCME utilise le message StationSetLamp pour contrôler l’état de la « LED » du
téléphone. Cinq états sont possibles : Off, On (Steady), Wink, Flash et Blink ;
Les messages StationKeypadButton sont envoyés à UCME pour indiquer
qu’une touche du téléphone a été pressée;
TFE 2008 - 2009






Le message StationStartTone indique au téléphone de jouer la tonalité. Le
mode alerting est le mode que l’on entend lorsque l’on attend que le
correspondant décroche ;
Le message StationStopTone indique au téléphone de ne plus jouer la tonalité.
Ce message est envoyé au téléphone dès qu’une touche est pressée ;
Le message StationCallInfo donne au téléphone des informations sur l’appel ;
Le message StationSetRinger fait sonner le téléphone. Plusieurs modes sont
possibles : RingOff, InsideRing, OutsideRing, FeatureRing et FlashOnly ;
Le message StationOpenReceiveChannel demande au téléphone d’ouvrir un
flux RTP/UDP unicast. Le client SCCP répond par un message
StationOpenReceiveChannelAck qui contient l’adresse IP et le port du flux
RTP/UDP ;
Finalement, le message StationStartMediaTransmission indique au client
Skinny qu’il doit commencer à transmettre sur le flux RTP/UDP. Ce message
contient l’adresse IP et le port du flux RTP distant (celui de l’autre client).
A partir de ce moment, les deux clients SCCP communiquent par flux RTP/UDP.
Lorsqu’un client termine l’appel en raccrochant, les messages suivants sont échangés :
Figure 4-32 : fin d’un appel
Les messages sont sensiblement les mêmes que lors du début de l’appel. Quand le
premier client raccroche, le message StationOnHook est envoyé au UCME. Les deux
clients ferment ensuite leur flux RTP/UDP et les LED sont éteintes.
TFE 2008 - 2009
69
70
TFE 2008 - 2009
Chapitre 5 : Fonctionnalités Supplémentaires
UCME met à notre disposition beaucoup de fonctionnalités plus ou moins utiles. Nous
allons en passer en revue quelques unes.
Message Système
Il est possible d’afficher une phrase dans le bas de l’écran des téléphones IP connectés à
UCME. Si cette fonctionnalité peut sembler inutile, elle peut servir par exemple pour
prévenir les utilisateurs d’une maintenance réseau.
rogue-cme(config-telephony)#systeme message /!\ Maintenance reseau /!\
Voici un aperçu du résultat :
Figure 5-1 : message système
Extension Mobility
L’extension Mobility permet à un utilisateur d’utiliser un téléphone qui n’est pas le sien
tout en gardant ses paramètres, ses numéros, ses services, etc comme s’il utilisait son
propre téléphone.
Chaque téléphone IP pour lequel l’extension Mobility est activée est configuré avec un
logout-profile. C’est un profil par défaut qui n’est associé à aucun utilisateur en
particulier. L’utilisateur peut ensuite s’authentifier sur le téléphone et ainsi récupérer
ses préférences.
Activation de l’Extension Mobility
Pour activer cette extension, il suffit de configurer l’url qui gère l’authentification des
utilisateurs. Le serveur web doit également être activé sur le routeur :
rogue-cme(config)#ip http server
rogue-cme(config-telephony)#url authentication
http://172.19.13.254/CCMCIP/authenticate.asp
TFE 2008 - 2009
71
72
rogue-cme(config-telephony)#em keep-history
rogue-cme(config-telephony)#em logout 08:00 12:00 16:00
La commande em keep-history permet de garder l’historique des appels lorsqu’un
utilisateur se déconnecte d’un téléphone où l’extension Mobility est activée. La
commande em logout définit jusqu’à trois heures auxquelles les utilisateurs Mobility
seront automatiquement déconnectés.
Création d’un Logout-Profile
Le logout-profile est le profil par défaut des téléphones où l’extension Mobility est
activée. Ce profil est donc partagé entre plusieurs téléphones.
rogue-cme(config)#voice logout-profile 1
rogue-cme(config-logout-profile)#number 1999
Il est important de noter que le numéro spécifié lors de la commande number doit
exister pour pouvoir être utilisé, même si l’on ne spécifie pas de DN. Le profil peut
ensuite être appliqué sur tous les téléphones qui serviront en tant que téléphones
« Mobility » :
rogue-cme(config-ephone)#logout-profile 1
rogue-cme(config-ephone)#ephone 5
rogue-cme(config-ephone)#logout-profile 1
Création d’un User-Profile
Tous les téléphones utilisent maintenant le profil par défaut, mais il faut également
créer un profil pour chaque utilisateur qui souhaite se connecter sur un autre téléphone
que le sien :
rogue-cme(config)#voice user-profile 1
rogue-cme(config-user-profile)#user sweeney password miam
rogue-cme(config-user-profile)#number 1001 type normal
rogue-cme(config-user-profile)#speed-dial 1 1002 label Pirelli
Ce profil utilisera donc le numéro 1001 qui est associé à Sweeney Todd, et possèdera
également un bouton pour le speed-dial afin de contacter Adolfo Pirelli (le 1002). La
commande user permet de spécifier le nom d’utilisateur et le mot de passe à utiliser
pour se connecter sur un téléphone Mobility avec ce profil.
Utilisation de l’Extension Mobility
Sur le téléphone, c’est assez simple à utiliser. Voici quelques captures montrant le
fonctionnement de cette fonctionnalité :
TFE 2008 - 2009
Figure 5-2 : affichage des services
Figure 5-3 : connexion à l’extension Mobility
TFE 2008 - 2009
73
74
Figure 5-4 : utilisateur connecté
Si l’utilisateur retourne dans le menu Mobility alors qu’il est déjà connecté, il lui sera
alors proposé de se déconnecter. A noter que lorsqu’un utilisateur se connecte sur un
téléphone alors qu’il est déjà connecté sur un autre, il est automatiquement déconnecté
du premier téléphone sur lequel il s’est connecté.
Single Number Reach (SNR)
Cette fonctionnalité est apparue dans la dernière version de UCME (7.1). Pour faire bref,
si un utilisateur est absent et ne répond pas à un appel, cet appel peut être redirigé
automatiquement vers un autre numéro, qu’il soit interne ou bien externe (un numéro
de GSM par exemple). L’utilisateur peut configurer le numéro auquel il souhaite être
contacté via l’interface du téléphone. Voici une illustration du principe :
TFE 2008 - 2009
Figure 5-5 : fonctionnement de SNR
Le SNR n’est cependant pas un simple transfert d’appel comme on pourrait le croire : si
l’utilisateur revient entretemps à son bureau, il peut choisir de reprendre l’appel sur son
téléphone principal (le téléphone IP) sans perdre la connexion.
SNR n’est malheureusement pas compatible avec SIP ni avec les téléphones analogiques
connectés à un FXS.
L’extension Mobility doit être activée pour que cette fonctionnalité puisse être utilisée.
Le SNR peut être configuré avec la commande suivante :
rogue-cme(config-ephone-dn)#snr numero delay <0-10> timeout <5-60>
Le paramètre delay définit le nombre de secondes pendant lesquelles le téléphone IP
doit sonner avant de transférer l’appel sur l’autre téléphone. Le paramètre timeout
indique quant à lui le nombre de secondes durant lesquelles le téléphone IP doit
continuer de sonner, même si l’appel a déjà été pris par l’autre téléphone.
L’exemple qui suit active SNR pour le DN 7 :
rogue-cme(config-ephone-dn)#mobility
rogue-cme(config-ephone-dn)#snr 90478123456 delay 10 timeout 15
TFE 2008 - 2009
75
76
La capture d’écran suivante montre le sous-menu dédié à SNR ; il permet à l’utilisateur
de facilement modifier le numéro auquel il souhaite être joint.
Figure 5-6 : configuration du numéro SNR
Interface Graphique (GUI)
UC Manager Express propose une interface graphique qui est accessible via un
navigateur web. Bien que cette interface web ne soit pas aussi évoluée que celle de UC
Manager, elle permet néanmoins d’ajouter, de modifier ou de supprimer des ephones et
des DNs. Elle permet également de modifier quelques paramètres systèmes.
Il est possible de créer différents types de compte pour accéder à l’interface graphique :



System admin : ce compte peut modifier les paramètres relatifs au système et aux
téléphones, il a donc tous les droits ;
Customer admin : ce type de compte a le droits d’ajouter ou de modifier des
téléphones ;
Phone user : le compte utilisateur peut uniquement modifier les paramètres de
son téléphone.
Un compte comme ceux utilisés dans l’extension Mobility – un voice user-profile –
peut aussi être utilisé en tant que compte utilisateur.
Activation de l’Interface Graphique
L’activation de l’interface web n’est pas très compliquée, il suffit simplement d’activer le
serveur HTTP du routeur. Il est également possible d’utiliser le serveur HTTPS, mais ce
TFE 2008 - 2009
n’est pas obligatoire (bien que préférable). La configuration qui suit active le service
web :
rogue-cme(config)#ip
http
http
http
http
server
secure-server
path flash:gui
authentication local
La méthode d’authentification peut être aaa, local ou enable. Le path fourni à la
deuxième ligne indique au serveur web le répertoire dans lequel il doit aller chercher les
pages web. Le répertoire gui repris dans cet exemple est le répertoire que l’on a
récupéré à partir de l’archive comprenant les firmwares de base, l’interface web, des
sonneries, etc.
Il faut ensuite créer un compte administrateur système afin de pouvoir se logger sur la
page. Ceci se fait en utilisant la commande web admin :
rogue-cme(config-telephony)#web admin system name fred secret 0 blah
rogue-cme(config-telephony)#dn-webedit
La commande dn-webedit permet la modification des DNs via l’interface web.
Nous pouvons maintenant essayer d’accéder à la page web d’UCME. L’URL à utiliser est
http://<ip_routeur>/ccme.html. Voici un aperçu de la page :
Figure 5-7 : page d’accueil de l’interface web
Pour créer un administrateur « client » (un customer admin), la commande est presque
identique à celle utilisée pour l’administrateur système :
TFE 2008 - 2009
77
78
rogue-cme(config-telephony)#web admin customer name paul secret 0 noon
Ajout d’un Utilisateur
L’ajout d’un utilisateur ne se fait pas au même endroit que lors de la création du compte
admin. C’est dans la configuration de l’ephone que le compte peut être crée, ce qui est à
mon sens plus logique. Voici un exemple :
rogue-cme(config-ephone)#username stodd password miam
Voice d’autres captures d’écrans illustrant les possibilités offertes par l’interface web :
Figure 5-8 : modification des paramètres d’un téléphone
TFE 2008 - 2009
Figure 5-9 : modification de paramètres système
Service de Nuit
La fonctionnalité night-service permet de notifier un téléphone lorsqu’un appel est reçu
sur un autre téléphone (ou plutôt un de ses DNs) après les heures de travail. Par
exemple, lorsque A reçoit un appel après 20h, B en est averti et peut récupérer l’appel
grâce au call-pickup.
Configuration du Service de Nuit
La première partie de la configuration consiste à définir les heures non considérées
comme « heure de travail » :
rogue-cme(config-telephony)#night-service weekday 18:00 08:00
rogue-cme(config-telephony)#night-service weekend 00:00 00:00
rogue-cme(config-telephony)#night-service code *1234
Dans cet exemple, le service de nuit commence à 18h et se termine le lendemain à 08h
pendant la semaine. Durant le week-end, le service de nuit est actif toute la journée. Un
TFE 2008 - 2009
79
80
code peut également être configuré afin d’activer ou désactiver le service de nuit à tout
moment.
L’heure de fin doit être supérieure à l’heure de début. Si 00:00 est entré en tant
qu’heure de fin, cette valeur est automatiquement convertie en 23:59. Si 00:00 est entré
deux fois (donc en tant qu’heure de début et en tant qu’heure de fin), le service de nuit
est activé pour une période de 24 heures.
Il est possible de raffiner ces plages horaires grâce aux commandes day, date,
everyday, weekday ou weekend. Par exemple, cette commande active le service de nuit
tous les jours de 16h à 09h le lendemain.
rogue-cme(config-telephony)#night-service everyday 16:00 09:00
Ici, le service de nuit est actif le 1er janvier pendant toute la journée.
rogue-cme(config-telephony)#night-service date Jan 1 00:00 00:00
Il faut ensuite configurer le téléphone à « surveiller » durant la nuit ainsi que les
téléphones qui devront être notifiés lors d’un appel. L’activation du service de nuit pour
le téléphone à surveiller se fait dans la configuration du DN :
rogue-cme(config-ephone-dn)#night-service bell
Voici ensuite la configuration des téléphones qui seront notifiés :
rogue-cme(config-ephone)#night-service bell
rogue-cme(config-ephone)#ephone 6
rogue-cme(config-ephone)#night-service bell
Il faut bien faire attention à ne pas se tromper : nous configurons le service de nuit pour
le téléphone à surveiller dans la configuration du DN, mais c’est dans la configuration de
l’ephone que nous configurons les téléphones à notifier. Voici une illustration du cas que
nous venons de configurer :
TFE 2008 - 2009
Figure 5-10 : service de nuit
Il reste une dernière chose à configurer. En effet, le call-pickup n’est pas configuré par
défaut. Les téléphones 1 et 6 seront alors notifiés de l’appel, mais ils ne pourront pas le
récupérer. Il faut alors configurer un pickup-group auquel appartiendront ces trois
téléphones :
rogue-cme(config-ephone-dn)#pickup-group 1
rogue-cme(config-ephone-dn)#ephone-dn 1
rogue-cme(config-ephone-dn)#ephone-dn 6
Ainsi, les utilisateurs des téléphones 1 et 6 pourront reprendre un appel du téléphone 4
en appuyant sur la touche GPickUp (Group PickUp) du téléphone.
TFE 2008 - 2009
81
82
TFE 2008 - 2009
Chapitre 6 : Téléphones Analogiques
Le lab précédent nous a permis de prendre en main UC Manager Express. Cela nous a
permis de nous familiariser avec la configuration de téléphones IP et du système
proprement dit. Ce chapitre a pour but de rajouter des éléments analogiques au lab
précédent. Nous rajouterons donc un téléphone analogique classique – que l’on retrouve
dans la majorité des foyers – et un lien vers le réseau extérieur (PSTN).
L’avantage de rajouter des téléphones analogiques est simple : une entreprise qui
possède déjà beaucoup de téléphones n’est pas obligée de réinvestir dans des téléphones
IP ; elle peut récupérer ceux qu’elles possédait avant et les réutiliser. Evidemment, les
coûts seront moindres au détriment d’un confort d’utilisation qui n’est pas comparable.
Voici le diagramme de ce lab. Seuls un téléphone analogique et un lien vers le réseau
téléphonique classique ont été ajoutés :
Figure 6-1 : topologie du deuxième lab
FXS vs FXO
Du matériel particulier est nécessaire pour ajouter des téléphones analogiques à un
routeur équipé de UC Manager Express. En effet, un téléphone analogique est équipé
d’un connecteur RJ-11 et non d’un connecteur RJ-45 et surtout, le signal n’est pas
numérique mais bien analogique. Il existe deux types de ports analogiques : les FXS et
les FXO.
TFE 2008 - 2009
83
84
Foreign eXchange Station (FXS)
Un port FXS (Foreign eXchange Station) connecte un périphérique analogique à la ligne
téléphonique. Ce port fournit donc la tonalité, le courant et le voltage nécessaire au
téléphone qui y est connecté. Une prise téléphonique murale est donc généralement un
port FXS bien que ce soit une extension au FXS qui se situe chez l’opérateur
téléphonique.
Le module qui a été utilisé dans ce lab est une VIC2-2FXS. C’est un module qui possède
deux ports FXS. Il existe une ancienne version de ce module (VIC-2FXS) mais celle-ci
n’est pas compatibles avec le routeur Cisco 2801 que j’ai utilisé.
Figure 6-2 : VIC-2FXS
Foreign eXchange Office (FXO)
Un port FXO (Foreign eXchange Office) représente au contraire le téléphone qui est
connecté au port FXS. Il en reçoit donc la tonalité. Ce type de port est utilisé en VoIP
pour connecter un réseau VoIP au réseau téléphonique classique afin de pouvoir faire
des appels vers l’extérieur. Les téléphones et les faxs font parties des FXO.
J’ai utilisé une VIC2-2FXO en tant que carte FXO. Tout comme la VIC2-2FXS, il existe
une ancienne version de la carte qui n’est pas compatible avec le matériel que j’ai utilisé.
Elle possède aussi deux ports qui sont quant à eux deux ports FXO.
Module VIC2-2FXS
Installation du Module
L’installation de la carte en soi n’est pas très compliquée, il suffit simplement de
l’insérer dans un des quatre slots du routeur. Il ne faut pas oublier d’éteindre le routeur
avant car ces cartes ne sont pas hot-plug comme le sont les modules pour Cisco 6500
par exemple.
TFE 2008 - 2009
Après avoir redémarré le routeur, je me suis vite rendu compte que les deux ports
n’étaient pas présents comme ils l’auraient du. En effet, il a fallu rajouter un module
PVDM au routeur. Ce type de module – interne – contient des DSPs. Sans entrer dans
les détails, les DSPs (Digital Signal Processing) gèrent tout ce qui concerne le traitement
de signaux audio et/ou vidéos : échantillonnage, compression, reconnaissance vocale,
etc. C’est donc grâce à ce module que la carte FXS est capable d’interagir avec le réseau
VoIP.
Le PVDM utilisé est un PVDM2-32, c'est-à-dire qu’il peut supporter 32 canaux vocaux.
Le codec utilisé par ce module est le G.711. Ce module contient deux DSPs.
Après l’insertion du module PVDM, les deux ports FXS sont reconnus par l’IOS. Les
commandes show version et show diag nous le confirment :
rogue-cme#show version
[...]
Cisco 2801 (revision 6.0) with 119808K/11264K bytes of memory.
Processor board ID FHK1106F1AX
2 FastEthernet interfaces
2 Voice FXS interfaces
2 DSPs, 32 Voice resources
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
500472K bytes of ATA CompactFlash (Read/Write)
[...]
rogue-cme#show diag
[...]
PVDM Slot 0:
32-channel (G.711) Voice/Fax PVDMII DSP SIMM PVDM daughter card
Hardware Revision
: 4.0
[...]
Product (FRU) Number
: PVDM2-32
[...]
VIC Slot 0:
2nd generation - FXS Voice daughter card (2 port)
Hardware Revision
: 3.1
[...]
Product (FRU) Number
: VIC2-2FXS
[...]
Configuration du Module
Par défaut, les ports FXS n’interagissent pas avec UC Manager Express. Pour qu’ils
puissent être contrôlés par SCCP, ces ports doivent utiliser l’application STC (SCCP
TFE 2008 - 2009
85
86
Telephony Control). Cette application doit être liée à un ccm-group – un groupe UC
Manager Express.
Il faut donc premièrement définir ce groupe :
rogue-cme(config)#sccp local FastEthernet0/1
rogue-cme(config)#sccp ccm 172.19.13.254 identifier 1 version 7.0
rogue-cme(config)#sccp
Les deux premières lignes sont utilisées pour identifier un UCME. Etant donné qu’il
tourne sur le routeur même, nous indiquons l’adresse du routeur. Le paramètre
identifier sera utile lors de la création du groupe pour identifier le UCME. La
commande sccp active tout simplement SCCP.
rogue-cme(config)#sccp ccm group 1
rogue-cme(config-sccp-ccm)#associate ccm 1 priority 1
Nous créons ensuite le groupe et y rajoutons le UCME défini auparavant. Une priorité
de 1 à 4 peut être entrée, la priorité 1 étant la plus importante.
Maintenant que nous avons notre groupe UCME, nous pouvons configurer l’application
STC :
rogue-cme(config)#stcapp ccm-group 1
rogue-cme(config)#stcapp
C’est assez simple : nous associons premièrement l’application au groupe UCME que
nous avons créé et ensuite nous l’activons. Maintenant que l’application STC est
configurée, nous pouvons indiquer au port FXS de l’utiliser.
En réalité, nous devons tout d’abord configurer un dial-peer que nous associerons au
port FXS. Nous lui dirons aussi d’utiliser STC. Ensuite nous pourrons configurer le port
FXS. Créons donc le dial-peer :
rogue-cme(config)#dial-peer voice 1 pots
rogue-cme(config-dial-peer)#port 0/0/0
rogue-cme(config-dial-peer)#service stcapp
L’identifiant du port peut être obtenu par la commande show voice port summary. Le
type de dial-peer que nous avons créé est de type pots (Plain Old Telephony Service).
Il existe quatre types possibles : mmoip (Multimedia over IP), pots, vofr (Voice over
Frame Relay) et voip (Voice over IP). UC Manager Express crée des interfaces virtuelles
de type pots. Il est possible de les voir avec la même commande :
rogue-cme#show voice port summary
IN
OUT
TFE 2008 - 2009
PORT
===============
0/0/0
0/0/1
50/0/1
50/0/2
CH
SIG-TYPE
ADMIN
== ============ =====
-- fxs-ls
up
-- fxs-ls
up
1
efxs
up
1
efxs
up
OPER
====
dorm
dorm
dorm
dorm
STATUS
========
on-hook
on-hook
on-hook
on-hook
STATUS
========
idle
idle
idle
idle
EC
==
y
y
y
y
Il est intéressant de noter le type des ports virtuels créés par UCME : ils sont de type
efxs (Ethernet FXS). Ces ports virtuels sont associés à des dial-peers que l’on peut
également voir grâce à la commande show dial-peer voice (cette commande a été
volontairement tronquée car les résultats n’étaient pas très clairs) :
rogue-cme#show dial-peer voice summary
dial-peer hunt 0
AD
TAG
TYPE MIN OPER PREFIX
DEST-PATTERN
1
pots up
up
20001 pots up
up
1001$
20002 pots up
up
1002$
OUT
STAT PORT
down 0/0/0
50/0/1
50/0/2
Nous y retrouvons le dial-peer que nous avons configuré ainsi que les deux dial-peers
que UCME a généré. Pour en revenir à la configuration de notre FXS, nous pouvons
maintenant configurer le port FXS :
rogue-cme(config)#voice-port 0/0/0
rogue-cme(config-voiceport)#ring frequency 50
rogue-cme(config-voiceport)#cptone BE
rogue-cme(config-voiceport)#caller-id enable
Nous y configurons d’abord la fréquence de la sonnerie. Deux choix sont possibles : 25
ou 50 Hertz. Cette fréquence doit être la même que celle utilisée par le téléphone
analogique, sinon il pourrait ne pas sonner. La commande cptone permet de fixer la
locale de la tonalité ; le paramètre est le code ISO 3166 du pays. La dernière commande
permet d’activer l’affichage du caller-id.
La configuration du port FXS est terminée. Cependant, aucun DN n’y est associé. Tout
comme les téléphones IP, il y a deux façons d’assigner un DN à un téléphone : la
méthode dynamique ou la méthode statique.
La méthode dynamique est la plus simple des deux : elle consiste à utiliser la commande
auto assign que nous avons vue auparavant. Il est possible de n’assigner des DNs
qu’aux téléphones analogiques en spécifiant le type anl.
rogue-cme(config-telephony)#auto assign 4 to 5 type anl
TFE 2008 - 2009
87
88
La méthode statique est beaucoup moins évidente à mettre en place. Elle est néanmoins
nécessaire lorsque l’on souhaite assigner un DN spécifique au téléphone. Rappelons
nous qu’un ephone est identifié par son adresse MAC. Cependant, un téléphone
analogique n’a pas d’adresse MAC ! Lors de l’assignation automatique, un algorithme
particulier est utilisé pour identifier un port FXS. C’est ce même algorithme qu’il faut
utiliser pour attribuer un DN de façon statique.
Calcul de l’Adresse MAC d’un Port FXS
Cet algorithme se base sur l’adresse MAC de l’interface du UC Manager Express local.
Lors de la création du groupe UCME, nous avons défini cette interface comme étant
FastEthernet0/1. Parmi les douze chiffres composant l’adresse MAC, seuls les neuf
chiffres les plus à droite sont retenus. Ces derniers composent les neuf premiers chiffres
de l’adresse MAC du port FXS.
Figure 6-3 : calcul de la MAC d’un port FXS
Les trois derniers chiffrent sont calculés à partir de l’identifiant du port FXS. Dans cet
exemple, nous utilisons le port 0/0/0 où chaque chiffre représente respectivement le
numéro de slot, le numéro de sous-unité et finalement le numéro de port. Ces valeurs
doivent être converties en binaire. Le numéro de slot occupera trois chiffres, le numéro
de sous-unité deux chiffres et le numéro de port sept chiffres. La valeur binaire obtenue
doit ensuite être convertie en hexadécimal afin d’avoir les trois chiffres manquants.
Par exemple, pour le port 0/2/1 :
Figure 6-4 : calcul de la MAC d’un port FXS (suite)
TFE 2008 - 2009
Dans notre cas, le port utilisé est le port 0/0/0. Sans trop de calculs, on peut facilement
déduire que les trois derniers chiffres seront 000. L’adresse MAC finale de notre carte
FXS est donc AE23.E600.B000. Nous pouvons comparer cette valeur avec celle obtenue
par l’assignation automatique. La commande show ephone anl fera l’affaire :
rogue-cme#show ephone anl
ephone-5[4] Mac:AE23.E600.B000 TCP socket:[1] activeLine:0 whisperLine:0
REGISTERED in SCCP ver 17/12 max_streams=1
mediaActive:0 whisper_mediaActive:0 startMedia:0 offhook:0 ringing:0 reset:0
reset_sent:0 paging 0 debug:0 caps:8
IP:172.19.13.254 17468 SCCP Gateway (AN) keepalive 297 max_line 1
available_line 1
port 0/0/0
button 1: dn 4 number 1004 CH1
IDLE
privacy button is enabled
Preferred Codec: g711ulaw
Finalement, nous pouvons vérifier que l’application STC est correctement configurée
grâce à la commande show stcapp device summary :
rogue-cme#show stcapp device summary
Total Devices:
1
Total Calls in Progress: 0
Total Call Legs in Use: 0
Port
Identifier
---------0/0/0
Device
Name
--------------AN1AE23E600B000
Device
State
-------IS
Call
Dev
Directory
State
Type
Number
------------- ------- ----------IDLE
ALG
1004
Dev
Cntl
---CME
Module VIC2-2FXO
Comme dit ci-haut, un port FXO permet de connecter notre système VoIP au réseau
téléphonique classique. L’intérêt réside dans le fait que l’on profite d’un système VoIP
avec un grand nombre de fonctionnalités et qu’à coté de cela, on puisse faire des appels
vers l’extérieur, comme avec un téléphone normal.
L’installation de la carte FXO au sein du routeur n’a pas posé de problème particulier.
Elle a directement été reconnue comme le montre le show version suivant :
rogue-cme#show version
[...]
Cisco 2801 (revision 6.0) with 119808K/11264K bytes of memory.
Processor board ID FHK1106F1AX
2 FastEthernet interfaces
2 Voice FX0 interfaces
2 Voice FXS interfaces
TFE 2008 - 2009
89
90
2 DSPs, 32 Voice resources
DRAM configuration is 64 bits wide with parity disabled.
191K bytes of NVRAM.
500472K bytes of ATA CompactFlash (Read/Write)
[...]
Configuration du Module
Tout comme le module FXS, il y a deux éléments à configurer : le port et un ou plusieurs
dial-peers. Commençons par configurer le port. Sa configuration est similaire à celle du
port FXS :
rogue-cme(config-voiceport)#cptone BE
rogue-cme(config-voiceport)#caller-id enable
Dans ce cas-ci, nous ne configurons pas la fréquence de la sonnerie ; c’est le port FXO
qui reçoit la tonalité. Nous créons ensuite un dial-peer pour permettre à nos utilisateurs
d’appeler l’extérieur :
rogue-cme(config)#dial-peer voice 999 pots
rogue-cme(config-dial-peer)#port 0/2/0
rogue-cme(config-dial-peer)#destination-pattern 9T
rogue-cme(config-dial-peer)#prefix 0
La première commande nous est déjà familière, elle indique le port à utiliser. Notre
carte FXO est installée dans le deuxième emplacement. Nous reparlerons du
destination-pattern un peu plus tard. La commande prefix indique que lorsqu’un appel
sort par le port FXO, le chiffre 0 doit être placé devant le numéro composé. Les lignes
analogiques de Cisco sont configurées ainsi : un appel extérieur doit toujours
commencer par un 0.
Revenons à notre destination-pattern. Lorsqu’un appel est émis, UC Manager Express
parcourt le destination-pattern de tous les dial-peers pour voir si l’un d’entre eux
correspond. Ces destination-patterns sont basés sur les expressions régulières (RegExp),
il est donc possible d’y avoir plusieurs correspondances. Dans ce cas, le destinationpattern le plus précis l’emporte. Ce fonctionnement fait fortement penser à celui de la
table de routage : si un paquet vers 192.168.1.200 doit être routé et qu’il y a deux routes
– 192.168.1.0/24 et 192.168.1.128/25, c’est la route la plus précise (la deuxième dans ce
cas) qui est utilisée.
Le tableau qui suit reprend les caractères qui peuvent être utilisés dans un destinationpattern :
Symbole
.
Description
Remplace un caractère
TFE 2008 - 2009
[]
()
?
%
+
T
$
Indique un fourchette de caractères possibles
Indique un pattern. Est utilisé avec ?, % ou +
Indique que le chiffre précédent peut être trouvé 0 ou 1 fois
Le chiffre précédent peut être trouvé 0 ou plusieurs fois (* en regexp)
Indique que le chiffre précédent est présent 1 ou plusieurs fois
Attend un certain timeout et récupère tous les chiffres
Indique la fin d’un numéro
Voici quelques exemples :
Pattern
1001$
9T
12[3-5].%
(23)+
Explication
Exactement le numéro 1001
Un numéro qui commence par 9
Le numéro doit commencer par 12, ensuite soit le chiffre 3, 4 ou 5 et
finalement n’importe quel caractère, zéro ou plusieurs fois.
23, 2323, 232323, 23232323, autant de fois 23
Tout numéro composé qui commence par le chiffre 9 sera automatiquement transféré
vers le port 0/2/0, c'est-à-dire notre carte FXO. Le chiffre 0 sera ajouté au début du
numéro. Ainsi, si le numéro 90478123456 est composé, le numéro qui sera transmis au
port FXO est le 00478123456.
Ceci s’applique pour les appels sortants. Pour ce qui concerne les appels entrants, c’est
la commande connection plar qui doit être utilisée. Cette commande s’applique
directement sur le port :
rogue-cme(config-voiceport)#connection plar opx 1001
Dans ce cas, tout appel entrant est redirigé vers le numéro interne 1001. Si plusieurs
numéros sont disponibles, il est possible d’utiliser le Direct Inward Dialing (DID). Ce
procédé utilise une partie du numéro pour identifier la personne qui doit être appelée en
interne. Malheureusement, je n’ai pas pu tester cette fonctionnalité.
Feature Access Code (FAC)
Cette fonctionnalité n’est pas propre aux téléphones analogiques mais c’est dans ce
domaine que j’en vois le plus l’utilité. Les Feature Access Codes (FAC) sont tous
simplement des combinaisons de touches qui permettent d’effectuer telle ou telle action.
Par exemple, si un utilisateur compose la combinaison **8 sur son téléphone, il rappelle
automatiquement le dernier numéro composé. C’est donc très utile pour les téléphones
analogiques qui ne disposent pas de touches supplémentaires prévues à cet effet
(softkeys) comme les téléphones IP.
Il est très simple d’activer les FACs :
TFE 2008 - 2009
91
92
rogue-cme(config-telephony)#fac standard
La commande qui suit affiche les FACs qui sont disponibles :
rogue-cme#show telephony-service fac
telephony-service fac standard
callfwd all **1
callfwd cancel **2
pickup local **3
pickup group **4
pickup direct **5
park **6
dnd **7
redial **8
voicemail **9
ephone-hunt join *3
ephone-hunt cancel #3
ephone-hunt hlog *4
ephone-hunt hlog-phone *5
trnsfvm *6
dpark-retrieval *0
Il est aussi possible de créer ses propres FACs. Il faut cependant désactiver le mode
standard. La commande devient alors :
rogue-cme(config-telephony)#fac custom feature code
Par exemple, si l’on veut que le FAC pour le rappel soit le **1, il suffit d’entrer :
rogue-cme(config-telephony)#no fac standard
fac standard has been disabled!
rogue-cme(config-telephony)#fac custom redial **1
fac redial code has been configurated to **1!
Pour vérifier que le système ait bien pris nos modifications en compte, on peut
réafficher les FACs disponibles :
rogue-cme#show telephony-service fac
telephony-service fac custom
redial **1
TFE 2008 - 2009
Chapitre 7 : La Téléphonie Sans-Fil
Notre lab est maintenant composé de téléphones IP ainsi que de téléphones
analogiques. Ce genre d’installation est suffisant pour la plupart des entreprises car les
employés travaillant a leur bureau le quitte assez rarement, du moins durant les heures
de travail. Néanmoins, il y a des employés qui se déplacent beaucoup, comme par
exemple les membres du team CALO. En effet, ces derniers voyagent fréquemment
entre leur bureau et le lab du TAC. Dans ce cas, il pourrait être intéressant d’avoir des
téléphones sans-fil qui accompagnerait les employés tout au long de la journée, ce qui
aurait l’avantage de les rendre joignable à tout moment.
Ce chapitre explique la mise en place d’un tel système. L’installation d’un access point et
la sécurisation du réseau sans-fil y est décrite. Voici le diagramme représente le lab de ce
chapitre :
Figure 7-1 : topologie du troisième lab
Cisco Aironet 1131 AG
L’access point que j’ai utilisé est un Cisco Aironet 1131 AG. C’est un access point
classique, opérant tant sur la bande des 2 GHz (802.11b/g) que sur la bande des 5 GHz
(802.11a). Il existe en version autonome ainsi qu’en version légère (pour être utilisé avec
un contrôleur sans-fil).
TFE 2008 - 2009
93
94
Figure 7-2 : Cisco Aironet 1131 AG
Cisco Unified Wireless IP Phone 7921G
Le téléphone sans-fil qui a été utilisé dans le lab est un Cisco Unified Wireless IP Phone
7921G. Ce téléphone est équipé d’un écran TFT couleur de 2 pouces (environ 5 cm). La
batterie permet au téléphone de tenir environ 200 heures en standby et environ 15
heures en communication. Il supporte les standards sans-fil IEEE 802.11a, b et g. Il
supporte également LEAP, PEAP, EAP-FAST, EAP-TLS, WPA, WPA2, CCKM, WEP,
TKIP et AES. Il peut être connecté à un ordinateur par USB. Il est aussi équipé d’une
dock-station avec haut-parleur intégré.
Figure 7-3 : Cisco Unified Wireless IP Phone 7921G
Sécurité des Réseaux Sans-Fil
Avant d’aborder la configuration de l’access point, nous allons revoir les différents
moyens de sécuriser un réseau sans-fil.
TFE 2008 - 2009
WEP
Wired Equivalent Privacy (WEP) est un algorithme de sécurisation des réseaux sans-fil.
Publié en 1997, cet algorithme est aujourd’hui déprécié à cause de certaines faiblesses
assez importantes. WEP utilise l’algorithme de chiffrement RC4 pour la confidentialité
et une somme de contrôle CRC-32 pour l’intégrité. WEP 64 utilise une clé de 40 bits
suivie d’un vecteur d’initialisation de 24 bits. WEP 128 utilise quant à lui une clé de 104
bits.
Figure 7-4 : WEP
WPA/WPA2
Wi-Fi Protected Access (WPA) a été créé suite aux problèmes rencontrés avec WEP.
WPA respecte une grande partie de la norme 802.11i tandis que WPA2 en respecte la
totalité. Ce mécanisme a été conçu pour être utilisé en collaboration avec un serveur
d’authentification 802.1X – WPA-Enterprise, mais il peut aussi être utilisé avec un
système de clé partagée, également appelée Pre-Shared Key (PSK). Nous parlons alors
de WPA-Personal.
WPA utilise le même algorithme de chiffrement que WEP, à savoir RC4. Cependant la
taille de la clé est de 128 bits et celle du vecteur d’initialisation est de 48 bits. WPA
utilise également le protocole TKIP (Temporal Key Integrity Protocol), qui change
dynamiquement les clés lors de l’utilisation du système. Ces améliorations empêchent
notamment certaines attaques dont WEP a souffert.
WPA n’utilise plus la somme de contrôle CRC-32 considérée comme peu sûre. A la
place, un algorithme d’identification des messages plus sécurisé appelé MIC (Message
Integrity Code) est utilisé.
WPA2 utilise l’algorithme de chiffrement CCMP qui est un protocole basé sur AES. Il est
considéré comme complètement sûr.
Concernant l’interopérabilité avec le framework EAP, seul le mécanisme EAP-TLS était
auparavant certifié par la Wi-Fi Alliance. Désormais les mécanismes EAP-TLS, EAP-
TFE 2008 - 2009
95
96
TTLS/MSCHAPv2, PEAPv0/EAP-MSCHAPv2, PEAPv1/EAP-GTC et EAP-SIM sont
inclus dans le programme de certification. Le but de cette certification est de faire
interopérer les mécanismes EAP les plus courants.
IEEE 802.1X
Le standard IEEE 802.1X est une solution de sécurisation basée sur EAP. Il contrôle
donc l’accès à un réseau. Ce standard repose sur trois acteurs :

Supplicant : c’est le client qui demande l’accès au réseau. Ce client fournit des
informations relatives à son identification comme par exemple un couple
login/password ;

Authenticator : c’est un équipement réseau tel qu’un switch ou un access point. Il
joue le rôle de garde de sécurité du réseau. Il transmet les informations fournies
par le client au serveur d’authentification ;

Serveur d’authentification : c’est un serveur (généralement RADIUS ou
TACACS+) qui vérifie que les informations fournies par le client sont exactes.
C’est donc lui qui décide si l’accès doit être donné ou non à un client.
Figure 7-5 : acteurs 802.1X
Le Framework EAP
Extensible Authentication Protocol (EAP) est un framework d’identification utilisé
principalement dans les réseaux sans-fil mais aussi dans les réseaux filaires. Il a été
défini dans la RFC 3748 et ensuite mis à jour dans la RFC 5247. EAP est un framework
dans le sens où il fournit des fonctions communes et des mécanismes d’authentification.
Ces mécanismes sont appelés « méthodes EAP » et sont au nombre de 40. Parmi cellesci, on peut retrouver EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-IKEv2, EAP-SIM
et EAP-AKA. Les méthodes les plus répandues dans les réseaux sans-fil sont EAP-TLS,
EAP-TTLS, PEAP, LEAP, EAP-FAST ou encore EAP-SIM.
Lorsque EAP est utilisé avec un NAS (Network Access Server) comme par exemple un
access point, une PMK (Pair-wise Master Key) est négociée entre le client et le NAS.
TFE 2008 - 2009
Cette clé peut ensuite être utilisée par des mécanismes d’encryptions comme TKIP ou
CCMP.
Bien que EAP ne soit pas un protocole, il définit des format de messages. Les méthodes
EAP doivent encapsuler ces messages. Dans le cas de 802.1X, l’encapsulation porte le
nom d’EAPOL (EAP over LAN).
Paquet EAP
Voici l’illustration d’un paquet EAP :
Figure 7-6 : paquet EAP
Un paquet EAP est composé de quatre champs :

Code : ce champ d’un octet identifie le type de paquet EAP. Il existe quatre codes
différents : Request, Response, Success et Failure ;
Identifier : ce champ, codé sur un octet, permet tout simplement de faire


correspondre une réponse à une demande ;
Length : ce champ de deux octets indique la taille totale du paquet EAP ;
Data : c’est la charge utile du paquet.

En ce qui concerne les paquets Request et Response, un champ supplémentaire Type
est déclaré comme suit :
Figure 7-7 : paquet EAP Request/Response
Ce champ peut prendre une des huit valeurs qui suivent :
TFE 2008 - 2009
97
98








Identity : ce type est utilisé par un utilisateur qui souhaite accéder à un réseau
protégé par une méthode EAP ;
Notification : utilisé par l’authenticator pour envoyer un message au
supplicant ;
Nak : ce type ne peut être utilisé qu’en tant que réponse. Il indique que le type
d’authentification n’est pas accepté ;
MD5-Challenge : ce type est utilisé dans les requêtes contenant un challenge
MD5 (semblable au protocole CHAP). La réponse doit être de type Nak ou MD5Challenge.
One Time Password (OTP) : utilisé pour les authentifications avec mot de passe
à usage unique. La réponse doit être de type Nak ou OTP.
Generic Token Card (GTC) : ce type est utilisé avec les implémentations de
cartes Token. La réponse doit être de type Nak ou GTC.
Expanded Types : ce champ est prévu afin que les constructeurs puissent utiliser
leur propre type ;
Experimental Use : utilisation expérimentale uniquement.
Voici le diagramme de séquence qui représente le mécanisme d’authentification de
base :
Figure 7-8 : authentification de base
TFE 2008 - 2009
Nous reverrons le mécanisme d’authentification plus en détail dans le paragraphe qui
suit. Notons tout de même que la communication de gauche, c'est-à-dire la
communication entre le client et l’access point est basée sur EAP tandis que la
conversation de droite (access point – RADIUS) est basée sur le protocole RADIUS.
EAP-FAST
EAP-FAST (Flexible Authentication via Secure Tunneling) est un protocole de Cisco
Systems défini dans la RFC 4851. Celui-ci remplace LEAP (Lightweight Extensible
Authentication Protocol) qui souffrait de quelques faiblesses. Toutefois, EAP-FAST
conserve le coté léger de celui qu’il a remplacé.
L’utilisation de certificats n’est pas obligatoire, EAP-FAST peut utiliser des PACs
(Protected Access Credential) pour établir un tunnel TLS dans lequel les informations
d’authentification du client seront transmises.
EAP-FAST possède trois phases :



La phase 0 est optionnelle, c’est celle où un éventuel PAC est approvisionné de
manière statique ou dynamique ;
La phase 1 concerne l’établissement du tunnel TLS ;
Finalement, la phase 2 concerne l’échange des informations du client dans le
tunnel crypté.
Lorsque le PAC est approvisionné de façon automatique, il y a un léger risque d’attaque
dans le sens où un attaquant pourrait intercepter le PAC et le réutiliser pour
compromettre les informations du client. La solution est alors d’utiliser un certificat.
Lorsque EAP-FAST est utilisé sans PAC, on se retrouve alors avec un EAP-TLS tout à
fait classique.
Paquet EAP-FAST
Un paquet EAP-FAST est constitué comme suit :
Figure 7-9 : paquet EAP-FAST
TFE 2008 - 2009
99
100
On y retrouve les quatre champs du paquet EAP. Viennent s’ajouter trois autres
champs : Flags, Ver et Message Length. Les flags sont au nombre de 4 : Lenght
Included, More Fragment, EAP-FAST Start et Reserved (doit être à zéro). Le champ
Ver contient tout simplement la version de EAP-FAST utilisée. Le champ Message
Length est présent uniquement si le flag Length Included est positionné : il indique la
taille totale du message dans le cas où celui-ci serait fragmenté. La valeur du champ
Type pour EAP-FAST est 43.
Fonctionnement de EAP-FAST
EAP-FAST Phase 0
Cette phase concerne l’approvisionnement du PAC (Protected Access Credentials). Elle
n’est pas décrite dans ce document.
EAP-FAST Phase 1
Durant cette phase, le tunnel TLS est établi. Le client commence par s’identifier (EAPResponse Identity) suite à la demande du serveur.
Le serveur débute ensuite la négociation du tunnel TLS qui est encapsulé dans un
paquet EAP-FAST avec le flag Start positionné. Le client s’identifie avec un
ClientHello en fournissant le PAC en tant qu’extension (SessionTicket SSL). Le
paquet envoyé par le client contient également la liste des algorithmes de chiffrement
supportés. Un nombre aléatoire est aussi transmis ainsi que la date courante. Le serveur
répond par un ServerHello : ce paquet contient également un nombre aléatoire ainsi
que l’algorithme retenu. TLS ChangeCipherSpec indique que l’on va passer dans le
tunnel TLS.
La MasterKey est calculée à partir du nombre aléatoire du client, du nombre aléatoire
du serveur et du PAC.
TFE 2008 - 2009
Figure 7-10 : phase 1 de EAP-FAST
Voici la phase 1 affichée dans Wireshark :
Figure 7-11 : phase 1 dans Wireshark
Dans l’exemple ci-dessus, le serveur propose d’abord la méthode LEAP. Le client répond
par un Nak et demande à la place l’utilisation de EAP-FAST.
EAP-FAST Phase 2
Les messages échangés durant cette phase sont cryptés ; ils passent par le tunnel TLS.
Le paquet EAP Payload TLV contient les informations du client (login/password par
exemple). Le Crypto-Binding TLV est utilisé pour prouver que le client et le serveur
ont participé dans l’établissement du tunnel TLS. Il permet également de vérifier la
version de EAP-FAST qui a été négociée.
TFE 2008 - 2009
101
102
Figure 7-12 : phase 2 de EAP-FAST
La phase 2 représentée dans Wireshark :
Figure 7-13 : phase 2 dans Wireshark
Mise en Place de EAP-FAST
Comme nous l’avons dit précédemment, EAP-FAST est une méthode EAP censée être
légère comme l’était LEAP. Justement, il n’est pas nécessaire de posséder un serveur
RADIUS externe pour mettre en place EAP-FAST. Les access points actuels incluent un
serveur RADIUS interne qui peut être utilisé pour l’authentification d’utilisateur via
EAP-FAST. Notre access point joue alors deux rôles parmi les trois du standard 802.1X :
celui d’authenticator et celui de serveur d’authentification.
Pour ce qui concerne la configuration de l’access point, elle sera elle aussi séparée en
deux parties : la partie dite classique, c'est-à-dire la configuration en tant
qu’authenticator et la partie AS, qui comprend la configuration du serveur RADIUS
local. La configuration de base de l’access point n’est pas développée ici ; elle est
cependant disponible en annexe.
Configuration de l’Authenticator
Commençons par définir le serveur RADIUS qui servira de serveur d’authentification.
Comme expliqué ci-haut, l’access point joue lui-même le rôle de serveur RADIUS ; il
doit donc indiquer sa propre adresse IP (172.19.13.253) :
TFE 2008 - 2009
rogue-ap(config)#radius-server host 172.19.13.253 auth-port 1812 acct-port
1813 key radiusKey
rogue-ap(config)#aaa new-model
rogue-ap(config)#aaa group server radius localRadius
rogue-ap(config-sg-radius)#server 172.19.13.253 auth-port 1812 acct-port 1813
Le paramètre key est un secret qui sera défini lors de la configuration du serveur
RADIUS. Il ne faut pas oublier d’activer le nouveau modèle AAA pour avoir accès aux
commandes relatives à AAA. Il faut également créer une liste AAA pour
l’authentification. Celle-ci sera utilisée plus tard lors de la configuration du SSID :
rogue-ap(config)#aaa authentication login fastMethod group localRadius
Nous pouvons nous attaquer à la configuration du SSID. Appelons-le cme :
rogue-ap(config)#dot11 ssid cme
rogue-ap(config-ssid)#authentication open eap fastMethod
rogue-ap(config-ssid)#authentication open network-eap fastMethod
rogue-ap(config-ssid)#authentication key-management wpa version 2
rogue-ap(config-ssid)#guest-mode
La commande authentication définit la méthode d’authentification utilisée par le
SSID. Dans notre cas, nous indiquons que nous souhaitons utiliser EAP couplé à WPA2,
ce qui correspond à WPA2-Enterprise. La commande guest-mode permet de diffuser le
SSID.
Nous devons maintenant configurer l’interface sans-fil – Dot11Radio0 :
rogue-ap(config)#interface Dot11Radio0
rogue-ap(config-if)#no ip address
rogue-ap(config-if)#ssid cme
rogue-ap(config-if)#encryption mode ciphers aes-ccm tkip
rogue-ap(config-if)#no shutdown
Cette interface n’a pas d’adresse IP, elle fait partie d’un bridge-group par défaut (BVI1).
Si ce n’est pas le cas, la commande bridge-group 1 suffit à régler le problème. Nous
assignons ensuite le SSID à l’interface grâce à la commande ssid. La commande
encryption permet de spécifier la méthode d’encryption utilisée par l’interface. Nous
indiquons à l’access point d’utiliser de préférence CCMP (AES) ou bien TKIP.
Finalement, nous activons l’interface avec la commande no shutdown (elle est
désactivée par défaut).
Après avoir été activée, l’interface va scanner les fréquences pendant un certain temps
(ce temps n’est pas fixe). C’est après ce scan qu’elle passera finalement en mode up/up.
TFE 2008 - 2009
103
104
%LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
%DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 33
seconds
Configuration du Serveur d’Authentification
Cette partie concerne la configuration du serveur RADIUS local :
rogue-ap(config)#radius-server local
rogue-ap(config-radsrv)#nas 172.19.13.253 key radiusKey
Après être entré dans le mode de configuration du serveur RADIUS local, nous
indiquons qu’il doit accepter les requêtes émanant du NAS (Network Access Storage –
l’authenticator) identifié par l’adresse 172.19.13.253 – c’est l’access point lui-même.
Le paramètre key est celui que nous avons configuré une page plus haut.
rogue-ap(config-radsrv)#no authentication leap
rogue-ap(config-radsrv)#no authentication mac
rogue-ap(config-radsrv)#eapfast authority id 12345678901234567890123456789012
rogue-ap(config-radsrv)#eapfast authority info rogue-ap
rogue-ap(config-radsrv)#eapfast server-key primary auto-generate
Dans les lignes ci-dessus, nous indiquons premièrement au serveur RADIUS de ne pas
accepter les requêtes pour les méthodes LEAP et MAC. Par défaut ces deux méthodes
ainsi que EAP-FAST sont activées. Les paramètres authority id et authority info
sont des valeurs qui seront affichées sur la machine du client lors de
l’approvisionnement du PAC. Ces valeurs permettent au client de s’assurer que l’access
point sur lequel il est connecté est le bon. En effet, un attaquant pourrait mettre en place
un access point avec le même SSID que le notre. Ainsi, lorsqu’un client se connecterait
sur l’access point de l’attaquant, ce dernier pourrait refuser le PAC du client et lui en
fournir un nouveau, ce qui n’est pas ce que nous voulons... Finalement, la dernière
commande – optionnelle – auto-génère la clé du serveur.
rogue-ap(config-radsrv)#group wcme
rogue-ap(config-radsrv-group)#ssid cme
rogue-ap(config-radsrv-group)#exit
rogue-ap(config-radsrv)#user fred password blah group wcme
La commande user permet de créer un utilisateur dans la base de donnée du serveur
RADIUS. Le paramètre group est optionnel, mais il permet de spécifier le SSID et le
VLAN auquel le client a accès. Dans notre cas, l’utilisateur fred a accès au SSID cme.
Il est possible de visualiser les statistiques du serveur RADIUS :
rogue-ap#show radius local-server statistics
Successes
: 1
Unknown usernames
: 0
TFE 2008 - 2009
Client blocks
Unknown NAS
: 0
: 0
Invalid passwords
: 0
Invalid packet from NAS: 0
NAS : 172.19.13.253
Successes
Client blocks
Corrupted packet
No username attribute
Shared key mismatch
Unknown EAP message
Auto provision success
PAC refresh
:
:
:
:
:
:
:
:
Unknown usernames
:
Invalid passwords
:
Unknown RADIUS message :
Missing auth attribute :
Invalid state attribute:
Unknown EAP auth type :
Auto provision failure :
Invalid PAC received
:
Username
fred
1
0
0
0
0
0
0
0
Successes
1
Failures
0
0
0
0
0
0
0
0
0
Blocks
0
Configuration du Client – Laptop
La configuration du laptop est assez simple. Le client que j’ai utilisé est le client d’Intel –
PROSet/Wireless. J’avais commencé à utiliser le client de Cisco (Secure Services Client)
mais un bug empêche la connexion à un réseau utilisant EAP-FAST avec un serveur
radius local...
Voici deux captures d’écran illustrant les paramètres de la connexion :
Figure 7-14 : configuration du client
TFE 2008 - 2009
105
106
Figure 7-15 : configuration du client (suite)
Configuration du Client – Cisco 7921G
La configuration du téléphone IP n’est pas très compliquée non plus... Un menu assez
intuitif permet de configurer jusqu’à quatre profils sans-fil. Voici grossièrement les
étapes à suivre pour configurer EAP-FAST sur un 7921G :







Aller dans Settings (flèche du bas) ;
Choisir Network Profiles (2) ;
Sélectionner un profil et aller dans WLAN Configuration ;
Afin de modifier les paramètres du profil, il faut déverrouiller le téléphone. Ceci
peut être fait avec la combinaison de touches **# ;
Modifier le champ SSID avec le SSID du réseau sans-fil ;
Sélectionner EAP-FAST dans le champ Security Mode ;
Remplir les deux champs UserName et Password avec les informations de
l’utilisateur.
EAP-TLS
EAP-TLS (Transport Layer Security) est un standard IETF défini dans la RFC 5216. Il
est considéré comme un des standards EAP les plus sécurisés et il est également
supporté par tous les équipementiers.
TFE 2008 - 2009
EAP-TLS utilise deux certificats pour établir le tunnel TLS : un coté client et un coté
serveur. Ceci a un avantage niveau sécurité : en effet, un vol de mot de passe n’est pas
possible. Cependant, il est possible de voler le certificat d’une personne, ce qui aurait le
même effet que le vol de mot de passe.
L’utilisation d’un certificat du coté client est aussi un problème car la mise en place et la
maintenance d’un tel système est laborieuse, du moins dans un réseau de grande taille.
En plus, le coût d’un certificat n’est pas négligeable. Il est néanmoins possible d’utiliser
un serveur de certificat lors d’une utilisation d’EAP-TLS en intranet. Les protocoles
PEAP et EAP-TTLS ont été créés pour palier à ce problème ; ils ne nécessitent qu’un
certificat coté serveur.
Paquet EAP-TLS
Voici un paquet EAP-TLS :
Figure 7-16 : paquet EAP-TLS
Ce paquet est sensiblement le même que celui de EAP-FAST. La seule différence se situe
au niveau des flags ; ceux-ci occupent 8 bits car il n’existe pas de champ version. Tout
comme dans les paquets EAP-FAST, il y a quatre différents flags : Length Included,
More Fragments, EAP-TLS Start et Reserved. Le champ TLS Message Length n’est
inclus que si le flag Length Included est positionné. La valeur du champ Type pour
EAP-TLS est 13.
TFE 2008 - 2009
107
108
Fonctionnement de EAP-TLS
Figure 7-17 : fonctionnement de EAP-TLS
Décrivons le fonctionnement principal de ce protocole :



Une fois qu’il a reçu l’identité du client, le serveur répond avec un paquet EAPTLS dont le flag EAP-TLS Start est positionné à 1. La conversation EAP-TLS
commence alors ;
Le client répond avec un paquet EAP-TLS dont la charge utile contient un
message ClientHello. Ce message comprend la version de TLS utilisée par le
client, un identifiant de session, un nombre aléatoire ainsi que la liste des
algorithmes de chiffrement supportés ;
Le serveur répond quant à lui avec un paquet EAP-TLS qui contient plusieurs
messages TLS. Le premier d’entre eux est le message ServerHello. Ce message
contient les mêmes informations que le message ClientHello, à savoir la
version de TLS utilisée par le serveur, un identifiant de session, un nombre
aléatoire ainsi que la liste des algorithmes de chiffrement supportés. Si
l’identifiant de session envoyé par le client est inconnu, le serveur considère qu’il
TFE 2008 - 2009




doit en établir une nouvelle. Dans ce cas, le serveur doit fournir son certificat
dans un message de type Certificate. Il demande également au client de
fournir son certificat via le message CertificateRequest. Finalement, le
message ServerHelloDone indique la cloture du paquet TLS ;
Si le client supporte EAP-TLS, il doit répondre par un paquet EAP-TLS qui
comprend lui aussi plusieurs messages TLS. Tout d’abord, il doit contenir les
messages ClientKeyExchange et ChangeCipherSpec. Ensuite, il doit contenir le
message Certificate étant donné que le serveur l’a demandé dans le message
précédent (CertificateRequest). Le message CertificateVerify permettra
au serveur de vérifier la signature du client. Finalement, le message TLS
Finished indique que le client a terminé ;
Le serveur envoie un paquet EAP-TLS contenant aussi les messages
ChangeCipherSpec et Finished.
Le client répond à la requête EAP-TLS du serveur par un paquet vide contenant le
même identifiant (champ Identifier).
Le serveur termine l’échange par un paquet EAP-Success.
Le client et le serveur peuvent alors communiquer en utilisant un chiffrement
symétrique. La clé secrète utilisée est dérivée du Master Secret, qui est un secret dérivé
du nombre aléatoire du client, du nombre aléatoire du serveur et du Pre Master Secret.
Figure 7-18 : construction des clés
Une capture dans Wireshark nous donne les paquets suivants :
TFE 2008 - 2009
109
110
Figure 7-19 : trafic EAP-TLS dans Wireshark
Certains paquets sont répétés car en réalité ces derniers sont fragmentés. Nous
retrouvons bien les paquets auxquels nous nous attendions, ce qui est déjà pas mal !
Mise en Place de EAP-TLS
La mise en place de EAP-TLS sur l’access point est plus simple que la mise en place de
EAP-FAST. En effet, le serveur d’authentification ne se situe plus sur l’access point. Il
faut utiliser un serveur RADIUS externe qui pourra gérer les certificats de nos clients.
Plusieurs serveurs RADIUS sont disponibles ; certains sont gratuits, d’autres le sont
moins ;). Parmi les plus connus, on retrouve FreeRADIUS, Cisco Secure ACS, Microsoft
IAS ou encore OpenRADIUS. Celui que j’ai décidé d’utiliser est évidemment Cisco
Secure ACS, afin de conserver une certaine homogénéité dans le réseau.
L’installation de Cisco Secure ACS est décrite dans les chapitres suivants. Nous ne nous
en occupons donc pas pour le moment ; la configuration de l’access point sera faite en
supposant que le serveur RADIUS est déjà configuré.
Configuration de l’Authenticator
La seule partie qui doit être configurée est donc la partie authenticator :
rogue-ap(config)#radius-server host 172.19.13.250 auth-port 1645 acct-port
1646 key acsKey
rogue-ap(config)#aaa new-model
rogue-ap(config)#aaa group server radius secureACS
rogue-ap(config-sg-radius)#server 172.19.13.250 auth-port 1645 acct-port 1646
Il est important de noter que le serveur Secure ACS utilise les ports 1645/1646 au lieu
des ports 1812/1813. Son adresse IP est 172.19.13.250.
rogue-ap(config)#aaa authentication login tlsMethod group secureACS
rogue-ap(config)#dot11 ssid cme
TFE 2008 - 2009
rogue-ap(config-ssid)#authentication open eap tlsMethod
rogue-ap(config-ssid)#authentication open network-eap tlsMethod
rogue-ap(config-ssid)#authentication key-management wpa version 2
rogue-ap(config-ssid)#guest-mode
rogue-ap(config-ssid)#exit
rogue-ap(config)#interface Dot11Radio0
rogue-ap(config-if)#no ip address
rogue-ap(config-if)#ssid cme
rogue-ap(config-if)#encryption mode ciphers aes-ccm tkip
rogue-ap(config-if)#no shutdown
Configuration du Client – Laptop
C’est encore le client d’Intel qui a été utilisé. Cette fois, il faut lui indiquer le certificat à
utiliser. La génération et l’installation de certificats est expliquée en annexe.
Figure 7-20 : configuration du client
TFE 2008 - 2009
111
112
Figure 7-21 : choix du certificat
Le certificat du client est automatiquement détecté lorsqu’il est installé sur l’ordinateur.
Figure 7-22 : configuration du client (suite)
TFE 2008 - 2009
Le certificat du serveur doit quant à lui être vérifié. Pour ce faire, il faut que le certificat
de l’autorité de certification soit installé (rogue-ca).
Configuration du Client – Cisco 7921G
Il n’est pas possible d’utiliser le menu du téléphone pour configurer EAP-TLS, du moins
pas entièrement. En effet, il faut installer le certificat du client et celui de l’autorité de
certification sur le téléphone. Il faut donc utiliser l’interface web qui nous permet de
faire tout ceci.
L’accès à l’interface web des téléphones est en mode read-only par défaut. Il faut donc
modifier un paramètre dans UC Manger Express pour lui indiquer que l’on souhaite
avoir un accès total à l’interface des téléphones IP. La commande à utiliser est très mal
documentée ; les seuls résultats que j’ai trouvé étant relatifs à UC Manager et non UC
Manager Express. Après quelques heures de recherche, je suis finalement tombé sur la
commande :
rogue-cme(config-telephony)#service phone webAccess 0
rogue-cme(config-telephony)#create cnf-files
En réalité, cette commande modifie un paramètre XML du fichier de configuration des
téléphones IP. Trois valeurs sont possibles : 0 (full-access), 1 (read-only) et 2
(disabled).
Ceci fait, nous avons accès à la page web du 7921G et plus particulièrement à la partie
Certificates :
TFE 2008 - 2009
113
114
Figure 7-23 : la page Certificates du 7921G
L’accès à certaines parties nécessite une identification de la part de l’utilisateur. Le
login/password par défaut est admin/Cisco.
Sur la capture d’écran ci-dessus, nous pouvons voir plusieurs certificats :





User Installed : c’est le certificat que nous allons utiliser pour EAP-TLS. C’est
l’utilisateur qui l’installe sur le téléphone IP ;
Manufacturing Issued : c’est un certificat qui est présent par défaut sur le
téléphone. Il peut aussi être utilisé pour une connexion EAP-TLS, mais il faut
alors installer le Manufacturing Root CA sur notre serveur ACS ;
Manufacturing Root CA : c’est le certificat racine de l’autorité de certification qui
a signé le certificat Manufacturing CA ;
Manufacturing CA : ce certificat, signé par le Manufacturing Root CA est le
certificat qui a signé le Manufacturing Issued ;
Authentication Server CA : c’est le certificat de notre autorité de certification.
Lorsque l’on souhaite installer un certificat utilisateur, le téléphone génère une
demande de certificat (CSR) à partir des données saisies :
TFE 2008 - 2009
Figure 7-24 : création d’un demande de certificat
TFE 2008 - 2009
115
116
Figure 7-25 : demande de certificat
Cette demande de certificat doit être fournie à l’autorité de certification qui délivrera
alors un certificat pour le téléphone. Ce certificat peut ensuite être installé sur le
téléphone (attention, le certificat doit être au format DER).
Le reste de la configuration peut être fait via le menu du téléphone :







Aller dans Settings (flèche du bas) ;
Choisir Network Profiles (2) ;
Sélectionner un profil et aller dans WLAN Configuration ;
Afin de modifier les paramètres du profil, il faut déverrouiller le téléphone. Ceci
peut être fait avec la combinaison de touches **# ;
Modifier le champ SSID avec le SSID du réseau sans-fil ;
Sélectionner EAP-TLS dans le champ Security Mode ;
Dans le champ EAP-TLS Certificate, choisir User Installed (cette option permet
aussi d’utiliser le Manufacturing Issued) ;
TFE 2008 - 2009
Chapitre 8 : Contrôleur de Réseaux Sans-Fil
Les réseaux sans-fil se répandent et évoluent de plus en plus chaque jour, c’est pourquoi
il est nécessaire de simplifier la configuration et la maintenance de tels réseaux. Par
exemple, si un site est couvert par trente access points, il est inconcevable de devoir
modifier la configuration des trente appareils pour changer le mot de passe
administrateur...
C’est dans ce type de situation que l’utilisation d’un contrôleur de réseaux sans-fil prend
tout son sens. En effet, il est possible de contrôler tous les access points d’un site à partir
d’un seul et même périphérique : le contrôleur de réseaux sans-fil (WLAN controller).
Dans ce cas, les access points connectés au contrôleur – appelés access point légers, font
tourner une version simplifiée d’IOS dans laquelle il n’est pas possible d’accéder au
mode de configuration.
Le Protocole LWAPP
Le protocole LWAPP (LightWeight Access Point Protocol) est un protocole ouvert
destiné à l’administration d’access points. LWAPP est utilisé pour les communications
entre les access points légers et le contrôleur.
Les messages de contrôle UDP sont cryptés avec un PKI utilisant AES-CCMP. Le trafic
classique (les données) n’est pas chiffré dans LWAPP et est commuté au niveau du
contrôleur. Ces deux types de trafic sont encapsulés. Le port source UDP est le port 1024
dans les deux cas. Le port destination 12222 est utilisé pour les données et le port
destination 12223 est utilisé pour le contrôle.
LWAPP peut-être utilisé à plusieurs niveaux du modèle OSI :


Layer 2 LWAPP : couche liaison (2) ;
Layer 3 LWAPP : couche réseau (3).
Lorsque le protocole LWAPP est utilisé au niveau de la couche liaison, il est encapsulé
dans une trame Ethernet. Ceci implique que l’access point et le contrôleur soient dans le
même VLAN ou sous-réseau. Dans ce cas, c’est l’adresse MAC qui est utilisée pour
communiquer. Un access point qui souhaite s’associer à un contrôleur commence par
envoyer un message LWAPP Discovery Request via broadcast et attend un Discovery
Response de la part d’un contrôleur. Si plusieurs réponses sont reçues, l’access point
choisit le contrôleur qui compte le moins d’access points connectés.
Si le protocole LWAPP est utilisé au niveau de la couche réseau, il est encapsulé dans
datagramme UDP puis dans un paquet IP. L’access point et le contrôleur peuvent alors
se situer dans des réseaux différents sans que cela ne pose de soucis. Le processus
TFE 2008 - 2009
117
118
d’association est sensiblement le même : l’access point envoie un LWAPP Discovery
Request et attend un Discovery Reponse en retour, qui contiendra alors l’adresse IP
du contrôleur en tant qu’adresse IP source.
Un access point essaie toujours d’utiliser LWAPP à la couche 2 en priorité et ensuite
LWAPP à la couche 3. Pour la couche 3, l’access point doit d’abord effectuer une requête
DHCP.
Cisco 2106 Wireless LAN Controller
J’ai utilisé dans ce lab un Cisco 2106 WLAN Controller. Ce contrôleur peut supporter
jusqu’à six access points. Il dispose de huit ports Ethernet, donc deux fournissant Power
over Ethernet.
Figure 8-1 : Cisco 2106 WLAN Controller
Configuration de Base
Le Cisco 2106 n’utilise pas l’IOS comme la plupart du matériel Cisco. Ceci est un peu
déroutant lorsque on est habitué à une interface particulière. Il m’a donc fallu quelques
temps pour me familiariser un peu avec ce nouveau CLI.
Quand on allume le contrôleur pour la première fois, un assistant de configuration nous
pose quelques questions afin de construire la base du système :
Welcome to the Cisco Wizard Configuration Tool
Use the '-' character to backup
System Name [Cisco_50:6d:80]: rogue_wlc
Enter Administrative User Name (24 characters max): fred
Enter Administrative Password (24 characters max): ********
Management
Management
Management
Management
Management
Management
Interface
Interface
Interface
Interface
Interface
Interface
IP Address: 172.19.13.252
Netmask: 255.255.255.0
Default Router: 172.19.13.254
VLAN Identifier (0 = untagged): 0
Port Num [1 to 8]: 1
DHCP Server IP Address: 172.19.13.254
AP Manager Interface IP Address: 172.19.13.251
TFE 2008 - 2009
AP-Manager is on Management subnet, using same values
AP Manager Interface DHCP Server (172.19.13.254):
Virtual Gateway IP Address: 10.10.10.254
Mobility/RF Group Name: rogue-rf
Network Name (SSID): rogue-cme
Allow Static IP Addresses [YES][no]: no
Configure a RADIUS Server now? [YES][no]: no
Warning! The default WLAN security policy requires a RADIUS server.
Please see documentation for more details.
Enter Country Code (enter 'help' for a list of countries) [US]: BE
Enable
Enable
Enable
Enable
802.11b
802.11a
802.11g
Auto-RF
Network [YES][no]: yes
Network [YES][no]: no
Network [YES][no]: yes
[YES][no]:
Configuration saved!
Resetting system with new configuration...
Deux interfaces sont configurées :


Management Interface : c’est l’interface que l’on a l’habitude de configurer ; c’est
cette interface qui sera « pingable » ;
AP Manager Interface : c’est l’interface qui est utilisée lors de l’utilisation de
LWAPP à la couche 3. L’adresse IP de cette interface est alors la source du tunnel
LWAPP. Cette interface peut être déclarée dans le même réseau que l’interface de
management.
Notons également que cet assistant crée pour nous un réseau sans-fil avec le SSID que
nous lui indiquons.
Nous pouvons ensuite nous connecter en utilisant le login et le mot de passe que nous
avons saisi lors de l’assistant. La commande suivante permet d’afficher la configuration
du contrôleur. Attention au paramètre commands ; sans celui-ci, la configuration est
fournie dans un format assez particulier...
>show run-config commands
On peut également ajouter un utilisateur de management (login : fred – pass : blah) :
>config mgmtuser add fred blah read-write
TFE 2008 - 2009
119
120
Finalement, configurons le contrôleur sans-fil pour qu’il se synchronise sur le serveur
NTP du 2801. Le timezone 14 correspond à GMT+1.
>config time timezone location 14
>config time ntp server 1 172.19.13.254
Mise à Jour de l’Image
J’ai du mettre à jour l’image du contrôleur sans-fil car l’ancienne version ne possédait
pas certaines commandes que je trouvais très utiles – show run-config commands par
exemple. La procédure de mise à jour est en fait très simple : on spécifie les différents
paramètres nécessaires au téléchargement de l’image et on lance la mise à jour avec la
commande transfer download start. Le contrôleur s’occupe du reste :
>transfer
>transfer
>transfer
>transfer
>transfer
>transfer
download
download
download
download
download
download
mode tftp
datatype code
serverip 172.19.13.254
path
filename AIR-WLC2100-K9-5-2-178-0.aes
start
Mode.............................................
Data Type........................................
TFTP Server IP...................................
TFTP Packet Timeout..............................
TFTP Max Retries.................................
TFTP Path........................................
TFTP Filename....................................
0.aes
TFTP
Code
172.19.13.254
6
10
AIR-WLC2100-K9-5-2-178-
This may take some time.
Are you sure you want to start? (y/N) y
TFTP Code transfer starting.
TFTP receive complete... extracting components.
Executing init script.
Writing new Code to flash disk.
Executing install_code script.
Writing new APIB to flash disk.
[00680266.58 <1242124708.626649>] Routine system resource notification.
TFE 2008 - 2009
Executing install_apib script.
TFTP File transfer is successful.
Reboot the switch for update to complete.
Mise en Place de EAP-TLS
Tout comme avec l’access point autonome, la configuration concernant EAP-TLS est
relativement simple et réduite. Un SSID a déjà été créé avec l’assistant de configuration,
néanmoins il peut être intéressant de connaître la commande à utiliser pour en créer un
nouveau :
>config wlan create 1 rogue-cme rogue-cme
Le premier paramètre est l’index qui identifie le réseau sans-fil ; c’est cet index que nous
utiliserons lorsque nous devrons configurer les paramètres du réseau. L’index 1 est
utilisé par le réseau qui est créé automatiquement avec l’assistant. Le deuxième
paramètre est le nom du profil créé. Finalement, le dernier paramètre représente le
SSID du réseau.
Commençons donc par configurer le serveur RADIUS :
>config radius auth add 1 172.19.13.250 1656 ascii acsKey
Cette commande ajoute la définition d’un serveur RADIUS. Le premier paramètre est
l’index du serveur. Ensuite viennent l’adresse IP et le port du serveur. Le dernier
paramètre, fourni au format ASCII, est le secret partagé.
>config radius auth network 1 enable
>config radius auth management 1 disable
>config radius auth enable 1
La commande radius auth network 1 enable configure le serveur RADIUS en tant
que serveur par défaut pour les utilisateurs réseau. La commande suivante le désactive
pour les administrateurs. Finalement on active le serveur RADIUS que nous venons de
définir avec la commande radius auth enable 1. L’index fourni à la fin de chaque
commande est l’index du serveur RADIUS que nous configurons.
Il faut ensuite activer WPA. Pour ce faire, il faut d’abord désactiver le réseau sans-fil afin
de pouvoir y faire des modifications :
>config
>config
>config
>config
wlan
wlan
wlan
wlan
1 disable
security wpa enable 1
security wpa wpa2 ciphers aes enable 1
security wpa wpa2 enable 1
TFE 2008 - 2009
121
122
Les trois dernières commandes activent WPA2 et spécifient l’algorithme à utiliser –
AES. L’index fourni à la fin de chaque commande est l’index du réseau sans-fil que nous
configurons.
Nous devons aussi activer le support de 802.1X pour WPA :
>config wlan security wpa akm 802.1x enable 1
La première commande qui suit associe notre serveur RADIUS au réseau sans-fil. Le
premier index est celui du réseau sans-fil ; le deuxième est celui du serveur RADIUS. La
commande suivante active le serveur pour ce réseau – normalement, il est actif par
défaut :
>config wlan radius_server auth add 1 1
>config wlan radius_server auth enable 1
Finalement, nous réactivons le réseau sans-fil :
>config wlan 1 enable
TFE 2008 - 2009
Chapitre 9 : Cisco Secure ACS
Cisco Secure Access Control Server (ACS) est le serveur RADIUS/TACACS+ de Cisco
Systems. La version 4.2 du serveur est compatible avec Microsoft Server 2000 et 2003.
Dans mon cas, je l’ai utilisé avec Microsoft Server 2003 Enterprise Edition.
L’installation du serveur en lui-même est exposée en annexe afin de ne pas polluer les
pages qui suivent avec trop d’images. Ce chapitre explique simplement la configuration
du serveur afin qu’il puisse jouer son rôle de serveur d’authentification dans le cadre
d’EAP-TLS.
Configuration de Cisco Secure ACS
Dans les chapitres précédents, nous avons vu comment EAP-TLS fonctionne ainsi que
les différents acteurs du standard 802.1X. La partie concernant le serveur
d’authentification n’ayant pas encore été abordée, nous allons la décrire maintenant.
Ajout d’un Compte Administrateur
Une fois Secure ACS installé, il faut accéder à l’interface web qui nous permet de
configurer le serveur. Attention, l’interface web n’est accessible que sur la machine
locale, du moins au début... Le port utilisé par l’interface web est le port 2002, l’URL
sera donc http://<ip_serveur>:2002. Commençons donc par créer un compte
utilisateur afin qu’un utilisateur distant puisse administrer le serveur :



Dans le menu de gauche, cliquer sur Administration Control ;
Une liste des comptes administrateur (vide pour le moment) s’affiche. Un bouton
Add Administrator permet d’ajouter un utilisateur ;
La page suivante permet de configurer le nom et le mot de passe du nouvel
utilisateur. Elle permet aussi de lui attribuer certains privilèges ;
TFE 2008 - 2009
123
124
Figure 9-1 : ajout d’un administrateur

Le nouvel utilisateur est créé lorsque l’on clique sur le bouton Submit.
Installation des Certificats
Etant donné que nous allons utiliser EAP-TLS, le serveur ACS a besoin d’un certificat
pour prouver son identité au clients du réseau. L’installation de certificats se fait dans la
partie System Configuration.
L’option ACS Certificate Setup nous affiche plusieurs possibilités :





Install ACS Certificate : cette option nous permet d’installer le certificat du
serveur. C’est cette option qui nous intéresse ;
ACS Certification Authority Setup : cette option permet d’ajouter des
autorités de certification ;
Edit Certificate Trust List : cette option indique à ACS de faire confiance
à des certificats installés avec l’option ci-dessus (ACS Cert Authority Setup) ;
...
Generate
Certificate
Signing
Request
(CSR) : ACS permet aussi de
générer des demande de certificats ;
TFE 2008 - 2009

Generate Self-Signed Certificate : cette option crée un certificat auto-
signé qui est installé automatiquement en tant que certificat du serveur.
L’option qui nous intéresse est la première, Install ACS Certificate :
Figure 9-2 : installation du certificat de Secure ACS
Le certificat que nous installons (rogue-aaa) a été délivré par notre autorité de
certification (rogue-ca). Il se trouve dans le magasin de certificats de la machine locale.
Le certificat de l’autorité de certification ne doit pas être spécialement ajouté au serveur
ACS car c’est l’autorité de certification qui a signé le certificat du serveur, il lui fait donc
automatiquement ainsi qu’à ceux dont le certificat est délivré par ce CA.
Ajout de Network Access Servers
Afin que les authenticators puissent effectuer des requêtes auprès de notre serveur
d’authentification, il faut que ceux-ci soient explicitement définis dans la configuration
du serveur ACS. Ceci se fait dans la partie Network Configuration :
TFE 2008 - 2009
125
126
Figure 9-3 : liste des clients et des serveurs AAA
Il y a deux types d’hôtes :

AAA Clients : ce sont les authenticators – dans notre cas l’access point et le

contrôleur sans-fil ;
AAA Servers : ce sont les serveurs d’authentification – RADIUS ou TACACS+.
Un serveur AAA est déjà défini, c’est le serveur ACS que l’on configure à l’instant. Si on
clique dessus, on peut modifier certains paramètres comme les ports sur lesquels le
serveur écoute (1645 et 1646 par défaut) et le type de requêtes qu’il accepte (RADIUS,
TACACS+ ou les deux).
La partie qui nous intéresse le plus est l’ajout de nouveaux clients AAA. Ceci peut être
fait en cliquant sur le bouton Add Entry situé sous la liste des clients AAA. La page qui
est ensuite affichée nous permet d’entrer les paramètres relatifs à notre authenticator :
nom, adresse IP, secret partagé et type d’authentification. Rappelons-nous que le secret
partagé est le paramètre key que nous avons utilisé lorsque nous avons configuré le
serveur RADIUS sur l’access point et le contrôleur sans-fil... Le type d’authentification
choisi est RADIUS.
TFE 2008 - 2009
Figure 9-4 : ajout d’un client AAA
Après avoir cliqué sur Submit+Apply, la liste des clients AAA se met à jour ; on peut
alors voir l’authenticator que nous venons d’ajouter :
Figure 9-5 : notre client AAA ajouté
Ajout d’Utilisateurs
Cisco Secure ACS possède une base de donnée interne dans laquelle il peut stocker les
utilisateurs qui se connectent sur le réseau. Il également possible de faire interagir
Secure ACS et l’Active Directory de Windows. Par manque de temps, je n’ai pas pu
tester cette fonctionnalité, c’est pourquoi nous allons utiliser la base interne du serveur
ACS.
Les utilisateurs peuvent être regroupés pour faciliter leur maintenance. C’est ce que
nous allons faire, nous allons créer un groupe qui s’appellera Wireless. En réalité, nous
allons renommer le groupe 0. Tous les utilisateurs que nous rajouterons par la suite
seront automatiquement ajoutés à ce groupe.
TFE 2008 - 2009
127
128
Pour renommer le groupe, il faut aller dans la partie Group Setup du menu. Trois
boutons sont disponibles. Le premier, Users in Group affiche les utilisateurs qui font
partie du groupe. Le deuxième bouton, Edit Setting permet de modifier des
paramètres du groupe, principale des attributs RADIUS. Finalement, le bouton Rename
Group nous permet de renommer le groupe.
L’ajout d’utilisateurs se fait quant à lui dans la partie User Setup. Il est possible de
rechercher un utilisateur par nom ou d’en créer un nouveau. Lors de l’ajout d’un
utilisateur, plusieurs paramètres peuvent être modifiés : le mot de passe, le groupe de
l’utilisateur, l’assignation d’adresse IP, etc. Le nom donné à l’utilisateur est important et
doit être le même que le nom indiqué dans le certificat de l’utilisateur (le CN – Common
Name).
Figure 9-6 : ajout d’un utilisateur
TFE 2008 - 2009
Activation de EAP-TLS
Finalement, il nous reste à activer EAP-TLS pour que notre réseau soit utilisable. Cette
activation se fait dans la configuration du système (System Configuration), plus
exactement dans sous-menu Global Authentication Setup.
La page de configuration de EAP nous permet d’activer ou de désactiver les protocoles
PEAP, EAP-FAST, EAP-TLS, LEAP et EAP-MD5. La configuration est assez limitée, on
indique simplement que l’on souhaite activer EAP-TLS et on choisit la façon dont le CN
du certificat est comparé avec le nom d’utilisateur de la base interne :
Figure 9-7 : configuration de EAP-TLS
On peut choisir parmi trois méthodes de comparaison :


Certificate SAN comparison : ce mode utilise le champ Subject
Alternative Name du certificat pour la comparaison ;
Certificate CN comparison : c’est le champ Common Name qui est utilisé pour
la comparaison ;

Certificate Binary Comparison : effectue une comparaison binaire entre le
certificat fourni par le client et celui stocké dans l’Active Directory.
Plusieurs méthodes peuvent être cochées ; Secure ACS les exécutera alors
séquentiellement. On peut également configurer la durée du timeout de la session EAPTLS.
TFE 2008 - 2009
129
130
TFE 2008 - 2009
Chapitre 10 : Conclusion
Chapitre 10 : Conclusion
Ce stage de 14 semaines chez Cisco m’a apporté beaucoup de choses. Du point de vue
professionnel, cela a été une découverte mais surtout un plaisir de pouvoir m’insérer
dans le monde du travail dans une société telle que Cisco Systems ! Cela m’a surpris
d’être considéré directement en tant qu’employé et non simplement comme un étudiant.
Ce stage m’a également permis d’avoir une approche plus ou moins précise du travail et
surtout de ce qui nous attend après les études. Ceci m’a confirmé que le domaine des
réseaux et des télécommunications est bel et bien un domaine qui me fascine.
L’entreprise m’a surtout bluffé du point de vue humain. Je ne m’attendais pas à être
intégré si rapidement. Une des forces de Cisco Systems est sa « multi-nationalité » ; des
personnes venant de plusieurs pays différents travaillent ensemble et arrivent à
communiquer, c’est ce que j’ai apprécié par-dessus tout. Il m’est arrivé de travailler avec
des espagnols, des libanais, des américains, des italiens, etc. Cependant, on n’apparaît
pas en tant que belge ou quoi que ce soit mais plutôt en tant qu’employé de chez Cisco !
Les employés sont polis et ont de l’humour. Il m’est arrivé de faire une partie de football
à l’extérieur avec trois personnes que je ne connaissais qu’à peine, et pourtant on a passé
un bon moment. Pareil pour le kicker, on se retrouvait de temps en temps au kicker
durant la pause ; ceci nous a permis de faire connaissance avec de nouvelles personnes.
Finalement, ce stage m’a aussi permis de mieux connaître certains élèves de ma classe
avec qui je ne parlais pas beaucoup auparavant.
TFE 2008 - 2009
131
132
TFE 2008 - 2009
Annexe A : Installation de Services Windows
Cette annexe reprend l’installation de deux composants Windows qui ont été installé
durant ce lab.
Internet Services (IIS)
Le premier service qui a été installé est Internet Services, connu sous le nom de IIS. Ce
composant est un serveur Web qui permet autant de gérer des pages statiques HTML
que des pages dynamiques ASP (.NET). Ce service est notamment utilisé par l’autorité
de certification pour son interface web, ce qui rend la création de certificats disponibles
à tous les utilisateurs du réseau. Internet Services est également utilisé par Cisco Secure
ACS. En effet, l’administration se fait via une page Web située sur le serveur. Il était
donc impératif d’installer ce service.
L’installation est très simple. Il faut tout d’abord se rendre dans le Panneau de
configuration. Il faut ensuite cliquer sur Ajout/Suppression de programmes. Une
fenêtre apparaît ; il faut alors cliquer sur Ajouter ou supprimer des composants
Windows dans le menu de gauche. Une nouvelle fenêtre fait son apparition :
Figure A-1 : liste des composants Windows
Il suffit ensuite de sélectionner le composant Serveur d’applications. Ce composant
inclut le service IIS. A la fin de l’assistant, le service est installé et démarré. On peut s’en
TFE 2008 - 2009
133
134
assurer en se rendant sur la page http://172.19.13.250 (ceci est l’adresse IP du
serveur sur lequel le service est installé) :
Figure A-2 : le serveur web fonctionne
Pas de panique, la page affiche est la page par défaut du service IIS. Elle peut être
modifiée dans le répertoire C:\Inetpub\wwwroot.
Autorité de Certification
Installation
L’autorité de certification est un service disponible sous Windows Server 2003. Il
permet de créer, signer ou supprimer des certificats. Il dispose d’une interface Web qui
permet aux utilisateurs du réseau de faire une demande de certificat via leur navigateur
Web.
L’installation de l’autorité de certification est similaire à celle du service IIS. Pour cela, il
faut se rendre dans le Panneau de configuration, Ajout/Suppression de
programmes et enfin Ajouter ou supprimer des composants Windows. Le
composant à installer est Services de certificats.
TFE 2008 - 2009
Figure A-3 : la liste des composants Windows
L’assistant nous pose ensuite quelques questions. Tout d’abord il nous demande le type
d’autorité de certifications que l’on souhaite établir. Dans la plupart des cas, c’est une
autorité racine qui est choisie.
Figure A-4 : type d’autorité de certification
Le Common Name (CN) de l’autorité nous est ensuite demandé ; le nom de notre
autorité est rogue-ca :
TFE 2008 - 2009
135
136
Figure A-5 : nom de l’autorité de certification
L’assistant nous signalement finalement que le service IIS doit être redémarré pour qu’il
puisse installer l’interface web du service. L’autorité de certification est installée ! On
peut
se
rendre
sur
l’interface
web
du
service
via
l’URL
http://172.19.13.250/certsrv (remplacer l’adresse IP par celle du serveur) :
TFE 2008 - 2009
Figure A-6 : interface web du serveur de certificats
Création de Certificats
Pour gérer les certificats de l’autorité, deux possibilités s’offrent à nous : l’interface Web
ou la console. La console, qui peut être lancée grâce à la commande mmc, peut se voir
greffer des « composants enfichables ». Voici une console où l’on a greffé trois
composants :
TFE 2008 - 2009
137
138
Figure A-7 : console
Pour la création du certificat du serveur ACS, nous avons créé un nouveau modèle de
certificat. Ce modèle peut être créé très facilement via le composant console Modèles
de certificats. La console nous affiche alors tous les modèles de certificats
disponibles. Nous pouvons partir d’un de ces certificats pour créer le notre. Il faut alors
faire un clic droit sur un certificat existant et choisir l’option Modèle dupliqué.
TFE 2008 - 2009
Figure A-8 : duplication d’un modèle
Une fenêtre de propriétés s’ouvre. Elle comporte plusieurs onglets. Parmi ceux-ci, les
plus importants :

Général : nous pouvons y changer le nom du modèle et sa période de validité par
défaut ;

Traitement de la demande : cet onglet permet de spécifier la taille minimale

de la clé et de choisir si la clé privée est exportable ou non ;
Nom du sujet : on peut choisir si le nom du sujet est fourni dans la demande ou
s’il est construit à partir des informations de l’Active Directory ;
TFE 2008 - 2009
139
140
Figure A-9 : propriétés du modèle
Il faut ensuite indiquer à l’autorité de certification que ce nouveau modèle doit être
proposé aux utilisateurs qui font des demandes de certificat. Ceci peut être configuré
dans les options de l’autorité de certification :
TFE 2008 - 2009
Figure A-10 : délivrance d’un nouveau modèle
Il faut alors choisir le modèle que nous venons de créer.
Nous allons maintenant créer le certificat du serveur proprement dit. Pour ce faire, nous
utiliserons l’interface Web du service. Sur la page d’accueil, il faut choisir Demander un
certificat, puis demande de certificat avancée. Un page nous permet de saisir
les informations relatives au serveur pour lequel nous demandons le certificat. Nous
pouvons également y choisir le modèle de certificat à utiliser. Il ne faut pas oublier de
cocher l’option Marquer les clés comme étant exportables ainsi que l’option
Stocker le certificat dans le magasin de certificats de l’ordinateur
local.
TFE 2008 - 2009
141
142
Figure A-11 : demande de certificat
Une fois le certificat généré, le serveur nous propose de l’installer sur la machine :
TFE 2008 - 2009
Figure A-12 : installation du certificat
TFE 2008 - 2009
143
144
TFE 2008 - 2009
Annexe B : Installation de Cisco Secure ACS
Annexe B : Installation de Cisco Secure ACS
La version de Cisco Secure ACS que j’ai installée est la version 4.2. Je l’ai installée sur
Windows Server 2003 Enterprise Edition. L’installation est très brève :
Premièrement, on commence par l’acceptation de la licence, un grand classique...
L’assistant d’installation nous demande ensuite s’il doit prendre la base de donnée de
l’Active Directory pour la gestion des utilisateurs :
Figure B-1 : choix de la base de données
Un mot de passe nécessaire au chiffrement de la base de donnée interne de Secure ACS
nous est ensuite demandé. Finalement, l’assistant nous demande si l’on souhaite
démarrer le service immédiatement. On peut également lancer la page d’administration
en cochant l’option prévue à cet effet :
TFE 2008 - 2009
145
146
Figure B-2 : options
L’installation est terminée. La page d’administration de ACS est accessible via l’URL
http://<ip_serveur>:2002.
TFE 2008 - 2009
Annexe C : Configurations Finales
rogue-cme (Cisco ISR 2801)
Current configuration : 8041 bytes
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname rogue-cme
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
enable secret 5 $1$hRBE$ykD9j8FwGDElGNWyFxSxa1
!
aaa new-model
!
!
aaa authentication login default local enable
!
!
aaa session-id common
clock timezone CET 1
clock summer-time CEST recurring
dot11 syslog
ip source-route
!
!
ip dhcp excluded-address 172.19.13.254
!
ip dhcp pool voicePool
network 172.19.13.0 255.255.255.0
default-router 172.19.13.254
option 150 ip 172.19.13.254
!
!
ip cef
no ip domain lookup
ip host rogue-ap 172.19.13.253
no ipv6 cef
multilink bundle-name authenticated
!
stcapp ccm-group 1
stcapp
!
!
!
!
voice logout-profile 1
user lp password blah
number 1999 type normal
!
voice user-profile 1
user sweeney password miam
number 1001 type normal
speed-dial 1 1002 label Pirelli
voice-card 0
TFE 2008 - 2009
147
148
!
username fred privilege 15 secret 5 $1$51wf$MZMzi4po2g.RhKUoPNH1p.
!
ip ssh version 2
ip scp server enable
!
interface Loopback0
ip address 128.0.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.48.77.184 255.255.255.0
duplex auto
speed auto
no cdp enable
!
ip address 172.19.13.254 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.48.77.1
!
ip http server
ip http authentication local
no ip http secure-server
ip http path flash:gui
!
tftp-server flash:atadefault.cfg
tftp-server flash:ata18xr.zup
tftp-server flash:APPS-1.3.2.SBN
tftp-server flash:TNUX-1.3.2.SBN
tftp-server flash:CP7921G-1.3.2.LOADS
tftp-server flash:WLAN-1.3.2.SBN
tftp-server flash:GUI-1.3.2.SBN
tftp-server flash:SYS-1.3.2.SBN
tftp-server flash:SCCP41.8-4-4S.loads
tftp-server flash:apps41.8-4-3-16.sbn
tftp-server flash:cnu41.8-4-3-16.sbn
tftp-server flash:cvm41sccp.8-4-3-16.sbn
tftp-server flash:dsp41.8-4-3-16.sbn
tftp-server flash:jar41sccp.8-4-3-16.sbn
tftp-server flash:term41.default.loads
tftp-server flash:P00308010100.bin
tftp-server flash:P00308010100.loads
tftp-server flash:P00308010100.sb2
tftp-server flash:P00308010100.sbn
tftp-server flash:RingList.xml
tftp-server flash:DistinctiveRingList.xml
tftp-server flash:Jamaica.raw
tftp-server flash:AIR-WLC2100-K9-5-2-178-0.aes
!
control-plane
!
voice-port 0/0/0
ring frequency 50
cptone BE
timeouts ringing infinity
caller-id enable
!
voice-port 0/0/1
!
TFE 2008 - 2009
voice-port 0/2/0
cptone BE
timeouts interdigit 0
impedance complex2
caller-id enable
!
voice-port 0/2/1
!
ccm-manager fax protocol cisco
!
mgcp fax t38 ecm
!
sccp local FastEthernet0/1
sccp ccm 172.19.13.254 identifier 1 version 7.0
sccp
!
sccp ccm group 1
associate ccm 1 priority 1
!
dial-peer voice 1 pots
service stcapp
port 0/0/0
!
dial-peer voice 911 pots
destination-pattern 9T
incoming called-number 1001$
direct-inward-dial
port 0/2/0
prefix 0
!
telephony-service
em keep-history
em logout 0:0 0:0 0:0
max-ephones 10
max-dn 10
ip source-address 172.19.13.254 port 2000
auto assign 4 to 5
service phone webAccess 0
timeouts night-service-bell 4
system message /!\ Maintenance reseau /!\
url authentication http://172.19.13.254/CCMCIP/authenticate.asp fred blah
user-locale FR
network-locale FR
load 7921 CP7921G-1.3.2
load 7960-7940 P00308010100
load 7941GE SCCP41.8-4-4S
time-zone 23
time-format 24
date-format dd-mm-yy
max-conferences 4 gain -6
web admin system name fadet password hello
dn-webedit
time-webedit
transfer-system full-consult
after-hours pstn-prefix 4 4
night-service code *1234
night-service everyday 16:00 07:00
night-service date Jan 1 00:00 23:59
fac custom redial **911
create cnf-files version-stamp 7960 May 20 2009 10:35:15
!
ephone-dn-template 1
TFE 2008 - 2009
149
150
!
ephone-template 1
softkeys idle Newcall Redial Join Mobility Cfwdall Dnd Pickup Gpickup
softkeys connected Endcall Trnsfer Hold Mobility Park Acct
speed-dial 1 1999 label "Receptionist"
!
ephone-dn 1 dual-line
number 1001
label Sweeney Todd
description Sweeney Todd
name Sweeney Todd
mobility
snr 90478123456 delay 3 timeout 10
!
ephone-dn 2
number 1002
pickup-call any-group
label Adolfo Pirelli
description Adolfo Pirelli
name Adolfo Pirelli
mobility
!
ephone-dn 3
number 1003
label Benjamin Barker
description Benjamin Barker
name Benjamin Barker
!
ephone-dn 4
number 1004
label Judge Turpin
description Judge Turpin
name Judge Turpin
night-service bell
!
ephone-dn 5
number 1005
label Johanna Barker
description Johanna Barker
name Johanna Barker
hold-alert 30 originator
!
ephone-dn 6
number 1006
label Beadle Bamford
description Beadle Bamford
name Beadle Bamford
mobility
!
ephone-dn 7
number 1007
label Mrs Lovett
description Mrs Lovett
name Mrs Lovett
!
ephone-dn 9
number 1999
label Receptionist
description Receptionist
TFE 2008 - 2009
name Receptionist
mobility
!
ephone 1
description Sweeney Todd
mac-address 0030.94C2.5E19
ephone-template 1
username "stodd" password miam
speed-dial 1 1002 label "Adolfo Pirelli"
type 7960
button 1:1 2s3
!
ephone 2
description Adolfo Pirelli
mac-address 0018.19B3.0224
ephone-template 1
speed-dial 1 1004 label "Judge Turpin"
type 7941GE
button 1:2
night-service bell
!
ephone 3
description Johanna Barker
mac-address 000D.294D.F1B7
max-calls-per-button 2
type ata
button 1:3
!
ephone 4
description Beadle Bamford
mac-address 001B.D454.A189
ephone-template 1
type 7921
logout-profile 1
!
ephone 5
privacy-button
mac-address AE23.E600.B000
type anl
button 1:4
!
ephone 6
mac-address 0021.553E.A709
type 7921
logout-profile 1
!
ephone 7
mac-address 001F.E21C.0187
ephone-template 1
type CIPC
button 1:7
!
alias exec sibu sh ip int brief | inc up
alias exec sir sh ip route
alias exec si sh ip int
alias exec sib sh ip int brief
!
line con 0
logging synchronous
TFE 2008 - 2009
151
152
line aux 0
line vty 0 4
logging synchronous
line vty 5 15
logging synchronous
!
scheduler allocate 20000 1000
ntp master
end
rogue-sw1 (Cisco Catalyst 2960)
version 12.2
no service pad
no service password-encryption
!
hostname rogue-sw1
!
boot-start-marker
boot-end-marker
!
enable secret 5 $1$flLj$0mvOCOKNFUXlw8f3l4ZQ81
!
username fred privilege 15 secret 5 $1$XlS7$Z3KTzY0B1ZdaH7TA682xe0
aaa new-model
!
!
system mtu routing 1500
ip subnet-zero
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
switchport mode access
!
!
[...]
!
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
no ip address
no ip route-cache
shutdown
!
ip http server
!
control-plane
TFE 2008 - 2009
!
line con 0
logging synchronous
line vty 0 4
logging synchronous
line vty 5 15
logging synchronous
!
monitor session 1 source interface Fa0/1
monitor session 1 destination interface Fa0/23
end
rogue-ap (Cisco Aironet 1131)
version 12.4
no service pad
service password-encryption
!
hostname rogue-ap
!
enable secret 5 $1$aA1A$2QHo/ZHyYsCvMRP6m4OS50
!
aaa new-model
!
aaa group server radius local_radius
server 172.19.13.253 auth-port 1812 acct-port 1813
!
aaa authentication login fast_login group local_radius
!
!
resource policy
!
clock timezone CET 1
clock summer-time CEST recurring
ip subnet-zero
!
dot11 ssid cme
authentication open eap fast_login
authentication network-eap fast_login
authentication key-management wpa
guest-mode
!
power inline negotiation prestandard source
!
username fred privilege 15 secret 5 $1$DzyD$Jkb5cvZ6S6Pf1RcH7zT6R.
!
bridge irb
!
interface Dot11Radio0
no ip address
no ip route-cache
shutdown
!
encryption mode ciphers aes-ccm tkip
!
ssid cme
TFE 2008 - 2009
153
154
!
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 source-learning
no bridge-group 1 unicast-flooding
bridge-group 1 spanning-disabled
!
interface Dot11Radio1
no ip address
no ip route-cache
shutdown
dfs band 3 block
channel dfs
station-role root
bridge-group 1
bridge-group 1 subscriber-loop-control
bridge-group 1 block-unknown-source
no bridge-group 1 unicast-flooding
!
interface FastEthernet0
no ip address
no ip route-cache
duplex auto
speed auto
bridge-group 1
!
interface BVI1
ip address 172.19.13.253 255.255.255.0
no ip route-cache
!
ip default-gateway 172.19.13.254
ip http server
no ip http secure-server
ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag
radius-server local
no authentication leap
no authentication mac
eapfast authority id 12345678901234567890123456789012
eapfast authority info AP
eapfast server-key primary 7 CDAA62BA123F980ECC28F1E27742179164
nas 172.19.13.253 key 7 06000E325871021C1C
group wireless_cme
!
group test
ssid cme
!
user fred nthash 7 08051D6D2D4D2440455F5C547B7E7D096166014750352656730100030C5B524B32
user fmereu nthash 7 0225517D52545B00156B2F4A5C4233595C567C7F027D6313074A5442265301097C group
test
!
radius-server host 172.19.13.253 auth-port 1812 acct-port 1813 key 7 000212151064000316
bridge 1 route ip
!
line con 0
logging synchronous
line vty 0 4
TFE 2008 - 2009
logging synchronous
line vty 5 15
logging synchronous
!
end
TFE 2008 - 2009
155
156
TFE 2008 - 2009
Acronymes Utilisés dans ce Livre
Acronymes Utilisés dans ce Livre
ACS
AES
AP
CA
CCKM
CDP
CN
DHCP
DN
DSP
EAP
EAP-FAST
EAPOL
EAP-TLS
FXO
FXS
EPhone
FAC
IAX
IIS
ILP
IOS
IP
ISDN
IVR
LEAP
LWAPP
MAC
MGCP
NAS
PAC
PBX
PEAP
PoE
POTS
PSK
PSTN
QoS
SPAN
RADIUS
RNIS
RTP
SCCP
SCP
: Access Control Server
: Advanced Encryption Standard
: Access Point
: Certification Authority
: Cisco Centralized Key Management
: Cisco Discovery Protocol
: Common Name
: Dynamic Host Configuration Protocol
: Directory Number
: Digital Signal Processing
: Extensible Authentication Protocol
: EAP-Flexible Authentication via Secure Tunneling
: EAP over LAN
: EAP-Transport Layer Security
: Foreign eXchange Office
: Foreign eXchange Station
: Ethernet Phone
: Feature Access Code
: Inter Asterisk eXchange
: Internet Services
: InLine Power
: Internetwork Operating System
: Internet Protocol
: Integrated Service Digital Network
: Interactive Voice Response
: Lightweight EAP
: LightWeight Access Point Protocol
: Media Access Control
: Media Gateway Control Protocol
: Network Access Server
: Protected Access Credential
: Private Branch eXchange
: Protected EAP
: Power over Ethernet
: Plain Old Telephone System
: Pre Shared Key
: Public Switched Telephone Network
: Quality of Service
: Switched Port ANalyzer
: Remote Authentication Dial In User Service
: Réseau Numérique à Intégration de Services
: Real Time Protocol
: Skinny Client Control Protocol
: Secure CoPy
TFE 2008 - 2009
157
158
SDP
SIP
SSID
STC
TACACS+
TCP
TFTP
TKIP
UCME
UDP
URL
VoIP
WEP
WLAN
WPA
: Session Description Protocol
: Session Initiation Protocol
: Service Set Identifier
: SCCP Telephony Control
: Terminal Access Controller Access-Control System Plus
: Transport Control Protocol
: Trivial File Transfer Protocol
: Temporal Key Integrity Protocol
: Unified Communications Manager Express
: User Datagram Protocol
: Uniform Resource Locator
: Voice over IP
: Wired Equivalent Privacy
: Wireless LAN
: Wi-Fi Protected Access
TFE 2008 - 2009
Bibliographie
Bibliographie
Building Cisco Multilayer Switched Networks (BCMSN) (Authorized SelfStudy Guide), 4th Edition [Livre] / aut. R. Froom B. Sivasubramanian, E. Frahim. [s.l.] : Cisco Press.
Cisco IOS in a Nutshell, Second Edition [Livre] / aut. Boney James. - [s.l.] :
O'Reilly.
Cisco Unified CME 7.1 Supported Firmwares, Platforms, Memory and Voice
Products [En ligne]. http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/requirements/guide/cme7
1spc.htm.
Cisco Unified CME and Cisco IOS Software Version Compatibility Matrix
[En ligne]. http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/requirements/guide/33ma
trix.htm.
Cisco Unified CME System Administrator Guide [En ligne]. http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guid
e/cmeadm.html.
Cisco Unified Wireless IP Phone 7921G Administration Guide [En ligne]. http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7921g/7_0/english/admi
nistration/guide/7921G_AdminGuide.html.
Cisco Wireless LAN Controller Configuration Guide [En ligne]. http://www.cisco.com/en/US/docs/wireless/controller/5.2/configuration/guide/Contr
oller52CG.html.
Configuring an Access Point as a Local Authenticator [En ligne]. http://www.cisco.com/en/US/docs/wireless/access_point/12.3_2_JA/configuration/g
uide/s32local.html.
Configuring Analog Voice Ports [En ligne]. http://www.cisco.com/en/US/docs/ios/voice/voiceport/configuration/guide/vp_cfg_a
nalog_vps_ps6441_TSD_Products_Configuration_Guide_Chapter.html.
Configuring Cisco Unified CallManager Express [En ligne]. http://uc500.com/CiscoCallManagerExpress.
Configuring FXS Ports for Basic Calls [En ligne]. http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fxsbasic.html.
TFE 2008 - 2009
159
160
LEAP Authentication on a Local RADIUS Server [En ligne]. http://www.cisco.com/en/US/products/hw/wireless/ps4570/products_configuration_
example09186a00801c0912.shtml.
Understanding Inbound and Outbound Dial Peers Matching on IOS
Platforms [En ligne]. http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010
fed1.shtml.
User Guide for Cisco Secure Access Control Server 4.2 [En ligne]. http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_f
or_windows/4.2/user/guide/SCBasic.html.
TFE 2008 - 2009

Etude et Implémentation d`une Téléphonie IP Mixte d

Transcription

Documents pareils

Fiche de stage 2015 CISCO Systems France 14NCER0010 Type de

CISCO Maisons-Alfort - Académie de Créteil

Forum des télécoms/TIC en Afrique, les 21 et 22 octobre à

Détail de l`offre : CDI - Responsable Réseaux

Recherche et partenariat

Proforma / Bon de commande N° 2011157

formation en kinésitherapie : les abdos autrement

DESGN – Designing for Cisco Internetwork

overview mb2kgroup

Les Télécoms