Dark_Angel

Мирорить на свитче во-первых не вариант по ряду причин, чтобы не засорять тему их тут не пишу, во-вторых это всегда можно успеть. Интересует именно механизм мирроринга на линуксе.

Добрый день. Есть необходимость миррорить трафик на линуксовой машине. Миррорить надо именно выборочно ( предполагается iptables ), поэтому весь порт смиррорить на порту коммутатора - не вариант. Читал, что есть неофициальный таргет ROUTE с параметром --tee. Но iptables 1.3.5 у которых он есть в extensions не собирает таргет, потому что у ядра нет к нему модуля. Ядро 2.4.37. Более свежие iptables не имеют этого модуля у себя в extensions. Patch-o-matic-ng который добавляет этот модуль больше не поддерживается netfilter.org а его замена только для ядер 2.6.х Существует ли выход из данной ситуации, кроме замены системы на 2.6.х и сборки этого модуля? Заранее спасибо.

2photon: А вы пробовали ставить значения таймера выше 1000? Нормально работало всё?

Я перепутал IntMode с ITR. Однозначно должно стоять 2, если карта поддерживает. Это самый "дешевый" и производительный режим работы.

Это количество прерываний на очередь. Итого у вас 16 очередей, а не 8. По 8 на каждый интерфейс. Да еще и ITR стоит 2, вот только что это за режим?

2Justas: Процессор разгонять, конечно, не надо на роутере. Если у вас все 4 ядра честные, тогда гут. Тут, кстати правильно kayot подсказывает насчет rss/rfs - может помочь, попробуйте. Я лично, не знаю как работают софтовые очереди, так как не было необходимости. Если же у вас есть под рукой сетевая с MSI-X, то меняйте и не парьтесь. Поможет радикально. Остальные моменты упомянутые здесь при этом тоже нужно реализовать.

Тут не про новые и старые вопрос, а про 1.8 новый и 3.6 старый. Так вот старый на 3.6 сделает новый при такой же количестве ядер на чистом роутинге. У вас есть обратный опыт?

3. Проблема известна, но с решением вы поторопились. Даже не знаю что вам теперь делать, учитывая отсутствие возможности масштабирования у pptp. Roundrobin DNS и второй сервер? 4. Учтите, что увеличение буфера усугубляет ситуацию. Чем меньше буфер, тем быстрее работает. При вашем трафике однако тут не большой вклад будет. Сразу хотел спросить: ложит ли смена буфера интерфейс или происходит налету? 5. Давайте уберем прервания, посмотрим что будет, переключений контекста действительно не много. 8. Дает ответ на 6) тут кто-то высказывался по этой теме на первых страницах, что из-за неидеальности софта приходиться разносить. Вовсе не потому что загружает под самые яйца, так что разносите, иначе проблему можно искать долго и в результате всеравно не найти. Насчет Ксеонов, да, даже несмотря на больший в 2 раза L1 кеш у последнего. Но у вас-то не чистый роутинг. UPD. Кстати, а откуда это? Этот ксеон может 4Ггц но работает на 1.8? External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 1866 MHz Если у него 2 ядра, а остальные HT, то HT на роутерах вреден и его надо отключать. С другой стороны, у вас опять-таки не чистый роутер. Core Count: 2 Core Enabled: 2 Thread Count: 2

