дублирующиеся записи о трафике

[ilya]

Вот купили ЮТМку, собираемся на нее переезжать.
У меня опорная сеть посторена полнстью на рутерах циско. Соответственно я собираюсь собирать информацию о трафике клиентов посредством нетфлоу. В тестовом режиме все обкатано и работает нормально, однако, топология у нас сети не звездообразная, все рутеры имеют связь как минимум с двумя другими в целях резервирования.
Поэтому записи о трафике экспортируемые с них буду дублироваться и даже затраиваться в некоторых случаях.
Разумеется можно снимать поток только с пограничных интерфейсов, однако тогда я потеряю статистику о внутреннем трафике.

Что делать?

[aospan]

Вот купили ЮТМку, собираемся на нее переезжать.
У меня опорная сеть посторена полнстью на рутерах циско. Соответственно я собираюсь собирать информацию о трафике клиентов посредством нетфлоу. В тестовом режиме все обкатано и работает нормально, однако, топология у нас сети не звездообразная, все рутеры имеют связь как минимум с двумя другими в целях резервирования.
Поэтому записи о трафике экспортируемые с них буду дублироваться и даже затраиваться в некоторых случаях.
Разумеется можно снимать поток только с пограничных интерфейсов, однако тогда я потеряю статистику о внутреннем трафике.

Что делать?

Есть вариант попробовать "разпулить" данную проблему на основании поля nexthop, но четко непонятно как это делать ... нужна схема сети и схема адресации - можно попробовать решить эту задачу.
В ndsad есть фильтры, которые указывают какой трафик считать ... вряд ли в циске есть такое

[gravis]

Netup предлагал решение для cisco где используется снятие netflow-статистики с loopback-интерфейса. Трафик на него заворачивается с помощью route-map, что позволяет настроить "заворот" только нужного трафика. Возможно это поможет.

А вообще, для себя я стараюсь придерживаться простого правила. Считать трафик для абонента нужно на крайнем (в его сторону) маршрутизаторе, это оградит от проблем дублирования и позволит считать любой трафик идущий к абоненту и от него.

[ilya]

Netup предлагал решение для cisco где используется снятие netflow-статистики с loopback-интерфейса. Трафик на него заворачивается с помощью route-map, что позволяет настроить "заворот" только нужного трафика. Возможно это поможет.

А вообще, для себя я стараюсь придерживаться простого правила. Считать трафик для абонента нужно на крайнем (в его сторону) маршрутизаторе, это оградит от проблем дублирования и позволит считать любой трафик идущий к абоненту и от него.

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

Гм. Мне думается что это не моя обязанность, а биллинга.
Ведь к абоненту же привязывается маршрутизатор, естественным образом следует учитывать что траффик для этого абонента стоит брать только с этого маршрутизатора. Или я не прав?

[gravis]

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

Не совсем понятно с кольцами. У вас что настройки оконечных интерфейсов к абонентам автоматически переезжают с роутера на роутер?

[ilya]

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

Ok.

____________________________ "клиенты на станции ааа
________________________________ |
Мир <-> граничный рутер <-> рутер на станции ааа <-> пиринг
____________________________ / __________ \
___________________________ / ____________ \
_______________________ станция ббб <-> станция ввв
________________________ / __________________ \
_______________________клиенты ббб ______ клиенты ввв

Вот примерная схема. Нарисовал очень коряво конечно, но понятно по моему. Извиняюсь за прочерки, но форум иначе аггрегирует пробелы и рисунок сжимается.

Итак, есть станция ааа - на нее приходит трафик прямо с граничного рутера. К ней подключены станции ббб и ввв и на ней есть клиенты ADSL. Также через нее сеть подключена к местной точке обмена трафиком.
Станции ббб и ввв также соединены между собой, между всеми рутерами бегает оспф, так что при пропадании любой междстанционной связи, связность в сети остается.
Далее, на рисунке не поместилось, но и к ббб и к ввв подключены еще станции, которые также связаны между собой.

Так вот, как мне в таком случае снимать всю статистику и не иметь дублирующих записей?

