Агрегация портов

Следующий наш модуль в рамках курса ICND2 будет посвящен тому, что в некоторых случаях Spanning Tree запускать нецелесообразно. Spanning Tree — протокол не очень приятный в использовании. Он, конечно же, защищает нас от петли. Но он защищает нас от петли тем, что блокирует коммутацию сначала везде, а потом потихоньку разблокирует эту самую коммутацию там, где ему кажется это безопасным. Если мы говорим про медленный Spanning Tree, он разблокирует каждый порт в течение 30 секунд. Если мы говорим про быстрый Spanning Tree, он может либо с помощью Edge-портов разблокировать коммутацию на порту сразу, но тогда мы обещаем, что там BPDU-шек не будет, либо мы говорим, что на порту коммутация разблокируется только после того, как мы убедимся, что там всё хорошо. На быстром Spanning Tree это либо с помощью Proposal/Agreement между свитчами, если у нас оба свитча быстрые, либо с помощью всё тех же таймеров на 30 секунд — выключать коммутацию на дважды Forward Delay таймер.

В результате Spanning Tree действительно защищает вас от петли, но в некоторых ситуациях он может потушить сетку на 30 секунд, даже если это быстрый Spanning Tree. А в некоторых особенно неудачных случаях даже быстрый Spanning Tree может положить сетку на более долгий срок, например, на те самые 50, а то и 60 секунд. Для того чтобы от этого защититься, возникает острое желание как-нибудь сделать так, чтобы Spanning Tree у нас в сети не выключал коммутацию насовсем. Это очень удобно делать с использованием PortFast и BPDU Guard на абонентских портах. Мы просто говорим, что если вдруг у нас формируется петля с использованием абонентского порта, не надо пытаться понять, как выгоднее через петлю добраться до корневого коммутатора. Надо пристрелить абонентский порт. И дальше уже не возникает событие смены топологии, если BPDU Guard пристрелил порт. Просто всё продолжает работать как ни в чём не бывало. У абонента прерывается связь. А почему она прерывается? Потому что он там что-то такое соорудил у себя,

что вызвало пристреливание порта. Как правило, это хорошо заметно. Либо там новый свитч поставил абонент какой-то нелегитимный, либо забриджевал свои порты на компьютере. Допустим, взял и в операционной системе Windows выделил Wi-Fi и Ethernet адаптеры, сказал объединить их в бридж. И получается, в этом случае BPDU-шки будут приходить, и такой порт будет пристрелен. В любом случае нездоровая активность на порту вызывает пристреливание порта. А что касается варианта, если у нас петля устроена с абонентским портом, там всё понятно, там BPDU Guard нас спасает, и Spanning Tree как таковой особо становится не нужен. Но что делать, если у нас есть штатная петля между коммутаторами? Не просто она там случайно образовалась — она случайно там образоваться не может между коммутаторами. Она образовалась там нарочно, потому что мы хотим повысить отказоустойчивость работы сети.

И в случае, если у нас вдруг, допустим, отваливается какой-то интерфейс от абонентского свитча до ядра или до дистрибьюшена, то чтобы Spanning Tree перестроил топологию, трафик всё-таки ходил бы в сторону дистрибьюшена, но уже, допустим, по другому линку. В таких ситуациях Spanning Tree может нас защитить от петли, может защитить даже от той петли, которую мы искусственно внесли, но при этом он приводит сеть к состоянию, когда она работает не на полной своей способности. У нас по факту трафик мог бы ходить, допустим, через два порта, а Spanning Tree взял и один пристрелил. И получается, трафик ходит только через один порт из двух. Если мы проложили четыре одинаковых линка, допустим, до дистрибьюшена, Spanning Tree всё равно скажет: извините, должен остаться только один. Один оставил, три пристрелил. И тем самым получается, что Spanning Tree не очень экономный протокол в части полосы пропускания. Он нас действительно защищает от петли, хоть медленно, хоть быстро,

но при этом он блокирует линки, которые формируют эту самую петлю. Если мы умышленно устраиваем петлю, то мы хотим зачастую, чтобы трафик шёл через все линки одновременно. Один из способов повысить полосу пропускания, проложив несколько параллельных линков между коммутаторами, — это агрегация каналов. Это альтернативный подход. Мы не используем Spanning Tree, мы используем другой механизм, с помощью которого коммутаторы будут препятствовать негативным последствиям возникновения петли. Чем хорош Spanning Tree? Тем, что он не даёт развиться трём проблемам, которые возникают в петле. Это широковещательный шторм, это нестабильность базы MAC-адресов, и это множественная доставка кадров. Если у нас есть два параллельных провода,

