Привет.

Задача. В одной конторе стоит VoIP-АТС, в другой - ее вынос. Кодеки G.729a. Голос идет через линуховый NATтер одной конторы, инет, линуховый NATтер другой конторы. Из-за нежелания светить потроха АТС на весь инет, было принято решение прокинуть между ними VPN и не давать им публичных айпишников.

При этом встает вопрос приоритизации трафика данной VPN, чтобы какой-либо "качок" из локалки не смог придушить голосовые каналы.

Насколько я знаю poptop, в ём нет ни diffserv, ни QoS. Будет ли работать ядреная система QoS на виртуальном интерфейсе pptpd? Нужно ли трогать реальную ethernetину, идущую к провайдеру? Не стоит ли предпочесть другую реализацию VPN? (желательна минимизация объема трафика и задержек, так что шифрование, наверное, стоит предпочесть наиболее шустрое.)

Спасибо! я.

Привет. Издревле мой байнд стоял в своем родном конфиге, будучи открыт всем запросам. Сейчас 96% сислога занимают сообщения а-ля
Lame server resolving "SUPERPORN.COM" from xxx.xxx.xxx

Как я понимаю, народ пытается поюзать меня как халявный ДНС. В девятом байнде появилась опция recursion - и я даже прожил парочку дней со значением no, пока меня не покусали мои собственные юзеры - поскольку байнд перестал ресолвить что-либо кроме своих собственных зон.

Нутк вопрос: как отлупать импортных халявщиков, НО продолжать отдавать миру свои зоны, И продолжать работать ресолвером для своих локалок?

Спасибо!
я.

Где бы скачать сабж? Если есть у кого, был бы премного благодарен.

Удачи!

Привет. Идиотическая ситуация, скажу сразу. 
По нужде пришлось сделать новый рутер вместо старого. Три интерфейса - локалка, ДМЗ, инет. Правила содрал со старого.

Со следующими правилами из инета в ДМЗ и обратно - всё ок, из локалки в ДМЗ и обратно - ок, из локалки в инет - НЕ ЛЕЗЕТ!!!

$IPTABLES -I FORWARD -i $LAN_IFACE -o $INET_IFACE -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -s $LAN_NET -o $INET_IFACE -j SNAT --to-source aaa.bbb.ccc.ddd
$IPTABLES -I FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -s $LAN_NET -o $DMZ_IFACE -j SNAT --to-source aaa.bbb.ccc.ddd


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

Спасибо,
 я.

Привет. Фигня какая-то. Зависает ftp-cессия при попытке законнектиться ко мне pasv'ом. Началось после апгрейда профтпд. Возможно, это лично мой косяк в настройке рутера (другая машина), но тогда бы это наблюдалось с момента перенастройки рутера, а не профтпд...?

Если кто сталкивался - это бага или фича?

Привет. Недавно тут писал про попытки сбить рабочий гейт на 2.6.14, все возможные и невозможные препятствия, начиная от зависания железа и заканчивая вываливающимся в кору fetchipac'ом.

Вроде, справился.
Если кому-нибудь интересно, выложу тут инфу о том, как прикрутить ipac-ng 1.31 (по всему судя, девелоперы его больше не поддерживают) к iptables, собранным для 2.6, а также о том, как перелить имеющуюся статистику из ipac-ng 1.21 в 1.31 (формат базы изменился полностью).

А нет - так и флудить нечего.

Удач,
я.

Привет.

Собираю сервер (intel se7500cw2, intel SRCU32, intel pro1000). Жужжит, работает. Компиляю 2.6.14.2, ставлю. Работает. Поработал полсуток - зависло до ресета. Обресетил. Теперь спорадически виснет раз в полчаса-час. Ни на экране ничего, ни в логах.

Грешил на мамку, ладно, поменял. Еще с неделю поработало. Зависло. Обресетил. Грузится. Естественно, system has been shut down uncleanly. e2fsck. Прочекало 74% - виснет. Ресет. 74% - виснет...

Плюнул. Сделал mke2fs наново. Включил, ушел домой - утром висит.

