EtherСhannel в Cisco IOS

Итак, продолжаем наш курс iSindy2, продолжаем говорить про агрегацию портов и рассказываем про то, как это настраивается на CSKA. Начнем с того, что можно настроить агрегацию просто. Просто сказать, что она есть, что мы со своей стороны агрегируем несколько портов в группу, трафик, который приходит из группы, мы обратно в группу не отправляем, а что будет с другой стороны — предполагается, что там все заведомо правильно. Если вы идете по этому пути, вы говорите, что вы безусловно агрегируете несколько портов в одну группу, контроль никакой не проводите, то вы сами несете ответственность за то, что там что-то может пойти не так. А если что-то пойдет не так, то, скорее всего, ваши железки просто перестанут отвечать, и сеть ваша развалится и перестанет корректно работать. Поэтому с безусловной агрегацией обычно все заканчивается не очень хорошо. Но тем не менее возможность такая есть.

Если вы хотите, вы можете настроить эту самую безусловную агрегацию, и тем самым ваша CSKA будет балансировать трафик по обоим интерфейсам с использованием application-based балансировки, но контроль производить не будет. Как это настраивается? Мы заходим на все физические интерфейсы, которые у нас входят в группу. В нашем случае и один, и другой интерфейс. Это, допустим, гигабит 0/0, а этот — гигабит 0/1. Мы на него заходим в конфиге и указываем там команду channel group, дальше номер группы, mode on. Это on означает безусловную агрегацию. Номер группы — это просто локально значимое число, которое должно быть одинаковое на всех интерфейсах, которые входят в эту группу. И вы можете создать несколько групп на устройстве. Допустим, сказать, что одни интерфейсы входят в группу номер 1, другие интерфейсы — в группу номер 2. По сети нигде этот номер не передается. Он, еще раз подчеркну, локально значимый. Когда вы указываете на первом интерфейсе channel group чего-то там, mode чего-то там, создается виртуальный интерфейс port channel с таким же номером, как вы указали номер группы.

В нашем случае мы сделали channel group 1 mode on, и у нас создался виртуальный интерфейс port channel 1. Он поднялся, и трафик, который мы будем направлять куда-нибудь в сторону соседа, мы направляем на самом деле в этот виртуальный интерфейс port channel 1, а дальше он уже физически разбрасывается по одному из двух шнурков, которые в него вошли. Либо по гигабит Ethernet 0/0, либо по гигабит Ethernet 0/1. С точки зрения всех вышестоящих приложений на соседа у нас смотрят уже не два шнурка, а один виртуальный интерфейс. Spanning Tree будет отправлять свои BPDU именно в этот самый виртуальный порт, port channel 1. С точки зрения Spanning Tree у нас будет не два параллельных провода, один из которых надо будет заблокировать, а только один порт. И естественно, учитывая, что трафик одного и того же приложения всегда уходит в один и тот же порт, Spanning Tree BPDU по факту будут бегать всегда только по одному проводу, а по второму они бегать, наверное, не будут.

Дальше. Если вы хотите дать какие-то настройки для агрегированного интерфейса, то вы заходите в контекст interface port channel, в нашем случае 1, и там указываем switchport trunk encapsulation dot1q, switchport mode trunk. Если вы хотите указать, что интерфейсы будут транковые либо что они будут аксессовые, мы это делаем не в настройках физических интерфейсов больше, а в настройке этого самого группового интерфейса. В настройку физики мы больше не лезем никогда и ни за что. Нам больше там делать нечего. Если вдруг вы возьмете и настроите какой-то физический интерфейс так, что его конфигурация будет отличаться от остальных, отличаться от настройки группового интерфейса port channel, то он у вас вывалится из группы, и по факту Cisco его не будет использовать для отправки трафика в групповой интерфейс. Он, возможно, будет висеть отдельно от всех, просто отдельный интерфейс, который не входит в группу, и все. С другой стороны, естественно, надо сделать те же самые действия.

Мы указываем с другой стороны, на другом свитче, на свитче B, тоже гигабит Ethernet 0/2, гигабит Ethernet 0/3. На один и на другой заходим, говорим channel group, чего-то там, mode on. Опять же, поскольку номер группы — это локально значимое число, которое не передается нигде по сети, то мы можем делать с одной стороны группу номер один, с другой стороны группу номер два, никто нам это запретить не может. Также на интерфейсе с другой стороны мы должны дать какие-то настройки. Наверное, мы хотим дать: если мы там с одной стороны trunk настроили, с другой стороны тоже мы должны будем настроить trunk. Указываем switchport trunk encapsulation dot1q, switchport mode trunk. Как обычные нормальные порты, все то же самое делается с port channel интерфейсами. Указания switchport mode access, switchport mode trunk, switchport access vlan, switchport trunk native vlan и все остальное такое. При этом, как уже было сказано, если мы используем безусловную агрегацию,

то мы, как сетевой администратор, будем ответственны за то, что что-то пошло неправильно. Никак наши устройства не проверяют параллельность проводов, которые входят в группу, никак они не проверяют провода на отказ, они просто балансируют трафик между проводами. Если мы хотим проверить, что у нас все хорошо, то мы можем включить LACP на этих интерфейсах, и он разблокирует коммутацию только тогда, когда убедится, что с той стороны действительно одно и то же устройство. Мы будем отправлять LACP PDU на одном интерфейсе, если мы включили LACP, и на другом интерфейсе, если мы включили LACP. И если здесь нам отвечает свитч B и здесь нам отвечает свитч B, то мы говорим: окей, все хорошо, с той стороны действительно одно и то же устройство. Более того, он должен не просто говорить, что я с той стороны свитч B, потому что вдруг у него с его стороны эти порты входят в разные порт-группы. Может же такое быть. Он еще и отвечает специальным magic number,

который уникален для всей группы. Поэтому если мы посылаем в такой порт PDU LACP, и нам возвращается PDU LACP, мы видим, что порт со стороны соседа настроен на работу в определенной группе. Если мы отправляем в другой порт, который с нашей стороны в ту же самую группу входит, и получаем ответ от соседа, что у него magic number будет другой, то получается, что со стороны соседа коммутация будет настроена неправильно, и мы такой порт не разблокируем. В случае если мы хотим включить LACP, глобально процедура настройки EtherChannel, этой самой агрегации портов, выглядеть будет точно так же. Она будет выглядеть как то, что мы заходим на физические интерфейсы, и там вместо channel group 1 mode on указываем channel group 1 mode либо active, либо passive. Можно с обеих сторон active задать, это будет правильно, ничего плохого в этом нет, потому что есть люди, которые считают, что если у нас есть активный, с другой стороны должен быть обязательно пассивный узел.

Нет, они могут быть активны. Active и passive — это про то, кто первый начинает передачу PDU. Если у вас active и active, они оба первые начнут передачу PDU, они будут прекрасно работать в таком режиме. Passive просто не станет отправлять свои PDU до тех пор, пока ему другой активный ничего не пришлет. Важное замечание. Если у вас с одной стороны LACP включился, то с другой стороны его тоже надо обязательно включить. Нельзя сделать так, чтобы с одной стороны у нас был on, статическая агрегация, без какого-либо контроля, а с другой стороны мы бы включили LACP и надеялись, что он там работал. Нет, on не включает ни LACP, ни PAgP. Это статическая агрегация без каких-либо проверок. Если мы с другой стороны включаем LACP, он будет долбиться своими LACP PDU на соседа со статикой и ничего не будет получать в ответ. Поэтому оно так не заведется. У нас есть протокол DTP, там похожая схема. Если мы с одной стороны делаем статический транк,

с другой стороны делаем динамическое согласование — DTP на транковом порту работает, именно на транковом порту. Там он и DTP динамически согласует транк, динамически отвечает на запросы. И у нас есть просто режим транк, который по умолчанию работает. Здесь, если вы включаете статическую агрегацию, у вас на ответы ни LACP, ни PAgP свитч отвечать не будет. Если вы делаете проверку с помощью PAgP, то настройка, опять же, будет выглядеть точно так же. Channel group, дальше мы указываем номер группы. Mode вместо active или passive или on указываем desirable или auto. Термины используются такие же, как в протоколе DTP. У нас там desirable и auto тоже были. Desirable активно пытался согласовать транк, auto был не против того, чтобы согласовывать транк. И здесь та же самая история. Если у вас два desirable с одной стороны — работать будет.

Если будет desirable и auto — работать будет. Два auto между собой не подружатся, они не согласуют работу агрегата на линке. Надо, чтобы хотя бы с одной стороны был desirable. Так же, как и в случае с LACP, то, что вы с одной стороны включаете статическую агрегацию, не означает, что у вас там включается ни LACP, ни PAgP. Поэтому если вы с одной стороны сделали channel group 1 mode on, а с другой стороны сделали channel group 1 mode desirable, у вас ничего не заведется. Вы получается с одной стороны PAgP включили, а с другой нет. Поэтому здесь есть небольшое отличие от протокола DTP. Термины похожи, но с DTP все-таки различия есть. Так. Как проверить, что port channel и что агрегация у нас работает? Здесь надо прояснить термины, которые использует Cisco. Самый первый термин — это EtherChannel. Это фирменная технология Cisco,

которая объединяет каналы в соответствии с 802.3ad, но делает это с использованием хитрой схемы балансировки, которая будет application-based. Cisco говорит: да, мы все делаем по стандарту, но наша фирменная хитрая схема балансировки — она наша фирменная, Cisco'вская. EtherChannel — это как раз 802.3ad агрегация с фирменной Cisco'вской балансировкой. Она называется EtherChannel. EtherChannel — это технология. И port channel — это конкретный виртуальный интерфейс, который образуется после включения EtherChannel на физических портах. Как нам проверить, что агрегированный канал у нас работает, что с ним все хорошо? Во-первых, каждый раз, когда у нас есть какой-то порт, который на железке работает, например port channel 1, мы можем выполнить show interface с названием интерфейса. И нам здесь покажут всякие разные свойства этого интерфейса, в том числе покажут, например, в up ли он или не в up. Если показывается, что интерфейс не в up,

