Если ваша сеть не работает в условиях экстремальной безопасности или в местах где нет доступа в интернет, ваше начальство вероятно уже попросило вас снизить стоимость глобальной сети(WAN) путем миграции от традиционных выделенных линий или сетей, основанных на frame-relay к Internet или VPN на основе MPLS, в тоже время сохранить или даже увеличить надёжность сети. Этот набор конфликтующих требований может вынудить вас сделать все ваши сайты со множественной адресацией (далее буду употреблять multihoming) т.е. подключенными более чем к одному интернет сервис провайдеру-ISP.
Требованиe multihoming не новость, например, каждое порядочное решение для электронной коммерции должно быть multihoming. Однако,большинство решений, которые вы найдёте с помощью Google требуют чтобы у вас был собственный IP префикс и номер автономной системы(оба являются редкими ресурсами) и запуска Border Gateway Protocol (BGP) со всеми ISP. Очевидно это требование полность нереально если вы хотите настроить multihoming на небольшом удалённом офисе.
В этой статье вы узнаете как:
-подключить небольшой удалённый офис более чем к одному ISP;
-обнаружить отказы в сетях ISP и соответственно приспособить свою маршрутизацию ;
-повысить общую доступность вашего сайта с помощью Service Level Agreement(соглашение об уровне сервиса - SLA) мониторинга;
-регистрировать все соответствующие изменения на удалённом сайте
Базовый multihoming на небольшом сайте.
Подключение небольшого сайта к нескольким провайдерам можен быть очень простым - вы получаете 2 upstream( восходящий информационный поток) линка и 2 назначенных провайдерами IP-адреса (назначенных либо статически, либо динамически). Так как каждый провайдер выдаст вам только один IP-адрес, используйте приватные адреса на стороне LAN вашего маршрутизатора (Рисунок 1).
РИСУНОК 1 IP-адресация на небольшом multihoming сайте
Большинство провайдеров будут не готовы запустить протокол динамической маршрутизации с вашим сайтом, настройте на своём конце статический маршрут по умолчаю. Предпочтение одного провайдера другому выльется в основной и резервный маршрут по умолчанию.
_______________________________________________________
Примечание
При тщательной настройке можно также достигнуть зачатка распределения нагрузки между 2-х одинаково хороших маршрутов по умолчанию.
_______________________________________________________
РИСУНОК 2 Статическая маршрутизация по умолчанию
Роутер на удалённом сайте должен ещё выполнять 2 независимых NAT преобразования, один для пакетов посланных на ISP A (где локальные адреса транслируются через IP-адрес, назначенный ISP A), а другой для пакетов посланных на ISP B (Рисунок 3).
РИСУНОК 3 NAT преобразование на небольшом multihoming сайте
Одна из главных проблем в прoектировании multihome сайта является правильная обработка возвращающегося трафика. В этом случае (известном как ассиметричная маршрутизация) нередко возникают проблемы с производительностью, если исходящий и возвращающийся трафик проходят через разные линки , в этих условиях IP-мультикаст и проверка состояния пакетов (часть особенности IOS файрвола) почти всегда не работают. К счастью ассиметричная маршрутизация не является проблемой в проектировании двойного NAT РИСУНОК 3, поскольку исходный адрес(source address ) исходящего пакета указывает линк, который был использован для его отправки (Рисунок 4).
РИСУНОК 4 Симметричная маршрутизация с двойным NAT
Настройка небольшого multihomed сайта.
Настроить маршрутизатор в небольшом multihomed сайте очень просто. Для начала настройте приватные и публичные IP-адреса (Листинг 1).
ЛИСТИНГ 1 Начальная настройка маршрутизатора
_______________________________________________
hostname GW
!
ip cef
!
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
!
interface FastEthernet0/0
description *** Inside LAN interface ***
ip address 192.168.0.1 255.255.255.0
!
interface Serial0/0/0
description *** Link to ISP 1 ***
ip address 172.16.1.1 255.255.255.252
!
interface Serial0/0/1 point-to-point
description *** Link to ISP 2 ***
ip address 172.17.3.1 255.255.255.252
_______________________________________________
Настройка NAT немного сложнее, вы настроите 2 NAT пула (по одному на каждый ISP), как показано ниже (Листинг 2).
ЛИСТИНГ 2 Настройка NAT
_______________________________________________
interface FastEthernet0/0
ip nat inside
!
interface Serial0/0/0
ip nat outside
!
interface Serial0/0/1 point-to-point
ip nat outside
!
ip nat inside source route-map ISP_A interface Serial0/0/0 overload
ip nat inside source route-map ISP B interface Serial0/0/1 overload
!
route-map ISP_A permit 10
match interface Serial0/0/0
!
route-map ISP_B permit 10
match interface Serial0/0/1
________________________________________________
________________________________________________
Примечание
Необходимо иметь 2 route-maps согласованных с исходящими(наружу) интерфейсами(утверждение match interface в NAT route-map, согласовывающее исходящий интерфейс), это единственный путь настройки на основе интерфейса NAT пула в Cisco IOS.
________________________________________________
Большинство ISP не готовы запускать протоколы динамической маршрутизации с небольшими сайтами, поэтому настройте на вашем конце статическую маршруты по умолчанию. Вы почти всегда предпочтете одного провайдера другому(обычно это вопрос цены и качества), (поэтому 1 маршрут по умолчанию должен быть с более низкой административной дистанцией (AD)), как показано ниже (Листинг 3), хотя есть также возможность использовать 2 маршрута по умолчанию с одинаковой AD при настройке балансировки нагрузки( с CEF свичингом, используя распределение нагрузки по точке назначения).
ЛИСТИНГ 3 Базовая установка multihomed маршрутизации по умолчанию.
_______________________________________________
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10
ip route 0.0.0.0 0.0.0.0 Serial0/0/1 251
_______________________________________________
Упрощенная статическая маршрутизация является главной проблемой готовности и доступности - если вы не можете обнаружить отказ на линке к ISP A, статический маршрут по умолчанию к ISP B никогда не будет использоваться. Хотя вы почти всегда можете обнаружить отказ выделенной линии или кабеля (из-за потери несущего сигнала) также можно обнаружить отказ Frame-Relay через Local Management Interface(LMI) сообщения и спомощью keepalives, это почти невозможно обнаружить при отказе на втором уровне OSI в PPPoE или на уровне доступа в Metro Ethernet. В этих случаях основной маршрут по умолчанию никогда не пропадёт (даже несмотря на то, что следущие (next-hop) маршрутизаторы недостижимы), делая статический multihoming невозможным. Однако эта проблема решается в версии Cisco IOS 12.3(8)T (влючен в версию 12.4) с помощью связки статических маршрутов со значением IP SLA.
Не совсем статический маршрут.
Релиз Cisco IOS 12.3(4)T Представил Расширенный Объект Слежения (Enhanced Object Tracking), который вместе с Надёжной Статической Маршритизацией, Использующей Объект Слежения введённый в IOS релизе 12.3(8)T решает нашу проблему. Расширенный Объект Слежения представляет общий объект track (следить), который может отследить состояние интерфейса (на 2 и 3 уровнях), существование или метрику маршрута, состояние SLA или даже пригодности GPRS узла. Даже больше, вы можете комбинировать различные track объекты (включая их взвешивание) в в объединённый объект.
Надёжная статическая маршрутизация, использующая объект слежения связывает track объект со статическим маршрутом - всякий раз когда track объект переходит в состояние down(вниз, а проще говоря когда объект падает), статический маршрут удаляется из таблицы маршрутизации, как раз то что нужно для поддержки надёжного multihoming. Для настройки статического маршрута, основанного на состоянии следующего (next-hop) маршрутизатора вам нужно :
- Настроить ip sla (ранее известных как Response Time Reporter – rtr) объект, пингующий next-hop маршрутизатор на основном Internet линке (Листинг 4). Частоту (frequency) последовательного опроса вы определяете ( в секундах) в зависимости от требований надёжности, но нужно быть осторожным т.к. это загружает next-hop маршрутизатор.
ЛИСТИНГ 4 Пингуем next-hop маршрутизатор.
________________________________________________
ip sla 100
icmp-echo 172.16.1.2 source-interface Serial0/0/0
timeout 500
frequency 3
ip sla schedule 100 life forever start-time now
________________________________________________
________________________________________________
Примечание
Вы не можете изменить параметр SLA объекта однажды создав его. Для изменения IP-адреса назначения, таймаута и частоты последовательного запроса, вам нужно будет удалить SLA объект и создать его заново.
________________________________________________
- Создать track объект, мониторящий достижимость SLA цели (Листинг 5). Вероятно вы не хотите, чтобы система реагировала на потерю единичного ICMP пакета, поэтому используйте у track объекта опцию delay, определяющую как долго next-hop маршрутизатор должен оставаться недоступным перед тем как его объявят потерянным (down delay должна быть приблизительно в 3 раза больше частоты последовательного запроса SLA (SLA polling frequency), а параметр up delay должен быть ещё больше.
________________________________________________
Примечание
Когда расчитываете параметр up delay, помните что роутер может
временно отвечать на пинги в течении bootstrap процесса(Bootstrap - начальный загрузчик , который загружается сразу после включения маршрутизатора. Bootstrap можно сравнить с BIOS в компьютере. Он проверяет внутреннюю целостность маршрутизатора: процессор, память и т.д., какие присутствуют модули, определяет стратегию загрузки IOS (в каком порядке и откуда его грузить)) .
_________________________________________________
ЛИСТИНГ 5 Отслеживание состояния next-hop маршрутизатора.
_________________________________________________
track 100 rtr 100 reachability
delay down 10 up 20
_________________________________________________
- После настройки track объекта , добавляем это на основной статический маршрут по умолчанию для гарантии что маршрут по умолчанию будет удалён если next-hop маршрутизатор недоступен (Листинг 6).
ЛИСТИНГ 6 Условный статический маршрут по умолчанию.
__________________________________________________
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10 track 100
ip route 0.0.0.0 0.0.0.0 Serial0/0/1 251
__________________________________________________
Вы можете соответствующую работу статической маршрутизации с помощью команды show ip route. Листинг 7 показывает таблицу IP маршрутизации на маршрутизаторе GW когда основной next-hop маршрутизатор доступен, Листинг 8 показывает таблицу маршрутизации после отказа основного next-hop маршрутизатора.
ЛИСТИНГ 7 Таблица маршрутизации с работающим основным next-hop маршрутизатором
__________________________________________________
GW#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
172.17.0.0 255.255.255.252 is subnetted, 1 subnets
C 172.17.3.0 is directly connected, Serial0/0/1
172.16.0.0 255.255.255.252 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Serial0/0/0
C 192.168.0.0 255.255.255.0 is directly connected, FastEthernet0/0
S* 0.0.0.0 0.0.0.0 is directly connected, Serial0/0/0
___________________________________________________
ЛИСТИНГ 8 Таблица маршрутизации после отказа next-hop маршрутизатора
___________________________________________________
GW#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
172.17.0.0 255.255.255.252 is subnetted, 1 subnets
C 172.17.3.0 is directly connected, Serial0/0/1
172.16.0.0 255.255.255.252 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Serial0/0/0
C 192.168.0.0 255.255.255.0 is directly connected, FastEthernet0/0
S* 0.0.0.0 0.0.0.0 is directly connected, Serial0/0/1
____________________________________________________
Мониторинг надёжной статической маршрутизации
Надёжная статическая маршрутизация "потихому" добавляет или убирает из таблицы маршрутизации, основанной на состоянии приложенного track объекта; единственными средствами контроля за ней является команда show ip route track-table (Листинг 9) или команда debug track (Листинг 10).
ЛИСТИНГ 9 Показ отслеживаемых маршрутов
_____________________________________________________
GW#show ip route track-table
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10 name ISP_A track 100 state is [down]
_____________________________________________________
ЛИСТИНГ 10 Отладка отслеживания
_____________________________________________________
GW#debug track
06:49:44: Track: 100 Down change delayed for 10 secs
06:49:54: Track: 100 Down change delay expired
06:49:54: Track: 100 Change #26 rtr 100, reachability Up->Down
06:50:24: Track: 100 Up change delayed for 20 secs
06:50:34: Track: 100 Up change delay cancelled
06:58:59: Track: 100 Up change delayed for 20 secs
06:59:19: Track: 100 Up change delay expired
06:59:19: Track: 100 Change #25 rtr 100, reachability Down->Up
_____________________________________________________
_____________________________________________________
Примечание
Распечатка отладки в Листинге 10 показывает жизненный сценарий, где next-hop маршрутизатор становится временно достижимым в процессе bootstrap и исчезает несколько минут спустя.
_____________________________________________________
Хотя "тихое" изменение таблицы маршрутизации может быть допустимо в большинстве случаев (вы не получите уведомления когда постоянный маршрут исчезает из таблицы маршрутизации), вы можете хотеть знать что ваш основной ISP недостижим (похожие на up/down события вы получите при использовании традиционных методов подключения: выделенная линия и Frame-relay). Встроенный Event Manager 2.2 (появился в IOS релизе 12.4(2)T является идеальным решением, так вы можете запускать EEM аплеты (или TCL скрипты) всякий раз когда состояние track объекта изменилось с помощью команды event track.
Для показа изменеий в состоянии отслеживаемых объектов вы можете определить 2 EMM аплета, один срабатывает на изменение down? второй на изменение up. Если вы хотите только быть уведомлённым, что состояние изменилось, тогда только действие вам необходимо определить действие syslog msg, но вы можете выполнять любое количество действий по желанию (например посылать e-mail сетевому администратору или даже перенастраивать маршрутизатор). Простая EEM настройка показана ниже (Листинг 11), результат отображен в Листинге 12 .
ЛИСТИНГ 11 IOS EEM генерирует syslog сообщение на отслеживаемое состояние изменения объекта
______________________________________________________
event manager applet ISP_A_down
event track 100 state down
action 1.0 syslog msg "ping to 172.16.1.2 from Serial 0/0/0 failed"
event manager applet ISP_A_up
event track 100 state up
action 1.0 syslog msg "172.16.1.2 is reachable"
______________________________________________________
ЛИСТИНГ 12 Пример EMM вывода
______________________________________________________
07:02:19: %HA_EM-6-LOG: ISP_A_down: ping to 172.16.1.2 from Serial 0/0/0 failed
07:03:19: %HA_EM-6-LOG: ISP_A_up: 172.16.1.1 is reachable
______________________________________________________
Проверка связи
После того как вы успешно настроили отслеживание готовности основного next-hop маршрутизатора вы может захотите улучшить решение для проверки связи через ISP A и переключать на резервного ISP всякий раз когда ваш головной офис недоступен через основной канал. В теории требуемые изменения в настройке должны быть минимальными - вы только IP-адрес назначения в IP SLA определении (Листинг 13).
ЛИСТИНГ 13 Пингование удалённого хоста
______________________________________________________
hostname GW
!
ip sla 100
icmp-echo 172.29.0.1 source-interface Serial0/0/0
timeout 200
frequency 10
ip sla schedule 100 life forever start-time now
______________________________________________________
В большинстве случаев это все что вы должны сделать. Поскольку ICMP эхо, отправленные на ваш головной офис, приходят с IP-адреса принадлежащего ISP A (IP адрес в примере настроен на Serial 0/0/0), маловероятно, что бы вы получили пакет обратно, если бы у ISP A были бы проблемы. Однако возвращающийся пакет может также достигнуть ваш маршрутизатор при определённых обстоятельcnвах (неправильно настроенный список доступа(access-list) или одностороннее(one-way) подключение в ISP A. Результаты удивительны:
- Поскольку пинги через ISP A не проходят(основной маршрут по умолчанию), маршрутизатор удаляет основной маршрут по умолчанию и устанавливает резервный, через ISP B.
- Пинги сейчас идут от адреса, принадлежащего ISP A через ISP B
- Если есть обраный путь от центрального офиса до IP-адреса, посылающего ICMP пакеты, центральный офис будет снова казаться достижимым и основной маршрут по умолчанию будет восстановлен (что быдет приводить к потере соединения).
- Из-за возобновлённой потери соединения маршрутизатор будет колебаться между двумя маршрутами по умолчанию (Листинг 14).
ЛИСТИНГ 14 Колебания маршрутизации
______________________________________________________
GW#debug track
07:15:09: Track: 100 Change #32 rtr 100, reachability Up->Down
07:15:09: %HA_EM-6-LOG: ISP_1_down: ping to 172.29.0.1 from Serial 0/0/0 failed
07:15:19: Track: 100 Up change delayed for 20 secs
07:15:39: Track: 100 Up change delay expired
07:15:39: Track: 100 Change #33 rtr 100, reachability Down->Up
07:15:39: %HA_EM-6-LOG: ISP_1_up: 172.29.0.1 is reachable
07:15:49: Track: 100 Change #34 rtr 100, reachability Up->Down
07:15:49: %HA_EM-6-LOG: ISP_1_down: ping to 172.29.0.1 from Serial 0/0/0 failed
07:15:59: Track: 100 Up change delayed for 20 secs
______________________________________________________
Для исправления этих (правда редких) проблем вы должны настроить локальные политики маршрутизации ( поскольку ip sla пакеты возникают внутри маршрутизатора, они затронуты только ip local policy) которые сопоставляют ICMP пакеты, посланные от интерфейса Serial0/0/0 (основываясь на его IP-адресе; access-list PingISP_A) и заставляют их отправляться с того же интерфейса с помощью команды set interface (Листинг 15).
ЛИСТИНГ 15 Иcправление колебания маршрутизации с помощью локальных политик
______________________________________________________
ip local policy route-map LocalPolicy
!
ip access-list extended PingISP_A
permit icmp host 172.16.1.1 host 172.29.0.1
!
route-map LocalPolicy permit 10
match ip address PingISP_A
set interface Serial0/0/0
_______________________________________________________
Если пожелаете, можете расширить концепцию, представленную в этой секции ещё больше. Например если головной офис недоступен и через оба ISP (оба упали), имеет смысл сохранить ISP A как основной ISP. Таким образом вы должны отслеживать доступность центральный офиса через оба ISP и настроить настроить надёжный маршрут по умолчанию для обоих (резерный канал конечно же с более высокой AD). Полная конфигурацию включает в себя Листинг 16, его интерпретация остаётся в качестве упражнения для читателей.
ЛИСТИНГ 16 Маршрутизатор GW отслеживает доступность центрального офиса через оба ISP
_______________________________________________________
hostname GW
!
ip cef
!
ip dhcp pool LAN
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
!
ip sla 100
icmp-echo 172.29.0.1 source-interface Serial0/0/0
timeout 200
frequency 3
ip sla schedule 100 life forever start-time now
!
ip sla 101
icmp-echo 172.29.0.1 source-interface Serial0/0/1
timeout 500
frequency 3
ip sla schedule 101 life forever start-time now
!
track 100 rtr 100 reachability
delay down 10 up 20
!
track 101 rtr 101 reachability
delay down 10 up 20
!
interface FastEthernet0/0
ip address 192.168.0.1 255.255.255.0
ip nat inside
!
interface Serial0/0/0
description *** Link to ISP 1 ***
ip address 172.16.1.1 255.255.255.252
ip nat outside
!
interface Serial0/0/1
description *** Link to ISP 2 ***
ip address 172.17.3.1 255.255.255.252
ip nat outside
!
ip local policy route-map LocalPolicy
!
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 10 track 100
ip route 0.0.0.0 0.0.0.0 Serial0/0/1 11 track 101
ip route 0.0.0.0 0.0.0.0 Serial0/0/0 250
ip route 0.0.0.0 0.0.0.0 Serial0/0/1 251
!
!
ip nat inside source route-map ISP_A interface Serial0/0/0 overload
ip nat inside source route-map ISP B interface Serial0/0/1 overload
!
ip access-list extended PingISP_A
permit icmp host 172.16.1.1 host 172.29.0.1
ip access-list extended PingISP_B
permit icmp host 172.17.3.1 host 172.29.0.1
!
route-map ISP_A permit 10
match interface Serial0/0/0
!
route-map ISP_B permit 10
match interface Serial0/0/1
!
route-map LocalPolicy permit 10
match ip address PingISP_A
set interface Serial0/0/0
!
route-map LocalPolicy permit 20
match ip address PingISP_B
set interface Serial0/0/1
!
!
event manager applet ISP_A_down
event track 100 state down
action 1.0 syslog msg "ping to central site from Serial 0/0/0 failed"
event manager applet ISP_A_up
event track 100 state up
action 1.0 syslog msg "central site is reachable"
event manager applet ISP_B_down
event track 101 state down
action 1.0 syslog msg "ping to central site from Serial 0/0/1 failed"
event manager applet ISP_B_up
event track 101 state up
action 1.0 syslog msg "central site is reachable"
!
en
Резюме
В связи с заменой традиционных WAN сетей на VPN MPLS или решения, основанные на Internet, возрастает важность хорошего проекта и стратегии осуществления для небольшого multihomed сайта. Легко осуществить multihomed сайт в случае работы динамических протоколов марщрутизации между customer edge (CE) и provider edge (PE) роутерами, как и в большинстве случаев реализации VPN MPLS, статическая маршрутизация по умолчанию применяется у большинства клиентов ISP. В этом случае надёжный multihoming почти невозможен в современных сетях , потому что они не в состоянии отследить потерю сигнала 2-го уровня.
Надёжная статическая маршрутизация (Reliable Static Routing) использует функцию отслеживания объекта доступную в релизе 12.4 Cisco IOS, позволяющую вам привязывать жизнеспособные статические маршруты к отслеживаемым объектам (интерфейс, другой маршрут ...). Если следить за состоянием next-hop маршрутизатора, можно надёжно обнаруживать отказы на 3-м уровне, запуская перенаправление (rerouting) на резервного провайдера. Вы можете улучшить этот проект следя за связью из центрального офиса и перенаправлять на резервного провайдера всякий раз когда вы не можете достигнуть центрального офиса через основного провайдера. Даже больше, вы не можете полагаться на ICMP эхо пакеты; функция IP SLA может отслеживать доступность большлго количества приложений(например центральный web-сервер вашей компании).
Комментариев нет:
Отправить комментарий