Bear_UA Опубликовано 28 июля, 2022 (изменено) · Жалоба Третий день мучаюсь не могу разобраться. Раздается инет методом 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. Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать. В общем мучаюсь третий день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить. Изменено 28 июля, 2022 пользователем Bear_UA Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 28 июля, 2022 · Жалоба Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 28 июля, 2022 · Жалоба Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 28 июля, 2022 · Жалоба В 28.07.2022 в 19:44, Bear_UA сказал: Также непонятно зачем шлется arp запрос если на сервер приходит ipv4 пакет уже с мак адресом клиента? ...Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать. А кто-то знает, как в сетевом стеке фряхи организовано хранение ARP-таблицы? А то мне это почему-то напомнило проблему с неизучением MAC-адресов коммутаторами некоторых моделей из-за коллизий хэша. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bear_UA Опубликовано 28 июля, 2022 · Жалоба 2 часа назад, VolanD666 сказал: Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан? Доступ - олты бдком. Перекидываем клиентов которые жалуются в другой влан - все начинает работать (но надолго ли). На столе не получается сделать стенд - все нормально работает, ип получает, инет бежит :( 2 часа назад, YuryD сказал: Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора. Клиенты включены по пон. На ону - один мак от клиента и он правильный. Включён dhcp snooping и arp inspection. На олтах все нормально, пакеты от абонов долетают до сервера но вот арп запрос-ответ не от всех :( Может какие-то есть крутилки sysctl на FreeBSD (типа количество маков на влан или ещё что-то). Голова уже третий день квадратная от этого :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 29 июля, 2022 · Жалоба Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю. Если сомневаетесь во фре, воткните рядом линукс и попробуйте с него попинговать клиентов, посмотрите как он отрезолвит. Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ. У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант. Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация. В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше. Для АРП крутилок почти никаких нет и смысла в них тоже практически нет. АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bear_UA Опубликовано 29 июля, 2022 · Жалоба 2 часа назад, Ivan_83 сказал: Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю. Если сомневаетесь во фре, воткните рядом линукс и попробуйте с него попинговать клиентов, посмотрите как он отрезолвит. Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ. У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант. Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация. В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше. Для АРП крутилок почти никаких нет и смысла в них тоже практически нет. АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден. Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 29 июля, 2022 · Жалоба В 29.07.2022 в 09:51, Bear_UA сказал: Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. Это все ваши догадки. Я понимаю что так проще- строить предположения и надеяться что это решит проблему. И возможно когда-нибудь методом исключения вы и найдете причину. Но это может случиться очень нескоро. Поэтому мой вам совет, начните уже искать причину, а не строить предположения. Для этого, как я сказал выше, становитесь с обоих концов и смотрите что уходит- что приходит. Если что-то теряется, тогда ищите где теряется. Как найдете где теряется, копаете в том месте и ищите почему это происходит. А так получается, что вы три дня убили, а проблема так и осталась и даже еще непонятно в каком месте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 29 июля, 2022 · Жалоба В 29.07.2022 в 06:51, Bear_UA сказал: Но вопрос в том - почему это происходит? Потому что где то аппаратный или программный сбой. В 28.07.2022 в 17:21, Bear_UA сказал: Включён dhcp snooping и arp inspection. Начните с отключения инспекции арп, если линух ставить рядом с фрёй и пинговать проблемных клиентов вам лень. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bear_UA Опубликовано 29 июля, 2022 · Жалоба 1 час назад, Ivan_83 сказал: Потому что где то аппаратный или программный сбой. Начните с отключения инспекции арп, если линух ставить рядом с фрёй и пинговать проблемных клиентов вам лень. Ставил, пинговал, не пингуется (мак также не появляется). Не могу понять почему :((( Ведь связанность до клиента есть. Клиент достукивается до дхцп сервера и получает ип. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 30 июля, 2022 · Жалоба Уже писали выше отключите arp inspection Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bear_UA Опубликовано 31 июля, 2022 · Жалоба В 30.07.2022 в 18:34, sirmax сказал: Уже писали выше отключите arp inspection Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azhur Опубликовано 1 августа, 2022 · Жалоба В 01.08.2022 в 01:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? Притом, что если Ivan_83 прав в том как это работает: В 29.07.2022 в 09:21, Ivan_83 сказал: Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице. То арп-запросы идут и от сервера к клиенту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 1 августа, 2022 · Жалоба В 31.07.2022 в 23:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? А на основе чего вы такой вывод делаете, что от абонента что-то уходит? Может до абонента даже запрос не доходит? Опять же, если вы уверены что от абонента идет ответ, но на сервере он не появляется- причем тогда тут FreeBSD? Может он все таки теряется на сети доступа? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 августа, 2022 · Жалоба В 31.07.2022 в 20:37, Bear_UA сказал: Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection? У вас либо арп запросы до клиента не долетают либо арп ответы от клиента к серверу. Вот как бы проблемы с арп есть и есть какая то крутилка которая влияет на арп. Но вы можете идти своим путём траблшута, потом поделитесь результатами :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 4 августа, 2022 · Жалоба Поставить у абонента роутер с wrt и модемом и ходить через модем дальше tcpdump и сравнивать что улетает а что прилетает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Gray swordsman Опубликовано 4 августа, 2022 · Жалоба возможно проблема в джипоне и построения им FDB, например у нас по дефолту стоит filterBroadcast от оператора к клиенту. Попробуйте сделать сделать clear arp 10.13.0.1 на клиенте, чтобы запрос who-has 10.13.0.1 сделал он в момент когда incomplete. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bear_UA Опубликовано 13 августа, 2022 · Жалоба Проблема никак не решилась. Сделали по влану на каждый олт. Вроде все стало нормально работать. Жаль что не нашлось решение :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...