Jump to content
Калькуляторы

Ilya Evseev

VIP
  • Content Count

    1955
  • Joined

  • Last visited

3 Followers

About Ilya Evseev

  • Rank
    Доцент
  • Birthday 10/25/1973

Контакты

  • Сайт
    https://github.com/ilyaevseev

Информация

  • Пол
    Мужчина
  • Интересы
    Jazz, box and sex

Город

  • Город
    SPb~

Recent Profile Visitors

5209 profile views
  1. Дано: два 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
  2. https://mikrotik.com/product/rb4011igs_5hacq2hnd_in
  3. Что говорит "sysctl net.core.default_qdisc"? Если "pfifo", то попробуйте заменить на "fq_codel".
  4. Ищете в Гугле - "mikrotik bgp session email". Тут же находите - https://forum.mikrotik.com/viewtopic.php?t=64572#p498656
  5. Можно к нагружающему CPU процессу на несколько секунд подключиться strace'ом и посмотреть, чем он занят.
  6. Это значит, что у вас проблема с тарифами - искуственно заставляете клиентов платить за дутые мегабиты, которых у вас нет и которые им по факту не нужны.   Проведите простой обратный эксперимент - зарежьте всем скорости до мегабита. По вашей логике "потребление инета" останется прежним?)
  7. Есть проверенная временем эмпирическая формула: требуемая толщина внешнего канала = сумма тарифных скоростей абонентов, поделенная на 10.
  8. В примере по ссылке dnsdist является фронтендом к авторитативному DNS-серверу (для внешних клиентов) и к DNS-рекурсору (для внутренних клиентов), но сам не является ни первым, ни вторым.
  9. Спасибо, интересный вариант. К сожалению, вряд ли подойдёт под мои задачи, т.к. не поддерживает рекурсивные запросы.
  10. Хотелки: 1) умение делать форвардинг-запрос, если рекурсивный завершился по таймауту 2) настраиваемые таймауты 3) prefetch для упреждающего обновления устаревающих записей 4) хранение записей с истёкшим TTL, если prefetch не сработал (т.е. чтобы для обновления использовался обычный TTL, а для хранения вручную выставлялся увеличенный) 5) подмена ответов NOT FOUND / NOREPLY на заданный IP 6) нормально держащий всплески запросов (т.е. асинхронный и\или многопоточный) 7) не BIND Сейчас использую Unbound, не хватает в нём пунктов 1 и 2 (если указан forward-addr, то по факту forward-first:false игнорируется и запросы всегда идут только к форвардерам).
  11. Шардировать или партицировать? Если второе, то немного напрягает, что вместо функциональности из коробки Заббикс предлагает городить полусамодельные костыли: https://www.zabbix.org/wiki/Docs/howto/mysql_partition Хотя альтернативы при большом числе метрик всё равно нет.
  12. В https://github.com/ilyaevseev/rkn-filter добавлена возможность загрузки реестра из https://reestr.rublacklist.net/ Кстати, бывало у кого-нибудь такое, что vigruzki.rkn.gov.ru начал возвращать ошибку, хотя ключ и сертификат не просрочены? "недействительный сертификат ЭП: не удалось выполнить проверку на отзыв сертификата (одного и/или нескольких в цепочке), необходимо обратиться в УЦ, выдавший сертификат (информация по обратной связи для разрешения проблем приведена в Памятке оператору связи в разделе http://eais.rkn.gov.ru/tooperators/)"
  13. Не совсем по теме, но на мой взгляд, важно: Если не хотите через N лет получить помойку, в которой перемешаны настройки железа и кучи сервисов, постарайтесь сразу же разобраться, как в Линуксе создавать контейнеры, и дальше для каждого сервиса всегда выделяйте отдельный контейнер. Если разбираться лень или некогда, можете начать с Proxmox, но в нём много лишнего: https://ru.wikipedia.org/wiki/Proxmox_Virtual_Environment