Cisco настройка двух провайдеров
Любой администратор когда-то обязательно сталкивался с выходом из строя канала связи, обеспечивающего офису доступ в Интернет или к другим ресурсам. Обычно в этот момент и возникает мысль о каком-то резерве (никак не раньше :-)). А вот при наличии двух провайдеров уже есть возможность настроить отказоустойчивое подключение.
Правильно было бы поставить некий маршрутизатор, подключить к нему двух провайдеров, зарезервировать автономную систему с блоком публичных ip адресов и настроить полноценное отказоустойчивое соединение с помощью протокола BGP (Cisco ASA поддерживает его только в серии 5500X в самых последних версиях IOS). Однако это решение подходит для крупных компаний, обладающих ресурсами, возможностями и квалифицированным персоналом.
В подавляющем большинстве случаев будет достаточно сделать простое переключение на резервного провайдера, если пропадет связь с основным. Cisco ASA может отслеживать доступность основного провайдера и, как только связь пропадет (шлюз перестанет отвечать на icmp в течение нескольких секунд), начнет пересылать трафик через резервный канал.
Перейдем к практике.
В нашем распоряжении есть Cisco ASA 5505, обеспечивающая подключение офиса к сети Интернет через провайдера 1 (Ethernet 0/1). Подробное описание настройки можно найти в статье «Cisco ASA. Основы. Доступ в Интернет»
К устройству дополнительно подключен провайдер 2 в интерфейс Ethernet 0/2. (см. схему).
Задача: настроить отказоустойчивое подключение к Интернет (dual wan).
Шаг 6. Активация переключения
Финальный шаг – привязать основной маршрут к функции слежения за доступностью канала (ip sla).
Добавляем новую строку для шлюза по умолчанию с пометкой track 1 и удаляем старую
После этого в итоговой конфигурации останутся две строчки для шлюзов по умолчанию
Важно!
Если существуют строки маршрутов для каких-то сетей, кроме шлюза по умолчанию, то следует учесть их наличие при настройке, продумав логику переключения аналогично шлюзу по умолчанию.
tips and tricks
Хочу отметить ещё несколько особенностей работы с VRF.
Например конфигурация NTP:
Из-за использования VRF любые сетевые операции нужно относить к виртуальному маршрутизатору, это связано с тем, что когда Вы настроите эту конфигурацию и выполните show ip route вы не увидите ни одной записи в таблице маршрутизации.
К преимуществам этой конфигурации я хотел бы отнести её гибкость. Можно с легкостью вывести один VLAN через одного ISP, а другой через второго.
К недостаткам, и это вопрос к уважаемой публике, когда отваливается один из ISP то команда clear ip nat translations * обрывает все соединения, включительно с работающим ISP. Как показала практика, в тех случаях когда отваливается провайдер — пользователи не замечают этот «обрыв» или он не является критичным.
Если кто-то знает как очищать таблицу трансляций частично — буду благодарен.
Рано или поздно, но каждая компания сталкивается с проблемой выхода из строя канала связи с интернет. И сразу же после этого встает вопрос об организации резервного канала. Но какие настройки нужно сделать для автоматического переключения на него в случае аварии?
В этой статье описаны настройки для маршрутизаторов Cisco 881 и подобных моделей. Если у вас Cisco ASA, то настройки для них написаны в статье Dual WAN на Cisco ASA.
Один из самых простых и эффективных способов для маршрутизаторов Cisco – использование ip sla monitor. Устройство будет отслеживать доступность основного интернет провайдера и, как только связь пропадет (некий адрес не будет отвечать на icmp запросы в течение нескольких секунд), начнет пересылать трафик через резервный канал.
Рассмотрим настройки на примере стандартной модели маршрутизаторов для небольшого офиса Cisco 881.
- В интерфейс 3 уровня Fa 4 подключен основной оператор связи;
- В интерфейс Fa 0 (Vlan 1) подключена локальная сеть офиса;
- В интерфейс FastEthernet 3 (Vlan 3) подключен резервный провайдер.
Если у вас иная модель, то отличие будет только в названии интерфейсов, но не в сути настроек.
Задача: настроить отказоустойчивое подключение к Интернет (dual wan).
Конфигурация интерфейсов
Применять команду ip vrf forwarding на интерфейсе нужно до назначения IP адреса. В противном случае IP адрес будет удалён и его придётся назначать заново.
Настройка track
В таблице маршрутизации есть маршрут ip route vrf isp1 0.0.0.0 0.0.0.0 198.51.100.2 tag 100 track 100 который завязан на track 100.
- Если track 100 в состоянии UP то маршрут в таблице есть.
- Объект 100 это boolean and, что означает, что UP он будет считаться если все его объекты в состоянии UP.
- Если любой из объектов 100 DOWN то весть объект 100 будет DOWN.
- Он содержит объекты 101 и 110.
- Объект 101 соответствует SLA 10 — проверяет шлюз провайдера.
- Объект 110 объединяет 102 и 103 как boolean or, что означает, что он будет UP если хотя бы один из его объектов UP.
- Объекты 102 и 103 проверяют 8.8.8.8 и 80.80.80.80 соответственно, их нужно два для исключения ложных срабатываний.
track 1000
Этот объект умолчанию имеет состояние DOWN.
В данной конфигурации этот объект необходим для того, что бы принудительно отключить одного из ISP и не подключать его. Для этого track 1000 нужно добавить в объект 100 или 200. Исходя из boolean and, если один из объектов DOWN то весь объект считается DOWN.
Шаг 7. Корректировка NAT
Самое главное, чем отличается настройка dual wan на маршрутизаторах Cisco 881 и Cisco ASA – это необходимость перенастройки трансляции адресов NAT (преобразование внутренних «серых» адресов в «белый» адрес внешнего интерфейса). Если для Cisco ASA достаточно продублировать настройки NAT для резервного провайдера, то для маршрутизаторов Cisco необходимо перенастраивать логику команд.
«Обычные» настройки NAT для доступа в сеть Интернет для пользователей сводится к указанию диапазона внутренних адресов и добавления правила «транслируй «эти адреса» в адрес внешнего интерфейса». Фактически описывается трафик ДО попадания на внутренний интерфейс маршрутизатора.
ip access-list standard ACL_NAT
permit 192.168.10.0 0.0.0.255
Interface Vlan 1
ip nat inside
Interface Fa 4
ip nat outside
ip nat inside source list ACL_NAT interface fa4
В случае с реализацией отказоустойчивого переключения на резервный канал с помощью ip sla необходимо использовать route-map. Это расширенная функция управления потоком трафика, в настройках которой указывается условие (какой трафик) и действие (что с ним делать).
В нашем случае для каждого из провайдеров создается route-map только с «условиями», в качестве которых выступают:
- заранее созданный список доступа ACL_NAT, в котором отражен трафик для всех внутренних хостов)
- Выходной интерфейс (свой для каждого из провайдеров
route-map ROUTE_ISP_MAIN permit 10
match ip address ACL_NAT
match interface FastEthernet 4
route-map ROUTE_ISP_BACKUP permit 10
match ip address ACL_NAT
match interface Vlan 3
Далее необходимо добавить правила для NAT, в которых сослаться на route-map
ip nat inside source route-map ROUTE_ISP_MAIN interface FastEthernet 4 overload
ip nat inside source route-map ROUTE_ISP_BACKUP interface Vlan 3 overload
Важно!
не забудьте проверить, что на каждом из трех интерфейсов, через которые проходит трафик, есть строки о принадлежности к NAT
Interface Vlan 1
ip nat inside
Interface Fa 4
ip nat outside
interface Vlan 3
ip nat outside
Описание:
Все действия выполняются на Cisco 1921 IOS Version 15.5(3)M3 с установленным модулем EHWIC-4ESG.
- Порты GigabitEthernet0/0 и GigabitEthernet0/1 задействованы для подключения ISP.
- Порты GigabitEthernet0/0/0 и GigabitEthernet0/0/1 сконфигурированы в TRUNK и подключены к коммутаторам.
- Для работы с локальной сетью используются VLAN интерфейсы.
- В данной схеме предусматривается три локальных IP сети 192.168.100.0/24 для VLAN 100, 192.168.101.0/24 VLAN 101 и 192.168.102.0/24 VLAN 102.
- В данном примере VLAN 100 и 101 будут иметь связь между собой но 101 будет без доступа к Интернету, а VLAN 102 будет иметь выход только в интернет.
Оставшиеся физические порты не задействованы, но Вам ничто не мешает их использовать по собственному усмотрению.
Конфигурация VRF
Настройка SLA
Ничего особенного в конфигурации нет, проверятся доступность по ICMP узлов 8.8.8.8 80.80.80.80 и маршрутизаторов провайдера из каждого ISP VRF.
Шаг 4. Шлюз по умолчанию для Резервного провайдера.
Шаг 1. Проверка маршрутов
Что проверять?
В большинстве случаев адрес внешнего интерфейса и шлюза провайдера заранее известны. Поэтому будет достаточно проверять доступность адреса шлюза провайдера. Но здесь есть один подвох. Что произойдет, если шлюз будет все так же доступен, но неисправность будет где-то дальше на сети провайдера? То есть «интернет не работает», но шлюз доступен. Ответ – ничего. Маршрутизатор не сможет распознать неисправность и не переключится на резерв. Сюда же подходят случаи, когда провайдер предоставляет динамический адрес, например, по технологии pppoe.
Чтобы это обойти, часто выбирается какой-то стабильно работающий адрес в Интернете, который вполне может быть в любой точке мира. Далее на маршрутизаторе задается статический маршрут до выбранного адреса через интерфейс основного провайдера. И уже наличие шлюза по умолчанию в сторону основного провайдера ставится в зависимость от доступности выбранного адреса. Тогда, что бы ни случилось со связью, будь то неполадки с настройками маршрутизатора, сбои у оператора связи и другие причины, механизм переключения сработает автоматически. При этом минусом такого подхода будет то, что заветный адрес будет всегда недоступен вместе с основным провайдером. Для этих целей советую использовать адрес 1.1.1.1, который стабильно доступен, но крайне редко используется в повседневной работе пользователей или устройств.
Сложно написано, не так ли? Давайте упростим до алгоритма действий маршрутизатора:
- Маршрутизатор, знай, что хост 1.1.1.1 всегда находится за шлюзом основного провайдера 10.10.10.1
- Маршрутизатор, проверяй доступность хоста 1.1.1.1 один раз в 10 секунд
- Если хост 1.1.1.1 доступен, то шлюз по умолчанию – адрес провайдера 1
- Если хост 1.1.1.1 недоступен, то шлюз по умолчанию – адрес провайдера 2
Задаем статический маршрут через основного провайдера до адреса 1.1.1.1
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
Для справки:
threshold 10000 – Запросы будут посылаться 1 раз в 10 секунд.
Шаг 2. Настройка интерфейсов для резервного провайдера
Настройка VRF для ISP
Обратите внимание, что в конфигурации нет импорта 65000:101 который будет закреплен за VLAN 101. Таким образом виртуальные маршрутизаторы isp1 и isp2 не будут иметь маршрутов в сеть 192.168.101.0/24
Настройка EEM
EEM — Embedded Event Manager позволяет автоматизировать действия в соответствии с определенными событиями.
В нашем случае, когда один из ISP перестанет работать, он будет исключен из таблицы маршрутизации. Но правила трансляции NAT будут оставаться. Из-за этого, уже установленные пользовательские соединения зависнут до того момента пока трансляции NAT не очистится по тайм-ауту.
Для того, что бы ускорить этот процесс нам необходимо очистить таблицу NAT командой clear ip nat translation * и лучше всего сделать это автоматически.
Если объекты 100 или 200 перейдут в состояние DOWN то будут выполнены команды action по порядку.
Настройка VRF для VLAN
Снова обратите внимание на VRF 101, который не обменивается маршрутами c ISP но обменивается с VRF 100.
На своём опыте я убедился, что название VRF для ISP удобно использовать как isp1 и isp2, название VRF для VLAN должно соответствовать номеру VLAN, всё что идентифицирует VRF — description. Это связано с тем, что если, например, у Вас поменяется один из провайдеров то вся реконфигурация сведется к изменению IP адреса интерфейса и description-а.
Шаг 1. Проверка маршрутов
Проверяем текущие маршруты на устройстве. Для удобства командой sh run | inc route
выводим строки текущей конфигурации, содержащие слово «route»
Если переводить с языка устройства на «человеческий», то получится следующее:
«Перенаправлять все пакеты, о которых я не знаю, в сторону интерфейса outside через шлюз 10.10.10.1»
Маршрутизатор «знает» только о тех сетях, которые подключены к нему напрямую (connected) или для которых имеются подобные строки маршрутов.
Проверка работы механизма отслеживания
Демо схема:
Настройка маршрутизации
Приступим к настройке маршрутизации. Одной из особенностей работы с VRF, которая усложняет конфигурацию, является необходимость всё определять в конкретный VRF.
- tag — поможет нам отфильтровать для передачи в локальные VRF только эти маршруты
- track — указывает какой объект отвечает за работоспособность маршрута
Используя этот route-map и применяя его в VRF для ISP перераспределяться будут только маршруты с тэгом, а остальные останутся только внутри ISP VRF.
Отдельные маршруты к хостам 8.8.8.8 и 80.80.80.80 необходимы для того, что когда сработает track и отключит шлюз по умолчанию у нас осталась возможность совершать проверку доступности этих адресов. Так как мы не присваиваем им тэг они не будут подпадать под route-map и перераспределяться.
Настройка NAT
Для работы NAT необходимо обозначить inside, outside интерфейсы. В качестве outside мы определяем интерфейсы в которые подключены ISP, командой ip nat outside. Все остальные интерфейсы, которые относятся к LAN обозначаем как inside командой ip nat inside.
Необходимо создать два route-map-а в которых определяются интерфейсы isp1 и isp2
Правила NAT необходимо указывать для каждого VRF через каждый ISP. Так как в нашем условии Vlan 101 не имеет доступа к сети Интернет то правила для него указывать нет необходимости, а даже если их указать — работать не будет, потому что нет маршрутизации.
У Cisco есть много разновидностей NAT. В терминологии Cisco, то что мы используем называется Dynamic NAT with Overload или PAT.
Что нужно для того что бы NAT работал?
- Определить внутренний и внешний интерфейсы
- Указать, что мы хотим транслировать
- Указать, во что мы хотим транслировать
- Включить трансляцию
Таким образом мы указываем, что/во что и включаем трансляцию, то есть выполняем все необходимые требования.
Это настройка простой конфигурации, она очевидна и понятна без дополнительных подробностей.
Правило которое мы применяем в нашей конфигурации уже не так очевидно. Как мы помним, route-map isp1 определяет интерфейс GigabitEthernet0/0. Перефразируя команду получается нечто подобное
Получается нужно транслировать трафик source которого GigabitEthernet0/0?
Для того что бы это понять необходимо погрузится в механизм прохождения пакета внутри маршрутизатора.
- Трафик который приходит на интерфейс который помечен как inside не подвергается трансляции. Он маркируется как возможно транслируемый.
- Следующим шагом обработки этого трафика является его маршрутизация согласно таблице маршрутизации или PBR.
- Если согласно таблице трафик попадает на интерфейс который отмечен как outside происходит его трансляция.
- Если трафик попадает на не outside интерфейс трансляции не происходит.
Ошибочно можно подумать, что можно делать route-map LAN match interface Vlan100. Применять этот как ip nat inside source route-map LAN и т.д.
Во избежание этой мысли нужно понять, что это правило трансляции срабатывает тогда, когда трафик уже находится на outside интерфейсе и match интерфейса где этого трафика уже нет ни к чему не приведет.
Шаг 1. Проверка маршрутов
Шаг 4. Проверка работы механизма отслеживания
Для проверки работы отслеживания ip sla используется команда sh ip sla statistics
Number of successes: 15 – показывает количество успешных icmp запросов
Number of failures: 0 – показывает количество неудачных запросов
Перед выполнением дальнейших шагов обязательно проверьте вывод этой команды несколько раз, чтобы убедиться, что счетчик успешных срабатываний (successes) растет со временем. Это означает, что основной канал работает стабильно и можно продолжать настройку без риска потерять связь с Интернет.
Конфигурация BGP
Каждый из BGP address-family настраивается отдельно для VRF и перераспределяет подключенные маршруты (redistribute connected). У нас будет два маршрута по умолчанию, один через VRF isp1 и второй через isp2. Параметр maximum-paths 2 позволит импортировать в VRF 100 и 102 оба маршрута по умолчанию.
Это будет выглядеть так:
Маршрутизаторы Cisco автоматически балансируют трафик по маршрутам в одном направлении с одинаковой стоимостью.
В VRF isp1 и isp2 необходимо, помимо redistribute connected, разрешить redistribute static и default-information originate, что позволит передать шлюз по умолчанию в другие VRF. Вы можете заметить, что redistribute static делается через route-map BGP_Filter. Это происходит исключительно из соображений эстетического вида таблиц маршрутизации VRF определенных в локальную сеть, что бы маршруты к 8.8.8.8 и 80.80.80.80 не попадали в таблицы маршрутизации VRF 100 и 102.
Шаг 5. Шлюз по умолчанию для Резервного провайдера.
Для Резервного провайдера требуется указать шлюз по умолчанию, куда маршрутизатор Cisco 881 будет отправлять все пакеты, но с одним отличием – этот маршрут не должен учитываться, когда доступен Основной провайдер. Для этого следует понизить приоритет этого маршрута, который здесь называется «административным расстоянием». Необходимо сделать его больше (дороже).
По умолчанию значение административного расстояния для статического маршрута – 1. Зададим для Резервного канала значение, близкое к максимальному – 250
После добавления в конфигурации маршрутизатора Cisco 881 должно быть 2 маршрута по умолчанию
Шаг 2. Настройка для резервного провайдера
На межсетевом экране уже настроен интерфейс outside (Ethernet 1/Vlan 2), к которому подключен Основной провайдер. В текущей конфигурации (просмотреть командой sh run) будут присутствовать подобные строки:
Добавим настройки для Резервного канала, который подключен к Ethernet 3/Vlan 3
Для этого сначала необходимо создать Vlan для подключения резервного оператора, привязать его к одному из свободных портов и после этого задать ip адрес.
Проверить текущие настройки можно командой sh current, не выходя из режима настройки Vlan. Достаточно, чтобы Vlan с порядковым номером 3 был в перечне существующих.
Для привязки Vlan 3 к интерфейсу FastEthernet 3 необходимо выйти из режима настройки Vlan и далее зайти в обычный режим конфигурирования conf t. После этого привязать Vlan 3 к интерфейсу FastEthernet 3 и активировать его командой no shut.
А после создания задать ip адрес и активировать интерфейс командой no shut
Если все провода подключены и настройки корректны, то для маршрутизатора должен быть доступен шлюз Резервного провайдера.
Шаг 5. Активация переключения
Важно!
Если существуют строки маршрутов для каких-то сетей, кроме шлюза по умолчанию, то следует учесть их при настройке.
Важно!
Кроме маршрутов необходимо скорректировать списки доступа (access-lists) и правила трансляций (NAT) для интерфейса Резервного провайдера. Добавьте идентичные правила и привяжите их к интерфейсу outside_backup.
Шаг 3. Настройка отслеживания доступности провайдера
track 1 rtr 1 reachability
Для справки:
timeout 3000 – время, которое Cisco ASA будет ждать ответа на icmp запрос. 3000 => 3 секунды.
frequency 5 – как часто посылать запросы. Раз в 5 секунд.
threshold 10000 – время задержки операции 10 секунд, в течение которого не происходит никаких действий.
Шаг 3. Настройка отслеживания доступности провайдера
Для того чтобы маршрутизатор Cisco 881 следил за доступностью Основного канала, необходимо настроить функцию ip sla monitor. С ней через равные временные промежутки будет посылаться ping (icmp запрос) на адрес провайдера 1 (основного). Получение ответного пакета (icmp ответ) будет означать доступность канала.
Важно!
Есть универсальное решение для подключения нескольких провайдеров, 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.
Из недостатков, хочу отметить необходимость почти в любую команду вставлять дополнительный текст vrf . Так просмотр таблицы маршрутизации виртуального роутера локальной сети вызывается командой:
Пинг из vrf первого провайдера:
Спасибо за внимание. Подготовлено на роутере Cisco 881 IOS version 15.5
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Для начала: нам надо обоих провайдеров проверять на «живость» и переключать все потоки на одного в случае, если кто то «упал». Это делается полностью аналогично проверке ISP1 в главе про Резервирование. С тем лишь отличием, что оба маршрута по умолчанию имеют одинаковую административную дистанцию
Правила NATа не претерпевают изменений. Те же route-map в динамических и статических трансляциях. Но как определить, какой пакет отправлять через какого провайдера? Можно принудительно раскидывать входящие с g0/0 пакеты ещё одним route-map.
Правда в этом случае пакет, попавший в ACLISP1, пойдет на первого провайдера всегда, независимо от того, жив провайдер или нет. Чтобы этого избежать есть возможность в этом route-map применить проверку по track
Напомню, что в случае если пакет явно не попал в route-map, он будет использовать обычную таблицу маршрутизации.
Ну а теперь давайте попробуем разобраться с двумя очень сложными вопросами: каким образом будут ходить пакеты, если вы не используете явно разделение трафика при помощи route-map на внутреннем интерфейсе. И как сделать так, чтобы пакет, пришедший снаружи на адрес сервера Srv(ISP1) ушел обратно через тот же интерфейс, через который пришёл. Это действительно сложные вопросы. И красивого решения для них нет, поэтому я в своей практике стараюсь избегать таких топологий.
Однако, жизнь может заставить, поэтому разберемся.
Пусть снаружи приходит пакет на интерфейс f0/0 на адрес Srv(ISP1). Благодаря статической трансляции адрес назначения будет изменен на Srv(LAN) и пакет пойдет дальше на сервер. На маршрутизаторе в кеше NAT трансляций появится запись о соответствии Srv(LAN) и Srv(ISP1). Сервер ответит, ответ дойдет обратно до маршрутизатора и…возникнет вопрос: по какому маршруту отправлять пакет в Интернет? В кеше трансляций есть явная запись, какой адрес ставить вместо Srv(LAN) – Srv(ISP1). Но нет ни намека, через какой интерфейс при этом посылать пакет. Для исправления этой неоднозначности надо по какому то критерию разделять приходящий с разных интерфейсов трафик. Этого можно добиться, но способ, по моему мнению, не очень элегантный: надо использовать подмену реальных адресов клиентов на разные пулы внутренних адресов. Надо только подобрать размер этого пула соответственно нагрузке на сервер – по одному адресу на каждого обращающегося, т.к. для внешнего NATa (outside NAT) на маршрутизаторах нельзя сделать РАТ (Port Address Translation), только трансляция адрес в адрес. Тогда всегда точно известно, с какого интерфейса поступил запрос. В качестве критерия для трансляции адреса сервера можно в существующие route-map добавить такие списки доступа
Таким образом получим:
Это решение, пусть не красивое, но все же полностью решает задачу, не затрагивая сервер (его часто и нельзя затрагивать: например, если это не приложение, а VPN сервер). Потеря здесь явная одна: сервер никогда не знает, с кем реально он общается, а значит нельзя собрать адекватную статистику и т.д.
Если же использовать возможности серверов, то на ум приходит несколько решений, не требующих внешнего NATа.
Первое – сделать на самом деле 2 сервера-партнера, с разными адресами и связанными друг с другом для репликации ещё одним линком. Каждый сервер транслируется в свой адрес, но в случае падения одного из каналов переключается на партнерский адрес.
Не самое простое и дешевое решение.
Второе: задать на одном и том же сервере 2 адреса. Если они из одной подсети, то проблемы с маршрутизацией не будет. Каждый из локальных адресов сервера строго транслируется только одного из провайдеров, т.к. физически сервер один и никакой выгоды по нагрузке мы все равно не получим. Для явного указания выходного интерфейса применяем route-map STRELKA. Тут может возникнуть проблема с самим сервером: часто бывает так, что при ответе сервер использует только первичный адрес интерфейса, независимо от того, на какой адрес пришел запрос.
Характерный пример: VPN сервер. Если в качестве VPN ¬сервера выступает маршрутизатор cisco, то он всегда отвечает с первичного адреса интерфейса.
UPD on 23:45 14.01.2010
Пришло письмо мне от читателя из Литвы, где он сослался на интересную статью. Пожалуй, она дополнит именно серверную часть задачи:
Тут на сайте НИЛа. Автор — Иван Пепельняк, один из ранних CCIE, очень глубокий специалист (его блог «IOS hints and tricks»
Вкратце: на виндузовом сервер можно создать интерфейсы loopback (2 штуки) и сорсировать пакеты от сервисов именно от этих адресов. И транслировать их в разные внешние. Дополнительно надо на маршрутизаторах прописать обратные маршруты в сети этих loopback. Тогда проблема адреса источника будет решена
__________________
Если адреса из разных подсетей, то шлюз по умолчанию все равно один. А значит маршрутизироваться все будет только через один интерфейс и задача полностью решена не будет.
PS Сегодня наконец собрал стенд и ещё раз все проверил, благодаря Вашему интересу! Так что пользуйтесь, дорогие мои :)
Добрый день! На написание этого материала меня вдохновил HunterXXI в своей статье Два провайдера одновременно или Dual ISP with VRF на Cisco. Я заинтересовался, изучил вопрос и применил на практике. Хотел бы поделится своим опытом в реализации Dual ISP на Cisco с реальным использованием одновременно двух ISP и, даже, балансировкой нагрузки.
Читайте также: