投稿
  1. 首页
  2. IT百科

ovs patch端口实现原理

爱ab • 2023-4-12 • IT百科 • 阅读 14

ovs patch端口实现原理,第1张

ovs的patch端口，用于连接两个网桥，命令如下

添加端口时，会先后调用 port_construct 和 port_add，下面看一下这两个函数对于patch端口的特殊处理

a. port_construct

b. port_add

如果是patch类型端口，不会将其添加到datapath中，所以通过 ovs-appctl dpctl/show 是看不到patch端口的

br10和br12必须在同一个datapath，否则寻找peer就会失败，ofport->peer就会为空，后面数据转发时也不会从peer设备发出。

假如出端口为patch port，流程如下：

最后会将流表和action安装到datapath中，指导后续报文转发。

下面做一个小实验，拓扑图如下:

创建三个网桥br10,br11和br12，其中br10和br12为netdev类型，br11为system类型。

br10和br11通过patch端口patch1/patch2相连接，br10和br12通过patch端口patch3/patch4相连接。

br10上还添加了一个物理网卡enp129s0f0，其直连的网卡enp129s0f1配置ip地址2.2.2.2/24。

结论：

a. patch端口只存在网桥上，datapath中不会存在

b. 如果出端口为patch端口，则相当于其peer设备收到报文，在peer设备所在网桥查找openflow流表进行转发

c. 不同类型datapath的网桥不能通过patch端口相连接

本文主要是在（一）的基础上，熟悉平台 *** 作，以及通过抓包来分析OF协议，在分析之前，最好是读读OF的标准。

因为本环境的软件只支持OF1.0，对于OF1.1 1.2我会在稍后用其他平台测试。

另外，接下来要做的就是对floodlight的深入学习以及mininet的学习。

下一步会尝试多Switch以及多controller的架构。

一 按照(一)中搭建好平台。

ssh进入VM，启动支持OF的wireshark

ssh进入VM，待用，dpctl的使用不需要在vm中，在用户空间就可以使用的，所以保留这个ssh以

作为dpctl使用。

1）创建拓扑

sudo mn –topo single,3 –switch ovsk –controller=remote ip=<controller ip>–port=6633

此时整个网络结构如下：

这是OF手册的图，与这不同的就是controller是远程的，而不是通过loopback接口的。

2）启动VM端的wireshark。

ssh -X root@VM-IP

wireshark &

3）查看网络情况

dpctl show tcp:127.0.0.1:6634

dpctl dump-flows tcp:127.0.0.1:6634

可以看到当前OF交换机的能力，此时才启动，流表为空：

root@localhost:~# dpctl show tcp:127.0.0.1:6634

features_reply (xid=0x31bed0e2): ver:0×1, dpid:1

n_tables:2, n_buffers:256

features: capabilities:0×87, actions:0xfff

1(s1-eth1): addr:5e:a5:4e:d7:06:43, config: 0, state:0

current: 10GB-FD COPPER

2(s1-eth2): addr:7a:5b:5e:61:24:b4, config: 0, state:0

current: 10GB-FD COPPER

3(s1-eth3): addr:ce:99:72:1f:e5:61, config: 0, state:0

current: 10GB-FD COPPER

LOCAL(dp0): addr:00:23:20:e8:64:b4, config: 0×1, state:0×1

get_config_reply (xid=0x7cff1d2e): miss_send_len=0

root@localhost:~# dpctl dump-flows tcp:127.0.0.1:6634

stats_reply (xid=0xb36de55d): flags=none type=1(flow)

4) 查看Floodlight端的启动信息

——————–

09:44:01.116 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.restserver.RestApiServer

09:44:01.117 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.learningswitch.LearningSwitch #floodlight控制交换机为自学习交换机

09:44:01.118 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.hub.Hub#floodlight控制交换机为HUB

09:44:01.119 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.jython.JythonDebugInterface

———————

09:44:01.183 [main] INFO n.f.core.internal.Controller – OpenFlow port set to 6633

09:44:01.183 [main] INFO n.f.core.internal.Controller – Number of worker threads set to 0

09:44:01.184 [main] INFO n.f.core.internal.Controller – ControllerId set to localhost

09:44:01.184 [main] INFO n.f.core.internal.Controller – Controller roles set to null

