antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 19 Январь , 2012

 

Подключение к двум провайдерам с помощью рутера Cisco и автопереключение каналов методом Cisco IP SLA ICMP Echo Operations

 

Часть 1: обеспечение автопереключения каналов.

Предположим, у вас есть рутер Cisco и вам надо подключиться сразу к двум провайдерам Интернета, ибо для вас наличие подключения к Интернет критично. Положим, вы можете или уже настроили свой рутер для подключения к одному провайдеру, и он у вас выполняет функции NAT\PAT, firewall и т.д. Т.е. как всё это сделать вы знаете. Но не знаете, как подключить второго провайдера и настроить рутер таким образом, чтобы переключение на резервный канал при “отсутствии Интернета” через основной канал и обратное переключении при нормализации основного канала осуществлялось автоматически. Отлично, данная статья поможет вам в этом.

Но сначала прочтите пару примечаний[1][2].

 

Вернемся к делу. Для начала давайте разберемся, что мы будем понимать под “пропаданием Интернета” и как его распознавать. Что касается распознавания, то, наверняка, большинство логически мыслящих обычных людей сразу подумают о пинге чего-то. Что ж, отличный вариант, причем у Cisco он представлен и называется “IP SLA ICMP Echo Operations”. Почитать в оригинале можно здесь (ссылка для IOS версии 12.4T, ибо я её и использую. Если у вас не эта, просто погуглите).

Следующий вопрос: “А что же пинговать?”. Вариант со шлюзом основного провайдера, так же как и любого устройства в его сети предлагаю отбросить, ибо (у нас, например) нередки ситуации, когда до провайдера соединение есть, а вот дальше – нет. Что тогда? Ну, можно выбрать хоть google.com или microsoft.com. Тоже варианты. Я же выбрал немного другой вариант – один из около 20-ти корневых DNS серверов Интернета.

Корневые DNS сервера обеспечивают работу всего Интернета, так что они сверхнадежны. К тому же, они идентифицируются (и резервируются) по ip адресам, а не DNS именам с кучей разных адресов, отсюда не надо думать о предварительном разрешении имени в адрес.

Остался последний вопрос. При каких условиях переключаться на второго провайдера и когда обратно? Тут уже смотрите сами. Я считаю, что переключаться на резерв надо относительно быстро, а обратно, наоборот, с большей задержкой, убедившись в стабильности канала. Критерии тут, очевидно, стоимость и скорость\качество соединения через резервного провайдера. Но если его условия  примерно эквивалентны условиям основного, то лучше перейти на резерв относительно быстро, а назад – относительно медленно. Для конкретики остановимся на таких числах:

пусть переход на резервный канал производится через 6 секунд после начала сбоя (в частности, при потере 3-х пингов подряд, идущих каждые 2 секунды),

а обратный переход – через 1 минуту восстановления стабильности основного канала (или успехе 30-ти пингов подряд).

Тут важно не перемудрить, иначе канал будет скакать туда-сюда, или, наоборот, никогда не переключиться на резерв (или никогда не переключиться обратно).

 

Итак, теперь всё ясно. Сформулируем задачу сухим языком и дадим решение.

Условия задачи.

Пусть ISP1 и ISP2 – наши провайдеры, причем ISP1 – основной провайдер.

FE1 — интерфейс рутера, смотрящий на основного провайдера, FE2 — на резервного.

GW1 и GW2 –  ip адреса соответствующих шлюзов провайдеров.

DNS1 и DNS2 – ip адреса DNS серверов соответственно ISP1 и ISP2.

RDNS – ip адрес любого корневого DNS сервера (список можете посмотреть, например, здесь. Пропингуйте и выберите сервер, который пингуется для вас стабильно и с минимальными задержками).

Цель.

Обеспечить подключение к Интернет через обоих провайдеров, но так, чтобы основным был ISP1 и при недоступности соединения с Интернет через ISP1, происходило переключение на ISP2. Причем переключение на резерв должно происходить при 6-ти секундной недоступности\нестабильности основного канала, а обратно – при восстановлении и стабильности основного канала в течении 1 минуты.

 

Что мы делаем.

1. Во-первых, подключаем и настраиваем второго провайдера точно так же, как сделали с первым. Настраиваем firewall и т.п. (кроме NAT, с ним разберемся позже)

2. Во-вторых, пишем для него маршрут по умолчанию, но с заданным вручную Administrative distance[3].

3. Самое главное, конфигурируем IP SLA в варианте ICMP Echo Operations.

 

А вот и конфиг с IP-SLA:

! Настройки IP SLA и его запуск
ip sla 1
icmp-echo RDNS source-interface FastEthernet1
threshold 400
timeout 1000
frequency 2
ip sla schedule 1 life forever start-time now
...
! Трекинг, отслеживающий события согласно нашему IP SLA
track 10 ip sla 1 reachability
delay down 6 up 60                                               
...
! Статические маршруты, включая маршрут до корневого DNS сервера.
ip route 0.0.0.0 0.0.0.0 GW1 track 10 name Primary line
ip route 0.0.0.0 0.0.0.0 GW2 4 name Secondary line with Admin distance equal to 4
ip route RDNS 255.255.255.255 GW1 name 2Check_ISP1

 

Итого:

3 неудачных пинга подряд, один в 2 секунды с максимальным временем ожидания каждого 1 сек — состояние изменится в Down (т.о. через 6 секунд после начала проблем с каналом он “отключится”),

30 успешных пингов подряд — состояние изменится в Up (т.о. через 60 секунд после нормализации основного канала он “включится” обратно)[4].

 

 

Ален Даниелян


[1] Примечание 1. По ходу повествования я часто буду писать “переключение каналов”, “отключение линии” и т.п.. На самом деле, будет производиться не переключение каналов или даже отключение соответствующего интерфейса рутера (что тоже возможно сделать), а просто удаление и возврат маршрута по умолчанию для подключения через основного провайдера.

Возможны и другие неточности в терминологии, но тут уже не моя вина, ибо я вообще не специалист по Cisco, а вина Сергея Федорова (он же Sergey Fedorov, он же Fedia), жестокого инженера-мафиози, который отбирает у доверчивых русскоговорящих туристов документы и заставляет писать статьи про Cisco. При этом кормит он нас вкусной, но фальшивой красной икрой без хлеба и липовым, во всех отношениях, медом. Прошу передать родным, что я жив и даже поправился, но страдаю сильной изжогой.

[2] Примечание 2. Статья будет довольно подробной и покажется избыточной по наполнению для нормальных специалистов (скажем, уровня CCNP или даже CCNA), прошу меня простить. Виноватого указал выше.

[3] Примечание 3. Что такое Administrative distance очень хорошо и коротко описано здесь, если просто, считайте, что Admin distance определяет нечто вроде приоритета маршрута при прочих равных (sic!), и, чем меньше его значение, тем выше приоритет маршрута.

По умолчанию, каждый “источник” маршрута имеет предопределенное значение Admin distance для всех своих маршрутов. Под источником я понимаю: метод или протокол, порождающий маршрут: статический или полученный посредством одного из протоколов динамической маршрутизации. Так, статический маршрут через интерфейс имеет Admin Distance = 0, обычный статический маршрут через Next Hop – 1 и т.д. Подробности смотрите по ссылке.

Т.к. в нашем примере маршрут по умолчанию мы задаем статически через Next Hop, то согласно Cisco его Administrative distance равен 1, поэтому Administrative distance для маршрута через резервного провайдера надо задать больше единицы. Я выбрал “4” – больше 1, но меньше величины, предусмотренной для протоколов маршрутизации. Мне просто так показалось правильным (захотелось, короче).

[4] Примечание 4. Немного информации по параметрам ip sla. (Внимание! Информация верна только для использованного нами IP SLA ICMP Echo Operations, в IP SLA других типов, а их куча, параметры могут иметь другой смысл):

timeout – это время ожидания ответа на пинг, в msec. Я выбрал 1000, ибо большее значение, скорее всего, означает нестабильность канала. Однако, это может быть также вызвано перегруженностью канала. Рекомендую установить в пределах 1000-2000 msec. Если же вы уверены в достаточности ПС вашего канала, можете использовать значения поменьше.

frequency – это периодичность пингов, в sec

threshold – предельное время, после которого можно зафиксировать событие несоответствия канала желаемому \ декларируемому качеству (скажем, на лог-сервере с помощью SNMP и пр. дополнительных инструментов). В нашем примере, данный параметр не играет роли, не берите в голову. Задается в msec.

Просто запомните, что должно соблюдаться неравенство:

threshold <= timeout <= frequency.

 

 

Метки: , , ,
Опубликовано: Маршрутизаторы и коммутаторы

 

One Response to “ISP Failover-Failback using IP SLA ICMP Echo Operations, p.1”

comment rss - Trackback

  1. m2s:

    Ссылки [1] и [2] не работают. 🙁

» Оставить комментарий

Вы должны войти чтобы прокомментировать.