VLAN

4 часть нашего курса про протокол азарнет мы сегодня будем говорить про виланы про протокол 800 2 1 кью и соответственно всякие штуки которые связаны с коммутацией в крупных сетях как следствие возникновение которых нужен этот самый протокол 800 2 1 кью и нужна концепция виланов для начала давайте поговорим про то что у нас будет в случае если мы возьмем и достаточно большую сеть соорудим ну просто возьмем азарнет там не знаю возьмем просто очень большой длинный коаксиальный кабель или очень много простых свечей на 4 порта соединив в большую цепочку и понасажаем на них абонентов любой узел соответственно сможет посылать кадр любому другому узлу можно будет отправить широковещательный кадр который будет идти на широковещательный mac fff и такой кадр

дойдет до всех участников если вы будете брать как ciao один большой толстый то вы будете посылать на всех сигнал если вы будете брать свечи то у вас сигнал электрически будет распространяться только в пределах небольшой области в пределах одного провода но зато кадры все равно будут проходить в пределах в сирон всим все равно общего шарогой широковещательного домена за пределы своего широкомещательного домена вы кадры передать не можете, широкомещательный домен это, по определению область, в пределах которой кадры передавать можно. За пределы широкомещательного домена передавать нельзя. Если Вам нужно передать данные за пределы домена Ethernet широкомещательного, Вам придется использовать какой-то способ переложить данные из одной канальной среды в другую, из одного широкомещательного домена во что-то еще. Такими штуками обычно занимаются маршрутизаторы, вам для того ,чтобы этот маршрутизатор работал, потребуется протокол сетевого уровня иногда нежелательно чтобы любые два узла могли передавать данные друг другу в пределах широкопрещательного домена то

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

не знаю отдел кадров включая айтишников в конце концов то получится что любые пользователи вашего широкопечательного домена могут этот самый файлик запросить посмотреть кто сколько зарабатывает что в общем совершенно нежелательно в более-менее серьезной компании иногда хочется сделать так чтобы бухгалтерия да она могла получать доступ к какому своему ресурсу а все остальные пользователи соответственно из других отделов не могли получать доступ к этому самому ресурсу или это может быть не на основе отделов такая организация доступа а на основе чего-нибудь еще ну вот самый простой вариант это вот именно с отделами в реализовать это можно если вы возьмете и посадите сотрудников каждого отдела на свой собственный switch между этими свечами неет deport ice руки вы и приводы а будете соединять их через маршрутизатор вот у вас будет там несколько разных широкопечательных доменов 12 и 10 домен на бухгалтерию 1 широкопечательные домена на водитель 1 широкопечательный домен найтешников 1

широкопечательные домен на сотрудников отдела кадров но соответственно маршрутизатор будет перекидывать данные между этими самыми узла между широкопещательным доменами между локальными сетями каждого отдельного отдела вот соответственно у вас будет недостаточная безопасность в такой большой сети что если вы всех посадите в одну большую сеть у вас будут пользователи иметь доступ к тем ресурсам которым в общем-то им логический доступ не должен предоставляться если вы будете всех сажать в одну большую сеть кроме того у вас еще резко будут расти затраты на обработку широкопещательных кадров потому что кадры у вас будут широкопещать не отправляться допустим протокола ip он работает достаточно тесно с протоколом арп и тот самый арпела достаточно часто отправляют широкопещательные кадры и каждый раз каждый широкопещательный кадр которые вас отправляется он отправляется на вообще всех пользователей если у вас все

пользователи в одной большой сети сидят в одном широкопечательном domenio то в illustration эта такая будет нащупывать все больше и больше пользователей а раз числа узлов в вас тоже растет то соответственно с ростом числа узлов допустим вдвое количество кадров которые вы будете отправлять будет возрастать вдвое и количество ресурсов которые которые будут тратиться на обработку таких широковещательных кадров, тоже будут тратиться вдвое больше. Более того, зачастую с ростом количества узлов в сети вы эти самые кадры начинаете чаще отправлять. И по этой причине, если вы начинаете запихивать слишком много пользователей в одну большую широковещательную сеть, у вас слишком много этих самых кадров в продкастовые будет отправляться, и слишком много ресурсов вы на них будете тратить. Вы можете легко определить, если у вас широковещательный домен в вашей организации использующийся слишком велик,

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

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

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

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

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

Это все локальная сеть. Локальная сеть максимум на 100 пользователей. В 1985 год не было тогда сетей на тысячи, десятки тысяч абонентов и не предполагалось, что они могут существовать, такие огромные сети. Сколько человек можете напихать на провод длиной 200 метров? 10Bs2 или 10Bs5? 500 метров? Ну, 100 компьютеров максимум. И то, если они будут в гирлянде висеть через каждый метр. Вот, соответственно, да. Вот именно под такого небольшого размера сети Ethernet строился. И когда мы начинаем перегружать его абонентами, у него резко начинают возникать те проблемы, которые изначально не были предусмотрены авторами стандарта. Ну, потому что, опять же, это да. Это вы начинаете использовать этот инструмент не по назначению. Использовать инструмент Ethernet, который создавался для решения задач локальной сети для создания каких-то совершенно других сетей. Сеть на тысячу или на 10 тысяч абонентов – это совершенно не локальная сеть.

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

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

Двумя свечами distribution на каждую сеть. И получится, что вам на каждый отдел, на каждых 100 абонентов потребуется купить 4 access свеча и 2 distribution. И вот этих самых пар distribution свечей у вас будет столько, сколько отделов. Это, конечно, дороговато получается. Дистрибьюшн-свечи, основная задача, чтобы их было мало, да, они дорогие, но их мало. И они нужны только для того, чтобы соединить аксессы и на них выполнять какие-то умные и важные задачи. А если вы делаете много мелких сетей, вам все равно придется купить на каждую отдельную сеть два дистрибьюшна и все равно придется на этих свечах делать все те же самые задачи, которые можно было бы делать на одной паре железок. И получается просто дорого и неудобно. У вас в этом случае количество свечей начинает резко расти и перестает ваша сеть стоить каких-то разумных денег. Вам придется купить много свечей, вам придется эти свечи где-то разместить, какие-то шкафы покупать. Если на каждом этаже у вас, допустим, 10 отделов, вам придется нужное количество аксесс-свечей купить и вам придется где-то на этаже размещать 20 дистрибьюшн-свечей.

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

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

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

показывать на слайде у вас вот этот компьютер этот компьютер айтишника он хочет послать данные вот этому вот второму компьютеру сверху тоже который компьютер айтишников они не сидят на одном свече они сидят на разных аксесс свечах и соответственно они подключены к одному distribution ну это не суть важно к одному или нет главное что они каким-то образом соединены между собой но не напрямую вам потребуется следующий узел отправляет просто самый обычный кадр азарнет на ближайший аксесс свеч ближайший аксесс свеч по какому-то своему внутреннему соображению говорит я понимаю что этот кадр пришел в широкомещательный домен айтишников неважно как я это под понял я это главное что понял я запускаю процесс коммутации по отдельной таблички коммутации который есть у меня для домена айтишников я понимаю что из порт назначения у меня вот этот вот товарищ и я этот кадр кидаю центральному свечу центральный свеч тоже принимает distribution

центральность ведь тоже принимает такой кадр говорит я получил только что кадр по каким-то своим критериям я понимаю что этот кадр относится к широкомещательном домену айтишников я должен по отдельной таблице коммутации айтишников определить где порт назначения у этого кадра и исходя из таблицы коммутации по mac у обычным самым образом наш свитч коммутирует этот кадр в какой-то из исходящих портов в нашем случае исходящим портом будет вот этот свитч access а уже назначение важно понять таблички широкомещательные они как были так и остались ось они к ничьи ракомещательные таблички коммутации они как были так и остались только их становится несколько и принимать решение по какой именно таблице коммутировать трафик свитч принимает вот исходя из того что за кадр пришел из каких-то свойств этого кадра процедура принятия решения какому широкомещательном домену отнести каждый конкретный кадр выполняется каждый раз когда мы этот самый кадр получаем то есть мы получаем кадр и мы говорим этот кадр

айтишников этот кадр и чаров в нашем случае access switch на нем в принципе сидят и те и другие пользователи и сотрудники айти отдела и сотрудники чара дело вот кадр у нас получила distribution свеча свечу получил кадр сказал по каким-то своим внутренним критериям я понимаю что этот что этот кадр относится к айти отделу я сейчас его коммутирую именно по табличке айти отдела и принимаю решение этот кадр надо отправить в сторону порта вот этого вот и кадр отправляется в сторону получателя никаким образом вы не можете отправить кадр из айти отдела в и чар отдел потому что просто коммутация не будет выполняться даже если вы браткаст отправить и вот с вот этого вот компьютера в сеть этот браткаст будет рассылаться только по тем портам которые относятся к айти отделу то есть он никогда не пойдет в те порты которые относятся только к чар отделу вот да как то так мы здесь нагло пользовались тем что у каждого коммутатор и есть механизм с помощью которого он может определить какому именно широковещательном домена относится кадр к

айти отделу к и чар отделу к водителям и бухгалтерии таких способов определить собственно говоря откуда взялся кадр у коммутатора будет несколько самый простой способ это сказать за конкретным портом у меня сидит компьютер который находится в айти отделе поэтому в любые кадры которые приходят из-под этого карта борта они будут относиться к айти отдела вот это типичное явление на access портах если у вас есть коммутатор у которого есть несколько широковещательных доменов которые на обслуживают просто он говорит все порты которые у меня есть они смотрят на конечных абонентов конечные абоненты они находятся вот в каком-то отдельном широковещательном домене они просто присылают кадры и я эти кадры просто будут говорить вот из-за того что он пришел из-под порта номер 17 я буду принимать решение это кадр относящийся к айтишникам а вот другой кадр пришел из-под протон номер 21 и это кадр относящийся к чару вы можете воспринимать такой подход как то что мы порту назначаем определенный вилан или

порт загоняем в определенный вилан или что-то еще но вот на самом деле коммутатор это будет правило рассматривать именно как то что любые кадры которые приходят из-под access порта мы будем относить к определенному широковещательным доменом вы не обязаны это делать то есть если вы захотите вы можете принимать решение о том к какому широковещательным домену относится кадр исходя из каких-то других совершенно иных предпосылок то есть можно например сказать кадры которые приходят на меня из подвода определенного порта могут быть как айтишными так и чарными я буду смотреть допустим на macadres вот если macadres источника в осен то это айтишный кадр а если macadres петен то это и чаровский кадр такое сделать можно если вы говорить процесс к допустим этого фича будет называться дай намек вилан динамические виланы но соответственно для этого требуется поддержка достаточно большого скажем достаточно тяжелой штуки это отдельного сервера который будет на каждый ваш кадр говорить на каждый приходящий на вас кадр говорить и это надо туда а это надо сюда

понятное дело что вы один раз спросите вот этот macadres куда одевать его он вам скажет вот этот macadres сидит допустим в и чарном отделе и вы после этого все кадры этого macadres уже будете коммутировать одинаково но тем не менее все равно вот эти самые данными к вилан это технология считается не очень надежно не очень безопасный в том числе и потому что macadres любой желающий может подделать очень легко то есть никто никогда не проверяет из-под какого macadres и вы отправляете кадры вы совершенно смело можете сказать сейчас вот у меня вот данный момент macadres 78 ac 91 3546 ab но я хочу сейчас вот конкретный макадр конкретный кадр отправить из под macadres и 000000001 я имею это право сделать то есть никто не обязывает вас обязательно кадр посылать из под burnton адреса или обязательно посылать кадры из подлог ли адмистрат адреса или вообще даже посылать обязательно кадры из-под одного и того же мака вы если хотите можете отправлять кадр из под любых маков которые вам захочется

просто ну как предполагается что вы будете отправлять кадры из-под своего мака но опять же в некоторых случаях относительно нормальным явлением будет отправить кадр из под чужого мака никто это не контролирует Штатно в Ethernet. Будут технологии, которые будут позволять это дело контролировать, потому что тут достаточно большой простор для атак, и мы поговорим про это в отдельной теме, про безопасность. Но имейте в виду, что вот эти вот самые Dynamic VLAN, они с безопасностью дружат очень плохо. Как называется фича от подмены Mac? Ну, у разных производителей по-разному будет. Но самая простая, про которую, например, идет разговор в цисковском треке CCNA, фича, она будет называться Port Security. Вы просто перечисляете, говорите, вот на таком-то порту могут быть вот такие-то МАКи. Или говорите, допустим, вот на таком-то порту может быть ровно один МАК, неважно какой. Чтобы вы выбрали себе какой-то МАК и с ним дальше сидели. Чтобы не перечислять точно, вот Вася может здесь сидеть, Петя может здесь сидеть. Неважно кто. Пришел кто-то, Коля. Вот мы его не знаем, кто такой Коля, но он сказал, вот у меня MAC-адрес вот такой,

