Changes in 54270d7: Updated remplacement du coeur de réseau Rennais (markdown)

				remplacement-du-coeur-de-r\303\251seau-Rennais.md
			
          @@ -31,15 +31,51 @@ L'opération ayant été infructueuse, Pessac a été remis en service. Le nouve

           ###Détail des modifications

           (tentative de) mise en prod du nouveau switch : transfers de toutes les IPs et du tunnel Gre sur le nouveau switch. L'équipement avait été configuré au préalable, il était néanmoins assez difficile d'en tester certaines fonctionnalités, telles que le tunnel Gre, etc. Migration de la connexion de delicate-cockroach (Hyperviseur) du LACP vers un lien 10Gbps (via un câble DAC): la nouvelle carte réseau était déjà reconnue, il fallait juste reconfigurer l'interface. Ce lien était fonctionnel. Cependant, openvswitch supporte difficilement ces changements d'interface, et il a fallu complètement rebooter l'hyperviseur pour avoir une connexion pleinement fonctionnelle sur les VMs. 

          +Après quelque heures à débugger les problèmes ci-desous, Pessac a été remis en prod en catastrophe.

           ###Problèmes rencontrés

          -Lors de la mise en prod du switch, plusieurs lien ne fonctionnaient pas, listés ci-dessous.

          -- Lien Disi: l'interface recevait les paquets encapsulés GRE contenant les pings d'Icinga. **Cependant, il était impossible, depuis le switch, de joindre l'interface distante du tunnel**. Après traceroutes et investigations, il s'avérait que les paquets n'allaient pas plus loin que le premier routeur de la DISI (10.35.5.1), sans que celui là ne forwarde / renvoie les paquets. Le ping était lui-même assez erratique **Nous avons donc pensé à un éventuel filtrage des adresses MAC du coté de la DISI, où à un cache ARP ayant gardé les adresses de Pessac**.

          +Lors de la mise en prod du switch, plusieurs lien ne fonctionnaient pas, listés ci-dessous (plus de détails dans la section *Tests*).

          +- Lien Disi: l'interface recevait les paquets encapsulés GRE contenant les pings d'Icinga. **Cependant, il était impossible, depuis le switch, de joindre l'interface distante du tunnel**. 

          -- Lien avec Peach : Sur Pessac, outre l'IdRAC, Peach était connecté grâce à un lien trunk, et un lien hybride sur le VLAN 994. Peach ne supportant pas les cartes 10G, cette configuration a été gardée pour Polaris. TODO

          +- Lien avec Peach : Sur Pessac, outre l'IdRAC, Peach était connecté grâce à un lien trunk, et un lien hybride sur le VLAN 994. Peach ne supportant pas les cartes 10G, cette configuration a été gardée pour Polaris. Une fois connecté au nouveau switch, nous avons constaté un **fonctionnement très aléatoire**.

          +  

          +Ce qui nous laissait un switch pas du tout fonctionnel : impossible de communiquer avec le Firewall, ou avec Brest via le tunnel Gre...

           ###Tests

          -TODO

          +Tous ces tests ont été effectué en faisant un mirroring des ports incriminés, pour analyser le traffic circulant. Cette fonction du switch a cependant ses limites, car:

          +- Les requêtes L2 (ARP notamment) ne sont pas présentes sur le port en mirroring

          +- Lors du mirroring, les trames encapsulées dans du 802.1Q (lien trunk) sont désencapsulées.

          +####Lien Disi:

          +- une capture sur l'interface du switch nous a montré que le lien _aurait du_ fonctionner (nous voyions passer les pings d'Incinga encapsulé dans le tunnel Gre). Les paquets avaient néanmoins une **mauvaise adresse Mac de destination** (adresse appartenant au nouveau switch, mais pas de la bonne interface...).

          +- routeur 10.35.5.1 joignable, mais **seulement après un changement d'adresse mac** (voir point plus haut). 

          +- **Impossible** de pinger l'interface distante du Tunnel (adresse Renater). Un traceroute nous a montré que le paquet n'allait **pas plus loin** que le premier routeur (ou la réponse était mal forwardée en retour). 

          +- il était possible de pinger depuis le switch une adresse sur le réseau wifi eduroam, et vice-versa, mais **de façon très erratique** (beaucoup de paquets perdus).

          +Nous avons donc diagnostiqué deux problèmes possibles:

          +- Cache ARP du coté de la DISI, renvoyant sur l'adresse de Pessac

          +- Whitelistage de Pessac sur le lien DISI, entravant la communication après le changement d'équipement.

          +

          +####Liens avec Peach:

          +- Les pings du switch vers Peach **ne fonctionnaient simplement pas**, quelle que soit l'interface testée.

          +- Les pings de Peach vers les IPs du switch **étaient très aléatoires** (ça marchait une fois sur 5!), et ne fonctionnaient encore _que pour les subnets directement connectés_ (possible de ping le vlan 994, mais pas le vlan 999, par exemple)

          +- Les pings vers le pont hertzien étaient possibles (addresse 192.168.254.1), mais cela n'allait pas plus loin... Impossible donc de joindre Internet.  

          +- La capture vers les interfaces incriminés (2 interfaces de Peach, et connexion Quantic) ne montrait _aucun paquets circulant_ (pas de requêtes, ni de réponses) lors des phases de non fonctionnement. Cependant, comme indiqué plus haut, les requêtes de trop bas niveau (ARP) ne sont pas présentes sur le port en mirroring... Nous en avons déduit qu'il y avait un point bloquant de ce coté-là. 

          +

          +Le fonctionnement de Peach restant assez obscur, il en a été déduis que **Peach devait filtrer sur les adresses Mac de Pessac**. Et que le changement d'équipement a rendu tous les liens quasi-inopérants.

          +

          +###Liens avec delicate-cockroach:

          +Pas de problèmes à ce niveau-là, si ce n'est qu'**openvswitch a l'air de mal supporter les changements d'interface à chaud**. En effet, 

          +- Lors d'un reload / restart du service networking, des erreurs étaient toujours affichés (anciennes interfaces encore présentes même en les désactivant manuellement, etc.)

          +- Après un reload / restart, le lien entre l'interface adm de l'hyperviseur et le switch ne **fonctionne pas à tout les coups**

          +- **Impossible de joindre les VMs**, que ce soit du switch, ou de l'hyperviseur directement.

          +Cependant, ces problèmes sont **également présents sur Pessac**, et il semblerait qu'un **reboot complet de l'hyperviseur** solutionne tout.

          +Ce problème a donc été identifié comme étant **inhérant à openvswitch**, et non au nouveau switch.

           ###Évolutions futures

          -TODO

          \ No newline at end of file

          +Actuellement nous sommes dans une situation ou **Pessac et Polaris cohabitent**:

          +- Le coeur de réseau principal reste Pessac (accès Adista, Disi, Tunnel GRE, et lien vers les serveurs).

          +- Cependant, les liens d'accès (vers les chambres et les studios) Passent par Polaris. Ce dernier n'assure pour l'instant que des fonctions de switch, et est connecté à Pessac via un LACP de 2Gbps en trunk sur les vlans 995,998 et 999. Tout est fonctionnel. **Les nouvelles fibres sont donc actuellement celles en production**. Cela permet non seulement la fin de l'exploitation de l'ancienne fibre, mais également **une plus grande robustesse aux pannes à l'accès**. En effet, actuellement les équipements de chaque bâtiment sont **tous connectés directement au switch**, et non plus chainés comme précédemment. Ce qui fait que la panne d'un équipement d'accès n'affectera désormais plus tout le bâtiment.

          +

          +Pour retirer définitivement Pessac du service certains points sont cependant à considérer:

          +- **Le nouveau switch ne gère actuellement pas de fonctions L3**. Ces dernières sont donc configurées, mais non testées. Et la migration de ces fonctions aurait à nouveau pour conséquence **une coupure totale du service rennais**. 

          +- **Le changement du firewall semble indispensable**, ou du moins de la machine physique assurant cette fonction. En effet, il apparait que **Peach ne peut supporter de cartes réseau 10G**, n'ayant pas les ports PCI requis. Une machine possible pour assurer cette fonction serait NSA, actuellement retirée du parc. De plus, les problèmes listés précédemment montrent qu'une refonte du firewall Rennais serait la bienvenue... 

          +

