Rapports-Intervention/ri-08-04-2018-remplacement-du-coeur-de-r\303\251seau-Rennais.md
... ...
@@ -0,0 +1,84 @@
1
+###État
2
+_Echec!!_
3
+
4
+###Date
5
+Dimanche 08 Mars 2018
6
+
7
+###Admins impliqués:
8
+ Thomas DELABY (à distance), Baptiste GUILLARD, Vincent MESSIÉ
9
+
10
+###But:
11
+Dans le cadre du projet fibre, remplacer Pessac par Polaris, afin de mettre le backbone en 10Gbps
12
+
13
+###État des lieux antérieur
14
+Pessac en prod. Le réseau était assez "instable": en effet, la mise en prod des nouveaux switchs d'accès dans les bâtiments nous a forcé, pour utiliser les anciennes fibres, à utiliser les switchs Unifi (Rox & Roucky) pour chainer les switchs d'accès (lien Pessac => Unifi => Quanta). **_Un problème sur ces derniers, et tout les bâtiments tombaient !_**. Fonctions assurés par Pessac:
15
+
16
+- Switch de coeur principal, connecté notamment à Delicate-cockroach (Hyperviseur), Peach (Firewall), F.O Quantic-Telecom et au réseau DISI.
17
+
18
+- Routage inter-vlans dans 2 zones définis : vlans d'administrations (997,998,988 + tunnel GRE) et vlans "utilisateurs" (999,994,995). Le vlan 980 (Quantic) ne possède pas d'@IP, et le vlan 990 (Disi) est dans une zone séparée (DMZ)
19
+
20
+Le nouveau switch était également complètement configuré. Certaines concessions ont du néanmoins êtres faites par rapport à Pessac. Notamment, cet équipement **ne peut avoir son interface d'administration dans une VRF**. il a donc été nécessaire de:
21
+- Mettre la vrf admin actuelle dans la zone par défaut
22
+
23
+- Et mettre l'ancienne zone par défaut dans une VRF "users".
24
+_Globalement, **la façon de penser Mikrotik étant très différente de celle de cisco**, la configuration a été très laborieuse._
25
+
26
+###État des lieux postérieur
27
+L'opération ayant été infructueuse, Pessac a été remis en service. Le nouveau switch a néanmoins été **installé uniquement pour l'accès** (pas de fonctions L3 fonctionnelles, donc), afin d'utiliser les nouvelles fibres. Il est connecté avec Pessac via un LACP en Trunk sur les vlans 995,998 et 999. Les anciennes fibres sont donc libérées.
28
+
29
+###Machines / Services touchés:
30
+À peut près tout le réseau Rennais ( ͡° ͜ʖ ͡°)
31
+
32
+###Détail des modifications
33
+- (tentative de) mise en prod du nouveau switch : transfert 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** avant la mise en prod, telles que le tunnel Gre, etc.
34
+- 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.
35
+- **Après quelque heures à débugger les problèmes ci-desous, Pessac a été remis en prod en catastrophe.**
36
+
37
+###Problèmes rencontrés
38
+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*).
39
+- 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**.
40
+
41
+- 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**.
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...
44
+
45
+###Tests
46
+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:
47
+- Les requêtes L2 (ARP notamment) ne sont **pas présentes sur le port en mirroring**
48
+- Lors du mirroring, les trames encapsulées dans du 802.1Q (lien trunk) sont **désencapsulées**.
49
+
50
+####Lien Disi:
51
+- 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...).
52
+- routeur 10.35.5.1 joignable, mais **seulement après un changement d'adresse mac** (voir point plus haut).
53
+- **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).
54
+- 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).
55
+
56
+Nous avons donc diagnostiqué deux problèmes possibles:
57
+- **Cache ARP** du coté de la DISI, renvoyant sur l'adresse de Pessac
58
+- **Whitelistage** de Pessac sur le lien DISI, entravant la communication après le changement d'équipement.
59
+
60
+####Liens avec Peach:
61
+- Les pings du switch vers Peach **ne fonctionnaient simplement pas**, quelle que soit l'interface testée.
62
+- 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)
63
+- 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.
64
+- 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à.
65
+
66
+Le fonctionnement de Peach restant assez obscur, il en a été déduit que **Peach devait filtrer sur les adresses Mac de Pessac**. Et que le changement d'équipement a rendu tous les liens quasi-inopérants.
67
+
68
+###Liens avec delicate-cockroach:
69
+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,
70
+- 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.)
71
+- Après un reload / restart, le lien entre l'interface adm de l'hyperviseur et le switch ne **fonctionne pas à tout les coups**
72
+- **Impossible de joindre les VMs**, que ce soit du switch, ou de l'hyperviseur directement.
73
+Cependant, ces problèmes sont **également présents sur Pessac**, et il semblerait qu'un **reboot complet de l'hyperviseur** solutionne tout.
74
+Ce problème a donc été identifié comme étant **inhérant à openvswitch**, et non au nouveau switch.
75
+
76
+###Évolutions futures
77
+Actuellement nous sommes dans une situation ou **Pessac et Polaris cohabitent**:
78
+- Le coeur de réseau principal **reste Pessac** (accès Adista, Disi, Tunnel GRE, et lien vers les serveurs).
79
+- 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.
80
+
81
+Pour retirer définitivement Pessac du service certains points sont cependant à considérer:
82
+- **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**.
83
+- **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...
84
+
remplacement-du-coeur-de-r\303\251seau-Rennais.md
... ...
@@ -1,84 +0,0 @@
1
-###État
2
-_Echec!!_
3
-
4
-###Date
5
-Dimanche 08 Mars 2018
6
-
7
-###Admins impliqués:
8
- Thomas DELABY (à distance), Baptiste GUILLARD, Vincent MESSIÉ
9
-
10
-###But:
11
-Dans le cadre du projet fibre, remplacer Pessac par Polaris, afin de mettre le backbone en 10Gbps
12
-
13
-###État des lieux antérieur
14
-Pessac en prod. Le réseau était assez "instable": en effet, la mise en prod des nouveaux switchs d'accès dans les bâtiments nous a forcé, pour utiliser les anciennes fibres, à utiliser les switchs Unifi (Rox & Roucky) pour chainer les switchs d'accès (lien Pessac => Unifi => Quanta). **_Un problème sur ces derniers, et tout les bâtiments tombaient !_**. Fonctions assurés par Pessac:
15
-
16
-- Switch de coeur principal, connecté notamment à Delicate-cockroach (Hyperviseur), Peach (Firewall), F.O Quantic-Telecom et au réseau DISI.
17
-
18
-- Routage inter-vlans dans 2 zones définis : vlans d'administrations (997,998,988 + tunnel GRE) et vlans "utilisateurs" (999,994,995). Le vlan 980 (Quantic) ne possède pas d'@IP, et le vlan 990 (Disi) est dans une zone séparée (DMZ)
19
-
20
-Le nouveau switch était également complètement configuré. Certaines concessions ont du néanmoins êtres faites par rapport à Pessac. Notamment, cet équipement **ne peut avoir son interface d'administration dans une VRF**. il a donc été nécessaire de:
21
-- Mettre la vrf admin actuelle dans la zone par défaut
22
-
23
-- Et mettre l'ancienne zone par défaut dans une VRF "users".
24
-_Globalement, **la façon de penser Mikrotik étant très différente de celle de cisco**, la configuration a été très laborieuse._
25
-
26
-###État des lieux postérieur
27
-L'opération ayant été infructueuse, Pessac a été remis en service. Le nouveau switch a néanmoins été **installé uniquement pour l'accès** (pas de fonctions L3 fonctionnelles, donc), afin d'utiliser les nouvelles fibres. Il est connecté avec Pessac via un LACP en Trunk sur les vlans 995,998 et 999. Les anciennes fibres sont donc libérées.
28
-
29
-###Machines / Services touchés:
30
-À peut près tout le réseau Rennais ( ͡° ͜ʖ ͡°)
31
-
32
-###Détail des modifications
33
-- (tentative de) mise en prod du nouveau switch : transfert 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** avant la mise en prod, telles que le tunnel Gre, etc.
34
-- 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.
35
-- **Après quelque heures à débugger les problèmes ci-desous, Pessac a été remis en prod en catastrophe.**
36
-
37
-###Problèmes rencontrés
38
-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*).
39
-- 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**.
40
-
41
-- 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**.
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...
44
-
45
-###Tests
46
-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:
47
-- Les requêtes L2 (ARP notamment) ne sont **pas présentes sur le port en mirroring**
48
-- Lors du mirroring, les trames encapsulées dans du 802.1Q (lien trunk) sont **désencapsulées**.
49
-
50
-####Lien Disi:
51
-- 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...).
52
-- routeur 10.35.5.1 joignable, mais **seulement après un changement d'adresse mac** (voir point plus haut).
53
-- **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).
54
-- 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).
55
-
56
-Nous avons donc diagnostiqué deux problèmes possibles:
57
-- **Cache ARP** du coté de la DISI, renvoyant sur l'adresse de Pessac
58
-- **Whitelistage** de Pessac sur le lien DISI, entravant la communication après le changement d'équipement.
59
-
60
-####Liens avec Peach:
61
-- Les pings du switch vers Peach **ne fonctionnaient simplement pas**, quelle que soit l'interface testée.
62
-- 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)
63
-- 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.
64
-- 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à.
65
-
66
-Le fonctionnement de Peach restant assez obscur, il en a été déduit que **Peach devait filtrer sur les adresses Mac de Pessac**. Et que le changement d'équipement a rendu tous les liens quasi-inopérants.
67
-
68
-###Liens avec delicate-cockroach:
69
-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,
70
-- 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.)
71
-- Après un reload / restart, le lien entre l'interface adm de l'hyperviseur et le switch ne **fonctionne pas à tout les coups**
72
-- **Impossible de joindre les VMs**, que ce soit du switch, ou de l'hyperviseur directement.
73
-Cependant, ces problèmes sont **également présents sur Pessac**, et il semblerait qu'un **reboot complet de l'hyperviseur** solutionne tout.
74
-Ce problème a donc été identifié comme étant **inhérant à openvswitch**, et non au nouveau switch.
75
-
76
-###Évolutions futures
77
-Actuellement nous sommes dans une situation ou **Pessac et Polaris cohabitent**:
78
-- Le coeur de réseau principal **reste Pessac** (accès Adista, Disi, Tunnel GRE, et lien vers les serveurs).
79
-- 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.
80
-
81
-Pour retirer définitivement Pessac du service certains points sont cependant à considérer:
82
-- **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**.
83
-- **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...
84
-