Bear_UA Posted July 28, 2022 (edited) Третий день мучаюсь не могу разобраться. Раздается инет методом dhcp option 82 Клиент получает ИП, шлюз, днс от dhcpd но при этом на сервере почему-то его arp выглядит как incomplete. ( Более глубокий анализ показал следующее. Роутер клиента получает ип, видит мак шлюза, пытается слать какие-то пакеты на шлюз. Пакеты от клиента приходят на сервер 22:20:04.146455 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 1.1.1.1.53: 21+ A? tp-link.com. (29) 22:20:04.146464 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 68: 10.13.1.49.34647 > 1.1.1.1.53: 22+ A? bing.com. (26) 22:20:04.146501 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 78: 10.13.1.49.37418 > 8.8.8.8.53: 6096+ A? a.root-servers.net. (36) 22:20:04.146507 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 8.8.8.8.53: 19+ A? tp-link.com. (29) 22:20:04.146511 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 68: 10.13.1.49.34647 > 8.8.8.8.53: 20+ A? bing.com. (26) и при этом сервер пытается определить мак клиента отправляя arp запрос 22:19:54.170633 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:55.170640 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:56.171657 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:58.170317 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 И не получает от клиентского роутера ответ. Причем проблема с некоторыми клиентами (не со всеми). Также непонятно зачем шлется arp запрос если на сервер приходит ipv4 пакет уже с мак адресом клиента? Если я прибиваю arp -S мак клиента - у клиента все начинает счастливо работать. Через какое-то время если таки клиентское железо отвечает на запрос и мак добавляется в таблицу на серваке - все также счастливо работает пока не пройдет таймаут и мак не удалится. Если мак появляется и его удалить принудительно - то заново он не добавляется и снова висит в incomplete. Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать. В общем мучаюсь третий день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить. Edited July 28, 2022 by Bear_UA Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted July 28, 2022 Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
YuryD Posted July 28, 2022 Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
azhur Posted July 28, 2022 В 28.07.2022 в 19:44, Bear_UA сказал: Также непонятно зачем шлется arp запрос если на сервер приходит ipv4 пакет уже с мак адресом клиента? ...Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать. А кто-то знает, как в сетевом стеке фряхи организовано хранение ARP-таблицы? А то мне это почему-то напомнило проблему с неизучением MAC-адресов коммутаторами некоторых моделей из-за коллизий хэша. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Bear_UA Posted July 28, 2022 2 часа назад, VolanD666 сказал: Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан? Доступ - олты бдком. Перекидываем клиентов которые жалуются в другой влан - все начинает работать (но надолго ли). На столе не получается сделать стенд - все нормально работает, ип получает, инет бежит :( 2 часа назад, YuryD сказал: Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора. Клиенты включены по пон. На ону - один мак от клиента и он правильный. Включён dhcp snooping и arp inspection. На олтах все нормально, пакеты от абонов долетают до сервера но вот арп запрос-ответ не от всех :( Может какие-то есть крутилки sysctl на FreeBSD (типа количество маков на влан или ещё что-то). Голова уже третий день квадратная от этого :( Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted July 29, 2022 Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю. Если сомневаетесь во фре, воткните рядом линукс и попробуйте с него попинговать клиентов, посмотрите как он отрезолвит. Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ. У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант. Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация. В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше. Для АРП крутилок почти никаких нет и смысла в них тоже практически нет. АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Bear_UA Posted July 29, 2022 2 часа назад, Ivan_83 сказал: Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю. Если сомневаетесь во фре, воткните рядом линукс и попробуйте с него попинговать клиентов, посмотрите как он отрезолвит. Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ. У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант. Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация. В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше. Для АРП крутилок почти никаких нет и смысла в них тоже практически нет. АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден. Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted July 29, 2022 В 29.07.2022 в 09:51, Bear_UA сказал: Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. Это все ваши догадки. Я понимаю что так проще- строить предположения и надеяться что это решит проблему. И возможно когда-нибудь методом исключения вы и найдете причину. Но это может случиться очень нескоро. Поэтому мой вам совет, начните уже искать причину, а не строить предположения. Для этого, как я сказал выше, становитесь с обоих концов и смотрите что уходит- что приходит. Если что-то теряется, тогда ищите где теряется. Как найдете где теряется, копаете в том месте и ищите почему это происходит. А так получается, что вы три дня убили, а проблема так и осталась и даже еще непонятно в каком месте. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted July 29, 2022 В 29.07.2022 в 06:51, Bear_UA сказал: Но вопрос в том - почему это происходит? Потому что где то аппаратный или программный сбой. В 28.07.2022 в 17:21, Bear_UA сказал: Включён dhcp snooping и arp inspection. Начните с отключения инспекции арп, если линух ставить рядом с фрёй и пинговать проблемных клиентов вам лень. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Bear_UA Posted July 29, 2022 1 час назад, Ivan_83 сказал: Потому что где то аппаратный или программный сбой. Начните с отключения инспекции арп, если линух ставить рядом с фрёй и пинговать проблемных клиентов вам лень. Ставил, пинговал, не пингуется (мак также не появляется). Не могу понять почему :((( Ведь связанность до клиента есть. Клиент достукивается до дхцп сервера и получает ип. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted July 30, 2022 Уже писали выше отключите arp inspection Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Bear_UA Posted July 31, 2022 В 30.07.2022 в 18:34, sirmax сказал: Уже писали выше отключите arp inspection Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
azhur Posted August 1, 2022 В 01.08.2022 в 01:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? Притом, что если Ivan_83 прав в том как это работает: В 29.07.2022 в 09:21, Ivan_83 сказал: Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. То арп-запросы идут и от сервера к клиенту. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted August 1, 2022 В 31.07.2022 в 23:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? А на основе чего вы такой вывод делаете, что от абонента что-то уходит? Может до абонента даже запрос не доходит? Опять же, если вы уверены что от абонента идет ответ, но на сервере он не появляется- причем тогда тут FreeBSD? Может он все таки теряется на сети доступа? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted August 3, 2022 В 31.07.2022 в 20:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? У вас либо арп запросы до клиента не долетают либо арп ответы от клиента к серверу. Вот как бы проблемы с арп есть и есть какая то крутилка которая влияет на арп. Но вы можете идти своим путём траблшута, потом поделитесь результатами :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
sirmax Posted August 4, 2022 Поставить у абонента роутер с wrt и модемом и ходить через модем дальше tcpdump и сравнивать что улетает а что прилетает Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Gray swordsman Posted August 4, 2022 возможно проблема в джипоне и построения им FDB, например у нас по дефолту стоит filterBroadcast от оператора к клиенту. Попробуйте сделать сделать clear arp 10.13.0.1 на клиенте, чтобы запрос who-has 10.13.0.1 сделал он в момент когда incomplete. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Bear_UA Posted August 13, 2022 Проблема никак не решилась. Сделали по влану на каждый олт. Вроде все стало нормально работать. Жаль что не нашлось решение :( Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...