пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
VoIP
How to
Статусные сообщения на IP телефонах Cisco
Всем привет! На IP-телефонах Cisco, которые зарегистрированы на Cisco Unified Communications Manager (CUCM) , можно просматривать статусные сообщения о состоянии телефона и сетевую статистику в реальном времени. Эта информация доступна с самого телефона и может быть полезна при траблшутинге системы. /p> Для доступа к статусным сообщениям нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и затем нажать Status Messages (Сообщения о состоянии). Сообщение отображается вместе со временем его появления. Сообщение Описание BootP server used Информационное сообщение, телефон получил IP адрес через BootP сервер, а не через DHCP сервер File auth error Произошла ошибка, когда телефон пытался проверить подписанный файл. Это сообщение содержит имя файла, с которым возникла проблема. Вероятная проблема – файл поврежден, необходимо удалить и добавить заново телефон через Cisco Unified Communications Manager Administration tool. Либо это проблема с CTL файлом и в этом случае нужно запустить CTL клиент и обновить CTL файл, убедившись, что в него включены необходимые TFTP серверы. CFG file not found Именной файл конфигурации и файл конфигурации по умолчанию не был найден на TFTP сервере. Файл конфигурации для определенного телефона создается при добавлении телефона в базу данных CUCM. Если телефон не был добавлен в базу данных, то TFTP-сервер генерирует ответ CFG File Not Found. CFG TFTP Size Error Конфигурационный файл слишком большой для файловой системы телефона. Нужно перезагрузить телефон. Checksum Error Скачанный файл ПО поврежден. Необходимо скачать новую копию файла прошивки телефона и поместить его в каталог TFTP. DHCP timeout DHCP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DHCP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DHCP сервер (проверить его конфигурацию). DNS timeout DNS сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между DNS сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам DNS сервер (проверить его конфигурацию). DNS unknown host DNS не смог разрешить имя TFTP сервера или CUCM. Необходимо убедиться, что имена хостов TFTP сервера или CUCM настроены правильно в DNS или использовать IP-адреса вместо имен хостов. Duplicate IP Другое устройство уже использует IP адрес, который присвоен телефону. Если телефону присвоен статический адрес, то нужно проверить, что ни у какого другого устройства нет такого же адреса, а если используется DHCP, то следует проверить конфигурацию DHCP сервера. Error update locale Один или более файлов локализаций не был найден в директории TFTP или файл оказался не валидным, и локализация не была изменена. Необходимо убедиться что следующие файлы находятся в поддиректориях TFTP сервера: tones.xml, glyphs.xml, dictionary.xml, kate.xml IP address released Телефон остается в режиме ожидания пока не включится питание или пока DHCP адрес не будет сброшен. Load ID incorrect Load ID программного обеспечения неправильного типа. Нужно проверить Load ID, назначенный телефону (во вкладке Device - Phone) и убедиться, что он введен правильно. Load rejected HC Загруженное приложение несовместимо с аппаратным обеспечением телефона. Эта ошибка возникает, когда происходит попытка установить на телефоне версию ПО, которое не поддерживает аппаратные изменения на этом телефоне. No default router В DHCP или статической конфигурации не указан default router. Если телефон имеет статические адреса, то необходимо проверить что default router был указан, а если используется DHCP, то нужно проверить его конфигурацию. No DNS server IP В DHCP или статической конфигурации не указан адрес DNS сервер. Нужно проверить что он указан на телефоне или на DHCP сервера. Programming error Произошла ошибка во время программирования телефона. Нужно попробовать перезагрузить телефон и если проблема не устранится, то обратиться в службу техподдержки Cisco. XmlDefault.cnf.xml, or .cnf.xml corresponding to the phone device name Информационное сообщение с указанием имени конфигурационного файла. TFTP access error TFTP сервер указывает на директорию, которая не существует. Необходимо проверить что у DHCP сервера или телефона правильно указан адрес TFTP. TFTP file not found Запрашиваемый файл (.bin) не найден в директории TFTP. Нужно проверить, что Load ID присвоен телефону (во вкладке Device - Phone) и что директория TFTTP сервера содержит .bin файл с этим идентификатором загрузки в качестве имени. TFTP server not authorized Указанный TFTP-сервер не может быть найден в CTL телефона. Это может быть по нескольким причинам: DHCP-сервер настроен неправильно и не обслуживает правильный адрес сервера TFTP, если телефон использует статический IP-адрес, телефон может быть настроен с неправильным адресом сервера TFTP или если адрес сервера TFTP верен, может возникнуть проблема с файлом CTL (в этом случае нужно запустить CTL клиент и обновить CTL файл). TFTP timeout TFTP сервер не отвечает. Возможные проблемы: большая нагрузка на сеть (выполнить проверку, когда нагрузка уменьшится), нет сетевой связанности между TFTP сервером и телефоном (проверить сетевой доступ между этими элементами сети) или не работает сам TFTP сервер (проверить его конфигурацию). Теперь рассмотрим меню сетевой статистики. Чтобы попасть в него нужно на IP-телефоне Cisco нажать физическую кнопку Settings, далее в меню настроек выбрать Status (Состояние) и Netwkork Statistics (Статистика сети). Там можно увидеть следующие поля Поле Описание Rcv (Rx Frames) Количество пакетов, полученных телефоном Xmt Frames (Tx Frames) Количество пакетов, отправленных телефоном REr (Rx Broadcasts) Количество broadcast пакетов, полученных телефонном BCast Количество broadcast пакетов, отправленных телефонном Phone Initialized Сколько времени прошло с момента инициализации телефона Elapsed Time Сколько времени прошло с момента перезагрузки телефона Port 1 Состояние PC порта телефона (скорость и дуплекс) Port 2 Состояние Network порта
img
DevOps
Теория
Кэш Docker: как выполнить повторную сборку образа и очистить кэш Docker
  С помощью контейнеров вы можете упаковать свое приложение и сделать его, таким образом, переносимым. В результате оно сможет работать в разных средах. Самая популярная платформа управления контейнерами – это Docker. Кэш сборки  Процесс создания образов должен быть быстрым, эффективным и надежным. Сама по себе идея образов Docker предполагает неизменность слоев. Каждая команда, которую вы выполняете, приводит к созданию нового слоя, содержащего изменения, которые отличают его от предыдущих слоев. Все предыдущие слои кэшируются, и вы можете использовать их повторно. Однако если ваша система зависит от внешних ресурсов, то кэш Docker может вызвать некоторые проблемы. Как оптимизировать кэш сборки Для того, чтобы понять, в чем заключаются проблемы, связанные с кэшем сборки Docker, давайте создадим собственное простенькое приложение Docker для ngnix. Прежде чем мы приступим к созданию образа, нам нужно создать Dockerfile, который отвечает за обновление библиотек и добавление пользовательской начальной страницы: FROM nginx:1.21.6 # Update all packages { // Обновляем все пакеты } RUN apt-get update && apt-get -y upgrade # Use a custom startpage { // Используем пользовательскую начальную страницу } RUN echo 'My Custom Startpage' > /usr/share/nginx/html/index.html Теперь мы можем создать образ Docker: $  docker build -t my-custom-nginx . => [1/3] FROM docker.io/library/nginx:1.21.6@sha256:e12...  5.8s => [2/3] RUN apt-get update && apt-get -y upgrade 3.6s => [3/3] RUN echo 'My Custom Startpage...  0.2s => exporting to image 0.1s => exporting layers 0.1s => writing image  0.0s => naming to docker.io/library/my-custom-nginx [+] Building 11.3s (7/7) FINISHED В данном примере я удалил часть вывода для того, чтобы его было проще читать. Если вы создаете образ впервые, то вы могли заметить, что этот процесс занимает довольно много времени – в данном случае  11.3s . Самый долгий шаг -  apt-get update && apt-get -y upgrade . Время его выполнения зависит от того, сколько зависимостей обновляется и насколько высока скорость вашего интернета. Эта команда проверяет наличие обновлений пакетов в операционной системе и устанавливает их при их наличии. А теперь вы можете выполнить эту команду снова и выиграть время, воспользовавшись кэшем сборки: $ docker build -t my-custom-nginx . => [1/3] FROM docker.io/library/nginx:1.21.6@sha256:e1211ac1… 0.0s => CACHED [2/3] RUN apt-get update && apt-get -y upgrade  0.0s => CACHED [3/3] RUN echo 'My Custom Startpage... 0.0s => exporting to image 0.0s => exporting layers 0.0s => writing image  0.0s => naming to docker.io/library/my-custom-nginx Building 1.1s (7/7) FINISHED На этот раз процесс создания образа был быстрее, так как были повторно использованы образы, созданные до этого. Когда вы будете настраивать свою начальную страницу в Dockerfile, вы увидите, как на это повлияет режим кэширования: FROM nginx:1.21.6 # Update all packages { // Обновляем все пакеты } RUN apt-get update && apt-get -y upgrade # Use a custom startpage { // Используем пользовательскую начальную страницу } RUN echo 'New Startpage' > /usr/share/nginx/html/index.html А теперь снова создадим образ: $ docker build -t my-custom-nginx . => [1/3] FROM docker.io/library/nginx:1.21.6@sha256:e1211ac1… 0.0s => CACHED [2/3] RUN apt-get update && apt-get -y upgrade  0.0s => [3/3] RUN echo 'My Custom Startpage...  0.2s => exporting to image 0.0s => exporting layers 0.0s => writing image  0.0s => naming to docker.io/library/my-custom-nginx Building 2.1s (7/7) FINISHED На этот раз мы видим, что был перестоен только последний слой, так как команда обнаружила, что изменилась команда  RUN . Но она повторно использовала второй этап сборки и не обновляла зависимости операционной системы.  В данном случае режим кэширования является вполне разумным. Как только вам необходимо перестроить первый шаг, каждый последующий будет строиться заново. Именно поэтому лучше всего помещать постоянно меняющиеся части в конец Dockerfile, чтобы повторно использовать предыдущие уровни сборки. И все же, вы можете захотеть принудительно перестроить кэшированный слой, чтобы принудительно выполнить обновление пакета. А так как вы хотите обеспечить безопасность своего приложения и использовать самые новые обновления, принудительная повторная сборка вам определенно потребуется.  Как использовать параметр  --no-cache для сборки Docker Причины отключения кэширования сборки могут быть самые разные. Вы можете повторно произвести сборку образа на базе основного образа, не используя при этом кэшированные слои, но используя при этом параметр  --no-cache .  $ docker build -t my-custom-nginx . => CACHED [1/3] FROM docker.io/library/nginx:1.21.6@sha256:...  0.0s => [2/3] RUN apt-get update && apt-get -y upgrade 3.5s => [3/3] RUN echo 'My Custom Startpage...  0.2s => exporting to image 0.1s => exporting layers 0.0s => writing image  0.0s => naming to docker.io/library/my-custom-nginx Building 5.5s (7/7) FINISHED Здесь были построены и созданы новые слои.  docker build запустила в этот раз обе команды, то есть применила подход «все или ничего». Либо вы указываете параметр  --no-cache , который позволит выполнить все команды, либо вы кэшируете по максимуму. Как применить аргументы Docker для очистки кэша Другой вариант позволяет создать некую отправную точку в Dockerfile. Для этого вам нужно изменить Dockerfile следующим образом: FROM nginx:1.21.6 # Update all packages { // Обновляем все пакеты } RUN apt-get update && apt-get -y upgrade # Custom cache invalidation { // Обновление пользовательского кэша } ARG CACHEBUST=1 # Use a custom startpage { // Используем пользовательскую начальную страницу } RUN echo 'New Startpage' > /usr/share/nginx/html/index.html Вы должны добавить в свой Dockerfile аргумент там, где вы хотите выполнить принудительную повторную сборку. Теперь вы сможете создать образ Docker и всегда указывать новое значение, что приведет к тому, что все следующие команды запустятся повторно: $ docker build -t my-custom-nginx --build-arg CACHEBUST=$(date +%s) . => [1/3] FROM docker.io/library/nginx:1.21.6@sha256:e1211ac1...  0.0s => CACHED [2/3] RUN apt-get update && apt-get -y upgrade 0.0s => [3/3] RUN echo 'My Custom Startpage... 0.3s => exporting to image  0.0s => exporting layers  0.0s => writing image 0.0s => naming to docker.io/library/my-custom-nginx Building 1.0s (7/7) FINISHED Указав  --build-arg CACHEBUST=$(date +%s) , вы постоянно будете устанавливать для параметра новой значение, что будет приводить к повторной сборке всех последующих слоев.  Заключение Кэширование сборок в Docker – довольно полезная функция. Она ускоряет процесс сборки образов Docker за счет повторного использования слоев, которые были созданы ранее. Для того, чтобы отключить функцию кэширования или использовать свой собственный аргумент сборки Docker, чтобы принудительно выполнить повторную сборку с какого-то определенного шага, вы можете воспользоваться параметром  --no-cache .  Понимание того, как работает сборка в Docker, крайне важно, так как это может сделать процесс создания контейнеров Docker более эффективным. 
