на других и не было
а на указанном, если убрать подсчет, например исходящего, будет некрасиво.
| forum.bitel.ru http://forum.bitel.ru/ |
|
| Обсчет абонентов PPPoE, задвоенный внутренний трафик http://forum.bitel.ru/viewtopic.php?f=5&t=2262 |
Страница 1 из 1 |
| Автор: | jack7 [ 28 апр 2009, 09:38 ] |
| Заголовок сообщения: | Обсчет абонентов PPPoE, задвоенный внутренний трафик |
выборка конфига cisco ESR-10008 виртуального шаблона, с которого отправляется поток netflow на BG Код: interface Virtual-Template1 description - Client - mtu 1492 ip unnumbered Loopback2 no ip proxy-arp ip flow ingress ip flow egress peer default ip address pool stat keepalive 6 12 ppp disconnect-cause keepalive lost-carrier ppp authentication chap ms-chap-v2 ppp authorization radius ppp accounting radius ppp ipcp dns x.x.x.x y.y.y.y в конфиге dialup установлен классы трафика для сети 10.0.0.0 Код: netflow.service.link.1=5 IN 10.0.0.0-10.255.255.254 ... netflow.service.link.6=24 OUT 10.0.0.0-10.255.255.254 Все внешние сети нормально считются кроме внутренней (между клиентами ppp) отрывок из детальной статистики Код: Время С адреса С порта На адрес На порт Байт С интерфейса На интерфейс
27.04.2009 14:51:49 10.2.10.2 44500 10.2.6.246 43064 2636025 344 133 27.04.2009 14:51:49 10.2.10.2 44500 10.2.6.246 43064 2636025 344 133 то есть идет задвоение трафика буду благодарен за советы |
|
| Автор: | max [ 28 апр 2009, 10:43 ] |
| Заголовок сообщения: | Re: Обсчет абонентов PPPoE, задвоенный внутренний трафик |
jack7 писал(а): выборка конфига cisco ESR-10008 виртуального шаблона, с которого отправляется поток netflow на BG Код: interface Virtual-Template1 description - Client - mtu 1492 ip unnumbered Loopback2 no ip proxy-arp ip flow ingress ip flow egress peer default ip address pool stat keepalive 6 12 ppp disconnect-cause keepalive lost-carrier ppp authentication chap ms-chap-v2 ppp authorization radius ppp accounting radius ppp ipcp dns x.x.x.x y.y.y.y в конфиге dialup установлен классы трафика для сети 10.0.0.0 Код: netflow.service.link.1=5 IN 10.0.0.0-10.255.255.254 ... netflow.service.link.6=24 OUT 10.0.0.0-10.255.255.254 Все внешние сети нормально считются кроме внутренней (между клиентами ppp) отрывок из детальной статистики Код: Время С адреса С порта На адрес На порт Байт С интерфейса На интерфейс 27.04.2009 14:51:49 10.2.10.2 44500 10.2.6.246 43064 2636025 344 133 27.04.2009 14:51:49 10.2.10.2 44500 10.2.6.246 43064 2636025 344 133 то есть идет задвоение трафика буду благодарен за советы уберите что то одно из этого на всех интерфейсах: Код: ip flow ingress
ip flow egress |
|
| Автор: | jack7 [ 28 апр 2009, 10:44 ] |
| Заголовок сообщения: | |
на других и не было
а на указанном, если убрать подсчет, например исходящего, будет некрасиво. |
|
| Автор: | max [ 28 апр 2009, 19:07 ] |
| Заголовок сообщения: | |
jack7 писал(а): на других и не было уберите на внутреннем одну комманду и добавьте на внешнем противоположную!
а на указанном, если убрать подсчет, например исходящего, будет некрасиво. |
|
| Автор: | Феанор [ 28 апр 2009, 19:22 ] |
| Заголовок сообщения: | |
jack7 писал(а): на других и не было
а на указанном, если убрать подсчет, например исходящего, будет некрасиво. почему некрасиво? у вас исходящий от одного клиента на циске будет считаться на входящем интерфейсе виртуального интерфейса другого клиента. другое дело, что если убрать исходящий на виртуальных интерфейсах, то придется считать его на какой то из других железок (допустим пограничный на интернет). вообще идеальный вариант ставить везде считать только исходящий трафик. (входящий к клиенту будет считаться на исходящем порту его виртуального интерфейса). исходящий от него будет считаться на исходящем интерфейсе пограничника. мы по крайней мере других вариантов не нашли |
|
| Автор: | jack7 [ 28 апр 2009, 20:24 ] |
| Заголовок сообщения: | |
ок, спасибо за советы - завтра подумаем и попробуем реализовать что-либо из указанного |
|
| Автор: | neo100 [ 10 июн 2009, 13:29 ] |
| Заголовок сообщения: | |
аналогичная проблема... наилучший вариант конечно считать и исходящий и входящий трафик прямо на виртуал интерфейсах - потому как при этом на коллектор поступает только интересующий его поток, где лишней информации практически не будет. Для меня это важно так как нетфлоу поток с пограничного с интернетом роутера почти 10 мегабит. При этом конечно будет задвоение межабонентского трафика 
Если поднять нетфлоу на всех роутерах и считать только исходящий трафик (входящий при этом конечно тоже посчитается так как в пределах сети для какого-то роутера он будет входящим), однако при этом размер нетфлоу потока будет весьма большим и в нем будет много лишней информации о том виде трафика, который к предмету биллинга отношения не имеет... Что же делать? Хорошо бы межабонентский трафик выделить в отдельный класс и как-то делить его на два
Возможно ли такое? |
|
| Страница 1 из 1 | Часовой пояс: UTC + 5 часов [ Летнее время ] |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|