отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel

Автоматизация в сети передачи данных при использовании OSPF и RIP: редистрибуция маршрутов на основе меток и действий EEM

2715
Просмотры
5
Полезный материал
7
Комментарии

ПРЕДИСЛОВИЕ

В этой статье рассматривается применение редистрибуции маршрутов между протоколами OSPF и RIP для автоматизации действий при сбое в работе одного из устройств в сети, а именно: изменение маршрутизации потоков данных при срабатывании определенных условий. Описываемая концепция работает как для двух, так и для 1000 филиалов.

ИСХОДНЫЕ ДАННЫЕ

Сеть состоит из головного офиса HQ и двух филиалов - Office #1 и Office #2, в каждом узле схожий набор оборудования:

  • маршрутизатор - R0, R1 и R2;
  • коммутатор с поддержкой статических маршрутов и протокола RIP - SW0, SW1 и SW2;
  • “черный ящик” (Black Box) - Blb0, Blb1 и Blb2.

В предлагаемом решении используются следующие протоколы динамической маршрутизации:

  • между коммутатором SWx и маршрутизатором Rx - протокол RIP;
  • для обмена маршрутной информации между головным офисом и филиалами - протокол OSPF.

Для демонстрации того, как гибко можно управлять маршрутизацией в сети добавим условие, что в случае сбоя в работе "черного ящика" необходимо, чтобы заданная группа пользователей могла дальше работать с ресурсами головного офиса и/или с другими филиалами. При этом в случае нормальной работы "черного ящика" все потоки данных должны идти через него.

 

Figure 1. Connecting network devices in HQ and branchesFigure 1. Connecting network devices in HQ and branches

 

Figure 3. Exchange of route information from R0 to SW0Figure 3. Exchange of route information from R0 to SW0

 

Figure 2. Exchange of route information from SW0 to R0Figure 2. Exchange of route information from SW0 to R0

 

ОПИСАНИЕ ПРИНЦИПА РАБОТЫ 

Итак, если “черный ящик” перестал работать должным образом, то один из вариантов решения проблемы - временно исключить это устройство из схемы маршрутизации трафика. В этом случае на помощь приходят динамические протоколы маршрутизации, сервисы IP SLA для отправки icmp-запросов и Embedded Event Manager (EEM) для выполнения действий при потере отправленных icmp-пакетов.

Дальше будем рассматривать принцип работы предлагаемого решения на примере выхода из строя "черного ящика" в Office #1, при этом “временную схему” работы сети настраиваем только для группы пользователей, чьи адреса попадают в диапазон 10.1.254.2-10.1.254.15, а отстальным адресам из диапазона 10.1.254.0/24 запрещена работа в случае недоступности "черного ящика".

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

Шаг №1: Изменяем таблицу маршрутизации на коммутаторе SW1

Недоступность “черного ящика” в Office #1 будем оценивать с помощью IP SLA теста на маршрутизаторе R1.

При внедрении “временной схемы” первым шагом требуется сообщить коммутатору SW1 в Office #1 куда отправлять трафик, т.е. указать какой next-hop использовать для передачи потоков данных вместо отправки их на “черный ящик”. Для этого используем функционал event manager applet на локальном маршрутизаторе R1, который реагирует на потерю icmp-запросов на адрес 10.1.255.2 в IP SLA тесте.

В результате срабатывания event manager applet маршрутизатор R1 отправляет маршрут 10.0.0.0/8 через протокол RIP коммутатору SW1. При этом на коммутаторе SW1 приоритеты настроены таким образом, что маршруты протокола RIP более предпочтительны, чем статические маршруты (см. Cisco Administrative Distances). Таким образом, решаем первую часть проблемы для временного исключения из работы “черного ящика” Blb1.

### R1 ###
!
router rip
version 2
redistribute static metric 12 route-map static2rip
redistribute ospf 1 metric 10 route-map ospf2rip
passive-interface default
no passive-interface Ethernet0/2
network 10.0.0.0
default-metric 5
no auto-summary
!

