SlideShare a Scribd company logo
1 of 20
Ваш ориентир в мире безопасности
Отказоустойчивые решения
на базе продуктов С-Терра
Шпаков Андрей
Ведущий инженер
Отдел технического консалтинга
О чем пойдет речь
2© «С-Терра СиЭсПи», 2017
• Какие виды отказоустойчивости есть в продуктах С-Терра?
• Резервирование шлюзов: технологии VRRP, RRI
• Резервирование интерфейсов: Link-aggregation
• Резервирование каналов связи: GRE-over-IPsec, Object
tracking
• Сценарии балансировки нагрузки с резервированием
Отказоустойчивость
3© «С-Терра СиЭсПи», 2017
Что должно резервироваться?
• Отдельные компоненты АП
• Шлюзы
• интерфейсы на устройствах
• Каналы связи
Резервирование компонентов АП
4© «С-Терра СиЭсПи», 2017
Прайс - https://www.s-terra.ru/upload/medialibrary/06d/price_list_4.1_ST.pdf
• Жесткие диске в массиве RAID1, RAID 10.
• Резервирование жестких дисков
• Гарантия на все АП – 3 года
• Параметр MBTF – время наработки на отказ
Резервирование шлюзов безопасности
5© «С-Терра СиЭсПи», 2017
VRRP (англ. Virtual Router Redundancy Protocol, RFC 3768) — сетевой протокол, предназначенный
для увеличения доступности сетевых устройств, в частности шлюзов безопасности.
Особенности протокола
• Несколько шлюзов объединяются в один виртуальный
• Используется единый виртуальный IP и маршрут
• Масштабируемость шлюзов, любая топология
• Кластер Active/Passive
• Среднее время перестроения туннеля ~ 90 секунд для версии 4.1
~ 30 секунд для версии 4.2.
• Доступен как для L2, так и для L3
VRRP. Логика работы
6© «С-Терра СиЭсПи», 2017
1. Настраиваем состояние MASTER (GW1), BACKUP(GW2), а так
же виртуальный IP и маршрут.
2. MASTER-шлюз отправляет VRRP-пакеты на multicast
224.0.0.18.
3. Если BACKUP-шлюз не получает VRRP-пакетов, он
становится MASTER и отправляет GARP со своим MAC-
адресом.
4. Когда бывший MASTER-шлюз(GW1) восстанавливает
работу, он отправляет VRRP-пакет и восстанавливает свой
статус.
MASTER-шлюз
Отслеживание работы VPN-демона
vrrp_script chk_dead {script "pgrep -x vpnsvc” interval 1}
Синхронизация VRRP-процессов:
vrrp_sync_group G1 { group { VI_1 VI_2 }
Параметры первого VRRP-процесса:
vrrp_instance VI_1 {
state MASTER
interface eth1
garp_master_delay 10
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {10.0.1.10/24}
authentication {auth_type PASS auth_pass password}
track_script { chk_dead }
virtual_routes {src 10.0.1.10 10.0.2.10 via
10.0.1.1}}
Параметры второго VRRP-процесса :
vrrp_instance VI_2 {…
interface eth0
virtual_router_id 52
virtual_ipaddress { 192.168.1.10/24 }
…}
Конфигурация VRRP (версия 4.1)
7© «С-Терра СиЭсПи», 2017
Конфигурация /etc/keepalived.conf
BACKUP-шлюз
вместо state MASTER будет state
BACKUP:
vrrp_instance VI_1 {
state BACKUP …}
Кроме того параметр priority
должен быть изменен с 100 на 50:
vrrp_instance VI_1 {
priority 50 …}
MASTER-шлюз
Настройка в CLI:
GW1(config)#interface GigabitEthernet 0/0
GW1(config-if)#vrrp 51 ip 192.168.1.10
GW1(config-if)#vrrp 51 priority 100
GW1(config-if)#vrrp 51 authentication pass123
GW1(config-if)#exit
GW1(config)#interface GigabitEthernet 0/1
GW1(config-if)#vrrp 52 ip 10.0.1.10
GW1(config-if)#vrrp 52 priority 100
GW1(config-if)#vrrp 52 authentication pass123
GW1(config-if)#exit
GW1(config)#vrrp ip route 10.0.2.0 255.255.255.0
10.0.1.1 src 10.0.1.10
GW1(config)#vrrp notify master
GW1(config)#vrrp notify backup
GW1(config)#vrrp notify fault
GW1(config)#exit
Конфигурация VRRP (версии 4.2)
8© «С-Терра СиЭсПи», 2017
Вся настройка из CLI
BACKUP-шлюз
Аналогично кроме параметра priority
GW2(config)#interface GigabitEthernet
0/0
GW2(config-if)#vrrp 51 priority 50
GW2(config-if)#exit
GW2(config)#interface GigabitEthernet
0/1
GW2(config-if)#vrrp 52 priority 50
GW2(config-if)#exit
Резервирование шлюзов безопасности
9© «С-Терра СиЭсПи», 2017
RRI (англ. Reverse Route Injection)— механизм, предназначенный для отказоустойчивости
Remote-Access VPN.
Особенности механизма
• Отказоустойчивость и балансировка нагрузки.
• Необходимость внешнего баласировщика
(маршрутизатора)
• Соединения инициируют удаленные узлы
• Работает как на статической, так и динамической
cryptomap
• В отдельных случаях резервирует и провайдеров
Peer B
ISP
Клиенты
Защищаемая
подсеть
GW1GW2
Peer A
Конфигурация RRI
10© «С-Терра СиЭсПи», 2017
1. Настройка RRI в криптокарте
GW1(config)#crypto dynamic-map DMAP 1
GW1(config-crypto-map)#match address LIST
GW1(config-crypto-map)#set transform-set TSET
GW1(config-crypto-map)#set pfs vko
GW1(config-crypto-map)#reverse-route
GW1(config-crypto-map)#exit
2. Настройка протокола RIP через /etc/quagga/ripd.conf
hostname ripd
password zebra
debug rip events
debug rip packet
router rip version 2
redistribute kernel
network eth0
distribute-list acl-in in
distribute-list acl-out out
access-list acl-in deny any
access-list acl-out permit 192.168.11.0/24
access-list acl-out deny any
log file /var/log/quagga/ripd.log
log stdout3.
Резервирование в IPsec – DPD
11© «С-Терра СиЭсПи», 2017
DPD (англ. Dead Peer Detection)— механизм обнаружения неработающего пира в
рамках IKE и IPsec
Особенности механизма
• Составная часть IPsec, не требует дополнительных портов
• Нет ответа – идем на next peer в cryptomap
• Настраивается командой crypto isakmp keepalive secs [retries]
• Требует настройки в случае нестабильного канала между устройствами
• Более гибкий в версии 4.2: crypto isakmp keepalive retry-count {retry-count}
Резервирование портов. Link-aggregation
12© «С-Терра СиЭсПи», 2017
Агрегирование каналов (англ. Link-aggregation)— технологии объединения нескольких
параллельных линков в один логический, позволяющие увеличить пропускную
способность и повысить надёжность.
Особенности:
• Описана в IEEE 802.3ad.
• Реализуется средствами OC шлюза
• Контроль канала – протокол LACP
Настройка Link-aggregation
13© «С-Терра СиЭсПи», 2017
Конфигурация /etc/network/interfaces
4. Отредактируйте ifaliaces.cf, удалив eth2 и eth3:
root@sterragate:~# vim.tiny
/etc/ifaliases.cf
interface (name="GigabitEthernet0/0"
pattern="eth0")
interface (name="GigabitEthernet0/1"
pattern="eth1")
interface (name="GigabitEthernet1/0"
pattern="bond0")
5. Затем пересчитайте контрольную сумму и
перезапустите VPN-демона
root@sterragate:~# integr_mgr calc -f
/etc/ifaliases.cf
root@sterragate:~# service vpngate restart
1. Внесите изменение в /etc/network/interfaces:
auto bond0
iface bond0 inet static
address 10.1.1.1
netmask 255.255.255.0
slaves eth2 eth3
bond_mode 802.3ad
bond_miimon 100
bond_xmit_hash_policy layer2+3
2. Далее, перезапустите сервис:
root@sterragate:~# service networking restart
3. Проверьте наличие интерфейса bond0 в системе:
root@sterragate:~# ip address show | grep bond0
4: eth2: mtu 1500 qdisc mq master bond0 state UP qlen
1000
5: eth3: mtu 1500 qdisc mq master bond0 state UP qlen
1000
10: bond0: mtu 1500 qdisc noqueue state UP inet
10.1.1.1/24 brd 10.1.1.255 scope global bond0
Резервирование провайдеров GRE-over-IPsec
14© «С-Терра СиЭсПи», 2017
GRE over IPsec— технология для обеспечения отказоустойчивости оборудования и каналов
связи.
Составные компоненты:
• GRE - протокол туннелирования сетевых пакетов, разработанный
компанией Cisco Systems.
• OSPF – протокол динамической маршрутизации для обеспечения
доступности площадок, отказоустойчивости и балансировки нагрузки
• IPsec – стек протоколов шифрования
1. Настроим первый туннель:
root@GW1:~# ip tunnel add gre1 mode gre remote 10.0.2.2 local 10.0.1.2 ttl 255
root@GW1:~# ip link set gre1 up
root@GW1:~# ip link set gre1 mtu 1400
root@GW1:~# ip addr add 1.1.1.1/30 dev gre1
2. Настроим второй туннель:
root@GW1:~# ip tunnel add gre2 mode gre remote 10.0.4.2 local 10.0.3.2 ttl 255
root@GW1:~# ip link set gre2 up
root@GW1:~# ip link set gre2 mtu 1400
root@GW1:~# ip addr add 2.2.2.1/30 dev gre2
3. Опишите трафик, который планируется защищать. Для этого создайте расширенный список доступа:
GW1(config)#ip access-list extended LIST
GW1(config-ext-nacl)#permit gre host 10.0.1.2 host 10.0.2.2 GW1(config-ext-nacl)#exit
GW1(config)#ip access-list extended LIST2
GW1(config-ext-nacl)#permit gre host 10.0.3.2 host 10.0.4.2 GW1(config-ext-nacl)#exit
4. Настройке OSPF в файле /etc/quagga/ospf.conf
hostname ospfd
password zebra
enable password zebra
router ospf
network 192.168.1.0/24 area 0
network 1.1.1.0/30 area 0
network 2.2.2.0/30 area 0
log file /var/log/quagga/ospfd.log
log stdout
Настройка GRE-over-IPsec
15© «С-Терра СиЭсПи», 2017
Object Tracking
16© «С-Терра СиЭсПи», 2017
Object Tracking— механизм переключения каналов, основанный на периодической
проверке доступности узла в сети.
Скрипт изменяет метрики основного и резервного маршрутов до узла.
Параметры скрипта /etc/rc.local.inc
#!/bin/bash
PING_IP=8.8.8.8 #IP-арес для ICMP запросов
PING_COUNT=10 #Кол-во пропущеных ICMP-запросов для переключения
PING_TIMEOUT=3 #Интервал отправки ICMP-запросов для переключения
RESTORE_PING_COUNT=10 #Кол-во пропущеных ICMP-запросов для восстановления
RESTORE_TIMEOUT=1 #Интервал отправки ICMP-запросов для восстановления
MAIN_INTERFACE=eth1 #Интерфейс, подключенный к основному провайдеру
BACKUP_INTERFACE=eth2 #Интерфейс, подключенный к резервному провайдеру
MAIN_GATEWAY=10.1.1.1 #Шлюз основого провайдера
BACKUP_GATEWAY=10.1.2.1 #Шлюз резервного провайдера
Масштабирование на L3, IPsec over GRE
17© «С-Терра СиЭсПи», 2017
Особенности решения
• GRE и OSPF/EIGRP-реализуется на маршрутизаторах
• Балансировка и отказоустойчивость на L3.
• Масштабируемость практически в любых объемах
Масштабирование на L2, Link-Aggregation
18© «С-Терра СиЭсПи», 2017
• Link-aggregation настраивается на коммутаторах
• На шлюзах используется пакет S-Terra L2
• Высокая масштабируемость решения
Резюме
19© «С-Терра СиЭсПи», 2017
Решение
Основное
назначение
Балан-
сировка
Оптимальная топология
Время
восстановления
* (секунд)
VRRP Резервирование шлюзов Нет Не важно 1-5
RRI Резервирование шлюзов Есть Большое количество удаленных
пользователей или филиалов.
7-15
Link Aggregation Резервирование портов Есть Для локального сегмента 1-5
GRE over IPsec на
шлюзе
Резервирование каналов Есть Site-to-Site или филиальная сеть. 7-15
Object Tracking Резервирование каналов Нет Site-to-Site или филиальная сеть. 10-20
GRE over IPsec для
балансировки
нагрузки
Резервирование
оборудования и каналов
связи
Есть Защита высокоскоростных каналов
связи на уровне L3
7-15
Link Aggregation
для балансировки
нагрузки
Резервирование
оборудования и каналов
связи
Есть Защита высокоскоростных каналов
связи на уровне L2
1-5
* без учета времени перестроения туннелей. Время перестроения туннелей зависит
от их количества и обычно лежит в диапазоне 0,5-1,5 минуты.
Шпаков Андрей
Ведущий инженер
Отдел технического консалтинга
Тел.: +7 (499) 940-90-61 (доб. 133)
Email: ashpakov@s-terra.ru, presale@s-terra.ru

More Related Content

What's hot

Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...Lenvendo
 
Технополис: Сетевой стек
Технополис: Сетевой стекТехнополис: Сетевой стек
Технополис: Сетевой стекDmitry Samsonov
 
Новая Cisco ASA: тотальный контроль над пользователем
Новая Cisco ASA: тотальный контроль над пользователемНовая Cisco ASA: тотальный контроль над пользователем
Новая Cisco ASA: тотальный контроль над пользователемSkillFactory
 
Повышаем отказоустойчивость без дорогих решений
Повышаем отказоустойчивость без дорогих решенийПовышаем отказоустойчивость без дорогих решений
Повышаем отказоустойчивость без дорогих решенийLenvendo
 
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?Cisco Russia
 
20201021 Технополис: Сетевой стек
20201021 Технополис: Сетевой стек20201021 Технополис: Сетевой стек
20201021 Технополис: Сетевой стекDmitry Samsonov
 
Симаков Алексей - Системы управления кластерами
 Симаков Алексей - Системы управления кластерами   Симаков Алексей - Системы управления кластерами
Симаков Алексей - Системы управления кластерами Yandex
 
Программируемость и автоматизация решений Ciscо - практическое применение
Программируемость и автоматизация решений Ciscо - практическое применениеПрограммируемость и автоматизация решений Ciscо - практическое применение
Программируемость и автоматизация решений Ciscо - практическое применениеCisco Russia
 
Практические советы по выбору и настройке Cisco VPN
Практические советы по выбору и настройке Cisco VPNПрактические советы по выбору и настройке Cisco VPN
Практические советы по выбору и настройке Cisco VPNSkillFactory
 
Программируемость корпоративной сети с Cisco APIC-EM
Программируемость корпоративной сети с Cisco APIC-EMПрограммируемость корпоративной сети с Cisco APIC-EM
Программируемость корпоративной сети с Cisco APIC-EMCisco Russia
 
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрия
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрияНовые возможности IOS-XR 6 контейнеры, программируемость и телеметрия
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрияCisco Russia
 
Гиперконвергентное решение Cisco HyperFlex
Гиперконвергентное решение Cisco HyperFlexГиперконвергентное решение Cisco HyperFlex
Гиперконвергентное решение Cisco HyperFlexCisco Russia
 
Как получить максимум от сетевого экрана Cisco ASA?
Как получить максимум от сетевого экрана Cisco ASA?Как получить максимум от сетевого экрана Cisco ASA?
Как получить максимум от сетевого экрана Cisco ASA?SkillFactory
 
Организация сети и безопасность
Организация сети и безопасностьОрганизация сети и безопасность
Организация сети и безопасностьOpenStackRU
 
Антон Карпов - Сетевая безопасность
 Антон Карпов - Сетевая безопасность Антон Карпов - Сетевая безопасность
Антон Карпов - Сетевая безопасностьYandex
 
DNA Security. Безопасность, встроенная в сетевую инфраструктуру
DNA Security. Безопасность, встроенная в сетевую инфраструктуруDNA Security. Безопасность, встроенная в сетевую инфраструктуру
DNA Security. Безопасность, встроенная в сетевую инфраструктуруCisco Russia
 

What's hot (19)

Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...
Конференция Highload++ 2014, "Отказоустойчивый микрокластер своими руками", "...
 
Технополис: Сетевой стек
Технополис: Сетевой стекТехнополис: Сетевой стек
Технополис: Сетевой стек
 
Новая Cisco ASA: тотальный контроль над пользователем
Новая Cisco ASA: тотальный контроль над пользователемНовая Cisco ASA: тотальный контроль над пользователем
Новая Cisco ASA: тотальный контроль над пользователем
 
Повышаем отказоустойчивость без дорогих решений
Повышаем отказоустойчивость без дорогих решенийПовышаем отказоустойчивость без дорогих решений
Повышаем отказоустойчивость без дорогих решений
 
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?
Сетевой инженер 2.0. Что нужно знать о программируемости в корпоративной сети?
 
20201021 Технополис: Сетевой стек
20201021 Технополис: Сетевой стек20201021 Технополис: Сетевой стек
20201021 Технополис: Сетевой стек
 
Симаков Алексей - Системы управления кластерами
 Симаков Алексей - Системы управления кластерами   Симаков Алексей - Системы управления кластерами
Симаков Алексей - Системы управления кластерами
 
Программируемость и автоматизация решений Ciscо - практическое применение
Программируемость и автоматизация решений Ciscо - практическое применениеПрограммируемость и автоматизация решений Ciscо - практическое применение
Программируемость и автоматизация решений Ciscо - практическое применение
 
Практические советы по выбору и настройке Cisco VPN
Практические советы по выбору и настройке Cisco VPNПрактические советы по выбору и настройке Cisco VPN
Практические советы по выбору и настройке Cisco VPN
 
Программируемость корпоративной сети с Cisco APIC-EM
Программируемость корпоративной сети с Cisco APIC-EMПрограммируемость корпоративной сети с Cisco APIC-EM
Программируемость корпоративной сети с Cisco APIC-EM
 
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрия
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрияНовые возможности IOS-XR 6 контейнеры, программируемость и телеметрия
Новые возможности IOS-XR 6 контейнеры, программируемость и телеметрия
 
Гиперконвергентное решение Cisco HyperFlex
Гиперконвергентное решение Cisco HyperFlexГиперконвергентное решение Cisco HyperFlex
Гиперконвергентное решение Cisco HyperFlex
 
DDOS mitigation software solutions
DDOS mitigation software solutionsDDOS mitigation software solutions
DDOS mitigation software solutions
 
Как получить максимум от сетевого экрана Cisco ASA?
Как получить максимум от сетевого экрана Cisco ASA?Как получить максимум от сетевого экрана Cisco ASA?
Как получить максимум от сетевого экрана Cisco ASA?
 
Организация сети и безопасность
Организация сети и безопасностьОрганизация сети и безопасность
Организация сети и безопасность
 
Антон Карпов - Сетевая безопасность
 Антон Карпов - Сетевая безопасность Антон Карпов - Сетевая безопасность
Антон Карпов - Сетевая безопасность
 
Cisco ASA CX
Cisco ASA CXCisco ASA CX
Cisco ASA CX
 
DNA Security. Безопасность, встроенная в сетевую инфраструктуру
DNA Security. Безопасность, встроенная в сетевую инфраструктуруDNA Security. Безопасность, встроенная в сетевую инфраструктуру
DNA Security. Безопасность, встроенная в сетевую инфраструктуру
 
RootConf 2015
RootConf 2015RootConf 2015
RootConf 2015
 

Similar to Вебинар по отказоустойчивости, 13.04.2017

Вебинар С-Терра CSCO-STVM, 18.05.2017
Вебинар С-Терра CSCO-STVM, 18.05.2017Вебинар С-Терра CSCO-STVM, 18.05.2017
Вебинар С-Терра CSCO-STVM, 18.05.2017S-Terra CSP
 
Вебинар С-Терра CSCO-STVM, 14.03.2017
Вебинар С-Терра CSCO-STVM, 14.03.2017Вебинар С-Терра CSCO-STVM, 14.03.2017
Вебинар С-Терра CSCO-STVM, 14.03.2017S-Terra CSP
 
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)Ontico
 
Поддержка Segment Routing на IOS XR
Поддержка Segment Routing на IOS XRПоддержка Segment Routing на IOS XR
Поддержка Segment Routing на IOS XRCisco Russia
 
Netmap (by luigi rizzo) простой и удобный opensource фреймворк для обработк...
Netmap (by luigi rizzo)   простой и удобный opensource фреймворк для обработк...Netmap (by luigi rizzo)   простой и удобный opensource фреймворк для обработк...
Netmap (by luigi rizzo) простой и удобный opensource фреймворк для обработк...Ontico
 
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...mikrotik-training
 
Архитектура Segment Routing
Архитектура Segment RoutingАрхитектура Segment Routing
Архитектура Segment RoutingCisco Russia
 
Aricent ISS integration for Marvell - requirements to candidates
Aricent ISS integration for Marvell - requirements to candidatesAricent ISS integration for Marvell - requirements to candidates
Aricent ISS integration for Marvell - requirements to candidatesVolodymyr Khomenko
 
Маршрутизатор ASR1000
Маршрутизатор ASR1000Маршрутизатор ASR1000
Маршрутизатор ASR1000Cisco Russia
 
Развитие платформы Cisco ASR 9000
Развитие платформы Cisco ASR 9000Развитие платформы Cisco ASR 9000
Развитие платформы Cisco ASR 9000Cisco Russia
 
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВС
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВСОбзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВС
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВСCisco Russia
 
Безопасность и виртуализация в центрах обработки данных (часть 2)
Безопасность и виртуализация в центрах обработки данных (часть 2)Безопасность и виртуализация в центрах обработки данных (часть 2)
Безопасность и виртуализация в центрах обработки данных (часть 2)Cisco Russia
 
Инновации Cisco для маршрутизации и коммутации в корпоративных сетях
Инновации Cisco для маршрутизации и коммутации в корпоративных сетяхИнновации Cisco для маршрутизации и коммутации в корпоративных сетях
Инновации Cisco для маршрутизации и коммутации в корпоративных сетяхCisco Russia
 
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...Cisco Russia
 
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)Andrey Klyuchka
 
