Blog sur les technologies réseau et sécurité

CCNP/ONT Yeah !

Bastien Migette — Wed, 17 Feb 2010 16:03:00 +0000

Ca y est, je suis CCNP ! Je viens de passer ONT.

CCNP

Pour le feedback, voir ici:

http://forum.madrouter.com/ont-feedback-t79.html

J’ai plus qu’a attendre le petit logo cisco pour me la péter sur mon CV

J’en profites pour mettre mes notes des différentes certifs, plus ou moins bien organisées, si j’avais le (temps|courage) je ferais un truc propre mais bon.
notes_bcmsn
notes_iscw
notes_bsci
notes_ont

Prochaine étape, je vais aller faire un petit tour dans les locaux de Cisco France et tâter de l’IPS (ASA5510/AIP-SSM) pour continuer ma CCSP

Une nouvelle page: Recrutez-moi

Bastien Migette — Tue, 16 Feb 2010 16:13:21 +0000

Etant maintenant à mon compte, je proposes différents services aux entreprises.

Plus d’information ici:
http://bmigette.fr/recrutez-moi/

N’hésitez pas à me contacter pour toute information.

Une de plus: BSCI passée aujourd’hui

Bastien Migette — Mon, 08 Feb 2010 17:45:54 +0000

Voici le feedback pour ceux que ça intéresse:

http://forum.madrouter.com/bsci-feedback-t75.html

Evolution du blog

Bastien Migette — Thu, 04 Feb 2010 22:37:14 +0000

Cela fait plus d’un an maintenant que mon blog est lancé, et bien que le trafic continue d’augmenter chaque mois, sauf la période plate d’il y a quelque temps, dont une partie s’explique par le fait que l’extension pour les stats étaient plantée (voir ci dessous), je ne vois que peux de commentaires.

Aussi, j’ai décidé de faire confiance à akismet (l’extension antispam), et d’autoriser les commentaires aux utilisateurs sans qu’ils n’aient besoin de s’inscrire, ceci afin, je l’espère, que chacun puisse participer un peu aux différents articles (cela vous a t-il été utile, y a t-il des erreurs, des précisions que l’on pourrait rajouter…).

Trafic global:

Vues par mois

Lab BSCI OSPF/OSPFv3

Bastien Migette — Thu, 28 Jan 2010 17:02:58 +0000

Un petit lab OSPF pour préparer BSCI, ou l’on va explorer tout ce que sont que ces notions bizarres de types de LSA, la problématique des réseaux NBMA, le routage OSPF multi aires, les routeurs type ABR, ASBR…

Ici, je vais tout faire en dual-stack ipv4/ipv6 juste pour le fun.

Voici la topologie:

Topologie

Introduction

Le fichier dynagen:

#!/bin/dynagen
sparsemem = True
#autostart = false

#================================#
#	HYPERVISOR 1 : AREA 0        #
#================================#
[localhost:7200]
udp=10000
	[[2621XM]]
		image = ../images/C2600-ADIP_12.4.BIN
		ram = 96
		idlepc = 0x82012bd4
		confreg = 0x2102

	[[ROUTER ASBR1]]
		model = 2621XM
		S0/0 = FRSW 1
		F0/0 = ISP F0/0

	[[ROUTER ABR1]]
		model = 2621XM
		S0/0 = FRSW 2
#ABR2 H4
	[[ROUTER ABR3]]
		model = 2621XM
		S0/0 = FRSW 4
		F0/1 = SW 1
	[[FRSW FRSW]]
		1:101=2:101
		1:102=3:102
		1:103=4:103

#================================#
#	HYPERVISOR 2 : AREA 1 & Net  #
#================================#
[localhost:7201]
udp=10100
	[[2621XM]]
		image = ../images/C2600-ADIP_12.4.BIN
		ram = 96
		idlepc = 0x82012bd4
		confreg = 0x2102

	[[ROUTER STUB1]]
		model = 2621XM
		S0/0 = ABR1 S0/1
	[[ROUTER ISP]]
		model = 2621XM
		F1/0 = ISPv6 F0/0
	[[ROUTER ISPv6]]
		model = 2621XM		

#================================#
#	HYPERVISOR 3 : AREA 2        #
#================================#
[localhost:7202]
udp=10200
	[[2621XM]]
		image = ../images/C2600-ADIP_12.4.BIN
		ram = 96
		idlepc = 0x82012bd4
		confreg = 0x2102
	[[ROUTER ASBR2]]
		model = 2621XM
		F0/0 = SW 2
		F0/1 = ISP F0/1
	[[ROUTER NSSA1]]
		model = 2621XM
		F0/0 = SW 3
	[[ETHSW SW]]
		1=access 1
		2=access 1
		3=access 1
#================================#
#	HYPERVISOR 4 : AREA 3 & 4    #
#================================#
[localhost:7203]
udp=10300
	[[2621XM]]
		image = ../images/C2600-ADIP_12.4.BIN
		ram = 96
		idlepc = 0x82012bd4
		confreg = 0x2102
	[[ROUTER ABR2]]
		model = 2621XM
		S0/0 = FRSW 3
		F0/1 = ABR4 F0/0
	[[ROUTER ABR4]]
		model = 2621XM
		F0/1 = RTR1 F0/0
	[[ROUTER RTR1]]
		model = 2621XM

Comme pour l’article précédent, les configurations seront mises tout au long de l’article.
Pour commencer, voici les configurations initiales: configs_initial.tar (vérifier la config de ABR3)
Pour l’IPv6 sur frame relay, l’inverse-arp n’est pas encore implémenté sur IOS, en tous cas sur les 12.2, j’ai pas testé sur le 12.4, j’ai donc fait des mapping manuels via la commande frame-relay map ipv6 ip dlci BROADCAST(à rajouter, j’ai oublié).
Pour la connexion internet, je ne mettrais pas d’IPv6 car j’ai envie de tester le NAT-PT et les tunnels

Area 0 : Réseaux NBMA

dans un réseaux non broadcast, un routeur n’aura pas forcément un accès direct aux autres routeurs, même si ceux-ci sont dans le même réseau, l’exemple le plus flagrant est celui du frame-relay partia-mesh ou hub and spoke comme dans notre exemple. Cela pose donc des problème, puisque admettons qu’ABR1 avertisse une route vers ASBR1, et que celui-ci la transmette a ABR2, ABR2 aura ABR1 en nexthop, mais ne saura pas y accéder (sauf si on rajoute un mappage ou une route manuellement).
On va donc voir plus en détail ces problèmes. Dans les configurations OSPF, je vais coder le router-id à la main, car en effet, par défaut il est calculé automatiquement en prenant en compte la plus grande interface, mais il suffit que l’on change ou rajoute une adresse IP, lorsque le process OSPF sera redémarré, cela peut changer la topologie et créer des erreurs.

Pour la configuration OSPF/OSPFv3, voici les commandes (remplacer les routers ID, et ajoutez les réseaux 10.X.0.0 sur ABR[1|2|3] dans les bonnes aires)

ASBR1(config)#router ospf 1
ASBR1(config-router)#network 10.0.0.0 0.0.0.255 area 0
ASBR1(config-router)#router-id 10.0.0.1
ASBR1(config-router)#ipv6 router ospf 1
ASBR1(config-rtr)#router-id 10.0.0.1
ASBR1(config-rtr)#interface serial 0/0
ASBR1(config-if)#ipv6 ospf 1 area 0
ASBR1(config-if)#exit

Et la on s’aperçois qu’aucun voisins ne passe en FULL, ils ne sont d’ailleurs pas reconnu. Pour la suite des choses je vais faire les différentes config uniquement pour IPv4 car cela fonctionne à l’identique pour IPv6, puis pour la configuration finale je reviendrai sur l’IPv6.

Cela s’explique de manière très simple (remarquez au passage ma maitrise de la CLI IOS ):

ASBR1#sh ip ospf interface | i 0/0 | Type
Serial0/0 is up, line protocol is up
  Process ID 1, Router ID 10.0.0.1, Network Type NON_BROADCAST, Cost: 64

Par défaut, le réseau est non broadcast, donc pas d’envoi de messages multicast pour la découverte des voisins. Si on veut activer les voisins, sur ce type de réseau, il faut les déclarer statiquement via la commande neighbor. Il n’est pas nécéssaire de le faire sur tous les routeurs puisqu’un routeur répondras aux hellos même s’ils viennent d’un voisin non déclarés statiquement, mais n’en enverra pas.

Sur ASBR1 donc:

ASBR1(config)#router ospf 1
ASBR1(config-router)#neighbor 10.0.0.2
ASBR1(config-router)#neighbor 10.0.0.3
ASBR1(config-router)#neighbor 10.0.0.4
ASBR1(config-router)#exit
*Mar  1 00:38:06.531: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.2 on Serial0/0 from LOADING to FULL, Loading Done
*Mar  1 00:38:13.570: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.3 on Serial0/0 from LOADING to FULL, Loading Done
*Mar  1 00:38:25.710: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.4 on Serial0/0 from LOADING to FULL, Loading Done

Donc mes voisins sont montés (cela peut prendre du temps, jusqu’a 1 minute…), mais est-ce que cela marche pour autant ?

Oui et non. Regardons ces commandes:

ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.2.0.0 is directly connected, FastEthernet0/1
C       10.0.0.0 is directly connected, Serial0/0
O IA    10.1.0.0 [110/192] via 10.0.0.1, 00:14:19, Serial0/0
ABR3#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.1          1   FULL/BDR        00:01:33    10.0.0.1        Serial0/0

On voit que mon routeur ASBR1 n’est pas le DR, seulement, les routes sont donc apprise par ASBR1, mais vue comme un saut supplémentaire, pas comme si c’était le DR qui les avait averties. On va donc passer ASBR1 en DR avec la commande ip[v6] ospf priority 10, et on va mettre les autres routeurs à 0 pour qu’il n’y ai pas de BDR (il faudrait un deuxième routeur avec 3 PVCs), puis pour que les changements soient reflettés, on va faire un clear ip[v6] ospf process (et attendre que les voisins montent, longtemps,…)

ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 3 subnets
C       10.2.0.0 is directly connected, FastEthernet0/1
C       10.0.0.0 is directly connected, Serial0/0
O IA    10.1.0.0 [110/128] via 10.0.0.2, 00:00:17, Serial0/0

Voyez que le cout à baissé, et que le next-hop n’est plus ASBR1, mais bien le bon routeur dans le réseau (ABR1). Ceci est le comportement normal, lorsqu’on est dans un réseau multi accès, un routeur avertissant une route devient le nexthop pour cette route pour les autres routeurs du réseau.

Ici avant la configuration du DR, vu que ce dernier n’était pas le bon routeur et que ASBR1 et ABR3 avaient formé une relation de voisinage, ASBR1 avertissait des routes, mais pas en tant que DR, bref, un gros bazard…Qui est loin d’être fini d’ailleurs: On remarque que le nexthop est bien ABR1, seulement, notre routeur ne sait pas joindre cette IP car il existe un VC frame relay uniquement entre ABR1 et ASBR1.
Ici plusieurs options s’offrent à nous (sans configurer de circuits virtuels supplémentaires):

Faire un mappage frame-relay manuel sur les ABR 1, 2 et 3 en mappant les next-hops vers leur DLCI de sortie
Faire un mappage des IPs des voisins avec des routes statiques et ASBR1 en nexthop
Activer l’option ip ospf network point-to-multipoint (sur tous les routeurs, si network type différent, pas d’adjacence), ce qu’on va faire.
On pourrait aussi utiliser des sous interfaces sur ASBR1 et faire des réseau point-to-point, mais cela necessiterai des sous réseaux séparés sur ASBR1.

On commence par enlever les neighbor, car toute la beauté de cette solution c’est qu’ils seront découverts dynamiquement (pour peu que votre réseau NBMA supporte le multicast, sans quoi il faut utiliser point-to-multipoint non-broadcast et laisser les neighbor)

ASBR1(config)#router ospf 1
ASBR1(config-router)#no neighbor 10.0.0.2
ASBR1(config-router)#no neighbor 10.0.0.3
ASBR1(config-router)#no neighbor 10.0.0.4
ASBR1(config-router)#exit
ASBR1(config)#int s0/0
ASBR1(config-if)#ipv ospf network point-to-multipoint
ASBR1(config-if)#ipv6 ospf network point-to-multipoint

N’oubliez pas les autres routeurs ABR 1/2/3

Et maintenant regardez ça :

ABR3#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.2.0.0/24 is directly connected, FastEthernet0/1
O       10.0.0.2/32 [110/128] via 10.0.0.1, 00:01:25, Serial0/0
C       10.0.0.0/24 is directly connected, Serial0/0
O IA    10.1.0.0/24 [110/192] via 10.0.0.1, 00:01:25, Serial0/0
O       10.0.0.1/32 [110/64] via 10.0.0.1, 00:01:25, Serial0/0
ABR3#ping 10.1.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/73/121 ms
ABR3#traceroute 10.1.0.1

Type escape sequence to abort.
Tracing the route to 10.1.0.1

  1 10.0.0.1 44 msec 32 msec 44 msec
  2 10.0.0.2 72 msec 100 msec *

On voit que ASBR1 averti des routes /32 vers les nexthop qui passent par lui !
Note: le mode Point-To-Multipoint n’utilise pas les mécanismes DR/BDR et multiplie donc les adjacences

Pour IPv6, cela ne marche pas, car j’avais oublié de rajouter l’option broadcast dans la commande frame-relay map dans la config initiale, donc modifiez les map (sh run | i map) en rajoutant broadcast pour que ça fonctionne, et la ça ne fonctionne pas, et voici l’explication (bon j’avoue que j’ai fait un petit coup de google :p).

On obtient ça :

*Mar  1 01:56:43.307: %OSPFv3-5-ADJCHG: Process 1, Nbr 10.0.0.4 on Serial0/0 from EXSTART to DOWN, Neighbor Down: Too many retransmits

Un petit coup de debug:

ASBR1#deb ipv osp ev
OSPFv3 events debugging is on
ASBR1#deb ipv6 packet
IPv6 unicast packet debugging is on
*Mar  1 02:00:56.133: OSPFv3: Send DBD to 10.0.0.4 on Serial0/0 seq 0x149B opt 0x0013 flag 0x7 len 28
*Mar  1 02:00:56.133: IPV6: source FE80::CA00:CFF:FE4F:0 (local)
*Mar  1 02:00:56.137:       dest FE80::CA01:CFF:FE4F:0 (Serial0/0)
*Mar  1 02:00:56.137:       traffic class 224, flow 0x0, len 68+0, prot 89, hops 1, originating
*Mar  1 02:00:56.137: IPv6: Encapsulation failed

ABR1#sh ipv6 int br s0/0
Serial0/0                  [up/up]
    FE80::CA01:CFF:FE4F:0
    FC00::A:0:0:2

Vous voyez où je veux en venir ? Dans OSPFv3 les hellos sont envoyés en multicast, les voisins de détectent, mais les mises à jours sont envoyées via les adresses Link-local, or, on a vu, il n’y a pas d’I-ARP pour IPv6 sur frame relay, votre routeur ne sait donc pas ou les router, il faut donc rajouter des frame-relay map broadcast vers les adresses des link local des voisins…
Note: les addresses mac sous dynamips pouvant changer, les adresses link-local vont aussi changer…
On peut modifier ça via la commande ipv6 address FE80::XXX:0 link-local (sans masque)

voici donc le résultat après le mapping:

ASBR1#sh ipv ospf nei

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
10.0.0.3          0   FULL/  -        00:01:59    5               Serial0/0
10.0.0.2          0   FULL/  -        00:01:40    5               Serial0/0
10.0.0.4          0   FULL/  -        00:01:40    5               Serial0/0

Notez qu’il n’y a pas de DR/BDR ce qui est normal. Et la table de routage:

ABR1#sh ipv route ospf
IPv6 Routing Table - 10 entries
O   FC00::A:0:0:1/128 [110/64]
     via FE80::CA00:AFF:FE87:0, Serial0/0
O   FC00::A:0:0:3/128 [110/128]
     via FE80::CA00:AFF:FE87:0, Serial0/0
O   FC00::A:0:0:4/128 [110/128]
     via FE80::CA00:AFF:FE87:0, Serial0/0
OI  FC00::A:2:0:0/120 [110/129]
     via FE80::CA00:AFF:FE87:0, Serial0/0
ABR1#ping FC00::A:2:0:1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FC00::A:2:0:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/69/100 ms

Voilà, notre aire 0 backbone est fonctionelle en IPv4 et IPv6.
Je voudrais attirer votre attention sur le fait qu’on n’est pas obligé d’avoir le même type de réseau OSPF en IPv4 et en IPv6… L’option point-to-multipoint est la plus intéressante si l’on a pas une topologie full mesh, du fait qu’elle palie aux problèmes de communication entre les voisins, cependant, le nombre d’adjacences et donc les ressources peuvent être impactée selon la topologie car vous n’avez pas de DR/BDR. Dans la réalité, il faut prendre en compte que les PVC frame relay ont un cout, mais qu’une topologie comme celle-ci ne fournie pas de redondance… L’utilisation de deux routeurs DR/BDR avec des VC sur chaques routeurs distants et un réseau type NBMA classique avec des map frame-relay manuelles peut être une bonne solution pour de la redondance sans utiliser de réseau full mesh qui nécessite plus de pvc frame-releay (dans ce cas utiliser le type de réseaux broadcast).

Les configs : configs_backbone.tar

Area 1 : Stub area

avant d’attaquer le principe des areas stub, et totally stub que l’on va découvrir, voici la configuration de STUB1:

STUB1(config)#ipv6 unicast-routing
STUB1(config)#router ospf 1
STUB1(config-router)#router-id 10.1.0.1
STUB1(config-router)#network 10.1.0.0 0.0.0.255 area 1
STUB1(config-router)#network 10.1.0.0 0.0.0.255 area 1
STUB1(config)#ipv6 router ospf 1
STUB1(config-rtr)#router-id 10.1.0.1
STUB1(config-rtr)#exit
STUB1(config)#int s0/0
STUB1(config-if)#ipv6 ospf 1 area 1
STUB1(config-if)#int loop0
STUB1(config-if)#ipv6 ospf 1 area 1
STUB1(config-if)#exit

Ici, l’interface n’utilise pas frame relay, et le réseau OSPF est de type point-to-point (par défaut), pas besoin donc de configuration particulière.
Jetons maintenant un coup d’oeil sur la table de routage de STUB1:

STUB1#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA    10.2.0.0/24 [110/193] via 10.1.0.1, 00:11:30, Serial0/0
O IA    10.0.0.2/32 [110/64] via 10.1.0.1, 00:11:30, Serial0/0
C       10.1.1.0/24 is directly connected, Loopback0
C       10.1.0.0/24 is directly connected, Serial0/0
O IA    10.0.0.1/32 [110/128] via 10.1.0.1, 00:11:30, Serial0/0
O IA    10.0.0.4/32 [110/192] via 10.1.0.1, 00:11:30, Serial0/0

On a donc plein de routes, alors que cette aire est isolée (stubbed), et n’a qu’un chemin pour contacter les autres aires. On va donc alléger cette table de routage en « stubbant » l’area.

Pour ce faire, il suffit d’aller sur STUB1 et ABR1, et de taper area 1 stub dans la configuration OSPF (IPv4/6)

Voyons ce qu’on obtiens:

STUB1#sh ip route
Gateway of last resort is 10.1.0.1 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA    10.2.0.0/24 [110/193] via 10.1.0.1, 00:07:03, Serial0/0
O IA    10.0.0.2/32 [110/64] via 10.1.0.1, 00:07:03, Serial0/0
C       10.1.1.0/24 is directly connected, Loopback0
C       10.1.0.0/24 is directly connected, Serial0/0
O IA    10.0.0.1/32 [110/128] via 10.1.0.1, 00:07:03, Serial0/0
O IA    10.0.0.4/32 [110/192] via 10.1.0.1, 00:07:03, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.0.1, 00:07:03, Serial0/0

Vous ne vous attendiez pas à ça hein ? On voit bien qu’on a une route par défaut qui a été ajoutée, mais on a encore les routes IA. Cela vient du fait que par défaut une area stub filtre les LSA type 5 (externes), mais pas les types 3 (inter Area). Pour tout filtrer, il faut rajouter l’option no-summary après area 1 stub, cela crée une aire dite « Totally stubbed »

STUB1(config)#router osp 1
STUB1(config-router)#area 1 stub no-summary
STUB1(config-router)#ipv6 router ospf 1
STUB1(config-rtr)#area 1 stub no-summary
STUB1(config-rtr)#exit
STUB1(config)#^Z
STUB1#sh ip
*Mar  1 00:15:35.228: %SYS-5-CONFIG_I: Configured from console by console
STUB1#sh ip route
Gateway of last resort is 10.1.0.1 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.1.0 is directly connected, Loopback0
C       10.1.0.0 is directly connected, Serial0/0
O*IA 0.0.0.0/0 [110/65] via 10.1.0.1, 00:00:13, Serial0/0
STUB1#sh ipv6 route ospf
OI  ::/0 [110/65]
     via FE80::CA01:AFF:FEC1:0, Serial0/0
STUB1#

C’est mieux non ? Mais on va pouvoir faire quelque chose d’encore mieux! Regardez ça:

ASBR1#sh ip route | i 10.1
O IA    10.1.1.1/32 [110/129] via 10.0.0.2, 00:13:45, Serial0/0
O IA    10.1.0.0/24 [110/128] via 10.0.0.2, 00:14:57, Serial0/0

On voit que toutes les routes de l’aire 1 sont averties séparément, alors que l’on pourrait les regrouper. Ici, on en a que deux, mais il faut imaginer qu’on puisse en avoir des centaine. Pour agréger des routes avec OSPF, il y a deux commandes:

area X range pour les routes OSPF
summary-address pour les routes externes

Cela donne donc ceci (configurer sur l’ABR):

ABR1(config-router)#area 1 range 10.1.0.0 ?
  A.B.C.D  IP mask for address

ABR1(config-router)#area 1 range 10.1.0.0 255.255.0.0
ABR1(config-router)#exit
ABR1(config)#ipv6 router ospf 1
ABR1(config-rtr)#area 1 range FC00::A:1:0:0/96

Vérification:

ASBR1#sh ip route | i 10.1
O IA    10.1.0.0/16 [110/128] via 10.0.0.2, 00:01:13, Serial0/0
ASBR1#sh ipv6 route | i A:1
OI  FC00::A:1:0:0/96 [110/128]

On a donc une belle aire OSPF Totally stubbed !

Areas 3 & 4: Virtual link OSPF

Ceux qui connaissent un petit peu OSPF savent que son design impose que toutes les aires soient reliées à l’aire 0 (d’ailleurs un des avantages de ISIS c’est de ne pas avoir cette contrainte). Cependant, dans la pratique, cela n’est pas toujours possible. Il faut donc créer un lien virtuel qui traverse une aire afin de simuler que notre aire (ici la 4) soit directement connectée. OSPF dispose d’une fonction dédiée à cela, cependant, il est tout à fait possible d’utiliser un tunnel GRE ou IPSEC (avec une VTI pour ne pas bloquer le multicast).

La configuration d’ABR4 de base n’étant pas plus compliquée que ce qu’il y a au dessus, je vais passer les détails:

ABR2(config)#router ospf 1
ABR2(config-router)#netw 10.3.0.0  0.0.0.255 area 3
ABR2(config-router)#int F0/1
ABR2(config-if)#ipv6 ospf 1 area 3
!!!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#net 10.3.0.0 0.0.0.255 area 3
ABR4(config-router)#net 10.4.0.0 0.0.0.255 area 4
ABR4(config-router)#router-id 10.3.0.2
ABR4(config-router)#exit
ABR4(config-if)#ipv6 ospf 1 area 3
ABR4(config-if)#int F0/1
ABR4(config-if)#ipv6 ospf 1 area 4
ABR4(config)#ipv6 router ospf 1
ABR4(config-rtr)#router-id 10.3.0.2

Note, si vous avez des messages %OSPF-4-BADLSATYPE un write mem à suffit à les faire disparaitre… allez savoir !
Donc ici, on va faire une config toute simple sur RTR1 pour le moment:

RTR1(config)#router ospf 1
RTR1(config-router)#router-id 10.4.0.2
RTR1(config-router)#net 10.4.0.0 0.0.0.255 area 4
RTR1(config-router)#net 10.4.1.0 0.0.0.255 area 4
RTR1(config-router)#ipv6 router ospf 1
RTR1(config-rtr)#router-id 10.4.0.2
RTR1(config-rtr)#int loop0
RTR1(config-if)#int F0/0
RTR1(config-if)#ipv6 ospf 1 area 4
OSPFv3: No IPV6 enabled on this interface
RTR1(config-if)#ipv6 enable
RTR1(config-if)#ipv6 address FC00::A:4:0:2/120
RTR1(config-if)#ip add 10.4.0.2 255.255.255.0
RTR1(config-if)#ipv6 ospf 1 area 4
RTR1(config-if)#no sh

Ici, on aura pas de messages d’erreur, mais ABR4 ne transmettras aucune route depuis/vers RTR1.
Pour palier à cela, il y a une commande qui permets de créer un lien virtuel très simplement, dans la configuration d’ospf, sur les 2 ABR de l’aire qui est traversée par le virtual-link (ici l’aire 3), taper area X virtual-link router_id_distant.
Il s’agit ici du router-ID OSPF, et non pas de l’IP de l’interface du routeur. Les routeurs ne sont pas obligé d’être directement reliés entre eux.

ABR2(config)#router ospf 1
ABR2(config-router)#area 3 virtual-link 10.3.0.2
ABR2(config-router)#ipv router ospf 1
ABR2(config-rtr)#area 3 virtual-link 10.3.0.2
!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#area 3 virtual-link 10.0.0.3
ABR4(config-router)#ipv6 router ospf 1
ABR4(config-rtr)#area 3 virtual-link 10.0.0.3
ABR4(config-rtr)#exit
ABR4(config)#
*Mar  1 00:11:10.390: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.3 on OSPF_VL0 from LOADING to FULL, Loading Done

Vérifications:

ABR4#sh ip ospf virtual-links
Virtual Link OSPF_VL0 to router 10.0.0.3 is up
!...
RTR1#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
O IA    10.2.0.0/24 [110/131] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.0.0.2/32 [110/130] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.3.0.0/24 [110/2] via 10.4.0.1, 00:00:27, FastEthernet0/0
O IA    10.0.0.3/32 [110/2] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.1.0.0/16 [110/194] via 10.4.0.1, 00:00:17, FastEthernet0/0
O IA    10.0.0.1/32 [110/66] via 10.4.0.1, 00:00:17, FastEthernet0/0
C       10.4.0.0/24 is directly connected, FastEthernet0/0
O IA    10.0.0.4/32 [110/130] via 10.4.0.1, 00:00:18, FastEthernet0/0
C       10.4.1.0/24 is directly connected, Loopback0

Evidemment ça marche aussi avec IPv6, mais je vais pas vous montrer la table de routage à tout bout de champ…
Bon, jvais totally stubb ça ça va être mieux

RTR1(config)#router ospf 1
RTR1(config-router)#area 4 stub no-summary
RTR1(config-router)#ipv router osp 1
RTR1(config-rtr)#area 4 stub no-summary
RTR1(config-rtr)#^Z
RTR1#
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ABR4(config)#router ospf 1
ABR4(config-router)#area 4 stub no-sum
ABR4(config-router)#ipv router ospf 1
ABR4(config-rtr)#area 4 stub no-sum
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
RTR1#sh ip route
Gateway of last resort is 10.4.0.1 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.4.0.0 is directly connected, FastEthernet0/0
C       10.4.1.0 is directly connected, Loopback0
O*IA 0.0.0.0/0 [110/2] via 10.4.0.1, 00:00:35, FastEthernet0/0

