Neutron is a an Openstack module which takes care of networking using the Plug-ins.It consists of the following Logical Elements depicted below in Figure 01. We will use the below figures 01 and 02 as reference through out this blog.
Figure01
Figure02
1) Neutron Server ( API Server): It receives the API calls and directs them to Neutron Plugins.Neutron-server is basically a Python daemon that provides the the OpenStack Networking API and passes tenant requests to a series of plug-ins for additional processing. Neutron brings Networking as a Service (NaaS). This means that the user gets the interface to configure the network and provision security (Add/Remove Routers, Firewalls, Loadbalancers etc.), without caring about the under technology.
2) Database: It is mysql/maria DB Stores the current state of different Plugins. We will explore the Database in details. Let us see what Schema/Tables Neutron Database uses . In my setup I have 2 node system one having Controller and Network node combined (hostname netcon) and the other one Compute node (hostname compute2).
The following output is captured from my controller node which is hosting the database. Lets see the schema in Neutron database.
[root@netcon ~]# mysql -u root
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 56
Server version: 10.1.20-MariaDB MariaDB Server
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.
MariaDB [(none)]> show databases ;
+——————–+
| Database |
+——————–+
| cinder |
| glance |
| gnocchi |
| information_schema |
| keystone |
| mysql |
| neutron |
| nova |
| nova_api |
| performance_schema |
| test |
+——————–+
11 rows in set (0.00 sec)
MariaDB [(none)]> use neutron;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [neutron]> show tables ;
+—————————————–+
| Tables_in_neutron |
+—————————————–+
| address_scopes |
| agents |
| alembic_version |
| allowedaddresspairs |
| bgp_peers |
| flavors |
| poolstatisticss |
| portbindingports |
| portdnses |
| portqueuemappings |
| ports |
| routerl3agentbindings |
| routerports |
| routerroutes |
| routerrules |
| routers |
| subnet_service_types |
| subnetpoolprefixes |
| subnetpools |
| subnetroutes |
| subnets |
| subports |
| tags |
| trunks |
| tz_network_bindings |
| vcns_router_bindings |
| vips |
| vpnservices |
+—————————————–+
162 rows in set (0.00 sec)
MariaDB [neutron]> desc ports ;
+——————+————–+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+——————+————–+——+—–+———+——-+
| project_id | varchar(255) | YES | MUL | NULL
| id | varchar(36) | NO | PRI | NULL
| name | varchar(255) | YES | | NULL
| network_id | varchar(36) | NO | MUL | NULL
| mac_address | varchar(32) | NO | | NULL
| admin_state_up | tinyint(1) | NO | | NULL
| status | varchar(16) | NO | | NULL
| device_id | varchar(255) | NO | MUL | NULL
| device_owner | varchar(255) | NO | | NULL
| standard_attr_id | bigint(20) | NO | UNI | NULL
| ip_allocation varchar(16) | YES | | NULL
+——————+————–+——+—–+———+——-+
11 rows in set (0.00 sec)
Rabbit Messaging:
- Message Queue: Generally this mechanism is based on Rabbit MQ , however there are options available for messaging queue.This is the BUS where the calls between the neutron-server and the agents are queued.
Starting the RabbitMQ
[root@netcon ~]# service rabbitmq-server start
Redirecting to /bin/systemctl start rabbitmq-server.service
Verfying the status of Rabbit MQ. You must see similar output as depicted below.
[root@netcon ~]# rabbitmqctl status
Status of node rabbit@netcon …
[{pid,5641},
{running_applications,[{rabbit,”RabbitMQ”,”3.6.5″},
{rabbit_common,[],”3.6.5″},
{{uptime,17},
{kernel,{net_ticktime,60}}]
<Output Truncated by me >
Listing out the connections where 192.168.0.22 is my compute node and 192.168.0.28 is my controller node.
[root@netcon ~]# rabbitmqctl list_connections
Listing connections …
guest 192.168.0.28 50828 running
guest 192.168.0.28 50829 running
guest 192.168.0.28 51154 running
[root@netcon ~]# rabbitmqctl list_connections
The Agents:
- L2 Agent (Openvswitch Agent) : Manages the Layer 2 Connectivity of every Node (Network and Compute). It resides on the Hypervisor and configures the local vbridges (br-int, br-tun) as shown in the figure 02,wires new devices, Applies security groups. L2 agent communicates all the connectivity changes to the neutron-server over RPC.
- DHCP Agent: DHCP Service doling out the IP address for the Tenant Networks.
- L3 Agent (neutron-l3-agent): L3/NAT Connectivity (Floating IP). It resides on the Network Node, and uses the IP Namespaces (IP NETNS).
The below screen shot shows the agents running on different nodes.
In the next episode we will explore Bridges Mechanism drivers , Type drivers