Serveur de management Cisco orienté Data Center et principalement Nexus.
Il permet de manager les équipements de cette gamme (Logs, installations, provisionning…etc.).
Il permet également de voir les équipements Cisco Catalyst, mais aucune modification possible.
Très orienté management, il ne récolte pas assez de logs/graphes pour faire de la supervision, capacité planning…etc. Il est plutôt orienté troubleshooting.

1 Serveur physique = 2 processus (LAN / SAN).

Les LAN et SAN sont historiquement séparés, mais sont en train de se consolider, la version 6.0 devrait avoir un seul processus pour les deux environnements.

+ Serveurs distants nécessaires :

• DB  - Base de donnée PostgreSQL/Oracle pour stoquer les données. Cette base peut aussi être locale pour des très petites architectures.
• AAA - Authentification pour les utilisateurs du DCNM
• NX-OS images - Pour le provisionning des Nexus (FTP, TFTP…etc.)

Fonctionnement:
Transferts DCNM<==>Nexus en XML (SSH/Netconf/XML), pas de SNMP, sauf pour les MDS.
4 clients différents (Web, DCNM-LAN, DCNM-SAN, Device manager)

——————————————————————————————————
INSTALLATION
——————————————————————————————————
Pré-requis:

• Windows 2k3 / 2k8 / RedHat - 32/64K (english)
• Static mac / IP
• ActivePerl
• Connectivité avec les ports de management des équipements Nexus

Database: sur le serveur ou remote (PostgreSQL / oracle…)
NAT : pas supporté
Problème pour les installations linux : interface graphique obligatoire.. donc installer X11, les Libx..etc.

A la fin de l’install : l’instance ID est affiché –> Sert pour les licences.
C’est le même lorsque l’on installe/désinstalle/ré-installe… pas de problème à ce niveau.

• Processus START/STOP dans menu démarrer pour le serveur LAN,
• Processus START/STOP dans services.msc pour le serveur SAN.

Accessibilité aux clients:

• DCNM-LAN Client = http://<ip-serveur>:8080/dcnm-client/
• DCNM-SAN Client = http://<ip-serveur>/

Best-practices à activer pour éviter les problèmes:

• Archivage des configurations automatiquement
• Auto-purge dans Auto-synchro with devices, pour purger les lots et éviter de surcharger le serveur.

Installation de DCNM sur XP, Windows 7…etc. possible:
installation en CLI avec “-Dforce=true” (évite la vérification de l’OS)

——————————————————————————————————
DCNM-LAN
——————————————————————————————————
Attention à la compatibilité DCNM / Nexus-OS
http://www.cisco.com/go/dcnm -> Release and general information -> Compatibility Information -> DCNM Release compatibility matrix

DCNM essaye de suivre les version NX-OS du N7k.

Découverte des équipements:
Pré-requis:

• via interfaces management
• synchronisation des horloges (DCNM <=> Nexus) Le DCNM doit être en avance par rapport aux nexus, au pire
• Timezone CET !!!!
• SSH, CDP activés
• user DCNM Network-admin role (utilisateur dédié recommandé)
• terminal no log-all sur les Nexus

Changements effectués par DCNM sur les Nexus
==> logging-level augmenté.

DCNM l’augmente lui-même pendant la découverte des équipements car il se sert des logs pour retranscrire l’état des équipements.
Si on baisse ce level plusieurs fois de suite, DCNM passe l’équipement en mode “unmanaged”.

Synchronisation des équipements
Toute les 60sec + à chaque changement
La découverte prends 1 à 4 minutes la première fois.

Etats des équipements
/ Managed
/ Unmanaged (sens-interdit)
/ Unreachable
/ Disvocery in process (loupe)

——————————————————————————————————
LICENSING
——————————————————————————————————

LAN essential : gratuit mais il faut commander un PID et générer une licence gratuite à 0$. Jusqu’à 100 équipements Nexus.

Possibilité d’avoir des licences d’évaluations (2 max).
Si besoin de licences pour maquettes…Etc; contacter Cisco.

LICENCE PAK + LICENCE ID + nombre d’équipements.
installation des licences (fichiers .lic) ==> Relancer l’installeur.

• - Un fichier .lic par Nexus 7000.
• - Il faut laisser les .lic sur le serveur dans un répertoire différent de l’installe DCNM !!

Aller ensuite sur le client dans DCNM > DCNM Licensed Devices List
Déployer les licences sur les équipements.
DEPLOY pour conclure l’installe des licences.

——————————————————————————————————
TAC
——————————————————————————————————

Pour ouvrir les cases, prendre les logs sur le serveur + Screenshots des problèmes.

Voici le programme de la semaine :
• Describe the Cisco Nexus products
• Implement security on Cisco Nexus products
• Manage and operate Cisco Nexus products
• Implement high availability features on Cisco Nexus products
• Troubleshoot Cisco Nexus products
• Implement Cisco Nexus network features and functionality
• Implement Cisco Nexus unified fabric features and functionality
• Understand how to install Cisco Nexus products

Au programme, passage en revue de la gamme Nexus, et donc des nouvelles fonctionnalités de virtualisation Data Center de Cisco (FCoE, VDC, vPC…).

• Jour 1:
  • Explications du contexte, positionnement de Cisco / Beaucoup de bla bla business.. ROI, Gross Margin.. perte de temps selon moi à ce niveau là par rapport à l’objectif du cours, mais ce passage va me servir à agrémenter mon mémoire de fin d’études.
  • Présentation des gammes Nexus (1000v, 2k, 5k, 7k)
  • FCoE (vu rapidement..)
  • VPC (vu rapidement..)
  • FabricPath (vu rapidement..)
  • VDC
  • Début du lab VDC
