Ilya Evseev Posted May 29, 2019 · Report post Дано: два Linux-сервера с ядром 4.15 На каждом запущен LXD с контейнерами. Для прозрачной связи контейнеров интерфейсы lxdbr0 соединены через vxlan или geneve. Проблема: Один из серверов периодически начинает неправильно обрабатывать ICMP-пакеты большого размера (больше 1322 байт): в geneve уходит только пакет со вторым фрагментом, а пакет с первым пропадает между lxdbr0 и geneve. Попытки менять MTU не помогли: ovs-vsctl set int lxdbr0 mtu=1300 ip link set mtu 9000 dev eth0 Вопросы: 1) что это может быть? 2) и как чинить? Про "ovs-appctl dpif/dump-flows lxdbr0" и "ovs-appctl ofproto/trace" уже прочёл. Скорее всего, ofproto/trace способен помочь, но в сети маловато примеров для него. Проверяю пингом с "хорошего" сервера: ping -s2000 10.20.30.99 На "плохом" сервере сниффер на lxdbr0 показывает, что приходят и отправляются фрагментированные ICMP-пакеты: # tcpdump -npi lxdbr0 host 10.20.30.99 and host 10.20.30.11 and icmp 05:24:23.941480 IP 10.20.30.11 > 10.20.30.99: ICMP echo request, id 14188, seq 3322, length 1376 05:24:23.941497 IP 10.20.30.11 > 10.20.30.99: ip-proto-1 05:24:23.941528 IP 10.20.30.99 > 10.20.30.11: ICMP echo reply, id 14188, seq 3322, length 1376 05:24:23.941543 IP 10.20.30.99 > 10.20.30.11: ip-proto-1 05:24:24.961502 IP 10.20.30.11 > 10.20.30.99: ICMP echo request, id 14188, seq 3323, length 1376 05:24:24.961515 IP 10.20.30.11 > 10.20.30.99: ip-proto-1 05:24:24.961544 IP 10.20.30.99 > 10.20.30.11: ICMP echo reply, id 14188, seq 3323, length 1376 05:24:24.961559 IP 10.20.30.99 > 10.20.30.11: ip-proto-1 Но на физическом интерфейсе "плохого" сервера начальная часть ответных пакетов отсутствует: # tcpdump -npi eth0 geneve 0 and host 10.20.30.99 and host 10.20.30.11 and icmp 05:24:38.273513 IP 5.6.7.8.52725 > 1.2.3.4.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.11 > 10.20.30.99: ICMP echo request, id 14188, seq 3336, length 1376 05:24:38.273540 IP 5.6.7.8.52725 > 1.2.3.4.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.11 > 10.20.30.99: ip-proto-1 05:24:38.273623 IP 1.2.3.4.46501 > 5.6.7.8.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.99 > 10.20.30.11: ip-proto-1 05:24:39.297443 IP 5.6.7.8.52725 > 1.2.3.4.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.11 > 10.20.30.99: ICMP echo request, id 14188, seq 3337, length 1376 05:24:39.297469 IP 5.6.7.8.52725 > 1.2.3.4.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.11 > 10.20.30.99: ip-proto-1 05:24:39.297546 IP 1.2.3.4.46501 > 5.6.7.8.6081: Geneve, Flags [none], vni 0x0: IP 10.20.30.99 > 10.20.30.11: ip-proto-1 lxdbr0 создан с параметрами по умолчанию. geneve добавляется в него так: # ovs-vsctl add-port lxdbr0 to_peer -- set Interface to_peer type=geneve options:remote_ip=5.6.7.8 Полученная конфигурация: # ip link list 7: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 1a:c2:5e:79:ad:4f brd ff:ff:ff:ff:ff:ff 173: genev_sys_6081: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65465 qdisc noqueue master ovs-system state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 82:d8:b5:23:71:03 brd ff:ff:ff:ff:ff:ff # ovs-vsctl show Bridge "lxdbr0" Port "lxdbr0" Interface "lxdbr0" type: internal Port to_peer Interface to_peer type: geneve options: {remote_ip="5.6.7.8"} ovs_version: "2.5.5" # ovs-vsctl list int lxdbr0 _uuid : edcbefb1-ae4c-46c7-ac33-979f7ff552b5 admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 7 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 1 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : "1a:c2:5e:79:ad:4f" mtu : 1400 name : "lxdbr0" ofport : 65534 ofport_request : [] options : {} other_config : {} statistics : {collisions=0, rx_bytes=832412940, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=7245565, tx_bytes=1757517491, tx_dropped=0, tx_errors=0, tx_packets=6808937} status : {driver_name=openvswitch} type : internal # ovs-vsctl list int to_peer _uuid : 99dfe7b8-bda4-4731-98a8-3ab357156a1d admin_state : up bfd : {} bfd_status : {} cfm_fault : [] cfm_fault_status : [] cfm_flap_count : [] cfm_health : [] cfm_mpid : [] cfm_remote_mpids : [] cfm_remote_opstate : [] duplex : [] error : [] external_ids : {} ifindex : 0 ingress_policing_burst: 0 ingress_policing_rate: 0 lacp_current : [] link_resets : 0 link_speed : [] link_state : up lldp : {} mac : [] mac_in_use : "6e:1d:9b:aa:55:87" mtu : [] name : to_peer ofport : 3 ofport_request : [] options : {remote_ip="5.6.7.8"} other_config : {} statistics : {collisions=0, rx_bytes=897330579, rx_crc_err=0, rx_dropped=0, rx_errors=0, rx_frame_err=0, rx_over_err=0, rx_packets=7119580, tx_bytes=1699432606, tx_dropped=0, tx_errors=0, tx_packets=6684287} status : {tunnel_egress_iface="eth0", tunnel_egress_iface_carrier=up} type : geneve Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
rm_ Posted May 29, 2019 · Report post А между серверами что, Интернет через сторонних провайдеров, или ваша локалка и сервера рядом стоят? Если локалка, то VXLAN видится избыточным, можно просто сбриджевать это с одним из VLANов. Если Интернет, то можно думать и в сторону "кто-то что-то иногда начинает блокировать", я бы попробовал IPv6 в кач-ве транспорта для VXLAN и посмотрел, будет ли с ним та же проблема. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...