DHCP по VLAN на коммутаторах Cisco

В данной статье хочу рассказать об очень удобной, по моему мнению, схеме IP-адресации в сети с и использованием VLAN.
В примере конфигурации будем использовать следующую схему:
image

Немного теории для самых маленьких


VLAN или Virtual Local Area Network — виртуальная локальная компьютерная сеть, представляет собой группу хостов с общим набором требований, которые взаимодействуют так, как если бы они были подключены к широковещательному домену, независимо от их физического местонахождения.
Другими словами VLAN — это технология сегментации локальной сети на более мелкие виртуальные локальные сети со своим широковещательным доменом.

Преимущества сетей с VLAN:
  • Облегчается перемещение, добавление устройств и изменение их соединений друг с другом;
  • Так как маршрутизация между VLAN осуществляется на третьем уровне, следовательно увеличивается степень административного контроля в сети;
  • В связи с разбиением широковещательного домена уменьшается широковещательный трафик в сети, что экономит пропускную способность каналов;
  • Сокращается непроизводственное использование CPU за счет сокращения пересылки широковещательных сообщений;
  • Предотвращение широковещательных штормов и предотвращение петель.

Вступление


О том что такое DHCP я думаю рассказывать не нужно, но для тех кто «не уверен» есть хорошая статья, можно почитать здесь. Также там описаны базовые настройки DHCP на маршрутизаторах Cisco. Они ничем не отличаются и для коммутаторов. Добавлю лишь то, что перед тем как конфигурировать DHCP необходимого включить ip routing на свитче, что бы поднять его на уровень 3 и осуществлять межвлановую маршрутизацию, для чего в свою очередь необходимо в режиме глобальной конфигурации ввести соответствующую команду:

core(config)#ip routing


Всем известно, что использовать протокол DHCP очень удобно — так как у администратора сети отпадает необходимость в настройке стека протоколов TCP/IP для каждой клиентской машины. С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. А если необходимо сохранить какой-то порядок назначения адресов, что делать в таком случае!?

1-ое решение: Сохранив удобство использования DHCP привязать каждый компьютер к определенному IP-адресу, так называемая привязка к MAC-адресу: на DHCP-сервере хранится таблица адресов, где IP привязаны MAC'ам, в соответствии с которой происходит выдача. Таблица заполняется по мере добавления компьютеров в сеть.
Минусы этого решения в том, что администратору необходимо отслеживания MAC-адреса и сопровождать таблицы соответствия на сервере.

Решение №2: Поставить IP-адреса в соответствие не MAC-адресам, а портам коммутатора уровня доступа, к которым подключены клиентские компьютеры.

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

Решение №4 (И самое гибкое): Раздавать IP-адреса по VLAN. Так мы получаем некое универсальное решение включающее преимущества всех предыдущих. Гибкость такого решения практически безгранична.

И так, приступим.

Практическая сторона вопроса


Для наглядности рассмотрим следующий пример, представленный на рисунке (см. выше).
У нас имеется: три коммутатора уровня доступа (sw1, sw2, sw3), девять клиентских компьютеров (user 1-9), коммутатор 3-го уровня (Multilayer Switch, обозначим его как Core) и три сети VLAN.
На коммутаторах уровня доступа не требуется никакой дополнительной конфигурации для осуществления задачи (ну только настроить интерфейсы в соответствующий vlan), вся необходимая настройка производится на коммутаторе Core. Пример конфигурации коммутатора Core:
!для начала создадим наши vlan'ы
core#vlan database
core(vlan)#vlan 10
core(vlan)#vlan 20
core(vlan)#vlan 30

!сохраняем базу и выходим
core(vlan)#exit
!назначаем vlan интерфейсам ip-адреса
core(config)#int vlan 10
core(config-if)#ip address 10.1.10.1 255.255.255.0

!и так для всех интерфейсов. vlan 20 - 10.1.20.1, vlan 30 10.1.30.1
!...
!включаем ip routing создаем пулы адресов dhcp
core(config)#ip routing
core(config)#ip dhcp pool vl10
core(dhcp-config)#network 10.1.10.0 255.255.255.0
core(dhcp-config)#default-router 10.1.10.1