которые именно параллельны, идут от одного коммутатора до другого, мы можем, немножечко изменив логику коммутации, добиться того же самого эффекта, что у нас не будет проблем, вызываемых этой самой петлёй. И логика эта будет вот какая. Мы объявляем некоторые интерфейсы, которые параллельно смотрят на соседнюю железку, членами одной большой группы. Мы говорим: этот интерфейс групповой, и этот интерфейс групповой, и они оба объединены между собой. В этом случае, если какой-то кадр отправляется по одному из интерфейсов, которые формируют такую группу, другой узел обратно в тот же самый групповой интерфейс, в групповой интерфейс той же самой группы трафик отправлять не будет. Когда у нас кадр приходит на порту, мы не отправляем копию этого кадра на все порты, кроме порта источника, и кроме тех же самых портов, которые формируют группу источника. В таком случае получается, что у нас,

несмотря на то что петля визуально есть, трафик обратно в петлю никогда не заворачивается. Какой бы трафик это ни был, Unicast, Broadcast, если он пришёл по одному проводу, формирующему группу, обратно в другой провод из этой же группы он тоже не отправляется. То же самое правило, что мы не отправляем обратно кадры в порт источника, только немножко более расширенно — в ту же группу, где сидит порт источника. При этом мы можем одновременно трафик отправлять по двум разным каналам. Просто это должны быть разные кадры. Один кадр отправляем в один канал, другой кадр в другой канал. И по факту в сторону соседа можно отправлять трафик по двум разным шнуркам на полной скорости. Если у нас два гигабитных шнурка, гипотетически мы можем до гигабита каждый шнурок загрузить. Насколько у нас получится это сделать — это другой отдельный вопрос. Логика агрегации портов заключается в том, что мы обратно не отправляем кадр в тот порт, который является членом группы,

из которой пришёл кадр. Эта штука стандартная. Она описана в стандарте 802.3ad и 802.3ax. И многие вендоры у себя умеют её реализовывать. Отдельный вопрос заключается вот в чём. Если у нас есть коммутатор, который может отправлять кадр либо в один канал, либо в другой, если у нас два канала формируют одну и ту же группу, в какой конкретно канал отправить каждый конкретный кадр? У нас есть какой-то кадр, который надо отправить в сторону соседнего свитча-получателя. Куда мы его отправляем? То ли в один линк, то ли в другой. И здесь возникают варианты. Первый вариант — можно взять и отправить всё в один и тот же линк. А в другой ничего не отправлять и ждать того, чтобы первый линк помер. Эта штука достаточно простая.

Она не требует никакой специальной логики. Но, естественно, производительность такого группового интерфейса будет равна производительности одного линка. Можно сказать: давайте мы будем балансировать кадры. Половину кадров отправляем на один интерфейс, половину кадров на другой интерфейс. В этом случае можно добиться повышения производительности. Не сказать, чтобы эта производительность была прям гарантированно удвоена, если у нас два линка формируют группу. Она будет повыше, конечно, чем производительность одного интерфейса, но она может даже гипотетически вплотную приблизиться к двойной производительности одного интерфейса, если мы формируем группу из двух одинаковых интерфейсов. Но нюанс заключается в том, что гарантированно выбрать 100% полосы пропускания на обоих интерфейсах мы при этом всё равно не сможем. Потому что если у нас чётные пакеты направляются вверх, нечётные вниз, они всё равно будут так или иначе немножко различаться по размеру.

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

или между тремя, между четырьмя интерфейсами, которые параллельно протянуты между двумя коммутаторами? Самый простой вариант, как уже говорилось, Active/Backup. Мы выбираем один интерфейс, весь трафик направляем по нему, а если он отказывает, то переключаемся на какой-то другой. Практически эту же схему вам реализует Spanning Tree. Если вы запустите Spanning Tree, он вам то же самое сделает. Он оставит один канал живой, а все остальные придушит. И трафик будет ходить через живой канал. Если Spanning Tree обнаруживает отказ канала, он переключается на другой интерфейс. Но ему для того, чтобы переключиться, требуется некоторое время. Если вы объединяете интерфейсы в группу и используете схему балансировки Active/Backup, то при обнаружении отказа, если у вас есть механизм обнаружения отказа на проводе, вы можете перескочить на соседний провод сразу, не дожидаясь никаких специальных действий. Spanning Tree потратит некоторое время на переключение, а балансировщик, который работает по схеме Active/Backup, нет.

