Что означают флаги su и p в сводных данных по ethernet
Пример настройки межстекового канала EtherChannel на коммутаторе Catalyst 3750
Параметры загрузки
Содержание
Введение
В данном документе приводится пример настройки межстекового канала EtherChannel на коммутаторе Cisco Catalyst 3750 под управлением операционной системы Cisco IOS®. Канал EtherChannel может иметь название Fast EtherChannel или Gigabit EtherChannel. Это зависит от скорости интерфейсов или портов, которые используются для формирования межстекового канала EtherChannel.
Предварительные условия
Требования
Для данного документа нет особых требований.
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются коммутатора Catalyst 3750 под управлением операционной системы Cisco IOS версии 12.2(25)SEC.
Сведения, представленные в данном документе, были получены на тестовом оборудовании в специально созданных лабораторных условиях. При написании данного документа использовались только данные, полученный от устройств с конфигурацией по умолчанию. В рабочей сети необходимо понимать последствия выполнения всех команд.
Условные обозначения
См. Технические советы Cisco. Условные обозначения для получения дополнительной информации об условных обозначениях в документах.
Теоретические сведения
В данном документе для межстекового канала EtherChannel объединяются следующие интерфейсы:
Два интерфейса Gigabit Ethernet одного из коммутаторов Catalyst 3750
Один интерфейс Gigabit Ethernet на другом коммутаторе Catalyst 3750 того же самого стека
Три интерфейса Gigabit Ethernet на коммутаторе Catalyst 3750 другого стека
Технология взаимоподключения Cisco StackWise предполагает использование двух взаимно направленных путей в 16 Гбит каждый. Для эффективного распределения нагрузки трафика, пакеты распределяются между этими двумя логическими взаимно направленными путями, которые образуют взаимоподключение в 32-Гбит. Это сдвоенные пути от любого порта к любому другому порту в рамках стека Catalyst 3750. Таким образом, гарантируется максимальное время доступности, так как всегда существует альтернативный путь при возникновении сбоя передачи данных по другому пути. Коммутатор Catalyst 3750 поддерживает:
Межстековый канал EtherChannel
Межстековый канал UplinkFast (с обработкой отказов в течение секунд)
Межстековые маршруты равной стоимости между различными коммутаторами в стеке
LACP-протокол и PAgP-протокол
Каналы EtherChannel могут настраиваться автоматически либо с помощью PAgP-протокола, либо с помощью LACP-протокола. PAgP-протокол – это принадлежащий компании Cisco протокол, который может работать только на коммутаторах Cisco и на коммутаторах, лицензированных для поддрежки PAgP, выпущенных другими лицензированными производителями. LACP-протокол определяется стандартом IEEE 802.3ad. LACP-протокол позволяет коммутаторам Cisco управлять Ethernet-каналами между коммутаторами, которые соответствуют стандарту IEEE 802.3ad.
PAgP-протокол не может использоваться на межстековых каналах EtherChannel, в то время как LACP-протокол поддерживается на межстековых каналах EtherChannel в операционной системе Cisco IOS версии 12.2(25)SEC и более поздней. Интерфейсы коммутатора обмениваются LACP-пакетами только с партнерскими интерфейсами в активном или пассивном режиме. Для формирования канала можно настроить до 16 портов. Восемь из этих портов будут находиться в активном режиме, а остальные восемь будут находиться в режиме ожидания. При выходе из строя любого из активных портов, произойдет активизация порта, находящегося в режиме ожидания. Интерфейсы в режиме настройки не обмениваются пакетами по протоколу PAgP или LACP.
На межстековом канале EtherChannel поддерживаются следующие режимы EtherChannel:
active — переводит интерфейс в активное состояние согласования, в котором интерфейс начинает обмениваться данными с другими интерфейсами, посылая LACP-пакеты.
passive — переводит интерфейс в пассивное состояние согласования, в котором интерфейс отвечает только на получаемые LACP-пакеты, однако, не начинает активного согласования. Этот параметр минимизирует передачу LACP-пакетов.
on — принудительно подключает интерфейс к каналу EtherChannel без использования протокола PAgP или LACP. В режиме «on» пригодный к использованию канал EtherChannel существует только тогда, когда группа интерфейса в режиме «on» имеет соединение с другой группой интерфейсов в режиме «on».
Настройка
В этом разделе приводятся сведения о настройке функций, описанных в данном документе.
Схема сети
В данном документе используется следующая схема сети:
В данной схеме сети существует два стека коммутатора Catalyst 3750 Switch — стек A и стек Б. Стек A содержит три узла коммутатора, а стек Б содержит только один узел коммутатора. Канал EtherChannel формируется двумя портами на коммутаторе 1 и одним портом на коммутаторе 3 стека A. Эти порты подключены к трем портам в стеке Б.
Процедура настройки сети необходима для определения этих портов в качестве магистральных.
Настройки
В данном документе используются следующие конфигурации:
Настройка межстекового канала EtherChannel без протокола PAgP или LACP
В данном подразделе содержится пример настройки канала EtherChannel без использования протокола PAgP или LACP:
Стек А коммутатора Catalyst 3750
Стек Б коммутатора Catalyst 3750
Состояние EtherChannel можно проверить следующим образом:
Примечание: В данном примере показано сообщение об ошибке, которое отображается при попытке настроить канал EtherChannel с помощью PAgP:
Стек А коммутатора Catalyst 3750
Настройка межстекового канала EtherChannel с помощью протокола LACP
В данном примере показана настройка канала EtherChannel с помощью протокола LACP. Минимально необходимой версией операционной системы IOS, которая поддерживает протокол LACP в межстековом канале Etherchannel, является операционная система Cisco IOS 12.2(25)SEC. В данном примере используется конфигурация LACP в режиме «active-active»:
Стек А коммутатора Catalyst 3750
Стек Б коммутатора Catalyst 3750
Состояние EtherChannel можно проверить следующим образом:
В данном примере используется конфигурация LACP в режиме «passive-active»:
Стек А коммутатора Catalyst 3750
Стек Б коммутатора Catalyst 3750
Состояние EtherChannel можно проверить следующим образом:
Проверка
Воспользуйтесь данным разделом для проверки правильности функционирования вашей конфигурации.
Выполните нижеследующие команды для проверки канала порта в коммутаторе Catalyst 3750 под управлением операционной системы Cisco IOS:
show interfaces port-channel [channel-group-number]
show etherchannel [channel-group-number] summary
Устранение неполадок
Для этой конфигурации отсутствуют сведения об устранении неполадок.
Тренинг Cisco 200-125 CCNA v3.0. День 38. Протокол EtherChannel для 2 уровня OSI
Сегодня мы рассмотрим работу протокола агрегирования каналов Layer 2 EtherChannel для 2 уровня модели OSI. Этот протокол не слишком отличается от протокола 3-го уровня, однако прежде чем начать изучение Layer 3 EtherChannel, я должен ознакомить вас с несколькими концепциями, так что к третьему уровню мы перейдем позже. Мы продолжаем следовать расписанию курса CCNA, так что сегодня рассмотрим раздел 1.5 «Настройка, проверка и неполадки Layer 2/3 EtherChannel» и подразделы 1.5а «Статический EtherChannel», 1.5b «Протокол PAGP» и 1.5с «Открытый стандарт IEEE- LACP».
Перед тем, как идти дальше, мы должны понять, что такое EtherChannel. Предположим, у нас имеется свитч А и свитч В, избыточно соединенные тремя линиями связи. Если использовать протокол STP, две лишних линии будут логически заблокированы, чтобы предотвратить образование петель.
Допустим, у нас имеются порты FastEthernet, обеспечивающие скорость трафика 100 Мбит/с, так что суммарная пропускная способность составляет 3 х 100 = 300 Мбит/с. Мы оставляем всего один канал связи, из-за чего она снизится до 100 Мбит/с, то есть в данном случае STP ухудшит характеристики сети. Кроме того, 2 лишних канала будут зря простаивать.
Для предотвращения подобного разработчик KALPANA – компания, которая создала свитчи Cisco Catalist и которую позже купила Cisco, в 1990-х разработала технологию под названием EtherChannel.
В нашем случае эта технология превращает три отдельных канала связи в один логический канал пропускной способностью 300 Мбит/с.
Первый режим технологии EtherChannel – это ручной, или статический режим. При этом свитчи ничего не будут делать при любых условиях передачи, полагаясь на то, что все ручные настройки параметров работы сделаны правильно. Канал просто включается и работает, полностью доверяя настройкам администратора сети.
Второй режим – это проприетарный протокол агрегирования каналов Cisco PAGP, третий – IEEE стандартный протокол агрегирования каналов LACP.
Если у нас есть свитч А с двумя интерфейсами f0/1 и f0/2, мы должны войти в настройки каждого порта и ввести данную команду, причем номер группы интерфейсов EtherChannel может иметь значение от 1 до 6, главное, чтобы это значение было одинаково для всех портов свитча. Кроме того, порты должны работать в одинаковых режимах: оба в режиме access или оба в режиме trunk и иметь одинаковые native VLAN или разрешенные VLAN.
Агрегирование EtherChannel сработает только в случае, когда группа каналов будет состоять из одинаково настроенных интерфейсов.
Соединим свитч А двумя линиями связи со свитчем В, который также имеет два интерфейса f0/1 и f0/2. Эти интерфейсы образуют свою группу. Настроить их для работы в EtherChannel можно с помощью той же команды, причем номер группы не имеет значения, поскольку они расположены на локальном свитче. Можно обозначить эту группу номером 1, и всё будет работать. Однако запомните – чтобы оба канала работали без проблем, все интерфейсы должны быть настроены совершенно одинаково, на один режим – access или trunk. После того, как вы зашли в настройки обоих интерфейсов свитча А и свитча В и ввели команду channel-group 1 mode on, агрегирование каналов EtherChannel будет выполнено.
Оба физических интерфейса каждого из свитчей будут работать как один логический интерфейс. Если просмотреть параметры STP, мы увидим, что у свитча А будет показан один общий интерфейс, сгруппированный из двух физических портов.
Перейдем к рассмотрению PAGP – протоколу агрегирования портов, разработанного компанией Cisco.
Если на обоих концах линии связи вы введете одинаковую команду channel-group 1 mode desirable, режим EtherChannel будет активирован. Аналогично произойдет, если на одном конце канала интерфейсы будут настроены командой channel-group 1 mode desirable, а на другом – командой channel-group 1 mode auto.
Однако если интерфейсы на обоих концах каналов настроить на auto командой channel-group 1 mode auto, агрегации каналов не произойдет. Поэтому запомните – если вы хотите использовать EtherChannel по протоколу PAGP, интерфейсы хотя бы одной из сторон должны находится в состоянии desirable.
Возможные комбинации настроек на обеих сторонах каналов таковы: если интерфейсы настроены на режим active или одна сторона на active, а другая на passive — режим EtherChannel будет работать, если обе группы интерфейсов настроить на passive, агрегирования каналов не произойдёт. Нужно помнить, что для организации объединения каналов по протоколу LACP необходимо, чтобы хотя бы одна из групп интерфейсов находилась в состоянии active.
Давайте попробуем ответить на вопрос: если у нас есть соединенные линиями связи свитчи А и В, причем интерфейсы одного свитча находятся в состоянии active, а другого в состоянии auto или desirable, будет ли работать EtherChannel?
Нет, не будет, потому что в сети должен действовать одинаковый протокол – либо PAGP, либо LACP, поскольку они не совместимы друг с другом.
Рассмотрим несколько команд, используемых для организации EtherChannel. В первую очередь вам нужно назначить номер группы, он может быть любым. Для первой команды channel-group 1 mode в качестве option можно выбрать 5 параметров: on, desirable, auto, passive или active.
В подкомандах интерфейса мы используем ключевое слово channel-group, но если, например, вы хотите задать балансировку нагрузки, используется слово port-channel. Рассмотрим, что представляет собой балансировка нагрузки.
Предположим, у нас имеется свитч А с двумя портами, которые соединены с соответствующими портами свитча В. К свитчу В подсоединены 3 компьютера – 1,2,3, а к свитчу А – один компьютер № 4.
Когда трафик перемещается от компьютера №4 к компьютеру №1, свитч А начнет передавать пакеты по обеим линиям связи. Метод балансировки нагрузки использует хеширование MAC-адреса отправителя таким образом, что весь трафик четвертого компьютера будет проходить только по одной из двух линий связи. Если мы подсоединим к свитчу А компьютер №5, благодаря балансировке нагрузки весть трафик этого компьютера будет перемещаться только по одной, нижней линии связи.
Однако это не типичная ситуация. Допустим, у нас есть облако-интернет и устройство, к которому подсоединен свитч А с тремя компьютерами. Интернет-трафик будет направляться к свитчу с MAC-адресом данного устройства, то есть с адресом конкретного порта, потому что это устройство является шлюзом. Таким образом, весь исходящий трафик будет иметь MAC-адрес данного устройства.
Если перед свитчем А расположить свитч В, соединенный с ним тремя линиями связи, то весь трафик свитча В в направлении свитча А устремится по одной из линий, что не соответствует нашим целям. Поэтому нам нужно задать параметры балансировки для данного свитча.
Для этого в команде используется ключевое слово port-channel в режиме глобальной конфигурации.
Если вы хотите посмотреть, какие линки задействованы в канале и какие протоколы используются, то в привилегированном режиме нужно ввести команду show etherchannel summary. Посмотреть настройки балансировки нагрузки можно с помощью команды show etherchannel load-balance.
Теперь рассмотрим все это в программе Packet Tracer. У нас имеется 2 свитча, соединенные двумя линками. STP начнет свою работу, и один из 4-х портов будет заблокирован.
Зайдем в настройки SW0 и введем команду show spanning-tree. Мы видим, что STP работает и можем проверить Root ID и Bridge ID. Использовав ту же команду для второго свитча, мы увидим, что первый свитч SW0 является корневым, так как у него, в отличие от SW1, значения идентификаторов Root и Bridge совпадают. Кроме того, здесь имеется сообщение о том, что SW0 является корневым – «This bridge is the root».
Оба порта корневого свитча находятся в состоянии Designated, заблокированный порт второго свитча обозначен как Alternative, а второй – как root-порт. Вы видите, как STP безупречно выполняет всю необходимую работу, автоматически настраивая соединение.
Активируем протокол PAGP, для этого в настройках SW0 последовательно введем команды int f0/1 и channel-group 1 mode с одним из 5-ти возможных параметров, я использую desirable.
Вы видите, что линейный протокол сначала отключился, а затем снова включился, то есть сделанные изменения вступили в силу и был создан интерфейс Port-channel 1.
Теперь перейдем к интерфейсу f0/2 и введем ту же команду channel-group 1 mode desirable.
Вы видите, что теперь порты верхнего линка обозначены зеленым маркером, а порты нижнего – оранжевым. В данном случае не может быть смешанного режима портов desirable – auto, потому что все интерфейсы одного свитча должны быть настроены одинаковой командой. Режим auto может быть использован на втором свитче, но на первом все порты должны работать в одинаковом режиме, в данном случае это desirable.
Зайдем в настройки SW1 и используем команду для диапазона интерфейсов int range f0/1-2, чтобы не вводить вручную команды отдельно для каждого из интерфейсов, а настроить оба одной командой.
Я использую команду channel-group 2 mode, но могу использовать любое число от 1 до 6 для обозначения группы интерфейсов второго свитча. Поскольку противоположная сторона канала настроена на режим desirable, интерфейсы этого свитча должны быть в режиме desirable или auto. Я выбираю первый параметр, набираю channel-group 2 mode desirable и нажимаю «Ввод».
Мы видим сообщение о том, что был создан канальный интерфейс Port-channel 2, а порты f0/1 и f0/2 последовательно перешли из состояния down в состояние up. Далее следует сообщение, что интерфейс Port-channel 2 перешел в состояние up и что линейный протокол этого интерфейса также включился. Теперь у нас сформировался агрегированный канал EtherChannel.
В этом можно убедиться, перейдя к настройкам свитча SW0 и введя команду show etherchannel summary. Вы видите различные флаги, которые мы рассмотрим позже, и далее группу 1, использующую 1 канал, число агрегаторов также равно 1. Po1 означает PortChannel 1, а обозначение (SU) расшифровывается как S – флаг уровня 2, U – используется. Далее указан используемый протокол PAGP и физические порты, агрегированные в канал – Fa0/1 (P) и Fa0/2 (P), где флаг P указывает на то, что эти порты входят в состав PortChannel.
Я использую те же команды для второго свитча, и в окне CLI появляется аналогичная информация для SW1.
Я ввожу в настройках SW1 команду show spanning-tree, и вы можете увидеть, что PortChannel 2 представляет собой один логический интерфейс, причем его стоимость по сравнению со стоимостью двух отдельных портов 19 снизилась и теперь равна 9.
Проделаем то же самое с первым свитчем. Вы видите, что параметры Root не изменились, но теперь между двумя свитчами вместо двух физических линков имеется один логический интерфейс Po1-Po2.
Попробуем заменить PAGP протоколом LACP. Для этого в настройках первого свитча я использую команду для диапазона интерфейсов int range f0/1-2. Если я сейчас введу команду channel-group1 mode active для включения LACP, она будет отвергнута, потому что порты Fa0/1 и Fa0/2 уже являются частями канала, использующего другой протокол.
Поэтому я должен сначала ввести команду no channel-group 1 mode active и только после этого использовать команду channel-group1 mode active. Давайте проделаем то же самое со вторым свитчем, сначала введя команду no channel-group 2, а затем команду channel-group 2 mode active. Если посмотреть параметры интерфейсов, видно, что Po2 снова включился, но он по прежнему находится в режиме протокола PAGP. Это не верно, потому что у нас сейчас действует LACP, и в данном случае имеет место некорректное отображение параметров программой Packet Tracer.
Для устранения этого несоответствия я использую временное решение – создание другого PortChannel. Для этого я набираю команды int range f0/1-2 и no channel-group 2, а затем команду channel-group 2 mode active. Давайте посмотрим, как это повлияет на первый свитч. Я ввожу команду show etherchannel summary и вижу, что Po1 снова показан как использующий PAGP. Это проблема симуляции Packet Tracer, потому что сейчас PortChannel отключен и у нас вообще не должно быть канала.
Я снова перехожу в окно CLI второго свитча и ввожу команду show etherchannel summary. Сейчас Po2 показан с индексом (SD), где D означает down, то есть канал не работает. Технически PortChannel здесь присутствует, но не используется, потому что с ним не связан ни один порт.
Я ввожу в настройках первого свитча команды int range f0/1-2 и no channel-group 1, а затем создаю новую канальную группу, на этот раз под номером 2, с помощью команды channel-group 2 mode active. Затем я проделываю то же самое в настройках второго свитча, только теперь канальная группа получает номер 1.
Теперь на первом свитче создана новая группа Port Channel 2, а на втором — Port Channel 1. Я просто поменял местами названия групп. Как видите, технически я создал новый Port Channel на втором свитче, и теперь он отображается с корректным параметром – после ввода команды show etherchannel summary мы видим, что Po1 (SU) использует LACP.
Точно такую же картину мы видим в окне CLI свитча SW0 – новая группа Po2 (SU) работает под управлением LACP.
Рассмотрим разницу между интерфейсом в состоянии active и интерфейсом, который всегда находится в состоянии on. Я создам новую канальную группу для свитча SW0 командами int range f0/1-2 и channel-group 3 mode on. Перед этим необходимо удалить канальные группы 1 и 2 командами no channel-group 1 и no channel-group 2, иначе при попытке использовать команду channel-group 3 mode on система выдаст сообщение о том, что интерфейс уже задействован для работы с другим канальным протоколом.
Аналогично поступаем со вторым свитчем – удаляем channel-group 1 и 2 и создаем группу 3 командой channel-group 3 mode on. Теперь зайдем в настройки SW0 и используем команду show etherchannel summary. Вы увидите, что новый канал Po3 уже запущен в работу и не требует никаких предварительных операций, как PAGP или LACP.
Он включается сразу, без отключения и последующего включения портов. Использовав ту же команду для SW1, мы увидим, что и здесь Po3 не использует никакого протокола, то есть у нас создан статический EtherChannel.
Cisco утверждает, что для широкой доступности сетей нужно забыть о PAGP и использовать статический EtherChannel как более надежный способ агрегирования каналов.
Как мы осуществляем балансировку нагрузки? Я возвращаюсь в окно CLI свитча SW0 и ввожу команду show etherchannel load-balance. Вы видите, что балансировка нагрузки произведена на основе MAC-адреса источника source MAC address.
Обычно балансировка использует именно этот параметр, но иногда это не соответствует нашим задачам. Если мы хотим изменить этот способ балансировки, нужно войти в режим глобальной конфигурации и ввести команду port-channel load-balance, после чего система выдаст подсказки с возможными параметрами для данной команды.
Если указать параметр port-channel load-balance src-mac, то есть указать MAC-адрес источника, будет включена функция хеширования, которая потом сообщит, какой из портов, являющийся частью данного канала EtherChannel, должен использоваться для передачи трафика. Каждый раз, когда адрес источника будет таким же, система будет использовать этот конкретный физический интерфейс для отправки трафика.