Vue normale

Reçu avant avant-hier Réseau

Just-Sudo-It.be

9 août 2023 à 19:26

Peut-être vous intéressez-vous à l’univers Linux … Si tel est le cas, vous pourriez avoir envie de jeter un œil à mon nouveau blog: just-sudo-it.be.

Depuis plusieurs années , je travaille très régulièrement dans des environnement Linux. Plus récemment j’ai également donné des cours d’Administration Linux…. Cheminement qui ressemble très fort à ce que j’avais fait au départ pour les réseaux. Quoi de plus logique dans ce cas que de partager mes connaissances également dans ce domaine ?

Voilà qui est chose faite via mon nouveau blog, flambant neuf … just-sudo-it.be !

Allez y jeter un œil si le cœur vous en dit. Il est encore tout jeune et encore un peu pauvre en contenu, mais j’y travaille 😉

Comprendre et configurer le Port-Security sur un switch Cisco.

11 juin 2023 à 20:54

Le « port-security » est une fonctionnalité des switches Cisco permettant de sécuriser un port d’accès (auquel est connecté une station de travail, un serveur,…) en contrôlant les adresses MAC source des trames Ethernet qui arrivent sur le port en question. En cas de violation une action sera prise.

Les application de cette fonctionnalité sont multiples:

  • Limiter le nombre de machines pouvant être connectées à un port du switch.
  • Restreindre l’accès au réseau à une machine spécifique.
  • Empêcher le spoofing d’adresse MAC.
  • etc.

Imaginons par exemple le cas d’un switch d’accès auquel ne devrait en principe être connecté une et une seule machine à chaque port, mais qu’un utilisateur ait décidé d’intercaler un autre switch pour pouvoir connecter plus de machines dans son bureau.

Du point de vue de switch de l’entreprise, il ne devrait y avoir qu’une seule adresse MAC associée à chacun des différents ports, l’adresse MAC de la machine connectée. Hors ici, sur l’interface Gi0/4, le switch recevra des trames de trois adresses MAC sources différentes.

Pour empêcher ce genre de détournement, on utilisera le « port-security » notamment pour limiter le nombre d’adresse MAC que le switch peut apprendre sur un port donnée, et si cette limite est transgressée, des mesures seront prises.

Le principe du port-security

Lorsque le port-security est activé sur un port du switch, chaque trame qui y entre sera vérifiée sur base de son adresse MAC source pour déterminer si une violation de sécurité a eu lieu ou non.

Les violations de sécurités peuvent être déterminées sur bases de plusieurs éléments:

  • Le nombre maximal d’adresses MAC source que le switch peut accepter sur le port concerné.
  • La « valeur » de l’adresse MAC

Le port-security offre trois modes de réaction qui définissent les actions effectuées lorsqu’une violation est détectée:

  • Filtrer (bloquer) les trames illicites.
  • Incrémenter un compteur de violations pour le port concerné.
  • Générer un message de LOG et SNMP.
  • Désactiver le port du switch et le placer dans un état spécifique: « error-disabled ».

Le tableau ci-dessous reprend les actions prises par chacun des trois modes existants:

MODEFiltre les trames illicitesIncrémente le compteur de violation
Génère un message de LOG et SNMP
Place le port en « error-disabled »
ProtectOUINONNON
RestrictOUIOUINON
ShutdownOUIOUIOUI

Notez qu’il est important de comprendre qu’un port placé en état « error-disabled » est réellement désactivé, plus aucun trafic ne passera, il faudra réinitialiser le port en question pour qu’il redevienne actif.

Configuration du port-security

Avant toute chose il faut définir statiquement le mode de fonctionnement du port, soit en mode « access », soit en mode « trunk ». Si vous essayez de configurer le port-security sur un port en mode dynamique (par défaut les ports sont généralement en mode « dynamic auto ») le switch vous affichera le message d’erreur suivant:

SW1(config)#interface g0/1
SW1(config-if)#switchport port-security
Command rejected: GigabitEthernet0/1 is a dynamic port.
SW1(config-if)#

Bien qu’il soit possible de configurer du port-security sur un trunk, c’est, la plupart du temps, une entreprise très délicate. Il faut être en mesure de connaître exactement le nombre d’adresses MAC qui peuvent passer sur le lien, ce qui, pour un trunk, est plutôt rare. Donc généralement, le port-security sera appliqué sur un port en mode « access ».

Première étape: définir le mode de fonctionnement du port

switch(config-if)# switchport mode <access|trunk>

Deuxième étape: activer le port-security

switch(config-if)# switchport port-security

Sans cette commande le port-security ne sera pas actif.

Troisième étape: définir les paramètres et mode du port-security

switch(config-if)# switchport port-security maximum <n>
switch(config-if)# switchport port-security violation <protect|restrict|shutdown>

Le première commande défini le nombre maximum d’adresses MAC source pouvant être acceptées par le switch sur le port. La seconde commande défini le mode de réaction (voir plus haut).

Par défaut le nombre maximum d’adresse MAC est de 1 et le mode est « shutdown ».

Etapes optionnelles

En soi le port-security n’empêche pas de déconnecter une machine et d’en mettre une autre à la place et ce tout simplement parce que les entrées de la table d’adresses MAC associées à une interface sont vidées lorsque l’interface passe « down ».

Pour palier à ce problème, il est possible de configurer le port pour que le switch enregistre dans sa configuration (running-config) toute adresse apprise sur un port où le port-security est activé.

switch(config-if)# switchport port-security mac-address sticky

Une fois activée, cette fonctionnalité permettra au switch d’enregistrer de manière statique dans sa configuration les entrées d’adresses MAC jusqu’au nombre maximum autorisé sur l’interface. Moyennant une sauvegarde de la configuration, ces entrées perdureront même en cas de redémarrage de l’équipement.

Notez qu’il faut que de trafic entre sur l’interface du switch pour que le sticky puisse faire effet, et dans le cas présent, premier arrivé, premier servi. Donc il est nécessaire de s’assurer que ce sont bien les machines légitimes qui sont connectées au switch.

Voici un exemple d’entrées ajoutées par la fonctionnalité sticky dans la configuration d’un switch:

interface GigabitEthernet0/1
 switchport mode access
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky
 switchport port-security mac-address sticky 0050.7966.6800
 switchport port-security mac-address sticky 0050.7966.6801
 switchport port-security

Il est également possible de configurer manuellement les adresses MAC à autoriser. C’est un travail fastidieux mais qui peut prendre du sens si on parle de ports auxquels sont attachés des machines fixes comme des serveurs.

switch(config-if)# switchport port-security mac-address <mac-address>

L’effet sera exactement le même que les adresses auto enregistrées avec l’option sticky mais ne dépend pas du trafic qui passer pour la découverte de l’adresse MAC.

Vérification du port-security

La commande « show port-security » vous permet rapidement de résumer la configuration du port-security et de l’état actuel des interfaces:

SW1#show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Gi0/0              1            1                  0         Shutdown
      Gi0/1              2            2                  0         Restrict
      Gi0/2              3            0                  0         Restrict
      Gi0/3              1            0                  0          Protect
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 1
Max Addresses limit in System (excluding one mac per port) : 4096
SW1#

Les différentes colonnes:

  • Secure Port: le nom de l’interface
  • MaxSecureAddr: le nombre d’adresses autorisées sur le port
  • CurrentAddr: le nombre d’adresses MAC actuellement associées au port
  • SecurityViolation: le compteur de violations du port
  • Security Action: le mode de réaction configuré

Une interface qui n’apparaît pas dans cette liste n’a pas de port-security activé.

Mise en pratique

Voici un récapitulatif de ce qu’il faut configurer sur un switch donné:

PortsVlanPortSecurity MaxPortSecurity ModeSticky
Gi0/0 – Gi0/3101ShutdownOui
Gi1/0 – Gi1/3201RestrictNon
Gi2/0 – Gi2/3302ProtectNon
Gi3/0 – Gi/3/3403RestrictOui

La configuration correspondante:

SW1(config)#interface range g0/0-3
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 10
SW1(config-if-range)#switchport port-security
SW1(config-if-range)#switchport port-security maximum 1
SW1(config-if-range)#switchport port-security violation shutdown
SW1(config-if-range)#switchport port-security mac-address sticky
SW1(config-if-range)#exit
SW1(config)#
SW1(config)#interface range g1/0-3
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 20
SW1(config-if-range)#switchport port-security
SW1(config-if-range)#switchport port-security maximum 1
SW1(config-if-range)#switchport port-security violation restrict
SW1(config-if-range)#exit
SW1(config)#
SW1(config)#interface range g2/0-3
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 30
SW1(config-if-range)#switchport port-security
SW1(config-if-range)#switchport port-security maximum 2
SW1(config-if-range)#switchport port-security violation protect
SW1(config-if-range)#exit
SW1(config)#
SW1(config)#interface range g3/0-3
SW1(config-if-range)#switchport mode access
SW1(config-if-range)#switchport access vlan 40
SW1(config-if-range)#switchport port-security
SW1(config-if-range)#switchport port-security maximum 3
SW1(config-if-range)#switchport port-security violation restrict
SW1(config-if-range)#switchport port-security mac-address sticky
SW1(config-if-range)#end
SW1#

Dans le cas présent, j’ai inclus les commandes pour définir le maximum à 1 ou le mode à shutdown par souci de clarté, mais dans les faits, vu que ce sont les valeurs par défaut, il n’est pas nécessaire de les configurer.

Et voici la vérification de la configuration:

SW1#show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Gi0/0              1            0                  0         Shutdown
      Gi0/1              1            0                  0         Shutdown
      Gi0/2              1            0                  0         Shutdown
      Gi0/3              1            0                  0         Shutdown
      Gi1/0              1            0                  0         Restrict
      Gi1/1              1            0                  0         Restrict
      Gi1/2              1            0                  0         Restrict
      Gi1/3              1            0                  0         Restrict
      Gi2/0              2            0                  0          Protect
      Gi2/1              2            0                  0          Protect
      Gi2/2              2            0                  0          Protect
      Gi2/3              2            0                  0          Protect
      Gi3/0              3            0                  0         Restrict
      Gi3/1              3            0                  0         Restrict
      Gi3/2              3            0                  0         Restrict
      Gi3/3              3            0                  0         Restrict
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 0
Max Addresses limit in System (excluding one mac per port) : 4096
SW1#