Он только обнаружит, что отказ случился, и перескочит. Если говорить про Ethernet, который по меди работает, в медном Ethernet время обнаружения отказа интерфейса, когда там лампочка гаснет, — 50 миллисекунд. Более строго — от 32 до 48 миллисекунд. За 50 миллисекунд точно обнаруживается отказ. Если лампочка на интерфейсе потухла, перескакиваем на запасной интерфейс. В чём фишка этого механизма? В том, что если вы на активном интерфейсе трафик принимаете и отправляете, а на запасных бэкапных — нет, то для того, чтобы эта штука работала, вообще никоим образом не требуется поддержка группировки с другой стороны. Если соседняя сторона будет просто обычный коммутатор, никак не настроенный, — Active/Backup не требует ничего специального с другой стороны. Если у вас есть один узел, на котором есть два канала,

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

которые были на том интерфейсе. И после этого кадры, которые будут приходить на те MAC-адреса, которые раньше виделись за проводом A, коммутатор будет флудить как Unicast. В том числе он будет флудить и на интерфейс B. После чего мы с интерфейса B будем какие-то новые кадры отправлять, и трафик будет приходить снова на интерфейс B. Эта штука простая, надёжная, дубовая как барабан. Если вы видели, допустим, настройки операционной системы Windows, на версиях Windows Server, начиная с 2012, там есть такая штука — NIC Teaming, или групповые интерфейсы, объединение интерфейсов. И там есть один из механизмов, Это switch-independent mode. Вы можете объединить интерфейсы в группу, и в этом случае фактически эта штука и будет работать. Вы один интерфейс объявляете живым, а все остальные по факту не работают. Если у вас есть операционная система хоста, она пользуется по факту только одним интерфейсом. Каждая конкретная виртуальная машина,

если вдруг она будет пользоваться этим же интерфейсом, она будет использовать уже другой интерфейс. Простой механизм. Есть другой вариант. Это каруселька, round robin. Мы говорим, что четные пакеты идут наверх, нечетные пакеты идут вниз. Четные пакеты наверх, нечетные пакеты вниз. Эта штука будет предполагать, что у нас с другой стороны уже switch понимает, что такой групповой интерфейс, и трафик, который приходит из одного интерфейса, обратно в другой не отправляется. И он нам гипотетически может позволить получить практически стопроцентную нагрузку обоих интерфейсов. Но не стопроцентную. В чем негатив этого самого round robin? Почему его на самом деле не стоит использовать? И очень редко вы можете увидеть round robin в продакшене. Дело в том, что если у вас неравномерно будут загружаться очереди, может получиться так, что в одной очереди пакеты поменьше, в другой очереди пакеты побольше. Это пакет номер один, это пакет номер два, это пакет номер три, это пакет номер четыре,

это пакет номер пять, это пакет номер шесть. Они отправляются более-менее синхронно, и у вас получится, что на получателя сначала приходят первый и второй, потом четвертый, потому что третий еще не успел отправиться. Потом начинает приходить шестой и третий одновременно, и только потом пятый. У них порядок следования будет нарушаться, если они отправляются по каналам с разной загрузкой. Поэтому round robin по факту вы не увидите, именно потому что он вызывает так называемый реордеринг пакетов, или нарушение порядка следования пакетов: они отправляются от отправителя с одним порядком следования, а на получателя приходят в другом порядке следования. В Ethernet такого быть не может, потому что Ethernet — это, как вы помните, тщательная эмуляция толстого желтого коаксиала. В толстом желтом коаксиале, если вы что-то отправляете в коаксиал, оно не может перепутаться по дороге. Но если вы используете балансировку round robin, оно может перепутаться в порядке следования по дороге, и получается, что мы не очень хорошо эмулируем общую среду передачи данных с использованием толстого желтого коаксиала.

