neutron的基本原理

首页 > 代码库 > neutron的基本原理

2024-07-05 19:43:26 234人阅读

neutron是openstack的一个重要模块，也是比较难以理解和debug的模块之一。

我这里安装如图安装了经典的三个节点的Havana的Openstack

openstack deployment

图1

分三个网络：

External Network/API Network，这个网络是连接外网的，无论是用户调用Openstack的API，还是创建出来的虚拟机要访问外网，或者外网要ssh到虚拟机，都需要通过这个网络
Data Network，数据网络，虚拟机之间的数据传输通过这个网络来进行，比如一个虚拟机要连接另一个虚拟机，虚拟机要连接虚拟的路由都是通过这个网络来进行
Management Network，管理网络，Openstack各个模块之间的交互，连接数据库，连接Message Queue都是通过这个网络来。

将这三个网络隔离，一方面是安全的原因，在虚拟机里面，无论采取什么手段，干扰的都紧紧是Data Network，都不可能访问到我的数据库，一方面是流量分离，Management Network的流量不是很大的，而且一般都会比较优雅的使用，而Data network和External Network就需要进行流量控制的策略。

我的这个网络结构有些奇怪，除了Controller节点是两张网卡之外，其他的都多了一张网卡连接到external network，这个网卡是用来做apt-get的，因为Compute Node按说是没有网卡连接到外网的，为了apt-get添加了eth0，Network Node虽然有一个网卡eth1是连接外网的，然而在neutron配置好之前，这个网卡通常是没有IP的，为了apt-get也添加了eth0，有人说可以通过添加route规则都通过Controller连接外网，但是对于初学的人，这个样比较容易操作。

neutron是用来创建虚拟网络的，所谓虚拟网络，就是虚拟机启动的时候会有一个虚拟网卡，虚拟网卡会连接到虚拟的switch上，虚拟的switch连接到虚拟的router上，虚拟的router最终和物理网卡联通，从而虚拟网络和物理网络联通起来。

neutron分成多个模块分布在三个节点上。

Controller节点：

neutron-server，用于接受API请求创建网络，子网，路由器等，然而创建的这些东西仅仅是一些数据结构在数据库里面

Network节点：

neutron-l3-agent，用于创建和管理虚拟路由器，当neutron-server将路由器的数据结构创建好，它是做具体的事情的，真正的调用命令行将虚拟路由器，路由表，namespace，iptables规则全部创建好
neutron-dhcp-agent，用于创建和管理虚拟DHCP Server，每个虚拟网络都会有一个DHCP Server，这个DHCP Server为这个虚拟网络里面的虚拟机提供IP
neutron-openvswith-plugin-agent，这个是用于创建虚拟的L2的switch的，在Network节点上，Router和DHCP Server都会连接到二层的switch上

Compute节点：

neutron-openvswith-plugin-agent，这个是用于创建虚拟的L2的switch的，在Compute节点上，虚拟机的网卡也是连接到二层的switch上

图2

当我们搭建好了Openstack，然后创建好了tenant后，我们会为这个tenant创建一个网络。

#!/bin/bash
TENANT_NAME="openstack"
TENANT_NETWORK_NAME="openstack-net"
TENANT_SUBNET_NAME="${TENANT_NETWORK_NAME}-subnet"
TENANT_ROUTER_NAME="openstack-router"
FIXED_RANGE="192.168.0.0/24"
NETWORK_GATEWAY="192.168.0.1"

PUBLIC_GATEWAY="172.24.1.1"
PUBLIC_RANGE="172.24.1.0/24"
PUBLIC_START="172.24.1.100"
PUBLIC_END="172.24.1.200"

TENANT_ID=$(keystone tenant-list | grep " $TENANT_NAME " | awk ‘{print $2}‘)

(1) TENANT_NET_ID=$(neutron net-create --tenant_id $TENANT_ID $TENANT_NETWORK_NAME --provider:network_type gre --provider:segmentation_id 1 | grep " id " | awk ‘{print $4}‘)

(2) TENANT_SUBNET_ID=$(neutron subnet-create --tenant_id $TENANT_ID --ip_version 4 --name $TENANT_SUBNET_NAME $TENANT_NET_ID $FIXED_RANGE --gateway $NETWORK_GATEWAY --dns_nameservers list=true 8.8.8.8 | grep " id " | awk ‘{print $4}‘)

