Installer let configurer les composants réseau sur le nœud contrôleur.
# apt-get install neutron-server neutron-plugin-ml2 \
neutron-plugin-linuxbridge-agent neutron-l3-agent neutron-dhcp-agent \
neutron-metadata-agent python-neutronclient conntrack
Editer le fichier /etc/neutron/neutron.conf et effectuer les modifications suivantes:
Dans la section [database], configurez l’accès à la base de données:
[database]
...
connection = mysql+pymysql://neutron:NEUTRON_DBPASS@controller/neutron
Remplacer NEUTRON_DBPASS par le mot de passe choisi pour la base de données.
Dans la section [DEFAULT], activer le plugin Modular Layer 2 (ML2), le service routeur, et la superposition d’adresses IP:
[DEFAULT]
...
core_plugin = ml2
service_plugins = router
allow_overlapping_ips = True
Dans les sections [DEFAULT] et [oslo_messaging_rabbit], configurer l’accès à la file de message RabbitMQ:
[DEFAULT]
...
rpc_backend = rabbit
[oslo_messaging_rabbit]
...
rabbit_host = controller
rabbit_userid = openstack
rabbit_password = RABBIT_PASS
Remplacer RABBIT_PASS par le mot de passe choisi pour le compte openstack dans RabbitMQ.
Dans la section [DEFAULT] et [keystone_authtoken], configurer l’accès au service d’Identité:
[DEFAULT]
...
auth_strategy = keystone
[keystone_authtoken]
...
auth_uri = http://controller:5000
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = service
username = neutron
password = NEUTRON_PASS
Remplacer NEUTRON_PASS par le mot de passe choisi pour l’utilisateur neutron dans le service d’Identité.
Note
Commenter ou supprimer toute autre option dans la section [keystone_authtoken].
Dans les sections [DEFAULT] et [nova], configurer le composant Réseau pour notifier le Compute des changements de topologie réseau:
[DEFAULT]
...
notify_nova_on_port_status_changes = True
notify_nova_on_port_data_changes = True
nova_url = http://controller:8774/v2
[nova]
...
auth_url = http://controller:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
region_name = RegionOne
project_name = service
username = nova
password = NOVA_PASS
Remplacer NOVA_PASS par le mot de passe choisi pour l’utilisateur nova dans le service d’Identité.
(Optionnel) Pour faciliter la résolution des problèmes, activer la verbosité des logs dans la section [DEFAULT] :
[DEFAULT]
...
verbose = True
Le plugin ML2 utilise le mécanisme Linux bridge pour construire l’infrastructure réseau virtuel de niveau-2 (bridging and switching) pour les instances.
Editer le fichier /etc/neutron/plugins/ml2/ml2_conf.ini et effectuer les modifications suivantes:
Dans la section [ml2], activer les réseaux flat, VLAN, et VXLAN:
[ml2]
...
type_drivers = flat,vlan,vxlan
Dans la section [ml2], activer les réseaux de projet (privé) VXLAN:
[ml2]
...
tenant_network_types = vxlan
Dans la section [ml2], activer Linux bridge et les mécanismes de population de niveau-2:
[ml2]
...
mechanism_drivers = linuxbridge,l2population
Avertissement
Après avoir configuré le plugin ML2, la suppression de valeurs dans l’option type_drivers peut conduire à une incohérence dans la base de données.
Note
L’agent Linux bridge supporte uniquement la superposition de réseaux VXLAN.
Dans la section [ml2], activer le driver d’extension sécurité des ports:
[ml2]
...
extension_drivers = port_security
Dans la section [ml2_type_flat], configurer le réseau plat fournisseur d’accès public:
[ml2_type_flat]
...
flat_networks = public
Dans la section [ml2_type_vxlan], configurer la plage d’identifiants de réseaux VXLAN pour les réseaux privés:
[ml2_type_vxlan]
...
vni_ranges = 1:1000
Dans la section [securitygroup], activer ipset pour augmenter l’efficacité des règles des groupes de sécurité:
[securitygroup]
...
enable_ipset = True
L’agent Linux bridge construit l’infrastructure de réseau virtuel de niveau-2 (bridging and switching) pour les instances incluant des tunnels VXLAN pour les réseaux privés et gère les groupes de sécurité.
Editer le fichier /etc/neutron/plugins/ml2/linuxbridge_agent.ini et effectuer les modifications suivantes:
Dans la section [linux_bridge], faire correspondre le réseau virtuel public à l’interface réseau physique publique:
[linux_bridge]
physical_interface_mappings = public:PUBLIC_INTERFACE_NAME
Remplacer PUBLIC_INTERFACE_NAME par le nom de l’interface sous-jacente sur le réseau physique public.
Dans la section [vxlan], activer la superposition de réseaux VXLAN, configurer l’adresse IP de l’interface réseau physique qui gère les réseaux superposés, et activer la population de niveau-2:
[vxlan]
enable_vxlan = True
local_ip = OVERLAY_INTERFACE_IP_ADDRESS
l2_population = True
Remplacer OVERLAY_INTERFACE_IP_ADDRESS par l’adresse IP de l’interface réseau physique sous-jacente qui gère les réseaux superposés. L’architecture en exemple utilise l’interface de management pour tuneliser le trafic vers les autres nœuds. Par conséquent, remplacer OVERLAY_INTERFACE_IP_ADDRESS par l’adresse IP de management propre à chaque nœud.
Dans la section [agent], activer la protection contre l’usurpation ARP (ARP spoofing):
[agent]
...
prevent_arp_spoofing = True
Dans la section [securitygroup], activer les groupes de sécurité et configurer le driver firewall Linux bridge iptables:
[securitygroup]
...
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
L’agent Layer-3 (L3) fournit le routage et les services NAT aux réseaux virtuels.
Editer le fichier /etc/neutron/l3_agent.ini et effectuer les modifications suivantes:
Dans la section [DEFAULT], configurer le driver d’interface Linux bridge et le bridge du réseaux externe:
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
external_network_bridge =
Note
L’option external_network_bridge manque volontairement d’une valeur pour permettre plusieurs réseaux externes sur un seul agent.
(Optionnel) Pour faciliter la résolution des problèmes, activer la verbosité des logs dans la section [DEFAULT] :
[DEFAULT]
...
verbose = True
L’agent DHCP fournit les services DHCP aux réseaux virtuels.
Editer le fichier /etc/neutron/dhcp_agent.ini et effectuer les modifications suivantes:
Dans la section [DEFAULT], configurer le driver d’interface Linux bridge, le driver DHCP Dnsmasq, et activer les metadata isolées pour que les instances sur les réseaux public puissent accéder aux metadata à travers le réseau:
[DEFAULT]
...
interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver
dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata = True
(Optionnel) Pour faciliter la résolution des problèmes, activer la verbosité des logs dans la section [DEFAULT] :
[DEFAULT]
...
verbose = True
Les réseaux superposés, comme VXLAN inclut une entête de paquet supplémentaire qui augmente le coût et diminue l’espace disponible pour la charge utile ou les données utilisateur. Sans connaissance de l’infrastructure de réseau virtuel, les instances tentent d’envoyer les paquets en utilisant le maximum transmission unit (MTU) Ethernet par défaut de 1500 octets. Les réseaux Internet protocol (IP) incluent le mécanisme de path MTU discovery (PMTUD) pour détecter le MTU de bout-en-bout et ajuster la taille du paquet packet size en conséquence. Cependant, certains systèmes d’exploitation et équipements réseau ou autre ne supportent pas PMTUD provoquant ainsi des dégradations de performance ou des échecs de connexion.
Idéalement, vous pouvez éviter ces problèmes en activant les jumbo frames sur le réseau physique qui contient les réseaux virtuels de votre tenant. Les jumbo frames supportent des MTUs jusqu’à approximativement 9000 octets ce qui annule l’impact du surcoût VXLAN sur les réseaux virtuels. Néanmoins, de nombreux équipements réseau ne supportent pas les jumbo frames et les administrateurs OpenStack manque souvent de contrôle sur l’infrastructure réseau. Étant donné cette dernière complication, vous pouvez aussi éviter les problèmes de MTU en réduisant le MTU de l’instance pour tenir compte de la surcouche VXLAN. Déterminer la bonne valeur de MTU passe souvent often par l’experimentation, mais 1450 octets fonctionne dans la plupart des environnements. Vous pouvez configurer le serveur DHCP qui attribue les adresses IP à vos instances pour également paramétrer le MTU.
Note
Certaines images cloud ignorent l’option DHCP MTU auquel cas vous devrez le configurer en utilisant les metadata, un script, ou tout autre méthode appropriée.
Dans la section [DEFAULT], activer le fichier de configuration dnsmasq:
[DEFAULT]
...
dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf
Créer et éditer le fichier /etc/neutron/dnsmasq-neutron.conf pour activer l’option DHCP MTU (26) et la configurer à 1450 octets:
dhcp-option-force=26,1450
Retourner à Configuration du nœud contrôleur pour le réseau.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.