Комментарии 65
Друзья не могли бы вы хоть как-то комментировать статью, что бы было понятно что удовлетворяет, а что не удовлетворяет хабраюзеров!? спасибо за понимание!
Вы раздаете серые адреса. Чтобы сократить расходование реальных ip используется (проприетарная) ip unnumbered. В вашем случае возможно использование этой технологии?
Дак ведь статья не об экономии ip-адресов, а о гибком использовании протокола DHCP.
Очень тривиально, если честно. И совершенно не понятно в приведённой схеме, нахрена там вообще виланы до дистрибуции. Делаются три вилана, по одному на коммутатор, каждый коммутатор отвечает за свой сегмент. Тупо, просто, надёжно.
У меня в предыдущей конторы вообще всю межсетевую маршрутизацию на себя взял гигабитный L3-коммутатор, а на долю циски пришлось только делать DHCP, NAT, принимать VPN, менять аплинков по SLA и т.д.
И никакой «экономии ЦПУ», т.к. L3-коммутаторы маршрутизируют (в пределах, насколько умеют) со скоростью среды.
У меня в предыдущей конторы вообще всю межсетевую маршрутизацию на себя взял гигабитный L3-коммутатор, а на долю циски пришлось только делать DHCP, NAT, принимать VPN, менять аплинков по SLA и т.д.
И никакой «экономии ЦПУ», т.к. L3-коммутаторы маршрутизируют (в пределах, насколько умеют) со скоростью среды.
управляющий влан + влан на каждый сегмент, но все зависит от кол-ва сегментов и кол-ва поддерживаемых вланов свитчами :)
Дело в гибкости, один сегмент может проходить через все коммутаторы в сети, например если используется видео или аудио.
Зачем для видео или аудио один сегмент сети?
Чтобы не пропускать широковещательный трафик через маршрутизатор, например.
Широковещательный трафик (broadcast) и так не пройдёт через маршрутизатор, учите матчасть.
имеется ввиду ВКС и телефония.
Задачи могут стоять разные и один влан — один коммутатор зачастую не очень удобно или невозможно.
Меня больше волнует следующий вопрос. Свитч используется для маршрутизации, Cisco выполняет все остальные функции. У меня такая же схема, но как в этом случае использовать rate-limit
Например, мне нужно по двум влан ограничить скорость. На маршрутизаторе это делается без проблем, а на catalyst 3550 это сделать невозможно. Как вы решаете этот вопрос?
Прошу прощения за оффтоп.
Меня больше волнует следующий вопрос. Свитч используется для маршрутизации, Cisco выполняет все остальные функции. У меня такая же схема, но как в этом случае использовать rate-limit
Например, мне нужно по двум влан ограничить скорость. На маршрутизаторе это делается без проблем, а на catalyst 3550 это сделать невозможно. Как вы решаете этот вопрос?
Прошу прощения за оффтоп.
НЛО прилетело и опубликовало эту надпись здесь
«vlan 300 10.1.300.1»
Прямо бросилось в глаза :)
А в целом — спасибо за статью!
Прямо бросилось в глаза :)
А в целом — спасибо за статью!
Надо бы как-нибудь описать «Решение №1» на циске (это так, в to do).
Также желательно пояснить «физику процесса», каким образом свич определяет, из какого пула выдавать адрес.
Также желательно пояснить «физику процесса», каким образом свич определяет, из какого пула выдавать адрес.
Из статьи не очевидно, что ip routing надо говорить только на той коробке, которая занимается DHCP-машинерией. Начинающий кошковод не поймёт, почему на 2950 не работает interVLAN routing. В целом — более чем тривиальная схема, я-то думал будет кунг-фу:)
Да, а ещё автор запутался вот здесь:
Добавлю лишь то, что перед тем как конфигурировать на коммутаторах DHCP необходимого включить ip routing, что бы поднять его на уровень 3 и осуществлять межвлановую коммутацию
Что значит поднять DHCP на 3 уровень? Сие есть совершенно некорректная формулировка. DHCP занимается исключительно выдачей адресов, это не протокол маршрутизации. ip routing же говорится для того, чтобы запустить межвлановую маршрутизацию, а не коммутацию, это очевидно из синтаксиса команды. Коммутация возможна лишь в пределах одного конкретного VLAN. Всё что шире — есть маршрутизация.
Добавлю лишь то, что перед тем как конфигурировать на коммутаторах DHCP необходимого включить ip routing, что бы поднять его на уровень 3 и осуществлять межвлановую коммутацию
Что значит поднять DHCP на 3 уровень? Сие есть совершенно некорректная формулировка. DHCP занимается исключительно выдачей адресов, это не протокол маршрутизации. ip routing же говорится для того, чтобы запустить межвлановую маршрутизацию, а не коммутацию, это очевидно из синтаксиса команды. Коммутация возможна лишь в пределах одного конкретного VLAN. Всё что шире — есть маршрутизация.
Ну потому что коммутатор L2 и соответственно не поддерживает interVlan routing. А насчет схемы, так это здорово, всем все понятно, не буду же я разрисовывать план здания.
sahe благодарю за наблюдательность, очень грубая ошибка, впредь буду более ответственным)
sahe благодарю за наблюдательность, очень грубая ошибка, впредь буду более ответственным)
Это я просто к тому, что стоило вначале сделать ремарку, что мол 2950 — чисто L2 коробка, и поэтому на ней interVLAN никакого нет. Просто вначале статьи есть пояснение sw(config)#ip routing, из которого не очевидно, что эту команду надо говорить только на Core. Просто раз уж статья рассчитана на самый начальный уровень, такие базовые вещи можно было бы пояснять.
Я не для того это пишу, чтоб придраться, а чтоб начинающим понятней было:)
Я не для того это пишу, чтоб придраться, а чтоб начинающим понятней было:)
А если вам хочется раздавать адреса по 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/
— включаем каким-либо образом 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/
Я думал будет про dhcp-relay, option82 и прочие возвышенные вещи.
про релей тут
Ну а почему ж не использовать option 82 и не выставлять адреса хоть в виде 10.$vlan.$switch.$port/16 раз уж на то пошло? В 82 все эти параметры передаются, и их можно крутить как угодно. Так что с фразой «Решение №4 (самое гибкое)» поспорил бы. Далеко не самое.
С реализацией 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.
В RFC сказано, что заголовок состоит из двух полей — Suboption Type и Length. Пацаны из циски что-то покурили, и зачем-то добавили ещё два поля — ещё один Length (содержимым которого является Lengh+2) и Remote ID Type (в случае с Circuit ID — Circuit ID Type). В итоге когда такое сообщение ловит устройство, DHCP-часть которого написана по RFC, оно считает два дополнительных поля значимой частью строки, которой они не являются, и тут начинается полная каша, option-82 не работает. Циска признавать этот фэйл не хочет, но и пояснить значение дополнительных полей также не желает.
Edgecore, которые слизали с циски всё что только можно, вначале имели такой же косяк. Но затем опомнились, и переписали этот функционал по RFC.
Так что решение-то гибкое, но в случае с циской возможны нюансы в части interop.
Вызывающе неверная информация ;)
Пацаны из циско курят конечно знатную дурь порой, но тут к ним вопросов нет, всё в соответствии с 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 написан достаточно свободно.
Пацаны из циско курят конечно знатную дурь порой, но тут к ним вопросов нет, всё в соответствии с 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 написан достаточно свободно.
Про 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. Жуниперы друг друга поняли сразу. Иджкор начал пониматься после того, как китайцы спешно переписали софт. Циску же так и не удалось заставить работать. Видимо, и не удастся.
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. Жуниперы друг друга поняли сразу. Иджкор начал пониматься после того, как китайцы спешно переписали софт. Циску же так и не удалось заставить работать. Видимо, и не удастся.
> Формально — да, нигде не сказано, что начиная с первого байта value должна следовать строка, но, чёрт побери, это ведь должно быть очевидно:) Ведь The Agent Information field consists of a sequence of SubOpt/Length/Value. Как можно было в Value засунуть ещё одни заголовки?!
Ну а как можно было тупо решить что там должна быть только ascii, не подумавши что само по себе value может быть каким-то более комплексным? скажем, взять тот же circuit id type. Вот куда его засунуть согласно rfc если не в Value? Можно конечно сказать что эта опция народу не нужна, но это уже совсем неправильно как-то. Описанное вами больше похоже на fail джунипера и спешный прогиб эджиков под него.
Ну а как можно было тупо решить что там должна быть только ascii, не подумавши что само по себе value может быть каким-то более комплексным? скажем, взять тот же circuit id type. Вот куда его засунуть согласно rfc если не в Value? Можно конечно сказать что эта опция народу не нужна, но это уже совсем неправильно как-то. Описанное вами больше похоже на fail джунипера и спешный прогиб эджиков под него.
Отбросим лишнее — за что отвечают Circuit ID Type и Remote ID Type? Нигде не нашёл ни одного объяснения.
RFC должен быть таким, чтобы не вызывать разночтений.
RFC должен быть таким, чтобы не вызывать разночтений.
Вроде как:
Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.
Remote ID — идентификатор самого DHCP-ретранслятора (например, MAC-адрес коммутатора).
Circuit ID — содержит информацию о том, с какого порта пришел запрос на DHCP-ретранслятор.
Remote ID — идентификатор самого DHCP-ретранслятора (например, MAC-адрес коммутатора).
Мы не о том. Мы с коллегой nicolnx байтики считаем:)
Беглого взгляда на документацию достаточно чтобы понять что это. Циска решила значения субопций хранить в виде TLV-триплетов для расширяемости в дальшейшем. Думается мне, это хорошее, годное начинание. По крайней мере, это абсолюно ничему не противоречит, в том числе и здравому смыслу. В описаниях форматов опции 82 в цисковских доках поле Type = 0 везде где я видел. Остальные значения, вестимо, reserved for future use.
RFC не допускает никаких разночтений. Сказано вам — Value, последовательность байт — извольте не додумывать всякое и не строить беспочвенных теорий на тему того что там мол строго ascii-стринг обязан быть.
И вот ведь как выходит. Juniper написал софт основываясь на предположениях которых в рфц ни разу нигде нет и они якобы молодцы. Edge-Core прогнулись под них (что неудивительно, им похоже вообще пофигу у кого софт передирать) — тоже респект. Кошковцы написали софт который нигде не противоречит rfc — и они злостные нарушители стандартов, проприетарные сволочи и гореть им в аду. Как-то странно, не?
RFC не допускает никаких разночтений. Сказано вам — Value, последовательность байт — извольте не додумывать всякое и не строить беспочвенных теорий на тему того что там мол строго ascii-стринг обязан быть.
И вот ведь как выходит. Juniper написал софт основываясь на предположениях которых в рфц ни разу нигде нет и они якобы молодцы. Edge-Core прогнулись под них (что неудивительно, им похоже вообще пофигу у кого софт передирать) — тоже респект. Кошковцы написали софт который нигде не противоречит rfc — и они злостные нарушители стандартов, проприетарные сволочи и гореть им в аду. Как-то странно, не?
Циска решила значения субопций хранить в виде TLV-триплетов
Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV. Можно пойти дальше и сделать ещё одну иерархию и т.д.
извольте не додумывать всякое и не строить беспочвенных теорий
Как же мне не додумывать, если в документе явно не оговаривается что такое Value и какую информацию оно несёт? Если не оговорено, самое логичное что приходит в голову (мою, естественно) — это собственно value, т.е. символьное значение той строки, на основании которой происходит DHCP-машинерия в части option-82. Мои теории настолько же беспочвенны, как и цискины, которая решила. Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить. Циска не смогла продавить это расширение в RFC? Так ведь на то, видимо, были причины, не находите?
Тем не менее, к чему вы клоните я понял. Признаю, что наезды на циску настолько же беспочвенны, как и на джунипер и иже с ними. Наезжать надо на написателей RFC.
Циска решила — ключевая фраза. Когда я вижу поле Value, мне в жизни не придёт в голову создавать там ещё одну сущность TLV, уже будучи внутри другой TLV. Можно пойти дальше и сделать ещё одну иерархию и т.д.
извольте не додумывать всякое и не строить беспочвенных теорий
Как же мне не додумывать, если в документе явно не оговаривается что такое Value и какую информацию оно несёт? Если не оговорено, самое логичное что приходит в голову (мою, естественно) — это собственно value, т.е. символьное значение той строки, на основании которой происходит DHCP-машинерия в части option-82. Мои теории настолько же беспочвенны, как и цискины, которая решила. Ну молодцы, сделали запас с прицелом на будущее, но только забыли других предупредить. Циска не смогла продавить это расширение в RFC? Так ведь на то, видимо, были причины, не находите?
Тем не менее, к чему вы клоните я понял. Признаю, что наезды на циску настолько же беспочвенны, как и на джунипер и иже с ними. Наезжать надо на написателей RFC.
> Циска решила — ключевая фраза. Когда я вижу поле 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.
Не надо. Вендорный разнобой в атрибутах — это суровая правда жизни, и ничего с этим не сделать. Авторы тут ни в чем не виноваты, их задача — написать внятный документ по которому можно что-то реализовать. На мой взгяд тут у них все в порядке.
Другое дело что если предстоит общаться с разными железяками, то безусловно стоит держать в голове тот факт что у них могут быть кардинально разные представления об этих атрбутах, и это нормально (по крайней мере на сегодняшний день).
> в голову создавать там ещё одну сущность 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.
Не надо. Вендорный разнобой в атрибутах — это суровая правда жизни, и ничего с этим не сделать. Авторы тут ни в чем не виноваты, их задача — написать внятный документ по которому можно что-то реализовать. На мой взгяд тут у них все в порядке.
Другое дело что если предстоит общаться с разными железяками, то безусловно стоит держать в голове тот факт что у них могут быть кардинально разные представления об этих атрбутах, и это нормально (по крайней мере на сегодняшний день).
Отсюда становится понятным зачем там TLV. Ибо данные могут быть ну очень разные, не эзернетом же единым…
Бесспорно. Но неужели нельзя использовать существующий байт Suboption type чуть более оптимально, чем сейчас? К примеру, разбить его на равное количество кусков, соответствующих Circuit ID, Remote ID, какому-либо ещё несуществующему зарезервированному ID и т.д. И внутри каждого из этих кусков напилить соответствия типам (Router interface number, Switching Hub port number и т.д.). Думаю, байта вполне себе хватит для этих нужд.
В общем, это переливание из пустого в порожнее. Надо работать с тем, что есть, и не забывать держать в голове все эти расклады во избежание некорректного интеропа.
Бесспорно. Но неужели нельзя использовать существующий байт Suboption type чуть более оптимально, чем сейчас? К примеру, разбить его на равное количество кусков, соответствующих Circuit ID, Remote ID, какому-либо ещё несуществующему зарезервированному ID и т.д. И внутри каждого из этих кусков напилить соответствия типам (Router interface number, Switching Hub port number и т.д.). Думаю, байта вполне себе хватит для этих нужд.
В общем, это переливание из пустого в порожнее. Надо работать с тем, что есть, и не забывать держать в голове все эти расклады во избежание некорректного интеропа.
> Бесспорно.
> Но неужели нельзя использовать существующий байт Suboption type
> чуть более оптимально, чем сейчас?
В байте 8 бит. Стало быть бить на равное количество кусков — это или на 2 или на 4. Если на 2- не хватит кусков, если на 4 — куски получатся слишком маленькие. А завтра к ipv6 появится какое-то интересное расширение — и приплыли. Зачем творить странное если TLV — это и есть общепринятое средство избегания подобных велосипедов с разбиванием байтов?
> В общем, это переливание из пустого в порожнее.
> Надо работать с тем, что есть, и не забывать держать в голове все эти
> расклады во избежание некорректного интеропа.
+1
> Но неужели нельзя использовать существующий байт Suboption type
> чуть более оптимально, чем сейчас?
В байте 8 бит. Стало быть бить на равное количество кусков — это или на 2 или на 4. Если на 2- не хватит кусков, если на 4 — куски получатся слишком маленькие. А завтра к ipv6 появится какое-то интересное расширение — и приплыли. Зачем творить странное если TLV — это и есть общепринятое средство избегания подобных велосипедов с разбиванием байтов?
> В общем, это переливание из пустого в порожнее.
> Надо работать с тем, что есть, и не забывать держать в голове все эти
> расклады во избежание некорректного интеропа.
+1
Очень неэкономичный расход IP адресов
ИМХО, решение с 82й опцией как-то красивее.
То что вы затолкали компьютеры по VLANам не избавляет вам от необходимости искать каждый компьютер по маку, чтобы определить какой же у него IP.
Статья как-то внезапно быстро кончилась…
Статья как-то внезапно быстро кончилась…
зачем вообще это?
Так вы же сами задавались вопросом в статье:
… С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. А если необходимо сохранить какой-то порядок назначения адресов, что делать в таком случае!?..
То что вы сделали несколько VLAN не решает эту проблему…
… С другой стороны, в общем случае адреса назначаются случайным образом, и заранее неизвестно какой хост получит какой адрес. А если необходимо сохранить какой-то порядок назначения адресов, что делать в таком случае!?..
То что вы сделали несколько VLAN не решает эту проблему…
Нам, например, требовалось как-то отделить компьютеры, имеющие доступ в интернет через NAT от тех, что могут работать только через прокси. Удваивать для этого набор виланов красивым решением не кажется.
Для новичков статья, пожалуй, окажется полезной. Но
1) для новичков очень формально расписано значение vlan и при этом совсем мало посвящено описанию L2-L3-коммутаторов
2) много частностей. Например в качестве DHCP-сервера может выступать и полноценный маршрутизатор и для новичков расписывание настройки L3-свитчей может только ввести в заблуждение
3) 4 решения не 4 альтернативы и преследуют всё-таки несколько разные цели. И 4-е решение вполне можно дополнить первым, например.
4) В общем-то непонятно, что было реализовано 4-е решение, поскольку в примерах настроен пул только для одной подсети, следовательно для одного влана.
Плюс за старания и в перспективу, но получилось весьма сумбурно и малоинформативно. Тем более, что примеров настройки dhcp в сети вагон.
1) для новичков очень формально расписано значение vlan и при этом совсем мало посвящено описанию L2-L3-коммутаторов
2) много частностей. Например в качестве DHCP-сервера может выступать и полноценный маршрутизатор и для новичков расписывание настройки L3-свитчей может только ввести в заблуждение
3) 4 решения не 4 альтернативы и преследуют всё-таки несколько разные цели. И 4-е решение вполне можно дополнить первым, например.
4) В общем-то непонятно, что было реализовано 4-е решение, поскольку в примерах настроен пул только для одной подсети, следовательно для одного влана.
Плюс за старания и в перспективу, но получилось весьма сумбурно и малоинформативно. Тем более, что примеров настройки dhcp в сети вагон.
1) Чет я уже подумал, что влан вообще не стоило описывать в этой статье.
2) Пусть будет маршрутизатор, настройки от этого не изменятся, а заодно и показано, что возможна реализация на L3 коммутаторе.
3) А это зачем? что бы жизнь медом не казалась!?)
4) Учел, исправил, спасибо.
2) Пусть будет маршрутизатор, настройки от этого не изменятся, а заодно и показано, что возможна реализация на L3 коммутаторе.
3) А это зачем? что бы жизнь медом не казалась!?)
4) Учел, исправил, спасибо.
1) вполне возможно. Но тогда заголовок был бы не таким интересным) Кто DHCP на cisco не настраивал?:)
2) Пусть будет так. Не буду спорить.
3) Статья была бы более интересной, чуть более полной. Совсем хорошая получилась бы, если бы были рассмотрены все варианты и отдельным бонусом option 82. Тогда бы и середняки и может, даже, гуру нашли что-то интересное.
2) Пусть будет так. Не буду спорить.
3) Статья была бы более интересной, чуть более полной. Совсем хорошая получилась бы, если бы были рассмотрены все варианты и отдельным бонусом option 82. Тогда бы и середняки и может, даже, гуру нашли что-то интересное.
НЛО прилетело и опубликовало эту надпись здесь
Новичок.
Ничего не понял.
Ничего не понял.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DHCP по VLAN на коммутаторах Cisco