Openstack isolates the networks of different projects (tenants) through namespaces. The administrator of each project needs to plan and construct the project network, which leads to the reuse of certain network segments between different projects. For example, 192.168.X.X is the management The network segment used by the staff.
Last time we created a new instance of cirros-vm1 located in vxlan10_net and cirros-vm3 located in vxlan11_net and successfully communicated. Let me talk about the principle today.
Cirros-vm1 and cirros-vm3 are located in different vxlans. The network card information of the tar device does not have an ip, but it can realize layer-3 communication through the router. If there is no Gateway IP, how does router_100_101 complete the routing?
The router realizes the communication between different vxlans by encapsulating the ip gateway information in the namespace, but why is it unnecessary? Obviously, communication between different vxlans can be achieved without namespace. The answer is to enable overlapping use of the network by different projects (tenants).
[root@localhost ~(keystone_admin)]# nova list
+ -------------------------------------- + ---------- -- + --------- + ------------ + ------------- + ---------- ---------------- +
| ID | Name | Status | Task State | Power State | Networks |
+ -------------------------------------- + ---------- -- + --------- + ------------ + ------------- + ---------- ---------------- +
| 791556ab-6231-4370-8a81-972862da200f | cirros-vm1 | SHUTOFF | - | Shutdown | vxlan10_net=172.16.10.11 |
| 6173f9bf-bbed-4d71-96d3-f7ae660dc21c | cirros-vm2 | SHUTOFF | - | Shutdown | vxlan10_net=172.16.10.9 |
| ea42b670-c084-4e76-ae84-23d6617eb420 | cirros-vm3 | SHUTOFF | - | Shutdown | vxlan11_net=172.16.11.4 |
+ -------------------------------------- + ---------- -- + --------- + ------------ + ------------- + ---------- ---------------- +
###View tap device
[root@localhost ~(keystone_admin)]# virsh dumpxml 791556ab-6231-4370-8a81-972862da200f | grep tap
<target dev='tap2c798bf4-8e'/>
[root@localhost ~(keystone_admin)]# virsh dumpxml ea42b670-c084-4e76-ae84-23d6617eb420 | grep tap
<target dev='tap00515be6-9e'/>
###View the network card information of the tap device
[root@localhost ~(keystone_admin)]# ifconfig tap2c798bf4-8e
tap2c798bf4-8e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::fc16:3eff:feee:1305 prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:ee:13:05 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 90 (90.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@localhost ~(keystone_admin)]# ifconfig tap00515be6-9e
tap00515be6-9e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet6 fe80::fc16:3eff:febf:c0eb prefixlen 64 scopeid 0x20<link>
ether fe:16:3e:bf:c0:eb txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1368 (1.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 1382 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
l3 agent will create a namespace for each router, and the interface information under the router will also be synchronized to the interface information of namespace, connect to TAP through veth pair, and then configure the Gateway IP in the namespace On the veth interface, routing can be provided.
###View routing (namespace) list
[root@localhost ~(keystone_admin)]# neutron router-list
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
+ -------------------------------------- + ---------- ---- + ---------------------------------- + ---------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ------------------------ + ------------- + ------- +
| id | name | tenant_id | external_gateway_info | distributed | ha |
+ -------------------------------------- + ---------- ---- + ---------------------------------- + ---------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ------------------------ + ------------- + ------- +
| 30bba1f4-96bb-459c-9760-dba01bde3a01 | router_10_11 | 26f0265d7ca347239ea13ed32279ff7a | {"network_id": "463adb80-e2f3-4a18-9629-cf966fc0b360", "enable_snat": true, "external_fixed_ips": [{"subnet_id": "00897e13 -a522-4b8a-943e-7943b652af5a", "ip_address": "172.24.4.4"}]} | False | False |
| 341a7e57-463d-411b-af0a-8cddc56777d1 | router1 | e035103daab74f818fcb4a8a7dbcfda6 | {"network_id": "463adb80-e2f3-4a18-9629-cf966fc0b360", "enable_ snat": true, "external_fixed_ips": [{"subnet_id": "00897e13 -a522-4b8a-943e-7943b652af5a", "ip_address": "172.24.4.2"}]} | False | False |
+ -------------------------------------- + ---------- ---- + ---------------------------------- + ---------- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- ------------------------ + ------------- + ------- +
###View the interface information of the specific route (namespace)
[root@localhost ~(keystone_admin)]# ip netns
qrouter-30bba1f4-96bb-459c-9760-dba01bde3a01 (id: 5)
qdhcp-53c25734-40ea-421e-8744-31d3e14819d0 (id: 4)
qdhcp-e64a94b3-3256-4a3d-9833-cc3c9f421e70 (id: 3)
qdhcp-d6c09c69-8bb0-476d-9c71-457251af87b9 (id: 1)
qdhcp-fcf7d046-0937-43af-8b94-32cc1edb24e1 (id: 2)
qrouter-341a7e57-463d-411b-af0a-8cddc56777d1 (id: 0)
The route (namespace) with id 5 is the specific id of router_10_11, and you can check the detailed information with ip netns exec ID.
###View routing (namespaceID:qrouter-30bba1f4-96bb-459c-9760-dba01bde3a01) details
[root@localhost ~(keystone_admin)]# ip netns exec qrouter-30bba1f4-96bb-459c-9760-dba01bde3a01 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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
33: qg-f86168a4-fc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:b9:54:91 brd ff:ff:ff:ff:ff:ff
inet 172.24.4.4/24 brd 172.24.4.255 scope global qg-f86168a4-fc
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:feb9:5491/64 scope link
valid_lft forever preferred_lft forever
34: qr-03ede9be-8d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:5f:04:7f brd ff:ff:ff:ff:ff:ff
inet 172.16.10.1/24 brd 172.16.10.255 scope global qr-03ede9be-8d
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe5f:47f/64 scope link
valid_lft forever preferred_lft forever
35: qr-3b2b1f99-dc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:9a:3f:f7 brd ff:ff:ff:ff:ff:ff
inet 172.16.11.1/24 brd 172.16.11.255 scope global qr-3b2b1f99-dc
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe9a:3ff7/64 scope link
valid_lft forever preferred_lft forever
When creating a new network, no gateway is set, and the first address of the default subnet is the gateway address of the network. Here you can see that the router has three interfaces, which are 33, 34, 35, and 33 is the external gateway. When creating a new route, it is there by default. 34 and 35 correspond to vxlan10 and vxlan11 interfaces, and the default gateway of the 172.16.10.0 network is 172.16.10.1 if no gateway is set.
1. The Gateway IP 172.16.10.1 is set on qr-03ede9be-8d, which forms a veth pair with tap03ede9be-8d in the root namespace.
2. The Gateway IP 172.16.11.1 is set on qr-3b2b1f99-dc, which forms a veth pair with tap3b2b1f99-dc in the root namespace.
Here, the routing information is encapsulated in the namespace.From the outside understanding, the namespace can be directly regarded as a route, and the administrator does not need to manage what is the namespace. The project administrator only needs to configure the vxlan network and routing to realize the three-tier Communication, but from the perspective of the administrator of openstack, it cleverly solves the problem of network overlap.
The names are inconsistent, just focus on the topological relationship.
Do not use namespace
use namespace