Технология Cisco Instant Access для упрощения структуры кампусных сетей.
Технология Cisco Instant Access для упрощения структуры кампусных сетей. Технология Cisco Instant Access для упрощения структуры кампусных сетей.
Технология Cisco Instant Access для упрощения структуры кампусных сетей. Cisco Russia
 
Подробный технический обзор коммутаторов Cisco ME3800X/3600X
Подробный технический обзор коммутаторов Cisco ME3800X/3600XПодробный технический обзор коммутаторов Cisco ME3800X/3600X
Подробный технический обзор коммутаторов Cisco ME3800X/3600XCisco Russia
 
Сетевое оборудование Cisco в индустриальном исполнении
Сетевое оборудование Cisco в индустриальном исполненииСетевое оборудование Cisco в индустриальном исполнении
Сетевое оборудование Cisco в индустриальном исполненииCisco Russia
 
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...Cisco Russia
 
GRANIT — Global Russian Advanced Network Initiative
GRANIT — Global Russian Advanced Network InitiativeGRANIT — Global Russian Advanced Network Initiative
GRANIT — Global Russian Advanced Network InitiativeARCCN
 

Similar to Вебинар по отказоустойчивости, 13.04.2017 (20)

Вебинар С-Терра CSCO-STVM, 18.05.2017
Вебинар С-Терра CSCO-STVM, 18.05.2017Вебинар С-Терра CSCO-STVM, 18.05.2017
Вебинар С-Терра CSCO-STVM, 18.05.2017
 
