lundi 7 juillet 2014

Lab OSPF/OSPFv3

Un lab OSPF  ou l’on va explorer tout ce que sont que ces notions importantes 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


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.
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.

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).

Area 1 : 

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.
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:

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
 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

mardi 24 juin 2014

PROJET D'INTEGRATION RESEAUX ET SERVICES-PARTIE I: CONCEPTION, DÉPLOIEMENT ET IMPLÉMENTATION D'UNE ARCHITECTURE RESEAUX IPV4 et IPV6 DISTRIBUÉE INTERCONNECTE VIA UN BACKBONE MPLS

Introduction

Dans cette article nous allons présenter la conception et l‟implémentation de l‟architecture réseau. On commence par une présentation générale de la maquette de l‟architecture du projet, puis on va présenter les différentes étapes pour la configuration et le déploiement de l'architecture réseaux, Enfin on va évoquer les étapes afin d‟intégrer une solution d'accès distant VPN permettant aux employés de la société un accès permanent aux ressources de la société d‟une manière sécurisée quel que soit leurs emplacements.

1 Environnement:

Ce paragraphe décrit l'environnement matériel mis à la disposition du présent projet ainsi que l'environnement logiciel qui nous a permis de le réaliser.
  • Environnement matériel

Pour la réalisation de notre projet on a besoin de 2 machines:


  • Environnement logiciel

Outil de Simulation : GNS 3
GNS3 (Graphical Network Simulator) est un simulateur de réseau graphique qui permet l‟émulation des réseaux complexes. GNS3 permet le même type d‟émulation à l‟aide de Cisco Inter network Operating Systems. Il vous permet d‟exécuter un IOS Cisco dans un environnement virtuel sur votre ordinateur. GNS3 est une interface graphique pour un produit appelé Dynagen. Dynamips est le programme de base qui permet l‟émulation d‟IOS. Dynagen s‟exécute au-dessus de Dynamips pour créer un environnement plus convivial.

Outil de virtualisation : Virtual Box
Il permet aux utilisateurs de créer plusieurs machines virtuelles (VM) et de les utiliser simultanément avec la machine réelle.
Chaque machine virtuelle peut exécuter son propre système d‟exploitation, comme Microsoft Windows, Linux ou variantes BSD. En tant que tel, Virtual Box permet à une machine physique d‟exécuter plusieurs systèmes d‟exploitation simultanément.
Système d'exploitation utilisé:
  • Windows server 2008 32 bits
  • Windows 7 32 bits
  • Windows XP sp2 32 bits
  • Ubuntu server 12.04 32bits
  • Cent OS 6.3 32 bits
  • pfSense 2.1
  • Freenas 9.2.1.5 32 bits
  • Elastix 2.6 32bits

2 Présentation de la maquette de l’architecture

La maquette de notre projet représente l‟interconnexion des sites de la société à travers un Backbone MPLS. Ces deux sites (Site1 et Site2) se connectent au Backbone MPLS via deux types de technologie WAN à fin d‟assurer la haute disponibilité des liaisons. La liaison principale utilise une fibre optique tant que la liaison de backup utilise le Backbone Frame Relay. Chaque site contient un Pare-feu afin de le délimiter en trois zones :
  • Une zone DMZ au niveau de laquelle on trouve les serveurs d‟entreprise privés (serveur voip, serveur annuaire, serveur streaming, serveur de stockage, serveur de sauvegarde et serveur de supervision) et les serveurs d‟entreprise public (serveur DNS et serveur de messagerie). Ces différents services fonctionnent aussi bien en IPv4 et en IPv6 et ils sont distribués sur les deux sites.
  • Une zone LAN qui fonctionne en IPv4 et qui contient les machines IPv4.
  • Une zone LAN2 fonctionnant en IPv6.
Nous avons aussi configuré une simulation d‟un réseau internet fonctionnant en ipv4 et ipv6
dans laquelle nous avons :
  • Une zone d‟hébergement (zone d‟hebergement globalnet) fonctionnant en ipv4 et ipv6 au niveau de laquelle on a mis en place un serveur de messagerie et un serveur DNS
  • Configurer deux réseaux d‟internautes l‟un fonctionne en ipv4 et l‟autre en ipv6
