Решение проблемы - магическое, без понимания причин и следствия.
Задушив Rdp трафик, вы ничего не сделали со всем остальным трафиком, а значит потери пакетов из-за превышения емкости канала связи вас ещё догонят.
Приоритет в очередях работает совсем не так, как вам вероятно показалось. У вас нет других, конкурирующих с этой очередей, а значит приоритет - просто ничего не значащая цифра.
Изучите то, что называется QoS, прежде, чем делать непонятно что. В вашем случае, вам надо изучать нагрузку на интернет канал в целом, вероятно там у вас возрос трафик и пошёл отброс пакетов как попало. После внедрения полноценного QoS на сети (хотя-бы на Edge роутере), вы кардинально порешаете многие сетевые проблемы в компании. Но тема эта не простая, для упрощения написано уже масса скриптов, решающих задачу генерации сотен правил.
И заметил такую вещь, если у вас GRE с маской 30, то установка OSPF peer в режим p2p - будет проблема, нескончаемый exchange.
Установка в broadcast или смены ip на настоящий p2p (маска 32) - решает проблему.
Однако есть ещё проблема, то ли она в OSPF то ли IPSec/GRE/L2TP, но линки очень часто переходят в exchange и частично ломают маршрутизацию. Я написал им в поддержку на этот счёт, жду ответа.
Для настройки вам надо сделать правильный шаблоны интерфейсов. Примеры в офф доке есть, там все вполне понятно. Надо проверить настройки зон, они мигрируют не полностью.
Для клиента с "телефона" в этой статье все расписано, просто замените подсеть на свою.
Я понимаю почему они не сделали полную автомиграцию - это очень не просто само по себе, да и учесть все нюансы конфигурации и особенности поведения старой версии софта при переносе в новую версию вообще считай невозможно.
OSPF часто используют как магическую технологию, где прописал очень мало чего и все ок. О суммаризации подобных маршрутов начинают думать только тогда, когда их становится много.
В данном случае вышло так, что эти маршруты были отфильтрованны багом, а те кто никогда не заморачивался на суммаризации - просто столкнуться с проблемой, о решении которой они никогда не думали.
Про NAT-PT у Cisco и Juniper очень скромно написано. Да, вы этой штукой готовите переход с IPv4 на IPv6, но тут есть побочная функциональность, прямо как NAT IPv4, но о боже нет, это не NAT ;)
Важно добавить. Всё эти способы «доверяют» платформе и как правило не имеют средств защиты от компрометации загрузчика. Если кто-то задумал получить ваши ключи шифрования, совсем не надо искать их в ОЗУ, надо подменить загрузчик на тот, который и сольет все ключи. Единственная, и довольно слабая надежда на Secure Boot.
Решение проблемы - магическое, без понимания причин и следствия.
Задушив Rdp трафик, вы ничего не сделали со всем остальным трафиком, а значит потери пакетов из-за превышения емкости канала связи вас ещё догонят.
Приоритет в очередях работает совсем не так, как вам вероятно показалось. У вас нет других, конкурирующих с этой очередей, а значит приоритет - просто ничего не значащая цифра.
Изучите то, что называется QoS, прежде, чем делать непонятно что. В вашем случае, вам надо изучать нагрузку на интернет канал в целом, вероятно там у вас возрос трафик и пошёл отброс пакетов как попало. После внедрения полноценного QoS на сети (хотя-бы на Edge роутере), вы кардинально порешаете многие сетевые проблемы в компании. Но тема эта не простая, для упрощения написано уже масса скриптов, решающих задачу генерации сотен правил.
Я попробовал на 7.1.2
И заметил такую вещь, если у вас GRE с маской 30, то установка OSPF peer в режим p2p - будет проблема, нескончаемый exchange.
Установка в broadcast или смены ip на настоящий p2p (маска 32) - решает проблему.
Однако есть ещё проблема, то ли она в OSPF то ли IPSec/GRE/L2TP, но линки очень часто переходят в exchange и частично ломают маршрутизацию. Я написал им в поддержку на этот счёт, жду ответа.
Ну вылизывать можно было очень долго еще.
Так они приняли волевое решение и начали уже активную миграцию на 7-ку, да, багов много...
Мне тоже сегодня ответили :)
В случае с бриджем, мы получаем L2 там, где раньше был только L3.
Приветствую.
Для настройки вам надо сделать правильный шаблоны интерфейсов. Примеры в офф доке есть, там все вполне понятно. Надо проверить настройки зон, они мигрируют не полностью.
Для клиента с "телефона" в этой статье все расписано, просто замените подсеть на свою.
Все верно, только я имел ввиду клиентов без OSFP, а обычных Windows или любых других Road warriors.
Если у пира есть OSFP, то его адрес анонсирует я без проблем.
Пробовал, нет изменений.
Написал в суппорт вчера, но ответа ещё нет, слишком мало времени прошло.
Я понимаю почему они не сделали полную автомиграцию - это очень не просто само по себе, да и учесть все нюансы конфигурации и особенности поведения старой версии софта при переносе в новую версию вообще считай невозможно.
Я все варианты пробовал, маршруты до /32 не раздаются.
Ваше непонимание понятно.
OSPF часто используют как магическую технологию, где прописал очень мало чего и все ок. О суммаризации подобных маршрутов начинают думать только тогда, когда их становится много.
В данном случае вышло так, что эти маршруты были отфильтрованны багом, а те кто никогда не заморачивался на суммаризации - просто столкнуться с проблемой, о решении которой они никогда не думали.
Про рекурсию - проверю в лабе, у меня куча мест, куда я точно не хочу ехать в ближайшее время.
Пробовал все варианты, ни один не работает. В листинге из статьи как раз есть такой интерфейс.
Ещё не успел, надо было обходняк сделать.
Он не мигрирует конфигурацию автоматом, в этом могут быть сложности.
Я в контексте не верно понял.
Про NAT-PT у Cisco и Juniper очень скромно написано. Да, вы этой штукой готовите переход с IPv4 на IPv6, но тут есть побочная функциональность, прямо как NAT IPv4, но о боже нет, это не NAT ;)
Для десятков тысяч малых предприятий - это непозволительная роскошь.
Сама по себе статья имеет место для существования, однако методы и подходы предложенные в ней не являются глубоко продумаными и обоснованными.