Et la on sens la puissance du stub no-summary !!

Area 2: Une aire pas si stub que ça!

Bon drole de titre, mais l’appellation « not so stubby area » m’a toujours amusé, et je suis rassuré, je ne suis pas le seul, le trainer du CBT nugget BSCI parlait, à ce que j’ai compris, d’australiens adepte de marijuana qui auraient trouvé ce titre. Je ne sais pas si une vérité historique se cache derrière cela, cela mériterai de creuser, mais on s’écarte un peu de notre objectif .

Bon, tout d’abord, qu’est-ce qu’une aire NSSA ? Et bien en fait c’est simplement une aire STUB au niveau OSPF, mais qui contient un ASBR, autrement dit, un routeur qui apprend des routes autrement que par OSPF, et surtout ,qui est connecté à un réseau externe qui n’est pas pris en compte dans la topologie OSPF. Ces routes, lorsque redistribuées dans OSPF, ont un type LSA 7, qui est traduit en type 5 par l’ABR.
Je voudrait attirer votre attention sur le fait qu’il y a 2 types de metriques pour les routes externes (types 5 et 7): 1 = cout incrémenté, 2 = cout non incrémenté, par défaut.
Pourquoi donc cette différence, hé bien prenons mon exemple:

Ici, nous avons 2 connexions internet, il est donc logique que OSPF utilise celle qui est la plus proche, on va donc redistribuer les routes externes avec une metrique de type 1
Il est fréquent de n’avoir qu’une seule connexion internet, et donc, dans ce cas, il n’est pas utile que les routeurs fassent des calculs supplémentaires sur ces routes puisque cela ne changera en rien le résultat, étant donné qu’il n’y a qu’un seul chemin possible.

Pour configurer une NSSA, il suffit de mettre area X nssa dans la configuration d’OSPF, et c’est tout !

ABR3(config)#router ospf 1
ABR3(config-router)#net 10.2.0.0 0.0.0.255 area 2
ABR3(config-router)#area 2 nssa
ABR3(config-router)#ipv6 router ospf 1
ABR3(config-rtr)#area 2 nssa
ABR3(config-rtr)#int F0/1
ABR3(config-if)#ipv6 ospf 1 area 2

NSSA1(config)#router ospf 1
NSSA1(config-router)#net 10.2.0.0 0.0.0.255 area 2
NSSA1(config-router)#area 2 nssa
NSSA1(config)#ipv6 router ospf 1
NSSA1(config-rtr)#area 2 nssa
NSSA1(config-rtr)#int F0/0

ASBR2(config)#router ospf 1
ASBR2(config-router)#area 2 nssa
ASBR2(config-router)#netw 10.2.0.0 0.0.0.255 area 2
ASBR2(config-router)#ipv6 router ospf 1
ASBR2(config-rtr)#area 2 nssa
ASBR2(config-rtr)#int f0/0
ASBR2(config-if)#ipv6 ospf 1 area 2
ASBR2(config-if)#exit

nos routeurs sont donc bien configurés, on aurait pu rajouter l’option no-summary derrière nssa pour alléger la table de routage, mais vu qu’ici on est censé redistribuer une route pour internet, on aurait 2 routes par défaut, et donc des problèmes…

Redistribution internet IPv4

On arrive bientôt à la fin de cet article, ici, je vais inclure les routes vers internet dans OSPF. On verra la subtilité IPv6 plus tard, car j’ai envie de tester le NAT-PT et les tunnels 6to4 (on y reviendra)

Pour inclure une route par défaut, on va utiliser la commande default-information originate que l’on a vu en CCNA, cependant, cette commande ne marche que dans les aire classique OSPF. Pour une aire NSSA il faut procéder comme ce qui suit (la commande ne change pas vraiment).
Note: le redistribute static subnets ne redistribue pas la route statique sous OSPF, alors que cela fonctionne avec EIGRP.

Ici, on va définir le type de metrique à 1 comme vu au dessus, et la metrique pour la route redistribuée à 100.

ASBR2(config)#ip route 0.0.0.0 0.0.0.0 100.0.1.1
ASBR2(config)#router ospf 1
ASBR2(config-router)#area 2 nssa default-information-originate metric 100 metric-type 1
ASBR2(config-router)#exit

On noteras que l’option pour définir le type de métrique existe aussi avec la commande default-information originate (sans tiret s’il vous plaît) pour les aires classiques.
Petites vérif:

ASBR2#sh ip osp database | b Type-7
		Type-7 AS External Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         100.0.1.2       298         0x80000001 0x00199B 0

sur l’ABR:

ABR3#sh ip route | i 0.0.0.0/0
O*N1 0.0.0.0/0 [110/101] via 10.2.0.2, 00:06:07, FastEthernet0/1

noter le type N1 (NSSA External 1), et le coût, puis regardez sur ABR2 (ou n’importe quel autre routeur à l’exterieur de l’airez):

ASBR1#sh ip route | i 0.0.0.0/0
O*E1 0.0.0.0/0 [110/165] via 10.0.0.4, 00:07:51, Serial0/0

On voit que le type passe en E1 lorsque la route quitte l’aire, et que le cout est incrémenté.

On va maintenant redistribuer une route par défaut sur ASBR1, en utilisant une route-map. Cela n’est pas forcément utile ici, vu que l’on a qu’une route, mais l’on aurait pu, dans le cas ou on redistribuerai plusieures routes, leur définir des paramètres différents.

