Помогите понять разницу между коммутатором и маршрутизатором

Помогите понять разницу между коммутатором и маршрутизатором

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

А дальше, коммутатор просто перекладывает пакет из одного интерфейса. Маршрутизатор же смотрит на ip адрес назначения, сверяется с таблицей маршрутизации и отправляет пакет на нужный интерфейс уже от своего имени (мака). Если утрировать, то коммутатор передаёт данные внутри сети, а маршрутизатор между.

Разобраться подробнее и с нюансами типа вланов, mac таблиц, арпов и т.п. лучше читая сети для самых маленьких. На уровнях OSI я бы не стал заострять внимание, там можно только познакомиться с общим принципом абстрагирования функций и упаковки/распаковки данных при переходе между абстракциями.

В модели разработчика который пишет приложения на уровне UNIX сокетов. Вам из контекста не понятно, что TCP/IP разработчик в данном случае, это человек использующий стек TCP/IP, а не создаель протокола в 70ых?

Вот вообще не понятно. Более того, после вашего пояснения сама формулировка стала непонятнее ещё больше, т.е. если я использую функции glibc я могу себя называть glibc разработчиком?

А дальше, коммутатор просто перекладывает пакет из одного интерфейса

Себе в карман и делает вид, что так и было…

Попытки упрощать неупрощуемое делают только хуже.

При такой схеме, хотя бы один пакет должен рассылаться всем. А я давно не видел ни одного чужого пакета на дампах трафика со свича. Они слушают ARP пакеты, я уверен в этом до сих пор. С этих пакетов, начинается жизнь, рассылать пакет с данными всем, не секурно, а ARP и так широковещательный. Я постараюсь сегодня сходить и проверить это. Есть свич с работающими компьютерами. 11 штук, обмениваются друг с другом данными. Втыкаю в него ещё один, с вайршарком. Выключаю все компьютеры, кроме того, что с вайршарком. Включаю. Если ты прав, я должен поймать минимум 10 чужих пакетов. Ну, хоть сколько то. Заранее уверен, что нихрена не поймаю.

С этих пакетов, начинается жизнь, рассылать пакет с данными всем, не секурно, а ARP и так широковещательный.

Когда нет записи юниакст мака в мак таблице, то это unknown unicast, и он, по умолчанию, шлётся на все подходящие порты сразу. Если один из компов погаснет, мак пропадет из таблицы, а арп связка где-то останется и будет слать пакеты на этот мак, то ты увидишь у себя эти пакеты в вайршарке. Можешь повторить это создав статическую арп связку на несуществующий ипшник.

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

Вот вообще не понятно. Более того, после вашего пояснения сама формулировка стала непонятнее ещё больше, т.е. если я использую функции glibc я могу себя называть glibc разработчиком?

Люди же называют себя C, C++, Java разработчиками, хоть никогда не создавали эти языки. Точно также по аналогии люди зовут себя React, Laravel, RoR разработчиками, просто работая с этими фреймворками и не участвуя в их разработке.

А дальше, коммутатор просто перекладывает пакет из одного интерфейса.

Коммутатор (Switch) не работает с «IP пакетами», он пересылает Ethernet frames с одного физического порта на другой. Комутатор вообще не знает ничего про IP, он работает на уровне физических портов, а не логических IP адресов. С позиции программ работающих с IP: Switch ни чем от проводов не отличается, а провода ни чем не отличаются от радио-пространства, все это всего лишь среда передачи данных нижестоящих уровней и их протоколов.

Маршрутизатор (Router) это работает с IP и пересылает пакеты согласно правилам в нем прописанным. И обычно Router стоит на границе двух разных IP сетей переправляя пакеты между этими адресными пространствами.

Как раз только доскональное понимание уровней OSI, и того факта что реализация нижестоящего протокола ни как не влияет на функционирование вышестоящего (знаменитая шутка про IP на голубиной почте) помогает понимать разницу между Повторителями/Коммутаторами/Маршрутизаторами. Тут углы не срезать. Когда начинают срезать углы то путают L2 кадры с L3 пакетами.

