И заметил такую вещь, если у вас 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.
Прошу, читайте: https://m.habr.com/en/post/331544/
И вообще, по теме QoS на habr.com много статей, моя тут не одна лежит годами, в то время как молодые авторы пишут что-то свое, не проверив, а стоит ли. Есть куча статей, которые нуждаются в работе сообщества, но молодые редко используют поиск или не умеют его использовать.
Я попробовал на 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 ;)
Для десятков тысяч малых предприятий - это непозволительная роскошь.
Сама по себе статья имеет место для существования, однако методы и подходы предложенные в ней не являются глубоко продумаными и обоснованными.
Прошу, читайте:
https://m.habr.com/en/post/331544/
И вообще, по теме QoS на habr.com много статей, моя тут не одна лежит годами, в то время как молодые авторы пишут что-то свое, не проверив, а стоит ли. Есть куча статей, которые нуждаются в работе сообщества, но молодые редко используют поиск или не умеют его использовать.