[DemYaN]

Думаю, что на этот вопрос будет дан ответ нет :), но все же...

Есть ли реализации, что бы при использовании DHCP option 82 в circuit ID suboption вносился не номер порта, а VID. Тобишь к порту подключены через краевой свитч несколько пользователей, но каждый в уникальном вилане и в зависимости от номера вилана dhcp выдавал бы уникальный ip. Таким образом можно было бы избавиться от необходимость в использовании коммутаторов с поддержкой option 82 на аксесс уровне.

[Roman Ivanov]

Он и так его дает.

По крайней мере 2950T ;)

и VLAN id, и порт ID ;)

[DemYaN]

Действительно :). Как я уже понял в превых 3550 заносился ifIndex в Circuit-ID, в более поздних vlan-моуль-порт или ifIndex по выбору, а в 2950 вроде только vlan-моуль-порт. Ну это для коммутаторов Cisco, а как интересно с этим обстоит дело у китайско-тайваньско-хзоткуда собратьев? Может кто сталкивался? Там у дликов, планет?

[Vovik]

а зачем вообще использовать этот option 82? На сервере, где запущен DHCP, поднимаешь подинтерфейсы, загоняешь их в нужные VLAN. соотвественно IP у подинтерфейсов должны быть из разных подсетей. Порт сервера (где запущен DHCP) загоняешь в 802.1q транк. В dhcpd.conf прописываешь все подсети через subnet { }. Все - теперь для каждого VLAN будут IPшники выдаваться из нужных уникальных подсетей.

[Ruslan_R]

Ага, и VLAN на пользователя... Не подойдет, уже обсуждалось.

[DemYaN]

Ну да, а если пользователей хотя бы больше 300 и каждый в своем вилане, чем виланы к серверу пробрасывать? Имеется hp5308xl в ядре, так для него 255 виланов потолок, к тому же, гад в circuit ID пишет только порт без всяких виланов :( Да и не хотелось бы лишний трафик к ядру гонять.

[Vovik]

Ну да, а если пользователей хотя бы больше 300 и каждый в своем вилане, чем виланы к серверу пробрасывать?

а как вы сейчас этих 300 пользователей в VLAN распихали? Я так понял, что у вас сейчас один пользователь - один VLAN, судя по первому сообщению.

[DemYaN]

Сейчас с виланами вообще никак :), цель как раз перейти к схеме 1 юзер -1 вилан до уровня агрегации, а там стекается максимум 240-250 пользовательских виланов.

[Vovik]

ну вот - ваша задача в ядре собрать все VLAN. если получится, и ядро выдержит - то проблем с DHCP не будет (см. схему выше). А раз HP свитч держит 255 VLANов, а вам надо 250 - то все укладывается в описанную мною схему. Если нужно больше VLAN, ставите второй HP свитч (или какой другой), только VLANы уже между двумя свичами в ядре пробрасываться не будут. а в DHCP сервер втыкаете два физических линка от каждого свича в ядре.

 

Да и не хотелось бы лишний трафик к ядру гонять.

 

при использовании VLAN весь трафик между VLAN будет гоняться через ядро - по другому никак. а трафик при запросе IP у DHCP сервера не такой уж и большой.

 

Но в идеале - лучше бы другое ядро взять, которое больше VLAN поддерживает.

 

при 300 VLAN - на сервере, где крутится DHCP, создаете 300 подинтерфейсов, на каждом своя IP подсеть (хоть с 30ой маской) . Прописываете 300 подсетей в dhcpd.conf. Запускаете DHCP - проблем быть не должно.

[Alex158]

Доброго времени, у меня вопрос на похожую тему. Мне нужно поднять DHCP в разных подсетях, количество VLAN может не ограничиться несколькими сотнями. Пока есть меньше сотни коммутаторов. Option 82 везде поддерживается. В центр хочу поставить Allied Telesis AT-x900 из за большого количества IP интерфейсов и невысокой цены. Его же планирую сделать шлюзом для всех и все Vlan-ы тоже зарулить на него же. Вопрос в том как мне раздать ИПишники в разных подсетях по номеру VLAN с единственного DHCP сервера который не является шлюзом ни для кого?

Если кто то поделится не только опытом, а ссылками на литературу буду очень рад :)

[cmhungry]

