Baneff

Для интересующихся результатом по сути вопроса топика. Таки было принято решение ограничится одним тазиком, который уже есть и на доступе стоит. Там установить DHCP relay для обеспечения основной задачи - добавление в запросы клиентов информации об интерфейсах, с которого пришли эти запросы. Это требуется для дальнейшей раздачи клиентам параметров в соответствии с интерфейсом, к которому они подключены, а не в соответствии с МАС адресом клиента, как это предполагает стандартная схема. А вот DHCP сервер было решено расположить на арендованном виртуальном сервере, который где-то там в облаках. П

И,кстати, гугл таки никто не отменял пока что. Вот тут, например, для интересующихся кратко изложены основные принципы. 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 лет проработал в дата центре и ещё

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

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

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

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

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

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

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

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

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

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