I briefly talked about OpenStack Neutron plugins and agents in my blog about OpenStack Neutron components. In this blog, let us go a step further and understand the roles of plugins and the agents.
OpenStack Neutron Plugins – why do we need them?
Networking in OpenStack (for VM instances) is very similar to networking in the real world. VM instances require Layer 2 (L2) network connectivity minimally. Additionally instances may also require routing, firewall and load-balancing services. These networking technologies and services can be implemented using a combination of software and networking hardware. In order to allow flexibility and choice, Neutron relies on plugins to support a wide variety of networking technologies.
More about Neutron Plugins
Plugins are pluggable python classes that are invoked while responding to API requests. Neutron plugins are classified into Core and Service plugins. Core plugin primarily deals with L2 connectivity and IP Address management. On the other hand, Service plugins support services such as Routing (L3), firewall and load-balancing services etc.
Note: plugin code is executed as part of Neutron Server on the Controller node.
ML2 – the most important core plugin
The ML2 or Modular Layer 2 plugin is bundled with OpenStack. It is an important core plugin because it supports wide variety of L2 technologies. More importantly the ML2 plugin allows multiple vendor technologies to co-exist.
Out of the box, the ML2 plugin supports Layer 2 technologies such as VLAN, VXLAN and GRE etc. These technologies are referred to as Type drivers. And these technologies in turn can be implemented using various methods like Open vSwitch or via network hardware. ML2 Plugin allows different implementation methods using mechanism drivers.
Although ML2 is the sole core plugin, it can support multiple type drivers and mechanism drivers. This model provides the flexibility and choice needed for tenants as well as leverage the hardware and software networking resources effectively.
OpenStack Neutron Agents
While the Neutron server acts as the centralized controller, the actual networking related commands and configuration are executed on the Compute and the Network nodes. And agents are the entities that implement the actual networking changes on these nodes. Agents receive messages and instructions from the Neutron server (via plugins or directly) on the message bus.
Since Agents are responsible for the implementation of networking, they are closely associated to specific technologies and the corresponding plugins.
An example – Open vSwitch (OVS) Plugin and Agent
The picture below shows a simplified view of the interaction of plugins and agents with rest of the components in OpenStack Networking.
As shown in the picture above, Neutron receives an API request (due to operations done on Horizon or CLI). The API server invokes the ML2 plugin to processes the request. The ML2 plugin has already loaded the OVS Mechanism driver and passes the request related information to the OVS driver. The OVS driver creates an RPC message using the information available in the request. The RPC message is cast to a particular OVS agent running on a compute node. This OVS agent receives the RPC message and proceeds to configure the local instance of OVS switch.