Cisco настройка двух провайдеров
Обновлено: 15.07.2024
Два и более провайдера в Интернет на cisco 871
В данной статье мне хотелось бы рассмотреть настройку маршрутизатора cisco на предоставление доступа в Интернет по двум канаkам от разных провайдеров, с возможностью автоматического переключения, в случае отказа одного из каналов.
Итак, исходные данные:
Почему именно такие условия? Во-первых была поставлена именно такая задача, а я стараюсь в этом блоге описывать не какие-то условные задачи, а предалагать решения на основе своей практики. Во-вторых, такая схема намного удобнее простой балансировки нагрузки, так как балансировка основывается, как правило, на соединениях (то есть каждое отдельное соединение клиент-сервер обслуживается по отдельному каналу), что создает ряд проблем. Однако намного проще и правильнее, когда сетевой администратор может, на основе имеющихся данных по среднему потреблению трафика каким-либо клиентом, распределить между провайдрами нагрузку действительно равномерно.
Первоначальная настройка интерфейсов
Для простоты описания возьмем следующую топологию нашей сети:
Заходим на cisco, включаем режим enable (привелегированный режим, аналогично пользователю root в linux) и переходим в режим конфигурации
Настраиваем интерфейс Fast Ethernet 4 (WAN):
Директивы интуитивно понятны, но на всякий случай рассмотрим их подробнее:
По сути всего одна директива, которая вполне понятна и без описания. Но есть еще один немаловажный момент, с которым я в свое время очень долго мучался и перерыл кучу документации на официальном сайте cisco. Суть вот в чем: когда я первый раз настроил vlan на cisco и назначил ему адреса я попробовал с cisco пропинговать свой шлюз, но он никак не хотел пинговаться. Оказывается vlan у меня включался в режим trank, а провайдер мне давал обычный ethernet линк и вообще мало подозревал о том, что я хожу в Интернет из-за cisco. Так что нам, чтобы не наступать на эти же грабли надо в режиме конфигурации ввести следующую директиву:
Как вы видите конфигурация немного отличается, а именно: изменилась директива ip nat inside и добавилась директива ip policy route-map RouteSelect.
ip nat inside говорит нашему маршрутизатору, что на этом интерфейсе внутренняя сторона NAT, то есть здесь происходит преобразтование из приватных адресов в публичные. Другими словами -это наш внутренний интерфейс
Настройка списков доступа и пулов NAT
Мы решили что первые две сети из нашего примера, то есть 10.10.1.0/24 и 10.10.2.0/24 мы будем маршрутизировать через провайдера FirstTelecom, а соответственно сети 10.10.3.0/24 и 10.10.4.0/24 через провайдера SecondTelecom.
Для этого нам нужно создать списки доступа (access-list), делается это весьма просто. Итак, создадим два списка доступа First и Second:
Как мы видим, маска для наших сетей задается не обычным образом. Дело в том, что при задании списков доступа на cisco используется wildcard маска, ее еще называют обратной маской
Пул для NAT задается директивой ip nat pool <start-ip> <end-ip> netmask <netmask>, где <start-ip> это начальный адрес пула, <end-ip>, соответственно конечный адрес пула, ну и<netmask> - это маска сети. Так как для нашего примера мы используем по одному ip адресу от каждого провайдера, то start-ip и end-ip будут совпадать. Создаем два пула для нашего будущего NAT:
Так же нам надо создать два списка доступа для локальных сетей самих провайдеров, чтобы в данные сети пользователи маршрутизировались всегда через того провайдера, которому сеть принадлежит. Скажем каждый провайдер обладает сетью класса B из того же диапазона, который выдан нам, то есть это будут сети 91.100.0.0/16 и 91.1.0.0/16. Для этого создадим еще два списка доступа FirstTelecomNet и SecondTelecomNet:
В данном случае мы используем extended списки доступа, которые отличаются от standart тем, что мы можем указать явно ip источника и назначения (в stanrart листах указываются просто ip и они могут быть как адресами источника, так и назначения). Таким образом мы указываем правила для соединений с любого ip на адреса, принадлежащие сети того или другого провайдера.
Карты маршрутов и обеспечение резервирования канала
Теперь мы подошли вплотную к понятию карты маршрутов (route-map). Я не буду приводить ссылки на документацию от cisco, а постараюсь объяснить вам все своими словами.
По сути карта маршрутов похожа по своему действию на списки доступа, за тем лишь исключением, что в карте маршрутов можно не только определить принадлежность к ней по какому-то параметру (например по ip-адресу), но и изменить какие-то параметры маршрутизации, например указать шлюз (nexthop), через который нужно маршрутизировать попавшие под данную карту маршрутов пакеты. Карта маршрутов поддерживает метки (match) по которым можно указать условия принадлежности каких-то пакетов в данной карте маршрутов, и инструкции set, при помощи которых можно изменить параметры маршрутизации. Так же для каждой карты маршрутов можно указать несколько правил, которые будут обрабатываться по возрастанию иx номера (sequence).
Как мы уже указали вначале, мы будем использовать для маршрутизации всего одну карту маршрутов с именем RouteSelect, но у нее будет несколько номеров.
Итак, начинаем создавать нашу карту маршрутов. Для начала добавим правила для маршрутизации пакетов, которые идут в сети провайдеров только через их шлюзы:
Настройка резервирования канала
Теперь, прежде чем продолжить настройку карт маршрутов, нам нужно настроить резервирование каналов. Делается это через использование технологии IP SLA и механизма Track.
Track - это флаг состояния, который может иметь два значения: up или down. Этот флаг будет устанавливаться на основе данных полученных от IP SLA.
Для обоих провайдеров директивы аналогичны, рассмотрим их значение:
Окончание настройки route-map. Распределение пользователей
Так же надо создать еще две карты маршрутов, но они по сути будут вести себя, как обычные списки доступа, так как не будут иметь директивы set:
После чего нам остается только включить NAT и настроить маршруты по умолчанию с использованием track:
Автор: Яковлев А.В
Полезные ссылки
Быстрое и недорогое обучение за рубежом английскому языку. Различные варианты обучения для всех уровней подготовки.
Любой администратор когда-то обязательно сталкивался с выходом из строя канала связи, обеспечивающего офису доступ в Интернет или к другим ресурсам. Обычно в этот момент и возникает мысль о каком-то резерве (никак не раньше :-)). А вот при наличии двух провайдеров уже есть возможность настроить отказоустойчивое подключение.
Правильно было бы поставить некий маршрутизатор, подключить к нему двух провайдеров, зарезервировать автономную систему с блоком публичных ip адресов и настроить полноценное отказоустойчивое соединение с помощью протокола BGP (Cisco ASA поддерживает его только в серии 5500X в самых последних версиях IOS). Однако это решение подходит для крупных компаний, обладающих ресурсами, возможностями и квалифицированным персоналом.
В подавляющем большинстве случаев будет достаточно сделать простое переключение на резервного провайдера, если пропадет связь с основным. Cisco ASA может отслеживать доступность основного провайдера и, как только связь пропадет (шлюз перестанет отвечать на icmp в течение нескольких секунд), начнет пересылать трафик через резервный канал.
Перейдем к практике.
В нашем распоряжении есть Cisco ASA 5505, обеспечивающая подключение офиса к сети Интернет через провайдера 1 (Ethernet 0/1). Подробное описание настройки можно найти в статье «Cisco ASA. Основы. Доступ в Интернет»
К устройству дополнительно подключен провайдер 2 в интерфейс Ethernet 0/2. (см. схему).
Задача: настроить отказоустойчивое подключение к Интернет (dual wan).
Шаг 1. Проверка маршрутов
Шаг 2. Настройка интерфейсов для резервного провайдера
Шаг 3. Настройка отслеживания доступности провайдера
track 1 rtr 1 reachability
Для справки:
timeout 3000 – время, которое Cisco ASA будет ждать ответа на icmp запрос. 3000 => 3 секунды.
frequency 5 – как часто посылать запросы. Раз в 5 секунд.
threshold 10000 – время задержки операции 10 секунд, в течение которого не происходит никаких действий.
Шаг 4. Шлюз по умолчанию для Резервного провайдера.
Шаг 5. Активация переключения
Важно!
Если существуют строки маршрутов для каких-то сетей, кроме шлюза по умолчанию, то следует учесть их при настройке.
Важно!
Кроме маршрутов необходимо скорректировать списки доступа (access-lists) и правила трансляций (NAT) для интерфейса Резервного провайдера. Добавьте идентичные правила и привяжите их к интерфейсу outside_backup.
Проверка работы механизма отслеживания
Важно!
Для повышенной надежности часто практикуют подключение к двум провайдерам одновременно.
Cisco IOS позволяет обеспечить автоматическое переключение с основного провайдера на резервный.
Мониторинг:
Для того чтобы понять работает интернет через ISP1 или нет, будем через него мониторить через пинг какой нибудь ресурс.
Возьмем к примеру внешний адрес 85.202.241.71
Для мониторнга этот ресурс необходимо смаршрутизировать только через ISP1
ip route 85.202.241.71 255.255.255.255 a.a.a.1
access-list 101 permit icmp any host 85.202.241.71 echo
route-map echo permit 10
match ip address 101
set interface GigabitEthernet0/2
ip local policy route-map echo
Собственно сам мониторинг организовывается через IP SLA:
track 123 ip sla 1 reachability
ip sla 1
icmp-echo 85.202.241.71 source-ip a.a.a.2
timeout 1000
threshold 3
frequency 5
ip sla schedule 1 life forever start-time now
Маршрутизация:
ip route 0.0.0.0 0.0.0.0 a.a.a.1 track 123
ip route 0.0.0.0 0.0.0.0 b.b.b.1 254
Таким образом если track 123 живой - у нас пропишется первый маршрут, т.к. у второго Administratove Distance 254 а у первого 1. При пропадании же track123 в таблицу пропишется второй маршрут
Трансляция:
route-map isp2 permit 10
match ip address NAT_Rules
match interface GigabitEthernet0/1
route-map isp1 permit 10
match ip address NAT_Rules
match interface GigabitEthernet0/2
ip nat inside source route-map isp2 interface GigabitEthernet0/1 overload
ip nat inside source route-map isp1 interface GigabitEthernet0/2 overload
ip access-list extended NAT_Rules
permit ip 192.168.100.0 0.0.0.255 any
Данная конструкция необходима для корректной работы NAT, который должен привязываться к разным интерфейсам при работе с разными провайдерами.
Для сброса NAT сессий при переключении, добавим следующее:
event manager applet ISP_SWITCHED_20
event track 123 state any
action 1.0 cli command «enable»
action 2.0 cli command «clear ip nat trans forced»
Система проверяет на доступность 4 разных внешних IP через основного провайдера. Если все они будут недоступны, основной провайдер будет считаться сбойным и произойдет переключение на резервный.
Предусмотрено переключение натирования внутренних пользователей, а также удаление старых сессий трансляции.
a.a.a.10 - адрес от основного ISP
a.a.a.1 - DG от основного ISP
b.b.b.10 - адрес от резервного ISP
b.b.b.1 - DG от резервного ISP
ip access-list extended echo_check
permit icmp any host 8.8.8.8 echo
permit icmp any host 62.141.69.157 echo
permit icmp any host 93.186.61.38 echo
permit icmp any host 85.202.241.71 echo
route-map echo_rm permit 10
match ip address echo_check
set ip next-hop a.a.a.1
ip local policy route-map echo_rm
ip sla 1
icmp-echo 8.8.8.8 source-ip a.a.a.10
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 62.141.69.157 source-ip a.a.a.10
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 93.186.61.38 source-ip a.a.a.10
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo 85.202.241.71 source-ip a.a.a.10
ip sla schedule 4 life forever start-time now
track 1 ip sla 1 reachability
delay down 30 up 30
track 2 ip sla 2 reachability
delay down 30 up 30
track 3 ip sla 3 reachability
delay down 30 up 30
track 4 ip sla 4 reachability
delay down 30 up 30
track 5 list boolean or
object 1
object 2
object 3
object 4
ip route 0.0.0.0 0.0.0.0 a.a.a.1 track 5
ip route 0.0.0.0 0.0.0.0 b.b.b.1 254
route-map isp2 permit 10
match ip address acl_nat_rules
match interface FastEthernet0/0/0
route-map isp1 permit 10
match ip address acl_nat_rules
match interface FastEthernet0/0/1
ip nat inside source route-map isp1 interface FastEthernet0/0/1 overload
ip nat inside source route-map isp2 interface FastEthernet0/0/0 overload
ip access-list extended acl_nat_rules
permit ip 192.168.100.0 0.0.0.255 any
event manager applet ISP_SWITCHED_20
event track 5 state any
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat trans forced"
show ip sla statistics
show track 123
Для теста удобны следующие адреса:
Сервис-провайдер: Google
8.8.8.8
8.8.4.4
Начну с реализации резервирования выхода в инет, т.к. это я делал в последнюю очередь, стало быть в голове пока свежо.
Итак, дано:
1. Cisco 2821;
2. Модуль HWIC-2FE;
3. Шнурок от одного прова (SPI1) ip: xxx.xxx.xxx.xx2 (шлюз: xxx.xxx.xxx.xx1);
4. Шнурок от второго прова (SPI2) ip: yyy.yyy.yyy.yy2 (шлюз: yyy.yyy.yyy.yy1);
5. Сеть предприятия, ip: 10.0.0.0 255.255.255.0.
Сразу хочу предупредить, что для дальнейших действий понадобиться IOS не ниже версии 12.4(15)T, по двум причинам: первая – это невозможность работать с IP Service Level Agreement, а вторая – это невозможность работать с HWIC-2FE, он просто не определяется циской. Я как раз под это и попал, пришлось извращаться, т.к., как оказалось, обновление IOS - процесс простой только с первого взгляда )) В общем собрав все, какие только можно, подводные камни, я всё же перешёл на нужную версию операционки. Потом, если соберусь, посвящу этому отдельную заметку )
Суть резервирования сводится к прописыванию двух маршрутов с разными метриками, и если нет необходимости в NATе, то всё вроде бы просто, но… мы не ищем лёгких путей ))) Шучу конечно же )) Просто в нашем случае NAT как раз-таки и нужен. Итак, чтобы иметь возможность задать две настройки для NAT, нужно использовать роут-мапы.
ip nat inside source route-map ISP1 interface GigabitEthernet0/1 overload
ip nat inside source route-map ISP2 interface FastEthernet0/2/0 overload
route-map ISP2 permit 10
match ip address 10
match interface FastEthernet0/2/0
!
route-map ISP1 permit 10
match ip address 10
match interface GigabitEthernet0/1
Так же следует настроить возможность отключения маршрута при его неисправности. Проверять валидность маршрута будем при помощи посылки icmp-пакетов на заведомо исправный узел, к примеру, yandex (87.250.251.3) и google (8.8.8.8). Алгоритм прост – через sla настраиваем мониторинг вышеуказанных узлов, создаём два маршрута через 2х разных провайдеров, настраиваем один как track 1, второй, соответственно как track 2, привязываем один трек к одному, sla, а второй ко второму.
ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xx2 3 name 1ISP track 1
ip route 0.0.0.0 0.0.0.0 yyy.yyy.yyy.yy2 100 name 2ISP track 2
ip sla 123
icmp-echo 87.250.251.3 source-interface GigabitEthernet0/1
frequency 10
ip sla schedule 123 life forever start-time now
ip sla 456
icmp-echo 8.8.8.8 source-interface FastEthernet0/2/0
frequency 10
ip sla schedule 456 life forever start-time now
track 1 ip sla 123
!
track 2 ip sla 456
При настройке маршрутов, так же необходимо указать метрики, у основного маршрута меньшую, у резервного большую, это нужно для того, чтобы не возникло путаницы, т.к. для роутера, при наличии пинга с обоих адресов, оба адреса считаются валидными, и будут работать. Так же необходимо прописать статичные маршруты и для адресов, которые будут пинговаться, при этом явно разнести эти два адреса по двум различным интерфейсам, соответствующим различным провайдерам это нужно для того, чтобы маршрут оживал, когда оживёт провайдер.
ip route 8.8.8.8 255.255.255.255 yyy.yyy.yyy.yy1 name Google
ip route 87.250.251.3 255.255.255.255 xxx.xxx.xxx.xx1 name Yandex
Тут вроде всё. Теперь вернёмся снова к NATу. Чтобы, при падении маршрута, в таблице трансляции не подвисали трансляции, нужно их сбрасывать. Настроить это лучше всего по событию трекинга.
event manager applet natclear
event track 1 state any
action 0.9 cli command "enable"
action 1.0 cli command "clear ip nat translation *"
action 2.0 cli command "clear ip nat translation forced"
Всё работает на реальном железе, маршруты переключаются. Пока всех всё устраивает. Как следующий шаг развития в этом направлении буду смотреть в сторону BGP, но это уже не много другая история.
З.Ы.: Полный листинг конфига ниже.
Читайте также: