Практическая настройка DHCP в операционной системе Cisco IOS

Продолжаем разговор про протокол DHCP и посмотрим на практическую его настройку в операционной системе Cisco IOS. Настройка, если мы говорим про DHCP для IPv4, достаточно простая. Нам нужно сделать пул адресов и указать опции, которые мы хотим выдавать при раздаче адресов из этого пула. И это всё. Не надо ничего делать специального на самом интерфейсе, на котором у вас будет работать DHCP. Это немножко странно звучит, но на самом деле в этом есть своя странная, извращённая, но всё-таки определённая логика. Итак, что мы делаем? Мы будем указывать, что у нас есть на интерфейсе IP-шник. В нашем случае этот адрес 10.0.0.1 с маской /24. Вот он. И отдельно от этого IP-шника делаем пул адресов, в котором указываем команду network. Делаем пул с названием, например, POOL_NAME.

Это, кстати, первая именованная сущность в Cisco, которую мы создаём в рамках нашего курса, поэтому про именованные вещи я расскажу немножко отдельно. Если вы делаете что-то, что можно поименовать, в нашем случае POOL_NAME — это имя пула, то я рекомендую вам все имена делать заглавными буквами. В нашем случае POOL_NAME делать именно большими буквами — это очень здорово облегчает чтение конфигурации. Если вы все сущности будете именовать маленькими буквами, будет очень сложно отличить в конфигурации, когда вы show run делаете, что является служебным словом, командой или параметром, и что является вашей собственной именованной сущностью. Если это всё будет монолитными маленькими буквами, то отделить визуально просто глазами одно от другого будет очень тяжело. В то же время большие буквы вам дают сразу понимание, что POOL_NAME — это именно отсылка к именованной сущности.

Давайте все имена, которые вы используете, будут разумные и понятные. Будет понятно сразу по внешнему виду этого пула, что он делает. Даже только имя его можете прочитать и уже сразу понять, зачем эта сущность нужна. POOL_NAME — не очень говорящее имя, но вы можете назвать, например, DHCP_POOL. И вот это уже будет понятно, что это такое, правда? Имейте в виду, что в Cisco все имена регистрозависимые, и везде, где вы делаете отсылку к ним, имена должны совпадать с точностью до символа. DHCP_POOL и DHCP-POOL — это будут два разных имени, поэтому везде используйте одинаковые символы. Мы сделали пул, который называется POOL_NAME. Если вдруг мы захотим в какой-то момент на него сослаться, то мы должны будем именно на его имя дать ссылку.

И самая важная команда, которая здесь есть, это команда network. И дальше мы указываем IP-шник сети и маску сети. Либо /24 в нашем случае, это мы указываем, что маска 24, либо можно указать 255.255.255.0. Но важно, что здесь есть пробел. Это немножко неочевидно, потому что маску вы можете задать как в виде префиксной записи, так и в виде десятичной записи. И если десятичную запись вы используете, то вы используете её через пробел. И перед префиксом тоже здесь пробел будет ставиться. Что таким образом мы сделали? Мы сделали пул адресов, в котором сказали: все адреса в сети 10.0.0.0/24 входят в этот пул. Как мы определяем, что на интерфейсе надо включить этот пул и раздачу адресов из этого пула? А очень просто. По тому факту, что IP-шник, который на этом интерфейсе висит, в этот пул тоже входит. Мы не делали специальную команду вида «включить раздачу адресов из POOL_NAME на интерфейсе GigabitEthernet 0/0».

Тот факт, что на нём висит IP-шник, который тоже попадает в пул, автоматически включает раздачу адресов из этого пула на интерфейсе. Дополнительно вы можете в конфигурации пула выдать опции. Чаще всего вы хотите это сделать. Например, такие джентльменские опции — это раздать шлюз по умолчанию, раздать DNS-серверы. Возможно, выдать доменный суффикс. И если вы хотите выдать какую-то кастомную опцию, которую Cisco знает, вы можете дополнительно что-то ещё выдать. А если вы хотите выдать опцию, которую Cisco не знает, это всё равно сделать можно. Используется синтаксис option — дальше вы указываете номер опции. Например, если вы хотите адрес TFTP-сервера выдать, IP-шник TFTP-сервера, это 150-я опция. Вы указываете, что раздаёте опцию 150, у неё значение имеет тип IP-адрес. Просто обычный IP-адрес. И вы IP-шник 10.0.0.2 выдаёте в качестве TFTP-сервера.

