Дизайн коммутируемой сети

Продолжаем говорить про коммутируемые сети, вопросы дизайна. И, соответственно, сейчас мы будем вспоминать, как нужно строить сети. Мы на роуте уже видели с вами, что хорошо, когда сети у вас строятся с помощью блоков, потому что такие сети можно будет масштабировать достаточно легко. Поэтому, соответственно, у вас есть сеть вашего предприятия, так называемая кампусная сеть. Это совокупность узлов, которые находятся где-то недалеко друг от друга, например, в одном здании. Эта сеть может разделяться на отдельные блоки, которые, ну, может быть, там, не знаю, по этажам, может быть, по соседним зданиям, если у вас несколько зданий, комплекс зданий. Соответственно, вот вы говорите, давайте соединим все здания в одну сеть, и у вас получается вот кампусная сеть, это вся территория, все пользователи на территории, и дальше в каждом здании у вас стоит один дистрибьюшн-блок, это пара дистрибьюшн-свечей

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

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

Ну и, соответственно, либо этот провод может сдохнуть, либо тот порт, который обслуживает абонента, может сдохнуть. Либо вся железка может сдохнуть. Здесь уже с этим ничего не придумаешь. Ситуация, при которой обычные абоненты у вас подключаются двумя или больше проводами к сети, все-таки экстремально редкие. Сюда же, кстати, подключаются точки доступа. Опять же, если у вас на этаже стоит свитч, рядом с ним висит точка доступа абонентская, то, соответственно, все это встыкается в свитчи доступа. Если у вас таких блоков много, то, соответственно, вам нужны будут отдельные свитчи на уровень ядра. Если этих блоков мало, то есть, например, у вас всего два этажа. На каждом этаже сидит по 30 человек. Зачем здесь какие-то специальные свитчи уровня ядра? Вы поставьте два свитча доступа, один на одном этаже, другой на другом, и соединить их прямым проводом. Но если у вас свитчей доступа много на каждый этаж, дальше этаж этих много, то вам потребуется полноценная вот такая вот сеть, типа той, которая нарисована.

И главное, что здесь у нас все разводится по блокам. То есть вот это вот, условно говоря, один этаж, это другой этаж, это третий этаж. Если нужно будет, просто масштабируем. Говорим, нам нужно еще один, в кавычках, этаж надстроить. Да, ну, у нас, не знаю, там, компания сняла еще один этаж. Не проблема, здесь вот взяли, ой, пардон, надстроили еще один этаж по образу и подобию, подключили его, опять же, к свитчам уровня ядра. Дальше. Точно таким же блоком, фактически, у вас будет блок, который называется Provider Edge. Ну, то есть пограничный блок. Сюда подключаются маршрутизаторы, которые будут смотреть в интернет. Сюда же будут подключаться к этим маршрутизаторам не только интернет-провайдеры, но и какие-то линки, которые используются для связи с другими сетями, которые принадлежат именно нам. Например, всякие VPN-концентраторы или point-to-point линки через провайдерские VPN или что-то в этом духе. Ну, короче говоря, это все вот здесь вот у нас, вот в этом блоке будет агрегироваться.

И со внешним миром, то есть в нашем случае с кампусной сетью, этот самый блок будет связываться все равно как вот, ну, точно так же. Да, здесь у нас две железки, которые двумя проводами смотрят. И здесь тоже самое две железки, которые проводами смотрят. В принципе, это все очень похоже друг на друга. Если вам вдруг захотелось вторую, да, не знаю, серверную построить, в которой будет точно так же там провайдеры приходить, будут точно так же VPN подключаться, вы говорите, окей, значит, это будет у нас Edge 1. А здесь вы рядом строите еще один блок, который будет называться E2, в котором точно так же два роутера, и которые точно так же каждый роутер двумя проводами связываются с ядром вашей сети. Ну и, наконец, если вдруг у вас есть дата-центр свой собственный, дата-центр это не обязательно какое-то такое красивое помещение, где много рядов стоек, где всякая лабуда. Это даже просто, если у вас там, не знаю, 10 серверов или 20 серверов, то все равно это уже имеет смысл делать отдельным блоком. Вы говорите, что у вас есть железки, и эти железки, к которым подключаются сервера, вы втыкаете, опять же, в ядро сети, как отдельный дистрибьюшн-блок.

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

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

