Так вот выпало стало быть.

ВОРНИНГ: NON-IT Content

По родине скучать начал заранее. За месяц облил испуганно жмущихся к стенам домочадцев слезами. За неделю помылся. Но тоска грызет. Я даже грустен сделался.

Родина, понимая тоску мою, подослала мне (прямо в ночь вылета) своих эмиссаров — позвонил Серж вечером поздним: «пойдем в лес, говорит, пиво пить в темноте из бутылок будем». Я вообще к подобным предложениям от мальчиков осторожно отношусь, оттуда не далеко до черты, за которой только узкие красные джинсы да степные пожары. А тут еще и компания соответствующая (Я щас пожары имею ввиду), прям флеш-рояль на поджоги. Но обошлось. Родина, увидив такой кафешантан тут же насторожилась и дождик выдала. Обнявшись, прорыдали до полуночи.

А там и такси примчало. Хотел в машине устроить прощание славянки и даже начал остатки слез выдавливать, как увидел на окружной дороге пробку в районе профы в три, разъети ее мать, часа то ночи. Плюнул в окно закрытое, закутался в бурку и насупился аки скорпий.

У входа в еропорт по старой традиции расцеловал взасос землицу Русскую и пошел на рейс чекиниться.

Подошел к первой стойке — отшили — только бизнесс класс.

Подошел ко второй стойке — отшили — программка не запускается.

На третьей наши уверенно победили и отдал Я котомку с исподним в холодное жерло багажного сортировщика. Все что нажито авиакомпания определенно собралась потерять, иначе нафига допытываться где Я остановлюсь в странах заморских. А там сала одного на пол пуда…

Время до вылета коротал в междугородней сети интернет. Благо в столице то в еропортах есть вайфай халявный.

Все культурные вокруг, матом не ругаются, типа забугор летим, элитные мы. Ну Я тоже одухотворенное лицо сделал.

Но очередь в дьютике была, да.

Авиакомпания аэрофлот— услада очей.  Бортпроводницы молодые, фигуристые,  декольты с шарфиками. Всю дорогу, вольготно разложившись, покровительственно похлопывал их по всякому.

Но музыка играла не долго. Пересадка в ЛондОне.

Ловко прошел предполетный досмотр — приноровился и подскочил к деве юной на ощупывание! Доложу Я вам, занятно. Спросили куда лечу и где буду жить. Записали адресок.

Спросил в ответ: «А вы чО правда решили продолбать мой багаж?».

В зале вылета усмотрел стратежное место (с розеткой рядом) и бросился туда, расталкивая зазевавшуюся чухонь. Рядом сидит природноподкопченный товарищ (Я не расист, да), плотоядно на мои переходнички (коих у меня набор знатный) щурится, Я на всякий случай деньги в носок перепрятал… А индусик мне и молвит человеческим голосом: дай, мол, мне на минуточку переходничек свой — я хочу на толику малую телефон зарядить. Пожурил его ласково за диагональ экрана неразумную, но дал.

Разговорились, он оказался CSE сектра SP маленького буржуйского кооператива, первый выезд на площадку.

Я ему показал кой-какие фотки с айпада и пару урлов дал. Два часа парень ржал как конь, потом потащил меня в кабак и настоял, что он заплатит.

Отступление: В Хитроу хитрые британцы навешали таблички вида «До выхода Х отсюда топать 20 мин», да он ппц какой большой.

Откушивали мы в самом далеком от моего выхода месте.

Вдруг табличка «иди к выходу» сменилась на «выход закрыт» а время вроде как еще есть…

Короче, реально двадцать минут бы протопал. Пробежал правда за 7.

Т.к. самолет летит в СШП в нем ЧСХ есть американцы — это такие крупные пацаны. Пока шел к месту целовал себя за то, что договорился о месте в проходе, потому как народ подобрался знатный — каждый не меньше полутора центнеров. Вот одна така тетка мне наушники порвала.

Перелёт в стиле «час поспал — час кино посмотрел» — это тема. Выучил ровно пол серии шерлока холмса и пол серии невыполнимой миссии.

Тут со стюардессами все в порядке, 40+ серьезные тетки. Прям веет уверенностью — долетим, им домой надо — дети не кормленные. Были правда две природнозагорелые с такими задницами, что в проходе с ними разминуться не мог никто. Типа такой поршень носится по проходу — выдавливает малохольных.

Сели в ЛА. Отстоял 40 минут в очереди на таможенный контроль. Воин Маниту Незатопляемый Буй (да не затупится его томагавк) нарек меня Великим Оленем т.к. не заполнил бумажку, которую надо было взять по пути, а той которую дали в самолете не достаточно. Но разрешил за ней сбегать и потом без очереди пройти. Естественно, бумажки на английском не оказалось шустрая тетка обещала подтащить, но исчезла. Пока ждал, изрисовал похабными картинками две корейских.

Тетку ждать надоело и Я пошел стучаться во все двери и просить бумажку. Собрал целый консилиум парней в форме которые решали где бы взять бумажки и не посдить ли меня такого наглого на обратный самолет.

Нашли. Заполнил. Прошел.

Простояв полчаса около карусели, осознал, что багаж таки продолбали. Озаботил этим вопросом шустрого природнозагорелого паренька, он приволок отприродыжелтоватую тетку она ткнула меля лицом в список с моим именем и сообщила, что багажа тут нет, но он прилетит и вообще иди в аэрофлот — это он виноват. Прикольно.

Дошел до аэрофлота. Там стоят пассажиры первого класса и громко всем хамят. Я вяло поинтересовался у природноподкопченной девочки где чемодан с любимыми ситцевыми трусами она взяла рацию и сказала туда много всего. Мне перевела ответ в стиле: «ищут, может занять время». Через полчаса Я скромно напомнил о себе. Она снова сказала что то в рацию. Появился русский дядька — Я его озаботил вопросом — он сказал — ждите и скрылся. Мне это настохорошело и Я пошел в АА.

Нашел офис обработки багажа и изложил проблему вовсенезагорелой, тетке она потыкала в комп, радостно сказала «АГА!» и скрылась. подождал еще. Надоело совсем. Нашел природнозагорелую и озаботил её — она потыкала в комп и тут же сообщила что багаж продолбан и прилетит ночью. Я грю в гостиницу могем? — Легко! Я вот уже тогда проникся серьёзностью природнозагорелых теток.

Но настоящий праздник души был в очереди на аренду машин. Еще одна природнозагорелая девочка жгла как дуговая сварка: у нее было два телефона оба торчали в декольте, симметрично так… миленько. один постоянно орал родные африканские мотивы, а на  другой время от времени звонили. От это жара была… Виброзвонок мощный, продолжительный, распространение гармонических колебаний в упругих средах потрясающее, Я выл.

С машиной получилось забавно: ваащета, Я заказывал мускул-кары до 1980 года выпуска с наклейкой «Fuck the fuel economy» и шляпой с очками в бардачке. Не дали, т.к. машину Я хотел взять в LA, а сдать в Сан-ФранЦыске. В итоге решил не выеживаться и заказал маленькую ниссан альтиму.

Лос-Анжелес прекрасен, Я типа попал в час пик представьте парни… мкад, час пик, по нему со скоростью 60 кмч едут машины во всех рядах. Каждая отстает от предыдущей на 50 метров. Ну млин готовая трасса для слалома. Я понял, что что-то не так, когда обратил внимание на то, что машины разбегаются пр виде меня. Короче выключил Я с трудом южный стиль вождения и поплелся со всеми.

Калифорния это наше Сочи только горы поменьше, а все остальное в наличии: песня «чОрные глаза», хачапури, лаваш, кебаб итп.

Постоял на берегу, посмотрел в сторону Родины… Туман был, не видно ничО. Но веяло оттуда чем-то хорошим.

Проехал не далеко, срубил джетлаг.

Мотель — полный атас. Все как в кино. Гадюшник, но мне было уже наплевать.

Характер расшатанности кроватей говорит о классической постановке вопроса на территории калифорщины. Зато душ.

Встал в 5 по местному времени. Как честный тип тытался минут 10 достучаться до портье, чтоб ключи отдать… забил и сунул под дверь.

Помчал дальше.

Показалось что машину ведет вправо, остановился, включил аварийку. Не успел отстягнуть ремень, как увидел сзади останавливающегося полицая, хайвей патрол блин.

Вот тут всякое подумалось: что в багажник не заглянул, бардачОк не проверил. А ну как там труп или запас зелья конский?

Машина полицая обвешана всякими деталями от звездолетов, ну чисто жигули семерка в Чалтыре (тут Я конечно приувеличил, ну куда ему до наших парней).

Подошел офицер Фернандез и, придерживая руку у пояса, поинтересовался

—А фигли ли ты тут делаешь?

—Лос лобос антонио бандераз, марьячи (колесо остановился посмотреть)

—А едешь куда? [он явно очленел от моего испанского]

—Туда.

—А ну ладно, скатертью по ягодицам.

Ни документов проверить, ни машину досмотреть… Плохо служба поставлена у товарища Фернадеса.

Зато я фотку сделал

 

