68 lines
3.2 KiB
YAML
68 lines
3.2 KiB
YAML
|
|
# Underlay du modèle « socle » — l'infrastructure PHYSIQUE la plus simple qui tienne.
|
||
|
|
#
|
||
|
|
# Un modèle d'underlay décrit le matériel d'un HÉBERGEUR, pas un plan de services :
|
||
|
|
# tous les hébergeurs n'ont pas les mêmes équipements. Celui-ci est volontairement
|
||
|
|
# minimal — un seul commutateur, pas de fabric de stockage séparée — parce que c'est
|
||
|
|
# le point de départ honnête d'un petit hébergeur. Les montages plus riches (étoile à
|
||
|
|
# trois commutateurs, paire en MLAG, stockage jumbo dédié) sont d'autres modèles.
|
||
|
|
#
|
||
|
|
# À l'usage : copier ce fichier dans le dépôt de l'hébergeur, l'adapter, puis le monter
|
||
|
|
# ln -s ../OPS-<hebergeur>/underlay.yml underlay.yml
|
||
|
|
# Validé par `python3 scripts/modeles.py verifier` (preuve P17, structure du modèle)
|
||
|
|
# puis, une fois adapté et monté, par `make underlay` (site réel, preuve P23).
|
||
|
|
---
|
||
|
|
underlay:
|
||
|
|
# LE commutateur, qui route tout. Avec un seul équipement il n'y a pas de switches
|
||
|
|
# d'accès : le devis n'émet donc que sa partie A.
|
||
|
|
routeur: switch-01
|
||
|
|
|
||
|
|
# Dialecte de CLI : décide la forme des masques d'ACL, des routes, du spanning-tree.
|
||
|
|
dialecte: cisco
|
||
|
|
|
||
|
|
# Un seul commutateur = aucun lien redondant, donc aucune boucle par construction.
|
||
|
|
# RSTP reste actif comme filet : deux ports brassés ensemble par mégarde suffiraient
|
||
|
|
# à provoquer une tempête de diffusion.
|
||
|
|
stp:
|
||
|
|
mode: rstp
|
||
|
|
topologie: etoile
|
||
|
|
|
||
|
|
reseaux:
|
||
|
|
# Plan de gestion : le commutateur lui-même, l'hyperviseur, l'OOB/IPMI.
|
||
|
|
- nom: management
|
||
|
|
description: Commutateur, mgmt de l'hyperviseur, OOB/IPMI
|
||
|
|
vlan: 10
|
||
|
|
sous_reseau: 10.0.0.0/24
|
||
|
|
passerelle: 10.0.0.1
|
||
|
|
mtu: 1500
|
||
|
|
|
||
|
|
# Lien vers le pare-feu de bordure. SANS LUI, la flotte n'a ni sortie vers
|
||
|
|
# Internet ni chemin de retour vers l'administration : elle serait routée
|
||
|
|
# jusqu'à la bordure puis muette, ce qui est très difficile à diagnostiquer.
|
||
|
|
# `passerelle_sortie` = l'adresse du pare-feu sur ce lien ; c'est elle qui fait
|
||
|
|
# émettre la route par défaut et les routes de retour.
|
||
|
|
- nom: transit-frontiere
|
||
|
|
description: Lien commutateur L3 <-> pare-feu de bordure
|
||
|
|
vlan: 40
|
||
|
|
sous_reseau: 10.0.4.0/29
|
||
|
|
# Le /29 loge deux pare-feux (transition, ou haute disponibilité plus tard) :
|
||
|
|
# ils occupent le bas de la plage, le SVI du commutateur le haut.
|
||
|
|
passerelle: 10.0.4.6 # SVI du commutateur
|
||
|
|
passerelle_sortie: 10.0.4.1 # pare-feu = sortie par défaut de la flotte
|
||
|
|
mtu: 1500
|
||
|
|
|
||
|
|
# Équipements fixes. Le routeur PORTE le SVI de management : son adresse de gestion
|
||
|
|
# EST la passerelle du réseau — `make underlay` refuse deux valeurs divergentes.
|
||
|
|
hotes:
|
||
|
|
- nom: switch-01
|
||
|
|
reseau: management
|
||
|
|
ip: 10.0.0.1
|
||
|
|
# Ports physiques (optionnel). Déclarés, le devis sort applicable tel quel ;
|
||
|
|
# absents, il émet des marqueurs `<PORT-VERS-...>` à remplacer à la main — et
|
||
|
|
# le travail est perdu à chaque régénération.
|
||
|
|
ports:
|
||
|
|
hyperviseurs: [Gi1/0/1]
|
||
|
|
frontiere: [Gi1/0/23]
|
||
|
|
# Le pare-feu de bordure : hors flotte Ansible, déclaré ici pour documenter le
|
||
|
|
# lien et réserver son nom.
|
||
|
|
- { nom: pare-feu-1, reseau: transit-frontiere, ip: 10.0.4.1 }
|