Les deux internautes qui ont des comptes de messagerie chez GlobalNet peuvent envoyer des emails aux employés de la société AlliaCom.
Au niveau des pare-feu qui se trouvent dans les sites, nous avons intégré un serveur VPN et nous avons réussi à travers les stations des internautes à se connecter en VPN (accès VPN distant) aux ressources privées (serveurs d‟entreprise) de la société AlliaCom.

3 Schéma d’adressages de l’architecture

Les tableaux ci-dessous regroupent les adresses des différents équipements
3.1 Adressage du Backbone MPLS
3.2 Adressage du Site1


3.3 Adressage Site2
3.4 Adressage du backbone internet
3.5 Nom du domaine


3.6 Adressage des Serveurs

4 Les étapes de la configuration de l’architecture

4.1 Configuration du Backbone MPLS/VPN
Le backbone MPLS est représenté par 11 routeurs Cisco désignés par 3 routeurs Provider Edge (PE1 , PE2 et PEGateway) et 8 routeurs Provider.
Afin de mettre en place la maquette du backbone MPLS nous allons configurer :
  • Le protocole OSPF au niveau des routeurs du Backbone MPLS ;
  • Le mécanisme MPLS dans les routeurs du backbone MPLS ;
  • Les VRF au niveau des routeurs du Backbone MPLS ;
  • Le protocole MP-iBGP entre PE1 et PE2, entre PE1 et PE Gateway et entre PE2 et PE Gateway ;

4.1.1 Configuration du protocole OSPF au niveau du Backbone MPLS
Le protocole OSPF est configuré au niveau des routeurs PE et P, pour chaque routeur il faut déclarer les réseaux voisins du backbone MPLS.
Ci-dessous un exemple de configuration pour le routeur PE :

4.1.2 Vérification des routes OSPF
La figure ci-dessous représente la table du routage du routeur IPv4 de PE1, en utilisant la commande « show ip route ». La lettre O définit les routes découvertes par le protocole OSPF.

Vérification des routes OSPF

4.1.3 Configuration du mécanisme MPLS
MPLS est configuré au niveau de tous les routeurs du backbone MPLS. Nous commençons par l‟activation de MPLS sur chaque interface puis par l‟activation du protocole d‟échange de label LDP.
Ci-dessous un exemple de configuration pour le routeur PE1

4.1.4 Vérification des interfaces des voisins LDP et MPLS
La commande « show mpls ldp neighbor »permet de visualiser les voisins.
Vérification des interfaces des voisins LDP et MPLS

La commande show mpls forwarding-table permet de visualiser la table de forwarding du MPLS (TFIB).
Vérification de la table TFIB

4.1.5 Implémentation du Traffic Engineering
Nous avons configuré la technologie d‟ingénierie de trafic au niveau du backbone MPLS, c‟est un ensemble de fonction permettant de contrôler l‟acheminement du trafic dans le réseau afin d‟optimiser l‟utilisation des ressources et de réduire les risques de congestion.
Implémentation du traffic Engineering

4.1.6 Configuration des tunnels
Nous avons Configuré trois tunnels explicites au niveau du routeur PE1 vers le routeur PE2 du Site d'AlliaCom.
L‟exemple ci-dessous décrit la configuration d‟un tunnel explicite au niveau du routeur PE1.