Есть механизм, который немножко похож на round robin, он называется load-based, и смысл его заключается в том, что кадр отправляется всегда в наименее загруженный порт — тот порт, в котором очередь будет поменьше. Эта штука позволяет вам выбрать для нового пакета, который пришел, тот порт, тот провод, в котором очередь будет меньше, и как следствие у вас очереди всегда будут плюс-минус одинаковые по размеру. В этом случае, если особенно вы будете добавлять искусственно небольшую задержку при добавлении новых пакетов, вы, может быть, и не получите стопроцентную утилизацию обоих интерфейсов, но вы получите практически правильный прием пакетов на стороне получателя. Эту штуку впервые реализовал Brocade на своих свитчах и получил на это патент.

Поэтому на оборудовании других вендоров такой механизм встретить не получится. Еще одна проблема с load-based балансировкой будет заключаться в том, что эти штуки очень чувствительны к длине провода. Если у вас даже на отправителе кадры отправляются в правильном порядке, но длина провода здесь будет побольше, а здесь будет поменьше, потому что они просто по разным трассам проложены, и у вас может быть длина на один метр больше на одном проводе, чем на другом, у вас уже это может повлечь за собой реордеринг пакетов. Поэтому для того, чтобы этот механизм работал на тех самых Brocade, у вас должны быть натурально одинаковые длины провода. И это все работает фактически только в пределах, например, одной стойки, когда у вас два свитча связаны между собой двумя проводами, и вы этот механизм load-based включаете. Поэтому по факту Active Backup встречается, но не очень часто, потому что неэффективен. Round robin и load-based в рамках CCNA можно говорить, что не существует, потому что у них есть проблемы с реордерингом.

И, наконец, Application Based Balancing — это то, что мы можем встретить на оборудовании практически всех вендоров, в том числе и Cisco, когда мы по какой-то очень простой схеме добиваемся эффекта, чтобы все кадры одного и того же приложения, от одного и того же отправителя до одного и того же получателя всегда шли по одному и тому же проводу. В этом случае может случиться такое, что у нас реордеринг будет происходить, но он будет происходить с пакетами разных потоков, разных сессий. Никогда не получится такого, что отдельное приложение на отправителе отправило пачку пакетов, и они дошли до получателя вперемешку. А то, что разные приложения могут отправлять пакеты разным получателям, и они придут не в том порядке — и фиг бы с ними, они все равно потом по разным трассам пойдут до разных получателей. И Application Based Balancing по факту встречается в подавляющем большинстве случаев. Работает она за счет какого-то очень простого критерия. Кадры, которые приходят на наш свитч,

дальше их какой-то очень простой анализатор будет изучать, и по какому-то очень простому критерию будет говорить: такой кадр надо отправить вверх или такой кадр надо отправить вниз. Механизм должен быть крайне простым и крайне быстрым, потому что если у вас есть линк, например, из двух 10-гигабитных интерфейсов, то вам надо в этот линк успевать набирать 20 гигабит трафика. И на таких скоростях обычно невозможно хранить какую-то табличку, типа как мы в IPv4 для NAT храним табличку, кто куда ходит, по какому интерфейсу, чтобы с ней консультироваться и принимать решение, что пакеты с такими IP-адресами, с такими MAC-адресами мы отправляли в прошлый раз на тот порт. Для того чтобы эта штука работала, нам обычно такая табличка не поможет, потому что скорости, на которых работают современные свитчи, слишком большие. Поэтому, как правило, такой анализатор, который будет принимать решение, куда девать кадр, он будет работать без хранения состояния.

У него никакой таблички не будет. Он будет смотреть на каждый конкретный кадр и говорить, что кадры с такими характеристиками мы отправляем наверх, а кадры с такими характеристиками мы отправляем вниз. Поэтому если приходят кадры от какого-то одного приложения, они все будут обладать какими-то общими характеристиками. Например, у них будут IP-адреса чётные или нечётные. И мы говорим: все кадры, которые содержат IP-пакеты, у которых IP-адреса чётные, мы отправляем в один порт. Все кадры, которые содержат IP-пакеты, у которых IP-адреса нечётные, мы отправляем в другой порт. В этом случае мы не можем гарантировать, что у нас будет равномерная загрузка всех интерфейсов, которые входят в группу, но мы получим гипотетическую возможность использования всех линков одновременно, вплоть до 100% загрузки при хорошем раскладе, и трафик реордериться при этом не будет.

