NiTr0

dhcdrop в помощь

600+ грн атом, 200+ грн нормальный БП (можно конечно и кодеген/гембирд какой, пару лет проработает но лотерея, либо корпус с таким БП за те же 200+ грн), 80-100 грн плашка памяти (б/у - дешевле), SATA DOM - 160 грн что ли, с 4 гигами на которых хоть конем гуляй. Можно USB флэш - дешевле будет, хоть и ИМХО менее надежно. Итого в районе 1к грн тазик, в несколько раз (минимум) мощнее микротиковской мыльницы. +150 грн карточка на атеросе (из тплинков что-то на выбор). Дешевые длинки у кого-то тоже работают годами без проблем. Потом проблемы таки начинаются. Обычно с железом (сохнут кон

А почему бы не купить в те же линукс роутеры какие-нить атомы + пристойные БП? И какой-то эмбеддед дистр на флэшке/DOM для полноты счастья воткнуть, чтобы избавиться от винчестеров - самой частой причины отказа (ну после говеных БП ессно)? Откуда такая уверенность в магической надежности soho железок (или роутерборды уже как энтерпрайз позиционируются)?

Прибор измеряет только сопротивление заземляющего контура при наличии возможности вкопать 2 контрольных электрода в грунт. То, что сопротивление контура - величина не постоянная, какбы и так понятно. По измерению сопротивления - таки да, лампочка (а лучше - не просто лампочка, а набор нагрузок, хотя бы несколько штук - эдак с ~5 Вт/8кОм, для обеспечения относительно безопасного тока в 25 мА, заканчивая утюгом на пару кВт) между фазой и предполагаемой землей, и измерение просадки напряжения при подключении каждой из нагрузок самый эффективный вариант в условиях чердака.

При большом кол-ве маков отваливается веб-морда (не всегда, не везде, но бывает). Больше особо проблем не заметили

В нормальных условиях железо на брасе берется с запасом. Как минимум на 1/N при максимально наблюдаемом трафике, где N - кол-во брасов. Лучше - больше, дабы не было пиковых перегрузок при авариях, и для минимизации задержек и т.п. при загрузке проца порядка 100%. Это во-первых. Во-вторых - повторюсь, ограничивать входящие коннекты полкой в 100% загрузки проца есть редкий идиотизм. Хотя бы потому, что при этом лаги юзерленда из-за 100% отжирания ресурсов ядром будут налицо - а это и дропы сессий, и т.п. прелести. И компетентность человека, такое рекомендующего - весьма спорный вопрос... В-тре

А как тогда понимать ваше ? По-хорошему как раз брас не должен склеиваться. Вообще. Грамотный выбор резерва, в крайнем случае - настройка лимитов коннектов. Но уж никак не скукоживание при авариях, попагандируемое вами как единственно верное решение для избегания переполнения пула. Ровно такое же, как и ваше утверждение о том, что более одного браса будет "прекрасно" работать со статической маршрутизацией. 1) Как на эту ситуацию повлияют аж 5-10-20 IP для локальных сервисов? 2) Какое отношение это имеет к теме? У ТС есть особо убогая железка, которая не может пережевать 5-1

Бред (с). Что, подбирать медленное железо или специально добавлять тупые правила файрвола, чтобы при приближении нагрузки к пиковой брас начало таращить, и абоны начали крыть матом ваш саппорт? И уж тем более при аварии одного из брасов остальные не должно таращить из-за перегрузки клиентами. А хочется странных извращений со статической маршрутизацией и фиксированными пулами - можете ограничить число коннектов (для пппое). Хотя все равно это еще не значит, что при аварии одного из брасов на всех абонов хватит половины всего диапазона адресов. Ни разу не замечал никаких неудобств от /32

Вы знаете, как при статическом разбиении AS на подсети с привязкой подсети к брасу, при условии наличия нескольких брасов, полностью использовать всю AS при краше одного из брасов? Без динамики ессно. Я вообще-то о дефолт роуте в квагге, либо - параллельно с квагговским, но с большей метрикой. Который будет работать при падении квагги. Да что объяснять-то, есть у него подсеть 91.xx.xx.0/27 (/28) между серверами - ее как area 0 объявить, и делов-то. Хотя проще внутри пользовать серую адресацию а на серверах поднимать белые адреса с маской /32, несколько ip сэкономятся.

ip r в студию. должны быть маршруты типа таких: 192.168.123.0/24 via 192.168.255.83 dev vlan1 proto zebra metric 20 ну и конфиги с живого тазика zebra.conf: hostname testpoint password <passwd> enable password <passwd2> log stdout ! interface vlan1 bandwidth 1000000 multicast ! line vty ! ospfd.conf: hostname testpoint password <passwd> enable password <passwd2> log stdout ! router ospf auto-cost reference-bandwidth 1000 redistribute connected redistribute static network 192.168.255.64/27 area 0.0.0.0 ! line vty ! Соседей принудит

На доме выходные цепи БП имели гальваническую развязку от земли/нуля дома или нет? Если нет - возможно, действительно образовалась следующая ситуация: перекос фаз + импульсная помеха, пришедшая по питанию, прошила емкости гальванической развязки роутерборда, при этом емкости в конверторе выжили; далее - благодаря перекосу фаз опять-таки потек ток по цепи ноль/замля дома - медные жилы - минусовой "провод" стабилизатора (там же управляющий элемент в разрыве пллюсового провода, а минус входа и выхода соединены?) - масса роутерборда - пробитые кондеры - грозозащита - труба. Хотя если заземлены ещ