Вот, что, типа, баржу купили маленьких свечиков, и вот такие же маленькие свечи поставим на сервера. Не получится. Там абсолютно разный профиль нагрузки, и свечи для абонентов, которые, вот именно абонентские свечи, кампусные сети, они просто не подходят для дата-центровых применений, потому что они рассчитаны под совершенно другие нагрузки. Вот. Ну, да, дата-центр — это отдельная песня. Мы сейчас пока эту тему трогать не будем. У них своя атмосфера, они там умеют развлечься сами. Ну, и если вдруг вам интересна дата-центровая тема, то, соответственно, вы, скорее всего, будете работать с железками CISC и Nexus, если говорить про CISC, или какие-то другие дата-центровые свечи. Ну, это, опять же, да, это... у них там все свое. У них, как правило, очень высокие нагрузки. Они уже оперируют терминами, там, не 100 мегабит, а 100 гигабит. У них ультравысокие ценники. Ну, и задачи, с которыми они сталкиваются, в общем, совсем не похожи на те, которые есть в сети предприятия.

Так. По поводу модели, которая называется CISC Enterprise Campus Architecture. Вот эту вот аббревиатуру надо запомнить. И смысл ее заключается в следующем. Что если вы покупаете для кампусной сети оборудование, вы покупаете свечи разных, скажем, линеек для разных задач. Для большинства задач вы подключаете... Вы подключаете этих пользователей к сети, и вам хочется, чтобы наиболее многочисленная категория ваших свечей была как можно более дешевой. Поэтому Access свечи, их больше всего, количественно. Они самые дешевые. Ну, и, как следствие, они самые тупые. Задача Access свечей будет отбить какие-то базовые атаки, то есть обеспечить базовую безопасность сети, причем не за счет какой-то грамотной инспекции трафика, а за счет того, что, ну, просто заведомо неразумные вещи отсечь.

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

Поэтому Аксессные свечи дешевые, у них порты дешевые. Если нужно будет на этих портах обеспечить какую-нибудь штуку типа PowerRover Zornet, опять же, это хороший пример, да, вот что PowerRover Zornet на Аксессовых свечах, как правило, есть. Ну, или, скажем, вы можете купить модель без по Е, но в линейке будет рядышком моделька с по Е. Да, она будет подороже, но тем не менее, такая модель в линейке вообще будет. Если говорить про дистрибьюшн свечи, дистрибьюшн нужны для того, чтобы соединить между собой Аксессы. И, соответственно, этих свечей будет меньше. Ну и на них надо будет выполнять задачи, которые, ну, больше негде делать. То есть, если у нас есть, например, пользователи, эти пользователи втыкаются в Аксесс свеч. Здесь у нас юзеры, здесь у нас юзеры. Получается, что этот свеч тупой, этот свеч тупой. И трафик, который между ними бегает, надо где-то проверять, что он, ну, что он имеет смысл, что он адекватен, что он не нарушает какие-то требования по безопасности. Поэтому дистрибьюшн свечей, которые соединяют между собой Аксессы,

они умные. Во-первых, их мало, поэтому они могут быть немножко подороже, это на цене не сильно скажется. А во-вторых, они за счет того, что они могут быть подороже, они становятся умнее. И они начинают заниматься задачами инспекции. Они начинают решать политики какие-то. Можно ходить, нельзя. Если можно, то как. Здесь же можно выполнить маршрутизацию. То есть, если вам нужны какие-то хитрые штуки, связанные с маршрутизацией, опять же, дистрибьюшн свечей – это правильное место, где можно выполнить такие задачи. Эти свечи умные. Их мало, и они умные. Корр-свечи. Их совсем мало. То есть, они нужны для того, чтобы соединить между собой много дистрибьюшн свечей. Если у вас дистрибьюшн свечей действительно много, их соединять по схеме каждый на каждый неэффективно. Вот в этом случае вы добавляете корр-свечи транзитные в связи между дистрибьюшнами. Тем самым вы снижаете количество линков между свечами, но вы добавляете лишний свеч в путь трафика. Добавление лишнего свеча не ускоряет работу. Оно только замедляет. Не бывает свечей, которые обрабатывают трафик за отрицательное время.