!...
!и другие необязательные параметры, такие как dns
! + аналогично повторяем для каждого vlan'а
core(config)#ip dhcp excluded-address 10.1.10.1 10.1.20.1 10.1.30.1


Вот и все, готово! Компьютеры при подключении к сети получат IP-адреса по протоколу DHCP в соответствии с пулами для VLAN'ов в которых они находятся.
В реальных сетях возможно целесообразно разделение VLAN'ами по этажам или по отделам и т.д. как вам будет удобно. Таким образом, раздача IP-адресов теперь полностью в ваших руках.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 65

    0
    Друзья не могли бы вы хоть как-то комментировать статью, что бы было понятно что удовлетворяет, а что не удовлетворяет хабраюзеров!? спасибо за понимание!
      0
      Так никто прочитать не успел, подождите до завтра.
        0
        нет, ну ведь кто-то прочитал, проголосовал, добавил в избранное, как бы о их мнение я и спрашиваю.
        0
        Слишком элементарно.
          0
          кому элементарно, а кому полезно.
            0
            Тогда уж можно было расширить: привязка по мак-адресу, опции.
              0
              Решил разделить статью и в следующей как раз рассказать об этом поподробнее.
                0
                поддерживаю. тем более перед тем как было написано приступим резервирование упоминалось.
          • UFO just landed and posted this here
            0
            Вы раздаете серые адреса. Чтобы сократить расходование реальных ip используется (проприетарная) ip unnumbered. В вашем случае возможно использование этой технологии?
              0
              Дак ведь статья не об экономии ip-адресов, а о гибком использовании протокола DHCP.
                0
                Очень тривиально, если честно. И совершенно не понятно в приведённой схеме, нахрена там вообще виланы до дистрибуции. Делаются три вилана, по одному на коммутатор, каждый коммутатор отвечает за свой сегмент. Тупо, просто, надёжно.

                У меня в предыдущей конторы вообще всю межсетевую маршрутизацию на себя взял гигабитный L3-коммутатор, а на долю циски пришлось только делать DHCP, NAT, принимать VPN, менять аплинков по SLA и т.д.

                И никакой «экономии ЦПУ», т.к. L3-коммутаторы маршрутизируют (в пределах, насколько умеют) со скоростью среды.
                  0
                  управляющий влан + влан на каждый сегмент, но все зависит от кол-ва сегментов и кол-ва поддерживаемых вланов свитчами :)
                    0
                    Дело в гибкости, один сегмент может проходить через все коммутаторы в сети, например если используется видео или аудио.
                      0
                      Зачем для видео или аудио один сегмент сети?
                        0
                        Чтобы не пропускать широковещательный трафик через маршрутизатор, например.
                          0
                          Широковещательный трафик (broadcast) и так не пройдёт через маршрутизатор, учите матчасть.
                            0
                            Мой косяк. Хотел сказать мультикаст-трафик.
                              +1
                              Как только мы начинаем говорить про маршрутизацию мультикаста, то тут сразу же начинаются такие нюансы, что закладывать их в «обычную» схему работы сети можно только с глубоким пониманием ответа на вопрос «нафига?».
                                0
                                Так вот, чтобы не говорить о маршрутизации, иногда лучше пробросить влан. Но в целом мы поняли друг друга.
                          0
                          имеется ввиду ВКС и телефония.
                            0
                            И? Нафига ВКС и телефонии один L2 сегмент?
                              0
                              Трафик телифонии один vlan, видеоконференция другой, остальные данные третий, так принято)
                        0
                        Задачи могут стоять разные и один влан — один коммутатор зачастую не очень удобно или невозможно.
                        Меня больше волнует следующий вопрос. Свитч используется для маршрутизации, Cisco выполняет все остальные функции. У меня такая же схема, но как в этом случае использовать rate-limit
                        Например, мне нужно по двум влан ограничить скорость. На маршрутизаторе это делается без проблем, а на catalyst 3550 это сделать невозможно. Как вы решаете этот вопрос?
                        Прошу прощения за оффтоп.
                        • UFO just landed and posted this here
                            0
                            3550 позволяет ограничивать входящий на интерфейс трафик. То есть это для пользователя это исходящий. С задачей ограничить входящую скорость я не справился.
                            Это написано в документации к 3550. Если это всё же возможно, буду сильно благодарен за пример настройки.
                            • UFO just landed and posted this here
                        +4
                        «vlan 300 10.1.300.1»
                        Прямо бросилось в глаза :)

                        А в целом — спасибо за статью!
                          0
                          да-да, что-то я разошелся), спасибо, щас исправлю!
                          0
                          Надо бы как-нибудь описать «Решение №1» на циске (это так, в to do).
                          Также желательно пояснить «физику процесса», каким образом свич определяет, из какого пула выдавать адрес.
                            +1
                            Из статьи не очевидно, что ip routing надо говорить только на той коробке, которая занимается DHCP-машинерией. Начинающий кошковод не поймёт, почему на 2950 не работает interVLAN routing. В целом — более чем тривиальная схема, я-то думал будет кунг-фу:)
                              0
                              Да, а ещё автор запутался вот здесь:
                              Добавлю лишь то, что перед тем как конфигурировать на коммутаторах DHCP необходимого включить ip routing, что бы поднять его на уровень 3 и осуществлять межвлановую коммутацию
                              Что значит поднять DHCP на 3 уровень? Сие есть совершенно некорректная формулировка. DHCP занимается исключительно выдачей адресов, это не протокол маршрутизации. ip routing же говорится для того, чтобы запустить межвлановую маршрутизацию, а не коммутацию, это очевидно из синтаксиса команды. Коммутация возможна лишь в пределах одного конкретного VLAN. Всё что шире — есть маршрутизация.
                                0
                                Ну потому что коммутатор L2 и соответственно не поддерживает interVlan routing. А насчет схемы, так это здорово, всем все понятно, не буду же я разрисовывать план здания.
                                sahe благодарю за наблюдательность, очень грубая ошибка, впредь буду более ответственным)
                                  0
                                  Это я просто к тому, что стоило вначале сделать ремарку, что мол 2950 — чисто L2 коробка, и поэтому на ней interVLAN никакого нет. Просто вначале статьи есть пояснение sw(config)#ip routing, из которого не очевидно, что эту команду надо говорить только на Core. Просто раз уж статья рассчитана на самый начальный уровень, такие базовые вещи можно было бы пояснять.
                                  Я не для того это пишу, чтоб придраться, а чтоб начинающим понятней было:)
                                    0
                                    Абсолютно согласен, статья для новичков, все исправил.
                                    От вас бы (от гуру) побольше статей из серии CCNP и выше, но только планомерно), а то литература то вся забугорная, а кто с английским не особо в ладах очень тяжко!
                                +3
                                А если вам хочется раздавать адреса по DHCP не с СISCO, а, скажем, с Windows 2008 Server или с Linux ISC DHCP, да еще находящемся не в том VLAN, то
                                — включаем каким-либо образом routing между этими VLAN-ами (чтобы адрес интерфейса DHCP cервера роутился к IP адресам, раздаваемым им во VLAN и обратно).
                                — используем команду ip helper-address в описании интерфейса destination vlan
                                — ip helper-address пробрасывает еще и кучу других полезных протоколов — если они вам не нужны — то уберите их по методу, описанному здесь: mschedrin.wordpress.com/2008/06/10/ip-addressing-and-services-commands/
                                  +5
                                  Я думал будет про dhcp-relay, option82 и прочие возвышенные вещи.
                                    +1
                                    про релей тут
                                    0
                                    Ну а почему ж не использовать option 82 и не выставлять адреса хоть в виде 10.$vlan.$switch.$port/16 раз уж на то пошло? В 82 все эти параметры передаются, и их можно крутить как угодно. Так что с фразой «Решение №4 (самое гибкое)» поспорил бы. Далеко не самое.
                                      0
                                      С реализацией option-82 у циски всё не так гладко на самом деле. Реализация проприетарная, и несколько не по RFC сделанная. в связи с чем не вполне интеропается с другими вендорами.
                                      В RFC сказано, что заголовок состоит из двух полей — Suboption Type и Length. Пацаны из циски что-то покурили, и зачем-то добавили ещё два поля — ещё один Length (содержимым которого является Lengh+2) и Remote ID Type (в случае с Circuit ID — Circuit ID Type). В итоге когда такое сообщение ловит устройство, DHCP-часть которого написана по RFC, оно считает два дополнительных поля значимой частью строки, которой они не являются, и тут начинается полная каша, option-82 не работает. Циска признавать этот фэйл не хочет, но и пояснить значение дополнительных полей также не желает.
                                      Edgecore, которые слизали с циски всё что только можно, вначале имели такой же косяк. Но затем опомнились, и переписали этот функционал по RFC.
                                      Так что решение-то гибкое, но в случае с циской возможны нюансы в части interop.
                                        0
                                        Вызывающе неверная информация ;)
                                        Пацаны из циско курят конечно знатную дурь порой, но тут к ним вопросов нет, всё в соответствии с RFC 3046. Suboption type, Length+2 — это первые байты заголовка. Здесь Length — длина ASCII Circuit ID String + 2 байта дополнительных Circuit ID Type, Length. По сути Circuit ID представлен в виде TLV-триплета, значение которого — ascii circuit id string. В RFC нигде не сказано что Circuit ID обязан быть ASCII строкой. Это видать Edge-Core себе что-то понапридумывали уже.
                                        Уж не знаю какие девайсы этого пугаются, но у нас все работает без дополнительных телодвижених, хотя сеть и мультивендорная.
                                        И, кстати, циска не только признает, а еще и разжевывает в картинках всё вышесказанное в документации. Что конечно-же не отменяет возможных ньюансов в части interop поскольку RFC написан достаточно свободно.
                                          0
                                          Про ASCII согласен, это может быть и hex, но здесь другой момент.
                                          TLV, ок. У циски же скорей сделано в виде TLTLV, о чём свидетельствует картинка-пояснение с офсайта:

                                          Но там нигде не поясняется что есть Circuit ID Type и Remote ID Type.
                                          Давайте посмотрим что происходит, когда такое сообщение приходит на тот же жунипер. Он видит поле Type и понимает, что приехал, к примеру, Remote ID. Отлично, дальше смотрим на длину. Он видит длину, которая составляет, как вы правильно подметили, ASCII String + 2 байта. Взглянув на цисковскую картинку, это объяснимо. Далее коробка уверена, что после поля Length следует полезная информация — ASCII String. Вместо этого там два байта с какой-то ерундой, которые ломают String к чертям. Приводит это к тому, что коробка не в состоянии корректно распознать строку, т.к. реально она начинается на два байта позже.
                                          В RFC нарисовано следующее:

                                          SubOpt Len Sub-option Value
                                          +------+------+------+------+------+------+--...-+------+
                                          | 1 | N | s1 | s2 | s3 | s4 | | sN |
                                          +------+------+------+------+------+------+--...-+------+
                                          SubOpt Len Sub-option Value
                                          +------+------+------+------+------+------+--...-+------+
                                          | 2 | N | i1 | i2 | i3 | i4 | | iN |
                                          +------+------+------+------+------+------+--...-+------+

                                          Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?! Видимо, при написании RFC подразумевалось, что вендоры не будут изобретать велосипед, но это явно не про циску:)
                                          Вам повезло, что всё работает как надо. Я имел большое несчастье тестить интероп в части option-82 с использованием Juniper MX как DHCP-коробки, и свитчей juniper EX, Cisco ME3400 и какого-то Edgecore. Жуниперы друг друга поняли сразу. Иджкор начал пониматься после того, как китайцы спешно переписали софт. Циску же так и не удалось заставить работать. Видимо, и не удастся.
                                            0
                                            > Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?!

                                            Ну а как можно было тупо решить что там должна быть только ascii, не подумавши что само по себе value может быть каким-то более комплексным? скажем, взять тот же circuit id type. Вот куда его засунуть согласно rfc если не в Value? Можно конечно сказать что эта опция народу не нужна, но это уже совсем неправильно как-то. Описанное вами больше похоже на fail джунипера и спешный прогиб эджиков под него.
                                              0
                                              Отбросим лишнее — за что отвечают Circuit ID Type и Remote ID Type? Нигде не нашёл ни одного объяснения.
                                              RFC должен быть таким, чтобы не вызывать разночтений.
                                                0
                                                Вроде как:
                                                Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.
                                                Remote ID — идентификатор самого DHCP-ретранслятора (например, MAC-адрес коммутатора).
                                                  0
                                                  Мы не о том. Мы с коллегой nicolnx байтики считаем:)
                                                  0
                                                  Беглого взгляда на документацию достаточно чтобы понять что это. Циска решила значения субопций хранить в виде TLV-триплетов для расширяемости в дальшейшем. Думается мне, это хорошее, годное начинание. По крайней мере, это абсолюно ничему не противоречит, в том числе и здравому смыслу. В описаниях форматов опции 82 в цисковских доках поле Type = 0 везде где я видел. Остальные значения, вестимо, reserved for future use.
                                                  RFC не допускает никаких разночтений. Сказано вам — Value, последовательность байт — извольте не додумывать всякое и не строить беспочвенных теорий на тему того что там мол строго ascii-стринг обязан быть.
                                                  И вот ведь как выходит. Juniper написал софт основываясь на предположениях которых в рфц ни разу нигде нет и они якобы молодцы. Edge-Core прогнулись под них (что неудивительно, им похоже вообще пофигу у кого софт передирать) — тоже респект. Кошковцы написали софт который нигде не противоречит rfc — и они злостные нарушители стандартов, проприетарные сволочи и гореть им в аду. Как-то странно, не?
                                                    0
                                                    Циска решила значения субопций хранить в виде TLV-триплетов
                                                    Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV. Можно пойти дальше и сделать ещё одну иерархию и т.д.

                                                    извольте не додумывать всякое и не строить беспочвенных теорий
                                                    Как же мне не додумывать, если в документе явно не оговаривается что такое Value и какую информацию оно несёт? Если не оговорено, самое логичное что приходит в голову (мою, естественно) — это собственно value, т.е. символьное значение той строки, на основании которой происходит DHCP-машинерия в части option-82. Мои теории настолько же беспочвенны, как и цискины, которая решила. Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить. Циска не смогла продавить это расширение в RFC? Так ведь на то, видимо, были причины, не находите?

                                                    Тем не менее, к чему вы клоните я понял. Признаю, что наезды на циску настолько же беспочвенны, как и на джунипер и иже с ними. Наезжать надо на написателей RFC.
                                                      0
                                                      > Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт
                                                      > в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV.

                                                      Увы, на голову отдельный RFC еще не вышел

                                                      > Можно пойти дальше и сделать ещё одну иерархию и т.д.

                                                      Можно конечно. Именно для этого создатели RFC и определили это поле как набор байт без детального описания формата, оставив это на откуп вендорам.

                                                      > Как же мне не додумывать, если в документе явно не оговаривается что такое Value
                                                      > и какую информацию оно несёт?

                                                      Читаем RFC 3046. Можно даже по диагонали.

                                                      3.1 Agent Circuit ID Sub-option

                                                      Possible uses of this field include:

                                                      — Router interface number
                                                      — Switching Hub port number
                                                      — Remote Access Server port number
                                                      — Frame Relay DLCI
                                                      — ATM virtual circuit number
                                                      — Cable Data virtual circuit number

                                                      3.2 Agent Remote ID Sub-option

                                                      he Remote ID field may be used to encode, for instance:

                                                      — a «caller ID» telephone number for dial-up connection
                                                      — a «user name» prompted for by a Remote Access Server
                                                      — a remote caller ATM address
                                                      — a «modem ID» of a cable data modem
                                                      — the remote IP address of a point-to-point link
                                                      — a remote X.25 address for X.25 connections

                                                      Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…

                                                      > Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить

                                                      А кого она должна была предупреждать? В документации это все прекрасно расписано, какие вопросы?

                                                      > Циска не смогла продавить это расширение в RFC?
                                                      > Так ведь на то, видимо, были причины, не находите?

                                                      Если циско каждое свое решение начнет продавливать в rfc, в отрасли начнется что-то не то, не находите?

                                                      > Наезжать надо на написателей RFC.

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

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

                                                        0
                                                        Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…
                                                        Бесспорно. Но неужели нельзя использовать существующий байт Suboption type чуть более оптимально, чем сейчас? К примеру, разбить его на равное количество кусков, соответствующих Circuit ID, Remote ID, какому-либо ещё несуществующему зарезервированному ID и т.д. И внутри каждого из этих кусков напилить соответствия типам (Router interface number, Switching Hub port number и т.д.). Думаю, байта вполне себе хватит для этих нужд.

                                                        В общем, это переливание из пустого в порожнее. Надо работать с тем, что есть, и не забывать держать в голове все эти расклады во избежание некорректного интеропа.
                                                          0
                                                          > Бесспорно.
                                                          > Но неужели нельзя использовать существующий байт Suboption type
                                                          > чуть более оптимально, чем сейчас?

                                                          В байте 8 бит. Стало быть бить на равное количество кусков — это или на 2 или на 4. Если на 2- не хватит кусков, если на 4 — куски получатся слишком маленькие. А завтра к ipv6 появится какое-то интересное расширение — и приплыли. Зачем творить странное если TLV — это и есть общепринятое средство избегания подобных велосипедов с разбиванием байтов?

                                                          > В общем, это переливание из пустого в порожнее.
                                                          > Надо работать с тем, что есть, и не забывать держать в голове все эти
                                                          > расклады во избежание некорректного интеропа.

                                                          +1
                                          0
                                          Очень неэкономичный расход IP адресов
                                          0
                                          ИМХО, решение с 82й опцией как-то красивее.
                                            0
                                            То что вы затолкали компьютеры по VLANам не избавляет вам от необходимости искать каждый компьютер по маку, чтобы определить какой же у него IP.
                                            Статья как-то внезапно быстро кончилась…
                                              0
                                              зачем вообще это?
                                                0
                                                Так вы же сами задавались вопросом в статье:

                                                … С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. А если необходимо сохранить какой-то порядок назначения адресов, что делать в таком случае!?..

                                                То что вы сделали несколько VLAN не решает эту проблему…
                                                  0
                                                  Ну прям что бы мы жестко знали какой компьютер какой адрес получит это нет. Но у каждого влана своя сеть, соответственно мы можем знать, что допустим отдел закупок в 21 сети, отдел продаж в 22, и так далее…
                                                  0
                                                  Нам, например, требовалось как-то отделить компьютеры, имеющие доступ в интернет через NAT от тех, что могут работать только через прокси. Удваивать для этого набор виланов красивым решением не кажется.
                                                0
                                                Для новичков статья, пожалуй, окажется полезной. Но
                                                1) для новичков очень формально расписано значение vlan и при этом совсем мало посвящено описанию L2-L3-коммутаторов
                                                2) много частностей. Например в качестве DHCP-сервера может выступать и полноценный маршрутизатор и для новичков расписывание настройки L3-свитчей может только ввести в заблуждение
                                                3) 4 решения не 4 альтернативы и преследуют всё-таки несколько разные цели. И 4-е решение вполне можно дополнить первым, например.
                                                4) В общем-то непонятно, что было реализовано 4-е решение, поскольку в примерах настроен пул только для одной подсети, следовательно для одного влана.
                                                Плюс за старания и в перспективу, но получилось весьма сумбурно и малоинформативно. Тем более, что примеров настройки dhcp в сети вагон.
                                                  0
                                                  1) Чет я уже подумал, что влан вообще не стоило описывать в этой статье.
                                                  2) Пусть будет маршрутизатор, настройки от этого не изменятся, а заодно и показано, что возможна реализация на L3 коммутаторе.
                                                  3) А это зачем? что бы жизнь медом не казалась!?)
                                                  4) Учел, исправил, спасибо.
                                                    0
                                                    1) вполне возможно. Но тогда заголовок был бы не таким интересным) Кто DHCP на cisco не настраивал?:)
                                                    2) Пусть будет так. Не буду спорить.
                                                    3) Статья была бы более интересной, чуть более полной. Совсем хорошая получилась бы, если бы были рассмотрены все варианты и отдельным бонусом option 82. Тогда бы и середняки и может, даже, гуру нашли что-то интересное.
                                                  0
                                                  То что здесь названо core на самом деле distribution.

                                                  Надеюсь, что статья кому-то поможет, но мне кажется, что она ценности не представляет.
                                                    0
                                                    Я исправлюсь, судя по логам :) это первый пост хабраюзера.
                                                    Спасибо.
                                                    0
                                                    Новичок.
                                                    Ничего не понял.
                                                      0
                                                      Купи Циску

                                                    Only users with full accounts can post comments. Log in, please.