Ключевые слова:cisco, dialup, backup, leased, (найти похожие документы)
From: Roman Shramko <http://dormestmass.blogspot.com>;
Date: Mon, 3 Jan 2008 14:31:37 +0000 (UTC)
Subject: Dial Backup выделенных каналов на Cisco
Оригинал: http://dormestmass.blogspot.com/2007/05/dial-backup-cisco.html
В последнее время, в связи с внедрением он-лайн ПО, передо мной остро
стал вопрос резервирования основного канала связи для региональных
отделений. Отделения соединены с Дирекцией каналами Frame Relay, в
качестве маршрутизаторов используются маршрутизаторы cisco 17 серии.
Также на каждом отделении присутствует модем, который используется для
приема входящих звонков клиентов.
У маршрутизаторов cisco существует технология резервирования основного
канала передачи данных, т.н. DDR (dial-on-demand routing). Когда
маршрутизатор со сконфигурированным DDR обнаруживает потерю основного
соединения, то он инициирует DDR соединение с центральным
маршрутизатором, используя dialup соединение.
Вот и я решил воспользоваться данной технологией для резервирования
каналов на отделения. И вот что у меня получилось.
Существует три методики поднятия dialup соединения:
1. командой backup interface на интерфейсе основного канала. Имеет
очень большой плюс в том, что позволяет определить задержку, по
истечению которой будет подниматься backup link. И большой минус,
заключающийся с том, что dialup соединение будет поднято до тех
пор, пока не восстановится основной канал, независимо, ходят
какие-то данные по этому backup каналу, или нет. С учетом того,
что для большинства отделений это будет оплата междугородки, я
отверг этот вариант.
2. при помощи плавающей маршрутизации (floating static routes). Этот
вариант мне показался наиболее приемлимым. Его то я и использовал.
Из недостатков - возможно поднятия backup линка при
кратковременном пропадании основного канала. Ну дернул провайдер
порт, на минутку канал упал. А маршрутизатор уже звонит :). Но это
компенсируется гибкими настройками условий для совершения звонка.
3. при помощи команды dialer watch. Данный способ является скорее
подмножеством предыдущего.
При настройке DDR требовалось сохранить возможность принимать входящие
звонки на модем, через который будет работать backup. После того, как
мы определим физический интерфейс в качестве резервного, он уходит в
standby режим и мы уже не сможем на него совершать звонки. Поэтому,
для сохранения возможности dialin необходимо настроить маршрутизатор
на использование логических интерфейсов (dialer profile), как для
приема входящих, так и для выполнения исходящих звонков.
Основная идея метода floating static routes заключается в следующем.
Необходимо определить статические маршруты, которые имеют
административную дистанцию больше, чем административная дистанция
маршрутов через основной канал.
Пока основной канал будет доступен, эти маршруты задействованы не
будут. Как только канал пропадет, а с ним уйдут и маршруты с меньшей
административной дистанцией, наши статические маршруты вступят в силу
и направят траффик через альтернативный интерфейс. А альтернативным
интерфейсом у нас будет DDR интерфейс.
После того, как основной канал восстановится, восстановятся и маршруты
через него. Соответственно через backup интерфейс перестанет идти
траффик и маршрутизатор разорвет соединение по таймауту.
Добиться того, чтобы при падении основного канала пропадал маршрут
через него, можно несколькими путями. Лучше всего использовать
динамическую маршрутизацию. Можно пользоваться и статической,
поскольку в случае падения интерфейса маршрутизатор удаляет записи из
таблицы маршрутизации, связанные с этим интерфейсом. Однако тут есть
подводный камень, по крайней мере для интерфейсов Frame Relay.
Провайдер не всегда отдает состояние PVC на протяжении всего канала.
Т.е. PVC может быть разорван на каком-то из промежуточных узлов, а на
локальном конце он будет находится в состоянии ACTIVE. Соответственно,
маршрутизатор не будет считать данный интерфейс упавшим. Для борьбы с
этим, можно включить в map-class обмен keepalive пакетами.
map-class frame-relay someclass
frame-relay end-to-end keepalive mode bidirectional
...
Попутно замечу, что все маршрутизаторы используют единый tacacs сервер
для ААА.
Для начала необходимо создать dialer profiles и сконфигурировать
физический интерфейс:
aaa authorization network BACKUP none
! объяснения для чего это нужно ниже
! Настройка физического интерфейса
interface Serial1/0
physical-layer async
no ip address
encapsulation ppp
no ip mroute-cache
no logging event link-status
dialer in-band
! указали что этот интерфейс будет использован для DDR
dialer pool-member 1
! создан пул 1 для использования с dial profile
async default routing
async mode interactive
no peer default ip address
ppp authentication chap pap callin
!
! Настройка dialer profiles
!
! Интерфейс, через который будет непосредственно
! подниматся backup line
interface Dialer0
ip address negotiated
encapsulation ppp
ip tcp header-compression
no logging event link-status
dialer pool 1
! указали какой пул физических интерфейсов используется
dialer remote-name central-router
! Имя удаленного узла, используется в случае
! CHAP аутентификации
dialer idle-timeout 180
! Время в сек, через которое маршрутизатор разорвет
! данное соединение, в случае отсутствия передаваемых данных
dialer string p8,,,XXXXXXXXX
! телефон дозвона
dialer hold-queue 20
! размер очереди на исходящие звонки
dialer redial interval 7 attempts 20 re-enable 5
! тут количество попыток дозвона
dialer-group 1
! привязка интерфеса к dialer-list
no peer default ip address
no cdp enable
ppp authentication pap callin
ppp authorization BACKUP
! при отладке работы столкнулся с ситуацией, когда
! звонящий маршрутизатор, т.е. данный, пытается
! проавторизировать удаленный маршрутизатор через tacacs сервер
! который в данный момент, естественно, недоступен
! поскольку данный интерфейс используется только для
! совершения исходящих звонков, то авторизацию просто отключаем
ppp pap sent-username backup_user password 7 XXXXXXXXXXXXXXXXXXXXXXX
!
! Данный интерфейс фактически не используется, но нужен
! для работы виртуальных интерфейсов из-за какого-то
! там бага, по крайней мере так написано на cisco.com
interface Dialer1
description dummy dialer
no ip address
encapsulation ppp
no ip mroute-cache
no logging event link-status
dialer pool 1
peer default ip address pool defualt
no cdp enable
ppp authentication chap pap
!
После настройки dialer profile для совершения исходящих звонков,
необходимо создать dialer-list, который, собственно, и будет
определять, когда и при каких условиях стоит поднимать backup link.
Т.е. помимо того, что мы при помощи плавающего статического маршрута
направляем траффик в интерфейс dialer 0, этот траффик ещё должнен
удовлетворять условиям dialer-list.
! Для начала создадим ACL с интересным траффиком, т.е.
! при наличие которого будет совершен звонок
! Временной диапазон, для использования в ACL
! Наши отделения не работают ни ночью, ни в выходные
! соответственно мы не хотим совершать звонки в это время :)
!
time-range only-during-work-hours
absolute start 00:00 01 January 2005
periodic weekdays 8:00 to 20:00
periodic Saturday 8:00 to 20:00
!
! А вот и сам ACL
access-list 166 remark Interest traffic for Backup Link
access-list 166 permit ip a.a.a.0 0.0.0.255 xxx.0.0.0 0.255.255.255 time-range
only-during-work-hours
access-list 166 permit ip a.a.a.0 0.0.0.255 yyy.yyy.0.0 0.0.255.255 time-range
only-during-work-hours
access-list 166 permit ip a.a.a.0 0.0.0.255 zzz.zzz.zzz.0 0.0.0.255 time-range
only-during-work-hours
! Определение dialer-list
dialer-list 1 protocol ip list 166
При использовании временных диапазонов следует убедиться, что на
маршрутизаторе правильно установлено время. И, желательно, чтобы это
время синхронизировалось с каким-нибудь сервером времени. Иначе
возможны загадочные звонки ночью и, неменее загадочное отсутствие
звонков днем.
Совершенно не экономные люди могут не заморачиваться с ACL и
временными диапазонами, а определить dialer-list таким образом:
dialer-list 1 protocol ip permit
С данным списком, backup link будет подниматься при наличие любого
траффика через интерфейс.
Для работы DDR осталось сконфигурировать всего ничего - плавающие
статические маршруты.
ip route xxx.0.0.0 255.0.0.0 Dialer0 200
ip route yyy.yyy.0.0 255.255.0.0 Dialer0 200
ip route zzz.zzz.zzz.0 255.255.255.0 Dialer0 200
Выбор административной дистанции 200 совершенно произволен. Главное,
чтобы она была больше административной дистанции маршрутов через
основной канал. Для протоколов динамической маршрутизации значения
административной дистанции следующие:
* EIGRP - 90
* IGRP - 100
* OSPF - 110
* RIP - 120
* External EIGRP - 170
После конфигурирования плавающих маршрутов настройка DDR завершена.
Осталось только настроить маршрутизатор принимать входящие звонки. Для
этого используем virtual template.
!
virtual-profile if-needed
virtual-profile virtual-template 1
! Включаем использование виртуальных профилей
!
!
interface Virtual-Template1
ip unnumbered FastEthernet0/0
no ip redirects
no ip unreachables
ip tcp header-compression
no logging event link-status
ntp disable
peer default ip address pool default
ppp authentication chap pap
!
Осталась лишь пара замечаний.
При использовании динамической маршрутизации маршрут на удаленном
роутере для данной сети будет создан автоматически. А вот в случае
использования статической маршрутизации необходимо такие маршруты
создать вручную. Я делаю это через tacacs. После успешной
аутентификации backup_user на центральном маршрутизаторе создается
маршрут.
aaa# cat tacacs.conf
...
user = backup_user {
....
service = ppp protocol = ip {
...
addr = "aaa.aaa.aaa.bbb"
route = "aaa.aaa.aaa.0 255.255.255.0 aaa.aaa.aaa.bbb 200"
}
}
Кроме того, при использовании протоколов динамической маршрутизации
желательно настроить интерфейс Dialer 0 как пассивный, иначе возможно
поднятие интерфейса из-за попыток отправить через него hello-пакеты,
особенно при использовании dialer-list разрешающего любой траффик.
router ospf 55555
...
passive-interface Dialer0