ip prefix-list commonnet seq 10 permit 10.0.0.0/8
!
route-map static2rip deny 10
match ip address prefix-list commonnet
!
event manager applet blblo0-down trap
event track 1 state down
...
action 2.0 syslog msg "Blb interface Lo0 is DOWN. Start to anonce route 10.0.0.0/8 to LANSW"
action 2.1 cli command "enable"
action 2.2 cli command "configure terminal"
action 2.3 cli command "route-map static2rip permit 10"
action 2.4 cli command "end"

Ниже приведен вывод команды show ip route с коммутатора SW1 при нормальной работе “черного ящика” Blb1 и в случае его недоступности:

  • при нормальной работе Blb1 коммутатор SW1 использует статический маршрут 10.0.0.0/8 со значением Administrative Distances равным 200;
  • при недоступности Blb1 на коммутатор SW1 “прилетает” маршрут 10.0.0.0/8 от маршрутизатора R1 через протокол RIP, который имеет значение Administrative Distances  равное 120. Соответственно коммутатор SW1 выбирает маршрут 10.0.0.0/8, который был получен через протокол RIP.
### SW1: show ip route при нормальной работе Blb1 ###
SW1#show ip route | begin Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
S 10.0.0.0/8 [200/0] via 10.1.23.2
C 10.1.13.0/24 is directly connected, Vlan13
L 10.1.13.3/32 is directly connected, Vlan13
C 10.1.23.0/24 is directly connected, Vlan23
L 10.1.23.3/32 is directly connected, Vlan23
C 10.1.254.0/24 is directly connected, Vlan1
L 10.1.254.1/32 is directly connected, Vlan1
R 10.1.255.1/32 [120/1] via 10.1.13.1, 00:00:10, Vlan13
C 10.1.255.3/32 is directly connected, Loopback0
SW1#

### SW1: show ip route при недоступности Blb1 ###
SW1#show ip route | begin Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
R 10.0.0.0/8 [120/1] via 10.1.13.1, 00:00:28, Vlan13
C 10.1.13.0/24 is directly connected, Vlan13
L 10.1.13.3/32 is directly connected, Vlan13
C 10.1.23.0/24 is directly connected, Vlan23
L 10.1.23.3/32 is directly connected, Vlan23
C 10.1.254.0/24 is directly connected, Vlan1
L 10.1.254.1/32 is directly connected, Vlan1
R 10.1.255.1/32 [120/1] via 10.1.13.1, 00:00:28, Vlan13
C 10.1.255.3/32 is directly connected, Loopback0
SW1#
SW1#show ip route 10.0.0.0 255.0.0.0
Routing entry for 10.0.0.0/8
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 10.1.13.1 on Vlan13, 00:00:27 ago
Routing Descriptor Blocks:
* 10.1.13.1, from 10.1.13.1, 00:00:27 ago, via Vlan13
Route metric is 1, traffic share count is 1
SW1#

 

Шаг №2: изменяем таблицу маршрутизации на коммутаторе SW0 в головном офисе

Следующий шаг при внедрении “временной схемы” заключается в том, что необходимо каким-то образом повлиять на таблицу маршрутизации на коммутаторе в головном офисе SW0 и коммутаторе SW2 в другом филиал. Это требуется для того, чтобы возвратный трафик до Office #1 эти коммутаторы временно передавали в обход своих локальных “черных ящиков” Blb0 и Blb2 соответственно. При этом трафик до “нормальных” (не проблемных) филиалов должен ходить без изменений. А теперь представьте, что количество филиалов увеличилось до 10 или даже до 100?

 

На этом шаге используется редистрибуция маршрутов из RIP в OSPF с навешиванием метки на маршрутизаторе R1 в Office #1 и обратная редистрибуция маршрутов из OSPF в RIP на маршрутизаторах R0 и R2 на основании метки:

  • при недоступности "черного ящика" Blb1 локальный маршрутизатор R1 в Office #1 добавляет маршрут 10.1.254.0/24 из RIP в OSPF и при этом изменяет значение метки (tag) со 120 на 254;
  • маршрутизатор в головном офисе R0 (и аналогично маршрутизаторы в других филиалах) добавляет маршрут с меткой (tag) 254 из OSPF в RIP для уведомления локального коммутатора  SW0 о том, что потоки данных для подсети 10.1.254.0/24 надо передавать временно по новому маршруту через R0 вместо Blb0.Figure 4. Route redistribution from RIP to OSPF in case of unavailability of the Black Box # 1Figure 4. Route redistribution from RIP to OSPF in case of unavailability of the Black Box # 1

     

