Nous utilisons principalement des [switchs Cisco](https://www.cisco.com/c/fr_fr/products/switches/index.html) Catalyst 2960/3750, des Cisco Nexus 3000, et quelques Cisco Small Business. Cette documentation sera orientée pour ces modèles.
**ℹ️ Note : historiquement, nous utilisions principalement des Catalyst 2960, c'est donc le modèle contenant la documentation la plus complète. Les commandes non indiquées pour les autres modèles sont généralement les mêmes que celles indiquées pour les Catalyst 2960. ℹ️**
* Exécuter la commande `minicom cisco` et observer l'initialisation du switch. À la question `Would you like to enter the initial configuration dialog?`, répondre `no`
Pour un switch récent, une fois allumé pour la 1ère fois et les voyants _SYST_, _MAST_ et _STAT_ verts, on appuie 3 à 4 secondes sur le bouton _MODE_ ce qui le fait passer en mode _Express Setup_.
Note : Pour les Catalyst, la commande d'origine est `show interfaces` avec un *s* et non `show interface`. Mais étant donné que la commande pour les Nexus est `show interface` sans *s* et que la commande sans *s* est comprise par les Catalyst, on la documente ainsi pour simplifier le copié/collé.
On passe dans le mode d'exécution privilégié avec `Switch> enable`. Dans ce mode, on ne peut rien configurer, mais c'est dans celui-ci que l'on pourra exécuter les commandes `show` permettant d'examiner les configurations en place. Avec `Switch# configure terminal`, on arrive dans le mode de configuration global. Enfin, `Switch(config)# interface XXX` nous mettra dans le mode de configuration d'interface.
On peut descendre d'un niveau avec la commande `exit`, ou redescendre directement vers le mode d'exécution privilégié avec la commande `end`. Les commandes `show` ne peuvent s'exécuter que dans le mode d'exécution privilégié, mais peuvent être exécutés depuis un mode plus élevé en débutant la commande avec `do` :
Attention : ces mots de passe ne sont pas sécurisés et sont déchiffrables par [Cisco Password Cracker](http://www.ifm.net.nz/cookbooks/passwordcracker.html). Il ne faut donc pas utiliser le mot clef `password` et préférer `secret` lorsque cela est possible : `enable secret PASSWORD` au lieu de `enable password PASSWORD`, et ne pas utiliser `password PASSWORD` pour les connexions telnet, ssh ou console. Voir [SwitchCisco#mise-en-place-dun-compte-utilisateur]()
Il faut également utiliser un mot de passe fort, puisque les mots de passes chiffrés par secret sont hashés en MD5 et déchiffrables avec [Cisco IOS Enable Secret Type 5 Password Cracker](http://www.ifm.net.nz/cookbooks/cisco-ios-enable-secret-password-cracker.html)
Par défaut, les privilèges 0 et 1 connectent l'utilisateur en mode user (prompt `Switch>`) où `enable` est nécessaire pour passer dans le mode supérieur. Les privilèges 2 à 15 connectent directement l'utilisateur dans le mode supérieur (prompt `Switch#`).
Avec `login local`, on utilisera un compte local créé par la commande `username`, alors qu'avec `login`, aucun compte n'est utilisé et le mot de passe doit être défini avec la commande `password PASSWORD`. Ces dernières ne doivent pas être utilisées, étant donné que le mot de passe ne serait pas sécurisé.
Le software IOS est téléchargeable gratuitement sur <https://software.cisco.com/download/home>. Il suffit d'avoir un compte Cisco, créable par n'importe qui.
On clique ensuite sur "IOS Software", et toutes les versions apparaissent, dont la version recommandée. Une version `.tar` et une version `.bin` sont proposées, nous téléchargeons plutôt la version `.bin`.
Le switch doit tout d'abord avoir une IP configurée. On peut par exemple configurer une IP dans le VLAN 1 comme indiqué [ici](#affecter-une-adresse-ip-%C3%A0-un-vlan), puis affecter l'interface qui sera branchée au serveur TFTP à ce VLAN 1 en s'aidant de [cette partie](#affecter-des-interfaces-ports-%C3%A0-un-vlan).
On configure le serveur sur l'utilisateur `nobody`, et on ajoute l'option `-c` pour autoriser la création de nouveaux fichiers sur le serveur. On place ensuite le binaire IOS dans le répertoire TFTP.
Une façon de contrôler si le trunk est bien mis en place des 2 côtés est de consulter la sortie de la commande `show vlan brief`. Si le port est toujours dans le vlan 1, c'est que le trunk n'est pas opérationnel (interface non montée, ou port distant non configuré en trunk). Si tout fonctionne bien, on ne doit le voir dans aucun vlan, mais on le verra en trunk dans un `show interface status`.
Note : `line vty 0 4` autorise 5 connexions simultanées tandis que `line vty 0 15` en autorise 16. Les plus anciens switchs ne permettaient pas plus de 5 connexions simultanées, c'est pourquoi les vty 0 4 et 5 15 sont souvent séparés.
Important : Mettre en place le [nom d'hôte](SwitchCisco#changer-le-nom-dh%C3%B4te), le [nom de domaine](SwitchCisco#changer-le-nom-de-domaine), et le [compte utilisateur](SwitchCisco#mise-en-place-dun-compte-utilisateur).
Cette commande permet de ne pas interrompre le prompt de l'utilisateur lorsque des logs s'affichent sur le switch. Ils s'afficheront sur la ligne du dessus plutôt que sur la ligne courante.
* Augmenter la taille du buffer de log :
~~~
Switch# conf t
Switch(config)# logging buffered 102400
~~~
La commande `show logging` gardera un historique de logs plus importants.
**Attention !** La commande `login on-success log` provoque un bug sous la version IOS `15.0(2a)EX5`. Si le switch est sous cette version, il ne faut **pas** configurer cette commande, qui provoquera un reboot du switch à chaque connexion d'un utilisateur.
* Afficher l'heure locale sur les logs, avec une présicion en millisecondes :
~~~
Switch# conf t
Switch(config)# service timestamps debug datetime msec localtime
Switch(config)# service timestamps log datetime msec localtime
~~~
* Envoyer les logs à un serveur syslog :
~~~
Switch# conf t
Switch(config)# logging trap debugging
Switch(config)# logging facility local6
Switch(config)# logging host 192.0.2.10
~~~
Du côté du serveur syslog, par exemple avec rsyslogd, on peut le configurer pour avoir un fichier de log par switch, selon son IP. Dans `/etc/rsyslog.conf` :
~~~
if $fromhost-ip=='192.0.2.5' then /var/log/switchs/switch-192.0.2.5.log
& stop
if $fromhost-ip=='192.0.2.6' then /var/log/switchs/switch-192.0.2.6.log
& stop
~~~
Attention à bien mettre ces règles **avant** les règles de facilités.
Vu qu'on a configuré le switch pour utiliser la facilité "local6", on peut également rajouter une règle supplémentaire pour tous les switchs sans règle spécifique :
~~~
local6.* -/var/log/switchs/unknown.log
~~~
Puis on restart le service :
~~~
# systemctl restart rsyslog
~~~
* Rate-limiter les messages de log
Dans le cas où on a un message qui s'écrit plusieurs fois à la suite, et qu'on veut éviter que celui-ci remplisse les logs, on peut rate-limiter ce log spécifiquement :
~~~
Switch# conf t
Switch(config)# logging discriminator SNMP severity drops 5 facility drops SYS mnemonics drops CONFIG_I msg-body drops "Configured from 192.0.2.10 by snmp"
~~~
Ici, il le message ne s'affichera pas plus de 5 fois à la suite.
Une fois le discriminator "SNMP" crée, on l'applique aux commandes syslog précédemment activées :
Si on veut limiter l'écriture SNMP par une IP source, et sur certains OID uniquement, il faut créer une `view` et une `access-list`, puis l'indiquer à SNMP :
Le terme "trap" englobe 2 types de trap SNMP : les requêtes "trap" et les requêtes "inform". La différence est que pour une requête "trap", l'agent SNMP qui l'envoie n'a aucun moyen de savoir si le manager SNMP l'a bien reçue ou non, alors qu'une requête "inform" sera ré-émise par l'agent SNMP tant qu'il n'a pas reçu d'acknowledgement de la part du manager SNMP lui indiquant que la requête inform a bien été reçue.
Si on veut envoyer des traps SNMP de type `inform` à l'hôte `192.0.2.10`, en utilisant la version SNMP `2c` et la communauté SNMP `private`, et en activant toutes les traps :
~~~
Switch# conf t
Switch(config)# snmp-server host 192.0.2.10 informs version 2c private
Switch(config)# snmp-server enable traps
~~~
Si on souhaite que les traps de type "link up" et "link down" soient au format standard IETF et indiquent notamment les status `ifAdminStatus` et `ifOperStatus` :
~~~
Switch(config)# snmp-server trap link ietf
~~~
En activant toutes les traps, certaines sont trop verbeuses et inutiles, et peuvent être désactivées :
~~~
Switch(config)# no snmp-server enable traps config
Switch(config)# no snmp-server enable traps syslog
~~~
La première désactive l'envoi de trap à chaque exécution d'une commande sur le switch, la deuxième désactive l'envoi de trap SNMP avec le contenu du log pour chaque syslog généré.
Dans le cas où il n'y a pas de serveur DNS configuré, cette commande permet de ne pas avoir à attendre quelques secondes avant timeout qu'un nom soit tenté d'être traduit. Très utile en cas d'erreur :
~~~
Switch# exiit
Translating "exiit"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
Ces deux protocoles de niveau 2 permettent la même chose : découvrir ses voisins réseau directement connectés, à l'aide d'annonces émises de façon régulière. CDP est propriétaire Cisco (et donc uniquement compatible avec d'autres équipements Cisco) tandis que LLDP est un protocole normé.
Si ces protocoles sont activés sur l'ensemble des équipements d'un réseau, ils permettent d'en découvrir la topologie en vérifiant les voisins de chacun des équipements. Attention cependant : si trois switchs sont interconnectés (switch1<--->switch2<--->switch3) mais que switch2 a ses protocoles LLDP et CDP désactivés, alors les paquets de découvertes de switch1 pour chacun des protocoles seront retransmis par switch2 à switch3. Si on ne fait pas attention, on peut alors penser que switch1 et switch3 sont directement connectés.
Pour chaque voisin est indiqué : son nom réseau, le type ou modèle d'appareil, son adresse IP, l'interface du switch local à laquelle l'appareil est connecté, l'interface du switch distant à laquelle l'appareil est connecté, ainsi que le VLAN utilisé sur ce lien.
Ces protocoles peuvent également servir à automatiquement configurer certains appareils sur le réseau à l'aide des informations partagées. Ce n'est généralement pas une bonne idée de l'utiliser à cette fin, de mauvaises configurations peuvent se faire et une configuration réseau qui fonctionnait peut devenir non fonctionnelle.
Le principe de fonctionnement est qu'un des switchs est élu ROOT (racine de l'arbre STP), et qu'un coût est associé à chaque lien vers le ROOT.
Ce coût est calculé automatiquement à partir du nombre de connexions et du type de ces connexions (un lien 10Mb/s coûte 100, un lien 100Mb/s coûte 19, un lien 1Gb/s coûte 4, etc.).
Ce coût peut aussi être forcé manuellement si l'on veut influencer le calcul du STP.
Ensuite, grâce à ces coûts, si une boucle est détectée certains ports peuvent être bloqués.
Des vérifications sont réalisées régulièrement pour détecter un changement et adapter les blocages si nécessaire.
/!\\ Attention : le simple branchement d'un switch peut provoquer un recalcul de l'arbre et de la topologie par STP, selon la topologie présente. Le branchement d'un nouveau switch peut faire changer le chemin pour permettre de joindre ce nouveau switch en moins de saut.
/!\\ Le _keepalive_ — élement essentiel pour STP — n'est pas activé par défaut sur les ports *SFP* d'un switch Cisco : il faut absolument l'activer si vos segments Ethernet sont propagés sur les ports SFP !
Sur les Cisco 2960-2970, le STP est géré par VLAN on parle de « per-VLAN spanning-tree plus (PVST+) » et si le mode « Rapid » est activé de « rapid per-VLAN spanning-tree plus (rapid-PVST+) ».
La valeur par défaut de la priorité du root switch est 3276.
Le root ID est calculé avec cette priorité + une dérivation de l'adresse MAC. C'est le plus petit ID qui l'emporte.
Il peut être intéressant de changer la priorité pour choisir le switch root.
On peut aussi changer la priorité des ports (128 par défaut + coût du lien [10MBps = 100, 100Mbps = 19, 1Gbps = 4]) pour influencer le calcul STP et les connexions à désactiver.
#### Différence entre Spanning-Tree et Rapid Spanning-Tree
En Spanning-Tree, le rajout d'un lien créant une boucle et ayant un coût plus bas que le lien déjà en place (donc nouveau lien qui sera utilisé à la place de l'actuel) provoquera une coupure de 30s de ces deux liens. Si le lien rajouté a un coût plus élevé et qu'il ne remplacera donc aucun lien, alors seul ce nouveau lien sera coupé 30s. Le changement du switch ROOT provoque également une coupure des ports 30s.
En Rapid Spanning-Tree, le rajout d'un lien et le changement du switch ROOT ne provoquent pas de coupure, seuls des liens redondants déjà désactivés peuvent se couper 30s.
Le passage du mode Spanning-Tree au mode Rapid Spanning-Tree ou inversement provoque également la coupure de tous les ports du switch pour 30s, sauf les ports en mode portfast.
On utilisera cette commande uniquement si l'on est sûr de ne pas avoir besoin du Spanning Tree (serveur non virtuel connecté directement au port, etc.). Le portfast ne désactive pas le spanning-tree puisque le port continue de recevoir et d'envoyer des trames BPDU : il sera bien désactivé par STP si une boucle est créée. Mais dans ce cas, le port pourra mettre jusqu'à 2s pour se désactiver (correspondant à la valeur hello time), et donc des duplications de trames pourront avoir lieu pendant cet instant.
Le VTP est un protocole de niveau 2 propriétaire Cisco et permettant de configurer et administrer les VLAN des switchs dans un même réseau local.
Attention, son utilisation peut être dangereuse si le protocole n'est pas maîtrisé.
Les différents switchs doivent être dans le même domaine VTP pour que la configuration se partage entre eux. Par défaut, aucun domaine n'est configuré, et celui-ci est configuré automatiquement sur tous les switchs dès que sa configuration est faite sur un premier switch.
~~~
Switch(config)# vtp domain NAME
~~~
VTP fonctionne selon plusieurs modes :
* Serveur (mode par défaut) : Création, modification et suppression de VLAN possible. La version VTP peut également être modifiée pour l'ensemble du domaine VTP. Les serveurs annoncent leur configuration VLAN aux autres switchs du domaine et la synchronisent selon les paquets VTP reçus au travers des liens trunks.
* Client : Les clients synchronisent leur configuration VLAN d'après les paquets VTP reçus, et les transférent au travers des liens trunks
* Transparent : Un switch en mode transparent ne participe pas à VTP. Il ne partage ni ne synchronise pas sa configuration, mais transfère les paquets VTP reçus sur ses liens trunks.
* Off : Aucune participation à VTP, et les paquets reçus ne sont pas transférés.
Les switchs ont un numéro de révision VTP, incrémenté lors de chaque modification d'une configuration VTP ou VLAN. Si le numéro de révision reçu par un switch serveur ou client est plus grand que celui en cours, la nouvelle configuration est appliquée. Sinon, elle est ignorée.
~~~
Switch# sh vtp status
VTP Version capable : 1 to 3
VTP version running : 1
VTP Domain Name :
VTP Pruning Mode : Disabled
VTP Traps Generation : Disabled
Device ID : a456.309a.d200
Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00
Local updater ID is 192.0.2.1 on interface Fa0 (first layer3 interface found)
Sans aucun des deux mots clefs `rx` ou `tx`, la réception et la transmission sont tous les deux mirrorés. Il faut préciser `tx` si on ne veut mirrorer que ce qui sort du port, ou `rx` si on ne veut mirrorer que ce qui rentre dans le port.
Si on veut monitorer à la fois un port en tx et un autre en rx :
La deuxième commande n'écrase pas la première, mais la configuration s'additionne.
#### Encapsulation replicate
Par défaut, le port mirroring renvoie tout le trafic vers l'interface de destination de façon non étiqueté (sans aucun marquage de VLAN), et sans les protocoles de niveau 2 : CDP (Cisco Discovery Protocol), VTP (VLAN Trunking Protocol), DTP (Dynamic Trunk Protocol), STP (Spanning Tree Protocol) et PAgP (Port Aggregation Protocol).
En rajoutant le mot clef `encapsulation replicate`, les paquets sont envoyés en gardant le même étiquetage VLAN qu'à la source, et les protocoles de niveau 2 sont également copiés.
Si parmi les ports source, l'un est en mode trunk et l'autre est en mode access, seul la source en trunk est affectée par ce filtre.
#### Autoriser un IDS/IPS à agir sur ce qu'il voit
L'IDS/IPS derrière la destination du port mirroring peut être configuré pour agir sur ce qu'il reçoit, et être ainsi capable d'envoyer par exemple un reset d'une connexion TCP qu'il a detecté comme étant indésirable. Le port de destination doit alors être autorisé à recevoir des paquets de l'IDS/IPS :
Le Port-Channel est une technologie qui permet d’agréger plusieurs interfaces ensemble. Le trafic est ensuite réparti sur chacune des interfaces. Cette technologie permet une meilleure redondance, ainsi qu’une augmentation de la bande passante. L'utilisation de l'un ou l'autre lien ne dépend pas de la charge sur les liens mais uniquement de l'algorithme du protocole : même si un lien est surchargé, l'algorithme continuera à pouvoir envoyer du trafic dessus.
Cisco propose le protocole propriétaire PaGP, mais nous utilisons le protocole standardisé [LACP](https://fr.wikipedia.org/wiki/IEEE_802.3ad).
Voici un schéma d'exemple :
~~~
┌────────┐Gi0/1 Gi0/1┌────────┐
│ ├─────────────┤ │
│ SW01 │ │ SW02 │
│ ├─────────────┤ │
└────────┘Gi0/2 Gi0/2└────────┘
~~~
On veut agréger les interfaces Gi0/1 et Gi0/2 entre SW01 et SW02.
Sur SW01 et sur SW02, on active LACP sur les ports souhaités :
~~~
Switch(config)# interface range GigabitEthernet0/1-2
Switch(config-if)# channel-protocol lacp
Switch(config-if)# channel-group 1 mode active
~~~
La configuration des ports devra ensuite se faire sur l'interface port-channel nouvellement créé. Les interfaces physiques membres du port-channel hériteront automatiquement de la configuration.
~~~
Switch(config)# interface Port-channel1
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan X
Par défaut, CISCO n'autorise pas les modules GBIC non agréés, il faut donc désactiver la vérification des checksum des modules GBIC pour pouvoir les connecter :
Pour qu'il soit ré-activé automatiquement au bout d'un certain temps :
~~~
Switch# conf t
Switch(config)# errdisable recovery interval 600
Switch(config)# errdisable recovery cause gbic-invalid
~~~
En remplaçant `gbic-invalid` par la cause souhaitée.
La durée en secondes indiquée par la commande `interval` est globale à toutes les causes, et est la durée après laquelle le port sera automatiquement ré-activé après être passé en errdisable.
Le Dynamic Trunk Protocol (DTP) est un protocole permettant de négocier la création automatique de trunk sur une liaison. Pour en profiter, il faut passer l'interface soit en mode dynamic auto, soit en mode dynamic desirable :
L'utilisation de DTP (et donc du mode dynamic) est risquée car un serveur en face pourrait négocier un trunk et ainsi avoir accès à tous les vlans. Il est donc conseillé de ne jamais utiliser le mode dynamic.
Le DTP peut également être désactivé :
~~~
Switch(config-if)# switchport nonegotiate
~~~
Mais cette commande n'a pas d'intérêt dans le cas où le mode dynamic n'est pas utilisé. Attention cependant, désactiver cette option (`no switchport nonegotiate`) entraînera une coupure de 3 secondes de la liaison.
Lors d'une tempête de paquet, le LAN peut être fortement dégradé, voire devenir inaccessible. Pour empêcher ça, l'option `storm-control` peut être utilisée afin de limiter le trafic unicast inconnu, multicast, ainsi que broadcast entrant (depuis l'interface vers le switch). Par défaut, le storm-control est désactivé.
**Attention** : configurer le storm-control peut provoquer une coupure de quelques secondes sur l'interface où c'est configuré. Supprimer la configuration ne provoque pas de coupure.
Le `storm-control` se configure au niveau de l'interface sur laquelle la limitation doit être faite, peut utiliser 3 méthodes de détection différentes, et peut également définir 2 actions lors d'une détection :
Ici, on a défini le seuil haut du trafic broadcast à 60.26% de la bande passante disponible sur l'interface et le seuil bas à 49.37%. On a défini le seuil haut du trafic multicast à 500Mbps et le seuil bas à 400Mbps. On a défini le seuil haut du trafic unicast inconnu à 1Mpps et le seuil bas à 500kpps. On a également défini les actions `shutdown` et `trap` : lorsqu'un des 3 seuils est atteint, l'interface passe en `errdisable` (voir [#ré-activer-un-port-désactivé-par-errdisable]()) et une trap SNMP est envoyée.
Le seuil haut indique le seuil à partir duquel le trafic choisi doit être bloqué. Le seuil bas est facultatif et indique le seuil en dessous duquel le trafic choisi ne sera plus bloqué ; s'il n'est pas indiqué, alors le trafic ne sera plus bloqué dès qu'il sera en dessous du seuil haut. Seul le trafic du type en question est bloqué, pas le reste.
Par exemple, `broadcast level 60.26 49.37` indique que tout le trafic broadcast sera bloqué dès qu'il atteint 60.26% de la bande passante disponible sur l'interface, et le trafic broadcast ne sera plus bloqué dès qu'il sera en dessous de 49.37% de la bande passante disponible sur l'interface.
L'obtention des infos d'une interface se fait de la même façon que sur les Nexus. La seule différence est l'orthographe du mot "interface", qui ne prend pas le "s" à la fin, contrairement aux Catalyst :
Contrairement à IOS, sous NX-OS il faut d'abord activer la fonctionnalité "interface-vlan" avec la commande `feature interface-vlan` pour pouvoir configurer une SVI (Switch Virtual Interface).
### Configurer l'heure
* Gestion Daylight Savings Time (DST) :
~~~
Switch# conf t
Switch(config)# clock timezone UTC 1 0
Switch(config)# clock summer-time UTC 5 Sun Mar 02:00 5 Sun Oct 03:00
~~~
### Gérer les logs
* Avoir une présicion en microsecondes sur l’heure des logs :
~~~
Switch# conf t
Switch(config)# logging timestamp microseconds
~~~
* Ajouter la description de l'interface aux logs concernant une interface :
~~~
Switch# conf t
Switch(config)# logging message interface type ethernet description
~~~
* Envoyer les logs à un serveur syslog :
~~~
Switch# conf t
Switch(config)# logging server 192.0.2.10 7 facility local6
~~~
### Configurer SNMP
* Activer SNMP en écriture :
Si on veut limiter l’écriture SNMP par une IP source, et sur certains OID uniquement, il faut créer une `access-list` et un `rôle`, puis les indiquer à SNMP :
~~~
Switch# conf t
Switch(config)# ip access-list snmp-rw
Switch(config-acl)# 10 permit ip host 192.0.2.4 192.0.2.0/24 vlan 1 log
Le terme "trap" englobe 2 types de trap SNMP : les requêtes "trap" et les requêtes "inform". La différence est que pour une requête "trap", l'agent SNMP qui l'envoie n'a aucun moyen de savoir si le manager SNMP l'a bien reçue ou non, alors qu'une requête "inform" sera ré-émise par l'agent SNMP tant qu'il n'a pas reçu d'acknowledgement de la part du manager SNMP lui indiquant que la requête inform a bien été reçue.
Si on veut envoyer des traps SNMP de type `inform` à l'hôte `192.0.2.10`, en utilisant la version SNMP `2c` et la communauté SNMP `private`, et en activant toutes les traps :
~~~
Switch# conf t
Switch(config)# snmp-server host 192.0.2.10 informs version 2c private
La première désactive l'envoi de trap à chaque changement de configuration sur le switch, la deuxième désactive l'envoi de trap SNMP avec le contenu du log pour chaque syslog généré. Les troisième et quatrième désactivent l'envoi de trap SNMP au format étendu Cisco (OID `SNMPv2-SMI::enterprises.9.9.276.0.*`) lorsqu'une interface passe down ou up, pour ne garder que celles au format IETF (`IF-MIB`) plus claires.
* Synchro immédiate : Spanning Tree Portfast => Spanning Tree Port Type Edge
Le nom "portfast" n'existe pas sous Nexus, c'est une notion de "port type" qui est utilisé. Lorsque le port est connecté à une machine finale, c'est un port de type `edge` (de bord, d'extrémité).
Puis on applique les deux policy sur l'interface souhaitée :
~~~
Switch(config)# int eth1/1
Switch(config-if)# service-policy type queuing output 100M-output
Switch(config-if)# service-policy type qos input 100M-input
~~~
Le `queuing` correspond à du traffic shaping avec lequel les paquets qui dépassent le seuil configuré sont placés en buffer : la latence peut augmenter, mais les paquets ne sont pas perdus (tant qu'ils ne dépassent pas la taille du buffer). Quant à lui, le `qos` correspond à du policing, avec lequel les paquets qui dépassent le seuil configuré sont perdus. Le traffic shaping n'est possible qu'en sortie, on est donc obligé d'utiliser du policing en entrée.
> Note : "sortie" et "entrée" sont définis du point de vue du switch. Le trafic en entrée est celui émis par le client vers le switch (upload par le client), alors que le trafic en sortie est celui émis depuis le switch vers le client (download par le client).
Le Port-Channel est une technologie qui permet d'agréger plusieurs interfaces ensemble. Le trafic est ensuite réparti sur chacune des interfaces. Cette technologie permet une meilleure redondance, ainsi qu'une augmentation de la bande passante.
Cependant un Port-Channel doit se faire depuis un seul serveur vers un seul même switch.
Le Virtual Port-Channel permet de dépasser cette limitation en faisant un Port-Channel virtuel depuis un serveur vers 2 switchs différents. Les deux switchs continuent à être gérés et configurés indépendamment.
* **Switchs pairs VPC** : switchs faisant partie du groupe VPC.
* **Ports membres VPC** : machines (switch ou serveur) branchées à des pairs VPC de façon redondante.
* **Lien VPC peer-link** : lien physique permettant de connecter les 2 switchs pairs VPC et de transpoter les BPDUs et adresses MAC entre eux. Il sert également à transporter le trafic de niveau 2 entre les switchs pairs VPC, soit en cas de défaillance d'une liaison vers un port membre, soit lors de communications entre machines non membres VPC (fonction d'un lien inter-switch classique). Il doit donc être suffisament dimensionné pour supporter ce potentiel trafic.
* **Lien VPC keepalive** : lien physique permettant, dans le cas où le VPC peer-link est down et que les switchs ne pourraient donc plus communiquer à travers celui-ci, de détecter les pairs VPC en mode "tous actifs"/"tous primaires". Dans cette situation, on peut avoir des paquets dupliqués ou d'autres problèmes. Il est donc important de le détecter afin de réagir de façon appropriée. Les ports de management peuvent être utilisés pour créer ce lien.
* **Ports orphelins** : un port qui utilise un des VLANs transportés sur le VPC peer-link mais qui n'est pas un membre VPC. C'est le cas d'une machine branchée de façon volontaire sur un seul switch, sans Port-Channel.
Dans le cas où le lien **VPC peer-link** est down, le lien **VPC keepalive** le détecte, et le **pair VPC** secondary coupe tous ses ports allant vers des **membres VPC** afin d'éviter des boucles réseau. Par défaut, les **ports orphelins** ne seront pas coupés, mais peuvent l'être automatiquement si on le souhaite (voir configuration ci-dessous). Les pairs VPC primaire et secondaire sont déterminés par défaut d'après l'adresse MAC, ou par une priorité configurée manuellement.
Le serveur ne sait pas qu'il est branché sur 2 switchs différents, et croit être sur un Port-Channel classique. Une configuration en [LACP](HowtoDebian/Reseau#mode-802.3ad-lacp) est donc suffisante sur celui-ci.
Voici un schéma avec l'ensemble de ces composants :
* Cas de défaillance d'une liaison vers un port membre :
Imaginons que Serveur1 veuille communiquer avec Serveur2, et que l'algorithme de LACP sur Serveur1 décide d'envoyer le paquet sur l'interface allant vers SW01.
Si tout fonctionne correctement, alors le paquet partira de Serveur1 pour passer par SW01, et arriver depuis SW01 vers Serveur2.
Cependant, dans le cas où le lien entre Serveur2 et SW01 est down, alors le paquet partira de Serveur1 pour passer par SW01, puis passera par le VPC peer-link pour arriver sur SW02, et enfin arriver depuis SW02 vers Serveur2.
La commande `peer-switch` permet aux 2 switchs d'apparaître comme un seul même switch au niveau du protocole Spanning Tree, en leur faisant avoir le même bridge ID. En cas de perte de l'un des 2 switchs, cela permettra de n'avoir aucun recalcul de topologie Spanning Tree.
Enfin, pour chacun des serveurs, on configure les ports membres VPC. Pour faciliter la gestion, on utilise le numéro de port comme numéro de channel-group/port-channel et comme numéro de vpc :
La configuration des ports devra ensuite se faire sur les interfaces `port-channel` ; l'interface physique (ou les interfaces physiques, s'il y en a plusieurs) membre du port-channel héritera automatiquement de la configuration.
**Attention** : Lors du branchement si le VPC est déjà configuré, il faut brancher en premier le lien `peer-link`, et ensuite le lien `keepalive`, pour éviter que le VPC secondary ne coupe ses ports membres VPC le temps du branchement complet.
Dans notre cas, si le VPC peer-link est down, alors SW02 (qui est VPC secondary) coupera tous ses ports allant vers des membres VPC, soit Eth1/10 et Eth1/11. Serveur3 sera alors isolé et ne pourra communiquer qu'avec les autres éventuels ports orphelins.
Cependant si Serveur3 était configuré par exemple pour du bonding en mode active/backup ou en mode [ALB](HowtoDebian/Reseau#mode-alb) en étant branché à la fois sur SW01 et SW02, alors le failover ne se ferait pas pour Serveur3 et des problèmes de communications aurraient lieux. Dans ce cas, on souhaiterait que le lien entre Serveur3 et SW02 se coupe pour que la communication entre Serveur1, Serveur2 et Serveur3 fonctionne par SW01.
Ainsi, le port sera automatiquement coupé quand le VPC peer-link sera down, et sera automatiquement rétabli lorsque le VPC peer-link sera de nouveau up.
Lors d'une tempête de paquet, le LAN peut être fortement dégradé, voire devenir inaccessible. Pour empêcher ça, l'option `storm-control` peut être utilisée afin de limiter le trafic unicast inconnu, multicast, ainsi que broadcast entrant (depuis l'interface vers le switch). Par défaut, le storm-control est désactivé.
Le `storm-control` se configure au niveau de l'interface sur laquelle la limitation doit être faite et peut également définir 2 actions lors d'une détection :
Ici, on a défini le seuil du trafic broadcast à 43.62% de la bande passante disponible sur l'interface. On a défini le seuil du trafic multicast à 45.3% de la bande passante disponible sur l'interface. On a défini le seuil du trafic unicast inconnu à 42% de la bande passante disponible sur l'interface. On a également défini les actions `shutdown` et `trap` : lorsqu'un des 3 seuils est atteint, l'interface passe en `errdisable` (voir [#ré-activer-un-port-désactivé-par-errdisable]()) et une trap SNMP est envoyée.
Tout le trafic au-delà du seuil configuré pour le type de trafic choisi sera bloqué, mais celui en-dessous du seuil continuera à passer. Par exemple, `broadcast level 43.62` indique que seul 43.62% de la bande passante disponible sur l'interface peut être utilisée par du trafic broadcast, et le trafic broadcast au-dessus de ce seuil sera bloqué.
**Beaucoup de commandes sont similaires entre les Catalyst (IOS) et les Small Business. Si les commandes ne sont pas indiquées pour les Small Business, il est probable que ce soit les mêmes que celles des Catalyst.**
Les switchs Cisco Small Business Pro (par exemple, le modèle Cisco ESW 500) sont en fait d'anciens switchs Linksys. Ils n'ont pas de système IOS habituel.
Selon le modèle, la connexion par le port console ou par telnet donne seulement accès à un menu interactif permettant d'effectuer seulement quelques opérations de base. Dans ce cas, on préférera donc l'utilisation de l'interface HTTP.
Si souhaité, on peut sauvegarder le binaire actuel en sélectionnant "Backup Firmware" pour Operation Type", et "HTTP/HTTPS" pour "Copy Method", puis le téléchargement débute.
À la fin, l'interface web indique que l'opération a été terminée avec succès.
Il faut finir avec un redémarrage du switch pour que la mise à jour soit prise en compte. Il peut être fait depuis l'interface web dans le menu Administration > Reboot, ou en ligne de commande avec `reload`.
Après redémarrage, on vérifie que la version a bien été mise à jour :
Le switch doit tout d'abord avoir une IP configurée. On peut par exemple configurer une IP dans le VLAN 1 comme indiqué [ici](#affecter-une-adresse-ip-%C3%A0-un-vlan), puis affecter l'interface qui sera branchée au serveur TFTP à ce VLAN 1 en s'aidant de [cette partie](#affecter-des-interfaces-ports-%C3%A0-un-vlan).
2.**Installer un serveur TFTP**
Un serveur TFTP est nécessaire pour transférer le binaire vers le switch.
On configure le serveur sur l'utilisateur `nobody`, et on ajoute l'option `-c` pour autoriser la création de nouveaux fichiers sur le serveur. On place ensuite le binaire dans le répertoire TFTP.
3.**Copier le binaire vers le switch**
Si souhaité, on peut sauvegarder le binaire actuel vers le serveur TFTP :
Dans la section «VLAN Management > Interface Settings» il suffit de configurer un port, puis en cliquant sur «Copy settings» en bas de la page, de renseigner la plage de ports à laquelle appliquer la même configuration.
Probablement dans un souci de cohérence, c'est également possible mais avec une méthode totalement différente…
Dans la section «VLAN Management > Port to VLAN» sélectionner le VLAN ID désiré, et cliquer sur Go. Puis cocher «Untagged» au lieu de «Excluded» pour tous les ports désirés, et valider avec «Apply».
L'application des modifications est visible dans «VLAN Management > Port VLAN Membership»
Le terme "trap" englobe 2 types de trap SNMP : les requêtes "trap" et les requêtes "inform". La différence est que pour une requête "trap", l'agent SNMP qui l'envoie n'a aucun moyen de savoir si le manager SNMP l'a bien reçue ou non, alors qu'une requête "inform" sera ré-émise par l'agent SNMP tant qu'il n'a pas reçu d'acknowledgement de la part du manager SNMP lui indiquant que la requête inform a bien été reçue.
Si on veut envoyer des traps SNMP de type `inform` à l'hôte `192.0.2.10`, en utilisant la version SNMP `2c` et la communauté SNMP `private`, et en activant toutes les traps :
~~~
Switch# conf t
Switch(config)# snmp-server host 192.0.2.10 informs version 2c private
Switch(config)# snmp-server enable traps
~~~
Pour les Cisco SMB, il n'est pas possible de choisir ce qui doit envoyer ou pas une trap SNMP.
Pour avoir une liste des bugs connus, il faut chercher le modèle du switch et sa version actuelle sur <https://software.cisco.com/download/home>.
Une fois la version sélectionnée, un lien "Release Notes for XXX" est présent sous "Related Links and Documentation". Dans ces releases notes peuvent être indiqués les bugs connus sous le nom "Open Caveats" ou "Known Issues".
Plus d'infos sur un bug peuvent être trouvées sur <https://bst.cisco.com/bugsearch/> en indiquant son numéro
### Bug avec la commande "login on-success log"
Sur les Cisco Catalyst sous la version IOS `15.0(2a)EX5`, la commande `login on-success log` provoque un reboot du switch à chaque connexion d'un utilisateur.
### Bug lors de l'ajout d'un VLAN dans un trunk sur un peer-link entre 2 switchs en VPC
Ce bug a été constaté avec des switchs Nexus sous la version NXOS `7.0(3)I7(9)`, mais nous ne savons pas s'il est aussi présent sous d'autres versions ou pas.
Le bug se produit avec 4 switchs configurés en 2 paires VPC de 2 switchs, dans 2 domaines VPC différents :
~~~
┌───────────────────────────────────┐
│ VPC domain 1 │
│ │
│ │
│ ┌────────┐VPC peer-link┌────────┐ │
│ │ ├─────────────┤ │ │
│ │ SW01 │VPC keepalive│ SW02 │ │
│ │ ├─────────────┤ │ │
│ └───┬────┘ └────┬───┘ │
│ │ │ │
└─────┼───────────────────────┼─────┘
│ │
│ │
│ │
│ │
┌─────┼───────────────────────┼─────┐
│ │ │ │
│ ┌───┴────┐VPC peer-link┌────┴───┐ │
│ │ ├─────────────┤ │ │
│ │ SW03 │VPC keepalive│ SW04 │ │
│ │ ├─────────────┤ │ │
│ └────────┘ └────────┘ │
│ │
│ │
│ VPC domain 2 │
└───────────────────────────────────┘
~~~
Lorsque l'un des 2 liens entre `SW01-SW03` ou `SW02-SW04` est coupé (port `shut`, fibre coupée, fibre non présente, …) et que l'on ajoute un VLAN autorisé dans le trunk sur le VPC peer-link d'une paire, alors certaines destinations deviennent inaccessibles par certaines sources.
Par exemple :
Le lien entre `SW01-SW03` est coupé pour une raison quelconque. Les machines `serveur1` et `serveur2` sont branchés en LACP à l'aide du VPC à la fois sur `SW01` et `SW02`. Les machines `serveur3` et `serveur4` sont branchés en LACP à l'aide du VPC à la fois sur `SW03` et `SW04`.
Les liens peer-link entre `SW01-SW02` et `SW03-SW04` sont configurés en trunk, avec seulement certains VLANs autorisés. Sur le lien peer-link `SW01-SW02`, je souhaite autoriser un nouveau VLAN :
À partir de ce moment-là, le bug apparaît (il n'y a pas besoin de faire la même commande sur SW02 pour que le bug apparaîsse, et il apparaît peu importe le switch sur lequel la commande est faite) : les 4 machines n'arriveront plus à communiquer correctement. Par exemple, `serveur1` n'arrivera plus à parler à `serveur3` mais arrivera à parler à `serveur4` (et inversement), et `serveur2` n'arrivera plus à parler à `serveur4` mais arrivera à parler à `serveur3` (et inversement).
Le fait de revenir en arrière en levant le VLAN 10 autorisé n'y changera rien.
Le bug disparaîtra soit après un reboot de `SW02` (switch paire de celui sur lequel la configuration a été modifiée, et sur lequel la liaison vers l'autre domaine VPC est toujours UP), soit dès que le lien `SW01-SW03` sera de nouveau opérationel, et ne ré-apparaîtra pas si le lien est de nouveau coupé. Il n'y a aucun problème lorsque l'on ajoute un VLAN autorisé dans le trunk et qu'aucun des 2 liens n'est coupé. Le bug ré-apparaîtra seulement si un VLAN est ajouté aux autorisations lorsqu'un des liens `SW01-SW03` ou `SW02-SW04` est coupé.