• Jour 2:
  • Fin du lab VDC
  • Lab PVRST+ (un peu trop basique, on ne s’attend pas à faire ça en arrivant)
  • Lab MST (un peu trop basique, on ne s’attend pas à faire ça en arrivant)
  • Lab VRF + Routage (RIP/OSPF)
  • lab VPC
• Jour 3:
  • FEX + Lab
  • OTV + Lab
  • Qos + Lab
• Jour 4:
  • Fin de la QoS
  • FabricPath
  • Lab Troubleshooting
  • “Freestyle Lab”, nous pouvions faire les tests que nous voulions sur la maquette.
• Jour 5:
  • FCoE + Lab
  • VSAN/MDS + Lab

La semaine se termine avec le sentiment de ne pas être assez entré dans les détails des technologies Nexus. Je trouve que nous avons perdus beaucoup de temps sur des technologies de bases en Lab (PVSTP+, RIP.. etc) et nous n’avons pas pu exploiter au mieux le Lab pour pratiquer les technologies nouvelles (FCoE, FabricPath..etc.). La formation devrait s’orienter beaucoup plus vers les technologies Nexus, mais elle s’attarde sur le L2 “général”.

Le cours ne parle pas vraiment des “Best Practise” en Design NEXUS non plus, heureusement que certaines personnes présentes ont pu détailler certains points grâce à leur expérience (ayant déjà effectué des installations Nexus pour de gros comptes).

J’ai récupéré pas mal de data sheet Cisco pour aller plus loin, ainsi que les présentations des derniers événements Networkers qui expliquent un peu plus largement les technologies abordées cette semaine.

Plus de détails sur les technologies rencontrées cette semaine dans de prochains articles.

Sommaire:

1. Introduction
2. Présentation d’IPv6
3. Méchanismes de transition IPv4 vers IPv6
   1. ISATAP
   2. TEREDO
   3. 6to4 Tunneling
4. Routage IPv6
5. Conclusion

I. Introduction

Le protocole de routage principalement utilisé aujourd’hui pour les communications Internet est le protocole IP (Internet Protocol). La version la plus utilisée du protocole IP est la version 4 (IPv4) et n’a fait l’objet d’aucune évolution majeure depuis la publication du document fondateur, la RFC 791. Le protocole IP dans sa version 4 s’est avéré assez robuste tout au long de l’essor de l’Internet. Cependant, un certain nombre de caractéristiques et d’évolutions n’ont pas été prises en compte, ce qui à conduit à la nécessité de l’élaboration d’un successeur au protocole IP actuel.

Parmi les évolutions actuelles mal considérées par IPv4, on peut citer :

• la croissance rapide de l’Internet qui conduit rapidement à un épuisement des adresses IPv4 disponibles L’IANA à distribué les derniers ranges IPv4 récemment, voir mon dernier article sur IPv6 (Graphiques).
  
• la multiplication des systèmes communiquant mobiles (PDAs, téléphones portables, …) ;
• l’essor de nouveaux services de diffusion multimédia (Vidéoconférence, VoD, … ).

Le successeur naturel aurait pu logiquement être IPv5, mais cette version a été attribuée à un protocole expérimental : ST (Internet Stream Protocol) qui n’a jamais atteint le grand public. Le successeur fut donc choisi sous le nom de IPv6, également appelé IPng (IP Next Generation).

Les détails techniques du protocole s’appuient sur la RFC suivante:  [RFC3513].

II. Présentation d’IPv6

La différence majeure entre IPv4 et IPv6 est la taille des paquets, 32 bits pour IPv4 contre 128 bits pour IPv6. Cette modification est liée à la pénurie actuelle d’adresses IPv4. IPv6 augmente le nombre d’adresses disponibles, soit 667 millions de milliards d’adresses IP disponibles par mm² de la surface de la Terre.

On peut également notter les améliorations suivantes:

• Des mécanismes de configuration et de renumérotation automatique.
• IPsec, QoS et le multicast font partie de la spécification d’IPv6, au lieu d’être des ajouts ultérieurs comme en IPv4.
• La simplification des en-têtes de paquets, qui facilite notamment le routage.

Composition d’une adresse IPv6

128bits, découpés en 8 octets dans sa forme canonique, soit 39 caractères: 1fff:0000:0a88:85a3:0000:0000:ac1f:8001.
Une grande série de 0 peuvent êtres remplacés une seule fois dans l’adresse par deux “semicolon” (::) ce qui donne 1fff:0000:0a88:85a3::ac1f:8001.
la notation décimale pointée est autorisée uniquement pour les 2 derniers blocs représentant les 32 derniers bits de l’adresse IPv6. Ainsi l’adresse ci-dessus est équivalente à 1fff:0000:0a88:85a3:0000:0000:172.31.128.1

Différence entre les entêtes (headers) IPv4 et IPv6

Pour commenter ce schéma, voici la description des éléments de l’entête (header) IPv6:

• Version (4 bits) Toujours à 06, il représente le numéro de version du protocole Internet.
• Traffic Class (8 bits) Définie la priorité du datagramme pour la QoS.
• Flow Label (20 bits) Utilisé par une source lorsqu’un traitement spécial de la part des routeurs IPv6 est demandé. (optionnel)
• Payload Length (16 bits) Longeur des données qui suivent l’entête IPv6 en octet
• Next Header (8 bits) entête ou protocole qui suit (Ex: 88 -010011000 - EIGRP)
• Hop Limit (8 bits) TTL (Time To Live) similaire à IPv4
• Source Address (128 bits) Adresse IP source
• Destination Address (128 bits) Adresse IP de destination

Les différents types d’adresses IPv6

• Unicast - Communication vers un hôte
• Multicast - Communication vers plusieurs hôtes
• Anycast - Une adresse Multicast destinée à un seul membre d’un groupe Multicast

Les ranges spécifiques d’adresses IPv6

Méchanismes de transition IPv4 vers IPv6