### R1 ###
!
router ospf 1
redistribute static subnets route-map static2ospf
redistribute rip subnets route-map rip2ospf
passive-interface default
no passive-interface Tunnel1
network 10.1.12.0 0.0.0.255 area 1
network 10.1.255.1 0.0.0.0 area 1
network 192.168.1.0 0.0.0.255 area 1
default-metric 1025
!
ip prefix-list lan seq 10 permit 10.1.254.0/24
!
route-map rip2ospf permit 100
match ip address prefix-list lan
set tag 120
!
event manager applet blblo0-down trap
event track 1 state down
action 1.0 syslog msg "Blb interface Lo0 is DOWN. Change route-map rip2ospf to set tag 254 for LAN route"
action 1.1 cli command "enable"
action 1.2 cli command "configure terminal"
action 1.3 cli command "route-map rip2ospf permit 100"
action 1.4 cli command "set tag 254"
action 1.5 cli command "end"
...

 

### R0 ###
!
router rip
version 2
redistribute ospf 1 metric 10 route-map ospf2rip
passive-interface default
no passive-interface Ethernet0/2
network 10.0.0.0
default-metric 5
distribute-list prefix rip-distrib-out out
no auto-summary
!

route-map ospf2rip permit 10
match tag 254
set tag 254
!

  

Для ограничения списка локальных IP-адресов, которым предоставлена возможность работы при “временной схеме”, настраиваем список доступа (access-list) и применяем его на интерфейсе Vlan 13 на коммутаторе SW1, т.е. на интерфейсе SW1 в сторону маршрутизатора R1. Если в будущем понадобится сузить или расширить этот диапазон IP-адресов, то это легко можно будет сделать изменением списка доступа.

SW1#show running-config interface vlan 13
Building configuration...

Current configuration : 129 bytes
!
interface Vlan13
description -= VL for SW0-R0 =-
ip address 10.1.13.3 255.255.255.0
ip access-group lan-restricted out
end

SW1#show access-lists lan-restricted
Extended IP access list lan-restricted
10 permit ip 10.1.254.0 0.0.0.15 any (15 matches)
SW1#

Ниже приведены выводы команды show ip route с коммутатора SW0 и show ip route с маршрутизатора R0  при нормальной работе “черного ящика” Blb1, а также в случае его недоступности.

### SW0: show ip route при нормальной работе Blb1 ###
SW0#show ip route | begin Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
S 10.0.0.0/8 [200/0] via 10.0.23.2
C 10.0.13.0/24 is directly connected, Vlan13
L 10.0.13.3/32 is directly connected, Vlan13
C 10.0.23.0/24 is directly connected, Vlan23
L 10.0.23.3/32 is directly connected, Vlan23
C 10.0.254.0/24 is directly connected, Vlan1
L 10.0.254.1/32 is directly connected, Vlan1
R 10.0.255.1/32 [120/1] via 10.0.13.1, 00:00:16, Vlan13
C 10.0.255.3/32 is directly connected, Loopback0
SW0#

### SW0: show ip route при недоступности Blb1 ###
SW0#show ip route | begin Gateway
Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
S 10.0.0.0/8 [200/0] via 10.0.23.2
C 10.0.13.0/24 is directly connected, Vlan13
L 10.0.13.3/32 is directly connected, Vlan13
C 10.0.23.0/24 is directly connected, Vlan23
L 10.0.23.3/32 is directly connected, Vlan23
C 10.0.254.0/24 is directly connected, Vlan1
L 10.0.254.1/32 is directly connected, Vlan1
R 10.0.255.1/32 [120/1] via 10.0.13.1, 00:00:18, Vlan13
C 10.0.255.3/32 is directly connected, Loopback0
R 10.1.254.0/24 [120/10] via 10.0.13.1, 00:00:18, Vlan13
SW0#
SW0#show ip route 10.1.254.0
Routing entry for 10.1.254.0/24
Known via "rip", distance 120, metric 10
Tag 254
Redistributing via rip
Last update from 10.0.13.1 on Vlan13, 00:00:16 ago
Routing Descriptor Blocks:
* 10.0.13.1, from 10.0.13.1, 00:00:16 ago, via Vlan13
Route metric is 10, traffic share count is 1
Route tag 254
SW0#
### R0: show ip route 10.1.254.0 при нормальной работе Blb1 ###
R0#show ip route 10.1.254.0

