Нормально ли экспортятся потоки с внешнего интерфейса?
в записях внутренние IP или внешние, на которые транслируются внутр.адреса?
Вопрос известный и документированный об учете входящего трафика с помощью Netflow для хостов, находящихся за NAT
http://www.opennet.me/base/cisco/netflow_nat.txt.html
http://www.netup.ru/articles_pdf/10.pdf
во многих источниках упоминается PBR на внешнем интерфейсе через Loopback и авторы утверждают, что это работает, у меня не получилось заставить работать(у меня во входящем трафике фигурирует внешний интерфейс циски, пробовал на 1841 и на 2621)
см. мой пост с конфигом
http://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi?az=sh...
Поможите люди добрые!
завести все этой на одной железке можно, даже чуть чуть работать будет, только статистика неверная будет, т.к. нетфлоу с виртуального интерфейса снимать нехорошо, и такой вариант генератора трафика для биллинга не сертифицируется.правильно снимать нетфлоу только с физических интерфейсов, т.е. нужно в вашей задаче использовать 2 железки, одну заставить делать нат, вторую считать флоу.
>статистика неверная будет, т.к. нетфлоу с виртуального интерфейса снимать нехорошо,
>и такой вариант генератора трафика для биллинга не сертифицируется.
какие могут быть расхождения, ориентировочно, если не секрет?
сам интуитивно понимаю, что через лупбэк не точно, но я не провайдер, мне сгодится оценочная и самое главное детализованная по хостам информация>нужно в вашей задаче использовать 2 железки, одну заставить делать нат, вторую считать флоу.
понимаю, но 2 железку ставить нецелесообразно и ее попросту нет :)
>какие могут быть расхождения, ориентировочно, если не секрет?
расхождения описать не могу, но то, что статистика с лупбека будет врать - это факт. хотя вранья там и не много. сам процесс вранья имхо возникает в моменты overload`а железяки, когда она не справляется с нагрузкой. шанс оверлоада с крутящимся натом сильно повышается>сам интуитивно понимаю, что через лупбэк не точно, но я не провайдер,
>мне сгодится оценочная и самое главное детализованная по хостам информация
я - провайдер. точно знаю, что решение нат+флоу на одной железке не пройдет, не пропустят>понимаю, но 2 железку ставить нецелесообразно и ее попросту нет :)
в вашей ситуации видимо потерять трафик не очень страшно, так что можно пробовать уговорить и одну железку работать :)
>>какие могут быть расхождения, ориентировочно, если не секрет?
>расхождения описать не могу, но то, что статистика с лупбека будет врать
>- это факт. хотя вранья там и не много. сам процесс
>вранья имхо возникает в моменты overload`а железяки, когда она не справляется
>с нагрузкой. шанс оверлоада с крутящимся натом сильно повышаетсяВозможность снимать нетфлоу с лупбэка очень иосозависима. Где-то работает, где-то нет. Где-то работает но как попало. Я бы не заморачивался на подобные вещи. Не исключено что завтра придется апгрейдить иос, и в нем все отвалится.
последних релизах можно с помощью netflow считать как входящий, так и исходящий...
ip flow ?
>последних релизах можно с помощью netflow считать как входящий, так и исходящий...
речь идет о ip flow egress/ingress ?
>ip flow ?
не понял...?
gw(config)#ip flow-?
flow-aggregation flow-cache flow-capture flow-egress
flow-export flow-top-talkers
gw(config-if)#ip flow ?
egress Enable outbound NetFlow
ingress Enable inbound NetFlow
>gw(config-if)#ip flow ?
> egress Enable outbound NetFlow
> ingress Enable inbound NetFlowда, об этом...
>>gw(config-if)#ip flow ?
>> egress Enable outbound NetFlow
>> ingress Enable inbound NetFlow
>
>да, об этом...
Уважаемый ВОЛКА, если не трудно дайте пару ссылок по теме, а то тематика eggress/ingress для меня нова, ничего про это не слышал
>>>gw(config-if)#ip flow ?
>>> egress Enable outbound NetFlow
>>> ingress Enable inbound NetFlow
>>
>>да, об этом...
>Уважаемый ВОЛКА, если не трудно дайте пару ссылок по теме, а то
>тематика eggress/ingress для меня нова, ничего про это не слышал
просто включаете на inside интерфейсе эти две команды и собираете netflow
хотите подробнее - сделайте поиск на www.cisco.com по этой команде
>>статистика неверная будет, т.к. нетфлоу с виртуального интерфейса снимать нехорошо,
>>и такой вариант генератора трафика для биллинга не сертифицируется.
>какие могут быть расхождения, ориентировочно, если не секрет?
у мя расхождения были. у прова 152 гига, у мя 150. но это фигня>сам интуитивно понимаю, что через лупбэк не точно, но я не провайдер,
>мне сгодится оценочная и самое главное детализованная по хостам информация
>такую инфу можно получить
>>нужно в вашей задаче использовать 2 железки, одну заставить делать нат, вторую считать флоу.
>понимаю, но 2 железку ставить нецелесообразно и ее попросту нет :)