Surcharger le DNS utilisé par dhclient

La configuration DNS sous UNIX est située dans le fichier /etc/resolv.conf. Dans une configuration classique pour un serveur ce fichier est statique. Il est créé lors de la première installation en se référant au paramétrage spécifié dans l'installeur. Pour une configuration dynamique en DHCP, généralement un client, c'est le binaire dhclient qui va s'occuper de modifier les lignes de configuration afin de mettre les DNS reçus via DNS ainsi que les zones de recherches et suffixe DNS. Le principal problème que nous allons essayer de résoudre ici est essentiellement une problématique de type cloud. Sur un cloud de type AWS nos serveurs sont tous en DHCP, c'est obligatoire. Pour prendre le cas pratique AWS, gérer son DNS sans serveur local consiste à configurer le service route53 avec ses enregistrements, soit via l'interface, awscli ou encore ansible. Si jamais on souhaite pouvoir interagir avec des DNS personnalisés ce n'est donc pas possible facilement, dhclient remplaçant automatiquement le fichier /etc/resolv.conf à chaque interrogation.

Résolution de la problématique

dhclient contient fort heureusement certaines options de configuration nous permettant de gérer le cas d'un DNS statique avec une IP dynamique, ce sont les directives prepend, append et supersede. Ces options permettent d'ajouter avant (prepend), après (append), ou de remplacer (supersede) des options DHCP reçues par le client avant d'interagir avec le système. Vous pouvez donc avoir 2 cas d'usages intéressants. La configuration suivante sera à insérer dans le fichier /etc/dhcp/dhclient.conf.

1. Remplacer le DNS obtenu par un DNS personnalisé

La directive supersede permet de remplacer complètement les DNS obtenus via DHCP

supersede domain-name-servers 172.0.14.1, 172.0.14.2;
supersede domain-name-servers 172.0.14.1, 172.0.14.2;

2 Utiliser un DNS personnalisé par défaut et les DNS obtenus en fallback

On va ici utiliser la directive prepend, nous permettant d'utiliser les DNS obtenus via DHCP uniquement en cas d'erreur d'accès à nos DNS personnalisés

prepend domain-name-servers 172.0.14.1, 172.0.14.2;

Note: Un effet de bord d'usage de ces directives, vous pouvez ainsi spécifier des DNS si votre DHCP n'en fournit pas.

Conclusion

Lors de la prochaine requête DHCP votre fichier resolv.conf sera ainsi configuré pour contenir les 2 serveurs DNS spécifiés dans dhclient.

Bonus

Puisqu'automatiser est très important, voici quelques lignes de configuration ansible à intégrer à vos rôles d'uniformisation des socles applicatifs

- name: "DHCLIENT | Set static nameservers"
  lineinfile: dest="/etc/dhcp/dhclient.conf" line="supersede domain-name-servers {{ dns_servers | join(', ') }};" state=present
  when: dns_servers is defined
  tags: [dhcp]

Relai DHCP sous Debian

Le relai DHCP permet d'isoler son serveur DHCP autoritaire du réseau de ses clients.

Que le serveur DHCP soit sous UNIX ou sur un OS propriétaire (ce qui est dommage), le relai DHCP va permettre aux clients d'interroger un DHCP en utilisant ce relai comme proxy.

Un relai DHCP est un outil très simple utilisant un système ajoutant le réseau source (connu par le relai DHCP) et un nombre de sauts (utile si vous souhaitez chaîner plusieurs relais DHCP, mais non recommandé en terme de latence).

Installation

Installez le paquet isc-dhcp-relay.

apt-get install isc-dhcp-relay

Configuration

Bien que le prompt isc-dhcp-relay vous offre la possibilité de configurer directement le service, nous allons le configurer manuellement. Ouvrez le fichier /etc/default/isc-dhcp-relay

Editez ensuite la ligne SERVERS afin d'ajouter une liste de serveurs DHCP autoritaires et la ligne INTERFACES afin de spécifier les interfaces sur lesquelles votre DHCP va écouter.

SERVERS="10.1.1.1 10.1.1.2"
INTERFACES="eth0 eth1 eth45 vlan5 bond0"

Relancez ensuite le service isc-dhcp-relay

service isc-dhcp-relay restart

UCARP

Introduction

UCARP est une implémentation alternative au protocole VRRP de FreeBSD et CISCO. Il permet de mettre en place un IP failover (autrement dit la redondance de service pour la haute disponibilité). De ce fait, grâce à UCARP, si vous avez un serveur redondé de votre serveur IMAP et SMTP, si le principal vient à tomber, la définition même d'UCARP permettra à votre réplicat de prendre le relai jusqu'à ce que le maître revienne à la normale.

Ce tutoriel aura pour but de définir comment mettre en place le failover. Pour la synchronisation des données, consultez les tutoriaux appropriés sur notre site ou Internet. Veuillez juste noter que si votre synchronisation est une synchronisation de type maître -> esclave et non maître <-> esclave vous risquez de perdre des données qui se retrouveraient uniquement sur le réplicat lors de la remise en service du serveur maître.

Le principe d'UCARP est le partage d'une adresse IP et adresse MAC sur le réseau. Nous allons ici étudier le principe UCARP sous Debian.

Fonctionnement du protocole

La protocole (U)CARP utilise une surcouche sur la configuration de vos cartes réseau. Il s'incorpore chaque réplicat associé à un service donné.

Toutes les x secondes il va envoyer une trame multicast afin d'avertir qu'il utilise le protocole VRRP/UCARP sur tel ID et tel priorité. cette priorité définit sur un degré de 1 à 255 quel sera le serveur qui répondra avant les autres et sera le réplicat du moment.

Lorsque le serveur maître ou un serveur de plus haute priorité est de retour, le serveur rend alors l'adresse IP à celui-ci, permettant ainsi de garantir la bonne gestion du service.

Configuration du fichier d'interfaces

Ouvrez le fichier /etc/networks/interfaces. Sur notre serveur maître:

iface eth1 inet static
         address 192.168.1.150
         netmask 255.255.255.0
