Neutron architecture

asked 2020-03-22 02:40:47 -0500

Dinkar gravatar image

Hi, the Neutron documentation in https://docs.openstack.org/neutron/train/contributor/internals/layer3.html (https://docs.openstack.org/neutron/tr...) states that Neutron is implemented via 3 switches - br-ex, br-int, and br-eth1. If I install Openstack via devstack, I am able to see and list these switches. However, if I install Openstack from scratch, these switches don't appear to be there even though Neutron is running. What am I doing wrong? Any help would be greatly appreciated...Dinkar

edit retag flag offensive close merge delete

2 answers

Sort by » oldest newest most voted
0

answered 2020-03-22 06:49:48 -0500

Neutron is quite open and permits many network access mechanisms. When installing from scratch (I suppose you mean the installation tutorial on docs.openstack.org), you didn't use Openvswitch as the mechanism, but Linuxbridge.

See also the description of the Linuxbridge-based architecture: https://docs.openstack.org/neutron/la....

edit flag offensive delete link more

Comments

Thanks very much for your prompt reply!! I will try it out and see if that's the problem.

Dinkar gravatar imageDinkar ( 2020-03-22 11:23:32 -0500 )edit
-1

answered 2020-03-27 23:54:44 -0500

Devendra_Singh_Balihar gravatar image

OpenStack Networking is a standalone service that often deploys several processes across a number of nodes. These processes interact with each other and other OpenStack services. The main process of the OpenStack Networking service is neutron-server, a Python daemon that exposes the OpenStack Networking API and passes tenant requests to a suite of plug-ins for additional processing.

The OpenStack Networking components are:

neutron server (neutron-server and neutron-*-plugin) This service runs on the network node to service the Networking API and its extensions. It also enforces the network model and IP addressing of each port. The neutron-server requires indirect access to a persistent database. This is accomplished through plugins, which communicate with the database using AMQP (Advanced Message Queuing Protocol).

plugin agent (neutron-*-agent) Runs on each compute node to manage local virtual switch (vswitch) configuration. The plug-in that you use determine which agents run. This service requires message queue access and depends on the plugin used. Some plugins like OpenDaylight(ODL) and Open Virtual Network (OVN) do not require any python agents on compute nodes.

DHCP agent (neutron-dhcp-agent) Provides DHCP services to tenant networks. This agent is the same across all plug-ins and is responsible for maintaining DHCP configuration. The neutron-dhcp-agent requires message queue access. Optional depending on plug-in.

L3 agent (neutron-l3-agent) Provides L3/NAT forwarding for external network access of VMs on tenant networks. Requires message queue access. Optional depending on plug-in.

network provider services (SDN server/services) Provides additional networking services to tenant networks. These SDN services may interact with neutron-server, neutron-plugin, and plugin-agents through communication channels such as REST APIs.

Ref link: https://docs.openstack.org/security-guide/networking/architecture.html (https://docs.openstack.org/security-g...)

edit flag offensive delete link more

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2020-03-22 02:40:47 -0500

Seen: 79 times

Last updated: Mar 22