Т.е. робит только на 75% Имхо ЧТД.

Просто меня жаба задушила брать проверенный АХ55 и я взял АХ53 подешевле, а он оказался глючным. Зависает раз в 3-4 недели. Но вообще я и кинетик раз в месяц ребутал. Я вообще, не уверен, что есть производители про которых можно сказать что у них ни одной глючной модели нет. Ну либо это из топа, где один роутер как 3 от туполинка будет стоить. Я тогда переберу 4 от туполинка и получу 3 рабочих за ту же цену.

Да я не против вашего unknown unicast правила, только за. Оно мне поможет. Я говорю о том, что до рассылки пакета данных всем дело не дойдет. Потому что свич слушает ARP пакеты, и на основе их строит MAC таблицы. А ARP - L3. Какого хрена тогда он L3?

и кинетик раз в месяц ребутал

У меня кинетик с какой-то обновы начал рандомно раздавать уже известным устройствам (зареганным и прибитым по маку к определенному айпи) какие-то левые «гостевые» адреса, хотя гостевая сетка вообще вся отключена :)

Так и не смог побороть. Ну и в принципе апгрейд давно назревал, заменил на китая с опенврт)

Читайте Столярова второй Том «Системы и Сети» пару глав 6го раздела. Он там все досконально рассказал. Еще Курячего с Маслинским главу «Сетевые протоколы. Семейство протоколов TCP/IP».

Тут в форуме столько ошибок, столько неверных трактовок, вы запутаетесь, запомните не правильно. Потом на собеседовании вас вежливо «выгонят в зашей». Так как вы покажете фундаментальное непонимание, а значит не способность отлаживать и настраивать и восстанавливать (код и сети).

Столяров и Курячий - оба талантливые рассказчики, пишут с юмором, легко и не казённо. В паре абзацев выделяют суть. Читайте, учитесь. В сетях углов не посрезать, надо чётко понимать причины и следствия.

Как раз только доскональное понимание уровней OSI…

Нихрена не помогает и достаточно поверхностного понимания принципа инкапсуляции разных уровней абстракции. Пониманию принципов работы эзернета и tcp/ip помогает изучение принципов работы эзернета и tcp/ip. А доскональное понимание OSI помогает сдать некоторые экзамены и показать себя с лучшей стороны в пространственных обсуждениях модели OSI.

А доскональное понимание OSI помогает сдать некоторые экзамены и показать себя с лучшей стороны в пространственных обсуждениях модели OSI.

Доскональное понимание модели OSI помогает в разработке сетевого ПО. И понимании чем занимается Kernel, а на каком уровне работает пользовательский процесс.

Оно не просто помогает, оно необходимо.

при наличии арп связки арп запросы никто слать не будет.

ARP таблицы чистятся, весьма часто. Дело в минутах.

Потому что свич слушает ARP пакеты, и на основе их строит MAC таблицы. А ARP - L3. Какого хрена тогда он L3?

Нет, он смотрит на мак источника и фиксирует порт. Что там выше его не касается, это не его проблемы.

Тогда, либо я должен поймать хотя бы немного чужих пакетов. Вот и проверю, как доберусь. Либо ARP - L2.

Доскональное понимание модели OSI помогает в разработке сетевого ПО

Напомню: вопрос, тащемта, про железки. :)

а на каком уровне работает пользовательский процесс.

Оно не просто помогает, оно необходимо.

Это скорее указывает на не понимание самой сути изучения модели OSI сейчас. Она существует для демонстрации принципов слоёв абстракции и инкапсуляции для построения сетей, а изучение истории принятых решений помогает не повторять уже пройденные ошибки.

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

Вот и проверю, как доберусь. Либо ARP - L2.

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

заменил на китая с опенврт

Я спрашивал, но так толком и не понял(или ответа нормального не получил). Можно ли на openwrt накрутить easy mesh вайфай? У меня территория 20 соток и 2 дома по 2 этажа, мне без mesh никак, постоянные разрывы будут при перемещении и переключении между точками доступа. Пока только от туполинка нашел вариант рабочий. Хотя, как линуксоиду, мне было бы приятнее на опенврт такое накрутить.

