Настройка резервного провайдера cisco

Обновлено: 04.07.2024

На этой странице описывается как настроить резервирование провайдеров без использования BGP.

При решении этой проблемы иногда возникает ряд проблем. Как правило, они связаны с небольшими нюансами. Без которых, однако, решение не работает корректно.

Для решения задачи резервирования провайдеров без BGP, требуется взаимодействие большого количества технологий и функций. Тут описаны кратко это технологии, а так же как их использовать для решения этой задачи.

Ранее на этой странице были лабораторные. Они перенесены на страницу Резервирование Интернет-каналов без использования BGP/Lab.

Эта же информация обзорно описана в презентации

Содержание

Для настройки резервирования требуется совмещение нескольких технологий:

Статическая маршрутизация
IP SLA
Track (Enhanced Object Tracking)
Local PBR
NAT
EEM (Embedded Event Manager)

В зависимости от того, какая схема работы требуется, могут понадобиться также и другие технологии:

Основное описание будет в разделе с описанием схемы с одним пограничным маршрутизатором и без балансировки нагрузки. Настройки, которые потребуются для других схем подключения, описаны в соответствующих разделах, но с учетом того, что основная часть описана в первой части. Поэтому, стоит начать с нее, даже если используется другая схема.

Краткое описание используемых технологий и задач, которые они решают:

IP SLA — IP SLA тесты будут мониторить несколько ресурсов в Интернет.
Local PBR — политика PBR для тестов IP SLA. Политика будет отправлять пакеты, которые генерирует тест, на определенного провайдера
Track — следит за соответствующим тестом IP SLA, а суммарный track объединяет их в один объект
Статическая маршрутизация — к маршруту по умолчанию на основного провайдера надо применить суммарный трек. На резервного провайдера настроить маршрут по умолчанию со значением AD, большим чем 1
NAT — правила динамической трансляции, с использованием route-map
EEM — сценарий EEM будет автоматически очищать таблицу трансляции, после переключения между провайдерами

IP SLA позволяет создавать тесты.

Один из самых простых примеров теста: проверка доступности ресурса с помощью простого “ping” (отправки ICMP-запроса и ожидания ICMP-ответа).

IP SLA нужен для того чтобы была возможность проверить ходит ли трафик через провайдера. И, если трафик не ходит, в ответ, выполнять переключение на резервного провайдера.

IP SLA, за время существования, сменил несколько вариантов настройки. Поэтому, настройка в другой версии IOS может отличаться от указанной.
Мониторить лучше стабильные ресурсы.
В тесте обязательно надо указывать IP-адрес отправителя или интерфейс.

Threshold – устанавливает верхнее пороговое значение для измерения RTT (round-trip time)
Timeout – период времени, который IOS ожидает ответ на пакеты теста
Frequency – частота отправки тестовых пакетов

Настройка IP SLA тестов (icmp-echo)

Проверить состояние тестов в кратком отображении:

Посмотреть более развернутую статистику по тесту:

Маршрутизация на основе политик (policy based routing, PBR):

позволяет маршрутизировать трафик на основании заданных политик, тогда как в обычной маршрутизации, только IP-адрес получателя определяет каким образом будет передан пакет
основной объект с помощью которого настраивается PBR: route-map
PBR может применяться, как для сквозного трафика, так и для трафика, который генерируется маршрутизатором.

Настройка Local PBR нужна для того, чтобы, при переключении провайдера, пакеты теста IP SLA шли через основного провайдера. Соответственно, в ACL, который использует route-map, должен быть описан трафик тестов IP SLA.

Настройка Local PBR:

Если PBR работает, то счетчики должны быть ненулевыми:

Второй вариант проверки. Тут также видно явно, что route-map применена:

Enhanced Object Tracking (track) — это функция оборудования Cisco, которая позволяет отслеживать состояние выбранного объекта и влиять на состояние других функций.

IP SLA не может быть напрямую применен к другим объектам. Для того чтобы маршрут по умолчанию зависел от результатов теста, нужно создать track, которые отслеживает состояние IP SLA и, в зависимости от ответа, переходит в состояние UP или DOWN.

