[post-factum]

Есть вредная железка 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'е — везде одно и то же.

[[anp/hsw]]

Только патчить ядро и iptables, есть такой таргет.

Последнее виденое мною ядро, на который оный накладывался - 3.2

[post-factum]

Мне тут посоветовали попробовать сделать трюк с обработкой пакета в юзерспейсе через nfqueue. Ещё нашёл упоминание того, что tc тоже может менять поля IP-пакета, правда, пока завести не получилось.

 

Можно ссылку на модуль? В крайнем случае попробую портировать на 3.10.

[post-factum]

Собственно, решение на NFQUEUE вот.

 

Похоже, что работает. В рабочей обстановке будем тестить с понедельника.

Edited August 27, 2016 by post-factum

[[anp/hsw]]

Вот патч DF для iptables и ядра 3.2

df.tar.gz

[post-factum]

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

[post-factum]

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

[alex_001]

man ip-route

 

             mtu lock MTU
                    the MTU along the path to the destination.  If the modifier lock is not used, the MTU may be updated by the kernel due to Path MTU Discovery.  If the modifier lock is used,
                    no path MTU discovery will be tried, all packets will be sent without the DF bit in IPv4 case or fragmented to MTU for IPv6.

[post-factum]

А это ещё интереснее. Спасибо, так тоже работает.