Mininet安装与使用问题

安装

# 升级pip3,避免后续安装报错吗，高版本的pip放弃了对2.7和3.5版本的支持，因此需要降级
wget https://bootstrap.pypa.io/pip/3.5/get-pip.py
python3 get-pip.py 

git clone git://github.com/mininet/mininet
cd mininet 
git tag # list available versions
git checkout -b mininet-2.3.0 2.3.0 # 
cd ..

mininet/util/install.sh -s mydir -a

mininet/util/install.sh [options]
    -a 全部安装
    -nfv 仅安装mininet, OpenFlow, OVS
    -s mydir 将source/build放在指定目录

指定python版本

Mininet 2.3.0 及更高版本支持 Python 3 和 Python 2

sudo PYTHON=python2 mininet/util/install.sh -n   # install Python 2 Mininet
sudo PYTHON=python3 mininet/util/install.sh -n   # install Python 3 Mininet

查看mininet对应的python版本

echo py sys.version | sudo mn -v output
    mininet> 3.5.2 (default, Jan 26 2021, 13:30:48)
    [GCC 5.4.0 20160609]
    mininet>

可能存在的报错

通过mininet面板设计拓扑，保存为py脚本时会报错，如下所示：

mininet> Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.5/tkinter/__init__.py", line 1553, in __call__
    return self.func(*args)
  File "miniedit.py", line 1707, in exportScript
    f.write("#!/usr/bin/env python\n")
TypeError: a bytes-like object is required, not 'str'

只需修改miniedit.py脚本的第1702行，f=open(“fileName”,”wb”) 改成 f=open(“fileName”,”w”)

连接远程控制器，没有流表

初次安装使用mininet启动基本拓扑，都会生成默认流表，网络时全连通的。但在后续的使用过程中，对流表进行添加、删除等操作，会导致再次启动新的默认网络拓扑不再有默认的全连通网络。此时，需要手动添加

## 为所有交换机添加端口1和端口2的操作---两个交换机公共操作
dpctl add-flow in_port=1,actions=output:2　　
dpctl add-flow in_port=2,actions=output:1
## 为交换机之间端口提供交互---只操作s1(因为只有s1有端口3)
sh ovs-ofctl add-flow s1 in_port=1,actions=output:2,3
sh ovs-ofctl add-flow s1 in_port=3,actions=output:1,2
sh ovs-ofctl add-flow s1 in_port=2,actions=output:1,3
## mininet命令
mininet> dpctl add-flow in_port=1,actions=output:2,3
mininet> dpctl add-flow in_port=2,actions=output:1,3
mininet> dpctl add-flow in_port=3,actions=output:1,2

## 为交换机2添加丢弃流表，使得两个交换机不可通信（在前面互通基础上实现）
mininet> sh ovs-ofctl del-flows s2 in_port=1　　删除原有流表
mininet> sh ovs-ofctl add-flow s2 in_port=1,actions=drop　　添加丢弃流表

MININET OpenFlow13协议支持问题

Steps to Reproduce:

• set OpenFlow protocol to 1.3 on bridge br0 (done during boot in OpenShift)

# ovs-vsctl set bridge br0 protocols=OpenFlow13
# sudo mn --switch=ovs,protocols=OpenFlow13 # 启动网络之前提前设置协议参数

• try to dump flows

# ovs-ofctl dump-flows br0

## 报错
Actual results:
2015-11-04T17:45:56Z|00001|vconn|WARN|unix:/var/run/openvswitch/br0.mgmt: version negotiation failed (we support version 0x01, peer supports version 0x04)
ovs-ofctl: br0: failed to connect to socket (Broken pipe)

Expected results:
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0x0, duration=1299.155s, table=0, n_packets=0, n_bytes=0, dl_src=01:00:00:00:00:00/01:00:00:00:00:00 actions=drop
 ...

Additional info:
this currently works when specifying the version

# ovs-ofctl dump-flows br0 --protocols=OpenFlow13

原因：

ovs-ofctl allows you to set many protocols on the command line, like –protocols=OpenFlow10,OpenFlow13.

That will work for bridges that only support OpenFlow13.

The problem with using any version by default is that mod-flow has different semantics depending on the version. So, instead of behaving differently whenever you use ovs-ofctl mod-flow, the tool defaults to OpenFlow10 only.

Why not use an alias like ovs-ofctl13=’ovs-ofctl –protocols=OpenFlow13’?

个人总结：即使采用 mn –protocols=OpenFlow10,OpenFlow13 这种方式也会出现上述报错问。可以先不指定协议直接启动一个网络拓扑，此时OpenFlow协议默认的1.0。然后再mininet命令行中输入命令进行协议修改，如： mininet> dpctl dump-flows -O OpenFlow13 。