Перейти к содержимому
Калькуляторы

Реальное применение Option-82 поделитесь опытом - что-то не получается

Описание "грамотно" - В СТУДИЮ!!!!

 

Прошу особо отразить ту часть "грамотности", которая обеспечит отсутствие аномального роста ошибок ТСР.

 

// Люблю я этих, блин, теоретиков... Просто чтобы было ясно: ключевой момент сверху ограничивается 50% пропускной способности канала при необходимости укладки линка в half-duplex. Но деталей рассказывать не буду, нам сейчас всё расскажет мега-гуру по обману 802.1X, заодно он нам расскажет, где он возьмёт необходимую аппаратуру, и сколько это примерно может стоить

 

UPD: возможен вариант с НЕ укладыванием линка в халф-дуплекс, но тот, кто это сможет, 200% имеет деньги уж на интернет - точно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из "аппаратуры" понадобится комп с тремя сетевыми платами и еще возможно два свича-мыльницы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Комп понятно, жду описания, что с ним будем делать. А свичи куда? Тоже жду описания, что с ними делать.

 

Незаметно запрятанный в щитке комп - уже интересно, да. Незаметная улика.

 

VCT и неожиданное изменение длины абонентского кабеля пока в расчёт не берём, т.к. в первоначальной задаче не было. Однако помним, что тут тоже прокол.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

vIv, а смысл? Это такой толстый тролль. Ясно, что на практикие никто такого не реализует никогда, но нужно потешить свое ЧСВ, обосрав решение.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну ладно, ладно, отстал :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм.....все что-то высказали, а про реальное применение у себя никто и словечком не обмолвился, видимо всё только в теории хорошо?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот установил BGBilling и проверил DHCP сервер встроенный с поддержкой Option-82 адреса может выдавать только одни и те же., а вот динамически разные никак...Может кто-то это решил?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://forum.nag.ru/forum/index.php?showto...st&p=416015

Как раз недавно это обсуждалось.

Opt 82 предназначен для статики.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в зависимости от масштаба сети - раздавать хоть по 10 адресов на порт(каждый раз может быть новый адрес у абонента из заданной подсети)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Однако как занесло то статью за 5 то лет )))

По теме:

Пытаюсь заставить ISC работать с 82 опцией, много всяких статей и почти все они скопипастены с http://xgu.ru/wiki/DHCP_option_82. В примерох конфигов есть как выдать ип компутеру по номеру порта и номеру вилана, но ведь 82 опция актуальна при использовании множества коммутаторов. Поделитесь конфигом ISC, в котором ип выдается по номеру порта и идентификатору свитча (судя по всему удобно использовать его мак). Наверняка есть у кого нить кусок текста в котором фигурируют больше одного свитча.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Однако как занесло то статью за 5 то лет )))

По теме:

Пытаюсь заставить ISC работать с 82 опцией, много всяких статей и почти все они скопипастены с http://xgu.ru/wiki/DHCP_option_82. В примерох конфигов есть как выдать ип компутеру по номеру порта и номеру вилана, но ведь 82 опция актуальна при использовании множества коммутаторов. Поделитесь конфигом ISC, в котором ип выдается по номеру порта и идентификатору свитча (судя по всему удобно использовать его мак). Наверняка есть у кого нить кусок текста в котором фигурируют больше одного свитча.

 

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

1 - свичи релеят в управляющий влан - в него и надо подключать сервер ISC

2 - ну конфиг можно и самому на писать исхожя из вышеозначенной статьи. Там весьма подробно все разжевано. Примеры конфигов есть на этом форуме

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 - свичи релеят в управляющий влан - в него и надо подключать сервер ISC

2 - ну конфиг можно и самому на писать исхожя из вышеозначенной статьи. Там весьма подробно все разжевано. Примеры конфигов есть на этом форуме