(3) ROUTER_ID=$(neutron router-create --tenant_id $TENANT_ID $TENANT_ROUTER_NAME | grep " id " | awk ‘{print $4}‘)

(4) neutron router-interface-add $ROUTER_ID $TENANT_SUBNET_ID

(5) neutron net-create public --router:external=True

(6) neutron subnet-create --ip_version 4 --gateway $PUBLIC_GATEWAY public $PUBLIC_RANGE --allocation-pool start=$PUBLIC_START,end=$PUBLIC_END --disable-dhcp --name public-subnet

(7) neutron router-gateway-set ${TENANT_ROUTER_NAME} public

create network

图3

为这个Tenant创建一个private network，不同的private network是需要通过VLAN tagging进行隔离的，互相之间broadcast不能到达，这里我们用的是GRE模式，也需要一个类似VLAN ID的东西，称为Segment ID
创建一个private network的subnet，subnet才是真正配置IP网段的地方，对于私网，我们常常用192.168.0.0/24这个网段
为这个Tenant创建一个Router，才能够访问外网
将private network连接到Router上
创建一个External Network
创建一个Exernal Network的Subnet，这个外网逻辑上代表了我们数据中心的物理网络，通过这个物理网络，我们可以访问外网。因而PUBLIC_GATEWAY应该设为数据中心里面的Gateway， PUBLIC_RANGE也应该和数据中心的物理网络的CIDR一致，否则连不通，而之所以设置PUBLIC_START和PUBLIC_END，是因为在数据中心中，不可能所有的IP地址都给Openstack使用，另外可能搭建了VMware Vcenter，可能有物理机器，仅仅分配一个区间给Openstack来用。
将Router连接到External Network

经过这个流程，从虚拟网络，到物理网络就逻辑上联通了。

创建完毕网络，如果不创建虚拟机，我们还是发现neutron的agent还是做了很多工作的，创建了很多的虚拟网卡和switch

在Compute节点上：

root@ComputeNode:~# ip addr
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:49:5c:41 brd ff:ff:ff:ff:ff:ff
    inet 172.24.1.124/22 brd 172.24.1.255 scope global eth0
2: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:8e:42:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.124/24 brd 192.168.56.255 scope global eth2
3: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:68:92:ce brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.124/24 brd 10.10.10.255 scope global eth3
4: br-int: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether d6:2a:96:12:4a:49 brd ff:ff:ff:ff:ff:ff
5: br-tun: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether a2:ee:75:bd:af:4a brd ff:ff:ff:ff:ff:ff
6: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff
7: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff

root@ComputeNode:~# ovs-vsctl show
39f69272-17d4-42bf-9020-eecc9fe8cde6
    Bridge br-int
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port br-int
            Interface br-int
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, local_ip="10.10.10.124", out_key=flow, remote_ip="10.10.10.121"}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "1.10.2"

在Network Node上：

root@NetworkNode:~# ip addr
1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:22:8a:7a brd ff:ff:ff:ff:ff:ff
    inet 172.24.1.121/22 brd 172.24.1.255 scope global eth0
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:56:7b:8a brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.121/24 brd 192.168.56.255 scope global eth2
4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:26:bc:84 brd ff:ff:ff:ff:ff:ff
    inet 10.10.10.121/24 brd 10.10.10.255 scope global eth3
5: br-ex: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 08:00:27:f1:31:81 brd ff:ff:ff:ff:ff:ff
    inet 172.24.1.8/24 brd 172.24.1.255 scope global br-ex
6: br-int: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 22:fe:f1:9b:29:4b brd ff:ff:ff:ff:ff:ff
7: br-tun: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether c6:ea:94:ff:23:41 brd ff:ff:ff:ff:ff:ff

root@NetworkNode:~# ip netns
qrouter-b2510953-1ae4-4296-a628-1680735545ac
qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b

root@NetworkNode:~# ip netns exec qrouter-b2510953-1ae4-4296-a628-1680735545ac ip addr
8: qg-97040ca3-2c: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:26:57:e3 brd ff:ff:ff:ff:ff:ff
    inet 172.24.1.100/24 brd 172.24.1.255 scope global qg-97040ca3-2c
11: qr-e8b97930-ac: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:43:ef:16 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global qr-e8b97930-ac

