Cahier 2016 groupe n°5
Sommaire
Cahier des charges
Présentation du travail
Répartition du travail
| Séance 1 (03/10) | Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau. |
|---|---|
| Séance 2 (10/10) | Création des VLAN - Bridge |
| Séance 3 (13/10) | Création des VLAN - Bridge |
| Séance 4 (24/10) | Test de la configuration locale |
| Séance 5 (14/11) | |
| Séance 6 (21/11) | |
| Séance 7 (28/11) | |
| Séance 8 (12/12) |
Travail réalisé la 1ère semaine
Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
Ainsi, nous obtenons ce résultat:
Installation Summary --------------------- Hostname : Flash Distribution : jessie MAC Address : 00:16:3E:49:8F:E5 IP Address(es) : 193.48.57.165 RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db Root Password : N/A
Travail réalisé la 2e semaine (2 séances)
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs).
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser.
Configuration générale
Communication: Série 9800 Bauds 8 bits sans parité sans contrôle de flux.
Lors de sa première mise en route, nous devons effectuer sa configuration générale :
hostname cisco config hostname enable secret reverse
Puis ensuite, nous pouvons passer à la configuration des VALNs.
Configuration des VLANs
Nous avons 12 VLANs à configurer :
- 11 VLANs (2-11) : VLAN correspondant aux différents groupes.
- 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs
- 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école
Sur l'interface physique du 4331, il y a 3 interfaces:
- Gi 0/0/0 : disponible en cuivre et en fibre
- Gi 0/0/1: disponible en cuivre
- Gi 0/0/2: disponible en fibre
Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des bridge-domain. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain.
Exemple: VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2
Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir.
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
interface GigabitEthernet 0/0/0.X
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge. Nous devons passer par une nouvelle commande qui s'appelle service instance :
int gi 0/0/0 service instance <n°VLAN> ethernet
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0.
Nous pouvons alors créer nous sous interfaces:
int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...
int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain.
Configuration des bridge-domain
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain:
bridge irb
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées :
bridge 2 protocol ieee bridge 2 route ip
Enfin, nous pouvons allouer des IP aux différents bridge domain :
int BDI2 ip address 10.60.2.1 255.255.255.0
Et nous répétons ces opérations pour tous les bridge-domain.
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.
Travail réalisé la 3e semaine
Test 1
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM.
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc.
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis eth4.
Ensuite, il fallait trouver le port physique correspondant a eth4. Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules, on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse:
# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe.
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk.
Premier essai: FAIL
Test 2
Et là, c'est le drame ... On ne ping rien ...
On se demande donc d'où cela peut venir.
Première cause possible : La configuration de CORDOUAN
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande cdpr (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande:
cdpr -d eth4 cdpr - Cisco Discovery Protocol Reporter Version 2.4 Copyright (c) 2002-2010 - MonkeyMental.com Using Device: eth4 Warning opening device (eth4: no IPv4 address assigned) Waiting for CDP advertisement: (default config is to transmit CDP packets every 60 seconds) Device ID value: Switch_E306 Addresses Port ID value: GigabitEthernet4/13
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13.
Deuxième cause possible: Le commutateur
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande cdpr, on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
Dernière cause possible:Le routeur
On se dit donc que le problème vient du routeur...
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q.
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution peu logique vu que l'encapsulation est déjà faite dans les service instance.
Après encore quelques recherches, une solution plausible est que le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q.
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
rewrite ingress tag pop 1 symmetric
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.
Résultat OK
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle :
ping 193.48.57.171 PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data. 64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms 64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms ^C --- 193.48.57.171 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.