За пункт первый спасибо, понято. А за второй... Можно то оно всё можно, но у меня чего то не вышло вот и спросил, если кому то не в лом ctrl+C & ctrl+V сделать то я буду шибко признателен. Если вы это не в состоянии или не в желании этого сделать - просто проходите мимо и не флеймите. А вообще ответить в таком духе можно на абсолютно любой вопрос и ежели бы все так поступали то подобные форумы заканчивались на объявлении правил.

Изменено пользователем Alex158

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Планирую запустить DHCP с option 82 в сети, где клиент не всегда включен в отдельный порт управляемого коммутатора.

Есть два варианта:

1. Клиент - управляемый порт (тут все понятно).

2. Несколько клиентов - управляемый порт.

Можно ли комбинировать option 82 и выдачу адреса с привязкой по mac? Есть ли примеры конфигов?

Даже в первом случае у клиента может быть несколько ip-адресов на разных ПК (например, внешний и внутренний) и раздавать их нужно именно так, как запросил клиент. То есть в общем случае первого варианта можно сказать нет.

Кто как поступает в этих случаях?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Доступ должен быть умный.

У вас опять начинается мешанина: внешний и внутренний... Надо или внешние отдавать или внутренние.

Лично я за внутренние + нат, для некоторых как допуслуга - binat.

Vlan per user решил бы вопрос нескольких компьютеров у клиента. Отдать клиенту 1 порт, в нем свой влан, в этом влане какая нужна маска сети. Для таких особенных клиентов (их не будет много) отключать ip unnumbered.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Option -82 как я понял такая фича, которая помогает узнать кто откуда пришёл..? но для чего реально нужна не понял может объясните

 

Краткая предыстория:

Ну вот я собрал стенд на доступ взял коммутатор с поддержкой 802.1q далее, на агрегацию 3550. Прописал VLAN-ы на доступе вручную и погнал их в 3550, далее билинг Abills кстати на основе маков выдавал IP с использованием DHCP сервака. Недостаток нужно знать мак клиента, чтобы выдать IP. Могла бы мне помочь Опция -82 в этом вопросе...

 

Всякие мне по поводу применения данной фичи, мне весьма интересны!

Я юзаю опцию82 + arp inspection + dhcp-снупинг. Вполне удобно и работает. Сеть 7000 физиков и все время растет.

Юзер всегда получает свой IP из базы и ручками не пропишет чужой IP, чтобы он не всунул в порт. MAC адреса совсем пофигу.

А придумано это, как я понимаю - чтобы юзать чистый IP траф поверх Ethernet (IPoE) без всяких тунелей и считать траф по юзерскому постоянному IP. Без всякий паролей и тунелей и другой мудаты типа 802.1x

Но у меня пока огород - пока 95% клиентов - юзают не анлимы, а дорогие помегобайтные тарифы (Республика Беларусь, и городок не богатый). Соотвественно стоит остро проблема с утечкой трафа (денег) - не важно - вирусня (бот-неты) или врезка в кабель злоумышленника.

Без пароля - никак пока. Поэтому всетаки юзаем VPN (pptp). Не ppoe - потому что юзаю VLAN на дом и терминирую на агрегации - далее маршрутизация в "ядро".

Локальный траф остается на районе - разрешен за деньги - и немного причесан ACL-ями. (Еще Плюс в том, что не нужно в ядро ничего серьезного, в отличие от схемы без опции82, дешевый доступ + VLAN на юзера - когда ВЕСЬ траф через центр гоняется)

 

 

Хотя перейти на чистый IPoE ничего не помешает в будущем - цены потиху на внешку падают - придем по любому к повальным анлимам - тогда можно без паролей обойтись и тунелей.

 

Только останется один нюанс - белые IP. Сейчас экономия реальная из-за раздачи белых IP "динамически" через тунели . Потом нужно либо кучу адресов держать (фактически = к-ву договоров) - юзер может воткнуть в порт девайс - и получить свой постоянный белый адрес через опцию82 - даже если он инет юзать не будет. И гибкости в маршрутизируемой сети с белыми ip - никакой.