Любой свеч вносит дополнительную задержку в транзит. Но, соответственно, за счет добавления этих свечей вы можете удешевить итоговое решение. Несмотря на то, что эти свечи, конечно же, ультрадорогие, несмотря на то, что эти свечи ультрабыстрые, все равно получается дешевле использовать сеть с ними, чем делать на дистрибьюшнене схему каждый на каждого. Аксесс-свечи, как правило, имеют основную задачу просто подключить конечное устройство к сети. Они дешевые, они достаточно тупые. Если они решают какие-то задачи, эти задачи несложные. Как правило, задачи связаны с безопасностью, с базовыми какими-то штуками, характерными для абонентов, например, по Е. Может быть, там будет что-то связанное с киосом, но слабенькое. Может быть, там что-то будет связанное с мультикастом, но слабенькое. То есть, это свечи тупые. Они не то чтобы прям совсем тупые. Они кое-что умеют делать. Даже, может быть, они делают почти все то же самое, что и взрослые их товарищи,

но они делают это очень неспешно и в маленьких объемах. Не стоит ожидать вот аксессовых свечей, что они у вас могут профарвардить, не знаю, десятки гигабит, сотни гигабит трафика. Но, как правило, они просто для этого не предназначены. Аксесс-свечи не означает, что они будут обязательно работать только с кадрами Ethernet. Они могут, как правило, выполнять маршрутизацию. Тогда такие свечи будут называться L3-аксесс. Ну и да, в любом случае, коммутацию, конечно же, они предоставлять могут. В этом случае, если у вас только коммутацию может предоставлять, но не маршрутизацию, такие свечи будут называться L2-свечи. Типичная модель в линейке CISC, если мы говорим про каталисты, это 2960, ну вот актуальная линейка 2960X. Это L3-свечи, они могут выполнять маршрутизацию. То есть все каталисты сегодня выполнять маршрутизацию могут. Но если говорить про CISC, то, соответственно, там у аксесс-свечей маршрутизация будет немножко урезанная

за счет того, что просто на уровне лицензии вы, покупая свеч, не получаете доступ ко всем фичам движка маршрутизации. Он будет немножко кастрированный. Ну даже кастрированный, в принципе, он неплохо работает, если не пытаться решить с помощью этого свеча какие-то странные задачи, не характерные для аксесса. Вот если вы покупаете такие свечи только на аксесс, то есть вот у вас сюда, в них, конечно, юзеры будут втыкаться, то маршрутизации у них вполне нормальные, вполне достаточные. Далее, далее, далее, далее. Дистрибьюшн-свечи, как правило, более мощные. Как правило, они более мощные, потому что они более дорогие. А более дорогие они, потому что их меньше. Нужны они для того, чтобы много аксесс-свечей связать между собой. То есть там, где у нас 20 аксесс-свечей будет, мы можем поставить пару дистрибьюшенов. И, соответственно, если вдруг эти дистрибьюшены будут стоить в 5 раз дороже, чем аксесс-свечи, все равно в общей стоимости они не будут как-то резко выбиваться по статьям расходов.

То есть все равно аксесс-свечи в совокупности свои будут стоить дороже. Они будут, как правило, работать в маршрутизирующем режиме. То есть если мы говорим, что у нас есть реальная сеть, да, у нас где-то вот здесь вот есть ядро сети, где-то здесь дистрибьюшены, где-то здесь вот аксессы. Что у нас на аксессе происходит, L2 или L3, мы заранее сказать не можем. Но, соответственно, вот здесь вот трафик наверх будет всегда почти идти по L3. Трафик в виде кадров ли, в виде IP-пакетов ли доходит до дистрибьюшенов, дальше уже точно маршрутизируется наружу. За счет того, что эти свечи работают с IP, они могут достаточно гибко оперировать всякими политиками, они могут работать с фильтрами, они могут работать с quality of service. Ну, если говорить про такую типичнейшую модель дистрибьюшен свечей, то это 4500 свечи. Вы можете иногда встретить как бы дизайн на основе 38 свечей на дистрибьюшене. Но 38 циск позиционирует как то, что в принципе они и на аксесс тоже неплохо идут.

