Про dualhoming в небольшой сети при подключении к Интернету

Сегодня практически невозможно представить себе организацию, которая бы не использовала в своей деятельности Интернет. Он нужен и для получения электронной почты, и для взаимодействия с государственными органами, для получения нужной информации и так далее -, перечислять можно практически бесконечно.  Поэтому создание надежного, стабильного канала доступа в Интернет является одной из ключевых задач в работе сетевых администраторов в любой компании. Очевидно, что механизмы, которые будут использованы для создания надежного канала доступа в Интернет, будут зависеть от критичности такого доступа и от ресурсов, в первую очередь материальных, которые компания готова потратить. С технической точки зрения, решения могут быть от подключения к Интернету по ADSL через одного провайдера (ISP) без резерва до покупки собственного диапазона публичных адресов, создания собственной автономной системы, установки eBGP сессий с несколькими ISP и анонсирования им своих адресов. Первое решение крайне не надежно, а второе – дорого. Хотя, конечно, все зависит от потребностей.

В данной статье мы рассмотрим некий баланс, который, с нашей точки зрения, отлично подойдет многим организациям, для которых доступ в Интернет критичен для бизнес-процессов, но необходимости (или возможности) создать собственную автономную систему — нет. Вообще, термин dualhoming в компьютерных сетях обозначает подключение к двум ISP одновременно.

Пример, который мы сейчас рассмотрим, является реальной практической задачей, которую наша команда решала еще в 2010 году. Поэтому, если у тебя возникает аналогичная задача, ты можешь просто скопировать настройку оборудования Cisco из этой статьи, и тебя все будет работать. А если по каким-то причинам не будет – обращайся, мы с радостью тебе поможем. Итак, начнем. Схема подключения организации к Интернету выглядит следующим образом:

 

Рисунок 1 / схема подключения к двум провайдерам

Рисунок 1 / схема подключения к двум провайдерам

Немного прокомментируем схему:

CE (Client Edge) – это наш маршрутизатор Cisco, а процессе работы мы можем настраивать только его;

AR (Aggregation Router) – в нашем случае это был обыкновенный маршрутизатор, у которого не было поддержки динамических протоколов маршрутизации. На самом деле, на его месте может быть что угодно, любое провайдерское устройство доступа;

PE-1 и PE-2 – граничные маршрутизаторы провайдеров, которые осуществляют доступ в Интернет.

Сразу оговоримся, сеть ISP в нашем случае очень упрощена. Понятное дело, что она состоит из огромного числа компонентов и доступ к услугам совершенно не так прост, как тут нарисовано. Упрощена сеть ISP, потому что не операторские решения являются фокусом данной статьи, а решения, которые инженеры могут самостоятельно внедрить в своих Enterprise решениях.

Собственно, задача, которая стоит перед нами, — это обеспечение доступа в Интернет. Условия задачи:

1)      Основной канал доступа в Интернет – канал через PE-1;

2)      В случае выхода из строя основного канала (авария на участке CE – AR, AR – PE-1) трафик должен быть переключен на резервный канал – через PE-2;

3)      После восстановления основного канала трафик должен быть снова пущен через него;

4)      Динамическую маршрутизацию использовать нельзя;

Входные данные мы обозначили, пора приниматься за ее решение. Беглый обзор условий показывает основную потенциальную проблему: если падает канал AR – PE-1, и динамической маршрутизации у нас нет, то нам необходим какой-то механизма, который бы оповещал наш CE маршрутизатор об аварии. В противном случае у нас не произойдет переключение на резервный маршрут, и трафик будет теряться. Таким механизмом оповещения у нас будет IP SLA. Подробнее о том, что это такое, и с чем его едят, ты можешь прочитать на cisco.com. Штука довольно интересная и полезная, нам она в первую очередь интересна тем, что позволяет проверять доступность IP-адреса устройства. Настройка этого механизма для нашей задачи довольно простая:

CE(config)# ip sla monitor 1
CE(config-ipsla)# type echo protocol ipIcmpEcho 10.10.0.1 source-interface FastEthernet0/0
CE(config)# ip sla monitor schedule 1 life forever start-time now

