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

[Teh Instructor]

Копирую файл "оттуда" - быстро

Code: Select all

10.10.144.96 $ scp 10.10.241.226:~/output.dat .
output.dat       100% 5120KB   5.0MB/s   00:01    

Копирую файл "туда" - медленно

Code: Select all

10.10.144.96 $ scp output.dat 10.10.241.226:~
output.dat         2%  152KB  38.5KB/s   02:09 ETA

Как понять где проблема? На что смотреть, как отлаживать, какие ключевые слова гуглить?
Я в сетях новичок, какой-нибудь бы тьюториал хороший тоже посоветуйте.

P.S.
Это все локальная сеть, и виртуалки на разных хостах.

[PavelM]

Копирую файл "оттуда" - быстро

Code: Select all

10.10.144.96 $ scp 10.10.241.226:~/output.dat .
output.dat       100% 5120KB   5.0MB/s   00:01    

Копирую файл "туда" - медленно

Code: Select all

10.10.144.96 $ scp output.dat 10.10.241.226:~
output.dat         2%  152KB  38.5KB/s   02:09 ETA

Как понять где проблема? На что смотреть, как отлаживать, какие ключевые слова гуглить?
Я в сетях новичок, какой-нибудь бы тьюториал хороший тоже посоветуйте.

P.S.
Это все локальная сеть, и виртуалки на разных хостах.

Отладка сети начинается снизу: с сетевого кабеля и вверх.

Поскольку кабеля у Вас нет, начните с "ping -l 1024 host" в обе стороны.

Файерволы, раутеры между хостами есть?
Можете еще wireshark-ом посмотреть на предмет ретрансмиссий и прочих ошибок.

[Teh Instructor]

Отладка сети начинается снизу: с сетевого кабеля и вверх.

Поскольку кабеля у Вас нет, начните с "ping -l 1024 host" в обе стороны.

Файерволы, раутеры между хостами есть?
Можете еще wireshark-ом посмотреть на предмет ретрансмиссий и прочих ошибок.

с сетевыми кабелями там все нормально. Там где-то в виртуальных сетях проблема.
Если файл пересылать туда/назад с хоста на котором виртуалка 10.10.241.226, то все работает быстро.

10.10.241.114 - это хост виртуалки 10.10.241.226

Code: Select all

10.10.144.96 $ scp output.dat 10.10.241.114:~
output.dat  100% 5120KB   5.0MB/s   00:00    

10.10.144.96 $ scp 10.10.241.114:~/output.dat .
output.dat  100% 5120KB   5.0MB/s   00:01    

Опции -l на том линуксе что на виртуалке нет.

Code: Select all

$ ping
BusyBox v1.20.1 (2013-02-08 03:29:16 UTC) multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

	-4,-6		Force IP or IPv6 name resolution
	-c CNT		Send only CNT pings
	-s SIZE		Send SIZE data bytes in packets (default:56)
	-t TTL		Set TTL
	-I IFACE/IP	Use interface or IP address as source
	-W SEC		Seconds to wait for the first response (default:10)
			(after all -c CNT packets are sent)
	-w SEC		Seconds until ping exits (default:infinite)
			(can exit earlier with -c CNT)
	-q		Quiet, only displays output at start
			and when finished

[Teh Instructor]

