[Bear_UA]

Третий день мучаюсь не могу разобраться.

 

Раздается инет методом 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

[VolanD666]

Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан?

[YuryD]

Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора.

[azhur]

В 28.07.2022 в 19:44, Bear_UA сказал:

Также непонятно зачем шлется arp запрос если на сервер приходит  ipv4 пакет уже с мак адресом клиента?

...Если перекидываем клиентов которые жалуются в другой влан (на этом же сервере) - у них все начинает работать.

А кто-то знает, как в сетевом стеке фряхи организовано хранение ARP-таблицы? А то мне это почему-то напомнило проблему с неизучением MAC-адресов коммутаторами некоторых моделей из-за коллизий хэша.

[Bear_UA]

2 часа назад, VolanD666 сказал:

Ну, а почему ответ не доходит до сервера? Может дело не в сервере, а в свиче доступа например? Может там какие-то фильтры настроены на доступе? Есть возможность собрать стенд и повторить проблему? Как вариант, можно смиррорить трафик с клиентского порта и посмотреть с двух сторон трубы. Доступ случайно не на микротиках сделан?

Доступ - олты бдком.

Перекидываем клиентов которые жалуются в другой влан - все начинает работать (но надолго ли). На столе не получается сделать стенд - все нормально работает, ип получает, инет бежит :(

 

2 часа назад, YuryD сказал:

Если это тп-линк, то некоторые модели отдают по паре маков на wan.... Изучите маки на порту клиентского коммутатора.

Клиенты включены по пон. На ону - один мак от клиента и он правильный. Включён dhcp snooping и arp inspection. На олтах все нормально, пакеты от абонов долетают до сервера но вот арп запрос-ответ не от всех :( Может какие-то есть крутилки sysctl на FreeBSD (типа количество маков на влан или ещё что-то). Голова уже третий день квадратная от этого :( 

[Ivan_83]

Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю.

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

 

Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице.

По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ.

 

У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант.

 

Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация.

В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше.

 

Для АРП крутилок почти никаких нет и смысла в них тоже практически нет.

АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден.

[Bear_UA]

2 часа назад, Ivan_83 сказал:

Давайте уже по порядку: у вас КЛИЕНТЫ НЕ ОТВЕЧАЮТ на арп запрос но лечить вы хотите фрю.

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

 

Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице.

По идее статические арп записи из таблицы не должны удалятся если клиент пришлёт арп ответ.

 

У нас в продукте есть нетграф модуль который кладёт маки и ип адреса из пакетов в арп таблицу, но это специфичный случай и по сути у нас другого выбора нет потому что мы стоим мостом и можем стоять между роутерами, которые почти всегда без прокси арп и соответственно мы никогда не отрезолвим нужные нам маки стандартным способом, а таблицу маршрутизации писать себе не вариант.

 

Проблем с хранением мака в таблице быть не может, потому что для любой ОС наличие кучи МАК адресов с разными IP в арп кеше нормальная штатная ситуация.

В случае если приходит новый клиент с таким же IP но другим маком то адрес может быть обновлён только после протухания записи в кеше.

 

Для АРП крутилок почти никаких нет и смысла в них тоже практически нет.

АРП кеш ничего не знает про вланы, вы их терминируете на интерфейсах и для дальнейшего стёка влан не виден.

 

Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. 

[VolanD666]

В 29.07.2022 в 09:51, Bear_UA сказал:

Вы все правильно говорите. Но вопрос в том - почему это происходит? И самое интересное что клиентов в этом влане который затянут на пачку олтов не так много - человек 200. Сомнительно чтоб где-то срабатывал шторм контроль или броадкаст контроль. И на эту машину затянут всего один dhcp влан с широкой ип маской и все. 

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

 

А так получается, что вы три дня убили, а проблема так и осталась и даже еще непонятно в каком месте.

[Ivan_83]

В 29.07.2022 в 06:51, Bear_UA сказал:

Но вопрос в том - почему это происходит?

Потому что где то аппаратный или программный сбой.

 

В 28.07.2022 в 17:21, Bear_UA сказал:

Включён dhcp snooping и arp inspection.

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

[Bear_UA]

1 час назад, Ivan_83 сказал:

Потому что где то аппаратный или программный сбой.

 

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

 

Ставил, пинговал, не пингуется (мак также не появляется). Не могу понять почему :((( Ведь связанность до клиента есть. Клиент достукивается до дхцп сервера и получает ип.

[sirmax]

Уже писали выше отключите arp inspection 

 

[Bear_UA]

В 30.07.2022 в 18:34, sirmax сказал:

Уже писали выше отключите arp inspection 

 

Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection?

[azhur]

В 01.08.2022 в 01:37, Bear_UA сказал:

Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection?

Притом, что если Ivan_83 прав в том как это работает:

В 29.07.2022 в 09:21, Ivan_83 сказал:

Фря и другие известные ОС не кладут в арп и нд таблицу маки из прилетающих к ним пакетов, они всегда запрашивают через арп/нд, кроме случаев с noarp на интерфейсе и статических записей в арп таблице.

То арп-запросы идут и от сервера к клиенту.

[VolanD666]

В 31.07.2022 в 23:37, Bear_UA сказал:

Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection?

А на основе чего вы такой вывод делаете, что от абонента что-то уходит? Может до абонента даже запрос не доходит? Опять же, если вы уверены что от абонента идет ответ, но на сервере он не появляется- причем тогда тут FreeBSD? Может он все таки теряется на сети доступа?

[Ivan_83]

В 31.07.2022 в 20:37, Bear_UA сказал:

Ип пакет ОТ абонентов уходит в сторону шлюза, причём тут отключение arp inspection?

У вас либо арп запросы до клиента не долетают либо арп ответы от клиента к серверу.

Вот как бы проблемы с арп есть и есть какая то крутилка которая влияет на арп.

Но вы можете идти своим путём траблшута, потом поделитесь результатами :)

[sirmax]

Поставить у абонента роутер с wrt и модемом и ходить через модем

дальше tcpdump и сравнивать что улетает а что прилетает 

[Gray swordsman]

возможно проблема в джипоне и построения им FDB, например у нас по дефолту стоит filterBroadcast от оператора к клиенту. Попробуйте сделать сделать clear arp 10.13.0.1 на клиенте, чтобы запрос who-has 10.13.0.1  сделал он в момент когда incomplete.
 

[Bear_UA]

Проблема никак не решилась. Сделали по влану на каждый олт. Вроде все стало нормально работать. Жаль что не нашлось решение :(