root@NetworkNode:~# ip netns exec qdhcp-96abd26b-0a2f-448b-b92c-4c98b8df120b ip addr
9: tapde5739e1-95: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether fa:16:3e:19:8c:67 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global tapde5739e1-95
    inet 169.254.169.254/16 brd 169.254.255.255 scope global tapde5739e1-95

root@NetworkNode:~# ovs-vsctl show
d5d5847e-1c9e-4770-a68c-7a695b7b95cd
    Bridge br-ex
        Port "qg-97040ca3-2c"
            Interface "qg-97040ca3-2c"
                type: internal
        Port "eth1"
            Interface "eth1"
        Port br-ex
            Interface br-ex
                type: internal
    Bridge br-int
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
        Port "tapde5739e1-95"
            tag: 1
            Interface "tapde5739e1-95"
                type: internal
        Port br-int
            Interface br-int
                type: internal
        Port "qr-e8b97930-ac"
            tag: 1
            Interface "qr-e8b97930-ac"
                type: internal
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port "gre-2"
            Interface "gre-2"
                type: gre
                options: {in_key=flow, local_ip="10.10.10.121", out_key=flow, remote_ip="10.10.10.124"}
        Port br-tun
            Interface br-tun
                type: internal
    ovs_version: "1.10.2"

这时候如果我们创建一个虚拟机在这个网络里面，在Compute Node多了下面的网卡：

13: qvof5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether c2:7e:50:de:8c:c5 brd ff:ff:ff:ff:ff:ff
14: qvbf5da998c-82: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether c2:33:73:40:8f:e0 brd ff:ff:ff:ff:ff:ff
15: qbr591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff
16: qvo591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether e2:58:d4:dc:b5:16 brd ff:ff:ff:ff:ff:ff
17: qvb591d8cc4-df: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr591d8cc4-df state UP qlen 1000
    link/ether f2:d9:f0:d5:48:c8 brd ff:ff:ff:ff:ff:ff
18: tap591d8cc4-df: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master qbr591d8cc4-df state UNKNOWN qlen 500
    link/ether fe:16:3e:6e:ba:d0 brd ff:ff:ff:ff:ff:ff

如果我们按照ovs-vsctl show的网卡桥接关系，变可以画出下面的图

gre tunnel

图4

当然如果你配的不是GRE而是VLAN的话，便有下面这个著名的复杂的图。

在network Node上：

under-the-hood-scenario-1-ovs-network

图5

在Compute Node上：

under-the-hood-scenario-1-ovs-compute

图6

当看到这里，很多人脑袋就大了，openstack为什么要创建这么多的虚拟网卡，他们之间什么关系，这些dl_vlan, mod_vlan_vid都是什么东东啊？

这些网卡看起来复杂，却是各有用处，这种虚拟网络拓扑，正是我们经常使用的物理网络的拓扑结构。

我们先来回到一个最最熟悉不过的场景，我们的大学寝室，当时我们还买不起路由器，所以一般采取的方法如下图所示：

寝室长的机器上弄两张网卡，寝室买一个HUB，其他人的电脑都接到HUB上，寝室长的电脑的两张网卡一张对外连接网络，一张对内连接HUB。寝室长的电脑其实充当的便是路由器的作用。

后来条件好了，路由器也便宜了，所以很多家庭也是类似的拓扑结构，只不过将Computer1和switch合起来，变成了一个路由器，路由器也是有多个口一个连接WLAN，一个连接LAN。

qinshi

图7

现在我们想象一个寝室变成了一台物理机Hypervisor，所有的电脑都变成了虚拟机，就成了下面的样子。

single node

图8

我们先忽略qbr和DHCP Server，以及namespace。

br-int就是寝室里面的HUB，所有虚拟机都会连接到这个switch上，虚拟机之间的相互通信就是通过br-int来的。

Router就是你们寝室长的电脑，一边接在br-int上，一边接在对外的网口上，br-ex/eth0外面就是我们的物理网络。

为什么会有个DHCP Server呢，是同一个private network里的虚拟机得到IP都是通过这个DHCP Server来的，这个DHCP Server也是连接到br-int上和虚拟机进行通信。