3. Многовато. Я так понимаю это НАС в локальной сети? Зачем там шифрование? 4. Да, статикой прибивайте и после прибивки посмотрите статистику драйвера, нет ли потерь из-за отстутсвия места в буфере. Если будет, подымете до 6К. Для вашего трафика и сетевой 4К - должно быть нормально. Сразу же подкрутите ring buffer. 5. Это что-то левое. Сделайте vmstat 1 и покажите в динамике, потому что судя по тому что Вы показали у Вас 43 прерывания непонятно в какую единицу времени. 6. Нет, iowait от этого не набегает. Дисковые операции плохи не только нагрузкой на ЦП, а переключением контекстов, вымываением кеша у процов, дополнительными прерываниями. Нужно выяснить откуда они идут и постараться их убрать. Это от проблемы, конечно, не излечит, но даст еще немного запаса производительности. Кроме того 190 операций - это не мало, тем более для 1.8 Ггц. 8. ? Но вообще oprofile правильно наводит на проблему - это шифрование. На 1.1К туннелей, я думаю что там порядка 120-150К переключений контекста, если не больше в моменты до захлеба. Уберете шифрование, получите порядка 60% доп мощности. То есть еще столько же тунелей сможете посадить и + столько же трафика пропустить. Еще узкое место - медленный процессор. Не помню есть ли в этой теме инфа или есть в другой, но для роутеров нужны быстрая память и быстрый процессор. Можно не супер производительный, но быстрый. И кешей побольше. Разнести нагрузку по процессорам поможет только наличие гибридных RxTx очередей, если карта умеет или увеличение tx очередей, опять таки есть можно, т.к. у Вас еще есть свободные ядра. UPD. Да, если разнести TX по ядрам - шифрование будет идти на нескольких ядрах, то есть другая сетевая проблему решит, но лиш временно, пока всё не захлебнется. Догадка по поводу шифрования при отдаче пакета в виртуальный интерфейс похожа на правду тем более что arc4 модуль ядра. Я думаю процедура там такова: получаем пакет, пропускаем через iptables, шифруем, переключаем контекст, отправляем в user-space. Зная как сделан pptp - я думаю там еще прикрутили десяток другой переключений туда-обратно. Цифра с количеством переключений контекстом - даст окончательный ответ. Т.к. если их уже и так много, то дополнительные сетевые не разгрузят систему линейно. Хватит на лишних 50Мбит и нагрузка начнет расти экспотенциально. Спасут только радикальные меры. Смена процессора на более быстрый опять таки только отсрочит проблему на лишних 100-150 Мбит.

2Justas: 1. А как Вы прибиваете очередь, если у вас запущен irq balance да еще и 72: 679 471475487 514932072 0 PCI-MSI-edge eth0-tx0 Второе и третье ядро примерно поровну прерываний? 2. Однозначно выключить и прибить руками, причем желательно к последним ядрам самые нагруженые очереди, потому что эти ядра обычно нагружены меньше всего. 3. Езернет интерфейсы не интересны ( вы про них написали до этого ), я спросил про ppp интерфейсы. 4. Это много, опускайте до 4К на очередь. 5. Покажите сколько переключений контекста у Вас сразу. Процессор 1.8 Ггц, это правда? 6. Откуда у вас набегают iowait? 7. Сколько HZ у вас стоит в ядре? 8. А что еще запущено на машине помимо PPTPd? Шифрование, очевидно, сильно грузит систему и это неоднократно обсуждалось тут. Если у вас сетевой НАС, то с шифрованием вам надо будет ставить в 4 раза больше НАСов, чем без него. Поэтому обычно шифрование на НАСах у всех выключено - и без того проблем достаточно.

2Justas: несколько вопросов: 1. Почему у вас tx очередь к ядру не прибита? 2. Включен ли irq balance? 3. Сколько суммарно интерфейсов у Вас? 4. Сколько прерываний выполняет каждая очередь?

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

Имеется сервер с rp-pppoe-3.10-6 и pppd-2.4.5-15, то есть последние. Было обнаружено странное поведение при флуде PADT от кривого "домашнего" роутера: поступают запросы вида: Dec 26 10:03:03 nas5 pppoe-server[13954]: PADT for session 17 received from 00:1A:70:9E:98:0D; should be from 00:C0:26:69:5F:7F Dec 26 10:03:04 nas5 last message repeated 96 times Dec 26 10:03:04 nas5 pppoe-server[13954]: PADT for session 1 received from 00:1A:70:9E:98:0D; should be from 00:13:D4:8D:C5:58 Dec 26 10:03:04 nas5 pppoe-server[13954]: PADT for session 17 received from 00:1A:70:9E:98:0D; should be from 00:C0:26:69:5F:7F Dec 26 10:03:05 nas5 last message repeated 28 times Dec 26 10:03:06 nas5 pppoe-server[13954]: PADT for session 1 received from 00:1A:70:9E:98:0D; should be from 00:13:D4:8D:C5:58 Dec 26 10:03:06 nas5 last message repeated 46 times Dec 26 10:03:06 nas5 pppoe-server[13954]: PADT for session 17 received from 00:1A:70:9E:98:0D; should be from 00:C0:26:69:5F:7F Dec 26 10:03:07 nas5 pppoe-server[13954]: PADT for session 1 received from 00:1A:70:9E:98:0D; should be from 00:13:D4:8D:C5:58 Dec 26 10:03:07 nas5 last message repeated 14 times Dec 26 10:03:07 nas5 pppoe-server[13954]: PADT for session 17 received from 00:1A:70:9E:98:0D; should be from 00:C0:26:69:5F:7F Dec 26 10:03:07 nas5 last message repeated 2 times Dec 26 10:03:08 nas5 pppoe-server[13954]: PADT for session 1 received from 00:1A:70:9E:98:0D; should be from 00:13:D4:8D:C5:58 Dec 26 10:03:08 nas5 pppoe-server[13954]: PADT for session 17 received from 00:1A:70:9E:98:0D; should be from 00:C0:26:69:5F:7F Dec 26 10:03:08 nas5 last message repeated 2 times и если флуд жесткий, то сервер через время делает. Время бывает разное, бывает 30 минут, бывает 10, видимо зависит от интенсивности флуда: Dec 26 09:13:01 nas5 last message repeated 772 times Dec 26 09:13:01 nas5 pppoe-server[14903]: Terminating on signal 15 -- killing all PPPoE sessions Флуд, понятное дело, обрезать не проблема, проблема в том, что сервер падает почему-то, хотя не должен и видимых причин для этого, очевидно нет. Так же не понятно кто шлет этот прекрасный сигнал. Сервер в kernel-mode. Какие есть варианты как побороть? Спасибо.

