Jump to content
Калькуляторы

Продолжение про трафик/флуд (сверка) Вопрос про общие методы сверки

Можно я отдельно темку подниму в продолжение http://forum.nag.ru/forum/index.php?showtopic=48151 ?

 

Каков нормальный уровень расхождений между показаниями провайдера и пользователя? По вашему мнению, в процентах.

 

И как при превышении нормально проводить сверку? Сталкиваемся же с разными системами подсчета. К примеру, у меня ng_ipacct у прова с его онимой, вероятно, нетфлоу, ежедневные различия бывают и в плюс и в минус. Как ковырять? В условиях, что и у меня и у прова может быть косяк и мы оба никогда в нем не признаемся (вариант: не узнаем, ибо линейные админы не скажут)?

Share this post


Link to post
Share on other sites

А какая разница прову на то "какое по вашему мнению расхождение считается нормальным".

У него же биллинг должен быть сертицифирован. Что таким образом насчитает, то и впишет.

Всякие внутренние счетчики это вообще то для себя. Чтоб каждый раз за более подробной статистикой не обращаться к провайдеру, и более быстро реагировать на неадекватный трафик.

Share this post


Link to post
Share on other sites
Каков нормальный уровень расхождений между показаниями провайдера и пользователя? По вашему мнению, в процентах.
Из опыта - мы проводили сверку при >0.5% различий, хотя в договоре было написано малость побольше ;)

Но это магистрал. И корпоративщики или агрегаторы. И была воля это делать ;-)))

И как при превышении нормально проводить сверку?
Самое нормальное решение - прежде всего убедиться, что кол-во пакетов и байт, ушедших в один интерфейс и вышедших с другого, совпадает. SNMP то есть.

На моей практике при достаточной синхронизации сбора с двух точек (асинхронный запрос с callback) реально достичь разницы в пять-десять пакетов.

При выборке периода времени за сутки эта разница превращается в эпсилон-окрестность.

Дальше сделать выводы, пакеты обязаны совпадать (с той разницей, что я привёл), байты могут отличаться (к примеру, catalyst считает с fcs-полем, if и sub-if на cisco считает без него, на sub-if считается паддинг payload, а на catalyst нет и прочее... подробнее трясти вендора, ну и версии софта тоже влияют на мировоззрение поклонников Гамеша), исходя из разницы в байтах ввести поправку.

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

Потом уже анализировать netflow. Там тоже пакеты должны совпасть (но только если сброс идёт регулярно!!!), а будет ли байты в ng_* совпадать с cisco или juniper видением мира - тайна.

Как-то так.

Share this post


Link to post
Share on other sites
А какая разница прову на то "какое по вашему мнению расхождение считается нормальным".

У него же биллинг должен быть сертицифирован. Что таким образом насчитает, то и впишет.

Всякие внутренние счетчики это вообще то для себя. Чтоб каждый раз за более подробной статистикой не обращаться к провайдеру, и более быстро реагировать на неадекватный трафик.

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

 

Share this post


Link to post
Share on other sites

Угу. Будем считать пакетики, если дадут snmp.

Просто тут еще проблема -- вероятно netflow счетчик и коллектор находятся от меня через 3-4 железяки, и гарантий совпадения само собой нету.

По поводу разрешения тайны ng_* -- netflow на конкретном типе интерфейса буду рыть.

Share this post


Link to post
Share on other sites

вам дать снмп на провайдерской железке??? я культурно пошлю такого клиента... Или я не прав?

Share this post


Link to post
Share on other sites
вам дать снмп на провайдерской железке??? я культурно пошлю такого клиента... Или я не прав?
Если железка держит, нужный view спасает. Если нет, то спасает провайдерский перловик-питонщик-тиклевец, который с удовольствием получит доступ к точке клиента и сольёт в файло сырую инфу, благо кодить там на полчаса. Ну а проанализировать файло можно и самому.

Ну а если у провайдера таких нету, то бороться придётся с ветряными мельницами, но это было озвучено в самом начале. Я рассматривал случай вменяемых людей, готовых идти навстречу.

Опять же если клиент хороший, грех в настоящих условиях его терять. Проще перловика пнуть в зад, чтобы оторвался от чтения спана ;-)

Share this post


Link to post
Share on other sites

две недели назад. жалоба на "низкую скорость" (тариф 6мбит, белый ИП). смотрим МРТГ абонентской железки и видим до НАТ и после НАТ. делаем вывод что кто-то ддосит, предлагаем сменить ИП.

 

PS мртг рисовал я клиенту по знакомству.

zhukov.JPG

Edited by woddy

Share this post


Link to post
Share on other sites
вам дать снмп на провайдерской железке??? я культурно пошлю такого клиента... Или я не прав?

вероятно речь идёт о графике загрузки, если да то почему бы и не дать?

Share this post


Link to post
Share on other sites

Интересный какой вопрос! Уже третий раз за неделю вижу.

 