Это скорее указывает на не понимание самой сути изучения модели OSI сейчас.

Модель OSI это абстрактная модель, TCP/IP стек не совпадает с моделью OSI на прямую. Но разработчики используют модель OSI для общения и объяснения конкретики. Например пользовательский процесс работает на L4. В Kernel обрабатывается L2, L3.

Если человек не понимает модель OSI, и свободно в ней не ориентируется, он еще не получил квалификацию системного разработчика.

Что там за уровни у osi, на каком уровне согласно этой модели что-то происходит - не имеет никакого значения.

Имеет значение когда вы сказали «коммутатор пропускает пакеты», а не «коммутатор пропускает кадры». Потом вы начинаете успорять, что модель OSI не имеет значения. Это красный флаг. Досконального понимания сети нет.

Такой боец в команде не нужен, который упорствует и не понимает абстракций. Вы начинаете спорить «я не знаю, мне не надо». Поздравляю. Таких борцов с образованием половина LOR.

P.S.

И это не «докапывание» без разделение на «пакеты», «кадры», «сигналы» невозможно объяснить разницу между Router, Switch, Hub.

Это будет большое с маленкой полоской и большим кружочком, и большое с большой полоской и маленький кружочком - запоминание маслянистое масло масмленное и промасленное мало маслянистое. И мычание в ответ, без внесения ясности.

P.P.S.

Модель OSI объясняет принцип и создает словарь. В ТСP/IP этот принцип реализован и пользоваться словарем OSI удобно. Например четкое понимание, что реализация Ethernet не влияет на IP адресацию. Так как сеть может быть по коаксиальному кабелю, витой паре, по радио каналу или по опто-волокну - разные L1/L2 уровни, одинаковый L3. Физический и Канальный отличаются, а Сетевой одинаковый.

Люди же называют себя C, C++, Java разработчиками, хоть никогда не создавали эти языки. Точно также по аналогии люди зовут себя React, Laravel, RoR разработчиками, просто работая с этими фреймворками и не участвуя в их разработке.

С конкретными инструментами для разработки как раз все понятно. Но когда идет речь про конечную реализацию это как бэ другое, например «разработчик mso» != «разработчик под mso».

Модель OSI это абстрактная модель, TCP/IP стек не совпадает с моделью OSI на прямую. Но разработчики используют модель OSI для общения и объяснения конкретики.

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

Понимание этого принципа важно. Сколько там уровней в этом референсе, что там в уровнях, что на каком уровне этой модели - нет.

Например пользовательский процесс работает на L4. В Kernel обрабатывается L2, L3.

Пример того, как забить голову мусором.

И это не «докапывание» без разделение на «пакеты», «кадры», «сигналы» невозможно объяснить разницу между Router, Switch, Hub.

Всегда нужно учитывать на каком уровне обсуждается вопрос и целесообразность вдаваться в детали для его разъяснения. Про разницу между кадрами и пакетами человек может узнать потом, если это ему когда-нибудь потребуется. Что мало вероятно, так как даже сетевикам не всегда приходится на этот уровень опускаться.

Например четкое понимание, что реализация Ethernet не влияет на IP адресацию.

Это и есть принцип упаковки/распаковки при переходе между разными уровнями абстракций. Про который я и написал в первом сообщении. И он не только в сетях применяется.

Пример того, как забить голову мусором.

Вы интеллектуальный собеседник, в принципе говорите связно и по делу, зачем вы опускаетесь до «воинствующего невежества»?

Еще раз объясняю, это не мусор, а важная классификация для системного разработчика. Вам не надо, а тем кто работает с современными протоколами TLS, QUIC - надо.

Чисто практически понимание какой уровень OSI обрабатывает Kernel, а какой уровень пользовательский процесс - дает понимание зачем в NetBSD в ядре можно запускать Lua скрипты. Если на знать, что L2/L3 обрабатывает Kernel, то и не понятно зачем тащить Lua. А так ясно, для низкоуровневой работы с кадрами и пакетами.