Если вдруг у вас достаточно много денег, то вы столкнетесь с тем, что циск, если вы к ней придете, скажете, я хочу построить у вас сеть, она скажет, ну давайте вы 38 на аксесс поставите. И тут вы скажете, ну ладно, давайте, конечно же, у нас действительно же много денег, нам может действительно некуда девать. Вот, ну в этой ситуации, да, 4-тонники у вас пойдут на аксесс. В принципе, да, третью серию можно поставить и на дистрибьюшен, если у вас денег мало и трафика не очень много, ну как не очень много, вы оперируете не сотнями гигабит, а только лишь там, допустим, одним десятком. В принципе, 37-ю, 38-ю линейку вполне мог поставить на дистрибьюшен. Свечи уровня ядра, как правило, очень быстрые, потому что они не решают никакие сложные задачи. Они нужны для того, чтобы разные дистрибьюшен-блоки соединить между собой. У нас вот здесь вот, соответственно, есть аксесс свечи. Я их не рисую, но они есть. И здесь тоже, соответственно, вот это вот один дистрибьюшен-блок, это другой дистрибьюшен-блок,

тоже, соответственно, здесь там треугольники рисуются. И вот для того, чтобы эти дистрибьюшен-блоки соединить между собой, нужно ядро. Почему эти свечи очень быстрые? Ну, для того, чтобы вносить как можно меньше задержки при передаче трафика между дистрибьюшен-блоками или между какими-то внешними блоками, типа того же сам ВЭДЖ-блока или дата-центр-блока. Как правило, они работают на L3, и, как правило, они не занимаются никакой обработкой трафика. То есть, если у нас есть связность в ядре, то эта связность, как правило, очень-очень простая. Вот. Да. Типичные сценарии для свечей уровня ядра – это либо шеститонники для старых применений, либо вот сейчас есть новая линейка, катализ девятитонники, 9400, например, свечи. Такие характерные свечи для того, чтобы соединить между собой много дистрибьюшен-блоков.

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

по схеме каждого на каждого. То есть вот у нас эта штука будет называться Collapsed Core, модель без выделенного ядра. У нас есть несколько дистрибьюшен-блоков. Раз дистрибьюшен-блок, два дистрибьюшен-блок, три дистрибьюшен-блок и четыре дистрибьюшен-блок. И мы говорим, у нас в принципе, ну можно же посоединять эти свечи по схеме каждого на каждого. Что вот у нас такими звездочками все рисуется. На каждом дистрибьюшен-свече нам потребуется раз, два, три, четыре, пять, шесть, семь, восемь портов под суммарное взаимодействие. То есть у нас на дистрибьюшен-свечах портов обычно там 24 или 48. Если мы можем выделить 8 портов под связи с соседними дистрибьюшенами, то у нас там 16 останется под аксесс-свечи. Если вы знаете, что у вас в каждом дистрибьюшен-блоке не больше 16 аксесс-свечей, то в принципе вы можете что-то вот такое вот сделать. Но понятное дело, что рано или поздно это все превратится в абсолютно немасштабируемую структуру, где у вас будут взрывные макаронные фабрики вместо проводов. И вот это вот оно уже должно намекать на то, к чему это все придет.

Если вы хотите упростить конфигурацию, упростить, скажем, путь трафика, упростить траблшутинг, упростить кабельные работы, то вы можете сказать, вместо вот этого взрыва на макаронной фабрике мы ставим два core-свеча, раз и два. И, соответственно, каждый свеч подключается к двум этим самым core-свечам. У нас дистрибьюшен-свечи подключаются между собой с помощью, ну там, либо двух линков в Azure Channel, либо двух линков в амортизирующем режиме. Это мы сейчас дальше отдельно проговорим. Ну, как бы там ни было, да. У нас внутри дистрибьюшен-блока связь отказоустойчивая сама по себе. А вот дальше между дистрибьюшен-блоками мы говорим, что у нас протягивается просто достаточное количество проводов, чтобы считать эту связь тоже отказоустойчивость. Любой core-свеч может выжить, ну, в смысле, может померять. Останется второй core-свеч. Любой дистрибьюшен-блок может померять. Соответственно, оставшиеся дистрибьюшен-блоки не повредятся от этого. Почему это важно? Потому что есть еще модель,