Толи дело сейчас - серые IP - крути как хочешь....

Хотя можно всеже оставить серую адресацию, убрать тунели и - юзать NAT (тоже определенный компромисс, но не нужно юзеру с впн и паролями трахаться).

И СОРМить можно на границе до NAT по серым адресам - они, как мы помним - всегда юзеры одни и теже выдаются через опцию82.

 

Подитожу:

расклад такой:

1. Юзать опцию82 и Если у вас есть куча белых адресов и деньги на них - тогда можно без тунелей и NAT вообще (вариант бывает только в вымышленном идеальном мире - как известно - белые IPv4 - кончаются (все никак не могут кончится : )))), а IPv6 на доступе и агрегации и в биллинге в чистом виде - пока не скоро ожидается такой полноценный функционал со всем фаршем) - вариант пока отпадает (к тому же с белыми IP - большой левый траф по идее на аплинке).

Хотя, чистый IPv6 без всякой мудаты, NAT и тунелей - похоже - это единтсвенно правильный вариант в будущем.

 

2. Юзать опцию82 + тунели - раздаем белые адреса динамически. Экономим белые IP, Имеем гемор, который присущ для тунелей (затраты мощностей и глюки у юзеров с вирусней и заморочки с настройками и саппортом). - ----> такая схема подходит, когда ваша политика "локальный траф разрешен" и должен быть локальным, но безопасным (дорогой доступ со всем фаршем, включая опцию82, чтобы залочить внутренний серый IP для порядка в сетке, и не иметь гимора с подделкой маков, IP, петлями, штормами и т.д.) (Этот вариант - изврат и огород, но я его пока юзаю - слишком дорогой (помегобайтный) траф пока для юзеров)

 

3. Юзать опцию82 без тунелей. Адресация серая. Тогда NATить на границе. Смысл тоже только в том, если разрешать локалку и четко ее контролировать. и СОРМить по серым адресам. (это самый лучший вариант, но нужны анлимы для юзеров )

_____

Таким образом:

Если вам нужна "настоящая локалка" (и при этом когда ВЕСЬ траф реально не ходит через ядро, а остается на районе или уходит в другой район не через ядро) - тогда только стоит брать дорогой доступ со всем фаршем, и нагрузка на ядро гораздо меньше.

Некоторые политически не приемлют таких "локалок" - они считают - на доступ надо что подешевле - только чтобы VLAN умел - далее гнать весь траф в центр на мощный солидный дорогой BRAS - и там ПРЕДОСТАВЛЯТЬ УСЛУГИ - шейпить, разрешать, запрещать, считать ВСЁ, контролировать ВСЁ, NATить, терминировать VLAN и/или тунели (как правило PPPoE).

Эта схема начинает выигрывать, тогда, когда 70 тысяч баков (минимум на ядро - очень грубо и условно) - будет гораздо дешевле, чем куча дорогих свичей на доступе (посчитайте сами количество домов и абонбазу).

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

И еще - если скажут СОРМить "локальный траф" - тогда все "вшивые пионерские локалки" - накрываются сразу же медным тазом - надо гнать все через центр и СОРМить......

(хотя можно СОРМить на агрегации - но нужно тянуть доп. волокно)

 

________________

Так что:

Важно - сколько есть денег инвестировать сразу, что изначально дано ? - уже сеть есть на мыльницах или нормальных свичах или с нуля? Какой ожидается рост абонбазы?

В реальной жизни может быть так, как у нас - денег много сразу нет, а хочется строить сеть - рынок голодный, пустой. Маркетинга нет, Бизнес-плана - нет. Никто не знает - сколько мы наберем киентов - 100 человек, 500, или 2000 ?

Сразу купить мощную байду штук за 70 бакинских - стремно. (А если сдохнит что-нить в ней? : )) А если у нас всего 300 клиентов будет? : )

 