И тогда, например, IP-телефоны смогут у вас подключиться к этому серверу и забрать с него конфигурацию, или прошивку, или что они ещё могут забрать с него. Так что на Cisco любые опции, как те, которые штатно предусмотрены, так и кастомные, произвольного формата, вы можете задать для работы каких-то произвольных механизмов. Если вдруг вы не хотите раздавать всю сетку, которая есть в вашем пуле — 10.0.0.0/24 у нас есть, но мы хотим не раздавать определённые адреса из этого диапазона, потому что они зафиксированы за какой-то конкретной задачей. Например, у нас есть статические IP-шники, которые мы по своему желанию можем раздавать в определённой части этой сети. Например, IP-шники с 1 по 50 раздаются вручную на какие-то серверы, принтеры, и мы не хотим, чтобы они динамически раздавались клиентам.

В этом случае мы должны будем воспользоваться командой ip dhcp excluded-address и дальше сказать, какой диапазон мы выкусываем из раздаваемых адресов. Есть нюанс, заключающийся в том, что мы это делаем не в пуле, а в глобальном конфиге. Мы говорим, что в принципе Cisco ни в одном пуле эти IP-шники раздавать не может. Понятно, что они все попадают в этот пул, но тем не менее мы говорим это не в пуле, а в глобальном конфиге. Немножко неочевидно. Если вдруг вы будете работать в провайдере, вам там может понадобиться тот самый агент ретрансляции, relay, и тогда в конфигурации вы увидите на роутере отсутствие пула, но присутствие вот такой странной команды. ip helper-address, и дальше некий IP-шник. Если вдруг вы это видите, не пугайтесь, это тот самый DHCP relay. Более строго говоря, это даже не DHCP relay, а это UDP relay.

Он любые бродкасты, которые содержат UDP-шное вложение распознанных типов, будет пересылать на указанный unicast-овый IP-шник, подставляя в качестве источника IP-шник самого интерфейса. Он это будет делать не только с DHCP, но ещё и с DNS, который тоже может бродкастом бегать, TFTP, который тоже может бродкастом бегать, TACACS — оригинальный старый, древний TACACS тоже по UDP мог бегать. Если вдруг вы хотите выключить поведение helper-address для некоторых протоколов, которые по умолчанию включены, то вы можете сказать no ip forward-protocol на глобальном конфиге и сказать, что для TFTP, например, мы выключаем обработку с помощью helper-address. Но всё остальное, включая DHCP, конечно же, будет форвардиться на указанный адрес. Если вы работаете в провайдере, вы можете увидеть в некоторых случаях добавление 82-й опции. Это указание интерфейса, на котором был получен определённый пакет, определённый DHCP Discover.

Смысл заключается в том, что если вы как relay перекладываете DHCP-запросы, вы часто хотите добавить в них какую-то доверенную, достоверную информацию. В оригинальном пакете вся информация представлена самим клиентом, и он там мог подделать всё, что угодно. Но если у вас есть умный свитч, например, цисковский свитч, и у него есть какие-то клиенты, которые на его портах сидят, вы можете, получая Discover'ы на портах свитча, добавлять к ним 82-ю опцию, которая указывает, из-под какого порта оно пришло. И если это порт GigabitEthernet 0/0, то у вас получится DHCP Discover, в котором есть какая-то информация, которую предоставил клиент, и плюс ещё есть доверенная информация, что это GigabitEthernet 0/0 интерфейс на каком-то конкретном свитче. И вы можете, пересылая такой запрос на DHCP-сервер, на самом сервере проанализировать эту информацию и сказать: в соответствии с нашей базой пользовательской, на интерфейсе GigabitEthernet 0/0 на свитче номер 17 у нас сидит Василий Петрович, который живёт по улице Строителей, дом 25, квартира 12.