ASBR1(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.1
ASBR1(config)#route-map NETMAP permit 10
ASBR1(config-route-map)#set metric 100
ASBR1(config-route-map)#set metric-type type-1
ASBR1(config-route-map)#exit
ASBR1(config-std-nacl)#exit
ASBR1(config)#router ospf 1
ASBR1(config-router)#default-information originate route-map NETMAP
ASBR1(config-router)#exit

Je peux voir que la le cout à changé sur ABR2 lorsque j’ai redistribué depuis ASBR1:

ABR2#sh ip route
!...
O*E1 0.0.0.0/0 [110/229] via 10.0.0.1, 00:00:42, Serial0/0
ABR2#sh ip route
!...
O*E1 0.0.0.0/0 [110/164] via 10.0.0.1, 00:03:08, Serial0/0
ABR2#

ce qui montre ASBR1 à bien injecté sa route, cepenant, rien n’a changé sur ABR3 puisqu’il garde la route qui passe par l’area 3 étant donné qu’elle a un cout plus faible.
Si l’on avait voulu changé cela, on aurait pu supprimer ou changer le cout de la route par défaut de l’aire 2 avec un filtre sur ABR3.
Aller, vu que je suis d’humeur, on va voir comment faire ça :p

ABR3(config)#ip access-list standard INTERNET_AREA2
ABR3(config-std-nacl)#permit 0.0.0.0 0.0.0.0
ABR3(config)#route-map NO_NET_AREA2 deny 1
ABR3(config-route-map)#match ip address INTERNET_AREA2
ABR3(config-route-map)#match interface F0/1
ABR3(config-route-map)#exit
ABR3(config)#route-map NO_NET_AREA2 permit 2
ABR3(config-route-map)#exit
ABR3(config)#
ABR3(config)#router ospf 1
ABR3(config-router)#distribute-list route-map NO_NET_AREA2 in

Notez le masque generique de 0.0.0.0 = 0.0.0.0/32, soit uniquement cette route, et non toutes les routes.
Piouf, au revoir la route de area 2 SUR ABR3

ABR3(config)#do sh ip route | i 0.0.0.0/0
O*E1 0.0.0.0/0 [110/164] via 10.0.0.1, 00:01:45, Serial0/0

le next-hop n’est plus 10.2.0.2 comme avant.

Je tiens toutefois à préciser que l’utilisation de distribute-list avec OSPF n’enlève pas les routes de l’arbre SPF, mais empêche qu’elles soient installées dans la table de routage, ce qui veut dire que dans l’exemple au dessus, si la connexions internet de ASBR1 tombe, les autres routeur utiliserons la route de ASBR2, mais pas ABR3. Une solution aurait été que ASBR2 augmente la metric lorsqu’il envoi la route à ABR3. Plus d’info ici:

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/routmap.html

Internet pour IPv6

Ici, on va utiliser deux fonctions pour accéder à internet via un réseau IPv4:

La première, c’est du NAT-PT qui permets de faire du nat entre IPv6 et IPv4, mes hosts IPv6 seront donc mappés à une IPv4 en sortant.

La seconde , c’est l’utilisation d’un tunnel 6to4 qui permets à un routeur IPv6 de s’interconnecter avec un FAI en IPv6 en utilisant une connexion IPv4.

Je vais mettre le NAT-PT sur ASBR1 et le 6to4 sur ASBR2.

Commençons déjà par la config des FAI (que je vais pas détaillé, si vous arrivez ici, vous devrier savoir ce qu’est une adresse ip et une route statique )

Router(config)#hostn ISP
ISP(config)#int F0/0
ISP(config-if)#ip add 100.0.0.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#int F0/1
ISP(config-if)#ip add 100.0.1.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#int f1/0
ISP(config-if)#ip add 100.0.2.1 255.255.255.0
ISP(config-if)#no sh
ISP(config-if)#exit

Router(config)#hostn ISPv6
ISPv6(config)#ipv6 unicast-routing
ISPv6(config)#int f0/0
ISPv6(config-if)#ip add 100.0.2.2 255.255.255.0
ISPv6(config-if)#no sh
ISPv6(config-if)#int lo0
ISPv6(config-if)#ipv6 en
ISPv6(config-if)#ipv6 add 2002::1/96
ISPv6(config-if)#exit

et ne pas oublier le routage IPv4 (avec un ptit ping pour la forme)

ISPv6(config)#ip route 100.0.0.0 255.0.0.0 100.0.2.1
ASBR2(config)#ip route 100.0.0.0 255.0.0.0 100.0.1.1
ASBR2(config)#do ping 100.0.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.2.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 16/92/184 ms

Maintenant attaquons la configuration du tunnel 6to4:
voici le template coté enteprise:

interface Tunnel0
 description 6to4 tunnel
 no ip address
 no ip redirects
 ipv6 address 2002:::1/64 !
 tunnel source
 tunnel mode ipv6ip 6to4
ipv6 route 2002::/16 Tunnel0 !Subnet ipv6 du FAI
ipv6 route ::/0 2002:::1 !ip 6to4 du FAI v6

coté FAI, la même chose, si ce n’est que l’on vas router uniquement la route en /64 vers le bon tunnel pour un client donné et pas de route par défaut.
Ici, pas de tunnel destination. La, vous allez me dire, comment ça marche ? tout simplement, lorsque je vais transférer un paquet dans mon tunnel 6to4, celui-ci va décoder l’IPv6 de destination en IPv4, et donc encapsuler l’IPv6 dans un paquet IPv4 avec l’IPv4 dérivée de l’IPv6 du paquet initial. Un tunnel 6to4 est donc multipoint.
voici mes IPv6 pour le 6to4:
100.0.2.2: 2002:6400:0202::1/64 (100=64 en hex)
100.0.1.2: 2002:6400:0102::1/64
et donc la ptite conf du tunnel (je vais pas faire de route par défaut IPv6, juste une globale)

ASBR2(config)#interface tunnel 0
ASBR2(config-if)#desc
*Mar  1 00:27:52.854: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
ASBR2(config-if)#desc cool 6to4 tunnel
ASBR2(config-if)#ipv6 address 2002:6400:0102::1/64
ASBR2(config-if)#tunnel source F0/1
ASBR2(config-if)#tunnel mode ipv6ip 6to4
ASBR2(config-if)#exit
ASBR2(config)#ipv6 route 2002:6400:0202::1/64 tunnel 0
ASBR2(config)#ipv6 route 2002::/16 2002:6400:0202::1

Ici, on a deux routes:
Une route vers le nexthop avec une IP 6to4 via le tunnel 0, qui vas permettre de router les paquets IPv6 qui transitent par ce tunnel vers la bonne IPv4, et le reste des routes IPv6 qui vont utiliser ce nexthop. Il ne faut pas router directement vers le tunnel les autres IPv6, sans quoi elles ne pourront pas, ou mal, être converties en IPv6
la configuration du FAI

ISPv6(config)#interface tunnel 1234
ISPv6(config-if)#desc tunnel 6to4 to my best client
ISPv6(config-if)#tunnel source F0/0
ISPv6(config-if)#ipv6 add 2002:6400:0202::1/64
ISPv6(config-if)#tunnel mode ipv6ip 6to4
ISPv6(config-if)#exit
ISPv6(config)#ipv6 route 2002:6400:0102::1/64 tunnel 1234
ISPv6(config)#exit

Petit ping:

SBR2#ping 2002::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 13/39/68 ms

Une petite capture:

Capture

On pourrait bien entendu router ce réseau via un redistribute static dans ipv6 router OSPF pour faire profiter les copains routeurs, mais je n’y ai pas pensé sur le coup, et j’ai fermé dynamips…

Aller, plus que le NAT-PT et on a terminé

Pour le NAT-PT, j’ai pour l’instant un peu la flemme de remonter mon lab pour tester ça, car c’est très similaire au nat en IPv4, si ce n’est que l’on a des IPv6 en source, et qu’apparement pas de nat inside/outside:

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-nat_trnsln_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1072944

en gros sur ASBR1:

ipv6 nat v6v4 source list IPV6_IP_TO_NAT interface F0/0 overload
ipv6 access-list IPV6_IP_TO_NAT
permit ipv6 any any

cela n’empêche normalement pas de faire du NAT + PAT IPv4 sur la même interface externe.

ISCW Ok

Bastien Migette — Wed, 06 Jan 2010 16:17:22 +0000

Bon ISCW c’est fait, Ok c’était pas avant la fin de l’année, mais les centre étaient fermé pendant les vacs … Incroyable ça les gens travaille pas le jour de noël !

Objectif BSCI/ONT avant mars, et je reprend ma CCSP, je compte l’avoir avant cet été.

Petit feedback :

http://forum.madrouter.com/post195.html#p195

Internetworking Technology Handbook

Bastien Migette — Tue, 29 Dec 2009 13:08:57 +0000

Un petit lien sympa de chez cisco, qui définit la pluspart des termes/technologie relatifs aux réseaux (en anglais)

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Intro-to-Internet.html

ISCW Lab: MPLS VPNs, BGP, PPPoE, PPPoA, IPSec Site To Site/Remote access,…

Bastien Migette — Sun, 13 Dec 2009 17:20:39 +0000

PE2(config)#ip route vrf VRF1 0.0.0.0 0.0.0.0 10.254.0.2 global

PE2(config)#router OSPF 1 vrf VRF1

PE2(config-router)#default-information originate

PE2(config-router)#exit

PE2(config)#

Comme vu sur le précédent billet, un bon gros lab ISCW, et même plus (partie FAI abordée pour PPPoX), je vous fournis une archive avec dynagen et les fichiers de configs de base (juste les IPs(sauf pour PPPoX, on y reviendra, et les hostnames, on va pas s’étaler dessus), pour attaquer la suite directement.

Topologie

Topologie format visio 2007: topo

Informations introductives

A noter que dans la topologie dynagen, j’utilise 4 hyperviseurs locaux pour tirer partie de mon quadcore, à vous de voir si vous voulez le modifier, mais en tous les cas il n’est pas gênant d’avoir plusieurs process dynamips même avec 1 ou deux coeurs (et sur le billet précédent, j’étais sur le laptop, donc dualcore ). pour lancer les hyperviseurs, j’utilise la commande (en root – sudo su)

dynamips -H 7200 & dynamips -H 7201 & dynamips -H 7202 & dynamips -H 7203

Note: pour importer les configs dans les routeurs, tapez, dans la console dynagen, import /all ./configs (il faut bien entendu que les fichiers de configs soient dans le dossier configs du fichier de topo). Le fichier .net est ici: topo.net Les configurations initiales ici: configs_initial.tar

Je fournirais les configs des différents équipements aux diverses étapes de l’article, les configurations finales étant disponible dans la conclusion.

Configuration du backbone MPLS

cette partie (ainsi que certaines des parties suivantes) ne change pas vraiment de ce que j’ai déjà abordé dans mon article sur les MPLS VPNs sauf qu’on mets du ISIS pour l’IGP (ça me permets de réviser pour BSCI ). Bon pour faire très simple (surtout que j’ai pas encore taffé à fond IS-IS, pas bien!, mais ça viendra…):

IS-IS = Intermediate System to Intermediate System (router to router quoi)
Séparation des networks en level (comparable aux aires OSPF), en gros, un routeur level 1 communique avec les routeur level 1, et un routeur level 2 avec un routeur level 2, et il y a des level 1 + 2 pour le routage entre aires. Les aires Level 1 sont destinées au routage interne, et les Level 2 au routage externe (à l’aire)
Les areas sont définies dans l’adresse NSAP, ce qui est l’adresse du protocole CLNS, qui est en fait le protocole de niveau 3 du modèle OSI (à ce propos, j’ai appris récément qu’en fait si OSI avait été implémenté, mais que TCP/IP l’ayant devancé et étant rapidement devenu populaire, OSI à été mis un peu de coté). Pour revenir à NSAP, c’est définit à un niveau global sur le routeur, pas interfaces par interfaces comme c’est le cas avec une adresse IP.
Voici la structure d’une adresse NSAP area.system_id.NSEL
-area, de 1 à 13 octets (il est courrant d’en utiliser 3), représente l’area. On l’écriras 49.XXXX (49 signifiant l’adressage privé).
-System ID, 6 octets: l’identifiant du système dans son aire, on utilise souvent la mac ou une IP de loopback précédée de 0. Ici, pour faire simple, je vais utiliser 0000.0000.00XX ou XX est l’ID définit dans le schéma).
-NSEL, 1 octet = NSAP Selector : Identifie le processus avec lequel on veux communiquer, pour le routage, c’est toujours 00.
Exemple de NSSAP pour LSR1: 49.0001.0000.0000.0010.00

la configuration se fait de la sorte:

router isis
net NSAP !replacer par le NSAP du router, net != network
!net = Network Entity Title = NSAP du router pour le routage (NSEL = 00)
is-type level-1|level-1-2 | level-2-only

puis

interface X/X
ip router isis

Voilà les configs sur les routeurs LSR1 et PEx : NE PAS OUBLIER DE ROUTER LES LOOPBACK, sans quoi LDP ne pourrait creer d’adjacence avec ses voisins (si il ne connait pas ses loopbacks)

LSR1:

LSR1(config)#router ISIS
LSR1(config-router)#net 49.0001.0000.0000.0010.00
LSR1(config-router)#is-type level-1
LSR1(config-router)#interface F0/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F0/1
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F1/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F1/1
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int loop0
LSR1(config-if)#ip router isis
LSR1(config-if)#exit

et pour les PE (on ne mets pas dans le routage le réseau qui sera dans la VRF, à noter que je l’ai fait sans faire gaffe, et que cela permets d’apprendre les routes des VRFs dans la table globale du routeur !!!!) Pour PE4, mettre le réseau qui relie vers BBR1, sans quoi, vu que son IP sera en nexthop pour les réseaux de l’AS 1001 appris via BGP, les routeurs de l’AS 1000 ne pourraient communiquer.

LSR1(config)#router ISIS
LSR1(config-router)#net 49.0001.0000.0000.00XX.00
LSR1(config-router)#is-type level-1
LSR1(config-router)#interface F0/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int loop0
LSR1(config-if)#ip router isis

Ce qui à la fin nous donne (SNPA = Adresse L2 OSI (MAC, DLCI, …), et show clns car clns transporte ISIS, mais ça on l’a déjà dit…):

LSR1#show clns neighbors 

System Id      Interface   SNPA                State  Holdtime  Type Protocol
PE3            Fa1/0       cc03.0bf4.0000      Up     8         L1   IS-IS
PE4            Fa1/1       cc04.0bf4.0000      Up     9         L1   IS-IS
PE2            Fa0/1       cc02.0be6.0000      Up     7         L1   IS-IS
PE1            Fa0/0       cc01.0be6.0000      Up     9         L1   IS-IS

Et (à ce moment j’avais oublié les loopbacks dans ISIS)

PE1#sh ip route
Codes: C - connected, S - static, 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
 i - IS-IS, su - IS-IS summary, 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 not set

 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C       10.1.0.11/32 is directly connected, Loopback0
i L1    10.0.2.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
i L1    10.0.3.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
C       10.0.0.0/30 is directly connected, FastEthernet0/0
i L1    10.0.1.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
i L1    10.254.0.0/30 [115/30] via 10.0.0.1, FastEthernet0/0
C       192.168.0.0 is directly connected, FastEthernet0/1

Et c’est tout ! la commande ip router isis sur les interfaces à permis d’indiquer que l’on voulait inclure les routes IP de l’interface en question dans ISIS. On aurait pu rajouter du redistribute xxx dans le mode router isis global, mais on s’écarte un peu du sujet. Une petite vérif pour la route et tout roule:

PE1#ping 10.0.0.2

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

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

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/76 ms
PE1#ping 10.0.3.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/32 ms
PE1#

Voilà, mon routage Interne dans le backbone MPLS est OKAY, mais, une petite minute, est-ce un backbone MPLS ? Bah non, on a pas encore mis le MPLS Je vous renvoi à mon article sur les MPLS VPNs pour le détail de la config MPLS, mais voici comment ça fonctionne: LSR1:

LSR1(config)#mpls ldp advertise-labels
LSR1(config)#mpls ldp router-id loop 0
LSR1(config)#int f0/0
LSR1(config-if)#mpls ip
LSR1(config-if)#int f0/1
LSR1(config-if)#mpls ip
LSR1(config-if)#int f1/0
LSR1(config-if)#mpls ip
LSR1(config-if)#int f1/1
LSR1(config-if)#mpls ip
LSR1(config-if)#exit

puis même chose sur les PE … Uniquement sur les F0/0 (reliées au LSR1), on va pas envoyer du MPLS sur le client.

LSR1#sh mpls ldp neighbor | i IP
 FastEthernet0/1, Src IP addr: 10.0.1.2
 FastEthernet1/0, Src IP addr: 10.0.2.2
 FastEthernet0/0, Src IP addr: 10.0.0.2
 FastEthernet1/1, Src IP addr: 10.0.3.2
LSR1#sh mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     10.254.0.0/30     0          Fa1/1      10.0.3.2
17     Pop tag     192.168.0.8/30    0          Fa1/0      10.0.2.2
18     Pop tag     192.168.0.0/30    0          Fa0/0      10.0.0.2
19     Pop tag     192.168.0.4/30    0          Fa0/1      10.0.1.2
20     Pop tag     10.1.0.12/32      0          Fa0/1      10.0.1.2
21     Pop tag     10.1.0.11/32      0          Fa0/0      10.0.0.2
22     Pop tag     10.1.0.13/32      0          Fa1/0      10.0.2.2
23     Pop tag     10.1.0.14/32      0          Fa1/1      10.0.3.2

Voilà tout est Ok, on fera un petit ping tout de même entre deux PE pour s’en assurer, mais le backbone est OK.

Création de la VRF et routage BGP

bon, vous vous rappelez des VRFs ? pour ceux qui n’ont pas lu mon article précédent, ça permets de faire une table de routage virtuelle pour un client, qui est donc indépendante de la table globale du routeur, et qui ce qui est génial c’est que l’on peux définir une route distinguisher pour identifier cette VRFs et transformer ses routes IPv4 en routes VPNv4 via l’utilisation de BGP en mode multi protocoles (MP-BGP) que l’ont peut transporter au sein du backbone et redistribuer ces routes dans la VRF d’un router distant, ce qui permets de faire un VPN en utilisant MPLS (chaque VRF est en fait double labélisée, et un label correspond à la VRF). Note: On peux faire des VRFs lite qui utilisent, au lieu des labels MPLS, un tag VLAN, l’avantage c’est qu’on peux le faire du des 3550 et pas besoin de MPLS. La VRF sera à créer sur les PE 1, 2 et 3, le PE 4 étant relié à un FAI (on avait pas vu le routage eBGP dans mon précédent article, on va corriger cela, et on va même mettre des route reflector ) Pour créer la VRF on utilisera ces commandes:

ip vrf VRF1
rd 1000:1
route-target both 1000:1
interface F0/1
ip vrf forwarding VRF1 ! et la ça fait sauter l'IP
ip address 192.168.0.X 255.255.255.252
exit

Ensuite, on active BGP. Ici, on vas utiliser la fonction de route reflector, en gros, au lieux que tous les routeurs soient voisins iBGP entre eux, ils seront voisins avec PE4 (qui fera aussi de l’eBGP), qui centralisera les routes et les « réfléchira », ce qui veux dire les renverra à ses autres voisins. On notera que LSR1 n’utilisera pas BGP (il faut simplement transiter le trafic au sein de l’AS). pour activer BGP (avec le support des VRFs, soient des adresses VPNv4), dans un premier temps au sein de l’AS (on verra eBGP après): Sur PE 1,2,3:

router bgp 1000
neighbor 10.1.0.14 remote-as 1000
neighbor 10.1.0.14 update-source loop0
address-family vpnv4
neighbor 10.1.0.14 activate
neighbor 10.1.0.14 send-community both

sur PE4

router bgp 1000
neighbor 10.1.0.11 remote-as 1000
neighbor 10.1.0.11 update-source loop0
neighbor 10.1.0.11 route-reflector-client
address-family vpnv4
neighbor 10.1.0.11 activate
neighbor 10.1.0.11 send-community both
neighbor 10.1.0.11 route-reflector-client
exit
neighbor 10.1.0.12 remote-as 1000
neighbor 10.1.0.12 update-source loop0
neighbor 10.1.0.12 route-reflector-client
address-family vpnv4
neighbor 10.1.0.12 activate
neighbor 10.1.0.12 send-community both
neighbor 10.1.0.12 route-reflector-client
exit
neighbor 10.1.0.13 remote-as 1000
neighbor 10.1.0.13 update-source loop0
neighbor 10.1.0.13 route-reflector-client
address-family vpnv4
neighbor 10.1.0.13 activate
neighbor 10.1.0.13 send-community both
neighbor 10.1.0.13 route-reflector-client
exit

Il faut maintenant activer ospf sur les PE 1,2 et 3 pour la VRF VRF1. Ceci se fait de la sorte:

PE1(config)#router ospf 1 vrf VRF1
PE1(config-router)#network 192.168.0.0 0.0.0.255 area 0 ! j'ai mis le subnet /24 pour pouvoir faire copier/coller entre PE

et sur les routeurs RMO1, 2, ainsi que sur RTRDT, config classique:

RMO2(config)#router ospf 1
RMO2(config-router)#network 192.168.0.0 0.0.0.255 area 0 !idem pour les masques
RMO2(config-router)#network 10.0.0.0 0.255.255.255 area 0 !idem pour les masques
RMO2(config-router)#exit

petite vérif pour la route:

PE2#sh ip route vrf VRF1

Routing Table: VRF1
Codes: C - connected, S - static, 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
 i - IS-IS, su - IS-IS summary, 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 not set

 10.0.0.0/32 is subnetted, 1 subnets
O       10.1.0.1 [110/2] via 192.168.0.6, 00:04:32, FastEthernet0/1
 192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.4 is directly connected, FastEthernet0/1

Et maintenant on redistribue OSPF dans BGP, et BGP dans ospf Config sur les PE 1,2 et 3:

PE2(config)#router ospf 1 vrf VRF1
PE2(config-router)#redistribute BGP 1000 subnets
PE2(config-router)#exit
PE2(config)#router bgp 1000
PE2(config-router)#address-family ipv4 vrf VRF1
PE2(config-router-af)#redistribute ospf 1
PE2(config-router-af)#exit
PE2(config-router)#exit

vérifications:

PE4#sh bgp vpnv4 unicast all
BGP table version is 6, local router ID is 10.1.0.14
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

 Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1000:1
*>i10.1.0.1/32      10.1.0.12                2    100      0 ?
*>i10.2.0.1/32      10.1.0.13                2    100      0 ?
*>i192.168.0.0/30   10.1.0.11                0    100      0 ?
*>i192.168.0.4/30   10.1.0.12                0    100      0 ?
*>i192.168.0.8/30   10.1.0.13                0    100      0 ?
PE4#
PE2#sh ip route vrf VRF1

Routing Table: VRF1
Codes: C - connected, S - static, 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
 i - IS-IS, su - IS-IS summary, 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 not set

 10.0.0.0/32 is subnetted, 2 subnets
B       10.2.0.1 [200/2] via 10.1.0.13, 00:01:45
O       10.1.0.1 [110/2] via 192.168.0.6, 00:03:11, FastEthernet0/1
 192.168.0.0/30 is subnetted, 3 subnets
B       192.168.0.8 [200/0] via 10.1.0.13, 00:01:45
B       192.168.0.0 [200/0] via 10.1.0.11, 00:01:45
C       192.168.0.4 is directly connected, FastEthernet0/1
RMO1#ping 10.2.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/68 ms

Voilà le le backbone MPLS et le VPN MPLS sont OK, on va attaquer la partie eBGP et la redistribution de route statique pour l’accès internet dans une VRF une petite archive avec les configs jusqu’a présent: configs_backbone.tar

Routage internet eBGP

Tout d’abord, en regardant la topologie, on voit que le routeur du datacenter a déjà une connexion internet, le FAI fournissant le service de VPN MPLS ne s’occupera pas d’internet pour ce routeur. Pour les autres (RMO1 et RMO2), le FAI va fournir internet, internet étant ici représenté comme l’AS 1001, bref, ce qui est important c’est de voir les options dont l’ont dispose pour amener une connectivité internet dans une VRF:

Copier la table de routage internet globale dans une VRF : Idiot, qui va s’ammuser à recopier plusieurs fois les quelques 150 000 Routes internet dans ses VRFs ?
Avoir deux interfaces vers le FAI : Une dans une VRF, une dans la table de routage : Implique d’avoir 2 liens (possibilité d’utiliser des liens virtuels), et que le FAI à dans sa table de routage globale les routes vers internet, ce qui n’est pas toujours souhaité pour des raisons de sécurités
Route statique vers la table globale: cela implique aussi que le FAI à mis sa table de routage internet dans sa table de routage globale. Cela est possible via la commande ip route vrf {vrf} {net} {mask} global (voir ici: Internet Access from an MPLS VPN Using a Global Routing Table
Utiliser la connexion internet du datacenter : On aurait pu, mais si elle tombe, plus personne n’a le net…
chaque site distant à une connexion internet séparée : pourquoi pas…
Utiliser une VRF dédiée pour internet, et redistribuer ses routes dans la VRF du client: Bonne pratique d’un point de vue sécurité, car le routage internet est séparé du routage interne du FAI, cependant, si la VRF internet contient toutes les routes internet, cela peut poser des problèmes… Cependant, la table de routage internet peux inclure une route par défaut, et l’on peut filtrer les routes redistribuée d’une VRF à une autre. Par contre, il faut prendre en compte que les routes d’une VRFs utilisent beaucoup plus de mémoire qu’une route dans la table globale… A noter aussi dans ce cas le routeur du FAI est vu comme le routeur d’un client (customer edge), mais qu’il est possible d’établir un peering BGP avec un router dans une VRF.
… il y a pas mal d’autres scénarios possibles, viennent ensuite les problématique du NAT, qui le fait ? Le client ? dans ce cas il faut une IP publique par site client… Le FAI ? dans ce cas il doit gérer les translations de port du client etc, cela peut être un peut lourd…

un peu de lecture:

http://fengnet.com/book/MPLS%20VPN%20Security/ch04lev1sec1.html

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_white_paper09186a00801281f1.shtml

Vous l’aurez compris, tout cela sont des notions de design MPLS, et il y a des bouquins de plusieurs centaines de pages la dessus, et bien que cela soit très intéressant, nous allons ici faire, dans la mesure du possible, ce qui est le plus simple. Ce que l’on va donc faire ici, c’est nater au niveau du client, en utilisant une route statique vers la table globale au niveau du PE. Cela est un peu subtile, car il faut redistribuer les routes des PE via BGP (sur PE4, qui va faire un peering avec le router de l’AS 1001), puis faire des routes statiques que l’on va inclure dans l’IGP qui auront 2 fonctions: Permettre aux routeurs du backbone comment joindre ces IPs, car ils ne sont pas dans la bonne VRF vous noterez qu’il faut spécifier manuellement l’interface et le next-hop pour forcer à passer dans une VRF. Je vais affecter des IP publiques. Sur PE1, cela donnerai ceci (192.0.0.2 serait l’IP publique affectée au routeur, on pourrais aussi faire la même chose avec ses IPs privées, mais on ne va pas envoyer d’ip privées via BGP à un autre FAI…):

ip route 192.0.0.2 255.255.255.255 F0/1 192.168.0.2
router ISIS
redistribute static ip level-1

Le principe est de router ces IPs publiques dans le backbone via ISIS et de les réinjecter dans BGP via la redistribution depuis ISIS avec une route map. Première étape, configuration eBGP: même chose qu’iBGP, mais avec un remote-as différent (par contre on échangeras pas de routes vpnv4) sur PE4 (on fait une route map pour ne réinjecter que les IPs publiques, pas les IPs du subnet backbone):

PE4(config)#ip access-list sta PUBIPs
PE4(config-std-nacl)#permit host 192.0.0.2
PE4(config-std-nacl)#permit host 192.0.0.6
PE4(config-std-nacl)#permit host 192.0.0.10
PE4(config-std-nacl)#exit
PE4(config)#route-map RMPUBIPs permit 10
PE4(config-route-map)#match ip address PUBIPs
PE4(config-route-map)#set metric 100
PE4(config-route-map)#exit
PE4(config)#router bgp 1000
PE4(config-router)#neighbor 10.254.0.2 remote-as 1001
PE4(config-router)#redistribute isis level-1 route-map RMPUBIPs

et sur BBR (ici juste un redistribute connected)

BBR1(config)#router bgp 1001
BBR1(config-router)#neighbor 10.254.0.1 remote-as 1000
BBR1(config-router)#redistribute connected metric 100

vérifications

PE1#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/30, 3 known subnets

B       100.0.0.4 [200/100] via 10.254.0.2, 00:06:20
B       100.0.0.0 [200/100] via 10.254.0.2, 00:06:20
B       100.0.0.12 [200/100] via 10.254.0.2, 00:06:20
BBR1#sh ip route 192.0.0.0
Routing entry for 192.0.0.0/32, 3 known subnets

B       192.0.0.2 [20/100] via 10.254.0.1, 00:07:46
B       192.0.0.6 [20/100] via 10.254.0.1, 00:07:47
B       192.0.0.10 [20/100] via 10.254.0.1, 00:07:47
BBR1#deb ip icmp
PE1#ping ip 100.0.0.1
ICMP packet debugging is on
BBR1#
*Dec 17 00:01:24.083: ICMP: echo reply sent, src 100.0.0.1, dst 10.0.0.2

sur l’exemple de ping au dessus, la réponse ne pourra arriver à PE1, car celui-ci utilise son IP privée que l’on a délibérément pas routée dans BGP Maintenant, on va créer une route statique par défaut dans la vrf VRF1 que l’on va faire pointer sur la passerelle internet (on va utiliser l’IP de BBR1), en indiquant que cette passerelle se trouve dans la table globale. Cela ce fait via l’utilisation du mot clé « global » dans la commande ip route. Ensuite, on va redistribuer cette route par défaut via OSPF. Note: On ne va faire cette manip que sur PE 2 et 3, car le router RTRDT dispose d’une connexion internet externe.

PE2(config)#ip route vrf VRF1 0.0.0.0 0.0.0.0 10.254.0.2 global
PE2(config)#router OSPF 1 vrf VRF1
PE2(config-router)#default-information originate
PE2(config-router)#exit
PE2(config)#

petite vérification:

RMO1#sh ip route
Codes: C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, 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 192.168.0.5 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA    10.2.0.1/32 [110/3] via 192.168.0.5, 00:02:42, FastEthernet0/0
C       10.1.0.0/16 is directly connected, Loopback0
O IA    10.0.0.1/32 [110/3] via 192.168.0.5, 00:02:42, FastEthernet0/0
     192.168.0.0/30 is subnetted, 3 subnets
O IA    192.168.0.8 [110/2] via 192.168.0.5, 00:02:42, FastEthernet0/0
O IA    192.168.0.0 [110/2] via 192.168.0.5, 00:02:42, FastEthernet0/0
C       192.168.0.4 is directly connected, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 192.168.0.5, 00:01:40, FastEthernet0/0
Dummy1#deb ip icmp
ICMP packet debugging is on
RMO1#ping 100.0.0.14

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Dummy1#
*Mar  1 00:06:07.207: ICMP: echo reply sent, src 100.0.0.14, dst 192.168.0.6

Evidemment le ping est reçu mais la réponse ne peut aboutir, puisque au niveau de RMO1 on a pas fait le NAT, donc le routeur distant voit son IP privée.

On va donc mettre le NAT en place. Ici, il y a une petite subtilité, car il faut bien sur pas nater ce qui est à destination des IP privées, ni le traffic OSPF, j’ai donc utilisé une route map.

Avant toute chose, ne pas oublié de faire une route sur DUMMY1 (on pourrait mettre de l’OSPF entre BBR1 et DUMMY1 et redistribuer BGP dans OSPF, mais on l’a déjà fait au dessus, on va faire au plus simple donc)

Dummy1(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.13

Et au niveau du nat, voici ce que j’ai fait:

Le but est de ne pas natter le trafic OSPF ni le trafic à destination des sites des VPN MPLS, et j’ai testé avec des deny sur une access-list, et ip nat inside source list, mais ça ne marche pas (ou j’ai loupé quelque chose)
j’ai donc défini 2 ACLs, une qui correspond au trafic à natter, l’autre à exclure (les noms sont explicites je penses), petite subtilité pour ceux qui n’ont pas l’habitude de matcher via des ACLs, l’ACL NONAT, bien que son but est d’empêcher du trafic d’être natter, va faire des permit sur le trafic à exclure, cela va permettre d’identifier ce trafic, et la route-map va l’interdire.
défini une route map avec 2 entrée qui font un match sur les ACL précédemment définie pour indiquer ce qui doit être natter ou non
appliquer la route map dans la commande IP NAT SOURCE
ne pas oublier les ip nat inside/outside

RMO2(config)#ip access-list extended NONAT
RMO2(config-ext-nacl)#permit ospf ANY ANY
RMO2(config-ext-nacl)#permit ip any 10.0.0.0 0.255.255.255
RMO2(config-ext-nacl)#permit ip any 192.168.0.0 0.0.255.255
RMO2(config-ext-nacl)#exit
RMO2(config)#ip access-list standard NAT
RMO2(config-std-nacl)#permit 10.0.0.0 0.255.255.255
RMO2(config-std-nacl)#exit
RMO2(config)#route-map NATMAP deny 10
RMO2(config-route-map)#match ip address NONAT
RMO2(config-route-map)#route-map NATMAP permit 20
RMO2(config-route-map)#match ip address NAT
RMO2(config-route-map)#exit
RMO2(config)#ip nat pool MyIP 192.0.0.10 192.0.0.10 netmask 255.255.255.252
RMO2(config)#ip nat inside source route-map NATMAP pool MyIP overload

On fait la même config sur RMO1 (en changeant les IPs)

Vérifications

RMO1#ping 100.0.0.14 source loop0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/272/304 ms
Dummy1#
*Mar  1 00:09:03.859: ICMP: echo reply sent, src 100.0.0.14, dst 192.0.0.6
RMO1#ping 10.2.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/192/256 ms

Et voilà nos routeurs ont un VPN MPLS ET un accès internet, c’est pas beau ça ?

Voici les configs jusqu’ici : configs_NAT.tar

Sur RTRDT, une simple route statique suffit pour internet. A noter qu’on aurait pu redistribuer cette route statique dans OSPF avec une métrique forte pour qu’au cas où la connexion internet des sites distants tombe, ces derniers pourraient utiliser celle du datacenter, mais tout de manière dans notre cas ici, vu que le net et le vpn passe par le même FAI, si le net est HS, le VPN le sera aussi probablement.

Note: Je ne vais pas mettre de NAT sur le routeur du datacenter vu qu’il n’est pas censé y avoir d’utilisateurs.

RTRDT(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.1
RTRDT#ping 100.0.0.14

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
!!!!!

Configuration PPPoE + Site To Site VPN

Pour la partie PPPoE, je me suis inspiré de l’article http://packetlife.net/blog/2009/apr/20/configuring-pppoe/ (très bon blog au passage, en anglais) Pour la partie FAI (ce n’est pas au programme ISCW mais bon toujours utile de savoir comment ça marche non ?), il faut, en gros, créer un group « broad band access aggregation », auquel on rattache une interface virtual-template qui va contenir les paramètres PPP (pool d’adresse notement), puis activer ce group BBA sur l’interface qui reçoit les connexions PPPoE. Il est possible de configurer pas mal de chose dans le groupe BBA, comme le nombre de sessions par adresses mac …

BBR1(config)#bba-group pppoe clients_pppoe
BBR1(config-bba-group)#virtual-template 1
BBR1(config-bba-group)#sessions per-mac limit 2
BBR1(config-bba-group)#exit
BBR1(config)#interface virtual-template 1
BBR1(config-if)#ip add 100.0.1.1 255.255.255.0
BBR1(config-if)#peer default ip address pool pool_pppoe
BBR1(config-if)#exit
BBR1(config)#ip local pool pool_pppoe 100.0.1.2 100.0.1.100
BBR1(config)#int F0/1
BBR1(config-if)#pppoe enable group clients_pppoe
BBR1(config-if)#no ip address
BBR1(config-if)#exit

Sur le client, il faut créer une interface Dialer qui contient les paramètres PPP et associer un dialer pool à cette interface dialer, que l’on va appliquer sur l’interface physique.

RBO1(config)#interface dialer1
RBO1(config-if)#dialer pool 1
RBO1(config-if)#encapsulation ppp
RBO1(config-if)#ip address negotiated !negociée via IPCP
RBO1(config-if)#mtu 1492 !1500 - 8 header ppp
RBO1(config-if)#int f0/0
RBO1(config-if)#no ip address
RBO1(config-if)#pppoe enable
RBO1(config-if)#pppoe-client dial-pool-number 1
RBO1(config-if)#exit
RBO1(config)#

vérifications:

RBO1#sh ip route | i 100
     100.0.0.0/32 is subnetted, 2 subnets
C       100.0.1.1 is directly connected, Dialer1
C       100.0.1.3 is directly connected, Dialer1
RBO1#sh ip int br dialer 1
Interface                  IP-Address      OK? Method Status                Protocol
Dialer1                    100.0.1.3       YES IPCP   up                    up
RBO1#ping 100.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/84/160 ms

BBR1#sh pppoe session
     1 session  in LOCALLY_TERMINATED (PTA) State
     1 session  total

Uniq ID  PPPoE  RemMAC          Port                    VT  VA         State
           SID  LocMAC                                      VA-st
      2      2  cc09.0ba0.0000  Fa0/1                    1  Vi1.1      PTA
                ca0b.0ba1.0006                              UP
BBR1#sh ip route | i 100.0.1
C       100.0.1.0/24 is directly connected, Virtual-Access1.1
C       100.0.1.6/32 is directly connected, Virtual-Access1.1

Voilà pour du PPPoE simple, mais on va rajouter un peut d’authentification, sinon c’est pas marrant… Sur le routeur FAI:

BBR1(config)#int virtual-template 1
BBR1(config-if)#ppp authentication chap
BBR1(config)#username pppoeuser password p4$$w0rd

et sur le client (noter le callin qui indique que l’on ne va pas authentifier le pair distant sur le client, en général les FAI utilisent l’authentification unidirectionnelle, le client s’authentifie, mais le FAI ne s’authentifie pas sur le client. Pour être pointilleux, le paramètre callin indique que l’on vas authentifier le pair distant que s’il initie la session, et vu qu’en l’occurence cela n’arrivera pas, quand le client initie la session il n’essaie pas d’authentifier le FAI)

RBO1(config)#int dialer1
RBO1(config-if)#ppp chap hostname pppoeuser
RBO1(config-if)#ppp chap password p4$$w0rd
RBO1(config-if)#ppp authentication chap callin

et on relance la machine

BBR1#clear pppoe all
!attendre que l'interface du client redevienne "up"
BBR1#sh user | b Interface
  Interface    User               Mode         Idle     Peer Address
  Vi1.1        pppoeuser          PPPoE        -        100.0.1.6 !l'ip a changée

Voilà, un petit coup de NAT (on utilisera pas le NAT) et route par défaut sur le routeur RBO1, et on attaque le Site-to-site, et pour le FUN, je vais mettre une crypto map sur le RBO et une interface VTI sur le router RTRDT, et le tout en GREoIPSEC

RBO1(config)#int loop 0
RBO1(config-if)#ip nat inside
RBO1(config-if)#int dialer 1
RBO1(config-if)#ip nat outside
RBO1(config-if)#exit
RBO1(config)#ip access-list standard NAT
RBO1(config-std-nacl)#permit 10.2.0.0 0.0.255.255
RBO1(config-std-nacl)#exit
RBO1(config)#ip nat inside source list NAT interface dialer1 overload
RBO1(config)#ip route 0.0.0.0 0.0.0.0 100.0.1.1
RBO1#ping 100.0.0.2 !on ping le datacenter sinon pas la peine de faire du VPN :p

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/94/124 ms

Donc pour le site to site, ici on va considérer que l’IP du routeur RBO1 est statique, sinon il aurait fallu faire de l’easy-vpn, ce qui aurait été possible, mais je n’avais pas envie. Pour le site-to-site je vais vous passer les détails de la conf, je penses qu’il y a assez d’exemples sur mon blog. Coté client:

RBO1(config)#int tunnel0 !creation tunnel
RBO1(config-if)#tunnel source dialer1 !prends l'ip de Dialer1 en source
RBO1(config-if)#tunnel destination 100.0.0.2
RBO1(config-if)#tunnel mode gre ip
RBO1(config-if)#ip add 10.10.0.2 255.255.255.0 !'lip du tunnel
RBO1(config)#crypto isakmp policy 10 !isakmp policy
RBO1(config-isakmp)#auth pre
RBO1(config-isakmp)#hash sha
RBO1(config-isakmp)#group 5
RBO1(config-isakmp)#encr aes
RBO1(config)#crypto isakmp key ipsecp4$$ address 100.0.0.2 !password isakmp
RBO1(config)#ip access-list extended CRYPTOACL
RBO1(config-ext-nacl)#permit gre host 100.0.1.6 host 100.0.0.2
RBO1(config-ext-nacl)#remark Voir note
RBO1(config-ext-nacl)#exit
RBO1(config)#crypto ipsec transform-set TSET esp-aes esp-sha-hmac
RBO1(cfg-crypto-trans)#mode transport !transport car tunneling par GRE
RBO1(cfg-crypto-trans)#exit
RBO1(config)#crypto map TUNNELDT 10 ipsec-isakmp !la crypto map
% NOTE: This new crypto map will remain disabled until a peer
	and a valid access list have been configured.
RBO1(config-crypto-map)#set peer 100.0.0.2
RBO1(config-crypto-map)#match address CRYPTOACL
RBO1(config-crypto-map)#set transform-set TSET
RBO1(config-crypto-map)#exit
RBO1(config)#interface dialer1
RBO1(config-if)#crypto map TUNNELDT
RBO1(config-if)#exit
RBO1(config)#

Note: Bien mettre les IP des hosts sur la crypto ACL, sans quoi vous aurez cette erreur:

*Mar  1 01:39:26.391: ISAKMP:(0:1:SW:1): IPSec policy invalidated proposal
*Mar  1 01:39:26.395: ISAKMP:(0:1:SW:1): phase 2 SA policy not acceptable! (local 100.0.0.2 remote 100.0.1.6)

Pour le coup j’avais mis permit gre any any.

Coté datacenter:

RTRDT(config)#crypto isakmp policy 10
RTRDT(config-isakmp)#auth pre
RTRDT(config-isakmp)#hash sha
RTRDT(config-isakmp)#group 5
RTRDT(config-isakmp)#encr aes
RTRDT(config)#crypto isakmp key ipsecp4$$ address 100.0.1.6
RTRDT(config)#crypto ipsec transform-set TSET esp-aes esp-sha-hmac
RTRDT(cfg-crypto-trans)#mode transport
RTRDT(cfg-crypto-trans)#exit
RTRDT(config)#crypto ipsec profile RBO1
RTRDT(ipsec-profile)#set transform-set TSET
RTRDT(ipsec-profile)#exit
RTRDT(config)#int tunnel0
RTRDT(config-if)#tunnel mode gre ip
RTRDT(config-if)#tunnel source F0/1
RTRDT(config-if)#tunnel dest 100.0.1.6
RTRDT(config-if)#ip address 10.10.0.1 255.255.255.0
RTRDT(config-if)#tunnel protection ipsec profile RBO1
RTRDT(config-if)#exit

Vérifs et Routage OSPF

RBO1#ping 10.10.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/106/164 ms
RBO1#sh crypto isakmp sa
dst             src             state          conn-id slot status
100.0.0.2       100.0.1.6       QM_IDLE              1    0 ACTIVE
RBO1#sh crypto session
Crypto session current status

Interface: Dialer1
Session status: UP-ACTIVE
Peer: 100.0.0.2 port 500
  IKE SA: local 100.0.1.6/500 remote 100.0.0.2/500 Active 
  IPSEC FLOW: permit 47 host 100.0.1.6 host 100.0.0.2
        Active SAs: 2, origin: crypto map
  IPSEC FLOW: permit 47 host 100.0.1.6 host 100.0.0.2
        Active SAs: 2, origin: crypto map

Je rappelle que QM_IDLE signifie que la phase 1 IKE est terminée, donc plus de négociation, du coup la SA de la phase 1 est « IDLE » et « ACTIVE » Pour OSPF, il est déjà configuré sur RTRDT, on va donc configurer sur RBO1

RBO1(config)#router ospf 1
RBO1(config-router)#network 10.3.0.0 0.0.255.255 area 0
RBO1(config-router)#network 10.10.0.0 0.0.255.255 area 0
RBO1(config-router)#exit

et la ça marche pas. J’aurai pu faire la modif discretos pour mla jouer roxor, mais c’est un point il me semble important. Je n’ai pas pour habitude dans mes exemples de modifier le MTU sur les tunnels IPSEC, car je fait essentiellement du PING donc pas besoin, mais du coup ce sont autant de bons reflexes qu’on ne prend pas. Dans le cas présent, voici les erreurs que j’ai eues:

*Mar  1 02:05:14.023: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
RBO1#
*Mar  1 02:05:17.851: OSPF: Rcv hello from 10.0.0.1 area 0 from Tunnel0 10.10.0.1
*Mar  1 02:05:17.851: OSPF:
OSPF: Nbr 10.0.0.1 10.10.0.1 Tunnel0 is currently ignored
*Mar  1 02:06:14.187: OSPF: Rcv DBD from 10.0.0.1 on Tunnel0 seq 0x1014 opt 0x52 flag 0x7 len 32  mtu 1476 state EXSTART
*Mar  1 02:06:14.191: OSPF: Nbr 10.0.0.1 has larger interface MTU

Donc en gros les mises à jour OSPF ne passaient pas dans le tunnel, et le voisin finissait par banir temporairement le neighbor.

Un petit ip mtu 1460 sur les interfaces tunnels des deux cotés et tout roulait.

Je vous mets en prime 2 petits liens sur le MTU et la commande tcp adjust-mss (importante pour s’assurer que les hosts n’outrepassent pas la limite MTU du routeu, en gros, il fait proxy et modifie le MSS lors des négocations TCP, donc si le MSS baisse, le MTU aussi, logique):

http://www.iphelp.ru/doc/3/Cisco.Press.Comparing.Designing.and.Deploying.VPNs.Apr.2006/1587051796/ch07lev1sec4.html

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

petite vérif:

RBO1#un all
All possible debugging has been turned off
RBO1#sh ip route
Codes: C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, 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 100.0.1.1 to network 0.0.0.0

     100.0.0.0/32 is subnetted, 2 subnets
C       100.0.1.6 is directly connected, Dialer1
C       100.0.1.1 is directly connected, Dialer1
     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.10.0.0/24 is directly connected, Tunnel0
C       10.3.0.0/24 is directly connected, Loopback0
O IA    10.2.0.1/32 [110/11114] via 10.10.0.1, 00:09:10, Tunnel0
O IA    10.1.0.1/32 [110/11114] via 10.10.0.1, 00:09:10, Tunnel0
O       10.0.0.1/32 [110/11112] via 10.10.0.1, 00:09:10, Tunnel0
     192.168.0.0/30 is subnetted, 3 subnets
O IA    192.168.0.8 [110/11113] via 10.10.0.1, 00:09:10, Tunnel0
O       192.168.0.0 [110/11112] via 10.10.0.1, 00:09:10, Tunnel0
O IA    192.168.0.4 [110/11113] via 10.10.0.1, 00:09:10, Tunnel0
S*   0.0.0.0/0 [1/0] via 100.0.1.1
RBO1#ping 10.1.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/313/404 ms

Voilà, j’ai ma table de routage, je peux pinger un autre site via mon VPN, tout est OK. Je vous mets les configs, et je vais reposer un peu mon pauvre PC portable qui commence à chauffer à être à 100% de CPU pendant des heures :p

Configs: configs_pppoe.tar

Configuration PPPoA + Remote VPN

Aller, on arrive à la fin !

Au niveau de PPPoA, la conf est quasi identique coté FAI et client (on aurait pu utilisé la même interface virtual template pour les deux d’ailleurs). Juste quelques notions d’ATM, en gros, les VPI (virtual path identifier) identifient un chemin, et les VCI (Virtual Circuit Identifier) identifient un Circuit au sein d’un VPI. Les switchs ATM commutent un couple VPI/VCI vers un autre VPI/VCI. Puisqu’on va l’utiliser, très rapidement, l’encapsulation AAL5 (ATM Adaptation Layer), ajoute des infos à la trame (longueur et CRC), puis du padding pour obtenir un multiple de 48 (rappelez vous qu’ATM utilise des cellules de 53 octets, 5 pour l’entête et 48 pour les données). Cela permets donc, lorsque la trame est reconsituée, de vérifier son intégrité.

Bref, attaquons la config coté FAI:

BBR1(config)#interface virtual-template 2 !la 1 est pour pppoe
BBR1(config-if)#ip address 100.0.2.1 255.255.255.0
BBR1(config-if)#peer default ip address pool pool_pppoa !le pool d'ip clients
BBR1(config-if)#ppp authentication chap
BBR1(config-if)#exit
BBR1(config)#ip local pool pool_pppoa 100.0.2.2 100.0.2.254
BBR1(config)#interface atm2/0
BBR1(config-if)#no sh
BBR1(config-if)#pvc 10/100 !pvc choisi arbitrairement, voir switch atm topo.net
BBR1(config-if-atm-vc)#encapsulation aal5snap
BBR1(config-if-atm-vc)#protocol ppp virtual-Template 2 !on associe la template pour ppp
BBR1(config-if-atm-vc)#exit
BBR1(config-if)#exit
BBR1(config)#username pppoauser password p4$$w0rd !création d'un autre utilisateur, pour la forme

Au niveau du client:

!RTL1
interface ATM1/0
 no ip address
 no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
 no snmp trap link-status
 pvc 20/200
  encapsulation aal5snap
  protocol ppp dialer
  dialer pool-member 1
 !
!         
interface Dialer1
 ip address negotiated
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap
 ppp chap hostname pppoauser
 ppp chap password 0 p4$$w0rd
!

Par contre la configuration ci dessus, malgré qu’elle me semble bonne, ne fonctionne pas, et après plusieurs tests, je n’ai pas réeussi à faire fonctionner pppoa sur dynamips, peux être un problème de version d’IOS, je me renseigne sur ça, et sinon tanpis pour la partie pppoa…

Pour continuer l’article, je vais utiliser ces configs :

!RTL1
interface ATM1/0
 ip address 100.0.2.2 255.255.255.0
 pvc 20/200
  encapsulation aal5snap
!
!BBR1
interface ATM2/0
 ip address 100.0.2.1 255.255.255.0
 pvc 10/100
  encapsulation aal5snap
!

Un petit mot rapidement, j’ai mis la configuration du PVC directement sur l’interface ATM, vous verrez souvent que la config des PVC est appliquée sur une sous interface ATM, cela permets d’avoir plusieurs IP et plusieurs circuits, moi je n’ai qu’une IP et qu’un circuit, donc pas besoin de sous interfaces. A noter aussi que l’on doit obligatoirement spécifier les VPI/VCI pour que cela fonctionne.

Au niveau de la config du routeur RTL1, il manque le default-router dans le pool DHCP (un petit oubli). Pensez à le rajouter:

!
ip dhcp pool private_lan
  default-router 192.168.0.254
!

Ne pas oublier le nat et la route par défaut non plus:

RTL1(config-if)#int atm1/0
RTL1(config-if)#ip nat outside
RTL1(config-if)#int f0/0
RTL1(config-if)#ip nat inside
RTL1(config-if)#exit
RTL1(config)#access-list 1 permit 192.168.0.0 0.0.0.255
RTL1(config)#ip nat inside source list 1 int atm1/0 overload

Aller, on passe au Remote VPN. Pour ce faire, on vas utiliser des interfaces Virtual Template et des profiles ISAKMP/IPSEC, d’une part parce que la gestion des clients en est facilitée, et d’autre part, il semble qu’il ne soit pas possible d’avoir une même crypto map pour du remote VPN et du site to site (même si on peut avoir plusieurs entrées via les séquences pour une même crypto map), et vu qu’on ne peux avoir qu’une crypto map par interface, on aurait pas pu avoir les 2 sur BBR1, mais je n’ai pas testé cela.

Première chose, ne pas oublier la liste AAA avec les profiles VPN (c’était l’objet du dernier contest).

Donc dans l’ordre, au niveau du routeur qui va recevoir les connexions VPN

Configurer la liste pour l’authorization isakmp (password group, pool,…)
Configurer la liste pour l’authentication (optionnel, mais on va mettre du XAUTH, penser à créer un user local)
Créer le groupe VPN (on choisira le nom remote_users, on crééra ausis le pool pool_remote_vpn), et un utilisateur
Créer l’ACL pour le split tunneling (on veux que le VPN serve uniquement pour accéder au réseau 10.0.0.0/8 – réseau de l’entreprise).
Créer transform set et profile IPSEC
Créer profile ISAKMP pour le groupe VPN
Créer une policy ISAKMP en accord avec celle disponible sur le client VPN (on avait pas créé de policy pour le site to site, les paramètres par défaut entre les routeurs étant compatibles).
Créer une interface tunnel et y appliquer le profile IPSEC

!aaa
RTRDT(config)#aaa new-model
RTRDT(config)#aaa authorization network remote_vpn local
RTRDT(config)#aaa authentication login remote_vpn local
!IPSEC transform set et profile
RTRDT(config)#crypto ipsec transform-set rvpn_tset esp-aes esp-sha-hmac
RTRDT(cfg-crypto-trans)#exit
RTRDT(config)#crypto ipsec profile rvpn_ipsec_profile
RTRDT(ipsec-profile)#set transform-set rvpn_tset
RTRDT(ipsec-profile)#set isakmp-profile rvpn_profile ! optionnel
!group VPN
RTRDT(config)#crypto isakmp client configuration group remote_users
RTRDT(config-isakmp-group)#key vpnp4$$
RTRDT(config-isakmp-group)#pool remote_vpn_pool
RTRDT(config-isakmp-group)#domain corp.lan
RTRDT(config-isakmp-group)#acl splitacl
RTRDT(config-isakmp-group)#netmask 255.255.255.0 !masque associé au pool
RTRDT(config-isakmp-group)#exit
!ACL
RTRDT(config)#ip access-list extended splitacl !utiliser ACL étendue, standard ne marche pas
RTRDT(config-std-nacl)#permit ip 10.0.0.0 0.255.255.255 any
RTRDT(config-std-nacl)#exit
!user
RTRDT(config)#username remote_user password cisco
!pool
RTRDT(config)#ip local pool remote_vpn_pool 10.11.0.1 10.11.0.254
!Profile ISAKMP
RTRDT(config)#crypto isakmp profile rvpn_profile
% A profile is deemed incomplete until it has match identity statements
RTRDT(conf-isa-prof)#match identity group remote_users
RTRDT(conf-isa-prof)#client configuration address respond
RTRDT(conf-isa-prof)#virtual-template 1
RTRDT(conf-isa-prof)#client authentication list remote_vpn
RTRDT(conf-isa-prof)#isakmp authorization list remote_vpn
RTRDT(conf-isa-prof)#exit
!policy isakmp, correspond à une policy du client VPN
RTRDT(config)#crypto isakmp policy 1
RTRDT(config-isakmp)#auth pre-share
RTRDT(config-isakmp)#hash sha
RTRDT(config-isakmp)#encr aes
RTRDT(config-isakmp)#group 2
RTRDT(config-isakmp)#exit
!création du template de tunnel
RTRDT(config)#interface virtual-template 1 type tunnel
RTRDT(config-if)#tunnel mode ipsec ipv4
RTRDT(config-if)#tunnel protection ipsec profile  rvpn_ipsec_profile
RTRDT(config-if)#ip mtu 1460
RTRDT(config-if)#ip unnumbered F0/1 !l'oubli de cette commande m'a valu 2h de deboggage...
RTRDT(config-if)#tunnel source F0/1 !mettre l'interface qui reçoit les connexions

Configuration du client:

configuration client

Un ping vers la loopback du routeur RTRDT (10.0.0.1) doit aboutir. Pour l’instant on a pas redistribuer les routes des clients VPNs dans le backbone, donc ça ne va pas marcher vers les autres routeurs.

Un petit avant après de la table de routage du PC:

C:\Documents and Settings\bastien>route print
===========================================================================
===========================================================================
===========================================================================
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.0.254     192.168.0.1       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.1     192.168.0.1       20
      192.168.0.1  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.0.255  255.255.255.255      192.168.0.1     192.168.0.1       20
        224.0.0.0        240.0.0.0      192.168.0.1     192.168.0.1       20
  255.255.255.255  255.255.255.255      192.168.0.1     192.168.0.1       1
  255.255.255.255  255.255.255.255      192.168.0.1               3       1
Passerelle par défaut :     192.168.0.254
===========================================================================
#après
C:\Documents and Settings\bastien>route print
===========================================================================
===========================================================================
===========================================================================
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.0.254     192.168.0.1       20 Passerelle par défaut pas par le VPN
         10.0.0.0        255.0.0.0        10.11.0.4       10.11.0.4       1  Uniqument 10.0.0.0 (ACL Split tunneling)
        10.11.0.0    255.255.255.0        10.11.0.4       10.11.0.4       20 Commande netmask dans le groupe isakmp
        10.11.0.4  255.255.255.255        127.0.0.1       127.0.0.1       20
   10.255.255.255  255.255.255.255        10.11.0.4       10.11.0.4       20
        100.0.0.2  255.255.255.255    192.168.0.254     192.168.0.1       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.0.0    255.255.255.0      192.168.0.1     192.168.0.1       20
      192.168.0.1  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.0.254  255.255.255.255      192.168.0.1     192.168.0.1       1
    192.168.0.255  255.255.255.255      192.168.0.1     192.168.0.1       20
        224.0.0.0        240.0.0.0        10.11.0.4       10.11.0.4       20
        224.0.0.0        240.0.0.0      192.168.0.1     192.168.0.1       20
  255.255.255.255  255.255.255.255        10.11.0.4               3       1
  255.255.255.255  255.255.255.255        10.11.0.4       10.11.0.4       1
  255.255.255.255  255.255.255.255      192.168.0.1     192.168.0.1       1
Passerelle par défaut :     192.168.0.254
===========================================================================

Vérifications:

RTRDT#sh ip route | i 10.11.0
S       10.11.0.4/32 [1/0] via 0.0.0.0, Virtual-Access2 !Route statique vers le client
RTRDT#sh crypto ipsec sa | i peer
   current_peer 100.0.1.6 port 500 !site to site
   current_peer 100.0.2.2 port 3550 !mon client remote vpn
RTRDT#sh crypto isakmp sa
dst             src             state          conn-id slot status
100.0.1.6       100.0.0.2       QM_IDLE              1    0 ACTIVE
100.0.0.2       100.0.2.2       QM_IDLE              2    0 ACTIVE
RTRDT#sh crypto ipsec sa interface virtual-access 2 | i settings
        in use settings ={Tunnel UDP-Encaps, } !utilisation du nat transparency

Bon on y est presque, il faut redistribuer ces routes statiques au sein du backbone.

Ici, un redistribute static subnets dans OSPF fait que les routes sont de types external E2, et ne seraient donc pas redistribuées dans BGP (voir configuration BGP). De plus, cela redistriburait toutes les routes statiques.

On va donc modifier la configuration sur PE1 (et accessoirement sur les PE2 et 3 pour être logique), de la sorte:

PE1#sh ip route vrf VRF1 | i 10.11.0
O E2    10.11.0.2/32 [110/20] via 192.168.0.2, 00:02:00, FastEthernet0/1
PE1(config)#router bgp 1000
PE1(config-router)# address-family ipv4 vrf VRF1
PE1(config-router-af)#redistribute OSPF 1 vrf VRF1 match internal external
PE1(config-router-af)#exit
PE1(config-router)#exit

petite vérification

RMO1#sh ip route | i 10.11.0
O E2    10.11.0.3/32 [110/20] via 192.168.0.5, 00:00:34, FastEthernet0/0

Et du PC connecté en VPN, je peux pinger les réseaux distants (exemple la loopback RMO1 – 10.1.0.1)

Conclusion

Voilà, bravo à ceux qui ont suivi l’article en entier, il y a sans doute des points qui pourraient être améliorés, mais ici le but était plus de manipuler le plus de technologies possibles, et bien que cela s’intitule ISCW Lab, beaucoup de notions ne sont pas à savoir pour ISCW, comme les routes-map, le routage BGP, la configuration PPPoE coté FAI, …

Configuration finales: configs_finales.tar

Je crois que c’est sans conteste l’article le plus long que j’ai fait à ce jour, aussi n’hésitez pas à laisser vos commentaires.

Si certains ont réussi à faire du PPPoA sur dynamips, je suis preneur

ISCW avant la fin de l’année, je vous prépares du lourd

Bastien Migette — Sat, 12 Dec 2009 18:14:11 +0000

Edit: Ce sera pas avant la fin de l’année cause les centres de certifications sont fermés pendant les vacances de noël… Mais début janvier ce sera fait

Voilà ce qui va bientôt arriver:

http://img109.imageshack.us/img109/6951/topoc.png

http://pastebin.com/m3896a7f3

http://img706.imageshack.us/img706/6919/lolix.png

http://img138.imageshack.us/img138/4610/lol2v.png

http://img138.imageshack.us/img138/7408/lol3.png

Compte rendu des cisco experience days de lyon (3/12/2009)

Bastien Migette — Sun, 06 Dec 2009 15:31:58 +0000

Salut à tous, ayant assisté à la conférence cisco experience days à Lyon mercredi 3 décembre, je fais un petit compte rendu de ce que j’y ai appris. Pour ceux qui ne savent pas ce que c’est, allez vite voir le site http://www.cisco.com/web/FR/events/ExperienceDays/index.html peut être que ce n’est pas encore passez prêt de chez vous, c’est gratuit, et y’a même un buffet (gratuit lui aussi), le midi, des cadeaux a gagner, bref c’est pas le but principal, mais l’effort est toutefois à saluer. J’ai assisté aux conférence « borderless network » et « Datacenter ». Mon seul regret à été que sur 3 sessions, 2 seulement ont eu lieu, donc j’ai pas pu voir la session « Architecture ». Il y avait aussi du green IT, nouvelles experiences utilisateurs…

Vous trouverez des infos sur les sessions auxquelles j’ai participé dans la suite de l’article…

Introduction

La journée a commencée par une séance plénière avec un bref historique de cisco, le passé, le futur, pour résumer la chose, cisco à 25 ans, se porte bien, et se focalise non plus sur la vente de produits individuels (exemple des routeurs, des switchs), mais sur des solutions pour des architecture modernes ! (Telepresence, Datacenter, Network,…).

J’ai appris aussi que de plus en plus de registrars internet allaient cesser la distribution d’IPs v4 d’ici 2011 pour forcer l’adoption de l’IPv6 ! Bah oui, les millions d’abonnés, de téléphones 3g, de caméras IP et autre, ça finit pas épuiser nos bonnes vieilles IPv4…

Borderless network

Deuxième présentation à laquelle j’ai assistée, assez technique et très intéressante j’ai trouvée, qui pose la problématique des nouveaux réseaux, dit sans frontières, avec l’essor des utilisateur mobile (SmartPhones, Teleworkers…). Voici les points que j’ai notés de cette sessions:

Une recherche est menée pour avoir des temps de convergence en cas de panne (failover) les plus petit possible.
Un première chose est la redondance hardware, entre les cartes de supervisions (cartes sup’, contiennent l’intelligence d’un châssis type 4500 et supérieurs). En gros vous avez deux cartes sup qui se synchronisent, et si la première est défectueuse, on switch sur l’autre (SSO, Stateful Switch Over = protocole pour la synchro entre les cartes sup).
Ce processus mets 50 millisecondes sur un c4500, et 1 millisecondes sur un ASR (les beaux gros routeurs de FAI :p)

Il y a aussi le non-stop forwarding (NSF), qui permets de continuer le routage même en cas de failover entre cartes sup, imaginons que la 1ère SUP tombe, le routage va continuer au niveau du dataplane (partie qui gère le transit des données dans un routeur), puis quand la deuxième sup devient active, le protocole de routage va reconstruire la table (control plane), et pour ce faire, il va être capable de demander à son voisin la table de routage et de redevenir actif en moins de 100ms ! (voir http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-1/high_availability_routing.html). Cela permets que les routeurs voisins (qui savent que notre routeurs gère le NSF/GR (graceful restart), n’avertissent pas les autres routers de l’état du voisin (et de ses routes), afin de ne pas modifier la topologie du réseau). Les routeurs autres que celui qui effectuent le failover et ses voisins ne voient aucune interruption dans le réseau.

L’ISSU a aussi été abordé, pour ceux qui ne savent pas ça permets l’upgrade à chaud d’IOS, le principe en gros consiste à flasher une carte sup, de faire un failover dessus, et d’upgrader la seconde par la suite, mais ce qui est intéressant c’est qu’un ASR peut le faire avec une seule carte sup, en créant 2 processes IOS et en switchant de l’un vers l’autre !!).

Cisco (enfin celui qui faisait la présentation), annonce un temps de convergence OSPF de 60 ms !!! en tunant les timers, voir lien ci dessus, et cela permets d’éviter d’utiliser des fonctions type fast-reroute MPLS, qui nécessite d’avoir un coeur MPLS, ce qui n’est pas forcément toujours possible, du moins c’est cher

Pour les topologies en anneaux, ce qui est souvent utilisé par les topologie avec de la fibre optique, Cisco à développé REP (Resilient Ethernet Protocol) qui annoncent pas moins de 50ms de temps de convergence !

J’ai aussi appris que sur la version IOS IP Base, on a une version OSPF Light, qui, entre autres, ne permets l’apprentissage que de 200 routes ! pour un full ospf, faut une advipservices…

Une autre technologie cooooooool c’est le VSS (virtual switches system) qui permets d’agréger des catalyst 6500 (uniquement des 6500, ça c’est moins cool) en un seul switch, et donc, au lieux d’avoir de la redondance avec spanning tree au niveau de la couche distribution (comme sur ce schéma type), on a des liens etherchannel, dont qui vont et donc débit doublé x2, si un des switchs ou lien tombe, comme sur un etherchannel, ça bascule sur l’autre…

2/3 infos en vracs:

On peut mettre des APs 802.11n avec des APs 802.11b/g sur le même controller wireless (WCS).
les routers ISR Generation 2 (G2, séries 2900, 3900,…) ont un système de licence, en gros, ils embarquent tous le FULL IOS, et on peut activer des features à la volée sans avoir à rebooter ou flasher quoi que ce soit.
Au niveau de la solution NAC, il y a un guest server (je sais pas si c’est nouveau), permettant de centraliser les guests networks (ex 802.1x) filaires et Wireless.
Apparition d’appliance Mobility Service Engine (MSE : http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps4324/solution_overview_c22-530985.html) qui permettent aux APs et aux switchs catalyst de remontées l’informations des adresses macs qu’ils connaissent (par port/SSID/…), cela se fait via le protocol NMSP, et peut être loggué, en gros, c’est de l’user tracking. Cela peut utiliser les infos du dhcp snooping, pour tracker les couples MAC/IP.
Les VRFs lites utilisent le principe des VRFs MPLS, mais transportées via des VLANs entre switchs catalysts.
Il est possible d’assurer la compatibilité IGMPv3 avec IGMPv2 en utilisant le SSM mapping, en gros, il suffit de faire un A-Record sur une groupe MCast dans le serveur DNS, et le routeur, va pouvoir trouver la source multicast via DNS plutôt que par PIM/IGMPv2 (la V2 ne spécifie pas la source multicast).
Les ISRs G2 gèrent le transcodage de flux vidéo, et actuellement des recherches sont menées pour détecter les key frames et les prioriser par rapport aux autres (pour faire simple, sur les codecs modernes, un a des key frames qui sont une image complète, et les images suivantes des différences en fonction de la key frame, donc si elle est droppée, on se retrouve avec des pixel d’images différentes, vous avez peut être vu ça si vous avez la TV par votre box à la maison). Les ISRs G2 supportent aussi l’ajout de hardware générique (CPU/RAM) pour augmenter l’efficacité totale du routeur, et les perfs des G2 sont multipliée jusqu’a fois 5 à prix équivalent comparé aux ISR G1(séries 1800,2800,2800,…).
Nouvelle feature pour IOS 15.0 (j’ai pas réeussi à savoir pourquoi on est passé de 12.4 à 15, soit c’est top secret, soit y’a pas de raisons rationnelle ): Service Advertisement Framework (SAF), en gros c’est un genre de protocole de routage avec un framework ouvert permettant la découverte de services au sein du réseau de l’entreprise par les applications/hosts directement.

Quelques infos sur les nouveautés coté sécurité:

802.1X MAC Auth ByPass: processus qui va utiliser l’adresse MAC d’un équipement en tant que login/password pour le 802.1x: cela sert à utiliser 802.1X avec des équipements qui ne le gère pas, par exemple les imprimante. L’avantage est bien sur de conserver les avantages de 802.1x (authorization et accounting notemment)

Cisco Flex Auth : Il était possible de définir l’ordre de préférence pour l’auth 802.1X (EAP, Mac Auth Bypass, Web auth,…), mais d’une manière globale seulement, le flex auth permets de le faire par port du switch.

Open Mode 802.1X: Permets de faire du 802.1X sélectif, en gros, cela permets de laisser passer une partie ou tout le trafic sur un port 802.1X même si l’Authentification échoue, permets la migration plus en douceur du 802.1X.

Technologie cisco TrustSec (déjà dispo sur les switchs Nexus 7000, on va y revenir) : Permets l’encryption au niveau 2 (un peu comme de l’IPSEC mais au niveau du LAN, c’est l’arrêt de mort du spoofing et autre joyeuseté d’attaques locales), et aussi, et surtout, l’ajout de Security Groups Tags (SGT), qui permettent de tagguer des trames avec un champs spécial indiquant l’appartenance à un groupe de sécurité, à partir duquel il sera donc possible de filtrer efficacement pas groupe d’utilisateurs, et non plus par IP/MAC/…
A noter que cette encapsulation est standardisée (802.1ae) et que bien qu’elle soit gérée au niveau 2, un routeur pourra tout à fait conserver les SGTs lorsqu’il routera un packet qu’il encapsulera dans une nouvelle trame 802.1ae

Abordage du problème du « green it »

Cisco travaille a une solution appelée energy wise, avec des partenariats sur des entreprises de BTP.
L’energy wise en quelques points:

Création d’un protocole normalisé pour la remontée d’information et donc l’interopérabilité (soit via SNMP, soit via un protocole basé sur TCP que cisco veut faire (ou a fait) ratifier (les APIs ont été rendue publiques).
Permets de profils, pour par exemple mettre en veille les IPPhones pendant la nuit afin de moins consommer aux heures non ouvrées (HNO), mettre des capteurs qui allument/éteignent la lumière selon qu’il y ait des personnes dans la pièce …
Remontée des infos vers un serveur central, qui peut établir des profiles, par exemple une conso moyenne avec une limite max à ne pas dépasser (après laquelle certains équipements vont baisser leur consommation, par exemple les IPPhones des stagiaires vont passer leur écran en noir et blanc ).
Il sera aussi possible de mesurer des infos sur des équipements NON IP via l’ajout d’une genre de Gateway IP, par exemple les climatiseurs et autres, le but étant d’avoir une vision globale de la conso, non uniquement sur les équipements réseaux
Un soft pourra être installer sur les machines utilisateurs pour controller/informer leur consommation.

Voilà c’est tout (je crois) pour la partie borderless, c’est déjà pas mal non ? aller on attaque la partie datacenter

Datacenter

La session datacenter avait un but pas mal commercial, montrant la puissance de la solution cisco, et c’est vrai que ça envoi, surtout la solution avec les blade chassis (UCS Servers), et le câblage FCoE qui divise le nombre de câbles par 5 (voir en image: http://ciscodatacenter.files.wordpress.com/2009/10/cablage.jpg)

Tout d’abord, il est utile de rappeler que cisco ne vend pas de serveurs en tant que tels (ils vendent toutefois des châssis dans lesquels viennent se loger des blades servers, on y reviendra), mais des architectures (et il y a même un projet d’architectures turn key virtualisée, appelé Virtual Computing Environment, VCE, utilisant des VBlock, en gros, on vous livre une ou plusieurs baie avec tout ce qu’il faut dedans en partenariat avec VMWare et EMC, mais c’est du très lourd, et ça vise vraiment les plus grosses SSII mondiales).
Les problématiques des datacenter ont été abordées (oui, un datacenter ça consomme du watts !!), et quelques réponses, le développement durable, par exemple, VMWare alloue dynamiquement l’énergie nécessaire et coupe les processeurs non utilisés.

Cisco ACE (Appliance Control Engine): Définition de contexts clients au sein desquels on peut faire du load balancing de la couche 2 à la couche 7.

Services WAAS (WIDE AERA APPLICATION SERVICES): Permets l’optimisation des liens WANs, en gros, on a une passerelle WAAS qui va agir comme proxy et modifier le comportement de certains protocoles pour optimiser la latence et l’encombrement des liaisons WAN, par exemple, il y a un mécanisme de mise en cache pour que les informations très demandées (genre une page HTML Distante), soit envoyée en local, et ne transite pas sur le WAN, il y a de la compression,… Je vous laisse lire le white paper (lien au début du paragraphe).

Cisco avait innové avec ses switchs MDS (pour le fibre channel, connexion haut débit quasi temps réel pour les réseaux de stockage essentiellement), qui avaient une notion de VSANs (virtuals Storage Area Network), et ils frappent encore plus fort avec les switchs NEXUS qui sont dédiés aux besoins des datacenter. Pour faire simple, ce sont des switchs à haute densité de ports Giga ou 10Giga, dont le prix au port est moitié moins que celui d’un catalyst (en même temps ils font pas la même chose).

Quelques infos en vrac sur les nexus:

Le nexus 1000V est un switch virtuel, remplace celui de VMWare ESX Server pour la communication inter VM, et support le Network Interface Virtualization, qui permets d’identifier le trafic des différentes VM (en le marquant dans un VLAN par exemple)
Les câbles 10G utilisent du câble coaxial et des SFP+, ce qui réduit presque par 10 le coût des installations (par contre c’est 5M max), tout en consommant moins que du câble RJ 45 10G (oui ça existe), par exemple, un lien 10G eth consomme 8w, un lien fibre, 0.1w, et les liens COAX je sais pas …
Nexus 2000: Switch passif, liens Gb, agrège une baie vers un nexus 5000/7000
Nexus 4000: Switch sous forme de blade, prévu pour être intégré dans un blade chassis d’autres constructeurs (IBM et HP sont cités) pour les intégrer à la solution datacenter cisco (sans utiliser de châssis UCS)
Gere le FCoE (Fiber Channel Over Ethernet), plus besoin d’avoir des cartes Ethernet (NIC), des cartes Fiber Channel (HBA), mais des cartes gérant les deux (CNA) sur les serveurs (Ex les UCS, serveurs qui gèrent les hyperviseurs et les VMs), et donc réduisent considérablement le câblage (voir photo plus haut). Utilise le protocole DCB (datacenter bridging, permettant l’encapsulation du FC sur Eth sans perte de paquet (voulu par le standard FC))
Ont un équivalent du VSS pour les 6500 appelé VPC, pas de spanning-tree dans le datacenter…
Virtual Devices Context (VDC): partitionnement des ressources virtuel parmis l’ensemble des serveurs.
Protocole OTV permettant la synchronisation de l’état des machines virtuelles entre 2 datacenter via une liaison IP, toutefois, cela nécessite que les données des VM soit aussi synchronisée (ex: c’est bien beau de sync les connexions TCP pour le serveur SQL, si les bases de données ne sont pas synchro)
Quelques caractéristiques (cisco c’est beau): UCS(je sais plus quel modèle) : 2 Unités de rack, 384Gb de ram (rien que ça), Nexus 7016, 512Ports 10Gb, ou 768 Gb).
L’utilisation de switchs nexus et de servers UCS dans les baie de datacenter permettent d’économiser énormément de place.

Voilà, c’est tout ce que j’ai noté, dommage qu’il n’y ai pas moyen de récupérer les slides de cet évènement (si quelqu’un sait ou ça se trouve qu’il le dise )

Conclusion

Les Cisco experience days ont donc montrer les nouvelles features actuellement déployées, en cours de déploiement, ou encore au stade de recherche chez Cisco, et ça envoi du très très lourd, par contre je manque cruellement de recul pour comparer avec les offres des autres constructeurs si certains savent ce qui se fait chez juniper et autres ça peut être intéressant (faut que j’attaques JNCIA d’ailleurs, et si vous le voulez, je ferai un petit Topo sur l’émulation Juniper, j’ai trouvé une ptite VM qui a l’air de pas trop mal marcher après quelques bidouilles… Je m’écartes du sujet ? ).

Si vous avez des commentaires, si j’ai dit une bêtises, si vous avez des précisions à apporter, n’hésitez pas à réagir à cet article

Quelques liens en vracs:
En fait j’ai la flemme de les mettre, alors vous cliquez la : http://securityblog.cisco-france.com/ et vous cliquez sur les liens du menu à gauche… Je vais pas tout vous faire non plus :p