# Configuration réseau de Secours Le test de basculement réseau du 9 aout 2022 des partitions ATLAS (VIPA 10.37.219.10) et LATLAS (VIPA 10.37.218.110) a échoué. Les partitions sont joignables de l'extérieur mais les flux internes (à l'exception du ping) échouent. ## ASAs Les adresses des partitions sont natées par les ASA dans leurs adresses connues sur le site de secours (10.103.218.110 et 10.103.219.10) et ce sont ces adresses qui sont transportées. Ainsi un client qui tente de se connecter à 10.37.218.110 arrive en entrée du fédérateur du SNS avec cette adresse de destination, les ASAs Modifient cette adresse en 10.103.218.110 et c'est la VM LATLAS hébergée au SNS qui répond et le client recevra le flux en retour avec l'adresse source 10.37.218.110. Les règles de natages déclarées dans les ASA sont les suivantes ``` nat (outside,inside) source static any any destination static MRS-218 MRS-218 nat (outside,inside) source static any any destination static MRS-219 MRS-219 nat (outside,inside) source static any any destination static TRS-218 MRS-218 nat (outside,inside) source static any any destination static TRS-219 MRS-219 ``` Lorsqu'on décompose chaque clause de la commande nat ... sur une ligne distincte: ``` nat (outside,inside) source static any any destination static MRS-21x MRS-21x ``` On peut traduire les actions ainsi : * Lorsque le trafic outside correspond: * une source (client) any * une destination (serveur) 10.103.21x.0/24 * Envoyer à inside et translater * la source (client) en any (ne rien faire) * la destination (serveur) en utilisant une traduction statique en 10.103.21x.0/24 Si la destination du flux est 10.103.21x.xxx (adresses du Z de Marseille) on ne fait rien ``` nat (outside,inside) source static any any destination static TRS-21x MRS-21x ``` On peut traduire les actions ainsi : * Lorsque le trafic outside correspond: * une source (client) any * une destination (serveur) 10.37.21x.0/24 * Envoyer à inside et translater * la source (client) en any (ne rien faire) * la destination (serveur) en utilisant une traduction statique en 10.103.21x.0/24 Si la destination est 10.37.21x.xxx celle ci est modifiée en 10.103.21x.xxx Dans le cas étudié le flux est initié par la partition hébergée l'adresse source est l'adresse de la partition au SNS (10.103.21x.xxx) et l'adresse de destination est l'adresse de la partition à TOURS (10.37.21y.yyy) L'adresse de destination étant inconnue du réseau local le flux est envoyé au fédérateur qui le redirige vers le coeur de réseau du Backup. En traversant les ASA l'adresse de destination est transformée en 10.103.21y.yyy est c'est la partition à Marseille qui reçoit la demande. La partition répond à la demande avec l'adresse source 10.103.21x.xxx et l'adresse de destination 10.103.21y.yyy En passant par les ASAs l'dresse 10.103.21y.yyy est transformée en 10.37.21y.yyy L'absence de MASQUERADE peut expliquer la difficulté rencontrée, la solution envisagée consiste à masquer l'adresse source pour faire croire que c'est une adresse en 10.37.21x qui répond. ``` nat (inside,outside) 1 source static MRS-219 TRS-219 destination static TRS-219 MRS-219 nat (inside,outside) 1 source static MRS-219 TRS-219 destination static TRS-218 MRS-218 nat (inside,outside) 1 source static MRS-218 TRS-218 destination static TRS-218 MRS-218 nat (inside,outside) 1 source static MRS-218 TRS-218 destination static TRS-219 MRS-219 nat (outside,inside) source static any any destination static MRS-218 MRS-218 nat (outside,inside) source static any any destination static MRS-219 MRS-219 nat (outside,inside) source static any any destination static MRS-BDX3 MRS-BDX3 nat (outside,inside) source static any any destination static TRS-BDX3 MRS-BDX3 nat (outside,inside) source static any any destination static TRS-218 MRS-218 nat (outside,inside) source static any any destination static TRS-219 MRS-219 ``` La route statique du mini-coeur IBM enjambe le coeur de backup et pointe directement vers le fédérateur:\\ \\ `ip route-static 0.0.0.0 0.0.0.0 10.103.212.34` ## RIP L'étude de la configuration des commutateurs de l'infrastructure de backup a révélé un problème relatif à l'utilisation du RIP. Le RIP est utilisé par les partitions et les ZVM hébergées sur le Z, afin de diffuser les routes des adresses VIPA. Les adresses VIPA ne sont pas adossées à un réseau physique (un réseau décrit dans les commutateurs), les équipements intelligents de l'infrastructure réseau (les commutateurs) apprennent les routes de ces adresses grâce au RIP au travers des adresses physiques connues du réseau local. '--------------------------------------------' .-----------------------------. |[PK] COMMUTATEUR | | ZIBM .-----------. | | | | | LPAR | | | table de routage | '-=------------------' | | ATLAS | | | .----------------+-------------------. | | VIPA:10.103.219.10 | +-------+ | '-=-' | | | | @ destination | Next Hop | | .----.PHYS:10.103.222.11 |---------| OSA 1 |<-----+->| | | | | +----------------+-------------------+<----+----|[yn]|-------------------' +-------+ | | V | | | | | 10.103.219.10 | 10.103.222.11 | | .----. | OSA 2 |<-----+->| | | | | +----------------+-------------------+ | +-------+ | | I | | | | | 10.103.219.10 | 10.103.222.12 | | .----. | OSA 3 |<-----+->| | | | | +----------------+-------------------+<----+----|[yn]|-------------------' +-------+ | | P | | | | | 10.103.219.10 | 10.103.222.13 | | .----.VIPA:10.103.219.10 |---------| OSA 4 |<-----+->| | | | | +----------------+-------------------+ | | PHYS:10.103.222.12 | +-------+ | | A | | | | | 10.103.219.10 | 10.103.222.14 | | '--------------------' | | | | | | | .----------------+-------------------. | | | '-=-' | | | | | .-----------. | '--------------------------------------------' .-----------------------------. [yn]: {"a2s:type":"diamond","a2s:delref":true} [PK]: {"fill":"#FFAAAA","a2s:delref":true} La configuration des mini coeur IBM autorise le RIP pour le Network 10.0.0.0, mais il n'est pas possible de reproduire cette configuration pour les commutateurs de niveau supérieur (le coeur de backup et le fédérateur) car les routes des passerelles BULL (configurées en cas de backup ou de test), seraient également diffusées. Ce qui rend toute communication depuis l'un ces réseaux impossible (par exemple les sites ne peuvent plus envoyer leur liste par FTP vers la boite noire ). Pour résoudre cela une solution consiste à suppléer le RIP en déclarant les routes statiques manuellement sur le coeur de Backup: ``` ip route-static 0.0.0.0 0 10.103.222.34 ip route-static 10.103.218.0 24 10.103.222.36 ip route-static 10.103.219.0 24 10.103.222.36 ip route-static 10.103.222.0 24 10.103.222.36 ip route-static 10.103.218.0 24 10.103.222.36 ``` Les routes statiques sont renseignées dans le fédérateur\\ `ip route-static 10.103.218.0 24 10.103.212.33 tag 30 description IBM-VIPA-ZVMs`\\ `ip route-static 10.103.219.0 24 10.103.21x2.33 tag 30 description IBM-VIPA`\\ `ip route-static 10.37.218.110 32 10.103.212.33 description IBM-VIPA-LATLAS`\\ `ip route-static 10.37.219.10 32 10.103.212.33 description IBM-VIPA-ATLAS` Une autre solution consiste à remonter les passerelles des sous réseaux IBM sur le coeur de réseau du backup. Aucune de ces solutions n'est satisfaisante car elle prive le réseau des fonctionnalités du RIP.