qos_project
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
qos_project [2017/11/23 15:19] – [5. [CO1] Connecting the Platform] enwan | qos_project [2017/12/03 13:05] – [1. Hardware] samer | ||
---|---|---|---|
Line 12: | Line 12: | ||
- | [{{ :tp-link.jpg? | + | [{{ :glinet.jpg? |
- | + | ||
- | [{{ :glinet.jpg? | + | |
===== -. Software ===== | ===== -. Software ===== | ||
Line 75: | Line 73: | ||
| | ||
</ | </ | ||
- | Routing | + | |
+ | In order to analyse the addressing and routing on the platform, we need to look carefully on the interface configuration and routing tables of the different devices. | ||
+ | |||
+ | Let us start with the routing devices. The routing | ||
<code bash> | <code bash> | ||
- | 10.0.0.0/24 dev eth0 proto kernel | + | 10.0.0.0/24 dev eth0 proto kernel |
192.168.8.0/ | 192.168.8.0/ | ||
- | 192.168.100.0/ | + | 192.168.100.0/ |
192.168.200.0/ | 192.168.200.0/ | ||
10.0.0.2 of the TP-LINK router | 10.0.0.2 of the TP-LINK router | ||
</ | </ | ||
+ | |||
+ | Similarly, the routing table of the TP-LINK router shows the following: | ||
<code bash> | <code bash> | ||
- | |||
- | Routing table of GL-iNet: | ||
- | |||
10.0.0.0/24 dev eth1 src 10.0.0.2 # connection to directly connected network 10.0.0.0/24 | 10.0.0.0/24 dev eth1 src 10.0.0.2 # connection to directly connected network 10.0.0.0/24 | ||
192.168.100.0/ | 192.168.100.0/ | ||
10.0.0.1 of the GL-iNet router | 10.0.0.1 of the GL-iNet router | ||
192.168.200.0/ | 192.168.200.0/ | ||
- | |||
</ | </ | ||
- | <code bash> | + | We note on the two routers that static routes are used in order to give access to the two LANs. Particularly, |
- | + | ||
- | # | + | |
- | + | ||
- | # | + | |
+ | As given below, the configuration of the TP-Link router shows the static addressing of the interface '' | ||
+ | |||
+ | <file bash / | ||
+ | # | ||
config interface ' | config interface ' | ||
option type ' | option type ' | ||
Line 110: | Line 109: | ||
option ip6assign ' | option ip6assign ' | ||
| | ||
- | # | + | # |
config interface ' | config interface ' | ||
option ifname ' | option ifname ' | ||
Line 126: | Line 124: | ||
option netmask ' | option netmask ' | ||
option gateway ' | option gateway ' | ||
+ | </ | ||
+ | Similarly, the configuration of the GL-iNET router below shows the following: | ||
+ | * The WiFi interface is configured with a static IP address 192.168.8.1/ | ||
+ | * The WAN interface is configured with a static IP address 10.0.0.1/24 | ||
+ | * A static route enables GL-iNET to reach the network 192.168.200.0/ | ||
+ | |||
+ | <file bash / | ||
+ | config interface ' | ||
+ | option force_link ' | ||
+ | option proto ' | ||
+ | option ipaddr ' | ||
+ | option netmask ' | ||
+ | option ip6assign ' | ||
+ | option _orig_ifname ' | ||
+ | option _orig_bridge ' | ||
+ | |||
+ | config interface ' | ||
+ | option ifname ' | ||
+ | option hostname ' | ||
+ | option proto ' | ||
+ | option ipaddr ' | ||
+ | option netmask ' | ||
+ | |||
+ | config route | ||
+ | option interface ' | ||
+ | option target ' | ||
+ | option netmask ' | ||
+ | option gateway ' | ||
+ | |||
+ | </ | ||
+ | |||
+ | The two routers allocate IP addresses using DHCP. In order to facilitate the usage of the platform, fixed allocations are configured for the end hosts. This is configured in ''/ | ||
+ | |||
+ | <file / | ||
+ | config dhcp ' | ||
+ | option interface ' | ||
+ | option start ' | ||
+ | option limit ' | ||
+ | option leasetime ' | ||
+ | option dhcpv6 ' | ||
+ | option ra ' | ||
+ | |||
+ | config host | ||
+ | option name ' | ||
+ | option mac ' | ||
+ | option ip ' | ||
+ | |||
+ | config host | ||
+ | option name ' | ||
+ | option mac ' | ||
+ | option ip ' | ||
+ | </ | ||
+ | |||
+ | Finally, we verify the routing and addressing on the Raspberry Pi devices using '' | ||
+ | |||
+ | <code bash> | ||
+ | pi@raspberrypi: | ||
+ | eth0 Link encap: | ||
+ | inet addr: | ||
+ | inet6 addr: fdd5: | ||
+ | inet6 addr: fe80:: | ||
+ | inet6 addr: fdd5: | ||
+ | UP BROADCAST RUNNING MULTICAST | ||
+ | RX packets: | ||
+ | TX packets:983 errors:0 dropped:0 overruns:0 carrier:0 | ||
+ | collisions: | ||
+ | RX bytes: | ||
</ | </ | ||
+ | |||
+ | <code bash> | ||
+ | pi@raspberrypi: | ||
+ | default via 192.168.200.1 dev eth0 metric 202 | ||
+ | 192.168.200.0/ | ||
+ | </ | ||
+ | ===== -. [CO2] Implementing the Applications and Tools ===== | ||
+ | |||
+ | <WRAP center round info 100%> | ||
+ | * Accomplished | ||
+ | * Using the tools to obtain performance results of basic tests | ||
+ | * Wiki tutorial on the tools and applications | ||
+ | * Exceeded | ||
+ | * Installing tools on a new device | ||
+ | </ | ||
+ | |||
+ | In order to describe and analyze the basic steps for installing and using the tools and client/ | ||
+ | ==== -. iperf tool ==== | ||
+ | |||
+ | Let us start with the application iperf. In the following, we present a short tutorial on the main functions of the perf tool. | ||
+ | |||
+ | * To launch iperf3: | ||
+ | * On the server side: '' | ||
+ | * On the client side: '' | ||
+ | |||
+ | * By default, the trafic sent by iperf uses TCP. In order to send UDP trafic with a specific bandwidth: | ||
+ | * On the client side: iperf3 -c 192.168.200.192 -u -b 2M | ||
+ | |||
+ | Here we set the bandwidth with UDP to 2Mbit/s. Note that by default, UDP sets the bandwidth to 1Mbit/s. | ||
+ | |||
+ | * To extend the transmission time(second) as well as the number packets sent: | ||
+ | * On the Client side: '' | ||
+ | |||
+ | Note that by default, iperf3 sets the time to 10 seconds. | ||
+ | |||
+ | * To use reverse mode (server sends the trafic and client receives): | ||
+ | * On the Client side: '' | ||
+ | |||
+ | * To send multiple flows: | ||
+ | * On the Client side: '' | ||
+ | |||
+ | Here we are sending two flows for one minute (60 seconds). We note that the average rate for the two flows can be different. However, this is not a fairness issue: we only need to extend the transmit time in order to have similar throughput for the two flows. | ||
+ | |||
+ | ==== -. Flent Tool ==== | ||
+ | |||
+ | Let us now analyze [[ https:// | ||
+ | |||
+ | * On the Server side: '' | ||
+ | * To sent one TCP stream from the client to the server: | ||
+ | * On the Client side: '' | ||
+ | * To send 12 TCP streams: | ||
+ | * On the Client side: '' | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
qos_project.txt · Last modified: 2021/08/28 09:58 by samer