为什么会有qbr呢，这是和security group的概念有关，openstack中的security group开通哪些端口，屏蔽哪些端口是用iptables来实现的，然而br-int这些虚拟bridge都是openvswitch创建的，openvswitch的kernel mode和netfilter的kernel mode不兼容，一个IP包进来要么走iptables的规则进行处理，要么走openvswitch的规则进行处理，通过上面的复杂的图我们可以看到，br-int上面有很多openvswitch的规则，比如vlan tag等，所以iptables必须要另外建立一个linux bridge来做，因而有了qbr，在了解拓扑结构的时候，可以将qbr忽略，看成VM直接连接到br-int上就可以了。

为什么会有namespace呢，java的namespace是为了相同的类名，不同的namespace，显然是不同的类。openstack也想做到这一点，不同的tenant都想创建自己的router和private network，彼此不知道别人指定了哪些网段，很有可能两个tenant都指定了192.168.0.0/24，这样不同的private network的路由表，DHCP Server就需要隔离，不然就乱了，因而有了namespace。

上面的图其实就是单节点的openstack的网络结构，虽然复杂，但是就是把我们家里的，或者寝室里面的物理机搬到一个Hypervisor上了，其结构就不难理解了。

当然单节点的openstack不过是个测试环境，compute节点和network节点也是要分开的，如图4，每个机器上都有了自己的br-int。

但是对于虚拟机和虚拟Router来讲，他们仍然觉得他们是连接到了一个大的L2的br-int上，通过这个br-int相互通信的，他们感受不到br-int下面的虚拟网卡br-tun。所以对于多节点结构，我们可以想象br-int是一个大的，横跨所有的compute和network节点的二层switch，虚拟机之间的通信以及虚拟机和Router的通信，就像在一个寝室一样的。

然而br-int毕竟被物理的割开了，需要有一种方式将他们串联起来，openstack提供了多种方式，图4中是用GRE tunnel将不同机器的br-int连接起来，图5图6是通过VLAN将br-int连接起来，当然还可以使用vxlan。

这就是为什么openstack有了br-int这个bridge，但是不把所有的openvswitch的规则都在它上面实现。就是为了提供这种灵活性，对于虚拟机来讲，看到的是一大整个br-int，不同机器的br-int可以有多种方式连接，这在br-int下面的网卡上面实现。

如果有不同的Tenant，创建了不同的private network，为了在data network上对包进行隔离，创建private network的时候，需要指定vlanid或者segmentid。

从ovs-vsctl show我们可以看到，不同的tenant的private network上创建的虚拟机，连接到br-int上的时候是带tag的，所以不同tenant的虚拟机，即便连接到同一个br-int上，因为tag不同，也是不能相互通信的，然而同一个机器上的tag的计数是仅在本机有效的，并不使用我们创建private network的时候指定的全局唯一的vlanid或者segmentid，一个compute节点上的br-int上的tag 1和另一台compute节点上的br-int的tag1很可能是两码事。全局的vlanid和segmentid仅仅在br-int以下的虚拟网卡和物理网络中使用，虚拟机所有能看到的东西，到br-int为止，看不到打通br-int所要使用的vlanid和segmentid。

从局部有效的taging到全局有效的vlanid或者segmentid的转换，都是通过openvswitch的规则，在br-tun或者br-eth1上实现。

我们可以用下面的命令看一下这个规则:

在Compute节点上：

private network “openstack-net”的tag在这台机器上是2，而我们创建的时候的segmentid设定的是1

Bridge br-int
    Port patch-tun
        Interface patch-tun
            type: patch
            options: {peer=patch-int}
    Port br-int
        Interface br-int
            type: internal
    Port "qvo591d8cc4-df"
        tag: 2
        Interface "qvo591d8cc4-df"

root@ComputeNodeCliu8:~# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):

//in_port=1是指包是从patch-int，也即是从虚拟机来的，所以是发送规则，跳转到table1
cookie=0x0, duration=77419.191s, table=0, n_packets=22, n_bytes=2136, idle_age=6862, hard_age=65534, priority=1,in_port=1 actions=resubmit(,1)

//in_port=2是指包是从GRE来的，也即是从物理网络来的，所以是接收规则，跳转到table2
cookie=0x0, duration=77402.19s, table=0, n_packets=3, n_bytes=778, idle_age=6867, hard_age=65534, priority=1,in_port=2 actions=resubmit(,2)
cookie=0x0, duration=77418.403s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

