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 обновили.