Сегодня попробую выкинуть raid, поставить ide-шный диск и поглядеть. Но странно это всё - если raid работает, так он работает, а нет - так нет...

Память? Вторая битая мамка? ПРОЦЕССОР?!! Или всё же raid?

Спасибо за советы,
я.

Привет. Я в глубочайшей скорби: шесть лет я считал трафик при помощи сабжа - и вот. Переехал на mdk10/2.6.14.2 (не смог подружить старое ядро с новым железом) - и старый добрый ipac-ng 1.21 попросту не линкуется, а 1.31 выпадает в кору при первой же попытке поставить правила.

R.I.P.

Что теперь юзать?.. Поделитесь опытом, плз.

Вот к этому: http://www.linux.org.ru/jump-message.jsp?msgid=1196944

Есть ли возможность отследить, какой из виртуальных хостов, сконфигуренных на один айпи, пытаются досить? netstat тут не поможет, логи в динамике не отловишь, грубых дыр в пхп пока не заметил...

А?

Заинтересовался вопросом (http://www.linux.org.ru/jump-message.jsp?msgid=1180454).

Дело было вечером, делать было нечего. Скачал sysbench-0.4.3, собрал.

На машине 2XeonPIII@1GHz (pc133) 2.4.21 он показал mem i/o 240MB/s, на машине 1XeonP4@1.8GHz (pc4200) 2.6.14.2 mem i/o было 70MB/s.

То ли парень я красивый, то ли sysbench слегка неправ. Знает ли кто объективный тест скорострельности памяти и сети?

Спасибо! я.

Swap: 4192924k total, 0k used, 4192924k free, 821060k cached
Почти гиг памяти расходуется зазря, я верно понимаю? Если да, то как отключить кеширование неиспользуемого свопа? Прибить своп не предлагайте, бо понадобиться реально может.

Спасибо,
я.

Сабж.

Есть две мамки, думаю, какая лучше для скоростного рутера.

Привет.

Помучил 2.6.14.2 на веб-мейл-днс машине, вроде, молотит ок. В связи с тем, что 2.4.х кривовато поддерживает мое железо (http://www.linux.org.ru/jump-message.jsp?msgid=1162579), есть мысль поставить 2.6 и на рутер (2хP3Xeon@1GHz, 512M RAM, Intel SRC-U31a RAID, Intel Pro100+Pro1000, 30-40 клиентских NAT-локалок, две DMZ, шейперы, squid, socks, ipac-ng).

С полгода назад слыхал, что 2.6 еще сыроваты. Есть ли аргументированные мнения за и против?

Спасибо! я.

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

Входит - eth0 от провайдера, 100М.
Выходит - eth1 на ДМЗ (100М) и транк eth2 (100М) с кучей виланок и фейковыми подсетками (192.168.*.0) для клиентуры.

Теперь меняем eth2 на гигабитную. Виланки сразу вздыхают легче, но легче ли становится машине? Она продолжает получать прерывания от трех сетевых карт сразу! Чтоб уменьшить количество прерываний, предлагается оставить ОДИН гигабитный адаптер, а бывшие eth0 и eth1 ввести в транк. Логично!

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

Я предложил оставить eth0(100M) и eth2(1G), а веревку к ДМЗ ввести в транк. С таким конфигом машина доступна хоть откуда-то, если летит одна из сетевух, плюс - ingress буфер eth0 не забивается посторонними пакетами - и из инета всё идет с максимальной скоростью.

А что думают уважаемые гуру?

Привет. Пробовал кто?

Привет.

Вчера сутки имел интим с серваком, так и не понял, что за. Вкратце задача заключалась в переезде на новый raid-массив и контроллер. Прицепил к своему компу (i875) контроллер (SRCU31a), проинитил массив, поставил мандрык 10 (единственный известный мне дистр, который с лёту подхватывает интеловские raid`ы), загрузился без проблем.

Скачал ядро 2.4.32 (пока не доверяю 2.6, на дистре стоит 2.6.3 - может, разубедит кто?), скомпилял, поставил. Ядро грузится, до инита не доходит. Посмотрел опции лила - ага, devfs=mount. Скомпилял с поддержкой devfs, сделал initrd - шуршит, молотит, красота.

Переткнул массив с контроллером на сервер (i7500cw2) - и оппппа! Непосредственно перед инитом вываливается "mkrootdev: failed to create inode: 17" и всё. Висеть не висит, инит не грузит... Тут я впервые увидел nash, ее linuxrc и вообще осознал, что я НЕ ПОНИМАЮ, что это за хрень и зачем она нужна. Ну и почему она не работает, тоже не понял.

Внимание, вопрос: нафига нужен devfs, зачем ядро не может грузиться по старинке, напрямую цепляя init, а нуждается в initrd, хитровыколупнутым методом перемонтирующем все файловые системы, как наперсточник на рынке, и как можно (и можно ли) избежать этой ашыпки? Все драйвера вкомпилены в ядро, так что мне этот initrd нафик не сдался, всю жизнь без него работал.

Пока, проebookавшись с 19 вечера до 04.30 ночи (перекопав этот initrd, linuxrc, /dev и т.д.) не добился ничего понятного, оставил машину работать на 2.6.3 и поехал спать. Сижу вот боюсь, бо слышал про проблемы 2.6 и интеловских raid`ов...

Посоветуйте, плз, знатоки!

Спасибо,
я.

Привет.

Перелезаю с raid-контроллера Intel SRC-U21 (UWSCSI2) на U31 (U160). Насколько я понял доки, просто перецепить массив со старой карты на новую, как хотелось, не получится, поэтому придется строить новый массив.

Внимание, вопрос. U21 работал через драйвер i2o, медленно до жути, но это я списывал на 32-битный PCI и scsi2. Сейчас будет pci64/33 и U160, к тому же появился родной интеловский драйвер, gdth. Что предпочесть?

Дело в том, что сильно изменится логическая адресация устройств - было /dev/i2o/hda*, станет /dev/sda, т.е. просто бекапом уже не обойтись, придется весь конфиг менять. Есть ли смысл, шустёр ли родной драйвер?

Спасибо за советы!
я.

Return-Path: <loz@spamtest.ru>
Received: from c-66-41-17-190.hsd1.mn.comcast.net (c-66-41-17-190.hsd1.mn.comcast.net [66.41.17.190])
        by mail.myownmailserver.ru (8.13.4/8.12.9) with SMTP id j9RAtVsD016665;
        Thu, 27 Oct 2005 14:55:32 +0400
Message-ID: <000b01c5dac9$47e37da0$3c7e77d4@>
From: "user777" <loz@spamtest.ru>
To: Postmaster@.ru
Subject: =?koi8-r?B?8uXt7+70IO7h8vX27u/qIPLl6+zh7fk=?=
Date: Thu, 27 Oct 2005 11:37:25 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_0006_01C5DAEA.CD5A0B40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Status: O
X-UID: 218422
Content-Length: 11660
X-Keywords:                                                                                                    

------=_NextPart_000_0006_01C5DAEA.CD5A0B40
.....................

Что-то в "железках" никто не отвечает...

http://www.linux.org.ru/profile/billy/jump-message.jsp?msgid=1076510&last...

Привет.

Пока в инет шла 10-мегабитная веревочка, сервачок, собранный на двух гигагерцных ксеонах-коппермайнах с гигом памяти, справлялся лучше некуда. SNAT/DNAT/IP Filtering/squid/stats для сорока виланок - вот и вся нагрузка.

Однако с апгрейдом канала до 100мбит/с начал потихоньку лагать - особенно заметно на пингах большими пакетами. А мне еще скоро апгрейдить внутренний интерфейс до гигабитного...

Ну не 7206VXR с NPEG1 же ставить!

Думаю, где узкое место. Сквида уже скоро уберу, однако, есть идея, что затыкаются ядреные процессы обработки пакетов. Есть ли смысл менять железяки?..