Меня конечно как сетевика поражает, что снять дамп это не самоочевидно при локализации любой сетевой проблемы
Я кстати сам с этой же хернёй столкнулся на связи между инстансом в рф и в каматере. Один к одному: tcp устанавливается, clinet hello прилетает на каматеру, он отправляет ответ, ответ в рф не приходит. Если запускать тестовые коннекты подряд , то проходит меньше половины. Проблема плавающая: то включат эту политику, то выключат. У меня это вызывает только один вопрос: какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций? или как? Ну и плюс должен быть какой-то второй фактор для срабатывания фильтрации помимо зарубежного ASN, иначе будут страдать все сайты на зарубежных хостингах. Хотя может в этом и цель...
Откуда информация, что команда spanning-tree bpduguard enable реагирует имменно на поддельные BPDU? Я так понимаю, что порт в этом режиме отреагрует на получение ЛЮБОГО BPDU и уйдет в err-disable
Меня конечно как сетевика поражает, что снять дамп это не самоочевидно при локализации любой сетевой проблемы
Я кстати сам с этой же хернёй столкнулся на связи между инстансом в рф и в каматере. Один к одному: tcp устанавливается, clinet hello прилетает на каматеру, он отправляет ответ, ответ в рф не приходит. Если запускать тестовые коннекты подряд , то проходит меньше половины. Проблема плавающая: то включат эту политику, то выключат.
У меня это вызывает только один вопрос: какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций? или как?
Ну и плюс должен быть какой-то второй фактор для срабатывания фильтрации помимо зарубежного ASN, иначе будут страдать все сайты на зарубежных хостингах. Хотя может в этом и цель...
Откуда информация, что команда
spanning-tree bpduguard enableреагирует имменно на поддельные BPDU? Я так понимаю, что порт в этом режиме отреагрует на получение ЛЮБОГО BPDU и уйдет вerr-disable