значит что-то там пошло не по плану. В нашем случае мы видим, что интерфейс у нас в up, line protocol в up. Все хорошо, интерфейс работает, связь есть, как минимум один живой интерфейс в этот групповой port channel 1 вошел нормально. Показывается, что у этого интерфейса есть MAC-адрес. Вообще говоря, MAC-адреса нам не сильно нужны на коммутируемых интерфейсах, но если мы будем переключать этот интерфейс в маршрутизируемый режим, то MAC-адрес там нам действительно понадобится. Берется самый большой MAC-адрес из тех портов, которые вошли в группу по факту. У нас есть устройство-коммутатор, у него есть несколько физических интерфейсов. Если у этих физических интерфейсов MAC-адреса разные, то когда мы объединяем их в группу, у port channel будет MAC-адрес совпадать с самым большим MAC-ом живого интерфейса, который вошел в группу. В нашем случае мы видим 5.0.0.0.0.0.3.0.0.0.3. И если вдруг у нас добавится новый интерфейс в эту группу,

MAC-адрес автоматически пересчитается, если это будет нужно. Дальше. Показывается, какие у нас MTU, какие у нас скорости. Здесь показывается скорость — математическая сумма скоростей портов. В нашем случае 2 гигабита в секунду. Мы объединили 2 гигабитных интерфейса, математическая сумма — 2 гигабита. Это не означает, что вы в этот групповой интерфейс можете напихать 2 гигабита трафика, и он обязательно сможет пройти через такой интерфейс. Скорее всего, не сможет. Но, по крайней мере, гигабит вы, конечно, туда напихать можете. Скорее всего, реальность будет где-то посерединке. Если вы там гигабит 100, гигабит 200 будете туда отправлять, он пройдет нормально. Гигабит 900 уже, скорее всего, будет захлебываться. Дальше. Показываются, какие порты входят в эту группу. Здесь у нас показывается, что 2 интерфейса, гигабит 0/0 и гигабит 0/1, в группу вошли. И если вдруг мы захотим посмотреть, у нас есть такая сводная табличка — show etherchannel protocol.

Она покажет список всех интерфейсов, на которых у нас есть корректная работа. Показывает, что у нас есть интерфейс номер 1, который проверяется с помощью протокола LACP. Простенькая картинка, но тем не менее она довольно полезная. Она показывает вам, как настроены те или иные групповые интерфейсы в части проверки контроля сборки. Есть более продвинутые команды. Если вдруг вы посмотрели, и вам недостаточно той диагностики, что какие-то порты входят в группу и они проверяются с помощью того или иного механизма, есть диагностика show etherchannel summary. Она дает нам конского размера легенду. И тут в самом конце одна строчка, которая нас по факту будет интересовать. Строчка с данными. Показывается номер группы, номер port channel. Показывается название интерфейса. Po1 — это port channel 1. И дальше в скобочках SU. По легенде S — это значит, что это Layer 2 интерфейс,

что это коммутируемый интерфейс Ethernet. Кадры, которые приходят на этот групповой интерфейс, мы отправляем на таблицу коммутации. И U — это то, что он работает. In use. С ним всё хорошо, он действует. Действительно, коммутация осуществляется. Опять же, напоминают нам, что у нас используется, например, протокол LACP. И показывается, какие порты входят в группу. И показывается по каждому порту его статус. Напротив Gigabit 02 показывается P. Опять же, по табличке находим, что P — это Bundled In Port Channel. То есть с интерфейсом всё хорошо, он в группу вошёл. А вот Gigabit 03 показывается буквой D. И это D означает down. То есть у нас что-то с интерфейсом случилось, и он выключился. Как раз в этом случае мы понимаем, что у нас на этом интерфейсе Gigabit 02 в группу вошёл, и Gigabit 03 тоже в группу вошёл. Но он не работает, потому что там, например, линка нет. И в этой ситуации в такой интерфейс, который по факту работает в деградированном состоянии,

мы не можем напихать больше гигабита трафика. Если вдруг вам и такой диагностики не будет достаточно, есть более продвинутая диагностика. Это show EtherChannel port-channel. Здесь уже прямо совсем много всякого. Это уже прямо детальный разбор. И вряд ли вы когда-то туда полезете, потому что на экзамене вас туда не заставят лезть, а в жизни, скорее всего, у вас таких проблем не будет, которые потребуют залезать на такую глубину. Но тем не менее в учебниках команда есть, и разобраться с ней как минимум стоит. Show EtherChannel port-channel показывает по каждой группе, во-первых, как называется интерфейс, во-вторых, покажет, сколько живых портов в этой группе есть по факту. Показывает, что у нас сейчас один живой порт. Дальше показывает протокол, который используется для проверки, если нужно. Включена ли port security на этом интерфейсе. В принципе, port-channel может быть с port security, если вы с помощью port-channel смотрите, например, на роутер

