MagMike

Второй слева парень на выставке будет выкрикивать то же самое, что написано?

загрузку процессора чем смотрите? vmstat не покажет, а вот "mpstat -P ALL 1" во время тормозных пингов должен показать 100% softirq как минимум на одном из CPU - на том, к которому "прикреплена" проблемная сетёвка. всё потому что карточка работает с одним процессором (ядром). вывод - надо ставить сетевые, имеющие несколько очередей, каждая из которых может обрабатываться отдельным CPU. например, на базе 82576.

вот уж действительно - "оптоволоконный - это оптом, на волах и конях" :)

Дык все просто - надо сделать возможным указывать ник при заполнении анкеты участника и указывать его на бейджике вместе с ФИО.

насчет скоростемерялки от яндекса не соглашусь. запускаю тест - показывает 2 мбита. одновременно запускаю 2 теста. каждый показывает по те же 2 Мбита, но общая загрузка канала, естественно, выдает 4 мбита - отдельной программой снимаю показания загрузки своего подключения. добавляю еще один тест. все вместе выдают 6 - каждый по те же 2 мбита. Может быть, конечно, как-то связано с браузером и какими-нибудь его модулями/плагинами или с географической удаленностью от сервиса (задержки и всё такое). Но тут же беру спидтест.нет до нескольких разных серверов - все четко - скорость соответствует тарифной. вот и сейчас замерял... http://internet.yandex.ru/informer/horizontal/3021-2392.png и тут же три разных сервера в районе МСК - Мегафон - 16 Мбит/с, Химки 14, Долгопрудный - 6. Наиболее просто для провайдера, imho, поднять у себя какой-нить сервачок, который будет периодически замерять скорость до нескольких, заранее определенных спидтестовских серверов (благо выбор есть) и по результатам замеров строить графики в том же мртг. по ним и ориентироваться - какой наиболее кашерный в плане рекомендуемого пользователям

у меня подобная проблема - высокая загрузка - была, когда в одном из route-map-ов забыл указать "set".

а сделать route-target import 1:40 для vrf1 и route-target import 1:30 для vrf2 не надо?

не удивлюсь, если по техзаданию и в смете на поставку систем видеонаблюдения было заявлено оборудование, дающее качественную картинку. но как всегда - попилили.

Как в Ваших краях погода? Как показывает практика, погода очень хорошо коррелируется с количеством пользователей и загрузкой внешних каналов? чем меньше тянет на улицу, тем тяжелее провайдеру :)

если не секрет, какие тарифные скорости у этик 2к сессий?

Спорить не буду - возможно, что на серверах домена .ru всегда было 4 суток. не обращал внимание. Просто мне казалось, что таких проблем раньше не было и зоны можно было переносить на другие адреса вполне быстро и без простоя, если заранее выставить достаточно малый TTL. Наверное поэтому думал, что на .ru-шных серверах TTL-ы повторяли те, которые указывали у себя праймари сервера доменов второго уровня. С точки зрения управления анонсами и предупреждения проблем, подобных той, которая была у клиента dewil'а, это было бы вполне оправдано.

Я пока периодически вынужден делать принудительную очистку кеша - rndc flush. Раньше такой проблемы не было. а последние где-то пол-года-год - пользователи стали жаловаться... Может поменяли политику на "корневых" для домена ru серверах, никто не в курсе?

смотрю TTL, который выдают серверы, обслуживающие зону .ru, и TTL, который указаны для NS-записей на dns-серверах, обслуживающих конкретную зону второго уровня. попробую более разжеванно. странно, но сейчас и ns5.yandex.ru отвечает с TTL 345600 Поэтому возьму другой домен - mail.ru. запрашиваю NS-запись для домена mail.ru у сервера ns9.ripn.net dig -t ns mail.ru @ns9.ripn.net получаю ;; AUTHORITY SECTION: mail.ru. 345600 IN NS ns5.mail.ru. mail.ru. 345600 IN NS ns1.mail.ru. mail.ru. 345600 IN NS ns3.mail.ru. mail.ru. 345600 IN NS ns.mail.ru. mail.ru. 345600 IN NS ns2.mail.ru. mail.ru. 345600 IN NS ns4.mail.ru. ;; ADDITIONAL SECTION: ns.mail.ru. 345600 IN A 94.100.178.70 ns1.mail.ru. 345600 IN A 94.100.179.159 ns2.mail.ru. 345600 IN A 94.100.186.189 ns3.mail.ru. 345600 IN A 94.100.178.66 ns4.mail.ru. 345600 IN A 94.100.178.64 ns5.mail.ru. 345600 IN A 94.100.178.54 т.е. если верить самому ns9.ripn.net, NS-записи ссылаются на ns[1-5].mail.ru. при этом TTL для этих записей - 345600. если тут же запросить непосредственно один из мэйлуршных DNS-серверов, dig -t ns mail.ru @ns1.mail.ru получаю ответы с TTL 3600: ;; ANSWER SECTION: mail.ru. 3600 IN NS ns4.mail.ru. mail.ru. 3600 IN NS ns.mail.ru. mail.ru. 3600 IN NS ns3.mail.ru. mail.ru. 3600 IN NS ns5.mail.ru. mail.ru. 3600 IN NS ns2.mail.ru. mail.ru. 3600 IN NS ns1.mail.ru.

