orlik

Согласен, почти наверняка проблема в mtu, вопрос только в том какой mtu включен на стороне клиента и какой максимальный проходит по сети. @Igore, вы бы подняли тестовый vlan и проверили какой MTU проходит при ваших настройках и потом поинтересовались у клиента , какие у него настройки, а так вы ещё долго будете гадать и предполагать ..

Вы расскажите чуть больше. Как часто флапает и есть ли периодичность. ? Есть логи ospf ? Приложите , хотя бы будет понятно с какой стороны не получают пакеты. Снимите дамп трафика, может там будет что-то видно. ?

Вам "Missing-Attribute" прилетает в ответе от NAS, поэтому без включенного дебага на NAS вы врятли сможете найти ответ, что ему не хватает

Зависит от апстрима , может послать, т.к. у него ничего нет, а может и предложить полноценную защиту от ддос атак.

Да там не в прошивке дело, есть определенные PN и эти дейвайсы залочены на работу только в qfabric.

discover будут "броадкаститься" на все сервера в группу, request будет лететь только на определенный сервер , который и выдал эту лизу. Почитайте по ссылке описание. P.S. могу подтвердить что так оно и работает, проверял на разных версиях софта

Не знаю как работает dhcp-relay на cisco , на juniper пакетики отправляются на все сконфигурённые dhcp-server в данной группе https://www.juniper.net/documentation/us/en/software/junos/dhcp/topics/topic-map/dhcp-relay-agent-security-devices.html The DHCP relay agent receives the discover packet and forwards copies to each of the two DHCP servers. The DHCP relay agent then creates an entry in its internal client table to keep track of the client’s state.

судя по ошибке, у вас проблема не в прошивке. там некоторые их этих моделей могут работать только в составе qfabric и их не возможно конвертнуть в standalone. Если вам попался именно такой, то можете смело выкидывать его :)

А он у вас до этого работал , или это "новый" коммутатор ? Он точно не был частью qfabriс, а то его для начала надо конвертнуть.

если есть copp фильтр , попробуйте в нём разрешить udp port 67/68, да , знаю что оно транзитное ...

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

Доступа к кейс менеджеру нет , потому-что надо купить саппорт, тогда у вас и RMA будет доступен. А сейчас у вас два варианта , либо купить саппорт (сомневаюсь что будет оправдано по цене), либо играть с программатором. Еще можно попробовать найти сервисные центры (не официальные) которые возьмутся за такое

Нее , вы немного путаете. Вы не погоните весь свой трафик (при условии что вы ISP) через СF , Бесспорно CF/Qrator намного лучше защитят конкретный сервис. Подобные же системы способны очень качественно и очень быстро реагировать на amplification(в первую очередь) атаки и служат скорее для защиты операторов , как первый щит, для более тонкой очистки есть другие системы (при необходимости часть трафика можно завернуть на очистку на них), которые ставятся каскадом. Наблюдая за одной такой системой установленой isp, фиксировали сотни атак на клиентов (в том числе шпд) , большей частью короткоживущие (чаще всего 5-10 мин, но бывали и те которые длились по часу и более). И отфильтровать подобное на CF , не представляется возможным.

Вон тоже cf отбивался от терабитной атаки на обычных коробках https://blogs.juniper.net/en-us/security/stopping-1-4tbps-memecached-ddos-attack-at-peering-router

попробуйте fastnetmon для начала , за одно и приценитесь. А вообще всё очень сильно зависит от того что именно вы хотите защищать. Если на asbr стоит juniper MX , то можно посмотреть в сторону corero.