И что бы ни написал Василий Петрович в своём Discover, мы всё равно будем ему предлагать тот самый IP-шник, который зафиксирован за улицей Строителей, дом 25, квартира 12. В провайдерах эта штука довольно часто используется. Не пугайтесь, если увидите information option — это как раз 82-я опция. Information — это про то, на каком порту был получен такой запрос. Как диагностировать работу DHCP на Cisco? Используется команда show ip dhcp pool, которая покажет список пулов и краткую выжимку информации про них. В нашем случае у нас есть пул, который называется POOL_NAME. В нём есть всего 254 боевых адреса, которые можно использовать. 256 адресов всего, но два из них служебные. С 10.0.0.1 по 10.0.0.254 они все в пуле находятся. Некоторые адреса из этого пула раздавать по факту не получится.

Например, потому что у нас могут быть выкушены адреса из пула с помощью DHCP excluded-address. Или некоторые адреса могут принадлежать самому роутеру. Или некоторые адреса мы уже выдали, поэтому их повторно сейчас выдавать уже не будем. Здесь показывается следующий адрес, который мы собираемся выдать. Это будет 10.0.0.5. Здесь показывается общее количество адресов, которые мы из этого пула по факту выдали. Если вы хотите посмотреть, что именно было арендовано, что именно было выдано, то есть команда show ip dhcp binding, которая покажет, что у нас есть адрес 10.0.0.2, который мы выдали автоматическим образом. Просто у нас есть какой-то клиент, он пришёл, сказал «дайте мне адрес», мы ему выдали этот адрес и потом его обратно заберём. Этот адрес будет действителен до вот этого времени. И каким образом мы определили, что это именно он пришёл — он нам показал свой так называемый client ID.

Это некий идентификатор клиента, который он предъявил при аренде. Гипотетически можно предположить, что в следующий раз, если он придёт, он снова нам покажет именно этот идентификатор. Можно заметить, что в пуле у нас был выдан один адрес, но как-то подозрительно не бьётся здесь, что у нас пул начинается с 10.0.0.1, есть ещё адрес 10.0.0.2, мы знаем, что он выдан, 10.0.0.3, 10.0.0.4 и 10.0.0.5. И следующий, который мы будем выдавать, будет 10.0.0.5. А возникает вопрос: 3 и 4, куда они делись? Их явно никто не выдавал, но почему-то мы их не можем даже попытаться выдать. Дело в том, что некоторые адреса, которые у вас помечены как свободные в пуле, на самом деле являются занятыми. И система может определить, что такое произошло. Ваш роутер включился в сеть, у него все адреса свободные, но он подключился и, например, ловит Gratuitous ARP с IP-шником 10.0.0.3 или 10.0.0.4.

И в этой ситуации у вас может возникнуть когнитивный диссонанс. Не понимаете, что происходит. Адрес вроде должен быть свободен, а по факту его уже кто-то использует. В этом случае вы такой адрес не выдаёте — было бы странно, если бы вы его выдавали — и помечаете его как конфликтный. И эти конфликтные адреса можно посмотреть с помощью команды show ip dhcp conflict. Показываются проблемные IP-шники и откуда мы решили, что они проблемные. Если вдруг мы попытались выдать какой-то IP-шник, мы сначала, перед тем как его выдавать, должны будем убедиться, что он не занят на самом деле. Тот факт, что он у нас в пуле числится как свободный, не означает, что на самом деле этот адрес свободный. Мы его должны будем какими-то доступными нам способами проверить на свободность. И самый простой способ — это попинговать его. Если он пингуется, значит, он занят. Второй вариант — если мы сидели, никого не трогали, и тут к нам Gratuitous ARP пришёл. Тоже значит, что кто-то этот адрес захватил.

Показывается время, когда конфликт был обнаружен. И если вдруг вы, допустим, перезагрузились как DHCP-сервер, у вас были какие-то пользователи, они получали адреса, вы их выдавали. Дальше вы, как роутер, перезагрузились, базу DHCP свою потеряли. Все, кто у вас раньше получал IP-шники, они все будут порождать конфликтные записи. Такие IP-шники повторно в ближайшее время уже выдавать не будете. Давайте попробуем понастраивать всё это дело на наших железках. Вот наши роутеры и свитчи. Давайте сделаем первым делом связь между роутером и свитчем. Если вы помните, у нас роутер и свитч связаны между собой с помощью интерфейсов Ethernet 0/0. И есть маленький нюанс, который заключается в том, что там по умолчанию не совпадают дуплексы.