Данная функция была впервые внедрена в маршрутизаторы Cisco в IOS 12.3(7)T. Она позволяет проводить фильтрацию трафика и осуществлять динамическую инспекцию приложений, когда маршрутизатор выступает в роли L2-моста.

В прозрачном (transparent) режиме маршрутизатор не осуществляет маршрутизацию, а просто изучает MAC-адреса на всех своих интерфейсах подобно коммутатору. Когда Вы конфигурируете прозрачный фаирвол на Cisco IOS, прежде всего необходимо определиться с типом бриджирования, которое будет осуществлять маршрутизаторах. Таких типов два: CRB и IRB. Что же это за звери такие? Поговорим об этом подробнее.

1. CRB (Concurrent Routing and Bridging) режим включается командой bridge crb. Позволяет маршрутизатору коммутировать фреймы между интерфейсами, которые являются членами одной мостовой группы (bridge group). Интерфейсы, которые не являются членами никакой мостовой группы и на которые назначены IP-адреса могут принимать и перенаправлять IP-пакеты. Т.е. в этом режиме маршрутизатор выступает в роли моста для одного набора интерфейсов и в роли обычного L3-устройства для других интерфейсов.
2. IRB (Integrated Routing and Bridging) режим включается командой bridge irb. Позволяет сконфигурировать специальный интерфейс BVI (Bridge Virtual Interface) для каждой мостовой группы. Данный интерфейс представляет маршрутизатор как L3-устройство для определенной мостовой группы. Все устройства внутри группы, которые знают MAC-адрес BVI-интерфейса, могут отправлять маршрутизатору IP-пакеты и общаться с другими сетевыми устройствами данного L2-домена. Этот режим позволяет маршрутизатору производить коммутацию между своими интерфейсами и маршрутизировать пакеты для членов мостовой группы, которые знают о данной службе.

В целом, для простоты понимания, Вы можете сравнить BVI с SVI (Switch Virtual Interface) на L3-коммутаторе. В дополнение ко всему, вместе с командой bridge irb Вам необходимо добавить команду bridge <NUMBER> route ip, где NUMBER – номер мостовой группы. В противном случае, BVI-интерфейс не будет маршрутизировать IP-пакеты.

Вы можете применять правила классического фаирволла для динамической инспекции приложении и списки доступа на интерфейсы. Например:

В прозрачном режиме поддерживается инспекция только для TCP/UDP и ICMP. Все не IP-пакеты по-умолчанию разрешены (ARP, STP и т.д.). Если Вы хотите заблокировать не IP-трафик, необходимо применить список доступа к мостовому интерфейсу. Эти списки доступа основываются на значениях Ethertype. Например, следующий список доступа разрешает весь IP-трафик и ARP, но блокирует WOL Magic packet:

Прим.: Ethertype – двух байтовое поле в Ethernet-заголовке. Располагается сразу после поля «Source MAC». Используется для того, чтобы показать какой протокол инкапсулирован в Ethernet фрейм.

Фаирволл в прозрачном режиме не инспектирует multicast Ethernet фреймы – они разрешены независимо от того, что сконфигурировано во входящих списках доступа. Однако широковещательные фреймы проходят проверку в списках доступа. Для DHCP-пакетов фаирволл предоставляет специальное средство обработки (т.к. DHCP является важной составляющей сетевой инфраструктуры). Для разрешения прохождения DHCP-сообщений через фаирволл (опять же, независимо от того, что сконфигурировано в списках доступа) используйте команду ip inspect l2-transparent dhcp-passthrough.

И на последок скажу пару слов об IP-адресах, которые назначаются на BVI-интерфейс. Этот адрес должен быть внутри той же сети, что и защищаемый сегмент. Здесь вполне можно провести аналогию с фаирволлом Cisco ASA, когда та работает в прозрачном режиме и имеет единственный IP-адрес для управления.

Прим.: трафик, сгенерированный самим маршрутизатором не проходит проверку в списках доступа, которые назначены на интерфейсы в мостовой группе. Для контроля трафика управления Вам необходимо создать отдельный список доступа и применить его на BVI-интерфейс.

 

Маршрутизаторы Cisco IOS умеют проводить инспекцию протоколов не только на 3ем и 4ом уровнях модели OIS, но и на 7ом. Для чего это нужно? Например, вы захотите запретить определенные SMTP сообщения, которые открывают уязвимости на почтовом сервере. Или вы хотите быть уверенным, что HTTP соединения не используются для тунеллирования сервисов мгновенных сообщений (напр. сервис ICQ2GO). Решение задач, подобных тем, что описаны в этом абзаце выше, возможно только с помощью инспекции сообщений протоколов на уровне приложений.

Прим.: реализация L7-инспекции на маршрутизаторах имеет гораздо больше ограничений, чем на Cisco ASA

Программное обеспечение Cisco IOS поддерживает глубокую инспекцию следующих служб и сервисов:

1. HTTP
2. SMTP/eSMTP
3. POP3/IMAP
4. Приложения типа peer-to-peer (eDonkey, Kazaa, Gnutella)
5. Различные IM-приложения
6. Некоторые другие

Как же конфигурируется L7-инспекция? Для этого IOS использует специальные типы карт классов и политик – так называемые specific application карты: class-map type inspect http, policy-map type inspect http и подобные им для каждого поддерживаемого протокола. В этих картах определяются «узкие» параметры протокола, которые должны быть проверена. После определения того, что мы конкретно хотим отловить у протокола (например метод GET в HTTP), необходимо применить только что сконфигурированную карту политик как вложенную внутрь уже существующей карты 3го/4го уровней модели OSI. Например:

в при веденном примере сначала выделяется HTTP-трафик (class-map CLASS_HTTP), дальше указывается что конкретно мы хотим выявить в указанном трафике (match req-resp protocol violation отлавливает все HTTP сообщения, запрос или ответ в которых нарушают RFC). К отловленному трафику (с нарушениями RFC) применяется действие “reset”.

Прим.: важно помнить, что для каждой карты типа inspect <protocol>  применимы сугубо индивидуальные команды (т.е. для HTTP мы может отлавливать трафик по одним критериям, которых не будет в протоколе SMTP и наоборот). Чтобы ответить на вопрос «что можно поймать в том или ином протоколе?» необходимо внимательно прочитать соответствующий RFC.

Отдельно мне бы хотелось выделить один тип объектов, который часто используется при написании конфигов для L7-инспекции – это регулярные выражения. С помощью них можно поймать, например, определенную веб-страничку или почтовый адрес получателя электронного сообщения. Синтаксис для описания параметров регулярных выражений следующий:

Данная конструкция выловит все HTTP-сообщения, у которых в заголовках запроса содержится слово “flane” в любых вариантах написания.

Прим.: более подробную информацию о регулярных выражениях вы можете найти на сайте cisco.com

 

В ZFW появляется новое ключевое понятия – зона, которая состоит из набора различных интерфейсов, которые должны иметь одинаковую политику сетевой безопасности (или, иначе говоря, одинаковый уровень доверия). На рисунке, вы можете увидеть три зоны безопасности, назначенные на различные интерфейсы маршрутизатора:

Разрешения для прохождения того или иного трафика делаются между зонами, не между интерфейсами. По умолчанию, трафик разрешен между интерфейсами одной зоны безопасности и запрещен между разными зонами. Трафик между интерфейсом, который относится к какой-либо зоне, и интерфейсом, который не относится ни к одной зоне, запрещен. В дополнение ко всему, вы не можете применять классические правила фаирволла (CBAC, ACL) к интерфейсу, который принадлежит какой-либо зоне безопасности.

Существует одна зона, которая есть на всех маршрутизаторах и создана по-умолчанию и известна как self-зона. К этой зоне относятся все IP-адреса маршрутизатора. Трафик между self-зоной и любой другой по-умолчанию разрешен. Однако, вы можете применить политику между self-зоной и любой другой чтобы контролировать трафик, который генерируется маршрутизатором. Если вы примените политику от любой зоны к self-зоне, то трафик от self-зоны в обратном направлении будет все равно разрешен (пока вы явно это не запретите).

Когда вы хотите применить политики к трафику, который проходит между зонами, необходимо помнить одно важное правило: политики применяются к зоновой паре (zone pair). При этом, пара зон {A,B} это не тоже самое, что {B,A}. Первая зона в паре называется зоной-источником (source zone), вторая зоной назначения (destination zone). Когда вы применяете политику фаирволла к зоновой паре, она применяется к трафику который «бежит» от зоны-источника к зоне назначения.

Для применения политик ограничения/разрешения трафика, ZFW использует новый язык конфигурации, называемый Cisco Policy Language (CPL). Синтаксис CPL был полностью позаимствован от широко-известного MQC (Modular QoS CLI). Ниже представлен краткий обзор шагов конфигурации ZFW:

1. Определить зоны. Это делается с помощью команды zone security <ZONE_NAME>. Для каждой зоны можно задать описание (description).
2. Определить зоновые пары. Это делается с помощью команды zone-pair security <ZONEPAIR_NAME> source <ZONE_SOURCE> destination <ZONE_DESTINATION>
3. Определить карты классов (class-map), которые описывают трафик, к которому применяются политики фаирволла. В ZFW используется новый тип классовых карт class-map type inspect, который описывает область инспекции трафика.
4. Определить карты политик (policy-map). В ZFW введен новый тип таких карт policy-map type inspect. Вы применяете ранее определенные классовые карты к картам политик и назначаете действия, который должен сделать маршрутизатор с определенным выше трафиком (например пропустить или дропнуть).
5. (Опционально) определить расширенные параметры политики: например ограничение количества TCP/UDP сессий. Более подробно различные сценарии мы с вами рассмотрим в отдельных статьях.
6. Применить карты политик к зоновой паре. Делается это командой service-policy type inspect <POLICY NAME> в режиме конфигурирования зоновой пары, которую мы определили на шаге 2 данного алгоритма.
7. Завести интерфейсы в зоны. Это последний шаг, который делается в режиме конфигурирования интерфейса командой zone-member security <ZONE NAME>

Определение классов трафика

Классовые карты инспекции могут быть двух типов: match-all и match-any, точно также, как и обычные карты в MQC. В первом случае, все условия match, которые заданы внутри карты, должны быть выполнены; во втором случае должно совпасть хотя бы одно условие.

Для выделения трафика по направлению вы можете использовать команду match access-group name <ACL NAME> (это единственный способ выделить трафик от конкретного источника к конкретному получателю).

В дополнение к спискам доступа, вы можете выделять протоколы, которые поддерживаются модулем инспекции маршрутизатора (inspection engine). Список поддерживаемых протоколов такой же как у технологии CBAC. Однако, в противовес классическим классовым картам, когда вы вводите команду match protocol (для просмотра всех протоколов, которые поддерживаются для команды match, можно использовать команду show ip port-map), вы не включаете процесс NBAR’а – скорее протокол для инспекции будет выбран когда карта политики будет применена к зоновой паре. Довольно часто комбинируют «отлов» трафика по спискам доступа и протоколам, например:

выше приведенная конструкция отловит HTTP-трафик от пользователей, который находятся в INSIDE-сети (согласно списку доступа).

Кроме того, вы можете использовать вложенные классовые карты – это может быть полезно, когда необходимо применить комплексную логику И/ИЛИ. Например: вы хотите выбрать набор протоколов (HTTP, DNS, ICMP) для определенной группы пользователей. Итоговый результат будет выглядеть следующим образом:

Применение политик

Существует три основных действия, которые применимы для инспектирующих карт политик: “inspect”, “drop” и “pass”. Первое действие (inspect) аналогично правилу CBAC-инспекции. Оно включает динамическую инспекцию для трафика, который бежит от зоны источника к зоне назначения и автоматически разрешает обратный трафик даже для сложны протоколов, таких как H323. Действие “drop” просто отбрасывает трафик, а “pass” пропускает не включая инспекцию протокола (аналогично строчке “permit” в списке доступа). Пример команды:

Прим.: если вы используете “inspect” в карте политик, то классовые карты должны содержать хотя бы одно “match protocol” условие для определения того, какой протокол необходимо инспектировать. В противном случае будут инспектироваться все поддерживаемые протоколы. Если вы используете действие типа “pass”, то необходимо убедиться, что обратный трафик также разрешен. Помимо выше сказанного, каждая карта политик имеет скрытый класс class-default, для которого сконфигурировано действие “drop” (аналогично строке deny any any в любом списке доступа).

Изменение портов для инспектирования протоколов

Как было замечено раньше, ZFW поддерживает тот же набор протоколов, что и CBAC. Вы можете посмотреть стандартные порты того или иного протокола на котором он может инспектироваться командой show ip port-map. Если вам нужно изменить стандартный порт инспекции, используйте команду ip port-map <protocol>. Если вам нужно изменить стандартный порт только для определенных адресов (скажем для некоторых WEB-серверов), используйте команду ip port-map <protocol> port <port> list <ACL>. Например:

выше приведенные команды добавят инспектирование протокола HTTP по порту 8080 для адресов из диапазона 10.1.1.0/24.

Self-зона маршрутизатора

Политики, которые могут быть применены относительно self-зоны маршрутизатора имеют некоторые ограничения. Во-первых, динамическая инспекция для трафика, который сгенерирован самим маршрутизатором, ограничена протоколами TCP, UDP, ICMP и H323. Инспекция протоколов на уровне приложений (HTTP, TELNET и пр.) не поддерживается. Во-вторых, ограничение по количеству сессий и по полосе также не может быть сконфигурировано.

Рассмотрим пример: нам требуется разрешить только SSH-трафик на машрутизатор. Сделать это можно следующим образом:

Прим.: после примененной выше конфигурации, весь трафик кроме SSH будет отброшен. Если вы используете, например, протоколы маршрутизации OSPF, EIGRP, то они должны быть явно разрешены – т.к. инспекция этих протоколов не поддерживается.

 

Одно из главных преимуществ DMVPN – возможность построения отказоустойчивых виртуальных сетей на базе классического подхода посредством использованием протоколов динамической маршрутизации. Шифрованное mGRE облако фактически представляет собой легко масштабируемый L3 транспорт, прозрачный для протоколов маршрутизации – в этом основное преимущество перед классическим IPsec.

Рассмотрим наиболее сложную в плане отказоустойчивости схему, включающую всевозможные варианты:

• 2 DMVPN hub-а в центральном офисе.
• 3 провайдера в центральном офисе.
• 1 из hub-ов подключен одновременно к двум провайдерам.
• 2 удаленных Spoke офиса.
• 1 из spoke-ов подключен одновременно к двум провайдерам.

Лабораторный стенд будет иметь следующий вид:

Итак, в данной схеме со стороны центрального офиса мы имеем 2  HUB маршрутизатора и 2 провайдера, оба из которых терминируются на первом маршрутизаторе, и один на втором.  Нашей целью является организовать свое mGRE облако поверх каждого провайдерского линка центрального офиса. Соответственно мы будем иметь 2 виртуальных туннельных mGRE интерфейса на  первом маршрутизаторе и 1 mGRE интерфейс на втором.  Итого 3 облака.  И на каждом Spoke маршрутизаторе будет терминироваться 3 туннельных интерфейса.  На Spoke_2 — первое облако будет работать через первого провайдера — остальные два через второго. Маршрутизатор LAN_CORE – эмулирует ядро локальной сети центрального офиса.

Основным вопросом в данной ситуации является: как заставить трафик интересующего туннельного mGRE интерфейса ходить всегда через соответствующего провайдера?  Ответом на этот вопрос является весьма простая технология Tunnel route selection, которая непосредственно в настройках туннельного интерфейса позволяет явным образом указать физический интерфейс, через который должен маршрутизироваться туннельный трафик: tunnel route-via interface-type interface-number {mandatory | preferred}.  Важно понимать, что данная опция работает только в том случае, если в таблице маршрутизации имеется соответствующий маршрут!

Вторым важным вопросом является:  как Spoke маршрутизатор сможет понять, к какому туннельному интерфейсу отнести приходящий GRE пакет?   Для этого существует технология tunnel key.  Данный механизм осуществляет маркировку GRE пакетов заданным значением tunnel key. Маркировка осуществляется  посредством записи  значения в добавляемые 4 байта к GRE заголовку.

Приступим к конфигурации наших маршрутизаторов.  Тестовая лаборатория собрана и отлажена в GNS3, платформа 7200 NPE-400, версия 15.0(1)M. Аналогично подобная конфигурация успешно опробована в боевой среде на платформах 7200 NPE-G2, ISR 1800/2800. В том числе с версиями 12.4(24)T  и более ранними.

1.) Первоначальная конфигурация:

HUB 1:
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
!
interface FastEthernet1/0
ip address 1.1.1.2 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 0.0.0.0 0.0.0.0 2.2.2.1

HUB 2:
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.3 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 2.2.2.1

INTERNET:
interface FastEthernet1/0
ip address 1.1.1.1 255.255.255.0
!
interface FastEthernet2/0
ip address 2.2.2.1 255.255.255.0
!
interface FastEthernet3/0
ip address 3.3.3.1 255.255.255.0
!
interface FastEthernet4/0
ip address 4.4.4.1 255.255.255.0
!
interface FastEthernet5/0
ip address 5.5.5.1 255.255.255.0
!

SPOKE_1:
interface Loopback0
ip address 10.2.2.2 255.255.255.0
!
interface FastEthernet3/0
ip address 3.3.3.2 255.255.255.0
!
interface FastEthernet4/0
ip address 4.4.4.2 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 3.3.3.1
ip route 0.0.0.0 0.0.0.0 4.4.4.1

SPOKE_2:
interface Loopback0
ip address 10.3.3.3 255.255.255.0
!
interface FastEthernet0/0
ip address 5.5.5.2 255.255.255.0
duplex full
!
ip route 0.0.0.0 0.0.0.0 5.5.5.1

LAN_CORE:
interface Loopback0
ip address 10.1.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.10.10.3 255.255.255.0
!

Ключевым моментом данной части является настройка равноценных маршрутов (выделено желтым) до всех остальных маршрутизаторов, если на конфигурируемом маршрутизаторе терминируется 2 или более провайдеров. В данном случае мы используем маршруты по умолчанию – но это могут быть и конкретные маршруты до конечных узлов.  Без этого не будет работать функционал tunnel route-via.