Routing entry for 10.1.254.0/24
Known via "ospf 1", distance 110, metric 1025
Tag 120, type extern 2, forward metric 1000
Redistributing via rip
Last update from 192.168.1.2 on Tunnel1, 00:08:00 ago
Routing Descriptor Blocks:
* 192.168.1.2, from 10.1.255.1, 00:08:00 ago, via Tunnel1
Route metric is 1025, traffic share count is 1
Route tag 120
R0#

### R0: show ip route 10.1.254.0 при недоступности Blb1 ###
R0#show ip route 10.1.254.0
Routing entry for 10.1.254.0/24
Known via "ospf 1", distance 110, metric 1025
Tag 254, type extern 2, forward metric 1000
Redistributing via rip
Advertised by rip metric 10 route-map ospf2rip
Last update from 192.168.1.2 on Tunnel1, 00:05:15 ago
Routing Descriptor Blocks:
* 192.168.1.2, from 10.1.255.1, 00:05:15 ago, via Tunnel1
Route metric is 1025, traffic share count is 1
Route tag 254
R0#

 

Ниже приведен вывод команды trace 10.0.254.10 с PC-1 (10.1.254.10) до PC-0 (10.0.254.10) при нормальной работе “черного ящика” Blb1, а также в случае его недоступности.

### PC-1: trace 10.0.254.10 при нормальной работе Blb1 ###
PC-1> trace 10.0.254.10
trace to 10.0.254.10, 8 hops max, press Ctrl+C to stop
1 10.1.254.1 0.434 ms 0.281 ms 0.264 ms
2 10.1.23.2 0.641 ms 0.511 ms 0.514 ms
3 10.0.12.2 1.634 ms 1.269 ms 1.316 ms
4 10.0.23.3 1.684 ms 1.457 ms 1.431 ms
5 *10.0.254.10 1.897 ms (ICMP type:3, code:3, Destination port unreachable)

PC-1>

### PC-1: trace 10.0.254.10 при недоступности Blb1 ###
PC-1> trace 10.0.254.10
trace to 10.0.254.10, 8 hops max, press Ctrl+C to stop
1 10.1.254.1 0.398 ms 0.249 ms 0.265 ms
2 10.1.13.1 0.650 ms 0.532 ms 0.499 ms
3 192.168.1.1 1.104 ms 0.963 ms 0.940 ms
4 10.0.13.3 1.241 ms 1.157 ms 1.159 ms
5 *10.0.254.10 1.474 ms (ICMP type:3, code:3, Destination port unreachable)

PC-1>

 

При доступности устройства Blb1 (адреса 10.1.255.2) на маршрутизаторе R1 срабатывает event manager applet и все возвращает обратно. Время переключения на временную схему и обратно зависит от настроенных таймеров в тестах IP SLA, в сервисе event manager applet и в протоколе RIP. В результате сеть живет своей жизнью и со стороны сотрудников отдела ИТ не требует вмешательства.

ЗАКЛЮЧЕНИЕ

Приведенное решение будет работать и при увеличении количества филиалов. При этом выход из строя нескольких “черных ящиков” в разных филиалах будет приводить к тому, что "временная схема" будет автоматически включаться только для проблемных филиалов, а для остальных филиалов все останется без изменений. Сотрудникам службы ИТ необходимо своевременно отслеживать состояние устройств сети в системе мониторинга и проводить разбор инцидентов и анализировать закономерности.

 

P.S. Самые терпеливые, кто нашел в себе силы дочитать до этого абзаца, найдут конфигурации устройств по ссылкам - R0, R1, SW0 и SW1.

Комментарии
Vasilii Mikhailovskii
Rising star

Добрый день.

Интересная статья. Только есть несколько вопросов:

Q1: что имеено вы понимаете под "черным ящиком" (приведите пожалуйста пару примеров) и по какой причине он должен быть inline?

Q2: почему выбран RIPv2 (а не BGP)?

Q3: как Вы предлагаете использовать решение в случае двух линков на сайте?

Q4: при сбое ящика в филиале, трафик из филиала к центральным серверам будет идти через черный ящик центрального офиса - это допустимо?

 

Vladimir.Timkin
Beginner

Добрый день, @Vasilii Mikhailovskii

 

На ваши вопросы ответы ниже:

Q1: что имеено вы понимаете под "черным ящиком" (приведите пожалуйста пару примеров) и по какой причине он должен быть inline?

=> например, VPN-шлюзы - S-Terra, VIPnet, Континент и т.п.

 

Q2: почему выбран RIPv2 (а не BGP)?

=> Протокол RIP выбран исходя из того, что коммутатор L3 в ЛВС, как правило, имеет базовую лицензию, которая ограничивает использование маршрутизации на нем.

=> И BGP все-таки для использования во внутренней сети как-то не очень подходит :) Хотя иногда очень хочется его задействовать ;)

 

Q3: как Вы предлагаете использовать решение в случае двух линков на сайте?

=> Если имеется ввиду два канала от ISP, то все будет работать точно также, т.к. в этом решении рассматривается вариант подключения к ISP без использования динамического протокола маршрутизации с самим ISP.

 

Q4: при сбое ящика в филиале, трафик из филиала к центральным серверам будет идти через черный ящик центрального офиса - это допустимо?

=> это зависит от логики работы  "черного ящика". С теми, что я сталкивался, это не получится, т.к. в моим случае "черные ящики" любят симметричность потоков данных и если это VPN-шлюзы, то возвратный трафик будет попадать в crypto-map, а на другом конце некому этот трафик расшифровать.

=> в моей статье описан общий случай, когда при "временной схеме" необходимо обеспечить симметричность потоков данных. Если ваш "черный ящик" возвратный трафик сможет передать, то в вашем вопросе логика работы несколько упрощается.

 

Цель статьи была показать как можно использовать обычные протоколы маршрутизации для более тонкого управления трафиком в сети на основе срабатывания событий. Мой пример можно расширить и, например, построить более сложную матрицу из меток (tags) и для каждой метки прописать свою логику обработки машрутов.

 

Дайте знать, если появились новые вопросы или не ответил в полной мере на текущие.

 

Vasilii Mikhailovskii
Rising star

Добрый день.

Q3 - имеется в виду использование двух линков от того же или разных ISP при использовании двух маршрутизаторов (для отказоустойчивости).

Q4: видимо я пропустил в статье - а как трафик из филиала (в обход филиального черного ящика) НЕ попадает на черный ящик ДЦ? Там же, вроде, только один статический маршут черех черный ящик... там только PBR поможет.

 

****

Q2 - Cisco рекомендует использование BGP для построения крупных DMVPN (BGP масштабируется лучше, чем EIGRP).

Vladimir.Timkin
Beginner

Добрый день, Василий.

 

Q3: Прошу прощения, я не сразу понял про какие два линка и в какую сторону имелось ввиду :)

В случае двух маршрутизаторов, например, в HQ роутер R0.1 будет отправлять маршрут в сторону SW0 через протокол RIP с метрикой 10, а роутер R0.2 - с метрикой 12. И в этом случае SW0 будет использовать маршрут через R0.1, если этот маршрутизатор доступен или доступен канал связи от R0.1 до Office #1.

 

