CiscoMadeSimple.be

Migration du site

Steve De Jongh — Wed, 02 May 2012 18:26:58 +0000

Après quelques déboires du point de vue stabilité du site suite à de multiples plantages de l’hôte (un RPS OVH pourtant), j’ai décidé de migrer CiscoMadeSimple.be sur une plateforme un peu plus fiable. Il se pourrait donc que certaines erreurs se produisent (liens morts, …) n’hésitez pas à poster votre feedback en commentaire à ce post si vous rencontrer une quelconque anomalie.

Bonne visite.

Reset d’un switch Cisco … avec un doigt !

Steve De Jongh — Mon, 05 Mar 2012 17:08:37 +0000

Remettre la config d’un switch à zéro n’est pas très compliqué:

SW1# erase nvram:
SW1# delete flash:vlan.dat
SW1# reload

Mais saviez-vous que par défaut il y a bien plus simple encore ?

La méthode qui suit semble être valable pour les switches relativement récents (IOS >= 12.1(14)EA1) et possédant un bouton « Mode ».

La méthode:

Quand le switch est en fonctionnement, appuyez sur le bouton « Mode » et maintenez enfoncé pendant +/- 10 secondes. Vous noterez que dans un premier temps les leds système etc clignotent, et finissent par se figer. A ce moment là relâchez … Et hop … config à zéro et reload automatique à la clé.

A l’origine il s’agit d’une fonctionnalité permettant d’accéder à la configuration du switch par un port ethernet via un browser. En réalité le switch passe en mode « express setup », se configure l’adresse ip 10.0.0.1 sur l’interface VLAN1 et active son serveur DHCP pour fournir une config à un éventuel client. Pour fonctionner le switch ne peut avoir de config active … c’est la raison pour laquelle il s’en débarrasse au lancement de la méthode.

Pratique quand on ne sait pas comment accéder au CLI par le port console … mais surtout … dangereux dans un environnement en production ! A désactiver sans le moindre doute non ?

J’ai testé la méthode sur un c2960-24, sur un c3560-24 et Funkychild (merci pour l’info) me confirme que cela fonctionne également sur les tout récents c3750. A priori, sont concernés les 29xx, 35xx et 37xx.

Désactiver l’express setup

Rien de plus simple, en configuration globale:

SW1(config)# no express setup

A noter que cela ne désactive pas le service de password recovery que l’on lance gardant le bouton mode enfoncé tout en débranchant et rebranchant l’alim du switch.

Remerciements:

Merci à Funkychild pour m’avoir rappelé l’existence de cette commande et surtout de m’avoir indiqué les danger de l’express setup !

IOS: « enable password » vs « enable secret »

Steve De Jongh — Sun, 04 Mar 2012 16:24:23 +0000

Petite piqûre de rappel, cela ne fait jamais de tort … Au cours des formations dont je m’occupe, je m’aperçois souvent que l’utilité et l’existence de ces deux commandes reste assez floues malgré leur apparente simplicité. Voici donc en quelques lignes ce dont il s’agit…

Tout d’abord, rappelons que ces eux commandes, à savoir « enable password » et « enable secret », ont toute deux la même fonction: définir le mot de passe pour accéder au mode privilégié du CLI.

R1>enable
Password:
R1#

La question qui en découle est donc la suivante: « Pourquoi deux commandes pour faire la même chose ? ». La réponse est simple et réside dans la manière ou l’IOS encode le mot de passe dans la config de l’équipement.

Avec « enable password » le mot de passe défini est encodé en clair dans la config.

R1(config)#enable password cisco

R1#show running-config
Building configuration...
Current configuration : 470 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname R1
!
!
!
enable password cisco
!
!

Tandis qu’avec la commande « enable secret » le mot de passe est stocké sous forme de hashage MD5, ce qui rend cette version beaucoup plus sécurisée…

R1(config)#enable secret cisco

R1#sh running-config
Building configuration...
Current configuration : 517 bytes
!
version 12.4
no service timestamps log datetime msec
no service timestamps debug datetime msec
no service password-encryption
!
hostname R1
!
!
!
enable secret 5 $1$mERr$hx5rVt7rPNoS4wqbXKX7m0
!

Notez que dans la config le chiffre « 5″ précède la version « cryptée » du mot de passe. Le but ici est de permettre de copier la commande telle qu’elle apparaît dans la config sur un autre équipement. Ainsi l’autre équipement saura que le mot passe donné dans la commande est en fait une version cryptée et qu’il ne doit pas la repasser par le hashage MD5.

