如何解决你如何模拟Mininet中UDP泛洪造成的丢包?
明确地说,我对在链接上添加持续丢包不感兴趣(如 this Stack Overflow question 所述)。我想观察由于拥塞而在网络中自然发生的丢包。
我的项目的目的是通过改变路由器节点上的 qdisc 缓冲区大小来观察网络(最好是 SDN)中发生的数据包丢失和延迟。我有一个连接到路由器 r 的三个节点 h1、h2 和 h3 的基本拓扑。我正在按照 this tutorial taking place inside a custom environment 的思路进行我的实验。我的代码如下所示:
DELAY='110ms' # r--h3 link
BBR=False
import sys
import shelve
import os
import re
import numpy as np
import matplotlib.pyplot as plt
from mininet.term import makeTerm
from mininet.net import Mininet
from mininet.node import Node,OVSKernelSwitch,Controller,RemoteController
from mininet.cli import CLI
from mininet.link import TCLink
from mininet.topo import Topo
from mininet.log import setLogLevel,info
import time
class LinuxRouter( Node ):
"A Node with IP forwarding enabled."
def config( self,**params ):
super( LinuxRouter,self).config( **params )
# Enable forwarding on the router
info ('enabling forwarding on ',self)
self.cmd( 'sysctl net.ipv4.ip_forward=1' )
def terminate( self ):
self.cmd( 'sysctl net.ipv4.ip_forward=0' )
super( LinuxRouter,self ).terminate()
class RTopo(Topo):
def build(self,**_opts):
defaultIP = '10.0.1.1/24' # IP address for r0-eth1
r = self.addNode( 'r',cls=LinuxRouter) #,ip=defaultIP )
h1 = self.addHost( 'h1',ip='10.0.1.10/24',defaultRoute='via 10.0.1.1' )
h2 = self.addHost( 'h2',ip='10.0.2.10/24',defaultRoute='via 10.0.2.1' )
h3 = self.addHost( 'h3',ip='10.0.3.10/24',defaultRoute='via 10.0.3.1' )
self.addLink( h1,r,intfName1 = 'h1-eth',intfName2 = 'r-eth1',bw=80,params2 = {'ip' : '10.0.1.1/24'})
self.addLink( h2,intfName1 = 'h2-eth',intfName2 = 'r-eth2',params2 = {'ip' : '10.0.2.1/24'})
.
self.addLink( h3,intfName1 = 'h3-eth',intfName2 = 'r-eth3',params2 = {'ip' : '10.0.3.1/24'},delay=DELAY,queue=QUEUE) # apparently queue is IGnorED here.
def main():
rtopo = RTopo()
net = Mininet(topo = rtopo,link=TCLink,#switch = OVSKernelSwitch,# ~ controller = RemoteController,autoSetMacs = True # --mac
)
net.start()
r = net['r']
r.cmd('ip route list');
# r's IPv4 addresses are set here,not above.
r.cmd('ifconfig r-eth1 10.0.1.1/24')
r.cmd('ifconfig r-eth2 10.0.2.1/24')
r.cmd('ifconfig r-eth3 10.0.3.1/24')
r.cmd('sysctl net.ipv4.ip_forward=1')
h1 = net['h1']
h2 = net['h2']
h3 = net['h3']
h3.cmdPrint("iperf -s -u -i 1 &")
r.cmdPrint("tc qdisc del dev r-eth3 root")
bsizes = []
bsizes.extend(["1000mb","10mb","5mb","1mb","200kb"])
bsizes.extend(["100kb","50kb","10kb","5kb","1kb","100b"])
pdrops = []
delays = []
init = 1
pdrop_re = re.compile(r'(\d+)% packet loss')
delay_re = re.compile(r'rtt min/avg/max/mdev = (\d+).(\d+)/(\d+).(\d+)/(\d+).(\d+)/(\d+).(\d+) ms')
bsizes.reverse()
for bsize in bsizes:
if init:
init = 0
routercmd = "sudo tc qdisc add dev r-eth3 root tbf rate 18mbit limit {} burst 10kb".format(bsize)
else:
routercmd = "sudo tc qdisc replace dev r-eth3 root tbf rate 18mbit limit {} burst 10kb".format(bsize)
r.cmdPrint(routercmd)
h1.cmd("iperf -c 10.0.3.10 -u -b 20mb -t 30 -i 1 >>a1.txt &")
h2.cmd("ping 10.0.3.10 -c 30 >> a2.txt")
print("Sleeping 30 seconds")
time.sleep(30)
#Below is the code to analyse delay and packet dropdata
f1 = open("a2.txt",'r')
s = f1.read()
f1.close()
l1 = pdrop_re.findall(s)
pdrop = l1[-1][0]
pdrops.append(int(pdrop))
print("Packet Drop = {}%".format(pdrop))
l2 = delay_re.findall(s)
delay = l2[-1][4] + '.' + l2[-1][5]
delays.append(float(delay))
print("Delay = {} ms".format(delay))
bsizes = np.array(bsizes)
delays = np.array(delays)
pdrops = np.array(pdrops)
plt.figure(0)
plt.plot(bsizes,delays)
plt.title("Delay")
plt.savefig("delay.png")
plt.show()
plt.figure(1)
plt.plot(bsizes,pdrops,'r')
plt.title("Packet Drop %")
plt.savefig("pdrop.png")
plt.show()
for h in [r,h1,h2,h3]: h.cmd('/usr/sbin/sshd')
CLI( net )
net.stop()
setLogLevel('info')
main()
然而,当我运行程序时,只有延迟会随着队列/缓冲区大小的增加而增加。丢包率保持不变(除了最初发生的 3% 丢包率与使用的队列大小无关)。我对此感到困惑,因为从理论上讲,随着缓冲区大小的减小,在队列中“存储”数据包的空间会减少,因此根据教程,数据包被丢弃的机会应该会增加。图表如下所示:
描绘延迟增加的图表:
描绘停滞数据包丢弃的图表:
我需要对这种相反的行为进行解释。我也很感激在我的例子中观察数据包丢失的方法。它是否与 Mininet/SDN 通常优先考虑 ICMP 而非 UDP 数据包有关,从而导致数据包丢失?或者它可能与控制器有关(我使用的是默认的 OpenFlow 控制器)?
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。