Pendant la période de transition (actuelle) entre IPv4 et IPv6, il est nécessaire de pouvoir utiliser, (et ce pendant encore très longtemps) les deux types d’adresses.

Voici les principales méthodes

• ISATAP - [RFC 4214]
• TEREDO - [RFC 4380]
  
• Nat-PT - [RFC 4966]
  
• 6to4 tunneling - [RFC 3142]

ISATAP

ISATAP définit un méthode pour générer un lien local IPv6 depuis une IPv4, et un mécanisme pour la découverte des voisins IPv4.

TEREDO

TEREDO définit une méthode permettant d’accéder à l’Internet IPv6 derrière un équipement réalisant du NAT. Il consiste à encapsuler les paquets IPv6 dans de l’UDP sur IPv4 entre le client et le relais Teredo, avec l’aide d’un serveur Teredo.

6to4 Tunneling

Encapsulation d’une adresse IPv6 dans un tunnel IPv4.

Fonctionnement

Suivons le chemin d’un paquet IPv6 depuis un hôte derrière R1 vers un hôte après R2. Le paquet commence normalement son chemin avec une source IPv6 et une destination IPv6. Ces adresses ne changent pas durant le parcours du paquet.

R1 reçois le paquet IPv6 et compare la destination IPv6 dans sa table de routage IPv6.

R1# show ipv6 route
IPv6 Routing Table - 7 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
C   2001:DB8:0:1::/64 [0/0]
     via ::, Loopback0
L   2001:DB8:0:1::1/128 [0/0]
     via ::, Loopback0
S   2001:DB8:0:2::/64 [1/0]
     via 2002:A00:201::
S   2001:DB8:0:3::/64 [1/0]
     via 2002:A00:301::
S   2002::/16 [1/0]
     via ::, Tunnel0
LC  2002:A00:101::/128 [0/0]
     via ::, Tunnel0
L   FF00::/8 [0/0]
     via ::, Null0

Le meilleur chemin est la route statique pour 2001:db8:0:2::/64, le prochain saut est 2002:a00:201::.

Cela force un recursive lookup pour 2002:a00:201::. La meilleure route est Tunnel0.

C’est ici que l’on commence à jouer avec du 6to4. Le paquet IPv6 est routé dans le tunnel 0, il est encapsulé dans un paquet IPv4. L’adresse IPv4 source est celle du tunnel. La destination est calculée en fonction de l’adresse de destination 2001:db8:0:2::/64; 2002:a00:201:: est convertie en 10.0.2.1.

Le paquet encapsulé est routé en IPv4 jusqu’à R2. Le header IPv4 est retiré quand il entre sur l’interface 10.0.2.1 de R2. Le paquet IPv6 qui reste est routé jusqu’à l’hôte B.

Cet exemple se base sur un routage statique, notez que les protocoles de routage (EIGRP, OSPFv3..) ne peuvent être utilisés au travers de tunnels 6to4 car les adresses IPv6 de type ‘link-local’ (requises pour former les adjacences) ne sont pas supportées. Seul BGP peut-être utilisé ici.

Malgré le réseau NBMA (Non Broadcast Multi Access), les tunnels 6to4 sont quand même des tunnels, ils requièrent chacun une interface IN et OUT en IPv6; elles ne peuvent pas être utilisées pour faire communiquer directement les hôtes IPv4 vers IPv6.

• Cisco Unified Computing System (UCS): Data Center Virtualization Server Architecture - 36,22€
  
• I/O Consolidation in the Data Center: A Complete Guide to Data Center Ethernet and Fibre Channel over Ethernet - 29,97€
  
• CCDA Official Exam Certification Guide - 39,56€
  
• Authorized Self-Study Guide: Designing Cisco Network Service Architectures (ARCH) - 44,72€
  
• Mastering VMware vSphere 4 - 33,07€
  
• Data Center Networks and Fibre Channel over Ethernet (FCoE) - 6,67€

Si vous en avez d’autres à proposer, laisser les références en commentaire !

Vous pouvez visualiser ci-dessus les deux types d’architectures. L’architecture avec des serveurs physiques ainsi que l’architecture virtualisée.

La virtualisation apporte beaucoup de solutions pour le partage de charge, ou une amélioration de la haute disponibilité des applications. Néanmoins, elle apporte de nouveaux challenges technologiques :

• Les ports d’accès réseaux ne sont plus reliés à un unique VLAN mais deviennent des liens de Trunk 802.1q vers un certain nombre de VLANs.
• Le vSwitch (Virtual Access Switch) est maintenant géré par les équipes d’ingénieurs systèmes.
• Les équipes d’ingénieurs réseaux perdent en visibilité sur le trafic des machines virtuelles.

Ce schéma est d’autant plus complexe à mettre en place et troubleshooter.

De plus, les possibilités les plus novatrices de la virtualisation sont les améliorations qui stressent le plus le réseau :

• vMotion transporte les machines virtuelles au travers de différents ports physiques.
• Le réseau n’a aucune visibilité sur la provenance du trafic applicatif.
• Les serveurs doivent maintenant s’occuper du réseau. Chaque ESX équivaut à un vSwitch.
• Les règles et configurations doivent suivre les vlans, acls..

Le facteur à prendre en compte ici est l’insertion du réseau vers la partie applicative avec les vSwitchs, et le rapprochement du système vers le réseau. Ces rapprochements nécessitent donc des rapprochements entre les équipes d’ingénieurs systèmes et réseaux afin de travailler ensemble dans la définition des besoins et la mise en place de l’architecture du système d’information d’une entreprise.

Voyez-vous d’autres problématiques pour suivre cette réflexion ? n’hésitez pas à commenter !

You can view above two types of architectures. The architecture with physical servers and virtualized architecture.

Virtualization provides many solutions for load sharing,  or improved application availability.
Nonetheless, it brings new technological challenges:

• The network ports are not connected to a single VLAN but become 802.1q Trunk links to a number of VLANs.
• vSwitch (Virtual Switch Access) is now managed by teams of systems engineers.
• The teams of network engineers have a weak of visibility into the traffic in virtual machines.

This pattern is even more complex to implement and troubleshoot.

In addition, most innovative possibilities of virtualization are improvements that stress the more the network:

• VMotion VMs carries through different physical ports.
• The network has no visibility from the application traffic.
• Servers must now deal with the network. Each ESX equivalent to a vSwitch.
• The rules and configurations must follow the vlans, acl ..

Factor to consider here is insertion of the network towards the application with the vSwitch and the mix between the system and the network. These comparisons therefore require reconciliations between the systems engineering teams and networking teams to work together in identifying needs and implementing the system architecture of an enterprise’s IT.

Do you see some others problematic to improve this reflexion? Feel free to comment !

Je suis déjà entré en contact avec quelques CCIE blogueurs (que je remercient déjà fortement) afin qu’ils me donnent des pistes de recherches mais il m’en faut encore afin de peaufiner mon plan et prévoir mes recherches pour la rédaction du mémoire cette année.

J’en profite pour féliciter Greg Ferro pour le podcast PacketPushers car ils ont été la source d’inspiration pour ce mémoire. Et les podcasts 2011 devraient être dans la même lignée que 2010 : “In 2011, we’re keeping it nerdy. We’re planning more dialog with the virtualization folks, discussions about data center design, deep dives on ubergeek network issues, and chats with vendors about their products. We’ll also keep bringing on the most interesting bloggers, tweeters, and socially “out there” networking folks we can find.”.

Si vous êtes en train de lire cet article et que vous êtes un professionnel, vous travaillez chez Cisco, ou vous êtes un architecte réseau ayant des connaissances sur l’évolution que sont en train de connaitre les Data Center suite à la Virtualisation système. N’hésitez pas à laisser un commentaire ou à m’envoyer un mail (postmaster@networklife.net) avec les axes que vous pensez bon de développer dans ce mémoire, mais aussi les livres à lire absolument sur ce sujet !

Merci d’avance pour votre aide !
Cette année, les articles du blog devraient êtres orientés Virtualisation réseau !

Data Center Virtualization. Here’s the title I expected to give for my Master thesis. It can still evolve, but that title is already causing great topic that I want to develop. I have not much knowledge in the Data Center area, but I’d like to develop my skills about it this year while preparing my thesis.

I’ve already contacted some CCIE bloggers (which I thanks a lot) who gave me some research, but I need to refine my plan and plan my research for the year.

I thanks Greg Ferro for the PacketPushers podcast as it’s a great inspiration for this thesis subject.  The 2011 podcasts should be in the same vein as 2010 : “In 2011, we’re keeping it nerdy. We’re planning more dialog with the virtualization folks, discussions about data center design, deep dives on ubergeek network issues, and chats with vendors about their products. We’ll also keep bringing on the most interesting bloggers, tweeters, and socially “out there” networking folks we can find.”.

If you’re reading this article and are a professional, you work at Cisco, or you’re a network architect with knowledge about the Data Center Virtualization. Feel free to leave a comment or send me an email (postmaster@networklife.net) with the axes you think good to develop into this thesis, and also the must-read books on the subject.

Thank you in advance for your help!
This year, the blog posts should be Network Virtualization oriented!

Cisco CCNA Wireless - Chapter 10 Cisco Wirelss Networks Architecture

La solution CUWN (Cisco Unified Wireless Network)
Basée sur un modèle de contrôle centralisé.

5 aires de fonctionnalités (élèments)

• Wireless clients
• Access Points
• Network unification
• Network management
• Network services

Les bornes dans le CUWN
Les bornes légères sont contrôlées et monitorées par le WLC (Wireless LAN Controller).
Les bornes communiquent grâce au protocole LWAPP (Lightweight AP Protocol) pour relayer l’information au WLC à propos de la couverture, les interférences, les données du client a propos de l’association, et d’autres infos.
C’est une communication de management, et c’est encrypté dans le tunnel LWAPP.
Les données sont également envoyées dans le tunnel LWAPP. Les données clientes transitent depuis le client vers la borne et jusqu’au WLC puis vers le reste du réseau.
Quand la donnée est encapsulée dans un header LWAPP, il n’y a pas que la donnée, mais également des informations RSSI (Received Signal Strength Indicator) et SNR (Signal/Noise rate). Le WLC utilise ces informations pour prendre des décisions pour améliorer la couverture.

WLC et CUWN
Un simple WLC peux gérer de 6 à 300 bornes. On peux créer des groupes de contrôleurs.
On peux également créer des groupes de contrôleurs dans le cas ou il y à plus de 300 AP.

Important: Dans CUWN, une AP utilise LWAPP pour échanger des messages de contrôle avec le WLC.

Fonctionnalités d’un contrôleur Cisco
Un des design du WLC est le “Split MAC design”. On peux diviser 802 protocoles entre le contrôleur et les bornes. D’un coté, les bornes gèrent le temps-réel et les paquets sensibles au temps. De l’autre coté, le contrôleur gère les paquets non sensibles au temps.

Les bornes gèrent les opérations suivantes:

• Échangede trames et vérification entre clients
• Transmet les beacons
• Met en buffer et retransmet les trames pour les clients qui sont en mode économie d’énergie
• Envoi des réponses aux “probe requests” depuis différents clients du réseau
• Retransmet les notifications des probes request au contrôleur
• Fournis des informations temps-réel au contrôleur
• Monitor les canaux pour le bruit et les interférences

Le contrôleur gère tout le reste:

• Association
• Réassociation pendant le roaming
• Processus d’authentification
• Traduction des trames
• Pont pour les trames

Une part du trafic envoyé via LWAPP fournis des infos RRM (Radio Ressource management). Ce moteur RRM monitor les ressources radio, effectue de l’assignation automatique de canaux, détecte et préviens les interférences, fournis du TPC (Transmit Power Control).