Поэтому то, что мы сейчас сделаем — мы включим интерфейс Ethernet 0/0 на роутере, если мы этого ещё не сделали. Дальше на нас будут начинать валиться вот такие сообщения. Конкретно здесь просто я знаю, что интерфейс уже на этом роутере включился. И мы со стороны роутера зафиксируем полный дуплекс. Сейчас я на роутере. Enable. Conf t. Как вы понимаете, enable я сократил до en, а configure terminal сократил до conf t. Это стандартные сокращения в отрасли. И в принципе, несмотря на то что я рекомендую вам, по крайней мере, до экзамена все команды писать целиком, вот эти команды вы, наверное, можете просто уже сразу привыкать, что они пишутся всегда и везде сокращённо. Дальше. Interface Ethernet 0/0 и duplex full. Я фиксирую полный дуплекс для того, чтобы наш роутер и свитч не ругались между собой.

Если вдруг у вас такие сообщения не пробегают — no shutdown. Дополнительная команда понадобится, чтобы со стороны роутера включить интерфейс, который смотрит на свитч. Дальше. У нас роутер и свитч соединены между собой интерфейсом, и наши свитчи — они умные. Они не просто свитчи. Они могут прикидываться и роутерами тоже. Это то, что я вам показывал — L3-свитчи, которые могут выполнять и функции маршрутизаторов. Поэтому сейчас мы сделаем следующую вещь. Мы заставим наш свитч быть DHCP-сервером, а наш роутер мы заставим быть DHCP-клиентом. Вам может показаться это немножко странным, вы можете сказать «что за фигня, давай наоборот сделаем». Но проблема в том, что свитч может быть DHCP-сервером, но не может быть DHCP-клиентом. Поэтому придётся делать именно вот так, кривенько. На интерфейсе Ethernet 0/0 мы сейчас выполним очень простую команду IP address DHCP.

И роутер будет пытаться получить адрес по DHCP со стороны свитча. А на свитче мы сейчас будем делать тюнинг. Мы будем там включать интерфейсы, включать интерфейсы, на которых можно повесить IP-шники, потому что на штатных интерфейсах свитча нельзя повесить адрес. На роутере можно повесить IP-адрес. Команда такая есть. Можно IP-адрес ручками повесить, можно по DHCP, можно сказать, выбери себе какой-нибудь случайный IP-шник из link-local адресов. Все эти контексты тут есть. И в контексте IP на самом деле тут тоже много всякого есть. Большой контекст. Видите? Много тут всякого на интерфейсе можно связанного с IP сделать. На свитчах по умолчанию мы ничего такого сделать не можем, потому что на свитче интерфейсы все находятся в коммутируемом режиме. Вот свитч. Enable. Conf t. Интерфейс, допустим, Ethernet 0/0. Я сейчас специально вам показываю.

Контекст IP у него есть, но он крошечный. Даже близко не идёт ни в какое сравнение с тем, который на роутере был. Вот роутерный контекст IP. Он какой большой. И свитчовый контекст IP. Вообще ни о чём. Так вот, чтобы IP-адрес на свитч повесить, нам нужно сделать интерфейс, который бы смотрел в тот же самый широковещательный домен, который обслуживает интерфейс Ethernet 0/0. Если вы помните, у нас была такая штука, как VLANы, транки. Мы могли создавать эти самые VLANы, мы могли создавать транки, но сейчас нам это всё не понадобится, потому что лабу на VLANах и транках мы будем делать отдельно на ICND2. А что нам потребуется, так это команда show interface Ethernet 0/0 switchport. Вы уже помните, что это за команда. Она показывает состояние коммутации на интерфейсе. И на интерфейсе Ethernet 0/0 у нас действительно включена коммутация.