Не спорю, что можно. Только печали будут в любом случае - и неэффективное использование адресного пространства при краше одного из серверов (особенно смешно будет если абонов после краша окажется больше, чем доступных адресов), и принципиальная невозможность выдачи статических ип, и прочие "прелести". Прекрасно все расшифровывается. Ну попутал человек брас и бордюр. Если вам этого не видно из контекста сообщения - пичалька... Или вы просто попридираться к мелочам решили? Дефолт роут (можно даже с большой метрикой, чтобы с дефолтом из квагги не конфликтовал) с кваггой что, уже непри

Не спорю, можно и не вводить, можно и с десятком брасов жить без динамики, но печально... Все там понятно из контекста. Если квагга ипанется вдруг, ипанется и bgp, и добраться до серверов можно будет только через ssh с бордюра, и то если на бордюре есть дефолт роут. По дефолту на вебе и т.п. - бордюр. Т.е. - все через бордюр шурует. Вопрос - накой? О том, какая пичалька будет при падении бордюра - ни на форуме отпостить новость чтобы саппорт разгрузить и хомяков успокоить, ни диагностику из локалки произвести - помолчу. А я где-то писал, что это всенепременно должно бы

Если ospf вводить - почему бы не ввести его везде? Внимательно читать не пробовали? В первом же посте ТС говорит, что будет разносить брас и бордюр на 2 разные железки. Т.е. статика уже отпадает, по-хорошему. Статика в теории сработает, но надо будет прописывать статикой и на бордере, и дефолт на серверах. + весь локальный трафик при этом будет гулять до серверов через бордер - что есть криво. И это неприменимо в ситуации, когда есть канал на мир и украину отдельно, на разных бордерах, либо если есть 2 бордера (хотя там не через оспф уже а через ibgp надо транслировать маршруты, ка

А зачем ему динамическая маршрутизация, если всего хостов меньше чем пальцев на руке и из за этих хостов похоже ничего выглядывать не будет? 1) на будущее 2) выделять реальные ИП хостам удобнее с динамикой, поднял адрес /32 - и пришло счастье. Пока сеть маленькая - оно не заметно, а станет 2 браса, да кучка сервисов на разных IP, да еще виртуализация если где-то, да еще что-то - тут-то оспф и сгодится весьма сильно... Почему бы сразу не настроить и не ознакомиться с возможными граблями?

Поднимайте оспф везде, приоритеты давайте основным серверам (бордюр, биллинг) - которые наиболее стабильны и наиболее критичны (т.к. падение DR приводит к перестройке таблицы маршрутов, с сопутствующими лагами)

E3-12x0 вообще не имеют встроенного видео А накой? Мсье предпочитает экономить на спичках? Ладно, понимаю, какой-то бордер/брас, где 1-2 сбоя в неделю в обрабатываемых данных проблем не составят и пройдут незаметно, но если это какой-то хостинг/сервер БД/прочее - стабильность намного важнее, чем сэкономленные 5$ на памяти.

В зависимости от бюджета. Дешево и сердито - тплинки вебсмарты. Работают вполне адекватно.

dd if=/dev/sdX of=/dev/null bs=1M в помощь... нормальный винт с живой поверхностью спокойно 100+ МБ/с даже в конце должен отдать ИМХО.

Одиночный винт в один поток прекрасно выдаст 120-130 МБ/с, отсюда выводы...

Нет, проблема возникает только когда за промежуток времени проходит более 4 ГБ. Переполнение - явление нормальное (и обрабатываемое rrdtool адекватно), т.е. если сейчас 3.9 гига а через Т - 100 МБ, это будет оценено как 200МБ трафика. А вот если сейчас 2 гига, а за промежуток прошло 4.2ГБ трафика - следующее показание будет 2.2ГБ, тут-то кактусу крышу и сорвет...

При интервале опроса в 5 минут - переполнение вроде при 120 мбитах идет...

Есть такое. Дропается пакет либо сервер чуть дольше отвеяает на него, чем кактус ждет. Как лечить - хз, тоже послушаю советов. По снмп ручками опрос нормально.

Свои плюсы есть, да. Есть и некоторые минусы, особенно - на дешевых коммутаторах. В частности, необходима поддержка multicast vlan в железе - иначе, если понадобится внедрять iptv, будет мучительно больно, особенно если на дом с 50+ абонами кинут один гигабитный линк. Зато слепить vlan per user можно из говна и палок, даже на дешевых мыльницах, всего лишь еепромку или МК, конфигурирующий свич при буте, впаять, либо по RRCP конфигурить. На писюке с линем все прекрасно, вланы вида ethX.Y.Z получаются... Даже DES-3200 поддерживают стекирование. Ессно, виртуальное, проприетарные "косты

<p> </p><p>Как минимум, в спорных случаях, когда налицо явная невозможность идентифицировать абонента, решения должен принимать человек. Номер договора, адрес, ФИО - третий вопрос. Иначе как вы определите, абонент ли работает, или малолетний хакер Вася, узнавший чужой логин-пароль?</p> <p>Контролировать верность принятия решений автоматикой опять же по-хорошему должен человек. Не обязательно, но желательно. Благое дело, просмотреть уведомление, со статистикой работ на узле и обоснованием принятия решения системой - 30 секунд дела. При необходимости - это уведом