[gravis]

Надо было в code /code запихать, чтобы пробелы остались. А то фигня какая-то, а не схема...

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

- клиентский интерфейс на роутере ААА
- клиентский интерфейс на роутере БББ
- клиентский интерфейс на роутере ВВВ
- интерфейс до граничного роутера на роутере ААА (либо интерфейс в инет на граничном роутере)
- пиринговый интерфейс на роутере ААА

На межстанционных линках ничего учитывать не требуется.

В случае использования последних версий IOS'a, доступна комманда ip flow egress, т.е. подсчет исходящего трафика посредством Netflow, настройка будет аналогичной. Если не требуется учитывать исходящий трафик от абонентов, то при использовании ip flow egress не нужно учитывать трафик на внешних интерфейсах (интернет, пиринг).

[ilya]

Надо было в code /code запихать, чтобы пробелы остались. А то фигня какая-то, а не схема...

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

- клиентский интерфейс на роутере ААА
- клиентский интерфейс на роутере БББ
- клиентский интерфейс на роутере ВВВ
- интерфейс до граничного роутера на роутере ААА (либо интерфейс в инет на граничном роутере)
- пиринговый интерфейс на роутере ААА

На межстанционных линках ничего учитывать не требуется.

В случае использования последних версий IOS'a, доступна комманда ip flow egress, т.е. подсчет исходящего трафика посредством Netflow, настройка будет аналогичной. Если не требуется учитывать исходящий трафик от абонентов, то при использовании ip flow egress не нужно учитывать трафик на внешних интерфейсах (интернет, пиринг).

В общем понятно, но есть все таки шероховатости. В ряде случае межстанционные интерфеймы - dot1q сабинтерфейсы интерфейсов, на которых сидят в том числе и клиенты. Циска же позволяет прописать
ip route-cache flow только на физических интерфейсах, т.о. межстанционные линки автоматом подпадают под сбор статистики.

[gravis]

В роутерах Cisco уже давно не обязательно настраивать сбор netflow на parent-интерфейсе. Вместо этого можно использовать комманду ip flow ingress (или ip flow egress) только на тех vlan-сабинтерфейсах, на каких нужно.

[ilya]

В роутерах Cisco уже давно не обязательно настраивать сбор netflow на parent-интерфейсе. Вместо этого можно использовать комманду ip flow ingress (или ip flow egress) только на тех vlan-сабинтерфейсах, на каких нужно.

За это спасибо, не знал фишку.

[ilya]

В роутерах Cisco уже давно не обязательно настраивать сбор netflow на parent-интерфейсе. Вместо этого можно использовать комманду ip flow ingress (или ip flow egress) только на тех vlan-сабинтерфейсах, на каких нужно.

Кстати, "уже давно" не распостраняется на (C2600-IS-M) 12.2(13)T1.
Т.о. на моих 2611ХМ непримениемо без тотального апгрейда флеша.
На новой 2801 есть, но туда я зашил софт C2800NM-ADVIPSERVICESK9-M, Version 12.3(14)T2. На стандартном возможно и не было бы.

[gravis]

Эта фича называется NetFlow Subinterface Support.
Появилась она в 12.2(14)S - так что ты не так уж и далеко

Кстати, начиная с 12.3(4)T в IOS'е появилась еще более гибкая возможность управления netflow - составление фильтров. Таким образом можно четко определять по ACL или по полям netflow какой трафик отправлять в биллинг.

[Chris]

Короче, Aospan, я тебе уже говорил про эту проблему, включи её в to do лист, я же тебе сказал как исправить.

[aospan]

Короче, Aospan, я тебе уже говорил про эту проблему, включи её в to do лист, я же тебе сказал как исправить.

предлагаете анализировать с какого шлюза пришел нетфлоу и смотреть какому юзеру соответсвует этот маршрутизатор на того и писать этот трафик ?

[gravis]

предлагаете анализировать с какого шлюза пришел нетфлоу и смотреть какому юзеру соответсвует этот маршрутизатор на того и писать этот трафик ?

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