Reste maintenant à savoir pourquoi ces deux commandes existent … He bien rien de plus banal, c’est tout simplement pour assurer une rétro-compatibilité des config. De sorte que si vous copiez la config d’un équipement qui ne supporte pas la version « enable secret » vers un nouvel équipement, ce dernier puisse quand même accepter l’ancienne version.

Fiche récapitulative n°6 : Spanning-Tree Protocol (STP)

Steve De Jongh — Mon, 12 Dec 2011 21:31:20 +0000

Voici la sixième fiche récapitulative. Celle-ci est consacrée à STP, ses principes, son fonctionnement et sa configuration de base.

F06 – Spanning-Tree Protocol (STP)

Bonne lecture!

Access-list « réflexive »

Steve De Jongh — Tue, 29 Nov 2011 23:10:36 +0000

Lorsque l’on veut protéger un réseau du trafic venant de l’extérieur, on est souvent confronté au problème suivant : « Comment prévoir ce qui peut/devrait pouvoir passer ? ». D’un point de vue général, la politique la plus sécuritaire consiste à bloquer tout trafic par défaut et n’autoriser que le strict nécessaire, mais cela devient vite difficile à gérer si on ne veut pas trop brider les communication provenant de l’intérieur du réseau.

Il existe plusieurs méthodes pour gérer au mieux cette situation:

Le filtrage sur base des flags TCP (un segment tcp entrant n’ayant pas le flag ACK activé ne peut pas être originaire de l’intérieur, …), l’inconvénient majeur, c’est qu’il n’est pas possible d’en faire de même pour le protocole UDP.
Le filtrage par Access-list réflexive, ce que nous allons voir ici, qui consiste à générer une ACL dynamiquement en fonction du trafic sortant afin d’autoriser temporairement le retour.
Les « Zone-Based Firewall » qui se basent sur le principe de définition de zones et de création de règles d’une zone à une autre (la méthode la plus moderne).

Voyons ce qu’il en est pour les ACL réflexives …

La topologie

Un LAN internet (192.168.0.0/24) est connecté à Internet par l’intermédiaire de R2 qui est configuré pour faire du NAT overload.

R1 a une route par défaut qui pointe vers R2, R2 une route par défaut vers R3. R3 ne connait que 80.0.0.0/30.

Objectif

Configurer R2 de sorte qu’il n’autorise les paquets provenant d’Internet à l’unique condition qu’ils correspondent à une « conversation » initiée depuis le LAN interne.

Méthode générale

Configurer une ACL définissant le trafic autorisé à sortir (LAN vers Internet) en spécifiant l’ACL dynamique à peupler.
Appliquer cette ACL sur une interface.
Créer un ACL correspondant au trafic autoriser à entrer où l’on fait évaluer l’ACL dynamique.
Appliquer cette ACL en sens inverse de l’ACL pour le trafic sortant.

Considération dans le cas présent

Le NAT ne nous facilite pas la vie. Il faut garder en mémoire que l’opération du NAT (modification de l’adresse source du paquet) est effectuée avant le filtrage. Dés lors si on n’y prête pas attention on risque fort de ne pas arriver à identifier correctement le trafic.

Dés lors il faut commencer par se fixer une base de travail, à savoir, à quel moment le filtrage aura lieu. Si on le fait sur l’interface de R2 côté LAN, on devra tenir compte des adresses locales, si on filtre à la sortie de l’interface côté publique, il faudra traiter les données en fonction de l’adresse utilisée par le NAT.

Pour la configuration, on filtrera la trafic côté LAN de R2. L’avantage majeur est que l’on peut distinguer les adresses privées, l’inconvénient c’est que le routeur effectuera l’opération de routage même si les paquets termineront à la poubelle juste après.

Configuration

Commençons par créer l’ACL autorisant le trafic sortant:

R2(config)#ip access-list extended ACL-L2W
R2(config-ext-nacl)#permit ip 192.168.0.0 0.0.0.255 any reflect ACL-REFLECTED
R2(config-ext-nacl)#exit

ACL-L2W (Lan to Wan) sera l’ACL que l’on appliquera sur l’interface côté LAN de R2 en « input ». On y autorise le traffic ip (n’importe quel protocole) provenant de 192.168.0.0/24 vers n’importe quelle direction.

L’instruction reflect indique au routeur qu’il devra créer une règle réflexive (correspondant au trajet inverse) dans l’access-list dynamique ACL-REFLECTED.

Créons maintenant l’ACL qui filtrera le trafic entrant et que l’on appliquera de nouveau sur l’interface LAN de R2 mais cette fois en « output ».