##############################
##### UCARP Configuration #####
ucarp-vid        1
ucarp-vip        192.168.1.250
ucarp-password   unix-experience
ucarp-advskew    1
ucarp-advbase    1
ucarp-master     yes

# Interface Carp en tant qu'alias de eth1
iface eth1:ucarp inet static
         address 192.168.1.250
         netmask 255.255.255.0

Sur notre serveur esclave :

iface eth1 inet static
         address 192.168.1.160
         netmask 255.255.255.0
##############################
##### UCARP Configuration #####
ucarp-vid        1
ucarp-vip        192.168.1.250
ucarp-password   unix-experience
ucarp-advskew    1
ucarp-advbase    2
ucarp-master     no

# Interface Carp en tant qu'alias de eth1
iface eth1:ucarp inet static
         address 192.168.1.250
         netmask 255.255.255.0

Description des champs

vid

L'identifiant Virtual Host ID. C'est un numéro unique utilisé pour identifier le groupe de redondance parmi les autres groupes, et pour distinguer les différents groupes sur un même réseau. Les valeurs acceptables vont de 1 à 255. Elles doivent être identiques sur chacun des membres du groupe.

vip

Virtual IP est l'adresse virtuelle que ce partagerons le maître et l'esclave.

password

Le mot de passe d'authentification à utiliser lors de la communication avec d'autres hôtes CARP dans le même groupe de redondance. Ce mot de passe doit être partagé entre tous les membres du groupe.

advbase

Ce paramètre optionnel spécifie le nombre de secondes qui s'écoule entre chaque annonce CARP. La valeur par défaut est 1 seconde. Les valeurs acceptables sont de 1 à 255.

advskew

Ce paramètre optionnel spécifie le biais à introduire au niveau de advbase lors de l'envoi d'annonces CARP. En manipulant advskew, l'hôte maître CARP peut être choisi. Plus grand est ce nombre, moindres sont les chances pour que l'hôte soit retenu lorsqu'un maître est choisi. La valeur par défaut est 0. Les valeurs acceptables sont de 1 à 254.

Cette configuration est active lors de l'initialisation du réseau au démarrage ou avec la commande "service networking restart".

Exemple de situation de failover

Soit un serveur maître d'IP 192.168.1.150 et un serveur esclave d'IP 192.168.1.160 et une IP commune en 250.

Si vous avez paramétré comme il faut le protocole, voici ce qu'il devrait se passer sur votre réseau :

tcpdump -i eth0 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:59:25.431354 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
10:59:28.431354 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
10:59:31.431354 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36

Une trame de ce type sera envoyée toutes les 3secondes (champ intvl) avec la priorité 1 (priorité maximale) et le vrid 47 (correspondant à l'ID de failover, attention il doit être identique sur le maître et l'esclave).

Ici tout se passe bien la machine maître est en ligne.

Prenons une machine esclave en priorité 10. Le maître tombe à 12h51 et 33sec. Nous avons défini l'intervalle de trame à 3 secondes et le nombre d'essais maximum à 5.

Voici ce qu'il se passera au niveau UCARP à partir de l'esclave.

tcpdump -i eth0 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:51:25.431354 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
12:51:28.123456 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
12:51:31.254789 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
12:51:49.478946 IP 192.168.1.160 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 10,
authtype none, intvl 3s, length 36
12:51:52.325894 IP 192.168.1.160 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 10,
authtype none, intvl 3s, length 36

L'esclave a pris le relai après 5 essais à 3 secondes d'intervalle (soit 15 secondes) plus tard.

Maintenant simulons le retour du maître à 13h01 et 45 sec.

tcpdump -i eth0 vrrp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:01:43.478946 IP 192.168.1.160 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 10,
authtype none, intvl 3s, length 36
13:01:46.325894 IP 192.168.1.160 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 10,
authtype none, intvl 3s, length 36
13:01:49.431354 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36
13:01:52.123456 IP 192.168.1.150 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 47, prio 1,
authtype none, intvl 3s, length 36

Et voilà, désormais vous savez faire du failover via UCARP !

Note: vous pouvez faire du failover en cascade en rajoutant des serveurs avec des priorités différentes

Merci à Olivier Calzi pour cette actualisation

Migrer des bornes lourdes en bornes légères

Le réseau évolue, se complexifiant et se centralisant, aux moyens de contrôleurs. Le WiFi est une des premières technologies à avoir évoluer afin de centraliser son intelligence autour d'un contrôleur.

Chez CISCO on retrouve une gamme de contrôleurs WLC 55XX destinés à gérer un ensemble de bornes légères.

Dans ce tutoriel nous allons migrer des bornes WiFi 1242AG de 2006 en bornes légères et les relier à un contrôleur WLC 5500 (version 7) de 2013

Différences bornes lourdes et légères

La principale différence entre bornes lourdes et légères, hormis l'autonomie vs la centralisation de l'intelligence, est au niveau réseau.

Les bornes lourdes CISCO se basent sur des agrégats de VLAN en 802.1Q avec un VLAN d'administration et autant de VLAN tagués que de SSID (voire plus si les VLANs sont dynamiques via Radius).

Les bornes légères montent un tunnel (CAPWAP) entre la borne et le contrôleur, faisant transiter l'ensemble du trafic par celui-ci, que ce soit le trafic administratif ou celui des clients.

Prérequis: DHCP

Si vos bornes sont configurées en IP statiques, vous devez configurer votre réseau afin de distribuer des IP via DHCP.

Configurez donc un réseau en IP dynamiques afin de provisionner vos bornes.

Prérequis: configuration de la découverte de contrôleur via DHCP ou DNS

Afin de permettre à vos bornes de trouver le contrôleur vous devez générer une chaîne et l'ajouter à l'option 43 de votre DHCP. Vous trouverez de la documentation sur cette chaîne ici.

Attention: il se peut que cette option ne fonctionne pas correctement sur certains DHCP UNIX. CISCO prévoit une méthode de découverte alternative via un enregistrement DNS.