Вебинар С-Терра CSCO-STVM, 14.03.2017
Вебинар С-Терра CSCO-STVM, 14.03.2017Вебинар С-Терра CSCO-STVM, 14.03.2017
Вебинар С-Терра CSCO-STVM, 14.03.2017
 
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)
Отказоустойчивый микрокластер своими руками, Виталий Гаврилов (Ленвендо)
 
Поддержка Segment Routing на IOS XR
Поддержка Segment Routing на IOS XRПоддержка Segment Routing на IOS XR
Поддержка Segment Routing на IOS XR
 
Netmap (by luigi rizzo) простой и удобный opensource фреймворк для обработк...
Netmap (by luigi rizzo)   простой и удобный opensource фреймворк для обработк...Netmap (by luigi rizzo)   простой и удобный opensource фреймворк для обработк...
Netmap (by luigi rizzo) простой и удобный opensource фреймворк для обработк...
 
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...
Настройка резервирования в Mikrotik. Dual-WAN, основные принципы и пошаговая ...
 
Архитектура Segment Routing
Архитектура Segment RoutingАрхитектура Segment Routing
Архитектура Segment Routing
 
Aricent ISS integration for Marvell - requirements to candidates
Aricent ISS integration for Marvell - requirements to candidatesAricent ISS integration for Marvell - requirements to candidates
Aricent ISS integration for Marvell - requirements to candidates
 
