Перейти к содержимому
Калькуляторы

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

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


 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.