он просто вам кадр отправил с вот таким вот MAC-адресом. И вы сказали, окей, Коля, рад тебя приветствовать в нашей сети. С тех пор, пожалуйста, MAC-адрес не меняй. А если будешь менять, то мы тебя просто будем тогда палками бить. Или, например, можно использовать другую технологию, которая называется 802.1x. Она чуть получше, чем Port Security. То, что здесь фу-фу, Port Security очень старая технология забыть. Нет, Port Security не надо забывать. Очень хорошая технология Port Security для сценариев, когда вам лень разбираться с 802.1x. А даже если не лень разбираться с 802.1x, все равно Port Security не надо забывать. Только не надо ей пользоваться неправильно. То, как Cisco про нее рассказывает в официальных своих курсах, это типа то, что надо взять и явно перечислить все MAC и сделать такой белый список MAC. Так делать не надо, это очень плохо, и вот это вот надо забыть действительно. Port Security надо использовать в совершенно другом сценарии, и мы опять же проговорим про нее чуть-чуть в тему про безопасность.

Так, далее. Еще какие фичи могут быть от подмены MAC? Вы можете, например, зная, какие IP-адреса, какие MAC-адреса у вас будут присутствовать в CC, дополнительно использовать какие-то еще накидные технологии, типа защиты от подмены IP-шника, защиты от подмены DHCP-ответов. Опять же, это все вендорские технологии, ничего штатного здесь нет. Каждый вендор реализует это все по-своему. Если вы точно знаете, что MAC-адрес вот такой и IP-шник у него вот такой, вы можете, соответственно, знать, что еще может отправляться и что приниматься из-под этого порта. Да. В большинстве случаев вы будете на таких аксесс-портах видеть самые обыкновенные кадры. То есть обычный абонент, когда он посылает кадр в сторону аксесс-свича, он что делает? Он просто обычный кадр изернета посылает.

И, соответственно, коммутационное решение и определение того, к какому широкопечательному домену принадлежит кадр, вы можете принять либо из того, откуда кадр пришел, либо из заголовка изернета, либо из чего-нибудь еще, то есть, например, из содержимого этого кадра, либо из каких-то третьих совершенно источников, например, спросить у внешнего сервера. Сказать ему, смотри, вот ко мне пришел вот такой вот кадр, вот на таком-то порту, чем мне с ним делать? То есть вы можете это сами принять решение, либо вы можете задать вопрос кому-нибудь, кто вам это самое решение доверенное даст. Большинство аксесс-свичей, которые будут работать, оно будет определять, к какому Вилану отнести кадр, именно на основании того, из-под какого порта кадр пришел. Если кадр пришел из-под вот этого порта, это один Вилан. Если кадр пришел из-под вот этого порта, это другой Вилан. Естественно, на конкретном свече может быть сколько угодно абонентских портов, ну как, не более чем 48 чаще всего,

и вы можете создать некоторое количество Виланов, некоторое количество шерепчатных доменов и сказать, что вот, допустим, у вас вот эти вот 2-3 порта сидят на одном домене, в одном домене, вот эти вот там 5 портов сидят в другом домене. Технически можно, никто вам не запретит создать 48 широкопрещательных доменов и сказать первый порт в первом домене, второй порт во втором домене, третий порт в третьем домене. Правда, никто друг другу кадры в этом случае не сможет посылать. У вас всегда кадры будут идти только куда-нибудь еще, но не на соседних абонентов. Иногда такое бывает полезно, но все-таки это очень редкое явление. Чаще всего у вас есть пачка портов, сидящих в одном широкопрещательном домене, и они там как-то между собой кадры теоретически посылать могут. Вот такие вот аксесс-порты, они достаточно простые. Они просто устроены, они просто настраиваются. В терминологии CISC вы говорите, это аксесс-порт, и этот порт сидит в таком-то Вилане. Если говорить про других вендоров, не про CISC, а про каких-то еще, например, Хиллит Паккарт, тот же самый Huawei, кто еще?

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

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

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

Либо из того, откуда пришел кадр, но здесь возникает сложность, все кадры приходят из-под одного и того же порта. Так что только по порту определить, что за широкопечательный домен не получается. Либо, опять-таки, спросить кого-то со стороны, но, опять же, этих кадров может быть много, а спрашивать каждый раз, в общем, накладно. Поэтому чаще всего на междукоммутаторных связях, на транковых портах у вас будет определяться, к какому широкопечательному домену отнести тот или иной кадр на основании содержимого этого самого кадра. На основании не данных, которые внутри передается, а на основании даже заголовка. Сразу возникает еще одна проблема. Заголовок в Ethernet фиксированный. Если вы помните, он очень и очень конкретный. Там нет никаких лишних полей. Макадрес получателя, макадрес источника. Чего внутри лежит 2 байта и чек сумма. И все. И больше ничего нет. Мы туда не можем записать, что этот кадр, допустим, светло-зеленый.

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

И будет добавлять сверху 30 байт. И после того, как вот эти самые 30 байт добавлены, там 26 байт заголовка, 4 байта чек-сумма трейлер. Соответственно, вот новый получившийся кадр совершенно другого формата. Он уже будет вот этот самый заголовок 26 байт, но он совершенно не похож на Ethernet. Он отправляется в сеть. И если с той стороны кадр ловится свечом, который тоже поддерживает ASL, он говорит, ага, я получил ASL-ный заголовок. Срезает его, видит внутри кадр Ethernet. Говорит, на основании заголовка, который только что срезал, я вот этот кадр отношу к определенному VLAN, потому что он был получен по ASL-линку. Вот такие вот штуки, они бывают, но чаще всего все-таки вы будете использовать другой формат, который будет называться 802.1 кьюшный кадр, 802.1 кьюшный заголовок. Вот, ну собственно да, вот ASL, фирменный цисковский протокол, поддерживается только циской. На самом деле, если уж быть совершенно точными, совершенно честными, ASL был придуман фирмой Catalyst. Тогда, когда еще циски не было, была просто отдельная компания Catalyst, которая делала совершенно отдельные коммутаторы.

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

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