Маршрутизатор ASR1000
Маршрутизатор ASR1000Маршрутизатор ASR1000
Маршрутизатор ASR1000
 
Развитие платформы Cisco ASR 9000
Развитие платформы Cisco ASR 9000Развитие платформы Cisco ASR 9000
Развитие платформы Cisco ASR 9000
 
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВС
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВСОбзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВС
Обзор коммутаторов Catalyst 4500-X уровня распределения корпоративных ЛВС
 
Безопасность и виртуализация в центрах обработки данных (часть 2)
Безопасность и виртуализация в центрах обработки данных (часть 2)Безопасность и виртуализация в центрах обработки данных (часть 2)
Безопасность и виртуализация в центрах обработки данных (часть 2)
 
Инновации Cisco для маршрутизации и коммутации в корпоративных сетях
Инновации Cisco для маршрутизации и коммутации в корпоративных сетяхИнновации Cisco для маршрутизации и коммутации в корпоративных сетях
Инновации Cisco для маршрутизации и коммутации в корпоративных сетях
 
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...
Инновации Cisco: эволюция оборудования для построения сетей доступа и агрегац...
 
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)
Cisco Connect Almaty 2014 - Security Solutions for Data Centers (russian)
 
Технология Cisco Instant Access для упрощения структуры кампусных сетей.
Технология Cisco Instant Access для упрощения структуры кампусных сетей. Технология Cisco Instant Access для упрощения структуры кампусных сетей.
Технология Cisco Instant Access для упрощения структуры кампусных сетей.
 
Подробный технический обзор коммутаторов Cisco ME3800X/3600X
Подробный технический обзор коммутаторов Cisco ME3800X/3600XПодробный технический обзор коммутаторов Cisco ME3800X/3600X
Подробный технический обзор коммутаторов Cisco ME3800X/3600X
 
Сетевое оборудование Cisco в индустриальном исполнении
Сетевое оборудование Cisco в индустриальном исполненииСетевое оборудование Cisco в индустриальном исполнении
Сетевое оборудование Cisco в индустриальном исполнении
 
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...
Cisco Nexus 7700 и Cisco Catalyst 6800. Особенности применения в корпоративно...
 
GRANIT — Global Russian Advanced Network Initiative
GRANIT — Global Russian Advanced Network InitiativeGRANIT — Global Russian Advanced Network Initiative
GRANIT — Global Russian Advanced Network Initiative
 

More from S-Terra CSP

Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017
Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017
Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017S-Terra CSP
 
Вебинар по защите ПДн, 30.03.2017
Вебинар по защите ПДн, 30.03.2017Вебинар по защите ПДн, 30.03.2017
Вебинар по защите ПДн, 30.03.2017S-Terra CSP
 
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017S-Terra CSP
 
Презентация Huawei на совместном вебинаре, 30.11.2016
Презентация Huawei на совместном вебинаре, 30.11.2016 Презентация Huawei на совместном вебинаре, 30.11.2016
Презентация Huawei на совместном вебинаре, 30.11.2016 S-Terra CSP
 
Вебинар С-Терра–Huawei, 30.11.2016
Вебинар С-Терра–Huawei, 30.11.2016 Вебинар С-Терра–Huawei, 30.11.2016
Вебинар С-Терра–Huawei, 30.11.2016 S-Terra CSP
 
Вебинар по СМЭВ, 24.11.2016
Вебинар по СМЭВ, 24.11.2016Вебинар по СМЭВ, 24.11.2016
Вебинар по СМЭВ, 24.11.2016S-Terra CSP
 
Доклад С-Терра на Код ИБ, Казань, 2016
Доклад С-Терра на Код ИБ, Казань, 2016Доклад С-Терра на Код ИБ, Казань, 2016
Доклад С-Терра на Код ИБ, Казань, 2016S-Terra CSP
 
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016S-Terra CSP
 
Вебинар “С-Терра «Пост»”, 14.10.2016
Вебинар “С-Терра «Пост»”, 14.10.2016Вебинар “С-Терра «Пост»”, 14.10.2016
Вебинар “С-Терра «Пост»”, 14.10.2016S-Terra CSP
 
Доклад С-Терра на InfoSecurity Russia-2016
Доклад С-Терра на InfoSecurity Russia-2016Доклад С-Терра на InfoSecurity Russia-2016
Доклад С-Терра на InfoSecurity Russia-2016S-Terra CSP
 
Доклад С-Терра на Код ИБ, Красноярск, 2016
Доклад С-Терра на Код ИБ, Красноярск, 2016Доклад С-Терра на Код ИБ, Красноярск, 2016
Доклад С-Терра на Код ИБ, Красноярск, 2016S-Terra CSP
 
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016S-Terra CSP
 
Вебинар С-Терра–Зелакс, 20.07.2016
Вебинар С-Терра–Зелакс, 20.07.2016Вебинар С-Терра–Зелакс, 20.07.2016
Вебинар С-Терра–Зелакс, 20.07.2016S-Terra CSP
 
Вебинар С-Терра-Элтекс, 05.07.2016
Вебинар С-Терра-Элтекс, 05.07.2016 Вебинар С-Терра-Элтекс, 05.07.2016
Вебинар С-Терра-Элтекс, 05.07.2016 S-Terra CSP
 
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016 Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016 S-Terra CSP
 
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.S-Terra CSP
 
Доклад С-Терра на Код Иб, Новосибирск, 2016
Доклад С-Терра на Код Иб, Новосибирск, 2016Доклад С-Терра на Код Иб, Новосибирск, 2016
Доклад С-Терра на Код Иб, Новосибирск, 2016S-Terra CSP
 
Подключение к СМЭВ. Решение С-Терра, 24.05.2016
Подключение к СМЭВ. Решение С-Терра, 24.05.2016Подключение к СМЭВ. Решение С-Терра, 24.05.2016
Подключение к СМЭВ. Решение С-Терра, 24.05.2016S-Terra CSP
 
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016S-Terra CSP
 
Актуальные решения C-Терра
Актуальные решения C-ТерраАктуальные решения C-Терра
Актуальные решения C-ТерраS-Terra CSP
 

More from S-Terra CSP (20)

Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017
Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017
Доклад С-Терра на «Код ИБ», С.-Петербург, 27.04.2017
 
Вебинар по защите ПДн, 30.03.2017
Вебинар по защите ПДн, 30.03.2017Вебинар по защите ПДн, 30.03.2017
Вебинар по защите ПДн, 30.03.2017
 
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017
Доклад С-Терра на «ИнфоФоруме-2017», 02.02.2017
 
Презентация Huawei на совместном вебинаре, 30.11.2016
Презентация Huawei на совместном вебинаре, 30.11.2016 Презентация Huawei на совместном вебинаре, 30.11.2016
Презентация Huawei на совместном вебинаре, 30.11.2016
 
Вебинар С-Терра–Huawei, 30.11.2016
Вебинар С-Терра–Huawei, 30.11.2016 Вебинар С-Терра–Huawei, 30.11.2016
Вебинар С-Терра–Huawei, 30.11.2016
 
Вебинар по СМЭВ, 24.11.2016
Вебинар по СМЭВ, 24.11.2016Вебинар по СМЭВ, 24.11.2016
Вебинар по СМЭВ, 24.11.2016
 
Доклад С-Терра на Код ИБ, Казань, 2016
Доклад С-Терра на Код ИБ, Казань, 2016Доклад С-Терра на Код ИБ, Казань, 2016
Доклад С-Терра на Код ИБ, Казань, 2016
 
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016
Доклад С-Терра на форуме «Вся банковская автоматизация-2016», 19.10.2016
 
Вебинар “С-Терра «Пост»”, 14.10.2016
Вебинар “С-Терра «Пост»”, 14.10.2016Вебинар “С-Терра «Пост»”, 14.10.2016
Вебинар “С-Терра «Пост»”, 14.10.2016
 
Доклад С-Терра на InfoSecurity Russia-2016
Доклад С-Терра на InfoSecurity Russia-2016Доклад С-Терра на InfoSecurity Russia-2016
Доклад С-Терра на InfoSecurity Russia-2016
 
Доклад С-Терра на Код ИБ, Красноярск, 2016
Доклад С-Терра на Код ИБ, Красноярск, 2016Доклад С-Терра на Код ИБ, Красноярск, 2016
Доклад С-Терра на Код ИБ, Красноярск, 2016
 
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016
Вебинар С-Терра и ИЦ РЕГИОНАЛЬНЫЕ СИСТЕМЫ, 06.09.2016
 
