Дано: базовая топология для рассмотрения концепта работы 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 адреса на интерфейсы(пропущено) и прописываем маршрутизацию
ПоказатьСкрыть
2) Настраиваем mGRE и маршрутизацию
ПоказатьСкрыть
3) На данном этапе надо решить задачку по экономии трафика подключив логический модуль
ПоказатьСкрыть
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_concept_of_decision.jpg)
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_logic_module.jpg)
4) И дошлифуем шифрованием
ПоказатьСкрыть
5) "Пилите, Шура, пилите! Они золотые!"
ПоказатьСкрыть
пятница, 27 июня 2014 г.
VRF Basic Example
VRF на данный момент не является широко документированным и полно разобранным материалом. К тому же полносвязно и доходчиво он рассматривается и понимается -- как механизм в MPLS в курсе CCIE. Однако для "зашедших на огонёк" тут есть немного мат части.
Virtual Routing and Forwarding (VRF) -- технология позволяющая создать несколько виртуальных маршрутизаторов на одной железке, каждый со своей таблицей маршрутизации. Каждый VRF состоит из трёх основных компонентов:
1) RIB ( Routing Information Base ) -- таблицы маршрутизации
2) CEF FIB ( Forwarding Information Base ), заполненной на основании RIB этой VRF ( если включен CEF)
3) Отдельной instance или процесса протокола маршрутизации, который используется для обмена маршрутами с CE, которые должны поддерживаться этой VRF. Графический разворот трёх пунктов дан на картинке вначале. Стоит учесть, что он сильно упрощён только под данный пример.
Дано: В нашем случае рассмотрим пример взаимодействия PE (Provider Edge) и нескольких клиентов (CE - Client Edge)
Задача: создать для них 3 виртуальных таблицы маршрутизации типа VRF, при этом подсети и адреса клиентов будут идеентичны.
четверг, 26 июня 2014 г.
DMVPN addons
(Опционально) Настройка аутентификации:
Router(config-if)#ip nhrp authentication nhrppass
----------------------------------
(Опционально) Настройка флага неуникальности ip-адреса туннеля в базе nhrp на hub-маршрутизаторе:
Spoke(config-if)#ip nhrp registration no-unique
Если изменится внешний адрес spoke-маршрутизатора и этой команды не будет, то hub-маршрутизатор не обновит свою базу nhrp из-за ошибки: unique address registered already
----------------------------------
(Опционально) Настройка holdtime:
Spoke(config-if)#ip nhrp holdtime 222
Дефолтное значение 2 часа. По ситуации рекомендую уменьшать до 30 минут.Tunnel2 created 00:00:02, expire 01:59:57
воскресенье, 22 июня 2014 г.
DMVPN HUB1(DualISP) SPOKE1(DualISP) SPOKE2(SingleISP)
_SPOKE1(DualISP)_SPOKE2_(SingleISP)_example1.jpg)
Дано:
Блок одной из классических схем организации DMVPN типа HUB-and-SPOKE,
R20 -- HUB с двумя провайдерами
R21 и R22 -- SPOKE маршрутизаторы с двумя и одним провайдерами соответственно
Все линки на провайдеров даны типа default-gateway
R2...R11 -- имитируют интернет, типа OSPF area 0 процесс 77
Задача:
Построить DMVPN, типа mGRE с шифрацией трафика типа IPSec.
Динамической маршрутизацией типа EIGRP.
Свободный обмен данными между хостами xp_http_ftp_cisco, xp_http_ftp_cisco1, xp_http_ftp_cisco2 (здесь проверен icmp, http и ftp трафик)
вторник, 17 июня 2014 г.
DMVPN Basic Example
Дано:
Классическая схема DMVPN -- HUB and SPOKE
R1 -- центральный офис и логический HUB
R3, R4 -- региональные офисы логические SPOKE
R2 -- имитация интернет, с маршрутизацией типа OSPF 77
Loopback интерфейсы прописываются для упрощённой настройки OSPF (RouterID)
Схема упрощена до базового концепта DMVPN типа HUB-SPOKE,
т.е. у филиалов присутствуют белые IP и отсутствует NAT
каждая логическая единица схемы имеет только одного провайдера
вместо BGP используется OSPF ( как вариант можно было бы ещё упростить до default-gateway )
Задача:
Настроить DMVPN типа point-to-multipoint с поддержкой логических mGRE тоннелей с поддержкой шифрования IPSec
Настроить днамическую маршрутизацию между ними объединяя их в одну логическую сеть
Создать эту систему таким образом чтобы добавление нового SPOKE узла требовало настройки только с его стороны
суббота, 14 июня 2014 г.
OSPF accross multi area
Дано: Картинка немножко корявая, потому что служила для другого проекта, но смысл примерно такой логическая цепочка выглядит так:
R2[AREA 0,10] --- (( R3[AREA 10,20] --- R1[AREA 10,30] )) --- R4[AREA 20,30]
Задача: Настроить маршрутизацию так, чтобы хост [xp_http_ftp_cisco_2] мог общаться с [xp_http_ftp_cisco] в частности, и любым хостом в инфраструктуре в общем и целом. Соответственно, каждый роутер должен иметь в таблице маршрутизации живой путь до зоны backbone-area0 и обратно.
четверг, 12 июня 2014 г.
IP SLA
HOST1 имитирует внутреннюю сеть
HOST2 имитирует интернет хост
R1 имитирует пограничный маршрутизатор с двумя линками на провайдера ( F0/1 и F1/0 )
R2 - R4 имитирут интернет
Задача: Обеспечить хождение трафика по дефолту через ISP1. В случае падения линка или пропадания сервиса переключится на ISP2. Всё это должно происходить автоматически без ручной перенастройки.
среда, 11 июня 2014 г.
понедельник, 9 июня 2014 г.
Diffie-Hellman
Демонстрация работы обмена ключами Diffie-Hellman
Хорошая картинка и сразу под рукой :)
Хорошая картинка и сразу под рукой :)
MARC. NetFlow.
Кратко об общем или что нужно видеть не вставая с дивана.
Для начала нужно понимать, что мониторинг сетей – штука довольно щепетильная и тонкая, и внедрить её в уже работающий проект, не спроектированный с учётом требований и возможностей мониторинга является очень затратной статьей расходов, которая далеко не всегда может, в конечном итоге, удовлетворить требованиям заказчика. Зачастую, потребность в мониторинге появляется у довольно прилично разросшейся инфраструктуры, и потом начинаются танцы с бубном в борьбе за рациональный бюджет и максимальную эффективность сбора данных.
Поэтому best practice является планирование и внедрение мониторинга на стадии проектирования и продажи её вместе с проектом.
NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.
Архитектура системы строится на сенсоре, коллекторе и анализаторе:
Для начала нужно понимать, что мониторинг сетей – штука довольно щепетильная и тонкая, и внедрить её в уже работающий проект, не спроектированный с учётом требований и возможностей мониторинга является очень затратной статьей расходов, которая далеко не всегда может, в конечном итоге, удовлетворить требованиям заказчика. Зачастую, потребность в мониторинге появляется у довольно прилично разросшейся инфраструктуры, и потом начинаются танцы с бубном в борьбе за рациональный бюджет и максимальную эффективность сбора данных.
Поэтому best practice является планирование и внедрение мониторинга на стадии проектирования и продажи её вместе с проектом.
NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.
Архитектура системы строится на сенсоре, коллекторе и анализаторе:
SCTP Stream Control Transmission Protocol
Прекрасная статья на wiki
http://ru.wikipedia.org/wiki/SCTP
На мой взгляд просто очень вкусный протокол
Несколько вкусностей сразу
Протокол SCTP защищен от DoS с помощью механизма четырёхэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.
Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.
В протоколе TCP возможна ситуация частичного закрытия соединения, когда один узел закончил передачу данных (выполнив посылку пакета FIN), но продолжает принимать данные по этому соединению. Другой узел может продолжать передавать данные до тех пор, пока сам не проведёт закрытие соединения на своей стороне. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.
Достоинства использования SCTP включают в себя:
Протокол TCP предоставляет основные средства для передачи данных по сети Internet по надежному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:
http://ru.wikipedia.org/wiki/SCTP
На мой взгляд просто очень вкусный протокол
Несколько вкусностей сразу
Протокол SCTP защищен от DoS с помощью механизма четырёхэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.
Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.
В протоколе TCP возможна ситуация частичного закрытия соединения, когда один узел закончил передачу данных (выполнив посылку пакета FIN), но продолжает принимать данные по этому соединению. Другой узел может продолжать передавать данные до тех пор, пока сам не проведёт закрытие соединения на своей стороне. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.
Достоинства использования SCTP включают в себя:
- Использование множественных интерфейсов (англ Multihoming)
Допустим, у нас есть два хоста. И хотя бы один из них имеет несколько сетевых интерфейсов, и соответственно несколько IP-адресов. В TCP, понятие «соединение» означает обмен данными между двумя точками, в то время, как в SCTP имеет место концепция «ассоциации» (англ. association), обозначащая всё происходящее между двумя хостами
- Многопоточность
Данные приходят в точку по независимым потокам. Это позволяет устранить феномен en:Head-of-line blocking, которым так страдает TCP - Поиск пути с мониторингом
Протоколом выбирается первичный маршрут передачи данных, а также производится проверка и мониторинг связности пути. - Механизмы валидации и проверки подлинности
Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках. - Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в Ethernet.
Протокол TCP предоставляет основные средства для передачи данных по сети Internet по надежному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:
- TCP предоставляет надежную передачу данных в строгой последовательности. Тем не менее одни приложения требуют передачу без управления и контроля последовательности, а другие будут вполне удовлетворены частичной упорядоченностью данных. Оба этих случая страдают из-за ненужных задержек, связанных с восстановлением и упорядочиванием нарушенных последовательностей TCP.
- Природа TCP ориентирована на поток байт, что вызывает неудобства. Приложения вынуждены самостоятельно добавлять собственные маркеры в пакеты, чтобы распараллелить передачу собственных сообщений, а также использовать дополнительные ухищрения, чтобы убедиться в том, что целое сообщение было доставлено за определенное время.
- Ограниченные рамки возможностей TCP-сокетов ещё более усложняют задачу предоставления возможности параллельной передачи информации к хостам по нескольким каналам связи (см. multi-homing выше).
- TCP относительно уязвим к атакам класса «Отказ в обслуживании» (DoS), таким как SYN-flood.
понедельник, 26 мая 2014 г.
QoS рабочие заметки
http://xgu.ru/wiki/QoS_в_Cisco
Тоже есть парочка интересных моментов. Увлекательно.
Тоже есть парочка интересных моментов. Увлекательно.
суббота, 24 мая 2014 г.
QoS кратко и доходчиво
Существует три модели реализации QoS: наилучшая возможная; интегральная и дифференцированная. Наилучший возможный вид услуг реализуется в сети, когда делается все возможное для доставки пакета, но при этом ничего не гарантируется (например FTP или HTTP). Интегрированный вид услуг (RFC-1633, 1994 год) разрабатывался первым и реализуется путем резервирования по схеме точка-точка (протокол RSVP; 1997; см. book.itep.ru/4/44/rsv_4496.htm). Протокол RSVP предоставляет сигнальный механизм для конфигурирования удаленных маршрутизаторов с целью получения нужного QoS. Протокол ориентирован на работу с тремя видами трафика: best efforts (обычная передача IP-данных без установления соединения), чувствительный к скорости передачи и чувствительный к задержкам.Трафик чувствительный к загрузке требует формирования канала с гарантированной пропускной способностью. Приложение при этом вынуждено мириться с определенными задержками доставки (класс услуг с гарантированной скоростью в битах в сек). Третий вид трафика (чувствительный к задержкам) гарантирует минимальную задержку и низкую дисперсию времени доставки. Пропускная способность может при этом варьироваться. Примером такого вида трафика может служить передача голоса или видео. RSVP определяет два типа услуг для этого вида трафика: сервис с контролируемыми задержками и предсказуемый сервис (для приложений реального времени (видео-конференции и телефонные переговоры).
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
В рамках протокола стандартизованы схемы обработки очередей WFQ (Weighted Fair Queuing) и WRED (Weighted Random Early Detection). В CISCO IOS по умолчанию используется WFQ (для каналов Е1 = 2028 кбит/с или медленнее). Intserv предлагает на L3 тот же уровень услуг, что можно получить в АТМ на уровне L2. В АТМ определены 4 QoS класса:
- QoS Class 1 (называемый также классом услуг А) имеет те же характеристики, что и выделенный цифровой канал точка-точка
- QoS Class 2 (называемый также классом услуг В) обеспечивает режим, приемлемый для аудио и видео при видеоконференициях или передачи мультимедиа
- QoS Class 3 (называемый также классом услуг 3) обеспечивает режим, приемлемый для передачи, ориентированной на соединение, например, через посредство frame relay.
- QoS Class 4 (называемый также классом услуг 4) эквивалентен режиму IP-передачи в условиях наилучших усилий (best efforts) при отсутствии гарантии доставки.
четверг, 22 мая 2014 г.
среда, 21 мая 2014 г.
вторник, 20 мая 2014 г.
GRE over IPsec
Задача: Необходимо поднять GRE туннель между офисами R5 и R4 и зашифровать его с помощью IPSec (т.н. GRE over IPSec ). Через GRE туннель должна работать маршрутизация типа EIGRP обеспечивая роутинг между локальными сетями офисов через GRE туннель.
Условимся, что EIGRP AS1 у нас имитирует интернет. Вначале настраиваем IP адреса на интерфейсах и EIGRP AS1 маршрутизацию, чтобы приступить к конфигурированию тоннеля.
1) Настраиваем дефолтный маршрут в сторону "провайдера"
R5(config)#ip route 0.0.0.0 0.0.0.0 211.181.24.51
R4(config)#ip route 0.0.0.0 0.0.0.0 211.181.25.112
2) Конфигурируем GRE туннель
-----------------------------
R5(config)#interface Tunnel0
*Mar 1 00:01:47.799: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R5(config-if)#ip address 10.0.100.1 255.255.255.0
R5(config-if)#tunnel source fastEthernet 0/0
R5(config-if)#tunnel destination 211.181.25.221
R5(config-if)#
*Mar 1 00:02:48.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R5(config-if)#exit
-----------------------------
R4(config)#int Tunnel0
*Mar 1 00:03:24.595: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R4(config-if)#ip address 10.0.100.2 255.255.255.0
R4(config-if)#tunnel source fastEthernet 0/0
R4(config-if)#tunnel destination 211.181.24.15
R4(config-if)#
*Mar 1 00:04:11.403: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R4(config-if)#exit
-----------------------------
Пингуем и проверяем, что маршрутизация не хромает и нигде не ошиблись в базовой настройке
R4(config)#do ping 10.0.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/68 ms
R4(config)#
3) Расписываем маршрутизацию EIGRP AS2 на LAN и Туннель
-----------------------------
R5(config)#router eigrp 2
R5(config-router)#no au
R5(config-router)#no auto-summary
R5(config-router)#net
R5(config-router)#network 10.0.100.1 0.0.0.255
R5(config-router)#net
R5(config-router)#network 10.0.1.254 0.0.0.255
R5(config-router)#exit
R5(config)#
*Mar 1 00:20:28.251: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.2 (Tunnel0) is up: new adjacency
R5(config)#
-----------------------------
R4(config)#router eigrp 2
R4(config-router)#no au
R4(config-router)#no auto-summary
R4(config-router)#net
R4(config-router)#network 10.0.100.2 0.0.0.255
R4(config-router)#net
R4(config-router)#network
*Mar 1 00:20:18.731: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is up: new adjacency
R4(config-router)#network 10.0.2.254 0.0.0.255
R4(config-router)#exit
-----------------------------
Проверяем что все настроено правильно и маршрутизация работает
R4(config)#do sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 211.181.25.112 to network 0.0.0.0
C 211.181.25.0/24 is directly connected, FastEthernet0/0
D 211.181.24.0/24 [90/30720] via 211.181.25.112, 00:20:39, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.2.0 is directly connected, FastEthernet0/1
D 10.0.1.0 [90/297246976] via 10.0.100.1, 00:00:30, Tunnel0
C 10.0.100.0 is directly connected, Tunnel0
S* 0.0.0.0/0 [1/0] via 211.181.25.112
R4(config)#
4) Сконфигурируем ISAKMP
а) Политики
-----------------------------
R5(config)#crypto isakmp enable
R5(config)#crypto isakmp policy 10
R5(config-isakmp)#authentication pre-share
R5(config-isakmp)#encryption des
R5(config-isakmp)#group 2
R5(config-isakmp)#hash sha
R5(config-isakmp)#lifetime 86400
R5(config-isakmp)#exit
-----------------------------
R4(config)#crypto isakmp enable
R4(config)#crypto isakmp policy 10
R4(config-isakmp)#authentication pre-share
R4(config-isakmp)#encryption des
R4(config-isakmp)#group 2
R4(config-isakmp)#hash sha
R4(config-isakmp)#lifetime 86400
R4(config-isakmp)#exit
б) ключи
-----------------------------
R5(config)#crypto isakmp key 0 cisco111 address 211.181.25.221
-----------------------------
R4(config)#crypto isakmp key 0 cisco111 address 211.181.24.15
-----------------------------
5) Задаём трансформу ( вид шифрования трафика в туннеле )
R5(config)#crypto ipsec transform-set CryptoTransformTunnel esp-aes 128
R5(cfg-crypto-trans)#exit
-----------------------------
R4(config)#crypto ipsec transform-set CryptoTransformTunnel esp-aes 128
R4(cfg-crypto-trans)#exit
6) Задаём ACL (карту совпадения) согласно которому будет шифроваться трафик
-----------------------------
R5(config)#access-list 101 permit gre host 211.181.24.15 host 211.181.25.221
-----------------------------
R4(config)#access-list 101 permit gre host 211.181.25.221 host 211.181.24.15
7) Создаём Crypto-Map и применяем на интерфейс
-----------------------------
R5(config)#crypto map MapOffice 5 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R5(config-crypto-map)#match address 101
R5(config-crypto-map)#set peer 211.181.25.221
R5(config-crypto-map)#set transform-set CryptoTransformTunnel
R5(config-crypto-map)#set pfs group1
R5(config-crypto-map)#set security-association lifetime seconds 86400
R5(config-crypto-map)#exit
R5(config)#int fa 0/0
R5(config-if)#crypt
R5(config-if)#crypto map MapOffice
R5(config-if)#
-----------------------------
ISAKMP включился -- настроен потенциально верно
*Mar 1 07:55:24.074: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R5(config-if)#
-----------------------------
Регистрация события -- получен не IPSec
*Mar 1 07:55:25.158: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /211.181.24.15, src_addr= 211.181.25.221, prot= 47
R5(config-if)#
-----------------------------
GRE туннель опущен из-за несовместимости IPSec на концах туннеля
*Mar 1 07:55:35.226: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.2 (Tunnel0) is down: holding time expired
R5(config-if)#exit
R5(config)#do ping 10.0.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5(config-if)#
*Mar 1 07:56:29.770: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /211.181.24.15, src_addr= 211.181.25.221, prot= 47
R5(config-if)#
-----------------------------
Теперь настраиваем IPSec с другой стороны
Прогнозируемый результат:
-- установление IPSec туннеля
-- повторное автоматическое поднятие GRE туннеля теперь с IPSec шифрацией трафика
-- повторное установление EIGRP соседства и возобновление маршрутизации
Как и ожидалось туннель GRE опустился как показано выше с момента как был включен IPSec на другой стороне
*Mar 1 07:55:29.374: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is down: holding time expired
R4(config)#crypto map MapOffice 5 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
R4(config-crypto-map)#match address 101
R4(config-crypto-map)#set peer 211.181.24.15
R4(config-crypto-map)#set transform-set CryptoTransformTunnel
R4(config-crypto-map)#set pfs group1
R4(config-crypto-map)#set security-association lifetime seconds 86400
R4(config-crypto-map)#exit
R4(config)#int fa 0/0
R4(config-if)#cryp
R4(config-if)#crypto map MapOffice
R4(config-if)#
*Mar 1 08:20:26.289: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
R4(config-if)#
-----------------------------
Прогнозируемое поднятие туннеля GRE и возобновление соседства
*Mar 1 08:20:27.573: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is up: new adjacency
R4(config-if)#
-----------------------------
Проверка пинга и прохождения пакетов через туннель
R4#ping 10.0.100.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.100.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/68/120 ms
R4#show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: MapOffice, local addr 211.181.25.221
protected vrf: (none)
local ident (addr/mask/prot/port): (211.181.25.221/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (211.181.24.15/255.255.255.255/47/0)
current_peer 211.181.24.15 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 141, #pkts encrypt: 141, #pkts digest: 141
#pkts decaps: 148, #pkts decrypt: 148, #pkts verify: 148
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
-----------------------------
Проверка роутинга
R4#sh ip ro
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 211.181.25.112 to network 0.0.0.0
C 211.181.25.0/24 is directly connected, FastEthernet0/0
D 211.181.24.0/24 [90/30720] via 211.181.25.112, 08:30:31, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
C 10.0.2.0 is directly connected, FastEthernet0/1
D 10.0.1.0 [90/297246976] via 10.0.100.1, 00:10:13, Tunnel0
C 10.0.100.0 is directly connected, Tunnel0
S* 0.0.0.0/0 [1/0] via 211.181.25.112
R4#
8) Убедиться что трафик идущий через тоннель шифрован
а) Убедиться что данные зашифрованы IPSec
Подключить Wireshark на интерфейс fa0/0 R5 и начать обмен данными между хостами (скачивать файл например). Сразу заметно, что данные только в зашифрованном виде (здесь был пущен банальный пинг по туннелю)
б) Убедиться, что данные идут по GRE туннелю (хотя это очевидно из построенной маршрутизации, проверить лишним не будет)
-----------------------------
Даём пинг с хоста xp_http_ftp_cisco(10.0.1.2) на хост xp_http_ftp_cisco1(10.0.1.2)
admin>ping 10.0.2.2
Обмен пакетами с 10.0.2.2 по 32 байт:
Ответ от 10.0.2.2: число байт=32 время=136мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=145мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=119мс TTL=126
Ответ от 10.0.2.2: число байт=32 время=98мс TTL=126
-----------------------------
Теперь опускаем GRE туннель
R4(config)#int Tunnel 0
R4(config-if)#sh
R4(config-if)#
*Mar 1 08:38:45.365: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 2: Neighbor 10.0.100.1 (Tunnel0) is down: interface down
R4(config-if)#
*Mar 1 08:38:47.181: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Mar 1 08:38:48.181: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R4(config-if)#
-----------------------------
И повторяем пинг
admin>ping 10.0.2.2
Обмен пакетами с 10.0.2.2 по 32 байт:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Настройка и проверка завершены. Поставленная задача достигнута.
Подписаться на:
Сообщения (Atom)