2JMan: покажите больше технической информации: сколько прерываний, переключений контекста, кто большего всего систему грузит, размер таблицы НАТ, количество фильтров шейпера и другие параметры системы в процессе полной загрузки. Я думаю всем будет интересна именно эта информация. Касательно HT: Да, вымывает кеш и растет оверхед на перегрузку этого кеша в реальных ядрах. Получается ситуация, как будто очереди к ядрам не прибиты. Там примерно такая же потеря производительности при этом: 30%. Видимо на 50-60% оверхед не так видно, а потом начинается лавина. Вообщем для роутинга НТ однозначно отключать. Касательно 8000 прерываний. Всего 8К на все очереди или каждая очередь делала 8К?

2Iva: а что говорит профайлер? Если у Вас 275 Kpps только на одно из направлений, то сколько всего проходит через данный интерфейс? Насчет HT подтверждаю проблему с деградацией скорости, тоже наблюдали в тех же пределах ( после 60% начинает задираться загрузка ), просто меня удивило, что разница в 11 раз должна была получиться. Да, где-то 30-40%

2Гость_nag-f_*: а что, HT может давать такую деградацию? В 11 раз? Что-то мне кажется дело не в HT.

Если внешний NAT адрес один, а не пул. Или пул, но жестко прибитый, можно обойтись сбором флова до НАТ, а после уже не собирать.

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

Они хотели 600 грн или 120 грн за переподключение? То есть или то или то, или я не понял?

Списали деньги за прошедших 11 месяцев, а за текущий месяц списывать не стали. Там даже за текущий месяц не плохо получилось. Созвонились с клиентом, поговорили, ситуацию объяснили, клиент ситуацию понял, обещал расчитаться. Но, лично я, не считаю, что так правильно было делать - нужно было работать с полной суммой. Но я согласен со всеми высказавшимися - ситуация скользкая и правильно объяснить свою позицию будет сложно. Не правильная трактовка может вызвать негативную реакцию и клиента бы мы потеряли, чего, очевидно, не хотелось, несмотря на то, что он вел себя по отношению к нам не честно. Примерно так разрулили. Всем спасибо.

C клиентом никто еще не говорил, т.к. не ясно какую позицию занять. А если долг спишут, то клиент и не узнает, что случилось. Просто трафик начнет считаться.

То есть на сколько я понял, почти все высказывающиеся считают, что долг нужно списать?

Насчет примера с помидорами и со скоростью у провайдера: все они примерно подходят под данную ситуацию с одной оговоркой: Вы как второе лицо поступаете не честно в отношении первого лица. Вам дали больше чем 1 кг помидор, и Вы решили этим воспользоваться. Вам дали больше 2 Мбит и Вы решили этим воспользоваться. В данном случае первое лицо несет янвый убыток, а Вы несете явную сверхприбыль. Причем Вы точно знаете, что покупали 1 кг помидор, а не 2. С поставщиком оборудования - тоже самое. Если Вы заказали одну кошку, а Вам привезли 3 - Вы тоже заберете, а потом скажите, что, мол, нефиг было ошибаться или всетаки обратите внимание поставщика, что количество заказаного и привезенного по факту товара не совпадает? Т.е. вопрос добросовестности. У нас был случай, когда аплинк ошибся и у нас скорость на канале не резалась, согласно купленой полосе. Ну и ничего, позвонили, сказали - потому что мы партнеры. То же самое с клиентом. Я отношусь к клиенту как к партнеру и расцениваю такое поведение как недобросовестную игру. Жаль, что с юридической стороны нет комментариев - было бы интересно почитать. Насчет админ ошибки мнение понятно: не было бы её, не было бы и прицидента, но она есть и прецендент есть. И никто не говорит, что человек допустивший ошибку - не виноват, просто тут не одна его вина, вот в чем как бы основной вопрос. Идея про самый дорогой тариф на какое-то время - интересная, возьму как вариант. Оплата канала по полосе, т.е. фактически денег мы не потеряли, но и выгоду упустили. Я считаю, что это одно и то же.