Вебинар С-Терра–Зелакс, 20.07.2016
Вебинар С-Терра–Зелакс, 20.07.2016Вебинар С-Терра–Зелакс, 20.07.2016
Вебинар С-Терра–Зелакс, 20.07.2016
 
Вебинар С-Терра-Элтекс, 05.07.2016
Вебинар С-Терра-Элтекс, 05.07.2016 Вебинар С-Терра-Элтекс, 05.07.2016
Вебинар С-Терра-Элтекс, 05.07.2016
 
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016 Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016
Совместный вебинар Orange и «С-Терра СиЭсПи», 28.06.2016
 
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.
Решения С-Терра для защиты трансграничных каналов связи. Порядок экспорта СКЗИ.
 
Доклад С-Терра на Код Иб, Новосибирск, 2016
Доклад С-Терра на Код Иб, Новосибирск, 2016Доклад С-Терра на Код Иб, Новосибирск, 2016
Доклад С-Терра на Код Иб, Новосибирск, 2016
 
Подключение к СМЭВ. Решение С-Терра, 24.05.2016
Подключение к СМЭВ. Решение С-Терра, 24.05.2016Подключение к СМЭВ. Решение С-Терра, 24.05.2016
Подключение к СМЭВ. Решение С-Терра, 24.05.2016
 
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016
Совместный вебинар Citrix и «С-Терра СиЭсПи», 26.04.2016
 
Актуальные решения C-Терра
Актуальные решения C-ТерраАктуальные решения C-Терра
Актуальные решения C-Терра
 

