Baneff

Для интересующихся результатом по сути вопроса топика. Таки было принято решение ограничится одним тазиком, который уже есть и на доступе стоит. Там установить DHCP relay для обеспечения основной задачи - добавление в запросы клиентов информации об интерфейсах, с которого пришли эти запросы. Это требуется для дальнейшей раздачи клиентам параметров в соответствии с интерфейсом, к которому они подключены, а не в соответствии с МАС адресом клиента, как это предполагает стандартная схема. А вот DHCP сервер было решено расположить на арендованном виртуальном сервере, который где-то там в облаках. Почему так? Посчитали, что расходы на покупку, обслуживание, охлаждение и бесперебойное электрообеспечение своего второго физического сервака не имеют смысла по сравнению со стоимостью аренды виртуалки - 3.5 евро/мес при помесячной оплате, при оплате наперёд - скидка. Там у заказчика имеется уже такой арендованный виртуальный сервер для других целей, так вот, поинтересовался я аптаймом того сервака и был сильно удивлён. Таки смотрите сами: > uptime 11:44 up 506 days, 1:47, 1 users, load averages: 0,07 0,12 0,14 Вот как его арендовали полтора года назад, так он с тех пор и крутится без остановки, то есть надёжность такого решения исключительно высока, для своего физического сервера обеспечить такое довольно затруднительно. Короче всё работает как надо без лишних затрат, постепенный переход со старой схемы авторизации на новую вполне возможен, заказчик доволен результатом. И для себя попутно сделал я ещё один вывод: всё что можно унести в облачные виртуалки нужно туда уносить, надёжность от этого повысится, стоимость эксплуатации уменьшится. Где-то так. Комментарии приветствуются.

И,кстати, гугл таки никто не отменял пока что. Вот тут, например, для интересующихся кратко изложены основные принципы. https://ctopmbi4.wordpress.com/2015/03/23/синхронная-асинхронная-передача-сиг/ Вывод такой: синхронность либо наоборот асинхронность канала никак не должна интересовать потребителя интернет услуг - не его ума это дело, не его уровень.

Тут, вероятно, все слишком молоды для того, чтобы помнить что такое синхронный и асинхронный каналы. Так я напомню. В седую древность, когда интернет подавался с помошью медных витых пар (НС) и скорости измерялись в килобитак/сек существовали соответсвующие модемы для асинхронной связи (более дешёвые и чуть более медленные) и для синхронной связи (более дорогие и чуть более быстрые). Разница там чисто в протоколах передачи и способах синхроизации сигнала. Короче говоря, термины "синхронный" и "асинхронный" совершенно неприменимы к сегодняшним реалиям в области интернет провайдинга, нынче передача информации проискходит на совершенно других принципах. Однако, народ запомнил с тех времён, что синхронный канал - это для пацанов, а асинхронный - это для лохов. Вот и. Кроме того, встречаются случаями, когда под синхронным каналом подразумевалось то, что теперь называется симметричным каналом - это когда скорость на вход и на выход у канала одинаковые. В отличии от асинхронного канала, под которым понимают то, что теперь называется несимметричным каналом - скорость загрузки больше скорости оттдачи, иногда существенно больше. Такое трактование терминов неверно, но приходится с ним считаться ибо глас народа и всё такое.

Настоящие джедаи маны и матчасти не читают . Но, я сделал над собой усилие раз такое дело, прочитал этот фрагмент. Да, наверное dhcpd можно таки привязать только к одному IP, виноват. Однако решению исходной задачи это никак не поможет, увы. Надо ещё и dhcp relay такому научить, а тут облом, у него вообще даже конфига нет. Релей всё равно сядет на все адреса и всё равно запустить dhcpd server после этого не получится ибо порт менять нельзя, только 67.

Так это, не сдерживайте себя. Как вы дошли до жизни такой? Покайтесь, может вам послабление выйдет!

Жду ответа, как соловей лета. Возможно я что-то сделал не так. Спасибо.

Спасибо, вариант рабочий, но увы. Там дорогие белые адреса и их мало. Потеря 75% адресов недопустима. Как раз всё и затевалось, чтобы получить соответствие один интерфейс = один IP адрес.

Зато там можно подключить ДВА БП, вариант для серверной типа :). Только уши забыли в комплект положить. Да, странный аппарат, непонятно куда это и зачем.

Вот ещё интересное. Хоть не в тему, бо только 4 порта, но зато 150$ всего. https://mikrotik.com/product/crs305_1g_4s_in

Опять же, вы пробовали? А я пробовал . ISC DHCP - система многоплатформенная и документация одна общая на все платформы. Да, там написано, что можно собрать с опцией слушать сокеты, а не BPF, вот только там не написано что под FreeBSD эта опция не работает. То есть опция принимается, всё компилится и собирается, но результат тот-же. Тут выше уже писали, что это видимо связано с тем, что на FreeBSD нет другой возможности слушать бродкаст, только вот так. Если так, то даже ковыряние в сырцах ничего не даст, тем более, что это уже слишком, задача того не стоит и всё-же решается просто разделением на два физических сервака. А про вариант с сабнетами я не понял, поясните подробнее, плиз. Поделить сеть на подсети можно, конечно, только это приведёт к потере дефицитных адресов и непонятно как это поможет.