В последнее время часто стали обращаться пользователи, держащие свои домены второго уровня и переехавшие с одного хостинга на другой. Жалуются, что через день-два после переезда наш dns-сервер отдает старые адреса либо что вообще ничего не возвращает. При разборе обнаружил, что серверы, отвечающие за домен ru, во всех записях NS доменов второго уровня выдают TTL 345600 (4 суток). при этом авторитетные dns-серверы выдают гораздо меньший TTL. вот, для примера, dig +trace -t ns ya.ru ... ya.ru. 345600 IN NS ns5.yandex.ru. ya.ru. 345600 IN NS ns1.yandex.ru. ;; Received 98 bytes from 194.85.252.62#53(ns9.ripn.net) in 38 ms ya.ru. 7200 IN NS ns5.yandex.ru. ya.ru. 7200 IN NS ns1.yandex.ru. ;; Received 98 bytes from 213.180.193.1#53(ns1.yandex.ru) in 45 ms т.е. яндексовские dns-ы выдают TTL 7200, а ns9.ripn.net (один из 7ми серверов, обслуживающих .ru) сообщает 345600 Из-за такого дикого ТТЛ и возникают проблемы - мой dns, закешировав положительный ответ незадолго до миграции домена, продолжает обращаться за данными домена к старым днс еще в течение 4 суток, получая в ответ устаревшие данные или NXDOMAIN Раньше, насколько я помню, не было проблем при миграции доменов на другие серверы. предварительно можно было поставить достаточно небольшой TTL и миграция проходила быстро и безболезненно. кто-то уже сталкивался с этим? как-то можно повлиять на TTL на ru-шных DNS-ов?

первым делом просто - ethtool <iface> карточка-то на гиг поднялась или может только на 100? мало ли - глюкануло что-то при перезагрузке...

а под линукс что-то аналогичное uTPControl-а есть? или придется новые и новые сигнатуры выискивать? кстати, вроде бы нашел вот такие: -m string --hex-string "|2001000041379e|" --algo kmp --from 36 --to 42 -m string --hex-string "|200100005ef573|" --algo kmp --from 36 --to 42

проблема-то, насколько я понимаю, в том, что у pppd (а точнее, даже в самом ядре) счетчики октетов - 32битные. поэтому в самом pppd, когда он обновляет счетчики в своих внутренних структурах, надо вести учет того, что произошло переполнение разрядности и как только это происходит - увеличивать на 1 счетчики Gigawords. а потом еще надо "научить" плагин radius заполнять атрибуты Acct-Input-Gigawords и Acct-Output-Gigawords Все это моё imho.

Тоже был в первый раз. Много полезного извлек. Спасибо всему коллективу nag.ru за то что у нас есть КРОС! в соседнем топике была высказана мысль о двух непересекающихся сообществах. Фактически - админы/технари и манагеры/управленцы. А может по образу олимпиад - летние-зимние - разделить КРОС на два - на одном обсуждать технические вопросы, на другом - правовые и организационные? Одного боюсь - наговцам будет тяжко...

можно утилитой dhcdrop посылать фейковый RELEASE

ну так ранее (на 4й странице) было предложено -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44

true.ru Ну так поделитесь, что сделали-то?

sdy_moscow У меня замечена такая бага. Когда завершается pptp-сессия, у клиента оборудование тут же коннектиться, причем что странно, коннект организуется теми же процессами pptpd и pppd. хотя при дисконнекте должна полностью разрываться не только pppd-сессия, но и pptp. т.е. новое соединение должно организовано на новых процессах pptpd и pppd. но этого не происходит. Но что самое противное, pppd для новой сессии не обнуляет счетчики трафика. т.е., к примеру, сессия продлилась 1000с и скачано было 15 гигов, она заканчивается, начинается новая. И в счетчиках трафика уже лежат те самые 15 гигов. такое поведение замечено у di-[68]04.

удалось справиться с этой проблемой. бага была в исходниках pptp-1.3.3, а точнее в определении параметра unique_id, которые используются в accel pptp. в 1.3.4 это подправили. тупо скопировал одни новые сорцы в сорцы ацеля, собрал бинарники, перезапустил пптп. сейчас тестирую. на момент написания поста аптайм сессии 15 мин. ранее более трех минут сессия не держалась. отпишусь о тестировании чуть позже. update: аптайм сессии сутки. полет нормальный. ну-ка, ну-ка... это случайно не та бага, которая приводит к тому, что сессия как бы рвется, но тут же устанавливается заново в рамках того же pptp и ppp-соединений. т.е. на радиус скидывается Session-ID тот же самый, что только что был, но самое плохое, что и счетчики трафика не сбрасываются? т.е. юзер отвалился с наработкой 100МБ, тут же образуется новая сессия, где наработка начинается с тех же самых 100МБ... так еще сессии, бывает, колбасит так, цепляется на 1-2 сек., тут же разрывается и снова цепляется. и так - несколько раз подряд. Кстати, такое поведение было замечено еще и на DI-[68]04.

Сталкивался с таким... Если оба туннеля терминировались на одном и том же NAS-е - результат печальный - CPU пожирался весь, так что не получалось даже с консоли доступ получить.

6 RP 43% / 42% 44% 45% по крайней мере видно, что с RP связано... route-map-ы есть? полисироутинг? vrf-ы используются?