Хочу заметить, что часто значение MED фильтруется, поэтому метод с его изменением не является надёжным.
Лучшим вариантом в данном случае было бы добавление AS (as-prepend) к параметру AS_PATH, тогда будет точно выбран путь с более коротким значением.
Заменяем set metric 30 на set as-path prepend 65500 65500 65500 на роутере, канал к которому хотим сделать резервным для входящих подключений.
На основном можно ничего не настраивать.
Хей-хо, товарищи.
Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.
На Cisco это решается так:
1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).
Так что рискну предположить, для полного понимания работы системы, описанной в посте, не хватает конфигурации NAT.
Пепельняк в своей книге тоже говорит, что худший load выбирается…
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
Reliability is the worst reliability for any interface in the path. Load is cumulative.
Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.
Если мне не изменяет память, EIGRP передаёт векторную метрику при изменении BW или delay. При добавлении в расчёт reliability и load это поведение не меняется.
То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.
Они это мотивировали тем, что для Wasteland весь сюжет, мир и т.д. уже написаны и проработаны, осталось реализовать. Так что теперь либо разгонять штат писателей, либо дать им новую работу. Вот как раз Торментом и займутся.
Если бы мы кто-то хотел прочитать маркетинговый материал Хуавея, он бы легко это сделал и в другом месте.
Здесь нужны интересные статьи. Например, «мы внедряли, выбрали такое-то железо по такой-то причине, с такими-то технологиями, столкнулись с такими-то проблемами и выкрутились вот так».
А «покупайте наших слонов» на хабре ни к чему.
...per default router would load balance per prefix. So if you have 10 prefixes learned over two equal-cost pathes then traffic destined to 5 out of 10 prefixes would be forwarded over one path and another 5 would go over other path.
Now if you define «per-packet» it will load-balance per flow. L4 information is taken in account in this case. The name «per-packet» is highly misleading but it has historical reasons. No reordering will ever take place!
Если есть несколько маршрутов до цели, берётся набор next-hop`ов, хешируется и выбирается 1. Таким образом, балансировки нет.
Если включить load-balance per-packet, то:
1. На Internet Processor ASIC включается именно per packet балансировка.
2. На Internet Processor II ASIC включается балансировка per flow.
А, кстати, почему зона 0 должна быть непрерывной? В RFC про это не сказано.
Рискну предположить, что ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.
Насчёт условия считания себя ABR в RFC написано, что просто должен принадлежать нескольким зонам. Хотя в Cisco надпись «It is an area border router» не появится, пока не дашь ему ещё и интерфейс в 0 зоне.
Лучшим вариантом в данном случае было бы добавление AS (as-prepend) к параметру AS_PATH, тогда будет точно выбран путь с более коротким значением.
Заменяем set metric 30 на set as-path prepend 65500 65500 65500 на роутере, канал к которому хотим сделать резервным для входящих подключений.
На основном можно ничего не настраивать.
Я тут наткнулся на решение схожей задачи на Cisco (выпустить людей, находящихся в VRF, в интернет), и, думаю, оно нам может немного помочь.
На Cisco это решается так:
1. Создаём маршрут по умолчанию для VRFа, который будет брать next-hop из глобальной таблицы адресов. Это указывается словом global в конце команды ip route…
2. Включаем NAT обычным образом, указав в конце команды ip nat inside… ключевые слова VRF xxx. Тогда (ход конём!) внутренние адреса (inside local) берутся из VRF xxx, а интерфейс, куда будет натиться (inside global) берётся из глобальной таблицы.
Когда трафик возвращается назад, NAT отрабатывает раньше роутинга и помещает пакеты в нужный интерфейс (и VRF соответственно).
Так что рискну предположить, для полного понимания работы системы, описанной в посте, не хватает конфигурации NAT.
Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
Источник: www.routeralley.com/ra/docs/eigrp.pdf
Почему выкинуть? Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.
Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.
То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.
Неужели в городе N превалируют *nix-администраторы? о_О
Мне казалось, обычно бывает наоборот.
Здесь нужны интересные статьи. Например, «мы внедряли, выбрали такое-то железо по такой-то причине, с такими-то технологиями, столкнулись с такими-то проблемами и выкрутились вот так».
А «покупайте наших слонов» на хабре ни к чему.
Если есть несколько маршрутов до цели, берётся набор next-hop`ов, хешируется и выбирается 1. Таким образом, балансировки нет.
Если включить load-balance per-packet, то:
1. На Internet Processor ASIC включается именно per packet балансировка.
2. На Internet Processor II ASIC включается балансировка per flow.
Спасибо!
Рискну предположить, что ABR отбрасывает LSA 3 типа и выше, если не имеет LSA 1 про Advertising Router.
Насчёт условия считания себя ABR в RFC написано, что просто должен принадлежать нескольким зонам. Хотя в Cisco надпись «It is an area border router» не появится, пока не дашь ему ещё и интерфейс в 0 зоне.
Damn, опередили)