Мост между двумя серверами периодически перестаёт пропускать длинные пакеты

[Ilya Evseev]

Дано: два 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

 

[rm_]

А между серверами что, Интернет через сторонних провайдеров, или ваша локалка и сервера рядом стоят?

Если локалка, то VXLAN видится избыточным, можно просто сбриджевать это с одним из VLANов.

Если Интернет, то можно думать и в сторону "кто-то что-то иногда начинает блокировать", я бы попробовал IPv6 в кач-ве транспорта для VXLAN и посмотрел, будет ли с ним та же проблема.