Каждый track (10,20,30) отслеживает свой тест IP SLA:

Суммарный track настраивается для того, чтобы причиной переключения не было состояние одного объекта. Для каждого теста IP SLA есть свой track, которые потом объединяются в один суммарный.

Суммарный track 100 объединяет созданные track. Настройка “boolean or” обозначает, что суммарный track будет в состоянии UP, если хотя бы один из track в состоянии UP:

Параметр “delay” в настройке track 100 нужен для того, чтобы track переходил в состояние DOWN с задержкой. Иначе, как только пропадет хотя бы один пакет ICMP, track перейдет в состояние DOWN.

Параметр delay настраивается в соответствии с частотой отправки ICMP-запросов.

В нашем примере, частота 3 секунды, а задержка на переход в состояние DOWN 10 секунд. То есть, track 100 перейдет в состояние DOWN только если все тесты перестали получать ответы. И не получили, как минимум 3 ответа.

Аналогично с переходом в состояние UP.

Статический маршрут остается в таблице маршрутизации до тех пор, пока маршрутизатор может найти путь к next-hop. Но, если проблема находится внутри сети провайдера, или за ее пределами, с помощью обычного статического маршрута её обнаружить нельзя.

Для того чтобы решить эту проблему, настроенные ранее IP SLA тесты, через суммарный track, применяются к статическому маршруту по умолчанию.

Применение суммарного track к маршруту по умолчанию, который ведет к основному провайдеру:

Маршрут по умолчанию к резервному провайдеру с AD 250:

Просмотр таблицы маршрутизации с параметром track-table позволяет просмотреть маршруты, к которым применен track:

Состояние суммарного track:

Если на маршрутизаторе Cisco созданы два правила для динамической трансляции, он выбирает правило в порядке создания. К сожалению, не учитывается то, через какой интерфейс маршрутизируется пакет.

Поэтому, когда на маршрутизаторе два outside интерфейса, правила трансляции необходимо настраивать с route-map:

При переключении между провайдерами, возникает проблема с подвисшими сессиями (как правило, TCP). Для её решения используется EEM. EEM автоматически очищает таблицу трансляций, после каждого переключения.

Обратите внимание, что route-map могут использоваться в разных областях. Например:

как фильтры маршрутов
для настройки PBR
для настройки политик BGP
для NAT

Смысл команд внутри route-map, в зависимости от области применения, может меняться. Поэтому, при чтении документации, нужно обращать внимание на то, к каком контексте используется route-map.

В этом контексте, route-map чем-то похожи на ACL. ACL также, в зависимости от области применения, может выполнять разные действия.