Доброго времени, у меня вопрос на похожую тему. Мне нужно поднять DHCP в разных подсетях, количество VLAN может не ограничиться несколькими сотнями. Пока есть меньше сотни коммутаторов. Option 82 везде поддерживается. В центр хочу поставить Allied Telesis AT-x900 из за большого количества IP интерфейсов и невысокой цены. Его же планирую сделать шлюзом для всех и все Vlan-ы тоже зарулить на него же. Вопрос в том как мне раздать ИПишники в разных подсетях по номеру VLAN с единственного DHCP сервера который не является шлюзом ни для кого?

Если кто то поделится не только опытом, а ссылками на литературу буду очень рад :)

поднимается DHCP relay на х900, он передает на DHCP-сервер номер влана, с которого пришел запрос. DHCP-сервер в конфиге содержит строчки, что для такого влана - такой пул, для такого - такой.

[ifndx]

Навеяло после прочтения темы вот такие вопросы для самообразования

 

1) DHCP-Relay и DHCP Local relay.

правильно я понимаю что в случае Local-relay коммутатор только обрачивает приходящий с порта абонента Discover опцией82 и передает дальше броадкастом?

А релей это опция82+юникаст в сторону сервера?

 

 

2) DHCP-серверу пофиг каким образом прилетает к нему DHCP-discover ?

 

я к тому что может прилететь юникастом с опцией82 или броадкастом, но с опцией82 от dhcp local relay.

или все зависит от настройки DHCP-сервера?

 

3) есть тупой коммутатор который поддерживает только вланы, перед ним стоит DGS-3627/3612.

получится ли включить на D-link опцию так, чтобы в circuit-id он вставлял vlan-id в зависимости от в каком влане пришел запрос и передавал дальше броадкастом?

[xcme]

1) DHCP-Relay и DHCP Local relay.

 

правильно я понимаю что в случае Local-relay коммутатор только обрачивает приходящий с порта абонента Discover опцией82 и передает дальше броадкастом?

А релей это опция82+юникаст в сторону сервера?

В терминах длинка да, только вот опция82 - это реально опция. То есть релей можно настроить и без опции 82.

 

2) DHCP-серверу пофиг каким образом прилетает к нему DHCP-discover ?

 

я к тому что может прилететь юникастом с опцией82 или броадкастом, но с опцией82 от dhcp local relay.

или все зависит от настройки DHCP-сервера?

В целом да. Но, емнип, в случае использования релея меняется порт отправителя. Наш фрирадиус вздумал отвечать коммутатору не на тот порт, пришлось его патчить.

 

3) есть тупой коммутатор который поддерживает только вланы, перед ним стоит DGS-3627/3612.

получится ли включить на D-link опцию так, чтобы в circuit-id он вставлял vlan-id в зависимости от в каком влане пришел запрос и передавал дальше броадкастом?

В последних прошивках длинка опция 82 может очень тонко настраиваться. Но использовать на практике не приходилось. И относится ли это к серии 36xx - не знаю.

 

Вообще с DHCP очень много тонкостей, потому надо смотреть под конкретную ситуацию. Разные устройства по разному интерпретируют протокол, этого уже наелись в свое время предостаточно. Надо стремиться к тому, чтобы схема настолько простой, насколько это возможно.

 

p.s. Если что, то в третьем случае можно будет косвенно определять vlan по шлюзу. Это если напрямую вставить в пакет не получится.

Изменено 19 августа, 2015 пользователем xcme

[ifndx]

1) DHCP-Relay и DHCP Local relay.

 

правильно я понимаю что в случае Local-relay коммутатор только обрачивает приходящий с порта абонента Discover опцией82 и передает дальше броадкастом?

А релей это опция82+юникаст в сторону сервера?

В терминах длинка да, только вот опция82 - это реально опция. То есть релей можно настроить и без опции 82.

 

2) DHCP-серверу пофиг каким образом прилетает к нему DHCP-discover ?

 

я к тому что может прилететь юникастом с опцией82 или броадкастом, но с опцией82 от dhcp local relay.

или все зависит от настройки DHCP-сервера?

В целом да. Но, емнип, в случае использования релея меняется порт отправителя. Наш фрирадиус вздумал отвечать коммутатору не на тот порт, пришлось его патчить.

 

3) есть тупой коммутатор который поддерживает только вланы, перед ним стоит DGS-3627/3612.

