Présentation🔗

Le service DHCP est un composant essentiel aux fonctionnalitées réseaux natives d'Opentack, il est de fait complètement intégré et redondé. Sa configuration s'effectue au sein des sous réseaux (WIP).

Au déploiement, une instance se voit obligatoirement attribuer une adresse IP par Openstack:

soit automatiquement parmis les adresses disponibles au sein de la plage d'adresse du sous réseaux
soit prédéterminée si explicitement spécifiée, l'adresse choisie pouvant ou non faire partie de la plage DHCP

Le service DHCP distribue systématiquement l'adresse attribuée à l'instance au déploiement, ce qui d'un point de vu opérationnel revient à une configuration réseau statique, même si la configuration de l'instance demeure en DHCP.

Les avantages apportés par ce mode de fonctionnement:

évite la configuration réseau des instances au déploiement, facilite le déploiement en masse
fournit un référentiel fiable de l'adressage des plateformes, intérogeable via l'API d'Openstack
améliore la sécurité des instances au travers de l'application de règles anti-spoofing par défaut sur chaques instances

Les contraintes:

l'utilisation au sein de l'instance d'une adresse IP différente de celle attribuée par Openstack implique de la configuration supplémentaire sur le port en question, voir la désactivation des sécuritées réseaux. Exemple de cas :
- nécéssitée de modifier l'adressage post déploiement
- utilisation d'une adresse IP virtuelle basculant entre plusieurs instances (VIP)

Note

les images natives Openstack démarrent par défaut avec une configuration réseau en DHCP
le service DHCP distribue des adresses uniquement aux instances Openstack
les instances Openstack ne peuvent recupérer une adresse IP uniquement par un service DHCP Openstack

Attention

l'IP attribuée au déploiement ne peut être modifiée
l'agent clout-init dépend du service DHCP Openstack (hors utilisation d'un config-drive)

Cas d'usage🔗

1. Sous réseaux avec DHCP Openstack🔗

Valable pour les réseaux provider et self service. C'est le fonctionnement par défaut, à privilégier autant que possible afin de profiter pleinement des possibilitées d'automatisations offertes par Openstack:

l'IP attribuée au déploiement est provisionnée dans le service DHCP et associée à l'adresse MAC de l'instance
l'instance démarre avec une configuration réseau DHCP et se voit distribuée l'adresse IP correspondante
cloud-init par défaut ne re-configure pas l'adressage réseau de l'OS

2. Subnet sans DHCP Openstack🔗

Valable pour les réseaux provider et self service. Dans le cas présent l'utilisation d'un config-drive est nécessaire au fonctionnement de cloud-init.

l'instance démarre avec une configuration réseau DHCP
cloud-init, en mode config-drive et sans présence de DHCP, configure l'adressage réseau de l'OS en static avec l'IP attribuée à l'instance au déploiement

3. Subnet avec DHCP Openstack et externe🔗

Valable pour les réseaux provider uniquement. De par le fait que le service DHCP Openstack ne distribue des adresses qu'aux instances Openstack, et que les instance Openstack ne récupèrent des adresses seulement du service DHCP Openstack, la principale précaution dans le cas présent est de s'assurer que les plage d'adresses allouées aux différents serveurs DHCP ne rentrent pas en conflit.

4. Subnet avec DHCP externe seul🔗

Valable pour les réseaux provider uniquement. C'est le cas le plus contraignant, principalement du fait des sécurités anti-spoofing qui, par défaut, interdisent à une instance l'utilisation d'une adresse IP différente de celle attribuée par Openstack. Les sécurités réseaux doivent donc être complètement désactivées.

Les contraintes et fonctionnalitées rendues inopérantes:

l'utilisation de cloud-init via un config-drive est nécessaire
le référentiel Openstack d'adressage des instances n'est plus valide
les règles anti-spoofing sont désactivées
les règles de firewalling des groupes de sécurités ne sont également plus appliquées au instances

C'est un mode de fonctionnement à éviter autant que possible.