2.) Настраиваем mGRE транспорт:

HUB 1:
interface Tunnel1
ip address 192.168.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1360
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet1/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 2
ip tcp adjust-mss 1360
tunnel source FastEthernet2/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet2/0 mandatory
tunnel path-mtu-discovery

HUB 2:
interface Tunnel3
ip address 192.168.3.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map multicast dynamic
ip nhrp network-id 3
ip tcp adjust-mss 1360
tunnel source FastEthernet2/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet2/0 mandatory
tunnel path-mtu-discovery

SPOKE_1:
interface Tunnel1
ip address 192.168.1.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.1.1 1.1.1.2
ip nhrp map multicast 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source FastEthernet3/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet3/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.2.1 2.2.2.2
ip nhrp map multicast 2.2.2.2
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1
ip tcp adjust-mss 1360
tunnel source FastEthernet4/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet4/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel3
ip address 192.168.3.101 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.3.1 2.2.2.3
ip nhrp map multicast 2.2.2.3
ip nhrp network-id 3
ip nhrp nhs 192.168.3.1
ip tcp adjust-mss 1360
tunnel source FastEthernet4/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet4/0 mandatory
tunnel path-mtu-discovery

SPOKE_2:
interface Tunnel1
ip address 192.168.1.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.1.1 1.1.1.2
ip nhrp map multicast 1.1.1.2
ip nhrp network-id 1
ip nhrp nhs 192.168.1.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel2
ip address 192.168.2.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.2.1 2.2.2.2
ip nhrp map multicast 2.2.2.2
ip nhrp network-id 2
ip nhrp nhs 192.168.2.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 2
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery
!
interface Tunnel3
ip address 192.168.3.102 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp map 192.168.3.1 2.2.2.3
ip nhrp map multicast 2.2.2.3
ip nhrp network-id 3
ip nhrp nhs 192.168.3.1
ip tcp adjust-mss 1360
tunnel source FastEthernet0/0
tunnel mode gre multipoint
tunnel key 3
tunnel route-via FastEthernet0/0 mandatory
tunnel path-mtu-discovery

Наиболее важные моменты выделены желтым. Это:
1.) ip nhrp network-id — идентификатор nhrp процесса/базы – для каждого облака должен быть свой уникальный идентификатор.
2.) tunnel key — идентификатор туннельного интерфейса на маршрутизаторе, для выяснения соответствия туннельного интерфейса и приходящего GRE пакета.
3.) tunnel route-via FastEthernetX/X mandatory – явное указание маршрутизировать туннельный трафик через указанный интерфейс. Параметр mandatory указывает, что в случае падения интерфейса или отсутствия маршрута — трафик не пойдет никуда.

3.) Настраиваем динамическую маршрутизацию:

HUB маршрутизаторы:
interface TunnelX // для всех туннелей
bandwidth 1000
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
!
router eigrp 1
network 10.0.0.0
network 192.168.0.0 0.0.255.255

SPOKE маршрутизаторы:
interface TunnelX // для всех туннелей
bandwidth 100
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
!
router eigrp 1
network 10.0.0.0
network 192.168.0.0 0.0.255.255
eigrp stub connected summary

LAN_CORE:
router eigrp 1
network 10.0.0.0

Важным моментом здесь являются специфические настройки туннельных интерфейсов (выделено желтым), обусловленные non-broadcast multi-access природой сети mGRE.
Также крайне рекомендуется настраивать везде, где возможно, опцию stub zone на SPOKE маршрутизаторах. Это может ускорить процесс сходимости сети, а так же исключит возможность транзитного трафика через филиалы.

Стоит отметить, что в данном случае я растянул процесс маршрутизации EIGRP 1 до маршрутизатора LAN_CORE. Для реальной сети это не совсем правильная практика, и используется она исключительно в целях упрощения лабораторного стенда.

4.) Проверяем, что у нас получилось:

HUB_1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
5 192.168.2.102 Tu2 10 03:43:00 873 5000 0 5
4 192.168.1.102 Tu1 12 03:43:00 819 4914 0 4
3 192.168.1.101 Tu1 12 03:43:01 427 2562 0 4
2 192.168.2.101 Tu2 10 03:43:01 326 1956 0 5
1 10.10.10.3 Fa0/0 10 03:43:07 128 768 0 9
0 10.10.10.2 Fa0/0 12 03:43:07 215 1290 0 14

HUB_1#show ip nhrp
192.168.1.101/32 via 192.168.1.101
Tunnel1 created 03:45:17, expire 00:04:48
Type: dynamic, Flags: unique registered
NBMA address: 3.3.3.2
192.168.1.102/32 via 192.168.1.102
Tunnel1 created 03:45:17, expire 00:05:08
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2
192.168.2.101/32 via 192.168.2.101
Tunnel2 created 03:45:17, expire 00:04:50
Type: dynamic, Flags: unique registered
NBMA address: 4.4.4.2
192.168.2.102/32 via 192.168.2.102
Tunnel2 created 03:45:17, expire 00:05:10
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2

HUB_1#sh ip route
S* 0.0.0.0/0 [1/0] via 2.2.2.1
[1/0] via 1.1.1.1
1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 1.1.1.0/24 is directly connected, FastEthernet1/0
L 1.1.1.2/32 is directly connected, FastEthernet1/0
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/24 is directly connected, FastEthernet2/0
L 2.2.2.2/32 is directly connected, FastEthernet2/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/156160] via 10.10.10.3, 03:43:18, FastEthernet0/0
D 10.2.2.0/24 [90/3968000] via 192.168.2.101, 03:43:09, Tunnel2
[90/3968000] via 192.168.1.101, 03:43:09, Tunnel1
D 10.3.3.0/24 [90/3968000] via 192.168.2.102, 03:43:09, Tunnel2
[90/3968000] via 192.168.1.102, 03:43:09, Tunnel1
C 10.10.10.0/24 is directly connected, FastEthernet0/0
L 10.10.10.1/32 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Tunnel1
L 192.168.1.1/32 is directly connected, Tunnel1
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Tunnel2
L 192.168.2.1/32 is directly connected, Tunnel2
D 192.168.3.0/24 [90/3842560] via 10.10.10.2, 03:43:10, FastEthernet0/0

HUB_2#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
3 192.168.3.101 Tu3 11 03:55:52 1612 5000 0 6
2 192.168.3.102 Tu3 12 03:55:52 170 1020 0 6
1 10.10.10.1 Fa0/0 11 03:56:04 227 1362 0 16
0 10.10.10.3 Fa0/0 11 03:56:06 519 3114 0 9

HUB_2#sh ip nhrp
192.168.3.101/32 via 192.168.3.101
Tunnel3 created 03:56:05, expire 00:05:08
Type: dynamic, Flags: unique registered
NBMA address: 4.4.4.2
192.168.3.102/32 via 192.168.3.102
Tunnel3 created 03:56:06, expire 00:05:27
Type: dynamic, Flags: unique registered
NBMA address: 5.5.5.2

HUB_2#sh ip route
S* 0.0.0.0/0 [1/0] via 2.2.2.1
2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 2.2.2.0/24 is directly connected, FastEthernet2/0
L 2.2.2.3/32 is directly connected, FastEthernet2/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/156160] via 10.10.10.3, 03:56:22, FastEthernet0/0
D 10.2.2.0/24 [90/3968000] via 192.168.3.101, 03:56:08, Tunnel3
D 10.3.3.0/24 [90/3968000] via 192.168.3.102, 03:56:08, Tunnel3
C 10.10.10.0/24 is directly connected, FastEthernet0/0
L 10.10.10.2/32 is directly connected, FastEthernet0/0
D 192.168.1.0/24 [90/3842560] via 10.10.10.1, 03:56:08, FastEthernet0/0
D 192.168.2.0/24 [90/3842560] via 10.10.10.1, 03:56:08, FastEthernet0/0
192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.3.0/24 is directly connected, Tunnel3
L 192.168.3.1/32 is directly connected, Tunnel3

SPOKE_1#sh ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.1.1 Tu1 12 04:01:24 788 5000 0 19
1 192.168.2.1 Tu2 12 04:01:24 836 5000 0 20
0 192.168.3.1 Tu3 14 04:01:25 612 5000 0 15

SPOKE_1#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:02:09, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:02:08, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:02:08, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3

SPOKE_1# show ip route eigrp
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27010560] via 192.168.3.1, 04:03:18, Tunnel3
[90/27010560] via 192.168.2.1, 04:03:18, Tunnel2
[90/27010560] via 192.168.1.1, 04:03:18, Tunnel1
D 10.3.3.0/24 [90/28288000] via 192.168.3.102, 04:03:13, Tunnel3
[90/28288000] via 192.168.2.1, 04:03:13, Tunnel2
[90/28288000] via 192.168.1.102, 04:03:13, Tunnel1
D 10.10.10.0/24 [90/26882560] via 192.168.3.1, 04:03:18, Tunnel3
[90/26882560] via 192.168.2.1, 04:03:18, Tunnel2
[90/26882560] via 192.168.1.1, 04:03:18, Tunnel1

