FAQ - Анализ трафика и управление сетью

Аппаратные коммутаторы типа 4000/4500 - 6000/6500 производят обработку пакетов данных с помощью ASIC (application-specific integrated circuits) и могут экспортировать NetFlow, если эта функция встроена в них. Иногда требуется дополнительная плата с NetFlow. Ниже приведена дополнительная информация.

Catalyst 4k/4000

Модель	Поддержка NetFlow	IOS	Версия NetFlow
Supervisor I, II, II Plus, III	нет	-	-
Supervisor IV	опционально, требуется NetFlow Daughter Card	12.1.(19)EW	V1, V5, V8
Supervisor V	опционально, требуется NetFlow Daughter Card	12.2(25)SG	V1, V5, V8
Supervisor V-10GE	встроенная	12.2(25)EW	V5, V8

Catalyst 6k/6000

Конфигурация может быть достаточно сложной для этих моделей, в зависимости от кода, который работает у вас на Cat6k. Доступные опции - это режимы CATOS, гибридный и обычный (native), все имеют различные функции и возможности. Существуют также различные версии экспорта NetFlow, если экспорт осуществляется из SP или RP (медленный путь / быстрый путь).

Модель 12000

Модель	Поддержка NetFlow	IOS	Версия NetFlow
12000	да	12.0(14)S	V5
12000	да	12.0(6)S	v8
12000	да	12.3(1), 12.0(24)S, 12.2(18)S, 12.3(2)T	v9

Другие устройства Cisco и роутеры на базе ПО

В основе своей все устройства Cisco на базе ПО с Cisco IOS могут поддерживать экспорт NetFlow v5 (версия IOS 11.1CA или более поздняя). Важно: Но не все могут конфигурироваться.

Модель	Поддержка NetFlow	IOS	Версия NetFlow
Все на базе ПО	возможна	11.1CA или более поздняя	v5
Cisco 800, 1700, 2600, 3600, 3700, 6400, 7200, 7300, 7500	да	12.3(1), 12.0(24)S, 12.2(18)S, 12.3(2)T	v9

Дополнительно смотрите NetFlow Services Solutions Guide.

Как влияет включение NetFlow на производительность моего роутера или коммутатора?

Чтобы получить точную информацию, каким образом влияет включение NetFlow на производительность вашего роутера или коммутатора Cisco, посмотрите следующий документ - NetFlow Performance Analysis или обратитесь к NetFlow Bandwidth Calculator на сайте Lancope.

Как долго я должен ждать, пока будет опубликован первый график (отчет)?

Менее 5 минут. Только убедитесь, что вы правильно сконфигурировали ваш маршрутизатор или коммутатор.

Полная утилизация интерфейса кажется заниженной. Почему это может происходить?

Убедитесь, что NetFlow включен на всех физических интерфейсах устройства. Это не относится к виртуальным интерфейсам, поскольку там включение произойдет автоматически после включения NetFlow на физическом интерфейсе.
Если устройство не может постоянно посылать пакеты NetFlow, то необходимо войти в устройство Cisco и проверить есть ли там проблема. Наберите следующую команду:
Router_name>sh ip flow export
Поищите сообщение что-то типа "294503 export packets were dropped due to IPC rate limiting". Если этот счетчик постоянно увеличивается, то оборудование не может удовлетворять требованиям по экспорту данных.
Команда ниже разрывает долгоживущие потоки на 1-минутные сегменты. Вы можете выбрать любой интервал в минутах между 1 и 60; если вы оставите значение по умолчанию (30 мин), то это может привести к появлению пиков в отчете по утилизации. Вот эта команда:
ip flow-cache timeout active 1
Команда внизу гарантирует, что потоки, которые завершились, экспортируются своевременно. По умолчанию интервал 15 секунд. Вы можете выбрать любое знаение между 10 и 600. Отметим, что если вы выберете значение больше 250 секунд, то ваш анализатор трафика может показывать заниженный уровень трафика.
Команда: ip flow-cache timeout inactive 15
NetFlow v5 экспортирует только IP-трафик (т.е. не IPX, и т.п.) и никакой трафик 2-го уровня (layer 2) не экспортируется.

Чем отличается OpenFlow от NetFlow?

