Странный глюк трассировки в VyOS

[alibek]

Есть Ubiquiti EdgeRouter Lite, на котором запускается скрипт.

Скрипт делает пинги и трассировки на несколько узлов.

Код срипта примерно такой (в цикле):

...
sudo ping -q -4 -c 20 -s 50 -f $NODE > "$TS/flood_$NODE" 2>&1 &
ping -4 -c 20 -s 1000 $NODE > "$TS/ping_$NODE" 2>&1 &
traceroute -4 -l $NODE > "$TS/trace_$NODE" 2>&1 &
...

Делается флуд-пинг, обычный пинг и трассировка, результаты сохраняются в соответствующие файлы.

С пингом все нормально.

Но трассировка на все узлы идет одинаковая:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets
 1  192.168.1.254 (192.168.1.254)  15.552 ms (64)  0.041 ms (64)  0.040 ms (64)
 2  xx.xx.xx.126 (xx.xx.xx.126)  0.039 ms (63)  0.085 ms (63)  0.038 ms (63)
 3  xx.xx.xx.201 (xx.xx.xx.201)  2.587 ms (253)  2.722 ms (253)  2.548 ms (253)
 4  10.222.9.97 (10.222.9.97)  76.434 ms (243)  59.378 ms (243)  67.617 ms (243)
 5  10.222.9.10 (10.222.9.10)  57.988 ms (245)  57.896 ms (245)  62.315 ms (245)
 6  10.222.26.114 (10.222.26.114)  59.860 ms (245)  65.423 ms (245)  72.101 ms (245)
 7  10.222.36.74 (10.222.36.74)  92.464 ms (246)  114.163 ms (246)  10.222.36.78 (10.222.36.78)  109.837 ms (246)
 8  83.169.204.50 (83.169.204.50)  87.834 ms (248)  102.653 ms (248)  76.720 ms (248)
 9  *  83.169.204.113 (83.169.204.113)  721.265 ms (247)  36.731 ms (247)
10  178.176.133.95 (178.176.133.95)  35.891 ms (247)  188.170.162.85 (188.170.162.85)  37.320 ms (246)  178.176.133.95 (178.176.133.95)  36.039 ms (247)
11  108.170.250.51 (108.170.250.51)  37.558 ms (243)  108.170.250.146 (108.170.250.146)  38.062 ms (244)  108.170.250.66 (108.170.250.66)  37.283 ms (246)
12  yandex.ru (77.88.55.50)  37.249 ms (244)  10.1.2.3 (10.1.2.3)  40.851 ms (247)  yandex.ru (77.88.55.50)  37.885 ms (244)

Откуда берется Яндекс для меня загадка.

Единственное предположение — трассировка выполняется в несколько потоков и поток не может отличить свои ответы от чужих.

Если трассировку выполнять интерактивно, то она выполняется нормально.

 

Может быть причина в багах самой утилиты traceroute?

Или пинать аплинка и спрашивать, почему он влезает в служебный трафик?

 

5 минут назад, alibek сказал:

Единственное предположение — трассировка выполняется в несколько потоков и поток не может отличить свои ответы от чужих.

Похоже на то.

Добавил ключ -I (использовать icmp вместо udp) — теперь трассировка выполняется нормально (правда требует sudo для запуска).

[QWE]

20 часов назад, alibek сказал:

Если трассировку выполнять интерактивно, то она выполняется нормально.

 

Единственное предположение — трассировка выполняется в несколько потоков и поток не может отличить свои ответы от чужих. 

 

значит treceroute не хватает консольного окружения

tcpdump

treceroute - многопотоковая программа?

[Pinkbyte]

Пальцем в небо - traceroute выполняется слишком долго(дольше чем ping-и), поэтому в файле ты видишь результат трассировки с предыдущим значением $NODE

 

Решение - синхронизировать весь скрипт через wait и не позволять запуск множества экземпляров скрипта

[alibek]

Так это всю идею сделает бессмысленной. В один поток трассировка на десяток узлов будет занимать слишком много времени, при том что нагрузка в pps тут очень скромная.

Использование ключа -I полностью решает проблему. И причина скорее всего именно та, что я предположил — утилита не может отличить свои ответные udp-пакеты от не своих.

[Pinkbyte]

4 hours ago, alibek said:

Так это всю идею сделает бессмысленной. В один поток трассировка на десяток узлов будет занимать слишком много времени, при том что нагрузка в pps тут очень скромная.

Я дико извиняюсь, был неправ, я почему-то подумал что вы всё пишите в один файл, хотя там четко видно что имя файла включает в себя имя хоста, до которого делается трассировка. То есть путаться именно запись в файл не может в принципе.

 

[GrandPr1de]

9 часов назад, alibek сказал:

Так это всю идею сделает бессмысленной. В один поток трассировка на десяток узлов будет занимать слишком много времени, при том что нагрузка в pps тут очень скромная.

Использование ключа -I полностью решает проблему. И причина скорее всего именно та, что я предположил — утилита не может отличить свои ответные udp-пакеты от не своих.

можно завести каунтер для номера порта и инкрементировать его)))

думаю что там смысл в том что оно по сорс порту смотрит