Pour utiliser cette méthode, ajoutez simplement un enregistrement DNS de type A nommé CISCO-CAPWAP-CONTROLLER dans la zone DNS associée à votre subnet DHCP, par exemple CISCO-CAPWAP-CONTROLLER.example.org si le subnet DHCP définit example.org comme suffixe DNS.

nsupdate
> update add CISCO-CAPWAP-CONTROLLER.example.org. 86400 A 10.0.0.1
> send
> quit

Prérequis: pare-feux

Les bornes légères montant un tunnel CAPWAP avec le contrôleur, n'oubliez pas d'autoriser les flux.

Migration

Etape 1: changement d'IOS

L'IOS d'une borne lourde ne peut pas se connecter à un contrôleur WiFi. Il vous faudra le changer pour utiliser un IOS de borne légère.

Afin d'identifier si un IOS est utilisé pour une borne légère ou lourde, il faut regarder le nom du fichier et sa taille:

-rw-r--r--   1 root      wheel  5570560 Sep 17 17:43 c1240-k9w7-tar.124-10b.JDA3.tar
-rw-r--r--   1 root      wheel  2631680 Sep 17 18:11 c1240-rcvk9w8-tar.124-21a.JA2.tar

Dans l'exemple ci-dessus, l'IOS original de la borne lourde est le plus gros. De plus, la chaîne rcvk9w8 définit que l'IOS est dédié à une borne légère, a contrario de k9w7.

Note: vous n'êtes pas obligé d'utiliser un IOS de borne légère légal pour effectuer votre migration, le WLC remplacera l'IOS par un plus récent et original, adapté à la borne lorsque la borne le contactera. Néanmoins, si possible, utilisez un IOS original pour votre migration.

On va maintenant changer l'IOS de la borne (évitez les coupures électriques pendant cette manipulation !!!) et supprimer la startup-config de la borne lourde (ce fichier de configuration n'est pas utilisée par les bornes légères)

delete /recursive /force flash:c1240-k9w7-tar.124-10b.JDA3
archive download-sw /overwrite /reload tftp://10.0.0.50/c1240-rcvk9w8-tar.124-21a.JA2.tar
erase startup-config

Vous pouvez désormais redémarrer votre borne.

reload

Etape 2: configuration du port du commutateur

Reconfigurons maintenant le port du commutateur.

switch(configure-if)# no switchport trunk allowed vlan
switch(configure-if)# no switchport trunk native vlan
switch(configure-if)# no switchport trunk encapsulation dot1q
switch(configure-if)# switchport mode access
switch(configure-if)# switchport access vlan 18
switch(configure-if)# shutdown
switch(configure-if)# no shutdown

On retire l'encapsulation et on déclare le VLAN 18, correspondant à notre réseau de bornes légères en DHCP. Enfin on redémarre le port afin d'être certain que la borne est dans le nouveau réseau.

C'est tout, votre borne devrait désormais demander une IP puis contacter le contrôleur.

Les étapes suivantes sont habituelles lors de l'installation de bornes légères: mise à jour de l'IOS local, redémarrage et configuration de la borne.

Il ne vous reste plus qu'à ajouter la borne dans le bon groupe sur le WLC afin de la provisionner.

Erreurs possibles après migration

J'ai eu quelques cas étranges où la borne utilisait l'IOS temporaire de bornes légères mais refusait d'utiliser le DHCP. Afin de l'obliger à se reconfigurer en DHCP, tapez simplement les commandes suivantes:

clear lwapp private-config
clear lwapp ap ip address
clear lwapp ap ip default-gateway

Conclusion

Lorsque j'ai fait ce test j'étais sceptique quant au fonctionnement du système, au vu de l'écart d'âge entre les 1242 et le WLC. Néanmoins ce fût une bonne surprise de voir que CISCO n'a pas choisi l'obsolescence programmée de son matériel, bien qu'une voire deux générations de bornes WiFi soient passées.

En terme de fonctionnalités, la borne garde un niveau fonctionnel équivalent, pour une résilience légèrement moindre, mais un fonctionnement global de l'infrastructure meilleur (roaming, authentification, gestion des logs et des configurations...). Si vous utilisez des bornes lourdes, peut être est-il temps de vous orienter vers une solution légère ?

Comparaison de performances IPv4/IPv6

Suite à notre récent peering BGPv4 sur le réseau Renater et notre demande en IPv6, je me suis penché cet après midi sur un petit benchmark de performances. Je souhatais donc vous partager le résultat de ce test

IPv4+IPv6 comparisonGlobalement sur les BSD les performances IPv4/IPv6 sont équivalentes, même en passant par des routeurs OpenBSD (traitement soft). On remarquera néanmoins qu'un équipement CISCO (chassis 4500 de 2006) qui fait du traitement soft a de très grandes difficultés à router les paquets (2.3Mo/sec au lieu des 48Mo/sec d'IPv4).

Script PHP: envoi de commandes sur un ensemble d’équipements réseau