SPOKE_2#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 192.168.1.1 Tu1 13 04:06:30 256 5000 0 17
1 192.168.2.1 Tu2 11 04:06:30 292 5000 0 18
0 192.168.3.1 Tu3 13 04:06:31 384 5000 0 16

SPOKE_2#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:06:55, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:06:54, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:06:54, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3

SPOKE_2#sh ip route eigrp
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
D 10.1.1.0/24 [90/27010560] via 192.168.3.1, 04:06:45, Tunnel3
[90/27010560] via 192.168.2.1, 04:06:45, Tunnel2
[90/27010560] via 192.168.1.1, 04:06:45, Tunnel1
D 10.2.2.0/24 [90/28288000] via 192.168.3.101, 04:06:41, Tunnel3
[90/28288000] via 192.168.2.1, 04:06:41, Tunnel2
[90/28288000] via 192.168.1.101, 04:06:41, Tunnel1
D 10.10.10.0/24 [90/26882560] via 192.168.3.1, 04:06:45, Tunnel3
[90/26882560] via 192.168.2.1, 04:06:45, Tunnel2
[90/26882560] via 192.168.1.1, 04:06:45, Tunnel1

Итак видно, что полная связность mGRE сети имеется, трафик балансируется по всем имеющимся туннелям.
Проверяем работу сети посредством ICMP:

LAN_CORE#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 140/177/264 ms

LAN_CORE#ping 10.3.3.3 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 140/170/220 ms

Видно, что проходящий через HUB-ы трафик маршрутизируется успешно.
Теперь протестируем Spoke to Spoke трафик:

SPOKE_1#ping 10.3.3.3 source loopback 0 repeat 50

Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 168/233/380 ms

SPOKE_1#sh ip nhrp
192.168.1.1/32 via 192.168.1.1
Tunnel1 created 04:13:06, never expire
Type: static, Flags: used
NBMA address: 1.1.1.2
192.168.1.102/32 via 192.168.1.102
Tunnel1 created 00:00:18, expire 00:06:21
Type: dynamic, Flags: router used
NBMA address: 5.5.5.2
192.168.2.1/32 via 192.168.2.1
Tunnel2 created 04:13:06, never expire
Type: static, Flags: used
NBMA address: 2.2.2.2
192.168.3.1/32 via 192.168.3.1
Tunnel3 created 04:13:05, never expire
Type: static, Flags: used
NBMA address: 2.2.2.3
SPOKE_1#

Также видим, что в результате теста появилась выделенная динамическая NHRP запись. Т.е. трафик между SPOKE маршрутизаторами прошел напрямую, минуя HUB маршрутизаторы.

5.) Настраиваем шифрование полученного транспорта посредством IPsec:

Теперь самое интересное – настройка IPSec.
Ключевыми моментами здесь является:

• Для каждого туннельного интерфейса необходимо настроить отдельный IPsec profile.
• Для каждого IPsec profile необходимо настроить отдельный crypto isakamp profile с явным указанием используемого физического интерфейса.
• Для каждого crypto isakamp profile необходимо настроить отдельный crypto keyring с явным указанием используемого физического интерфейса.

Без выше приведенных указаний схема работать не будет! Даже если все туннели бегают через один и тот же физический интерфейс.

HUB_1:
crypto keyring DMVPN-1
local-address FastEthernet1/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet2/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet1/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet2/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2

HUB_2:
crypto keyring DMVPN-3
local-address FastEthernet2/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet2/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

SPOKE_1:
crypto keyring DMVPN-1
local-address FastEthernet3/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet4/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-3
local-address FastEthernet4/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet3/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet4/0
crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet4/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

SPOKE_2:
crypto keyring DMVPN-1
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-2
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
crypto keyring DMVPN-3
local-address FastEthernet0/0
pre-shared-key address 0.0.0.0 0.0.0.0 key secret
!
crypto isakmp policy 10
authentication pre-share
group 2

crypto isakmp profile DMVPN-1
keyring DMVPN-1
match identity address 0.0.0.0
local-address FastEthernet0/0
crypto isakmp profile DMVPN-2
keyring DMVPN-2
match identity address 0.0.0.0
local-address FastEthernet0/0
crypto isakmp profile DMVPN-3
keyring DMVPN-3
match identity address 0.0.0.0
local-address FastEthernet0/0
!
crypto ipsec transform-set ESP-DES-MD5-HMAC esp-des esp-md5-hmac
!
crypto ipsec profile DMVPN-1
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-1
!
crypto ipsec profile DMVPN-2
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-2
!
crypto ipsec profile DMVPN-3
set transform-set ESP-DES-MD5-HMAC
set isakmp-profile DMVPN-3
!
interface Tunnel1
tunnel protection ipsec profile DMVPN-1
!
interface Tunnel2
tunnel protection ipsec profile DMVPN-2
!
interface Tunnel3
tunnel protection ipsec profile DMVPN-3

Проверяем работоспособность

6.) Проверяем, что получилось в конечном варианте:

SPOKE_1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
2.2.2.2 4.4.4.2 QM_IDLE 1002 ACTIVE
1.1.1.2 3.3.3.2 QM_IDLE 1001 ACTIVE
2.2.2.3 4.4.4.2 QM_IDLE 1003 ACTIVE

SPOKE_2#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
2.2.2.3 5.5.5.2 QM_IDLE 1001 ACTIVE
1.1.1.2 5.5.5.2 QM_IDLE 1003 ACTIVE
2.2.2.2 5.5.5.2 QM_IDLE 1002 ACTIVE

LAN_CORE#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 148/213/540 ms

LAN_CORE#ping 10.3.3.3 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 132/168/232 ms

SPOKE_2#ping 10.2.2.2 source loopback 0 repeat 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 10.3.3.3
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 144/293/1176 ms

HUB_1#show crypto ipsec sa

interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 1.1.1.2

