Комментарии 5
Какой ужас:
Два интернет-провайдера (ISP) используются в режимах активный/ожидания с помощью статических маршрутов
нет, они обычно используются с использованием бегепе.
У меня два вопроса.
Зачем?
Чтобы что?
Данные упражнения сегодня актуальны исключительно в академический целей, но в прод такое пускать категорически не рекомендуется.
Сегодня используются совершенно иные технологии, для того предназначенные. Bgp, eigrp, технологии L2, и иные инструменты, которые умеют не только в 2 isp.
Основной недостаток описанного решения - не гарантированный и не явный возврат на поднявшийся канал обратно.
Второй не менее важный недостаток - это необходимость платить за неиспользуемый канал. Куда лучше использовать технологии, которые умеют в балансировку нагрузки. Для этого даже не нужно IP SLA если есть два маршрутизатора, которые умеют любой протокол динамической маршрутизации... А на схеме они есть. Отсюда и выглядит данное решение как минимум странным.
Третий недостаток - проблемы с управлением входящим трафиком, особенно при NAT/PAT. Изначально айпиосел предназначен не для этого вообще, и умеет только в исходящий трафик. А что делать с входящим - предмет отдельных упражнений с присяданиями.
Четвёртая грабля - всякие там туннели,ipsec и иная инкапсуляция.
Проблема номер пять - а если провайдеров не 2,а три, пять, семь? А интерфейсов 2... И вот уже саб интерфейсы, с которыми есть свои сложности, а если, не дай вам Один, ещё и адресации на loop back...
Короче это то ещё развлекалово.
На крайняк, можно использовать vrf и имея два дефолта вполне можно запилить intervrf routing и получить желаемое. Это ещё и решит проблему со входящим трафиком,если таковой вдруг появится...
Bgp, eigrp, технологии L2, и иные инструменты
Не согласен с этим утверждением, таким технологиям есть место. Полно объектов, подключаемых через LTE, спутник, xDSL. Есть операторы, у которых за BGP (и за публичные адреса для его работы) надо доплачивать, а то и брать канал минимальной емкости. Но в статье описан довольно примитивный сценарий использования этого инструмента. Люди используют технологию для изменения путей трафика в случае ухудшения качественных характеристик внешних каналов (пошел джиттер по голосу — переключить на другой канал).
Так с этим ни кто и не спорит, но не IP SLA единым, как говорится.
Если входящий трафик не важен, то что мешает настроить тот же eigrp внутри сети и настроиь variance 4 например? Будут доступны обы шлюза, трафик разольется равномерно между каналами, не только по отказу, но и по перегрузке, а при отказе одного - весь трафик пойдёт по живому линку. При этом логика сработает не только по падению линка, но и по ухужшению параметров [см формулу расчёта метрики в eigrp].
Среда передачи тут не имеет значения.
Если хочется в QoS, то можно использовать bgp и краску, для управления потоками. Данный протокол это умеет. Если оборудования достаточно, 4 и более устройств - можно заюзать плюшки mpls +bgp te. Это позволит избавиться от ограничений L3 на транспорте. И в некоторых случаях даже позволит управлять входящим трафиком, без собственной пкбличной AS.
Просто IP SLA - это инструмент, который позволяет изменять конфигурацию на основе измерения довольно ограниченных показателей.
Например я использую его в своей инфре, для изменения принципов маркировки исходящего трафика, в зависимости от уровня потерь udp пакетов до voip шлюза оператора.
Для активного мониторинга качества каналов, чтобы сразу получать данные анализа и статистики по snmp.
Для оценки эффективности текущих конфигураций.
Но за выбор маршрута прохождения трафика должен отвечать именно протокол маршрутизации, благо их больше чем один и можно выбрать наиболее подходящий.
Можно ли менять дефолт роут с помощью айпиосла? Конечно! Но на сколько это эффективно, если в наличии есть более подходящие инструменты? Я вот к чему.
Пример из жизни, место где ip-sla действительно выручает - на 4500X SVI клиента, в который сроучена крупная сеть (/24 и больше), сам клиент при этом физически включен дальше в другой коммутатор. Соответственно при падении клиента, SVI остается живым и маршрут остается в таблице. Коммутатор при этом начинает генерировать арпы в гигантских количествах, одно из ядер сразу становится в полку. Ограничение арпов контрол плейном эту проблему не решает, так как ограничивает все арпы вообще. А вот привязка трекинга к нужному маршруту отлично избавляет от таких проблем
Глубокое погружение в IP SLA на границе интернета