Suite à un désespoir aujourd'hui, à cause d'un contrôleur WiFi CISCO qui déconne mais également d'un besoin d'envoyer des commandes sur l'ensemble de notre parc de bornes WiFi, j'ai développé un script qui permet d'envoyer des commandes à un ensemble d'équipements réseau (sous réserve d'avoir les mêmes logins partout).

Le script lit 2 fichiers:

  • Liste des adresses des équipements (adresse IPv4)
  • Liste des commandes à exécuter (dans l'ordre)

Ensuite pour chaque équipement il va exécuter les commandes spécifiées.

Prérequis

  • php5
  • libssh2

Le script (licence BSD)

<?php
/* Copyright (c) 2013, Loïc Blot
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1\. Redistributions of source code must retain the above copyright notice, this
*  list of conditions and the following disclaimer.
* 2\. Redistributions in binary form must reproduce the above copyright notice,
*  this list of conditions and the following disclaimer in the documentation
*  and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
* ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* The views and conclusions contained in the software and documentation are those
* of the authors and should not be interpreted as representing official policies,
* either expressed or implied, of the FreeBSD Project.
*/
    function printErr($output) {
        echo "Erreur: ".$output."\n";
    }

    function printInfo($output) {
        echo "Info: ".$output."\n";
    }

    function connectToDevice($device,$sshuser,$sshpwd,$enablepwd) {
        global $conn;
        $conn = ssh2_connect($device,22);
        if(!$conn)
            return -1;

        if(!ssh2_auth_password($conn, $sshuser, $sshpwd))
            return -2;

        $stdio = @ssh2_shell($conn,"xterm");
        fwrite($stdio,"enable\n");
        usleep(250000);
        while($line = fgets($stdio)) {}

        fwrite($stdio,$enablepwd."\n");
        usleep(250000);
        while($line = fgets($stdio)) {
            if($line == "% Access denied\r\n")
                               return -3;
               }
        return $stdio;
    }

    function sendSSHCmd($stdio, $cmd) {
        $output = "";
        $output_arr = array();
        $promptfind = false;

        fwrite($stdio,$cmd."\n");
        $matches = array();
        while(!$promptfind) {
            while($line = fgets($stdio)) {
                if(preg_match("#--More--#",$line))
                    fwrite($stdio," ");
                else if(preg_match("/^(.+)[#]$/",$line,$matches))
                    $promptfind = true;
                else array_push($output_arr,$line);
            }
        }

        for($i=0;$i<count($output_arr)-2;$i++) {
            $output .= $output_arr[$i];
        }
        return $output;
    }

    function readCmdFile($file) {
        global $cmdfilebuf;
        $cmdfilebuf = file($file);
        if(!$cmdfilebuf) return false;
        return true;
    }

    function readDevAndExec($file) {
        global $sshuser,$sshpwd,$enablepwd,$cmdfilebuf;

        $devfilebuf = file($file);
        if($devfilebuf == false) {
            printErr("Impossible de lire le fichier '".$file."'");
            return false;
        }

        for($i=0;$i<count($devfilebuf);$i++) {
            if(!preg_match("#^(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\.(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])$#",$devfilebuf[$i])) {
                printErr("L'IP '".$devfilebuf[$i]."' n'est pas valide");
                return false;
            }
        }

        $cmds="";
        for($i=0;$i<count($cmdfilebuf);$i++)
            $cmds .= $cmdfilebuf[$i];
        printInfo("Le fichier suivant va etre envoye aux peripheriques:\n--------------------------------------\n".$cmds."--------------------------------------");

        for($i=0;$i<count($devfilebuf);$i++) {
            $host = substr($devfilebuf[$i],0,-1);
            printInfo("Connexion a '".$host."'");
            $out = "";
            $stdio = connectToDevice($host,$sshuser,$sshpwd,$enablepwd);
            switch($stdio) {
                case -1: printErr("SSH conn failed"); break;
                case -2: printErr("SSH auth failed"); break;
                case -3: printErr("Enable auth failed"); break;
                case false: printErr("Steam failed"); break;
                default:
                    for($j=0;$j<count($cmdfilebuf);$j++) {
                        sendSSHCmd($stdio,$cmdfilebuf[$j])."\n";
                    }
                    break;
            }
        }
        return true;
    }

    /*
    * Main
    */

    $conn = NULL;
    $cmdfilebuf = NULL;

    if(count($argv) != 6) {
        if(count($argv) < 6)
            printErr("Il manque des arguments\nSyntaxe: program <sshuser> <sshpwd> <enablepwd> <devfile> <cmdfile>");
        else
            printErr("Il y a trop d'arguments\nSyntaxe: program <sshuser> <sshpwd> <enablepwd> <devfile> <cmdfile>");
        return;
    }

    $sshuser = $argv[1];
    $sshpwd = $argv[2];
    $enablepwd = $argv[3];    
    $devfile = $argv[4];
    $cmdfile = $argv[5];

    if(!readCmdFile($cmdfile)) {
        printErr("Impossible de lire le fichier '".$cmdfile."'");
        return;
    }

    readDevAndExec($devfile);    
?>

A vous de jouer, n'hésitez pas à rajouter des options des améliorations et à le partager !

Mise en place de pare-feu/routeurs hautement disponibles avec CARP et pfsync + GRE et OSPF et IPSEC

Introduction

Nous allons voir dans cette article comment mettre en place de la haute disponibilité sur pare-feu en utilisant CARP et pfsync. Ensuite nous relierons deux sites par un tunnel GRE chiffré en IPSEC.

Ce tutoriel est réalisé sous Virtualbox.

Schéma global de la solution:

Infrastructure

Pour appréhender ce tutoriel vous devez avoir pris connaissance des liens suivants:

Nous allons dans cet exemple mettre en place trois serveurs OpenBSD, dont deux utilisant CARP (avec une IP virtuelle) pour assurer de la haute-disponibilté.

Voici le scénario:

  • Réseau d'entreprise
  • Site distant
  • LAN principal et LAN distant.

Matériel

  • Trois serveurs OpenBSD 5.2 disposant de deux cartes réseau:
    • em0: WAN
    • em1: LAN

Modifications du Noyau

Nous allons configurer le noyau de chaque OpenBSD afin qu'il puisse répondre à nos besoins.

Activez le routage en éditant le fichier /etc/sysctl.conf:

net.ipv4.ip_forward=1

ainsi que les options relatives à CARP:

net.inet.carp.preempt=1
net.inet.carp.log=3

Configuration de CARP et PFSync

Nos machines utilisent le réseau LAN via la plage d'adresses 10.17.0.0/24. Pour mettre en place CARP et pfsync nous allons avoir besoin de plusieurs interfaces que nous allons configurer.

Configuration de CARP

GATEWAY A

/etc/hostname.carp1

inet 10.17.0.12 255.255.255.0 NONE vhid 1 carpdev em1 \
pass unixperience advbase 1 advskew 100
GATEWAY B

/etc/hostname.carp1

inet 10.17.0.12 255.255.255.0 NONE vhid 1 carpdev em1 \
pass unixperience advbase 1 advskew 10

Le paramétrage définit:

  • Les requêtes CARP sont envoyées toutes les secondes entre les deux passerelles afin de définir le "Master" et le "Backup".
  • Le advbase étant identique, la gateway B sera maître étant donné que sont advskew est le plus faible

Configuration de PFSync

Par souci de sécurité nous allons mettre le trafic de synchronisation pfsync dans un VLAN dédié entre les gateway. Ce VLAN sera encapsulé sur l'interface em0 et tagué VLAN 2.

Gateway A

/etc/hostname.vlan2

inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev em1

/etc/hostname.pfsync0

up syncdev vlan2 syncpeer 172.21.0.32
Gateway B

/etc/hostname.vlan2

inet 172.21.0.32 255.255.255.0 NONE vlan 2 vlandev em1

/etc/hostname.pfsync0

up syncdev vlan2 syncpeer 172.21.0.31

Une fois la configuration effectuée, on lance les interfaces dédiées avec le script de lancement d'OpenBSD (vous ne pouvez spécifier qu'une interface en argument, cela évitera de reconfigurer les interfaces physique):

sh /etc/netstart

Vous devez maintenant avoir 2 nouvelles interfaces réseau (carp1 et pfsync0), la première possèdant notre IP 192.168.56.101 de manière partagée.

ifconfig carp1
ifconfig pfsync0

Vous pouvez observer le basculement entre les serveurs en désactivant l'interface carp1 sur le serveur maître. L'autre serveur passera de backup à master (ce changement est visible dans la console tty1, via un message kernel, ou en tapant dmesg).

Connexion au site distant

Mise en place un Tunnel GRE

Vous trouverez plus d'informations sur le Tunnel GRE dans cet article: Tunnel GRE

Configurons maintenant les interfaces GRE sur chaque passerelle.

Gateway A

/etc/hostname.gre0

172.16.0.1 172.16.0.3 netmask 0xffffffff link0 up
tunnel 192.168.56.102 192.168.56.105

Gateway B

172.168.0.2 172.16.0.4 netmask 0xffffffff link0 up
tunnel 192.168.56.103 192.168.56.105

Gateway C (Routeur distant)

/etc/hostname.gre0

172.168.0.3 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.56.105 192.168.56.102

/etc/hostname.gre1

172.168.0.4 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.56.105 192.168.56.103

Chaque interface GRE est connectée à une des gateway de notre LAN.

Tapez ensuite la commande sh /etc/netstart sur chaque machine pour prendre en compte les tunnels. Testez ensuite le fonctionnement du tunnel en pingant "l'autre bout"

Nos sites distants sont désormais connectés. Le principal inconvénient est la sécurité. En effet, ces tunnels ne sont pas sécurisés, n'importe qui peut observer le trafic en clair sur le WAN. Le second problème est le routage, comment rendre cette interconnexion dynamique ? La réponse: OSPF.

Mise en place de OSPF

La mise en place d'ospf est plutôt simple. La lecture du man (article ospfd.conf) vous apportera toute la lumière nécessaire. Nous allons dans le cas présent utiliser l'aire OSPF 1 via les tunnels GRE et utiliser un mot de passe (hashé en MD5): unix-experience.

/etc/ospfd.conf (Gateway A)

router-id 192.168.56.102
redistribute connected
gre_if="gre0"
password="unix-experience"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.1 {
         interface $gre_if {}
}

/etc/ospfd.conf (Gateway C)

router-id 192.168.56.103
redistribute connected
gre_if0="gre0"
gre_if1="gre1"
password="unix-experience"
auth-md 1 $password
auth-type crypt
auth-md-keyid 1
area 0.0.0.1 {
         interface $gre_if0 {}
         interface $gre_if1 {}
}

Pour ceux connaissant la syntaxe de pf vous retrouverez des similitudes.

Après quelques secondes, tapez la commande netstat -nrf -inet afin de visualiser l'état de la table de routage. Elle devrait se remplir avec des champs de poids 32 (OSPF)

N'oubliez pas d'activer OSPF au démarrage via /etc/rc.conf.local

Mise en place d'IPSEC

Le tunnel GRE étant non chiffré, nous allons appliquer une couche de chiffrement IPSec entre nos deux sites. Il faut commencer par activer la prise en charge d'IPSEC dans le noyau:

net.inet.esp.enable=1
net.inet.ah.enable=1

Voici donc le fichier de configuration de GA qui devra être adapté pour chaque gateway.

/etc/ipsec.conf

ike esp transport from 192.168.56.102 to 192.168.56.105 \
psk unix-experience

Il faut ensuite échanger les clés publiques (créée dans le fichier /etc/isakmp/local.pub à l'installation).

Par exemple pour le chiffrement de GA vers GC, copiez le fichier local.pub de GA dans le fichier /etc/isakmpd/pubkeys/ipv4/192.168.56.102 sur GC (le nom de fichier correspondant à l'IP de GA)

Notez que si vous utilisez un nom DNS pour établir le tunnel, il faudra utiliser le répertoire FQDN avec pour nom de fichier le FQDN

Lancez ensuite le chiffrement IPSEC

isakmpd -K
ipsecctl -f /etc/ipsec.conf

Si vous rencontrez des problèmes, un tail sur le fichier /var/log/messages devrait permettre de comprendre les problèmes pouvant être rencontrés.

Si le tunnel est opérationnel, ajoutez l'entrée suivante dans /etc/rc.conf.local afin d'activer IPSEC au boot:

isakmpd_flags="-K"
ipsec=YES

Sources

PPTPD (Poptop)

Introduction

Les tunnels PPTP sont des tunnels qui sont intégrés nativement dans la plupart des OS depuis une dizaine d'années. S'appuyant sur PPP et ajoutant une couche d'authentification plus robuste voire du chiffrement, ils permettent aux utilisateurs distants de pouvoir se connecter à leur réseau d'entreprise.

Installation:

Sous Debian tapez la commande suivante:

aptitude install pptpd radiusclient1

Sous FreeBSD:

cd /usr/ports/net/poptop
make install clean

Configuration du service PPTPD

Ouvrez/créez le fichier /usr/local/etc/pptpd.conf (/etc/pptpd.conf sous Debian) et insérez les lignes suivantes:

#
# PPTPD configuration
#

name pptpd

# Authentication
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128

plugin radius.so
plugin radattr.so

# Routing
proxyarp
nodefaultroute

# Misc
nobsdcomp
noipparam
logwtmp

Le nom est très important, car c'est ce nom qui permettra de faire le lien entre pptpd et pppd. Si le lien est incorrect et qu'il manque un label, l'erreur suivante apparaîtra dans les logs:

pptp: Configuration label not found

L'authentification est configurée au niveau de sécurité maximal sur MSChapv2, et on refuse explicitement toutes les autres méthodes. On active le chiffrement MPPE-128 bits sur la connexion et enfin on fait le lien avec le plugin du serveur radius.

Les options suivantes permettent

  • aux requêtes ARP d'aboutir (proxyarp)
  • de ne pas distribuer la route par défaut (nodefaultroute)
  • de ne pas utiliser la compression BSD (nobsdcomp) afin d'être interopérable
  • de loguer les connexion en WTMP (logwtmp)

Configuration de PPP (sous FreeBSD uniquement)

Adressage et tunnel

Ouvrez maintenant le fichier /etc/ppp/ppp.conf et ajoutez les lignes suivantes:

loop:
    set timeout 0
    set log phase chat connect lcp ipcp command
    set device localhost:pptp
    set dial
    set login
    set ifaddr 10.4.7.250 10.4.7.1-10.4.7.200 255.255.255.255
    add default HISADDR
    set server /tmp/loop "" 0177

loop-in:
    set timeout 0
    set log phase lcp ipcp command
    allow mode direct

pptp:
    load loop
    disable pap
    disable ipv6cp
    enable proxy
    accept dns
    enable MSChapV2
    enable mppe
    set dns 129.175.196.160
    set device !/etc/ppp/secure
    set radius /etc/ppp/radius.conf

Dans le label loop, changez les IP de ifaddr par celles que vous souhaitez, la première étant l'adresse du tunnel VPN. Il est important que le masque soit 255.255.255.255 afin que vous n'ayez pas de mauvaise surprise !

Dans le label pptp, spécifiez un serveur DNS afin que le client l'utilise de manière préférable à celui de sa connexion physique (accept dns puis set dns ), activez MSChapv2 (enable MSChapV2) et MPPE (enable mppe). On a désactivé IPCP pour IPv6 ici car notre réseau ne le supporte pas (disable ipv6cp).

Créez maintenant le fichier /etc/ppp/secure et insérez les lignes suivantes:

#!/bin/sh
exec /usr/sbin/ppp -direct loop-in

et rendez le exécutable:

chmod +x /etc/ppp/secure

Ceci permettra à PPP de créer une interface de loopback direct pour relier le tunnel et l'interface physique du serveur.

Authentification

Pour terminer on va configurer le serveur Radius en créant le fichier /etc/ppp/radius.conf

auth 10.4.3.1:1812 radPwd
acct 10.4.3.2:1813 radPwd2

Activation du service & NAT

Il faut maintenant nater le trafic du tunnel (à moins que vous ne souhaitiez le router), grâce à Packet Filter. Ouvrez le fichier pf.conf et ajoutez la ligne suivante:

nat on em0 inet proto { tcp, udp, icmp } from 10.4.7.0/24 to any -> <ip publique>

Editez le fichier /etc/rc.conf afin d'ajouter les lignes suivantes:

gateway_enable="YES"
pptpd_enable="YES"

Ensuite rechargez vos règles Packet Filter, activez le routage et lancez le service:

pfctl -f /etc/pf.conf
sysctl -w net.inet.ip.forwarding=1
service pptpd start

Configuration de PPP (Debian uniquement)

Adressage des clients

Dans le fichier /etc/pptpd.conf ajoutez les lignes suivantes permettant de configurer l'IP du tunnel et des clients:

localip 10.4.7.250
remoteip 10.4.7.1-250

Authentification

On va maintenant configurer l'authentification radius, ouvrez le fichier /etc/radiusclient/radiusclient.conf et modifiez les lignes suivantes:

authserver      10.4.3.1:1812
acctserver      10.4.3.2:1813

Ouvrez maintenant le fichier /etc/radiusclient/servers et ajoutez les mots de passe de vos serveurs radius

10.4.3.1 radPwd
10.4.3.2 radPwd2

Activation du service & NAT

Activez le routage en éditant le fichier /etc/sysctl.conf:

net.ipv4.ip_forward=1

puis ajoutez la ligne suivante au fichier /etc/rc.local (permettant le nat au démarrage)

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

et exécutez les lignes suivantes pour prendre en compte la configuration et lancer le service

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
service pptpd start

Sources

PPTPD + FreeRadius + MySQL

ISC-DHCP-Server: problèmes courants

Introduction

Cet article a pour but de détailler et d'aider à résoudre les problèmes courants pouvant être recontrés sur ISC-DHCP-Server (dhcpd).

Erreur "no free leases"

Cette erreur survient lorsque le DHCP ne peut pas fournir d'adresses IP, que ce soit parce que tous les baux ont été pris ou bien que votre subnet DHCP ne délivre aucune IP dynamiquement.

Oct 12 11:57:13 dhcpsrv dhcpd: DHCPDISCOVER from a0:16:18:b1:6f:ca via vlan134: network 10.1.6.0/22: no free leases

Pour le résoudre trois choix:

  • Augmentez la taille du réseau (changement de masque) et/ou le range d'adresses distribuables
  • Supprimez les baux DHCP inutiles dans le dhcpd.leases (dangeureux !)
  • Réduisez la durée de vie des baux (default-lease-time et max-lease-time) du subnet

Erreur "peer holds all free leases"

Cette erreur ne peut être obtenue que dans le cas d'une configuration de dhcp en failover/load-balacing. Elle signifie que l'autre DHCP a libéré tous les baux, ou n'a que des baux vides. Elle survient lorsqu'un client fait une requête DHCP sur une zone en erreur, et uniquement lorsque la zone est pleine.

Oct 12 09:54:59 dhcp1srv dhcpd: DHCPDISCOVER from f0:fa:47:36:43:c0 via vlan185: peer holds all free leases

Pour résoudre ce problème, surveillez bien que l'autre DHCP peut distribuer des adresses sur le réseau mentionné. En redémarrant le second DHCP, l'erreur suivante s'est produite:

Oct 12 09:56:00 dhcp2srv dhcpd: No subnet declaration for vlan185 (10.1.35.211).
Oct 12 09:56:00 dhcp2srv dhcpd: ** Ignoring requests on vlan185\.  If this is not what
Oct 12 09:56:00 dhcp2srv dhcpd:    you want, please write a subnet declaration
Oct 12 09:56:00 dhcp2srv dhcpd:    in your dhcpd.conf file for the network segment
Oct 12 09:56:00 dhcp2srv dhcpd:    to which interface vlan185 is attached. **

Il faut vérifier 3 points:

  • Vous avez fait une erreur lors de la déclaration du subnet, l'IP n'est pas bonne
  • Vous avez oublié d'inclure le fichier de configuration du subnet
  • Votre DHCP n'écoute pas sur l'interface du subnet (netstat -an)

Bind9(named) + isc-dhcp-server: Mise à jour DNS Dynamique

Introduction

Ce tutoriel fait suite à une erreur rencontrée sur un service ISC-dhcpd OpenBSD et un service bind9 à mettre en corrélation, l'erreur d'origine était:

dhcpd: Unable to add forward map "not found"

Dans un réseau avec adresses IP dynamiques, il est intéressant d'utiliser des noms DNS afin de retrouver les machines. Ces noms doivent évoluer avec la configuration du réseau. Il existe une mécanique interne à named (bind) et isc-dhcpd permettant de relier le DHCP et le DNS afin que les mises à jour soient faites entre les 2 services/hôtes.

Cette mécanique utilise le principe du RNDC, qui est une clé partagée, et permet ainsi d'assurer l'authentification des services entre eux.

Dans ce tutoriel nous partirons du principe que chaque machine est à la fois DHCP et DNS.

Génération de la clé partagée

Sur chaque hôte ayant besoin de la clé partagée, tapez:

rndc-confgen -a
cat /etc/rndc.key

Voici le contenu de /etc/rndc.key

key "rndc-key" {
        algorithm hmac-md5;
        secret "vf1uTu6d33PnjMaVTv9++A==";
};

Vous pouvez copier ce fichier (en faisant attention à préserver les droits root et le mod 600 !) sur les différents hôtes si vous souhaitez utiliser une seule clé, et renommer rndc-key en autre chose, my-key par exemple.

Configuration d'ISC-dhcpd

Deux éléments sont nécessaires à ISC-dhcpd afin de pouvoir se relier au(x) DNS:

  • La clé partagée
  • Les zones DNS et serveurs DNS associés

La première étape est d'ajouter la ligne suivante à votre fichier /etc/dhcpd.conf permettant d'ajouter la clé au DHCP

include "/etc/rndc.key";

La seconde étape consiste à déclarer les zones DNS au DHCP (ici la zone et un reverse associé):

zone domain.tld. {
        secondary 10.1.1.3;
        primary 10.1.1.2;
        key my-key;
}

zone 50.10.in-addr.arpa. {
        secondary 10.1.1.3;
        primary 10.1.1.2;
        key my-key;
}

On déclare le serveur primaire DNS 10.1.1.2 et le serveur secondaire 10.1.1.3, ceci permettra de garder une synchronisation des enregistrements entre les différents DNS.

Configuration de named (bind9)

Ouvrez votre named.conf et ajoutez les lignes suivantes:

key "my-key" {
        algorithm hmac-md5;
        secret "vf1uTu6d33PnjMaVTv9++A==";
};

controls {
       inet 10.117.1.2 port 953
               allow { 10.117.1.2; 10.117.1.3; 127.0.0.1; } keys { "my-key"; };
};

Ces lignes vont dire à named d'écouter sur une interface (port TCP 953) et de n'autoriser que certains hôtes (lui même en localhost et adresse externe, ainsi que le second DHCP) avec la clé my-key à venir mettre à jour le DNS.

Maintenant éditez les zones afin de permettre les mises à jour (named.conf):

zone "domain.tld." IN {
        type master;
        file "master/db.domain.tld";
        allow-update {
                key my-key;
                127.0.0.1;
                10.1.1.2;
                10.1.1.3;
                10.50.0.0/16;
        };
        notify yes;
};

zone "50.10.in-addr.arpa" {
        type master;
        file "master/db.10.50";
        allow-update {
                key my-key;
                127.0.0.1;
                10.1.1.2;
                10.1.1.3;
                10.50.0.0/16;
        };
        notify yes;
};

On autorise la clé et les deux serveurs à mettre à jour la zone, ainsi que les adresses IP des clients, car Windows n'utilise pas les mécaniques conventionnelles et vient lui même mettre à jour le DNS (et c'est important que ce soit le cas, si vous voulez mettre en place un annuaire ActiveDirectory, autorisez le à mettre à jour le DNS avant d'installer le service !!)

Pour terminer, veillez au éléments suivants:

  • Le répertoire contenant les fichiers de zone doit appartenir à l'utilisateur et groupe named et avoir les droits 755
  • Les fichiers de zone doivent appartenir à l'utilisateur et groupe named doivent être en droits 644

Désormais vous avez un DHCP et un DNS dynamiques multi serveurs !

Configurer 802.1X sur un port

Introduction

Il est de plus en plus courant dans le monde de l'entreprise d'utiliser du 802.1X afin de sécuriser son réseau et le dynamiser. Cela nécessite une légère augmentation de la bande passante et un serveur dédié avec un CPU robuste et des accès aux données rapides. Nous allons voir rapidement comment mettre en place du 802.1X sur un switch CISCO

Création de la politique 802.1X

switch# conf t
switch(config)# aaa new-model
switch(config)# aaa authentication login default local-case
switch(config)# aaa authentication dot1x default group radius
switch(config)# aaa authorization network default group radius
switch(config)# dot1x system-auth-control
switch(config)# radius-server host 10.1.1.3 auth-port 2812 acct-port 1813 key 0 motdepasseradius
switch(config)# radius-server vsa send authentication
switch(config)# exit

Le mot de passe radius sera chiffré de manière réversible (niveau 7) ensuite.

Utilisation de la politique 802.1X sur un port

interface FastEthernet 1/0/1
 switchport mode access
 authentication event fail action authorize vlan 23
 authentication event no-response action authorize vlan 23
 authentication port-control auto
 dot1x pae authenticator
end

Ces commandes permettent d'utiliser 802.1X sur un port de switch. Linux et MAC OS le gèrent nativement, néanmoins quelques manipulations seront nécessaires sous Windows.

Les deux lignes stipulant le VLAN 23 permettent de basculer la machine dans ce VLAN lorsqu'elle n'est pas autorisée ou encore qu'il n'y a pas de réponse de la part du serveur radius.

Authentification Radius par adresse MAC

interface FastEthernet 1/0/1
 switchport mode access
 authentication event fail action authorize vlan 23
 authentication event no-response action authorize vlan 23
 authentication port-control auto
 mab eap
end

La configuration est quasiment identique, à une nuance près qu'on rajoute la ligne mab eap qui permet de définir l'option mac-address bypass qui nous intéresse ici. Si vous ne souhaitez pas utiliser EAP pour sécuriser les échanges vous pouvez indiquer uniquement mab.

Management de stack CISCO

Introduction

Je vous propose ici d'apprendre les rudiments du stacking. Nous étudierons ici comment bien remplacer un switch dans un stack. Pour l'ajout et la suppression nous y reviendrons plus tard.

Un stack de switch consiste à mettre en cascade les switch via le connecteur dédié, situé à l'arrière de l'équipement. Il existe deux types de stack CISCO, le stackwise, présent sur les séries 3750, et le flexstack, présent sur les séries 2960. La techonologie stackwise permet d'intégrer jusqu'à 9 switches dans la pile tandis que flexstack n'en permet que 5.

Dans le cadre d'un stack, il faut savoir que la configuration est copiée sur l'ensemble des switch, et qu'ils vont élire un maître, qui sera celui qui gèrera l'ensemble de la configuration et des mises à jour. Cette élection se fait via un indicateur de priorité (de 1 à 15, 15 étant la plus forte priorité), qui reste au sein du switch, même si vous supprimez la configuration de celui-ci ! En cas d'égalité de priorité, ce sera, soit le switch ayant démarré le premier, soit celui ayant la plus petite mac-address qui sera élu maître. Une fois cette élection effectuée, le maître ne changera pas, même si vous changez la priorité, à moins de débrancher le maître.

Connaître l'état du stack

Afin de connaître l'état de votre stack (ici des 3750) tapez la commande:

show platform stack manager all

Voici le résultat:

  Switch/Stack Mac Address : 000a.b87b.abcd
                                             H/W   Current
  Switch#  Role   Mac Address     Priority Version  State
  ----------------------------------------------------------
  *1       Master 000a.b87b.abcd     15     0       Ready
   2       Member 0018.7358.aaaa     5      0       Ready
   3       Member 001a.a22e.bbbb     1      0       Initializing
   4       Member 0018.7358.cccc     3      0       Ready
   5       Member 0018.19da.dddd     2      0       Ready
   6       Member 0018.7315.eeee     1      0       Ready

           Stack Port Status             Neighbors
  Switch#  Port 1     Port 2           Port 1   Port 2
  --------------------------------------------------------
    1        Ok         Ok                2        6
    2        Ok         Ok                3        1
    3        Ok         Ok                4        2
    4        Ok         Ok                5        3
    5        Ok         Ok                6        4
    6        Ok         Ok                1        5

Je ne vous ai pas mis la suite, suite qui n'est que composée de données peu explicites et utile dans le cadre de l'article.

Le premier table récapitulatif montre l'état du stack, avec les différentes adresses MAC des équipements, leur rôle (maître ou membre), la priorité, la version et pour terminer le statut du switch dans le stack.

Les états peuvent être:Ready : le switch est dans la pile et tout est correct

  • Ready : le switch est dans la pile et tout est correct
  • Removed : pas de switch dans le slot du stack
  • Progressing: le switch regarde l'état du stack et qui sont ses voisins
  • Initializing : le switch se synchronise avec les autres du stack

Remplacement du switch dans un stack

Lorsque vous voulez remplacer le switch d'un stack, que ce soit parce qu'il est défectueux, ou parce qu'il était non POE et qu'il doit être POE, il faut tout d'abord vous assurer que l'IOS du stack et celui du switch sont identiques, afin que la version du protocole de stacking soit la même. Vous pouvez brancher les deux switches entre eux par un port ethernet pour transférer l'IOS directement ou encore via TFTP par exemple.

Pour retirer le switch du stack, débranchez le électriquement tout d'abord, puis ensuite débranchez les deux ports stackwise.

Il faut savoir que la configuration qu'aura votre switch de remplacement ne sera pas celle du switch manquant. Il aura la configuration telle qu'elle est indiquée dans la startup-config de celui-ci pour le slot et les ports données du stack. Si vous avez rebrassé les prises sur les autres switches, vous pouvez supprimer la startup-config, ce qui permettra de ne pas avoir de conflit de configuration lors de l'intégration dans le stack

erase startup-config
reload

Si vous n'avez pas rebrassé les prises, copiez la startup-config du stack vers le switch de remplacement de la même manière que pour l'IOS, par exemple

copy tftp://192.168.1.2//srv/tftp/startup-config startup-config
reload

Une fois la cohérence de l'ensemble effectuée, insérez le switch à l'emplacement dédié, branchez les cables de stacking et ensuite électriquement. Suivant l'équipement, comptez entre 1 et 5 minutes avant l'intégration et la synchronisation de l'ensemble du stack. Vous pourrez vérifier l'avancement avec la commande citée en début d'article.