#controller的角色，难道floodlight支持多controller，这是OF1.2里增加的。

———————

09:44:01.420 [main] DEBUG n.f.restserver.RestApiServer – REST API routables: StorageWebRoutable (/wm/storage), StaticFlowEntryWebRoutable (/wm/staticflowentrypusher), PerfWebRoutable (/wm/performance), StaticWebRoutable (/ui/), CoreWebRoutable (/wm/core), DeviceRoutable (/wm/device), TopologyWebRoutable (/wm/topology)

#REST API支持

———————

09:44:02.127 [main] INFO n.f.core.internal.Controller – Listening for switch connections on 0.0.0.0/0.0.0.0:6633

———————

09:46:21.106 [New I/O server worker #1-2] INFO n.f.core.internal.Controller – New switch connection from /192.168.1.141:35414

09:46:21.108 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – HELLO from OFSwitchImpl [/192.168.1.141:35414 DPID[?]]

09:46:21.110 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – Features Reply from OFSwitchImpl [/192.168.1.141:35414 DPID[?]]

09:46:21.121 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – Config Reply from OFSwitchImpl [/192.168.1.141:35414 DPID[00:00:00:00:00:00:00:01]] confirms miss length set to 0xffff

09:46:21.124 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – This controller’s role is null, not sending role request msg to null

#controller和switch端的交互流程。

二 协议分析：通过分析wireshark的包，我们来梳理OF流程。

1）C-S的初始化

在frame中看到：协议的封装格式是〔Protocols in frame: eth:ip:tcp:of〕

也就是说，OpenFlow Protocol在应用中是在传输层以上，也就是应用层解析的。

首先是初始话，发送hello信息，并协商使用OF协议的版本号。

2）能力请求响应

OFS回应能力请求响应，返回本S的一些设置。包括交换机能力以及接口信息，如下：

3) config回应，回应配置信息，主要包括接口配置等等。

4）stats回应，主要是交换机stats

5）flow_mod涉及到流项的匹配信息等。这个flow_mod的作用我还要查查。

可以看到flow match的匹配项。

6）后续流程，涉及到packet_in,packet_out之类。

在这部分流程中，发现有些时候整个OF消息还携带了一个MAC帧，应该是和当流表无匹配时将包发给controller决策的思想。（到底是包头还是整个，再看看）

以上几种消息类型，可以参照下图：

三 后续

在VM的shh中，添加流表：

sudo dpctl add-flow tcp:127.0.0.1:6634 in_port=2,idle_timeout=360,actions=output:3

然后通过前后mininet中执行pingall来看看流表带来的影响。

同时，可以进如floodlight的web界面看看情况。

本文主要是在（一）的基础上，熟悉 *** 作，以及通过抓包来分析OF协议，在分析之前，最好是读读OF的标准。

因为本环境的只支持OF1.0，对于OF1.1 1.2我会在稍后用其他测试。

另外，接下来要做的就是对floodlight的深入学习以及mininet的学习。

下一步会尝试多Switch以及多controller的架构。

一 按照(一)中搭建好。

ssh进入VM，启动支持OF的wireshark

ssh进入VM，待用，dpctl的使用不需要在vm中，在用户空间就可以使用的，所以保留这个ssh以

作为dpctl使用。

1）创建拓扑

sudo mn –topo single,3 –switch ovsk –controller=remote ip=<controller ip>–port=6633

此时整个网络结构如下：

这是OF手册的图，与这不同的就是controller是远程的，而不是通过loopback接口的。

2）启动VM端的wireshark。

ssh -X root@VM-IP

wireshark

3）查看网络情况

dpctl show tcp:127.0.0.1:6634

dpctl dump-flows tcp:127.0.0.1:6634

可以看到当前OF交换机的能力，此时才启动，流表为空：

root@localhost:~# dpctl show tcp:127.0.0.1:6634

features_reply (xid=0x31bed0e2): ver:0×1, dpid:1

n_tables:2, n_buffers:256

features: capabilities:0×87, actions:0xfff

1(s1-eth1): addr:5e:a5:4e:d7:06:43, config: 0, state:0

current: 10GB-FD COPPER

2(s1-eth2): addr:7a:5b:5e:61:24:b4, config: 0, state:0

current: 10GB-FD COPPER