Этот «быдло-стайл» - «а мине ваша матеймантика не нужна» лишний.

Всегда нужно учитывать на каком уровне обсуждается вопрос и целесообразность вдаваться в детали для его разъяснения.

Вы знаете я учился и прекрасно помню как воспринимается разница между Hub/Switch/Router. Без ключевого объяснения заменяемости нижних уровней теоретически и практического подкрепления терминами.

Ваша «Switch пропускает пакет» - это неопределенная метафора. Ключевая деталь для объяснения разницы это уровни OSI и «сигналы»/«фреймы»/«пакеты». Логически и Switсh и провод и волокно и волна - все они пакте пропускают. Но практически Switch пропускает кадр, а провода пропускают сигналы.

Переупрощение также усложняет объяснение как и переусложнение.

важная классификация для системного разработчика

Да при чем тут системная разработка? 😂

Сам придумал сам споришь, а чел ПРОСТО СПРОСИЛ чем свитч от роутера отличается 😂😂😂

Я вообще, не уверен, что есть производители про которых можно сказать что у них ни одной глючной модели нет.

Тут согласен, глюки у любого сохо это явление которое не вызывает удивления, другой вопрос в самих глюках и частоте этих глюков. Например если мне мой асус (что старый, что новый) приходиться ребутать только из-за хулиганства в энергоснабжении, то на фоне этого вариант «Зависает раз в 3-4 недели.» смотрится как-то сильно не очень.

Это и есть принцип упаковки/распаковки при переходе между разными уровнями абстракций. Про который я и написал в первом сообщении. И он не только в сетях применяется.

Да. Это классика которая входит в объяснение архитектуры сетей. Информация к передаче окружается метаинформацией нижний слоев у отправителя, и у получателя она от этой метаинформации постепенно отчищается. Называется «Протоколы и Интерфейсы». Протоколы между отправителем и получателем, интерфейсы между слоями абстракции хоста.

Раз. Два. Подобные изображения есть в знаменитой книге Олиферов и у Adam Woodbeck в его «Network Programming with Go». Классика.

вообще, не уверен, что есть производители про которых можно сказать что у них ни одной глючной модели нет.

Тут надо брать уже: не модели, а конкретного экземпляра. Скорее всего, тебе просто такой экземпляр попал, а не вся линейка такая.
У меня Некротик RB2011+ВиФи работал и работал. Перезагружался он только в случае обновлений и отключений электричества.

Пример того, как забить голову мусором.

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

Если человек называет модель OSI мусором, ругает Алгоримы или Матан - все с таким я «в разведку не пойду». Уже ходил, знаем чем это заканчивается.

По этому возвращаясь на несколько своих сообщений выше. Такой боец нам в отряде не нужен. И думаю не нам одним. Прекращайте с этим «невежеством».

Толерантным к невежеству я не буду.

Чисто практически понимание какой уровень OSI обрабатывает Kernel, а какой уровень пользовательский процесс - дает понимание зачем в NetBSD в ядре можно запускать Lua скрипты. Если на знать, что L2/L3 обрабатывает Kernel, то и не понятно зачем тащить Lua.

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

А модель OSI в этом никак не помогает и подобные утверждения только путают. У тебя какой-нибудь VPN может быть условно на L3 уровне, при этом соединение поддерживать два приложения в пространстве пользователя, а сам канал для этого L3 вообще внутри UDP пакетов. Можно поупрожняться и разложить по уровням модели OSI, но теория должна помогать понять происходящее на практике, а не человек натягивать на неё теорию. За пределами слоёв абстракции и инкапсуляции модель OSI этого не делает.

Ну, ядро никакие уровни модели OSI не обрабатывает, оно выполняет сетевые функции, которые можно на уровни этой модели как-нибудь разложить.

Как ни обрабатывает, когда обрабатывает?

