FreeBSD 12.3 странная проблема с arp

[Kto To 602]

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

 

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

В общем мучаюсь второй день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить.

Відредаговано 2022-07-27 19:30:10 Kto To

[Kiano 616]

У меня похожая фигня была, но на микротах. По пути до абона на свитчах стоял шторм контрол и прочие ограничения на юникаст и бродкаст. Вот, их потюнить для начала. 

[Kto To 602]

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

У меня похожая фигня была, но на микротах. По пути до абона на свитчах стоял шторм контрол и прочие ограничения на юникаст и бродкаст. Вот, их потюнить для начала. 

 

Нигде по дороге до абона шторм контроль не включен. Переводим тех абонов которые не работают в другой влан - у них все начинает работать. 

 

Коллеги помогите разобраться. За третий день уже мозг сломал себе  Не хочется возвращаться к долбаному пппое

Відредаговано 2022-07-28 14:12:51 Kto To

[Туйон 1 265]

А что за железо там вообще?

Абоненты между собой по L2 не общаются, Vlan на каждого клиента или я как понял в одном Vlan множество клиентов?
Если так, может какой-то роутер флудит. 

[Kto To 602]

3 минуты назад, Туйон сказал:

А что за железо там вообще?

Абоненты между собой по L2 не общаются, Vlan на каждого клиента или я как понял в одном Vlan множество клиентов?
Если так, может какой-то роутер флудит. 

 

Олты бдком. Между ними магистральные свитчи. В одном влан пачка клиентов. Пакеты от клиентов прилетают на сервер, но арп запрос отправленный от сервера к клиенту остается без ответа. Так не у всех но у пачки клиентов такая проблема. Причем на олте могут быть клиенты которые нормально работают и которые не работают.

[Туйон 1 265]

Если  в влане много людей - ищи.

[nedoinet 440]

4 часа назад, Kto To сказал:

Олты бдком

Маки абонентов не попадают случаем в Locally Administered MAC addresses?

[Kto To 602]

10 минут назад, nedoinet сказал:

Маки абонентов не попадают случаем в Locally Administered MAC addresses?

Абоненты работали до этого долго и счастливо. В схеме ничего не менялось. Проблемы начались три дня назад.

19 минут назад, Туйон сказал:

Если  в влане много людей - ищи.

 

Искать что? Пакет от абона долетает до сервера - пакет от сервера, видимо, не долетает до абона ( arp запрос ). Что искать то?

[Kto To 602]

7 часов назад, carver сказал:

тоже что-то такое вроде слышал. несколько лет назад.
интеграторы поставили на автономный погрузчик какие-то "индастриал свичи" на 100Мб,

и налепили на него "проф-камер" с битретом в 20 Mb, еще и по вайфай собирались все это передавать ))
но проблема вылезла еще на свичах, резали мультикаст от камер.
так-что, соглашусь, изменение в "IPTV" - вполне могли что-то изменить.

По сети не производилось никаких изменений ни аппаратных ни настроек.

[Dimkers 1 600]

Значит ищите флудящего

[ISK 259]

В 27.07.2022 в 22:24, Kto To сказал:

Если я прибиваю arp -S мак клиента - у клиента все начинает счастливо работать. Через какое-то время если таки клиентское железо отвечает на запрос и мак добавляется в таблицу на серваке - все также счастливо работает пока не пройдет таймаут и мак не удалится. Если мак появляется и его удалить принудительно - то заново он не добавляется и снова висит в incomplete.

На размер ARP таблицы лимиты никакие не установлены?

[Kiano 616]

Как вариант, предлагаю в роли абона (в той же схеме в смысле) подключить микрот и торчем посканить всё и подампить. Думаю найдёте флудера

[Kto To 602]

20 часов назад, ISK сказал:

На размер ARP таблицы лимиты никакие не установлены?

На сервере никаких крутилок по арп не делалось. Да и абонов в влане порядка 200+-. tcpdump на сервере ничего аномального не показывает :(( Просто когда прилетает ип пакет от клиента - широковещалка с запросом мака клиента, в основном 

[ISK 259]

В 28.07.2022 в 17:12, Kto To сказал:

Переводим тех абонов которые не работают в другой влан - у них все начинает работать. 

Вы сами практически ответили на свой вопрос. Если проблема в каком то конкретном влане, нужно парсить логи. Да и шторм контроль лично я не игнорирую, да. И ещё, позволю себе личные домыслы, хотя, опять же, утверждать не буду, у какого-то абона сидит малварь типа MAC Spoofing Attack. Но, опять же, утверждать не буду...

[nedoinet 440]

7 часов назад, Kto To сказал:

На сервере никаких крутилок по арп не делалось. Да и абонов в влане порядка 200+-. tcpdump на сервере ничего аномального не показывает :(( Просто когда прилетает ип пакет от клиента - широковещалка с запросом мака клиента, в основном 

У меня подобная петрушка была с дырлинками. Тупо на одном влане из пачки. Лечилось ребутом дырлинка

[skybetik 134]

On 7/28/2022 at 5:12 PM, Kto To said:

Нигде по дороге до абона шторм контроль не включен. Переводим тех абонов которые не работают в другой влан - у них все начинает работать. 

 

Коллеги помогите разобраться. За третий день уже мозг сломал себе  Не хочется возвращаться к долбаному пппое

По пути есть edge core switch?

[ISK 259]

18 часов назад, nedoinet сказал:

У меня подобная петрушка была с дырлинками. Тупо на одном влане из пачки. Лечилось ребутом дырлинка

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

[Kto To 602]

20 часов назад, skybetik сказал:

По пути есть edge core switch?

 

 Нету.

 

Смотрите - пакет с дхцп запросом проходит от абона до сервера и клиент получает ип.

Пакет от клиента на запрос арп сервера проходит до сервера и сервер отвечает и клиент видит арп сервера и начинает слать на сервер ип пакеты.

Но пакет от сервера к клиенту на запрос мак адреса клиента - остается без ответа

[tkapluk 908]

Поставити перед роутером клієнта коммутатор що вміє віддзеркалити трафік... і подивитись, що з тієї сторони приходить/уходить. 

[Kiano 616]

В 31.07.2022 в 22:58, carver сказал:

потерял нить разговора, но еще на dlink была какая-то лажа с хешами маков. но это было как-то очень давно, да и детали не помню. может и у других. явно там на чипсеты же "SDK" один, и производители копипастят все что могут.

Это не то. То - коллизия хеш функции

[nvr 52]

Может кто-то из клиентов воткнул вместо роутера кабель в точку доступа аля tp-link tl-wa801. На таких девайсах есть режим smart dhcp...

Ну так чисто на правах нереальной версии. 

Был опыт эксплуатации таких девайсов, много гемора от этого режима было.

[Kto To 602]

Проблему так и не нашли. Перевели все олты на отдельные вланы. Пока наблюдаем. Обидно что природа проблемы не ясна

[Туйон 1 265]

10 часов назад, Kto To сказал:

Проблему так и не нашли. Перевели все олты на отдельные вланы. Пока наблюдаем. Обидно что природа проблемы не ясна

Природа подобных явлений как правило когда много людей в одном влан. 

Говорю как представитель сетей на медиках и тупарях.

У меня разное случалось, но нашел время и перевел всё в режим, что на одно волокно один влан, а на волокне медик или сфп а там человек 5-10.

До этого было, что в одном влане было около 100 чел. То роутеры флудили, то одно то другое то третье.

Идеально бы конечно влан на каждого юзверя, но это не мой метод ))