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.
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
CONFIGURATION DE BASE DU 2801 ... 44
NTP ... 44
DHCP ... 44
CONFIGURATION DE UCMANAGER EXPRESS ... 45
Configuration Classique (Manuelle) ... 45
Configuration Automatique ... 46
AJOUT DE TÉLÉPHONES À UCMANAGER 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 1131AG ... 93
CISCO UNIFIED WIRELESS IPPHONE 7921G... 94
SÉCURITÉ DES RÉSEAUX SANS-FIL ... 94
WEP ... 95
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 2106WIRELESS LANCONTROLLER ... 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 ISR2801) ... 147
ROGUE-SW1(CISCO CATALYST 2960) ... 152
ROGUE-AP (CISCO AIRONET 1131) ... 153
ACRONYMES UTILISÉS DANS CE LIVRE ... 157
BIBLIOGRAPHIE ... 159
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
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.
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.
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.
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
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
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
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
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 Etats- Unis. 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 :
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 – rassurez- vous, ils devraient être remplacés sous peu !
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 ci- dessous 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.
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.
Figure 1-9 : VMWare ESX Server
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é Assignation Résolution
CAPS Dans les 10 minutes Dans les 4 heures
P1 Dans les 15 minutes Dans les 4 heures
P2 Dans les 4 heures Dans les 24 heures
P3 Dans les 24 heures Dans les 2 jours
P4 Dans les 24 heures 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 :
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 ;
WorkinProgress : le propriétaire du case travaille sur le case ;
PendingClient : le propriétaire attend une réponse de l’ingénieur ;
PendingApproval : la topologie a été soumise à l’ingénieur ;
PendingHardware : 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 :
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.
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 !
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 ordre- ci 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
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.
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
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.
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
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 :
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.
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.
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 Débit Score MOS BP 802.3 1 heure
G.711 64 Kbps 4.45 87.2 Kbps 38.3 MB
G.729 8 Kbps 3.92 31.2 Kbps 13.7 MB
G.723.1 6.3 Kbps 3.9 21.9 Kbps 9.6 MB
G.723.1 5.3 Kbps 3.65 20.8 Kbps 9.1 MB
G.726 32 Kbps 3.85 55.2 Kbps 24.2 MB
G.728 16 Kbps 3.61 31.5 Kbps 13.8 MB
GSM 13.2 Kbps 3.5 28.7 Kbps 12.6 MB
iLBC 15.2 Kbps 4.14 30.83 Kbps 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
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.
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
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
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
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 Puissance Maximale 0 (par défaut) 15.4 Watts
1 4.0 Watts
2 7.0 Watts
3 15.4 Watts
4 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).
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) Remaining:363.7(w)
Interface Admin Oper Power Device Class Max (Watts)
--- --- --- --- --- --- ---- Fa0/1 auto on 6.3 IP Phone 7960 n/a 15.4 Fa0/2 auto off 0.0 n/a n/a 15.4 Fa0/3 auto off 0.0 n/a n/a 15.4 Fa0/4 auto off 0.0 n/a n/a 15.4 Fa0/5 auto off 0.0 n/a n/a 15.4 Fa0/6 auto off 0.0 n/a n/a 15.4 Fa0/7 auto off 0.0 n/a n/a 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 ;
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 :
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 Device Class Max (Watts)
--- --- --- --- --- --- ---- Fa0/1 auto on 15.4 Cisco PD n/a 15.4 Fa0/2 auto off 0.0 n/a n/a 15.4 Fa0/3 auto off 0.0 n/a n/a 15.4 Fa0/4 auto off 0.0 n/a n/a 15.4 Fa0/5 auto off 0.0 n/a n/a 15.4 Fa0/6 auto off 0.0 n/a n/a 15.4 Fa0/7 auto off 0.0 n/a n/a 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.
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
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 excluded- address ; 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.
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).