4.1.7 Vérification de l’établissement des tunnels :
La commande « show mpls traffic-eng tunnels brief » permet de visualiser la liste des tunnels créés.
4.1.8 Configuration des VRFs (Virtual Routing and Forwarding)
Les VRFs sont configurés au niveau des routeurs PE afin d‟isoler le trafic entre les sites clients. Grâce à la notion de VRF le routeur PE peut gérer plusieurs tables de routage.
Ci-dessous la configuration des VRFs sur PE1.
Nous avons configuré de la même manière deux VRFs intitulés CUST et CUST2 au niveau du routeur PE2 important les routes VPN de l‟autre site et de la PEgateway, et un VRF intitulé ISP au niveau du routeur PEGateway export toutes les routes VPN des deux clientx .
La commande « show vrf » permet de visualiser les VRFs configurés au niveau des PEs
4.1.9 Configuration du protocole OSPF et OSPFv3 entre CE1 et PE1
Nous avons activé les protocoles OSPF et OSPFv3 au niveau du routeur client CE1 et au niveau de PE1 vrf CUST.
L‟exemple ci-dessous montre une configuration du routeur CE1 en ipv4 :
Alors que l‟exemple suivant montre une configuration du routeur CE1 en ipv6 :
L‟exemple suivant montre une configuration du routeur PE1 en ipv4 :
Alors que l‟exemple ci-dessous montre une configuration du routeur PE1 en ipv6 :
4.1.10 Vérification des routes OSPF et des routes OSPF3
La commande « show ip route vrf CUST » permet d‟afficher la table de routage ipv4 du VRF CUST au niveau du routeur PE1.
Vérification des routes OSPF
La commande « show ipv6 route vrf CUST » permet d‟afficher la table de routage ipv6 de VRF CUST au niveau du routeur PE1.

4.1.11 Configuration de la technologie WAN de backup Frame Relay


Nous avons configuré la technologie Frame-Relay comme une liaison de backup au cas où la liaison entre le routeur PE1 et le routeur CE1 tombe en panne.
  • Configuration d’un mappage statique
Malgré l‟utilité du protocole ARP inverse, il n‟est pas toujours fiable. La meilleure pratique consiste à mapper les adresses IP avec les DLCI, de manière statique
Nous décrivons ci-dessous une configuration du mappage statique au niveau des routeurs PE1 et CE2 en ipv4 :
Ainsi qu‟une configuration du mappage statique au niveau des routeurs PE1 et CE2 en ipv6
4.1.12Vérification du mappage statique
La commande « show frame-relay map » permet de vérifier le mappage statique
4.1.13 Configuration du protocole EIGRP et EIGRP v6 entre CE2 et PE1
Nous avons configuré les protocoles EIGRP et EIGRP v6 au niveau de CE2 et de PE1 VRF CUS2. Afin d‟échanger les routes ipv4 et ipv6.
Nous décrivons ci-dessous un exemple d'une configuration du routeur CE2 en ipv4 :
Ainsi qu‟un exemple d‟une configuration du routeur CE2 en ipv6 :
Comme le routeur PE1 a une configuration propre à la notion de VRF, nous avons configuré les protocoles EIGRP et EIGRP v6 dessus afin qu‟il accepte les routes de CE2 puis il les convertit en route VPN
Nous décrivons ci-dessous un exemple d‟une configuration du routeur PE1 en ipv4
Ainsi la configuration du routeur PE1 en ipv6 :
4.1.14 Vérification des routes EIGRP et EIGRP6
La commande « show ip route vrf CUST2 » permet d‟afficher la table de routage de VRF CUST2 du routeur PE1 en ipv4. Nous précisons que les lettres D et D EX précèdent les routes découvertes par le protocole EIGRP.
La commande « show ipV6 route vrf CUST2 » permet d‟afficher la table de routage de VRF CUST2 du routeur PE1 en ipv6.

4.1.15 Configuration du protocole RIP et RIPng
Nous avons activé les protocoles Rip version 2 et RIPng entre CE1 et CE2 afin d‟échanger entre eux les routes ipv4 et ipv6
L‟exemple ci-dessous détaille les étapes d‟activation du protocole RIP au niveau des routeurs CE1 et CE2.

4.1.16 Vérification des routes RIP et RIPng
La commande « show ip route» permet d‟afficher la table de routage des routeurs clients CE1 et CE2 en ipv4.
La capture d‟écran ci-dessous montre la table de routage RIP de CE2 en ipv4 :

La commande « show ipv6 route» permet d‟afficher la table de routage des routeurs clients CE1 et CE2 en ipv6. Nous précisons que les Lettres R précèdent les routes découvertes par le protocole RIPng.