которая называется кольцо. Ее очень любят провайдеры, потому что она не предполагает двух каких-то вот таких монстров, которые в центре сидят. Вы говорите, а давайте просто соединим их вот по такой схеме. Вот этого всего у нас не будет. Ну, тогда, если у вас где-то в какой-то момент отваливается один из блоков, то, соответственно, сеть становится либо не работоспособной вовсе, либо трафик начинает ходить какими-то очень странными путями, типа вот такого. В любом случае, да, Core Свечи – это инструмент экономии денег. Несмотря на то, что сами Свечи достаточно дорогие, они действительно способны экономить деньги за счет сокращения количества портов на дистрибьюшенах. Если здесь у нас на каждом дистрибьюшен-свече 8 портов задействуются, то здесь у нас на каждом дистрибьюшен-свече 4 порта задействуются. На дистрибьюшенах порты довольно дорогие. То есть, если мы говорим там про те же самые 45-ю линейку, то сам свитч стоит, ну, условно, там, я не знаю, 30 тысяч долларов, 20 тысяч долларов. И, соответственно, на нем будет там 24 порта.

Ну, можем считать 25 тысяч долларов, да, 25 портов. Один порт стоит 1000 долларов. И за счет того, что вы добавляете вот эти вот два свитча, вы говорите, на каждом свитче мы экономим 4 тонны. 4 тонны здесь, 4 тонны здесь, 4 тонны здесь. То есть, 32 тысячи долларов мы сэкономили за счет того, что мы выделили вот эти вот два товарища в отдельный блок. И, понятно, сами вот эти вот корс-свечи, они тоже будут недешевые. То есть, если вы их добавляете, то вы тем самым какую-то сумму здесь заплатите. Но зато этот дизайн становится у вас масштабируемый. Зато вот если захотите еще один дистрибьюшен-блок добавить, он добавляется уже без особых затрат. Вот. Такая вот история. Collapsed Core, да, это дизайн, при котором у вас нету отдельных core-свечей, когда у вас дистрибьюшены смотрят друг на друга, либо в кольце, либо в full mesh. И эта модель иногда имеет смысл. Если у вас дистрибьюшенов много, Collapsed Core становится неразумным. Вот на картинке показан взрыв на макаронной фабрике,

но на самом деле для 8 свечей это еще хоть как-то имеет смысл. Если у вас свечей становится, например, 10-12 дистрибьюшенов, то есть дистрибьюшен блоков 5 или 6, это уже становится перебор. Если у вас здесь рядышком есть еще дата-центровый блок, если у вас здесь рядышком есть edge-блок, ну то есть это уже напрямую имеет финансовый смысл ставить выделенные свечи уровня ядра. Поскольку, как правило, свечи позиционируемые как уровень ядра модульные, то вы можете купить, скажем, по минимуму необходимые вам модули, а потом, если вдруг сеть будет расти дальше, то вы будете просто эти модули докупать по мере необходимости. Что касается различных вариантов построения сети на уровне аксесса. Значит, с аксесс-свечами, я уже говорил, что они бывают подешевле, бывают подороже. Самый хороший вариант с точки зрения администратора, потому что его легче всего траблшутить, там меньше всего проблем, это вариант, при котором у вас аксесс-свечи будут маршрутизируемы. То есть они будут предоставлять доступ точно так же по Ethernet,

но дальше пакеты, которые будут отправляться, они будут отправляться, условно говоря, в определенную Вилане, и дальше трафик будет приниматься на интерфейсе Вилана, кадр будет открываться, видится внутри IP-пакет, и дальше у нас этот свеч начинает работать как маршрутизатор. Он говорит, у меня есть доступ во все остальные сети, и дальше я по таблице маршрутизации содержимое IP-пакет, например, отправляю в сторону одного из моих соседей по динамическому маршрутизации. Чем хорош такой дизайн? Он не требует никаких L2 протоколов, не требует First Hop Redonancy Protocol, не требует Spanning 3, не требует никаких костылей по ускорению сходимости. То есть там чистый SPF, чистый условно BGP, эта штука работает очень быстро, эта штука очень легко траблшутится, если есть какие-то проблемы, но в кавычках недостатком ее будут то, что она требует исключительно локальной Виланы. То есть если вдруг вам нужно будет обеспечить связь между двумя разными аксесс-свечами и сказать, что вот у нас есть пользователи здесь в сети

