Автоматическая синхронизация конфигураций 2-х AIP-SSM модулей.

Неизвестно по какой причине, но AIP-SSM модули для ASA не умеют синхронизировать свои конфиги, когда "асы" стоят в фаиловере. Поэтому изменения конфигурации необходимо производить на двух модулях. Неудобно, большой риск допустить ошибку и вообще не комильфо. Можно, однако, сливать конфигурациию с одного модуля на FTP и оттуда заливать ее на второй модуль, при этом настройки, касающиеся сетевой части модуля можно оставить прежними. Эта опция и легла в основе автоматической синхронизации конфигураций.

Cisco IOS Release 15.0(1)M

А между тем в пятницу, 2 октября, cisco выпустила новый релиз IOS'a - 15.0М.
Список поддерфиваемых платформ:

•Cisco VG202 and VG204 voice gateways
•Cisco VG224 analog gateways
•Cisco VGD 1T3 voice gateways
•Cisco AS5350XM universal gateways
•Cisco AS5400XM universal gateways
•Cisco IAD2801 series integrated access devices
•Cisco IAD2430 series integrated access devices
•Cisco 800 series routers
•Cisco 1800 series routers
•Cisco 2800 series integrated services routers
•Cisco 3200 series rugged integrated services routers
•Cisco 3800 series integrated services routers
•Cisco 7000 family routers

Список новых программных и аппаратных фич впечатляет.
Release Notes for Cisco IOS Release 15.0M
New Features in Cisco IOS Release 15.0(1)M
Configuration Guides
Загнал образ в динамипс, работает для 7200. Будем тестировать.

Catalyst 6500, netflow и vrf

Есть Catalyst 6500 с настроенными vrf'ами. Vrf ONE - корпоративный интернет, vrf TWO - управление устройством и другие сервисы. Необходимо снимать статистику по netflow для корпоративных пользователей.

Казалось бы, тривиальная задача - снять нетфлоу с interface vlan. Однако не тут то было. Не имея опыта работы с нетфлоу на каталистах, посмотрел на cisco.com решение. Итак, понеслась

Проблема с двумя точками редистрибьюции маршрутов

Допустим, мы имеем в сети подобную схему:

Имеем 2 части сети, одна пусть будет BGP Backbone, вторая - конечные пользователи с EIGRP. Маршруты из BGP редистрибьютируются в EIGRP и наоборот. Для обеспечения необходимой избыточности существуют две точнки подключения конечного пользователя к backbone через R2 и R3, которые еще и соеденены между собой.
Основная проблема в таких сетях - петли маршрутов (routing loops), которые происходят из-за прозрачной двунаправленной редистрибьюции одного протокола в другой. Как это происходит?

Везет как утопленнику.

Однако же с VSS-ом приключилась беда.
Сразу же повле установки и перехода на новое ядро все было отлично. Заменили первый коммутатор который благополучно проработал в паре со старым неделю. Затем заменили второй. VSS поднялся, дистрибьюшн подключился etherchannell'ами, и все вместе весело работало. Сутки...

VSS Failiure Scenarios. Dual-active recovery.

Тестирование VSS проводилось по четырем сценариям. Первый - это падение одного из линков multichassis etherchannel.



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

Cat6500 VSS

Давно уже было желание протестировать Cat6500 в режиме Virtual Switch, но все руки не доходили. И вот дошли, наконец.

Итак, имеем 2 Cisco Catalyst 6500 Series с Supervisor Engine 720-10G VSS на борту. Необходимо объединить их в виртуальный свитч, поднять Multichassis Etherchannel между получившимся виртуальным свитчем и distribution. В качестве distribution layer будем использовать 2950, т.к. под рукой ничего серьезней не оказалось, да и надо всего лишь протестировать etherchannel.

Немного теории. VSS представляет собой систему, когда два коммутатора объединяются посредствам 2-х 10-гигабитных линков VSL (Virtual Switch Link) в одно логическое устройство с централизованным управлением. Помимо управления это позволяет отказаться от использования протоколов избыточности 2-го и 3-го уровней, а использовать простой etherchannel. А это в свою очередь обеспечивает время восстановления 200 мс.

TCP and UPD port numbers

Хорошая табличка с номерами TCP и UDP портов и их описанием. Закину в Links еще пожалуй.
TCP and UPD ports

В пятницу вечером...

...или в субботу утром.

Как обычно, по закону подлости, если что-либо нехорошее случается, то это непременно случится в пятницу. Вот и сегодня, вернее уже вчера, утром почему-то упал супервайзер 4500. И не поднялся. Четырехтонник, конечно, взлетел на резервном, но планы на вечер пятницы были однозначно нарушены. Пришлось выходить ночью, устранять проблему. Плюс к этому выяснилось, что он ни с того ни с сего свитч вдруг перезагрузился.
Причину, к сожалению, так и не нашли. В логах не было ничего, кроме констатации факта, что супервайзер отвалился и произошел stateful switchover. Пришлось лечить симптомы, просто достали модуль и воткнули назад. Все поднялось без проблем, как будто ничего и не произошло.
И еще предстоит разобраться с чего вдруг среди ночи на практически незагруженном коммутаторе такая картина:
Вот такая мистика творится сегодня целый день...
Зато получил бесценный опыт общения с четырехтонником. Заодно и IOS обновили.