Сеть медленная в одном направлении - куда смотреть?

[Flash-04]

еще из приколов: когда отправитель не нуждается в static routes, а получатель должен их иметь, иначе пакеты отправлялись обратно совсем в другом направлении (multiple NICs).

[PavelM]

Вряд ли "routes".
Обе машины на одной сети IP.
Маска сети ведь 255.255.255.0?

гы! вы будете смеяться, но именно в такой сетке я недавно наблюдал как пришлось делать static routes, иначе не работало! а по всем докам выходило что нафиг не нужен static route. таки оказался нужен.

"Такой" - понятие растяжимое. Желательно побольше деталей.
Компьютерам в одной подсети айпи никакие пути прописывать не надо.
Это как бы основа айпи.
Одна сеть айпи определяется по маске и адресам получателя и отправителя.
Теоретически можно поставить два компьютера на одну физическую сеть с разными подсетями айпи, тогда да - потребуется прописывание путей и т.п. И внешне (на физическом уровне) обе ситуации выглядят очень похоже.

[PavelM]

еще из приколов: когда отправитель не нуждается в static routes, а получатель должен их иметь, иначе пакеты отправлялись обратно совсем в другом направлении (multiple NICs).

Опять же если получатель на одной подсети, путей не надо.
Если путь идет через раутер, то да.

[erix]

Кто сказал, что сеть тормозит?

как я уже говорил:

1. make sure output.dat is on tmpfs
2. copy to "/dev/null"
3. use ncat instead of scp, the busybox-equipped host likely has dropbear instead of openssh as an ssh server, I am not sure about its scp server perfomance.

[PavelM]

Кто сказал, что сеть тормозит?

Пока не доказано. Бывает и антивирус так шалит. Но тут Линукс вроде.

Но и traceroute явно не нормальный для локальной сети, трафик где-то фильтруется/теряется.

[Vladimir1440]

у вас сетка большая? наверное да, т.к. есть VLANs. Зовите network engineer, без него в таких сетях чёрт ногу сломит. Недавно имел опыт: несколько человек "танцевали" неделю пока нашли товарища кто точно знал какие routes прописать надо чтобы два хоста "разговаривать" могли.

Это и должны делать именно люди поддерживающие конкретную сеть.

Просто потому что у ниx есть статистика за прошлые годы. Интструмент ее сбора - т.н. "пинг тесты" (обычные батч-файлы, гоняющие пинги всего на сети и пишущие вывод в лог). Они иx гоняют с разныx мест, либо сами (если есть ремоут-доступ) либо просто послав батч-файл как Е-мейл аттачмент кому-нибудь в дальний оффис с просьбой прогнать его да послать лог им обратно.

Т.е. с таким фундаментом типовую ситуацию им разрулить - раз плюнуть. Просто повторить тот же пинг тест да сравнить логи тогда (когда все работало) и сейчас (когда что-то не работает). Оттуда однозначно следует какой комп неправильно сконфигурирован (тогда - менять его АйПи конфигурацию), или раутинг тейбл какого раутера надо поменять, или какой провайдер какого ван-линка, впн-линка, или еще кто на дороге дурить начал.

Внутри раутеров - все практически просто на английском языке (пытаюсь сказать, простите за косноязычие, нечто по смыслу "не на каком-то неведомом языке программирования"), нечто навроде (и легко редактируется после изменений конфигурации):



Но вот если вы - человек со стороны, то потратите гораздо дольше, разбираясь. Именно потому, что у вас нет того что есть у ниx (блоксxемы данной сети и информации "о том, как все было раньше").

[Flash-04]

еще из приколов: когда отправитель не нуждается в static routes, а получатель должен их иметь, иначе пакеты отправлялись обратно совсем в другом направлении (multiple NICs).

Опять же если получатель на одной подсети, путей не надо.
Если путь идет через раутер, то да.

так ужас в том был, что вроде как "лишнего" роутера там не было, но пакеты шли не туда куда надо. меня самого это жутко удивило, т.к. так же как и вы был уверен что такого быть не может. Оказывается может

[PavelM]

Просто потому что у ниx есть статистика за прошлые годы.

Да тут статистика не нужна, достаточно одной команды и уже многое станет ясно.

tcpdump -i <interface> -s 65535 -w <some-file>

[erix]

OMG, ppl.

Я один понимаю, что "host" - hypervizor виртуалки?

Смешно, что еше никто не спросил, что за hypervizor и какой режим сети VM: nat/bridged/etc...

[erix]

OMG, ppl.

Я один понимаю, что "host" - hypervizor виртуалки?

Смешно, что еше никто не спросил, что за hypervizor и какой режим сети VM: nat/bridged/etc...

[Flash-04]

даже еще больше упрощу ситуацию.
Передаю файл между хостом (10.10.241.114) и виртуалкой (10.10.241.226) которая на нем:

И если смотреть с хоста то там странный трайс


а если трейсить с виртуалки (10.10.241.226) на хост то все ОК

один в один ситуация недавно была: обратно пакеты пытались идти другим путём. network engineer только глянул - сказал "прописать на хосте назначения static route до отправителя через default host явным образом" и сразу всё заработало. Только не спрашивайте почему, я понятия не имею как у нас эти подсетки сконфигурированы

[erix]

даже еще больше упрощу ситуацию.
Передаю файл между хостом (10.10.241.114) и виртуалкой (10.10.241.226) которая на нем:

Code: Select all

10.10.241.114 $ scp 10.10.241.226:~/output.dat .
output.dat 100% 5120KB   5.0MB/s   00:00   
 
10.10.241.114 $ scp output.dat 10.10.241.226:~
output.dat  2%  128KB  53.5KB/s   01:33 ETA

1. какой hypervizor?
2. VM NIC mode: bridged?

Если проблема в сети, то это баг hypervizor-а

You need to time ncat over udp transfer between /dev/zero (or file on tmpfs) and /dev/null of these two hosts in order to confirm this is a network problem indeed.

Не знаю, есть ли ncat (nc, netcat) на хосте с busybox-ом. good luck

[PavelM]

OMG, ppl.

Я один понимаю, что "host" - hypervizor виртуалки?

Смешно, что еше никто не спросил, что за hypervizor и какой режим сети VM: nat/bridged/etc...

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

[erix]

Я тоже могу много баек рассказать.

[erix]

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

А если в traceroute задать max hops 126, то еше длинее будет.
Сорри, не смог удержаться