Shulou(Shulou.com)06/03 Report--

The design goal of Neutron is to achieve "network as a service". In order to achieve this goal, the design follows the principle of network virtualization based on "software-defined network", and makes full use of various network-related technologies on Linux system.

The linux network technologies involved are as follows:

Bridge: bridge, used in Linux to represent a virtual device that can connect different network devices. The bridge traditionally implemented in linux is similar to a hub device, while the bridge managed by ovs is generally similar to a switch.

Br-int:bridge-integration, an integrated bridge, is often used to represent a bridge that implements major internal network functions.

Br-ex:bridge-external, the external bridge, usually represents the bridge responsible for communicating with the external network.

GRE:General Routing Encapsulation, a way to tunnel through encapsulation. In openstack, it is generally based on L3 gre, that is, original pkt/GRE/IP/Ethernet.

VETH: virtual ethernet interface, usually in the form of pair. The network packet sent by one end will be received by the other end, which can form a channel between two bridges.

Qvb:neutron veth, Linux Bridge-side

Qvo:neutron veth, OVS-side

TAP device: simulates a layer 2 network device that can accept and send layer 2 network packets.

TUN device: simulates a layer 3 network device that can accept and send layer 3 network packets.

Firewall software commonly used on iptables:Linux to implement security policies.

Vlan: virtual Lan, which is isolated with tags under the same physical Lan. Available labels are 1-4094.

VXLAN: an Overlay implementation that uses the UDP protocol as the underlying transport protocol. It is generally considered as an extension or replacement of VLan technology.

Namespace: a set of mechanisms used to achieve isolation. Resources in different namespace are not mutually exclusive.

Taking neutron's gre model as an example, the simplification is as follows

I. Namespace

In Linux, namespaces (namespace) can be thought of as isolated environments with separate network stacks (network cards, routing tables, iptables). Network namespaces are often used to isolate network devices and services, and only devices with the same network namespace can see each other.

You can use the ip netns list command to view existing namespaces.

Ip net list

The namespace that begins with qdhcp is used by the dhcp server, and the namespace that begins with qrouter is used by the router service. You can use ip netns exec namespaceid command to leave the specified network name empty

Occasionally execute network commands, such as

Ip netns exec qdhcp-3bb9ca55-d2e5-45eb-b782-e4de1f60014a ip addr

As you can see, the network namespace of the dhcp service has only one network interface, "aa08fc00-39", which connects to the br-int through "tapa08fc00-39".

1.1DHCP service

Dhcp services are implemented through a dnsmasq process (a lightweight server that can provide services such as dns, dhcp, tftp, and so on), which is bound to the interface of br-int in the dhcp namespace. You can view related processes

For example, query the service process of "qdhcp-3bb9ca55-d2e5-45eb-b782-e4de1f60014a"

Ps-ef | grep 3bb9ca55-d2e5-45eb-b782-e4de1f60014a

This dhcp service, which mainly provides dhcp services to tenants' VPCs, is shown in the dashboard of openstack as follows:

2.1 routing Servic

Router provides interconnection across subnet. For example, if a host in a user's internal network wants to access the address of the external Internet, it needs to be forwarded by router (therefore, all traffic to the external network must pass through router). At present, router is implemented through iptables.

Similarly, the router service runs in its own namespace, which can be viewed with the following command:

Ip netns exec qrouter-014e0e10-47fc-469f-9883-3a5130fc79e6 ip addr

As you can see, the namespace includes two network interfaces.

The first interface, qr-d1a40252-8b (192.168.1.1 Universe 24), is connected to the interface on br-int. That is, any network packet from br-int looking for 192.168.1.0 Universe 24 (the tenant's private network segment) will arrive at this interface.

The first interface qg-2fe564e2-cd connects to the interface on br-ex, that is, any external network packet, ask 172.31.208.102 (the default static NAT external address) or 172.31.208.110 (requested by the tenant)

Floating IP address), will arrive at this interface.

You can also see it on dashboard.

View the routing table in this namespace

Ip netns exec qrouter-014e0e10-47fc-469f-9883-3a5130fc79e6 ip route

By default, and when accessing an external network, the recess is sent out of the qg-xxx interface and published to the br-ex

The extranet. When accessing the tenant's private network, it will be sent to br-int from the qr-xxx interface.

View snat and dnat rules for rout

Ip netns exec qrouter-014e0e10-47fc-469f-9883-3a5130fc79e6 iptables-t nat-S

Where SNAT and DNAT rules complete the mapping from external floating ip (172.31.208.110) to internal ip (192.168.1.17)