Вебинар по отказоустойчивости, 13.04.2017

  • 1. Ваш ориентир в мире безопасности Отказоустойчивые решения на базе продуктов С-Терра Шпаков Андрей Ведущий инженер Отдел технического консалтинга
  • 2. О чем пойдет речь 2© «С-Терра СиЭсПи», 2017 • Какие виды отказоустойчивости есть в продуктах С-Терра? • Резервирование шлюзов: технологии VRRP, RRI • Резервирование интерфейсов: Link-aggregation • Резервирование каналов связи: GRE-over-IPsec, Object tracking • Сценарии балансировки нагрузки с резервированием
  • 3. Отказоустойчивость 3© «С-Терра СиЭсПи», 2017 Что должно резервироваться? • Отдельные компоненты АП • Шлюзы • интерфейсы на устройствах • Каналы связи
  • 4. Резервирование компонентов АП 4© «С-Терра СиЭсПи», 2017 Прайс - https://www.s-terra.ru/upload/medialibrary/06d/price_list_4.1_ST.pdf • Жесткие диске в массиве RAID1, RAID 10. • Резервирование жестких дисков • Гарантия на все АП – 3 года • Параметр MBTF – время наработки на отказ
  • 5. Резервирование шлюзов безопасности 5© «С-Терра СиЭсПи», 2017 VRRP (англ. Virtual Router Redundancy Protocol, RFC 3768) — сетевой протокол, предназначенный для увеличения доступности сетевых устройств, в частности шлюзов безопасности. Особенности протокола • Несколько шлюзов объединяются в один виртуальный • Используется единый виртуальный IP и маршрут • Масштабируемость шлюзов, любая топология • Кластер Active/Passive • Среднее время перестроения туннеля ~ 90 секунд для версии 4.1 ~ 30 секунд для версии 4.2. • Доступен как для L2, так и для L3
  • 6. VRRP. Логика работы 6© «С-Терра СиЭсПи», 2017 1. Настраиваем состояние MASTER (GW1), BACKUP(GW2), а так же виртуальный IP и маршрут. 2. MASTER-шлюз отправляет VRRP-пакеты на multicast 224.0.0.18. 3. Если BACKUP-шлюз не получает VRRP-пакетов, он становится MASTER и отправляет GARP со своим MAC- адресом. 4. Когда бывший MASTER-шлюз(GW1) восстанавливает работу, он отправляет VRRP-пакет и восстанавливает свой статус.
  • 7. MASTER-шлюз Отслеживание работы VPN-демона vrrp_script chk_dead {script "pgrep -x vpnsvc” interval 1} Синхронизация VRRP-процессов: vrrp_sync_group G1 { group { VI_1 VI_2 } Параметры первого VRRP-процесса: vrrp_instance VI_1 { state MASTER interface eth1 garp_master_delay 10 virtual_router_id 51 priority 100 advert_int 1 virtual_ipaddress {10.0.1.10/24} authentication {auth_type PASS auth_pass password} track_script { chk_dead } virtual_routes {src 10.0.1.10 10.0.2.10 via 10.0.1.1}} Параметры второго VRRP-процесса : vrrp_instance VI_2 {… interface eth0 virtual_router_id 52 virtual_ipaddress { 192.168.1.10/24 } …} Конфигурация VRRP (версия 4.1) 7© «С-Терра СиЭсПи», 2017 Конфигурация /etc/keepalived.conf BACKUP-шлюз вместо state MASTER будет state BACKUP: vrrp_instance VI_1 { state BACKUP …} Кроме того параметр priority должен быть изменен с 100 на 50: vrrp_instance VI_1 { priority 50 …}
  • 8. MASTER-шлюз Настройка в CLI: GW1(config)#interface GigabitEthernet 0/0 GW1(config-if)#vrrp 51 ip 192.168.1.10 GW1(config-if)#vrrp 51 priority 100 GW1(config-if)#vrrp 51 authentication pass123 GW1(config-if)#exit GW1(config)#interface GigabitEthernet 0/1 GW1(config-if)#vrrp 52 ip 10.0.1.10 GW1(config-if)#vrrp 52 priority 100 GW1(config-if)#vrrp 52 authentication pass123 GW1(config-if)#exit GW1(config)#vrrp ip route 10.0.2.0 255.255.255.0 10.0.1.1 src 10.0.1.10 GW1(config)#vrrp notify master GW1(config)#vrrp notify backup GW1(config)#vrrp notify fault GW1(config)#exit Конфигурация VRRP (версии 4.2) 8© «С-Терра СиЭсПи», 2017 Вся настройка из CLI BACKUP-шлюз Аналогично кроме параметра priority GW2(config)#interface GigabitEthernet 0/0 GW2(config-if)#vrrp 51 priority 50 GW2(config-if)#exit GW2(config)#interface GigabitEthernet 0/1 GW2(config-if)#vrrp 52 priority 50 GW2(config-if)#exit
  • 9. Резервирование шлюзов безопасности 9© «С-Терра СиЭсПи», 2017 RRI (англ. Reverse Route Injection)— механизм, предназначенный для отказоустойчивости Remote-Access VPN. Особенности механизма • Отказоустойчивость и балансировка нагрузки. • Необходимость внешнего баласировщика (маршрутизатора) • Соединения инициируют удаленные узлы • Работает как на статической, так и динамической cryptomap • В отдельных случаях резервирует и провайдеров Peer B ISP Клиенты Защищаемая подсеть GW1GW2 Peer A
  • 10. Конфигурация RRI 10© «С-Терра СиЭсПи», 2017 1. Настройка RRI в криптокарте GW1(config)#crypto dynamic-map DMAP 1 GW1(config-crypto-map)#match address LIST GW1(config-crypto-map)#set transform-set TSET GW1(config-crypto-map)#set pfs vko GW1(config-crypto-map)#reverse-route GW1(config-crypto-map)#exit 2. Настройка протокола RIP через /etc/quagga/ripd.conf hostname ripd password zebra debug rip events debug rip packet router rip version 2 redistribute kernel network eth0 distribute-list acl-in in distribute-list acl-out out access-list acl-in deny any access-list acl-out permit 192.168.11.0/24 access-list acl-out deny any log file /var/log/quagga/ripd.log log stdout3.
  • 11. Резервирование в IPsec – DPD 11© «С-Терра СиЭсПи», 2017 DPD (англ. Dead Peer Detection)— механизм обнаружения неработающего пира в рамках IKE и IPsec Особенности механизма • Составная часть IPsec, не требует дополнительных портов • Нет ответа – идем на next peer в cryptomap • Настраивается командой crypto isakmp keepalive secs [retries] • Требует настройки в случае нестабильного канала между устройствами • Более гибкий в версии 4.2: crypto isakmp keepalive retry-count {retry-count}
  • 12. Резервирование портов. Link-aggregation 12© «С-Терра СиЭсПи», 2017 Агрегирование каналов (англ. Link-aggregation)— технологии объединения нескольких параллельных линков в один логический, позволяющие увеличить пропускную способность и повысить надёжность. Особенности: • Описана в IEEE 802.3ad. • Реализуется средствами OC шлюза • Контроль канала – протокол LACP
  • 13. Настройка Link-aggregation 13© «С-Терра СиЭсПи», 2017 Конфигурация /etc/network/interfaces 4. Отредактируйте ifaliaces.cf, удалив eth2 и eth3: root@sterragate:~# vim.tiny /etc/ifaliases.cf interface (name="GigabitEthernet0/0" pattern="eth0") interface (name="GigabitEthernet0/1" pattern="eth1") interface (name="GigabitEthernet1/0" pattern="bond0") 5. Затем пересчитайте контрольную сумму и перезапустите VPN-демона root@sterragate:~# integr_mgr calc -f /etc/ifaliases.cf root@sterragate:~# service vpngate restart 1. Внесите изменение в /etc/network/interfaces: auto bond0 iface bond0 inet static address 10.1.1.1 netmask 255.255.255.0 slaves eth2 eth3 bond_mode 802.3ad bond_miimon 100 bond_xmit_hash_policy layer2+3 2. Далее, перезапустите сервис: root@sterragate:~# service networking restart 3. Проверьте наличие интерфейса bond0 в системе: root@sterragate:~# ip address show | grep bond0 4: eth2: mtu 1500 qdisc mq master bond0 state UP qlen 1000 5: eth3: mtu 1500 qdisc mq master bond0 state UP qlen 1000 10: bond0: mtu 1500 qdisc noqueue state UP inet 10.1.1.1/24 brd 10.1.1.255 scope global bond0
  • 14. Резервирование провайдеров GRE-over-IPsec 14© «С-Терра СиЭсПи», 2017 GRE over IPsec— технология для обеспечения отказоустойчивости оборудования и каналов связи. Составные компоненты: • GRE - протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. • OSPF – протокол динамической маршрутизации для обеспечения доступности площадок, отказоустойчивости и балансировки нагрузки • IPsec – стек протоколов шифрования
  • 15. 1. Настроим первый туннель: root@GW1:~# ip tunnel add gre1 mode gre remote 10.0.2.2 local 10.0.1.2 ttl 255 root@GW1:~# ip link set gre1 up root@GW1:~# ip link set gre1 mtu 1400 root@GW1:~# ip addr add 1.1.1.1/30 dev gre1 2. Настроим второй туннель: root@GW1:~# ip tunnel add gre2 mode gre remote 10.0.4.2 local 10.0.3.2 ttl 255 root@GW1:~# ip link set gre2 up root@GW1:~# ip link set gre2 mtu 1400 root@GW1:~# ip addr add 2.2.2.1/30 dev gre2 3. Опишите трафик, который планируется защищать. Для этого создайте расширенный список доступа: GW1(config)#ip access-list extended LIST GW1(config-ext-nacl)#permit gre host 10.0.1.2 host 10.0.2.2 GW1(config-ext-nacl)#exit GW1(config)#ip access-list extended LIST2 GW1(config-ext-nacl)#permit gre host 10.0.3.2 host 10.0.4.2 GW1(config-ext-nacl)#exit 4. Настройке OSPF в файле /etc/quagga/ospf.conf hostname ospfd password zebra enable password zebra router ospf network 192.168.1.0/24 area 0 network 1.1.1.0/30 area 0 network 2.2.2.0/30 area 0 log file /var/log/quagga/ospfd.log log stdout Настройка GRE-over-IPsec 15© «С-Терра СиЭсПи», 2017
  • 16. Object Tracking 16© «С-Терра СиЭсПи», 2017 Object Tracking— механизм переключения каналов, основанный на периодической проверке доступности узла в сети. Скрипт изменяет метрики основного и резервного маршрутов до узла. Параметры скрипта /etc/rc.local.inc #!/bin/bash PING_IP=8.8.8.8 #IP-арес для ICMP запросов PING_COUNT=10 #Кол-во пропущеных ICMP-запросов для переключения PING_TIMEOUT=3 #Интервал отправки ICMP-запросов для переключения RESTORE_PING_COUNT=10 #Кол-во пропущеных ICMP-запросов для восстановления RESTORE_TIMEOUT=1 #Интервал отправки ICMP-запросов для восстановления MAIN_INTERFACE=eth1 #Интерфейс, подключенный к основному провайдеру BACKUP_INTERFACE=eth2 #Интерфейс, подключенный к резервному провайдеру MAIN_GATEWAY=10.1.1.1 #Шлюз основого провайдера BACKUP_GATEWAY=10.1.2.1 #Шлюз резервного провайдера
  • 17. Масштабирование на L3, IPsec over GRE 17© «С-Терра СиЭсПи», 2017 Особенности решения • GRE и OSPF/EIGRP-реализуется на маршрутизаторах • Балансировка и отказоустойчивость на L3. • Масштабируемость практически в любых объемах
  • 18. Масштабирование на L2, Link-Aggregation 18© «С-Терра СиЭсПи», 2017 • Link-aggregation настраивается на коммутаторах • На шлюзах используется пакет S-Terra L2 • Высокая масштабируемость решения
  • 19. Резюме 19© «С-Терра СиЭсПи», 2017 Решение Основное назначение Балан- сировка Оптимальная топология Время восстановления * (секунд) VRRP Резервирование шлюзов Нет Не важно 1-5 RRI Резервирование шлюзов Есть Большое количество удаленных пользователей или филиалов. 7-15 Link Aggregation Резервирование портов Есть Для локального сегмента 1-5 GRE over IPsec на шлюзе Резервирование каналов Есть Site-to-Site или филиальная сеть. 7-15 Object Tracking Резервирование каналов Нет Site-to-Site или филиальная сеть. 10-20 GRE over IPsec для балансировки нагрузки Резервирование оборудования и каналов связи Есть Защита высокоскоростных каналов связи на уровне L3 7-15 Link Aggregation для балансировки нагрузки Резервирование оборудования и каналов связи Есть Защита высокоскоростных каналов связи на уровне L2 1-5 * без учета времени перестроения туннелей. Время перестроения туннелей зависит от их количества и обычно лежит в диапазоне 0,5-1,5 минуты.
  • 20. Шпаков Андрей Ведущий инженер Отдел технического консалтинга Тел.: +7 (499) 940-90-61 (доб. 133) Email: ashpakov@s-terra.ru, presale@s-terra.ru

Editor's Notes

  1. Коллеги, Добрый день, давайте начинать. Меня зовут Шпаков Андрей. Я являюсь presale-инженером компании С-Терра СиЭсПИ. На сегодняшнем вебинаре мы обсудим тему отказоустойчивых решений наших продуктах, как они настраиваются и реализуются. Данный доклад является техническим и содержит минимум маркетинговой информации. По времени – рассчитывайте примерно на 45 минут + секция вопросов. Если у вас возникают вопросы, задавайте их в соответствующем окне в нижней правой части экрана. По окончанию доклада я отвечу на них.. После вебинара мы разошлем ссылки на видеозапись и на презентацию всем участникам.
  2. Итак, как будет построен данный вебинар. Вначале мы немного поговорим об определении отказоустойчивости и о том, какие узлы компоненты необходимо резервировать. Затем, мы поговорим о технологиях, которые для этого используются в шлюзах С-Терра, и об основных моментах их настройки.
  3. Как гласит определение, Отказоустойчивость – это способность системы выполнять свое предназначение в случае отказа какого-либо из своих элементов. В хорошо организованной надежной сети отказ любого из её элементов не приведет к заметному падению уровня предоставляемых сервисов. Если рассмотреть такой вид оборудования, как VPN-шлюз, то него есть несколько аспектов, по которым требуется резервирование: Аппаратные компоненты шлюза. Это непосредственно сами шлюзы Порты на устройствах Ну и последнее – это каналы связи, по которым шлюзы передают зашифрованные данные, Так же стоит отметить, что в некоторых случаях сами шлюзы безопасности являются составными компонентами отказоустойчивого решения. Далее, рассмотрим более детально каждый из этих аспектов.
  4. Резервирование комплектующих АП. Самые уязвимые из них – это носители информации на магнитных дисках, то есть жесткие диски и блоки питания, единственные комплектующие в современных платформах имеющих аналоговые компоненты. Для старших моделей шлюзов компания С-Терра предлагает такое резервирование. На слайде можно видеть фрагмент из нашего открытого прайс-листа, ссылка на который имеется на экране. В нем отдельные артикулы шлюзов, начиная с С-Терра Шлюз 3000 Low-end имеют полноценное резервирование аппаратных комплектующих. , Напомню, что С-Терра Шлюз 3000 low-end - это самые младшие шлюзы, которые производятся на базе полноценных серверных платформ, Определить то, что платформа имеет резервирование, можно, посмотрев на артикул в левой части прайса. Если в нем есть обозначение RP – это означает Redundant Power Supply, то есть резервирование блоков питания в горячем резерве Если в артикуле есть обозначение RED – это означает, что дополнительно к резерву блоков питания добавляются два жестких диска в RAID1-массиве. А , если есть обозначение RED10, то в шлюзе будет 4 диска в массиве RAID10. Отмечу ,что все реализации RAID в наших шлюзах - аппаратные. Так же при выборе платформы нужно обращать внимание на декларируемое время наработки на отказ. Все платформы шлюзов С-Терра имеют время наработки на отказ не менее 50000 часов. Гарантия на них составляет 3 года. Напомню, что у конкурентов – только 1 год гарантии. DEPO - 50000 EL19 – 50000 Cisco C220 - 73000
  5. Далее, перейдем к резервированию шлюзов безопасности. Для этого в шлюзах С-Терра используются протокол VRRP, либо технология RRI. Рассмотрим первый протокол. VRRP это сетевой протокол, описанный в RFC 3789 и предназначенный для увеличения доступности сетевых устройств. Это достигается путём объединения группы шлюзов в один виртуальный шлюз и назначения им общих IP-адреса, которые и будут использоваться, как адреса для терминирования VPN-туннелей и как адрес шлюза по-умолчанию для компьютеров в локальной сети. При типовом случае применения протокола VRRP два шлюза безопасности объединяются в один виртуальный. В каждый момент времени трафик обрабатывает только одно устройство. В случае его отказа — в работу включается второй шлюз. То есть мы имеем кластер вида Active-Passive. Переключение между ними происходит за несколько секунд и обычно незаметно для конечного пользователя. После переключения происходит перестроение туннелей. Время полного восстановления работы сети зависит от многих факторов, таких как количество туннелей, терминирующихся на шлюзе, настройка таймеров DPD и др., но обычно не превышает 1 или 2 минут. Стоит отметить, что сценарий работы данного протокола доступен как для L3-интерфейсов, так и для L2-интерфейсов.
  6. Рассмотрим более подробно логику работы на примере кластера из двух шлюзов. Один из шлюзов настраивается предварительно, как MASTER, остальные - как BACKUP. В один момент времени виртуальный адрес (10.0.1.10 в нашем случае) может быть только на шлюзе, который находится в состоянии MASTER. Далее, MASTER-Шлюз начинает слать пакеты VRRP через интерфейсы 0/0 и 0/1 используя мультикаст адрес 224.0.0.18. Если по причинам, описанным ниже, главный шлюз становится недоступным, его состояние меняется с MASTER на FAULT. Второй шлюз определяет отсутствие VRRP-пакетов и состояние меняет состояние с BACKUP на MASTER. Далее он отсылает так называемый GARP-пакет, чтобы обозначить коммутаторам свой MAC-адрес для обновления ARP-таблицы и продолжает заниматься обработкой трафика. При возвращении в строй главного шлюза, трафик снова будет обрабатываться на нем.
  7. Теперь перейдем к конфигурации непосредственно на шлюзах. Протокол VRRP реализован в шлюзах безопасности S-Terra при помощи open-source проекта Keepalived Для настройки keepalived используется файл /etc/keepalived/keepalived.conf. Данный файл разбит на блоки, каждый блок отвечает за свою часть настроек. Далее я постараюсь описать основную часть этих блоков: Во-первых это скрипт, который отслеживает состояние VPN-демона каждую секунду. Если демон vpnsvc по каким-то причинам выгрузится, состояние шлюза изменится с BACKUP/MASTER на FAULT. Далее синхронизация состояния двух VRRP-процессов (VRRP-instances) на шлюзе. В случае отказа одного из VRRP-процессов, для всей группы будет происходить смена состояния. Теперь укажем параметры первого VRRP-процесса: Состояние MASTER, интерфейс, на котором работает процесс VRRP, задержку секунд перед повторной отправкой GARP после перехода в состояние MASTER, Идентификатор виртуального маршрутизатора. Обратите внимание, что для шлюзов в одном кластере и в одном бродкаст домене этот параметр должен быть идентичен. Далее интервал отправки пакетов, параметры аутентификации, а также виртуальный IP-адрес для данного бродкаст-домена и маршрут. Обратите внимание, что задается так называемый source-маршрут. То есть при отправке пакетов по адресу 10.0.2.10 через шлюз 10.0.1.1 мы будем изменять source-адрес пакета на наш виртуальный адрес. Далее, мы настраиваем VRRP-процесс на втором интерфейсе. Здесь все настройки те же самые, кроме virtual_router_id, адреса и самого интерфейса. Для второго шлюза настройки идентички, кроме того, что мы указываем состояние BACKUP по умолчанию, а так же ставим более низкий параметр priority. Этот параметр сравнивается, когда устранен отказ шлюза GW1, для того, чтобы он снова стал Мастером. Настройка в 4.2
  8. В версии 4.2 настройка VRRP уже осуществляется через Cisco-like консоль. Здесь, по аналогии с Cisco, мы должны указать номер VRRP группы, который аналогичен параметру router_id из конфигурации 4.1, Ip-адреса на интерфейсах, параметры аутентификации и виртуальный маршрут, ну и включить дополнительные скрипты при активации состояния канала. Таким образом в новой версии мы сделали новый шаг к унификации настройки параметров шлюза из одного интерфейса. Так же в версии 4.2 появился ряд дополнительных параметров, который позволил уменьшить время перестроения туннеля со средних 90 секунд до 30-ти.
  9. Теперь поговорим о втором механизме отказоустойчивости для шлюзов – механизм RRI. Данная технология была разработана компанией Cisco для повышения отказоустойчивости схем подключения удаленного доступа. То есть у нас есть удаленные клиенты, которые подключаются к какому-то колличеству шлюзов, либо у нас есть классическая звезда, где spoke должны строить соединения к отказоустойчивому хабу – мы можем использовать данную технологию. Как она работает? Как только удаленный объект строит VPN-туннель на шлюз с включенным RRI, шлюз автоматически добавляет маршшрут до этого объекта в таблицу маршрутизации. Даллее маршрут передается с помощью протокола динамической маршрутизации на балансировщик и весь обратный трафик к удаленному объекту пойдет через этот шлюз. При этом для реализации балансировки нагрузки на удаленных узлах нужно вносить в список пиров все шлюзы, а в случае мобильного клиента – включить кнопку случайного выбора пира В отдельных случаях, когда каждый из шлюзов подключен к своему оператору, сценарий RRI позволяет резервировать и провайдеров.
  10. Перейдем к настройке. Как видно на слайде…
  11. Дополнительно хотел бы немного рассказать о механизме Dead Peer Detection, упомянутом в предыдущем слайде. Этот механизм является составной частью IPSec-а и предназначен для определения статуса пира. Как он работает: каждый из партнеров проверяет наличие регулярного обмена шифрованными пакетами в рамках IKE-сессии. Если у нас идет трафик, то механизм не запускается. Как только появляется простой – запускается механизм обмена DPD-пакетами. В случае, если ответы не приходят, происходит перестроение на следующего пира в списке криптокарты. В Cisco-like консоли он настраивается командой crypto isakmp keepalive с двумя аргументами, где первый – это промежуток простоя обмена пакетами, а второй - время между отправкой следующего DPD-пакета Стоит отметить, что в случае использования этого механизма на нестабильных каналах связи, может потребоваться некоторая настройка. В частности, если мы хотим ослабить реакцию на кратковременные падения линка, то нам следует поднять значения retries, а не увеличивать период отсутствия трафика. В версии 4.2 у нас появилась дополнительная настройка, отсутствующаяв Cisco IOS – это колличество пакетов, которое необходимо посылать. Меняя данный параметр, в том числе, можно ускорить переключение различных сценариев резервирование. В завершение отмечу, что механизм DPDмы рекомендуем использовать данный механизм во всех сценариях.
  12. Теперь перейдем к следующей задаче – резервирование портов. Для этого используется технология Link Aggregation, которая позволяет объединить несколько физических интерфейсов в один логический и базируются на стандарте IEEE 802.3ad. Настраивается агрегация портов средстави операционной системы шлюза. Объединив два физических Гигабитных интерфейса, в ОС мы будем видеть один интерфейс, но способный работать со скоростью до 2Гбит. Влияние агрегированного канала на производительность шлюза безопасности можно считать незначительной. Накладные расходы на балансировку пакетов между физическими каналами внутри агрегированного уменьшают максимальную производительность шлюза в среднем на 5-10%. Для контроля состояния агрегированного канала используется протокол LACP. Это публично описанный протокол и реализация его в С-Терра совместима с реализацией у других российских и иностранных производителей телекоммуникационного оборудования. Этот же протокол используется для балансировки нагрузки между каналами.
  13. Теперь перейдем непосредственно к настройке агрегированных каналов на шлюзах. Настройка осуществляется через файл /etc/network/interfaces. Это стандартный файл в ОС Debian для внесения сетевых настроек. Первым шагом вносим строчки, как показано на слайде. Здесь мы указываем адрес и маску нового интерфейса, его имя, какие порты будут агрегироваться (в данном случае это eth2 и eth3, режим работы LACP командой bond_mode, интервал проверки интерфейсов, а так же метод балансировки нагрузки на основе хеша от мак-адресов и ip-адресов. Далее, перезапускаем сетевой сервис Debian-а, убеждаемся, что у нас появился новый интерфейс в системе. Теперь нужно отердактировать файл ifalices.cf, который лежит в каталоге /etc/, добавил туда новый интерфейс, удалив eth2 и eth3. В данный файле указываются интерфейсы, на которые будет повешен драйвер С-Терра. После чего пересчитываем контрольную сумма и перезапускаем vpn-сервис.
  14. Итак, перейдем к задаче резервирования каналов передачи данных. Начнем с В данном сценарии рассматривается схема обеспечения отказоустойчивости с применением технологии GRE over IPsec с балансировкой по протоколу EIGRP/OSPF. Логика работы и используемые технологии GRE – протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Данный протокол позволяет инкапсулировать пакеты сетевого уровня в IP пакеты. OSPF – протокол динамической маршрутизации, основанный на технологии отслеживания состояния канала (link-state technology). EIGRP – усовершенствованный дистанционно-векторный протокол динамической маршрутизации, разработанный компанией Cisco. Шлюзы безопасности, попарно, настраиваются для работы в режиме защиты канала связи (site-to-site). Маршрутизаторы создают несколько параллельных GRE-туннелей, каждый из которых проходит через отдельный шлюз безопасности. Внутри GRE-туннелей проброшена динамическая маршрутизация EIGRP. Каждая пара шлюзов защищает один GRE туннель (пакеты GRE шифруются и попадают в IPsec туннель). В результате такой настройки в таблице маршрутизации маршрутизатора появляется несколько маршрутов (через GRE-туннели) до удаленной защищаемой подсети с одинаковой метрикой. В результате, маршрутизатор балансирует трафик между несколькими эквивалентными маршрутами и, как следствие, между разными парами шлюзов безопасности. Отказоустойчивость такой схемы обеспечивается за счет динамической маршрутизации. Если один из шлюзов безопасности выходит из строя, маршрут через соответствующий ему GRE-туннель автоматически удаляется. Балансировка трафика продолжается на оставшиеся в работе шлюзы безопасности. В реальных сетях обычно применяется схема, в которой присутствует также выходной маршрутизатор, подключенный к линии провайдера. В рамках данного решения резервируются провайдеры (каналы связи). Это достигается следующим образом: между шлюзами безопасности строится 2 GRE-туннеля. GRE-туннели, в свою очередь, инкапсулируются в IPsec. Внутри GRE-туннелей пропускается полезный трафик, а также пакеты динамической маршрутизации OSPF. Это позволяет иметь до удаленной подсети 2 равноправных (с одинаковой метрикой) маршрута. OSPF по умолчанию осуществляет балансировку между эквивалентными маршрутами по алгоритму “per-destination IP”. В случае сбоя одного из каналов связи – динамическая маршрутизация обнаружит отказ, и в таблице маршрутизации останется только один маршрут. Как следствие, весь трафик будет направлен через рабочий канал связи. Кроме того, имеется возможность построить решение без балансировки: весь трафик будет идти только через 1 канал, а второй включится в работу только при обрыве первого. Время восстановления связи при обрыве канала зависит от настроек OSPF и обычно находится в диапазоне 10-40 секунд. Важно отметить, что за счет двойной инкапсуляции (ESP+GRE) требуется несколько уменьшить MTU на интерфейсах. Стенд отрабатывает следующие типы отказов:  отказ одного из провайдеров;  отказ порта шлюза с одним из провайдеров. .
  15. Для простоты я уточнил
  16. Так же, альтернативным методом резервирования каналов связи является исопльзование механизмов Object Tracking, то есть отслеживани какого-либо узла в интернете, и, в случае его недостуности, переключение на резервный канал. Для наших шлюзов версии 4.1 имеется такой сценарий при использовании скрипта. Я не буду приводить сюда полный текст, с ним вы сможете ознакомиться в соответсвующем сценарии на сайте, а приведу логику работы и основные параметры. ; По умолчанию существует оба маршрута через основного и резервного провайдера. Маршрутизация определяется метрикой маршрута. Метрика через основного провайдера – 100, метрика через резервного провайдера – 200. Трафик идет через основного провайдера. Через каждые N секунд (количество секунд определяется переменной PING_TIMEOUT) запускается утилита ping на отправку 1 ICMP-запроса. С каждым неполученным ICMP-ответом число PING_COUNT уменьшается. При получении ICMP-ответа число PING_COUNT возвращается в изначальное значение. Если PING_COUNT доходит до нуля, то метрика через резервного провайдера становится – 100, а через основного – 200. Трафик начинает идти через резервного провайдера. При этом ICMP-запросы через основного провайдера продолжают отправляться. При получении ICMP-ответа интервал между ICMP-запросами становится в значение RESTORE_PING_TIMEOUT. После получения подряд N пакетов (количество пакетов определяется переменной RESTORE_PING_COUNT) происходит обратное переключение на основного провайдера. Если ICMP-ответ не приходит счетчик ICMP- ответов сбрасывается. При переключении провайдера происходит перезагрузка политики безопасности (lsp_mgr reload), а в лог добавляется сообщение о переключении.
  17. Опишите трафик, который планируется защищать. Для этого создайте расширенный список доступа (47 – номер протокола GRE): GW1(config)#ip access-list extended LIST GW1(config-ext-nacl)#permit 47 1.1.1.1 0.0.0.0 1.1.1.2 0.0.0.0 GW1(config-ext-nacl)#exit Задайте loopback-интерфейсы, которые будут использоваться как source-интерфейсы для GRE- туннелей. На каждый туннель необходимо по одному такому интерфейсу с каждой стороны. В данном случае их 3. interface Loopback1 ip address 1.1.1.1 255.255.255.255 interface Loopback2 ip address 1.1.2.1 255.255.255.255 interface Loopback3 ip address 1.1.3.1 255.255.255.255 2. Создайте GRE-туннели: interface Tunnel1 ip address 10.2.1.1 255.255.255.252 ip mtu 1420 ip load-sharing per-destination 3. Задайте source-адрес и destination-адрес туннеля. В данном случае – это IP-адрес соответствующего loopback-интерфейса: tunnel source Loopback1 Версия 4.1 Пример использования Редакция 13 © 2003-2015 S-Terra CSP 7 tunnel destination 1.1.1.2 4. Остальные туннели настройте аналогично: interface Tunnel2 ip address 10.2.1.5 255.255.255.252 ip mtu 1420 ip load-sharig per-destination tunnel source Loopback2 tunnel destination 1.1.2.2 interface Tunnel3 ip address 10.2.1.9 255.255.255.252 ip mtu 1420 ip load-sharig per-destination tunnel source Loopback3 tunnel destination 1.1.3.2 5. Настройте EIGRP-маршрутизацию: router eigrp 10 passive-interface GigabitEthernet0/0 network 10.2.1.0 0.0.0.15 network 192.168.1.0 no auto-summary Цифра 10 в команде router EIGRP 10 указывает на Autonomous System Number и должна быть одинакова для обоих маршрутизаторов. Параметр passive-interface указывает, что через Gi0/0 EIGRP-пакеты посылаться не будут, т.к. мы не ожидаем увидеть на нем EIGRP-маршрутизатора. Команда network задает подсети, информация о которых будет передаваться по EIGRP. 6. Пропишите пути к разным удаленным Loopback-интерфейсам через разные шлюзы (192.168.2.2 – 192.168.2.4 – адреса шлюзов GW11, GW21, GW31) таким образом, что трафик по разным туннелям будет ходить по разным физическим каналам: ip route 1.1.1.2 255.255.255.255 192.168.2.2 ip route 1.1.2.2 255.255.255.255 192.168.2.3 ip route 1.1.3.2 255.255.255.255 192.168.2.4
  18. Сводная таблица параметров отказоустойчивых решений
  19. Все указанные сценарии доступны у нас на сайте в разделе Решения.