Q4: Тут как раз была идея не использовать PBR, а использовать решение на базе редистрибуции между OSPF и RIP (или между OSPF и EIGRP). Если, например, рассмотреть вариант выхода из строя черного ящика в Office #1:
- в этом случае R1 будет анонсировать подсеть 10.1.254.0/24 (LAN в Office #1) через OSPF с tag 254 другим маршрутизаторам в сети;

- маршрутизаторы R0 (в HQ) и R2 (в Office #2) при получении маршрута с tag 254 (в нашем случае это будет маршрут10.1.254.0/24) будут анонсировать его своим локальным коммутатрам - SW0 и SW2 соответственно. Т.о. в таблице маршрутизации на коммутаторах будут маршруты:

SW0#show ip route

S        10.0.0.0/8 [200/0] via 10.0.23.2 <- маршрут через черный ящик в HQ

R        10.1.254.0/24 [120/10] via 10.0.13.1, 00:00:23, Vlan13 <- маршрут через R0.

 

SW2#show ip route

S        10.0.0.0/8 [200/0] via 10.2.23.2 <- маршрут через черный ящик в Office #2

R        10.1.254.0/24 [120/10] via 10.2.13.1, 00:00:23, Vlan13 <- маршрут через R2.

 

Таким образом, получаем таблицу маршрутизации для "временной схемы", в которой трафик из Office #2 до HQ идет через "черный ящик" Blb2, а трафик из Office #2 до Office #1 идет через роутер R2 - в обход "черного ящика". Соответственно PBR в этом случае не требуется. Аналогично это будет работать и для HQ  и для других филиалов. В этом как раз и заключается одна из "фишек" это решения - мы используем "временную схему", когда есть проблема с тем или иным "черный ящиком" и не используем PBR.

 

=>> Q2 - Cisco рекомендует использование BGP для построения крупных DMVPN (BGP масштабируется лучше, чем EIGRP).

- Если отойти от того решения, которое я описал в статье, на мой взгляд (возможно я заблуждаюсь), что решение с BGP лучше подходит для какого-то регионального представительства, в котором есть еще территориальные подразделения, но если в филиалах по 20-50 пользователей, то не будет ли решение с BGP избыточным? Например, в структуре ФНС - между федеральными или областными ФНС решение на BGP вполне применимо, но внутри одной области или одного города (например, Свердловской области или внутри города Екатеринбурга) не будет ли избыточным решение с использованием BGP?

Это не вопрос с подвохом, мне действительно интересно узнать мнение профессоналов как в таких структурах лучше организовать маршрутизацию? 

Vasilii Mikhailovskii
Rising star

Q4: в описываемой Вами схеме трафик ИЗ офиса №1 (где мы идем в обход) придет в дата центра и по таблице маршрутизации R0 попадет на ДЦ черный ящик (SW1=>R1=>R0=>Blb0). Что, в случае stateful устройства, приведет в потери связи.

 

Q2: выбор кокретного протокола зависит от потребностей отдельно взятого решения (стоимость, мастшабируемость, устойчивость, "supportability"), т.о. выбор BGP может быть обоснован.

Vladimir.Timkin
Beginner

Добрый день.

 

По Q2 понял.

 

[ Q4: в описываемой Вами схеме трафик ИЗ офиса №1 (где мы идем в обход) придет в дата центра и по таблице

[ маршрутизации R0 попадет на ДЦ черный ящик (SW1=>R1=>R0=>Blb0). Что, в случае stateful устройства, приведет в

[ потери связи.

Тут есть особенность в дизайне решения - при использовании Blb0 и Blb1 как VPN шлюзов трафик от них выходит в режиме tunnel mode (в моем случае используется IPSec), т.о. при прохождении по пути от SW0->Blb0 трафик с Blb0 выходит с адресом 10.0.12.2, а в случае временной схемы роутер R0 использует маршрут10.0.254.0/24, который получает от SW0 через RIP через линк SW0-R0. Т.е. при стабильной работе черных ящиков промежуточные устройства в сети не видят трафик между подсетями 10.0.254.0/24 и 10.1.254.0/24, а видят трафик между IP-адресами 10.0.12.2 и 10.1.12.2 - это адреса outside интерфейсов черных ящиков. Благодаря этому мы обходим необходимость использования PBR.

 

Sergey Lisitsin
Rising star

Большое спасибо за интересный материал. Очень познавательно. Фактически можно рассматривать разные пути трафика как две изолированных друг от друга сети. Сеть туннелей "чёрных ящиков" представляет собой альтернативную среду передачи. А метки используются для сигнализации удалённым маршрутизаторам о необходимости использования того или иного пути.

Не удалось отобразить этот виджет.