Интерфейс принимает пакеты, приложение `iperf` НЕ получает пакеты и не работает - PullRequest
0 голосов
/ 12 июня 2019

Я использую 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)
...