R2(config)#ip access-list extended ACL-W2L
R2(config-ext-nacl)#evaluate ACL-REFLECTED
R2(config-ext-nacl)#exit

ACL-W2L (Wan to Lan) ne contient ici qu’une seule instruction, evaluate ACL-REFLECTED, qui indique au routeur qu’il doit utiliser les règles cntenues dans l’ACL ACL-REFLECTED. Pour ceux qui ont des notions de programation, cela reviendrait à faire un « include » en PHP par exemple.

Il reste maintenant à appliquer ces deux ACL sur l’interface LAN (Fa0/0 dans le cas présent) de R2.

R2(config)#int fa0/0
R2(config-if)#ip access-group ACL-L2W in
R2(config-if)#ip access-group ACL-W2L out

Vérification

Commençons par vérifier si R1 arrive bien à communiquer avec R3, cela devrait fonctionner puisqu’il génèrerait des paquets provenant de 192.168.0.10 à destination de 80.0.0.1, ce qui correspond à la clause « permit » de ACL-L2W.

R1#ping 80.0.0.1

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

A priori tout va bien … vérifions le fonctionnement des ACLs…

R2#sh access-lists
Standard IP access list 1
    10 permit 192.168.0.0, wildcard bits 0.0.0.255 (5 matches)
Extended IP access list ACL-L2W
    10 permit ip 192.168.0.0 0.0.0.255 any reflect ACL-REFLECTED (5 matches)
Reflexive IP access list ACL-REFLECTED
 permit icmp host 80.0.0.1 host 192.168.0.10 (5 matches) (time left 286)
Extended IP access list ACL-W2L
    10 evaluate ACL-REFLECTED
R2#

L’access-list 1 est utilisée ici pour le NAT, elle n’est utile pour la vérification. Ce qui nous intéresse ici, c’est l’ACL-L2W … « 5 matches » … les 5 paquets icmp générés par le ping sont bien passés et ont été traités correctement par l’ACL. Mieux encore … l’ACL-REFLECTED contient une règle qui correspond au traffic correspondant à la réponse de R3 au ping de R1: des paquets ICMP en provenance de 80.0.0.1 à destination de 192.168.0.10.

Quelques remarques

Comme je l’ai dit un peu plus haut, le NAT est assez gênant dans le sens où il nous impose de travailler en in et out du même côté de R2. Si les ACLs étaient appliquées du côté WAN de R2, il aurait fallu remplacer la règle « permit ip 192.168.0.0 0.0.0.255 …. » par « permit ip host 80.0.0.2 any … « , puisqu’à la sortie de l’interface WAN de R2, l’adresse source des paquets est remplacée par l’adresse configurée sur son interface WAN.
Point important … l’utilisation d’access-list réflexive ne peut se faire que dans des access-list étendues.
Il est tout à fait possible de mélanger des règles statiques avec une ou plusieurs instructions « evaluate », il faut juste garder en tête qu’une ACL s’exécute séquentiellement, règle après règle, par ordre de séquence. Les règles contenues dans l’ACL évaluées seront donc exécutées comme si elles étaient définies à cet endroit dans l’ACL.
En l’absence de NAT, il vaut clairement mieux appliquer l’ACL autorisant le trafic sortant côté interne en input, et l’ACL filtrant le trafic entrant côté extérieur en « input » également. Cela évite au routeur de traiter des paquets qui ne sont pas autorisés.

Coexistence IPv4-IPv6 : Tunnel dynamique 6-to-4

Steve De Jongh — Thu, 17 Nov 2011 20:06:39 +0000

A l’heure ou l’implémentation de l’IPv6 dans les réseaux s’accélère (certes encore trop lentement), on observe des situations délicates du point de vue de la coexistence IPv6-IPv6. Cet article a pour objectif d’expliquer la configuration d’une méthode de transition, les tunnels dynamiques 6-to-4…

Introduction

Cette technique fait partie de celles qui ont pour but de permettre l’interconnexion de plusieurs « îlots » IPv6 en passant au travers d’un réseau IPv4. L’idée principale est, du point de vue du réseau IPv4, de considérer les paquets IPv6 comme étant les données à faire transiter, ce qui aura pour effet d’encapsuler le paquet IPv6 dans un paquet IPv4 (delà la notion de tunnel faisant référence à l’encapsulation entre deux points donnés).