...	...	@@ -31,15 +31,51 @@ L'opération ayant été infructueuse, Pessac a été remis en service. Le nouve
31	31
32	32	###Détail des modifications
33	33	(tentative de) mise en prod du nouveau switch : transfers de toutes les IPs et du tunnel Gre sur le nouveau switch. L'équipement avait été configuré au préalable, il était néanmoins assez difficile d'en tester certaines fonctionnalités, telles que le tunnel Gre, etc. Migration de la connexion de delicate-cockroach (Hyperviseur) du LACP vers un lien 10Gbps (via un câble DAC): la nouvelle carte réseau était déjà reconnue, il fallait juste reconfigurer l'interface. Ce lien était fonctionnel. Cependant, openvswitch supporte difficilement ces changements d'interface, et il a fallu complètement rebooter l'hyperviseur pour avoir une connexion pleinement fonctionnelle sur les VMs.
	34	+Après quelque heures à débugger les problèmes ci-desous, Pessac a été remis en prod en catastrophe.
34	35
35	36	###Problèmes rencontrés
36		-Lors de la mise en prod du switch, plusieurs lien ne fonctionnaient pas, listés ci-dessous.
37		-- Lien Disi: l'interface recevait les paquets encapsulés GRE contenant les pings d'Icinga. Cependant, il était impossible, depuis le switch, de joindre l'interface distante du tunnel. Après traceroutes et investigations, il s'avérait que les paquets n'allaient pas plus loin que le premier routeur de la DISI (10.35.5.1), sans que celui là ne forwarde / renvoie les paquets. Le ping était lui-même assez erratique Nous avons donc pensé à un éventuel filtrage des adresses MAC du coté de la DISI, où à un cache ARP ayant gardé les adresses de Pessac.
	37	+Lors de la mise en prod du switch, plusieurs lien ne fonctionnaient pas, listés ci-dessous (plus de détails dans la section Tests).
	38	+- Lien Disi: l'interface recevait les paquets encapsulés GRE contenant les pings d'Icinga. Cependant, il était impossible, depuis le switch, de joindre l'interface distante du tunnel.