There is another SNAT rule that maps all other traffic from the internal IP to the external IP172.31.208.102. In this way, access to the external network can be initiated even if the internal virtual machine does not have an external floating IP.

Ask

2. Security team

Security group is implemented through Linux IPtables, and for this reason, a traditional Linux bridge such as qbr* is introduced on the control node (iptables rules cannot currently be loaded on tap devices directly attached to ovs). First list the port id of the virtual machine with the neutron port-list command on the control node

Neutron port-list

The first 10 digits of the id are used as the id of the qbr (also the tap port) connected to the virtual machine. I or o plus the first nine digits is used as the id of the security group chain.

All the rules are implemented by default in the filter table (default table) on the Compute node to view the rules on the INPUT, OUTPUT and FORWARD chains of the filter table.

On the Compute node, you can use iptables-- line-numbers-vnL [CHAIN] to get the filter table rules (which can be specified on a chain).

2.1INPUT

Iptables-- line-numbers-vnL INPUT

As you can see, the rules related to the security group are redirected to neutron-openvswi-INPUT. Check its rules, there is only one rule

Iptables-- line-numbers-vnL neutron-openvswi-INPUT

Redirect to neutron-openvswi-ocleef425-c

Iptables-- line-numbers-vnL neutron-openvswi-oc1eef425-c

If the dhcp request is made by vm, pass it directly, otherwise go to neutron-openvswi-ocleef424-c

2.2 OUTPUT

Iptables-- line-numbers-vnL OUTPUT

Jump to neutron-filter-top and neutron-openvswi-OUTPUT, respectively.

Iptables-- line-numbers-vnL neutron-filter-top

The neutron-filter-top chain is a jump to neutron-openvswi-local.

View neutron-openvswi-OUTPUT

Iptables-- line-numbers-vnL neutron-openvswi-OUTPUT

You can see that the output chain has no rules.

View neutron-openvswi-local chain rules at the same time

Iptables-- line-numbers-vnL neutron-openvswi-local

You can see that the neutron-oenvswi-local chain is also irregular.

2.3 FORWARD

The function of security group is mainly implemented on FORWARD chain. Users affect the chain when configuring default security rules (for example, allow ssh to vm, allow ping to vm)

Iptables-- line-numbers-vnL FORWARD

Also jump to neutron-filter-top, no rules. Jump to neutron-openvswi-FORWARD.

Iptables-- line-numbers-vnL neutron-openvswi-FORWARD

Neutron-openvswi-FORWARD will match all traffic entering and leaving the tapcleef425 port.

Iptables-- line-numbers-vnL neutron-openvswi-sg-chain

If the traffic is from the bridge to the VM from the tap-cleef425 port, then jump to the neutron-openvswi-icleef425-c;. If the traffic is coming from the tap-cleef425 port to the bridge (that is, from the vm), it jumps to the neutron-openvswi-ocleef425.

Iptables-- line-numbers-vnL neutron-openvswi-ic1eef425-c

Neutron-openvswi-icleef425-c allows policies configured in the security group (allow ssh, ping, and so on) and dhcp reply to pass. The default neutron-openvswi-sg-fallback will drop all traffic.

As you can see, there is also a rule numbered 4 that allows the destination port 22 of the tcp protocol. This is our open port group for ssh protocol login using port 22.

Iptables-- line-numbers-vnL neutron-openvswi-oc1eef425-c

The neutron-openvswi-ocleef425-c will jump to neutron-openvswi-scleef425-c, allowing traffic from DHCP Request and the source IP and source MAC that match the VM.

2.4 overall logic

The overall logic is as follows:

2.5 Quick find Security Group rules

As can be seen from the previous analysis, the name of the chain of the security group related rules of a vm is related to the first nine characters of the id of vm. Therefore, to quickly find the relevant iptables rules on qbr-XXX, you can list them with iptables-S (default is

Filter table) all the rules on the chain, and the chain containing id is the security group rule related to the virtual machine. Where-- physdev-in indicates the port that is about to enter a bridge, and-- physdev-out indicates that it is about to be issued from a bridge port.

Iptables-S | grep tapc1eef425-c0

As you can see, the traffic on the FORWARD chain entering and leaving the tap-cleef425-c0 port is thrown into the neutron-openvswi-sg-chain chain, and the neutron-openvswi-sg-chain is the specific implementation of security group (two

As a rule, the traffic that accesses the virtual machine is thrown to neutron-openvswi-icleef425-c;, which comes out of the virtual machine and is thrown to neutron-openvswi-ocleef4250-c.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.