Les tunnels 6-to-4 dynamiques, comme leur nom l’indique ne sont pas figés, c’est à dire qu’ils sont établis à la demande. D’un point de vue du fonctionnement, cela sous-entend que la source du tunnel ne change pas, mais par contre la destination, elle, n’est pas définie.

Comment peut-on établir un tunnel si il n’y a pas de destination ?

C’est là la particularité du 6-to-4, la destination du tunnel n’est pas figée, mais elle est toutefois fournie par le biais de l’adresse destination contenue dans le paquet IPv6, ce qui fait que le tunnel aboutira à un endroit donné, selon le réseau de destination qu’il faut atteindre… Oui mais comment ?

L’astuce réside dans l’adressage IPv6 de l’ilot. Avec du 6-to-4, il faut absolument respecter les règles suivantes:

L’adresse globale de l’îlot doit faire partie des adresses 2002::/16 (espace d’adresses réservées pour le 6-to-4)
L’adressage de l’îlot doit être fonction de l’adresse IPv4 qui donne accès au réseau IPv4 « central ».

Prenons un exemple concret:

Trois îlots IPv6 sont séparés par un réseau IPv4. Afin de pouvoir utiliser des tunnels 6-to-4, il faut adresser ces ilots IPv6 en tenant compte de l’adresse IPv4 du routeur d’accès. Donc par exemple, l’ilot situé derrière R1 sera adressé en fonction de 192.168.0.1.

L’adresse 6-to-4 de l’îlot sera composée comme ceci: 2002:PREFIX:IPV4::/48, c’est-à-dire que l’on doit incorporer l’adresse IPv4 traduite en hexadécimal dans l’adresse IPv6. Le préfixe 2002: forme les 16 premiers bits, les 32 bits suivants seront ceux de l’adresse IPv4, le tout formant un réseau /48. Ensuite tous les sous-réseaux de l’îlot doivent appartenir à cette adresse générale.

Concrètement, l’ilot IPv6 derrière R1 aura l’adresse: 2002:C0A8:1::/48 ( 192=C0, 168=A8,0 = 00, 1 = 01, soit 2002:C0A8:0001:: où on peut omettre les 0 non significatif).

On aura donc au final trois îlots:

R1: 2002:C0A8:1::/48
R2: 2002:C0A8:2::/48
R3: 2002:C0A8:3::/48

Etant donné qu’en IPv6 la bonne pratique veut que l’on attribue un subnet en /64 par sous-réseau, il reste 16 bits pour effectuer les découpes (soit 65536 sous-réseaux). Pour l’exercice, on utilisera un seul sous-réseau de chaque côté. Comme ceci:

Fonctionnement des tunnels 6-to-4

Prenons par exemple un PC situé derrière R1 qui communique au travers du tunnel 6-to-4 (qui n’est pas encore configuré dans cet article bien entendu ) avec un PC sur le réseau IPv6 de R2. Lorsque le paquet IPv6 arrive sur R1, ce dernier constate qu’il s’agit d’un paquet à destination d’un réseau 6-to-4, il déduit donc l’adresse IPv4 du routeur qui donne accès à ce réseau IPv6 (soit ici 192.168.0.2), il peut donc générer un paquet IPv4 à destination de 19.168.0.2 qui contiendra le paquet IPv6 d’origine.

Le paquet IPv4 arrive à R2, R2 constate qu’il contient un paquet IPv6 pour un réseau auquel il est connecté et n’a donc plus qu’à l’y diffuser.

Entre R1 et R2 la structure des données serait la suivante:

|ETHERNET|-|IPv4|-|IPv6|-|DATA|

L’avantage principal de ce genre de tunnel est l’évolutivité. Il n’est pas nécessaire de configurer plus d’un tunnel localement, puisque la destination est définie dynamiquement. Par contre, l’inconvénient majeur de cette technique, c’est qu’il n’est pas possible, sans avoir recours à d’autre technique, d’utiliser un protocole de routage entre les deux ilots IPv6. Il faut obligatoirement travailler avec du routage statique.

Ceci dit, il suffit de rajouter une route 2002::/16 qui pointe vers le tunnel … ce n’est pas la mer à boire !.

Configuration des tunnels 6-to-4

Sur chaque routeur, il faut créer une interface Tunnel avec les paramètres suivants:

Mode IPv6ip 6to4
Source : adresse IPv4 ou nom de l’interface ipv4
Destination: aucune!
Adresse IPv6: 2002:PREFIX:IPV4:????::/64

Il faut donc attribuer une adresse IPv6 correspondant à un subnet de l’îlot à l’interface du tunnel.

En détail pour R1…