38	39
39		-- Lien avec Peach : Sur Pessac, outre l'IdRAC, Peach était connecté grâce à un lien trunk, et un lien hybride sur le VLAN 994. Peach ne supportant pas les cartes 10G, cette configuration a été gardée pour Polaris. TODO
	40	+- Lien avec Peach : Sur Pessac, outre l'IdRAC, Peach était connecté grâce à un lien trunk, et un lien hybride sur le VLAN 994. Peach ne supportant pas les cartes 10G, cette configuration a été gardée pour Polaris. Une fois connecté au nouveau switch, nous avons constaté un fonctionnement très aléatoire.
	41	+
40	42
	43	+Ce qui nous laissait un switch pas du tout fonctionnel : impossible de communiquer avec le Firewall, ou avec Brest via le tunnel Gre...
41	44	###Tests
42		-TODO
	45	+Tous ces tests ont été effectué en faisant un mirroring des ports incriminés, pour analyser le traffic circulant. Cette fonction du switch a cependant ses limites, car:
	46	+- Les requêtes L2 (ARP notamment) ne sont pas présentes sur le port en mirroring
	47	+- Lors du mirroring, les trames encapsulées dans du 802.1Q (lien trunk) sont désencapsulées.
	48	+####Lien Disi:
	49	+- une capture sur l'interface du switch nous a montré que le lien _aurait du_ fonctionner (nous voyions passer les pings d'Incinga encapsulé dans le tunnel Gre). Les paquets avaient néanmoins une mauvaise adresse Mac de destination (adresse appartenant au nouveau switch, mais pas de la bonne interface...).
	50	+- routeur 10.35.5.1 joignable, mais seulement après un changement d'adresse mac (voir point plus haut).
	51	+- Impossible de pinger l'interface distante du Tunnel (adresse Renater). Un traceroute nous a montré que le paquet n'allait pas plus loin que le premier routeur (ou la réponse était mal forwardée en retour).
	52	+- il était possible de pinger depuis le switch une adresse sur le réseau wifi eduroam, et vice-versa, mais de façon très erratique (beaucoup de paquets perdus).
	53	+Nous avons donc diagnostiqué deux problèmes possibles:
	54	+- Cache ARP du coté de la DISI, renvoyant sur l'adresse de Pessac
	55	+- Whitelistage de Pessac sur le lien DISI, entravant la communication après le changement d'équipement.
	56	+
	57	+####Liens avec Peach:
	58	+- Les pings du switch vers Peach ne fonctionnaient simplement pas, quelle que soit l'interface testée.
	59	+- Les pings de Peach vers les IPs du switch étaient très aléatoires (ça marchait une fois sur 5!), et ne fonctionnaient encore _que pour les subnets directement connectés_ (possible de ping le vlan 994, mais pas le vlan 999, par exemple)
	60	+- Les pings vers le pont hertzien étaient possibles (addresse 192.168.254.1), mais cela n'allait pas plus loin... Impossible donc de joindre Internet.
	61	+- La capture vers les interfaces incriminés (2 interfaces de Peach, et connexion Quantic) ne montrait _aucun paquets circulant_ (pas de requêtes, ni de réponses) lors des phases de non fonctionnement. Cependant, comme indiqué plus haut, les requêtes de trop bas niveau (ARP) ne sont pas présentes sur le port en mirroring... Nous en avons déduit qu'il y avait un point bloquant de ce coté-là.
	62	+
	63	+Le fonctionnement de Peach restant assez obscur, il en a été déduis que Peach devait filtrer sur les adresses Mac de Pessac. Et que le changement d'équipement a rendu tous les liens quasi-inopérants.
	64	+
	65	+###Liens avec delicate-cockroach:
	66	+Pas de problèmes à ce niveau-là, si ce n'est qu'openvswitch a l'air de mal supporter les changements d'interface à chaud. En effet,
	67	+- Lors d'un reload / restart du service networking, des erreurs étaient toujours affichés (anciennes interfaces encore présentes même en les désactivant manuellement, etc.)
	68	+- Après un reload / restart, le lien entre l'interface adm de l'hyperviseur et le switch ne fonctionne pas à tout les coups
	69	+- Impossible de joindre les VMs, que ce soit du switch, ou de l'hyperviseur directement.
	70	+Cependant, ces problèmes sont également présents sur Pessac, et il semblerait qu'un reboot complet de l'hyperviseur solutionne tout.
	71	+Ce problème a donc été identifié comme étant inhérant à openvswitch, et non au nouveau switch.
