Что такое isp cisco
Два провайдера одновременно или Dual ISP with VRF на Cisco
Есть универсальное решение для подключения нескольких провайдеров, ip sla + track. Решение легкое для понимания и простое в управлении. Но когда дело доходит до одновременного использования двух и более каналов связи, данная технология в чистом виде не подходит.
Хочу поделится своим опытом. На узлах с несколькими провайдерами я использую конфигурацию содержащую виртуальные роутеры – VRF. Эта конфигурация взята из моей практики и хорошо себя зарекомендовала.
Предположим у нас есть 2 провайдера с параметрами:
ISP1 1.1.1.1 шлюз 1.1.1.2
ISP2 2.2.2.1 шлюз 2.2.2.2
И локальная сеть:
LAN 192.168.1.1/24
Приступим к конфигурации. Для начала нужно создать эти самые виртуальные маршрутизаторы, а будет их 3. Два на провайдеров и один на локальную сеть.
Сразу же настроим правила экспорта маршрутов, что бы не возвращается в раздел ip vrf. Логика следующая – нельзя обменивается маршрутами между VRF провайдеров (на самом деле можно, но при таких вариантах настройка усложнится). На пальцах: VRF провайдеров могут получать и отправлять маршруты только в/от VRF локальной сети. VRF локальной сети может отправлять свои маршруты и получать маршруты от любых других VRF.
Вводим данные о сетях в наш маршрутизатор, не забываем сразу включить NAT и назначить интерфейсам нужные VRF. Один интерфейс не может принадлежать сразу нескольким VRF. Представьте себе, что вы решили сделать из одного маршрутизатора несколько, распилив его на части и в каждой части остались свои интерфейсы.
Все, теперь у нас есть 3 маленьких, но гордых независимых маршрутизатора. Перед тем как сделать главное – прописать шлюзы провайдеров, надо настроить ip sla тест. Делается это так же, как и в стандартном решении, но с указанием VFR’а из которого предполагается проводит ip sla тест.
Добавляем маршруты в наши виртуальные маршрутизаторы, которые отвечают за связь с провайдерами. Обратите внимание на значения метрики, на резервном канале метрика выше и далее вы поймете почему.
В принципе этого уже достаточно, для того что бы к маршрутизатору можно было подключится из вне по публичному адресу любого из провайдеров (если, конечно, настроен SSH или telnet доступ).
Далее приготовим NAT, все делаем практически так же, как мы привыкли настраивать в стандартном решении без VRF. Делаем access-list который запрещает транслировать локальные адреса в локальные адреса:
Делаем карты маршрутизации для каждого провайдера:
И включаем NAT overload (обратите внимание, что правило настраивается на виртуальный маршрутизатор vrf lan):
Наше элегантное решение практически готово, но нужен финальный штрих, это BGP процесс который будет заниматься перераспределением маршрутов между VRF учитывая правила импорта\экспорта которые мы настроили в каждом VRF.
Команда default-information originate позволяет передавать через bgp маршрут по умолчанию. В результате, в кандидаты на маршрут по умолчанию для vrf lan попадут два маршрута до шлюзов разных провайдеров, но с помощью bgp будет выбран тот, у которого метрика меньше. Соответственно если вдруг надо переключить NAT с одного провайдера на другой, достаточно будет поменять метрику в таблице маршрутизации одного из VRF.
Заключение. Данная конфигурация позволяет организовать подключение к двум провайдерам связи одновременно. Конфигурация очень гибкая, используя PBR, можно разделять трафик между провайдерами, и даже в случае падения одно из них, продолжать предоставлять сервис. Особенность VRF, позволяет даже во время сложных манипуляций с конфигурацией не потерять связь с устройством (нельзя одновременно править две таблицы маршрутизации, хотя…). Конфигурация легко расширяется и позволяет без заморочек добавить новых провайдеров.
Пинг из vrf первого провайдера:
Спасибо за внимание. Подготовлено на роутере Cisco 881 IOS version 15.5
Резервирование каналов в CISCO Дневник Максим Боголепов
Резервирование каналов в CISCO
 | В дополнение к недавней заметке про резервирование каналов на сервере под управлением FreeBSD, выкладываю решение такой же задачи с использованием одного пограничного маршрутизатора (cisco 2821) с двумя каналами, подключённого к различным провайдерам без балансировки нагрузки (без PBR – policy based routing). |