А если провайдер даст, предположим для простоты, ДВА набора настроек + УРЛ для их смены? За мелкую абонентку. Допустим, в набор настроек входит /30 сетка два раза + УРЛ с паролем. Дёргаешь УРЛ с паролем - настройки меняются местами. Старый теряет маршрутизацию и перестаёт биллиться, новый применяется на абонента и начинает биллиться. В итоге всякие ДДОСы идут в лес.

 

Надо такое?

Share this post


Link to post
Share on other sites
Старый теряет маршрутизацию и перестаёт биллиться, новый применяется на абонента и начинает биллиться. В итоге всякие ДДОСы идут в лес.

 

Надо такое?

скольких клиентов у тебя ддосили? сколько из них готовы платить? сколько из них имеют адекватного админа способного переключить ИП?

 

ИМХО не надо. кроме как "конкретному клиенту за конкретные деньги". а у нас ваще щас безлимиты и на деньги клиент не попадает. только "инет лагает"

Share this post


Link to post
Share on other sites

Во-первых бывало такое, во-вторых и тут жалуются, а в-третьих страховка всегда полезна. Даже если это один случай на сеть, а "застраховаться" захотят с десяток абонентов, - платить будут все десять. Была бы в прайсе такая услуга.

При хорошем ДДОСе не "ИНет лагает", а "полный песец". Канал перегружен мусором.

Share this post


Link to post
Share on other sites

Чтобы чем-то меряться, у этого чего-то должен быть сертификат. У провайдерского биллинга он есть, а чем клиент докажет ? Показания пузомерок типа ворованного tmeter ? В таких разборках отдаем клиенту сырые логи - пусть сам ищет в своей сети за своим nat....

Share this post


Link to post
Share on other sites

трафик инспектор стоит копейки и сертифицирован

Share this post


Link to post
Share on other sites
Чтобы чем-то меряться, у этого чего-то должен быть сертификат. У провайдерского биллинга он есть, а чем клиент докажет ?
Ну, справедливости ради надо сказать, что вполне известно, как у нас получается сертификат на АРС. Достаточно два договора (раньше было, сейчас - не знаю) заключить и денег заплатить. И никуда не надо ездить и ничего не надо показывать. И через полгода приходит бумажка "разрешается использования Остбилл на сети Осттелеком в качестве АСР верхнего уровня". Или что там сейчас пишут?

От хитрых клиентов и связьнадзора, конечно, отмахиваться им можно, но то, что система правильно считает, сертификат отнюдь не утверждает.

Share this post


Link to post
Share on other sites

cae, хочется отметить что клиент не делает даже этого.

Но уже требует соответствия каким то своим мнимым данным, тому что получается у провайдера.

Кажется не с того бока начали.

 

 

 

Share this post


Link to post
Share on other sites
cae, хочется отметить что клиент не делает даже этого.
Не, ну физика с tmeter, конечно, надо отправить в пеший путь сертификации, гемора больше, чем дохода. А с хорошим юриком можно и разобраться плотнее. Приятные "неожиданности" в оборудовании случаются, к сожалению, как shit. И если пострадал от пошедших назад счётчиков кто-то, сам бог велел поделиться ;-) Знаниями ;-)

То есть, как говорил п/п-к Сувернев "Это многое зависит от самого каждого себя". Повторяю эту мантру регулярно. И медленно просветляюсь.

Share this post


Link to post
Share on other sites

Вот, вспомнилось, живая история:

...в техподержке на такое же количества юриков админов больше нужно и т.д. Типичный срок восстановления услуги для физика по договаору 10 дней, для юрика 4-24 часа. Разницу улавливаете?
Например, при проблемах я звоню не в саппорт, а корпоративному манагеру, или админам, или техдиректору, а то и всем сразу. При очередных боданиях магистралов или успешной работе очередного файберфайндера провайдер шустро перестраивает роутинг, чтобы мои клиенты могли достучаться до своих серверов в хер-знает-где. Если что с полосой или с потерями - тоже всё шустро решается, с выездами\заменами оборудования - аналогично. Я уж не говорю о заточке договоров под конкретного клиента и прочих мелочах...

Ну и вообще там упоминался "час пик", приходящийся на юриков, вот этот: http://www.msk-ix.ru/network/traffic.html (21:00 - 23:00)

 

В общем, как обычно: "мы, продавайдеры, клиенту-юрику жёппу готовы лизать, брать за это много денег, но как только клиент приходит утверждать, что жёппа недовылизана, мы его посылаем" :)

 

Ничего личного, просто вспомнил недавние слюнопускания в этом же, между прочим, подфоруме

 

PS. Выделенное красным - словарная редакция МрМиши

Share this post


Link to post
Share on other sites

вам дать снмп на провайдерской железке??? я культурно пошлю такого клиента... Или я не прав?

Не прав. Слать надо некультурно. )

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this