Kaban Опубликовано 29 июля, 2009 · Жалоба А что мешает стоимость внутрисетевого траффика засунуть в фиксированую абонку ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 (изменено) · Жалоба куда ж быстрее, чем тупо покупка свича с netflow/sflow и модуля к биллингу? // это я пока молчу, что sflow/netflow и так в приличной сети нужны для текущего мониторинга загрузки каналов, то есть уже есть заранее... Мне, как разработчику кластерной системы подсчета траффика по направлениям реализованную для европейского оператора связи, несколько удивительно читать про некий модуль к некоему биллингу, который можно просто за 1000$ купить и что то там считать.... в принципе можно, но когда 100-500 клиентов. Подсчет траффика по направлениям/as/ip-абонента (netflow), представляет собой нетривиальную задачу. Назовите мне модуль для биллинга, стоимость самого биллинга, стоимость серверной платформы и не одной, решающей такую задачу для ~10000 абонентов в реальном масштабе времени!. А если их к примеру 100000? Изменено 29 июля, 2009 пользователем nag-f Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikevlz Опубликовано 29 июля, 2009 · Жалоба На UTM5 вроде олимпус считал чуть-ли межабонентский трафик. По моим ощущениям и слежке за новостями достаточно долго, абонентов было больше 10к Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 (изменено) · Жалоба На UTM5 вроде олимпус считал чуть-ли межабонентский трафик. По моим ощущениям и слежке за новостями достаточно долго, абонентов было больше 10к Очень сомневаюсь что в реальном времени. UTM - поделка еще та. Считает траффик по направлениям не в реальном масштабе времени (при >=1000 клиентов и приличном наборе направлений работать уже невозможно). В UTM используется две базы данных - 1-я реляционная PostgreSQL/MySQL , 2-я объектоно-ориентрованная GigaBase в которую помещаются "cырые" данные NetFlow, которые потом в не реальном времени обрабатываются. Время обработки - может достигать и нескольких часов. При большом потоке данных NetFlow - коллектор от Нетапа их не успевает обрабатывать, вледствии переполнения буффера просто теряет. Такой функционал нетапа применим при колличестве клиентов <=500, собственно они об этом сами говорят. Я поставил четкое условие - подсчет в реальном масштабе времени без потерь. Под реальным временем понимается период в 1 сек. Изменено 29 июля, 2009 пользователем nag-f Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SmokerMan Опубликовано 29 июля, 2009 · Жалоба А есть какой-то смысл локалку в реалтайм считать?... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 · Жалоба А есть какой-то смысл локалку в реалтайм считать?... Тут надо понять есть ли вообще ее смысл считать? Ну не хотите давать клиенту бесплатно локальную сеть - зарежте ему скорость на порту до двойной скорости пакета в Интернет и все. За открытие скорости порта - до максимальной снимайте дополнительно оплату. А оперировать терабайтами данных по внутристетевому траффику в нетфлоу при ~10000 клиентов - это нонсенс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 29 июля, 2009 · Жалоба куда ж быстрее, чем тупо покупка свича с netflow/sflow и модуля к биллингу? // это я пока молчу, что sflow/netflow и так в приличной сети нужны для текущего мониторинга загрузки каналов, то есть уже есть заранее... Мне, как разработчику кластерной системы подсчета траффика по направлениям реализованную для европейского оператора связи, несколько удивительно читать про некий модуль к некоему биллингу, который можно просто за 1000$ купить и что то там считать.... в принципе можно, но когда 100-500 клиентов. Подсчет траффика по направлениям/as/ip-абонента (netflow), представляет собой нетривиальную задачу. Назовите мне модуль для биллинга, стоимость самого биллинга, стоимость серверной платформы и не одной, решающей такую задачу для ~10000 абонентов в реальном масштабе времени!. А если их к примеру 100000? Стоп-стоп-стоп... До 5К юзеров я могу дать ответ на-вскидку, на бОльшее - тоже могу, но после некоторых изысканий. Для 10-15К я бы (с условием предварительных тестов) поставил несерийную сборку ЛанБиллинг на распределённой БД (она есть, но как бы не для всех, под заказ). Минус - это решение не будет идти в общей roadmap. А вот дальше, - уже другой класс решений, сорри, если вопрос предметный, я могу сделать запрос, но это будет предметом очень непубличных переговоров. Кстати, на VLAN-per-Customer в жилом секторе есть цифра около 4К юзеров, которую ЖЕЛАТЕЛЬНО локализовывать, ставя локальный коллектор и, по желанию, предбиллинг. Чисто так, для информации: есть минимум два решения: для GSM сетей и Juniper E-Series. технологии там разные, но near-RT присутствует в обоих случаях. Понятно, что это не коробочное решение. Философское: не хотите биллить, станете сантехниками (см. сайт за 2006 год) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 · Жалоба куда ж быстрее, чем тупо покупка свича с netflow/sflow и модуля к биллингу? // это я пока молчу, что sflow/netflow и так в приличной сети нужны для текущего мониторинга загрузки каналов, то есть уже есть заранее... Мне, как разработчику кластерной системы подсчета траффика по направлениям реализованную для европейского оператора связи, несколько удивительно читать про некий модуль к некоему биллингу, который можно просто за 1000$ купить и что то там считать.... в принципе можно, но когда 100-500 клиентов. Подсчет траффика по направлениям/as/ip-абонента (netflow), представляет собой нетривиальную задачу. Назовите мне модуль для биллинга, стоимость самого биллинга, стоимость серверной платформы и не одной, решающей такую задачу для ~10000 абонентов в реальном масштабе времени!. А если их к примеру 100000? Стоп-стоп-стоп... До 5К юзеров я могу дать ответ на-вскидку, на бОльшее - тоже могу, но после некоторых изысканий. Для 10-15К я бы (с условием предварительных тестов) поставил несерийную сборку ЛанБиллинг на распределённой БД (она есть, но как бы не для всех, под заказ). А вот дальше, - уже другой класс решений, сорри, если вопрос предметный, я могу сделать запрос, но это будет предметом очень непубличных переговоров. Чисто так, для информации: есть минимум два решения: для GSM сетей и Juniper E-Series. технологии там разные, но near-RT присутствует в обоих случаях. Понятно, что это не коробочное решение. Да я сам могу предоставить такую информауию и не на вскидку. И прекрасно знаком со стоимостью таких решений. Скажу даже больше, RT - решений для 10-100к пользователей в мире по пальцам рук пересчитать. Одну из таких систем мне довеодилось проектировать и разрабатывать. Собственно поэтому я и говорю - о экономической нецелесообразности подсчета внутрисетевого траффика. Намного эффективней оперировать скоростью порта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 29 июля, 2009 · Жалоба ээ... на порту? уж не про rate-limit ли вы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 (изменено) · Жалоба ээ... на порту? уж не про rate-limit ли вы? Да, преславутый rate-limit. Собственное его недостатки мне не стоит рассказывать. Учитывая, вышеупомнутый метод я оговорил, что скорость должна зарезаться минимум до двойной скорости пакета в Интернет. Лично я не практикую таких извращений и жадностью не страдаю. Изменено 29 июля, 2009 пользователем nag-f Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 29 июля, 2009 · Жалоба Ох, как он без flow control здорово показывает себя на локальном трафике! 8-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 · Жалоба Ох, как он без flow control здорово показывает себя на локальном трафике! 8-) Все зависит от модели используемых коммутаторов. Я использую коммутаторы Alcatel, CISCO - при тестрировании таких схем проблем не было (flow control отключен), хотя все модели с поддержкой flow control. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 29 июля, 2009 · Жалоба wireshark с обеих сторон и флудогенератор ;-) Сравнить выход и получение, особенно в сравнении "ДО" с "ПОСЛЕ". Будете сильно удивлены ростом нагрузки "из ниоткуда". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nag-f Опубликовано 29 июля, 2009 · Жалоба wireshark с обеих сторон и флудогенератор ;-)Сравнить выход и получение, особенно в сравнении "ДО" с "ПОСЛЕ". Будете сильно удивлены ростом нагрузки "из ниоткуда". Я еще раз вам говорю, мне на стоит рассказывать о недостатках rate-limit. Вы предоставляете домашним пользователям CIR каналы? Поставьте "флуд генератор" на гигабитный порт коммутатора, а wireshark на выход со 100Мбитного - будете тоже сильно удивлены. Так что теперь делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vIv Опубликовано 29 июля, 2009 · Жалоба ааа... таки в курсе =) // я ничего никому не предоставляю, я сторонний наблюдатель Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BudushiyISP Опубликовано 29 июля, 2009 · Жалоба Хорошо, Вы мне объясните такое коль здесь мы обсуждаем техническую сложность .... По логике получается так у оператора 4K пользователей он ставить Циску 65xx серии, с Ipunmumberedи прочими полезными фичами..появилось 4001 пользователь он ставит рядом вторую циску. На доступ тут на форуме предлагалось ставить простые свитчи с поддержкой 802.1q и всё. Но если так приглядется возникает разные ньюансы развития сети в будущем. 1)А именно nag-f и vlv вышу обсудили rate-limit на порту...но чтобы его менять на доступе, наверно нужен доступ к коммутатору по snmp, telnet, а свитч от этого не сильно умнеет? 2) И если rate-limit выставлять по диапазону айпи, то наверно это уже точно очень умный свитч? может такого и в природе нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 29 июля, 2009 · Жалоба Хорошо, Вы мне объясните такое коль здесь мы обсуждаем техническую сложность ....По логике получается так у оператора 4K пользователей он ставить Циску 65xx серии, с Ipunmumberedи прочими полезными фичами..появилось 4001 пользователь он ставит рядом вторую циску. Чёйто ? QinQ отменили ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BudushiyISP Опубликовано 30 июля, 2009 · Жалоба Чёйто ? QinQ отменили ?А что даёт эта кукушка , если кол-во L3 İP интерфейсов ограничено? И в каких моделях циски она поддерживается ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 30 июля, 2009 · Жалоба Во всех маршрутизаторах, начиная прямо с 2800 и вверх. На 7600 нужны специальные карты (SIP/SPA). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 30 июля, 2009 · Жалоба 2) И если rate-limit выставлять по диапазону айпи, то наверно это уже точно очень умный свитч? может такого и в природе нет. DES-3526 Flow-meter на основе ACL Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
azlozello Опубликовано 30 июля, 2009 · Жалоба UTM5 нормально считает большие потоки NetFlow, по крайней мере > 4k абонентов проблем не наблюдается. Не нужно путать понятие РЕАЛЬНОГО времени. 1 секунда это уже не реальное время. А по сему я не вижу разницы между 1 секундой и 300 секундами. Это всего лишь время агрегации данных и сверка счетов. Я даже представить себе не могу технологии биллинга считающего трафик в РЕАЛЬНОМ времени :D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrew Rogov Опубликовано 2 августа, 2009 · Жалоба Во всех маршрутизаторах, начиная прямо с 2800 и вверх. На 7600 нужны специальные карты (SIP/SPA). На 7600 платформе с RSP720 и линейными картами серии 6700 QinQ вполне работает. Не без ограничений, конечно, но они не смертельные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 2 августа, 2009 · Жалоба Во всех маршрутизаторах, начиная прямо с 2800 и вверх. На 7600 нужны специальные карты (SIP/SPA). На 7600 платформе с RSP720 и линейными картами серии 6700 QinQ вполне работает. Не без ограничений, конечно, но они не смертельные. подразумевается терминация q-in-q покажите как на картах 6700 терминировать q-in-q Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 2 августа, 2009 · Жалоба подразумевается терминация q-in-qпокажите как на картах 6700 терминировать q-in-q как то так, только не на 67хх:http://www.cisco.com/en/US/prod/collateral..._c78-49152.html А на 67хх только второй тег навешивать можно имхо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ingress Опубликовано 2 августа, 2009 · Жалоба думаю эти слоённые пироги стоят космически ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
