Cisco не работает ip helper

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Устранение неисправностей DHCP на Cisco

Часть 2. Dynamic Host Configuration Protocol

В этой части мы рассмотрим проблемы DHCP.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Урок 1

Вот новый сценарий, позвольте мне сначала объяснить его:

• Зеленая зона — это наша локальная сеть, так что это наш NAT inside.
• Красная область — это Интернет, поэтому это наш NAT outside.
• Предполагается, что хост — это компьютер с шлюзом по умолчанию 192.168.12.2.
• Наш маршрутизатор NAT подключен к маршрутизатору ISP.
• Маршрутизатор ISP назначил нам подсеть 172.16.1.0 / 24, которую мы собираемся использовать для трансляции NAT.
• BGP был настроен между NAT и маршрутизатором ISP для доступа к сети 192.168.34.0/24.
• Предполагается, что веб-сервер прослушивает TCP-порт 80 и использует 192.168.34.3 в качестве шлюза по умолчанию.

Однако пользователи нашей локальной сети жалуются на то, что не могут подключиться к веб-серверу. Давайте проверим нашу конфигурацию NAT:

Мы можем убедиться, что трансляция работает:

• Inside local IP-адрес нашего хоста.
• Inside global находится один из IP-адресов из нашей подсети 172.16.1.0/24.
• Outside local and global IP-адрес нашего веб-сервера

Эта трансляция выглядит хорошо, потому что все IP-адреса верные.

Мы видим, что маршрутизатор NAT научился достигать сети 192.168.34.0 / 24 через BGP.

Наш NAT-маршрутизатор может подключаться к веб-серверу, поэтому проблема с подключением отсутствует. Однако следует помнить одну важную вещь. Пакет IP, который производит маршрутизатор NAT, выглядит следующим образом:

IP-адрес получателя является нашим веб-сервером, и с ним нет проблем. Исходный IP-адрес — 192.168.23.2, и поскольку мы получили ответ, мы знаем, что маршрутизатор ISP знает, как достичь подсети 192.168.23.0 / 24. Это важно, поскольку подсеть 192.168.23.0 / 24 напрямую подключена к маршрутизатору ISP.

Однако, если мы отправляем эхо-запрос с хост-устройства, он преобразуется из-за NAT в IP-адрес в подсети 172.16.1.0/24. Пакет IP будет выглядеть так:

Вот что происходит, когда этот IP-пакет покидает маршрутизатор NAT и отправляется маршрутизатору ISP:

1. Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
2. Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
3. Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
4. Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
5. Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
6. Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.

Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!

Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.

Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.

Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to. it является не маршрутизируемым и будет отброшен.

Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:

Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.

Пинг прошел проблема решена!

Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.

Урок 2

Начнем с простого сценария. Маршрутизатор с левой стороны — это наш DHCP-клиент, а маршрутизатор с правой стороны — это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов . что может быть не так?

Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.

Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо.

Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail , чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.

Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.

Мы будем использовать команду show ip dhcp pool , чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем «MYPOOL», и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.

Мы можем использовать команду show ip dhcp server statistics , чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает . что это может значить?

Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты . если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.

Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.

Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP . проблема решена!

Итог урока: если все в порядке, убедитесь, что служба DHCP работает.

Урок 3

Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP

Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief .

Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.

Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит.

Включим отладку, чтобы увидеть, что происходит.

Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?

Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.

Чтобы доказать это, мы можем включить отладку

Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.

Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.

Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.

Если вы оставили » debug ip dhcp server packet» включенным, вы увидите весь процесс DHCP:

1. DHCP Discover
2. DHCP Offer
3. DHCP Request
4. DHCP ACK

Вот и все . проблема решена!

Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.

Полный курс по Сетевым Технологиям

В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Особенности работы и настройки DHCP на маршрутизаторах Cisco (Часть 2)

1. Конфигурация

В качестве примера возьмем следующую схему:

На маршрутизаторе R3 расположен DHCP-сервер, который централизованно выдает адреса в сети LAN_1 и LAN_2. Маршрутизаторы R1 и R2 в данной схеме являются DHCP-Relay агентами

Сконфигурируем на R3 два пула адресов для каждой локальной сети:

!в режиме глобальной конфигурации определим адреса, которые будут исключены из пула (это адреса интерфейсов R1 и R2
ip dhcp excluded-address 192.168.1.1
ip dhcp excluded-address 192.168.2.1
!создадим пул адресов с именем LAN_1
ip dhcp pool LAN1
network 192.168.1.0 255.255.255.0
ip default-router 192.168.1.1
!создадим пул адресов с именем LAN_2
ip dhcp pool LAN2
network 192.168.2.0 255.255.255.0
ip default-router 192.168.2.1

Естественно, при необходимости можно добавить в пул дополнительные опции.

Следующий этап — конфигурация агентов DHCP-Relay на маршрутизаторах R1 и R2. Суть DHCP-Relay заключается в пересылке широковещательного пакета от клиента одноадресатным пакетом DHCP-серверу.

Конфигурация агентов выполняется следующей командой:

!выбираем интерфейс, на который будет приходить широковещательный запрос от клиентов, в данном случае это интерфейс f0/0 маршрутизатора, который подключен к сегменту сети
interface fa0/0
ip helper-address 10.1.1.2

no ip forward-protocol udp 37
no ip forward-protocol udp 53

2. Как это работает?

Клиент шлет стандартный DISCOVERY:

который пересылается Relay-агентом в направлении DHCP-сервера (измененные поля отмечены красным):

Как видно из картинки, сообщение теперь пересылается одноадресным пакетом с источником 192.168.1.1 (интерфейс маршрутизатора, на который был получен широковещательный пакет) и получателем 10.1.1.2 (адрес, который указан командой ip helper-address. Кроме того, адрес 192.168.1.1 указан в поле Relay agent IP address

На основании адреса источника сообщения DHCP-сервер определяет, из какого пула выдавать адреса. Для маршрутизатора R2 запрос пойдет с адресом источника 192.168.2.1 и сервер выдаст адрес из пула LAN_2.

Предложение OFFER от R3 к R1 выглядит следующим образом:

R1 пересылает его клиенту меняя только адреса источника на 192.168.1.1 и получателя на 192.168.1.2 (ссылка на скриншот)

Вот таким образом выглядит обмен сообщениями между клиентом, агентом и сервером:

3. Заключение

Для правильной работы данного примера важно учесть следующий момент: маршрутизатор R3 получает пакеты от R1 с адресом источника 192.168.1.1, поэтому на R3 сеть 192.168.1.0 должна быть в таблице маршрутизации, я настроил EIGRP между маршрутизаторами для решения этой проблемы. Смотрим таблицу:

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets
C 10.1.2.0 is directly connected, FastEthernet0/0
C 10.1.1.0 is directly connected, FastEthernet0/1
D 192.168.1.0/24 [90/307200] via 10.1.1.1, 00:00:16, FastEthernet0/1
D 192.168.2.0/24 [90/307200] via 10.1.2.1, 00:02:17, FastEthernet0/0

Источник