И там многие вещи по умолчанию работают именно с поддержкой вот этих старых режимов каталистовских свечей. То есть по умолчанию там, допустим, протокол VTP работает, и этот VTP работает с 10-битными номерами VLAN. Вы не можете сделать VLAN, который будет иметь номер больше, чем там, допустим, 1005, чтобы он нормально работал с VTP. Ну, да, то есть надо просто знать про такие особенности. Вот одного из самых популярных вендоров для сетевого оборудования, что есть тяжелое, скажем, наследие старых времен. Ну, те, кто на Cisco курс ходили, те в курсе. То, как современные коммутаторы, все, включая Cisco, и особенно все, кроме Cisco, будут использовать передачу данных между разными свечами по транковым портам, это будет как раз другой способ, который я обозначил, это 802.1Q.

Вы будете добавлять новое поле в заголовок Ethernet. Соответственно, это поле будет 4-байтовое. Нагрузка дополнительная на сеть, она, соответственно, будет существенно меньше, потому что если вы добавляете 4 байта, это одно. Если вы добавляете 30 байт на каждый кадр, это другое. Это, в общем, на минимальный размер кадров 64 байта довольно заметно сказывается, что у вас в полтора раза в случае ASL возрастает нагрузка на сеть, это чувствительно. В 802.1Q добавляется всего 4 байта, и, в общем, оно нормально работает. Поддерживается всеми вендорами данных. Естественно, что самые глупые, самые дешевые свечи, которые неуправляемые, которые просто куплены в продуктовом ларьке, они могут не поддерживать 802.1Q. Но обычно все управляемые свечи умеют работать с VLAN с 802.1Q. Протокол 802.1Q, помимо всего прочего, частично совместим с обычным Ethernet.

То есть вы можете, если захотите, взять один свеч, который будет смотреть на другой, не 802.1Q-шный, транком, а тот другой будет пересылать третьему, который, в свою очередь, уже тоже будет смотреть транком на порт, смотрящий в сторону первого. Но вот посерединке между двумя поддерживающими на 802.1Q свечами может быть не 802.1Q-шный свеч. И все равно он продолжит нормально кадры чужие коммутировать. То есть от того, что вы добавляете этот самый доп.заголовок, свечи, как правило, не ломаются. Свечи будут оперировать частью заголовка Ethernet, которая их интересует. Это MAC-адрес источника, MAC-адрес получателя. В основном MAC-адрес получателя, естественно. И чек-сумма. Вот это то, на что смотрят свечи. Заголовок, который вы добавляете, вот этот самый 4 байта, они будут идти после MAC-адреса получателя. И большинству свечей на эти самые дополнительные заголовки абсолютно фиолетово. То есть они это видят как нормальный кадр Ethernet.

Понятное дело, ситуация вида, у вас есть свеч А, который смотрит на свеч Б, и свеч Б смотрит на свеч С, и А и С поддерживают 802.1Q и смотрят друг на друга. Ну, на промежуточный свеч Б 802.1Q-шными интерфейсами. А промежуточный свеч не поддерживает 802.1Q вообще. Эта ситуация очень и очень редкая. И вы должны такие штуки никоим образом не проектировать. А если у вас такое запроектировано, то, конечно, надо это срочно переделать. Но, тем не менее, если что, вот такая ситуация как бы есть, что 802.1Q частично совместим с обычным Ethernet. Да. И, соответственно, да, если вы посылаете кадр в сторону соседнего свеча, и этот кадр будет каким-либо образом модифицирован, либо с помощью доп. заголовка 802.1Q, либо с помощью инкапсуляции в ASL, то такие интерфейсы, по которым вы будете отправлять модифицированные кадры, будут называться транками. Модификацию кадра вы будете выполнять, потому что вы хотите отправлять информацию о принадлежности кадра к Вилану,

чаще всего. То есть вы хотите отправлять кадры нескольких Виланов по одному интерфейсу. И вот транг как раз будет позволять отправлять данные нескольких Виланов. Обычные аксессовые порты, как мы уже сказали, чаще всего не позволяют отправлять данные нескольких Виланов. Вы всегда говорите, кадры, которые отправляются через этот интерфейс, кадры, которые принимаются через этот интерфейс, они всегда исключительно только самые обычные кадры, и они всегда относятся к одному и тому же Вилану. Вот как будет выглядеть кадр Ethernet 2 и такой же кадр, этот же кадр, но с дополнительным заголовком. Сначала у обоих кадров будет идти преамбула 8 байт, 1, 0, 1, 0, 1, 0, 1, 0 и так далее. Потом будет идти 6 байт MAC адреса получателя, 6 байт MAC адреса источника. У оригинального кадра дальше идут 2 байта поля Ethertype. Если вы возьмете 802.2 формат, то здесь будет идти длина, но опять для нас это будет не актуально.

Здесь просто идет какие-то 2 байта, мы их можем назвать полем Ethertype или можем назвать полем длина. Для нас важно, что там какие-то 2 байта лежат и мы их постараемся сохранить. Дальше идут какие-то данные 46 байт минимум, 1,5 килобайта максимум и поле FrameCheckSequence, которая, как мы помним, добавляется таким образом, чтобы после того, как мы посчитали чек-сумму от всего вот этого вот содержимого, получился предсказуемый результат Ethernet Magic Number. Если здесь будет 802.2 заголовок, ну просто вот это поле будет называться по-другому, а первые 8 байт от поля данных мы будем тоже трактовать как дополнительный заголовок. Но опять же, свечи при коммутации, они не обращают внимания на то, что внутри лежит, они смотрят только вот на эти 12 байт. Если вы хотите добавить дополнительный заголовок 802.1Q, то вы добавляете его после поля отправителя, после 6 байт MACADES отправителя. И перед двумя байтами того, что вот там было либо в поле EtherType, либо в поле длина, неважно что,

главное, что оно сохранилось, оно все равно есть. Вот только 4 байта добавилось перед этим самым, перед полем EtherType. От того, что мы 4 байта добавили, результат не перестал быть кадром Ethernet. Соответственно, смотрите, вот эти вот самые 4 байта, они будут иметь очень определенный и, главное, хитрый формат. Такой хитрый, что после того, как вы добавили даже 4 байта на место какого-то другого поля, все равно, если вдруг свеч захочет посмотреть, чего внутри лежит, посмотрит вот здесь вот на какие-то 2 байта, которые там, что внутри в этом кадре передается, он все равно увидит что-то логичное и разумное. Первые 2 байта доп.заголовка, которые вы добавляете, будут называться Tag Protocol Identifier, TPID. И там всегда будет лежать значение 8100, 16-ти личные. То есть, смотрите, вы передавали оригинальный кадр, допустим, с протоколом IP внутри, там было число 0800. Вы добавили заголовок 802.1Q, у вас 0800 переехало вот сюда,

