что такое mgmt порт
Консольный порт и порт управления в сетевых устройствах / Cisco 2960S
Разница между консольным портом и портом управления в сетевых устройствах
«В чем разница между консольным портом и выделенным портом управления (fa0) на коммутаторе Cisco 2960s? «У вас когда-нибудь была такая проблема? Этот вопрос задавали пользователи Cisco, и поэтому многие эксперты поделились своими предложениями здесь, давайте узнаем больше о различии между консольным портом и портом управления в сетевых устройствах.
Консольный порт предназначен для внеполосного управления и настройки? Специальный порт управления предназначен для удаленного управления и настройки вне диапазона?
Я думаю, у меня есть вся информация, что мне нужно попробовать. Я собираюсь сделать эту конфигурацию в 2960-х годах, и я никогда раньше этого не делал.
Что делает команда «ip tftp interface f0»?
Эта команда сообщает коммутатору использовать fa0 для tftp при загрузке или загрузке конфигураций.
Однако он ничего не сообщит telnet / ssh.
Если вы хотите, чтобы telnet или ssh на порт управления с IP-адреса не в той же подсети, что и IP-адрес управления, коммутатору нужен стандартный шлюз, установленный с помощью команды «ip default-gateway ».
Я никогда не использовал порт управления, поэтому не могу сказать, что коммутатор будет использовать этот шлюз по умолчанию, но он должен до тех пор, пока на коммутаторе нет других интерфейсов L3.
Что вы подразумеваете под «L3-интерфейсом на коммутаторе»? Вы имеете в виду подключение к маршрутизатору, который является устройством уровня 3? Нет, прямо сейчас ничего не связано с коммутатором, кроме Gi1 / 0/1, который является интерфейсом, который я использую для интерфейса управления через SSH. Сейчас я подключился к коммутатору через SSH. Я хочу изменить его на выделенный интерфейс управления fa0. Gi1 / 0/1 находится на vlan 1. IP-адрес 192.168.0.149. SM 255.225.254.0. Шлюз по умолчанию, 192.168.1.1. Я нахожусь в сети 23. Я думаю, что я просто позвоню в центр Cisco TAC и попрошу, чтобы они показали мне, как это сделать, потому что я более смущен тем, что был, когда я впервые начал. Я ценю, что вы пытаетесь мне помочь.
Если вы назначаете IP-адрес порта управления, вы можете подключиться к порту управления, если ваш компьютер находится в одной подсети IP.
Если это не так, то 2960 должен иметь шлюз по умолчанию, чтобы знать, куда отправлять пакеты.
Если у вас уже есть шлюз по умолчанию, вам может потребоваться его изменить, т.е. шлюз по умолчанию должен быть в той же подсети IP, что и IP, назначенный интерфейсу управления, если вы не собираетесь подключаться из той же самой подсети IP-адреса, что и интерфейс управления, в котором я сомневаюсь.
Таким образом, шлюз по умолчанию будет IP из той же подсети, что и IP в интерфейсе управления, и это будет на устройстве L3, которое будет маршрутизировать для vlans.
Если вы в настоящий момент вошли в этот коммутатор и хотите назначить IP-адрес из той же подсети IP, что и в настоящее время на вашем интерфейсе vlan, вы не можете этого сделать.
Я говорю не могу, потому что, как я уже сказал, я не использовал порт управления и, поскольку он не пропускает пользовательский трафик, он может позволить вам это сделать.
Таким образом, вы не можете управлять этим удаленно, а затем удаленно, я имею в виду, из другой IP-подсети, чем IP-подсеть, используемая для порта управления?
Поскольку коммутатор должен знать, должен ли использоваться его MAC-адрес, является MAC-адрес клиента, т.е. ПК находится в той же самой подсети IP-адреса или должен ли Mac быть MAC-адресом устройств L3?
Никогда не использовали их, поэтому просто пытались понять, что вы можете и не можете сделать с этим портом.
Да. Я тоже. И, зная Cisco (в последнее время), документация (о руководстве по настройке порта управления) действительно s * cks.
Нетривиальные случаи работы с серверами
Любое оборудование, в том числе и серверное, иногда начинает работать непредсказуемо. Абсолютно не важно — новое ли это оборудование, или же оно уже несколько лет работает с полной нагрузкой.
Случаев сбоя и некорректной работы возникает множество и диагностика проблемы зачастую превращается в увлекательную головоломку.
Ниже мы расскажем о некоторых интересных и нетривиальных случаях.
Обнаружение неполадок
Регистрация проблемы чаще всего происходит после обращения клиентов в службу технической поддержки посредством тикет-системы.
В случае обращения клиента, который арендует у нас выделенные серверы фиксированной конфигурации, мы проводим диагностику, чтобы выяснить, что проблема не носит программный характер.
Проблемы программного характера клиенты обычно решают собственными силами, тем не менее, мы в любом случае стараемся предложить помощь наших системных администраторов.
Если становится ясно, что проблема аппаратная (например, сервер не видит часть оперативной памяти), то на этот случай у нас всегда есть в резерве аналогичная серверная платформа.
В случае выявления аппаратной проблемы мы переносим диски со сбойного сервера на резервный и, после небольшой перенастройки сетевого оборудования, выполняется запуск сервера в работу. Таким образом данные не теряются, а время простоя не превышает 20 минут с момента обращения.
Примеры неполадок и способы их устранения
Сбой в работе сети на сервере
Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.
Дело в том, что при первоначальной установке операционной системы, MAC-адреса сетевых карт записываются в специальный файл, расположенный по адресу: /etc/udev/rules.d/70-persistent-net.rules.
При старте операционной системы этот файл сопоставляет имена интерфейсов MAC-адресам. При замене сервера на резервный, MAC-адреса сетевых интерфейсов уже не совпадают, что и приводит к неработоспособности сети на сервере.
Для решения проблемы необходимо удалить указанный файл и перезапустить сетевой сервис, либо перезагрузить сервер.
Операционная система, не найдя этого файла, автоматически сгенерирует аналогичный и сопоставит интерфейсы уже с новыми MAC-адресами сетевых карт.
Перенастройки IP-адресов после этого не требуется, сеть сразу начнет работать.
Плавающая проблема с зависаниями
Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI — пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры — завис намертво через 30 минут работы.
При этом процессор работал штатно, значения температуры не превышали стандартных при нагрузке, все кулеры были исправны. Стало ясно, что дело не в перегреве.
Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.
Заменив модуль на новый, мы поставили сервер на тест повторно, однако нас ждало фиаско — сервер вновь завис, выдав ошибки уже по другому модулю ОЗУ. Заменили и его. Еще один тест — еще раз завис, вновь выдав ошибки по оперативной памяти. Внимательный осмотр слотов ОЗУ не выявил никаких дефектов.
Оставался один возможный виновник проблемы — центральный процессор. Дело в том, что контроллер оперативной памяти расположен именно внутри процессора и именно он мог давать сбой.
Сняв процессор, обнаружили катастрофу — один пин сокета был сломан в верхней части, обломанный кончик пина буквально прикипел к контактной площадке процессора. В итоге, когда на сервере не было нагрузки, все работало адекватно, но при увеличении температуры процессора контакт нарушался, тем самым прекращая нормальную работу контроллера оперативной памяти, что и вызывало зависания.
Окончательно проблема решилась заменой материнской платы, поскольку восстановить сломавшийся пин сокета нам, увы, не под силу, и это уже задача для сервисного центра.
Мнимое зависание сервера при установке ОС
Достаточно забавные случаи возникают, когда производители оборудования начинают менять архитектуру аппаратной части, отказываясь от поддержки старых технологий в пользу новых.
К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру — все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.
На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.
На моменте выбора диска для установки ни одного диска не отображалось, более того, выдавалась ошибка необходимости установки дополнительных драйверов. Операционная система устанавливалась с USB-флешки и быстрый поиск в интернете показал, что такой эффект возникает, если программа установки не может найти драйвера для контроллера USB 3.0.
Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз — разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.
Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.
Интересная особенность Dell PowerVault
Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.
Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.
Среди наших услуг для размещенного оборудования как раз есть специальная услуга «Дополнительный порт 10 Мбит/с», которую заказывают в случае необходимости подключения средств удаленного управления сервером. Эти средства носят разные названия:
Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово — мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.
Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.
Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле — вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.
Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT — все в порядке.
Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить — возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось — порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) — иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой — линка не было и идеи уже заканчивались.
Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.
Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай — очень большая редкость, но имеет место быть.
Клиент был удивлен не меньше нашего и очень благодарил за решение проблемы. Соответственно ему так и оставили порт в 100BASE-TX, ограничив скорость на порту непосредственно с помощью встроенного механизма ограничения скорости.
Отказ турбин охлаждения
Как-то раз к нам приехал клиент, попросил снять сервер и вынести его в сервисную зону. Инженеры все сделали и оставили его наедине с оборудованием. Прошел час, второй, третий — клиент все время запускал/останавливал сервер и мы поинтересовались, в чем же заключается проблема.
Оказывается, что у сервера производства Hewlett-Packard отказало две турбинки охлаждения из шести. Сервер при этом включается, выдает ошибку по охлаждению и сразу выключается. При этом на сервере располагается гипервизор с критичными сервисами. Для восстановления штатной работы сервисов требовалось выполнить срочную миграцию виртуальных машин на другую физическую ноду.
Решили клиенту помочь следующим образом. Обычно сервер понимает, что с вентилятором охлаждения все хорошо, просто считывая количество оборотов. При этом, разумеется, инженеры Hewlett-Packard сделали все, чтобы нельзя было заменить оригинальную турбинку аналогом — нестандартный коннектор, нестандартная распиновка.
Дальнейшее было делом техники — взяли пару проводов для прототипирования (волей случая оказались под рукой — некоторые наши инженеры увлекаются Arduino) и просто соединили пины от соседних рабочих турбинок с коннекторами вышедших из строя. Сервер запустился и клиенту наконец-то удалось выполнить миграцию виртуальных машин и запустить сервисы в работу.
Разумеется, что все это было выполнено исключительно под ответственность клиента, тем не менее в итоге такой нестандартный ход позволил сократить простой до минимума.
А где же диски?
В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа — Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.
Первое, что удалось выяснить — диски отваливались только на одном контроллере. При этом «выпавшие диски» исчезали из списка в родной утилите управления Adaptec и заново там появлялись только при полном отключении питания сервера и последующем подключении. Первое, что пришло на ум — программное обеспечение контроллера. На всех трех контроллерах стояли немного разные прошивки, поэтому было решено на всех контроллерах установить одну версию прошивки. Выполнили, погоняли сервер в режимах максимальной нагрузки — все работает как положено. Пометив проблему как решенную, сервер отдали клиенту обратно в продакшн.
Через две недели снова обращение с той же проблемой. Было решено заменить контроллер на аналогичный. Выполнили, прошили, подключили, поставили на тесты. Проблема осталась — через пару дней выпали все диски уже на новом контроллере и сервер благополучно завис.
Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали — сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло — они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.
Проблему удалось решить случайно, когда стали проверять в отдельности каждый диск. При определенной нагрузке один из дисков начинал стучать головами и давал короткое замыкание на порт SATA, при этом какая-либо аварийная индикация отсутствовала. Контроллер при этом переставал видеть часть дисков и вновь начинал их опознавать только при переподключении по питанию. Вот так один единственный сбойный диск выводил из строя всю серверную платформу.
Заключение
Конечно, это лишь малая часть интересных ситуаций, которые были решены нашими инженерами. Некоторые проблемы «отловить» достаточно непросто, особенно когда в логах нет никаких намеков на произошедший сбой. Зато любые подобные ситуации стимулируют инженеров детально разбираться в устройстве серверного оборудования и находить самые разнообразные решения проблем.
Вот такие забавные случаи были в нашей практике.
А с какими сталкивались вы? Добро пожаловать в комментарии.
Базовые сведения о работе с коммутаторами Cisco
Базовые сведения о работе с коммутаторами Cisco
Данная статья когда-то разрабатывалась, как пособие по основам работы с коммутаторами для «самых начинающих» инженеров. Постараемся в нём рассмотреть практические аспекты работы, не закапываясь особенно в теорию коммутации. В качестве подопытной зверушки у нас будут выступать коммутатор L3 серии Cisco Catalyst 3560 – достаточно универсальная железка, позиционируемая производителем как коммутатор корпоративного класса с фиксированной конфигурацией. Может применяться, как на уровне доступа, так и на уровне распределения.
При написании статьи предполагается, что читающий уже знаком с основами работы в Cisco IOS, или способен разобраться с встроенной системой помощи, благо, что она достаточно информативна и дружелюбна. Также предполагается само собой разумеющимся хотя бы базовое знание технологий TCP/IP и модели OSI.
Базовая конфигурация режимов работы портов.
Поскольку в построении сети практически невозможно обойтись без использования VLAN, то первое, на что мы обратим внимание – это два основных режима работы портов для передачи тегированного и нетегированного трафика, или, в терминологии Cisco – trunk & access соответственно.
К access порту подключаются, как правило, оконечные устройства, не умеющие работать с тегированным трафиком, а к trunk – каналы для передачи данных по различным VLAN в сети.
Конфигурация access-порта предельно проста, и выглядит примерно так:
interface FastEthernet0/4
description –simple access port—
switchport access vlan 100
switchport mode access
Настраивается, соответственно, так:
sw1(config-if)# switchport mode access
Переключаем порт в режим access.
Базовая конфигурация транковых портов тоже элементарна:
interface FastEthernet0/21
description –simple trunk port—
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 952, 953
switchport mode trunk
Как мы видим – добавляется только список разрешенных к прохождению VLAN (не обязательно, но в целях безопасности лучше применить) и применяемый стандарт энкапсуляции – dot1q, пропиетарный Cisco ISL, или автосогласование.
Транковый порт сам по себе не умеет работать с нетегированным трафиком, поэтому такой трафик будет просто отброшен. Для его обработки можно настроить на портах native vlan. Любой пакет, не принадлежащий к определенному VLAN будет помечаться меткой native vlan, а трафик из данного vlan будет передаваться в транковый порт нетегированным.
Стоит заметить, что конфигурация порта при переключении его из одного режима в другой не изменяется, в отличие от режима его работы. Поэтому порт, сконфигурированный, как показано ниже, будет работать в trunk. Стоит ориентироваться только на switchport mode или, на вывод информации, как будет изложено далее.
interface FastEthernet0/21
description — port — switchport access vlan 2
switchport trunk encapsulation dot1q
switchport mode trunk
Конфигурация скорости и дуплекса.
Несмотря на повсеместное распространение автосогласования работы портов, зачастую встречаются проблемы, связанные с некорректной работой автосогласования, в результате чего порт может постоянно «прыгать» из рабочего состояние в нерабочее и генерировать ошибки. Поэтому самым надежным путем решения данной проблемы является ручной перевод портов на обои концах линка в одинаковый режим работы.
Конфигурируется элементарно, следующими командами:
sw1(config-if)#speed?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration
sw1(config-if)#duplex?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation
О диагностике проблем, связанных с автосогласованием будет сказано далее.
Сами VLAN создаются так:
ors-sw-ortpc(config)#vlan 777
ors-sw-ortpc(config-vlan)#name test_vlan
ors-sw-ortpc(config-vlan)#exit
Просмотр информации о созданных VLAN – show vlan
Catalyst 3560 поддерживает до 1005 созданных VLAN. Возникает вопрос – что делать, если число созданных VLAN подходит к концу, а нужно подключить скажем, новый сегмент сети? Или же, до новой БС присоединяющий оператор выделил 1 VLAN, а нам нужно пробрасывать свой VLAN. В таком случае можно использовать dot1q tunneling, или Q-in-Q – двойное тегирование VLAN. В таком случае на входе транспорта внуть одного VLAN упаковываются остальные VLAN, и распаковываются на выходе. Сражу стоит отметить что 29хх серия Catalyst, в отличие от 35xx, 37xx такой режим работы не поддерживает.
Настраивается тоже достаточно элементарно:
sw1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
sw1(config)#interface fa0/17
sw1(config-if)#description – QinQ double encapsulation — sw1(config-if)#switchport mode dot1q-tunnel
sw1(config-if)#switchport access vlan 77
interface FastEthernet0/17
switchport access vlan 77
switchport mode dot1q-tunnel
end
Таким образом настроенный порт все приходящие пакеты будет энкапсулировать в VLAN 77, который и будет виден для всех устройств, находящихся далее. Достаточно передать данный VLAN до того узла, на котором необходимо развернуть обратно, и там распаковать, используя аналогичные настройки порта.
При этом, возможно, нужно будет увеличить MTU по данному пути на 4 байта, для обеспечения дополнительной метки vlan tag.
Адресация и маршрутизация.
Catalyst 3560 может работать как на третьем уровне сетевой модели, так и на втором. В любом случае для доступа к нему необходимо присвоить ему IP адрес в требуемом VLAN (как правило, для управления устройствами выделяется отдельный VLAN) и настроить маршрутизацию.
interface Vlan100
ip address 192.168.10.254 255.255.255.0
ip default-gateway 192.168.10.1
Тем самым мы назначили коммутатору IP-адрес 192.168.10.254/24 в 100м VLAN и установили шлюзом по умолчанию 192.168.10.1. При такой схеме коммутатор используется как L2. Включить L3 маршрутизацию можно командой ip routing. При этом становится возможным задавать множество маршрутов, и просматривать, соответственно, таблицу маршрутизации (show ip route). Естественно, перед переключение необходимо сначала указать маршруты, чтобы не потерять управление коммутатором из другой сети.
conf t
ip route 0.0.0.0 0.0.0.0 192.168.10.1
Получение и обработка информации.
Думаю, тут стоит рассмотреть практические примеры с пояснениями:
show interfaces status – выводит общую информацию по всем портам.
sw1#show interfaces status
Port Name Status Vlan Duplex Speed Type
Fa0/1 Sector-1 connected trunk a-full a-100 10/100BaseTX
Fa0/2 Sector-2 connected trunk a-full a-100 10/100BaseTX
Fa0/3 Sector-3 connected trunk a-full a-100 10/100BaseTX
Fa0/4 notconnect 1 auto auto 10/100BaseTX
Fa0/5 port connected 100 a-full a-100 10/100BaseTX
Fa0/6 connected trunk full 100 10/100BaseTX
Fa0/7 disabled 100 auto auto 10/100BaseTX
Здесь мы можем видеть:
Собственно, сам порт, его имя (задаваемое description).
Status – порта – подключен и поднят (connected)/не подключен физически (notconnect) либо административно отключен (disabled).
Vlan – режим работы порта – trunk, или соответствующий access vlan.
Дуплекс и скорость порта – авто, или же жестко заданные установки (Fa0/6 – принудительно в режиме 100 Mb, full duplex.), Обратите внимание что на нерабочих интерфейсах прописано auto.
sh interfaces – просмотр подробной информации об указанном интерфейсе.
sw1#sh interfaces fa0/21
FastEthernet0/21 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 001f.0001.0001 (bia 001f.0001.0001)
Description: — some port — MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:06, output hang never
Last clearing of «show interface» counters 17w4d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1056000 bits/sec, 203 packets/sec
5 minute output rate 551000 bits/sec, 269 packets/sec
1015031190 packets input, 556493190204 bytes, 0 no buffer
Received 8800603 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 5337282 multicast, 0 pause input
0 input packets with dribble condition detected
1761812043 packets output, 340685749958 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Is up, line protocol is up (connected) — Первое «up» относится к состоянию физического уровня передачи данных интерфейса. Сообщение «line protocol up» показывает состояние уровня канала передачи данных для данного интерфейса и означает, что интерфейс может отправлять и принимать запросы keepalive.
Для сравнения
FastEthernet0/4 is down, line protocol is down (notconnect) – порт отключен.
FastEthernet0/7 is administratively down, line protocol is down (disabled) – отключен административно (shutdown).
Full-duplex, 100Mb/s (полнодуплексный, 100 Мбит/с) — текущая скорость и режим дуплексирования для данного интерфейса. Заметьте, что сейчас невозможно узнать – было ли включено автосогласование для порта.
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
– очередь входа для пакетов. На коммутаторах данной серии не используется, но служит для отброса пакетов с низким приоритетом в случае перегрузки CPU. Общее число сбросов. Стоит заметить, что типичной причиной сброса пакетов может быть прием трафика в канал с меньшей пропускной способностью из более широкого канала.
5 minute input rate 1056000 bits/sec, 203 packets/sec
5 minute output rate 551000 bits/sec, 269 packets/sec
Скорость ввода/вывода трафика за 5 минут – в битах и пакетах. Возможно подсчитывать трафик за иные промежутки времени – для этого используется команда load-interval. Однако, это ведет к увеличению загрузки CPU.
sw1(config)#int fa0/1
sw1(config-if)#load-interval?
Load interval delay in seconds
1015031190 packets input, 556493190204 bytes, 0 no buffer
Received 8800603 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 5337282 multicast, 0 pause input
0 input packets with dribble condition detected
1761812043 packets output, 340685749958 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out
Далее показаны текущие счетчики ошибок, являющиеся важнейшим инструментом в диагностике возникающих проблем.
Счетчики ошибок на самом деле разбросаны по разным местам IOS, но для примера можно рассмотреть следующее:
sw1#sh interfaces fa0/1 counters errors
Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize
Fa0/1 0 0 0 3 1.46E+08
Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants
Fa0/1 0 0 0 0 0 3 64
Счетчик и некоторые рекомендации:
Align-Err
Количество ошибок выравнивания.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.
collisions
Число коллизий произошедших до окончания передачи пакета. Нормальное явление для полудуплексного интерфейса. Быстрый рост счетчика может быть вызван высокой загрузкой интерфейса, либо несоответствием режимов дуплекса.
CRC
Несовпадение контрольной суммы кадра.
Обычно является результатом конфликтов, но может указывать и на физическую неполадку. В некоторых случаях возможны наводки на физику ЛВС, либо помехи.
pause input
Подключенное устройство запрашивает приостановку передачи трафика при переполнении его буфера.
Excess-ColПодобно коллизиям не должно наблюдаться на полнодуплексном интерфейсе.
FCS-Err
Ошибки в контрольной последовательности кадров.
Как правило, увеличение данного счетчика свидетельствует о проблемах согласования дуплексных режимов, либо о наличии проблемы на физическом уровне.
ignored
Может быть признаком широковещательного шторма в сети.
Late-Col
Коллизии на последних этапах передачи кадра. Не должны наблюдаться на полнодуплексном порту.
lost carrier
Потеря несущей. Проблемы на физическом уровне.
Underruns
Скорость передатчика превышает возможности коммутатора.
Undersize
Полученные кадры с размером меньше минимума. Необходимо проверить устройство, посылающее такие кадры.
Для получения подробной информации по обработанным пакетам можно использовать команду
sh controllers ethernet-controller
Пример вывода:
sw1 #sh controllers ethernet-controller fa0/21
Transmit FastEthernet0/1 Receive
665578020 Bytes 662563391 Bytes
3057832162 Unicast frames 2887447872 Unicast frames
2443399319 Multicast frames 100518228 Multicast frames
132541948 Broadcast frames 90307083 Broadcast frames
0 Too old frames 533536518 Unicast bytes
0 Deferred frames 3228404572 Multicast bytes
0 MTU exceeded frames 1010212552 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 145990113 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 735750877 Minimum size frames
0 8 collision frames 1557036200 65 to 127 byte frames
0 9 collision frames 305275380 128 to 255 byte frames
0 10 collision frames 95908725 256 to 511 byte frames
0 11 collision frames 126755638 512 to 1023 byte frames
0 12 collision frames 257546363 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 64 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
521536351 64 byte frames 145990113 Valid frames, too small
3679829207 127 byte frames
317941784 255 byte frames 0 Too old frames
197523329 511 byte frames 64 Valid oversize frames
114203781 1023 byte frames 0 System FCS error frames
802738977 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames
На этом позвольте закончить, все дополнительное уже мало укладывается в рамки данной статьи.