Архив форумов ЦИТФорума

[Безсистемный]

Всем привет!
Несколько вопросов.
1. Вообщем так, прихожу вчера на работу и случайно замечаю, что на хабе на одной ячейке горит зеленая ламочка (т.е. 10mbs) хотя сеть - сотка. Ну самое первое - ping computer -t -l 65500. Хрен. Cделал -l 30000. Пингуется. Что это? Косяк сетевухи?
2. Сетевой принтер hp2300dn пингуется нормально только -l 1400. Задаю -l 1500 - ни фига. Косяк? Или для принтеров енто нормально?
3. Некоторые компы при ping computer -t -l 65500 теряют одни пакет. Это нормально?

Заранее спасибо за участие.

[and3008]

Дык эта...
ping -l СКОЛЬКО-ТО означает, что надо сперва создать в ОЗУ буфер размером СТОЛЬКО-ТО байт, а потом выстрелить это в сеть с максимально возможной скоростью.

Принимающая сторона еслу успеет все это принять и обработать, то теоретически это хорошо.

Если будут потери пакетов, то это может быть все, что угодно: Сама сетевуха, кабель, качество набивки кабеля, скорость проца, скорость коммутирующего оборудования, текущая загрузка компа, текущая загрузка сетевого оборудования, сила ветра, величина атмосферного давления и т.д. и т.п.

[Безсистемный]

"ping -l СКОЛЬКО-ТО означает, что надо сперва создать в ОЗУ буфер размером СТОЛЬКО-ТО байт" А можно подробнее, плз. Что значить создать в ОЗУ буфер и как его создать? В ОЗУ машины какой, отправляющей или принимающей?

[MiK]

_

[SAW]

Параметр -l означает размер отправляемого по ping'у в сеть пакета. Обычно, при обмене информации по сети, чем больше загружена сеть - тем меньше размер отправляемого пакета (кажется протоколы сами могут динамически изменять размер отправляемого пакета, имеется ограничение только на минимальный и максимальный размер).
Очевидно, что прежде чем отправить пакет в сеть, он должен быть сформирован (ну конечно, в отправляемой машине).
При заруженности сети (или при наличии помех, некоторых неисправностях в оборудовании, ...) большие пакеты не доходят до адресата или доходят с искажениями. Обычно, для примитивного диагностирования сети посылают пинги, начиная с маленького размера и увеличивая его. Примерно, на качественном уровне, можно судить о работоспособности сети, но это никак не является показателем скорости обмена информацией.

То, что при больших размерах отправляемого пакета встречается всего потеря первого (а именно об этом кажется идет речь), это нормально, так как перед отправкой ping-пакета с данными, отправляющий должен разрешить МАС-адрес получателя с помощью ARP-запроса. На это уходит определенное время, которое не учитывается (не разделяется) в TTL (времени жизни пакета) и отправляющий не успев получить ответ в заданном интервале считает его утерянным. При отправке последующих пакетов МАС-адрес получателя уже известен (кеширован) и пинг-пакеты уходят без задержек.

[Безсистемный]

В моем посте, в первом пункте, машина не пингуется ВООБЩЕ, если посылать максимальный пакет. Если пакет по-умолчанию, то все ОК.

Что касается одного пакета, был бы он первый все с ним ясно было бы, но не всегда он первый. Пакет может не пройти после, допустим нормального пинга 100 пакетов. Ну да да это бог с ним, мож комп у кого подвис (или такого не может быть?).

И что там and писал про буфер ОЗУ? Не в курсе?

[and3008]

Про MTU слыхал?
Maximal transfer unit.

Обычно чтобы определить максимальный MTU на удаленной машине надо запустить ping -f -l 1472

Запуск -l без -f не имеет смысла по большому счету. Т.к. при этом большой пакет начинает разбиваться на части. Ну в принципе можно проверить как реализация TCP/IP на удаленной машине справляется с фрагментированными пакетами.

Первые версии виндузей 95/98 валились только в путь от сильно фрагментированных пакетов. Для атаки надо было выставить у себя малый MTU и послать на атакуемый комп нечто вроде ping -l 100000

