А Вы не могли бы прислать полное описание проблемы с графической схемой и конфигом устройства?

К сожалению, проблема имеет "плавающий" характер. Заметил её давно, но совершенно не могу уловить хоть какую-то закономерность. Я бы и рад помочь, но пока не смог продвинуться дальше, чем только продекларировать "да, что-то там такое есть" и подсказать обходное решение - прописать там, где это позарез необходимо, статические АРП-записи.
Поэтому от "подробного описания проблемы с графической схемой сети" пока воздерживаюсь. Но если что-то всё-таки прояснится, то обязательно проделаю такую работу.

присоединяюсь, только чуть перефразирую: не на все arp-запросы отвечают.

стоит 3828, фирмварь 4.05.B09 (ориентировочно последняя, совсем недавно просил у ивана демина), используется как L3, для терминации и маршрутизации нескольких виланов.

есть такой замечательный прибор для диагностики "тупой" части сети (той, которая из неуправляемых железок состоит) - КТ 1.4, http://www.equicom.dp.ua/kt/kt14/KT14.htm
по сути это программируемая пинговалка, работает тривиально: создаёт и шлёт в сеть arp-запрос на заданый ip (чтобы узнать mac), ловит ответ, достаёт из него его mac, и дальше просто его пингует, выдавая статистику потерь.
устройство минимального интеллекта, ничего не знает ни про L3, ни толком про даже L2 - просто запрограмировано на формирование по заданому шаблону пакетов и ловлю ответов + попутный сбор статистики и поэтапной диагностики этого процесса. для неуправляемых "цепочек" за управляемыми устройствами (рапространено в домосетях) - большего и не нужно, и это просто офигительная замена ноутбуку, который много весит, долго грузится, быстро разряжается и т.д.

так вот, на попытках пингать ipif 3828, КТ "затыкается" на первом же шаге - 3828 на его arp-запросы просто не отвечает.
с компьютера - 3828 пингается.
с другой стороны, с КТ исправно пингается и компьютер, и 3028, и 3526 (последние 2 - по адресу ipif System, разумеется), и даже принтер со встроеным принт-сервером
(про все устройства речь идёт в том же вилане, разумеется)
а 3828 по адресу интерфейса в том же вилане - никак. хотя на самом свитче при этих попытках правильный след КТшки появляется во всех нужных местах - в fdb, в ipfdb, в arptable.


и получается в итоге, поскольку за 3828 в "тупых" ответвлениях L3-устройств больше нет, а у немногочисленых L2 системный ipif находится НЕ в клиентском вилане, дабы не терять управление в экстремальных ситуациях - когда техник выходит в проблемное место, пингать "в сторону базы" ему получается просто нечего, что делает КТ бесполезным, и приходится таскать за собой ноутбук и убивать с ним массу лишнего времени.

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

enable sim попробуйте авось поможет)

PS Интересно а что железка вставляет в ARP запрос в качестве Sender IP Adress

может его ещё погладить и фамилию свою вслух назвать?
sim то здесь причём, тем более что в 99% пинг нужен в вилане отличном от системного..



а собственный IP адрес конечно же тоже программируется - вот его и вставляет, его и видно в L3-таблицах на свитче.

и как я сразу не присмотрелся.. КТ при попытке пингать 3828 выдаёт на arp-стадии код ошибки S, согласно его документации, это:

'S' size of ARP packet is wrong

то есть, шлёт всё таки 3828 ответные arp, но сформированы они похоже не по RFC 826. этим вероятно и объясняется, почему компьютеры, где arp-пакеты разбираются программно, их воспринимают, а железки заточеные под точную их структуру - спотыкаются.

сейчас попробую сдампить сниффером экземпляр arp reply от 3828, поищу расхождения со спецификацией и выложу сюда.

...


нашёл. вот что имеем:



в пакете всё нормально, кроме, собственно, его длины.
по спецификации на arp, размер arp-пакета всегда равен 28 байтам; но по спецификации на передачу кадров ethernet (RFC 894) минимальный размер поля данных ethernet-фрейма равен 46 байтам, поэтому arp-пакет при отправке дополняется 18-ю нулевыми (обычно) байтами, 46-28=18.

у arp reply от 3828 в конце наблюдается ещё 4 байта. судя по тому что они каждый раз меняются - это похоже на контрольную сумму фрейма (crc32), но вообще-то сниффер не должен её видеть, так как crc32 проверяется на уровне драйвера и отрезается от пакета перед передачей его на верхние уровни. раз пакет до сниффера успешно дошёл - значит это и было сделано, из чего можно сделать предположение, что на 3828 crc32 по крайней мере в arp-пакетах "пришивается" к фрейму дважды, и если это так - это определённо баг, подлежащий исправлению.

итого, КТ (и вполне вероятно другие железки, в том числе и д-линковские, о которых в этом топике писалось ранее) ожидает ровно 60 байт (ведь больше быть и не должно, там и так паддинг нулями), а получает переполнение и потому дальше ничего не работает..

вот для сравнения "нормальный" arp-пакет, который КТ нормально воспринимает:



тут всё нормально, 60 байт с заголовком, такие ответы шлют 3028, 3526, а вот с 3828 - беда.

проверьте, пожалуйста, мою гипотезу, если подтвердится - ждём-с новой прошивки asap.

ответьте пожалуйста что-нибудь по этому вопросу - непингуемость 3828 сильно усложняет обслуживание сети..

Спасибо! Обязательно проверим. Вам ответит Руслан Бигаров.

Проблема подтвердилось и я ей занимаюсь. Как только будут новости я напишу.

_________________
С уважением,
Бигаров Руслан.

Как влияет команда enable sim на работы ICMP протокола?

Это изначально касалось не ответа первого хопа на trace route. Включение SIM в этом случае помогает.

Руслан, есть ли какое-то продвижение по этому вопросу?

Попробуйте прошивку которую я Вам выслал.

Иван, супер, теперь всё отлично! на прошивке 4.50.B13 "посторонние" 2 байта пропали, длина пакета 60 байт, и КТшка работает отлично!
большое спасибо!

Rudz, маршрутизация между ipif на этой прошивке работает нормально?