DHCP в деталях
Назначение протокола и основные принципы его работы
Дополнительные возможности: relay
Дополнительные возможности: option 82, snooping
Дополнительные возможности: импорт параметров
Дополнительные возможности: поддержка VRF
Дополнительные возможности: Voice VLAN
Введение
За кажущейся простотой протокола DHCP скрывается большой набор возможностей, о которых администраторы часто не подозревают. В данной статье мы не станем подробно изучать все возможности протокола, однако в некоторые интересные детали всё-таки погрузимся. Мы не претендуем на максимально полное рассмотрение теоретических аспектов, за которыми читатель может обратиться к любым специализированным изданиям. Здесь же хотелось бы особо подчеркнуть, что, несмотря на то, что рассматривать работу DHCP (RFC2131) в основном мы будем на оборудования компании Cisco, большинство параметров также доступны в коммутаторах и маршрутизаторах других вендоров. Также хотелось бы отметить, что данная статья рассчитана на широкий круг читателей, поэтому начинать мы будем с самых простых, можно даже сказать, элементарных вещей, однако, надеемся, что не отпугнём этим более продвинутого читателя.
Итак, скорее приступим!
Назначение протокола и основные принципы его работы
Протокол DHCP (Dynamic Host Configuration Protocol) предназначен для централизованного управления IP-параметрами конечного клиентского оборудования. Конечно же, никто не запрещает использовать DHCP для настройки серверов или сетевого оборудования, однако чаще всего в таких случаях применяется статическая конфигурация, которая считается более предсказуемой. Мы специально отметили, что протокол используется для управления именно IP-параметрами, потому что у многих администраторов сложился неправильный стереотип, заключающийся в том, что клиент-серверный протокол DHCP ограничен лишь настройкой IP-адреса. IP-адрес – лишь один из параметров, которые могут быть сконфигурированы с помощью обсуждаемого протокола. Какие же ещё параметры могут быть переданы узлу? К их числу (но не ограничиваясь ими) относятся следующие (RFC1533 и RFC2132): маска подсети, шлюз по умолчанию, адреса DNS и WINS серверов, имя домена и самого узла, маршруты на определённые подсети, временную зону и адрес сервера времени, адрес загрузочного образа, TTL и MTU, адреса POP3 и SMTP серверов, время аренды адреса. Не все опции могут использоваться или поддерживаться клиентом или сервером, однако часто клиенты и серверы DHCP всё-таки поддерживают довольно широкий набор опций.
Получение IP-параметров производится с помощью четырёх сообщений, которыми обмениваются клиент и сервер.
Сообщение DHCP discover отправляется клиентом для обнаружения DHCP-сервера в локальном сегменте сети. Забегая вперёд, отметим, что современные топологии не подразумевают непосредственной установки сервера в каждую виртуальную сеть (VLAN), в которой расположены клиентские узлы. Вместо этого используются особый ретранслятор, о котором мы поговорим чуть позже.
Получив сообщение DHCP discover, сервера DHCP отвечают клиенту сообщением DHCP offer, содержащим предлагаемые параметры. Получив несколько таких предложений, клиент может выбрать из них то, которое его максимально устраивает. Обычно, правда, выбирается первое полученное сообщение DHCP offer. Стоит отметить, что в этот момент сервер лишь на короткое время резервирует за клиентом предложенный IP-адрес, и если клиент не запросит его использование, - освободит для дальнейшего использования (вернёт адрес в пул).
Выбрав одно из предложений, клиент отправляет широковещательный запрос DCHP request серверу на закрепление за ним предложенных параметров. До получения подтверждения от сервера клиент не вправе использовать избранный IP-адрес. Широковещательное сообщение здесь используется в том числе и для того, чтобы уведомить остальные серверы, что их предложения не рассматриваются, что позволит им быстрее вернуть адрес в пул.
Получив сообщение DHCP request, сервер отправляет клиенту сообщение DCHP ack, подтверждающее за клиентом право использования выданного IP-адреса. Стоит заметить, что в некоторых случаях, сервер может не подтвердить клиенту запрос на использование адреса. Такая ситуация может произойти, например, в случае, когда сервер выдал данный IP-адрес другому клиенту, либо была произведена переконфигурация самого DHCP-сервера. Если сервер не может подтвердить клиенту использование ранее предложенных параметров, то сервер отправляет клиенту сообщение DHCP nack.
Одной из обязательных опций, сообщаемых сервером клиенту, является время аренды IP-адреса. Данный параметр указывает на интервал времени, в течение которого клиент в праве использовать полученные IP-параметры. По истечении данного времени, клиент обязан освободить занимаемый IP-адрес, либо произвести его продление. Если клиент собирается освободить занимаемый адрес, то производится отправка сообщения DHCP release. Получив такое сообщение, сервер возвращает IP-адрес, ранее принадлежавший клиенту, в пул свободных адресов.
Для наших читателей мы подготовили дамп трафика, содержащий процедуру получения и освобождения IP-адреса хостом. Все файлы дампов, размещённые в данной статье можно открыть с помощью сетевого анализатора Wireshark. Мы настоятельно рекомендуем внимательно изучить все поля во всех пакетах, содержащихся в данном файле. Отфильтровать DHCP-сообщения в большом дампе с помощью Wireshark можно путём использования фильтра «bootp».
Пакеты с первого по четвёртый включительно содержат стандартную процедуру получения IP-параметров. В пакетах 5, 6 и 7 клиентом было отправлено сообщение DHCP release, извещающее сервер о досрочном прекращении аренды.
Каким же образом сервер извещает клиента о том, на какое время ему выдаётся IP-адрес? Как и всё в DHCP, данная информация передаётся в пакете в виде опции (опция №51). Кроме этого в протоколе DHCP предусмотрены два таймера, обычно называемые T1 (renewal) и T2 (rebinding), передаваемые опциями 58 и 59, соответственно. Таймер T1 обычно равен половине времени аренды, тогда как T2 соответствует 7/8 времени аренды. Для чего же используются данные таймеры? Спустя время T1 после получения сообщения DHCP ack клиент начинает процедуру обновления IP-параметров (renewing), повторно запрашивая у сервера разрешение на право их использования. Если никаких изменений не произошло, сервер разрешает продление времени аренды путём отправки сообщения DHCP ack. Если же по какой-то причине сервер на запрос о продлении аренды не ответил, спустя время T2 происходит широковещательная отправка сообщения DHCP request, с помощью которого клиент пытается найти сервер, способный продлить аренду полученных ранее IP-параметров. Если же данная попытка не увенчалась успехом, то по окончанию времени аренды клиент обязан освободить полученный IP-адрес.
В предыдущем примере сервер устанавливает время аренды, равное семи дням. Мы уменьшили время аренды до одной минуты и пронаблюдали за процессом обмена DHCP-сообщениями. Из приведённого ниже списка пакетов видно, что примерно каждые 30 секунд клиент отправляет сообщение DHCP request, запрашивая у сервера подтверждение на право использования полученных адресов. В ответ на данное сообщение сервер отправляет пакет DHCP ack. Так, например, пары пакетов 5-6, 7-8 и 9-10 являются успешными попытками продления аренды. Пакет №11 содержит сообщение DHCP request, на которое не приходит подтверждение от сервера. Тогда клиент отправляет широковещательный DHCP request (пакет №12), на который (в нашем примере) также не получает подтверждения. Пакеты №№ 13-17 содержат стандартные сообщения DHCP discover, отправляемые после того, как хост отказался от использованного IP-адреса.
На картинке ниже представлено содержимое пакета DHCP offer, содержащее все три таймера.
Если клиентом является маршрутизатор Cisco, то в логе в момент окончания аренды появляются следующие сообщения.
R1#*Aug 11 21:16:12.743: %DHCP-5-RESTART: Interface GigabitEthernet0/0 is being restarted by DHCP
R1#*Aug 11 21:16:14.815: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down
R1#*Aug 11 21:16:15.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down
R1#*Aug 11 21:16:17.847: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
R1#*Aug 11 21:16:18.847: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
Также нельзя обойти вниманием самое первое сообщение, отправляемое клиентом, - DHCP discover. Опция №55 (Parameter Request List) содержит список опций, интересующих конечное устройство. На картинке ниже представлен такой список, сгенерированный маршрутизатором Cisco 7206VXR (NPE400) с установленной операционной системой IOS версии 15.2(4)M8 ADVENTERPRISEK9, выполняющий функции DHCP-клиента.
Список запрашиваемых опций не статический, его состав зависит от типа и настройки конечного устройства. Так, например, для клиента на базе операционной системы Windows 7 x64 список несколько отличается и представлен ниже.
Строго говоря, полностью идентифицировать клиента по списку запрашиваемых параметров нельзя, однако операционная система и используемое программное обеспечение всё же оставляют некоторый отпечаток в DHCP сообщениях, по которому можно приблизительно определить, какой клиент используется. Мы не будем здесь описывать все возможные следы, однако укажем на несколько наиболее интересных. Так, например, маршрутизатор компании Cisco в опцию №61 включит краткую информацию о себе. Опция №12 содержит имя запрашивающего узла. Пожалуй, стоит отметить, что среди возможностей, предоставляемых системой Cisco ISE, присутствует функция определения используемой клиентом операционной системы, но обсуждение вопросов работы данной системы далеко выходит за рамки данной статьи.
Встроенный в операционную систему Microsoft Windows 7 x64 клиент протокола DHCP с помощью опции №60 (Vendor class identifier) также передаёт о себе некоторые сведения, по которым его можно идентифицировать.
Кроме уже описанных ранее сообщений протокола DHCP существует и ещё одно, которое мы не упомянули, - DHCP information. С его помощью клиент может запросить дополнительную информацию, которую сервер не отправил в сообщении DHCP offer.
На этом мы заканчиваем беглое рассмотрение основных аспектов работы протокола DHCP и переходим к изучению его настройки.
Настройка оборудования
Настроить использование протокола DHCP с клиентской стороны, как правило, труда не составляет. Например, при использовании операционной системы Microsoft Windows 7, единственное, что требуется сделать, - выбрать опцию «Получить IP-адрес автоматически» в настройках протокола IPv4.
Убедиться в успешном получении адреса с помощью GUI тоже не сложно.
Получить информацию о текущей конфигурации сетевых карт компьютера в современных операционных системах Microsoft Windows можно с помощью команды ipconfig /all.
C:\>ipconfig /all
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : torrent
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Порядок просмотра суффиксов DNS . : Beeline.Gate
Ethernet adapter Подключение по локальной сети 2:
DNS-суффикс подключения . . . . . : Beeline.Gate
Описание. . . . . . . . . . . . . : Сетевое подключение Intel(R) PRO/1000 MT
Физический адрес. . . . . . . . . : 00-0C-29-CD-86-26
DHCP включен. . . . . . . . . . . : Да
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 10.0.1.112(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Аренда получена. . . . . . . . . . : 13 августа 2015 г. 21:20:01
Срок аренды истекает. . . . . . . . : 14 августа 2015 г. 21:20:01
Основной шлюз. . . . . . . . . : 10.0.1.5
DHCP-сервер. . . . . . . . . . . : 10.0.1.5
DNS-серверы. . . . . . . . . . . : 8.8.8.8
Основной WINS-сервер. . . . . . . : 10.0.1.5
NetBios через TCP/IP. . . . . . . . : Включен
Отказаться от используемого адреса и запросить новый можно с помощью команд ipconfig /release и ipconfig /renew. Стоит также отметить, что в указанном семействе операционных систем, существует достаточно мощная сетевая утилита netsh, с помощью которой можно просматривать и изменять параметры работы сетевых карт. Так, например, получить информацию об используемых IPv4 адресах можно с помощью вызова netsh interface ipv4 show addresses.
Современные SOHO маршрутизаторы позволяют подключаться к провайдеру, предоставляющему IP-параметры динамически. На картинках ниже показаны типовые настройки подключения к провайдеру на примере двух современных беспроводных маршрутизаторов.
Кроме того, такие устройства обладают также встроенным DHCP-сервером, позволяющим динамически назначать IP-адреса в локальной сети пользователя. Да, параметров здесь не много…
Всю дальнейшую конфигурацию мы будем производить с использованием оборудования Cisco Systems в эмуляторе GNS3 версии 1.3.9. Мы специально решили использовать эмулятор, чтобы наши читатели могли при желании самостоятельно повторить все те настройки, которые будут обсуждаться. Стоит отметить, что в GNS3 версии 1.4.0 появится встроенная поддержка виртуальных машин VMware, что во многом сможет упростить процесс тестирования новых схем сети. Конечно, уже сейчас есть возможность, связать эмулируемое в GNS3 оборудование с реальной сетью и виртуальными сетями VMware с помощью объекта Cloud, однако, особенно удобной такую связку не назовёшь. Однако мы отвлеклись, пора вернуться к DHCP. В качестве маршрутизаторов мы будем использовать модель 7206VXR (NPE400) с IOS ADVENTERPRISEK9 версии 15.2(4)M8. Также нам потребуется L2-коммутатор IOU (встроенный в GNS3 свитч не подойдёт из-за отсутствия нужной функциональности).
В принципе, в качестве DHCP-клиента в GNS3 можно использовать объект VPCS, допускающий статическое и динамическое назначение IP-параметров. Для демонстрации работы VPCS мы собрали простую схему, приведённую ниже. Настройки серверной стороны – маршрутизатора R1 – мы обсудим позже.
Приведённый ниже листинг отображает процесс динамического получения IP-параметров виртуальным хостом VPCS версии 0.6.1 в эмуляторе GNS3.
PC1> ip ?
ip ARG ... [OPTION]
Configure the current VPC's IP settings
ARG ...:
address [mask] [gateway]
address [gateway] [mask]
Set the VPC's ip, default gateway ip and network mask
Default IPv4 mask is /24, IPv6 is /64. Example:
ip 10.1.1.70/26 10.1.1.65 set the VPC's ip to 10.1.1.70,
the gateway to 10.1.1.65, the netmask to 255.255.255.192.
In tap mode, the ip of the tapx is the maximum host ID
of the subnet. In the example above the tapx ip would be
10.1.1.126
mask may be written as /26, 26 or 255.255.255.192
auto Attempt to obtain IPv6 address, mask and gateway using SLAAC
dhcp [OPTION] Attempt to obtain IPv4 address, mask, gateway, DNS via DHCP
-d Show DHCP packet decode
-r Renew DHCP lease
-x Release DHCP lease
dns ip Set DNS server ip, delete if ip is '0'
domain NAME Set local domain name to NAME
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.101/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE : 86388, 86400/43200/75600
MAC : 00:50:79:66:68:00
LPORT : 10001
RHOST:PORT : 192.168.56.1:10000
MTU: : 1500
Несмотря на то, что VPCS для своей работы требует гораздо меньше оперативной памяти, чем эмулируемый маршрутизатор Cisco серии 7200, далее мы будем использовать именно маршрутизатор даже для выполнения роли клиента DHCP, так как, во-первых, командная строка маршрутизатора нам более привычна, а, во-вторых, мы не стеснены в ресурсах.
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no sh
R2(config-if)#ip add dc
*Aug 14 08:50:40.347: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up
*Aug 14 08:50:41.347: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up
R2(config-if)#ip address dhcp
*Aug 14 08:50:59.183: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.102, mask 255.255.255.0, hostname R2
R2(config-if)#^Z
R2#sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.0.102 YES DHCP up up
FastEthernet1/0 unassigned YES unset administratively down down
FastEthernet1/1 unassigned YES unset administratively down down
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [254/0] via 192.168.0.1
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.102/32 is directly connected, GigabitEthernet0/0
R2#sho ip dns view
DNS View default parameters:
Logging is off
DNS Resolver settings:
Domain lookup is disabled
Default domain name:
Domain search list:
Lookup timeout: 3 seconds
Lookup retries: 2
Domain name-servers:
8.8.8.8
DNS Server settings:
Forwarding of queries is disabled
Forwarder timeout: 3 seconds
Forwarder retries: 2
Forwarder addresses:
Из приведённого выше листинга видно, что маршрутизатор R2 получает IP-адрес 192.168.0.102/24 на интерфейс Gi0/0. Кроме самого адреса с помощью DHCP был передан маршрут по умолчанию и адрес DNS-сервера. Более подробную информацию о работе протокола DHCP на клиентском маршрутизаторе можно получить с помощью команды sho dhcp lease.
R2#sho dhcp lease
Temp IP addr: 192.168.0.102 for peer on Interface: GigabitEthernet0/0
Temp sub net mask: 255.255.255.0
DHCP Lease server: 192.168.0.1, state: 5 Bound
DHCP transaction id: 2155
Lease: 86400 secs, Renewal: 43200 secs, Rebind: 75600 secs
Temp default-gateway addr: 192.168.0.1
Next timer fires after: 11:53:40
Retry count: 0 Client-ID: cisco-ca02.0468.0008-Gi0/0
Client-ID hex dump: 636973636F2D636130322E303436382E
303030382D4769302F30
Hostname: R2
Естественно, доступен и вывод отладочной информации об обмене сообщениями DHCP. Приведённый ниже листинг отображает момент отказа маршрутизатора R2 от арендованного ранее адреса. Вывод отладочных сообщений может быть произведён и на стороне DHCP-сервера, однако стоит отметить, что следует быть особенно осторожным при использовании команды debug в высоконагруженных сетях.
R2#debug dhcp ?
detail DHCP packet content
redundancy DHCP client redundancy support
<cr>
R2#debug dhcp
DHCP client activity debugging is on
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#no ip add
*Aug 14 08:59:30.487: DHCP: Sending notification of TERMINATION:
*Aug 14 08:59:30.487: Address 192.168.0.102 mask 255.255.255.0
*Aug 14 08:59:30.491: DHCP: Client socket is opened
*Aug 14 08:59:30.491: DHCP: SRelease attempt # 1 for entry:
*Aug 14 08:59:30.491: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:30.495: DHCP: SRelease: 279 bytes
*Aug 14 08:59:32.175: DHCP: SRelease attempt # 2 for entry:
*Aug 14 08:59:32.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:32.175: DHCP: SRelease: 279 bytes
*Aug 14 08:59:34.175: DHCP: SRelease attempt # 3 for entry:
*Aug 14 08:59:34.175: DHCP: SRelease placed Server ID option: 192.168.0.1
*Aug 14 08:59:34.175: DHCP: SRelease: 279 bytes
R2(config-if)#
*Aug 14 08:59:35.999: RAC: DHCP stopped on interface GigabitEthernet0/0
R2(config-if)#
*Aug 14 09:00:07.207: DHCP: deleting entry 6AF1FA40 192.168.0.102 from list
*Aug 14 09:00:07.207: DHCP: Client socket is closed
R2(config-if)#do sho deb
DHCPC:
DHCP client activity debugging is on
Рассмотрим теперь настройки с серверной стороны, то есть конфигурацию маршрутизатора R1. Первое, что требуется сделать, - запустить соответствующую службу. В современных версиях IOS служба DHCP по умолчанию запущена. Отключить указанную службу можно с помощью команды no service dhcp.
R1(config)#service dhcp
R1(config)#no service dhcp
Вторым шагом является создание DHCP пула с помощью команды ip dhcp pool name, где name – имя создаваемого пула. В листинге ниже на маршрутизаторе R1 создаётся пул foxnetwork, для которого указываются DNS-сервера, шлюз по умолчанию и время аренды. Если в сети планируются какие-либо изменения в ближайшее время, то перед этими изменениями мы бы рекомендовали значительно уменьшать время аренды для того, чтобы пользовательские устройства максимально оперативно отреагировали на произошедшие изменения. Когда топология сети стабилизировалась, время аренды может быть существенно увеличено. Часто время аренды устанавливают равным нескольким дням или даже неделям. В принципе, значение данного параметра выбирается не только из статичности сетевой инфраструктуры, но и с учётом мобильности клиентов. Например, при организации сети в кафе, стоит учитывать, что происходит частая смена посетителей, таким образом, обычно не имеет смысла выставлять время аренды более одного часа. С помощью команды network производится выбор интерфейса, к которому привязан данный пул, а также указание диапазона адресов, который используется для назначения клиентам. Исключить какие-либо IP-адреса из диапазона можно с помощью команды ip dhcp excluded-address режима глобальной конфигурации.
ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
lease 1
default-router 192.168.0.1
dns-server 8.8.8.8
Посмотреть список созданных пулов и их использование можно с помощью команды sho ip dhcp pool.
R1#sho ip dhcp pool
Pool foxnetwork :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses
192.168.0.102 192.168.0.1 - 192.168.0.254 1
Команда sho ip dhcp binding отображает список адресов, которые были назначены клиентам.
R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.0.101 0063.6973.636f.2d63. Aug 21 2015 09:46 AM Automatic
6130.322e.3034.3638.
2e30.3030.382d.4769.
302f.30
Статистические сведения о работе службы DHCP на маршрутизаторе можно получить с помощью команды sho ip dhcp server statistics.
R1#sho ip dhcp server statistics
Memory usage 73238
Address pools 1
Database agents 0
Automatic bindings 1
Manual bindings 0
Expired bindings 0
Malformed messages 0
Secure arp entries 0
Message Received
BOOTREQUEST 0
DHCPDISCOVER 5
DHCPREQUEST 4
DHCPDECLINE 0
DHCPRELEASE 6
DHCPINFORM 0
Message Sent
BOOTREPLY 0
DHCPOFFER 4
DHCPACK 4
DHCPNAK 0
Иногда в корпоративных сетях возникает необходимость статической привязки выдаваемого IP-адреса к определённому клиенту. Такую привязку можно осуществить на основе идентификатора клиента, передаваемого в опции №61. Сравните значение опции №61 в сообщениях DHCP discovery, отправляемых разными DHCP-клиентами. Пример DHCP discovery, отправляемый маршрутизатором Cisco, содержится в файле foxnetwork_1.pcapng, то же сообщение от Microsoft Windows 7 находится в файле foxnetwork_3.pcapng. Таким образом, перед началом создания статической привязки IP-адреса к клиенту, нужно выяснить значение идентификатора, отправляемого операционной системой клиента. После того, как идентификатор клиента выяснен, необходимо перейти к настройке DHCP-сервера, работающего на маршрутизаторе. Статическая привязка организуется путём создания нового DHCP-пула, в котором требуется лишь указать адрес, выдаваемый клиенту, и идентификатор клиента. Также можно указать имя клиента с помощью команды client-name (не передаётся клиенту в сообщениях DHCP). Пример такого пула представлен ниже.
ip dhcp pool r2
host 192.168.0.111 255.255.255.0
client-identifier 0063.6973.636f.2d63.6130.322e.3135.3063.2e30.3030.382d.4769.302f.30
client-name test
Все остальные настройки (кроме IP-адреса) клиент наследует из родительского пула. Стоит также отметить, что наследование настроек происходит и при использовании обычных пулов. Рассмотрим небольшой сегмент сети, представленный на схеме.
В листинге ниже мы создали два пула для вложенных диапазонов: 192.168.0.0/16 и 192.168.0.0/24. Для большой подсети задана единственная настройка – адрес DNS-сервера. Пул с более мелкой подсетью содержит адрес шлюза по умолчанию.
ip dhcp pool parent
network 192.168.0.0 255.255.0.0
dns-server 8.8.8.8
ip dhcp pool child
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
R1#sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.0.1 YES manual up up
Убедиться, что клиент (роль которого выполняет узел VPCS) получает все необходимые настройки можно с помощью команды show ip.
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.2/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE : 86397, 86400/43200/75600
MAC : 00:50:79:66:68:00
LPORT : 10000
RHOST:PORT : 192.168.228.2:10001
MTU: : 1500
Для закрепления материала рекомендуем начинающим читателям выполнить соответствующую лабораторную работу.
Процесс назначения IP-адреса
Ранее мы рассмотрели команду ip dhcp excluded-address, позволяющую исключить диапазон адресов из выдачи. Такое исключение будет полезным, когда в одной IP-подсети находятся как динамически конфигурируемые клиенты, так и узлы со статической конфигурацией, например, интерфейсы сетевого оборудования или сервера. Но что если в сети окажется статически сконфигурированное устройство, адрес которого выходит за пределы исключаемого диапазона? Для обнаружения подобных ситуаций, служба DHCP, работающая на маршрутизаторе Cisco, использует протокол ICMP. Вероятно, некоторые наши читатели удивятся, узнав, что используется ICMP echo, а не ARP. Да-да, используется именно ICMP и в дальнейшем станет понятно, почему. Рассмотрим на примерах, что именно происходит в момент выдачи адреса клиенту.
Для начала используем простую схему с двумя маршрутизаторами R1 и R2, которую мы уже применяли ранее. R1 выполняет функции сервера, а R2 – клиента. Все пакеты, которыми обмениваются два устройства, мы сохранили в файле foxnetwork_4.pcapng. Первый пакет отправляется клиентом - это обычный gratuitous ARP, за которым следует широковещательное сообщение DHCP discover. Третий пакет – ARP-запрос DHCP-сервера об адресе 192.168.0.102. Следующие три пакета – обычное окончание DHCP обмена. Но что это за адрес 192.168.0.102? Из четвёртого пакета (DHCP offer) понятно, что это адрес, предлагаемый сервером клиенту. Получается, что перед тем, как выдать адрес, сервер рассылает ARP-запрос. Но никакого ICMP, верно? Что ж, попробуем разместить в сети узел с IP-адресом, который планирует выдать R1. Наша сеть несколько изменится.
Мы добавили маршрутизатор R3, на интерфейс Gi0/0 которого назначили IP-адрес 192.168.0.103, который должен быть выдан при следующем DHCP-запросе к маршрутизатору R1. Следующий выдаваемый адрес отображается в выводе команды sho ip dhcp pool в поле Current index. Мы перехватили процесс обмена сообщениями при получении адреса маршрутизатором R2 и сохранили его в файле foxnetwork_5.pcapng. По дампу трафика видно, что маршрутизатор R1, получив запрос DHCP, отправляет ARP-запрос об адресе 192.168.0.103, а после получения ответа, отправляет сообщение ICMP echo-request, в ответ на которое R3 отправляет ICMP echo-reply. После получения эхо-ответа маршрутизатор R1 проверяет на занятость следующий адрес – 192.168.0.104. Убедившись в том, что данный адрес свободен, R1 предлагает его клиенту. Итак, мы увидели, что при выборе адреса для клиента DHCP-сервер проверяет занятость этого адреса с помощью ICMP. Маршрутизаторы Cisco Systems, выполняющие функции DHCP-сервера позволяют даже произвести настройку количества отправляемых ICMP эхо-запросов и их таймауты.
R1(config)#ip dhcp ping ?
packets Specify number of ping packets
timeout Specify ping timeout
R1(config)#ip dhcp ping pa
R1(config)#ip dhcp ping packets ?
<0-10> Number of ping packets (0 disables ping)
<cr>
R1(config)#ip dhcp ping ti
R1(config)#ip dhcp ping timeout ?
<100-10000> Ping timeout in milliseconds
Остаётся единственный вопрос: что будет делать DHCP-сервер, если получит ARP-ответ, но не получит ICMP echo-reply? Попробуем воспроизвести данную ситуацию. Для того чтобы запретить маршрутизатору R3 отвечать на ICMP-запросы, требуется создать список доступа, запрещающий ICMP эхо, а также ввести команду no ip unreachables на интерфейсе Gi0/0. Список доступа и конфигурация интерфейса Gi0/0 маршрутизатора R3 представлены в листинге ниже. Хотелось бы обратить внимание читателей на то, что мы также изменили IP-адрес интерфейса, так как следующим предлагаемым по DHCP адресом должен быть 192.168.0.105.
ip access-list extended NOICMP
deny icmp any any
permit ip any any
interface GigabitEthernet0/0
ip address 192.168.0.105 255.255.255.0
ip access-group NOICMP in
no ip unreachables
duplex full
speed 1000
media-type gbic
negotiation auto
И что же будет теперь, если допустить, что DHCP-сервис маршрутизаторов Cisco полагается именно на ICMP? При использовании приведённой конфигурации, R2 должен получить адрес, уже назначенный маршрутизатору R3. К счастью, этого не происходит, так как перед началом использования предлагаемого DHCP-сервером адреса клиент проверяет наличие такого адреса в сети именно с помощью протокола ARP. Все сообщения, которыми обмениваются маршрутизаторы, представлены в файле foxnetwork_6.pcapng. Последовательность действий узлов в сети следующая.
- R2 отправляет сообщение DHCP discover.
- R1 с помощью ICMP проверяет занятость адреса 192.168.0.105.
- Во время такой проверки R3 отвечает на ARP-запрос (что делает возможной отправку сообщения ICMP), но не отвечает на сообщение ICMP echo-request.
- Маршрутизатор R1, не получив никакого ICMP сообщения от узла с адресом 192.168.0.105, предлагает его использование клиенту R2 при помощи сообщения DHCP offer.
- Клиент R2 получает сообщение DHCP offer от сервера R1, содержащее предлагаемый IP-адрес, после чего выполняет собственную проверку занятости адреса 192.168.0.105 с помощью протокола ARP.
- Узел R3 отвечает на ARP-запрос маршрутизатора R2.
- R2 считает, что предложенный сервером IP-адрес 192.168.0.105 уже занят, и отправляет серверу уведомление об этом с помощью сообщения DHCP decline.
- R1 вносит адрес 192.168.0.105 в свою базу конфликтующих адресов.
- R2 вновь инициирует поиск сервера DHCP путём отправки сообщения DHCP discover.
- Сервер R1 выбирает следующий адрес из пула – 192.168.0.106 – и проверяет, не занят ли он.
- Сервер R1 предлагает адрес 192.168.0.106 клиенту R2 с помощью сообщения DHCP offer.
- Клиент R2 запрашивает у сервера разрешение на использование адреса 192.168.0.106 при помощи сообщения DHCP request.
- Сервер R1 подтверждает использование клиентом R2 адреса 192.168.0.106 с помощью сообщения DHCP ack.
- Маршрутизатор R2 выполняет собственную проверку занятости нового адреса и убеждается, что он свободен.
Стоп-стоп-стоп! Что-то в этом списке не так. Судя по дампу, после отправки второго сообщения DHCP discover клиент не выполняет проверку занятости предлагаемого адреса, а сразу принимает его, после чего рассылает сообщение gratuitous ARP. Мы повторили процесс ещё раз, назначив узлу R3 адрес 192.168.0.107. Ошибки быть не может, всё именно так и происходит. Но что же будет, если повторно полученный адрес окажется также занятым? Мы добавили в нашу схему ещё один хост со следующим по порядку адресом, таким образом у нас в сети сейчас присутствует узел R3 с адресом 192.168.0.109, и R4 – 192.168.0.110, которые не отвечают на ICMP-сообщения.
Мы вновь инициировали процедуру получения IP-адреса маршрутизатором R2. Дамп трафика мы сохранили в файле foxnetwork_7.pcapng. Получается, что получив IP-адрес второй раз, клиент назначает его на свой интерфейс, отправляет gratuitous ARP, обнаруживает занятость данного адреса, после чего проводит стандартную процедуру отказа от полученного адреса с помощью сообщения DHCP decline. На узлах R3 и R4 в этот момент появляются следующие сообщения.
*Aug 14 15:22:04.751: %IP-4-DUPADDR: Duplicate address 192.168.0.110 on GigabitEthernet0/0, sourced by ca02.150c.0008
Просмотреть список конфликтующих адресов на R1 можно с помощью команды sho ip dhcp conflict.
R1#sho ip dhcp conflict
IP address Detection method Detection time VRF
192.168.0.103 Ping Aug 14 2015 01:12 PM
192.168.0.105 Gratuitous ARP Aug 14 2015 02:15 PM
192.168.0.107 Gratuitous ARP Aug 14 2015 03:16 PM
192.168.0.109 Gratuitous ARP Aug 14 2015 03:22 PM
192.168.0.110 Gratuitous ARP Aug 14 2015 03:22 PM
Очистка базы конфликтующих адресов производится с помощью команды clear ip dhcp conflict.
R1#clear ip dhcp conflict ?
* Clear all address conflicts
A.B.C.D Clear a specific conflict
vrf DHCP vrf conflicts
R1#clear ip dhcp conflict *
R1#sho ip dhcp conflict
IP address Detection method Detection time VRF
R1#
На этом мы завершаем рассмотрение процедуры получения IP-параметров и переходим к рассмотрению использования вторичных IP-подсетей совместно с протоколом DHCP.
Secondary subnet
С увеличением количества IP-устройств в сети может возникнуть нехватка IP-адресов в пуле. Конечно, в некоторых случаях с данной проблемой можно справиться путём уменьшения времени аренды IP-адреса, однако ситуации, когда все устройства длительное время находятся во включённом состоянии, нередки. Выхода из сложившейся ситуации два: увеличение ранее выделенной подсети и использование второй подсети. К сожалению, увеличение подсети не всегда возможно, например, из-за отсутствия непрерывных подсетей большего размера. Рассмотрим настройку оборудования для использования вторичной подсети на примере сети, представленной ниже. Будем считать, что изначально для связи узла PC1 и маршрутизатора R1 использовалась подсеть 192.168.0.0/30. После появления узла PC2 существующего диапазона, очевидно, стало недостаточно.
В листинге ниже представлены основные настройки маршрутизатора R1, до появления хоста PC2. Интерфейс Loopback 0 используется для эмуляции глобальной сети.
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.252
default-router 192.168.0.1
dns-server 8.8.8.8
domain-name foxnetwork.ru
lease 0 1
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.252
load-interval 30
Первое, с чего, естественно, требуется начать, - это настройка интерфейса маршрутизатора или L3-коммутатора, на интерфейсе которого необходимо прописать вторичный IP-адрес.
R1#sho run int gi0/0
Building configuration...
Current configuration : 204 bytes
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.252 secondary
ip address 192.168.0.1 255.255.255.252
load-interval 30
end
Одним из способов использования DHCP-сервером вторичной подсети является создание второго DHCP-пула.
ip dhcp pool foxnetwork2
network 192.168.1.0 255.255.255.252
dns-server 8.8.8.8
domain-name foxnetwork.ru
default-router 192.168.1.1
lease 0 1
Кроме создания второго пула существует и более элегантное решение, состоящее в указании наличия вторичной сети в настройках существующего пула адресов.
R1#sho run | sec pool
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.252
network 192.168.1.0 255.255.255.252 secondary
override default-router 192.168.1.1
default-router 192.168.0.1
dns-server 8.8.8.8
domain-name foxnetwork.ru
lease 0 1
Стоит, правда, отметить, что для вторичной сети в настройках DHCP-пула можно изменить лишь значение шлюза по умолчанию. Если требуется, чтобы различались какие-либо ещё параметры, единственным решением на данный момент является создание второго DHCP-пула.
Осталось только проверить работоспособность приведённой выше конструкции.
PC2> ip dh
DDORA IP 192.168.1.2/30 GW 192.168.1.1
PC2> sho ip
NAME : PC2[1]
IP/MASK : 192.168.1.2/30
GATEWAY : 192.168.1.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE : 3599, 3600/1800/3150
DOMAIN NAME : foxnetwork.ru
MAC : 00:50:79:66:68:01
LPORT : 10004
RHOST:PORT : 192.168.56.1:10005
MTU: : 1500
PC2> sho ip all
NAME IP/MASK GATEWAY MAC DNS
PC2 192.168.1.2/30 192.168.1.1 00:50:79:66:68:01 8.8.8.8
PC2> sho arp
ca:01:5f:7c:00:08 192.168.1.1 expires in 37 seconds
PC2> ping 192.168.1.1 -c 3
84 bytes from 192.168.1.1 icmp_seq=1 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=2 ttl=255 time=9.000 ms
84 bytes from 192.168.1.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.1 -c 3
84 bytes from 192.168.0.1 icmp_seq=1 ttl=255 time=5.001 ms
84 bytes from 192.168.0.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 192.168.0.1 icmp_seq=3 ttl=255 time=9.000 ms
PC2> ping 192.168.0.2 -c 3
84 bytes from 192.168.0.2 icmp_seq=1 ttl=63 time=11.001 ms
84 bytes from 192.168.0.2 icmp_seq=2 ttl=63 time=19.001 ms
84 bytes from 192.168.0.2 icmp_seq=3 ttl=63 time=19.002 ms
PC2> ping 1.1.1.1 -c 3
84 bytes from 1.1.1.1 icmp_seq=1 ttl=255 time=4.000 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=255 time=9.001 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=255 time=9.000 ms
Очевидным недостатком использования вторичных сетей (вместо увеличения существующей сети) является необходимость использования маршрутизатора для передачи трафика между узлами, расположенными в первичной и вторичных IP-сетях. Использование двух и более IP-сетей в данном случае не приводит к уменьшению широковещательного трафика, что также, возможно, стоит учитывать при построении крупных корпоративных сетей. В этом случае, вероятно, лучше использовать несколько виртуальных сетей (VLAN) и различные DHCP-пулы. Ещё одно замечание, которое хотелось бы здесь привести, связано с использованием многоуровневых коммутаторов. Если используется единственное MLS устройство, которое выполняет функции маршрутизации, коммутации и DHCP-сервера, в этом случае увеличением задержек и падением производительности сети (из-за необходимости маршрутизировать трафик между узлами в первичной и вторичных IP-сетях) можно пренебречь.
При обсуждении особенностей использования вторичных IP-сетей на интерфейсах нельзя не упомянуть о команде ip dhcp smart-relay, влияющей на работу маршрутизатора, выполняющего функции ретранслятора DHCP и использующего вторичные IP-адреса на интерфейсах. Рассмотрим в качестве примера небольшую сеть, представленную на рисунке ниже.
Маршрутизатор R1 является ретранслятором DHCP, тогда как маршрутизатор R2 выполняет функции DHCP-сервера. Допустим, что на интерфейсе Fa1/0 маршрутизатора R1 настроены две IP-сети. Пример настройки интерфейса Fa1/0 маршрутизатора R1 представлен ниже. Адрес 2.2.2.2 назначен на интерфейсе Loopback 0 маршрутизатора R2. Считаем, что на обоих маршрутизаторах маршрутизация настроена правильно.
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0 secondary
ip address 192.168.0.1 255.255.255.0
ip helper-address 2.2.2.2
На маршрутизаторе R2 настроен DHCP-пул.
ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool foxnetwork
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
dns-server 8.8.8.8
lease 0 1
По умолчанию, маршрутизатор R1 пересылает сообщение DHCP discover с первичного IP-адреса, настроенного на интерфейсе Fa1/0. Так как на устройстве R2 нет DHCP-пула для сети 192.168.0.0/24, сообщение DHCP offer отправлено не будет, что приведёт к тому, что клиентский узел PC1 не получит IP-адрес. Включение опции smart-relay заставляет маршрутизатор R1 после отправки трёх сообщений с первичного IP-адреса, отправлять сообщения DHCP discover с адреса вторичной сети в ситуации, когда на первые три сообщения не было получено сообщения DHCP offer. Перехват сообщений DHCP между маршрутизаторами R1 и R2 мы сохранили в файл foxnetwork_13.pcapng. Читателям стоит обратить внимание на поле «Relay agent IP address» в сообщениях DHCP discover.
С точки зрения маршрутизации первичная и вторичные сети ничем принципиальным не отличаются. Здесь мы не рассматриваем использование протоколов динамической маршрутизации, некоторые из которых не могут установить соседство с другими маршрутизаторами, расположенными во вторичных IP-сетях.
R1#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/30 is directly connected, GigabitEthernet0/0
L 192.168.0.1/32 is directly connected, GigabitEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/30 is directly connected, GigabitEthernet0/0
L 192.168.1.1/32 is directly connected, GigabitEthernet0/0
Рассмотрим теперь, какие ещё возможности предоставляет оборудование компании Cisco по работе с протоколом DHCP.
Дополнительные возможности: relay
Все схемы, обсуждавшиеся выше, предполагали установку DHCP-сервера непосредственно в пользовательский сегмент. Конечно же, использование многоуровневого коммутатора в качестве DHCP-сервера также допустимо, однако при использовании MLS оборудования эксплуатация IPAM систем, к числу которых относится и решение для управления сетями Cisco Network Registrar (CNR), может быть затруднена или вовсе невозможна. Существует ли технология, позволяющая не подключать DHCP-сервер к каждому пользовательскому сегменту и при этом не заставлять коммутаторы и маршрутизаторы заниматься распределением IP-адресов? Такая функция, конечно же, существует и называется DHCP relay. Оборудование, выполняющее роль DHCP-ретранслятора, перехватывает широковещательные сообщения DHCP discover и пересылает их DHCP-серверу. Включение поддержки функции ретранслятора производится с помощью интерфейсной команды ip helper-address. Рассмотрим небольшую схему, приведённую ниже.
Узел PC1 является DHCP-клиентом. Маршрутизатор R1 терминирует на себе клиентскую сеть и выполняет функции ретранслятора. DHCP-сервером является маршрутизатор R2. Приведём основные параметры конфигурации обоих маршрутизаторов. На устройстве R1 введены следующие команды.
interface Loopback0
ip address 192.168.255.1 255.255.255.255
interface FastEthernet1/0
ip address 192.168.0.1 255.255.255.0
ip helper-address 192.168.255.2
interface FastEthernet1/1
ip address 192.168.1.1 255.255.255.0
router eigrp 1
network 192.168.1.0
redistribute connected
Конфигурация маршрутизатора R2 представлена ниже.
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
dns-server 8.8.8.8
lease 0 1
interface Loopback0
ip address 192.168.255.2 255.255.255.255
interface FastEthernet1/1
ip address 192.168.1.2 255.255.255.0
router eigrp 1
network 192.168.1.0
redistribute connected
Процесс получения IP-адреса клиентом с использованием ретранслятора не отличается от такового при размещении DHCP-сервера непосредственно в сети клиента.
PC1> ip dhcp
DDORA IP 192.168.0.11/24 GW 192.168.0.1
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.11/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE : 3595, 3600/1800/3150
MAC : 00:50:79:66:68:00
LPORT : 10000
RHOST:PORT : 192.168.56.1:10001
MTU: : 1500
PC1> ping 192.168.255.2
84 bytes from 192.168.255.2 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 192.168.255.2 icmp_seq=3 ttl=254 time=16.001 ms
84 bytes from 192.168.255.2 icmp_seq=4 ttl=254 time=21.001 ms
84 bytes from 192.168.255.2 icmp_seq=5 ttl=254 time=32.002 ms
Естественно, мы перехватили процесс получения клиентом IP-адреса. В файле foxnetwork_11.pcapng находятся пакеты, передаваемые между клиентом и маршрутизатором R1, тогда как файл foxnetwork_12.pcapng содержит трафик, которым обменивались маршрутизаторы R1 и R2. Как видно из дампа foxnetwork_12.pcapng обмен DHCP сообщениями между маршрутизаторами происходит с помощью unicast-адресов. Мы рекомендуем читателям сравнить значение поля «Relay agent IP address» в обоих файлах. Также небезынтересным является ICMP трафик, отправляемый DHCP-сервером в процессе получения IP-адреса клиентом. В предыдущем разделе мы описывали алгоритмы, используемые сервером DHCP, для определения занятости IP-адреса до предложения его клиенту. Так вот, протокол ARP в данном случае, очевидно, не может быть использован совершенно, так как передача ARP-сообщений через маршрутизатор не производится.
Стоит отметить, что по умолчанию, команда ip helper-address пересылает не только DHCP сообщения, но и целый ряд других. Отключить ретрансляцию протокола можно с помощью команды no ip forward-protocol.
switch(config)#no ip forward-protocol ?
nd Sun's Network Disk protocol
sdns Network Security Protocol
spanning-tree Use transparent bridging to flood UDP broadcasts
turbo-flood Fast flooding of UDP broadcasts
udp Packets to a specific UDP port
switch(config)#no ip forward-protocol udp ?
<0-65535> Port number
biff Biff (mail notification, comsat, 512)
bootpc Bootstrap Protocol (BOOTP) client (68)
bootps Bootstrap Protocol (BOOTP) server (67)
discard Discard (9)
dnsix DNSIX security protocol auditing (195)
domain Domain Name Service (DNS, 53)
echo Echo (7)
isakmp Internet Security Association and Key Management Protocol (500)
mobile-ip Mobile IP registration (434)
nameserver IEN116 name service (obsolete, 42)
netbios-dgm NetBios datagram service (138)
netbios-ns NetBios name service (137)
netbios-ss NetBios session service (139)
non500-isakmp Internet Security Association and Key Management Protocol (4500)
ntp Network Time Protocol (123)
pim-auto-rp PIM Auto-RP (496)
rip Routing Information Protocol (router, in.routed, 520)
snmp Simple Network Management Protocol (161)
snmptrap SNMP Traps (162)
sunrpc Sun Remote Procedure Call (111)
syslog System Logger (514)
tacacs TAC Access Control System (49)
talk Talk (517)
tftp Trivial File Transfer Protocol (69)
time Time (37)
who Who service (rwho, 513)
xdmcp X Display Manager Control Protocol (177)
<cr>
Также мы не можем не упомянуть здесь об одной, возможно, не самой очевидной детали: на маршрутизаторе, выполняющем функции ретранслятора DHCP, должна быть включена служба DHCP. Включение службы производится с помощью команды service dhcp, для отключения используйте команду no service dhcp. В маршрутизаторах Cisco данная служба включена автоматически и в запущенном состоянии даже не отображается в текущем конфиге.
R2#sho run | i dhcp
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#no serv dhcp
R2(config)#^Z
R2#sho run | i dhcp
no service dhcp
R2#
Администратор может также настроить поведение ретранслятора DHCP при получении DHCP сообщения, содержащего информацию о другом ретрансляторе. Указанные сообщения могут быть отброшены, инкапсулированы (DHCP-сервер, в принципе, может использовать обе опции №82), пересланы без изменений, либо информация о ретрансляторе может быть заменена.
switch(config)#ip dhcp relay information policy ?
drop Do not forward BOOTREQUEST message
encapsulate Encapsulate existing information
keep Leave existing information alone
replace Replace existing information
Очень тесно с темой DHCP ретранслятора связаны поддержка опции №82 и DHCP snooping, о которых мы поговорим в следующем разделе.
Дополнительные возможности: option 82, snooping
До этого момента мы никак не настраивали коммутатор, связывающий клиента и маршрутизатор R1, единственное, что требовалось, - чтобы порты e0/0 и e0/1 находились в одной виртуальной сети. Однако периодически возникает необходимость определённому клиенту выдавать фиксированный адрес с помощью DHCP. Задача осложняется тем, что клиент может использовать различные устройства для подключения к сети, таким образом его MAC-адрес и идентификатор клиента могут отличаться, что не позволит использовать данные поля DHCP-сервером для создания статической привязки. В этом случае на помощь приходит коммутатор с поддержкой функции option 82. Данную опцию ото всех остальных отличает то, что её в DHCP сообщение добавляет не клиент и не сервер, а коммутатор, тогда как сервер DHCP анализирует её значение. К счастью L2 IOU версии adventerprisek9-15.1a поддерживает данную функцию. Включение поддержки option 82 производится с помощью команды ip dhcp relay information option режима глобальной конфигурации. Также необходимо включить DHCP snooping. Ниже представлены команды, которые были введены на коммутаторе.
ip dhcp relay information option
ip dhcp snooping vlan 1
ip dhcp snooping
interface Ethernet0/1
ip dhcp snooping trust
Мы перехватили сообщение DHCP discover на участке сети между коммутатором IOU1 и маршрутизатором R1. Как видно из представленной ниже картинки, коммутатор добавил в сообщение опцию №82. Её содержимое мы пока не рассматриваем.
Однако, несмотря на то, что мы увидели сообщение DHCP discover в сети, клиент перестал получать IP-адрес. Просмотр дампа трафика нас приводит к тому, что маршрутизатор R1 перестал выполнять функции ретранслятора. Неожиданно, правда? С помощью команды deb ip dhcp server packet мы включили вывод отладочной информации на маршрутизаторе DHCP. В момент получения пакета, содержащего сообщение DHCP discover, в консоли появлялись следующие сообщения, - сработала так называемая санитарная проверка.
*Aug 21 18:28:28.247: DHCPD: inconsistent relay information.
*Aug 21 18:28:28.247: DHCPD: relay information option exists, but giaddr is zero
Отключение указанной выше проверки производится на интерфейсе Fa1/0 маршрутизатора R1 с помощью команды ip dhcp relay information trusted, после чего клиент успешно получает IP-адрес. Список интерфейсов, для которых включена данная команда выводится с помощью вызова sho ip dhcp relay information trusted-sources.
R1#sho ip dhcp relay information trusted-sources
List of trusted sources of relay agent information option:
FastEthernet1/0
Выдача адреса клиенту на данный момент никак не учитывает значение опции №82. Для того чтобы DHCP-сервер начал учитывать значение опции №82 необходимо сконфигурировать специальный класс для данного клиента. Пример такой конфигурации представлен ниже.
ip dhcp class foxnetwork
remark test client
relay agent information
relay-information hex 010600040001000002080006aabbcc000100
Команда remark не является обязательной, однако мы настоятельно рекомендуем использовать, чтобы в дальнейшем не запутаться в большом количестве созданных классов. С помощью данной команды нужно вносить максимально понятное описание, связанное с клиентом, для которого создаётся класс.
Теперь требуется использовать созданный класс в настройках DHCP-сервера. Конфигурация DHCP пула представлена ниже.
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
dns-server 8.8.8.8
lease 0 1
class foxnetwork
address range 192.168.0.101 192.168.0.101
Повторно произведём получение IP-адреса клиентом и убедимся, что PC1 получил адрес 192.168.0.101.
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.11/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE : 2753, 3600/1800/3150
MAC : 00:50:79:66:68:00
LPORT : 10003
RHOST:PORT : 192.168.56.1:10000
MTU: : 1500
PC1> ip dhcp
DDORA IP 192.168.0.101/24 GW 192.168.0.1
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.101/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.1.2
DHCP LEASE : 3593, 3600/1800/3150
MAC : 00:50:79:66:68:00
LPORT : 10003
RHOST:PORT : 192.168.56.1:10000
MTU: : 1500
Но что же это за магическое число 010600040001000002080006aabbcc000100, которое мы указывали в команде relay-information и которое передавалось в опции №82? Разберём, из чего оно состоит.
| 010600040001000002080006aabbcc000100 | |
| 0106 | Начало первой секции, 6 байт |
| 0004 | Поле curcuit-id, 4 байта |
| 0001 | Номер VLAN (в hex) |
| 0000 | Номер порта коммутатора, к которому подключен клиент (счёт начинается с нуля) |
| 0208 | Начало второй секции, 8 байт |
| 0006 | Поле remote-id, 6 байт |
| aabbcc000100 | MAC-адрес коммутатора, к которому подключен клиент |
Теперь мы можем рассчитывать значение опции №82 заранее, не дожидаясь её в перехватываемых пакетах. Справедливости ради, стоит отметить, что коммутаторы Cisco позволяют изменить формат опции №82.
cisco_3750(config)#ip dhcp snooping information option format remote-id ?
hostname Use configured hostname for remote id
string User defined string for remote id
cisco_3750(config)#ip dhcp snooping information option format remote-id hostname ?
<cr>
cisco_3750(config)#ip dhcp snooping information option format remote-id string ?
WORD Use string for remote id (max length 63)
При настройке коммутатора в данной секции, мы задействовали функции DHCP-snooping. Но для чего она предназначена? Функция коммутатора DHCP-snooping предназначена для защиты от атак с использованием протокола DHCP. Примером таких атак может быть подмена DHCP-сервера или же атака DHCP starvation, в результате которой атакующий заставляет DHCP-сервер выдать злоумышленнику все доступные IP-адреса. Построенная в результате работы функции DHCP snooping база данных может использоваться и другими механизмами защиты, к числу которых относятся DAI (Dynamic ARP Inspection) и IP Source Guide. Правда, обсуждение работы данных функций выходит далеко за пределы темы данной статьи.
Функция DHCP snooping определяет для всех портов две роли: доверенный/надёжный (trusted) и ненадёжный (untrusted). К доверенным портам подключают другие коммутаторы или DHCP-серверы, DHCP-сообщения, полученные через эти порты, не отбрасываются. DHCP-трафик от ненадёжных портов инспектируется, а сообщения DHCP offer, ack/nack и leasequery отбрасываются. Инспекция DHCP-трафика от ненадёжных портов заключается, например, в следующем: проверяются сообщения DHCP release и decline на соответствие базе, проверяется соответствие MAC-адресов во фрейме и самом сообщении DHCP, устанавливается отсутствие опции №82. Также можно заставить коммутаторы выполнять проверку DHCP-сообщений на отсутствие в сообщении адреса ретранслятора.
IOU1(config)#ip dhcp snooping verify ?
mac-address DHCP snooping verify mac-address
no-relay-agent-address DHCP snooping verify giaddr
Просмотр настроек функции DHCP snooping производится с помощью команды show ip dhcp snooping.
IOU1#sho ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
1
DHCP snooping is operational on following VLANs:
1
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
circuit-id default format: vlan-mod-port
remote-id: aabb.cc00.0100 (MAC)
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface Trusted Allow option Rate limit (pps)
----------------------- ------- ------------ ----------------
Ethernet0/1 yes yes unlimited
Custom circuit-ids:
Команда show ip dhcp snooping statistics отображает статистические сведения о работе DHCP snooping.
IOU1#sho ip dhcp snooping statistics
Packets Forwarded = 229
Packets Dropped = 0
Packets Dropped From untrusted ports = 0
Просмотреть существующие в данный момент привязки можно с помощью команды show ip dhcp snooping binding.
IOU1#sho ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:50:79:66:68:00 192.168.0.101 1992 dhcp-snooping 1 Ethernet0/0
Total number of bindings: 1
Иногда требуется внести статическую запись в базу данных привязок DHCP snooping. Для выполнения указанной операции используется команда ip dhcp snooping binding <mac-address> vlan <vid> <ip-address> interface <interface-id> expiry <seconds>. Ключевое слово expiry позволяет указать время, в течение которого создаваемая запись будет существовать. Максимальное значение, которое допускает опция expiry, составляет 4294967295 секунд, что примерно соответствует 136 годам.
Базу данных функции DHCP snooping можно сохранять в энергонезависимой памяти локально, либо на удалённых серверах.
IOU1(config)#ip dhcp snooping database ?
disk0: Database agent URL
disk1: Database agent URL
ftp: Database agent URL
http: Database agent URL
rcp: Database agent URL
scp: Database agent URL
tftp: Database agent URL
timeout Configure abort timeout interval
unix: Database agent URL
write-delay Configure delay timer for writes to URL
Пожалуй, здесь же можно ещё отметить, что сохранить на удалённых серверах или в энергонезависимой памяти можно не только базу данных функции DHCP snooping, но и саму базу DHCP привязок, то есть используемых в данный момент клиентами IP-адресов. Такое сохранение базы может потребоваться для того, чтобы не потерять указанную базу в момент перезагрузки устройства. Пример команды, сохраняющей базу привязок DHCP локальной, можно найти ниже.
ip dhcp database disk1:fox.txt
Однако файл будет создан не сразу после введения команды, но с определённой задержкой. По умолчанию такая задержка составляет 300 секунд. Удостовериться в этом можно с помощью команды sho run all, выводящей также значения параметров по умолчанию. В листинге ниже содержится та же команда, но вместе с параметрами по умолчанию.
ip dhcp database disk1:fox.txt write-delay 300 timeout 300
Содержимое сохранённого таким образом файла представлено ниже.
R1#more disk1:fox.txt
*time* Aug 24 2015 02:07 AM
*version* 4
!IP address Type Hardware address Lease expiration VRF
192.168.1.3 id 0063.6973.636f.2d63.6130.322e.3165.3663.2e30.3030.382d.4769.302f.30 Aug 25 2015 02:03 AM
!IP address Type Hardware address Interface-name
!IP address Interface-name Lease expiration Server IP address Hardware address Vrf
*end*
Ещё одной интересной опцией, о которой мы не можем не упомянуть здесь, является сообщение DHCP lease query, позволяющее запросить у DHCP-сервера информацию о выданных IP-адресах. Сообщение DHCP lease query может использоваться устройствами, выполняющими, например, функции DHCP ретрансляторов, в ситуации утери собственной базы активных привязок из-за аварийной перезагрузки или по иным причинам. Подобная информация может быть использована сетевым оборудованием, например, для выполнения защиты от IP spoofing атак, либо при необходимости выполнить аутентификацию клиента на основе его MAC-адреса сервисом SSG. Подробное изучение сообщения DHCP lease query далеко выходит за рамки данной статьи. Более подробную информацию об этом сообщении можно получить в RFC4388 и RFC6148.
Дополнительные возможности: импорт параметров
Иногда может возникнуть необходимость выдавать DHCP-клиентам параметры, которые в свою очередь также были получены динамически. Рассмотрим схему ниже.
Маршрутизатор R3 – оборудование провайдера, выполняет функции DHCP-сервера для подключённых клиентов. Маршрутизатор R2 – оборудование клиента, являющееся одновременно DHCP-клиентом в сети провайдера и DHCP-сервером в собственной сети, к которой подключён узел PC1. R3 выдаёт адреса из сети 192.168.1.0/24, R2 выдаёт адреса из сети 192.168.0.0/24. Задача состоит в том, чтобы передать определённые параметры, например, адрес DNS-сервера, от маршрутизатора R3 к узлу PC1. Поскольку адреса DNS-серверов передаются на R2 динамически, включить их в конфигурацию заранее не представляется возможным. Вместо этого нужно использовать опцию import all в настройках DHCP-пула. В приведённом ниже листинге содержится частичный конфиг маршрутизатора R3. Как мы видим, R3 отдаёт своим клиентам адрес DNS-сервера.
ip dhcp excluded-address 192.168.1.1 192.168.1.10
ip dhcp pool test
network 192.168.1.0 255.255.255.0
dns-server 8.8.8.8
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.0
Ниже приведён частичный конфиг маршрутизатора R2.
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp pool test2
import all
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
interface FastEthernet1/0
ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
ip address dhcp
Как мы видим, маршрутизатор R2 не содержит информации о DNS-сервере, при этом узел PC1 соответствующую настройку получает.
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.0.12/24
GATEWAY : 192.168.0.1
DNS : 8.8.8.8
DHCP SERVER : 192.168.0.1
DHCP LEASE : 71323, 86400/43200/75600
MAC : 00:50:79:66:68:00
Здесь же хотелось бы обратить внимание читателей на одну вполне очевидную вещь – порядок действий. Чтобы импорт параметров был произведён успешно, необходимо, чтобы соответствующий DHCP-пул был уже полностью сконфигурирован до момента получения IP-параметров от оборудования провайдера.
Дополнительные возможности: поддержка VRF
В современных корпоративных сетях администраторы всё чаще прибегают к использованию VRF. Служба DHCP-сервера, реализованная в оборудовании Cisco, обладает поддержкой VRF. Рассмотрим ситуацию, когда к маршрутизатору подключаются клиенты, расположенные внутри определённой VRF, а также глобальные клиенты (не привязанные ни к какой VRF). Стоит напомнить, что VRF имеет локальную значимость, то есть никакие соседние устройства не знают о том, сконфигурированы ли какие-либо VRF на данном маршрутизаторе.
Итак, в нашем примере маршрутизатор R1 обладает двумя интерфейсами: FE 1/0 (принадлежит VRF a) и FE1/1 (принадлежит глобальной таблице маршрутизации). Подключение клиентов произведено так, как показано на схеме выше. В нашем примере мы будем использовать перекрывающиеся адреса сетей, например, 192.168.0.0/24. На оба интерфейса маршрутизатора мы назначим адрес 192.168.0.1/24. Исключим из раздачи адреса с первого по десятый включительно. Для проверки работоспособности схемы мы создадим два DHCP-пула, незначительно отличающиеся друг от друга. Клиенты, подключающиеся к глобальному пулу, будут получать адрес шлюза по умолчанию и адрес DNS-сервера 8.8.8.8. Клиенты, подключающиеся к интерфейсу, находящемуся в vrf a, не будут получать адрес шлюза по умолчанию, а адрес их DNS-сервера будет 8.8.4.4. Листинг ниже содержит основные параметры конфигурации маршрутизатора R1.
vrf definition a
rd 1:1
address-family ipv4
exit-address-family
ip dhcp excluded-address 192.168.0.1 192.168.0.10
ip dhcp excluded-address vrf a 192.168.0.1 192.168.0.10
ip dhcp pool global
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
dns-server 8.8.8.8
ip dhcp pool vrfa
vrf a
network 192.168.0.0 255.255.255.0
dns-server 8.8.4.4
interface FastEthernet1/0
vrf forwarding a
ip address 192.168.0.1 255.255.255.0
interface FastEthernet1/1
ip address 192.168.0.1 255.255.255.0
Просмотреть статистику использования пулов можно с помощью команды sho ip dhcp pool, отображающую также информацию о принадлежности пула определённой VRF.
R1#sho ip dhcp pool
Pool global :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
Total addresses : 254
Leased addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses
192.168.0.12 192.168.0.1 - 192.168.0.254 1
Pool vrfa :
Utilization mark (high/low) : 100 / 0
Subnet size (first/next) : 0 / 0
VRF name : a
Total addresses : 254
Leased addresses : 1
Pending event : none
1 subnet is currently in the pool :
Current index IP address range Leased addresses
192.168.0.12 192.168.0.1 - 192.168.0.254 1
Команда sho ip dhcp binding также отображает информацию о том, к какой VRF привязан клиент, получивший IP-адрес.
R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.0.11 0100.5079.6668.01 Jan 09 2016 12:30 AM Automatic
Bindings from VRF pool a:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.0.11 0100.5079.6668.00 Jan 09 2016 12:30 AM Automatic
В заключение стоит отметить, что поддержка VRF и MPLS VPN присутствует также и для устройств, выполняющих функции DHCP ретранслятора. Желающие могут самостоятельно изучить следующие команды.
ip helper-address vrf
ip dhcp relay information option vpn
ip dhcp relay information option vpn-id
Дополнительные возможности: Voice VLAN
Необходимость в использовании Voice VLAN возникает в ситуации, когда требуется подключить компьютер через IP-телефон, при этом телефон и компьютер должны находиться в разных виртуальных сетях.
Получается такая цепочка из устройств.
Коммутатору и телефону нужно каким-то образом договориться о том, каким образом будут передаваться данные. Обычно на линке между коммутатором и телефоном передаётся тегированный трафик двух виртуальных сетей: голос и данные. На линке между компьютером и телефоном обычно передаётся не тегированный трафик соответствующей виртуальной сети.
В описанной выше ситуации интерфейс коммутатора находится в режиме доступа (access) даже несмотря на то, что трафик передаётся тегированный. Конечно, между коммутатором и телефоном можно поднять и полноценный транк, однако этого часто стараются избегать. Пример настройки голосовой виртуальной сети на интерфейсе коммутатора представлен ниже.
interface GigabitEthernet 1/0/1
switchport
switchport mode access
switchport access vlan 2
switchport voice vlan 3
Традиционно сигнализация номеров виртуальных сетей для голоса и данных производилась с помощью протоколов LLDP или CDP. Конечно, телефонный аппарат может быть и вручную сконфигурирован на использование соответствующих номеров виртуальных сетей. Однако, что делать в ситуации, когда по какой-либо причине использование CDP/LLDP невозможно, а производить настройки телефонов вручную очень не хочется?! На помощь придёт DHCP!
Итак, полная конфигурация интерфейса коммутатора, с которой мы будем работать, представлена ниже.
interface GigabitEthernet1/0/1
description DHCP_voice_VLAN_test
switchport access vlan 2
switchport mode access
switchport voice vlan 3
load-interval 30
no cdp enable
no lldp transmit
no lldp receive
spanning-tree portfast edge
В нашем распоряжении был IP-телефон Avaya модели 9620L. Телефоны данного вендора могут получать информацию о номере голосового VLAN с помощью опций №176 или №242. Мы сконфигурировали DHCP-пулы для обеих подсетей, включив в них обе упомянутые опции. Сеть с данными: VLAN2 и подсеть 192.168.2.0/24. Голосовая сеть: VLAN3 и подсеть 192.168.3.0/24.
fox_switch#sho run | s pool
ip dhcp pool voice
network 192.168.3.0 255.255.255.0
default-router 192.168.3.1
dns-server 8.8.8.8
option 242 ascii "L2QVLAN=3,L2Q=1"
option 176 ascii "L2QVLAN=3,L2Q=1"
ip dhcp pool data
network 192.168.2.0 255.255.255.0
default-router 192.168.2.1
dns-server 8.8.8.8
option 242 ascii "L2QVLAN=3,L2Q=1"
option 176 ascii "L2QVLAN=3,L2Q=1"
С помощью L2Q=1 включается использование меток IEEE 802.1Q, тогда как параметр L2QVLAN позволяет задать номер виртуальной сети для голоса.
После того, как телефон полностью загрузился, он использует адрес из голосовой виртуальной сети, данные же с ПК помещаются в VLAN 2.
fox_switch#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type State Interface
Hardware address/
User name
192.168.3.6 3cb1.5b4b.9cc7 Jan 02 2000 06:31 AM Automatic Active Vlan3
Но что же произошло за сценой? Опишем весь процесс чуть подробнее.
- Телефон загружается и передаёт данные без тегирования, то есть в data-vlan.
- С помощью DHCP телефон получает основные сетевые параметры: IP-адрес, маску, шлюз, адрес DNS-сервера и так далее. Среди параметров передаётся также номер голосовой виртуальной сети.
- Телефон освобождает полученный ранее адрес, переинициализирует стек и получает IP-адрес уже в голосовом VLAN. В данный момент используются уже тегированные Ethernet-кадры.
Именно потому, что на третьем шаге происходит освобождение арендованного ранее адреса, мы видим лишь один выданный с помощью DHCP IP-адрес. Однако запись в ARP-таблице ещё будет сохраняться некоторое время.
fox_switch#sho ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.2.1 - 9c57.adb0.34c4 ARPA Vlan2
Internet 192.168.2.4 0 3cb1.5b4b.9cc7 ARPA Vlan2
Internet 192.168.3.1 - 9c57.adb0.34c5 ARPA Vlan3
Internet 192.168.3.6 0 3cb1.5b4b.9cc7 ARPA Vlan3
Также косвенным подтверждением наших слов является наличие записи о MAC-адресе телефона в обоих виртуальных сетях в таблице коммутации в течение времени Aging Time. Коммутаторы Cisco Catalyst по умолчанию сохраняют такую запись в течение пяти минут.
fox_switch#sho mac add int gi1/0/1
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
2 3cb1.5b4b.9cc7 DYNAMIC Gi1/0/1
3 3cb1.5b4b.9cc7 DYNAMIC Gi1/0/1
Total Mac Addresses for this criterion: 2
Мы решили предоставить лог работы DHCP-сервера, встроенного в наш коммутатор, в виде отдельного файла.
Такое поведение телефона необходимо обязательно учитывать, если проектируется какая-либо защита коммутатора на втором уровне, например, port-security.
DHCP и туннельные интерфейсы
Протокол DHCP может использоваться не только для назначения IP-адресов при Ethernet подключениях, но и в случае использования туннелей. Рассмотрим для начала туннели типа точка-точка на базе протоколов IPIP или GRE. Схема сети представлена ниже. Маршрутизатор R1 выполняет функции DHCP-сервера, а R3 – DHCP-клиента.
Со стороны DHCP-сервера или релея конфигурация стандартная.
R1#sho run | sec dhcp
ip dhcp pool fox
network 10.0.0.0 255.255.255.252
default-router 10.0.0.1
dns-server 8.8.8.8
R1#sho run int tu 0
Building configuration...
Current configuration : 145 bytes
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel mode ipip
tunnel destination 192.168.23.3
end
Настройки клиентской части также весьма просты.
R3#sho run int tunnel 0
Building configuration...
Current configuration : 127 bytes
!
interface Tunnel0
ip address dhcp
tunnel source GigabitEthernet1/0
tunnel mode ipip
tunnel destination 192.168.12.1
end
Перехват трафика внутри IPIP туннеля показывает вполне стандартные сообщения протокола DHCP. Для туннелей на базе GRE ситуация аналогичная.
Немного сложнее обстоит дело с туннелями на базе DMVPN. Если выполнить такую же настройку DHCP для интерфейсов, как и при обычном GRE/IPIP, то через туннель от клиента будут передаваться сообщения DHCP Discover, но ничего не будет возвращаться назад.
Со стороны DHCP-сервера появляются следующие отладочные сообщения (deb ip dhcp events). Маршрутизатор R1 выполняет функции hub, а R3 – spoke для DMVPN в топологии, представленной в начале данного раздела.
R1#
*Apr 17 18:10:00.059: DHCPD: Sending notification of DISCOVER:
*Apr 17 18:10:00.059: DHCPD: htype 1 chaddr ca03.3870.0006
*Apr 17 18:10:00.063: DHCPD: circuit id 00000000
*Apr 17 18:10:00.063: DHCPD: Seeing if there is an internally specified pool class:
*Apr 17 18:10:00.063: DHCPD: htype 1 chaddr ca03.3870.0006
*Apr 17 18:10:00.063: DHCPD: circuit id 00000000
*Apr 17 18:10:00.063: DHCPD: Found previous server binding
С точки зрения маршрутизатора R1, клиент получил адрес.
R1#sho ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
10.0.0.2 0063.6973.636f.2d63. Apr 17 2017 06:56 PM Automatic
6130.332e.3338.3730.
2e30.3030.362d.5475.
30
Однако, очевидно, что всё не совсем так с точки зрения клиента.
R3#sho ip int bri | i up
GigabitEthernet1/0 192.168.23.3 YES manual up up
Tunnel0 unassigned YES DHCP up up
Проблема кроется в том, что клиент выставляет флаг Broadcast в своих сообщения DHCP Discover. Для решения проблемы необходимо выполнить два действия: заставить клиента снимать флаг Broadcast (интерфейсная команда ip dhcp client broadcast-flag clear), а также заставить сервер отправлять все сообщения клиенту с помощью unicast сообщений (команда ip dhcp support tunnel unicast глобального режима).
Действие команды, снимающей флаг Broadcast, явно видно в сообщениях DHCP Discover.
Действие команды со стороны сервера, включающей поддержку отправки DHCP-сообщений в режиме unicast, тоже не заставит себя долго ждать: клиент получит адрес сразу после первого присланного запроса.
Таким образом, клиент может получать динамически адрес не только для своего NBMA-интерфейса, но и для туннельного также.
На это мы завершаем данный раздел и переходим к рассмотрению связи протокола DHCP и процессов маршрутизации.
DHCP и маршрутизация
В данном разделе мы решили затронуть вопросы, связанные с взаимодействием протокола DHCP и процессами построения таблицы маршрутизации. Начать мы решили с протоколов динамической маршрутизации (IGP).
Допустим, перед нами стоит задача в общем виде: требуется установить EIGRP соседство с устройствами, подключёнными к интерфейсуGi0/0 маршрутизатора R2, IP-адрес на котором конфигурируется динамически и диапазон адресов не известен.
В этом случае в настройках процесса маршрутизации EIGRP нужно выполнить три команды: отключить EIGRP на всех интерфейсах (passive-interface default), включить маршрутизацию для всех сетей (network 0.0.0.0), включить поддержку интерфейса Gi0/0 в EIGRP (no passive-interface GigabitEthernet0/0). Конфигурация маршрутизатора R1 типична, поэтому мы не приводим её здесь. Основные конфигурационные команды, введённые на маршрутизаторе R2 представлены ниже.
interface GigabitEthernet0/0
ip address dhcp
!
router eigrp 1
network 0.0.0.0
passive-interface default
no passive-interface GigabitEthernet0/0
После этого EIGRP-соседство с маршрутизатором R1 успешно устанавливается.
R2# sho ip eigrp interfaces
EIGRP-IPv4 Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 1 0/0 0/0 24 0/0 64 0
R2#sho ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.0.1 Gi0/0 13 00:05:10 24 144 0 3
Конфигурация протокола RIP аналогична и приведена ниже.
router rip
version 2
passive-interface default
no passive-interface GigabitEthernet0/0
network 0.0.0.0
no auto-summary
Протокол динамической маршрутизации OSPF может быть настроен аналогично EIGRP и RIP.
router ospf 1
passive-interface default
no passive-interface GigabitEthernet0/0
network 0.0.0.0 255.255.255.255 area 0
Однако из приведённого выше примера конфигурации протокола OSPF вытекает очевидное ограничение: если интерфейсов, на которых адрес назначается динамически, два или более, они все должны будут принадлежать одной зоне. К счастью для OSPF существует интерфейсная команда, позволяющая включить данный протокол на конкретном интерфейсе без указания IP-адреса, но с указанием номера зоны. Пример такой конфигурации представлен ниже, в нём все доступные интерфейсы добавляются в зону №1, тогда как Gi0/0 принадлежит магистральной зоне.
interface GigabitEthernet0/0
ip address dhcp
ip ospf 1 area 0
!
router ospf 1
router-id 2.2.2.2
network 0.0.0.0 255.255.255.255 area 1
Протокол динамической маршрутизации OSPF позволяет выяснить, какие интерфейсы и почему участвуют в маршрутизации, а также каким зонам они принадлежат. Для вывода указанной информации предназначена команда sho ip proto, пример работы которой представлен ниже.
R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 2.2.2.2
It is an area border and autonomous system boundary router
Redistributing External Routes from,
connected, includes subnets in redistribution
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
0.0.0.0 255.255.255.255 area 1
Routing on Interfaces Configured Explicitly (Area 0):
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
1.1.1.1 110 00:00:05
Distance: (default is 110)
Ещё одним локальным протоколом динамической маршрутизации, популярным в сетях крупных операторов связи, является ISIS. И хотя ISIS редок в корпоративных сетях, мы решили упомянуть и его, благо настройка данного IGP для работы с DHCP чрезвычайно проста и похожа на настройку OSPF. ISIS не поддерживает команду network для указания интерфейсов, на которых данный протокол будет работать. Вместо этого должна использоваться лишь интерфейсная команда. Пример настройки ISIS представлен ниже.
interface GigabitEthernet0/0
ip address dhcp
ip router isis
!
router isis
net 49.0001.0000.0000.0002.00
Также мы решили представить нашим читателям вывод нескольких диагностических команд.
R2#sho isis neighbors
System Id Type Interface IP Address State Holdtime Circuit Id
R1 L1 Gi0/0 192.168.0.1 UP 29 R2.01
R1 L2 Gi0/0 192.168.0.1 UP 23 R2.01
R2#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
i L2 1.1.1.1 [115/10] via 192.168.0.1, 00:07:05, GigabitEthernet0/0
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.2/32 is directly connected, GigabitEthernet0/0
R2#sho ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "isis"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Redistributing: connected, isis
Address Summarization:
None
Maximum path: 4
Routing for Networks:
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
192.168.0.1 115 00:06:56
Distance: (default is 115)
С динамической маршрутизацией, будем считать, разобрались, однако остаются не менее интересные вопросы, связанные со статической маршрутизацией.
Во-первых, может потребоваться передать клиенту по протоколу DHCP не только маршрут по умолчанию, но и другие статические маршруты. Маршрут по умолчанию (опция №3) можно передать с помощью команды default-router в режиме конфигурации DHCP пула. Статические маршруты передаются с помощью опции №33, запрашиваемой клиентом. Мы собрали небольшую схему, чтобы проиллюстрировать работу данных опций.
Маршрутизаторы R1 и R2 имеют статическую конфигурацию интерфейсов. На интерфейсах Gi0/0 настроены адреса 192.168.0.1/24 и 192.168.0.2/24. Также на этих маршрутизаторах настроены интерфейсы loopback 0 с адресами 1.1.1.1/32 и 2.2.2.2/32. Маршрутизатор R3 получает IP-параметры динамически с помощью интерфейсной команды ip addr dhcp. Настройки DHCP на маршрутизаторе R1 представлены ниже. С помощью опции №33 передаются статические маршруты.
ip dhcp excluded-address 192.168.0.1 192.168.0.100
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
dns-server 8.8.8.8
default-router 192.168.0.1
option 33 ip 2.2.2.2 192.168.0.2
Естественно, мы не могли не убедиться в том, что маршрутизатор R3 успешно получил все необходимые параметры.
R3#sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.0.101 YES DHCP up up
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.0.1 to network 0.0.0.0
S* 0.0.0.0/0 [254/0] via 192.168.0.1
2.0.0.0/32 is subnetted, 1 subnets
S 2.2.2.2 [254/0] via 192.168.0.2
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.101/32 is directly connected, GigabitEthernet0/0
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms
Весь обмен трафиком мы сохранили в дампе foxnetwork_8.pcapng.
Использование опции №33 чрезвычайно простое, однако с данной опцией невозможно передать маршрут с маской отличной от /32. Выполнить передачу маршрута с произвольной маской DHCP клиенту, расположенному на маршрутизаторе Cisco, можно с помощью опции №121, правда, правило её формирования чуть сложнее. Все числа записываются в шестнадцатеричном виде. Первый октет содержит длину маски. Дальше содержатся значащие октеты адреса сети назначения, после которых указывается адрес следующего маршрутизатора. Если требуется передать несколько маршрутов одновременно, все они записываются последовательно друг за другом без пробелов. Разберём сказанное выше на примере. Допустим, мы используем предыдущую схему сети и хотим передать следующие маршруты: 1.1.1.1/32 через 192.168.0.1 и 2.2.2.0/23 через 192.168.0.2. Первый маршрут содержит четыре значащих октета сети, второй – три. Поэтому записи указанных маршрутов в шестнадцатеричном виде будут такими: 2001010101C0A80001 и 17020202C0A80002, где 20 и 17 – длины масок в шестнадцатеричном виде, 01010101 и 020202 – шестнадцатеричная запись значащих октетов адреса сети, а C0A80001 и C0A80002 – адреса маршрутизаторов. Пример обновлённой конфигурации DHCP пула маршрутизатора R1 представлен ниже.
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
dns-server 8.8.8.8
option 121 hex 2001.0101.01c0.a800.0117.0202.02c0.a800.02
Однако указанных команд недостаточно. По умолчанию DHCP-клиент на базе Cisco IOS не запрашивает у сервера опцию №121. Заставить клиента запрашивать данную опцию можно с помощью интерфейсной команды ip dhcp client request classless-static-route, выполняемой на клиенте. Убедимся в работоспособности представленной конфигурации.
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int gi0/0
R3(config-if)# ip dhcp client request classless-static-route
R3(config-if)#ip add dhcp
R3(config-if)#^Z
R3#
*Aug 16 04:23:03.179: %SYS-5-CONFIG_I: Configured from console by console
*Aug 16 04:23:04.467: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.0.106, mask 255.255.255.0, hostname R3
R3#sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.0.106 YES DHCP up up
R3#sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [254/0] via 192.168.0.1
2.0.0.0/23 is subnetted, 1 subnets
S 2.2.2.0 [254/0] via 192.168.0.2
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet0/0
L 192.168.0.106/32 is directly connected, GigabitEthernet0/0
R3#ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/17/20 ms
R3#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/15/20 ms
R3#
Перехват процесса обмена трафиком между тремя маршрутизаторами представлен в файле foxnetwork_9.pcapng.
Передача статических маршрутов DHCP клиентам, выполняющихся на других операционных системах может производится с помощью других опций, однако в любом случае любая опция – всего лишь hex-строка, то есть DHCP сервер на базе маршрутизаторов Cisco может быть сконфигурирован на передачу маршрутной информации клиентам и на других операционных системах тоже.
Также стоит отметить, что получаемые по DHCP маршруты, могут быть переданы в любой протокол динамической маршрутизации с помощью команды redistribute static (или redistribute static subnets при использовании OSPF).
По умолчанию DHCP клиент на базе Cisco IOS запрашивает целый набор опций, в число которых, например, входит маршрут по умолчанию (опция №3). Отучить маршрутизатор от запроса некоторых опций можно с помощью соответствующих интерфейсных команд.
R3(config-if)#no ip dhcp client request ?
classless-static-route Classless static route (121)
dns-nameserver DNS nameserver (6)
domain-name Domain name (15)
netbios-nameserver NETBIOS nameserver (44)
router Default router option (3)
sip-server-address SIP server address (120)
static-route Static route option (33)
tftp-server-address TFTP server address (150)
vendor-identifying-specific Vendor identifying specific info (125)
vendor-specific Vendor specific option (43)
<cr>
На картинках ниже показаны сообщения DHCP discover и DHCP offer от маршрутизаторов R3 и R1, на котором в режиме конфигурации DHCP пула была введена команда default-router. На интерфейсе Gi0/0 маршрутизатора R3 мы предварительно выполнили команду no ip dhcp client request router.
Как видно из двух представленных выше DHCP сообщений, маршрутизатор R3 не запрашивает опцию №3, а R1 не отправляет её клиенту. DHCP сообщения, которыми обменивались маршрутизаторы R1 и R3 представлены в файле foxnetwork_10.pcapng.
Наш внимательный читатель уже, наверняка, обратил внимание на то, с каким значением административной дистанции в таблице маршрутизации появлялся маршрут по умолчанию, получаемый по протоколу DHCP – 254. Такое значение AD говорит о том, что практически любой статически сконфигурированный маршрут или маршрут, полученный с помощью любого IGP или даже BGP, окажется приоритетнее того, который был получен с помощью DHCP. Изменить дистанцию маршрута по умолчанию, получаемого с помощью DHCP можно командой ip dhcp-client default-router distance из режима глобальной конфигурации. Данная команда влияет лишь на вновь получаемый маршрут, оставляя неизменным тот, что уже находится в таблице маршрутизации. Если же маршрутизатор динамически получает маршрут по умолчанию через два или большее количество интерфейсов, то изменить предпочтения можно с помощью интерфейсной команды ip dhcp client default-router distance, влияющей только на маршрут по умолчанию, получаемый через определённый интерфейс. Проиллюстрируем всё вышесказанное на примере небольшой сети. Маршрутизаторы R1 и R3 настроены как DHCP серверы, тогда как R2 выполняет функции DHCP клиента.
На маршрутизаторе R1 введена следующая конфигурация.
interface GigabitEthernet0/0
ip address 192.168.12.1 255.255.255.0
ip dhcp pool test
network 192.168.12.0 255.255.255.0
default-router 192.168.12.1
Конфигурация R3 практически идентична.
interface GigabitEthernet0/0
ip address 192.168.23.3 255.255.255.0
ip dhcp pool test
network 192.168.23.0 255.255.255.0
default-router 192.168.23.3
Рассмотрим процесс получения IP-параметров маршрутизатором R2, во время которого мы сначала получаем IP-адрес от маршрутизатора R1, затем меняем административную дистанцию глобально, повторно запрашиваем IP-параметры, меняем административную дистанцию для интерфейса Gi1/0 и запрашиваем IP-адрес и маршрут по умолчанию у маршрутизатора R3.
R2#sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 unassigned YES unset up up
GigabitEthernet1/0 unassigned YES unset up up
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int gi0/0
R2(config-if)#ip add dh
*Aug 16 08:05:21.255: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.6, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.12.6 YES DHCP up up
GigabitEthernet1/0 unassigned YES unset up up
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S* 0.0.0.0/0 [254/0] via 192.168.12.1
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/0
L 192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config-if)#exi
R2(config)#ip dhcp-client default-router distance 10
R2(config)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S* 0.0.0.0/0 [254/0] via 192.168.12.1
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/0
L 192.168.12.6/32 is directly connected, GigabitEthernet0/0
R2(config)#int gi0/0
R2(config-if)#no ip add dh
R2(config-if)#ip add dh
*Aug 16 08:06:23.807: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 192.168.12.7, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.12.7 YES DHCP up up
GigabitEthernet1/0 unassigned YES unset up up
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.12.1 to network 0.0.0.0
S* 0.0.0.0/0 [10/0] via 192.168.12.1
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/0
L 192.168.12.7/32 is directly connected, GigabitEthernet0/0
R2(config-if)#int gi1/0
R2(config-if)#ip dhcp client default-router distance 5
R2(config-if)#ip add dh
*Aug 16 08:07:00.471: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet1/0 assigned DHCP address 192.168.23.1, mask 255.255.255.0, hostname R2
R2(config-if)#do sho ip int bri
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES unset administratively down down
GigabitEthernet0/0 192.168.12.7 YES DHCP up up
GigabitEthernet1/0 192.168.23.1 YES DHCP up up
R2(config-if)#do sho ip ro
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 192.168.23.3 to network 0.0.0.0
S* 0.0.0.0/0 [5/0] via 192.168.23.3
192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/0
L 192.168.12.7/32 is directly connected, GigabitEthernet0/0
192.168.23.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.23.0/24 is directly connected, GigabitEthernet1/0
L 192.168.23.1/32 is directly connected, GigabitEthernet1/0
Ещё, пожалуй, стоит отметить, что администратор может вручную удалить или восстановить те или иные маршруты, полученные при помощи DHCP, из таблицы маршрутизации. Восстановить, естественно, можно лишь те маршруты, которые DHCP сервер реально объявлял в сообщении DHCP offer. Правда, восстановление происходит с административной дистанцией обычного статического маршрута, если не указать значение AD дополнительно. Также введённая команда ip route попадёт в текущую и/или загрузочную конфигурацию маршрутизатора.
Подключение к провайдеру с использованием динамически конфигурируемого IP-адреса позволяет обеспечить доступ к глобальной сети узлам, расположенным в пользовательской сети, с помощью NAT/PAT. Рассмотрим сеть, представленную на схеме ниже.
Маршрутизатор R1 принадлежит провайдеру и выполняет функции DHCP сервера для сети 192.168.0.0/24. Пользовательский маршрутизатор R2 интерфейсом Gi0/0 подключён к провайдеру, а интерфейсом Gi1/0 – к локальной сети пользователя 192.168.1.0/24. Естественно, маршрутизатор R1 не имеет маршрутов к внутренней клиентской сети. Настройка маршрутизатора R1 чрезвычайно простая и представлена ниже.
ip dhcp pool foxnetwork
network 192.168.0.0 255.255.255.0
default-router 192.168.0.1
interface Loopback0
ip address 1.1.1.1 255.255.255.0
interface GigabitEthernet0/0
ip address 192.168.0.1 255.255.255.0
Конфигурация узла PC1 также предельно проста.
PC1> sho ip
NAME : PC1[1]
IP/MASK : 192.168.1.2/24
GATEWAY : 192.168.1.1
DNS :
MAC : 00:50:79:66:68:00
LPORT : 10003
RHOST:PORT : 192.168.56.1:10002
MTU: : 1500
Единственное, что осталось, - настроить маршрутизатор R2. Первое, с чего мы начнём, - создадим список доступа, отбирающий IP-адреса, для которых будет производиться трансляция. Затем нужно указать IP-адреса на интерфейсах Gi0/0 и Gi1/0, указать внутренний и внешний интерфейс для NAT, а также создать саму трансляцию. При создании трансляции требуется указывать ключевое слово overload, заставляющее маршрутизатор выполнять PAT трансляцию. Пример конфигурации маршрутизатора R2 представлен ниже.
interface GigabitEthernet0/0
ip address dhcp
ip nat outside
ip virtual-reassembly in
interface GigabitEthernet1/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip virtual-reassembly in
ip nat inside source list PAT interface GigabitEthernet0/0 overload
ip access-list extended PAT
permit ip 192.168.1.0 0.0.0.255 any
Убедимся в корректности конфигурации с помощью узла PC1.
PC1> ping 1.1.1.1
84 bytes from 1.1.1.1 icmp_seq=1 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=2 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=3 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=4 ttl=254 time=29.002 ms
84 bytes from 1.1.1.1 icmp_seq=5 ttl=254 time=29.002 ms
Проверим то же самое, включив вывод отладочной информации на маршрутизаторе R1. Естественно, мы не рекомендуем включать отладку в высоконагруженных сетях.
R1#deb ip icmp
ICMP packet debugging is on
R1#
*Aug 16 19:58:21.931: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:22.959: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:23.975: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:25.003: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
*Aug 16 19:58:26.035: ICMP: echo reply sent, src 1.1.1.1, dst 192.168.0.2, topology BASE, dscp 0 topoid 0
При проверке на маршрутизаторе R2 создаются следующие трансляции.
R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.0.2:16835 192.168.1.2:16835 1.1.1.1:16835 1.1.1.1:16835
icmp 192.168.0.2:17091 192.168.1.2:17091 1.1.1.1:17091 1.1.1.1:17091
icmp 192.168.0.2:17347 192.168.1.2:17347 1.1.1.1:17347 1.1.1.1:17347
icmp 192.168.0.2:17859 192.168.1.2:17859 1.1.1.1:17859 1.1.1.1:17859
icmp 192.168.0.2:18115 192.168.1.2:18115 1.1.1.1:18115 1.1.1.1:18115
Конечно же, убедиться в корректности выполненных настроек можно было с помощью сетевого анализатора Wireshark, анализируя проходящие пакеты.
На этом мы завершаем раздел, описывающий взаимное влияние протокола DHCP и маршрутизации и переходим к подведению итогов.
Заключение
В данной статье мы попытались достаточно детально описать возможности и примеры использования протокола DHCP. Мы не ставили перед собой цели рассмотреть абсолютно все возможности всех реализаций и платформ, вместо этого мы решили познакомить наших читателей с наиболее часто используемыми опциями и функциями. Так, например, мы умышленно опустили вопросы, связанные с использованием DHCP на ATM-интерфейсах, так как наивно полагаем, что время повсеместного внедрения ATM уже давно позади.
Несмотря на то, что практически все конфиги приведены для оборудования компании Cisco, мы надеемся, что администраторы, в чьём ведении находится оборудование других производителей, смогут также найти в этой статье много интересного.
Комментарии
RSS лента комментариев этой записи