Que se passe-t-il en cas de violation de sécurité ?

Bien évidemment tout dépend du mode de fonctionnement:

  • En mode « protect », les trames illicites seront rejetées. C’est tout.
  • En mode « restrict », en plus de rejeter les trames, le compteur de violation sera incrémenté et un message de log sera généré.
  • En mode « shutdown », en plus des précédentes actions, le port sera placé dans un état spécial: « error-disabled ».

Voici un exemple de message de log d’une violation de sécurité sur un port configuré en mode « restrict »:

*Jun 11 20:28:50.094: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0050.7966.6801 on port GigabitEthernet1/1.

On retrouve alors le nombre de violations avec la commande « show port-security »

SW1#show port-security
Secure Port  MaxSecureAddr  CurrentAddr  SecurityViolation  Security Action
                (Count)       (Count)          (Count)
---------------------------------------------------------------------------
      Gi0/0              1            1                  1         Shutdown
      Gi0/1              1            0                  0         Shutdown
      Gi0/2              1            0                  0         Shutdown
      Gi0/3              1            0                  0         Shutdown
      Gi1/0              1            0                  0         Restrict
      Gi1/1              1            1                  5         Restrict
      Gi1/2              1            0                  0         Restrict
      Gi1/3              1            0                  0         Restrict
      Gi2/0              2            0                  0          Protect
      Gi2/1              2            0                  0          Protect
      Gi2/2              2            0                  0          Protect
      Gi2/3              2            0                  0          Protect
      Gi3/0              3            0                  0         Restrict
      Gi3/1              3            0                  0         Restrict
      Gi3/2              3            0                  0         Restrict
      Gi3/3              3            0                  0         Restrict
---------------------------------------------------------------------------
Total Addresses in System (excluding one mac per port)     : 0
Max Addresses limit in System (excluding one mac per port) : 4096
SW1#

Comme vous pouvez le voir dans cette dernière commande l’interface Gi0/0 a également un compteur de violation qui a été incrémenté. Mais de une unité seulement. Etant donné que cette interface est en mode « shutdown » elle devrait être placée en état « error-disabled ». On peut le vérifier avec la commande « show interfaces status err-disabled »:

SW1#show interfaces status err-disabled

Port      Name               Status       Reason               Err-disabled Vlans
Gi0/0                        err-disabled psecure-violation
SW1#

L’état est visible avec n’importe quelle variante du « show interface »:

SW1#show interfaces g0/0
GigabitEthernet0/0 is down, line protocol is down (err-disabled)
  Hardware is iGbE, address is 0cd8.fffc.0000 (bia 0cd8.fffc.0000)
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Auto Duplex, Auto Speed, link type is auto, media type is RJ45
  output flow-control is unsupported, input flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:07:32, output 00:07:33, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/0 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     14 packets input, 1098 bytes, 0 no buffer
     Received 6 broadcasts (6 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 6 multicast, 0 pause input
     1734 packets output, 135925 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     3 lost carrier, 0 no carrier, 0 pause output
     0 output buffer failures, 0 output buffers swapped out
SW1#
SW1#show interfaces status

Port      Name               Status       Vlan       Duplex  Speed Type
Gi0/0                        err-disabled 10           auto   auto RJ45
Gi0/1                        notconnect   10         a-full   auto RJ45
Gi0/2                        notconnect   10         a-full   auto RJ45
Gi0/3                        notconnect   10         a-full   auto RJ45
Gi1/0                        notconnect   20         a-full   auto RJ45
Gi1/1                        connected    20         a-full   auto RJ45
Gi1/2                        notconnect   20         a-full   auto RJ45
Gi1/3                        notconnect   20         a-full   auto RJ45
Gi2/0                        notconnect   30         a-full   auto RJ45
Gi2/1                        notconnect   30         a-full   auto RJ45
Gi2/2                        notconnect   30         a-full   auto RJ45
Gi2/3                        notconnect   30         a-full   auto RJ45
Gi3/0                        notconnect   40         a-full   auto RJ45
Gi3/1                        notconnect   40         a-full   auto RJ45
Gi3/2                        notconnect   40         a-full   auto RJ45
Gi3/3                        notconnect   40         a-full   auto RJ45
SW1#

Réactiver une interface « err-disabled »

Pour réactiver une interface placée en « err-disabled », il y a deux solutions, manuellement ou à l’aide du mécanisme « err-disable recovery ».

Réactiver manuellement

Avant toute chose il faut s’assurer que la cause a été identifiée et éliminée. Sans quoi l’interface repassera rapidement en « err-disabled ».

Une fois celà fait, il suffit d’effectuer un « shutdown/no shutdown » sur l’interface.

SW1(config)#interface g0/0
SW1(config-if)#shutdown
SW1(config-if)#no shutdown

Le « shutdown » a son importance. Il faut passer l’interface en « shutdown » sans quoi le « no shutdown » n’aura pas d’effet.

Réactiver automatiquement à intervalle régulier

Les switches Cisco disposent d’un mécanisme de réactivation automatique à intervalle régulier pour les ports qui seraient placés en « err-disabled » (que ce soir par le port-security, BPDUGuard ou autres).

Il faut définir les causes de « err-disabled » à prendre en charge et l’intervalle entre les tentatives (entre 30 et 86400 secondes):

SW1(config)#errdisable recovery cause psecure-violation
SW1(config)#errdisable recovery interval 30

Ces commandes définissent la tentative de réactivation des ports en « err-disabled » pour cause de violation de port-security avec un intervalle de 30 secondes entre chaque vérification.

PPP Multilink : Agrégation de liaisons sérielles PPP

25 mai 2016 à 09:11

Cela faisait bien longtemps que je n’avais plus posté de nouveau contenu, mais avec l’arrivée de la nouvelle CCNA, de nouveaux sujets apparaissent et me donnent donc de nouvelles idées d’articles…

Parmi les nouveaux sujets de la CCNAv3 … ou du nouvel examen ICND2 (200-105) se trouve la configuration d’agrégation de liens sériels PPP, aussi connu sous le nom de PPP Multilink.

A l’instar des Etherchannel en Ethernet, le PPP Multilink permet de regrouper virtuellement plusieurs liaisons sérielles en une seule interface virtuelle avec pour principaux objectifs l’augmentation de bande passante et la gestion de la redondance.

Qu’est-ce que le PPP Multilink ?

Il s’agit d’un protocole standard qui permet l’agrégation de liaisons PPP en un seul lien PPP. Les liaisons groupées peuvent être de tout type, ISDN, T1, ou tout autre type qui supporte le protocole PPP de base. La configuration multilink doit être effectuée des deux côtés de la liaison, ce qui implique que les différents liens doivent relier les deux mêmes équipements.

La topologie

Pour la démonstration, j’utilise ici deux routeurs interconnectés par deux liaisons sérielles. L’objectif sera donc de les combiner en une interface Multilink que l’on configurera ensuite comme n’importe quelle interface.

La configuration

Pour configurer ce multilink PPP, il faut passer par deux étapes majeures:

  1. Créer l’interface virtuelle Multilink
  2. Configurer les interfaces sérielles à intégrer dans le bundle.

Configuration sur R1

R1#configure terminal
!!!! Création de l'interface Multilink !!!!
R1(config)#interface multilink 1
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#ip address 192.168.0.1 255.255.255.252
R1(config-if)#exit
R1(config)#
!!!! Intégration de l'interface s0/0 dans le bundle
R1(config)#interface serial 0/0
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#
!!!! Intégration de l'interface s0/1 dans le bundle
R1(config)#interface serial 0/1
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink
R1(config-if)#ppp multilink group 1
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#

Parmi les détails importants… Il faut bien entendu que le numéro de groupe multilink indiqué dans la configuration des interfaces corresponde. Comme le montre cette configuration, les interfaces S0/0 et s0/1 ne sont pas adressées. Elles ne servent plus que de liaison physique. L’adressage se fait sur l’interface multilink.

Notez également que si vous devez utiliser un protocole de routage, un processus de NAT ou tout autre élément qui interviendrait au niveau du routage de cette interface, c’est l’interface multilink qui devra être référencée.

Configuration sur R2

R2#configure terminal
!!!! Création de l'interface Multilink !!!!
R2(config)#interface multilink 1
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#ip address 192.168.0.2 255.255.255.252
R2(config-if)#exit
R2(config)#
!!!! Intégration de l'interface s0/0 dans le bundle
R2(config)#interface serial 0/0
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#
!!!! Intégration de l'interface s0/1 dans le bundle
R2(config)#interface serial 0/1
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink
R2(config-if)#ppp multilink group 1
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#

La configuration est quasiment identique, bien entendu. Notez que le numéro de l’interface multilink ne doit pas être forcément le même que sur l’autre routeur. Il en va de même pour le numéro de groupe multilink. Il n’y a pas non plus de relation entre le numéro de l’interface multilink et le numéro du groupe.

Test de communication

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/12 ms
R1#

Pas de surprise… tout fonctionne!

Vérification de la configuration

R1#show interface serial 0/0
Serial0/0 is up, line protocol is up
 Hardware is GT96K Serial
 MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, LCP Open, multilink Open
 Link is a member of Multilink bundle Multilink1, loopback not set
 Keepalive set (10 sec)
 CRC checking enabled
 Last input 00:00:09, output 00:00:03, output hang never
 Last clearing of "show interface" counters 00:13:07
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: weighted fair [suspended, using FIFO]
 FIFO output queue 0/40, 0 drops
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 163 packets input, 5310 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 183 packets output, 5770 bytes, 0 underruns
 0 output errors, 0 collisions, 6 interface resets
 0 unknown protocol drops
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions
 DCD=up DSR=up DTR=up RTS=up CTS=up
R1#

L’interface fonctionne bien en PPP, et est membre du groupe multilink 1.

R1#show interface multilink 1
Multilink1 is up, line protocol is up
 Hardware is multilink group interface
 Internet address is 192.168.0.1/30
 MTU 1500 bytes, BW 3088 Kbit/sec, DLY 100000 usec,
 reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation PPP, LCP Open, multilink Open
 Open: IPCP, CDPCP, loopback not set
 Keepalive set (10 sec)
 DTR is pulsed for 2 seconds on reset
 Last input 00:00:31, output never, output hang never
 Last clearing of "show interface" counters 00:17:23
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 29 packets input, 5944 bytes, 0 no buffer
 Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
 29 packets output, 6266 bytes, 0 underruns
 0 output errors, 0 collisions, 1 interface resets
 0 unknown protocol drops
 0 output buffer failures, 0 output buffers swapped out
 0 carrier transitions
R1#

Remarquez ici la bande passante de l’interface qui reprend la valeur combinée des deux interfaces physiques (2x 1544kbits/s).

R1#show ppp multilink

Multilink1
 Bundle name: R2
 Remote Endpoint Discriminator: [1] R2
 Local Endpoint Discriminator: [1] R1
 Bundle up for 00:26:33, total bandwidth 3088, load 1/255
 Receive buffer limit 24000 bytes, frag timeout 1000 ms
 0/0 fragments/bytes in reassembly list
 0 lost fragments, 37 reordered
 0/0 discarded fragments/bytes, 0 lost received
 0x5C received sequence, 0x5C sent sequence
 Member links: 2 active, 0 inactive (max not set, min not set)
 Se0/0, since 00:26:34
 Se0/1, since 00:26:03
No inactive multilink interfaces
R1#

Ici vous retrouvez l’état du lien multilink. vous retrouvez les interfaces qui font partie du bundle, ainsi que les informations relatives au nom de l’équipement distant et des compteurs pour le nombre de paquets transmis, détruits, …

Conclusion

La configuration de base d’une liaison multilink PPP est assez simple et intuitive. Elle permet en outre d’augmenter la bande passante de la liaison sans rendre la topologie plus complexe. Notez toutefois qu’il s’agit ici d’une configuration tout ce qu’il y a de plus basique, il est bien entendu possible de configurer l’authentification, ou encore de paramétrer la répartitions des données sur les liens.

VLAN Access-List (VACL)

28 juillet 2015 à 12:33

Les ACLs (Access Control Lists) traditionnelles, aussi parfois appelées RACL (Router-based ACL) nous permettent de filtrer du trafic qui passe d’un réseau à un autre, donc dans le cas de VLANs, … le trafic qui est routé d’un VLAN à l’autre. En aucun cas celles-ci ne permettent de filtrer le trafic qui circule au sein d’un VLAN. Pourtant … c’est faisable…

Pour cela on fait appel aux VACLs (Vlan Access Control List), celles-ci, une fois appliquées à un VLAN vont nous permettre d’autoriser ou non la propagation d’une trame et même éventuellement de contrecarrer la logique de commutation du switch en redirigeant celle-ci vers une interface spécifique.

Voici comment configurer ces VACLs…

La topologie

vacl

Nous avons ici trois routeurs, qui serviront ici de simples hôtes dans un VLAN.

  • R1 : 192.168.0.1/24
  • R2 : 192.168.0.2/24
  • R3 : 192.168.0.3/24

Le switch (c3750-1) est ici l’unique élément intéressant. Afin de concentrer le config sur les VACLs, tous les ports de celui-ci sont placées dans le VLAN10, en mode accès.

Configuration initiale du switch

3750-1(config)#vlan 10
3750-1(config-vlan)#exit
3750-1(config)#interface range fastEthernet1/0/1-24
3750-1(config-if-range)#switchport mode access
3750-1(config-if-range)#switchport access vlan 10
3750-1(config-if-range)#spanning-tree portfast
3750-1(config-if-range)#exit

Petits tests de routine, R1,R2 et R3 doivent pouvoir communiquer sans problème…

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
R1#ping 192.168.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
R2#ping 192.168.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R2#

Passons maintenant aux VACLs…

Objectif de la configuration

Alors que sans VACLs, les trois routeurs peuvent communiquer entre eux sans problème, nous allons faire en sorte que R1 puisse communiquer avec R2 et R3 … mais que R2 et R3 ne puissent pas communiquer entre eux.

Configuration de la VACL

De manière générale, une VACL fonctionne sur un principe similaire à celui des route-maps. Il s’agit d’une liste ordonnée de règles, chacune ayant un numéro de séquence. Pour chacune de ces règles nous devons identifier le trafic correspondant à laide d’une clause « match », à laquelle nous ferons correspondre une « action » qui peut être l’une des trois suivantes:

  • forward: le trafic est traité normalement en suivant la logique de commutation du switch.
  • drop: le trafic est rejeté.
  • redirect: le trafic est redirigé vers une interface spécifique, indépendamment de la logique de commutation du switch.

Les clauses « match » utilisent des ACL (soit IP, soit MAC). C’est donc par là que nous devrons commencer.

Chose importante… A l’instar d’une ACL classique, les VACL rejettent tout ce qui n’est pas permis. Une VACL sans règle « forward » bloquera tout simplement tout le trafic dans le vlan donné.

Etape n°1 : Créer une ACL (classique) pour identifier le trafic à traiter

Attention à la confusion, l’ACL sert ici à identifier un trafic spécifique. Il faut donc qu’une règle « permit » corresponde à ce que l’ont souhaite rejeter ou autoriser, indépendamment de l’action. Ici, ce que nous voulons identifier, c’est le trafic entre R2 et R3, parce que nous voulons le bloquer. Donc il faut une règle permit qui y corresponde.

3750-1(config)#ip access-list extended VLAN10
3750-1(config-ext-nacl)#permit ip host 192.168.0.2 host 192.168.0.3
3750-1(config-ext-nacl)#permit ip host 192.168.0.3 host 192.168.0.2
3750-1(config-ext-nacl)#exit

Etape n°2 : Créer la VACL pour associer des « match » à des « action »

Nous allons donc créer ici une Vlan Access Map (l’élément qui combine les matches avec les actions), munie de deux règles.

  1. Le trafic correspondant à l’ACL VLAN10 doit être « droppé » (n° de séquence 10)
  2. Le reste du trafic doit être « forwardé » (n° de séquence 20)
3750-1(config)#vlan access-map VMAP-VLAN10 10
3750-1(config-access-map)#match ip address VLAN10
3750-1(config-access-map)#action drop
3750-1(config-access-map)#exit
3750-1(config)#vlan access-map VMAP-VLAN10 20
3750-1(config-access-map)#action forward
3750-1(config-access-map)#exit

Etape n°3 : Appliquer la VACL au(x) VLAN(s) désiré(s)

Il ne reste plus qu’à appliquer ces règles au Vlan 10.

3750-1(config)#vlan filter VMAP-VLAN10 vlan-list 10

Test de la configuration

Si tout se passe comme prévu, un ping entre R1 et R2, ou entre R1 et R3 devrait fonctionner, tandis que entre R2 et R3, le trafic devrait être bloqué…

R1#ping 192.168.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
R1#
R1#ping 192.168.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
R1#
R2#ping 192.168.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R2#

Tout fonctionne comme prévu! Nous arrivons donc bien ici à filtrer du trafic au sein du VLAN10, chose impossible avec les ACLs classiques.

Authentification 802.1X sur un réseau Ethernet (Port-Based Authentication) – WS-C2950 vs WS-C3750

25 juillet 2015 à 18:32

cisco-catalyst-2950-switchSur tout bon switch  qui se respecte il est possible de configurer de l’authentification des clients afin de sécuriser la connectivité au réseau. Pour faire simple, lorsqu’une machine est connectée au réseau (physique), le switch attend une authentification de la part de l’utilisateur (ou de la machine) avant que l’interface ne devienne fonctionnelle.

Pour arriver à ça, on utilise d’une part les fonctionnalités AAA (Authentication, Authorization & Accounting) des switches ansi qu’un protocole de communication, soit TACACS+(propriétaire Cisco) soit Radius avec extensions EAP (protocole standard). Cette méthode porte le doux nom de IEEE 802.1x … ou … pour les intimes … Dot1x 😉

Bien que le principe de configuration soit assez simple, il s’avère généralement assez délicat à mettre en oeuvre et ce principalement en raison des différentes implémentations du protocole Radius chez les différents fabricants. Voici un petit retour d’expérience personnelle, moyennant quelques explications sur la configuration…

Topologie de la configuration

Afin de comparer le fonctionnement de deux équipements différents, j’ai utilisé un WS-C3750 et un WS-C2950, interconnectés par un Trunk dot1Q. Le Vlan20 reçoit les clients qui devront s’authentifier, tandis que le Vlan10 héberge le serveur radius.

Pour que tout cela fonctionne, il faut uniquement que les clients soient connectés aux switches et que ceux-ci puissent communiquer avec le serveur radius. C’est la raison pour laquelle chaque switch a une SVI VLAN10 (interface Vlan 10) adressée.

Pré-requis:

  • Un serveur Radius
  • Un switch supportant Dot1x et le « Port-Based Authentication »
  • Une communication IP fonctionnelle entre les deux entités (Radius <-> Switch)

Configuration du serveur Radius:

Je ne vais pas ici vous faire un step-by-step, étant donné que chaque serveur Radius a ses propres spécificités. Par contre je peux lister dans les grandes lignes ce qui est nécessaire de configurer:

  • Un client radius par switch (les switches qui font appel au service d’authentification), avec au minimum une adresse IP ( « 10.0.0.1 » et  « 10.0.0.2 » ) ainsi qu’une clé d »authentification ( « ciscomadesimple » ).
  • Au moins un utilisateur qui permettra à la machine client de s’identifier et d’avoir accès au réseau (login: « cmsbe », pwd: « userpwd »).
  • Assurez-vous des ports utilisés par le serveur radius. Il y en a en général deux. Le premier pour l’authentification/authorisation, le second pour l’accounting. (dans mon cas, auth: UDP 1812, acct: UDP 1813).

Configuration du WS-C2950 (le plus ancien des deux)

  1. Configuration de base du switch
    c2950(config)#vlan 10,20
    c2950(config-vlan)#exit
    c2950(config)#interface fastEthernet0/24
    c2950(config-if)#switchport mode trunk
    c2950(config-if)#exit
    c2950(config)#interface range fastEthernet0/1 - 23
    c2950(config-if-range)#switchport mode access
    c2950(config-if-range)#switchport access vlan 20
    c2950(config-if-range)#spanning-tree portfast
    c2950(config-if-range)#exit
    c2950(config)#interface vlan 10
    c2950(config-if)#ip address 10.0.0.2 255.255.255.0
    c2950(config-if)#no shutdown
    c2950(config-if)#exit
  2. Activer les fonctionnalités AAA globalement
    c2950(config)#aaa new-model
  3. Configurer les informations relatives au serveur radius
    c2950(config)#radius-server host 10.0.0.10 auth-port 1812 acct-port 1813 key ciscomadesimple
  4. Configurer la méthode d’authentification dot1x globale
    c2950(config)#aaa authentication dot1x default group radius
  5. Activer le service d’authentification des ports
    c2950(config)#dot1x system-auth-control
  6. Configurer les ports
    c2950(config)#interface range fastEthernet0/1 - 23
    c2950(config-if)#dot1x port-control auto
    c2950(config-if)#end

Pour le WS-C2950 tout se passe comme prévu (comme c’est écrit dans les bouquins 🙂 ),  aucun souci, il suffit d’appliquer la doc à la lettre.

Machine client connectée (un MacBook), quelques secondes  et hop … une fenêtre qui demande d’entrer les login et mot de passe. Vient ensuite autour d’une machine Windows 7 … n’espérez pas que cela fonctionne sans avoir au préalable activé manuellement le service d’authentification réseau (« Wired AutoConfig » ou « Configuration automatique de réseau câblé »). Une fois cela fait, dés que la machine est branchée sur le switch, même comportement, un popup, on entre les infos et c’est parti.

Configuration du WS-C3750

  1. Configuration de base du switch
    c3750(config)#vlan 10,20
    c3750(config-vlan)#exit
    c3750(config)#interface fastEthernet1/0/24            ! Port trunk vers c2950
    c3750(config-if)#switchport trunk encapsulation dot1q ! remarque (1)
    c3750(config-if)#switchport mode trunk
    c3750(config-if)#exit
    c3750(config)#interface fastEthernet1/0/23            ! Port connecté au serveur radius
    c3750(config-if)#switchport mode access
    c3750(config-if)#switchport access vlan 10
    c3750(config-if)#spanning-tree portfast
    c3750(config-if)#exit
    c3750(config)#interface range fastEthernet1/0/1 - 22
    c3750(config-if-range)#switchport mode access
    c3750(config-if-range)#switchport access vlan 20
    c3750(config-if-range)#spanning-tree portfast
    c3750(config-if-range)#exit
    c3750(config)#interface vlan 10
    c3750(config-if)#ip address 10.0.0.1 255.255.255.0
    c3750(config-if)#no shutdown
    c3750(config-if)#exit
  2. Activer les fonctionnalités AAA globalement
    c3750(config)#aaa new-model
  3. Configurer les informations relatives au serveur radius
    c3750(config)#radius-server host 10.0.0.10 auth-port 1812 acct-port 1813 non-standard key ciscomadesimple
    ! remarque (2)
  4. Configurer la méthode d’authentification dot1x globale
    c3750(config)#aaa authentication dot1x default group radius
  5. Activer le service d’authentification des ports
    c3750(config)#dot1x system-auth-control
  6. Configurer les ports
    c3750(config)#interface range fastEthernet0/1 - 23
    c3750(config-if)#authentication port-control auto        ! remarque (3)
    c3750(config-if)#dot1x pae authenticator                 ! remarque (4)
    c3750(config-if)#end

Comme vous l’aurez remarqué, il y a quelques changements…
(1) Les ws-c3750 supportent ISL et dot1q comme protocole de trunking, donc si on veut forcer le trunk, il faut forcer le protocole.

(2) Pour une raison qui m’échape, là où le c2950 discutait volontiers avec le serveur radius utilisé, pour le c3750 j’ai du forcer l’analyse des informations non-standard, sans quoi dans un « debug radius authentication« , je recevais des messages du genre: « RADIUS: Response (9) failed decrypt ».

(3) Ô joie, ô bonheur, les commandes « standard » ne sont plus supportées sur les plateformes plus récentes. « dot1x port-control auto » devient « authentication port-control auto ». Je parie que des développeurs sont payés pour faire ce genre de modifications 😉

Jusqu’ici rien ne marche … après avoir testé aussi bien avec le Mac que la machine Windows … nada, rien …

(4) L’épine que j’ai eu du mal à retirer de mon pieds … par défaut le wc-c3750 (C3750-IPSERVICESK9-M, Version 12.2(55)SE7) … je suppose que le version de l’IOS a une influence sur ce genre de comportements … ne se conduit pas comme un authentificateur … en gros … le client voudrait bien (mais n’peut point) se présenter et s’identifier, le switch fait la sourde oreille… Problème résolu en lui disant quoi faire avec « dot1x pae authenticator ».

C’est toujours frustrant de s’apercevoir que ce qui sert de référence (qui parle des ouvrages CiscoPress Official Certification Guide ???) pour les certifications se révèle être une guerre ou deux en retard. Ce ne sont que des détails, bien entendu, mais on pourrait s’attendre à un peu plus de cohérence entre certification et vie réelle … non ?

(S)NTP – Synchronisation d’horloge et configuration de l’heure d’été

22 juillet 2015 à 17:45

Même si dans bien des cas l’heure donnée par l’horloge du switch ou du routeur importe peu (du moins jusqu’au jour où on aurait aimé qu’elle soit correcte), il peut être utile, voire indispensable de s’assurer que tout le monde est à la bonne heure.

Il y a deux grandes méthodes:

  • Configurer l’heure manuellement … autrement dit, la mauvaise méthode.
  • Synchroniser l’heure sur une horloge de référence … la bonne solution.

Reste à voir ce qui doit être défini pour que tout cela fonctionne…

(S)NTP – (Simple) Network Time Protocol

NTP est un protocole applicatif ayant pour but de synchroniser les horloges de machines entre elles. Il n’y a pas grand chose de réellement nécessaire à savoir concernant les  entrailles de ce protocole pour l’utiliser si ce n’est :

  • C’est un protocole client-serveur.
  • Un équipement peut être à la fois client et serveur.
  • Il fournit un moyen de synchroniser l’horloge … mais indépendamment des fuseaux horaires, et des systèmes d’heure d’été/hiver. Ca, il faudra s’en charger nous-même.
  • Les messages NTP sont envoyés à destination du port UDP 123 (attention aux ACLs et autres firewalls).
  • Il est possible de gérer une authentification entre les clients et serveurs.

NTP vs SNTP

Sur les équipements Cisco on retrouve parfois un service NTP mais aussi SNTP. La différence est simple:

  • Le service NTP est le service à la fois client et serveur.
  • Le service SNTP est la version client uniquement.

Donc quoi qu’il en soit, c’est le protocole NTP qui est utilisé.

Configuration de base NTP

Afin de rester bref, je vais me contenter ici d’une configuration NTP fonctionnelle, sans authentification.

Etape n°1: Définir la « timezone », en gros le fuseau horraire.

switch(config)# clock timezone zone offset_h offset_m
  • zone: l’acronyme correspondant à votre zone (liste complète des zones)
  • offset_h: nombre d’heure de décalage par rapport à UTC (Greenwich)
  • offset_m: nombre de minutes de décalage par rapport à UTC

En ce qui me concerne, pour la belgique, cela donne…

switch(config)# clock timezone CET 1

vous aurez noté que le nombre de minutes de décalage est optionnel.

Etape n°2: Configurer le passage à l’heure d’été (optionnel suivant le pays bien entendu).

Ici je donne un example concret, il y a trop de variations possibles pour le formuler de manière générique. En Belgique, l’heure d’été commence le dernier dimanche de Mars à 3h du matin. Elle se termine le dernier dimanche d’Octobre à 2h du matin. Voici ce que je configure donc:

switch(config)# clock summer-time CET recurring last sunday march 03:00 last sunday october 02:00 60

J’ai donc indiqué ici que le calcul de l’heure dété est basé sur la zone CET, que cela se produit de manière récurrente avec le dernier dimanche de Mars comme début, le dernier dimanche d’Octobre comme fin, et que ça implique un décalage de 60 minutes.

Etape n°3: Synchroniser l’horloge

En gros, on indique ici à quel serveur NTP l’équipement doit s’adresser. Si vous n’en connaissez pas, pas de souci, il existe une multitude de serveurs, partout dans le monde et totalement accessibles. Jetez un oeil sur www.pool.ntp.org.

Pour configurer un serveur ntp de référence, procédez comme ceci:

switch(config)# ntp server adresse/hostname
  • adresse/hostname: vous pouvez indiquer soit une adresse ip, soit le nom de machine, pour autant que votre équipement soit capable d’effectuer la résolution DNS, bien entendu.

Voici ce que j’utilise (en Belgique):

switch(config)# ntp server be.pool.ntp.org

Et voilà, le tour est joué… il ne reste plus qu’à vérifier…

Etape n°4: Vérification

switch#show ntp status
Clock is synchronized, stratum 3, reference is 85.88.55.5
nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**24
reference time is D95A4D34.8B1F5043 (19:11:16.543 CET Wed Jul 22 2015)
clock offset is 1.9180 msec, root delay is 20.52 msec
root dispersion is 38.45 msec, peer dispersion is 2.69 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.000000081 s/s
system poll interval is 64, last update was 218 sec ago.
switch#

On voit ici que la clock de la machine est synchronisée avec 85.88.55.5 (qui n’est autre qu’un des serveurs caché derrière be.pool.ntp.org).

switch#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~85.88.55.5      193.79.237.14    2      2     64   377 15.810   1.918  4.086
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
switch#

Si la ligne de 85.88.55.5 comportait des champs vides, il y aurait de forte chance que la synchro n’ait pas fonctionné.
Ne paniquez toutefois pas trop vite, il faut parfois quelques minutes pour que ça se mette ne place (tout dépend du serveur par rapport auquel vous vous synchronisez).

switch#show clock detail
19:19:24.884 CET Wed Jul 22 2015
Time source is NTP
Summer time starts 03:00:00 CET Sun Mar 29 2015
Summer time ends 02:00:00 CET Sun Oct 25 2015
switch#

On retrouve ici la confirmation que le protocole NTP est utilisé pour synchroniser l’horloge, ainsi que les réglages de l’heure d’été.

Et ensuite ?

Il est bien sur possible d’en faire plus, avec de l’authentification etc. Mais ce n’est pas ce qui est le plus intéressant ici. Par contre, une fois que vous avez configuré ceci sur un équipement, n’oubliez pas qu’il se comporte désormais comme client NTP mais aussi comme serveur NTP. Du coup, vous pouvez très bien en configurer un pour se synchroniser avec un serveur de temps publique, et configurer les autres pour se synchroniser sur le premier. Pratique non ?

Dans le cas où vous ne souhaiteriez pas que votre équipement fasse office de serveur, il vous suffit de remplacer la commande « ntp server » par « sntp server » … pour autant qu’elle soit disponible.

Diagnostic du câblage depuis un switch Cisco

24 avril 2015 à 06:58

Si vous suspectez un problème de câblage entre deux équipements dont un Switch Cisco, il se peut que celui-ci vous permette de le diagnostiquer.
En effet, beaucoup de modèles récents disposent d’un mécanisme appelé « Time-Domain Reflectometer », qui permet de vérifier le bon fonctionnement du câble et éventuellement en cas de problème de situer approximativement le défaut d’un point de vue de sa longueur.

Voici comment procéder…

Prérequis

Avant tout vous devez bien entendu disposer d’un équipement où cette fonctionnalité est disponible. En voici quelques-uns:

  • WS-C2960
  • WS-C2960G/S
  • WS-C3560E/G/X
  • WS-C3750E/G/X
  • Nexus 7K

Ce qu’il faut savoir

Le test sera effectué sur chacune des paires du câble UTP Ethernet. Toutefois dans la majeure partie des cas, si il s’agit d’une connexion 100Mbits/s (FastEthernet), seules deux paires seront testées, puisqu’il y en a que deux d’utilisées.
En GigabitEthernet, les quatre paires seront testées.

Chaque paire aura un état qui lui sera associé parmi les suivants:

  • Normal : Résultat idéal, tout va bien
  • Open : Pas de contact
  • Short: Court-circuit
  • Impedance Mismatched : Câble défectueux.

Pour résumer, en temps normal vous devriez obtenir …

  • En FastEthernet : 2 paires en Normal, 2 paires en Open
  • En GigaBitEthernet : 4 paires en Normal

Si ce n’est pas le cas, il y a un problème!

Effectuer le test

Switch#test cable-diagnostics tdr interface nom_interface 

Afficher le résultat

Switch#show cable-diagnostics tdr interface nom_interface

Exemple d’un câble Gigabit à problème (cas réel)

C3560G#test cable-diagnostics tdr interface g0/14
Link state may be affected during TDR test
TDR test started on interface Gi0/14
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

C3560G#show cable-diagnostics tdr interface g0/14
TDR test last run on: April 24 07:09:18

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/14    100M  Pair A     N/A                Pair A      Normal
                Pair B     N/A                Pair B      Normal
                Pair C     52   +/- 10 meters Pair C      Open
                Pair D     N/A                Pair D      Normal
C3560G#

Exemple d’un câble Gigabit fonctionnel

C3560G#test cable-diagnostics tdr interface g0/20
TDR test started on interface Gi0/20
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

C3560G#show cable-diagnostics tdr interface g0/20
TDR test last run on: April 24 07:11:58

Interface Speed Local pair Pair length        Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi0/20    auto  Pair A     58   +/- 10 meters Pair B      Normal
                Pair B     58   +/- 10 meters Pair A      Normal
                Pair C     58   +/- 10 meters Pair D      Normal
                Pair D     58   +/- 10 meters Pair C      Normal
C3560G#

Formule de calcul d’un masque réseau en fonction d’un nombre de machines

29 mars 2015 à 01:49

Quoi de plus courant en IPv4 que de devoir trouver le bon masque de sous-réseau en fonction d’un nombre de machines à y adresser ?

D’un point de vue purement théorique, il faut définir le nombre de bits dans l’adresse qui seront consacrés à la partie « machines ». C’est-à-dire les bits mis à 0 dans le masque, en partant de la droite (bits de poids faible). Les bits restants détermineront la partie réseau bien entendu.

Par exemple, si on a besoin d’un réseau pour 100 machines:

  • Il faut que 2x >= 100 + 2, où x est le nombre de bits consacrés aux machines.
    (Ne pas oublier de tenir compte de l’adresse réseau et de l’adresse broadcast qu’on ne peut pas attribuer à une machine, c’est la raison du +2)
  • On prendra donc ici 7 bits pour les machines , ce qui permet d’attribuer 27-2 adresses.
  • On obtient donc un masque /32-7 = /25, soit 255.255.255.128

En général, soit on a ces chiffres en tête par habitude, soit on utilise un tableau récapitulatif.

C’est par contre moins évident d’automatiser ce calcul dans une feuille Excel ou dans un programme par exemple, sauf si on a la bonne formule:

BitsMachines = ArrondiHaut( log2( nb_machines + 2) )
  • ArrondiHaut : Prendre la valeur arrondie vers le haut de …
  • log2(…) : logarithme en base 2 de …
  • nb_machines : Nombre de machines à adresser
  • +2 : Pour ne pas oublier de tenir compte de l’adresse réseau et du broadcast

De là pour obtenir le nombre de bits côté réseau :

BitsRéseau = 32 - BitsMachines

ou en une fois …

BitsRéseau = 32 - ArrondiHaut( log2( nb_machines + 2) )

Exemples d’application

Formule Excel (Syntaxe en français)

=32-PLAFOND(LOG(D4+2;2);1)

Formule Excel (Syntaxe en Anglais)

=32-CEILING(LOG(D4+2;2);1)

Application en Python

# Importation de la bibliothèque Math
# pour les fonctions logarithmiques etc
import math

# Fonction qui retourne le nombre de bits réseau 
# sous forme d'un entier
def calculMasque(nbMachines):
    return int ( 32 - math.ceil(math.log(nbMachines+2,2)))

# Exemple ...
print calculMasque(100)

Protocole IPv4 : Les bases

8 novembre 2014 à 17:35

Le protocole IPv4 : les bases

Introduction

IPv4 est un protocole « routable », de la couche réseau du modèle OSI (couche 3), entendez par là qu’il défini principalement un système d’adressage permettant de router des paquets.
Ce protocole est décrit dans la RFC791 publiée en 1981. Son objectif initial était de permettre l’interconnexion de réseaux.
Le principe sur lequel il est bâtit est relativement simple: attribuer aux machines une (ou plusieurs) adresses(s) d’une taille donnée afin que celle-ci puissent s’échanger des paquets de données. Ces adresses permettent aux machines composant le réseau de choisir un itinéraire pour acheminer les données depuis une source vers une destination.

Analogie

Si je veux transmettre une lettre à un voisin qui habite la même rue que moi, je ne me préoccupe pas de l’adresse de la rue. Tout ce que j’ai besoin de savoir c’est ce qui distingue sa maison de la mienne. Une caractéristique physique de sa maison.
Par contre, si je souhaite envoyer une lettre à un correspondant à l’étranger, je vais généralement faire appel à un service qui acheminera ma lettre à son destinataire. Pour que ce service puisse faire son travail, je dois lui indiquer à qui j’envoie la lettre, mais surtout, où cette personne habite. Hors pour préciser cette information, je dois disposer d’un système d’adressage. Le service postal utilisera l’adresse du destinataire pour définir l’itinéraire que prendra la lettre.
En y réfléchissant de plus près, même moi j’ai besoin de cet adressage. Sans lui je ne pourrais raisonnablement pas définir si le destinataire est dans la même rue que moi. Donc au final, quand j’envoie la lettre, le compare l’adresse du destinataire à la mienne, si nous sommes dans la même rue, je lui apporte moi même (c’est plus simple non ?), si ce n’est pas le cas, je fais appel à un service qui l’acheminera vers sa destination.
Le système postal que nous connaissons fonctionne (Si si, il fonctionne… ou pas… 😉 ) parce que nous utilisons un protocole qui consiste à indiquer sur l’enveloppe l’adresse du destinataire à un endroit défini, au dos, nous marquons notre propre adresse, pour un retour éventuel, nous l’affranchissons, indiquons aussi d’éventuelles options (courrier prioritaire, colis fragile…) etc.
Du point de vue réseau, le concept est similaire…

L’en-tête IPv4

Lorsque des données doivent être véhiculées sur un réseau, les machines les encapsulent dans un paquet muni d’un en-tête qui comporte toutes les informations nécessaires au routage des données. Voici l’en-tête:

Chacune des case représente un champs qui apporte une information précise pour le traitement du paquet IPv4:

  • Version: indique la version du protocole (toujours égal à 4 pour IPv4)
  • IHL: Longueur de l’en-tête IPv4 (nécessaire en raison de la présence possible d’options)
  • ToS: Marquage différentiel pour la qualité de service (permet de marquer un paquet comme étant plus important).
  • TPL: Longueur totale du paquet IPv4.
  • Fragment ID: Identification d’un fragment de paquet, permet de le reconstituer plus tard. Utilisé lorsqu’un paquet doit être fragmenté parce que sa taille dépasse la capacité du réseau sur lequel il doit être émis.
  • FLAG: Marqueurs permettant d’indiquer si un paquet peut/doit ou ne peut pas être fragmenté.
  • Fragment Offset: Indique la position du fragment au sein du paquet original.
  • TTL: Time To Live, représente le nombre d’intermédiaire (routeurs) par lesquels le paquet peut encore passer avant d’être détruit. Il s’agit d’un mécanisme permettant d’éviter qu’un paquet ne tourne indéfiniment dans un réseau suite à un problème de routage. On peut comparer cela à une date de péremption.
  • Protocol: Contient une valeur numérique qui identifie la nature du contenu du paquet.
  • Checksum: SOmme de contrôle calculée sur l’en-tête du paquet IPv4. Permet de contrôler l’intégrité de l’entête et donc de le détruire s’il avait été altéré.
  • Source IP: Adresse IPv4 de la machine qui a émis le paquet.
  • Destination IP: Adresse IPv4 de la machine à laquelle est destinée le paquet.
  • Options: Permet d’ajouter différentes informations optionnelles et rarement utilisées.
  • Data: Les données véhiculées dans le paquet.

Chaque machine travaillant au niveau de la couche réseau (couche 3) du modèle OSI analysera cette en-tête et agira en conséquence. Par exemple, les routeurs l’utiliseront pour acheminer les données vers la destination en fonction de l’adresse IPv4 de destination.

Types de communications IPv4

Il existe en IPv4, trois manières de communiquer…

  • Le paquet unicast: Un paquet émis par une machine, destiné à une et une seule autre machine. Une communication de un-à-un.
  • Le paquet broadcast (de diffusion): Un paquet émis par une machine et destiné à toutes les machines d’un réseau. Une communication de un-à-tous.
  • Le paquet multicast (de multi diffusion): Un paquet émis par une machine et destiné à un groupe de machine. Une communication de un-à-plusieurs.

La majorité des échanges de données sont des communications unicast. Par exemple, lorsque je surfe sur un site web, c’est ma machine (le client) qui dialogue avec le site distant (le serveur). On a donc bien une relation de un à un.
Chaque type de communication utilise un adressage différent bien que défini dans une structure unique.

L’adressage IPv4

Pierre angulaire du protocole IPv4, l’adresse IPv4 est donc une valeur numérique codée sur 32 bits (soit 2^32 adresses IPv4 au total) que l’on attribue principalement aux interfaces des machines afin que celles-ci puissent s’échanger des données. Malheureusement, toutes ces adresses ne sont pas utilisables pour adresser une machine, nous y reviendrons.
Ces adresses sont représentées généralement sous la forme de 4 octets exprimés en valeur décimale, séparés par un point. (Ex: 192.168.0.1, 80.200.14.58, etc.)
Un octet étant composé de 8 bits, sa valeur ne peut pas excéder 255. Toutes les adresses IPv4 sont donc comprises entre 0.0.0.0 et 255.255.255.255.

Pour comprendre la structure d’une adresse IPv4, le plus simple est de réfléchir à l’adresse d’une série de maisons dans une rue:

  • Toutes les maisons d’une même rue auront une partie de leur adresse commune (le nom de la rue, la commune, la ville, le pays, etc.)
  • Chaque maison aura dans son adresse un élément qui lui est propre: le numéro de la maison dans la rue.

L’adressage IPv4 fonctionne exactement sur le même principe. Toutes les interfaces de machines dans un même réseau auront une partie de leur adresse qui sera commune: l’identifiant réseau et une deuxième partie qui lui sera propre: l’identifiant hôte. Ces deux éléments ensembles formant l’adresse complète de la machine dans son réseau. Voici ce que ça donne d’un point de vue conceptuel:

L’identifiant réseau est formé par un certain nombre de bits (à gauche, les bits de poids fort), et l’identifiant hôte (à droite, les bits de poids faible) représenté par ce qui reste de bits.
Normalement une question doit vous venir à l’esprit… « Combien de bits côté réseau ? et donc combien côté hôte ? »… Et c’est ici que les Romains s’empoignèrent!

Comment définir la limite entre l’identifiant réseau et l’identifiant hôte ?

Les classes

La première idée était de faire simple, enfin, humainement simple en tout cas: on définit 5 classes. A chaque classe correspond une définition en terme de limite d’identifiant réseau/hôte ou autre etc.

  • Classe A: Toutes les adresses dont le premier bit vaut 0 (donc de 0.0.0.0 à 127.255.255.255). Ces adresses ont 8 bits pour la partie réseau, et donc 24 pour la partie hôte.
  • Classe B: Toutes les adresses dont les deux premiers valent 10 (donc de 128.0.0.0 à 191.255.255.255). Ces adresses ont 16 bits pour la partie réseau, et donc 16 pour la partie hôte.
  • Classe C: Toutes les adresses dont les trois premiers valent 110 (donc de 192.0.0.0 à 223.255.255.255). Ces adresses ont 24 bits pour la partie réseau, et donc 8 pour la partie hôte.
  • Classe D: Toutes les adresses dont les quattre premiers valent 1110 (donc de 224.0.0.0 à 239.255.255.255). Ce sont les adresses multicast. Elles représentent une groupe de machine et n’entrent donc pas dans la logique d’adresse d’une machine unique.
  • Classe E: Toutes les adresses restantes (donc de 240.0.0.0 à 255.255.255.254). Adresses réservées pour utilisation futures… ou pas… donc non utilisables pour adresser une machine.

Nous nous retrouvons donc avec 3 classes utilisables. La première qui défini des réseaux pouvant comporter 2^24 machines ( 16,7 millions de machines !!! ), la seconde qui permet d’adresser des réseaux de 2^16 machines (65536), et enfin la plus petite, qui permet elle d’adresser des réseaux de 2^8 machines (256).

Faites une pause de quelques secondes, et demandez-vous combien de sociétés que vous connaissez disposent de plus de 16 millions de machines ? Et environ 65000 machines ? …

Il faut remettre tout ça dans son contexte. IPv4 est apparu alors qu’Internet n’existait pas encore. A l’époque, ce qui est maintenant le réseau des réseaux n’était qu’une interconnexion d’établissements militaires, universitaires etc, nommé ARPAnet. Ce n’est qu’une bonne dizaine d’années plus tard que les particuliers ont commencé tout doucement à disposer d’un accès à Internet.
L’idée de base avait du sens: une société forme un réseau de machines, donc, on attribuait une plage d’adresses plus ou moins grande en fonction de la taille de la société. Donc si je suis un géant de l’informatique de l’époque, je reçois une classe A, par exemple toutes les adresses de 23.0.0.0 à 23.255.255.255. Dés lors lorsqu’un paquet doit être transmis à une machine, en fonctionne de l’adresse de destination je peux déterminer la classe de celle-ci, et donc savoir combien de bits représentent le réseau. Dans l’exemple précédent, cela signifie que toutes les adresses dont le premier octet vaut 23 sont dans le même réseau.

C’est donc un principe qui suivait la logique de l’époque mais qui manquait cruellement de vision. Quand l’accès à Internet a commencé à se démocratiser, d’abord pour les entreprises, et ensuite pour les particuliers, un problème est apparu: il était impossible de fournir suffisamment de plages d’adresses et ce parce que les classes ont découpé l’espace global d’adresses IPv4 en des ensembles trop grossiers qui ne correspondent plus aux besoins.

Autre problème, mais celui-là inhérent à IPv4, le nombre d’adresse IPv4 disponible au total est insuffisant. 2^32 adresses au total, soit un peu moins de 4,3 milliards d’adresses, pour à l’heure actuelle quelques 7 milliards d’êtres humains. Si en plus on attribue les adresses par classe, gaspillant ainsi une quantité énorme d’adresses, on comprend vite que ça ne peut mener qu’à une impasse.
Si j’attribue toutes les adresses de 23.0.0.0 à 23.255.255.255 à une société mais que celle-ci n’en utilise que 10%, cela représente approximativement 15 millions d’adresses « perdues » puisqu’on ne peut pas donner une adresse de cette classe à une machine qui n’est pas dans ce réseau. Cela reviendrait à mettre le même nom de rue à des maison qui ne sont pas physiquement dans la même rue.

Le CIDR (Classless Inter-Domain Routing)

La seule chose à faire était donc d’abandonner les classes de définir des réseaux dont la taille peut être ajustée en fonction des besoins réels afin d’éviter tant que faire se peut le gaspillage de ces adresses.
Si on abandonne les classes, on abandonne donc aussi la définition de leur taille en terme d’identifiant réseau et identifiant hôte. Il faut donc un nouvel élément qui servira de délimitation: le masque de réseau.

Masque de (sous-)réseau

Le masque est une valeur numérique qui comme l’adresse IPv4 est codé sur 32bits et représenté en décimal sous forme de 4 octets séparés par des points. (Ex: 255.255.255.0, 255.255.224.0). Son rôle est d’indiquer quels sont les bits de l’adresse qui identifient la partie réseau et donc aussi ceux qui identifient la partie hôte.
Les bits de poids fort (à gauche) représentent la partie réseau et ont leur valeur à 1. Les bits de poids faible (à droite) ont leur valeur à 0 et identifient la partie hôte de l’adresse.

C’est donc le masque du réseau qui détermine sa taille, et donc le nombre d’adresses qui font partie de ce réseau. Plus le masque est grand (plus il y a de bits à 1) plus le réseau est petit (il y a moins de bits côté hôte). Plus le masque est petit, plus le réseau est grand.

Prenons par exemple le masque suivant:

255.255.255.192

En binaire cela donne:

11111111.11111111.11111111.11000000

Il y a 26 bits à 1, donc 26 bits qui identifient la partie réseau. Il en reste donc 32-26=6 bits pour les adresses hôtes, soit 2^6=64.

Par contre avec le masque…

255.255.224.0

Qui s’écrit en binaire…

11111111.11111111.11100000.00000000

Il y a 19 bits côté réseau et donc 32-19=13 bits côtés hôte. Ce qui donne 2^13=8192 adresses dans un même réseau.

Une autre notation du masque est également souvent utilisée, en suivant le format suivant: adresse_ip / bits_réseaux
Exemple: 21.58.63.250/26, cette notation revient à écrire 21.56.63.250 / 255.255.255.192

Au lieu d’écrire l’expression décile du masque, on indique uniquement

Avec le CIDR, une adresse seule n’a plus de sens. Elle doit toujours être accompagnée d’un masque. Sans quoi il est impossible de déterminer à quel réseau elle appartient.

L’adresse de (sous-)réseau

A chaque réseau correspond une adresse qui l’identifie. Il s’agit de la première adresse du réseau lui même. Celle pour laquelle tous les bits hôtes vallent 0.
Une opération simple (un ET logique) entre une adresse quelconque et le masque qui lui est joint permet de retrouver l’adresse du réseau auquel elle appartient.

Prenons par exemple l’exemple d’une machine qui aurait la configuration suivante:

  • Adresse IPv4: 158.98.45.33
  • Masque réseau: 255.255.255.0

L’application d’un ET logique (une opération binaire) entre ces deux valeurs donnent l’adresse du réseau:

        10011110.01100010.00101101.00100001	(158.98.45.33)
ET      11111111.11111111.11111111.00000000	(255.255.255.0)
=======================================
        10011110.01100010.00101101.00000000	(158.98.45.0)

L’adresse du réseau dans lequel se trouve la machine est donc 158.98.45.0. Notez que si on tenait compte des classes. Les adresses 158… commencent par 10… en binaire et donc auraient fait partie de la classe B 158.98.0.0.

Autre exemple:

  • Adresse IPv4: 89.27.250.45
  • Masque réseau: 255.255.255.248

On retrouve donc l’adresse réseau de cette machine par l’opération suivante:

        01011001.00011011.11111010.00101101	(89.27.250.45)
ET      11111111.11111111.11111111.11111000	(255.255.255.248)
=======================================
        01011001.00011011.11111010.00101000	(89.27.250.40)

L’adresse réseau de cette machine est donc 89.27.250.40

Il est important de noter que l’adresse du réseau ne peut pas être attribuée à une machine. Une machine est un élément du réseau et non le réseau lui-même.

L’adresse de diffusion (broadcast) du (sous-)réseau

Pour chaque réseau, il existe une adresse dite de diffusion (de broadcast). Cette adresse a pour but d’émettre un paquet et de l’adresser à l’ensemble des machines du réseau en question (Communication de un à tous). Il s’agit de la dernière adresse du réseau. Celle pour laquelle tous les bits hôtes vallent 1.

Exemple:

  • Adresse: 121.43.98.205
  • Masque: 255.255.255.128

On obtient donc l’adresse réseau par l’opération logique ET (comme plus haut):

     01111001.00101011.01100010.11001101	(121.43.98.205)
ET   11111111.11111111.11111111.10000000	(255.255.255.128)
========================================
     01111001.00101011.01100010.10000000	(121.43.98.128)

L’adresse du réseau est donc 121.43.98.128.
A partir de là il suffit de mettre tous les bits hôtes, c’est à dire les 7 bits à droite à 1:

     01111001.00101011.01100010.11111111	(121.43.98.255)

L’adresse broadcast de ce réseau est donc 121.43.89.255.

Plage d’adresses utilisables

Puisque l’adresse du réseau est la première adresse dans ce réseau et que l’adresse broadcast est la dernière. Tout ce qui se trouve entre les deux forme la plage d’adresses utilisables.
On obtient le nombre d’adresses utilisable dans un réseau par la formule suivante: nb adresses = 2^n-2, où n est le nombre de bits hôtes. On soustrait deux unités pour l’adresse du réseau et l’adresse broadcast.

Exemple récapitulatif

Les données de bases étant les suivantes:

  • Adresse: 188.56.58.39
  • Masque: 255.255.248.0

On obtient l’adresse réseau en appliquant le masque à l’adresse…

     10111100.00111000.00111010.00100111	(188.56.58.39)
ET   11111111.11111111.11111000.00000000	(255.255.248.0)
========================================
     10111100.00111000.00111000.00000000	(188.56.56.0)

L’adresse réseau est donc 188.56.56.0

Pour obtenir l’adresse broadcast, il faut remplacer mettre les bits hôtes à 1…

     10111100.00111000.00111111.11111111		(188.56.63.255)

L’adresse broadcast est donc 188.56.63.255

Les adresses comprises entre 188.56.56.0 et 188.56.63.255 forment donc la plage d’adresses utilisables.
Leur nombre est de 2^11-2 = 2046 adresses.

Routage IPv4

Router un paquet consiste à l’acheminer vers la destination en fonction de sa table de routage. Cette table contient la liste des réseaux vers lesquels elle est apte à acheminer les données ainsi que les informations nécessaires au traitement du paquet.

Table de routage

La table de routage est une liste de routes, c’est-à-dire, une liste de réseaux auxquels sont attachés les informations nécessaires au routage du paquet: un next-hop (la prochaine machine à qui le paquet doit être transmis), une interface (celle par laquelle le paquet devra être émis), une métrique (une valeur permettant de comparer deux routes), etc.

exemple de table de routage sous Windows 7

IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau    Masque réseau  Adr. passerelle   Adr. interface Métrique
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.9     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link       192.168.1.9    266
      192.168.1.9  255.255.255.255         On-link       192.168.1.9    266
    192.168.1.255  255.255.255.255         On-link       192.168.1.9    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.9    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.9    266
===========================================================================
  • Destination réseau: L’adresse du réseau de destination.
  • Masque réseau: Détermine la taille du réseau en question.
  • Adresse passerelle: L4adresse IPv4 de la machine à qui le paquet doit être transmis pour l’acheminer vers le réseau en question.
  • Adresse Interface: L’adresse de l’interface par laquelle le paquet devra être émis/routé.
  • Métrique: permet de choisir en plusieurs routes qui indiquerait la même destination.

Exemple de table de routage sur un routeur Cisco

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
 * - candidate default, U - per-user static route, o - ODR
 P - periodic downloaded static route

Gateway of last resort is 10.0.0.1 to network 0.0.0.0

 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.0.0.0/30 is directly connected, Serial0/0
O       10.0.10.0/24 [110/782] via 10.0.0.1, 00:53:35, Serial0/0
 192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, FastEthernet0/0
 192.168.1.0/24 is variably subnetted, 3 subnets, 2 masks
C       192.168.1.0/28 is directly connected, FastEthernet0/0.10
C       192.168.1.16/28 is directly connected, FastEthernet0/0.20
C       192.168.1.32/29 is directly connected, FastEthernet0/0.30
O*E2 0.0.0.0/0 [110/1] via 10.0.0.1, 00:50:51, Serial0/0

Lorsqu’on y est pas habitué, cet affichage put perturber. Ceci dit, chaque route est précédée d’un symbole. Dans le cas présent, les routes commençant par un « C » indiquent une route directement connectée. Donc un réseau directement attaché au routeur (dans Windows 7, on le voit avec la mention « On-link »).
Les routes commençant par « O » sont des routes apprises à l’aide d’un protocole de routage, OSPF. Ce sont des routes vers des réseaux qui se trouvent au-delà d’une autre machine.

Pour chacun de ces routes on a donc un format du genre:

ORIGINE     Réseau/Masque [AD/Métrique]     next-hop     Interface

Le terme « AD » représente la distance administrative. Il s’agit d’une notion que l’on retrouve surtout sur les routeurs Cisco. Cette élément permet lui aussi de différencier des routes. Chaque source d’information aura sa distance administrative. Par exemple une route connectée a une AD=0, une route statique AD=1, une route OSPF AD=110, etc. (valeurs par défaut).

Pour plus d’explication concernant les tables de routage, je vous invite à lire cet article: « Table de routage – Comment ça marche?« 

LLDP (Link Layer Discovery Protocol)

30 juillet 2014 à 15:56

LLDP est un protocole standardisé (IEEE 802.1AB) de découverte de réseau ayant pour vocation de supplenter la multitudes de protocoles propriétaires du même type (Cisco Discovery Protocol, Nortel Discovery Protocol, …) et ainsi de permettre aux équipements de différents fabriquants de se découvrir mutuellement.

Introduction

LLDP est défini par le standard IEEE 802.1AB. Il s’agit d’un protocole de la couche liaison de données du modèle OSI (protocole de niveau 2). Ce qui signifie que LLDP est directement véhiculé dans une trame. Il est conçu pour fonctionner sur les réseaux de type IEEE 802 (Ethernet, …). Comme pour CDP il s’agit d’une simple émission de messages à interval régulier (Ce n’est pas une communication bidirectionnelle).

Les messages LLDP portent le doux nom de LLDPDU. Chacun de ces message est composé d’une suite de structures appellées TLV (Type-Length-Value) servant à contenir les informations.
Les LLDPDU sont envoyés à une adresse MAC destination spéciale qui n’est pas forwardée par les switches (0180.c200.000e, 0180.c200,0003 ou 0180.c200.0000), ce qui signifie que, à l’instar de CDP, LLDP sert à communiquer au travers d’un lien uniquement. D’équipement à équipement.
LLDP possède son propre EtherType (0x88CC) qui est donc indiqué dans le champs « Type » de la trame Ethernet.

Structure du LLDPDU

  • DMAC: Adresse MAC destination (0180.c200.000e, 0180.c200,0003 ou 0180.c200.0000).
  • SMAC: Adresse MAC de la machine émetrice.
  • TYPE: 0x88CC.
  • TLV1: Chassis ID, identifiant de la machine.
  • TLV2: Port ID, identifie le port depuis lequel le LLDPDU est émis.
  • TLV3: TTL TLV, Indique la durée de vue du LLDPDU.
  • TLVx: TLV supplémentaires optionnels.
  • ENDTLV: Indique la fin des TLVs dans le LLDPDU.

Structure d’un TLV

  • TLV Type (7 bits): indique la nature du TLV.
  • TLV Length (9 bits): indique la longueur de l’information.
  • TLV String (0-511 octets): information du TLV.

Principaux TLVs

  • Chassis ID (Type 1) : Identifie la machine émetrice (obligatoire).
  • Port ID (Type 2) : Identifiant du port duquel est émis le LLDPDU (obligatoire).
  • TTL TLV (Type 3) : Indique la durée de vie du LLDPDU (obligatoire).
  • Port Description (Type 4) : Description textuelle du port (optionnel).
  • System Name (Type 5) : Nom de la machine émetrice (optionnel).
  • System Description (Type 6) : Description de la machine émetrice (optionnel).
  • System Capabilities (Type 7) : Fonctionnalités de la machine émetrices (optionnel).
  • Management Address (Type 8) : Adresse IP de management de la machine (optionnel).

LLDP-MED (LLDP for Media Endpoint Devices)

LLDP-MED est une extension de LLDP servant à communiquer avec les équipements terminaux (les téléphones VoIP par exemple) qui offre des TLVs complémentaires pour supporter des informations relatives au PoE (Power Over Ethernet), à la localisation de l’équipement, aux polices d’accès réseau (informations relatives au VLANs, …), ou encore à la gestion d’inventaire (modèle de l’équipement, version du software, numéro de série, …). Sur les équipements Cisco, LLDP-MED est actif dés qu’on utilise LLDP.

Paramètres par défaut de LLDP (pour les équipements Cisco)

  • Etat initial de LLDP: désactivé
  • Etat initial de LLDP: désactivé
  • LLDP Holdtime (TTL): 120 secondes
  • LLDP Timer: 30 secondes (interval entre deux LLDPDU)
  • LLDP init delay: 2 secondes (temps d’attente avant premier envoi sur une interface)
  • LLDP tlv-select: désactivé (tous les TLVs sont envoyés par défaut)
  • LLDP med-tlv-select: désactivé (tous les TLVs spéciaux sont envoyés par défaut)

Disponibilité de LLDP sur les équipements Cisco

LLDP est un protocol assez récent et donc il est implémenté sur les plateformes assez récentes.
Pour les platerofmes de type IOS:

  • Côté switch, on le trouve à partir de la game des WS-C2960, WS-C3560, WS-C3750 et ME3400 depuis la version 12.2(37)SE toute licence confondue.
  • Côté routeur, il faut un IOS en version 15.2M pour les plateformes courantes et donc uniquement dans les dernières générations comme les séries 1900, 2900, 3900 ou encore dans les plus petits modèles les séries 880 et 890.

C’est un élément à prendre en compte pour la nouvelle CCNP et l’acquisition de matériel dans cette optique. Pour ma part j’ai eu du flair en faisant l’acquisition de trois WS-C3750 pour une bouchée de pain.

Configuration de base de LLDP

Commençons par vérifier l’état initial de LLDP dans une configuration par défaut…

3750-1#show lldp
% LLDP is not enabled
3750-1#

Comme prévu LLDP est désactivé par défaut. Activons le… et voyons ce que ça change.

3750-1#configure terminal
3750-1(config)#lldp run
3750-1(config)#end
3750-1#show lldp

Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds
3750-1#

LLDP est maintenant active avec un timer par défaut de 30 secondes, une durée de vie des LLDPDU de 120 secondes et un délai d’initialisation sur les interfaces de 2 secondes.

Qu’en est-il des interfaces ? Sont elles actives ou non ?

3750-1#show lldp interface

FastEthernet1/0/1:
    Tx: enabled
    Rx: enabled
    Tx state: INIT
    Rx state: WAIT PORT OPER

FastEthernet1/0/2:
    Tx: enabled
    Rx: enabled
    Tx state: INIT
    Rx state: WAIT PORT OPER
	
	....

Activer LLDP globalement active également toutes les interfaces possibles!
Mais le switch discute-t-il vraiment ? Pour vérifier, branchons un autre switch à celui-ci (avec LLDP activé de la même manière).

3750-1#debug lldp packets
LLDP packet info debugging is on
3750-1#
*Mar  1 00:44:50.989: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to up
*Mar  1 00:44:51.996: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
3750-1#
*Mar  1 00:45:20.836: LLDP advertisement packet RX'd on intf FastEthernet1/0/1
*Mar  1 00:45:20.920: LLDP advertisement packet TX'd on intf FastEthernet1/0/1
3750-1#

L’interface passe UP/UP, le temps que Spanning-Tree fasse son job et hop, les premiers LLDPDU sont échangés!

Regardons maintenant à quoi ressemble le résultat…

3750-1#show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID           Local Intf     Hold-time  Capability      Port ID
3750-2              Fa1/0/1        120        B               Fa3/0/1

Total entries displayed: 1

3750-1#

Notez que l’affichage ressemble très fort à celui de CDP et que les informations sont quasi identiques! « show lldp neighbors » affiche donc une liste simplifiée des voisins directements connectés. Comme pour CDP nous pouvons afficher les informations détaillées pour tous les voisins (dans ce cas-ci il n’y en a qu’un 😉 )…

3750-1#show lldp neighbors detail
------------------------------------------------
Chassis id: 001b.d59e.3100<= Adresse MAC principale du switch (TLV Chassis ID)
Port id: Fa3/0/1<= Port émetteur, donc celui du voisin (TLV Port ID)
Port Description: FastEthernet3/0/1<= Nom complet de l'interface du voisin (TLV Port description)
System Name: 3750-2<= Hostname du voisin (TLV System Name)

System Description:
Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(55)SE7, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Mon 28-Jan-13 10:16 by prod_rel_team

Time remaining: 97 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: 1


Total entries displayed: 1

3750-1#

De nouveau cela ressemble très fort à l’affichage de CDP, toutefois, les informations affichées concernent l’émetteur du LLDPDU … cela vaut aussi pour l’interface affichée. Attention à la confusion!

Il est également possible d’afficher les informations détaillées pour un seul équipement en spécifiant son Hostname.

3750-1#show lldp entry 3750-2

Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
------------------------------------------------
Chassis id: 001b.d59e.3100
Port id: Fa3/0/1
Port Description: FastEthernet3/0/1
System Name: 3750-2

System Description:
Cisco IOS Software, C3750 Software (C3750-IPSERVICESK9-M), Version 12.2(55)SE7, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2013 by Cisco Systems, Inc.
Compiled Mon 28-Jan-13 10:16 by prod_rel_team

Time remaining: 94 seconds
System Capabilities: B,R
Enabled Capabilities: B
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
    100base-TX(FD)
    100base-TX(HD)
    10base-T(FD)
    10base-T(HD)
Media Attachment Unit type: 16
Vlan ID: 1


Total entries displayed: 1
3750-1#

Comme pour CDP, il est possible d’avoir les statistiques concernant le nombre de messages envoyés et reçus, le nombre d’erreurs etc…

3750-1#show lldp traffic

LLDP traffic statistics:
    Total frames out: 78		<= LLDPDU envoyés
    Total entries aged: 0		<= LLDPDU expirés
    Total frames in: 78			<= LLDPDU reçus
    Total frames received in error: 0   <= Erreurs à la réception
    Total frames discarded: 0           <= Trames rejetées
    Total TLVs discarded: 0             <= TLVs rejetés
    Total TLVs unrecognized: 0          <= TLVs inconnus
3750-1#

Pour afficher l’état de LLDP sur les interfaces…

3750-1#show lldp interface

FastEthernet1/0/1:
    Tx: enabled
    Rx: enabled
    Tx state: IDLE			<= En attente d'émission (l'interface est fonctionelle)
    Rx state: WAIT FOR FRAME		<= En attente de réception

