По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитатей первую часть статьи про траблшутинг NAT/PAT на Cisco.
В этой части мы рассмотрим проблемы DHCP.
Урок 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:
Маршрутизатор ISP получает IP-пакет и проверяет свою таблицу маршрутизации, знает ли он, куда отправлять трафик для сети 192.168.34.0 / 24.
Сеть 192.168.34.0/24 напрямую подключена к маршрутизатору ISP, поэтому она выполняет запрос ARP для MAC-адреса веб-сервера, получает ответ ARP и может пересылать IP-пакет на веб-сервер.
Веб-сервер хочет ответить, и он создает новый IP-пакет с IP-адресом назначения 172.16.1.
Поскольку веб-сервер имеет маршрутизатор ISP в качестве шлюза по умолчанию, он отправит IP-пакет маршрутизатору ISP.
Маршрутизатор ISP должен выполнить поиск в таблице маршрутизации, чтобы узнать, знает ли он, где находится сеть 172.16.1.0 / 24.
Маршрутизатор ISP не знает, где находится 172.16.1.0 / 24, и отбросит IP-пакет.
Если бы это была настоящая производственная сеть, у нас не было бы доступа к маршрутизатору ISP. Так как это эмуляция сети и устройств, к которой у нас есть доступ, поэтому давайте сделаем отладку!
ISP#debug ip packet 1
IP packet debugging is on for access list 1
ISP#conf t
ISP(config)#access-list 1 permit host 192.168.34.4
Сначала включим отладку IP-пакетов и используем список доступа, который соответствует IP-адресу веб-сервера.
Следующим шагом является то, что мы будем генерировать некоторый трафик с хост-устройства.
Это то, что будет производить маршрутизатор ISP. Он говорит нам, что понятия не имеет, куда отправить IP-пакет для 172.16.1.1 to...it является не маршрутизируемым и будет отброшен.
Так как же мы решим эту проблему? ISP-маршрутизатор требует сеть 172.16.1.0 /24 в таблице маршрутизации. Поскольку мы уже запустили BGP мы можем использовать его для объявления этой сети с нашего маршрутизатора NAT:
NAT(config)#ip route 172.16.1.0 255.255.255.0 null 0
NAT(config)#router bgp 1
NAT(config-router)#network 172.16.1.0 mask 255.255.255.0
Сначала мы создадим статическое правило, которое указывает сеть 172.16.1.0 / 24 на интерфейс null0. Мы делаю это потому, что невозможно объявлять то, чего у тебя нет. Следующий шаг-объявить эту сеть в BGP.
Пинг прошел проблема решена!
Итог урока: убедитесь, что ваши маршрутизаторы знают, как связаться с translated сетями.
Урок 2
Начнем с простого сценария. Маршрутизатор с левой стороны - это наш DHCP-клиент, а маршрутизатор с правой стороны - это наш DHCP-сервер. Клиент, однако, не получает никаких IP-адресов ... что может быть не так?
Сначала мы проверим, включен ли интерфейс на клиенте DHCP и настроен ли он для DHCP. И это действительно так.
Мы также должны убедиться, что интерфейс на сервере DHCP включен/включен и что у него есть IP-адрес. Пока все выглядит хорошо...
Если мы хотим быть абсолютно уверенным, что проблема не в клиенте, нам надо применить отладку командой debug dhcp detail, чтобы посмотреть, отправляет ли клиент DHCP сообщения об обнаружении DHCP.
Мы видим некоторые отладочные выходные данные, как показано выше. Это говорит о том, что наш DHCP-клиент отправляет сообщения DHCP Discover. Клиент, скорее всего, не является источником этой проблемы.
DHCPServer#show ip dhcp pool
Мы будем использовать команду show ip dhcp pool, чтобы проверить, существует ли пул DHCP. Вы видите, что у нас есть пул DHCP с именем "MYPOOL", и он настроен для подсети 192.168.12.0 / 24. Пока все выглядит хорошо.
Мы можем использовать команду show ip dhcp server statistics, чтобы узнать, что делает сервер DHCP. Вы видите, что он ничего не делает ... что это может значить?
Эта команда не часто применяется. show ip sockets показывает нам, на каких портах роутер слушает. Как вы видите, он не прослушивает никакие порты ... если мы не видим здесь порт 67 (DHCP), это означает, что служба DHCP отключена.
DHCPServer(config)#service dhcp
Включим сервис.
Так-то лучше! Теперь мы видим, что маршрутизатор прослушивает порт 67, это означает, что служба DHCP активна.
Как только служба DHCP будет запущена, вы увидите, что клиент получает IP-адрес через DHCP ... проблема решена!
Итог урока: если все в порядке, убедитесь, что служба DHCP работает.
Урок 3
Взгляните на сценарий выше. У нас есть 3 маршрутизатора; маршрутизатор на левой стороне настроен как DHCP-клиент для своего интерфейса FastEthernet0/0. Маршрутизатор с правой стороны настроен как DHCP-сервер. Помните, что DHCP-сообщения об обнаружении от клиентов транслируются, а не пересылаются маршрутизаторами. Вот почему нам требуется команда ip helper на маршрутизаторе в середине, именуемым как relay. Проблема в этом сценарии заключается в том, что клиент не получает IP-адреса через DHCP
Сначала мы проверим, что интерфейс настроен для DHCP. Мы определим это с помощью команды show ip interface brief.
DHCPClient(config)#interface fastEthernet 0/0
DHCPClient(config-if)#shutdown
DHCPClient(config-if)#no shutdown
Мы будем переводить интерфейс в режимы up и down для проверки, будет ли он отправлять сообщение DHCP Discover.
Мы видим, что сообщения DHCP Discover принимаются на DHCP-сервере. Это означает, что маршрутизатор в середине был настроен с IP helper, в противном случае мы даже не получили бы эти сообщения. Сообщения с предложениями DHCP отправлены, но мы не видим сообщений DHCPACK (Acknowledgment). Это дает нам понять, что что-то происходит...
DHCPServer#debug ip dhcp server packet
Включим отладку, чтобы увидеть, что происходит.
Мы видим, что наш DHCP-сервер пытается достичь IP-адреса 192.168.12.2, это интерфейс FastEthernet0/0 нашего маршрутизатора в середине. Знает ли DHCP-сервер, как добраться до этого IP-адреса?
Как вы можете видеть, его нет в таблице маршрутизации, это означает, что IP-пакеты с назначением 192.168.12.2 будут отброшены.
Чтобы доказать это, мы можем включить отладку
Здесь видим, что IP-адрес назначения 192.168.12.2 не является маршрутизируемым, и в результате IP-пакет будет отброшен. Давайте исправим эту проблему.
DHCPServer(config)#ip route 192.168.12.0 255.255.255.0 192.168.23.2
Мы добавим этот статический маршрут, чтобы исправить нашу проблему с подключением.
Через некоторое время вы должны увидеть, что клиент получает IP-адрес через DHCP.
Если вы оставили "debug ip dhcp server packet" включенным, вы увидите весь процесс DHCP:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACK
Вот и все ... проблема решена!
Итог урока: если вы используете IP helper, убедитесь, что DHCP-сервер знает, как связаться с подсетью, в которой находится клиент.
3 часть статьи про FHRP траблшутинг на Cisco доступна по ссылке.
Допустим, Вы решили обзавестись IP телефонией для своего офиса. Вы закупили необходимое количество телефонов, настроили voice VLAN, DHCP, TFTP серверы и определились с номерным планом. Однако, прежде чем Ваш IP Phone зазвонит, ему еще предстоит пройти процедуру загрузки, так называемый Bootup или Startup process, которому и будет посвящена данная статья.
В качестве примера будет рассмотрен процесс загрузки Cisco IP Phone под управлением Cisco CallManager. Понимание данного процесса даст более полное представление о работе телефонов Cisco и IP телефонии в целом, а также поможет в оперативном траблшутинге неисправностей.
Итак, пусть имеется некая сеть, содержащая: сервер с Cisco CallManager, сервер DHCP, сервер TFTP, коммутатор с поддержкой PoE (Power over Ethernet) и Cisco IP Phone, как показано на рисунке ниже.
Допустим, что наш коммутатор и телефон поддерживают протокол PoE. Тогда, сразу после того, как телефон будет подключен к одному из Ethernet портов, коммутатор отреагирует специальным сигналом FLP (Fast Link Pulse), который определяет, имеет ли подключенное устройство питание.
Возвращение FLP в форме петли (loopback) на порт коммутатора, к которому недавно было подключено новое устройство, сигнализирует о том, что на данный порт необходимо незамедлительно подать питание. Таким образом, IP Phone по протоколу PoE 802.3af получает питание в 48 Вольт.
Cisco IP Phone имеет встроенную, энергонезависимую Flash-память, в которой хранится образ прошивки и начальные пользовательские настройки. В процессе начальной загрузки телефон, загружая из Flash-памяти образ прошивки, инициализирует своё программное обеспечение и аппаратные средства.
Как только телефон получил питание и прошел POST (Power-on self-test) для проверки базовой функциональности, коммутатор, по проприетарному протоколу CDP (Cisco Discovery Protocol), отправляет на телефон информацию о том, какой voice VLAN необходимо использовать.
Затем, IP Phone отправляет на широковещательный адрес 255.255.255.255 запрос DHCPDISCOVER, в свою очередь DHCP сервер возвращает ответ DHCPOFFER, который содержит следующую информацию:
Свободный IP адрес
Маска подсети
Адрес шлюза по умолчанию (Default Gateway)
Адрес DNS (Domain Name System) сервера. (опционально)
Адрес TFTP (Trivial File Transfer Protocol) сервера, на котором хранится файл конфигурации для телефонов.
Адрес TFTP сервера задается при конфигурировании DHCP по средствам, так называемой опции 150 (option 150). Синтаксис команды приведен ниже:
option 150 ip 'TFTP server IP address'
После того как телефон с помощью option 150 получил адрес TFTP сервера, он скачивает конфигурационный файл, содержащий параметры для подключения к CallManager.
Если телефон был зарегистрирован на CallManager’е вручную, то он начинает проверять файл .cnf.xml, который определяет какую версию программного обеспечения должны использовать все телефоны, зарегистрированные в данном CallManager’е. Если обнаруживается, что загруженный образ не соответствует общепринятому, то телефон вновь обращается на TFTP сервер для получения корректного образа, хранящегося там в формате .bin.
После обращения к TFTP, загрузив новый образ, телефон инициирует установление TCP соединения с CallManager’ом. Данное соединение открывает возможность использования функционала Cisco IP Phone в полной степени.
Как видите, с того момента как наш IP Phone был подключен в один из портов коммутатора и до того момента, когда мы можем совершать звонки, он проходит еще множество всевозможных этапов загрузки, большинство из которых, конечный пользователь даже не заметит.
В этой статье рассмотрим как решить следующие неисправности:
Вам не удаётся включить виртуальную машину
При включении виртуальной машины происходит сбой
Вы видите ошибку:
An unexpected error was received from the ESX host while powering on VM .
Reason: Cannot open the disk disk_name or one of the snapshot disks it depends on.
Где причина одна из следующего:
Reason: Failed to lock the file.
Reason: The parent virtual disk has been modified since the child was created.
Reason: The destination file system does not support large files.
Reason: Could not open/create change tracking file.
Reason: Cannot allocate memory.
Reason: The file specified is not a virtual disk.
Reason: Insufficient permission to access file.
Решение
Ошибка №1: не удалось заблокировать файл.
Ошибка «не удалось заблокировать файл» означает, что файл открывается другим процессом и используемый Вами процесс не может открыть файл должным образом.
Это обычно происходит, если Вы:
Пытаетесь запустить вторую виртуальную машину, используя тот же .vmx файл конфигурации виртуальной машины.
Включаете виртуальную машину с подключенными дисками с помощью утилиты vmware-mount.
Пытаетесь включить виртуальную машину через пользовательский интерфейс во время операции снимка.
Пытаетесь добавить виртуальный диск к виртуальной машине, которая уже используется.
Ошибка №2: Родительский виртуальный диск был изменен с момента создания дочернего диска
Данная ошибка возникает, когда снимки находятся в плохом состоянии, либо из-за ручного вмешательства, либо из-за сбоя системы.
Ошибка №3: целевая файловая система не поддерживает большие файлы
Данная проблема возникает, если размер блока целевого хранилища данных не поддерживает VMDK такого же размера, как исходный.
Чтобы устранить данную проблему, убедитесь, что целевое хранилище данных отформатировано с размером блока, достаточным для поддержки файла VMDK исходной машины.
Ошибка №4: не удалось открыть или создать файл отслеживания изменений
Эта проблема может возникнуть, если файл filename-ctk.vmdk был создан ранее и не был очищен.
Ошибка №5: не удается выделить память
Данная проблема может возникнуть, если в модуле VMFS не хватает места в куче.
Ошибка №6: указанный файл не является виртуальным диском
Данная проблема может возникнуть, если файл дескриптора .vmdk поврежден или отсутствует. Чтобы решить данную проблему, создайте новый файл дескриптора .vmdk для этого диска, а затем отмените регистрацию и заново зарегистрируйте виртуальную машину. Это гарантирует, что клиент vSphere определит правильный размер диска и виртуальная машина включится правильно.
Ошибка №7: недостаточно прав для доступа к файлу
Данная проблема обычно наблюдается в виртуальных машинах, расположенных на хранилищах данных NFS. Данная проблема может возникнуть из-за проблем с разрешениями в хранилище данных NFS.
Чтобы решить данную проблему, убедитесь, что хост имеет правильные разрешения на чтение / запись для доступа к экспорту NFS. Если в массиве хранения установлен параметр "Нет корневого квадрата" (No Root Squash), убедитесь, что данная опция включена, или обратитесь к администратору хранилища.