Несколько сообщений назад мы же с вами рассматривали вопросы инкапсуляции сетевых данных по уровням. И разделение этих уровней на интерфейсы внутри хостов, и на протоколы между хостами.

UNIX Kernel предоставляет услуги процессам, одна из таких услуг UNIX socket - объект который работает на основе транспортного уровня модели OSI. Есть Raw Socket который позволяет работать на L3 - формировать последовательность байт IP пакета.

Тут надо брать уже: не модели, а конкретного экземпляра. Скорее всего, тебе просто такой экземпляр попал, а не вся линейка такая.

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

Свитч - работа на уровне mac-кадров, mac-адресов ethernet/wifi кадров.

Роутер - работа на уровне IP пакетов, IP-адресов.

Тащемта это всё что надо знать. Бугага.

Как ни обрабатывает, когда обрабатывает?

Как я и написал, у ядра есть функции, а ты натягиваешь на них модель OSI. Только эта модель никак не упрощает их понимание.

UNIX Kernel предоставляет услуги процессам, одна из таких услуг UNIX socket - объект который работает на основе транспортного уровня модели OSI.

Аналогично. Соотносить или нет это с каким-то уровнем модели OSI - выбор человека, а понять работу сокетов это не помогает.

Как я и написал, у ядра есть функции, а ты натягиваешь на них модель OSI.

Во первых не я натягивая, а они так спроектированы.

Вы упорно игнорируете сообщения и фрагменты сообщений. Уже началось хождение по кругу. Два раза круг про «Протоколы и Интерфейсы» я навернул, пару раз навернул круг про Unix-сокеты и разделение OSI уровней между Кernel/Userspace. Второй раз наворачиваю про реализации/использование/понимание новых протоколов HTTP/2, QUIC, HTTP/3 - которые требуют досконального владения моделью OSI. Повторяю одно и тоже по несколько раз.

Вы все твердите об усечённой картине мира кодера. Да вы правы, на лабораторной можно передать строчку «Hello, World!» от компьютера А, к компьютеру Б не понимая, что вы работаете на L4 уровне, через предоставленный Kernel интерфейс. И даже получить 5 за эту лабораторную. Также можно писать сайты не понимая, что такое IP адрес, просто описывая контроллеры в фреймворке, и также можно работать эникейщиком. Вы правы.

Но я говорю о системном программировании.

ARP таблицы чистятся, весьма часто. Дело в минутах.

Точняк. На нормальных железках по умолчанию всего 240 минут…

А MAC в CAM-таблице протухает за долгие 300 секунд…

Вы все твердите об усечённой картине мира кодера.

Вообще ничего не говорил про кодеров.

Два раза круг про «Протоколы и Интерфейсы» я навернул, пару раз навернул круг про Unix-сокеты и разделение OSI уровней между Кernel/Userspace.

И я уже пару раз написал, что использовать или нет модель OSI в своих рассуждениях - твоё желание. Уместность этого зависит от ситуации.

Да вы правы, на лабораторной можно передать строчку «Hello, World!» от компьютера А, к компьютеру Б не понимая, что вы работаете на L4 уровне, через предоставленный Kernel интерфейс.

Можно не только строчку написать, а прекрасно жить и разбираться в вопросе не прибегая к модели OSI.

Функции с моделью сопоставляет человек, когда по той или иной причине эту модель использовать удобно. Если ко мне вдруг придет разраб и скажет что-то типа «у нас проблема на L4 уровне», то я буду пялиться на него с недоумением. И буду сомневаться в этом заявлении, так как неуместное использование модели намекает на то, что он ничего сам не понимает в происходящем.

В то же время, я вполне могу сказать коллеге «у нас проблема на L2/L3 уровне». Не из-за моей любви к уровням OSI или её важности, так короче и он всё равно поймёт. Но не буду задумываться о вопросах «к какому уровню OSI относится ARP», так как в этой ситуации модель превращается из удобного упрощения и способа коммуникации в скрывающую суть сложность.