FastEthernet1/0/2:
    Tx: enabled
    Rx: enabled
    Tx state: INIT			<= En attente d'initialisation de l'interface (rien n'est connecté)
    Rx state: WAIT PORT OPER        <= En attente d'initialisation de l'interface (rien n'est connecté)
	
	...

Pour afficher l’état de LLDP d’une interface spécifique…

3750-1#show lldp interface fastEthernet 1/0/1

FastEthernet1/0/1:
    Tx: enabled
    Rx: enabled
    Tx state: IDLE
    Rx state: WAIT FOR FRAME
3750-1#

Paramétrage de LLDP

Activation globale de LLDP

3750-1(config)#lldp run

Désactivation globale de LLDP

3750-1(config)#no lldp run

Configurer l’interval entre deux LLDPDU (10 secondes par exemple). Vous pouvez choisir une valeur comprise entre 5 et 65534 secondes.

3750-1(config)#lldp timer 10

Configurer la durée de vie des LLDPDU envoyés (par exemple 60 secondes). Vous pouvez définir une durée de vie de 0 à 65535 secondes.

3750-1(config)#lldp holdtime 60

Configurer le délai d’initialisation de LLDP, (par exemple 4 secondes). Valeur comprise entre 2 et 5 secondes.

3750-1(config)#lldp reinit 4

Par défaut LLDP transmet tous les TLVs disponibles. Mais vous pouvez choisir de restreindre cela en définissant ceux à propager.
Il faut répéter la commande pour chaque TLV. Une fois un TLV choisi, l’équipement ne propagera plus que lui (et ceux qui vous configurerez après).

3750-1(config)#lldp tlv-select ?
  mac-phy-cfg          IEEE 802.3 MAC/Phy Configuration/status TLV
  management-address   Management Address TLV
  port-description     Port Description TLV
  port-vlan            Port VLAN ID TLV
  power-management     IEEE 802.3 DTE Power via MDI TLV
  system-capabilities  System Capabilities TLV
  system-description   System Description TLV
  system-name          System Name TLV

3750-1(config)#

Pour envoyer tous les TLVs, il faut annuler les différentes commandes « lldp tlv select » entrées.

Paramétrage spécifique de LLDP à une interface

Activer l’émission des LLDPDUs

3750-1(config-if)#lldp transmit

Désactiver l’émission des LLDPDUs

3750-1(config-if)#no lldp transmit

Activer la réception des LLDPDUs

3750-1(config-if)#lldp receive

Désactiver l’émission des LLDPDUs

3750-1(config-if)#no lldp receive

Notez que par défaut, les interfaces envoient et reçoivent les LLDPDU une fois que LLDP est activé globalement.

Vous pouvez également défini les TVLs mais aussi les MED-TLV à émettre par l’interface. Par exemple:

3750-1(config-if)#lldp tlv-select ?
  power-management  IEEE 802.3 DTE Power via MDI TLV

Et…

3750-1(config-if)#lldp med-tlv-select ?
  inventory-management  LLDP MED Inventory Management TLV
  location              LLDP MED Location TLV
  network-policy        LLDP MED Network Policy TLV
  power-management      LLDP MED Power Management TLV

Pour conclure

Comme beaucoup de protocoles standardisé, LLDP hérite quasi toutes ses fonctionnalités de ses prédécesseurs propriétaires. A priori, lorsque son implémentation sera plus globale, il remplacera CDP avec aisance.
Là ou Cisco a clairement pensé à nous, c’est dans son implémentation. Vous utilisez CDP ? Alors changez un mot clé dans la commande et vous savez utiliser LLDP ! (« show cdp neighbors » ou « show lldp neighbors » … quelle différence ?).

Voici donc un des sujets ajoutés dans la nouvelle version dde l’examen CCNP Switch … pas de quoi fouetter un chat … si ?

❌