или на конечного абонента. На самом деле вам может показаться, что это немножко странно, но в дата-центровых применениях у нас довольно часто бывает такое, что на свитче у нас много-много-много портов, и дальше эти порты смотрят на серверá. И на серверах тоже много портов. Там четыре, например, — достаточно частое явление. В этом случае у вас там в стойке два свитча стоит, и первый и второй порты одного свитча и первый и второй порты другого свитча смотрят на этот самый сервер. То есть четыре порта. Примерно так это выглядит. И соответственно рядышком второй сервер, до него тоже два порта от одного свитча, два порта от другого свитча. Рядом третий сервер, два порта от одного свитча, два порта от другого свитча. И получается, что эти порты, допустим, соединены в стек, получается один виртуальный свитч, и все эти четыре порта будут объединены в одну такую группу. И на сервер вы вполне можете включить port security. Но если мы вспомним механизм port security, как он вообще работает, мы вспомним, что если у вас линки будут между коммутаторами, там port security не включается. Поэтому если то, что мы с вами разбираем, — мы берём два свитча, которые связаны параллельными проводами, и эти параллельные провода объединены в группу, — то port security на таких интерфейсах включать, конечно же, не нужно.

И да, по умолчанию port security никто не включает, вот у нас он disabled. Дальше. После того как мы выяснили, сколько там по факту портов, здесь показывается, какие это порты — вот Gigabit 0/2, и показывается, что с ним всё хорошо, он активен, он нормально работает. Если у вас один порт, то количество бит энтропии, которое вам необходимо для каждого кадра, чтобы определить, в какой конкретно порт кадр посылать, — это будет ноль. Дело в том, что если у вас один порт, то балансировщик в любом случае примет одно-единственное решение — посылать кадр именно в этот Gigabit 0/2 порт. Но если у вас будет, например, Gigabit 0/3 рядышком, который тоже в этом же интерфейсе будет, и он тоже будет active, соответственно, в этом случае вам понадобится один битик энтропии, чтобы балансировщик посмотрел на кадр и с некоторой вероятностью сказал либо нолик, либо единичка. И тогда трафик у вас будет направляться либо в Gigabit 0/2 порт, либо в Gigabit 0/3 порт.

Как правило, балансировщик будет смотреть на IP-адреса, на MAC-адреса в кадрах, то есть если он видит, что внутри кадра лежит IP-пакет, он может заглянуть в IP-пакет и посмотреть на IP-шники. Если он увидит TCP или UDP внутри, он даже дополнительно может посмотреть TCP-шный, UDP-шный заголовок и заглянуть в номера портов. Но это только на самых жирных свитчах, на 4500-х, 6500-х каталистах, а на маленьких 2960, там 3750, 3850, он не может такое сделать. И соответственно он смотрит на эту пачку IP-адресов, MAC-адресов. Как правило, он их всех XOR-ит, перемешивает между собой, то есть исключающим ИЛИ из кучи различных полей, в которые он может заглядывать, формирует какое-то одно поле и берёт от него последние несколько битиков. Если вам нужен один бит энтропии, берёт самый последний битик. То есть, условно говоря, проверяет: если IP-шники одинаково чётные или одинаково нечётные, то он трафик направляет в левый порт. Если IP-шник один чётный, другой нечётный, направляет его во второй порт.

Это я так, на примере. Короче говоря, если у вас два порта, нужен один бит энтропии. Если у вас 3–4 порта, вам нужно больше бит энтропии. Как эта штука будет работать? По факту в любом случае у вас будут считаться последние 4 битика от этого конгломерата данных, на которые смотрит балансировщик. Он смотрит на MAC-адреса, на IP-адреса, на порты. Дальше он всё это дело XOR-ит. Получает какую-то достаточно монолитную колбасу. И у этой колбасы все битики сравнительно случайны. Он берёт от этой колбасы последние 4 бита и говорит, что если у него получается результат 0-0-0-0, дальше 0-0-0-1, 0-0-1-0, 0-0-1-1, вот он их выписывает, 1-1-1-0, 1-1-1-1. У него получается 16 вариантов. И дальше он заносит в эту табличку возможные линки, которые у вас есть. То есть если у вас есть линк только один, Gigabit 0/2, он напротив каждого пишет Gigabit 0/2, Gigabit 0/2 и так далее.

Если у вас линков больше, чем один, например, 2 или 3, то он их выписывает прямо в цепочку. Gigabit 0/2, Gigabit 0/3, Gigabit 0/4. Потом снова Gigabit 0/2, Gigabit 0/3 и Gigabit 0/4. И так у него получается, что он размазывает достаточно равномерно возможные исходы работы балансировки — Gigabit 0/2, Gigabit 0/3, Gigabit 0/4 — по всем 16 возможным вариантам последних 4 битиков результата этого самого XOR. И мы берём какой-то кадрик, смотрим на то, какие у него последние 4 бита, выясняем, что это последние 4 бита — 0-0-1-0. Смотрим, куда отправить трафик. Выясняем, что трафик надо направить в Gigabit 0/4 интерфейс. Какие бы ни были эти самые последние 4 бита, конечный вариант, куда посылать трафик, будет сравнительно случайным, сравнительно равномерным. Если хотите — будет распределение трафика по интерфейсам. Но есть нюанс. Эта штука будет ещё неплохо работать,