//multicast，跳转到table21
cookie=0x0, duration=77416.63s, table=1, n_packets=21, n_bytes=2094, idle_age=6862, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21)

//broadcast，跳转到table 20
cookie=0x0, duration=77417.389s, table=1, n_packets=1, n_bytes=42, idle_age=6867, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)

//这是接收规则的延续，如果接收的tun_id=0x1则转换为本地的tag，mod_vlan_vid:2，跳转到table 10
cookie=0x0, duration=6882.254s, table=2, n_packets=3, n_bytes=778, idle_age=6867, priority=1,tun_id=0x1 actions=mod_vlan_vid:2,resubmit(,10)

cookie=0x0, duration=77415.638s, table=2, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

cookie=0x0, duration=77414.432s, table=3, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

cookie=0x0, duration=77412.825s, table=10, n_packets=3, n_bytes=778, idle_age=6867, hard_age=65534, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1

cookie=0x0, duration=77411.549s, table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,21)

//这是发送规则的延续，如果接收到的dl_vlan=2，则转换为物理网络的segmentid=1，set_tunnel:0x1
cookie=0x0, duration=6883.119s, table=21, n_packets=10, n_bytes=1264, idle_age=6862, priority=1,dl_vlan=2 actions=strip_vlan,set_tunnel:0x1,output:2

cookie=0x0, duration=77410.56s, table=21, n_packets=11, n_bytes=830, idle_age=6885, hard_age=65534, priority=0 actions=drop

在Network节点上：

Bridge br-int
    Port patch-tun
        Interface patch-tun
            type: patch
            options: {peer=patch-int}
    Port "tapde5739e1-95"
        tag: 1
        Interface "tapde5739e1-95"
            type: internal
    Port br-int
        Interface br-int
            type: internal
    Port "qr-e8b97930-ac"
        tag: 1
        Interface "qr-e8b97930-ac"
            type: internal

非常相似的规则。

root@NetworkNodeCliu8:~# ovs-ofctl dump-flows br-tun
NXST_FLOW reply (xid=0x4):

//in_port=1是指包是从patch-int，也即是从虚拟机来的，所以是发送规则，跳转到table1
cookie=0x0, duration=73932.142s, table=0, n_packets=12, n_bytes=1476, idle_age=3380, hard_age=65534, priority=1,in_port=1 actions=resubmit(,1)

//in_port=2是指包是从GRE来的，也即是从物理网络来的，所以是接收规则，跳转到table2
cookie=0x0, duration=73914.323s, table=0, n_packets=9, n_bytes=1166, idle_age=3376, hard_age=65534, priority=1,in_port=2 actions=resubmit(,2)

cookie=0x0, duration=73930.934s, table=0, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

//multicast，跳转到table21
cookie=0x0, duration=73928.59s, table=1, n_packets=6, n_bytes=468, idle_age=65534, hard_age=65534, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21)

//broadcast，跳转到table20
cookie=0x0, duration=73929.695s, table=1, n_packets=3, n_bytes=778, idle_age=3380, hard_age=65534, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)

//这是接收规则的延续，如果接收的tun_id=0x1则转换为本地的tag，mod_vlan_vid:1，跳转到table 10
cookie=0x0, duration=73906.864s, table=2, n_packets=9, n_bytes=1166, idle_age=3376, hard_age=65534, priority=1,tun_id=0x1 actions=mod_vlan_vid:1,resubmit(,10)

cookie=0x0, duration=73927.542s, table=2, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

cookie=0x0, duration=73926.403s, table=3, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=drop

cookie=0x0, duration=73925.611s, table=10, n_packets=9, n_bytes=1166, idle_age=3376, hard_age=65534, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1

cookie=0x0, duration=73924.858s, table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=0 actions=resubmit(,21)

//这是发送规则的延续，如果接收到的dl_vlan=1，则转换为物理网络的segmentid=1，set_tunnel:0x1
cookie=0x0, duration=73907.657s, table=21, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=1,dl_vlan=1 actions=strip_vlan,set_tunnel:0x1,output:2

cookie=0x0, duration=73924.117s, table=21, n_packets=6, n_bytes=468, idle_age=65534, hard_age=65534, priority=0 actions=drop

声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉：投诉/举报工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。

联系
我们

首页 > 代码库 > neutron的基本原理

neutron的基本原理

看完仍有疑问？有类似问题直接问程序猿