Ну зачем это писать? Вы пробовали? Вы читали что я выше писал? Каждый экземпляр садится НА ВСЕ адреса. Запуск второго экземпляра невозможен. Привязка к интерфейсам на это никак не влияет. Именно это и проблема. При чём тут 82-я опция? О ней ни слова выше не было и это вообще из другой оперы. Нужна тупая привязка к виланам, привязка к портам и свичам не требуется, так как не поддерживают те свичи такого функционала.

Так тогда надо было сюда админа своего посылать с вопросами или вдвоём с ним тут спрашивать/слушать. Админу лучше всего админить то, что он умеет админить и если смена админа не обсуждается, тогда надо плясать от печки, то есть от него. Если он умеет админить такую систему на одном-двух серваках, то это одно, если умеет на джуниперах - другое, на микротиках - третье. Это всё очень разные сущности и заставлять админа изучать матчасть на лету за счёт мучений юзеров - плохая идея имхо.

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

А можно подробнее? Правда интересно. Что за виртуалки такие и как они помогут в данном конкретном случае увеличить надёжность? Если это виртуалки на локально расположенных серверах, то непонятно зачем, если и одного, ну на крайняк двух дешёвых физических серверов вполне хватает. Дополнительные расходы, на освоение новых сущностей и их поддержку, на лицензии. Это ж не дата центр, это серверная некрупного провайдера там нет стройных рядов стоек с серваками под виртуализацию, там кроме этих одного-двух физических серваков и свичей вообще ничего нет. Что и где там виртуализировать? А если вопрос о виртуалке где-то в облаках или где-то в удалённом дата центре, то как туда притянуть терминацию юзеров и всё прочее, что должно быть расположено локально в силу своей специфики? Я чего-то не понимаю? Объясните, пожалуйста, подробнее.

Можно я ещё немножко тут насорю? У нас стоит задача повысить надёжность? Непонятно чем не устраивает то, что есть. В чём причина ненадёжности? 1. Увеличение кол-ва сущностей не увеличивает надёжность, а уменьшает её. Два сервера менее надёжны чем один, не говоря уже о большем их кол-ве. 2500 юзеров прекрасно выдержит и один сервер, это грубо где-то 3 гбит/с трафика в пиках всего-то. Туда влезет всё, если это дастаточно мощный многоядерный сервак с достаточным кол-вом памяти и он правильно настроен. Стоимость такого сервака сейчас копеечная, он уже 5 лет проработал в дата центре и ещё проработает 10 лет без проблем - там заложен большой запас прочности. В таких серваках очень развита система самоконтроля и имеется дистанционное управление, что немаловажно. Из плюсов - не надо изучать новую матчасть и не надо привлекать специалистов за деньги, всё уже известно. Далее сосредоточится на повышении надёжности. По возможности питание от двух-трёх независимых подстанций с автопереключением или генератор + два UPS-а с аккумуляторами. Два-три независимых внешних канала с BGP. Два недорогих кондиционера для охлаждения, если это серверная без вентиляции. В самом серваке - два блока питания с горячей заменой, дисковая система с горячей заменой дисков. Диски SSD необходимого размера 3шт в RAID1 - вылет одного или двух дисков не приведёт к падению. Ну еще много чего можно сделать за деньги для повышения надёжности. Самое простое - поставить рядом такой-же точно второй сервак для горячей замены - дёшево и сердито. Замена отказавшего сервака на резервный - дело минут. Другое дело, если всё в один сервак не влазит из-за какой-то несовместимости или технологической необходимости. Ну тогда два сервака и один-два в горячем резерве. Ну это всё уже будет супернадёжно и стоить будет сильно дешевле одного MX. Да, ещё важный фактор надёжности - стабильность работы программных решений, конечно там всё должно быть вылизано до состояния работы без вмешательства оператор и перезагрузок в течение длительного времени. Никаких прихождений ногами раз в месяц и ручного вытирания! Профилактика и обновление ПО - только ночью в нерабочее время и как можно реже ибо злить юзеров - себе дороже. Работает - не трогай, никаких экспериментов на юзерах по улучшению и ускорению. 2. Каким образом это увеличит надёжность? Что выход из строя одной трети сети сильно лучше чем если всё поляжет? А вероятности-то перемножаются. Что, Микротики чем-то надёжнее? Постоянные дыры, постоянные обновления. Аппаратно там ничего нет для повышения надёжности. Цена опять же. Необходимость изучения и поддержки новых сущностей, тоже деньги. Главное - не вижу преимуществ в надёжности. 3. Тут вы уже сами ответили - цена, нестабильность, необходимость изучения и поддержки новой матчасти... При такой нагрузке как по мне явно излишне.

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

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