Вторая строчка настройки как раз и определяет, как будет наш монитор работать: мы будем посылать регулярные icmp echo на IP-адрес 10.10.0.1 через интерфейс fa 0/0. Третья строчка настройки запускает в работу наш монитор (с теперешнего момента и до скончания веков J). Она не относится к настройке монитора, но если ее не указать, то монитор просто не начнет работу, хотя может быть полностью настроен.

Следующим шагом является создание механизма, который бы связал результаты работы нашего IP SLA монитора с манипуляцией статическими маршрутами. Таким механизмом в оборудовании Cisco является трэкинг (англ «track» — проверка, отслеживание). Как и в случае с IP SLA, он может быть использован для огромного количества задач. В нашем случае данный трэк будет привязан к основному статическому маршруту по умолчанию (через 10.10.0.1) и будет убирать его из таблицы маршрутизации, если указанный IP-адрес станет недоступен:

СE(config)# track 123 rtr 1 reachability
СE(config-track)#delay down 5 up 10

Первая строчка настройки трэкинга указывает на то, что использовать результаты монитора 1 по параметру доступности (ответа на icmp echo). Вторая строчка указывает тайм ауты, которые будут проходить, прежде чем трэкинг будет срабатывать. Это необходимо для того, чтобы избежать бесконечных переключений трафика между каналами в случае «флапанья» (переход из рабочего состояния в нерабочее или наоброт), которое может быть обусловлено плохой физической линией или техническими работами на сети провайдера.

Остается только привязать этот трэк к статическому маршруту и наш конфиг готов:

СE(config)# ip route 0.0.0.0 0.0.0.0 10.10.0.1 track 123
СE(config)# ip route 0.0.0.0 0.0.0.0 20.20.0.1 20
СE(config)# ip route 10.10.0.0 255.255.255.252 10.10.0.5

Для передачи трафика по резервному каналу, нам необходим статический маршрут, который бы указывал на PE-2. Однако в нормальном режиме работы, этого маршрута не должно быть в таблице маршрутизации. Для этого мы выставляем его AD (Administrative Distance, административное расстояние) ниже стандартного значения. Стандартное значение AD для статических маршрутов – «1».  Маршрут на 10.10.0.0/30 нужен для того, маршрутизатор CE мог отправлять тестовые запросы IP SLA монитора на нужный адрес даже в том случае, когда маршрута по умолчанию через PE-1 в таблице маршрутизации нет.

Общая логика работы нашего решения выглядит следующим образом:

1)      В нормальном режиме работы трафик передается через PE-1. Через интерфейс Fa 0/0 маршрутизатора CE регулярно посылаются icmp запросы на PE-1.

2)      Если маршрутизатор CE перестает получать icmp ответы, срабатывает флаг track 123, который удаляет из таблицы маршрутизации CE статический маршрут по умолчанию через PE-1.

3)      В таблице маршрутизации появляется маршрут по умолчанию через PE-2, которого там не было изначально в силу меньшего AD, чем у маршрута через PE-1. Трафик начинает передаваться через новый маршрут.

4)      Когда CE начнет получать ответы на icmp запросы от PE-1, изначальный маршрут по умолчанию через PE-1 будет возвращен в таблицу маршрутизации и трафик будет переключен на основной канал.

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

Финальный конфиг нашего маршрутизатора CE выглядит следующим образом:

CE#show run
Building configuration…
Current configuration : 1687 bytes
!
version 12.4
!
hostname CE
!
ip sla monitor 1
type echo protocol ipIcmpEcho 10.10.0.1 source-interface FastEthernet0/0
ip sla monitor schedule 1 life forever start-time now
!
track 123 rtr 1 reachability delay down 5 up 10
!
interface FastEthernet0/0
ip address 10.10.0.6 255.255.255.252
duplex auto
speed auto
!
interface Serial0/0
bandwidth 256
ip address 20.20.0.2 255.255.255.252
clock rate 256000
!
interface FastEthernet0/1
ip address 30.30.0.254 255.255.255.0
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.0.1 track 123
ip route 0.0.0.0 0.0.0.0 20.20.0.1 20
ip route 10.10.0.0 255.255.255.252 10.10.0.5
!
End

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


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me