а вот здесь сразу после поля отправитель первые 2 байта будут лежать 8100. И такой свеч, если вдруг он будет зачем-нибудь смотреть, что внутри лежит, он скажет, ага, я вижу тип вложения 1.0.0, означает, что это доп.заголовок 802.1Q. Этот самый заголовок, он не показывает, что за данные передаются. То есть, на самом деле, с точки зрения свеча, после того, как он считал вот эти 2 байта, все, что после этого, по идее, должно быть данными. Вот поле TCI, поле там какое-то там EtherType данные. Вот с точки зрения формата кадра Ethernet, оригинального формата, без каких-либо доп.заголовков, если бы мы пытались тактовать кадр с доп.заголовком, как кадр без доп.заголовка, у нас бы получилось, что вот этот оригинальный заголовок и вот этот тоже заголовок. А дальше мы бы сказали, что все, что после заголовка, это данные. То есть, вот они, данные. И вот они, тоже данные. То есть, можно рассматривать кадр, который у вас получился, как кадр Ethernet,

у которого тип вложения 8100. А дальше неважно что. Вот если Switch обычный коммутирует данные, он не смотрит, что внутри вложено. Ему все равно, какое там 2 байта будет в поле вложения. Но если вдруг Switch захочет, он может посмотреть, что в поле EtherType лежит что-то ему знакомое. 8100. Он может, в зависимости от того, что знает он, что такое 8100 или не знает, сказать, ага, я понимаю, что 8100 это не просто так. Это не какое-то там абстрактное вложение 1,5 килобайта, там дальше идет. Это надо взять и посмотреть следующие 2 байта, и там будет указан, например, номер Вилана, среди прочего. Там будет много чего указано, но номер Вилана тоже. А дальше, после этого самого поля TCI, будет передаваться поле старое EtherType. Вот оно. То есть, если, допустим, у вас Switch хочет разобрать, что внутри лежит, зачем-нибудь ему это надо. Например, он потому что хочет голосовые данные приоритизировать и пропустить вперед. Он может сказать, давайте-ка мы посмотрим, что внутри лежит.

Говорит, ага, вижу 8100 в поле TAC протокола ID. Окей. Значит, поле EtherType настоящее смещено на 4 байта. То есть, надо взять и посмотреть на 4 байта правее. И вот смотрит в эти вот 2 байта и говорит, ага, вижу там 0800. Это протокол IP. Расковыриваем, видим в поле протокол UDP. Там чего у нас будет 17. Смотрим UDP номера портов. Видим, что номера портов там какие-то нас интересуют. Или даже не видим, что нас интересует, потому что мы хотим расковырять RTP. Расковыриваем дальше данные после заголовка UDP. И видим там характерную сигнатуру для этого самого UDP. То есть, вот если Switch захочет, он может трактовать такой кадр, как обычный кадр Ethernet. Если Switch захочет, он может трактовать такой кадр, как кадр Ethernet, у которого вот это вот поле EtherType надо посмотреть второй раз. После того, как мы посмотрели вот здесь, вот и увидели 8100. Да. По поводу, соответственно, вот этого поля TCI 2 байта. Оно будет называться Tag Control Information.

Там будет несколько полей. В том числе 12 бит номера VLAN. В отличие от ISL, у 802.1Q будет 12 битный VLAN. Там будет 3 бита под протоколу 802.1P. Куда можно записать тот самый Class of Service COS. И если вы запишите туда в эти 3 биты какие-то значения, там будет 8 разных значений от 0 до 7. То вы можете на основании этих циферок принимать коммутационные решения по-разному. Например, можно сказать, что если к вам прибежал кадр, у которого в поле COS лежит число 0, то мы такой кадр расцениваем как просто самый обычный кадр. Передаем его на совершенно общем основании по принципу BestEfford. То есть я попытаюсь, если не получится, я переживать не буду. Можно будет сказать, что, допустим, если кадры голосовые прибегают, там будет лежать число, допустим, 5 или 3. И такие кадры будут отправляться с приоритетными какими-то очередями. То есть вы в виде кадры с COS, допустим, пятеркой, будете их класть сразу в приоритетную очередь.

Далее, что еще хочется заметить. При добавлении 4 байт вот этого самого заголовка у вас поле с данными не меняется. Оно как было, так и остается. Здесь нарисованы, смотрите, вот эти вот длинные колбасы одинаковые. На самом деле они не одинаковые. У вас прибежал какой-то кадр на свитч. Вы к этому кадру должны добавить 4 байта. Если он к вам прибежал, и у него поле с данными было 1,5 килобайта, вы не можете взять и выкинуть 4 байта из поля данных для того, чтобы оставить максимальный размер кадров 1,5 килобайта, там, 1518 байт. Вы вынуждены будете к этим 1500 байтам данных плюс 18 байт заголовка добавить 4 байта сверху. И тем самым, да, вы превзойдете максимальный размер, который может быть у кадра в Ethernet штатно в 1518 байт на 4 байта. И действительно, свитчи, которые поддерживают 802.1.q, они нормально относятся к ситуации вида.

Прибегают какие-то кадры, которые имеют максимальный размер 1522 байта. Поэтому добавление права читать заголовки 802.1.q на порту и отправлять заголовки 802.1.q на порту автоматом повышает максимальный размер кадров, который вы будете отправлять на 4 байта. Это нормальное явление. На самом деле, современные свитчи, они будут совершенно нормально относиться к тому, что у вас на портах можно отправлять кадры заметно больше, чем 1500 байт содержимого. То есть, если посмотреть на то, как устроено большинство современных чипсетов, которые работают с Ethernet, там будут типичные явления для максимального L2 MTU. Либо 1598 байт, либо порядка 2 килобайт, либо порядка 4 килобайт, либо порядка, ну уже дальше больше, 32 килобайт. То есть, если свитч не поддерживает джамбофреймы, типичный размер кадра, который он все еще при этом будет уметь на уровне железа обрабатывать, это порядка 1600 байт.

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