На этом интерфейсе у нас нет собственного MAC-а. Любые кадры, которые приходят на этот интерфейс, мы отправляем на виртуальный коммутатор. И если бы это был транк, то мы бы верили тому, что написано в заголовке кадра. Мы бы из заголовка транка прочитали, на какой виртуальный коммутатор нужно отправить этот кадр. Но этот порт работает в режиме Dynamic Auto, который не согласовал нам транк. Соответственно, у нас по факту получился access-порт. И в access-режиме наш порт все кадры трактует как кадры первого VLANа. Соответственно, у нас есть первый VLAN, у нас есть порт, который смотрит в первый VLAN коммутируемый. И для того, чтобы в этом VLANе нам можно было обрабатывать IP-пакеты, нам нужно сделать воображаемый интерфейс, который в этот VLAN бы и смотрел. Conf t. Дальше. Interface VLAN 1.

Мы создали воображаемый интерфейс, который смотрит в первый VLAN. Это интерфейс маршрутизируемый, и он по умолчанию выключенный, поэтому надо включить его. Команда на нём штатная есть, no shutdown. Это, соответственно, антивыключатель интерфейса. После того, как её задал, интерфейс поднимается, переходит в состояние up. Пожалуйста, у себя то же самое сделайте. Включите воображаемый интерфейс VLAN 1 и сделайте на нём команду no shutdown. Убедитесь, что у вас пробежало два сообщения, что физика поднялась, и канальный уровень поднялся. Физика на нём поднята, а канальный уровень означает, что можно отправлять IP-пакеты в кадрах Ethernet на таком воображаемом интерфейсе. Этот интерфейс сейчас находится в общем широковещательном домене со всеми портами, которые находятся в первом VLANе. Например, с Ethernet 0/0. Как следствие, на этом интерфейсе мы сейчас можем взаимодействовать с нашим роутером, потому что он смотрит на тот же виртуальный коммутатор,

что и порт Ethernet 0/0, за которым сидит наш роутер. Этот воображаемый интерфейс, зачем мы его сделали? Потому что на него можно повесить IP-адреса. У него контекст IP уже нормальный. Видите, много всего можно сделать. На физическом интерфейсе IP-шник повесить нельзя, потому что он в коммутируемом режиме. А на этом виртуальном интерфейсе, который смотрит на виртуальный коммутатор, можно повесить IP-шник. Фактически это интерфейс маршрутизатора. Наш свитч объединяет в себе и коммутатор, и маршрутизатор. И здесь мы можем сказать IP address. И дальше здесь можно как раз повесить IP-шник. Обратите внимание как раз на то, что я вам говорил. Сейчас я на роутер переключаюсь. IP address. Команда, которую я задал на роутере, IP address DHCP, заставляет роутер получить по DHCP адрес от кого-то ещё. На роутерах, на наших устройствах,

эта команда есть. А на свитче команды IP address DHCP нету. То есть EOS на роутерах и на свитчах всё-таки чуть-чуть отличается между собой. Немножко отличается. Поэтому здесь мы IP-шник задаём ручками. После того, как интерфейс включился, пробежало сообщение, что физика поднялась, канальный уровень поднялся, даём на интерфейсе VLAN 1 на свитче команду IP address. Дальше указываем IP-шник, который мы хотим получить. Обратите внимание, у вас на лабораторном стенде два устройства, роутер и свитч. Каждое из них относится к некоторому лабораторному комплекту. И в заголовке вкладки с консолькой устройства написано, какие номера роутера и свитча у вас есть. У меня написано роутер R08, свитч S08. У вас какие-то другие цифры. R01, S01, R02, S02 и так далее. Эти цифры, которые там есть, показывают номер вашего лабораторного комплекта.

Например, если у вас R01, значит, это у вас первый комплект. R02 — второй комплект. Пожалуйста, давайте воспользуемся этим номером комплекта и зададим IP-адрес. 10.0. Номер комплекта. У меня он восьмой. Видите? R08, S08. У вас другие номера. Поэтому я делаю 10.0.8, что-то там, а вы делаете 10.0.1, что-то там. 10.0.2, что-то там. В зависимости от того, какой у вас номер комплекта. И, соответственно, дальше на конце единичка. И дальше маска. 255.255.255.0. Я создал IP-адрес на интерфейсе свитча, который на самом деле маршрутизируемый интерфейс. И у меня этот IP-шник повесился на интерфейс. Дальше. Сейчас я должен буду, для того чтобы проверить, что у нас DHCP работает, создать пул адресов, которые я готов раздавать своим клиентам. Выхожу из контекста настройки интерфейса и указываю IP DHCP pool.

