1.17 Как объединить три и более компьютера в сеть или зачем нужны коммутаторы
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжаем изучать основы работы компьютерных сетей, напомню, что эти записи основаны на программе Cisco ICND1 и помогут вам подготовиться к экзаменам CCENT/CCNA. В этой теме мы поговорим о том как объединить три или более компьютера в одну сеть, а в процессе этого разговора мы разберемся с вопросом: зачем нужны коммутаторы и какие преимущества они нам дают.
Перед началом я хотел бы вам напомнить, что ознакомиться с опубликованными материалами первой части нашего курса можно по ссылке: «Основы взаимодействия в компьютерных сетях».
Содержание статьи:
1.17.1 Введение
Ранее мы очень много времени уделяли теоретическим вопросам и пытались в общих чертах разобраться с тем, как функционирует наша компьютерная сеть, теперь давайте поговорим немного про практические задачи и попробуем разобраться с тем как наладить взаимодействие между тремя и более конечными устройствами компьютерной сети, в частности, тремя компьютерами, для этих целей нам потребуется коммутатор.
Мы наконец-то опять воспользуемся Cisco Packet Tracer и попробуем собрать более сложную и интересную схему с использованием коммутаторов и нескольких компьютеров, обратите внимание: сейчас мы не рассматриваем хабы, они уже морально устарели, также в данной теме на неважно какой перед нами коммутатор: управляемый или неуправляемый, для нас это пока просто коммутатор, а в дальнейшем мы будем работать только с управляемыми коммутаторами.
1.17.2 Вспоминаем схему соединения двух узлов
Давайте вспомним нашу простую компьютерную сеть, в которой было ровно два участника, схема такой сети показана на Рисунке 1.17.1. Напомню, что устройства одного уровня модели OSI 7 при классической схеме включаются витой парой с перекрестным обжимом, на рисунке это показано пунктиром.
Скорее всего вы уже слышали о том, что для компьютера есть три очень важных параметра для сетевого подключения: IP-адрес, маска и основной шлюз. В нашем случае мы не задаем конечным устройствам шлюз по умолчанию, так как все наши устройства находятся в одной канальной среде или в одной подсети, поэтому шлюз не нужен, если бы нам нужно было попасть в другую сеть, то тогда нам бы потребовался шлюз, а сейчас этого нам не нужно.
Понять факт того, что два устройства находятся в одной подсети можно по комбинации IP-адреса и маски сети, с этим мы разберемся в дальнейшем. Результаты проверки при помощи утилиты пинг говорят нам, что все хорошо: компьютер может взаимодействовать с ноутбуком (Рисунок 1.17.3), а ноутбук с компьютером (Рисунок 1.17.2).
Пинг проходит, потерь нет, всё здорово.
В обратную сторону ситуация аналогичная, все хорошо работает. Давайте посмотрим на физический интерфейс ноутбука и компьютера, то есть на сетевую карту, которая выполняет работу сразу на трех уровнях эталонной модели сетевого взаимодействия или на двух уровнях модели стека протоколов TCP/IP, в Cisco Packet Tracer это сделать можно, достаточно кликнуть два раза левой кнопкой мышки по устройству, находящемуся в рабочей области, а затем в появившемся окне выбрать вкладку Physical.
Ноутбук и доступные для него интерфейсы показан на Рисунке 1.17.4, вкладку Physical я выделил красным прямоугольником, сетевая карта ноутбука выделена зеленым.
Слева показаны интерфейсы, которые можно использовать в качестве сетевой карты ноутбука. Если нажать левой кнопкой мышки на тот или иной интерфейс, то в нижней части окна появится его краткое описание и примерный внешний вид, это показано на Рисунке 1.17.5
Сетевые карты на ноутбуке в Cisco Packet Tracer (о других стандартных физических компонентах компьютерной сети вы можете почитать в соответствующей публикации) меняются очень просто: сначала нам нужно выключить ноутбук, нажав на кнопку питания, выделенную желтым на Рисунке 1.17.4, затем зажать левой кнопкой мышки на текущей сетевой карте ноутбука и перетащить ее в левую область, где расположен список сетевых модулей, таким образом мы извлекли сетевую карту из ноутбука, затем нам нужно выбрать новую сетевую карту из списка, зажать на ней левую кнопку мыши и перетащить ее в освободившийся разъем на устройстве, после этого не забудьте включить питание.
На Рисунке 1.17.6 показана вкладка Physical, но уже для стационарного ПК, выглядит и меняется это все аналогично.
Обратите внимание: что у ноутбука, что у стационарного ПК в сетевой карте один разъем для подключения. Тут логично задуматься над вопросом: что делать, если нам нужно соединить три или больше устройств и заставить их работать вместе?
1.17.3 Что если узлов нужно соединить больше, чем два?
Первое, что приходит на ум – добавить каждому устройству по сетевой карте и соединить эти устройства между собой. Ломовое решение, допустим, на стационарном ПК это бы и получилось, есть сетевые карты с двумя и более разъемами, есть конструктивные решения, которые позволяют нам добавить сетевую карту к ПК, но что делать с ноутбуком, там-то сетевую карту не добавишь. И допустим, нам нужно объединить три ПК между собой, и мы даже нашли ноутбук с двумя сетевыми картами, давайте посмотрим на схему, которая показывает такое соединение на Рисунке 1.17.7.
Помните, мы говорили о физической и логической топологии компьютерной сети, сейчас мы по сути реализовали топологию full mesh, хотя в данном случае это можно назвать еще и кольцом, хотя как кольцо эта схема не будет работать, это видно по IP-адресам, которые заданы на интерфейсы сетевых карт.
Итак, на схеме показано три компьютера, соединенных между собой витой парой, что же не так с этой схемой? Давайте посмотрим, во-первых, пришлось потратить денег для того, чтобы купить по дополнительной сетевой карте каждому участнику сети, вас никто не погладит по головке за дополнительные расходы. Во-вторых, соединение в такой схеме должно быть каждый на каждого, чтобы узлы общались друг с другом без проблем.
Третий момент, избыточность соединительных линий, а это тоже дополнительные расходы на монтаж этих самых линий и затем на дальнейшее обслуживание, кабель бесплатно никто прокладывать не будет. Четвертый момент, неэкономное расходование IP-адресов, да сейчас мы используем частные IP-адреса, которых для небольших сетей хватит за глаза, но проблема в том, что в данном случае для соединения трех машин между собой мы использовали три подсети: 192.168.1.(1-255), 192.168.2.(1-255), 192.168.3.(1-255). Но по сути только лишь в первую подсеть мы могли бы включить 253 машины, а включили только две, хотя тут можно было бы использовать и более мелкие подсети, но мы с масками пока не работали и сейчас ничего не будем усложнять.
Пятый недостаток заключается в масштабируемости такой сети, представьте, что в эту сеть вам потребуется добавить четвертый компьютер, если следовать выбранному принципу, то получится примерно такая схема, как показано на Рисунке 1.17.8.
Итак, для того чтобы соединить четыре компьютера нам потребовалось по три сетевых карты на каждом устройстве, шесть соединительных линий и шесть подсетей, по сути мы сейчас лишились всех тех преимуществ, который дает нам технология Ethernet, но также мы устранили некоторые недостатки этой технологии, об этом обо всем мы поговорим в отдельной части, посвященной технологии Ethernet, сейчас просто обратите внимание на все те неудобства, которые несет схема соединения каждый на каждого, их на самом деле больше, но мы перечислили самые очевидные. Для решения этой проблемы я перечислю вам три способа: использовать схему с общей шиной и коаксиальные Ethernet провода, использовать хаб и использовать коммутатор.
Про хабы и схему с общей шиной мы поговорим в отдельных темах, благо что сейчас вы их редко где встретите, также не стоит путать хабы с простенькими неуправляемыми коммутаторами, в основе их работы лежат разные физические и канальные процессы, ну а про коммутаторы мы сейчас немного поговорим и посмотрим, как они могут облегчить вам жизнь.
1.17.4 Нас спасает коммутатор
Итак, у нас стоит задача объединить четыре компьютера в локальную сеть без лишних трудозатрат, для решения такой или подобной задачи в современных компьютерных сетях используются коммутаторы, на данном этапе нам даже не важно что за коммутатор перед нами: управляемый или простенький неуправляшка. Давайте посмотрим на то, как преобразится наша схема, если мы будем использовать коммутатор. Тут стоит сказать, что с добавлением коммутатора изменится не только топология, но и другие характеристики планируемой компьютерной сети. Давайте сперва добавим коммутатор в проект Cisco Packet Tracer, где найти коммутаторы показано на Рисунке 1.17.9.
Чтобы добавить коммутатор в проект нужно сперва нажать на иконку, выделенную зеленым, затем желтым, а после этого перетащить в рабочую область красную иконку. Тем самым вы добавите в проект коммутатор Cisco 2960 – это один из самых простых и дешевых управляемых коммутаторов Cisco, который чаще всего используется на уровне доступа в корпоративных сетях, если они построены на базе оборудования Cisco.
Обратите внимание на Рисунок 1.17.10, здесь показаны порты коммутатора Cisco 2960. У данного коммутатора имеется один консольный порты, который используется для первоначальной конфигурации устройства, 24 медный порта с пропускной способностью 100 Мбит/c (про скорость передачи данных можно понять по надписи FastEthernet), обычно эти порты используются для подключения конечных абонентов, а также два гигабитных медных порта, которые чаще всего используются для соединения коммутатора с другими коммутаторами или маршрутизаторами.
Иногда первых двадцать четыре порта называют access-портами или портами доступа, что не совсем корректно. Да, эти порты чаще всего используются для подключения конечных абонентов, но никто не запрещает вам использовать эти порты для соединения с другими коммутаторами/маршрутизаторами. Два гигабитных порта иногда называют транковыми, поскольку они используются для соединения с другими транзитными устройствами сети, но опять же, эти порты можно использовать и для подключения конечных абонентов, никто этого вам запретить не может. Само логическое состояние порта: транк(trunk) и access мы обсудим и поговорим про настройки, когда начнем разбираться с вланами.
Как выглядит лицевая панель коммутатора Cisco 2960, а также других устройств от Cisco, можно посмотреть в самом Cisco Packet Tracer, достаточно кликнуть дважды на интересующее устройство и в левом верхнем углу появившегося окна выбрать вкладку Physical, появится рисунок устройства, который можно приближать и удалять, лицевая панель нашего коммутатора показана на Рисунке 1.17.11.
Теперь давайте объединим наши компьютеры в сеть при помощи коммутатора, обратите внимание на Рисунок 1.17.12. Тут нужно сказать вот о чем: при подключении к порту коммутатора вы не сможете тут же начать передавать данные, главным образом из-за того, что работает протокол защиты от петель STP, который в первичной своей редакции очень медленный, также при подключении коммутатор согласовывает физические и канальные характеристики передачи данных с удаленным устройством, но это уже влияет не так сильно.
О том, что передавать данные еще нельзя, говорит нам оранжевая индикация со стороны коммутатора, с появлением зеленой индикации можно начинать передавать данные. На Рисунке 1.17.13 показана та же схема, но здесь коммутатор уже готов к передаче данных.
Об этом нам говорит зеленая индикация с обеих сторон. Также обратите внимание на то, что для конечных устройств я задал IP-адрес и маску подсети, а к настройкам коммутатора я не прикасался вовсе, для работы схемы в данном случае нам это не нужно, сейчас мы можем даже считать, что на коммутаторе нет IP-адреса. Также обратите внимание, если навести курсор мыши на зеленую лампочку и немного его там подержать, появится подсказка в виде портов, в которые включен выбранный кабель, на Рисунке вы можете видеть надписи Fa0 и Fa0/1, эти надписи появились после наведения и говорят о том, что первый компьютер включен в порт коммутатор FastEthernet0/1.
Теперь давайте проверим работоспособность схемы, зайдем на первый ПК и пропингуем с него три других, результаты показаны на Рисунке 1.17.14.
Мне следует сделать небольшое примечание уже сейчас: в нашей импровизированной компьютерной сети в качестве транзитного узла используется коммутатор, то есть устройство канального уровня нашей компромиссной модели передачи данных, которую мы выработали, когда разбирались с моделью стека протоколов TCP/IP. А это очень важно, так как это означает, что для передачи данных по нашей сети сетевой уровень не используется вовсе, так как транзитный узел не умеет работать с IP-адресами, то есть, если посмотреть на инкапсуляцию данных в такой сети в процессе их передачи, то мы не увидим заголовков сетевого уровня (IP-протокол просто не используется), если выполнить декомпозицию взаимодействия в сети с коммутаторами, то мы увидим, что для передачи данных из точки А в точку Б будет достаточно только двух уровней: физического и канального.
Как видим, пинг проходит до всех участников сети без потерь, для полной проверки нужно повторить эту манипуляцию со всех устройств, но это уже вы сможете сделать самостоятельно. Сейчас же я хочу вернуть вас к схеме с четырьмя устройствами, соединенными напрямую, там у нас было три сетевых карты на каждом устройстве, шесть соединительных медных линий, а также мы использовали шесть подсетей, в которые можно было включать до 253 устройств. С появлением коммутатора наша жизнь резко изменилась, нам потребовалась одна подсеть, из которой мы заняли четыре IP-адреса по числу устройств (192.168.1.1, 192.168.1.2, 192.168.1.3, 192.168.1.4), на каждом конечном устройстве по одной сетевой карте, так как больше и не надо, а для соединения нам потребовалось четыре медных линии типа витая пара, кстати, обратите внимание: конечные устройства соединяются с коммутатором при помощи витой пары с прямой схемой обжима, так как Cisco Packet Tracer считает, что компьютеры находятся на сетевом уровне модели OSI 7, а коммутаторы доступа находятся на канальном уровне эталонной модели.
Давайте сейчас попробуем сделать широковещательный запрос в нашу сеть, для этого нам нужно с первого компьютера пропинговать самый последний IP-адрес подсети, в которой он находится, в данном случае это 192.168.1.255. Сейчас я попытаюсь дать поверхностное объяснения тому, как я определил широковещательный IP-адрес, в дальнейшем будет более подробный разговор.
У нашего первого ПК задан IP-адрес 192.168.1.1 с маской 255.255.255.0, это означает, что IP-адреса других компьютеров, которые могут находится в одной подсети или в одном широковещательном домене с первым компьютером, должны начинаться с 192.168.1.x, а вот в качестве «x» может быть любое число от 0 до 255, но дело в том, что IP-адрес 192.168.1.0 – это номер нашей подсети и его нельзя задавать конечным устройствам, также, как и IP-адрес 192.168.1.255, который является широковещательным IP-адресом, если попробовать пропинговать такой адрес, то наш компьютер обратится ко всем узлам, которые находятся с ним в одной подсети, в современных компьютерных сетях широковещательные IP-адреса используются для служебных целей, например, чтобы получить IP-адрес от DHCP-сервера. Хочу сразу заметить, что не стоит обобщать широковещательный трафик с видами сетевого взаимодействия, которых мы говорили, это совсем другая классификация. Обратите внимание на результаты работы команды ping 192.168.1.255 в рамках нашей схемы, он показан в листинге ниже:
[php]
C:\>ping 192.168.1.255
Pinging 192.168.1.255 with 32 bytes of data:
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.4: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.4: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time<1ms TTL=128
Reply from 192.168.1.4: bytes=32 time<1ms TTL=128
Reply from 192.168.1.2: bytes=32 time<1ms TTL=128
Reply from 192.168.1.3: bytes=32 time=1ms TTL=128
Reply from 192.168.1.4: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.255:
Packets: Sent = 4, Received = 12, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms
[/php]
В данном случае мы сделали четыре широковещательных запроса и четыре раза нам ответили узлы, находящиеся в одной с нами подсети, этот процесс можно рассмотреть более детально в режиме симуляции Cisco Packet Tracer, как это сделать показано на Рисунке 1.17.15.
Сначала нажмите на иконку, выделенную зеленым в правой нижней части, а затем нажмите на кнопку Show All/None, дело в том, что по умолчанию Cisco Packet Tracer показывает пакеты нескольких десятков протоколов в режиме симуляции, нам это будет только мешать, нажатие на эту кнопку говорит Packet Tracer о том, что никакие пакеты показывать вообще не надо, после этого нужно будет нажать на кнопку Edit Filters, у вас должно появиться примерно такое окно как на Рисунке 1.17.16, здесь нужно будет поставить галочку напротив ICMP.
Утилиты ping и tacert как раз-таки и используют протокол ICMP для своих задач, об этом протоколе мы поговорим чуть позже, когда будет разговор об IP протоколе, также обратите внимание, что есть еще утилита traceroute, которая не тоже самое, что и tracert, traceroute использует для диагностики UDP дейтаграммы.
Давайте попробуем пропинговать широковещательный IP-адрес в режиме симуляции, результат показан на Рисунке 1.17.17.
Как видим, от удаленных машин нет никаких ответов, все дело в том, что процессом передачи данных в режиме симуляции мы управляем вручную, наш ПК еще даже не отправил запрос, поэтому мы ничего не видим в командной строке. Обратите внимание на следующий Рисунок.
Здесь показано состояние нашей компьютерной сети сразу после того, как мы выполнили команду ping 192.168.1.255. Также обратите внимание на то, что возле первого ПК появился фиолетовый пакет, это означает, что наш компьютер сформировал пакет, но пока его еще не отправил, чтобы он отправил этот пакет, да и вообще, чтобы посмотреть что будет дальше, нужно нажимать на кнопку «Capture/Forward» в правой части окна Cisco Packet Tracer, чтобы вернуться на шаг назад нужно нажать на кнопку «Back».
После первого нажатия на кнопку Capture наш пакет с ICMP вложением попадет на коммутатор, при этом в командной строке мы еще ничего не увидим, так как этот пакет принадлежит не коммутатору, он на него не отвечает, а лишь пересылает его дальше, руководствуясь пока непонятными для нас механизмами, но мы с этими механизмами обязательно разберемся в дальнейшем.
На следующем шаге коммутатор разошлет ICMP-пакеты до всех участников нашей локальной сети и при этом состояние командной строки никак не изменится, так как компьютер, пославший ICMP запрос при помощи команды Ping еще не получил ответ, его пакет только дошел до адресатов. Стоит сделать еще одно примечание: коммутатор понял, что полученное сообщение является широковещательным не по IP-адресу, а по мак-адресу, указанному в кадре в качестве мак-адреса назначения (да, мак-адреса тоже бывают широковещательными).
На следующем Рисунке показан следующий шаг: 2, 3, 4 компьютеры ответили первому на его ICMP запрос и кадры с ICMP вложением дошли до коммутатора, состояние командной строки первого ПК на данном шаге никак не меняется, поэтому я его не показываю, наш ПК до сих пор не получил ответ на свой запрос.
Нам не стоит бояться, что данные перепутаются, или произойдет коллизия, современный Ethernet практически исключает такую вероятность, хотя коллизии могут и случаться. Также обратите внимание, что на двух пакетах из трех нарисован значок паузы, все дело в том, что у каждого порта коммутатора есть входной и выходной буферы, пакет без значка паузы будет передан первым, так как он первый в очереди (вообще о принципах работы коммутатора мы поговорим отдельно, сейчас просто запомните, что одной из причин, по которой в современном Ethernet коллизии очень маловероятны, является входные и выходные буферы коммутатора, Ethernet-кадры ожидают в этих буферах до тех пор, пока коммутатор не поймет что с ними делать и не выделит ресурс на их дальнейшую обработку).
Для того чтобы все три пакета были отправлены с коммутатора на ПК1, нужно нажать три раза кнопку Capture. Результат показан на Рисунке 1.17.22, также на этом Рисунке показаны изменения, произошедшие в командной строке первого компьютера, здесь у нас появилась информация от трех ответах от трех других участников сети и за какой время были получены ответы.
Обратите внимание: утилита Ping в своем стандартном режиме отправляет четыре пакета с ICMP вложением, мы сейчас посмотрели только на путь первого пакета, смотреть на путь последующих пакетов уже будет неинтересно, хотя вы самостоятельно можете понаблюдать за дальнейшим развитием событий.
1.17.5 А что если IP-адреса узлов будут из разных подсетей?
Мы убедились, что коммутатор – это очень удобная штука, которая может сэкономить нам деньги и время, а также избавить сетевого инженера от множества проблем, связанных с обслуживанием сети, управляемые коммутаторы еще и упрощают диагностику неполадок на сети и их (управляемые коммутаторы) можно мониторить при помощи специальных приложений. Но давайте попробуем провести еще один эксперимент. В первом случае все узлы нашей сети имели IP-адреса из одной подсети, то есть находились в одном широковещательном домене, давайте подключим к нашему коммутатору еще два узла, которые будут находиться в другой подсети, скажем 192.168.2.25 и 192.168.2.120, у обоих будет маска 255.255.255.0. Новая схема показана на следующем рисунке.
Таким образом получается, что ноутбуки у нас находятся в подсети 192.168.2.х, а стационарные ПК находятся в подсети 192.168.1.х. Давайте попробуем с ноутбука .25 пропинговать другой ноутбук, сделать широковещательный запрос и пропинговать первый стационарный компьютер. Результат показан в листинге ниже:
[php]
Packet Tracer PC Command Line 1.0
C:\>ping 192.168.2.120
Pinging 192.168.2.120 with 32 bytes of data:
Reply from 192.168.2.120: bytes=32 time=8ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Ping statistics for 192.168.2.120:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 8ms, Average = 5ms
C:\>ping 192.168.2.255
Pinging 192.168.2.255 with 32 bytes of data:
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Reply from 192.168.2.120: bytes=32 time=4ms TTL=128
Ping statistics for 192.168.2.255:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 4ms, Average = 4ms
C:\>ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\>
[/php]
Сначала мы пинговали ноутбук, который находится с нами в одной подсети, на наши запросы мы получили четыре ответа, затем мы сделали широковещательный запрос (ping 192.168.2.255), логично, что ответ мы получили только от узла с IP-адресом 192.168.2.120, так как все остальные узлы находятся в другом широковещательном домене/канальной среде/подсети и классический L2 коммутатор никак не сможет нам помочь попасть из одной подсети в другую, он просто не умеет этого делать, зато у классического L2 коммутатора есть такая технология как VLAN, которая позволяет еще более надежно изолировать одну подсеть от другой.
В качестве самостоятельно работы рекомендую вам повторить схему и в режиме симуляции попробовать сделать широковещательный запрос, например, из первой подсети, тогда вы увидите, что в данной схеме коммутатор, получив пакет от источника, разошлет его всем подключенным устройствам в том числе и тем, что находятся в другой подсети, но вот устройства из второй подсети не станут отвечать на этот запрос, так как они умеют анализировать IP-адреса и по IP-адресу они понимают, что полученный пакет был адресован не им.
Если коммутатор не может объединить две подсети и сделать так, чтобы пакеты из первой подсети добирались до второй подсети и обратно, то возникает логичный вопрос: какое устройство может реализовать данный функционал? Все на самом деле очень просто, такой функционал реализуют роутеры или маршрутизаторы, как вам удобно, так и называйте. Теперь вы с легкостью сможете ответить на вопрос о том чем отличается коммутатор от роутера? Первые используются для объединения нескольких узлов в одну сеть, а вторые используются для того, чтобы организовать взаимодействие между двумя и более сетями, но об этом мы еще поговорим.
1.17.5 Выводы
Итак, мы буквально на пальцах разобрались с вопросами: зачем нужны коммутаторы и как объединить три и более компьютера в одну сеть при помощи этих самых коммутаторов. Но помимо всего прочего мы обозначили несколько важных и интересных тем, с которыми нам предстоит разбираться в дальнейшем, без понимания которых лучше даже не браться за работу.
Также прошу вас не пугаться чего-то незнакомого и новых терминов, в значение которых я сейчас не вдаюсь. Все дело в том, что общение между машинами, которое мы называем процессом передачи данных, это очень строгое и формализованное занятие, которое описывается огромным множеством протоколов со своими службами и технологиями, у каждого протокола и технологии есть свой словарь терминов, в итоге получается очень большая солянка, которую нужно как-то запомнить, сразу скажу, что специально заучивать термины не нужно, лучше концентрироваться на принципах работы.
В любом случае все необходимые термины и слова вы запомните, читая различные статьи в Интернете и книги, а также самостоятельно практикуясь, при этом процесс запоминания лучше происходит во время практики, поэтому запомните вы именно то, что вам будет необходимо для работы, а для всего остального у вас есть Яндекс и Google, понимая принципы работы и зная назначения технологии или протокола, найти нужное решение, инструкцию или подсказку в Интернете не составит труда.
А подскажи, пожалуйста, чем отличаются управляемые сетевые коммутатора от неуправляемых коммутаторов. И в чем разница между свичом или свитчем и коммутаторами, а то этот момент для меня не совсем понятен. Неуправляемый коммутатор это тоже что и сетевой концентратор или как?
Привет! Свич и коммутатор — это одно и то же, просто разные слова. Разница между управляемым сетевым коммутатором и неуправляемым действительно есть. Неуправляемый коммутатор ты достаешь из коробки, ставишь себе на сеть и он будет работать так, как его настроил производитель, никаких изменений и конфигураций на нем ты сделать не сможешь. Еще стоит добавить, что у управляемых коммутаторов обычно гораздо больше всяких плюшек и дополнительных технологий, которые ты можешь настраивать включать и отключать. Если интересно, зайди на сайт, например, D-Link, найди там описание и характеристики неуправляемого коммутатора, а затем сравни их с характеристиками управляемого. Пример неуправляемого коммутатора: D-link DES1008D, пример управляемого свича: D-Link DES 3200.
Что касается хабов и неуправляемых свичей — это разные вещи, хаб — это устройство физического уровня, оно ничего не знает о Ethernet кадрах и MAC-адресах и по сути не имеет программной логики, неуправляемый коммутатор в курсе, что есть кадры и мак-адреса и умеет с ними работать. У него есть своя небольшая таблица мак-адресов. Такая путаница происходит по одной простой причине: многие называют неуправляемый коммутатор хабом, хоть он им и не является, настоящие хабы ты уже вряд ли найдешь в магазинах.
А почему вместо сетевого коммутатора нельзя использовать сервер с несколькими сетевыми картами или сетевой картой с несколькими портами?
А кто сказал, что нельзя? Можно и иногда так и делают, например, сервер подключают к интернету, а затем он раздает этот интернет на устройства офисной сети. Но сервер не всегда удобно использовать, сам сервер обойдется, скорее всего, дороже. Плюс надо учитывать, что коммутаторы и роутеры — это по сути тоже компьютеры, только вот железо этих компьютеров заточено на обработку Ethernet кадров и IP-пакетов. Вообще, всё зависит от инженера, который занимается планированием сети, задач и бюджета, выделенного на эту сеть, иногда действительно может оказаться так, что сервер выгоднее поставить, чем связку роутер + сетевой коммутатор или L3 коммутатор. В общем, всё индивидуально.