получится ли включить на D-link опцию так, чтобы в circuit-id он вставлял vlan-id в зависимости от в каком влане пришел запрос и передавал дальше броадкастом?

В последних прошивках длинка опция 82 может очень тонко настраиваться. Но использовать на практике не приходилось. И относится ли это к серии 36xx - не знаю.

 

Вообще с DHCP очень много тонкостей, потому надо смотреть под конкретную ситуацию. Разные устройства по разному интерпретируют протокол, этого уже наелись в свое время предостаточно. Надо стремиться к тому, чтобы схема настолько простой, насколько это возможно.

 

p.s. Если что, то в третьем случае можно будет косвенно определять vlan по шлюзу. Это если напрямую вставить в пакет не получится.

 

 

 

Благодарю за ответ!

 

1) эта фича распространена среди вендров? не получится ли vendorlock...

3) у нас брас L2-connected.

[xcme]

1) эта фича распространена среди вендров? не получится ли vendorlock...

Может получиться по разному. На Eltex MES2124 есть и тот и другой вариант, но аналог Local Relay (только вписывание опции) работает более предсказуемо. Собственно сам Relay нормально завести можно только имея интерфейс в VLAN абонента. Свичик может срелеить и с другого интерфейса, но там есть нюансы.

 

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

[biox]

ifndx на самом деле есть 2 вещи:

 

1. dhcp snooping - перехватывает dhcp запросы на клиентских портах, вставляет в них дополнительные параметры (опции) и отправляет "с богом" дальше через аплинк порт. То есть запрос идёт бродкастом и распроcтраняется только в пределах одного vlan.

2. dhcp reley - передаёт dhcp запрос из одного vlan в другой vlan, в котором функционирует ваш DHCP сервер.

 

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

[ifndx]

ifndx на самом деле есть 2 вещи:

 

1. dhcp snooping - перехватывает dhcp запросы на клиентских портах, вставляет в них дополнительные параметры (опции) и отправляет "с богом" дальше через аплинк порт. То есть запрос идёт бродкастом и распроcтраняется только в пределах одного vlan.

2. dhcp reley - передаёт dhcp запрос из одного vlan в другой vlan, в котором функционирует ваш DHCP сервер.

 

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

 

 

Спасибо!

 

Всегда думал что snooping это для изоляции левых DHCP-серверов :)

[pppoetest]

1. dhcp snooping - перехватывает dhcp запросы на клиентских портах, вставляет в них дополнительные параметры (опции) и отправляет "с богом" дальше через аплинк порт. То есть запрос идёт бродкастом и распроcтраняется только в пределах одного vlan.

Неправда ваша, изначально dhcp snoop это защита от атак. То что вы описали это обычный dhcp local relay.

[Ivan_83]

Всегда думал что snooping это для изоляции левых DHCP-серверов :)

это скрининг режет тупо встроенными ацлями все юдп с срц=порт дхцп сервера

[biox]

pppoetest можете давать этому любое удобное вам название, но коммутатор всё равно будет перехватывать dhcp запросы, вставлять в них опцию и отправлять восвояси.

[DRiVen]

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

[biox]

одно другого никак не исключает, а прекрасно дополняет.

[tehmeh]

pppoetest можете давать этому любое удобное вам название, но коммутатор всё равно будет перехватывать dhcp запросы, вставлять в них опцию и отправлять восвояси.

Вам уже указали на ошибки, а вы спорите. Коммутатор не будет ничего перехватывать и ничего никуда вставлять, если на нем активирован dhcp snooping, по крайней мере в его классических реализация на Cisco.

Если дополнительно включить dhcp snooping information option, тогда будет передаваться опция.

 

У меня гора коммутаторов, на которых включен dhcp snooping, но никакая опция не добавляется, так авторизация происходит по паре s-tag/c-tag на NAS.

[Night_Snake]

Кстати, коллеги, а подскажите, пожалуйста.

На длинке будет ли работать relay (не local, обычный) при навешанных acl на аплинк-порты? Ну т.е. в настоящий момент по магистральным портам гоняется куча dhcp-дублей (от нижестоящих коммутаторов вышестоящим), что не есть правильно.

[pppoetest]

В последний версиях софта на блинки, появился функционал релея пер порт, отрубите релей на аплинках/даунлинках, и аклы - не нужны.