По чуть чуть строим домик за домиком.... База расширяется от 7 человек до 7000.... Конкуренты в шею не гнали (ЭТО КЛЮЧЕВОЙ НЮАНС такого колхозного сетестроения).

Решили - умный доступ - это все же хорошо и кашерно - инвестиции плавные, сеть под полным контролем, можно мультикаст без проблем в будущем пустить (уже пустили). Деньги размазаны по все сети, а центр - дешевый (PC), В этом есть свои плюсы - домовой свич если сдохнет или сервак - легко держать резерв и заменить.

 

А купить мощное профессионально ЯДРО в будущем - не так и сложно , если дорости до этого из молодой небольшой сети в МЕГАПРОВАЙДЕРА : )))

(а вот доступ весь заменить - сложнее)

 

 

____________________________________________

Я ничего не напутал? (столько уже про это написано - но всегда актуально и интересно обсудить и поспорить : )

Изменено пользователем white_crow

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Option -82 как я понял такая фича, которая помогает узнать кто откуда пришёл..? но для чего реально нужна не понял может объясните

 

Краткая предыстория:

Ну вот я собрал стенд на доступ взял коммутатор с поддержкой 802.1q далее, на агрегацию 3550. Прописал VLAN-ы на доступе вручную и погнал их в 3550, далее билинг Abills кстати на основе маков выдавал IP с использованием DHCP сервака. Недостаток нужно знать мак клиента, чтобы выдать IP. Могла бы мне помочь Опция -82 в этом вопросе...

 

Всякие мне по поводу применения данной фичи, мне весьма интересны!

Я юзаю опцию82 + arp inspection + dhcp-снупинг. Вполне удобно и работает. Сеть 7000 физиков и все время растет.

Юзер всегда получает свой IP из базы и ручками не пропишет чужой IP, чтобы он не всунул в порт. MAC адреса совсем пофигу.

А придумано это, как я понимаю - чтобы юзать чистый IP траф поверх Ethernet (IPoE) без всяких тунелей и считать траф по юзерскому постоянному IP. Без всякий паролей и тунелей и другой мудаты типа 802.1x

Но у меня пока огород - пока 95% клиентов - юзают не анлимы, а дорогие помегобайтные тарифы (Республика Беларусь, и городок не богатый). Соотвественно стоит остро проблема с утечкой трафа (денег) - не важно - вирусня (бот-неты) или врезка в кабель злоумышленника.

Без пароля - никак пока. Поэтому всетаки юзаем VPN (pptp). Не ppoe - потому что юзаю VLAN на дом и терминирую на агрегации - далее маршрутизация в "ядро".

Локальный траф остается на районе - разрешен за деньги - и немного причесан ACL-ями. (Еще Плюс в том, что не нужно в ядро ничего серьезного, в отличие от схемы без опции82, дешевый доступ + VLAN на юзера - когда ВЕСЬ траф через центр гоняется)

 

 

Хотя перейти на чистый IPoE ничего не помешает в будущем - цены потиху на внешку падают - придем по любому к повальным анлимам - тогда можно без паролей обойтись и тунелей.

 

Только останется один нюанс - белые IP. Сейчас экономия реальная из-за раздачи белых IP "динамически" через тунели . Потом нужно либо кучу адресов держать (фактически = к-ву договоров) - юзер может воткнуть в порт девайс - и получить свой постоянный белый адрес через опцию82 - даже если он инет юзать не будет. И гибкости в маршрутизируемой сети с белыми ip - никакой.

Толи дело сейчас - серые IP - крути как хочешь....

Хотя можно всеже оставить серую адресацию, убрать тунели и - юзать NAT (тоже определенный компромисс, но не нужно юзеру с впн и паролями трахаться).

И СОРМить можно на границе до NAT по серым адресам - они, как мы помним - всегда юзеры одни и теже выдаются через опцию82.

 

Подитожу:

расклад такой:

1. Юзать опцию82 и Если у вас есть куча белых адресов и деньги на них - тогда можно без тунелей и NAT вообще (вариант бывает только в вымышленном идеальном мире - как известно - белые IPv4 - кончаются (все никак не могут кончится : )))), а IPv6 на доступе и агрегации и в биллинге в чистом виде - пока не скоро ожидается такой полноценный функционал со всем фаршем) - вариант пока отпадает (к тому же с белыми IP - большой левый траф по идее на аплинке).

Хотя, чистый IPv6 без всякой мудаты, NAT и тунелей - похоже - это единтсвенно правильный вариант в будущем.

 

2. Юзать опцию82 + тунели - раздаем белые адреса динамически. Экономим белые IP, Имеем гемор, который присущ для тунелей (затраты мощностей и глюки у юзеров с вирусней и заморочки с настройками и саппортом). - ----> такая схема подходит, когда ваша политика "локальный траф разрешен" и должен быть локальным, но безопасным (дорогой доступ со всем фаршем, включая опцию82, чтобы залочить внутренний серый IP для порядка в сетке, и не иметь гимора с подделкой маков, IP, петлями, штормами и т.д.) (Этот вариант - изврат и огород, но я его пока юзаю - слишком дорогой (помегобайтный) траф пока для юзеров)

 

3. Юзать опцию82 без тунелей. Адресация серая. Тогда NATить на границе. Смысл тоже только в том, если разрешать локалку и четко ее контролировать. и СОРМить по серым адресам. (это самый лучший вариант, но нужны анлимы для юзеров )

_____

Таким образом:

Если вам нужна "настоящая локалка" (и при этом когда ВЕСЬ траф реально не ходит через ядро, а остается на районе или уходит в другой район не через ядро) - тогда только стоит брать дорогой доступ со всем фаршем, и нагрузка на ядро гораздо меньше.

Некоторые политически не приемлют таких "локалок" - они считают - на доступ надо что подешевле - только чтобы VLAN умел - далее гнать весь траф в центр на мощный солидный дорогой BRAS - и там ПРЕДОСТАВЛЯТЬ УСЛУГИ - шейпить, разрешать, запрещать, считать ВСЁ, контролировать ВСЁ, NATить, терминировать VLAN и/или тунели (как правило PPPoE).

Эта схема начинает выигрывать, тогда, когда 70 тысяч баков (минимум на ядро - очень грубо и условно) - будет гораздо дешевле, чем куча дорогих свичей на доступе (посчитайте сами количество домов и абонбазу).

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

И еще - если скажут СОРМить "локальный траф" - тогда все "вшивые пионерские локалки" - накрываются сразу же медным тазом - надо гнать все через центр и СОРМить......

(хотя можно СОРМить на агрегации - но нужно тянуть доп. волокно)

 

________________

Так что:

Важно - сколько есть денег инвестировать сразу, что изначально дано ? - уже сеть есть на мыльницах или нормальных свичах или с нуля? Какой ожидается рост абонбазы?

В реальной жизни может быть так, как у нас - денег много сразу нет, а хочется строить сеть - рынок голодный, пустой. Маркетинга нет, Бизнес-плана - нет. Никто не знает - сколько мы наберем киентов - 100 человек, 500, или 2000 ?

Сразу купить мощную байду штук за 70 бакинских - стремно. (А если сдохнит что-нить в ней? : )) А если у нас всего 300 клиентов будет? : )

 

По чуть чуть строим домик за домиком.... База расширяется от 7 человек до 7000.... Конкуренты в шею не гнали (ЭТО КЛЮЧЕВОЙ НЮАНС такого колхозного сетестроения).

Решили - умный доступ - это все же хорошо и кашерно - инвестиции плавные, сеть под полным контролем, можно мультикаст без проблем в будущем пустить (уже пустили). Деньги размазаны по все сети, а центр - дешевый (PC), В этом есть свои плюсы - домовой свич если сдохнет или сервак - легко держать резерв и заменить.

 