И какое-нибудь название. Учитывая, что в этой лабораторной работе нам название не сильно важно, я сделаю здесь DHCP_pool. Нажимаю Enter, перехожу в контекст настройки пула и здесь указываю network. Дальше указываю ту самую сетку, в которой находится этот IP-шник. 10.0.8.1 по 24-й маске. 10.0.8.0 по маске /24. И это всё, что требуется для настройки DHCP. Со стороны свитча мы: а) включили воображаемый интерфейс, б) убедились, что этот воображаемый интерфейс смотрит туда же, куда смотрит Ethernet 0/0, в) повесили на этом интерфейсе IP-шник, и г) создали pool, в котором раздаются все адреса из той же самой сети 10.0.8.0. У вас это будет другая сеть. У вас будет 10.0.2.0, 10.0.1.0 и так далее.

После того, как я создал этот pool, и на интерфейсе, на котором наш свитч смотрит на роутер, появился IP-шник из этого пула, гипотетически наш роутер должен уже получить адрес из этой сети. И что я вижу? Пробежало вот такое диагностическое сообщение, что наш интерфейс Ethernet 0/0 получил IP-адрес 10.0.8.8. Какой красивый адрес ему выдался. И, соответственно, маска 255.255.255.0. Давайте проверим, что этот адрес действительно работает. Я с роутера попингую. Ping 10.0.8.1. И он пингается. Обратите внимание на вывод команды ping. Мы про пинги чуть дальше будем говорить. Сейчас просто поверьте, что этот результат обозначает, что всё хорошо. Вообще говоря, восклицательный знак обозначает, что вы смогли попингать соседа. То, что здесь отправлено 5 пакетов,

из которых только 4 дошли до получателя и вернулись назад, это нормально, это ожидаемое поведение в нашем случае. В нашем случае мы попингали соседа, и он пингается. Да, у вас из вашей сети, из моей сети в адрес... Я что-то не подумал. У нас же все свитчи соединены в один широковещательный домен. Я обычно эту лабу делаю, создавая отдельный VLAN под каждый роутер. И сейчас я решил схалявить и сделать всё в первом VLANе. И у нас получилось, что все роутеры находятся в одном широковещательном домене. Да, давайте я со своей стороны сейчас... Что бы мне такое сделать? Давайте я на свитче. Пожалуй, на центральном свитче, который соединяет все наши свитчи. Enable, conf t, VLAN 1. Можно ли его выключить?

State suspend. Так, с VLANом первым такой номер не пройдёт. Та-да-да-да. Так, ладно. Interface range. Ethernet 0, слэш 0-3. Ethernet 1, слэш 0-3. Ethernet 2, слэш 0-3. Ethernet 3, слэш 0-3. Shutdown. Центральный свитч, который связывает наши свитчи, я сейчас выключил. Выключил все интерфейсы на нём. И как следствие, гипотетически, наши свитчи теперь больше не связаны между собой. Выключите, пожалуйста, интерфейс Ethernet 0/0 на вашем роутере. Я покажу, как это делается. Interface Ethernet 0/0. Shutdown. У вас пробегает сообщение о том, что интерфейс погасился. И после чего no shutdown.

Интерфейс снова включился. Так, два сообщения пробежало. И no shutdown. И после того, как вы это сделаете, ваш роутер больше не сможет получить DHCP-аренду с моего свитча. Он может получить только со своего свитча. И теперь, по идее, гипотетически, всё должно быть хорошо. Главное теперь не забыть, что у нас интерфейсы на свитче выключены. Это может превратиться в весёлый траблшутинг. Так, замечательно. У нас появился IP-шник на роутере. У нас есть IP-шник на свитче. И давайте теперь посмотрим на то, что в итоге получается, когда у нас есть IP-адрес. Сам факт наличия IP-адреса на интерфейсе порождает строчку в таблице маршрутизации. Show IP route.