То, что загрузка портов конкретных может меняться во времени — да, это факт, потому что если мы говорим, допустим, четные пакеты мы всегда направляем вверх, нечетные пакеты мы всегда направляем вниз, может быть, у нас сейчас приходят только четные пакеты, и в 100% загрузку упадет верхний интерфейс, а потом через некоторое время картинка поменяется, и интерфейс упадет до нуля, зато в нижний интерфейс будет литься 100% трафика. Да, это не очень красиво, что у нас сначала загружен был только один интерфейс, а потом тоже загружен только один, но уже другой, но сделать с этим ничего нельзя, потому что мы не можем делать излишне сложный анализатор и излишне сложный механизм принятия решения, в какой конкретный интерфейс направлять какие конкретные кадры. Так, дальше. Если у нас есть такой механизм группировки, то мы должны будем соблюдать определенные требования к топологии. Фактически группировать интерфейсы очень просто: можно только между двумя устройствами.

Если у нас есть два устройства, мы протягиваем 2, 3, 5, 10 параллельных проводов между ними, и трафик между ними каким-то образом балансируем. Причем механизм балансировки с одной стороны совершенно не обязан совпадать с механизмом балансировки с другой стороны. С другой стороны, главное, чтобы просто всё, что приходит по проводу, который формирует группу, обратно в ту же самую группу не отправлять. Почему нельзя сделать то, что на картинке? Почему нельзя взять и объединить 2 провода, или 3 провода, или 10 проводов, которые будут идти до разных сетевых устройств? Потому что в этом случае, если что-то мы отправляем в какой-то один интерфейс, мы обратно трафик этот не ожидаем видеть. А в случае, если мы отправляем этот кадр на один коммутатор, и в той же самой группе есть какой-то порт, который смотрит на другой коммутатор, то что будет происходить с таким кадром? Представьте себе, что это broadcast. Этот broadcast дошел до верхнего свитча. Что с этим broadcast свитч должен делать?

Он должен разбросать его на все порты, кроме порта источника. И он разбрасывает на все порты, кроме порта источника, плюс бросает на порт, который отправляет трафик на соседний свитч. Тут то же самое. Что делать с broadcast? Он должен отправить его на все порты, кроме порта источника. Если только вы не пометите кадр, который приходит по этому линку, что он пришел из определенной группы, и его нельзя отправлять в порты, которые входят в ту же самую группу, то свитч, который второй в цепочке будет, у него вариантов не будет, он должен будет отправить этот кадр обратно в этот порт. И у нас по этому же самому порту придет какой-то кадр и вызовет те же самые проблемы, которые были характерны для петли. В частности, это будет нестабильность базы MAC-адресов. Если изначальный broadcast был отправлен каким-то узлом А, то после того, как по этой полупетле кадр прошел, MAC-адрес А у нас будет теперь известен за этим групповым портом. Поэтому ничего хорошего в этом нет.

Если у вас вдруг параллельные линки разошлись и стали смотреть не на одно и то же устройство, у вас, как правило, сеть будет работать крайне криво. Поэтому такого допускать не рекомендуется. Либо, если вы точно уверены, что ваше оборудование такое поддерживает, вы должны будете убедиться, что кадры, которые между двумя этими устройствами отправляются, отправляются с какими-то дополнительными маркировками. Механизмы, которые позволяют такие маркировки делать, как правило, называются либо Multi-Chassis LAG. LAG — это Link Aggregation Group. M-LAG — это Multi-Chassis, когда два свитча объединяются в какую-то виртуальную группу, которая по факту для внешних свитчей выглядит как одна большая группа. И в этом случае трафик, который приходит на порт, формирующий группу, отправляется на соседнюю железку с приписочкой «Не отправлять это на порты, которые входят в группу номер 17». И поэтому соседний свитч знает, что этот порт в группе номер 17, и обратно в тот же самый порт, в ту же самую группу кадр уже не отправит.

Если говорить про конкретные реализации Multi-Chassis LAG, это либо Cisco vPC на Nexus — Virtual Port Channel, либо если вы используете стекирование, когда несколько свитчей объединяются в один групповой мега-свитч, там тоже это может быть, либо если вы используете VSS на 4500-х и 6500-х, Virtual Switch System, то тоже там они умеют между собой обмениваться информацией о том, откуда пришел конкретный кадр. Но если мы говорим про какие-то простые модели, то такого, как на картинке, когда агрегированный порт смотрит на несколько разных сетевых устройств, делать нельзя. Именно потому что будет нестабильность базы MAC-адресов. Дальше. Если вы агрегируете несколько портов, то вам следует убедиться,