Народ, берегите нервы, к людям надо мягше, а на вопросы смотреть ширше. Для меня, например, очевидно, что проблема топикстартера не в оборудовании, он же сам говорит, что оборудование нагрузку тянет и так. Значит это только то, что если он докупит ещё цельную стойку джуниперов с цисками, то проблемы никуда не денуться, а скорее всего даже усугубятся. Хотя, если деньги нужно просто потратить, то можно и докупить чего полезного в будущем и поставить на склад :). Но это, канешна, чисто моё личное мнение, извините за засирание, я не нарошно, больше не буду :).

Что-то непонятно. Откуда на том сервере при таких раскладах критичные проблемы? Если с нагрузкой справляется, то один раз настроил и больше к нему даже не подходи, всё ж работает. Или у вас админ умный, всё время что-то улучшает? Увольняйте - поможет. Если там нормальное питание и охлаждение, два-три внешних канала с BGP, то правильно собраный и настроенный писюк такое кол-во юзеров будет годами тянуть без проблем. В конце концов можно рядом поставить ещё один точно такой-же писюк для оперативной замены основного если что. А джуниперы - это хорошо, канешна, если деньги чужие. А если свои, так при такой нагрузке лучше их пропить, хоть будет что вспомнить.

Кстати, попробовал сейчас такую связку: релей на локальном компе, а сервер на виртуальном серваке, арендованом где-то в облаках за 3.5 евры в мес. Работает. Это, конечно, экстрим, на как вариант на крайняк... Между релеем и сервером идёт простой юникастовый обмен по udp с порта 67 на порт 67 и обратно, никакой магии. Попутно выяснилось, что продукты ISC действительно работают с клиентами через BPF на очень глубоком уровне стека, еще перед всякими файерволами и тому подобным. Запретить там что-то или перенаправить куда-то правилами файервола невозможно, обмен происходит ниже. Говорят так исторически сложилось, слишком древний и слмшком многоплатформенный продукт, получилось как смогли. Но вот с нелокальными ресурсами эта байда работает стандартно, потому физическое разнесение и помогает. Где-то так.

Увы, связка на одном компе не выходит никак. После установки релея уже ничто в пару к нему не становится ибо 67 порт занят полностью релеем. По крайней мере у меня так. У кого есть в системе второй физический комп, то проблем нет, разносим и работаем. В моём случае там нет второго физического компа, а значит либо доставляем его специально под эту задачу либо используем релеи свичей, ничего другого я не вижу. Как по мне, доставить второй комп проще. Если решите, то, плиз, дайте знать, интересно всё таки.

Похоже, что так, тоже пришёл к такому выводу. Хотелось простоты и однообразия, а релеи на свичах как бы лишние сущности если удалось бы запустит требуемую связку. Свичи разные, с разными системами команд, сегодня одни, а завтра другие и всё это напрягает. Кроме того свич с релеем предполагает определённую ценовую категорию, на дешёвые свичи релеи не ставят, нет функционала. Но делать нечего - не получилось по простому - пойдём по сложному пути. Опять же, если у кого и так есть второй комп под контролем и не нужно доставлять ещё один, то всё прекрасно решается без релеев на свичах. И, если уж на то пошло, таки можно и доставить второй комп, может заодно ещё для чего пригодится.

Пробовал 3-ю версию - аналогично, да и безопасность пострадает, там дыры.С нага и прочее стороннее брал и пробовал, но проблема в том, что всё это потустороннее - это всё DHCP сервера, а рабочий DHCP релей с нужным функционалом по сути наличествует только один, вот этот самый ISC DHCP Relay. Это очень странно, но правильно работать с виланами, а не только с МАС-ами клиентов почему-то может только вот эта поделка. Значит, если мы ставим перед собой задачу все это запустить на одно компе, то первая половина задачи не обсуждается - сначала ставим ISC DHCP Relay. На а дальше всё, тупик. Как я уже говорил этот релей хоть и обеспечивает необходимый функционал, но при запуске сразу и без вариантов биндится на *:67, а после этого уже невозможно на этот комп поставить никакой DHCP сервер, поскольку ему тоже нужно биндиться на 67 порт хотя-бы на один IP адрес, но всё уже тупо занято релеем. Попытки привязать DHCP сервер к другому порту и потом мапить/перенаправлять порты к успеху не привели, возможно я что-то не так делал. Вывод я для себя сделал такой - не хочешь использовать релеи на свичах - ставь второйкомп и разноси физически релей и сервер, всё работает без проблем. Не хочешь ставить второй комп - только схема с релеями на свичах и сервером на компе, тоже работает. А вот первоначальная задача - обойтись одним компом без использования релеев свичей похоже решения не имеет, что обидно конечно.

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

Опция есть, говорит на каких интерфейсах слушать. Но тулза всё равно садится на *:67 без разговоров и это не отключается. В код лезть как-то лениво, видно придётся таки доставить второй комп, может заодно ещё для чего пригодится. Больше идей пока нет.