Чтобы данные сами не побились при попытке занять среду. Если бы вы сразу начали фигачить MAC адрес получателя, оба, то у вас получилось бы, что вы бы начали передавать полезные данные, сосед бы начал передавать полезные данные, и у вас данные бы столкнулись по мясу. А так они сталкиваются именно с специальными буферами. Вы пытаетесь занять среду, сосед пытается занять среду, вы пытаетесь, и сосед пытается. Видите оба коллизию. Говорите, я бы пытался занять среду, у меня не получилось. Я сейчас возьму, успокоюсь, пойду попью кофе, вернусь и попробую снова. Плюс к тому преамбула будет нужна для самосинхронизации изорнета, поскольку она имеет очень предсказуемый электрический сигнал, который в случае с манчестерским ходом постоянно переходит через ноль. Вы подаете плюс 0,7 вольта, минус 0,7 вольта, плюс 0,7 вольта, минус 0,7 вольта. Или в современных даже стандартах физического кодирования, которые будут использоваться, всё равно преамбула имеет, опять же, предсказуемую форму сигнала. И по этой предсказуемой форме сигнала можно будет временно подстроить свои часы, свой кварц, который будет дергать вам тактовую частоту, под частоту отправителя.

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

Сначала было плюс 0,7, потом минус 0,7. И это очень легко на оборудовании ловится. Вы сможете легко сделать такой считыватель аналогового сигнала, который будет возбуждаться, когда будет переходить напряжение через ноль. Она была сначала положительная, потом будет отрицательная. И тем самым будет происходить подстройка тактовой частоты. Поскольку на таких частотах, на которых работает Ethernet даже 10 BST, время может расходиться очень сильно, то, соответственно, вам эту частоту надо подстраивать регулярно. В случае с Ethernet, каждый кадр, который вы будете отправлять, будете выполнять автосинхронизацию. Отправителем. То есть чаще некуда. Так, да. По поводу поля FrameCheckSequence. Да, мы уже сказали, что... Если у вас, соответственно, кадр вырос на 4 байта, то содержимое его изменилось.

И то значение, которое лежало в поле FrameCheckSequence, оно тоже, получается, должно измениться. Потому что данные во FrameCheckSequence, которые лежат, они подобраны таким образом, чтобы чек-сумма, подсчитанная от всего, кроме преамбулы, вот от этого вот значения, давала вам результат MagicNumber. Если вы вставили в серединку какие-то другие байты, то чек-сумму, которая будет новый свитч считать, вот от всего вот этого вот дела, она уже не получится правильно. Там уже не получится MagicNumber. Там получится какое-то совершенно произвольное число. Поэтому каждый раз, когда вы добавляете заголовок 802.1Q, вы старую чек-сумму сбрасываете, удаляете, и на ее место ставите новую чек-сумму, которая, опять же, подобрана по стандартному правилу Ethernet, чтобы после того, как вы посчитали все вот это вот содержимое, чек-сумму CRC32, у вас получился MagicNumber. Опять же, CRC32 устроена таким образом, что ее можно считать с самого начала. Вот показались первые 4 байта MAC-адреса получателя, а вы уже запустили подсчет чек-суммы.

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

Соседний свитч ловит такой кадр, принимает дальше решение на основании вот этого самого поля TCI, в котором хранится номер VLAN и прочего, что с этим кадром делать. И он определяет, к какому широкопечательному домену кадр следует отнести. Сейчас у меня, по-моему, картинка тут была. Да, картинка есть. Кадры, которые могут приходить, могут быть до 1522 байт в размере. Формат, как у кадра Ethernet 2 с Ethertype 8100. Если у вас есть два коммутатора, которые друг на друга смотрят 802.1 кьюшными портами, но в серединке откуда-то берется уродец свитч, который 802.1 кьюшный не поддерживает, он все равно такие кадры сможет прокоммутировать. То есть с его точки зрения это просто нормальный кадр Ethernet 2. У него чек-сумма правильная, у него MAC-адрес источника есть, у него MAC-адрес получателя есть, у него даже Ethertype есть. Да, Ethertype 8100. Но свитчам абсолютно пофигу, что там внутри лежит, какое там поле Ethertype.

Если ему не пофигу, он скорее всего знает, что такое 802.1 кьюшный, потому что это достаточно широко известная технология. Но большинству свитчей абсолютно все равно, что внутри поля Ethertype лежит. Да, поле есть. Да, какие-то 2 байта. Да, там лежит странное число 8100. Ну и что? Чек-сумма при добавлении кадра портится. И, соответственно, после того, как вы отправили кадр с новой чек-суммой, с дополнительным заголовком соседу, сосед отправил своему соседу, другой сосед отправил третьему, третий четвертому. Четвертый сосед хочет отправить, допустим, этот кадр обычному абоненту. То есть вот вы нашли конечного получателя. Конечный получатель сидит за аксесс-портом. Такой кадр для отправки в аксесс-порт обычному пользователю надо будет обратно восстановить. То есть если вы взяли и модифицировали кадр Ethernet, добавили к нему удоб-заголовок, да, он при этом остался, формально говоря, кадром Ethernet, но он стал другим кадром Ethernet, не таким, которым его отправили.

Обычный получатель, как правило, не знает ничего про 802.1Q. Если ваш оригинальный отправитель отправил просто кадр, не 802.1Q, то оригинальный получатель должен получить оригинальный кадр без всяких 802.1Q. Отправили IP-пакет, вложенный в Ethernet. Ethertype был 0800. Вот получатель должен получить Ethertype 0800. Поэтому для конечных пользователей все вот эти вот самые VLAN, они будут абсолютно неважны, незаметны. И более того, большинство абонентских машин, скажем, просто обычных машин, компьютеров, ноутбуков, они с 802.1Q просто работать даже не будут уметь. Да, поддержка на уровне операционной системы, допустим, Windows 800.1Q есть в VANDIS, но в драйверах сетевых карт, как правило, просто нет возможности такие кадры обрабатывать. Они просто не будут обрабатывать кадры, которые приходят со вложением 8100. Вот.

Если вы, соответственно, собираетесь отправлять 802.1Q кадр абоненту, вы должны вот этот самый доп. заголовок стереть. И когда вы доп. заголовок стираете, кадр становится тем же самым кадром, что и раньше, за исключением чек-суммы. И вы чек-сумму должны заново пересчитать. Если вы каждый раз передавали кадр, и этот кадр не побился по дороге, то когда вы будете чек-сумму считать от нового кадра без 800.1Q, то чек-сумма при этом естественным образом станет такой же, какой она изначально и была. То есть вы ее посчитали по тому же самому механизму, каким считал ее отправитель. И у вас естественным образом чек-сумма выросла та же самая. Что касается содержимого поля TCI, то самое... Сейчас, как он назывался? На предыдущем слайде было. Tag Control Information. У нас там будет 16 бит, 2 байта. 12 бит VLAN идентификатор,