@Tyse_Ex если затеешь разбираться в теме… То как оно работает сейчас, в значительной мере обусловлено остаточной обратной совместимостью с тем, как оно работало 45 лет назад.

В этой эволюционной гонке победила простота и дешевизна.
«Более умные» TR, ATM и CDDI/FDDI вымерли.
Если при разглядывании возникает вопрос «почему всё так черезжопно», то это нормально. Ответ: «так получилось».

Избегай упрощаторов и абстракционистов: навяжут неправильную модель, потом не избавишься.

Раньше так и было, весь подъезд втыкали в один коммутатор и можно было смотреть домашний прон с компа соседа, который забыл поставить пароль на свою шару. Потом всё таки всех изолировали, вот для этого уже желательно роутер.

Так и счас тоже самое. Из твоего роутера кабель идёт в провайдёрский свитч-шлюз.

Надо же, дешевый вброс от тузика набрал 250 сообщений уже. И местные ыксперды всё еще выясняют «… разницу между коммутатором и маршрутизатором»

Потому что свич слушает ARP пакеты

Свич «слушает» все пакеты, а не только ARP.

и на основе их строит MAC таблицы.

Нет. Таблицы заполняются на основе юникастных адресов источника в любом пакете. Записи обновляются при прохождении любого пакета.
(Disclaimer: временно проигнорируем подробности типа «испорченный пакет», «коллизия» и прочее.)
В нормальных железках (последующее описание относится к нормальным железкам без отдельного указания на это) всё это живёт в CAM.
Размер CAM ограничен, поэтому записи протухают по таймауту при отсутствии пакетов отправленных с соответствующего MAC, а если места не хватает, то новые записи перезаписывают самые* старые.
Если какой-то MAC начнёт прыгать туда-сюда между активными портами, то тебе ещё и в лог про это напишут.

(* в код я не смотрел, может и не САМЫЕ старые)

А ARP - L3. Какого хрена тогда он L3?

А что не так c L3?
Если этот ARP улетел в ethernet, то в нём есть заголовок L2, которым и пользуется коммутатор.

начинается жизнь, рассылать пакет с данными всем, не секурно, а ARP и так широковещательный

Так-то, если отбросить излишнюю категоричность, ты недалеко от истины.
Жизнь МОЖЕТ начинаться с ARP в (хинт) сети со статически назначенными IP-адресами.
Но сеть не обязана использовать IPv4, коммутатор при этом продолжит работать без проблем.
Ты нетварь застал или «молодой ишшо»?

рассылать пакет с данными всем, не секурно

«Кормить в пути никто не обещал».
Натрави на свич генератор пакетов с рандомными src mac, зафлуди его и посмотри, что получится.
Поймёшь какие проблемы решает 802.1x.

UPD: хотел сказать port-security, но 802.1x тоже подойдёт.

вот для этого уже желательно роутер

PVLANs, если публичный IPv4, или VLANs в ином случае.

И я уже пару раз написал, что использовать или нет модель OSI в своих рассуждениях - твоё желание. Уместность этого зависит от ситуации.

Это не мое желание - это базовый инженерный стандарт, который вы пытаетесь представить как некую «академическую прихоть». Которую люди приплетают от нечего делать, и «засоряют мусором голову».

Почему это OSI «базовый инженерный стандарт»? Потому что разделение по модели OSI позволяет понять какой протокол будет работать в Kernel и обслуживаться драйверами (на худой конец программа должна работать под root), а какой протокол можно писать в Userspace. Это не прихоть, не понты, это базовая необходимость.

Вот в этом весь наш с вами конфликт. В остальном мне не о чем с вами спорить. То что есть моменты уместные или неуместные я с вами согласен.

Коммутаторы прямоугольные, а маршрутизаторы круглые. Даже детсадовец может отличить.

Честно говоря, сам офигел.
Но тут такой срач случился, что даже не ожидал такого.
А главное то, что не выясняют, а меряются длиной своего ШЙ на знание OSI и прочего. Прикольно же.

Жаль, что не про роутер vs маршрутизатор.

Было бы веселее.