когда интерфейсов, например, 2 или когда интерфейсов 3. Но если у нас их, например, будет 7, то получится, что мы скажем, что направляем трафик в первый порт, второй порт, третий порт, четвёртый порт, пятый, шестой, седьмой. Дальше снова первый, снова второй, снова третий, снова четвёртый, снова пятый, снова шестой, снова седьмой. Так 14 различных исходов мы прошли. Потом первый и второй. Это 16 исходов. Здесь у нас 0-0-0-0. А здесь у нас 1-1-1-1. И получается, что с большей вероятностью трафик попадёт в первый порт или во второй порт, чем в любые другие, которые у нас есть — третий, четвёртый, пятый, шестой или седьмой. Поэтому хорошо это будет работать тогда, когда количество ваших портов будет делителем числа 16. То есть если у вас два порта, трафик будет размазываться сравнительно неплохо. Если у вас три порта, трафик будет похуже размазываться,

потому что какой-то порт получит гипотетически меньшее количество трафика. 4 — нормально. 8 — тоже нормально. Больше чем 8 сделать тоже нельзя, потому что если у вас будет больше чем 8, то тоже начинает плохо работать эта самая схема балансировки. Допустим, 9 портов у вас будет. Какие-то порты 1, 2, 3, 4, 5, 6, 7 будут получать вдвое больше трафика, чем все остальные, вплоть до 9. Поэтому для того чтобы это всё работало хорошо, количество портов, которые можно включить в одну группу на Cisco, будет не больше 8. Это та самая фирменная технология EtherChannel, которая у Cisco так называется. Вы можете объединить в группу не больше 8 портов. Хорошо это работает, когда количество портов у вас кратно степени двойки. То есть более строго говоря, когда 16 делится на количество портов нацело. Но это будет степень двойки.

И в принципе, если у вас количество портов не кратно степени двойки, не так сильно будет Cisco от этого страдать, как может показаться. Но при этом может быть такое, что трафик у вас будет загружаться не очень равномерно. Балансировку вы можете настроить. Балансировку можно настроить только для исходящих кадров. То есть если у вас есть два свитча, которые связаны двумя проводами, вы у себя настраиваете, как выполняется балансировка с одной стороны. При этом вас абсолютно не волнует, как настроена балансировка на соседе. То есть вы со своей стороны настраиваете балансировку так, сосед может использовать совершенно другой механизм балансировки. Вам на это наплевать. Дальше. Балансировку можно настроить только глобально на всём устройстве целиком. То есть нельзя сказать, что у нас есть один port-channel, который смотрит на одного соседа, другой port-channel, который смотрит на другого соседа, третий, который смотрит на третьего, и во всех трёх разных port-channel у нас разные механизмы балансировки используются.

Можно только глобально настроить. Настраивается эта команда в конфиге глобальном: port-channel load-balance. И дальше один из нескольких вариантов балансировки. Если вы по умолчанию используете Cisco, то она по умолчанию использует вот эту штуку — src-dst-ip. То есть она берёт MAC-адреса отправителя и получателя в кадре. Если видит IP, внутри лежит 0x0800 в EtherType, смотрит на IP-адреса и тоже берёт их в оборот, XOR-ит всё это вместе и берёт последние биты от этого самого XOR-результата. Если вдруг вы хотите, вы можете поменять эту схему балансировки, сказать, что биты надо брать не по MAC и IP-шникам, а по чему-нибудь ещё. Например, вы можете сказать — только по MAC-у источника. В этом случае вы выбираете режим src-mac. Или только по MAC-у получателя. То есть не надо XOR-ить ничего ни с чем. Вы просто берёте MAC получателя, берёте от него последние биты.

И если вы хотите, вы можете в этом случае выполнять балансировку только по последним битам MAC. Можно сказать — возьмём MAC и IP-шник получателя. Как правило, если вы берёте IP-шник получателя, то MAC там всегда одинаковый. То есть это MAC либо обладателя этого самого IP-шника, либо MAC шлюза. Поэтому да, dst-ip — это, можно сказать, XOR MAC и IP-адреса, но по факту только IP-шник там будет влиять на что-то. Или если вас интересует IP-шник источника, тоже, соответственно, берётся MAC и IP-шник. Но при этом, если мы говорим про IP, MAC-и там будут всегда одинаковые в любом случае. И можно взять только MAC-и, source и destination, про-XOR-ить между собой и IP-шники не брать. Если говорить про 4500-е и 6500-е свитчи и более новые в тех линейках, то можно дополнительно ещё взять порты TCP и UDP. Если у вас такой свитч, вы просто там вопросиком посмотрите, как это делается.

Смысл в том, что да, вы можете выбрать режим балансировки. По умолчанию выбрана балансировка по IP-адресам и MAC-адресам, если у вас не IP внутри, то в этом случае берутся source и destination MAC. Вот так работает всё это дело на Cisco. Если мы переведём port-channel в L3-режим, достаточно ли просто перевести интерфейсы-участники в маршрутизируемый режим? Нужно ли что-то дополнительное? Вы должны будете и интерфейсы-участники, все физические, перевести в no switchport, и сам интерфейс port-channel перевести в no switchport. Это такой небольшой нюанс, который связан именно с реализацией на Cisco в актуальных IOS. Если вдруг вы будете это делать, то я рекомендую сначала пройти курс по свитчингу. Там мы про port-channel говорим чуть более детально. Потому что там есть небольшие аспекты, которые надо знать перед тем, как переводить порт из одного режима в другой. В частности, вы не можете перевести уже имеющийся port-channel