Configuration de l’interface ethernet (ipv4)

R1>en
R1#conf t
R1(config)#int fa0/0
R1(config-if)#ip address 192.168.0.1 255.255.255.0
R1(config-if)#no shut
R1(config-if)#exit

Configuration de l’interface loopback IPv6 (simulation du réseau derrière R1) et activation du routage IPv6

R1(config)#ipv6 unicast-routing
R1(config)#interface loopback 0
R1(config-if)#ipv6 address 2002:C0A8:1::1/64
R1(config-if)#exit

Configuration du tunnel 6-to4 et de la route IPv6

R1(config)#interface Tunnel 0
R1(config-if)#tunnel mode ipv6ip 6to4
R1(config-if)#tunnel source fa0/0
R1(config-if)#ipv6 address 2002:C0A8:1:FFFF::1/64
R1(config-if)#exit
R2(config)#ipv6 route 2002::/16 Tunnel 0

Il reste ensuite à configurer R2 et R3 selon le même principe:

Pour R2:

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
no ip domain lookup
!
ipv6 unicast-routing
multilink bundle-name authenticated
!
archive
 log config
  hidekeys
!
interface Loopback0
 no ip address
 ipv6 address 2002:C0A8:2::1/64
!
interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:C0A8:2:FFFF::1/64
 tunnel source FastEthernet0/0
 tunnel mode ipv6ip 6to4
!
interface FastEthernet0/0
 ip address 192.168.0.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ipv6 route 2002::/16 Tunnel0
!
control-plane
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
end

Enfin, pour R3:

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
no ip domain lookup
!
ipv6 unicast-routing
multilink bundle-name authenticated
!
archive
 log config
  hidekeys
!
interface Loopback0
 no ip address
 ipv6 address 2002:C0A8:3::1/64
!
interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:C0A8:3:FFFF::1/64
 tunnel source FastEthernet0/0
 tunnel mode ipv6ip 6to4
!
interface FastEthernet0/0
 ip address 192.168.0.3 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ipv6 route 2002::/16 Tunnel0
!
control-plane
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
end

Il ne reste maintenant plus qu’à vérifier …

R1#ping ipv6 2002:c0a8:3::1 source 2002:c0a8:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:C0A8:3::1, timeout is 2 seconds:
Packet sent with a source address of 2002:C0A8:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/36/56 ms

R1#ping ipv6 2002:c0a8:2::1 source 2002:c0a8:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:C0A8:2::1, timeout is 2 seconds:
Packet sent with a source address of 2002:C0A8:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/44 ms
R1#

Tout est en ordre, les réseaux derrière R1, R2 et R3 peuvent communiquer entre eux, au travers du réseau IPv4 !

IPv6 : e-Learning gratuit

Steve De Jongh — Wed, 26 Oct 2011 19:29:44 +0000

L’Union Européenne subsidie un projet d’e-learning concernant l’IPv6 … visiblement le contenu est au moins en partie gratuit et plutôt bien réalisé pour autant que l’anglais ne vous rebute pas…

http://www.6deploy.com/e-learning/english/

Fiche récapitulative n°5 : Configuration d’interface Frame-Relay

Steve De Jongh — Wed, 26 Oct 2011 18:49:16 +0000

Après une bonne grosse période d’inactivité, voici une nouvelle fiche récapitulative. Celle-ci reprend les différents types de configurations d’interface frame-relay, selon que l’on utilise l’interface physique, une sub-interface point-à-point ou encore une sub-interface multipoints, avec ou sans inverse-arp.

F05 – Configuration d’interface Frame-Relay

Fiche récapitulative n°4 : Les ACLs (Access Control Lists)

Steve De Jongh — Fri, 03 Jun 2011 20:22:20 +0000

Voilà déjà quelques semaines que je n’ai plus apporté d’eau au moulin… C’est ce qui arrive quand on mène plusieurs projets de front (il y en a quand même un qui concerne Cisco ). Afin d’apporter un peu de contenu supplémentaire, voici la 4ème fiche récapitulative. Celle-ci est consacrée aux ACLs.

F04 – Les ACLs (Access Control Lists)

En espérant qu’elle sera appréciée… bonne lecture!

Fiche récapitulative n°3 : RIP (Routing Information Protocol)

Steve De Jongh — Fri, 08 Apr 2011 17:43:23 +0000

Voici la troisième fiche récapitulative, celle-ci est dédiée à RIP (v1 et v2), à ses généralités et sa configuration.

F03 – RIP (Routing Information Protocol)

Bonne lecture!