В действительности OpenFlow (http://www.openflow.org/wp/learnmore/) и NetFlow это две различные технологии, которые предназначены для разных целей. Для лучшего понимания поясним некоторые различия.
Что такое OpenFlow?
OpenFlow - методология, используемая для передачи (форвардинга) пакетов через сетевые устройства, такие как коммутаторы и роутеры. OpenFlow предоставляет открытый протокол для создания таблиц потоков в коммутаторах и роутерах. Это помогает исследовать потоки и контролировать их.
OpenFlow помогает создавать высоконадежные скоростные сети с точной передачей пакетов в нужные приемники.
Что такое NetFlow?
NetFlow это разработанный Cisco протокол, который помогает осуществлять в сети аудит транзакций (трафика), которые проходят через сетевые устройства. NetFlow (и др. потоковые форматы типа sFlow, IPFIX) помогает определять основных пользователей сети, основные сетевые приложения, протоколы и порты, утилизацию сети. Преимуществами экспорта NetFlow являются:
   • Аналитика трафика
   • Анализ поведения сети
   • Мониторинг полосы пропускания
   • Планирование емкости
   • Анализ трендов
   • Мониторинг производительности приложений

Почему возникает путаница?
Путаница возникает из-за того, что обе технологии используют термин "поток" в своем наименовании и используют потоки в устройствах для достижения своих целей. OpenFlow использует поля типа "адрес источника", "адресат", "MAC-адрес источника", "MAC-адрес приемника", "порт", "протокол" для эффективного перемещения данных через коммутаторы.
В то время как NetFlow использует потоки с упомянутыми выше полями для мониторинга трафика, аудита и планирования емкости.
Эти цели принципиально разные.
Если вам необходим метод эффективного форвардинга пакетов по сети, то вам весьма подходит OpenFlow. Если ваша цель мониторинг трафика и анализ безопасности, то лучший выбор - NetFlow.

Что лучше, sFlow или NetFlow?

Вопрос, что лучше, NetFlow или sFlow, обсуждался уже много раз и пришло время закончить дебаты. Вот, что мы думаем:
Люди, которые утверждают, что sFlow лучше, чем NetFlow, это те, кто не использовал и то и другое и не видит разницы.
И это мнение не какого-то определенного производителя, а скорее понимание, сформированное годами работы на этом поприще. Многие заказчики, хотят, чтобы "sFlow вел себя так же, как NetFlow". Действительно, многие клиенты, которые сталкиваются с необходимостью иметь дело с выборками данных, предпочитают внедрить генераторы NetFlow (иногда называемые "зондами (пробами) потоков"), такие как nBox или Cisco NGA, для создания NetFlow на SPAN-портах, чем иметь дело с трудностями, которые доставляет sFlow.
Не поймите нас превратно, NetFlow и IPFIX также доставляют проблемы. Механизм кэширования и экспорта NetFlow очень сложен для корректного внедрения, требует много ресурсов для своей работы, примеров внедрения с различным результатом очень много. NetFlow стал жертвой своей популярности. Каждый производитель хочет добавить поддержку NetFlow в свои роутеры, коммутаторы, файерволы, балансировщики нагрузки и оптимизаторы WAN, но они очень часто не обращаются к профессионалам и стараются сделать все сами, добиваясь того, что экспорт не всегда работает корректно. sFlow не имеет проблем со стандартизацией в первую очередь потому, что только несколько производителей его внедрили.
Но преимущества NetFlow существенно перевешивают его недостатки.

Нужна вся история
Хотя выборка и может использоваться с NetFlow, но она не является обязательным требованием. Люди вообще-то не любят выборки данных. Особенно люди из департамента безопасности. Действительно, если у вас есть достаточное количество пакетов за долгий период времени, вы, в принципе, можете работать на нужном уровне, но когда вы пытаетесь поймать проникновение, которое произошло за одну двухминутную HTTP SQL транзакцию, то вам необходимо иметь "всю историю".
Технология на базе выборок просто не может это обеспечить. Оно может читать только каждое 128 слово в "книге". И к концу чтения вы будете знать сюжетную линию, что делали действующие лица, но не более того. Аналитикам безопасности не хочется иметь дело с каждым 128 пакетом, они хотели бы иметь их все.

Лучшая поддержка коллекторов
Примерно 95% заказчиков потоковых коллекторов обращаются за поддержкой на тему NetFlow/IPFIX. Почти все оборудование поддерживает эти технологии и почти вся поддержка имеет отношение к этому. Конечно, заказчикам нужна поддержка и sFlow, но таких обращений мало. Поскольку все подобные технологии продвигаются вперед именно за счет потребностей заказчиков, то неудивительно, что производители больше развивают NetFlow.

Лучшая поддержка производителей
Кроме того, большая часть производителей внедряет поддержку NetFlow во всех своих новых продуктовых линейках. Например, продукты компании Cisco Cat6k w/Sup2T или Catalyst 4500E w/Sup7E. Даже другие компании занимаются инновациями на фронте NetFlow. Enterasys добавил мощную аппаратную поддержку NetFlow в свои коммутаторы серии r S Series и K Series . Аппаратная поддержка NetFlow исключает одну из основных проблем NetFlow - ее влияние на загрузку процессора.

Больше полей, больше инноваций
Необходимо также учесть, что за последние годы Cisco приложило много усилий для развития NetFlow. Flexible NetFlow, NBAR, MediaNet, ASA NAT export, PfR - можно долго продолжать список расширений. sFlow ничего подобного не имеет и я не уверен, что кто-либо работает над тем, чтобы сделать его лучше.

Файерволы адаптируют NetFlow
Тенденция развития файерволов - это размещение в местах, где более всего нужна видимость сети: в точках агрегирования и ключевых местах контроля доступа. NetFlow отлично подходит для измерения и мониторинга ключевых точек в сети. Производители файерволов наконец это поняли и сейчас фаерволы повсеместно включают в себя поддержку NetFlow/IPFIX. За исключением Fortinet, все производители фаерволов выбрали поддержку NetFlow или IPFIX. А именно: PaloAlto, CheckPoint, SonicWall и, естественно, Cisco ASA. Почему файерволы предпочитают NetFlow? Именно потому, что заказчикам нужна история целиком, а не выборка из нее.

NetFlow/IPFIX хорошо работает со всеми типами событий, не только с TCP/IP
sFlow фундаментально ориентирован на фреймы Ethernet. В своей сути sFlow создан для выборки пакетов. Не более того, и не менее. IPFIX и NetFlow v9 очень гибкие. NetFlow/IPFIX могут использоваться для экспорта любого типа структурированных данных. Действительно, поля переменной длины IPFIX могут даже использоваться для экспорта полуструктурированных данных, таких как URL, особенные для каждого вендора строки, или имена хостов. Для одновременного экспорта нескольких различных наборов данных могут использоваться различные шаблоны. sFlow не является достаточно гибкой технологией, удовлетворяющей современные сети. Несмотря на работу людей из sFlow.org, sFlow все-таки не так развивается, как IPFIX.

NetFlow хорошо работает поверх WAN, sFlow - нет
Маленький "грязный секрет" об sFlow, который предпочитают умалчивать, заключается в том, что количество sFlow, покидающего роутер прямо пропорционально скорости - количеству пакетов в секунду. Т.е. чем выше уровень bps на удаленном сайте, тем выше уровень записей sFlow, покидающих сайт. NetFlow, в свою очередь, базируется на количестве активных соединений, а не на скорости пакетов. Если я передаю файл в 500 Мб из А в В, то sFlow создаст несколько тысяч пакетных выборок, тогда как NetFlow создаст только два 46-байтных записи. Это именно тот пункт, где для большинства заказчиков решается вопрос смены технологии. Вполне возможно переполнить соединение WAN выборками sFlow. И, поскольку sFlow передается через двунаправленный UDP, нет никакой возможности сказать экспортеру замедлить передачу.

Что лучше? NetFlow или sFlow

Что лучше использовать для мониторинга: SNMP, NetFlow или Packet Sniffer?

Лучшее решение для вас зависит от вашей сети и доступных ресурсов.

SNMP

SNMP (Simple Network Management Protocol) - базовое средство для сбора данных по использованию сети и полосы пропускания. Мониторинг использования полосы пропускания маршрутизаторами и коммутаторами порт за портом - это наиболее обычное использование SNMP, так же как мониторинг различных устройств типа памяти, процессоров и т.п.
   • Рекомендуется для большинства стандартных ситуаций
   • Не поддерживает дифференциацию трафика в зависимости от услуг/протокола
   • Вызывает очень небольшую нагрузку на процессор

Packet Sniffer

Используя этот инструмент можно проверять все пакеты данные, проходящие через сетевую карту локальной машины. Для того, чтобы контролировать весь трафик, необходимо чтобы этот тарфик проходил через сниффер (т.е. подключать его к контролируемому порту коммутатора).
• Рекомендуется, когда необходимо разделять информацию о трафике по услугам/протоколу.
• Создает значительную нагрузку на процессор.

xFlow (NetFlow/sFlow)

NetFlow может использоваться с большинством роутеров Cisco для измерения, в частности, использования полосы пропускания. Эта технология наиболее сложная из упомянутых, но и наиболее мощная и комплексная для высокозагруженных сетей.
• Рекомендуется для больших и загруженных сетей и продвинутых специалистов.
• Требует дополнительных настроек в роутерах Cisco (вам необходимо указать роутеру посылать пакеты NetFlow в соответствующий коллектор/анализатор NetFlow).

Можно ли осуществлять мониторинг файервола Cisco ASA с помощью NetFlow v9?

Поддержка NetFlow на этом устройстве отличается от того, как это сделано на других системах Cisco. Эта технология называется "NetFlow Security Event Logging" (NSEL) и первоначально была внедрена на Cisco ASA 5580. После выхода новой версии операционной системы (ASA 8.2.x или более поздняя), она поддерживается на всех моделях Cisco ASA.
В действительности ASA NetFlow первоначально не предполагалось использовать для анализа трафика в реальном времени (она создавалась для мониторинга событий безопасности). Но, тем не менее, эта технология годится и для этих целей. Если сравнивать с "нормальным" NetFlow, есть несколько ограничений:

Вы не сможете видеть данные в реальном времени. NSEL отсылает пакет данных NetFlow только после того, как соединение будет закрыто. Если соединение активно в течение минут или часов, то ASA отправит только один пакет за все это время. Это вызовет появление пиков в графических отчетах анализатора, поскольку будет видна разница между соседними событиями.
Потоки в ASA двунаправленные (все счетчики потоков будут считать потоки как туда, так и обратно).
Мониторинг NetFlow v9 на ASA вызывает загрузку процессора.

Ниже вы можете видеть сравнение результатов мониторинга полосы пропускания для трех разных методов. Здесь показан трафик, проходящий через ASA, измеряемый с помощью SNMP (трафик на порту WAN), NetFlow v9 (анализируя пакеты NetFlow на следующем роутере Cisco) и NetFlow v9 (собственный NetFlow v9 на Cisco ASA).

Пример настройки NetFlow на Cisco ASA можно найти здесь.

Использованы материалы компании Paessler

Что такое управление производительностью приложений?

В чем цель идеальной системы управления производительностью приложений (Application Performance Management, APM)? Означает ли это доступность в 99.999%? Или что-то еще? На самом деле могут быть различные цели в зависимости от различных потребностей бизнеса, и APM может даже зависеть от собственно приложений.

Итак в чем цель APM?
Цель должна сначала созреть в вашей голове и лишь потом реализоваться в технологиях. Вы уже составили список параметров, которые вы надеетесь получить с помощью APM? Такой подход может существенно облегчить получение необходимого результата от решения. Вот несколько примеров.

Доступность в минимум 99.999% с минимальным временем определения причины инцидента (Mean Time To Know, MTTK) и временем исправления проблемы (Mean Time To Repair, MTTR).
Время отклика меньше, чем 50 миллисекунд для 95% запросов приложения.
Изоляция проблем конечного пользователя в пределах трех минут.

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

Отслеживание и определение трендов наиболее популярных типов поведения (например, объем трафика)
Исторический тренд как ресурсы потребляются серверами и приложениями, необходимыми для обслуживания пользователей.
Возможность отслеживать опыт конечного пользователя (End User Experience, EUE) и управление опытом пользователя (User Experience Management, UEM)*. Терминология Gartner.
Тренды доступности приложений. Эта возможность включает в себя детали того, как высчитывается время доступности.
Долговременные записи времени отклика каждой конечной системы для использования различными функциями в режиме день/неделя/месяц.
Тренды количества подключенных пользователей.
Тренд трафика и задержки транзакций между серверами в виртуальной среде.
Связывание трафика пользователя с пользовательским именем.
Открытый интерфейс для аналитических систем к собранной информации.

Можно ли ваши приложения контролировать?
Что означает, что приложение позволяет себя контролировать? Как мы можем осуществлять мониторинг, чтобы убедиться, что они корректно работают и обслуживают 100% пользователей? Что, если соединение закроется и как мы это обнаружим? Что, если процесс "подвиснет", как мы узнаем об этом? Есть несколько вопросов, которые необходимо задать о приложении, которое мы предполагаем контролировать:

Под управлением какой ОС работает приложение?
Может оно работать в среде VMware?
Используется кластеризация серверов?
Как много процессов поддерживает каждый сервер, какие это процессы и в чем их функции/взаимоотношения?
Поддерживает приложение логи? Могут они отсылаться как syslogs?
Будет использоваться SAN?
Приложение на базе WEB или традиционное?
Использует приложение TCP/IP или UDP/IP?

Выбор APM
Не удивляйтесь, если вам придется инвестировать в несколько решений для достижения своих целей. Всегда поинтересуйтесь бесплатным тестированием, чтобы убедиться, что вы получаете нужную функциональность и хорошую поддержку производителя. Идеальным выбором для APM сейчас является решение на базе IPFIX и NetFlow, поскольку:

NetFlow использует IP SLA для тестирования транзакций (например, URL).
Маршрутизаторы Cisco могут конфигурироваться для экспорта метрик производительности со скоростью соединения каждой конечной системы.
В большинстве случаев syslog и event logs могут экспортироваться с помощью IPFIX, который коррелируется с традиционным NetFlow.
VMware и виртуальные коммутаторы поддерживают экспорт NetFlow и зонды NetFlow, при необходимости.

Терминология Gartner.

Какие функции не поддерживаются NBAR?

Не поддерживаются следующие функции:

Более, чем 24 конкурентных URL, хоста или совпадений типов MIME
Совпадение болеше первых 400 байт в URL
Не IP-трафик
Мультикаст и другие не-CEF режимы коммутации
Фрагментированные пакеты
Конвеерные длительные HTTP-запросы
URL/HOST/MIME-классификацию с безопасным HTTP
Пакеты, исходящие из или направленные в роутеры с включенным NBAR

Где существуют ограничения для конфигурирования NBAR?

Вы не можете конфигурировать NBAR на следующих логических интерфейсах:

Fast EtherChannel
Интерфейсы, использующие туннелинг или шифрование
VLAN
Dialer interfaces
Multilink PPP

Примечание: NBAR конфигурируется на VLAN для Cisco IOS Release 12.1(13)E, но поддерживается только на пути программной коммутации.

Зависит ли производительность от количества интерфейсов, на которых включен NBAR? Влияет ли на производительность скорость линии на интерфейсе со включенным NBAR?

Нет. Производительность NBAR не зависит от количества интерфейсов, на которых включен NBAR или скорости соединения. Производительность зависит от количества пакетов, которое должен движок NBAR проверить, насколько глубоко в пакет он должен "заглянуть" для проведения проверки.

Я могу выполнить команду ip nbar protocol-discovery на роутере и видеть результаты. Но NFA сообщает, что мой роутер не поддерживает NBAR. Почему?

Ранние версии IOS поддерживают NBAR discovery только на роутере. Поэтому вы можете выполнять эту команду на роутере и видеть результат. Но поддержка NBAR Protocol Discovery MIB появилась только на более поздних версиях. Это необходимо для сбора данных через SNMP. Проверьте, поддерживает ли IOS вашего роутера CISCO-NBAR-PROTOCOL-DISCOVERY-MIB.

Как я могу проверить, поддерживает ли роутер CISCO-NBAR-PROTOCOL-DISCOVERY-MIB?

а) Вы можете проверить это по следующей ссылке http://tools.cisco.com/ITDIT/MIBS/AdvancedSearch?MibSel=250073

б) Вы можете выполнить команду show snmp mib | include cnpd на роутере, чтобы узнать какие объекты MIB внедрены на роутере. Если роутер поддерживает CISCO-NBAR-PROTOCOL-DISCOVERY-MIB, то упомянутая команда выдаст следующие объекты.

cnpdStatusEntry.1
cnpdStatusEntry.2
cnpdAllStatsEntry.2
cnpdAllStatsEntry.3
cnpdAllStatsEntry.4
cnpdAllStatsEntry.5
cnpdAllStatsEntry.6
cnpdAllStatsEntry.7
cnpdAllStatsEntry.8
cnpdAllStatsEntry.9
cnpdAllStatsEntry.10
cnpdAllStatsEntry.11
cnpdAllStatsEntry.12
cnpdTopNConfigEntry.2
cnpdTopNConfigEntry.3
cnpdTopNConfigEntry.4
cnpdTopNConfigEntry.5
cnpdTopNConfigEntry.6
cnpdTopNConfigEntry.7
cnpdTopNConfigEntry.8
cnpdTopNStatsEntry.2
cnpdTopNStatsEntry.3
cnpdTopNStatsEntry.4
cnpdThresholdConfigEntry.2
cnpdThresholdConfigEntry.3
cnpdThresholdConfigEntry.4
cnpdThresholdConfigEntry.5
cnpdThresholdConfigEntry.6
cnpdThresholdConfigEntry.7
cnpdThresholdConfigEntry.8
cnpdThresholdConfigEntry.9
cnpdThresholdConfigEntry.10
cnpdThresholdConfigEntry.12
cnpdThresholdHistoryEntry.2
cnpdThresholdHistoryEntry.3
cnpdThresholdHistoryEntry.4
cnpdThresholdHistoryEntry.5
cnpdThresholdHistoryEntry.6
cnpdThresholdHistoryEntry.7
cnpdNotificationsConfig.1
cnpdSupportedProtocolsEntry.2