из коммутируемого режима в маршрутизируемый и наоборот. То есть это надо делать только при создании интерфейса, при задании настроек для нового интерфейса. Так, давайте попробуем это всё дело сконфигурировать. Итак, мы должны будем сейчас настроить нашу пару интерфейсов, которые смотрят с нашего маленького свитча двумя интерфейсами на центральный свитч. Я сейчас, для того чтобы показать, какие это будут интерфейсы, сделаю следующее приготовление. conf t. На центральном свитче я укажу CDP timer 5, CDP holdtime 10. На центральном свитче я задал настройки CDP — как можно быстрее отправлять пакетики, как можно быстрее забывать про старые пакетики, которые отправлялись. Сделал я это для того, чтобы сейчас переименовать устройство,

чтобы оно называлось не просто switch, а hostname CoreS. Если бы я не поставил таймеры CDP на минимум, то дефолтные таймеры — 3 минуты holdtime — привели бы к тому, что в течение 3 минут после переименования пакетики от имени switch всё ещё показывались бы в таблице соседей на всех остальных свитчах. Сейчас я переименовал CoreS. И за счёт того, что таймеры были выставлены в минимальное значение, все остальные свитчи уже через 10 секунд перестали помнить то, что какой-то switch к ним приходил. И соответственно я сейчас могу взять и на маленьком свитче — enable, conf t. Нет, не conf t. Show CDP neighbors. Посмотреть список соседей. И вот я вижу, что да, у нас есть два интерфейса, которые смотрят на центральный свитч CoreS. Это мой интерфейс Ethernet 0/1 и Ethernet 0/3.

Соответственно, если мы хотим, Мы можем объединить наши два интерфейса в одну группу. Чтобы это сделать, нужно будет сначала выполнить ряд предосторожностей. Выполнить ряд действий, которые будут больше предосторожностью. Дело в том, что мы на курсе по свитчингу будем разбирать эту штуку. На цисках по умолчанию работает такой механизм, как Ether Channel Guard. Если мы на живых интерфейсах, которые входят в группу, получаем на обоих интерфейсах спанинг-тричные BPDU-шки, у которых номер порта разный, это будет означать, что сосед нам отправляет эти самые BPDU-шки, не зная про то, что с нашей стороны настроена групповая настройка. И у него, соответственно, не может быть такого, чтобы два разных интерфейса отправляли спанинг-тричные BPDU-шки, если они включены в одну группу. Это такая фирменная цисковская штука.

Если вдруг такие BPDU-шки на двух разных интерфейсах, которые входят в одну группу, будут получены, то вся группа будет пристрелена. И она упадёт в err-disable, и ничего хорошего нам от этого не будет. Поэтому для того, чтобы всё было хорошо, мы сейчас должны будем сделать следующее действие. Мы должны будем выключить интерфейсы, которые есть у нас. Это можно делать вместе со мной. conf t. Мы указываем, какие интерфейсы мы хотим выключить. interface range Ethernet 0/1, Ethernet 0/3. Я пользуюсь макросом interface range для того, чтобы одинаково настраивать сразу два интерфейса. Выключаем их как мера предосторожности, чтобы не словить неприятные последствия в виде Ether Channel Guard, который нам переведёт оба интерфейса в err-disable. Дальше. Интерфейсы выключились. Указываем, что эти интерфейсы будут включены в одну большую группу.

channel-group 1. mode. Дальше мы можем выбрать, какие у нас тут варианты есть. Либо мы можем сказать channel-group 1 mode on. Это значит, что включаем балансировку, но не проверяем контроль сборки вообще никак. Либо мы можем сказать channel-group mode active или passive, тем самым включив LACP. И в этом случае, если мы указываем active, то мы отправляем LACP PDU-шки сразу. А если passive, то мы только ждём, пока от соседа LACP PDU-шки придут. Соответственно, мы можем воспользоваться PAgP и сказать channel-group 1 mode desirable или channel-group 1 mode auto. Я предлагаю попробовать включить, например, channel-group 1 mode desirable. Попробуем PAgP. Если я правильно помню, у нас не совсем корректно работает на нашем стенде LACP по неизвестной причине. Поэтому PAgP.

Мы со своей стороны на обоих интерфейсах задали channel-group 1 mode desirable. Для того, чтобы это работало, надо с другой стороны настроить channel-group 1 mode desirable или channel-group 1 mode auto. Надо будет, чтобы оба соответствующих интерфейса были корректно настроены. Давайте проверять, как там это всё настроено. interface range Ethernet 0/0 и Ethernet 2/0. Это те интерфейсы, которые смотрят на первый комплект. channel-group 1 mode. Давайте тоже desirable сделаем. Это пачка портов, которые смотрят на первого соседа. Теперь то же самое делаем Ethernet 0/1, Ethernet 2/1. channel-group 2 mode desirable. Так, на меня, на восьмой комплект, смотрят Ethernet 1/3 и Ethernet 3/3.