Функционал встроенный в Cisco IOS, который позволяет создавать сценарии для автоматизации работы устройств.
Причиной для выполнения сценария является событие.
- Например, событием может быть изменение состояния track, запуск сценария вручную, выполнение команды и другие.
Краткое описание используемых технологий и задач, которые они решают:
- NAT — правила динамической трансляции, с использованием route-map
- EEM — сценарий EEM будет автоматически очищать таблицу трансляции, после переключения между провайдерами
- IP SLA — IP SLA тесты будут мониторить несколько ресурсов в Интернет. Так как, по умолчанию, будут использоваться оба провайдера, то тесты должны быть настроены для каждого их них
- Local PBR — политика PBR для тестов IP SLA. Политика будет отправлять пакеты, которые генерирует тест, на определенного провайдера
- Track — следит за соответствующим тестом IP SLA, а суммарный track объединяет их в один объект
- Балансировка нагрузки:
  - Статическая маршрутизация — к каждому провайдеру прописан статический маршрут по умолчанию, и к каждому из них применен суммарный трек
  - PBR
  - Пропорциональная балансировка с помощью статических маршрутов
  Основное описание технологий и настроек находится в разделе с описанием схемы с одним пограничным маршрутизатором и без балансировки нагрузки (в первом разделе).
  
  Настройки, которые потребуются для этой схемы подключения, описаны в соответствующих разделах, но с учетом того, что основная часть описана в первой части. Поэтому, стоит начать с прочтения первого раздела, даже если используется другая схема.
  
  Настройки NAT аналогичны:
  
  IP SLA тесты для разных провайдеров могут быть разные, или одни и те же.
  
  В этом примере тесты разные.
  
  Настройка IP SLA тестов (icmp-echo) для ISP 1:
  
  Настройка IP SLA тестов (icmp-echo) для ISP 2:
  
  Настройка Local PBR для тестов на ISP1:
  
  Настройка Local PBR для тестов на ISP2:
  
  Каждый track (10,20,30) отслеживает свой тест IP SLA для ISP1:
  
  Суммарный track 100 объединяет созданные track для ISP1:
  
  Каждый track (110,120,130) отслеживает свой тест IP SLA для ISP2:
  
  Суммарный track 200 объединяет созданные track для ISP2:
  
  Если настроить два равнозначных статических маршрута (с суммарными трек), то в таблице маршрутизации будут оба маршрута и балансировкой трафика будет заниматься CEF:
  
  CEF балансирует трафик на основании пары IP-адрес отправителя и получателя. Поэтому наилучшее распределение трафика будет, если количество адресов большое.
  
  Некоторые платформы позволяют добавлять в алгоритм балансировки порты:
  
  Добавление портов в выбор пути, позволяет улучшить равномерность распределения трафика между провайдерами.
  
  Балансировку можно настроить с помощью PBR.
  
  Тут показан пример, когда балансировка выполняется просто по адресам отправителя: пакеты с четными адресами отправителя отправляются на ISP1, с нечетными -- на ISP2.
  
  Эти настройки лучше добавить к конфигурации с балансировкой в предыдущем разделе (два равнозначных статических маршрута). Пакеты, которые описаны в PBR, будут маршрутизироваться по правилам PBR. Но, если пакет не попадает под эти правила, или один из треков, который привязан к next-hop, упадет, пакеты будут маршрутизироваться по стандартной таблице маршрутизации.
  
  Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
  
  Содержание
  
  Введение
  
  В этом документе описывается настройка резервного интернет-провайдера в луче Dynamic Multipoint VPN (DMVPN) с помощью функции Virtual Routing and Forwarding-Lite (VRF-Lite).
  
  Предварительные условия
  
  Требования
  
  Перед выполнением описанной в этом документе настройки компания Cisco рекомендует ознакомиться со следующими темами:
  
  Используемые компоненты
  
  Сведения в этом документе основываются на Cisco IOS® Version 15.4 (2) T.
  
  Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
  
  Общие сведения
  
  VRF — это технология, имеющаяся в маршрутизаторах сетей IP, которая позволяет нескольким экземплярам таблицы маршрутизации сосуществовать в маршрутизаторе и работать одновременно. Это расширяет функциональные возможности, поскольку позволяет сегментировать сетевые пути без использования нескольких устройств.
  
  Использование услуг двух интернет-провайдеров с целью резервирования стало общей практикой. Администраторы используют два канала поставщика услуг Интернета; один из них является основным подключением, а другой — резервным.
  
  Такой же принцип может быть реализован для резервирования DMVPN на конечном маршрутизаторе с использованием двух поставщиков услуг Интернета. Этот документ призван продемонстрировать, как можно разделить таблицу маршрутизации с помощью VRF-Lite, когда конечный маршрутизатор подключен к двум поставщикам услуг Интернета. Для того чтобы обеспечить резервирование пути для трафика, проходящего через туннель DMVPN, используется динамическая маршрутизация. В примерах конфигурации, которые описаны в этом документе, используется следующая схема конфигурации:
  
  Функция VRF-Lite позволяет реализовать на конечном маршрутизаторе DMVPN несколько экземпляров VPN маршрутизации/перенаправления. Функция VRF-Lite принуждает трафик из нескольких интерфейсов туннеля Multipoint Generic Routing Encapsulation (mGRE) использовать соответствующие им таблицы маршрутизации VRF. Например, если основной поставщик услуг Интернета оканчивается в ISP1 VRF, а дополнительный поставщик услуг Интернета оканчивается в ISP2 VRF, трафик, формируемый в ISP2 VRF, будет использовать таблицу маршрутизации ISP2 VRF, а трафик, формируемый в ISP1 VRF, будет использовать таблицу маршрутизации ISP1 VRF.
  
  Преимущество, которое дает использование наружной функции VRF (fVRF), главным образом заключается в возможности образования отдельной таблицы маршрутизации из глобальной таблицы маршрутизации (в которой имеются интерфейсы туннелей). Использование внутренней функции VRF (iVRF) позволяет определить частное пространство для хранения информации о DMVPN и частной сети. Обе эти конфигурации обеспечивают дополнительную защиту от атак на маршрутизатор из Интернета, где сведения о маршрутизации разделяются.
  
  Эти конфигурации VRF можно использовать и на концентраторах, и на конечных маршрутизаторах DMVPN. Это дает большое преимущество по сравнению с вариантом, когда оба поставщика услуг Интернета оканчиваются в глобальной таблице маршрутизации.
  
  Если оба поставщика услуг Интернета оканчиваются в глобальной VRF, они будут использовать одну таблицу маршрутизации, а работа обоих интерфейсов mGRE будет основана на глобальной информации о маршрутизации. В этом варианте в случае отказа основного поставщика услуг Интернета интерфейс основного поставщика услуг Интернета может сохранить работоспособность, если точка отказа находится в магистральной сети поставщика услуг Интернета, а не подключена к этому интерфейсу напрямую. При этом возникает ситуация, когда оба интерфейса туннелей MGRE продолжают использовать маршрут по умолчанию, который указывает на основного поставщика услуг Интернета, из-за чего происходит сбой резервирования DMVPN.
  
  Хотя существуют некоторые обходные пути для устранения этой проблемы без использования VRF-Lite, основанные на скриптах IP Service Level Agreements (IP SLA) или Embedded Event Manager (EEM), они далеко не всегда являются лучшим выбором.
  
  Методы развертывания
  
  В этом разделе приведены краткие обзоры разделенного туннелирования и туннелей между конечными маршрутизаторами.
  
  Раздельное туннелирование
  
  Когда сведения об определенных подсетях или итоговых маршрутах поступают через интерфейс mGRE, это называется разделенным туннелированием. Если сведения о маршруте по умолчанию поступают через интерфейс mGRE, то это называется tunnel-all.
  
  В примере конфигурации, предоставленном в этом документе, показано разделенное туннелирование.
  
  Туннели между конечными маршрутизаторами
  
  Приведенный в этом документе пример конфигурации является хорошим вариантом для метода развертывания (когда информация о маршруте по умолчанию поступает через интерфейс mGRE).
  
  При использовании двух fVRF формируются отдельные таблицы маршрутизации, что обеспечивает перенаправления пакетов, инкапсулированных после GRE, соответствующей fVRF. Это позволяет гарантировать, что туннель между конечными маршрутизаторами будет использовать активного поставщика услуг Интернета.
  
  Настройка
  
  В этом разделе описывается процедура настройки резервирования поставщиков услуг Интернета на конечном маршрутизаторе DMVPN посредством функции VRF-Lite.
  
  Схема сети
  
  Именно эта топология используется в примерах, приведенных в этом документе:
  
  Настройка концентратора
  
  Вот некоторые замечания о соответствующей конфигурации на концентраторе:
  Примечание. В этот пример включены только соответствующие разделы конфигурации.
  
  Настройка конечного маршрутизатора
  
  Вот некоторые замечания о соответствующей конфигурации на конечном маршрутизаторе:
  Примечание. В этот пример включены только соответствующие разделы конфигурации.
  
  Проверка
  
  Используя информацию из этого раздела, проверьте правильность работы своей конфигурации.
  
  Основной и дополнительный поставщики услуг Интернета активны
  
  В этом варианте проверки и основной и дополнительный поставщики услуг Интернета активны. Вот некоторые дополнительные примечания об этом варианте:
  Далее приведены соответствующие команды show, с помощью которых можно проверить свою конфигурацию в этом варианте:
  
  Основной поставщик услуг Интернета не работает / дополнительный поставщик услуг Интернета активен
  
  В этом варианте время таймеров EIGRP Hold заканчивается для отношений соседства через Tunnel0, когда канал ISP1 выходит из строя, а маршруты к концентратору и другим конечным маршрутизаторам теперь указывают на Tunnel1 (реализованный с помощью Ethernet0/1).
  
  Далее приведены соответствующие команды show, с помощью которых можно проверить свою конфигурацию в этом варианте:
  
  Восстановление канала основного поставщика услуг Интернета
  
  Когда связь через основного поставщика услуг Интернета восстановится, сеанс шифрования Tunnel0 станет активным, а предпочтение будет отдаваться маршрутам, информация о которых получена через интерфейс Tunnel0.
  
  Устранение неполадок
  
  Для поиска и устранения неполадок с конфигурацией включите debug ip eigrp и logging dmvpn.
  
  Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
  
  Содержание
  
  Введение
  
  В этом документе описывается настройка многофункционального устройства обеспечения безопасности Cisco ASA серии 5500 для использования функции отслеживания статических маршрутов, чтобы устройство могло использовать избыточные или резервные интернет-соединения.
  
  Предварительные условия
  
  Требования
  
  Для этого документа отсутствуют особые требования.
  
  Используемые компоненты
  
  Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
  Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
  
  Родственные продукты
  
  Эту конфигурацию также можно использовать с версией 9.1(5) Cisco ASA серии 5500.
  
  Общие сведения
  
  В этом разделе представлен обзор функции отслеживания статических маршрутов, которая далее подробно рассматривается в данном документе, а также приведены важные аспекты, которые нужно учитывать перед началом работы.
  
  Обзор функции отслеживания статических маршрутов
  
  Одна из проблем, связанных с использованием статических маршрутов, заключается в том, что не существует встроенного механизма, который мог бы определить, функционирует ли маршрут. Маршрут остается в таблице маршрутизации, даже если шлюз следующего перехода становится недоступен. Статические маршруты удаляются из таблицы маршрутизации, только если соответствующий интерфейс в устройстве безопасности прекращает работу. Для решения этой проблемы используется функция отслеживания статических маршрутов, которая позволяет отслеживать доступность статического маршрута. Эта функция при сбое статического маршрута удаляет его из таблицы маршрутизации и заменяет резервным маршрутом.
  
  Отслеживание статического маршрута позволяет ASA использовать экономичное подключение к вторичному поставщику услуг Интернета, если основная выделенная линия становится недоступной. Для того чтобы обеспечить такое резервирование, ASA привязывает статический маршрут к целевому объекту мониторинга, который вы определяете. Операция соглашения об уровне обслуживания (SLA) выполняет мониторинг целевого объекта путем периодической отправки эхозапросов ICMP. Если эхоответ не получен, объект считается вышедшим из строя, и соответствующий маршрут удаляется из таблицы маршрутизации. А вместо удаленного маршрута используется ранее настроенный резервный маршрут. Пока используется резервный маршрут, операция мониторинга SLA продолжает попытки достичь целевой объект. Когда целевой объект снова становится доступен, первый маршрут возвращается в таблицу маршрутизации, а резервный маршрут удаляется.
  
  В примере, который используется в этом документе, ASA поддерживает два подключения к Интернету. Первое подключение — это высокоскоростная выделенная линия, доступная через маршрутизатор, предоставленный основным поставщиком. Второе подключение — это цифровая абонентская линия (DSL) с более низкой скоростью, доступ к которой осуществляется через модем DSL, предоставляемый вторичным поставщиком услуг Интернета.
  
  Примечание. Конфигурация, описываемая в этом документе, не может использоваться для распределения или балансировки нагрузки, так как это не поддерживается на ASA. Используйте эту конфигурацию только для обеспечения избыточности или резервирования. Исходящий трафик идет через основного поставщика услуг Интернета, и в случае сбоя переключается на вторичного поставщика. Сбой основного поставщика приводит в временному прекращению потока трафика.
  
  В ASA настраивается статический маршрут, который направляет весь трафик Интернета основному поставщику. Каждые десять секунд процесс мониторинга SLA проверяет, есть ли связь со шлюзом основного поставщика услуг Интернета. Если выясняется, что шлюз основного поставщика недоступен, статический маршрут, по которому трафик направляется в этот интерфейс, удаляется из таблицы маршрутизации. Чтобы заменить этот статический маршрут, устанавливается другой статический маршрут, направляющий трафик вспомогательному поставщику. Этот альтернативный статический маршрут направляет трафик вспомогательному поставщику по DSL-модему до тех пор, пока канал основного поставщика не станет доступен.
  
  Данная конфигурация представляет относительно недорогой способ обеспечить постоянный исходящий доступ к Интернету пользователям через ASA. Как показано в данном документе, такая настройка может не подойти для входящего доступа к ресурсам за ASA. Для обеспечения непрерывных входящих подключений требуются знания более сложных сетевых технологий. Эти навыки не рассматриваются в этом документе.
  
  Важные рекомендации
  
  Прежде чем приступить к настройке, которая описана в этом документе, необходимо выбрать целевой объект мониторинга, который может отвечать на эхозапросы протокола ICMP. Это может быть любой выбранный вами сетевой объект, но рекомендуется выбирать тот, который находится ближе к подключению к вашему поставщику услуг Интернета. Ниже перечислены некоторые возможные целевые объекты мониторинга:
  В этом документе предполагается, что устройство ASA находится в полностью рабочем состоянии и настроено, чтобы можно было изменять конфигурацию в диспетчере устройств Cisco Adaptive Security Device Manager.
  
  Настройка
  
  Используйте информацию, приведенную в этом разделе, чтобы настроить ASA для использования функции отслеживания статических маршрутов.
  
  Примечание. IP-адреса, которые используются в этой конфигурации, нельзя маршрутизировать в Интернет. Это адреса RFC 1918 , которые используются в лабораторной среде.
  
  Схема сети
  
  В примере, который приводится в этом разделе, используется следующая схема сети:
  
  Конфигурация интерфейса командой строки CLI
  
  Настройка посредством ASDM
  Конфигурации появятся в списке интерфейсов:
  
  Проверка
  
  Воспользуйтесь данным разделом для проверки правильности функционирования вашей конфигурации.
  
  Подтверждение завершения конфигурации
  
  Для проверки завершенности конфигурации используйте следующие команды show:
  - show running-config sla monitor — в выходных данных этой команды отображаются команды SLA в конфигурации.
  - show sla monitor configuration — в выходных данных этой команды отображаются текущие параметры действующей конфигурации.
  - show sla monitor operational-state — в выходных данных этой команды отображается текущая статистика работы SLA.
  - До сбоя основного поставщика рабочее состояние выглядит так:
  - После сбоя основного интернет-провайдера (и истечения времени ожидания эхозапроса ICMP) рабочее состояние выглядит следующим образом:
  Подтверждение установки резервного маршрута (с помощью интерфейса командной строки)
  
  Введите команду show route, чтобы удостовериться, что резервный маршрут установлен.
  
  До сбоя основного интернет-провайдера таблица маршрутизации выглядит следующим образом:
  
  После сбоя основного интернет-провайдера статический маршрут удаляется, устанавливается резервный маршрут и таблица маршрутизации выглядит следующим образом:
  
  Подтверждение установки резервного маршрута (с помощью ASDM)
  
  Для того чтобы проверить установку резервного маршрута с помощью ASDM, перейдите в раздел Monitoring > Routing (Мониторинг > Маршрутизация) и выберите Routes (Маршруты) в дереве маршрутизации.
  
  До сбоя основного интернет-провайдера таблица маршрутизации выглядит примерно так, как на следующей иллюстрации. Обратите внимание на то, что маршрут по умолчанию (DEFAULT) указывает на адрес 203.0.113.2 через внешний интерфейс:
  
  После сбоя основного поставщика его маршрут удаляется и устанавливается резервный маршрут. DEFAULT указывает на адрес198.51.100.2 через резервный интерфейс:
  
  Устранение неполадок
  
  В этом разделе приведено описание нескольких полезных команд отладки и описывается способ поиска и устранения неполадки, когда отслеживаемый маршрут был удален без надобности.
  
  Команды отладки
  
  С помощью следующих команд отладки можно искать и устранять неполадки в конфигурации:
  - Если отслеживаемый объект (шлюз основного интернет-провайдера) включен и эхозапросы ICMP успешно выполняются, выходные данные имеют следующий вид:
  - Если отслеживаемый объект (шлюз основного интернет-провайдера) не работает и эхозапросы ICMP не выполняются, выходные данные имеют следующий вид:
  - Если отслеживаемый объект (шлюз основного интернет-провайдера) включен и эхозапросы ICMP успешно выполняются, выходные данные имеют следующий вид:
  - Если отслеживаемый объект (шлюз основного интернет-провайдера) не работает и отслеживаемый маршрут удален, выходные данные имеют следующий вид:
  Ненужное удаление отслеживаемого маршрута
  
  Если отслеживаемый маршрут был случайно удален, убедитесь, что цель мониторинга всегда доступна для получения эхозапросов. Кроме того, убедитесь, что состояние объекта мониторинга (т.е. достижим ли он) тесно связано с состоянием подключения к основному поставщику.
  
  При выборе цели мониторинга, расположенной дальше шлюза интернет-провайдера, может произойти сбой другого канала на этом маршруте или другое устройство может вносить помехи. Работая с такой конфигурацией, монитор SLA может прийти к заключению, что связь с основным интернет-провайдером прервалась, и вынудить ASA выполнить ненужное переключение на канал резервного интернет-провайдера.
  
  Например, если в качестве объекта мониторинга выбран маршрутизатор филиала компании, то возможен сбой подключения поставщика к этому филиалу, а также сбой любого другого канала на всем пути. Если эхозапросы ICMP, отправляемые при выполнении мониторинга, не выполняются, основной отслеживаемый маршрут удаляется, даже если канал основного интернет-провайдера остается активным.
  
  В этом примере шлюз основного поставщика, используемый как объект отслеживания, управляется поставщиком услуг Интернета и располагается на другой стороне канала поставщика. Эта конфигурация гарантирует, что в случае невыполнения эхозапросов ICMP, отправляемых во время мониторинга, канал провайдера почти наверняка не работает.
  
  Типичная задача, которая тем не менее, продолжает вызывать массу вопросов.
  
  Попробую вкратце описать суть технологии и подводные камни.
  
  Итак, пусть у нас есть один пограничный маршрутизатор cisco с одним внутренним портом (g0/0) и двумя внешними (f0/0, f0/1). Есть подключение к двум провайдерам, каждый из которых выдал свой пул адресов Pool(ISP1) и Pool(ISP2) (это некоторые сети, принадлежащие конкретному провайдеру). Пусть для простоты адреса интерфейсов f0/0 и f0/1 из этих же пулов. И адреса шлюзов из этих же пулов (Gate(ISP1) и Gate(ISP2) соответственно).
  Так как у нас нет возможности поднять BGP, значит мы должны на каждого из провайдеров прописать маршрут по умолчанию. И вот тут возникает первый вопрос: какую задачу мы хотим решить? Резервирование или одновременная работа с двумя провайдерами?
  
  Резервирование.
  
  В этой топологии одновременно работает только один провайдер. То есть мы должны организовать проверку провайдера ISP1 и в случае если он живой – ходить через него, а если «мертв», то переключаться на запасного провайдера ISP2. Здесь есть подводный камень: NAT. Мы можем написать несколько правил трансляции, но надо как то указать, что при выходе через ISP1 мы используем Pool(ISP1), а при выходе через ISP2 – Pool(ISP2), иначе маршрутизатор всегда будет использовать трансляцию, которая первой написана в конфигурации. Понятно, что если идти через ISP2, а адреса источника будут из Pool(ISP1), то в лучшем случае мы получим несимметричную маршрутизацию, в худшем пакеты вообще никуда не дойдут, например потому, что провайдеры выполняют предписание использовать фильтрацию по RFC2827, что означает не принимать пакеты с адресами источника не из своей сети.
  Итак, у нас 2 подзадачи: проверка провайдера (маршрута) на «живость» и трансляция адресов с учётом выходного интерфейса.
  
  Проверка на «живость».
  
  Маршрутизаторы cisco обладают замечательной технологией, называемой SLA. При помощи неё можно не только проверять пингом некий адрес, но также проверять живость определенных сервисов (ftp-connect, tcp-connect) или параметра канала связи (icmp-jitter, udp-jitter). Здесь рассмотрим самый простой и распространенный способ – пинг определенного хоста. Для простоты будем пинговать адрес шлюза провайдера Gate(ISPX). Если надо пинговать другой адрес, то необходимо явно прописать маршрут до этого адреса через конкретного провайдера, которого мы проверяем.
  
  Примечание: в старых IOS команда привязки track к sla выгдялела так
  
  Если хост пингуется, то track будет в состоянии UP и маршрут будет в таблице маршрутизации. А
  если пинг пропадет, то через настроенный промежуток времени (по умолчанию 3*10 секунд) track
  поменяет состояние на DOWN и маршрут будет удален до тех пор, пока track вновь не изменит
  состояние.
  
  ISP2 можно не проверять, чтобы не создавать лишний служебный трафик в канал, т.к. он у нас запасной и может быть дорогим (спутниковый канал, к примеру, или коммутируемый канал, оплачиваемый по времени работы). Маршрут на второго провайдера мы напишем с большей административной дистанцией и тем самым заставим его работать только при пропадании основного.
  
  Задание правил трансляции адресов с учетом исходящего интерфейса.
  
  Тут на самом деле тоже 2 задачи: динамическая трансляция и статическая трансляция адресов. Первая нам нужна для выхода наружу, а вторая – для анонса сервисов. И в том и в другом случае нам понадобится конструкция, называющаяся route-map (создать надо будет по route-map на каждого провайдера)
  
  Тут есть тонкость: при указании слова interface в подсказке пишется
  
  Т.е. вообще говоря, не понятно, что это за параметр. Плюс в зависимости от того, что написано на самом интерфейсе, этот критерий может означать как входящий интерфейс, так и исходящий! А зависит это от того, что написано в команде ip nat на интерфейсе:
  
  ip nat inside – критерий будет означать входящий интерфейс
  ip nat outside – критерий будет означать исходящий интерфейс
  
  Далее, нам понадобится пул адресов от каждого провайдера
  
  И можно уже писать правила NAT на каждого провайдера
  
  overload – ключевое слово, означающее использовать PAT (Port Address Translation, трансляцию с учётом порта источника)
  Если к надо добавить статические трансляции, то делаем почти так же (пусть серверу мы зарезервировали адрес Srv(ISPX) от каждого провайдера, а локальный адрес у сервера – Srv(LAN).)
  
  ____________
  UPD ВНИМАНИЕ: ВВЕРХУ ОПЕЧАТКА!
  Должно быть
  
  При этом конечно надо озаботиться, чтобы оба адреса (Srv(ISP1) и Srv(ISP2)) на ДНС серверах были прописаны и указывали на одно и то же имя.
  
  Итого, у нас получилось:
  
  Одновременное использование двух провайдеров
  
  Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
  
  Интересна ли эта тема? Какие мысли и проблемы есть?
  Пишите: скомпилирую со своими мыслями и выложу, если захотите.
  
  Читайте также:

Настройка резервного провайдера cisco

Содержание

Содержание

Введение

Предварительные условия

Требования

Используемые компоненты

Общие сведения

Методы развертывания

Раздельное туннелирование

Туннели между конечными маршрутизаторами