La capture d‟écran ci-dessous montre la table de routage RIPng de CE2 en ipv6

4.1.17 Configuration du protocole BGP (Border Gateway Protocol)
La configuration de ce protocole sera faite au niveau des trois routeurs du Backbone MPLS en ipv4 et en ipv6 : PE1, PE2, PEGateway.
Un exemple de configuration pour le routeur PE1 est décrit ci-dessous.
4.1.18 Vérification des routes BGP
La commande « show ip route vrf CUST » permet d‟afficher la table de routage ipv4 de la VRF CUST1 du routeur PE1. Nous précisons que la lettre B précède les routes VPN du site 2 envoyé par le protocole MP-BGP
La commande « show ipv6 route vrf CUST » permet d‟afficher la table de routage ipv6 de la VRF CUST1 du routeur PE1.

4.1.19 Test du backup Frame Relay
  • Avant rupture de la connexion fibre optique
Lorsque la liaison fibre optique est fonctionnelle entre les routeurs PE2 et CE3 le routeur client CE4 du Site2 connait bien les réseaux du Site1 et le route par défaut vers l‟Internet à travers les mises à jour RIP en IPv4 et RIPng en IPv6 comme le montrent les figures ci-après:
Table de routage de la CE2 en IPv4


Table de routage IPv6 du CE2

D‟après ces deux tables de routages, on remarque que le chemin principal pour transmettre l‟information vers un des réseaux du site 1 est à travers la fibre optique, c‟est à dire si je vais envoyer une trame du site2 vers n‟importe quelle adresse appartenant au site 1, le chemin principal sera à travers la liaison fibre optique (connexion entre CE3 et PE2). La liaison à travers le backbone frame relay n‟est pas utilisée pour la transmission vu que la distance administrative de l‟OSPF (AD=110) est inférieure à la distance administrative du protocole rip (AD=120) et que la distance administrative du rip (AD=120) est supérieure à la distance administrative d‟une route externe EIGRP (AD=170).
Si on désactive la connexion fibre optique, le chemin principal de la transmission serait à travers le backbone Frame relay vu que le routeur CE4 ne va pas recevoir des mises à jour rip concernant les réseaux des sites distant (vu que la connexion fibre est désactivée), donc il y a un seul chemin pour arriver au site distant c‟est à travers le backbone Frame relay. D‟autre part, le routeur CE3 va router la trame au routeur CE4 vu que la liaison fibre optique est désactivée.
Donc d‟après l‟analyse des tables de routage, on voit bien que la liaison frame relay est une connexion de backup.

4.2 Configuration du backbone internet

4.2.1 Configuration du VRF et du protocole BGP
Nous avons configuré un VRF intitulé ISP au niveau du routeur PEGateway qui va importer tous les réseaux VPN des sites de la société
Voici un exemple de la configuration du VRF au niveau du routeur PEGateway.
Voici un exemple de la configuration du protocole MP-BGP au niveau du routeur PEGateway

4.2.2 Configuration de la surcharge Nat

Nous avons configuré la surcharge Nat pour autoriser l‟accès internet aux employés de la société alliacom sur les routeurs PEGateway
4.2.3 Configuration du Nat Statique
Nous avons configuré le Nat Statique au niveau des routeurs PEGateway afin de rendre les serveurs (DNS, messagerie) hébergé au niveau de la zone DMZ du site 1 ainsi que le firewall accessible via internet

4.2.4 Vérification de la translation d’adresse
La commande « sh ip nat translations » permet d‟afficher la translation des adresses privées en adresses publiques.

4.2.5 Configuration des routes Statique
Nous avons configuré des routes statiques au niveau du routeur internet connecté à la gateway internet
Voici un exemple de configuration des routes statique au niveau du routeur ISP

4.2.6 Vérification des routes statiques

Tout au long de cette article, nous avons présenté la maquette générale de notre projet qui se présente par trois parties :
  • L'interconnexion de deux sites à travers un Bacbone MPLS
  • Simulation d‟un réseau internet
Dans l'article suivant suivant on va présenter l‟intégration des différents services de notre projet