192.168.1.0.24 и здесь то же самое, 192.168.1.0.24 Вот нам нужно будет сюда 192.168.1.1 повесить, сюда 192.168.1.2. Вот если вдруг вам требуется такого рода адресация, требуется сделать так, чтобы эти два узла думали, что они находятся в одной сети, то на L3 Routed Access вы это сделаете, ну хоть и можете, но с трудом. То есть это не на любой железке можно будет реализовать так, чтобы это было хорошо. Либо вы должны будете сказать, что это там, допустим, здесь у нас будет 192.168.1.0.25 А здесь 192.168.1.128 по 25 маске. То есть это уже, да, две разные IP-сети будут. Либо городить огород с костылями, с страшными и жуткими костылями. Сделать так, чтобы у нас здесь была сетка и вот здесь была сетка, это была бы одна и та же IP-сеть, находящаяся в разных местах сети, в разных частях топологии,

это действительно не самая тривиальная задача. Вот. Однако, смею заметить, что дизайнов, которые прямо вот требовали бы определенной IP-адресации, их не так много, и задач, которые реально требуют этого, ну их действительно мало. Если у вас есть реальная сеть, то скорее всего вы вполне можете сказать, что у нас вот один свитч есть, у него есть какие-то там юзеры, которые на нем сидят, мы используем здесь одни сети, у вас есть другой свитч, может быть даже на том же самом этаже, может быть даже в той же самой комнате он стоит и обслуживает пользователей, которые в той же самой комнате находятся, но вы говорите, эти пользователи будут получать другие IP-сети, другие IP-адреса. Ничего страшного в этом нету. То есть нет ничего плохого в том, что у вас в пределах одной комнаты будет часть юзеров сидеть в сети 192-168-10, а другая часть будет 192-168-20. Никакого криминала в этом нет, поверьте мне. Чаще всего в сети предприятия, к сожалению, вы этот подход встретить не сможете, потому что администраторы,

которые работают с сетями, они очень боятся почему-то, когда у нас начинает работать протокол IP, когда у нас начинает работать маршрутизация. Это очень страшное слово маршрутизация. От него пахнет какими-то всякими SPF, BGP и прочими страшными вещами. Намного прикольнее, когда у вас один большой VLAN, прям вот один и очень большой, в котором тысяча пользователей сидит. Это все понятно, что он работает, пить есть не просит, но немножко подказливает, немножко Spanning 3 заказливает, немножко шторм устроится, ну и что? Зато как бы все воткнул, и все сразу работает. Поэтому чаще всего вы увидите большой-большой L2 домен, широковещательный, у вас между всеми свечами будут протягиваться транки или прямые аксесс-порты. Ну и соответственно, да, такой дизайн будет называться Layer 2 Looped Design. Почему он называется Looped? Потому что для того, чтобы обеспечить отказоустойчивость, вы будете строить петли. То есть у вас есть аксесс-свечи, на них юзеры сидят, эти аксесс-свечи

подключаются к двум дистрибьюшнам, и дистрибьюшнам между собой связаны тоже L2-портами. То есть это все порты в одном широковещательном домене. Может быть, это будет транк, может быть, это будет аксесс-порты. То есть не суть важных. Здесь смысл в том, что кадры могут коммутироваться вот так вот по схеме и устроить петлю. Для того, чтобы эту петлю разобрать, нам надо будет использовать Spanning 3 или какой-то аналогичный протокол. Если у вас используется L2-лупед дизайн, то, в принципе, вам здесь не требуется никакой HSRP или VRRP или что-либо еще. То есть внутри вашей вот этой вот сети просто кадры передаются куда угодно, как угодно. Если вдруг где-то случается авария, эта сеть с помощью Spanning 3 сама перестроится под какую-то другую топологию. Так, 802.1x плюс Dynamic VLAN на L3 Access немножко сложнее наворачивать. Ну, почему? Мне кажется, так же. Но только, да, за счет Dynamic VLAN,

что у вас VLAN получится каждый раз разный и там с IP-шником немножко придется поиграть. Ну да, ну чуть-чуть. Это прям реально не настолько страшный вопрос, чтобы говорить, что прям вот сильно сложнее. Чуть-чуть сложнее. Вот. Еще один вариант, как можно построить связь между Access и Distribution, это так называемый Loop-Free Design. У вас свечи Access по-прежнему будут L2, но на Distribution вы включаете уже связь со внешним VR по L3 и связь между самими Distribution будет тоже по L3. То есть у нас вот здесь вот, вот это вот будет один большой широковещательный домен. Но связи между Distribution в этом широковещательном домене нет. Эта штука, она самая простая из всего перечисленного, в том смысле, что она требует меньше всего, скажем, задумок. Она требует меньше всего думать для того, чтобы реализовать. Она подходит хорошо для локальных VLAN,