Могу ли я использовать bridged IP traffic NetFlow на PFC3A?

Нет, режим PFC3A не поддерживает NetFlow bridged IP traffic. В этом режиме NetFlow собирает статистику только для маршрутизованного трафика. С помощью PFC3B или PFC3BXL вы можете сконфигурировать NetFlow для сбора статистики как для маршрутизованного трафика, так и трафика в режиме моста. NetFlow для трафика в режиме моста требует использования Release 12.2(18)SXE или более позднего.
Ниже приведен пример, как включить NetFlow для IP трафика в режиме ingress-bridged на VLAN 200:

Router# configure terminal
Router(config)# ip flow ingress layer2-switched vlan 200

Замечание: Для включения NetFlow для IP-трафика в режиме моста на VLAN, вы должны создать соответствующий интерфейс VLAN, привязать его к IP-адресу, и ввести команду no shutdown для поднятия интерфейса.

Каковы оптимальные значения aging для NetFlow?

Мы рекомендуем сконфигурировать длинный интервал времени жизни (aging) в 300 сек., а нормальный - в 60 сек. Время жизни (aging time) критично для систем обнаружения аномалий. В случае, если вы используете NetFlow только для биллинга, то вы можете оставить значения по умолчанию.
Нижеуказанные команды IOS будут разделять ваши потоки на более короткие сегменты:

router(config)# ip flow-cache timeout active 5
router(config)# ip flow-cache timeout inactive 60

Следующие команды устанавливают aging на IOS-устройствах:

L3switch(config)# mls aging long 300
L3switch(config)# mls aging normal 60

А это команды для CatOS-устройств:

switch> (enable) set mls agingtime long 304
switch> (enable) set mls agingtime 64

Какова емкость таблицы NetFlow в Cisco?

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

PFC	Рекомендованная утилизация таблицы NetFlow	Общая емкость таблицы NetFlow
PFC3BXL	235,520 (230 K) элементов	262,144 (256 K) элементов
PFC3B	117,760 (115 K) элементов	131,072 (128 K) элементов
PFC3A	65,536 (64 K) элементов	131,072 (128 K) элементов
PFC2	32,768 (32 K) элементов	131,072 (128 K) элементов