img
Сети
How to
Устранение неполадок коммутации Cisco
Для устранения неполадок мы должны пройти путь от нижней части модели OSI к верхней. Для этого нам придется начать с протоколов, которые используются для коммутации. Будем думать о VLAN, транкинге, об агрегировании каналов и связующем дерева. Мы рассмотрим различные протоколы и различные сценарии, где "что-то работает" не так. Мы решим эти проблемы с помощью комбинации команд show и debug. Первая остановка ... проблемы с интерфейсом! Следующие статьи этого цикла: Траблшутинг STP (Spanning tree protocol) Устранение неисправностей EtherChannel Case #1 В этом примере мы имеем коммутатор в центре и два компьютера, которые подключены к нему. Каждый компьютер имеет свой IP-адрес, и они должны иметь возможность пинговать друг друга. Мы будем считать, что компьютеры настроены правильно и там нет никаких проблем. Интерфейс FastEthernet 0/1 находится в состоянии down. Это может указывать на проблему уровня 1, такую как неисправный кабель, неправильный кабель (кроссовер вместо прямого) или, возможно, нерабочая сетевая карта. Обратите внимание, что этот интерфейс работает в полудуплексном режиме. Если повезет, вы можете получить дуплексное сообщение через CDP, которое сообщит вам, что существует дуплексное несоответствие. Если вам не повезло, возможно, из-за этого ваш интерфейс переходит в состояние down. Имейте в виду, что гигабитный интерфейс не поддерживает halfduplex. SwitchA(config)#interface fa0/1 SwitchA(config-if)#duplex auto Изменим настройки интерфейса на duplex auto, чтобы коммутатор мог само настроиться. Может быть, нам повезет...но не в этот раз, пинг не работает. Интерфейс fa0 / 3, подключенный к хосту B, также не работает. После проверки кабелей и разъемов мы можем проверить ошибки дуплекса и скорости. Дуплекс включен в режим auto, так что это не является проблемой. Скорость была установлена на 10 Мбит, однако в то время как этот интерфейс является каналом Fast Ethernet (100 Мбит). SwitchA(config)#interface fa0/3 SwitchA(config-if)#speed auto Давайте переключим скорость на авто и посмотрим, что произойдет. Похоже, что несоответствие скорости привело к тому, что интерфейс перешел в состояние down. Изменение его на auto-speed возвращает интерфейс в состояние up. Это то, что мы искали. Интерфейсы, с которыми мы работаем, оба показывают состояние up/up. По крайней мере, теперь мы знаем, что нет никаких ошибок в кабеле, скорости или дуплексе. Теперь наш пинг проходит. Первый урок усвоен: Проверьте свои интерфейсы и посмотрите, отображаются ли они как up/up. Case #2 Та же топология, но здесь другая проблема. Хост A не может пропинговать хост B. Мы начнем с проверки интерфейсов: Состояние интерфейса FastEthernet0/3 выглядит нормально, но что-то не так с интерфейсом FastEthernet 0/1. Давайте изучим его подробнее: Так так, мы видим сообщение err-disabled. Это уже дает нам понять, что проблема, где здесь (по крайней мере, это означает, что мы на что-то наткнулись). Используйте команду show interfaces status err-disabled, чтобы узнать, почему интерфейс перешел в режим error-disabled. Это сообщит нам, что причина-безопасность порта. Мы можем посмотреть на конфигурацию безопасности порта, и мы видим, что только 1 MAC-адрес разрешен. Последний MAC-адрес, который виден на интерфейсе - 000с.2928.5c6c. Выше мы видим, что интерфейс был настроен для обеспечения безопасности на другой MAC-адрес. Именно по этой причине порт перешел в режим err-disabled. SwitchA(config)#interface fa0/1 SwitchA(config-if)#no switchport port-security Давайте уберем port security, чтобы решить эту проблему. SwitchA(config)#interface fa0/1 SwitchA(config-if)#shutdown SwitchA(config-if)#no shutdown Главное, что вы не должны забыть сделать - это после очистки настройки от port security ваш интерфейс все еще находится в режиме err-disabled. Вам нужно выполнить команды отключения и включения порта (shutdown и no shutdown), чтобы он снова заработал! Консоль сообщает нам, что интерфейс теперь включен. Как мы видим эхо-запрос проходит между компьютерами. Проблема решена! Урок 2 усвоен: проверьте, находится ли интерфейс в состоянии err-disabled, и если да, то: а) проверьте, почему это произошло, и Б) решите проблему. Case #3 Давайте продолжим с другой проблемой. Та же топология, но опять проблема. Эти два компьютера не "видят" друг друга. Интерфейсы выглядят хорошо, никаких ошибок здесь нет. И так мы видим, что port security отключена на этом коммутаторе. На данный момент мы, по крайней мере, знаем, что нет никаких проблем с интерфейсом и port security не фильтрует никакие MAC-адреса. В данный момент это хорошая идея, чтобы проверить информацию о VLAN. Вы можете использовать команду show vlan, чтобы быстро проверить, к какой VLAN принадлежат интерфейсы. Как вы можете видеть, наши интерфейсы находятся не в одной и той же VLAN. SwitchA(config)#interface fa0/3 SwitchA(config-if)#switchport access vlan 1 Мы переместим интерфейс fa0/3 обратно в VLAN 1. Теперь оба компьютера находятся в одной VLAN. Проблема решена! Урок 3 усвоен: убедитесь, что интерфейсы находится в нужной VLAN. Case #4 Пришло время для другой проблемы! Наши два компьютера не пингуюся между собой. Вы теперь знаете, как выглядит неудачный пинг, поэтому скрин не будет публиковаться снова. Интерфейсы не показывают никаких ошибок. Мы изучим настройку VLAN. Вы видите, что FastEthernet 0/1 находится в VLAN 10, но мы нигде не видим FastEthernet 0/3. Вот возможные причины: Что-то не так с интерфейсом. Мы проверили и убедились, что это не так, потому что он показывает состояние up/up, поэтому он кажется активным. Интерфейс не в режиме access port, а в режиме trunk. Быстрый взгляд на информацию о коммутаторе показывает нам, что нам нужно знать. Мы убедились, что интерфейс fa0/3 находится в режиме trunk, а native VLAN - 1. Это означает, что всякий раз, когда хост B отправляет трафик и не использует маркировку 802.1 Q, наш трафик заканчивается в VLAN 1. SwitchA(config)#interface fa0/3 SwitchA(config-if)#switchport mode access SwitchA(config-if)#switchport access vlan 10 Мы включим fa0/3 в режим доступа и убедимся, что он находится в VLAN 10. Оба интерфейса теперь активны в VLAN 10. Возможно, лучше проверить информацию на коммутаторе. Теперь я могу отправить пинг с хоста а на хост Б...проблема решена! Урок 4 усвоен: убедитесь, что интерфейс находится в нужном режиме (доступ или магистральный режим). Case #5 Те же два компьютера, тот же коммутатор. Однако этот сценарий немного интереснее. Компьютеры не могут пинговать друг друга, поэтому давайте пройдемся по нашему списку "возможных" ошибок: Интерфейсы выглядят хорошо, up/up-это очень хорошо. Оба интерфейса находятся в VLAN 10, так что это тоже хорошо. Просто чтобы быть уверенным...там нет port security. Это очень интересная ситуация. Интерфейсы работают (в состоянии up/up), мы находимся в одной VLAN, и нет никакой защиты портов. Что еще может быть причиной "перекрытия" трафика? Ага! Это может быть не то, о чем нам может прийти в голову, но мы же можем использовать VACLs (VLAN access-list), чтобы разрешить или запретить трафик в пределах VLAN. Если вы устраняете неполадки коммутаторов, то необходимо проверить эту настройку, если все остальное кажется вам нормальным. В этом случае есть VACL, подключенный к VLAN 10, давайте проверим его. Есть два порядковых номера ... 10 и 20. Порядковый номер 10 соответствует access-list 1, и его задача состоит в том, чтобы отбросить трафик. Давайте посмотрим, что это за access-list 1: Не смущайтесь из-за заявления о разрешении здесь. Использование оператора permit в access-list означает, что он будет "соответствовать" подсети 192.168.1.0/24. Наши два компьютера используют IP-адреса из этого диапазона. Если он соответствует этому access-list, то VLAN access-map отбросит трафик. SwitchA(config)# vlan access-map BLOCKSTUFF 10 SwitchA(config-access-map)# action forward Давайте изменим действие на "forward" и посмотрим, решит ли оно нашу проблему. Ну вот, все работает. Урок 5 усвоен: если все остальное кажется нормальным, убедитесь, что нет никакого VACL! Case #6 Давайте продолжим урок 6 с другой топологией. Теперь вы знаете, что нам нужно сначала проверить интерфейсы, а затем VLAN. В этом примере у нас есть те же два компьютера, но теперь у нас есть два коммутатора. Пинг от Хост А к Хосту Б не работает, так с чего начнем поиск? Сначала мы проверим интерфейс fa0/1 на коммутаторе 1. Интерфейс запущен и работает, это switchport, назначенный для VLAN 10. Пока все выглядит неплохо. Port security не включен, так что нам не нужно беспокоиться об этом. Давайте проверим то же самое на коммутаторе 2. Интерфейс работает, и он был назначен на VLAN 10. В данный момент мы видим, что интерфейсы, "смотрящие" к компьютерам выглядят хорошо. В этот момент Вы могли бы сделать две вещи: Подключите другой компьютер к коммутатору 1 и назначьте его во VLAN 10. Посмотрите, можно ли общаться между компьютерами во VLAN 10, когда они подключены к одному коммутатору. Сделайте то же самое на коммутаторе 2. Проверьте интерфейсы между коммутатором 1 и коммутатором 2. Мы сконцентрируем свое внимание на интерфейсах между коммутатором 1 и коммутатором 2, потому что там много чего может пойти не так! Интерфейсы не показывают никаких проблем, время проверить информацию о switchport. Коммутатор A находится в магистральном режиме и использует инкапсуляцию ISL. Коммутатор B также находится в магистральном режиме, но использует инкапсуляцию 802.1Q. Имейте в виду, что (в зависимости от модели коммутатора) административный режим по умолчанию может быть dynamic auto. Два интерфейса, которые оба работают в dynamic auto режиме, станут портом доступа (access). Лучше всего самостоятельно переключить интерфейс в магистральный режим. В нашем случае оба интерфейса магистральные, так что это хорошо, но у нас есть несоответствие протокола инкапсуляции. SwitchA(config)#interface fa0/15 SwitchA(config-if)#switchport trunk encapsulation dot1q Мы изменим тип инкапсуляции, чтобы оба коммутатора использовали протокол 802.1Q. Проблема решена! И опять все работает. Урок 6 усвоен: убедитесь, что при настройке магистралей используется один и тот же протокол инкапсуляции. Case #7 Вот опять тот же сценарий. Сейчас рассмотрим еще кое-что, что важно проверить при решении проблем trunk. Предположим, мы проверили и убедились, что следующие элементы не вызывают никаких проблем: Интерфейсы (скорость/дуплекс). Безопасность портов. Конфигурация Switchport (назначение VLAN, интерфейс, настроенный в режиме доступа). К сожалению, эхо-запрос между компьютерами все еще не проходит. Давайте взглянем на интерфейсы fa0/15 на коммутаторах: Проверим, что оба интерфейса находятся в магистральном режиме и что мы используем один и тот же протокол инкапсуляции (802.1 Q). Здесь нет никаких проблем. Что-нибудь еще, что может пойти не так с этой магистральной связью? Да! Магистраль может быть работоспособной, но это не означает, что все VLAN разрешены по магистральному каналу связи. В приведенном выше примере вы видите, что разрешена только VLAN 20. SwitchA(config)#interface fa0/15 SwitchA(config-if)#switchport trunk allowed vlan all SwitchB(config)#interface fa0/15 SwitchB(config-if)#switchport trunk allowed vlan all Давайте позволим всем VLAN пройти магистраль. По магистральной линии может передаваться трафик VLAN 10 между двумя коммутаторами. В результате пинг идет между компьютерами....еще одна проблема решена! Урок 7 усвоен: всегда проверяйте, разрешает ли магистраль все VLAN или нет. Case #8 Вот вам новый сценарий. Два компьютера, имеют разные IP-адреса. Коммутатор - это многоуровневый коммутатор. Поскольку компьютеры находятся в разных подсетях, нам приходится беспокоиться о маршрутизации. Мы видим, что два компьютера не могут связаться друг с другом. С чего мы должны начать устранение неполадок? Это статья не о настройке windows, но нам нужно обратить внимание на наши хосты. Поскольку компьютеры должны "выйти из своей собственной подсети", мы должны проверить, что IP-адрес шлюза по умолчанию в порядке и доступен. Хост А может достичь шлюза по умолчанию, поэтому мы, по крайней мере, знаем, что хост А работает нормально. Вот IP-конфигурация хоста B. Давайте проверим доступность шлюза по умолчанию! Здесь тоже все работает. Мы знаем, что компьютеры рабочие, потому что они знают, как выйти из своей собственной подсети, и шлюз по умолчанию доступен. Пора проверить коммутатор. Как мы видим, что хост А находится в VLAN 10 и хост B находится в VLAN 20. Мы не проверяли, включены ли интерфейсы, потому что мы можем пинговать IP-адреса шлюза по умолчанию. Это говорит о том, что fa0/1 и fa0/3 работают, но мы не знаем, к какой VLAN они принадлежат. Были сконфигурированы два интерфейса SVI. Это IP-адреса, которые компьютеры используют в качестве шлюза по умолчанию. Так почему же наш коммутатор не маршрутизирует трафик? Наличие IP-адресов на интерфейсах не означает автоматическую маршрутизацию трафика. Для этого нам потребуется таблица маршрутизации. Этот коммутатор не имеет SwitchA(config)#ip routing Давайте включим маршрутизацию на этом коммутаторе. Давайте сделаем так, чтобы это выглядело получше. Теперь коммутатор знает, куда перенаправлять IP-пакеты на этом коммутаторе. Вот так...теперь два компьютера могут достучаться друг до друга! Проблема решена! Урок 8 усвоен: если вы используете многоуровневый коммутатор для маршрутизации interVLAN, убедитесь, что интерфейсы SVI настроены правильно и что маршрутизация включена. Мы рассмотрели наиболее распространенные ошибки, которые могут произойти с нашими интерфейсами, VLAN, транками и проблемами маршрутизации при использовании многоуровневых коммутаторов. В следующей статье мы рассмотрим связующее дерево. Spanning-tree-довольно надежный протокол, но есть ряд вещей, которые могут пойти не так, как, вы ожидаете. Кроме того, из-за неправильной настройки могут произойти некоторые странные вещи...давайте рассмотрим траблшутинг STP в следующей статье.
ЗИМНИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59
Выбрать курс