Я использую iperf
для проверки пропускной способности двух Docker
контейнеров. Интерфейс, настроенный с помощью ovs-docker
, видел пакеты клиента iperf
. Однако сервер iperf
, похоже, не знает о пакетах и не реагирует.
Настройка моей платформы показана в предыдущем вопросе . Я пошел дальше, чтобы решить проблему. Но все равно не получится. Пожалуйста, поделитесь любой подсказкой для меня.
Сетевая конфигурация двух контейнеров:
box1
состояние сети:
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:03
inet addr:172.17.0.3 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:470 errors:0 dropped:0 overruns:0 frame:0
TX packets:315 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:648279 (648.2 KB) TX bytes:26687 (26.6 KB)
eth1 Link encap:Ethernet HWaddr 92:9c:88:f6:cb:a0
inet addr:173.16.1.3 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3492 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5219001 (5.2 MB) TX bytes:728 (728.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Здесь eth0
подключен к docker0
, а не к OVS. eth1
создается с использованием ovs-docker
и подключается к мосту с именем ovs-br1
.
Статус ovs-br1
:
wcf@wcf-OptiPlex-7060:~/ovs$ sudo ovs-ofctl show ovs-br1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0000de3219b1f549
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
1(001d342f61744_l): addr:32:e7:19:7e:dc:8f
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
2(cb95b3dba5644_l): addr:b2:f3:4b:8e:d6:d7
config: 0
state: 0
current: 10GB-FD COPPER
speed: 10000 Mbps now, 0 Mbps max
LOCAL(ovs-br1): addr:de:32:19:b1:f5:49
config: 0
state: 0
current: 10MB-FD COPPER
speed: 10 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
ovs-br1
config в хост-системе:
wcf@wcf-OptiPlex-7060:~/ovs$ ifconfig ovs-br1
ovs-br1 Link encap:Ethernet HWaddr de:32:19:b1:f5:49
inet addr:173.16.1.1 Bcast:173.16.1.255 Mask:255.255.255.0
inet6 addr: fe80::dc32:19ff:feb1:f549/64 Scope:Link
UP BROADCAST RUNNING PROMISC MTU:1500 Metric:1
RX packets:5 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:342 (342.0 B) TX bytes:732 (732.0 B)
box2
состояние сети:
[ root@ddf06e436b89:~/tcpreplay-4.3.2 ]$ ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:02
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35 errors:0 dropped:0 overruns:0 frame:0
TX packets:128 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6651 (6.6 KB) TX bytes:190596 (190.5 KB)
eth1 Link encap:Ethernet HWaddr e2:2d:e7:e5:ee:5c
inet addr:173.16.1.2 Bcast:0.0.0.0 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:3465 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5458 (5.4 KB) TX bytes:5214474 (5.2 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Является ли iptables
неправильным?
Я думал, заблокирует ли iptables
трафик от 173.16.1.2
(от box1-eth1
). Но, похоже, нет. Я удаляю все iptables
правила и iperf
сервер на box2
все еще не работает.
Статус iptables
в box2
:
[ root@c5cb95fa2ca7:~/tcpreplay-4.3.2 ]$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Is eth1
in box1
получать трафик от box2
Да. Я начинаю с tcpdump
eth1
на box2
и получаю:
[ root@360f58e1ebec:~/tcpreplay-4.3.2 ]$ tcpdump -i eth1 -n -vvv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
05:21:00.108864 IP (tos 0x0, ttl 64, id 21670, offset 0, flags [DF], proto UDP (17), length 1498)
173.16.1.2.37156 > 173.16.1.3.9990: [bad udp cksum 0x61fd -> 0xced0!] UDP, length 1470
05:21:00.111266 IP (tos 0x0, ttl 64, id 21673, offset 0, flags [DF], proto UDP (17), length 1498)
173.16.1.2.37156 > 173.16.1.3.9990: [bad udp cksum 0x61fd -> 0xa065!] UDP, length 1470
05:21:00.123365 IP (tos 0x0, ttl 64, id 21676, offset 0, flags [DF], proto UDP (17), length 1498)
173.16.1.2.37156 > 173.16.1.3.9990: [bad udp cksum 0x61fd -> 0x728f!] UDP, length 1470
05:21:00.134962 IP (tos 0x0, ttl 64, id 21678, offset 0, flags [DF], proto UDP (17), length 1498)
173.16.1.2.37156 > 173.16.1.3.9990: [bad udp cksum 0x61fd -> 0x4437!] UDP, length 1470
05:21:00.146668 IP (tos 0x0, ttl 64, id 21680, offset 0, flags [DF], proto UDP (17), length 1498)
173.16.1.2.37156 > 173.16.1.3.9990: [bad udp cksum 0x61fd -> 0x16a1!] UDP, length 1470
eth1
в box2
наблюдал трафик от box1-eth1
!
Итак, я пытаюсь проверить пропускную способность между box1
и box2
, используя iperf
. Потому что я хочу добавить некоторые новые функции в OVS и повторно протестировать пропускную способность. Однако сервер iperf
не работает в моем случае.
Пожалуйста, поделитесь любой идеей о моей проблеме. Спасибо за ваше время.
С наилучшими пожеланиями.
EDIT
Я позволил серверу iperf
работать. Но у меня все еще есть некоторая путаница.
На этот раз я удаляю datatype_type
порта OVS.
Новая настройка:
sudo ovs-vsctl add-br ovs-br1
Старый Настройка:
sudo ovs-vsctl add-br ovs-br1 -- set bridge ovs-br1 datapath_type=netdev
После удаления datapath_type
все работает нормально.
Мне было интересно, почему datapath_type=netdev
не работает для iperf
?
Вот журнал openvswitch
после создания ovs-br1
и двух docker-ovs
портов с datapath_type=netdev
:
2019-06-13T03:38:33.303Z|00068|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports recirculation
2019-06-13T03:38:33.303Z|00069|ofproto_dpif|INFO|netdev@ovs-netdev: MPLS label stack length probed as 3
2019-06-13T03:38:33.303Z|00070|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports truncate action
2019-06-13T03:38:33.303Z|00071|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports unique flow ids
2019-06-13T03:38:33.303Z|00072|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports ct_state
2019-06-13T03:38:33.303Z|00073|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports ct_zone
2019-06-13T03:38:33.303Z|00074|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports ct_mark
2019-06-13T03:38:33.303Z|00075|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath supports ct_label
2019-06-13T03:38:33.303Z|00076|ofproto_dpif|INFO|netdev@ovs-netdev: Datapath does not support ct_state_nat
2019-06-13T03:38:33.304Z|00077|bridge|INFO|bridge ovs-br1: added interface ovs-br1 on port 65534
2019-06-13T03:38:33.304Z|00078|bridge|INFO|bridge ovs-br1: using datapath ID 00005203106b4948
2019-06-13T03:38:33.304Z|00079|connmgr|INFO|ovs-br1: added service controller "punix:/usr/local/var/run/openvswitch/ovs-br1.mgmt"
2019-06-13T03:38:41.003Z|00080|bridge|INFO|bridge ovs-br1: added interface 1dd6d0d9888a4_l on port 1
2019-06-13T03:38:41.003Z|00081|netdev_linux|WARN|error receiving Ethernet packet on 1dd6d0d9888a4_l: Network is down
2019-06-13T03:38:41.003Z|00082|dpif_netdev|ERR|error receiving data from 1dd6d0d9888a4_l: Network is down
2019-06-13T03:38:41.241Z|00083|bridge|INFO|bridge ovs-br1: added interface 959a4d31f93c4_l on port 2
2019-06-13T03:38:41.241Z|00084|netdev_linux|WARN|error receiving Ethernet packet on 959a4d31f93c4_l: Network is down
2019-06-13T03:38:41.241Z|00085|dpif_netdev|ERR|error receiving data from 959a4d31f93c4_l: Network is down
Вот лог OVS без datapath_type=netdev
:
2019-06-13T03:08:02.488Z|00007|ofproto_dpif|INFO|system@ovs-system: Datapath does not support recirculation
2019-06-13T03:08:02.488Z|00008|ofproto_dpif|INFO|system@ovs-system: MPLS label stack length probed as 0
2019-06-13T03:08:02.488Z|00009|ofproto_dpif|INFO|system@ovs-system: datapath does not support masked set action feature.
2019-06-13T03:08:02.488Z|00010|ofproto_dpif|INFO|system@ovs-system: Datapath does not support truncate action
2019-06-13T03:08:02.488Z|00011|ofproto_dpif|INFO|system@ovs-system: Datapath does not support unique flow ids
2019-06-13T03:08:02.488Z|00012|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_state
2019-06-13T03:08:02.488Z|00013|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_zone
2019-06-13T03:08:02.488Z|00014|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_mark
2019-06-13T03:08:02.488Z|00015|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_label
2019-06-13T03:08:02.488Z|00016|ofproto_dpif|INFO|system@ovs-system: Datapath does not support ct_state_nat
2019-06-13T03:08:02.491Z|00001|ofproto_dpif_upcall(handler1)|INFO|received packet on unassociated datapath port 0
2019-06-13T03:08:02.493Z|00017|bridge|INFO|bridge ovs-br1: added interface ovs-br1 on port 65534
2019-06-13T03:08:02.493Z|00018|bridge|INFO|bridge ovs-br1: using datapath ID 0000bef6ed276749
2019-06-13T03:08:02.493Z|00019|connmgr|INFO|ovs-br1: added service controller "punix:/usr/local/var/run/openvswitch/ovs-br1.mgmt"
2019-06-13T03:08:05.501Z|00020|memory|INFO|8564 kB peak resident set size after 10.1 seconds
2019-06-13T03:08:05.501Z|00021|memory|INFO|handlers:8 ports:1 revalidators:4 rules:5
2019-06-13T03:09:47.238Z|00022|bridge|INFO|bridge ovs-br1: added interface ed03f2fd53694_l on port 1
2019-06-13T03:10:37.665Z|00023|bridge|INFO|bridge ovs-br1: added interface 26d01f8770224_l on port 2
2019-06-13T03:18:47.974Z|00024|bridge|WARN|could not open network device 26d01f8770224_l (No such device)
2019-06-13T03:18:57.645Z|00025|bridge|WARN|could not open network device 26d01f8770224_l (No such device)
2019-06-13T03:18:57.645Z|00026|ofproto|WARN|ovs-br1: cannot get STP status on nonexistent port 1
2019-06-13T03:18:57.645Z|00027|ofproto|WARN|ovs-br1: cannot get RSTP status on nonexistent port 1
2019-06-13T03:18:57.647Z|00028|bridge|WARN|could not open network device 26d01f8770224_l (No such device)
2019-06-13T03:18:57.648Z|00029|bridge|WARN|could not open network device ed03f2fd53694_l (No such device)