Show IP route. Вот. У нас есть IP-шник. В моём случае 10.0.8.9. И, соответственно, есть вот такая 10.0.8.0 по 24-й маске connected-сеть. Мы повесили один IP-шник. Это сразу породило локальный маршрут на наш собственный адрес по 32-й маске. И сразу породило connected-маршрут, что все остальные IP-шники из сети 10.0.8.0 доступны через интерфейс Ethernet. Таким образом мы смогли сделать очень простую вещь. Все наши роутеры понимают, что за остальными узлами в этих сетях надо идти напрямую в интерфейс Ethernet. Слово directly connected обозначает как раз, что до всех узлов в этой сети можно напрямую добраться с помощью протокола ARP. Не надо ходить через какие-то транзитные узлы. Любой узел находится на расстоянии вытянутой руки.

Так. Далее. Про статические маршруты и динамические маршруты мы будем делать отдельную лабу в конце нашего курса. Поэтому здесь про таблицу маршрутизации можно пока завершить разговор. Потому что про таблицу маршрутизации мы будем говорить ещё довольно долго. Но можно посмотреть на свитче, что у нас получилось. С одной стороны мы знаем, что роутер действительно получил аренду адреса. А с другой стороны можно посмотреть со стороны DHCP-сервера, что там за аренды по факту были выданы. Я сильно подозреваю, что этих аренд там довольно много. Show у меня, по крайней мере. Show IP DHCP binding. Ну да, он понараздавал тут всяких разных адресов. 10.0.8.2, 10.0.8.3, 10.0.8.4. Все они выдавались в VLANе первом.

И, соответственно, у них у всех срок аренды — это один день. Show IP DHCP pool. Показывает, какой у меня pool. Он называется DHCP_pool. Показывается, какой диапазон адресов в этом пуле есть. Сколько адресов по факту выдано. 7 штук. Вот они, 7 штук. Сколько адресов всего? 254. И следующий адрес, который будет выдаваться — 10.0.8.10. Окей. Пусть будет так. Если вдруг у нас есть какие-то конфликты, show IP DHCP конфликт нам их покажет. Вряд ли у нас тут есть что-то. Да, у нас тут ничего нет. Вот так оно и работает. DHCP достаточно просто выглядит. Создаем пул. В этом пуле у нас должен быть IP-шник на нашем боевом интерфейсе. И как только два этих фактора начинают сочетаться между собой,

мы на интерфейсе начинаем раздавать адреса из этого пула. Больше никаких настроек не требуется. Если вдруг мы захотим раздавать какие-то опции, шлюз по умолчанию, DNS-сервер или что-либо еще, это в настройках пула все можно будет сделать. Conf-t. IP DHCP pool DHCP подчеркивание pool. Здесь я должен дать ровно такое же название, как я дал изначально. И вопросик нам покажет, что допустимо здесь указывать. Допустимо указывать шлюз по умолчанию. Допустимо указать DNS-сервера. Допустимо указать доменный суффикс. Network, понятное дело, это в обязательном порядке должно быть. Если хотим какие-то сырые опции, задать поле option. И всё. Остальное здесь не очень сильно интересно.

Вот такая настройка DHCP на цисках. Довольно просто всё. Можно ли еще раз про тип в байндингах? У меня там какая-то фигня. Я могу подтвердить, что да, какая-то тут фигня есть. Честно говоря, не знаю, что это за стейт. Сильно подозреваю, гипотетически, что это офферы, которые я послал, но которые не получили подтверждение. Я не могу вам точно сказать, что это за колонка, потому что я не знаю этого. Но я предполагаю, судя по тому, что я здесь вижу, что Active — это офферы, на которые я получил подтверждение, и, соответственно, Acknowledge на них отправил. А Selecting — это офферы, которые я отправил, но на них реквест не пришел. Поэтому адрес гипотетически занят, но практически он может освободиться в ближайшее время. У вас всё Selecting. Видимо, да, видимо, вы офферы посылали всякие,

а никто их не заклеймил, и вот они у вас висят как потенциально возможные, которые пригодятся в ближайшем будущем. Честно говоря, в реальности очень редко приходится их видеть, в основном всегда всё Active. Видимо, это как раз ситуация, когда у нас несколько непересекающихся сетей в одном широковещательном домене, и там несколько DHCP серверов дерутся за то, чтобы выдать кому-нибудь какой-нибудь IP-шник. Вероятно, в этой ситуации как раз Selecting будут встречаться. Да, по идее, всё. Тут больше ничего про DHCP не расскажешь. Давайте к следующей теме.