А купить мощное профессионально ЯДРО в будущем - не так и сложно , если дорости до этого из молодой небольшой сети в МЕГАПРОВАЙДЕРА : )))

(а вот доступ весь заменить - сложнее)

 

 

____________________________________________

Я ничего не напутал? (столько уже про это написано - но всегда актуально и интересно обсудить и поспорить : )

Очень похоже на мой сценарий в центре стоит PС-к на базе iCore7, доступ умный и трафик локальный часто до ядра не доходит, настоящая локалка, на доступе мини -колхоз, но он себя оправдывает :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перечитал всю тему .. ответа на свой вопрос не нашел(((

Уже описал здесь пока добрался в эту ветку.

 

Помогите понять в чем соль.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перечитал всю тему .. ответа на свой вопрос не нашел(((

 

Эээ... Стесняюсь спросить...

В чем вопрос-то?

 

PS. Тему "ниасилил многа букаф", но сам уже с пол-года раздаю инет с использованием opt82. Для подключения нескольких компов не обязательно ставить роутера, копеечного свитча будет достаточно. Белые адреса даются натом наружу/внутрь (думали тоже в dhcp воткнуть, но так проще оказалось). Проблем не наблюдается :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Перечитал всю тему .. ответа на свой вопрос не нашел(((

 

Эээ... Стесняюсь спросить...

В чем вопрос-то?

 

PS. Тему "ниасилил многа букаф", но сам уже с пол-года раздаю инет с использованием opt82. Для подключения нескольких компов не обязательно ставить роутера, копеечного свитча будет достаточно. Белые адреса даются натом наружу/внутрь (думали тоже в dhcp воткнуть, но так проще оказалось). Проблем не наблюдается :)

 

Хочется настроить привязку адреса к порту так, чтобы не возникало ситуаций задержек выдачи адреса. Например сейчас модель - 1 адрес на 1 порт. И если адрес был отдан на одно устройство, то простая смена на другое устройство показывает что адрес получить не так просто ибо он якобы отдан, нужно ожидать окончание срока его аренды. При изменении параметров лиз-тайм в сторону уменьшения сервер в логах пишет постоянные запросы от нового устройства и вроде бы как адрес отдан, но по факту - нет. Может поделитесь на каких конфигах работает ваша схема?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хочется настроить привязку адреса к порту так, чтобы не возникало ситуаций задержек выдачи адреса. Например сейчас модель - 1 адрес на 1 порт. И если адрес был отдан на одно устройство, то простая смена на другое устройство показывает что адрес получить не так просто ибо он якобы отдан, нужно ожидать окончание срока его аренды. При изменении параметров лиз-тайм в сторону уменьшения сервер в логах пишет постоянные запросы от нового устройства и вроде бы как адрес отдан, но по факту - нет. Может поделитесь на каких конфигах работает ваша схема?

 

Хех... Еще один :)

Я с этим боролся год назад. В гугле решения так и не нашел. Патчить dhcpd как-то не очень интересно, тем более при каждом обновлении.

Но недавно, вернувшись из интереса к этому вопросу, решил глянуть на omshell (программа из комплекта dhcpd). Пришел к решению слежения за логом в поисках DHCPACK и отправки набора команд в omshell:

 

server $SERVER

port $PORT

key $KEYNAME $KEY

connect

new lease

set ip-address = $IP

open

set state = 00:00:00:01

update

close

 

Таким образом, в логе пролетает:

 

dhcpd: DHCPACK on 1.2.3.4 to 00:11:22:33:44:55 (comp) via 1.2.3.1

dhcpd: lease 1.2.3.4 state changed from active to free

 

Ну и в лиз-файле оно тоже на free меняется.

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

 

PS. На другой сети потому, что у нас выдается по 4 адреса на порт и такая проблема еще не возникала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.