3(s1-eth3): addr:ce:99:72:1f:e5:61, config: 0, state:0

current: 10GB-FD COPPER

LOCAL(dp0): addr:00:23:20:e8:64:b4, config: 0×1, state:0×1

get_config_reply (xid=0x7cff1d2e): miss_send_len=0

root@localhost:~# dpctl dump-flows tcp:127.0.0.1:6634

stats_reply (xid=0xb36de55d): flags=none type=1(flow)

4) 查看Floodlight端的启动信息

——————–

09:44:01.116 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.restserver.RestApiServer

09:44:01.117 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.learningswitch.LearningSwitch #floodlight控制交换机为自学习交换机

09:44:01.118 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.hub.Hub#floodlight控制交换机为HUB

09:44:01.119 [main] DEBUG n.f.c.module.FloodlightModuleLoader – Found module net.floodlightcontroller.jython.JythonDebugInterface

———————

09:44:01.183 [main] INFO n.f.core.internal.Controller – OpenFlow port set to 6633

09:44:01.183 [main] INFO n.f.core.internal.Controller – Number of worker threads set to 0

09:44:01.184 [main] INFO n.f.core.internal.Controller – ControllerId set to localhost

09:44:01.184 [main] INFO n.f.core.internal.Controller – Controller roles set to null

#controller的角色，难道floodlight支持多controller，这是OF1.2里增加的。

———————

09:44:01.420 [main] DEBUG n.f.restserver.RestApiServer – REST API routables: StorageWebRoutable (/wm/storage), StaticFlowEntryWebRoutable (/wm/staticflowentrypusher), PerfWebRoutable (/wm/performance), StaticWebRoutable (/ui/), CoreWebRoutable (/wm/core), DeviceRoutable (/wm/device), TopologyWebRoutable (/wm/topology)

#REST API支持

———————

09:44:02.127 [main] INFO n.f.core.internal.Controller – Listening for switch connections on 0.0.0.0/0.0.0.0:6633

———————

09:46:21.106 [New I/O server worker #1-2] INFO n.f.core.internal.Controller – New switch connection from /192.168.1.141:35414

09:46:21.108 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – HELLO from OFSwitchImpl [/192.168.1.141:35414 DPID[?]]

09:46:21.110 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – Features Reply from OFSwitchImpl [/192.168.1.141:35414 DPID[?]]

09:46:21.121 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – Config Reply from OFSwitchImpl [/192.168.1.141:35414 DPID[00:00:00:00:00:00:00:01]] confirms miss length set to 0xffff

09:46:21.124 [New I/O server worker #1-2] DEBUG n.f.core.internal.Controller – This controller’s role is null, not sending role request msg to null

#controller和switch端的交互流程。

二 协议分析：通过分析wireshark的包，我们来梳理OF流程。

1）C-S的初始化

在frame中看到：协议的封装格式是〔Protocols in frame: eth:ip:tcp:of〕

也就是说，OpenFlow Protocol在应用中是在传输层以上，也就是应用层解析的。

首先是初始话，发送hello信息，并协商使用OF协议的版本号。

2）能力请求响应

OFS回应能力请求响应，返回本S的一些设置。包括交换机能力以及接口信息，如下：

3) config回应，回应配置信息，主要包括接口配置等等。

4）stats回应，主要是交换机stats

5）flow_mod涉及到流项的匹配信息等。这个flow_mod的作用我还要查查。

可以看到flow match的匹配项。

6）后续流程，涉及到packet_in,packet_out之类。

在这部分流程中，发现有些时候整个OF消息还携带了一个MAC帧，应该是和当流表无匹配时将包发给controller决策的思想。（到底是包头还是整个，再看看）

以上几种消息类型，可以参照下图：

三 后续

在VM的shh中，添加流表：

sudo dpctl add-flow tcp:127.0.0.1:6634 in_port=2,idle_timeout=360,actions=output:3

然后通过前后mininet中执行pingall来看看流表带来的影响。

同时，可以进如floodlight的web界面看看情况。

欢迎分享，转载请注明来源：内存溢出

原文地址: http://outofmemory.cn/bake/7960301.html

赞 (0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
爱ab 爱ab 一级用户组
0 0
上一篇 2023-04-12
下一篇 2023-04-12

发表评论

登录后才能评论

评论列表（0条）

保存