LWAPP Peux opérer dans 2 modes :
• Layer 2 LWAPP mode : Basé sur les adresses MAC. Dans ce mode, la borne doit être dans le meme sous-réseau que le contrôleur. Pas très flexible.
• Layer 3 LWAPP mode : Dans ce mode, le LWAPP peux voir et utiliser les adresses L2 et L3. Permet à l’administrateur réseau de placer les AP dans différents sous-réseaux.

Architecture CUWN

Le CUWN définis 5 aires de fonctionnalités (éléments interconnectés). Chacun des éléments travaillent ensembles.

• Wireless clients
  • Cisco Aironet client
  • Cisco-compatible client (pas nécessairement du cisco)
  • Cisco Secure Services Client (SSC)
• Access Points (bornes)
  • 1130AG
  • 1240AG
  • 1250AG
  • 1300 series bridge
  • 1400 series bridge
  • 1500 series outdoor mesh
• Network unification (controleûrs)
  • The 6500 series Catalyst switch Wireless Services Module (WiSM)
  • Cisco Wireless LAN Controller module (WLCM)
  • Cisco Catalyst 3750 series integrated WLC
  • Cisco 4400 series WLC
  • Cisco 2000 series WLC
• Network management
  • WCS
  • WCS Navigator
  • Vérification
• Network services
  • Support des routeurs, Switch, IDS, ASA, PIX..

Access points (bornes)
Deux types:

• Bornes lourdes (autonomes)
• Bornes légères

Wireless LAN Contrôleur
Le design du WLC est fait pour l’évolutivité. La communication entre les bornes légères peut intervenir entre n’importe quel type d’infrasctucture L2/L3 en utilisant LWAPP.

Wireless Network Management
Dans les très grands réseaux, un simple contrôleur n’est pas assez pour gérer toute les AP. Ce type de scénario peut faire appel au Cisco WCS, un Single Point Of Management pour plus de 3000 Bornes légères et 1250 bornes autonomes.
Le WCS tourne sous Windows ou Red Hat.
Pour évoluer au travers des 3000 bornes, on devrait utiliser le navigateur WCS. C’est un manageur de manageur… On peut l’utiliser pour naviguer au travers de différent serveurs WCS. On peut donc le faire évoluer à +de 3000 bornes.
On peux également utiliser WLA (Wireless Location Appliance). Il à été créer pour rechercher l’emplacement exact d’équipements Wifi et de Tags RFID. Il peut localiser des milliers d’équipements.

Chapitre 11 - Controller Discovery & Association

Comment font les bornes pour trouver leurs contrôleur? Choisir de s’associer à lui? Retrouver leurs configuration?.. Etc. Redondance dans le cas ou le contrôleur tombe en panne.

Les différents modes LWAPP
- L2

- L3

Découverte d’un contrôleur en LWAPP (Discovery Mode)

1. L’AP envoi un Brodcast L2 appellé LWAPP Discovery message au WLC. Il devrait aboutir à une erreur étant donnée que l’on veux utiliser du L3.
2. Si une erreur arrive, la borne procède à la couche 3 en cherchant une adresse IP dans sa configuration. Si il n’y en à pas, la borne commence le processus DHCP pour en avoir une.
3. La borne utilise les informations obtenu via les requetes DHCP pour contacter le contrôleur.
4. Tout contrôleur WLC recevant un LWAPP Discovery message répond avec un “LWAPP discovery response” messsage. Si aucun controleur ne répond, la borne recommence le processus à l’étape 1.

Choix d’un contrôleur et association en LWAPP (AP Join State)

Un message “join request message” contiens:

• Le type de controleur
• La MAC du controleur
• AP hadware version
• AP software version
• AP name
• Nombre et types de radio
• Certificate playload (x.509)
• Session playload pour mettre en place les valeurs de sessions
• Test playload pour voir si les Jumbo Frames passent ou pas

1. Une borne choisis un contrôleur primaire
   (en GUI - Wireless > Access Point > All Aps > SelectedAP > Details)
2. Choisis le contrôleur secondaire
3. Si aucune information disponible, agit en tant que master.
   (Définir un contrôleur Master: Controller > Advanced > Master Controller Mode )
4. Quand rien ne marche, regarder l’AP manager le moins chargé en se basant sur le nombre de bornes qu’il gère.

Quand le contrôleur reçoit un message, il répond avec un Join Reply Message.
Avec :

• Le code de resultat (la LED verte qui dit qu’elle peut communiquer)
• Le certificat du controleur
• Test playload pour les Jumbo Frames

La borne est maintenant associée au controleur.

Réception de la configuration en LWAPP (Image Data (Synch OS))
Après l’association, vérification de l’image du controleur et de la borne. Si ce sont les memes, l’image est utilisée. Dans l’autre cas, le controleur upgrade ou downgrade la borne et la reset pour refaire le meme processus.
Quand les images sont enfin les mêmes , la borne récupère sa configuration (Config Data).

AP ===== >LWAPP configure request message ===> CONTROLLEUR
AP <==== Configure response message <==== CONTROLLEUR

Redondance pour les AP et contrôleurs

Controleur redundancy

1e méthode : Chaque WLAN à un contrôleur différent. Primary, secondary, tertiary.
2e méthode : Link aggregation (LAG) ou Multiple AP manager.
3e méthode : Port Primary / Backup sur le controleur.

Design :
N + 1 = un seul backup pour plusieurs contrôleurs.
N + N = Chaque controleur backup l’autre.
Ex: AP1 : WLC1 Primary / WLC2 Secondary
AP2 : WLC3 Primary / WLC1 Secondary
N + N + 1 =Chaque contrôleur backup l’autre, et un autre contrôleur est désigné en backup.

<u>Différents modes d’AP</u>:

• Local
  • Mode normal. La borne scanne les canaux en 180 secondes pour le monitoring, et fait de l’IDS.
  • Quand l’AP scanne les canaux, elle saute les canaux toutes les 60ms puis reste sur son canal assigné pendant 13 secondes pour monitorer le trafic.
• Monitor
  • Mode passif. Cherche juste les Rogue AP ou des IDS match, troubleshooting, site survey.
  • Peut-être utilisé avec le WLA pour augmenter la précision
• Sniffer
  • Ce mode foncitonne avec OmniPeak, AirMagnet, ou Wireshark Server pour capturer de la donnée.
  • L’encapsulation est spécifique au produit utilisé
• Rogue Detector
  • Communique les rogue AP informations entre WLC. La radio est éteinte et écoute les messages
  • ARP sur le réseau cablé. Compare les infos MAC entre le rogue AP et une MAC list.
  • Si une requête ARP est entendu sur le LAN cablé, le contrôleur génère une alarme.
• Hybrid REAP
  • Utilisé quand on a des bornes au travers d’un WAN et que l’on veux utiliser le controleur d’un site central.
  • Le liens doit être supérieur à 128kbps.
  • Roundtrip latency supérieure a 100ms roundtrip
  • La borne doit recevoir un update de code de 4Mb au travers du lien WAN.
  • Ensuite la borne peux fonctionner en monde :
    • connecté - communique avec le controleur
    • standalone - déconnectée du controleur. Configuration locale sur l’AP. Supporté avec les AP 1130, 1240 et 1250.
• Bridge
  • Pont qui permet l’accès aux clients. PPP ou PTM link. Pour déterminer le meilleur chemin, la borne utilise le protocole AWPP (Adaptive Wireless Path Protocol).

Chapter 13 - Simple Network Configuration & Monitoring with de Cisco Controller

Interface
Avec un routeur, elle peut etre logique ou physique.
Avec un contrôleur, l’interface est logique. Incluant les VLANs, qui ont un port associé. Certaines interfaces sont statiques car le contrôleur doit toujours les avoir.

Port
Interface physique du controleur.

WLAN = SSID + ses paramètres.
Un WLAN est lié à un port.

Un port lie ensembles un WLAN et un VLAN. Le Cisco Wreless Service Manager (WiSM) à 8 ports virtuels.
Certaines interfaces sont statiques, d’autres virtuelles. Certaines interfaces statiques ne peuvent être retirées a cause de leurs usage spécifique :

• Management
• AP-Manager
• Service port
• Virtual

Connexion au contrôleur
CLI Access avec le câble console. On peut observer la séquence de boot et démarrer une configuration simple. Cette configuration permettra d’accéder au contrôleur via l’interface HTML.

Boot sequence:

Bootloader 4.1.171.0 (Apr 27 2007 - 05:19:36)
Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
CPU: 833 MHz
CCB: 333 MHz
DDR: 166 MHz
LBC: 41 MHz
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready
DTT: 1 is 20 C
DRAM: DDR module detected, total size:512MB.
512 MB
8540 in PCI Host Mode.
8540 is the PCI Arbiter.
Memory Test PASS
FLASH:
Flash Bank 0: portsize = 2, size = 8 MB in 142 Sectors
8 MB
L2 cache enabled: 256KB
Card Id: 1540
Card Revision Id: 1
Card CPU Id: 1287
Number of MAC Addresses: 32
Number of Slots Supported: 4
Serial Number: FOC1206F03A
Unknown command Id: 0xa5
Unknown command Id: 0xa4
Unknown command Id: 0xa3
Manufacturers ID: 30464
Board Maintenance Level: 00
Number of supported APs: 12
In: serial
Out: serial
Err: serial
.o88b. d888888b .d8888. .o88b. .d88b.
d8P Y8 `88’ 88’ YP d8P Y8 .8P Y8.
8P 88 `8bo. 8P 88 88
8b 88 `Y8b. 8b 88 88
Y8b d8 .88. db 8D Y8b d8 `8b d8’
`Y88P’ Y888888P `8888Y’ `Y88P’ `Y88P’
Model AIR-WLC4402-12-K9 S/N: FOC1206F03A
Net:
PHY DEVICE : Found Intel LXT971A PHY at 0x01
FEC ETHERNET
IDE: Bus 0: OK
Device 0: Model: STI Flash 8.0.0 Firm: 01/17/07 Ser#: STI1M75607342054704
Type: Removable Hard Disk
Capacity: 245.0 MB = 0.2 GB (501760 x 512)
Device 1: not available
Booting Primary Image...
Press  now for additional boot options...
***** External Console Active *****
Boot Options
Please choose an option from below:
1. Run primary image (version 4.1.192.17) (active)
2. Run backup image (version 4.2.99.0)
3. Manually update images
4. Change active boot image
5. Clear Configuration

Tapez 1 pour démarrer sur l’image primaire. Quand l’interface HTML est accessible, on peut upgrader le code sur le conrtoleur.

Initial CLI configurations:

Welcome to the Cisco Wizard Configuration Tool
Use the ‘-’ character to backup
System Name [Cisco_32:af:43]: WLC_1
Enter Administrative User Name (24 characters max): admin
Enter Administrative Password (24 characters max): *****
Re-enter Administrative Password : *****
Service Interface IP Address Configuration [none][DHCP]: 10.1.1.1
Invalid response
Service Interface IP Address Configuration [none][DHCP]: none
Service Interface IP Address: 10.1.1.1
Service Interface Netmask: 255.255.255.0
Enable Link Aggregation (LAG) [yes][NO]:
Management Interface IP Address: 192.168.1.75
Management Interface Netmask: 255.255.255.0
Management Interface Default Router: 192.168.1.1
Management Interface VLAN Identifier (0 = untagged):
Management Interface Port Num [1 to 2]: 1
Management Interface DHCP Server IP Address: 192.168.1.1
AP Transport Mode [layer2][LAYER3]:
AP Manager Interface IP Address: 192.168.1.80
AP-Manager is on Management subnet, using same values
AP Manager Interface DHCP Server (192.168.1.1):
Virtual Gateway IP Address: 1.1.1.1
Mobility/RF Group Name: CP_Mobile1
Enable Symmetric Mobility Tunneling [yes][NO]: no
Network Name (SSID): OpenAccess
Allow Static IP Addresses [YES][no]:
Configure a RADIUS Server now? [YES][no]:
Enter the RADIUS Server’s Address: -
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 list (enter ‘help’ for a list of countries) [US]:
Enable 802.11b Network [YES][no]:
Enable 802.11a Network [YES][no]:
Enable 802.11g Network [YES][no]:
Enable Auto-RF [YES][no]:
Configuration saved!
Resetting system with new configuration...
Configuration saved!
Resetting system with new configuration...
Bootloader 4.1.171.0 (Apr 27 2007 - 05:19:36)
Motorola PowerPC ProcessorID=00000000 Rev. PVR=80200020
CPU: 833 MHz
CCB: 333 MHz
DDR: 166 MHz
LBC: 41 MHz
continues
234 CCNA Wireless Official Exam Certification Guide
L1 D-cache 32KB, L1 I-cache 32KB enabled.
I2C: ready`
DTT: 1 is 31 C
DRAM: DDR module detected, total size:512MB.
512 MB
8540 in PCI Host Mode.
8540 is the PCI Arbiter.
Memory Test PASS

Une fois que le controleur à rebooté, on entre les identifiants demandés.

Enter User Name (or ‘Recover-Config’ this one-time only to reset configuration
to factory defaults)
User: admin
Password:*****
(Cisco Controller) >

Sauvegarder la configuration:

(Cisco Controller) >save config
Are you sure you want to save? (y/n) y
Configuration Saved!
(Cisco Controller) >

La plus grosse partie des configuration Cisco pour le Wifi se fait en Web, le CLI est vraiment dure à prendre en main par rapport aux routeurs/Switchs.

Sources :

• http://www.cisco.com/en/US/docs/wireless/technology/controller/deployment/guide/dep.html
• http://www.ciscopress.com/bookstore/product.asp?isbn=1587202115
• Wireless LAN Controller WLC-5508
• Wireless LAN Controller (WLC) FAQ

Fondamentaux des WLAN
Par quel moyen la bande passante est-elle retransmise sur des radiofréquences?

IEEE 802.11 décrit les opérations half-duplex en utilisant la même fréquence pour l’envoi et la réception.
Pas de licence requise pour utiliser les standards 802.11, mais on doit respecter les règles du FCC.

FCC -> Etats-Unis Federal communications commission
ETSI -> European Télécommunications Standards Institute

Le FCC Gère:

• les fréquences qui peuvent être utilisées sans licences,
• les puissances qui peuvent être utilisés sur les équipements,
• les technologies de transmissions,
• les endroits géographiques où l’on peut déployer du Wifi

Pour transmettre de la BW sur des RF (radiofréquences), vous devez envoyer les données sous forme de signaux electriques en utilisant certaines méthodes d’émissions.
Ex d’émission : “Spread Spectrum” - Authorisé par le FCC en 1986 sur le marché commercial.

Modulation : Ajout d’une donnée à un signal de transmission.

Ex: pour envoyer de la musique à la radio, on utilise les ondes FM (Frequency modulation) / AM (Amplitude modulation).

! Quand on parle de Bandwidth pour du Wifi, on réfère à la largeur du canal RF, et non au taux de transfert de donnée. !

Usable Frequency Bands in Europe, the United States, and Japan

900 MHz
De 902 MHz à 928 MHz. Le plus utilisé, avec les téléphones sans fil.

2.4 GHz
Le plus utilisé pour les WLAN.
Utilisé par le 802.11, 802.11a, 802.11b, 802.11g et 802.11n IEEE.
Subdivisé en canaux de 2.4000 à 2.4835 GHz.
Les US ont 11 canaux, chacun recouvre 22-MHz. Quelques canaux se recouvrent et provoquent des interférences. C’est pour cela que les canaux 1, 6 et 11 sont les plus utilisés.

802.11b et 802.11g => bandwidth de 22 MHz. Cela permet 3 canaux dans le même secteur qui pourront ne pas se recouvrir et interférer.

Le range des 2.4 GHz utilise la modulation DSSS (Direct Sequence Spread Spectrum).

5 Ghz
Le range des 5 Ghz est utilisé par le 802.11a et le nouveau 802.11n.
En 802.11a, les taux de transmissions peuvent atteindre 6 à 54Mbps.
Ce range est subdivisé en 23 Canaux qui ne se recouvrent pas, chacun d’une longueur de 20 MHz.
Techniques de modulations et comment elles fonctionnent.
La modulation est le processus de variance sur le signal appelé Carrier Signal (signal de transport). La data est ensuite ajouté au signal de transport dans le processus d’encodage.
La modulation permet l’envoi de données encodée en utilisant les signaux radios. Les réseaux Wireless utilisent la modulation en tant que signal de transport, ce qui veux dire que les tonalités modulées transportent la donnée.

Une onde modulée consiste en 3 parties:

Les différents techniques de modulation:

• DSSS
• OFDM
• MIMO (Multiple-Input Multiple-Output)
• DSSS

Utilisé par 802.11b pour envoyer les données.

Pour encode les données avec DSSS, on utilise une “chip sequence”. Un chip et un bit sont essentiellement la même chose, mais un bit représente la donnée et le chip est utilisé pour l’encodage du signal.

Chipping codes:
A cause des interférences possibles dans les transmissions Wireless, DSSS utilise une séquence de chips.

Quand DSSS diffuse des information au travers des ranges de fréquences, il envoi un simple bit de donnée sous forme de phrase de chips. Avec une donnée redondante envoyée, si une partie du signal est perdu, la donnée peut quand même être comprise. Le chipping code prend chaque bit et l’étend en une phrase de bits.

Chipping séquence:

Barker Code: ( pour les taux de 1 à 11Mbps )
Pour transmettre des taux de 1, 2Mbps, 802.11 utilise un “Barker Code”. Ce code définis l’utilisation des 11 chips qui encodent la donnée.

Complementary code keying: (pour les taux de 11 à 54 Mbps)
Quand on utilise DSSS, le barker code fonctionne bien pour de faible taux de transmission, jusqu’à 11Mbps. DSSS utilise des methodes permettant de transmettre jusquea 54Mbps. CCK (Complementary code keying) utilise une serie de codes appelés des séquences complémentaires. Ce sont des phrases uniques. 6 bits peuvent etre représentés par un mot, contrairement au 1bit représenté par le barker code.

DSSS Modulation Techniques & encoding:
Maintenant que la donnée est encodée (Barker Code ou CCK) elle doît être transmise ou modulée au travers des antennes radio.
L’encodage - comment les changements dans les signaux RF se transforment en 1 et 0.
Modulation - caractéristique du signal RF est manipulé.

4 Switchs 3750 Series interconnectés via StackWise

Insertion du câble Stackwise

• Une boucle fermée bidirectionnelle est formée entre les Switchs.

Boucle fermée bidirectionelle (32Gbps)

• Une pile de switch à une adresse IP unique et est gérée en tant qu’objet unique.
• Chaque pile à un fichier de configuration unique qui est distribué à tous les membres de la pile.
• Un pile peut contenir jusqu’à 9 switchs.
• Un switch peut être ajouté/retiré “à chaud” sans interrompre le fonctionnement de la pile.

Election du switch Master
Le switch Master crée automatiquement les tables de switching et de routage et les mets à jour. Chaque membre de la pile peut devenir master. Après l’installation, ou le reboot de la pile, un processus d’élection intervient pour désigner le Master. il y à plusieurs critères de sélection.

1. User priority- L’administrateur peut désigner un switch manuellement en tant que master.
2. Hardware and software priority- Cisco Catalyst 3750 Advanced IP Services IPv6 (AIPv6) à la plus haute priorité, suivi du Cisco Catalyst 3750 switches with Enhanced Multilayer Software Image (EMI) et ensuite, les Standard Multilayer Software Image (SMI) versions.
3. Default configuration- Si un switch à déjà des informations de configuration, il prendra le dessus sur les switchs qui ne l’ont pas été.
4. Uptime- Le switch allumé depuis le plus longtemps.
5. MAC address- Chaque switch comparent leurs adresses MAC. La plus petite adresse MAC est sélectionnée MASTER.

Vérification des ports

3750-Stk#show switch stack-ports

  Switch #    Port 1       Port 2
  --------    ------       ------
     1          Ok           Ok
     2          Ok           Ok
     3          Ok           Ok

Visualisation des voisins

3750-Stk# show switch neighbors

  Switch #    Port 1       Port 2
  --------    ------       ------
      1         2            3
      2         1            3
      3         2            1

Visualisation du stack

3750-Stk>show switch
                                               Current
Switch#  Role      Mac Address     Priority     State
--------------------------------------------------------
 1       Slave     0016.4748.dc80     5         Ready
*2       Master    0016.9d59.db00     1         Ready

Pour changer le numéro du switch dans la pile:

3750-Stk(config)#switch current-stack-member-number  renumber new-stack-member-number .

Pour changer la priorité du switch dans la pile

3750-Stk(config)#switch stack-member-number priority new-priority-value .

Le switch avec la plus haute priorité est censé être le Master.

Les IOS de vos switchs sont censé être les mêmes, dans le cas contraire, vous pouvez vérifier la version de votre “Stack Protocol” comme ceci:

3750-Stk# show platform stack-manager all
                                               Current
Switch#  Role      Mac Address     Priority     State
--------------------------------------------------------
 1       Slave     0016.4748.dc80     5         Ready
*2       Master    0016.9d59.db00     1         Ready

!--- output ommited

                 Stack State Machine View
==============================================================

Switch   Master/   Mac Address          Version    Uptime   Current
Number   Slave                          (maj.min)            State
---------------------------------------------------------------------
1        Slave     0016.4748.dc80          1.11        8724    Ready
2        Master    0016.9d59.db00          1.11        8803    Ready

Création d’une pile, à partir de deux switchs.

1. Switch-A and Switch-B sont connectés ensembles.

–

2. Election du master entre Switch-A et Switch-B; On considère que le switch B gagne.

–

3. Switch-A redémarre alors, et rejoint la pile.

–

–

4. Le numéro de membre du Switch-A va changer. il va choisir le nombre le plus petit possible, dans notre cas, le nombre “2″.

Packet Pushers is a weekly podcast about the networking industry. The concept is to put some CCIE engineers together to speak about their work , actuality of the networking industry and some networking related topics (routing, switching, security, firewalls, study and market changes). These podcasts are really interesting/formative for persons who work into networking industry, or persons like me, who are studying, and need some experts reviews.

One of the most interesting podcast for students is this one : Show 4 - The interview process.
In this one, Greg interview Marko by answering technology and personal questions, he deconstruct his answers and look at how his responses would have affected his chances. I recommend this one to prepare yourself !

The last issue Show 8 - Something on the light side seems nice too, with the great Jeremy Stretch from PacketLife, Amy Arnold, Greg Ferro as well, and Ethan banks. Great bunch of experts. I haven’t listened it yet (I need much more time to understand the entire record in english..)

Nice work then, I hope Greg and his experts will continue this great podcast for a long time!
And don’t forget, too much networking would never be enough ^^