Схема коммутации предельно проста. На ней видны все исходные данные:
Шлюз по умолчанию, выданный нам основным провайдером: 172.16.0.2, вспомогательным — 10.10.0.2.
Сперва настроим трансляцию адресов (nat) внутренней сети в выданный адрес каждого из провайдеров:
В списке доступа для трансляции адресов будет фигурировать только наша локальная сеть:
Теперь необходимо настроить роутинги. Сперва – route-map для правил трансляции через каждого из провайдеров:
И два статических роутинга до нескольких постоянно работающих в сети интернет хостов (мной выбраны два – dns Google и Яндекса) через шлюз по умолчанию основного провайдера:
Мы будем проверять доступность этих выбранных хостов через канал основного провайдера.
Теперь настраиваем правила динамической трансляции адресов внутренней сети через каждый из внешних адресов:
Впоследствии вам может понадобится настройка статической трансляции (например — для доступности почтового сервера с каждого из этих внешних ip). Делается это следующим образом:
Где 192.168.0.2 внутренний ip вашего почтового сервера.
Не забудьте при этом прописать во внешнем dns эти два адреса примерно следующим образом (в части касающейся):
Теперь воспользуемся инструментом IP SLA (IP Service Level Agreements) для мониторинга доступности выбранных нами хостов в сети интернет посредством обычного ping:
Рекомендации Cisco по настройке данных параметров: (frequency seconds) > (timeout milliseconds) > (threshold milliseconds).
Командой ip sla schedule мы запускаем каждый из этих двух тестов.
Каждый из track отслеживает свой ping тест. Для принятия окончательного решения о “падении” канала связи основного провайдера настроим суммарный track, который будет UP в случае, если хотя бы один из track 10 и track 20 будет находится в состоянии UP:
Наконец, нам осталось прописать статические маршруты. Первый — через основного провайдера с проверкой доступности через суммарный track 50. Второй — через вспомогательного провайдера:
Теперь, чтобы всё было “красиво”, необходимо решить проблему с подвисшими сессиями трансляции адресов при переключении между провайдерами. Конечно мы можем изменить значения по умолчанию время жизни трансляций (tcp, udp, dns и т.д.) (которые равны 24 часам), но это может привести к лишним разрывам сессий. Просто для примера (все значения в секундах):
Мы же этого воспользуемся EEM (embedded event manager). Им мы привяжем некоторые действия к изменению состояния наших track. А именно: каждый раз будем очищать динамические трансляции и записывать в syslog сообщения об этих изменениях:
Проверка наших настроек осуществляется следующими способами:
Проверка работы nat:
Вот, в принципе, и всё. В заключении привожу листинг проделанной работы:
Rating: 4.7/5(6 votes cast)
Настройка использования избыточных или резервных каналов интернет-провайдера в ASA
Параметры загрузки
Об этом переводе
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
В этом документе описывается настройка многофункционального устройства обеспечения безопасности Cisco ASA серии 5500 для использования функции отслеживания статических маршрутов, чтобы устройство могло использовать избыточные или резервные интернет-соединения.
Предварительные условия
Требования
Для этого документа отсутствуют особые требования.
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:
Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.
Родственные продукты
Эту конфигурацию также можно использовать с версией 9.1(5) Cisco ASA серии 5500.
Общие сведения
В этом разделе представлен обзор функции отслеживания статических маршрутов, которая далее подробно рассматривается в данном документе, а также приведены важные аспекты, которые нужно учитывать перед началом работы.
Обзор функции отслеживания статических маршрутов
Одна из проблем, связанных с использованием статических маршрутов, заключается в том, что не существует встроенного механизма, который мог бы определить, функционирует ли маршрут. Маршрут остается в таблице маршрутизации, даже если шлюз следующего перехода становится недоступен. Статические маршруты удаляются из таблицы маршрутизации, только если соответствующий интерфейс в устройстве безопасности прекращает работу. Для решения этой проблемы используется функция отслеживания статических маршрутов, которая позволяет отслеживать доступность статического маршрута. Эта функция при сбое статического маршрута удаляет его из таблицы маршрутизации и заменяет резервным маршрутом.
Отслеживание статического маршрута позволяет ASA использовать экономичное подключение к вторичному поставщику услуг Интернета, если основная выделенная линия становится недоступной. Для того чтобы обеспечить такое резервирование, ASA привязывает статический маршрут к целевому объекту мониторинга, который вы определяете. Операция соглашения об уровне обслуживания (SLA) выполняет мониторинг целевого объекта путем периодической отправки эхозапросов ICMP. Если эхоответ не получен, объект считается вышедшим из строя, и соответствующий маршрут удаляется из таблицы маршрутизации. А вместо удаленного маршрута используется ранее настроенный резервный маршрут. Пока используется резервный маршрут, операция мониторинга SLA продолжает попытки достичь целевой объект. Когда целевой объект снова становится доступен, первый маршрут возвращается в таблицу маршрутизации, а резервный маршрут удаляется.
В примере, который используется в этом документе, ASA поддерживает два подключения к Интернету. Первое подключение — это высокоскоростная выделенная линия, доступная через маршрутизатор, предоставленный основным поставщиком. Второе подключение — это цифровая абонентская линия (DSL) с более низкой скоростью, доступ к которой осуществляется через модем DSL, предоставляемый вторичным поставщиком услуг Интернета.
Примечание. Конфигурация, описываемая в этом документе, не может использоваться для распределения или балансировки нагрузки, так как это не поддерживается на ASA. Используйте эту конфигурацию только для обеспечения избыточности или резервирования. Исходящий трафик идет через основного поставщика услуг Интернета, и в случае сбоя переключается на вторичного поставщика. Сбой основного поставщика приводит в временному прекращению потока трафика.
DSL-подключение не используется, пока активна выделенная линия и доступен шлюз основного поставщика. Однако, если подключение к основному поставщику услуг Интернета разрывается, ASA изменяет таблицу маршрутизации, чтобы направить трафик через подключение DSL. Отслеживание статических маршрутов используется для обеспечения такого резервирования.
В ASA настраивается статический маршрут, который направляет весь трафик Интернета основному поставщику. Каждые десять секунд процесс мониторинга SLA проверяет, есть ли связь со шлюзом основного поставщика услуг Интернета. Если выясняется, что шлюз основного поставщика недоступен, статический маршрут, по которому трафик направляется в этот интерфейс, удаляется из таблицы маршрутизации. Чтобы заменить этот статический маршрут, устанавливается другой статический маршрут, направляющий трафик вспомогательному поставщику. Этот альтернативный статический маршрут направляет трафик вспомогательному поставщику по DSL-модему до тех пор, пока канал основного поставщика не станет доступен.
Данная конфигурация представляет относительно недорогой способ обеспечить постоянный исходящий доступ к Интернету пользователям через ASA. Как показано в данном документе, такая настройка может не подойти для входящего доступа к ресурсам за ASA. Для обеспечения непрерывных входящих подключений требуются знания более сложных сетевых технологий. Эти навыки не рассматриваются в этом документе.
Важные рекомендации
Прежде чем приступить к настройке, которая описана в этом документе, необходимо выбрать целевой объект мониторинга, который может отвечать на эхозапросы протокола ICMP. Это может быть любой выбранный вами сетевой объект, но рекомендуется выбирать тот, который находится ближе к подключению к вашему поставщику услуг Интернета. Ниже перечислены некоторые возможные целевые объекты мониторинга:
В этом документе предполагается, что устройство ASA находится в полностью рабочем состоянии и настроено, чтобы можно было изменять конфигурацию в диспетчере устройств Cisco Adaptive Security Device Manager.
Совет: Сведения о том, как позволить ASDM настраивать устройство, см. в разделе Настройка HTTPS-доступа для ASDM в книге 1: Руководства по настройке общих операций Cisco ASA в интерфейсе командной строки, версия 9.1.
Настройка
Используйте информацию, приведенную в этом разделе, чтобы настроить ASA для использования функции отслеживания статических маршрутов.
Примечание. С помощью средства поиска команд Command Lookup Tool (только для зарегистрированных заказчиков) можно получить дополнительные сведения о командах, которые используются в этом разделе.
Схема сети
В примере, который приводится в этом разделе, используется следующая схема сети:
Конфигурация интерфейса командой строки CLI
Настройка посредством ASDM
Конфигурации появятся в списке интерфейсов:
Проверка
Воспользуйтесь данным разделом для проверки правильности функционирования вашей конфигурации.
Подтверждение завершения конфигурации
Примечание. Средство интерпретации выходных данных (только для зарегистрированных заказчиков) поддерживает некоторые команды show. Используйте Средство интерпретации выходных данных, чтобы просмотреть анализ выходных данных команды show.
Для проверки завершенности конфигурации используйте следующие команды show:
Подтверждение установки резервного маршрута (с помощью интерфейса командной строки)
Введите команду show route, чтобы удостовериться, что резервный маршрут установлен.
До сбоя основного интернет-провайдера таблица маршрутизации выглядит следующим образом:
После сбоя основного интернет-провайдера статический маршрут удаляется, устанавливается резервный маршрут и таблица маршрутизации выглядит следующим образом:
Подтверждение установки резервного маршрута (с помощью ASDM)
Для того чтобы проверить установку резервного маршрута с помощью ASDM, перейдите в раздел Monitoring > Routing (Мониторинг > Маршрутизация) и выберите Routes (Маршруты) в дереве маршрутизации.
До сбоя основного интернет-провайдера таблица маршрутизации выглядит примерно так, как на следующей иллюстрации. Обратите внимание на то, что маршрут по умолчанию (DEFAULT) указывает на адрес 203.0.113.2 через внешний интерфейс:
После сбоя основного поставщика его маршрут удаляется и устанавливается резервный маршрут. DEFAULT указывает на адрес198.51.100.2 через резервный интерфейс:
Устранение неполадок
В этом разделе приведено описание нескольких полезных команд отладки и описывается способ поиска и устранения неполадки, когда отслеживаемый маршрут был удален без надобности.
Команды отладки
С помощью следующих команд отладки можно искать и устранять неполадки в конфигурации:
Ненужное удаление отслеживаемого маршрута
Если отслеживаемый маршрут был случайно удален, убедитесь, что цель мониторинга всегда доступна для получения эхозапросов. Кроме того, убедитесь, что состояние объекта мониторинга (т.е. достижим ли он) тесно связано с состоянием подключения к основному поставщику.
При выборе цели мониторинга, расположенной дальше шлюза интернет-провайдера, может произойти сбой другого канала на этом маршруте или другое устройство может вносить помехи. Работая с такой конфигурацией, монитор SLA может прийти к заключению, что связь с основным интернет-провайдером прервалась, и вынудить ASA выполнить ненужное переключение на канал резервного интернет-провайдера.
Например, если в качестве объекта мониторинга выбран маршрутизатор филиала компании, то возможен сбой подключения поставщика к этому филиалу, а также сбой любого другого канала на всем пути. Если эхозапросы ICMP, отправляемые при выполнении мониторинга, не выполняются, основной отслеживаемый маршрут удаляется, даже если канал основного интернет-провайдера остается активным.
В этом примере шлюз основного поставщика, используемый как объект отслеживания, управляется поставщиком услуг Интернета и располагается на другой стороне канала поставщика. Эта конфигурация гарантирует, что в случае невыполнения эхозапросов ICMP, отправляемых во время мониторинга, канал провайдера почти наверняка не работает.
По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP
Типичная задача, которая тем не менее, продолжает вызывать массу вопросов.
Попробую вкратце описать суть технологии и подводные камни.
Итак, пусть у нас есть один пограничный маршрутизатор 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)) на ДНС серверах были прописаны и указывали на одно и то же имя.
Итого, у нас получилось:
Одновременное использование двух провайдеров
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Интересна ли эта тема? Какие мысли и проблемы есть?
Пишите: скомпилирую со своими мыслями и выложу, если захотите.