43	72
44	73	###Évolutions futures
45		-TODO
...	...	\ No newline at end of file
	0	+Actuellement nous sommes dans une situation ou Pessac et Polaris cohabitent:
	1	+- Le coeur de réseau principal reste Pessac (accès Adista, Disi, Tunnel GRE, et lien vers les serveurs).
	2	+- Cependant, les liens d'accès (vers les chambres et les studios) Passent par Polaris. Ce dernier n'assure pour l'instant que des fonctions de switch, et est connecté à Pessac via un LACP de 2Gbps en trunk sur les vlans 995,998 et 999. Tout est fonctionnel. Les nouvelles fibres sont donc actuellement celles en production. Cela permet non seulement la fin de l'exploitation de l'ancienne fibre, mais également une plus grande robustesse aux pannes à l'accès. En effet, actuellement les équipements de chaque bâtiment sont tous connectés directement au switch, et non plus chainés comme précédemment. Ce qui fait que la panne d'un équipement d'accès n'affectera désormais plus tout le bâtiment.
	3	+
	4	+Pour retirer définitivement Pessac du service certains points sont cependant à considérer:
	5	+- Le nouveau switch ne gère actuellement pas de fonctions L3. Ces dernières sont donc configurées, mais non testées. Et la migration de ces fonctions aurait à nouveau pour conséquence une coupure totale du service rennais.
	6	+- Le changement du firewall semble indispensable, ou du moins de la machine physique assurant cette fonction. En effet, il apparait que Peach ne peut supporter de cartes réseau 10G, n'ayant pas les ports PCI requis. Une machine possible pour assurer cette fonction serait NSA, actuellement retirée du parc. De plus, les problèmes listés précédemment montrent qu'une refonte du firewall Rennais serait la bienvenue...
	7	+