собственный номер VLAN. 3 бита поля приоритета. Опять же, вы можете туда ничего не записывать, там будут тогда нули. Это будет означать, что все кадры, которые вы отправляете, они все отправляются без каких-либо дополнительных меток, для того, чтобы обеспечить разным кадрам разный заказ по качеству обслуживания. Вы можете туда написать что-нибудь. Вы не обязаны это делать, но вы можете. Из этого совершенно не следует, что соседний свитч будет как-то эти метки читать. То есть, если вы туда напишите 3 единицы, 7, не факт, что соседний свитч будет принимать какие-то кадры и будет на основе этих меток что-либо делать. Обычно, когда вы будете реализовывать концепцию Quality of Service, у вас все железки будут друг другу доверять, и все железки будут активно искать эти метки, которые приходят в кадрах, полученных от соседних железок. То есть, приходит какой-то кусок данных от соседа, и вы знаете, что сосед эти метки проставил правильно, и вы доверяете этим меткам, проставленным соседам,

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

Если там поменьше число, то поменьше. Но рассчитывать на то, что это всегда так, вы не можете. Поэтому если вы делаете quality of service, делайте так, чтобы все железки в пределах вашего административного домена, они друг другу доверяли, а на границе доверия бы не было для устройств, которые не принадлежат вашей автономной системе. Далее. Следующий момент. Да, то, что кадры, которые могут отправляться, они могут отправляться с меткой или без метки. Обычные пользователи отправляют, естественно, кадры без меток. То есть они просто отправляют самые обычные кадры из Ornette. В поле Zortype указывают по-честному, что внутри лежит. Свитчи друг к другу могут отправлять кадры 802 ZinQ с метками. Они от этого не перестают быть кадрами из Ornette, но это становится другой кадр, хотя он несет внутри в себе кадр оригинальный. И отличается от оригинального именно тем, что появляется дополнительная метка с указанием VELA. На обычных пользователей мы отправляем только обычные кадры.

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

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

и по умолчанию у вас на самом деле все порты, которые будут на оборудовании работать, допустим, на ЦИСКе, они как раз задействуют эти механизмы, и у вас все порты будут, которые даже транковые, по умолчанию почему-нибудь работать, они будут использовать именно отправку одновременно пакетов с метками и без меток кадров. Так вот, с вот этим механизмом отправляем одновременно и такие, и сякие кадры, надо будет разобраться. Этот механизм будет называться Native VLAN. Для начала заметим следующий момент, что если вы отправляете кадры на интерфейсе транковом с метками, то это означает, что как минимум два VLAN у вас будут передаваться по этому порту. Ну, логично, что вы не будете городить огород, если у вас все кадры будут принадлежать к одному и тому же VLAN. Поэтому предполагаем, что как минимум два VLAN передавать надо. Если вы кадры одного из этих VLAN помечаете метками, то все как бы понятно. Если вы кадры второго VLAN и там, вот у вас всего два VLAN есть, кадры второго VLAN тоже помечаете метками, тоже как бы все в порядке.

Что будет, если вы сделаете следующую штуку? У вас есть кадры там первого, второго, третьего, четвертого, пятого VLAN, которые вы помечаете метками, и есть еще какие-то кадры, которые вы не помечаете метками. Вы их просто отправляете. Неважно, что происходит на отправителе. Давайте разберем, что происходит на получателе. Вот получатель получает первый кадр. В нем написано «Привет, я тегированный кадр, у меня есть заголовок 802.1Q, из RTIP8100, я принадлежу к VLAN-у номер один». «Окей», — говорит наш свитч-получатель, «я отношу этот кадр к VLAN-у номер один» и откладывает его в сторону таблицы коммутации, которые занимаются коммутацией в первом VLAN. Приходит второй кадр, в нем написано «я VLAN номер два». «Окей», — говорит наш свитч, и отдает этот кадр на коммутацию в таблицу номер два. Приходит третий, четвертый, пятый кадр, но у всех у них есть метка VLAN-а, их отправляют в соответствующую таблицу коммутации соответствующему широковещательному домену. У каждого широковещательного домена есть отдельная таблица коммутации. Дальше приходит один кадр, у которого нет метки VLAN-а.

Вы должны будете такой кадр отнести к одному из широковещательных доменов, которые у вас есть на системе. Ровно к одному. Вы не можете его прокоммутировать по нескольким сразу таблицам, потому что вам нужно определить ровно один исходящий порт, или несколько исходящих портов, которые относятся все равно, тем не менее, к одному и тому же широковещательному домену. И как вы это можете сделать? Вот вам придется принять решение, исходя из свойств этого кадра, как и всегда. Номер VLAN-а в явном виде на пакете не написано. Поэтому вы говорите, все кадры, которые приходят без указания метки VLAN, так называемые untagged кадры, вы определяете их как принадлежащие ровно к одному к конкретному VLAN-у. То есть вы договорите тогда, все кадры, которые приходят с меткой 1, 2, 3, 4, 5, я отправляю в 1, 2, 3, 4, 5 VLAN-ы, а все кадры, которые приходят без метки, я отправляю в 3 VLAN. Вот потому, что если оно приходит без метки, это означает, что свитч-отправитель

мне дал понять отсутствием этой метки, что это кадр 3 VLAN-а. Не может быть ситуации вида кадры, которые идут с меткой. Я обрабатываю так, а кадры, которые приходят без метки, мне надо тоже каким-то образом разделить на 2 разных VLAN-а. Вот те VLAN-ы, которые были разные, они помечены. Поэтому все кадры, которые приходят без метки, они все одинаковые, и все их надо обрабатывать однотипно. И я просто говорю своей свитчовой волей, что я все их отправляю в 3 VLAN. На них не написано, что это 3 VLAN. Вы должны свитчу заранее, через какой-то административный инструмент, сказать, это все должен быть 3 VLAN, или 5 VLAN, или 7-й, неважно какой. Вы можете технически, если вы захотите, отправлять все кадры 3 VLAN без метки на отправителя. Или, если захотите, можете часть кадров 3 VLAN отправлять с меткой, часть кадров без метки. Отправитель волен делать как угодно. Но получатель, соответственно, он может сказать, что если метка указана действием по метке,