channel-group 8 mode desirable. Я создал три порт-группы на центральном свитче. Соответственно, у нас все интерфейсы, которые входят в эти самые группы, сначала выключились, а потом они потихоньку включаются. Это особенность именно PAgP в том, что PAgP может включить интерфейсы, даже если на них никто не ответил. Эти интерфейсы, правда, не входят в группу. Они в таком индивидуальном режиме будут. Но как только PAgP с той стороны прибежит, он с этими интерфейсами поиграет немножко и заставит их работать именно в групповом режиме. Видно здесь, что у нас переходят в up именно физические интерфейсы, но логические интерфейсы — Port-Channel 1, Port-Channel 2, Port-Channel 8 — они пока в down. И если мы закажем show etherchannel summary,

нам покажут, что у нас интерфейсы неактивные. И это individual, stand-alone интерфейс, просто отдельный интерфейс, никоим образом не участвующий во взаимодействии. А заодно здесь показывается, что Port-Channel 1 уже завёлся, и, видимо, кто-то на первом комплекте уже разблокировал свой интерфейс. Давайте я тоже тогда возьму на маленьком свитче, скажу no shutdown. Разблокируем интерфейс, он переходит в up, поднимается Port-Channel, у нас согласовался PAgP, и здесь пробегает сообщение, что Port-Channel 8 у нас согласовался. Второй комплект, видимо, всё ещё не работает. Вот так это выглядит на центральном свитче, первый комплект и восьмой комплект работают. В каждом комплекте у нас два порта. С обоими портами всё хорошо,

буковка P означает, что с ним корректно идёт работа. И на маленьком свитче, если взять и посмотреть show etherchannel summary, здесь покажется такая история, что у меня одна группа, с этой группой всё в порядке, интерфейс коммутируемый, находится в up, протокол проверки контроля сборки PAgP, интерфейс Ethernet 0/1, интерфейс 0/3 корректно работает. Если мы захотим, мы можем проверить и более детальную работу этого интерфейса. show etherchannel port-channel. Такая команда. Она покажет, что у нас тут есть. У нас есть два интерфейса. Они находятся в режиме проверки PAgP, настройка на них desirable, и у нас используется для балансировки по ним один бит энтропии. На самом деле один бит энтропии

нам минимум нужен, а по факту используются все четыре бита. Поэтому здесь показывается ноль битов. Это тяжёлое наследие древних времён, когда показывалось, сколько действительно бит энтропии берётся. Сегодня берётся четыре бита. И здесь показывается, что с PAgP всё хорошо. Port-Channel in use. Всё согласовано, всё хорошо работает. Последнее событие, которое происходило, было минуту назад, минуту девять секунд назад. Это Ethernet 0/3 входил в группу. Они одновременно сработали, они одновременно вошли в группу. Теперь. После того, как мы объединили интерфейсы в один логический интерфейс, с точки зрения Spanning Tree, у нас нету двух отдельных линков. У нас есть один линк, который называется Port-Channel. Активная топология Spanning Tree теперь состоит не из двух проводов, а из одного. show spanning-tree vlan 1. Он показывает, что есть два физических интерфейса, которые просто отдельно витают в облаке. И есть интерфейс Port-Channel 1,

который принимает BPDU-шки от root. Если у вас root, он будет отправлять BPDU-шки. Это не отдельные два интерфейса, из которых один должен быть заблокирован, а другой разблокирован. Это именно один интерфейс, который просто смотрит на соседа. Если бы у меня не было в этом случае Port-Channel, Spanning Tree бы мне заблокировал один из этих интерфейсов. Он бы сказал, что на одном интерфейсе у меня приходят BPDU-шки вкусные, а на другом интерфейсе тоже приходят BPDU-шки вкусные. И что мы делаем, когда приходят вкусные BPDU-шки? Мы выбираем один порт, который надо оставить. А на остальных портах мы блокируем коммутацию. Здесь мы ничего не блокируем, потому что у нас один root-овый порт, никаких больше BPDU-шек не приходит, поэтому всё хорошо. Так, это что касается агрегации на Cisco. В принципе, если бы мы захотели, мы могли бы поднять LACP, мы могли бы включить безусловную агрегацию,

но работа там выглядела бы точно так же, как и в случае с этим интерфейсом. Если мы захотим, мы можем на этом интерфейсе прописать какие-то настройки, включить транк, например, conf t, interface port-channel 1. Так, так он пишется, port-channel 1. И здесь указать switchport... Ой, перебор. switchport access vlan 10. И в этом случае настройки реплицируются автоматически на все физические свитчи. Здесь нам сразу CDP наябедничал, что у нас что-то тут плохо, потому что у нас не совпадают настройки, и как следствие немедленно надо разорвать этот самый интерфейс, потому что там всё плохо. Давайте уберём эту настройку. Так, убрали настройку,