что они примерно похожи друг на друга. По стандарту не написано, что порты должны быть одинаковые, но по факту реализации, которые позволяют объединить несколько портов в одну группу, будут проверять, что вы объединяете именно одинаково настроенные порты. Они должны быть одинаково настроены по скорости, по дуплексу, по типу access или trunk. Если это access-порты, они должны быть в одном VLAN. Если это транковые порты, они должны быть с одинаковым набором разрешенных VLAN, с одинаковым native VLAN. Они должны быть одинаковые. Если говорить про стандартные требования, то по стандарту требуется только, чтобы дуплекс был одинаковым. Но по факту на тех же самых цисках вы не сможете настроить порты, которые имеют, например, разную скорость. Более того, рекомендуется объединять не больше восьми физических линков в один групповой интерфейс. Здесь на картинке два линка, но вы можете взять 4, 5, 6, 7, 8 линков и объединить их в такой групповой интерфейс. И гипотетически, если вы используете восемь физических линков

и объединяете их в одну группу, то вы тем самым можете повысить скорость передачи данных до восьми раз. Но восьмикратное повышение скорости вы, конечно, не получите. Но при определенных раскладах, при сравнительно неплохом механизме балансировки, при сравнительно случайном трафике, который у вас будет бегать, вы можете повысить скорость довольно значительно. Если вам требуется больше, чем 8 портов, то намного проще будет использовать просто более скоростной интерфейс. Если у вас 100-мегабитные линки, возьмите и купите 1-гигабитный интерфейс. Если у вас гигабитные линки, возьмите 10-гигабитные. Если у вас 10-гигабитные линки, поставьте оптику 100-гигабитную. Если у вас уже 100-гигабитные линки, и вам не хватает полосы пропускания, я вам завидую. Откуда взялась цифра 8? Во-первых, потому что есть преемственность Ethernet, что каждое следующее поколение скорость увеличивается в 10 раз, хотя в последнее время тенденция сильно нарушается, потому что есть 25-гигабитные, 40-гигабитные линки,

потом в BASE-T есть 5- и 2,5-гигабитные. Но как бы там ни было, скорости так или иначе всё время постоянно растут. И дополнительно к тому цисковская реализация аппаратного балансировщика, она умеет принимать решение, куда девать трафик, и максимум может работать только с 8 портами. Поэтому, если мы говорим про Cisco, то больше чем 8 портов вы задействовать просто одновременно не сможете. Так. Если вдруг вы собрали всё хорошо, запустили, включили балансировку, включили агрегацию, всё работает замечательно, вы бурно радуетесь жизни. Но если вдруг вы всё запустили, всё собрали, всё включили, разблокировали порты, и тут выясняется, что где-то вы что-то напутали. Где-то либо глазки оптики переткнули не туда, либо где-то напутали интерфейс. В общем, вы получили картинку типа того, что здесь нарисовано. У нас опять параллельные групповые интерфейсы смотрят на разные устройства.

В этом случае вы можете сказать: shit happens, со всеми бывает, и на старуху бывает проруха. А можете воспользоваться механизмом, который избавит вас от проблем на самом деле. С одной стороны вы можете сказать: я администратор, я здесь самый главный, я хочу, чтобы у нас использовалась агрегация, и всю ответственность я беру на себя. И в этом случае, если вдруг вы со своей стороны что-то где-то напутали, сетка у вас сдохнет. Либо вы можете сказать: давайте запустим специальный механизм проверки, который сначала проверит, что всё правильно, что действительно все групповые порты смотрят на одну и ту же железку, и что с другой стороны железки эти порты действительно включены в группу. И если действительно там всё хорошо, то мы со своей стороны коммутацию разблокируем. А до тех пор у нас будет работать примерно как Spanning Tree. Он сначала всё блокирует, а потом, когда убеждается, что петли нет, всё разблокирует. То же самое и здесь. Это аналогичный Spanning Tree протокол по сути. Он сначала всё блокирует, а потом то, что настроено заведомо правильно, разблокирует.

И протоколов таких, которые умеют проверять корректность сборки групповых интерфейсов, их два. Один из них стандартный — 802.3ad. Он же, этот самый 802.3ad, предписывает рекомендации, даёт рекомендации, как группировать интерфейсы по стандарту. И второй вариант — это PAgP, Port Aggregation Protocol. Фирменный цисковский механизм, который по сути своей брат-близнец 802.3ad, но появился немножко раньше. Давайте разбираться с тем, как это всё устроено. Механизм LACP, который вы будете, скорее всего, использовать. Я рекомендую использовать определённо механизмы контроля. И если у вас поддерживается и LACP, и PAgP, никаких причин сегодня использовать PAgP нет. Поэтому LACP — протокол стандартный, поддерживается абсолютно всеми. Работает он очень просто. До 8 портов могут быть включены в одну группу. На всех этих портах вы отправляете специальные мультикастовые кадрики на хитрый MAC-адрес.

