pod Опубликовано 7 июня, 2019 (изменено) · Жалоба Здравствуйте! Подскажите, ПО SNR-S2985G-48T(24T_8T)(POE)(UPS)(RPS)_7.0.3.5(R0241.0311) содержит в себе исправление ошибки FIX|MT8441 skb leaking caused by dhcp packets with option82(из ченжлога ПО для 2990G) ? Т.к на 2985-8Т на версии R0241.0305 наблюдаю периодические проблемы с выдачей IP адресов при включенном ip dhcp snooping Изменено 7 июня, 2019 пользователем pod Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Tarasenko Опубликовано 7 июня, 2019 · Жалоба @pod, здравствуйте! Это исправление не имеет общего с вашей проблемой. Опишите проблему подробнее Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pod Опубликовано 7 июня, 2019 (изменено) · Жалоба @Ivan Tarasenko эта проблема встречалась и на 2990. Через рандомный промежуток времени после перезагрузки(от нескольких часов до недель) клиенты, включенные в 2985 или свичи за 2985 перестают получать IP адреса. Если убрать из конфига "ip dhcp snooping enable" то все сразу нормализуется, но в dhcp запросе перестает приходить опция82(что логично :)) Кроме того, в момент существования проблемы таблица биндингов "sh ip dhcp snooping binding all" пустая Изменено 7 июня, 2019 пользователем pod Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 7 июня, 2019 · Жалоба @pod Соберите данные дебага в момент проблемы: debug ip dhcp snooping binding/event/packet/update Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pod Опубликовано 7 июня, 2019 · Жалоба собирал, и трафик дампил с разных сторон. со свича dhcp запросы не уходят(все 1 в 1 как на 2990) 48-5b-39-95-fd-f8 - мак тестового клиента в 1м порту, 9й порт - аплинк в сторону ядра сети [tNACTask]:DHCPS: rcv packet from client 48-5b-39-95-fd-f8, interface Ethernet1/0/1(portID 0x1000001), length 363, type DHCPDISCOVER, opcode BOOTREQUEST, stacking 0 [tNACTask]:DHCPS: flood dhcp pkt from Ethernet1/0/1 dst mac ff-ff-ff-ff-ff-ff to all up port except input port Ethernet1/0/1 in vlan 18 [tNACTask]:DHCPS: do binding info from client 48-5b-39-95-fd-f8, interface Ethernet1/0/1, type DHCPDISCOVER, flag 0 [tNACTask]:DHCPS: rcv packet from client bc-ee-7b-65-96-c9, interface Ethernet1/0/9(portID 0x1000009), length 362, type DHCPDISCOVER, opcode BOOTREQUEST, stacking 0 [tNACTask]:DHCPS: flood dhcp pkt from Ethernet1/0/9 dst mac ff-ff-ff-ff-ff-ff to all up port except input port Ethernet1/0/9 in vlan 13 [tNACTask]:DHCPS: do binding info from client bc-ee-7b-65-96-c9, interface Ethernet1/0/9, type DHCPDISCOVER, flag 8 [tNACTask]:DHCPS: parse packet from client bc-ee-7b-65-96-c9, failed interface Ethernet1/0/9(portID 0x1000009), length 357, type DHCPOFFER, opcode BOOTREPLY, stacking 0 Invalid DHCP Server from Ethernet1/0/9 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 7 июня, 2019 · Жалоба @pod Cоберите, пожалуйста, полный вывод указанного дебага при попытке получения клиентом реквизитов, где будет видно время. А также снимите в момент проблемы 'sh tech' и приложите эти данные в обращение, которое необходимо открыть на support.nag.ru. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bike Опубликовано 7 июня, 2019 · Жалоба Кстати, а проблемные коммутаторы не с UPS встроенным случаем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pod Опубликовано 10 июня, 2019 · Жалоба On 6/7/2019 at 5:54 PM, bike said: Кстати, а проблемные коммутаторы не с UPS встроенным случаем? нет, самые обычные, без UPS On 6/7/2019 at 12:55 PM, Aleksey Sonkin said: @pod Cоберите, пожалуйста, полный вывод указанного дебага при попытке получения клиентом реквизитов, где будет видно время. А также снимите в момент проблемы 'sh tech' и приложите эти данные в обращение, которое необходимо открыть на support.nag.ru. ок, как следующая проблема случится - соберу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...