Потом Микрософт эту дрянь залатала, слава богу. Другое дело, что некоторые админы эти заплатки не поставили. Это уже их проблемы.

Резюме:
-l - это размер посылаемого пакета. На фига его обозвали буфером отправки - не понятно. Глупость какая-то.

Я на эту глупость тоже повелся. Думал что это ping перед отправкой формирует в ОЗУ очередь пакетов. Ан нет. Так что пургу я в первый раз прогнал.

По поводу 10 мегабит вместо 100. Ищи проблемму в кабеле, сетевых карточках, сетевом оборудовании. Бывает такое из-за неправильно обжатого кабеля, неправильных драйверов, умирающих карточек (две шткуки таких лежит у меня в столе) и неверного согласования скорости между карточкой и свичем/хабом. Обычно это бывает со старыми управляемыми свичами. Лечится обновлением ПО.

[mare]

Может, попробую тоже ответить на вопросы Бессистемного.

По 1-му и 2-му вопросу:
История зарыта где-то в прошлом.
Раньше очень часто встречал это "магическое число" - 1514. Для старых сетевух и драйверов эта величина считалась стандартной (по-умолчанию) максимальной длиной пакета (вместе с заголовком), передаваемого по сети.
Соответственно этому числу рассчитывались размеры буферов под принимаемые и отправляемые пакеты, и т.п.. Администратор сети мог эту стандартную величину менять в большую и меньшую стороны, если этого требовали прикладные задачи. Как правило, этим достигалась оптимизация передачи пакетов в сети. При смене надо было обойти ВСЕ рабочие станции, чтобы не было проблем в сети.
Соответственно, если длина пакета при передаче по сети превышала этот размер, начинались непредсказуемые вещи, именуемые сейчас buffer overflow. Если же основная масса хостов передает в сети короткие пакеты (например, терминалы в юниксовых сетях) , и только несколько станций (хостов)должны обмениваться длинными сообщениями (файловый обмен), эту величину в сети переопределяли (повторяю, для всех хостов).

Для новых сетевух и драйверов это "магическое число" закопали в истории. Эти новые устройства обязану по-умолчанию устойчиво работать с любой длиной пакета.
Но, вероятно, разработчики устройств типа принтера его по-прежнему "имеют в виду". И превышение длины входного пакета для этих устройств приводит к отказу.

По 3-му вопросу хорошо ответили до меня. Полностью поддерживаю ответ SAW насчет потери именно первого пакета.
_________________
Не злись на видовс, всяк в нее входящий!

[Безсистемный]

Купил вот сегодня триком, поменял на проблемной тачке - та же самая бодяга. Перекинул этот комп на другую ячейку на свиче и, как говорится, отсутствие результата - тоже результат ((( Есть у меня одно подозрение. Нашел в сетке еще одну тачку с таким же траблом. Обе эти корявые тачки покупались в одной не менее корявой (как я потом узнал) фирме. Похоже дело не только в сетевухах, но и другом железе. Каком? Хрен знает. Как мне сказали, в этой фирме компы собирают из железяк, которые чуть ли не на помойке нашли. Делаааааа. Не компы же менять, в самом деле.
Попробовал (спасибо and) ping -f -l 1472 - борода, попробовал ping -f -l 1 - борода. Это что? MTU меньше 1? Да, что еще можно покапать, плз.

[Безсистемный]

Сорри за предыдущий сабж. Когда поменял сетевушку изменился апишник (у меня DHCP), а я привык к старому и пинговал его вовсю. Короче, после замены сетевушки - все ОК!!! Тьфу-тьфу-тьфу. Всем огромное спасибо, почерпнул некоторое кол-во плезной инфы.

[and3008]

В сети Ethernet он должен быть не более 1500 байт. Из них 26 отдается под заголовок.
Минимальная длина пакета должны быть не менее 64 байт, если реальных данный меньше, то они заполняются нулями.

Тут на сайте есть прекрасные доки по TCP/IP. Почитай, хотя бы бегло. Многие вопросы отпадут сами собой.