Для мониторинга использования таблицы NetFlow на процессоре коммутатора и в DFC используйте команду mls netflow usage notify. Если мониторинг использования таблицы NetFlow включен и загрузка таблицы превышает пороговое значение, появляется предупреждающее сообщение.

mls netflow usage notify {threshold interval}

где threshold - порог в процентах, превышение загрузки выше его вызывает сообщение; значения могут быть в интервале 20 - 100%, а interval - определяет частоту, с которой таблица проверяется; значения могут быть в интервале от 120 до 1000000 сек.

Я вижу весь трафик, входящий в интерфейс, но не вижу выходящий

Выполните команду:
show ip interface brief | exclude unassigned
для получение перечня всех L3-интерфейсов, которые имеют присвоенные IP-адреса.
Проверьте, если вы включили ip route-cache cef или ip route-cache flow на всех L3-интерфейсах.

Что означает "flow mask" в конфигурации mls?

По умолчанию ключи потока - это: IP-адрес источника, IP-адрес приемника, порт источника, принимающий порт, тип протокола layer 3, байт ToS (DSCP) и входящий интерфейс. На Cisco Catalyst flow mask определяет ключи потока.

Весь интерфейс
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника
Полный
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника
Интерфейс приемник-источник
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника
Только источник
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника
Только приемник
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника
Приемник-источник
VLAN	IP-адрес источника	IP-адрес приемника	L3-протокол	Порт источника	Порт приемника

Я сконфигурировал NetFlow на Cat6500, но приложение показывает только несколько Мбайт, хотя должно быть несколько Гбайт.

Catalyst 6500 использует MSFC только для первого пакета, а остальные пакеты переключаются, используя ЗАС (CEF, dCEF). Для того, чтобы корректно сконфигурировать экспорт NetFlow на Cat6500, вы должны включить NetFlow на MSFC и PFC. В вашей конфигурации включен NetFlow только на только MSFC, и большая часть трафика пропадает!
См. подробности здесь: http://www.cisco .com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080160a2b.html .

Или данные NetFlow с коммутатора вообще не попадают на коллектор. Проверьте устройства, supervisor и MSFC для внесения изменения в конфигурацию.

Возможно ли использовать vrf-интерфейс как источник пакетов NetFlow?

Экспорт NetFlow через VRF:
- Разрешите экспорт записей потоков в VRF.
- Справедливо для экспорта SCTP и UDP.

Router(config)# ip flow-export destination 10.1.1.2 2000 vrf testvrf <sctp|udp>
Router(config-flow-cache)# export destination 10.1.1.2 2000 vrf testvrf <sctp|udp>

где testvrf - имя VRF.

Я хотел бы получать NetFlow с отдельного порта коммутатора Layer 2

Команды, которые вам необходимы для трафика Layer 2:

ip flow ingress layer2-switched vlan <vlanlist>
ip flow export layer2-switched vlan <vlanlist>

Cогласно справочнику IOS: PFC3B или PFC3BXL под управлением 12.2 (18)SXE или выше требуют этих команд, которые включают NDE для всего трафика в конкретном VLAN, а не только для внутреннего трафика VLAN. Если вы используете CatOS, вы можете применить команду:

set mls bridged-flow-statistics enable <vlanlist>

Какой порт Cisco предпочтителен для того, чтобы получать NetFlow?

Возможны варианты. RFC 3954 по NetFlow не уточняет конкретный порт для получения NetFlow, однако по опыту наиболее популярными являются 2055 и 9995 или 9996.
Хотя эти порты и наиболее популярны, они могут быть изменены. Для того, чтобы сделать это на маршрутизаторе Cisco, в котором включен NetFlow v5 или NetFlow v9, наберите команду:

router(config)# ip flow-export destination [collector ip address] [collector port]
ex. router(config)# ip flow-export destination 10.1.57.3 4432

Если вы используете Flexible NetFlow (см. конфигурацию на YouTube), посмотрите шаг 2 конфигурации "Создание экспортера" и используйте:

transport udp 2055

Как конфигурировать VMware vSphere ESX v5.1 для поддержки IPFIX?

С тех пор, как vSphere стала поддерживать IPFIX мониторинг виртуальных серверов стал очень простой задачей. Для того, чтобы сконфигурировать IPFIX для VMware vSphere ESX v5.1 необходимо следующее.
Сначала надо отредактировать установки распределенного коммутатора. Кликните на виртуальный коммутатор, затем нажмите на 4-ю закладку, озаглавленную NetFlow.

IPFIX на распределенных коммутаторах может быть включен на уровне групп портов, на уровне индивидуального порта или на уровне аплинка. Если вы впервые конфигурируете экспорт IPFIX, то убедитесь, что включили NetFlow на одном из этих уровней.
Экран конфигурации NetFlow предоставляет вам различные параметры, которые могут быть контролируемы во время установки.
   1. Установки коллектора (IP-адрес и порт) должны быть сконфигурированы в соответствии с информацией, полученной об инструменте сбора потоков, установленного в вашей сетевой среде.
   2. Параметры Advanced Settings предоставляют вам возможность контролировать таймаут и частоту выборки потоков. Для того, чтобы изменить количество информации, которая будет собираться для потока, вы можете изменить частоту выборки. Например, частота выборки 2 означает, что виртуальный распределенный коммутатор ( Virtual Distributed Switch, VDS) будет собирать данные из каждого второго пакета. Вы также можете модифицировать значение таймаута задержки экспорта потока.
   3. Конфигурирование IP-адреса VDS полезна, когда вы хотите видеть всю потоковую информацию в вашем коллекторе как часть одного IP-адреса VDS, а не видеть все хосты как отдельные анонимные коммутаторы на коллекторе. Т.е. если IP-адрес VDS останется незаполненным, каждая виртуальная машина появится в коллекторе как отдельный экспортер.
Когда конфигурируется IPFIX на уровне порта, администратор должен выбрать закладку NetFlow, чтобы быть уверенным, что потоки будут мониториться, несмотря на то, что на групповом уровне IPFIX будет отключен.