если метка не указана, определяем, что этот кадр принадлежит ровно к этому VLAN. И такой VLAN будет называться native VLAN. С точки зрения отправителя, вы должны будете, соответственно, точно такой же номер VLAN указать на отправителя, что если у нас есть желание отправлять какие-то кадры без метки, это должны быть кадры ровно вот такого вот 3 VLAN. Более того, вы должны будете сказать еще одну штуку. Вот к вам приходит какой-то кадр 3 VLAN. Вы должны его дальше перебросить в транковый порт. Этот самый транковый порт, у него прописан native VLAN 3. То есть вы должны будете принять решение. Да, мы можем отправить без метки, и этот кадр правильно обработается. Но мы можем также вы отправить и с меткой. Вот надо будет указать, надо вешать метку на native VLAN или не надо. Как правило, правилооборудование более-менее серьезного класса позволяет вам указать, надо ли native VLAN кадры обрабатывать и посылать с меткой.

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

он называется native VLAN. Тогда все остальные кадры, которые будут не native VLAN, они точно пойдут с меткой. Все кадры, которые приходят к нам с меткой, мы их определяем, принадлежность VLAN по метке. Все кадры, которые приходят к нам без метки, мы говорим, это кадры native VLAN. А что будете вы делать с кадрами native VLAN? Как вы будете отправлять в этот транковый порт? Это вы сами уже решаете. Хотите с меткой, хотите без. Изначально идеология native VLAN, естественно, была, что отправляются без метки, принимаются без метки. Что будет, если native VLAN один? Ну, ничего страшного не будет. То есть, типичный сценарий, это вы принесли, допустим, Cisco Switch домой, взяли, купили в магазине, принесли, распаковали, включили в сеть. У него обычно все порты аксессовые. То есть, если вдруг вы нигде не переключили режим транка на порту, то у него все порты в аксессии, все порты в первом VLAN. И у него других никаких VLAN нету, ну, кроме 1200, 1300, 1400, 1500, 1500. Так что все порты как бы работают,

как обычный тупой неуправляемый Switch. Но у Cisco Switch, особенно старых, если вы помните, там есть такой протокол, который называется Dynamic Trunk Protocol, когда два Cisco Switch друг с другом могут установить транк, хотя их об этом никто не просил. На новых Switch эта штука находится в таком полусонном состоянии, она как бы не против, если вдруг кто-то будет активно пытаться согласовать с вами транк. Но, если, соответственно, вы просто два новых Switch соединяете друг с другом, транк автоматом там не согласуется. Это надо взять один старый Switch, или один новый. Либо на одном из новых Switch, соответственно, если вы два новых Switch друг с другом дружите, этот самый DTP перевести в активную фазу, чтобы он активно пытался транк согласовать. Вот. DTP из Chadi, да, вот он на современных Switch такой полувыключенный, но не совсем довыключенный. Поэтому на него тоже можно устроить атаку, но все-таки эта атака будет характерна именно для Cisco Switch, поэтому мы сейчас ее не рассматриваем. Да, но вот он бывает, и может быть такое,

что вы купили Cisco Switch, поставили друг с другом, и они между собой автоматом согласовали транк. И на этом транковом порту по умолчанию на Cisco Switch будет работать первый VLAN в режиме native VLAN. Да, на Cisco Switch по умолчанию, который только что вы принесли из магазина, никаких VLAN нету, кроме первого. И первый VLAN на транковом порту будет native. Поэтому, от того, что у вас там транк согласовался, кадры при этом видоизменяться никак не будут. У вас Switch как поддерживал VLAN, так и поддерживает. Как все кадры, которые вы отправляли, относились к первому VLAN, так и относятся. Как кадры без башки передавались по транковому порту, так они и передаются. Так что, от того, что там транк этот самый согласовался, на самом деле ничего не изменилось. Просто имейте в виду, что native VLAN, он нужен именно для очень редкого сценария вида. Вам хочется обеспечить поддержку пользователей, которые сидят в промежутке между двумя умными свечами, которые умеют 802.1Q, а сами пользователи 802.1Q не умеют.

Вот именно для этого сценария нужен native VLAN. Во всех остальных случаях native VLAN использовать не надо. Он очень, скажем, неприятные последствия может вам обеспечить, если вы его будете использовать в неправильном сценарии, там, где он совершенно не нужен. И на него можно устроить ряд очень гадких атак. Поэтому не надо использовать native VLAN в тех ситуациях, когда вам точно понятно, что без них никак не обойтись. Если можно без них обойтись, лучше обойтись без них. Каким образом можно без них обойтись? Ну, самый простой способ это сказать, native VLAN будет такой, у которого на нашем свече нету тупо таблицы коммутации. То есть, мы, допустим, говорим, у нас на свече есть VLAN 2, 3, 5, 7. Вот у нас есть таблица коммутации, таблица MAC адресов за 2, за 3, за 5, за 7 VLAN. А мы дальше говорим, native VLAN объявляется 999 VLAN. Если кадры приходят и мы говорим, что кадры, которые без метки относятся к 999 VLAN,

вы запутаетесь запустить коммутацию по 999 VLAN, а у вас таблицы коммутации за этот широкосъщательный домен нету. И таблица коммутации вам говорит, я тебе не могу этот кадр прокоммутировать, сбрасывай его, потому что, ну вот, что с ним еще делать? Мы не можем ни один порт тебе сказать, что он теоретически может принять такой кадр. Мы даже Unicast Flading сделать не можем, потому что в этом порту вообще в этом VLAN ни одного порта нет. Поэтому, ну, порт неиспользуемый, да, VLAN неиспользуемый. То, что администратор сказал, кадры, которые без башки прибежали, относить к этому VLAN, против администратора попереть нельзя. Так что, вот, рекомендация по работе с native VLAN, это сделать так, чтобы с обеих сторон native VLAN был одинаковый, и чтобы он, более того, был неиспользуемый. Чтобы невозможно было кадры на ваш свитч отправить без 802.1Q-шной башки, и эти кадры как-то прокоммутировались. Идеальный вариант, когда кадр приходит, и вы его сразу расстреливаете, потому что, вот он такой

уродец без башки. Нормальные кадры между свитчами у вас будут передаваться с дополнительным заголовком 802.1Q. Да, это повлечет за собой перерасход в 4 байта на каждый кадр, но зато это позволит вам защититься от достаточно неприятных и гадких атак на этот самый native VLAN. Продолжение следует...