интерфейс пересобрался, и здесь уже всё хорошо. За счёт того, что у нас используется фирменный цисковский PAgP, фирменный цисковский PAgP умеет от фирменного цисковского CDP забирать информацию, и, как следствие, когда он обнаружил, что у нас несовпадение настроек VLAN, что с одной стороны на этих VLAN у нас используется первый, с другой стороны неразмеченный VLAN аксессорный будет десятый, он обнаружил это и разорвал нам подключение. Но если вы выключите CDP, то проблем здесь уже не будет. Давайте так и сделаем, кстати. no cdp enable. А, это на Port-Channel. no cdp run. Я выключил CDP вообще глобально, и сейчас повторю смертельный фокус. Включаю access vlan 10. Так, это я на физических интерфейсах сделал.

Это, конечно, ошибка. На физических интерфейсах нельзя давать настройки, которые не совпадают с Port-Channel. Сейчас я покажу, что получилось. В итоге я сейчас ошибся. Вместо того, чтобы зайти на интерфейс Port-Channel 1, я зашёл на interface range Ethernet 0/1, 0/3. Смотрите, show run interface Ethernet 0/1, 0/3 и Port-Channel 1. Так. В настройке физических интерфейсов я сделал эту команду. Одна, вторая. И в настройке логического интерфейса Port-Channel этой команды нет. У нас идёт рассогласование. Настройка физики не совпадает с тем, что у нас в настройке логики есть. И, как следствие, Cisco отказывается включать что Ethernet 0/1, что Ethernet 0/3 в Port-Channel 1. Для того, чтобы это поправить, надо, чтобы конфигурация всех интерфейсов совпадала. Либо чтобы, если вы даёте какие-то настройки, вы бы их давали на интерфейс Port-Channel 1.

В этом случае он конфигурацию автоматически обновит на физических интерфейсах, которые включены в группу. Так, interface Port-Channel 1. Я на нём даю настройку switchport access vlan 10. Она теперь согласуется с настройкой физических интерфейсов. Физические интерфейсы могут войти в группу. И у нас сейчас должно пробежать сообщение, что всё хорошо, PAgP обратно собрался. Это на самом деле сам Ethernet 0/1 теперь совместим, Ethernet 0/3 теперь совместим, Port-Channel 1 теперь пошёл в up, и do show run interface po1. На нём конфигурация теперь совпадает с физикой. Если я захочу дать какие-то настройки, которые будут применимы к этому самому Port-Channel целиком, то я должен их давать именно на интерфейсе Port-Channel, а не на физических интерфейсах, как я только что сделал. Сейчас я 20-й VLAN задал на Port-Channel. Ничего не произошло толком.

У нас физика нормально работает. Интерфейс, правда, упал-поднялся, но это временное явление. И теперь на физических интерфейсах этот самый 20-й VLAN прописан автоматом. show run interface ethernet 0/1. На нём эта штука появилась автоматом. Раньше было вот так. Если мы хотим давать какие-то настройки, мы должны давать их именно на Port-Channel интерфейсе. Никогда не на физическом интерфейсе, иначе будет то, что только что получилось у меня, а на виртуальном интерфейсе Port-Channel. Даём на нём, и всё у нас хорошо работает. Это всё, что хотелось рассказать про Port-Channel. Они довольно простые, как и всё в рамках нашего курса ICND1 и ICND2. И в реальности их довольно часто можно будет встретить в продакшене. Это очень простой способ. Легко и непринужденно повысить полосу пропускания,

которой вам, возможно, будет недостаточно для каких-то задач. Это намного дешевле, чем покупать новые свитчи с поддержкой более быстрых интерфейсов. Если вам нужно немножко повысить скорость, вы уже упираетесь, например, в гигабит, и вам, в принципе, полутора гигабит было бы достаточно. Берёте два интерфейса, соединяете в один. Логически вы получаете те самые полтора гигабита. Если вам нужно два гигабита, возьмите три-четыре линка, соедините их, и вы получите два гигабита. Но если вам нужно вместо одного гигабита сразу пять получить, то дешевле уже будет просто поменять свитчи и поставить десятигигабитный порт, производительности которого будет достаточно. Если говорить про формулировки Cisco на экзаменах, то корректно будет утверждать, что интерфейсы EtherChannel, эти самые port-channel'ы, это механизм не столько повышения полосы пропускания, сколько механизм повышения надёжности работы сети, потому что неизвестно, как этот самый EtherChannel разбросает трафик по интерфейсам. Может быть, он загрузит один линк в стопроцентную нагрузку, а все остальные будут лежать незагруженные.

Такое бывает. Поэтому в случае, если вдруг один интерфейс из группы выбылится, и у нас есть LACP, например, или PAgP, то остальные интерфейсы нагрузку подхватят и будут все корректно работать. Падение одного интерфейса станет незамеченным для сервисов. Но в то же время гарантировать, что обязательно повысится полоса, мы при этом не можем. Пожалуй, это всё, что стоит знать на уровне ICND2 для экзамена, по крайней мере, про EtherChannel'ы. Так что давайте переходить к следующей теме. Продолжение следует...