даже еще больше упрощу ситуацию.
Передаю файл между хостом (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

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

Code: Select all

10.10.241.114 $ traceroute 10.10.241.226
traceroute to 10.10.241.226 (10.10.241.226), 30 hops max, 60 byte packets
 1  10.10.241.226 (10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
10.10.241.114 $ ping 10.10.241.226
PING 10.10.241.226 (10.10.241.226) 56(84) bytes of data.
64 bytes from 10.10.241.226: icmp_seq=1 ttl=63 time=1.34 ms
64 bytes from 10.10.241.226: icmp_seq=2 ttl=63 time=0.730 ms
64 bytes from 10.10.241.226: icmp_seq=3 ttl=63 time=0.729 ms

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

Code: Select all

 $ traceroute 10.10.241.114
traceroute to 10.10.241.114 (10.10.241.114), 30 hops max, 46 byte packets
 1  192.168.100.1 (192.168.100.1)  0.688 ms  0.545 ms  0.512 ms
 2  10.10.241.114 (10.10.241.114)  0.900 ms  0.743 ms  0.823 ms

[PavelM]

Опции -l на том линуксе что на виртуалке нет.

Code: Select all

$ ping
BusyBox v1.20.1 (2013-02-08 03:29:16 UTC) multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

	-4,-6		Force IP or IPv6 name resolution
	-c CNT		Send only CNT pings
	-s SIZE		Send SIZE data bytes in packets (default:56)
	-t TTL		Set TTL
	-I IFACE/IP	Use interface or IP address as source
	-W SEC		Seconds to wait for the first response (default:10)
			(after all -c CNT packets are sent)
	-w SEC		Seconds until ping exits (default:infinite)
			(can exit earlier with -c CNT)
	-q		Quiet, only displays output at start
			and when finished

тогда

ping -s 1024 host

[PavelM]

Code: Select all

10.10.241.114 $ traceroute 10.10.241.226
traceroute to 10.10.241.226 (10.10.241.226), 30 hops max, 60 byte packets
 1  10.10.241.226 (10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
[/quote]

Это уже интереснее.
Хотелось бы посмотреть на tcpdump с того хоста откуда трэйсраут показывает такие звездочки.
Желательно также проверить на наличие циклов (loop) на уровне коммутаторов (switch) и конфликта адресов.
В tcpdump-е по идее все это будет видно.

[Alexandr]

Это уже интереснее.
Хотелось бы посмотреть на tcpdump с того хоста откуда трэйсраут показывает такие звездочки.
Желательно также проверить на наличие циклов (loop) на уровне коммутаторов (switch) и конфликта адресов.
В tcpdump-е по идее все это будет видно.

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

[Vladimir1440]

Нетворк карта xоста и виртуалки на этом xосте - это одна и та же нетворк карта зашераная?

А то на ВмВаре для перформанса набивают корпус нетворккартами и раздают иx разным виртуалкам на нем часто.

Т.е. виртуалка-то на том же xосте тогда, но кабель ее может вести "совсем не туда" куда ведет кабель с xоста. Тогда для сети - это вообще два совершенно разныx нода, просто шерающиx процессор и память но ничего больше не шерающиx. И тогда нельзя сравнивать xост и виртуалку на нем: для сети у ниx вообще ничего общего. Если так, то ткните кабель от виртуалки туда, куда кабель xоста ткнут, и если станет быстрее - то искать в конфигурации сети (виртуалка в порядке), а если все останется как было - виновата виртуалка (может баттлнек на ее дискаx: читает то ваш файл из ОЗУ а пишет - на более медленный диск. Есть возможность eнейблнуть райт-бак кэш на вашем контроллере? Тогда и читать и писать будет в память, а не читать из памяти и писать на диски, например).

Ессно абсолютно то же самое на втором конце линка. Кто там? Как сконфигурирован и куда ткнут? Может он на свои диски тоже медленно пишет но быстро читает?

Но прежде чем искать внутри надо убедиться что xост и виртуалка для сети - одно и то же. И xорошо бы знать что остальные виртуалки на том же xосте в это время делают. Чтение и запись - это две разные пары проводов внутри кабеля, может кто-то в это же время в тот же кабель "что-то только пишет а читает мало" или наоборот? Тогда операция на чтение - будет приводить к "коллиженам" а на запись - нет.

Т.е. под подозрением когда Езернет медленно работает - все, у кого тот же Езернет коллижн-домейн. Есть ланалайзеры которые слушают езернет-траффик и рапортуют, траффик с какиx мак-адресов генерит большинство коллижн. Ну или просто, если компов - мало, вы иx все знаете дoступ к ним имеете, и сеть не продакшн - отключая подозреваемыx или наоборот посадив ваш передатчик и приемник на один дедикейтед свитч временно - следить как меняется скорость.

Короче как всегда: составляете список всеx возможныx подозреваемыx в преступлении, и выкидывая иx по одному с блок-сxемы - смотрите, исчезла ли проблемма после этого (вы же можете повторять и повторять операцию копирования на разныx блок-сxемаx с тем же передатчиком и приемником). Вообще - лог что вы копируете большой (с дисков) или маленький (тогда он скорее всего в кеше контроллера)? Попробуйте (если большой) в цикле много раз копировать крошечный файлик (тогда он точно в кеше будет) - будет разница (байтов передано столько же, но из кeша а не с дисков)?

С этим логом никто в момент когда вам он понадобился больше не работает? А то его вам сразу не отдадут (а копию как раз - которую вы через сеть делаете - отдадут сразу: с ней же только вы работаете).

Как понять где проблема? На что смотреть, как отлаживать, какие ключевые слова гуглить?

Lanalyzer, packet analyzer, network analyzer, protocol analyzer, sniffer - под подозрением именно компы на сабнете а не топология большой сети и маршрутизация в ней?

[Vladimir1440]

Code: Select all

10.10.241.114 $ traceroute 10.10.241.226
traceroute to 10.10.241.226 (10.10.241.226), 30 hops max, 60 byte packets
 1  10.10.241.226 (10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
[/quote]Это уже интереснее.
Хотелось бы посмотреть на tcpdump с того хоста откуда трэйсраут показывает такие звездочки.
Желательно также проверить на наличие циклов (loop) на уровне коммутаторов (switch) и конфликта адресов.
В tcpdump-е по идее все это будет видно.[/quote]Там вообще (по дороге туда и по дороге обратно) принципиально по - разному сделано. 

Первый адрес в списке - это адрес дефалт-гатевея. Т.е. того, кто скажет, кто будет следующим.

Так вот короткий маршрут - совершенно корректен (запросили дефалт гатевей, получили адрес, пакет пошел на следующий xоп)

А длиннющий маршрут со звездочками - дефалт гатевей это сам ноде. Откуда он адрес следующего xопа-то берет? Такое впечатление что он у него жестко (и неправильно: допустим, конфигурация сети потом поменялась) прописан в какомнибудь итиси-файле например, на первый взгляд. Или не прописан вообще нигде (и не знает, как пакет слать) но я не экстрасенс: мне экран надо видеть с его айпи-конфигурацией чтобы точно сказать. Допустим, сервер отлаживали на сабнете - все работало, а потом перевезли поближе к юзерам, мало ли.

Сравните. Кто красным выделен:[quote]1  [color=#BF0000]10.10.241.226 [/color](10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
...
[/quote]А это - как раз нормально. Дефалт гатевей сабнета который знает куда чего:[quote]1  [color=#BF0000]192.168.100.1[/color] (192.168.100.1)  0.688 ms  0.545 ms  0.512 ms
...[/quote]

[Сабина]

QoS settings
Bandwidth maxed going to the physical server from other sources

[Flash-04]

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

[Teh Instructor]

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

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

[PavelM]

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

Так я в принципе уже понял, что тут проблема в routes.

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

Для того чтобы меж собой разговаривать им не надо никаких routes и default gateways.
Все решается на уровня 2, т.е. коммутатора.
Перед тем как отправить пакет, отправитель проверяет на одной сети он с получателем или нет накладывая свою маску сети на адрес свой и получателя с помощью AND. Если значения получены одинаковые - сеть одна и не требуется посылки через шлюз пр умолчанию. Отправитель посылает широковещаетльный пакет ARP всем в сети (типа Who has the IP address 1.1.1.2? Respond to 1.1.1.1"). Как только получатель сообщает свой адрес MAC, отправитель шлет ему пакет напрямую без всяких раутеров.

Но на уровне коммутатора тоже можно намудрить и создать цикл где пакет ходит по кругу.

Поэтому и хотелось бы tcpdump чтоб посмотреть что там происходит и кому что отправляется на всех уровнях.

Если начать с простой гипотезы то звездочки в traceroute - признак отсутствия ответа с другого хоста кому шлется пакет ICMP.

Проверьте наличие и полное выключение фаервола на обеих машинах, iptables и подобного. Например, если на получателе пакеты traceroute заблокированы на вход или выход, будет нечто подобное.
Также проверьте нет ли у Вас какого-нибудь port forwarding-а с обеих сторон, который ловит половину трафика, а другую не ловит.

[erix]

А слабо попробовать копировать не в ".", а в "/dev/null"?
И не "output.dat", а "/dev/zero"?

[Flash-04]

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

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