Neutron L3
The implementation of L3 is only responsible for the routing function. Other functions in traditional routers (such as Firewalls, LB, VPN) are implemented independently, so the actual demand for ML3 is relatively small.
neutron-server receives the request –> sends the request to MQ –> neotron-plugins receives the request –> sends the request to MQ –> neotron-agent establishes the network device.
neutron-plugin: handles requests sent by Neutron Server, maintains the status of the OpenStack logical network, and calls Agent to process requests. Each manufacturer develops software that simulates its own hardware based on Openstack. This software is a plugin. In the early days, each manufacturer developed its own plug-in, and its functions were implemented separately, with a large amount of code duplication; in addition, different manufacturers had different development standards, resulting in poor program compatibility. For this situation, neutron-plugin is divided into two parts: Core-plugin and Service-plugin.
Service-plugin: In addition to core-plugin, other plugins, including l3 router, firewall, loadbalancer, VPN, metering, etc., mainly implement L3-L7 network services. The resources that these plugins need to operate are relatively rich. The REST API that operates these resources is regarded as an Extension API by neutron-server and needs to be extended by the manufacturer.
Router
Provides virtual three-layer services, including routing and network address translation between tenant networks (Tenant Network) and between tenant networks and external networks (External Network). In native mode, router management functions are integrated into Neutron Server in the form of Service Plugin. , the router entity exists in the form of a Linux network namespace and is managed by Neutron L3 Agent.
As can be seen from the above figure, the functions of the Neutron L3 module are mainly implemented by the L3RouterPlugin on the server side and the L3NATAgentWithStateReport on the Agent side:
The Client initiates L3 resource Router and Floating IP management commands to the Server through HTTP. The Server is responsible for processing the addition, deletion, modification, and query of resources in the database, and notifies the Agent of resource update events through RPC. The Agent is ultimately implemented through the network tool stack under Linux. Specific L3 functions.
The core resource of L3 is the Router. Most of the L3 APIs revolve around the addition, deletion, modification, and query of the Router’s basic attributes, extended attributes, or affiliated resources. The Router is also the data unit for synchronization between the L3 Plugin and the L3 Agent.
neutron-agent: handles Plugin requests and is responsible for implementing various network functions on the network provider. There is a one-to-one correspondence with plugin.
iproute2
How to view network interfaces, addresses, routes
The most basic function of the iproute2 toolkit is to manage the network interface of the local machine.
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 54:be:f7:08:c2:1b brd ff:ff:ff:ff:ff:ff
inet 192.168.56.126/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::56be:f7ff:fe08:c21b/64 scope link
valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 54:be:f7:08:c2:1b brd ff:ff:ff:ff:ff:ff
inet 192.168.56.126/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::56be:f7ff:fe08:c21b/64 scope link
valid_lft forever preferred_lft forever
You can also enter the following commands to modify the MTU and packet queue length:
ip link set eth1 mtu 1500 ip link set eth1 txqueuelen 1000
Generally speaking, the network interfaces of this machine are usually named like eth0, eth1, lo. In the past, network interfaces were configured using the ifconfig command provided by the net-tools package. When using iproute2, you can usually use the subcommands ip addr and ip link to complete the same function.
IP routing rules
ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default
These three routing rules are the default rules configured by the kernel. The first line can match any traffic and is used to route high-priority traffic. The second line is the main rule for handling regular routing. The last line is an empty rule, which is used for post-processing if the above rule does not match the packet.
OpenStack FWaaS functionality
In terms of architectural design, Neutron follows the fully distributed idea of OpenStack. Each component communicates through a message mechanism, so that each component and even each process in Neutron can run on any node.
SWaas
Neutron is an OpenStack Networking as a Service project that includes a Firewall as a Service (FWaaS) plug-in that implements firewalls on OpenStack objects such as projects, router ports, and routers.
Firewall rules: Specify the action the firewall should take (allow or deny) when traffic matches a set of attributes (such as port range, protocol, or IP address).
Firewall policy: An ordered set of rules. You can publish policies to share between projects.
Firewalls can be implemented in various ways depending on the driver you use.
For example:
–The iptables driver uses iptable rules to implement firewalls;
–The OpenVSwitch driver uses flow entries in the flow table to implement firewall rules;
–Cisco firewall drivers are available for NSX devices.
The new features of FWaaS v2 are as follows:
FWaaS v1 has been deprecated in favor of v2. In v2, the concept of firewall has been replaced by firewall group, which indicates that a firewall requires two policies: egress policy and ingress policy. Firewall groups apply at the port level, not the router level, and you specify which router ports you want to protect.
The new features in FWaaS 2 are summarized below:
– Level 3 firewalling for routers is not supported by default, but you can enable it by applying a firewall group to all ports in a router.
–Level 3 firewall support for router ports.
–Supports level 2 firewall (i.e. VM port).
–Provide command line interface (CLI).
–Support OpenStack Horizon dashboard.
Enable FWaaS v2
To enable the FWaaS v2 plugin in OpenStack, the following steps are required:
–Install necessary software dependencies. You need to install the neutron-fwaas and neutron-fwaas-dashboard packages as well as any other dependencies required for your specific OpenStack deployment.
–Enable the FWaaS v2 plugin in the OpenStack configuration file. This usually involves adding the following lines to the neutron.conf file:
[fwaas]
driver = neutron_fwaas.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver
–Restart the OpenStack Neutron service. You need to restart the Neutron service for the changes to take effect.
Neither iptables nor firewalld is a real firewall. They are firewall management tools used to define firewall policies. They are just a service. The iptables service will hand over the configured firewall policy to the kernel-level netfilter network filter for processing. The firewalld service hands over the configured firewall policy to the nftables packet filtering framework at the kernel level for processing.
VPN
sudo apt-get install neutron-vpnaas-agent sudo service neutron-vpn-agent restart
Edit the /etc/neutron/neutron.conf file and add the following lines:
service_plugins = router,vpnaas
sudo service neutron-server restart sudo neutron-db-manage --subproject neutron-vpnaas upgrade head
Create a VPNaaS service provider:
neutron vpn-service-provider-create --name <provider-name> \ --vpn-service-provider <vpn-service-provider>
This command will create a VPNaaS service provider named
neutron vpn-service-list
Create VPN connection:
neutron ipsec-site-connection-create --name <ipsec-connection-name> \ --vpnservice-id <vpn-service-id> \ --ikepolicy-id <ikepolicy-id> \ --ipsecpolicy-id <ipsecpolicy-id> \ --peer-address <peer-address> \ --peer-cidr <peer-cidr> \ --peer-id <peer-id> --psk <psk> \ --mtu <mtu> --dpd <dpd> --initiator <initiator>
This command will create a VPN connection named
neutron ipsec-site-connection-list