protected vrf: (none)
local ident (addr/mask/prot/port): (1.1.1.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (3.3.3.2/255.255.255.255/47/0)
current_peer 3.3.3.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4016, #pkts encrypt: 4016, #pkts digest: 4016
#pkts decaps: 3941, #pkts decrypt: 3941, #pkts verify: 3941
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 1.1.1.2, remote crypto endpt.: 3.3.3.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
current outbound spi: 0x6D6950C(114726156)
PFS (Y/N): N, DH group: none

*******
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 2.2.2.2

protected vrf: (none)
local ident (addr/mask/prot/port): (2.2.2.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (4.4.4.2/255.255.255.255/47/0)
current_peer 4.4.4.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 3823, #pkts encrypt: 3823, #pkts digest: 3823
#pkts decaps: 3830, #pkts decrypt: 3830, #pkts verify: 3830
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 2.2.2.2, remote crypto endpt.: 4.4.4.2
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet2/0
current outbound spi: 0xAC4640D5(2890285269)
PFS (Y/N): N, DH group: none

********
Из приведенных пингов и куска show crypto ipsec sa на первом HUB-е видно, что все работает как надо, пакеты успешно ходят через оба туннельных интерфейса, GRE транспорт в обоих случаях успешно шифруется. Задача наша выполнена.
А теперь интересная деталь:

HUB_1#show ip cef tunnel 1 detail
IPv4 CEF is enabled and running
VRF Default
43 prefixes (43/0 fwd/non-fwd)
Table id 0×0
Database epoch: 0 (43 entries at this epoch)

10.2.2.0/24, epoch 0, per-destination sharing
nexthop 192.168.1.101 Tunnel1
10.3.3.0/24, epoch 0, per-destination sharing
nexthop 192.168.1.102 Tunnel1
192.168.1.0/24, epoch 0, flags attached, connected, cover dependents, need deagg
Covered dependent prefixes: 4
need deagg: 2
notify cover updated: 2
attached to Tunnel1
192.168.1.101/32, epoch 0, flags attached
Adj source: IP midchain out of Tunnel1, addr 192.168.1.101 67DE0C20
Dependent covered prefix type adjfib cover 192.168.1.0/24
attached to Tunnel1
192.168.1.102/32, epoch 0, flags attached
Adj source: IP midchain out of Tunnel1, addr 192.168.1.102 68738D00
Dependent covered prefix type adjfib cover 192.168.1.0/24
attached to Tunnel1

Как видно, в последних версиях IOS туннельные интерфейсы работают в режиме Cisco Express Forwarding (CEF) в том числе в случае использования опции tunnel key.
PS
Теперь отвечу на вопрос: почему я не рассмотрел вариант с 4 перекрещивающимися mGRE облаками для HUB-ов и SPOKE-ов, терминирующих по два провайдера (fullmesh) ? Мое мнение следующее: подобная схема конечно же имеет право на существование в воспаленном мозгу. Также, чисто теоретически, она должна работать на основе рассмотренной конфигурации (tunnel route via). Но в реальной жизни в здравом уме я бы определенно не стал этого делать. Так как ничего хорошего, кроме лишнего фактора непредсказуемости, нагрузки CPU и утилизации канала служебным трафиком — сложная и чрезмерно отказоустойчивая схема не принесет. ИМХО.

***

Рекомендуемое чтиво:
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPDG.html
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_trsel.html
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.pdf

С уважением,
Павел Попп aka P@ve1

 

Конфигурация интерфейса, смотрящая в сторону источника:

interface GigabitEthernet0/1.112
encapsulation dot1Q 112
ip address 10.251.251.1 255.255.255.240
no ip redirects
no ip proxy-arp
ip pim sparse-mode
no snmp trap link-status
end

Обращаю внимание на то, что для работы PIM адрес источника может быть не в одной сети с интерфейсом, смотрящим в его сторону, но для работы MSDP он должен знать reverse path к источнику в обычной табличке маршрутизации.

Интерфейс, смотрящий в «чужую» сеть:

interface GigabitEthernet0/1.111
encapsulation dot1Q 111
ip address 198.18.85.42 255.255.255.252
no ip redirects
no ip proxy-arp
ip pim sparse-mode
no snmp trap link-status
end

ВАЖНО: Принудительно делаем маршрутизатор точкой рандеву для PIM Sparse mode (Randevouz Point):

ip pim rp-address 10.251.251.1

Это обязательное условие для того, чтобы маршрутизатор принимал поток и готов был его передать в MSDP. Dence mode для PIM не нужен.

Поднимаем MSDP:

ip msdp peer 198.18.85.41

После этого можем видеть что появились следующие маршруты:

sh ip mroute
IP Multicast Routing Table
!
(*, 226.100.10.1), 01:34:16/stopped, RP 10.251.251.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
!
(10.251.251.10, 226.100.10.1), 01:33:14/00:03:29, flags: TA
Incoming interface: GigabitEthernet0/1.112, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1.111, Forward/Sparse, 00:16:59/00:02:30
!
(*, 224.0.1.40), 01:34:16/00:02:32, RP 10.251.251.1, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1.111, Forward/Sparse, 01:34:16/00:02:32

Видно что маршруты построены.
Флаг A говорит о том, что нужный маршрут отдаётся в MSDP.

Далее можно посмотреть дебаг MSDP:

debug ip msdp detail

Где должно быть видно примерно следующее:

[b]Mar 20 12:25:03 192.168.100.30 6148274: Mar 20 08:25:02.957: MSDP(0): (10.251.251.10/32, 226.100.10.1)[/b]
Mar 20 12:25:03 192.168.100.30 6148275: Mar 20 08:25:02.957: MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
Mar 20 12:25:03 192.168.100.30 6148276: Mar 20 08:25:02.957: MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
Mar 20 12:25:03 192.168.100.30 6148277: Mar 20 08:25:02.957: MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
Mar 20 12:25:15 192.168.100.30 6148286: Mar 20 08:25:14.941: MSDP(0): Received 3-byte TCP segment from 198.18.85.41
Mar 20 12:25:15 192.168.100.30 6148287: Mar 20 08:25:14.941: MSDP(0): Append 3 bytes to 0-byte msg 1577 from 198.18.85.41, qs 1

То есть маршрут отдаётся.

В принципе, если с той стороны всё поднято, то мы увидим сразу приходящие от них join и трафик, уходящий в сторону удалённого маршрутизатора.

Далее к этому можно прикрутить ряд «бантиков». Допустим, отфильтровать всё ненужное. Чтобы ничего лишнего не передавалось и не анонсилось. Допустим, если у Вас подняты протоколы маршрутизации, использующие мультикаст MSDP будет этот мультикаст анонсить.
Делается это очень просто:

ip msdp sa-filter in 198.18.85.41 list 111
ip msdp sa-filter out 198.18.85.41 list 111
!
access-list 111 permit ip 10.251.251.0 0.0.0.255 any
access-list 111 deny ip any host 224.0.2.2
access-list 111 deny ip any host 224.0.1.3
access-list 111 deny ip any host 224.0.1.24
access-list 111 deny ip any host 224.0.1.22
access-list 111 deny ip any host 224.0.1.2
access-list 111 deny ip any host 224.0.1.35
access-list 111 deny ip any host 224.0.1.60
access-list 111 deny ip any host 224.0.1.39
access-list 111 deny ip any host 224.0.1.40
access-list 111 deny ip any 239.0.0.0 0.255.255.255
access-list 111 deny ip 10.0.0.0 0.255.255.255 any
access-list 111 deny ip 127.0.0.0 0.255.255.255 any
access-list 111 deny ip 172.16.0.0 0.15.255.255 any
access-list 111 deny ip 192.168.0.0 0.0.255.255 any
access-list 111 deny ip any 232.0.0.0 0.255.255.255
access-list 111 permit ip any any

Ну и для пущей паранои можно включить чтобы MSDP не просто отбрасывал маршруты от удалённого пира, но и писал их в «лог».

ip msdp cache-rejected-sa 100

Вот, вроде, и всё. Всё работает.
Нагрузка на 2851 при этом на 6 мегабитах трафика, летящих сквозь нее порядка 3% CPU.

 

Данная технология здорово упрощает логическую топологию сети, уменьшает количество точек настройки да и вообще – хорошо продается
В данной заметке я хочу поделиться с вами результатами нескольких экспериментов, проведенных над VSS в рамках отладки одной ошибки. Сразу оговорюсь: ошибка была незначительная, но требовала «разобрать» VSS. Мы с Siv решили заодно потестить, что происходит в случае разных сбоев. Итак:

При сборке стека VSS необходимо учитывать несколько основных моментов:
1. Одинаковые версии софта (IOS)
Начиная с IOS12.2(33)
2. Поддерживаемые модули
Начиная с 67xx (и свежее – 68хх, 69хх). Набивка шасси не обязательно должна быть одинаковая.
3. Супервайзоры и Feature card
VS-S720-10G-3C (VS-S720-10G-3CXL)
VS-Sup2T (XL)
DFC3C (DFC3CXL) и свежее (DFC4C).

4. минимум по 2 10Г модуля для связи супервизоров (они есть встроенные в указанные супервайзоры)
Можно и больше интерфейсов 10Г, задействовав дополнительные из линейных карт.
Я намеренно подробно не касаюсь вещей, описанных в гидах, например, здесь:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html

Будем считать, что вы собрали VSS по гидам и все заработало. Но вы точно не знаете (а проверять стремно), что будет, если что-то сломается. Вот и пробежимся по этим «если». Но для затравки напомню, какие основные шаги требуются при настройке.

При первоначальной настройке необходимо задать, какой из 65хх будет основным, а какой — запасным.
SW(config)# switch virtual domain #
SW(config-vs-domain)# switch {1|2}


После этого необходимо настроить на разных 65хх пару 10Г портов, связанных в etherchannel.
Важно: номера этих port-channel на разных коммутаторах должны быть РАЗНЫЕ! Иначе после объединения конфига будет ошибка. Объединение происходит при ПЕРВОНАЧАЛЬНОМ переходе к VSS.

SW# switch convert mode virtual

После этого конфигурация сохраняется в NVRAM и обе железки перезагружаются
Примечание: если надо вернуться обратно, то используем команду

SW# switch convert mode stand-alone

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

Теперь немного помучаем собранный VSS

Консоль, подключенная в запасной коммутатор, когда VSS уже собран, позволяет зайти в непривилегированный режим, но не позволяет ввести других команд, в частности enable. Это гарантированно не дает изменить настройку через вторичный коммутатор.

MSK-HQ-SC01-sdby>
Standby console disabled


При разрыве одной связи между супервайзорами только основной коммутатор ругается, но VSS остается жив без перерыва связи.
При разрыве всех связей из VSL ругаются оба коммутатора, при этом резервный тоже становится активным (даже приглашение меняется).

MSK-HQ-SC01-sdby>
Feb 28 17:12:38.717: %VSLP-SW2_SPSTBY-3-VSLP_LMP_FAIL_REASON: Te2/5/4: Link down
Feb 28 17:12:38.717: %VSLP-SW2_SPSTBY-2-VSL_DOWN: Last VSL interface Te2/5/4 went down
Feb 28 17:12:38.721: %VSLP-SW2_SPSTBY-2-VSL_DOWN: All VSL links went down while switch is in Standby role
Feb 28 17:12:38.721: %DUAL_ACTIVE-SW2_SPSTBY-1-VSL_DOWN: VSL is down - switchover, or possible dual-active situation has occurred
Feb 28 17:12:38.721: %PFREDUN-SW2_SPSTBY-6-ACTIVE: Initializing as Virtual Switch ACTIVE processor
Feb 28 17:12:39.377: %SYS-SW2_SPSTBY-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output.
Feb 28 17:12:40.549: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
Feb 28 17:12:40.549: %C6KPWR-SP-4-PSOK: power supply 2 turned on.
Feb 28 17:12:40.917: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 3, interfaces are now online
Feb 28 17:12:40.917: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 4, interfaces are now online
Feb 28 17:12:40.993: %OIR-SW2_SP-6-INSCARD: Card inserted in slot 5, interfaces are now online
MSK-HQ-SC01>en
Password:
MSK-HQ-SC01#sh run
Building configuration...

Важно: в нашем случае изначально был отключен механизм проверки split brain. Если такой механизм подключить, то разрыв etherchannel (VSL) не приводит к ситуации, когда оба коммутатора считают себя основными со всеми вытекающими неприятными последствиями.
При этом резервный коммутатор знает все конфигурации (и running и startup), помнит про все модули и порты на основном. Единственные отличия — в настройке принадлежности к VSS — кто первичный, а кто — вторичный коммутатор. Поэтому в частности размер файлов конфигурации не одинаковый на двух коммутаторах.
(кусочки настройки VSS)

platform hardware vsl pfc mode pfc3c
!
interface Port-channel77
no switchport
no ip address
switch virtual link 1
mls qos trust cos
no mls qos channel-consistency
!
interface Port-channel78
no switchport
no ip address
switch virtual link 2
mls qos trust cos
no mls qos channel-consistency
!
module provision switch 1
slot 1 slot-type 147 port-type 61 number 48 virtual-slot 17
slot 3 slot-type 156 port-type 31 number 24 virtual-slot 19
slot 5 slot-type 254 port-type 31 number 2 port-type 61 number 1 port-type 60 number 2 virtual-slot 21
slot 7 slot-type 284 port-type 60 number 16 virtual-slot 23
slot 9 slot-type 227 port-type 60 number 8 virtual-slot 25
!
module provision switch 2
slot 3 slot-type 156 port-type 31 number 24 virtual-slot 35
slot 4 slot-type 147 port-type 61 number 48 virtual-slot 36
slot 5 slot-type 254 port-type 31 number 2 port-type 61 number 1 port-type 60 number 2 virtual-slot 37
!
switch virtual domain 77
switch mode virtual
switch 1 priority 200
switch 2 priority 150
mac-address use-virtual
!
MSK-HQ-SC01# sh switch virtual role det
!
Switch Switch Status Preempt Priority Role Session ID
Number Oper(Conf) Oper(Conf) Local Remote
------------------------------------------------------------------
LOCAL 2 UP FALSE(N ) 100(100) ACTIVE 0 0
!
MSK-HQ-SC01#show switch virtual red
My Switch Id = 2
Peer Switch Id = 1
Last switchover reason = active unit removed
Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
!
Switch 2 Slot 5 Processor Information :
-----------------------------------------------
Current Software state = ACTIVE
Uptime in current state = 5 minutes
Image Version = Cisco IOS Software, s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(33)SXI5, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Sat 23-Oct-10 01:29 by prod_rel_team
BOOT = sup-bootdisk:s72033-adventerprisek9_wan-mz.122-33.SXI5.bin,1;
Configuration register = 0x2102
Fabric State = ACTIVE
Control Plane State = ACTIVE
!
Peer information is not available because
it is in 'DISABLED' state

Если при разобранном VSS подключить обратно линки, то по прошествии примерно 20 секунд, оба видят установление связи и запасной (вторичный) пытается уйти в перезагрузку.

Feb 28 17:20:32.212: %VSLP-SW2_SP-5-RRP_MSG: Role change from Active to Standby and hence need to reload

Если на запасном был какой-то несохраненный конфиг, созданный во время разорванного VSS, то перезагрузка сразу не происходит, о чем пишется в консоль. На выбор предлагается:
- сохраниться и перезагрузить
- либо принудительно набрать команду из специального режима:
(recovery-mode)#

возможно выбрать перезагрузку соседа (peer)

Feb 28 17:20:32.212: %VSLP-SW2_SP-5-RRP_UNSAVED_CONFIG: Ignoring system reload since there are unsaved configurations.
Please save the relevant configurations
Feb 28 17:20:32.212: %VSLP-SW2_SP-5-RRP_MSG: Use 'redundancy reload shelf' to bring this switch to its preferred STANDBY role
Feb 28 17:20:32.236: %DUAL_ACTIVE-SW2_SP-1-RECOVERY: Dual-active condition detected: Starting recovery-mode, all non-VSL and non-excluded interfaces have been shut down
!
MSK-HQ-SC01(recovery-mode)#redundancy ?
Redundancy exec commands:
config-sync Redundancy config sync commands
force-switchover Force a switchover
reload Redundancy Facility (RF) reload
!
MSK-HQ-SC01(recovery-mode)#redundancy reload ?
peer Reload peer unit
shelf Reload this entire shelf
!
MSK-HQ-SC01(recovery-mode)#redundancy reload shelf ?
shelf id

!
MSK-HQ-SC01(recovery-mode)#redundancy reload shelf
Warning:The standby is not up,continuing may lead to reload of the switch
!
System configuration has been modified. Save? [yes/no]: no
Reload this shelf [confirm]
Feb 28 17:22:17.046: %SYS-SW2_SP-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
!
Feb 28 17:22:17.046: %RF-SW2_SP-5-RF_RELOAD: Shelf reload. Reason: Admin reload CLI
Feb 28 17:22:17.046: %OIR-SW2_SP-6-CONSOLE: Changing console ownership to switch processor

Если же настройки не менялись, то перезагрузка происходит автоматом.
После перезагрузки основной коммутатор насаждает свой startup-config запасному, никакого merge (слияния) не происходит. В отличие от начального конфигурирования, когда при переводе в режим VSS оба конфига сливаются в один общий файл.

В-общем, шаг влево, шаг вправо – расстрел. В смысле, ошибиться практически невозможно, циска все за нас порешала и предусмотрела, так что смело можете собирать ваши виртуальные коммутаторы, лишь бы аппаратно и программно все карточки и модули поддерживали этот режим. Сломать что-либо крайне сложно

 

Две недели безжалостных экспериментов показали. Для меня работает. Смело рекомендую.

Ну и еще это… количество приседаний на балконе таки надо плавно довести до трех, знающие люди говорят что способствует.

Пока так.

Писано над Ла-Маншем.

И, как пишет наш текущий Гарант(R): фото айпад.

PS:  С удовольствием почитаю в комментах/ на форуме Ваши способы повышения эффективности.

 

К счастью, уже давно существует инструмент для автоматизации таких задач под названием expect. А еще существует более удобная обертка к нему под названием expect-lite, которую мы сегодня и рассмотрим. Для примера мы напишем скрипт, который будет будет заводить порты коммутатора в нужный нам VLAN.

Добываем софт

1. Ставим expect. Системно-зависимо, для UNIX есть в репозитариях/портах, для винды есть сборка с cygwin на сайте из пункта 2.
2. Качаем expect-lite с сайта авторов, распаковываем, кладем файл expect-lite в нужное нам место.

Основы

По сути, expect умеет отправлять строки, принимать что-то обратно и выполнять действия на основании принятого. Отправляемые строки начинаются с символом «>>», ожидаемые строки или содержащиеся в них выражения с «<». Если ожидаемая строка не приходит, скрипт завершается. Если использовать «<<» вместо «<», expect будет ожидать точного совпадения полученной строки с указанной. Все, что начинается с «#» считается комментарием и игнорируется.

Скрипту можно передавать параметры в виде аргументов expect-lite вида «var1=value1 var2=value2 …» и потом ссылаться на них в скрипте через $var1 и так далее.

Приступаем

Логинимся на железку

Создадим файл типа portsetup.els и напишем в него следующее:

>>telnet $host
<Username
>>$user
<Password
>>$password
<>
>>enable
<Password
>>$enablePassword
<#

Будем считать, что коммутатор живет по адресу 10.91.19.2, и на нем есть юзер cisco с паролем cisco. Попробуем выполнить:

./expect-lite host=10.91.19.2 user=cisco password=cisco enablePassword=cisco ./portsetup.els

Смотрим на результат:

Const: host = 10.91.19.2
Const: user = cisco
Const: password = cisco
Const: enablePassword = cisco
Warning: Remote Host=none, using Localhost
spawn bash
INFO: CONST FOUND: host = 10.91.19.2

[dmbaturin@arcueid:~/bin/expect-lite]$ telnet 10.91.19.2
Trying 10.91.19.2...
Connected to 10.91.19.2.
Escape character is '^]'.

User Access Verification

Username: INFO: CONST FOUND: user = cisco
cisco
Password: INFO: CONST FOUND: password = cisco

switch>enable
Password: INFO: CONST FOUND: enablePassword = cisco

switch#exit
Connection closed by foreign host.
[dmbaturin@arcueid:~/bin/expect-lite]$ 

##Overall Result: PASS

Скрипт успешно пообщался с железкой на тему аутентификации. Можно сразу заметить важную особенность: expect игнорирует все полученные строки, кроме явно указанных к ожиданию.

Приступаем к действиям

И тут мы сразу сталкиваемся с проблемой выбора. Порт может быть trunk или access, не писать же два разных скрипта для них. Для этой цели в expect-lite есть условия. Выглядят они следующим образом:

? условие ? действие если условие верно :: действие если условие неверно

Команды можно группировать с помощью квадратных скобок. С группами команд с обеих частях условия у expect-lite какие-то проблемы, поэтому лучше использовать два условия.

# Clear existing config
>>default interface $intf
<(config)

# Enter interface config
>>nterface $intf
<(config-if)

# Access mode
? $mode == access ? [
                        >>switchport mode access
                        <(config-if)
                        >>switchport access vlan $vlan
                        <(config-if)
                    ]   

# Trunk mode
? $mode == trunk ? [
                         >>switchport mode trunk
                         <(config-if)
                         >>switchport trunk allowed vlan $vlan
                         <(config-if)
                    ]

Добавим к этому корректный выход:

>>exit
<(config)
>>exit
<#
>>exit

# Команда *TERM завершает работу скрипта
*TERM

Собираем все вместе

*NOWARN
*NODEBUG
*NOINFO
*NOEXP_INFO

# Login to the switch
>>telnet $host
<Username
>>$user
<Password
>>$password
<>

# Enter privileged mode
>>enable
<Password
>>$enablePassword
<#

# Enter configuration mode
>>configure terminal
<(config)

# Clear interface config
>>default interface $intf
<(config)

# Enter interface config
>>interface $intf
<(config-if)

# Configure access mode
? $mode == access ? [
		        >>switchport mode access
                        <(config-if)
			>>switchport access vlan $vlan
			<(config-if)
		    ]

# Configure trunk mode
? $mode == trunk ? [
			 >>switchport mode trunk
			 <(config-if)
			 >>switchport trunk allowed vlan $vlan
			 <(config-if)
         	   ]

# Exit properly
>>exit
<(config)
>>exit
<#
>>exit

# Terminate the script
*TERM

Четыре команды в начале скрипта уменьшают количество выводимых отладочных сообщений до минимума.

Пробуем запустить:

./expect-lite host=10.91.19.2 user=cisco password=cisco enablePassword=cisco mode=access vlan=10 intf="fa 0/19" ./portsetup.els
Const: host = 10.91.19.2
Const: user = cisco
Const: password = cisco
Const: enablePassword = cisco
Const: mode = access
Const: vlan = 10
Const: intf = fa 0/19
Warning: Remote Host=none, using Localhost
spawn bash

expect-lite directive: *NOWARN 

expect-lite directive: *NODEBUG 

expect-lite directive: *NOINFO 

expect-lite directive: *NOEXP_INFO 

[dmbaturin@arcueid:~/bin/expect-lite]$ telnet 10.91.19.2
Trying 10.91.19.2...
Connected to 10.91.19.2.
Escape character is '^]'.

User Access Verification

Username: cisco
Password: 

switch>enable
Password:
switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)#default interface fa 0/19
Interface FastEthernet0/19 set to default configuration
switch(config)#interface fa 0/19
switch(config-if)#switchport mode access
switch(config-if)#switchport access vlan 10
switch(config-if)#exit
switch(config)#exit
switch#
expect-lite directive: *TERM

Для большинства целей должно хватить. А для дальнейшего ознакомления на сайте автора есть подробная документация.

 

Топология сети примерно следующая:
RTA и RTC – роутеры Cisco. Минимальный конфиг у них такой:

interface FastEthernet0/0
ip address 10.1.1.2 255.255.255.252
duplex auto
speed auto

interface FastEthernet0/1
no ip address
duplex auto
speed auto

interface FastEthernet0/1.10
encapsulation dot1Q 10
ip address 192.168.0.1 255.255.255.0

interface FastEthernet0/1.20
 encapsulation dot1Q 20
 ip address 192.168.1.1 255.255.255.0

interface FastEthernet0/1.30
 encapsulation dot1Q 30
 ip address 192.168.2.1 255.255.255.0

interface FastEthernet0/1.40
 encapsulation dot1Q 40
 ip address 192.168.3.1 255.255.255.0

router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.1.1.2 0.0.0.0 area 0
 network 192.168.0.0 0.0.3.255 area 0

interface FastEthernet0/0
no ip address
duplex auto
speed auto

interface FastEthernet0/0.100
encapsulation dot1Q 100
ip address 192.168.10.1 255.255.255.0

interface FastEthernet0/0.200
encapsulation dot1Q 200
ip address 192.168.11.1 255.255.255.0

interface FastEthernet0/1
ip address 172.1.1.2 255.255.255.252
duplex auto
speed auto

router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/1
 network 172.1.1.2 0.0.0.0 area 1
 network 192.168.10.0 0.0.0.255 area 1
 network 192.168.11.0 0.0.0.255 area 1

RTB – роутер Huawei, вот его то и будем настраивать. Для начала на роутере Huawei нужно настроить сетевые интерфейсы и присвоить им IP адреса. Делаем это так:

<RTB>system-view
[RTB]interface Ethernet 0/0/0
[RTB-Ethernet0/0/0]ip address 10.1.1.1 30
[RTB-Ethernet0/0/0]q
[RTB]interface Ethernet 0/0/1
[RTB-Ethernet0/0/1]ip address 172.1.1.1 30
[RTB-Ethernet0/0/1]q
[RTB]interface Ethernet 0/1/0
[RTB-Ethernet0/1/0]ip address 192.168.20.1 24
[RTB-Ethernet0/1/0]q
[RTB]interface Ethernet 0/1/1
[RTB-Ethernet0/1/1]ip address 192.168.21.1 24

Активировать интерфейсы не надо, в отличие от роутеров Cisco они по умолчанию в активном состоянии.
Чтобы каждый роутер имел уникальный идентификатор в LSDB, нужно его задать:

[RTB]router id 127.1.1.2

Вообще-то, эта команда опциональная. Если ее не ввести, то маршрутизатор сам определит идентификатор на основе большего IP адреса своего loopback интерфейса, ну а если и лупбек не настроен, то будет использован больший IP адрес физического интерфейса.
Теперь переходим к поднятию ospf на роутере Huawei:

[RTB]ospf

На самом деле, нужно указать еще и id процесса ospf на роутере, если этого не сделать, то по умолчанию process-id будет 1.
Чтобы настроить area и включить сетевые сегменты в нее, нужно сделать следующее:

[RTB-ospf-1]area 0 <<определяем арию и переходим в режим ее настройки
[RTB-ospf-1-area-0.0.0.0]network 10.1.1.1 0.0.0.0 <<помещаем сеть в арию 0
[RTB-ospf-1-area-0.0.0.0]network 192.168.20.0 0.0.0.255
[RTB-ospf-1-area-0.0.0.0]area 1
[RTB-ospf-1-area-0.0.0.1]network 172.1.1.1 0.0.0.0
[RTB-ospf-1-area-0.0.0.1]network 192.168.21.0 0.0.0.255

Описание сетевого сегмента состоит из двух частей, это идентификатор сети и шаблонная маска (wildcard mask).
Небольшой тюнинг поможет запретить отправку и прием OSPF сообщений через интерфейсы, где нет OSPF маршрутизаторов:

[RTB-ospf-1]silent-interface Ethernet0/1/0
[RTB-ospf-1]silent-interface Ethernet0/1/1

Вот вроде все. Теперь можно проверить отношения смежности между роутером Huawei и устройствами Cisco. Для этого делаем следующее:

[RTB] display ospf peer
                OSPF Process 1 with Router ID 127.1.1.2
                               Neighbors
  Area 0.0.0.0 interface 10.1.1.1(Ethernet0/0/0)'s neighbor(s)
  RouterID: 192.168.3.1     Address: 10.1.1.2        <Opaque-capable>
        State: Full  Mode: Nbr is Master  Priority: 1
        DR: 10.1.1.2  BDR: 10.1.1.1
        Dead timer expires in 33s
        Neighbor has been up for 00:06:39
 
Area 0.0.0.1 interface 172.1.1.1(Ethernet0/0/1)'s neighbor(s)
  RouterID: 192.168.11.1    Address: 172.1.1.2       <Opaque-capable>
        State: Full  Mode: Nbr is Master  Priority: 1
        DR: 172.1.1.1  BDR: 172.1.1.2
        Dead timer expires in 37s
        Neighbor has been up for 00:02:06

Ну что, видим, что отношение смежности установлено. А что же в таблице маршрутизации? Ее вывод можно посмотреть вот так:

[RTB]display ip routing-table
Routing Table: public net
Destination/Mask   Protocol Pre  Cost        Nexthop         Interface
---вывод пропущен---
192.168.0.1/32     OSPF     10   2           10.1.1.2        Ethernet0/0/0
192.168.1.1/32     OSPF     10   2           10.1.1.2        Ethernet0/0/0
192.168.2.1/32     OSPF     10   2           10.1.1.2        Ethernet0/0/0
192.168.3.1/32     OSPF     10   2           10.1.1.2        Ethernet0/0/0
192.168.10.1/32    OSPF     10   2           172.1.1.2       Ethernet0/0/1
192.168.11.1/32    OSPF     10   2           172.1.1.2       Ethernet0/0/1

И в заключение. Проверим коннективити с использованием команды ping от IP адреса 192.168.21.1 на маршрутизаторе Huawei на адрес 192.168.0.1 маршрутизатора Cisco:

[RTB]ping -a 192.168.21.1 192.168.0.1
  PING 192.168.0.1: 56  data bytes, press CTRL_C to break
    Reply from 192.168.0.1: bytes=56 Sequence=1 ttl=255 time=2 ms
    Reply from 192.168.0.1: bytes=56 Sequence=2 ttl=255 time=1 ms
    Reply from 192.168.0.1: bytes=56 Sequence=3 ttl=255 time=2 ms
    Reply from 192.168.0.1: bytes=56 Sequence=4 ttl=255 time=2 ms
    Reply from 192.168.0.1: bytes=56 Sequence=5 ttl=255 time=2 ms

  --- 192.168.0.1 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 1/1/2 ms