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

post-factum

Пользователи
  • Публикации

    12
  • Зарегистрирован

  • Посещение

О post-factum

  • Звание
    Абитуриент
  1. GoIP мне в своё время показались несколько глючноваты и странноваты, а вот с OpenVox'ами проблем особо и не было.
  2. Когда-то давно тестил по CPU — с включенным JIT ведёт себя замечательно. Данных, к сожалению, не осталось. Всё, что могу сказать сейчас — правила писать намного проще и приятнее, ибо синтаксис pcap.
  3. Решение: BPF-программа должна возвращать либо правильный snaplen, чтобы самостоятельно классифицировать трафик по классам, либо -1, чтобы было поведение, как раньше. Детали: https://www.linux.org.ru/forum/admin/12946729
  4. Разбираюсь с шейпером на таком простом примере: # шейпим исходящий трафик, корневая дисциплина — HTB tc qdisc add dev enp3s0 root handle 1: htb default 99 r2q 1000 # корневой класс на ~20-мегабитный линк tc class add dev enp3s0 parent 1: classid 1:1 htb rate 18000kbit burst 10k # дочерний класс, допустим, сюда мы хотим засунуть ICMP tc class add dev enp3s0 parent 1:1 classid 1:11 htb rate 100kbit ceil 18000kbit prio 1 quantum 2000 # дочерний класс по умолчанию для неклассифицированного трафика tc class add dev enp3s0 parent 1:1 classid 1:99 htb rate 100kbit ceil 18000kbit prio 2 quantum 2000 # навешиваем fq_codel на дочерние классы tc qdisc add dev enp3s0 parent 1:11 handle 11: fq_codel tc qdisc add dev enp3s0 parent 1:99 handle 99: fq_codel # собственно, фильтр для ICMP tc filter add dev enp3s0 parent 1: bpf run bytecode "$(tcpdump -ienp3s0 -ddd 'ip proto 1' | tr '\n' ',')" flowid 1:11 Счётчики для 1:11 после такого лежат в нулях, весь трафик валит в 1:99. Если фильтр заменить на обычный u32, то всё ОК: tc filter add dev enp3s0 parent 1: u32 match ip protocol 1 0xff flowid 1:11 Самое плохое то, что всё это на BPF раньше работало. Не могу понять, что поменялось или сломалось при очередном апгрейде. Arch, ядро v4.7.6, стоковое.
  5. Флаг DF с ip_no_pmtu_disc в LXC

    А это ещё интереснее. Спасибо, так тоже работает.
  6. Флаг DF с ip_no_pmtu_disc в LXC

    Решение с NFQUEUE проверили в рабочей обстановке — проблем не замечено.
  7. Прерывания

    Версии ядра и утилит, а ещё логи, пожалуйста. Вообще, странно, что ifconfig'ом кто-то до сих пор пользуется.
  8. Флаг DF с ip_no_pmtu_disc в LXC

    Спасибо. Модуль на 4.7 с кое-какими корректировками собрался, что дальше — пока не пробовал.
  9. Флаг DF с ip_no_pmtu_disc в LXC

    Собственно, решение на NFQUEUE вот. Похоже, что работает. В рабочей обстановке будем тестить с понедельника.
  10. Флаг DF с ip_no_pmtu_disc в LXC

    Мне тут посоветовали попробовать сделать трюк с обработкой пакета в юзерспейсе через nfqueue. Ещё нашёл упоминание того, что tc тоже может менять поля IP-пакета, правда, пока завести не получилось. Можно ссылку на модуль? В крайнем случае попробую портировать на 3.10.
  11. Есть вредная железка X, которую нужно мониторить по SNMP и которая в упор не отвечает на IP-пакеты с флагом DF (баг в прошивке, который неизвестно как, когда и кто пофиксит). Есть софт, живущий в контейнере (systemd-nspawn), который опрашивает snmpget'ом разные железки, в том числе и железку X. Проблема в том, что все пакеты от софта в контейнере шлются с установленным флагом DF. Если на гипервизоре выставить ip_no_pmtu_disc=1 и запустить софт прямо на том же гипервизоре, а не в контейнере, то всё работает. Однако ip_no_pmtu_disc=1 не влияет на софт в контейнере — пакеты всё равно шлются с флагом DF. Как быть? Проверялось на Arch'е, CentOS'е 7, Ubuntu в systemd-nspawn и docker'е — везде одно и то же.