01:80:C2:00:00:02. Этот 01:80:C2 — это специальный OUI, который характерен для всяких IEEE-ных протоколов. Например, на похожий MAC-адрес будут отправляться классические стандартные 802.1D BPDU, которые будут участвовать в Spanning Tree. Там немножко другой MAC — 01:80:C2:00:00:00. А здесь 00:00:02. Этот MAC-адрес характерен для так называемых slow protocols. Протоколы, которые не очень часто отправляются, но при этом нужны для того, чтобы контролировать качество работы сети. И LACP будет отправлять мультикастовые кадрики, которые не коммутируются. Если соседний свитч понимает, что такое LACP-кадр, он не будет этот кадр форвардить никуда. Помните, я говорил, что на свитче, который поддерживает VLAN,

есть, например, 10-й VLAN, 20-й VLAN, и есть ещё рядом центральный процессор. Центральный процессор. И когда какие-то кадры приходят на транковом порту, они могут отправляться либо на коммутацию на 10-й VLAN, либо на коммутацию на 20-й VLAN, либо на центральный процессор. И то, что направляется на центральный процессор, оно не подлежит коммутации. Как раз кадры, которые приходят на этот самый MAC-адрес 01:80:C2:00:00:02, они направляются на центральный процессор, минуя матрицу коммутации, минуя виртуальные коммутаторы что 10-го, что 20-го VLAN. Поэтому они не принадлежат никакому VLAN. Если хотите — когда кадр приходит, мы говорим: по какому VLAN его коммутировать? Ни по какому. Он не подлежит коммутации. Это кадр, который идёт на процессор, мы дальше его не передаём. Мы на других портах, если вдруг захотим отправлять LACP-кадры, будем формировать новые кадры и будем центральным процессором их туда отправлять, и там уже будут отправляться другие LACP-кадры, отправленные нами самими.

Это некоммутируемые кадры, хотя они и мультикастовые. Мультикастовые они в том смысле, что адрес получателя там групповой. Он никому конкретно не принадлежит. И в то же время принадлежит любому коммутатору, который поддерживает LACP. LACP обнаруживает такую штуку, как непрямой отказ канала. Если у вас есть, например, оптическая линия, она будет выглядеть следующим образом. У вас есть коммутатор, на нем есть интерфейс, например, SFP. И у этой SFP два глазика. И эта SFP двумя волокнами соединяется с такой же SFP с другой стороны. У нее тоже два глазика, и она втыкается в коммутатор. Если вы случайно перепутаете эти глазки, то фактически линия не поднимется, порт не поднимется, и вы его в группу не включите.

Но может быть такая штука, что вы все правильно сделали, вы соединили все оптические линки правильно, у вас линк поднялся, LACP отправил специальные кадрики, получил специальные кадрики, понял, что все хорошо, а потом кто-то взял и случайно задел оптический разъем в SFP. Очень легко это на самом деле сделать, и у вас одно из волокон отвалилось. Допустим, отвалилось волокно, которое либо на отправку, либо на прием работает. И в этом случае вы не можете либо отправлять, либо принимать кадрики. Но при этом линк у вас остается живой, SFP торчит, но трафик либо в одну, либо в другую сторону не ходит. В этом случае LACP за счет того, что он отправляет специальные мультикастовые кадрики раз в секунду, он через некоторое время после того, как перестает принимать кадры от соседа, поднимает панику и говорит: у нас линк хоть вроде бы в UP, но на самом деле не в UP. И коммутацию на нем надо заблокировать. Фактически он как бы пингует соседа постоянно.