Опционально:
Вы может также осуществлять мониторинг только внутренних потоков виртуальной инфраструктуры, отметив пункт "Обрабатывать только внутренние потоки" ( "Process Internal flows only”).

Как конфигурировать VMware vSphere ESX v5.1 для поддержки IPFIX?

Сначала надо отредактировать установки распределенного коммутатора. Кликните на виртуальный коммутатор, затем нажмите на 4-ю закладку, озаглавленную NetFlow.

Как запустить NetFlow без поддержки этих технологий сетевым оборудованием?

Ваше оборудование не поддерживает NetFlow? Это не проблема, используйте генераторы NetFlow
Хотя сегодня практически все производители сетевого оборудования включают поддержку NetFlow в функциональность своей продукции, все еще существуют сети, в которых используется техника, не применяющая NetFlow. Это может быть оборудование, не поддерживающее NetFlow, или техника, в которой вы не хотите использовать эту функциональность, опасаясь влияния NetFlow на загрузку процессора или памяти. В любом случае альтернатива существует. Это генераторы NetFlow.
Генератор NetFlow - это сетевое устройство или программный "демон", который пассивно захватывает сетевые пакеты и переводит их в записи NetFlow. В сети это выглядит следующим образом:

Генераторы NetFlow подключаются точно так же, как и традиционные пассивные IDS или пакетные снифферы. Они используют "порт захвата", который подключается к сетевому SPAN-порту или TAP. Большинство генераторов NetFlow работают на базе Linux и используют стандартное оборудование. Опыт показывает, что программные генераторы, как правило, имеют более продвинутый функционал и легче расширяются в будущем. Если вам не требуются исключительная скорость типа 10Gbps+, то программные генераторы NetFlow вас вполне устроят.
Более подробно можно прочитать здесь.

Совместимы ли OpenFlow и NetFlow?

OpenFlow и NetFlow - это две полностью разные концепции. OpenFlow контролирует, как пакеты пересылаются через сетевые коммутаторы, а NetFlow собирает информацию об IP-трафике. Ошибка происходит от того, что оба термина содержат слово "flow", т.е. поток. Попробуем здесь уточнить природу обоих протоколов.
Что такое OpenFlow?
Это протокол, используемый в Software Defined Networks (SDN) для коммуникаций между сетевыми устройствами и сервером контроллера. Эта специфическая архитектура разделяет пересылку пакетов и решения маршрутизации верхнего уровня, в силу чего пересылка пакетов осуществляется коммутационным оборудованием, а маршрутизация верхнего уровня осуществляется сервером.
Что такое NetFlow?
Эта технология используется для сбора информации о сетевом трафике, такой как IP источника и приемника, порты, протоколы, загрузка полосы, данные о приложениях и др. Поддерживающий NetFlow коммутатор или маршрутизатор собирает данные IP-потоков и отправляет их на сервер, на котором установлен коллектор потоков. Этот коллектор может расшифровывать пакеты NetFlow и интерпретировать их содержимое в удобной для пользователей форме для дальнейшего анализа.
Дополняют ли NetFlow и OpenFlow друг друга?
На этот вопрос можно ответить: "может быть". Для того, чтобы понять, почему, мы должны несколько больше углубиться в архитектуру SDN и OpenFlow. В сети SDN когда хост определяет адрес для отправки, коммутатор, который сконфигурирован для OpenFlow, должен принять решение, для того, чтобы:
1. переслать пакет, основываясь на локальных правилах или
2. переслать запрос переопределения адреса в контроллер и ждать инструкций, как обработать запрос на соединение.
Если контроллер отказывает в соединении, то коммутатор ничего не делает. С другой стороны, если контроллер дает разрешение на соединение, то он затем "спускает вниз" всем коммутаторам и маршрутизаторам, находящимся на маршруте, инструкции о том, как пересылать трафик, причем иногда с заранее определенными приоритетами. Какая бы логика пересылки не использовалась (т.е. локальная или с помощью контроллера), коммутатор может экспортировать данные IPFIX, NetFlow или sFlow о потоках. В случае, когда контроллер принимает решение о соединении или о его запрете, он должен также поддерживать таблицу соединений. Теоретически возможно, что контроллер может экспортировать потоки с деталями сетевого трафика.
Короче говоря, можно говорить об OpenFlow как о протоколе, используемом при коммуникациях между коммутаторами и контроллером в мультивендорной SDN-среде.

Еще раз: что лучше - NetFlow или sFlow?

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

Что такое поток (flow)?
Как указано в IETF, поток - это последовательность пакетов, посылаемых одним приложением в другое. Технология sFlow использует выборки, для получения масштабируемости. Архитектура системы sFlow состоит из множества устройств, обеспечивающих два типа выборок: случайные выборки пакетов и операций на уровне приложений и выборка с определенным интервалом времени по счетчику. Выбранные данные о пакетах/операциях и счетчике отсылаются как датаграммы sFlow в центральный сервер с приложением, которое анализирует трафик и создает соответствующие отчеты - коллектор sFlow.Множество выборок sFlow могут отсылаться одной датаграммой.
sFlow может использоваться оборудованием или программным обеспечением и, хотя название sFlow означает, что речь идет именно о потоковой технологии, исходя из указанной выше информации, это вообще не потоковая технология. Этот термин (sFlow) имеет отношение больше к маркетингу. Подобные выборки пакетов не обеспечивают 100% точности, но дают результат с вычисляемой точностью.

Что такое NetFlow?
NetFlow - это действительно потоковая технология, в которой кэшируемые в оборудовании (например, роутере или коммутаторе) потоки агрегируют пакеты на основе определенных данных, чаще всего это набор семи ключевых полей:
   1. Интерфейс источника
   2. Тип сервиса
   3. IP-адрес источника
   4. IP-адрес приемника
   5. Порт (Layer 4) источника
   6. Порт (Layer 4) приемника
   7. IP-протокол
Когда потоки экспортируются, к этим данным добавляется значение объема (байтов) агрегированных или всех данных и данные счетчика пакетов, а также несколько других полей. Пакеты, которые не соответствуют данным ключевых полей потоков в кэше, создают уже новый набор потоков. В одной датаграмме могут отсылаться сразу много подобных наборов потоков. NetFlow обеспечивает 100% точность IP-трафика, хотя NetFlow поддерживает и пакетную выборку и потоковую выборку.

Что такое Flexible NetFlow?
Это в реальности никакой не новый формат экспорта. Скорее он базируется на архитектуре формата экспорта NetFlow v9 и делает несколько больше на этой основе. FnF является одним из лучших, хотя и наиболее сложных методов создания экспорта потоков на сегодняшний день. FnF позволяет пользователям экспортировать почти все, что проходит через роутер, включая целые пакеты и делает это в реальном времени, практически как sFlow.

Что такое IPFIX?
IPFIX - это предлагаемый стандарт для структурированной потоковой информации и он базируется на последней версии NetFlow (v9). Вследствие этого его иногда не совсем корректно называют NetFlow v10.

Что является стандартом - NetFlow или sFlow?
Ответ - ни то, ни другое. Если обратиться к сайту IETF, то можно найти RFC 3176, где обсуждается протокол sFlow, и RFC 3954, где речь идет о NetFlow v9. Эти технологии не являются стандартом. RFC означает "запрос на комментарии" (Request For Comment ), т.е. это не стандарт. IPFIX, который определяется в RFC 5101 - это предлагаемый стандарт. Не надо обращать внимание на документы, подобные выпущенному компанией Brocade, где говорится: "IPFIX страдает плохим принятием основных производителей и все еще имеет большинство недостатков NetFlow". Это просто неправда. Сейчас большинство вендоров уже внедрило или собирается внедрить поддержку IPFIX.

Что лучше масштабируется, sFlow или NetFlow?
Выборка может быть осуществлена с помощью и sFlow, и NetFlow, но она не может масштабироваться так, как этого хотелось бы большинству пользователей. Например, существенный рост объема трафика (как при DoS-атаках) может заставить sFlow делать выборку чаще, чем это нужно для сохранения параметра выборки 1:N. В случае NetFlow массивный объем пакетов, зависящий от атаки, даст нам просто несколько потоков с высоким объемом пакетов. Для NetFlow количество дополнительной работы минимально, особенно если мы сравним, как говорят, два апельсина от двух технологий, на одном оборудовании. В свое время была статья, где сравнивалась точность обоих технологий. В реальности случаются всяческие проблемы, и NetFlow предоставляет для анализа 100% всего трафика, а sFlow часто теряет трафик, который необходимо просмотреть, что делает sFlow практически непригодной технологией для обнаружения сетевых атак или анализа поведения.
Если sFlow не может обеспечить достаточную выборку для полезных измерений, или если NetFlow просто переполняет ваш коллектор потоков, то вам надо рассмотреть возможность перехода на Flexible NetFlow, где можно отконфигурировать экспорт так, чтобы посылать меньше деталей, но все равно сохранять 100%-точность. Например, можно рассмотреть такое сокращение, когда отсылается 5 полей, а не 7:
   1. Интерфейс источника
   2. Тип сервиса
   3. IP-адрес источника
   4. IP-адрес приемника
   5. IP-протокол
Когда из набора убирается информация о портах, то вы можете заметить, что объем экспортируемых потоков уменьшился на 75%! Если вам действительно надо видеть детали приложений, то организуйте экспорт NBAR, который также существенно уменьшает объем экспорта.

Если я должен использовать выборку, что я должен выбрать: выборку потоков или выборку пакетов?
Лучшим выбором является выборка потоков. Делая выборку 1 пакет из тысячи или даже уменьшая скорость выборки до 1 :100000 пакетов, вы усугубляете проблему неправильной репрезентативности. При выборке потоков, потоки с 10 пакетами выбираются также, как потоки со 100 000 пакетов. В результате, если вы хотите получить представление о приложениях в сети, то выборка потоков дает большую точность. Пакетная выборка, вероятнее всего, покажет наиболее основные приложения с большим количеством пакетов и полностью потеряет приложения с несколькими пакетами. Отметим, что и sFlow и NetFlow поддерживают пакетную выборку в реальном времени, в зависимости от платформы.

Если NetFlow лучше, чем sFlow, почему кто-то еще использует sFlow?
Многие коммутаторы сегодня поддерживают только sFlow. Дело в том, что существует очень недорогой в реализации метод пакетной выборки с sFlow. В результате большинство производителей поддерживают эту технологию, в том числе и Cisco. Сейчас многие потребители думают, что они имеют единственный выбор для коммутаторов - sFlow. Однако уже есть несколько производителей, включая Cisco, которые поддерживают NetFlow и/или IPFIX на коммутаторах (например, Cisco 3750X с модулем 3KX или 3850).

Вывод
Из-за того, что большое сообщество поддерживает IPFIX (Astaro, Barracuda, Cisco, Citrix, Dell, Enterasys, Lancope, Plixer и др.), инновации в экспорте данных очень существенные. Это:
   • Сообщения Log
   • Сообщения об обнаруженных вирусах
   • VoIP
       ○ Джиттер и потери пакетов
       ○ Идентификатор звонящего
       ○ Кодек
       ○ SSRC
   • Задержка или Round Trip Time
   • URL
   • Перенаправленные соединения
   • Идентификаторы беспроводной сети
   • Имена логина конечных пользователей
С другой стороны, sFlow нуждается в поддержке большого сообщества пользователей и инновации, которые возникают у них, к сожалению, не могут сравниться с потоковыми технологиями типа NetFlow или IPFIX. Ну, и для завершения: если вы спросите любого пользователя, у которого в сети стоит оборудование поддерживающее и sFlow, и NetFlow, то они скажут: "Я предпочитаю собирать NetFlow, но sFlow все-таки лучше, чем ничего".

Еще раз: что лучше - NetFlow или sFlow

Что является стандартом - NetFlow или sFlow?

Ответ - ни то, ни другое. Если обратиться к сайту IETF, то можно найти RFC 3176, где обсуждается протокол sFlow, и RFC 3954, где речь идет о NetFlow v9. Эти технологии не являются стандартом. RFC означает "запрос на комментарии" (Request For Comment ), т.е. это не стандарт. IPFIX, который определяется в RFC 5101 - это предлагаемый стандарт. Не надо обращать внимание на документы, подобные выпущенному компанией Brocade, где говорится: "IPFIX страдает плохим принятием основных производителей и все еще имеет большинство недостатков NetFlow". Это просто неправда. Сейчас большинство вендоров уже внедрило или собирается внедрить поддержку IPFIX.

Как рассчитать объем, занимаемый NetFlow?

Часто спрашивают, есть ли инструкция о том, как определить объем NetFlow. Какое количество дискового объема необходимо для обычного варианта использования NetFlow? Самые большие опасения связаны с тем, что экспорт NetFlow (или его аналогов) для использования при анализе сетевой производительности будет существенно влиять на доступную полосу пропускания, загружать процессор или емкость диска. Все это на самом деле совсем не так.
Что касается влияния NetFlow на полосу пропускания вашей сети, то вы можете легко найти ответ здесь. Тем не менее, попробуем вам немного рассказать о ресурсах, потребляемых NetFlow .
Один акт экспорта потоковых данных может содержать записи до 30 потоков. Это важно, поскольку средний объем NetFlow прямо пропорционален количеству уникальных сокетов TCP/IP, созданных клиентами и серверами в вашей сети.
Такой агрегационный характер NetFlow и тот факт, что NetFlow содержит только информацию заголовка IP (т.е. не собственно все содержание пакета), отвечают за то, что экспорт загружает только 1-2% пропускной способности интерфейса. Начиная с 2004 года эксперты в области Cisco NetFlow придерживаются правила, что NetFlow должен занимать только 1-1,5% полосы интерфейса, через который экспортируется.

На рисунке показано количество потоков через интерфейс в минуту. Обратите внимание, что это TCP-потоки, следовательно еще примерно 100 потоков в минуту пройдет в обратном направлении. Т.е. всего 200 в минуту.
Нам хотелось бы также знать, каков обычный объем потоков проходит через компьютер? Ответ таков: это зависит от ряда условий, но, скажем, в среднем офисе, как у нас, на компьютер приходится примерно 100 потоков в минуту, с пиковыми значениями равными 350. Допустим, для примера, что ваша компания содержит 20 000 узлов и каждый узел создает 200 потоков в минуту. Т.е. всего будет 4 млн. потоков в минуту или около 67 000 потоков в секунду. Вы можете спросить, почему столько много потоков?
Приложения порождают множество уникальных потоков, особенно браузеры и большинство приложений, которые соединяются с производителем для проверки обновлений. Вот несколько "болтливых" приложений:
   • Java, Adobe, антивирусы, веб-браузеры
   • Skype
   • Веб-страницы порождают потоки из-за картинок, рекламы и т.п.
   • Email, постоянно проверяющая почтовый ящик
   • NetBios

Каждая сеть индивидуальна, поэтому показатели будут различными. Тем не менее современные анализаторы трафика, такие как Lancope StealthWatch или Plixer Scrutinizer, могут обрабатывать свыше 100 000 потоков в секунду, или даже много больше при использовании распределенной системы сбора трафика. Только захват всех потоков позволяет использовать эти данные для поведенческого анализа сети или в аналитических системах, работающих для целей обеспечения безопасности. Поэтому нет большого смысла рассматривать для внедрения решения, которые не упоминают о сохранении "сырых" пакетов или не могут точно сказать, сколько потоков в минуту их решение может пропускать через себя.

Почему маршрутизатор теряет производительность при включении NetFlow?

Вы сталкивались с перегрузкой маршрутизатора после того, как вы включали на нем NetFlow? Это происходит, если роутер уже работал с полностью загруженным процессором. Поэтому необходимо исследовать тенденцию загрузки процессора роутера прежде, чем включать на нем NetFlow или IPFIX. Обычно же включение такого экспорта не влияет на производительность, если роутер работает в нормальном режиме.
У большинства вендоров оборудования потоковая технология внедрена как программное обеспечение. При этом хорошо написанное программное обеспечение лишь в малой степени влияет на производительность. В ранних же версиях NetFlow (т.е. NetFlow v1) при включении экспорта этих данных на загруженном роутере может быстро привести к его перегрузке. Включение NetFlow на Cisco Catalyst 4500, 6500, 7600, 10000 или 12000 приводит к следующему увеличению утилизации процессора:

Кол-во активных элементов кэша потоков	Дополнительная загрузка процессора
10000	< 4%
45000	< 12%
65000	< 16%

Предупреждение:включение стандартных функций NetFlow на сильно загруженных маршрутизаторах производства большинства вендоров может в некоторых случаях вызвать неприемлемое изменение производительности. В этих случаях следует рассмотреть возможность использования выборки потоков.

Cisco Systems, Enterasys, Extreme Networks и Dell Sonicwall разработали файерволы, маршрутизаторы и коммутаторы, которые поддерживают экспорт NetFlow и IPFIX аппаратным образом без оказания влияния на производительность. Например SonicWall экспортирует IPFIX, используя не более 1% мощности процессора. Другие производители, например, Enterasys, используют в своем оборудовании специальную интегральную схему для экспорта NetFlow, которая не замедляет скорость работы системы. При объеме потоков свыше 500 000 потоков в секунду проблема с производительностью часто переносится с экспортера на коллектор, поскольку сегодня нет одиночного коллекторного устройства, которая может обрабатывать такие потоки. Кроме того, распределенные NetFlow-решения также не могут всегда помочь, когда все потоки идут из одного экспортера.
Для обеспечения работы в таких условиях используются распределенные коллекторы NetFlow, которые позволяют разделить сбор потоков на группы. При этом каждый коллектор получает данные с определенного набора маршрутизаторов. Поскольку часто используется конфигурация с сотнями маршрутизаторами, то в системе инсталлируется также репликатор NetFlow (или другими словами - дупликатор NetFlow). Такой Flow Replicator позволяет администраторам конфигурировать роутеры, чтобы они отсылали потоки в единое устройство. Такая конфигурация позволяет осуществлять балансировку нагрузки коллекторов.

Производители коллекторов часто утверждают, скорость сбора данных у них составляет несколько миллионов потоков в секунду, однако архитектура, поддерживающая такую скорость, состоит из множества индивидуальных коллекторов, каждый из которых ограничен скоростью 100-200 тыс. потов в секунду. Для уменьшения объема данных часто используют выборку или PSAMP.

Чем отличается NetFlow v9 от предыдущих версий?

Этот формат более гибкий и расширяемый, обладает функционалом, позволяющим поддерживать новые поля и типы записей. Формат обеспечивает поддержку таких технологий, как NAT, MPLS,BGP next hop и Multicast. Основная новинка формата Version 5 в том, что он основан на шаблонах.

1-36 37-70