когда у вас VLAN локальные на свече, и они дальше не передаются между какими-то другими свечами. То есть у нас, к примеру, вот такая вот штука может быть. И если у вас гипотетически представить себе, что все хорошо, то здесь вот у нас абонент сидит, и здесь какой-то абонент сидит. Мы можем сказать, ну у нас вот этот вот провод L2, и вот этот вот провод L2. Мы же можем, в принципе, сказать, что у нас вот здесь вот VLAN, VLAN 10, и вот здесь вот VLAN 10. И как бы это гипотетически должно работать, что трафик прошел вот так, так, так, и как бы соединило нам два порта между собой в 10-м VLAN. А здесь мы поднимаем транки между свечами аксессовыми и дистрибьюшнами. Проблема будет в том, что если у нас все работает хорошо, то это действительно будет работать. Но как только у нас что-то начинает отмирать, например, Spanning 3, нам что-нибудь здесь заблокирует. Не то. Мы будем ловить проблему. Смотрите, какая штука. У нас вот здесь вот есть VLAN 10, и здесь VLAN 10. Соответственно, вот это вот все, это транки, в которых у нас 10-й VLAN действительно бегает.

Если у нас Spanning 3 вот здесь вот заблокирует вот этот вот линк, ну, соответственно, да, у нас превратится это все вот в такую вот кривую топологию, и трафик 10-го VLAN будет выходить наружу через какие-то вот эти вот самые другие аксессовые свечи. Для того, чтобы с этим нам бороться, нам нужно будет, соответственно, каким-то... как-то будет сказать, что Spanning 3 должен будет блокировать. Но в любом случае, гипотетически, может это привести к тому, что да, что у нас трафик будет ходить каким-то очень странными трассами. Поэтому Loop Free Design, как правило, используется только с VLAN-ами, которые локально для свеча. У нас здесь VLAN будет 10-й, а здесь VLAN будет 20-й. И эти VLAN-ы просто не пересекаются между собой. На разных свечах у нас VLAN-ы с разными номерами. И, в общем-то, проблем в этом случае возникать не будет. Трафик будет всегда доходить до ближайшего distribution свеча, там терминироваться и уходить наружу по IP. Для того, чтобы у вас обеспечить равноправность

двух distribution свечей, в этом случае нам нужно будет между ними гонять FHRP. First-Hop Redondancy Protocol, типа HSRP или VRRP или GLBP, которые скажут, да, что на какой бы... Что трафик, да, обслуживается вот этим вот свечом, а если он дохнет, то начинает обслуживаться вот этим вот свечом. Далее. Далее. Какой дизайн вы выберете, сами решайте. То есть, если есть возможность построить L3 Routed Access, то я вам рекомендую использовать эту опцию. Она наиболее, скажем, масштабируемая, наиболее гибкая. Вы с ее помощью можете сделать какие-то вещи, которые позволят вам строить достаточно большую сеть, и она будет работать беспроблемно. Со всеми остальными вариантами вы можете столкнуться с проблемами. Больше всего проблем будет у этого товарища. Вот это вот, это самая, соответственно, проблема, потому что здесь у нас будет петля,

и эта петля может рано или поздно причинить вам неудобства. В случае с L2 LoopFree Access петли как бы штатно не будет, поэтому мы можем там не использовать Spanning 3 для разрывания этой петли. Он там все равно должен быть на Access. То есть, вот здесь вот у нас все равно Spanning 3 будет, равно как и тут вот у нас тоже Spanning 3 тоже присутствовать будет. Но, тем не менее, самой петли штатно вот здесь вот уже не будет, поэтому Spanning 3 ее разрывать не должен. Если есть возможность отказаться от протоколов типа вот Spanning 3 и прочих, есть смысл, прямой смысл от них отказываться. Но если бы это было повсеместно распространено, отсутствие Spanning 3 в сетях предприятия, то мы бы с вами этот курс не проходили. К сожалению, чаще всего сталкиваться придется именно с самым проблемным товарищем. И поэтому нам придется изучать Spanning 3, поэтому нам придется смотреть, как будут устроены транки, как будут устроены виланы и как их надо будет настраивать.