Пингует, пингует, пингует. Как только пинги прекратились — всё, сразу паника, сразу выключаем порт. Не выключаем порт, а придушиваем порт, выключаем коммутацию на нем, так же, как Spanning Tree блокирует коммутацию на порту. У LACP есть два режима работы. Один называется Active, когда мы посылаем LACPDU, эти пакетики LACP-овские, всегда мы отправляем их, пингуем соседа и ожидаем, что сосед будет тоже пинговаться. И второй режим — это пассивный. Больше правильнее было бы сказать, наверное, скрытный. В пассивном режиме PDU-шки будете вы отправлять только в ответ на PDU-шки от соседа. Если вы с обеих сторон включаете, например, активный режим, то у вас все нормально работает. С одной стороны отправляются PDU-шки, с другой стороны отправляются PDU-шки. Все хорошо. Если с одной стороны включаете Active, с другой Passive, тоже все нормально, активный узел просыпается, начинает отправлять PDU-шки сам. Через некоторое время пассивный сосед, видя, что к нему приходят PDU-шки от соседа,

в ответ тоже посылает свои PDU-шки, у вас тоже все поднимается, все начинает работать. Но если вы с обеих сторон зададите пассивный режим, то, естественно, связи не будет. Оба свича будут сидеть, ждать у моря погоды, пока кто-нибудь им пришлет PDU-шку. А сосед ничего не посылает, потому что он сам ждет у моря погоды. Поэтому если вы настраиваете LACP, то настраивайте с обеих сторон Active, и это будет, как правило, все хорошо. Passive нужен только в исключительно редких ситуациях, когда вы не уверены, что с другой стороны будет включаться, что там может какой-то злодей сидеть, и вы не хотите раскрывать детали того, как настроены вы. В этом случае вы можете указать, что вы Passive, и только если сосед пришлет корректную, правильную PDU-шку, то вы в ответ отправите и свою PDU-шку тоже. Но в реальности, в продакшн-сети, в предприятии, вы заведомо знаете все линки, которые у вас формируют группу. И не может быть такого, что вы не уверены, что с другой стороны будет находиться ваш собственный свич.

Поэтому включайте Active с обеих сторон, и это будет хорошо. У PAgP, на самом деле, очень похожий механизм работы. Там есть небольшие отличия, но по большому счету он работает примерно так же. Есть еще такая штука, которая называется L2 и L3 агрегация. Это очень часто смущает людей, но на самом деле ничего сложного там нет. Смысл заключается в том, что у вас в коммутаторе все порты, которые в нем есть, находятся по умолчанию в коммутируемом состоянии. Кадры, которые приходят на коммутатор, мы направляем на матрицу коммутации, дальше находим список выходных интерфейсов для этого кадра и разбрасываем копии кадра по выходным интерфейсам. Если же у вас интерфейс переведен из коммутируемого в маршрутизирующий режим, то на интерфейсе у вас появляется свой собственный MAC-адрес. Кадры, которые приходят на этот MAC-адрес, вы обрабатываете, посылаете их на центральный процессор. Не на матрицу коммутации, а на центральный процессор.

А кадры, которые приходят на другие MAC-адреса, вы выбрасываете. На L2 порту, на порту в коммутирующем режиме, у нас своего MAC-а нету, и все, что приходит на порт, мы отправляем на матрицу коммутации. На L3 порту, на порту в маршрутизирующем режиме, у нас есть свой MAC-адрес. Кадры, которые приходят на этот MAC, мы направляем на процессор, а все остальные кадры мы выбрасываем. В этом разница. Если мы берем и объединяем несколько физических портов в одну группу, то мы можем эту группу тоже объявить либо в коммутирующем режиме, либо в маршрутизирующем. Если мы объявляем, что эта группа будет в коммутирующем режиме, то кадры, которые приходят либо через один физический интерфейс, либо через другой, направляются на матрицу коммутации и дальше куда-то разбрасываются. Если мы говорим, что у нас интерфейс будет в маршрутизирующем режиме, эта группа, то у нас любой кадр, который будет приходить на групповой интерфейс, будет проверяться на то, на какой MAC-адрес он пришел, у этого группового интерфейса будет свой собственный MAC-адрес,

и кадры, которые приходят на этот MAC-адрес, направляются на процессор, а кадры, которые приходят на другие MAC-адреса, просто выбрасываются. Мы не коммутируем кадры на такие интерфейсы. Соответственно, на маршрутизируемые интерфейсы мы можем назначить IP-шник. Если мы говорим, что у нас такой L3-порт, L3-агрегируемый порт, то в этом случае мы на него можем повесить IP-адрес, так же, как на физический интерфейс на роутере. Это то, что касается теории про агрегацию портов. Давайте посмотрим, разберемся, как это все делается на практике на оборудовании Cisco.