Ок, а как тогда быть с GSM операторами, которые могут в течении года выставить счет за услуги роуминга? И выставляют. Насчет аналогии с ГАИшником тут не согласен. Мы же не играем в "словил", "не словил" в данном случае. Оказывается услуга, которая стоит денег. Услуга оказана в полном объеме - данные прошли. Услуга явно заказана клиентом, т.к. он эти данные передавал/принимал. Учитывая, что услуга не разовая, а заключен договор, разве мы не имеем права довыставить счета за оказанные услуги? Ведь услуги таки были оказаны, но увы не оплачены.

Добрый день, господа. Возникла такая не приятная ситуация. Есть клиент. У клиента пакет с оплатой по трафику. Пакет имеет предоплаченый трафик и абонку. Клиент спокойно ним пользуется. Затем происходит перенастройка подключения клиенту и в следствии административной ошибки со стороны провайдера трафик клиента перестает обсчитываться. То есть трафик считается ( флов ), но не обсчитывается. Спустя 11 месяцев это замечают. До этого заметить было не реально, т.к. клиент своевременно платил за услуги и в принципе заметили это случайно при смене мака на его машине. Трафик досчитывают и оказывается, что клиент весьма значительно выходил за пределы трафика предусмотреного пакета. На вопрос по поводу, почему клиент не сообщил про отсутствие цифр на личной странице клиент отвечал не внятно, что он туда якобы не смотрел и вообще платил по выставленным счетам. Он лжет и это видно нескольким параметрам: есть логи веб сервера, где видно, что он заходил на страницу статистики именно трафика, где ничего кроме этой самой статистики трафика нет, соответственно там делать, кроме как смотреть статистику трафика - нечего. Более того, заходов за месяц намного больше, чем 1, 2 или 10. Второе, клиент разбирается в компах и прекрасно знает что такое пакет оплаты по трафику, соответственно совершенно ясно зачем он ходил смотреть статистику и это вполне здоровое желание. Третье, это после 2-го месяца отсутсвия подсчетов по трафику у клиента резко возрастает потребления трафика в 9 раз и примерно в таком же состоянии находится до момента обнаружения проблемы. Четвертое, это то, что за это время, были объявлены уже новые, более выгодные пакеты для работы в Интернет, но клиент на них не переходил. Вопрос в том, как быть. Ошибка с нашей стороны очевидна и никто её отрицать не собирается, но и отсутствие сигнала со стороны пользователя явно не правильное поведение. Я, лично, расцениваю это как езду на машине с неисправным спидометром, а потом доказыванием ГАИшнику, что ты всегда так ездиш и нормально. Ситуация, конечно, утрирована, но суть примерно такая. Уже пару раз были подобного рода ошибки у нас. Обычная схема решения проблемы была такая: мы 50% долга спиываем за свою ошибку, остальные 50% реструктурируем так, чтобы клиенту было удобно их гасить. В данном случае сумма настолько большая, что даже если забрать оттуда 50% и реструктурировать долг - клиент всеравно его платить не будет, либо будет платить 10 лет, что тоже не имеет смысла. Кроме того, есть конкуренты, котрые с радостью его заберут. Клиент платит вовремя - претензий к нему по оплате никогда не было. По договору мы не обязаны предоставлять клиенту статистику по расходу в определенном временном промежутке. То есть даже, если это 11 месяцев - никакой из пунктов договора не нарушается. Дело происходит в Украине, поэтому требования к сертификации биллинга тоже отсутствуют. То есть юридически мы вроде как правы. Возможно у кого-то были похожие ситуации? Как бы вы поступили в данном случае? Заранее спасибо за ваше время.