Дано: базовая топология для рассмотрения концепта работы HSRP. Базовые интерфейсы роутеров и свитчей уже настроены и здесь не рассматриваются подробно.
Приступим.
вторник, 23 сентября 2014 г.
HSRP basic example 2 routers
Дано: базовая топология для рассмотрения концепта работы HSRP. Базовые интерфейсы роутеров и свитчей уже настроены и здесь не рассматриваются подробно.
Приступим.
среда, 3 сентября 2014 г.
ASA policy
Yea, yea, yea. ASA policy. Yes :)
■ Class map: Which traffic will be matched?
■ Policy map: What action will be taken on each class of traffic?
■ Service policy: Where will the policy map be applied?
■ Class map: Which traffic will be matched?
■ Policy map: What action will be taken on each class of traffic?
■ Service policy: Where will the policy map be applied?
802.1p
Стандарт IEEE 802.1p специфицирует метод указания приоритета кадра, основанный на использовании новых полей, определенных в стандарте IEEE 802.1Q.
К кадру Ethernet добавлены четыре бита, которые содержат информацию о принадлежности кадра Ethernet к VLAN и о его приоритете. Говоря точнее, тремя битами кодируется один из восьми уровней приоритета, а последние 12 бит относят трафик к одному из 4096 VLAN.
Восемь различных классов для 3-битового поля PCP в заголовке IEEE 802.1Q:
К кадру Ethernet добавлены четыре бита, которые содержат информацию о принадлежности кадра Ethernet к VLAN и о его приоритете. Говоря точнее, тремя битами кодируется один из восьми уровней приоритета, а последние 12 бит относят трафик к одному из 4096 VLAN.
Восемь различных классов для 3-битового поля PCP в заголовке IEEE 802.1Q:
| PCP | Priority | Acronym | Traffic Types |
|---|---|---|---|
| 1 | 0 (lowest) | BK | Background |
| 0 | 1 | BE | Best Effort |
| 2 | 2 | EE | Excellent Effort |
| 3 | 3 | CA | Critical Applications |
| 4 | 4 | VI | Video, < 100 ms latency and jitter |
| 5 | 5 | VO | Voice, < 10 ms latency and jitter |
| 6 | 6 | IC | Internetwork Control |
| 7 | 7 (highest) | NC | Network Control |
пятница, 29 августа 2014 г.
ASA memo-simple tutorial
Firewall Techniques
network layer access control
decisions based on Layers 2 through 4, or the data link, network, and transport layers.
application layer access control
Layers 5 through 7, or the session, presentation, and application layers.
четверг, 28 августа 2014 г.
IPS False Positives and Negatives
False Positives
False positives are events where the sensor reacts or responds to traffic that is not malicious. This would represent an error in the network environment the sensor is in. For two different networks, the attack might be a false positive in one and correct in the other. It depends on what type of traffic is permitted or acceptable on each network. A false positive can be caused by signatures that are too general in their attack-matching criteria and fire off on both malicious and nonmalicious traffic.
False Negatives
False negatives are events where the sensor doesn’t fire off any alerts, or produce any actions, even when the sensor has seen malicious traffic. One network’s malicious traffic can be a different network’s acceptable traffic. This would represent an error from an IPS perspective and can be caused by a signature that is too specific in its matching criteria. This could also be caused by evasion techniques the attacker is using or by signatures being disabled that might have been able to identify the attack. Table 13-2 shows some examples of false positives.
False positives are events where the sensor reacts or responds to traffic that is not malicious. This would represent an error in the network environment the sensor is in. For two different networks, the attack might be a false positive in one and correct in the other. It depends on what type of traffic is permitted or acceptable on each network. A false positive can be caused by signatures that are too general in their attack-matching criteria and fire off on both malicious and nonmalicious traffic.
False Negatives
False negatives are events where the sensor doesn’t fire off any alerts, or produce any actions, even when the sensor has seen malicious traffic. One network’s malicious traffic can be a different network’s acceptable traffic. This would represent an error from an IPS perspective and can be caused by a signature that is too specific in its matching criteria. This could also be caused by evasion techniques the attacker is using or by signatures being disabled that might have been able to identify the attack. Table 13-2 shows some examples of false positives.
| ICMP Network Sweep w/Echo | ICMP reconnaissance | Network mapping tools being run by management host |
| Failed Login | Brute-force attack or password guessing | Valid user forgot password and was making several attempts |
| UDP Flood | UDP DoS attack | Video or voice calls, using lots of UDP |
воскресенье, 24 августа 2014 г.
IPS Custom Signatures
| Traffic Analysis Method | Cisco IPS Inspection Engines |
| Packet header matching | Atomic |
| Packet content matching | Atomic |
| Stateful content matching | String |
| Protocol decoding | Service |
| Rate analysis | Flood |
| Traffic correlation | Sweep |
| Event correlation | Meta |
Creating Custom Signature Guidelines:
IPS anomaly overview and components
Anomaly Detection Overview
The IPS anomaly detection feature is a statistical anomaly-based system. Its purpose is to identify and prevent scanning network worms. A scanning network worm spreads by blindly scanning a network to find victims and then compromising those victims through network attacks. These attacks are typically against exposed network services.
IPS Traffic normalization and signatures
Understanding Cisco IPS Sensor Inline Traffic Normalization
The Cisco IPS Sensor traffic normalizer is a function performed by the SensorApp application in inline mode. A function of the normalizer identifies and stops users from trying low-level evasive techniques to evade detection. The normalizer ensures low-level (mostly IP and TCP) protocol conformance, tracks session state, modifies ambiguously fragmented traffic to remove ambiguities, and properly orders segments to present normalized data to application layer inspectors.
The inline traffic normalizer enforces all anti-evasion checks to traffic incoming from inline traffic sources by operating in its Strict Evasion Protection mode. The normalizer operates in this mode by default, and it is the recommended mode by Cisco best practices. The normalizer can optionally be switched to Asymmetric Mode Protection. While in Asymmetric Mode Protection, most anti-evasion countermeasures are disabled, but the sensor is able to analyze asymmetric traffic. Also in this mode, the sensor only sees one direction of a session. Asymmetric Mode Protection of the traffic normalizer should only be used if asymmetric traffic flows are being inspected and remediation cannot be done by forcing symmetric traffic flows.
The Cisco IPS Sensor traffic normalizer is a function performed by the SensorApp application in inline mode. A function of the normalizer identifies and stops users from trying low-level evasive techniques to evade detection. The normalizer ensures low-level (mostly IP and TCP) protocol conformance, tracks session state, modifies ambiguously fragmented traffic to remove ambiguities, and properly orders segments to present normalized data to application layer inspectors.
The inline traffic normalizer enforces all anti-evasion checks to traffic incoming from inline traffic sources by operating in its Strict Evasion Protection mode. The normalizer operates in this mode by default, and it is the recommended mode by Cisco best practices. The normalizer can optionally be switched to Asymmetric Mode Protection. While in Asymmetric Mode Protection, most anti-evasion countermeasures are disabled, but the sensor is able to analyze asymmetric traffic. Also in this mode, the sensor only sees one direction of a session. Asymmetric Mode Protection of the traffic normalizer should only be used if asymmetric traffic flows are being inspected and remediation cannot be done by forcing symmetric traffic flows.
суббота, 23 августа 2014 г.
Accessing and Using the Cisco IPS Sensor CLI and IDM
You can access the CLI of a sensor appliance in one of three ways:
- SSH (Secure Shell)
- Telnet (disabled by default)
- Serial interface connection
четверг, 21 августа 2014 г.
IPS Deployment
Sensor Deployment Modes
- Promiscuous mode
- Inline interface pair mode
- Inline VLAN pair mode
- Inline VLAN group mode
- Selective inline analysis mode
воскресенье, 17 августа 2014 г.
IPS tutorial, basic concepts and terminology
SITUATIONS
■ True positive: A situation in which a signature fires correctly when intrusive traffic for that signature is detected on the network. The signature correctly identifies an attack against the network. This represents normal and optimal operation.
Атаки обнаруживаются корректно. Нормальный режим работы.
■ False positive: A situation in which normal user activity triggers an alarm or response. This is a consequence of nonmalicious activity. This represents an error and generally is caused by excessively tight proactive controls or excessively relaxed reactive controls.
Ситуация, в которой деятельность обычного пользователя деятельность вызывает тревогу или срабатывание. Это является следствием либо слишком жёстких политик мониторинга либо слишком мягкой политикой регламента работы персонала.
пятница, 15 августа 2014 г.
MPLS-TE
As I promised, a short briefing on the MPLS-TE.
CONFIGURATION CONCEPT
1) Configuring a Device to Support Tunnels
Enable standard CEF operation.
Enables the MPLS traffic engineering tunnel feature on a device.
and additionsRouter(config)# ip cef Router(config)# mpls traffic-eng tunnels
Router(config)#mpls traffic-eng logging lsp setups Router(config)#mpls traffic-eng logging lsp teardowns Router(config)#mpls traffic-eng reoptimize events link-up
среда, 13 августа 2014 г.
MPLS brief
MPLS is a simple protocol for me. But some of my colleagues in the discussion asked me to talk about it in more detail.
Terminology
LSR (Label Switch Router) -- Any router that pushes labels onto packets, pops labels from packets, or
simply forwards labeled packets.
CE -- Customer edge
simply forwards labeled packets.
CE -- Customer edge
PE -- Provider edge
E-LSR (Edge LSR) -- An LSR at the edge of the MPLS network, meaning that this router
processes both labeled and unlabeled packets.
Ingress E-LSR -- For a particular packet, the router that receives an unlabeled packet and then
inserts a label stack in front of the IP header.
Egress E-LSR -- For a particular packet, the router that receives a labeled packet and then
removes all MPLS labels, forwarding an unlabeled packet.
ATM-LSR -- An LSR that runs MPLS protocols in the control plane to set up ATM
virtual circuits. Forwards labeled packets as ATM cells.
ATM E-LSR -- An E-edge LSR that also performs the ATM Segmentation and Reassembly
(SAR) function.
TE -- Traffic Engineering
CEF -- Cisco Express Forwarding
RIB -- Routing Information Base
processes both labeled and unlabeled packets.
Ingress E-LSR -- For a particular packet, the router that receives an unlabeled packet and then
inserts a label stack in front of the IP header.
Egress E-LSR -- For a particular packet, the router that receives a labeled packet and then
removes all MPLS labels, forwarding an unlabeled packet.
ATM-LSR -- An LSR that runs MPLS protocols in the control plane to set up ATM
virtual circuits. Forwards labeled packets as ATM cells.
ATM E-LSR -- An E-edge LSR that also performs the ATM Segmentation and Reassembly
(SAR) function.
TE -- Traffic Engineering
CEF -- Cisco Express Forwarding
RIB -- Routing Information Base
FIB -- Forwarding Information Base
LFIB -- Label Forwarding Information Base
LFIB -- Label Forwarding Information Base
LIB -- Label Information Base. LSRs store labels and related information inside. The LIB essentially
holds all the labels and associated information that could possibly be used to forward packets.
holds all the labels and associated information that could possibly be used to forward packets.
воскресенье, 10 августа 2014 г.
QoS для совсем чайников, вдруг кому поможет :)
| Что такое ToS, DSCP, CoS, QoS. |  |
Для начала расшифруем аббревиатуры.
Термин QoS объединяет три термина: 1) ToS 2) DSCP 3) CoS. QoS - в построении и обработке очереди пакетов с разным приоритетом по одному из алгоритмов
QoS Layer 3 (ToS , DSCP)
Аббревиатуры ToS и DSCP родственны - используются для обозначения специального байта данных стандартного заголовка IP-пакета. Этот байт несет информацию о приоритете трафика, который в бизнес-трафике обычно назначается для пакетов IP-телефонии (третий сетевой уровень L3). Поскольку этот один и тот же байт иногда интерпретируется по-разному (либо как ToS байт, либо как DS/DSCP байт), получается некоторая путаница, хотя смысл и принцип технологии приоритезации не меняется - пакеты, помеченные более высоким приоритетом, передаются быстрее (менее приоритетные становятся в очередь). Накладывание на пакеты битов приоритета еще называют "маркированием" трафика, и чтобы приоритезация действительно работала, на всем пути прохождения трафика биты приоритета должны быть проанализированы и обработаны на активном сетевом оборудовании (настраиваемые роутеры и коммутаторы). На рисунке показано расположение бит байта маркировки трафика (красным помечена наиболее важная, серым - неиспользуемая часть).  Когда используют терминологию ToS, то в контексте приоретизации имеют в виду 3 старшие бита P2..P0, кодирующие уровень приоритета от 0 (минимальный приоритет) до 7 (максимальный приоритет). Для IP-телефонии применяется уровень приоритета: 5 (critical, ToS-байт равен 0xA0 или 10100000b). Для обычного трафика уровень проритета: 0 (routine, ToS-байт равен 0x00 или 00000000b) . У Cisco есть для каждого уровня приоритета специальное имя (precedence critical, precedence flash и т. д., см. таблицу). IP Precedence Value
Когда используют терминологию DSCP, имеются в виду 6 старших бит DS5..DS0, где DS5..DS3 кодируют уровень класса обслуживания от 0 (минимальный приоритет) до 7 (максимальный приоритет) и приоритет удаления (от 0, когда приоритет удаления максимальный, до 7, когда приоритет удаления минимальный - кодирование приоритета удаления “обратное”). В итоге получается число от 0 до 63, кодирующее приоритет (чем больше число, тем трафик важнее). Такое многоуровневое кодирование приоритета часто оказывается избыточным, и поэтому используются только биты DS5..DS3. При IP-телефонии применяется класс сервиса 5 (DS-байт равен 0xA0 или 10100000b) Для обычного трафика класс сервиса 0 (DS-байт равен 0x00 или 00000000b). Сравните с ToS - изменилась только терминология, а значение байта передается то же самое. Буквенные мнемонические коды величины DSCP можно посмотреть командой: Router(config)# class-map match-all VOIP 1751-uut1(config-cmap)# match ip dscp ? <0-63> Differentiated services codepoint value af11 Match packets with AF11 dscp (001010) af12 Match packets with AF12 dscp (001100) af13 Match packets with AF13 dscp (001110) af21 Match packets with AF21 dscp (010010) af22 Match packets with AF22 dscp (010100) af23 Match packets with AF23 dscp (010110) af31 Match packets with AF31 dscp (011010) af32 Match packets with AF32 dscp (011100) af33 Match packets with AF33 dscp (011110) af41 Match packets with AF41 dscp (100010) af42 Match packets with AF42 dscp (100100) af43 Match packets with AF43 dscp (100110) cs1 Match packets with CS1(precedence 1) dscp (001000) cs2 Match packets with CS2(precedence 2) dscp (010000) cs3 Match packets with CS3(precedence 3) dscp (011000) cs4 Match packets with CS4(precedence 4) dscp (100000) cs5 Match packets with CS5(precedence 5) dscp (101000) cs6 Match packets with CS6(precedence 6) dscp (110000) cs7 Match packets with CS7(precedence 7) dscp (111000) default Match packets with default dscp (000000) ef Match packets with EF dscp (101110) Router1(config-cmap)# match ip dscp af31 Эти коды используются также при назначении трафику маркировки, при конфигурировании policy-map: !создается карта политики Police-GE0/1 policy-map Police-GE0/1 class Voice-GE0/1 priority 5000 set dscp ef class Route-GE0/1 set dscp cs6 priority 1000 class Signal-GE0/1 set dscp cs3 priority 4500 class class-default fair-queue
QoS Layer 2(CoS)
Когда используется термин CoS, то обычно имеется в виду перенос информации о приоритете на втором сетевом уровне L2 (MAC-адреса). При этом для кодирования приоритета используются 3 бита (получаются уровни от 0 до 7). Расположение этих бит в потоке данных зависит типа магистрального канала L2. Источник: http://microsin.net/adminstuff/cisco/tos-dscp-cos-qos.html |
среда, 30 июля 2014 г.
FlexVPN simple configuration
А почему, нет. Уже в 2012 году в Сан-Диего анонс был, пора начинать потихоньку.
Дано: Топология на рисунке. Задача сходна с DMVPN, нужно получить объединение в виртуальную LAN.
Решение:
Дано: Топология на рисунке. Задача сходна с DMVPN, нужно получить объединение в виртуальную LAN.
Решение:
воскресенье, 27 июля 2014 г.
SLA 24/7/365 with BGP dual way
Недавно разработывал комплексное решение в том числе с BGP, и вспомнил, что упоминался способ организации 24/7/365 доступности сервисов с помощью BGP. Особых пояснений тут не требуется.
P.S. IOS 15.1(4) M2 имеет проблемы в работе с BGP.
Как всегда кусок топологии от другого проекта на скорую руку :)
Никаких излишеств, только демонстрация принципа.
Дано:
Искомая AS1. Border routers CE1 CE2. Внешний IP их совпадает. BGP настроен тривиально просто без излишеств.
Решение:
Если CE1 анносировался первым, то таблица маршрутизации P роутера:
При падении линка или маршрутизации до CE1 зоны 10001, таблица маршрутизации перестроится на СЕ2. Правда это потребует "значительного" времени согласно таймерам BGP. Таблица маршрутизации роутера Р после перестройки маршрутизации станет такой.P.S. IOS 15.1(4) M2 имеет проблемы в работе с BGP.
Как всегда кусок топологии от другого проекта на скорую руку :)
Никаких излишеств, только демонстрация принципа.
Дано:
Искомая AS1. Border routers CE1 CE2. Внешний IP их совпадает. BGP настроен тривиально просто без излишеств.
Решение:
Если CE1 анносировался первым, то таблица маршрутизации P роутера:
100.0.0.0/30 is subnetted, 3 subnets
B 100.1.1.0 [20/0] via 201.0.0.2, 00:07:03
B 100.1.1.4 [20/0] via 201.0.0.2, 00:10:10
B 100.1.1.8 [20/0] via 202.0.0.2, 00:01:19
201.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 201.0.0.0/30 is directly connected, FastEthernet1/0
L 201.0.0.1/32 is directly connected, FastEthernet1/0
202.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 202.0.0.0/30 is directly connected, FastEthernet1/1
L 202.0.0.1/32 is directly connected, FastEthernet1/1
R2#
100.0.0.0/30 is subnetted, 3 subnets
B 100.1.1.0 [20/0] via 202.0.0.2, 00:01:16
B 100.1.1.4 [20/0] via 201.0.0.2, 00:19:18
B 100.1.1.8 [20/0] via 202.0.0.2, 00:01:16
201.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 201.0.0.0/30 is directly connected, FastEthernet1/0
L 201.0.0.1/32 is directly connected, FastEthernet1/0
202.0.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 202.0.0.0/30 is directly connected, FastEthernet1/1
L 202.0.0.1/32 is directly connected, FastEthernet1/1
Это простое, с виду, решение на самом деле открывает приличный простор для комбинирования решений.среда, 16 июля 2014 г.
Cisco syslog и syslog-ng под Debian
Итак, перейдём к одной из самых важных компонент мониторинга и поддержки сетевого периметра вместе с модулями сети. Это логирование сообщений на удалённый хост с cisco с помощью syslog-сервера.
В качестве simple примера который не претендует на оперативность и вообще ответа, т.е. является только частью M от MARC ( не путайте с цисковским MARS)-- решение syslog-ng поднятое под дебиан, 100% дёшево и сердито, а главное работает, но как в тайге.1) Установка и настройка SYSLOG-NG
Как обычно ставим из менеджера пакетов, ибо он входит в стандартный набор.
Вкатываем в конфиг файл по адресу:
/etс/syslog-ng/syslog-ng.conf
Следующую начинку:
Файл для хранения логов
destination d_cisco { file("/var/log/cisco.log"); };Фильтры по критериям
filter f_cisco_info { level(info); };В куда класть
filter f_cisco_notice { level(notice); };
filter f_cisco_warn { level(warn); };
filter f_cisco_crit { level(crit); };
filter f_cisco_err { level(err); };
log { source(net); filter(f_cisco_info); destination(d_cisco); };Источник приёма данных
log { source(net); filter(f_cisco_notice); destination(d_cisco); };
log { source(net); filter(f_cisco_warn); destination(d_cisco); };
log { source(net); filter(f_cisco_crit); destination(d_cisco); };
log { source(net); filter(f_cisco_err); destination(d_cisco); };
source net { udp(ip(0.0.0.0) port(514)); };2) Настройка cisco
Указываем хост логирования, уровень логирования и сервис нумерации сообщений ( на всякий случай)
logging 13.18.10.4 logging trap informational service sequence-numbers
3) Результат
В файле по адресу /var/log/cisco.log благополучно находите свои syslog сообщения свитча/роутера. Всё вроде бы хорошо, но есть одна проблема, сообщения от роутеров будут валиться в одну и ту же малину, что создаст, в конечном итоге, невероятный бардак в этом файле. Как вариант решения можно использовать для каждого роутера разные порты, например, и раскладывать их в разные файлы, с совпадающими номерами портов и номеров файлов в названии, оно опробовано и работает.
Однако, если хочется внедрить хорошее комлексное продакшн решение в плане мониторинга, то у меня осталось очень положительное мнение о PRTG. Установка из коробки, куча разноообразных сенсоров, интуитивно сразу понятный интерфейс, всё необходимое сразу под рукой, графики и сводки выдаёт не запинаясь, единственное -- он платный больше чем за 10 сенсоров. Очень платный. Судя по свежему прайсу просто ахрененно платный.Но, как говорится, кому и буханка хлеба дорого, кому-то и яхта на сдачу. Однако хорошие вещи дешёво не стоят -- тоже факт.
понедельник, 14 июля 2014 г.
Гипотеза чёрной королевы
— У нас, — сказала Алиса, с трудом переводя дух, — когда долго бежишь со всех ног, непременно попадёшь в другое место.
— Какая медлительная страна! — вскричала Королева. — Ну а здесь,
знаешь ли, приходится бежать со всех ног, чтобы только остаться на том
же месте, а чтобы попасть в другое место нужно бежать
вдвое быстрее.
Л. Кэррол.
Увидел сегодня старую побитую проржавевшую тачку, и мне вспомнился один разговор в июне.
Стоят трое человек перед старой, разбитой машиной и думают:
1) Какая рухлядь, фу, ни за что на ней не поеду
2) Пофиг, если едет значит едет, буду ездить
3) Видит перед собой произведение искусства, филигранные формы, отточенные боковые линии спойлеров, логотипы огня по бокам, мощные воздухозаборники, слышит наяву рёв двигателя и затем воплощает это в жизнь.
Сдаётся мне, админы деляться по классам точно так же. Спасибо Тимофей, ты стал моим человеком июня.
Cisco SNMP в связке с Zabbix
Всё руки не доходили сразу затолкать пост после оформления brief. Решил сегодня добить чтобы не глаза не мозолил, а то валяется который год в черновиках. Поднял чистый Zabbix для скриншотов и собрал к нему топологию
Итак Cisco и Zabbix. Без долгих вступлений.
Крайне рекомендую к полному прочтению сначала RFC по SNMP.
Затем вот это
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/12-4t/snmp-12-4t-book.pdf
чтобы понимать общие принципы, кто про что и зачем вообще встал с дивана.
1) Включаем snmp для снятия данных с агента на cisco (stimcom это своеобразный ключ аутентификации, может быть любым, но должен совпадать на zabbix и cisco )
2) Нужно получить OID нужного компонента для снятия данных Zabbix'ом. Поскольку с актуализацией данных по cisco -- это НЕВЕРОЯТНЫЙ бардак, зная первоосновы можно пойти деревянным путём.
Чавкаем запрос с Zabbix тачки в сторону роутера, заодно проверяя, что есть контакт и вторая версия snmp на ней поддерживается корректно.
если лог полетел значит всё хорошо
ждём нужного куска и находим нужный нам элемент
Например ifInOctets.4 на моей циске для снятия скорости передачи данных
или загрузку ЦПУ например можно подставить
.1.3.6.1.4.1.9.2.1.56.0 - загрузка CPU в среднем за за 5 секунд.
.1.3.6.1.4.1.9.2.1.57.0 - загрузка CPU в среднем за за 60 секунд.
.1.3.6.1.4.1.9.2.1.58.0 - загрузка CPU в среднем за 5 минут.
на одних роутерах данные будут верны, на других неверны, копается в этой помойке каждый сам, и ни одна организация порядок навести не хочет, так что хаос торжествует во всей красе.
3) Дальше нам нужно в zabbix , в свойствах hosts составить Item
Затем там же Graphs
И насладиться мега графиком в Monitorings --> Graphs
Итак Cisco и Zabbix. Без долгих вступлений.
Крайне рекомендую к полному прочтению сначала RFC по SNMP.
Затем вот это
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/12-4t/snmp-12-4t-book.pdf
чтобы понимать общие принципы, кто про что и зачем вообще встал с дивана.
1) Включаем snmp для снятия данных с агента на cisco (stimcom это своеобразный ключ аутентификации, может быть любым, но должен совпадать на zabbix и cisco )
Опционально можно сразу включить трапы ( если нужно конечно )snmp-server community stimcom RO
snmp-server enable traps snmp-server host 10.0.2.100 version 2c stimcom
2) Нужно получить OID нужного компонента для снятия данных Zabbix'ом. Поскольку с актуализацией данных по cisco -- это НЕВЕРОЯТНЫЙ бардак, зная первоосновы можно пойти деревянным путём.
Чавкаем запрос с Zabbix тачки в сторону роутера, заодно проверяя, что есть контакт и вторая версия snmp на ней поддерживается корректно.
snmpwalk -v2c -c stimcom 10.0.1.1
если лог полетел значит всё хорошо
ждём нужного куска и находим нужный нам элемент
Например ifInOctets.4 на моей циске для снятия скорости передачи данных
Вторая строчка в ответ на запрос покажет нам искомый OID.zabbix# snmpget -v 2c -On -c stimcom 10.0.2.1 ifInOctets.4 .1.3.6.1.2.1.2.2.1.10.4 = Counter32: 88920305 zabbix#
или загрузку ЦПУ например можно подставить
.1.3.6.1.4.1.9.2.1.56.0 - загрузка CPU в среднем за за 5 секунд.
.1.3.6.1.4.1.9.2.1.57.0 - загрузка CPU в среднем за за 60 секунд.
.1.3.6.1.4.1.9.2.1.58.0 - загрузка CPU в среднем за 5 минут.
на одних роутерах данные будут верны, на других неверны, копается в этой помойке каждый сам, и ни одна организация порядок навести не хочет, так что хаос торжествует во всей красе.
3) Дальше нам нужно в zabbix , в свойствах hosts составить Item
Затем там же Graphs
И насладиться мега графиком в Monitorings --> Graphs
воскресенье, 13 июля 2014 г.
DMVPN DualHUB(Dual_ISP) Spoke1(Dual_ISP)
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_topology.jpg)
Данное продакш решение демонстрирует возможности построения логических модулей и является одним из фундаментальных блоков для решения множества задач. Написано уже давно лично мной без чьей-либо помощи, и является моей привычной средой уровня работы.
Все элементарные-базовые концептуальные решения заимствованы из гугла, и цисковких манов. Спасибо так же более "старшим" неизвестным мне коллегам, у которых можно было увидеть базовые применения по EEM в пределах одного оператора.
Надеюсь, что и мои записи так же помогут неизвестным мне начинающим коллегам.
В данном рассмотрении уделено особое внимание связке HUB1-Spoke1, как выделения его в модуль решения. Всё остальные связки делают по аналогии пользуясь этим же решением или комплектом более простых.
1) Задаём IP адреса на интерфейсы(пропущено) и прописываем маршрутизацию
ПоказатьСкрыть
HUB1
Spoke1
Снимем маршрутизацию с физических интерфейсов в VRF-ы ( в моём концептном решении это было необходимо в силу глобальной задачи, но рассмотрению самой изюминки это не мешает )
ip route 0.0.0.0 0.0.0.0 100.1.1.1 ip route 0.0.0.0 0.0.0.0 100.1.2.1
Spoke1
Снимем маршрутизацию с физических интерфейсов в VRF-ы ( в моём концептном решении это было необходимо в силу глобальной задачи, но рассмотрению самой изюминки это не мешает )
ip vrf R1C1 rd 101:11 ip vrf R2C1 rd 101:12 ip route vrf R1C1 0.0.0.0 0.0.0.0 200.1.1.1 ip route vrf R2C1 0.0.0.0 0.0.0.0 200.1.2.1
2) Настраиваем mGRE и маршрутизацию
ПоказатьСкрыть
HUB1
Spoke1
уже прописано на туннельных интерфейсах
и поднимаем eigrp на HUB и Spoke роутерах
interface Tunnel1 ip address 192.168.101.1 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco711 ip nhrp map multicast dynamic ip nhrp network-id 1 ip tcp adjust-mss 1360 no ip split-horizon eigrp 77 tunnel source FastEthernet2/1 tunnel mode gre multipoint tunnel key 2011 tunnel route-via FastEthernet2/1 mandatory tunnel path-mtu-discovery interface Tunnel2 ip address 192.168.102.1 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco712 ip nhrp map multicast dynamic ip nhrp network-id 2 ip tcp adjust-mss 1360 no ip split-horizon eigrp 77 tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel key 2012 tunnel route-via FastEthernet1/0 mandatory tunnel path-mtu-discovery
Spoke1
interface Tunnel111 ip address 192.168.101.101 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco711 ip nhrp map 192.168.101.1 100.1.1.2 ip nhrp map multicast 100.1.1.2 ip nhrp network-id 1 ip nhrp holdtime 1800 ip nhrp nhs 192.168.101.1 ip nhrp registration no-unique no ip split-horizon eigrp 77 tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel key 2011 tunnel route-via FastEthernet1/0 mandatory tunnel path-mtu-discovery tunnel vrf R1C1 ! interface Tunnel112 ip address 192.168.101.101 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco711 ip nhrp map 192.168.101.1 100.1.1.2 ip nhrp map multicast 100.1.1.2 ip nhrp network-id 1 ip nhrp holdtime 1800 ip nhrp nhs 192.168.101.1 ip nhrp registration no-unique no ip split-horizon eigrp 77 shutdown tunnel source FastEthernet2/1 tunnel mode gre multipoint tunnel key 2011 tunnel route-via FastEthernet2/1 mandatory tunnel path-mtu-discovery tunnel vrf R2C1 ! interface Tunnel121 ip address 192.168.102.101 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco712 ip nhrp map multicast 100.1.2.2 ip nhrp map 192.168.102.1 100.1.2.2 ip nhrp network-id 2 ip nhrp holdtime 1800 ip nhrp nhs 192.168.102.1 ip nhrp registration no-unique no ip split-horizon eigrp 77 shutdown tunnel source FastEthernet1/0 tunnel mode gre multipoint tunnel key 2012 tunnel route-via FastEthernet1/0 mandatory tunnel path-mtu-discovery tunnel vrf R1C1 ! interface Tunnel122 ip address 192.168.102.101 255.255.255.0 no ip redirects ip mtu 1400 no ip next-hop-self eigrp 77 ip nhrp authentication cisco712 ip nhrp map multicast 100.1.2.2 ip nhrp map 192.168.102.1 100.1.2.2 ip nhrp network-id 2 ip nhrp holdtime 1800 ip nhrp nhs 192.168.102.1 ip nhrp registration no-unique no ip split-horizon eigrp 77 shutdown tunnel source FastEthernet2/1 tunnel mode gre multipoint tunnel key 2012 tunnel route-via FastEthernet2/1 mandatory tunnel path-mtu-discovery tunnel vrf R2C1
уже прописано на туннельных интерфейсах
no ip next-hop-self eigrp 77 no ip split-horizon eigrp 77
и поднимаем eigrp на HUB и Spoke роутерах
router eigrp 77 network 10.0.0.0 network 192.168.0.0 0.0.255.255
3) На данном этапе надо решить задачку по экономии трафика подключив логический модуль
ПоказатьСкрыть
Условия и ситуации данной задачи сводятся к решению простого концепта указанного на картинке которую я сделал.
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_concept_of_decision.jpg)
Приоритет использования туннелей в порядке убывания в данных условиях будет такой: Tunnel 111, Tunnel 112, Tunnel 121, Tunnel 122
А так же приведена блок-схема логического модуля.
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_logic_module.jpg)
Приступим к анализу ситуаций и выработке стратегии
Spoke1
а) Задаём SLA и треки следящие за SLA
б) Задаём stub-треки для снятия информации о текущем состоянии SLA
в) Задаём stub-треки для снятия информации о текущем состоянии Tunnel интерфейсов
г) Прописываем обработку срабатываний SLA-Track в STUB-Track и старт основного логического блока
д) Создаём основной логический блок (Central Office 1 Service Logic Tunnels)
Срабатывает на изменение STUB-Track'ов принудительно через run
action 110-141 -- считываем данные с STUB-Track'ов из SLA в переменные $_track_state_1ХХ
action 150-181 -- считываем данные с STUB-Track'ов из Tunnel в переменные $_track_state_1ХХ
action 201-215 -- Вывод данных в лог для визуализации
action 301-399 -- Логический блок
Приоритет использования туннелей в порядке убывания в данных условиях будет такой: Tunnel 111, Tunnel 112, Tunnel 121, Tunnel 122
А так же приведена блок-схема логического модуля.
Приступим к анализу ситуаций и выработке стратегии
Spoke1
а) Задаём SLA и треки следящие за SLA
ip sla 111 icmp-echo 100.1.1.2 source-interface FastEthernet1/0 vrf R1C1 threshold 3 timeout 2000 frequency 5 ip sla schedule 111 life forever start-time now track 111 ip sla 111 reachability delay down 10 up 20 ip sla 112 icmp-echo 100.1.1.2 source-interface FastEthernet2/1 vrf R2C1 threshold 3 timeout 2000 frequency 5 ip sla schedule 112 life forever start-time now track 112 ip sla 112 reachability delay down 15 up 25 ip sla 121 icmp-echo 100.1.2.2 source-interface FastEthernet1/0 vrf R1C1 threshold 3 timeout 2000 frequency 5 ip sla schedule 121 life forever start-time now track 121 ip sla 121 reachability delay down 20 up 30 ip sla 122 icmp-echo 100.1.2.2 source-interface FastEthernet2/1 vrf R2C1 threshold 3 timeout 2000 frequency 5 ip sla schedule 122 life forever start-time now track 122 ip sla 122 reachability delay down 25 up 35
б) Задаём stub-треки для снятия информации о текущем состоянии SLA
track 911 stub-object default-state down track 912 stub-object default-state down track 921 stub-object default-state down track 922 stub-object default-state down
в) Задаём stub-треки для снятия информации о текущем состоянии Tunnel интерфейсов
track 811 stub-object default-state down track 812 stub-object default-state down track 821 stub-object default-state down track 822 stub-object default-state down
г) Прописываем обработку срабатываний SLA-Track в STUB-Track и старт основного логического блока
event manager applet TRACK111UP event track 111 state up action 100 track set 911 state up action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK111DOWN event track 111 state down action 100 track set 911 state down action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK112UP event track 112 state up action 100 track set 912 state up action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK112DOWN event track 112 state down action 100 track set 912 state down action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK121UP event track 121 state up action 100 track set 921 state up action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK121DOWN event track 121 state down action 100 track set 921 state down action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK122UP event track 122 state up action 100 track set 922 state up action 101 cli command "enable" action 102 cli command "event manager run CO1SLT" event manager applet TRACK122DOWN event track 122 state down action 100 track set 922 state down action 101 cli command "enable" action 102 cli command "event manager run CO1SLT"
д) Создаём основной логический блок (Central Office 1 Service Logic Tunnels)
Срабатывает на изменение STUB-Track'ов принудительно через run
action 110-141 -- считываем данные с STUB-Track'ов из SLA в переменные $_track_state_1ХХ
action 150-181 -- считываем данные с STUB-Track'ов из Tunnel в переменные $_track_state_1ХХ
action 201-215 -- Вывод данных в лог для визуализации
action 301-399 -- Логический блок
event manager applet CO1SLT
event none
action 110 track read 911
action 111 set track_state_911 "$_track_state"
action 120 track read 912
action 121 set track_state_912 "$_track_state"
action 130 track read 921
action 131 set track_state_921 "$_track_state"
action 140 track read 922
action 141 set track_state_922 "$_track_state"
action 150 track read 811
action 151 set track_state_811 "$_track_state"
action 160 track read 812
action 161 set track_state_812 "$_track_state"
action 170 track read 821
action 171 set track_state_821 "$_track_state"
action 180 track read 822
action 181 set track_state_822 "$_track_state"
action 201 syslog msg "======================================================"
action 202 syslog msg "--- Central Office 1 Service Logic Tunnels started ---"
action 203 set eq_up "up"
action 204 set eq_down "down"
action 207 syslog msg "Status track911 is $track_state_911"
action 208 syslog msg "Status track912 is $track_state_912"
action 209 syslog msg "Status track921 is $track_state_921"
action 210 syslog msg "Status track922 is $track_state_922"
action 211 syslog msg "Status track811 is $track_state_811"
action 212 syslog msg "Status track812 is $track_state_812"
action 213 syslog msg "Status track821 is $track_state_821"
action 214 syslog msg "Status track822 is $track_state_822"
action 215 syslog msg "------------------------------------------------------"
action 301 if $track_state_911 eq $eq_up
action 301.0 syslog msg "Logical module CO1SLT: Track911-UP-confirmed"
action 301.1 if $track_state_911 ne $track_state_811
action 301.1.0 syslog msg "Logical module CO1SLT: Track911 ne Track811 confirmed. Tunnel 111 must be UPPED"
action 301.1.11 cli command "enable"
action 301.1.12 cli command "configure terminal"
action 301.1.13 cli command "interface range tunnel 111-112, tunnel 121-122"
action 301.1.14 cli command "shutdown"
action 301.1.15 track set 811 state down
action 301.1.16 track set 812 state down
action 301.1.17 track set 821 state down
action 301.1.18 track set 822 state down
action 301.1.21 cli command "do clear crypto isa"
action 301.1.22 cli command "do clear crypto sa"
action 301.1.23 wait 1
action 301.1.31 cli command "interface tunnel 111"
action 301.1.31a cli command "no ip add"
action 301.1.31b cli command "ip add 192.168.101.101 255.255.255.0"
action 301.1.32 cli command "no shutdown"
action 301.1.41 track set 811 state up
action 301.1.98 syslog msg "Logical module CO1SLT: Operation to UP the Tunnel 111 completed. Track811 --> UP. Exit 301.1.99"
action 301.1.98a syslog msg "======================================================"
action 301.1.99 exit 301.1.99_Normal_Exit
action 301.2 else
action 301.2.1 syslog msg "Logical module CO1SLT: Current optimal Tunnel 111. And he already UP. Exit 301.2.2"
action 301.2.1a syslog msg "======================================================"
action 301.2.2 exit 301.2.2_Normal_Exit
action 301.3 end
action 302 else
action 303 if $track_state_912 eq $eq_up
action 303.0 syslog msg "Logical module CO1SLT: Track912-UP-confirmed"
action 303.1 if $track_state_912 ne $track_state_812
action 303.1.0 syslog msg "Logical module CO1SLT: Track912 ne Track812 confirmed. Tunnel 112 must be UPPED"
action 303.1.11 cli command "enable"
action 303.1.12 cli command "configure terminal"
action 303.1.13 cli command "interface range tunnel 111-112, tunnel 121-122"
action 303.1.14 cli command "shutdown"
action 303.1.15 track set 811 state down
action 303.1.16 track set 812 state down
action 303.1.17 track set 821 state down
action 303.1.18 track set 822 state down
action 303.1.21 cli command "do clear crypto isa"
action 303.1.22 cli command "do clear crypto sa"
action 303.1.23 wait 1
action 303.1.31 cli command "interface tunnel 112"
action 303.1.31a cli command "no ip add"
action 303.1.31b cli command "ip add 192.168.101.101 255.255.255.0"
action 303.1.32 cli command "no shutdown"
action 303.1.41 track set 812 state up
action 303.1.98 syslog msg "Logical module CO1SLT: Operation to UP the Tunnel 112 completed. Track812 --> UP. Exit 303.1.99"
action 303.1.98a syslog msg "======================================================"
action 303.1.99 exit 303.1.99_Normal_Exit
action 303.2 else
action 303.2.1 syslog msg "Logical module CO1SLT: Current optimal Tunnel 112. And he already UP. Exit 303.2.2"
action 303.2.1a syslog msg "======================================================"
action 303.2.2 exit 303.2.2_Normal_Exit
action 303.3 end
action 304 else
action 305 if $track_state_921 eq $eq_up
action 305.0 syslog msg "Logical module CO1SLT: Track921-UP-confirmed"
action 305.1 if $track_state_921 ne $track_state_821
action 305.1.0 syslog msg "Logical module CO1SLT: Track921 ne Track821 confirmed. Tunnel 121 must be UPPED"
action 305.1.11 cli command "enable"
action 305.1.12 cli command "configure terminal"
action 305.1.13 cli command "interface range tunnel 111-112, tunnel 121-122"
action 305.1.14 cli command "shutdown"
action 305.1.15 track set 811 state down
action 305.1.16 track set 812 state down
action 305.1.17 track set 821 state down
action 305.1.18 track set 822 state down
action 305.1.21 cli command "do clear crypto isa"
action 305.1.22 cli command "do clear crypto sa"
action 305.1.23 wait 1
action 305.1.31 cli command "interface tunnel 121"
action 305.1.31a cli command "no ip add"
action 305.1.31b cli command "ip add 192.168.102.101 255.255.255.0"
action 305.1.32 cli command "no shutdown"
action 305.1.41 track set 821 state up
action 305.1.98 syslog msg "Logical module CO1SLT: Operation to UP the Tunnel 121 completed. Track821 --> UP. Exit 305.1.99"
action 305.1.98a syslog msg "======================================================"
action 305.1.99 exit 305.1.99_Normal_Exit
action 305.2 else
action 305.2.1 syslog msg "Logical module CO1SLT: Current optimal Tunnel 121. And he already UP. Exit 305.2.2"
action 305.2.1a syslog msg "======================================================"
action 305.2.2 exit 305.2.2_Normal_Exit
action 305.3 end
action 306 else
action 307 if $track_state_922 eq $eq_up
action 307.0 syslog msg "Logical module CO1SLT: Track922-UP-confirmed"
action 307.1 if $track_state_922 ne $track_state_822
action 307.1.0 syslog msg "Logical module CO1SLT: Track922 ne Track822 confirmed. Tunnel 122 must be UPPED"
action 307.1.11 cli command "enable"
action 307.1.12 cli command "configure terminal"
action 307.1.13 cli command "interface range tunnel 111-112, tunnel 121-122"
action 307.1.14 cli command "shutdown"
action 307.1.15 track set 811 state down
action 307.1.16 track set 812 state down
action 307.1.17 track set 821 state down
action 307.1.18 track set 822 state down
action 307.1.21 cli command "do clear crypto isa"
action 307.1.22 cli command "do clear crypto sa"
action 307.1.23 wait 1
action 307.1.31 cli command "interface tunnel 122"
action 307.1.31a cli command "no ip add"
action 307.1.31b cli command "ip add 192.168.102.101 255.255.255.0"
action 307.1.32 cli command "no shutdown"
action 307.1.41 track set 822 state up
action 307.1.98 syslog msg "Logical module CO1SLT: Operation to UP the Tunnel 122 completed. Track822 --> UP. Exit 307.1.99"
action 307.1.98a syslog msg "======================================================"
action 307.1.99 exit 307.1.99_Normal_Exit
action 307.2 else
action 307.2.1 syslog msg "Logical module CO1SLT: Current optimal Tunnel 122. And he already UP. Exit 307.2.2"
action 307.2.1a syslog msg "======================================================"
action 307.2.2 exit 307.2.2_Normal_Exit
action 307.3 end
action 308 else
action 309.10 syslog msg "Logical module CO1SLT: WARNING ALL PROVIDERS ARE DOWN. Administrator has been notified. Type of communication: SMS."
action 301.10.a syslog msg "======================================================"
action 309.11 cli command "enable"
action 309.12 cli command "configure terminal"
action 309.13 cli command "interface range tunnel 111-112, tunnel 121-122"
action 309.14 cli command "shutdown"
action 309.15 track set 811 state down
action 309.16 track set 812 state down
action 309.17 track set 821 state down
action 309.18 track set 822 state down
action 309.19 cli command "do clear crypto isa"
action 309.20 cli command "do clear crypto sa"
action 396 end
action 397 end
action 398 end
action 399 end
4) И дошлифуем шифрованием
ПоказатьСкрыть
HUB1
а) Создаём две ключницы -- по одной на каждое облако и строго определяем интерфейс использования
б) Создаём политику служебного туннеля ( можно создать и два, если это требует регламент безопасности )
в) Создаём профиль isakmp для создания служебного тоннеля, по одному на каждое облако
г) Задаём трансформу-шифрование основного туннеля
д) Создаём профили ipsec на каждое облако
е) И променяем профили к тоннелям
------------------------------------------- Spoke1
а) Создаём две ключницы -- по одной на каждое облако и строго определяем интерфейс использования
б) Создаём политику служебного туннеля ( можно создать и два, если это требует регламент безопасности )
в) Создаём профиль isakmp для создания служебного тоннеля, по одному на каждый туннель
г) Задаём трансформу-шифрование основного туннеля
д) Создаём профили ipsec на каждый туннель
е) И променяем профили к тоннелям
а) Создаём две ключницы -- по одной на каждое облако и строго определяем интерфейс использования
crypto keyring DMVPN-CLOUD1 local-address fa 2/1 pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 crypto keyring DMVPN-CLOUD2 local-address fa 1/0 pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
б) Создаём политику служебного туннеля ( можно создать и два, если это требует регламент безопасности )
crypto isakmp policy 10 encryption 3des authentication pre-share group 2
в) Создаём профиль isakmp для создания служебного тоннеля, по одному на каждое облако
crypto isakmp profile DMVPN-CLOUD1 keyring DMVPN-CLOUD1 match identity address 0.0.0.0 local-address fa 2/1 crypto isakmp profile DMVPN-CLOUD2 keyring DMVPN-CLOUD2 match identity address 0.0.0.0 local-address fa 1/0
г) Задаём трансформу-шифрование основного туннеля
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
д) Создаём профили ipsec на каждое облако
crypto ipsec profile DMVPN-CLOUD1 set transform-set ESP-DES-MD5-HMAC set isakmp-profile DMVPN-CLOUD1 crypto ipsec profile DMVPN-CLOUD2 set transform-set ESP-DES-MD5-HMAC set isakmp-profile DMVPN-CLOUD2
е) И променяем профили к тоннелям
interface Tunnel 1 tunnel protection ipsec profile DMVPN-CLOUD1 interface Tunnel 2 tunnel protection ipsec profile DMVPN-CLOUD2
------------------------------------------- Spoke1
а) Создаём две ключницы -- по одной на каждое облако и строго определяем интерфейс использования
crypto keyring D-CLOUD1 vrf R1C1 pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 crypto keyring D-CLOUD2 vrf R2C1 pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123
б) Создаём политику служебного туннеля ( можно создать и два, если это требует регламент безопасности )
crypto isakmp policy 10 encryption 3des authentication pre-share group 2
в) Создаём профиль isakmp для создания служебного тоннеля, по одному на каждый туннель
crypto isakmp profile D-CLOUD11 vrf R1C1 keyring D-CLOUD1 match identity address 0.0.0.0 R1C1 local-address fa 1/0 crypto isakmp profile D-CLOUD12 vrf R2C1 keyring D-CLOUD2 match identity address 0.0.0.0 R2C1 local-address fa 2/1 crypto isakmp profile D-CLOUD21 vrf R1C1 keyring D-CLOUD1 match identity address 0.0.0.0 R1C1 local-address fa 1/0 crypto isakmp profile D-CLOUD22 vrf R2C1 keyring D-CLOUD2 match identity address 0.0.0.0 R2C1 local-address fa 2/1
г) Задаём трансформу-шифрование основного туннеля
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
д) Создаём профили ipsec на каждый туннель
crypto ipsec profile D-CLOUD11 set transform-set ESP-DES-MD5-HMAC set isakmp-profile D-CLOUD11 crypto ipsec profile D-CLOUD12 set transform-set ESP-DES-MD5-HMAC set isakmp-profile D-CLOUD12 crypto ipsec profile D-CLOUD21 set transform-set ESP-DES-MD5-HMAC set isakmp-profile D-CLOUD21 crypto ipsec profile D-CLOUD22 set transform-set ESP-DES-MD5-HMAC set isakmp-profile D-CLOUD22
е) И променяем профили к тоннелям
interface Tunnel 111 tunnel protection ipsec profile D-CLOUD11 interface Tunnel 112 tunnel protection ipsec profile D-CLOUD12 interface Tunnel 121 tunnel protection ipsec profile D-CLOUD21 interface Tunnel 122 tunnel protection ipsec profile D-CLOUD22
5) "Пилите, Шура, пилите! Они золотые!"
ПоказатьСкрыть
В продакшне при внедрении выловлено немало косяков, главная трудность в том что железка имеет свойство:
а) Перезагружаться при потере питания, значит внедрённое решение должно быть саморегулирущимся.
б) Поскольку конфиги меняются и сохраняются в процессе работы, то могут сохраниться и поднятые туннели и прочее атрибуты решения
Значит внедрённое решение должно быть саморегулирущимся из любой точки и из любого состояния
Пункты 1 и 2 в сумме налагают приличное количество ограничений на конструирование. Рабочее решение я подобрал только на 8-мом варианте переписывания, меняя как идеи с концептами, так и общесистемную логику.
Например был выловлен такой косяк на поднятых туннелях при загрузке циски, крайне неприятное сообщение:
% 192.168.101.0 overlaps with Tunnel111 % 192.168.102.0 overlaps with Tunnel121
после чего ip адреса пропадут с опущенных туннелей в избежании Overlaps.
action 30Х.1.31a,b решают эту проблему.
Так же это решение не будет работать, если не решить вопрос маршрутизации на HUB1 потому что, sla 22 будет всегда проседать из-за роутинга, решается простым применнием концептного модуля ip sla (искать по метке).
Кстати ip sla модуль был описан как раз составляющий элемент данного решения.
И конечно в каждом внедрении нужно чётко шлифовать таймеры в зависимости от нагрузки на железку. Словом масса нюансов в каждом конкретном случае будет иметь место быть. Но все они решаемы.
Подписаться на:
Сообщения (Atom)