Comments 63
Поле «адрес назначения Ethernet» заполняется единицами (ff:ff:ff:ff:ff:ff)Что значит, «единицами»?
Статья опробована на реальных студентах.… упрощал материал до тех пор, пока он ни стал понятен даже самым отпетым двоечникам.Модель OSI и место описываемых протоколов в ней именно поэтому сократили, осознанно?
Да. Модель OSI вызывает зевоту и полное отторжение у целевой аудитории этой статьи. Добавлю так же, что первый пункт этой статьи поняли и одобрили даже девушки младших курсов, которым данная тема была совершенно непонятна до этого.
Единицами — значит (ff:ff:ff:ff:ff:ff), т.е. (255, 255, ...), т.е. (1111111111111111b, 1111111111111111b, ,,,).
т/e вы просто говорите, что заполняем единицами и не говорите, что ff(16ричная система):255(10чная система)11111111(2ичная система)
я бы сказал, что это не понятно (=
я бы сказал, что это не понятно (=
Я понял, что автор оперирует двоичной системой в описании шестнадцатеричной адресации только после его объяснения. Я все таки думаю, что автор занижает уровень своей целевой аудитории :)
Нет, статья проверялась на живых студентах =)
И редактировалась много раз, до тех пор, пока не стало понятна даже самой далёкой от компьютеров блондинке. В прямом смысле. Просил вычитывать эту статью и блондинок тоже. И просил пересказа то, что они поняли.
И редактировалась много раз, до тех пор, пока не стало понятна даже самой далёкой от компьютеров блондинке. В прямом смысле. Просил вычитывать эту статью и блондинок тоже. И просил пересказа то, что они поняли.
так если вы упрощаете для самых самых
то я думаю нужно пояснить почему фраза заполняем единицами верна
как я писал выше 16->10->2
то я думаю нужно пояснить почему фраза заполняем единицами верна
как я писал выше 16->10->2
Исходя из практики, живые студенты(даже отличники) очень затрудняются при решении универсальной задачи на собеседовании для IT.
Мол есть два компьютера в сети. Дается схема сети, но допустим каждый за своим коммутатором которые связаны через интернет.
Суть задачи в следующем, необходимо описать полностью последовательно все процессы происходящие после того как пользователь1 на своем компьютере1 ввел в строку браузера белый айпи пользователя2 и нажал Enter. То есть не то какой пакет даже появится если просмотреть ваершарком, а даже те моменты в каком порядке берутся маки айпи порты и тп. Как зарождается пакет, как он идет и что где и на что заменяется.
Обычно когда человек понимает это, остальное становится легко. Лучше на таких задачах объяснять студентам.
Мол есть два компьютера в сети. Дается схема сети, но допустим каждый за своим коммутатором которые связаны через интернет.
Суть задачи в следующем, необходимо описать полностью последовательно все процессы происходящие после того как пользователь1 на своем компьютере1 ввел в строку браузера белый айпи пользователя2 и нажал Enter. То есть не то какой пакет даже появится если просмотреть ваершарком, а даже те моменты в каком порядке берутся маки айпи порты и тп. Как зарождается пакет, как он идет и что где и на что заменяется.
Обычно когда человек понимает это, остальное становится легко. Лучше на таких задачах объяснять студентам.
Задача: соединить два компа одним кабелем друг с другом.
Вы: у меня два компа в локалке смотрят в инет, можно поставить одинаковые мак-адреса.
https://toster.ru/q/386543
Вы: у меня два компа в локалке смотрят в инет, можно поставить одинаковые мак-адреса.
https://toster.ru/q/386543
Давно хотел спросить, у меня сеть из двух компьютеров с одним и тем же мак-адресом на каждом компьютере, он одинаковый, программой поставил, айпи одно (внешнее тоже одно, и по первому и по второму можно выходить в сеть), и всё работает. Витая пара между компьютерами, виндовс-10 и виндовс xp. Это не запрещено, конфликтов с оборудованием тоже нет.
Что не запрещено то разрешено.
Всё верно. Мы должны указывать mac адрес для того, чтобы коммутатор (или домашний модем-роутер с несколькими RJ45 под LAN), мог определить, какому комптютеру пересылать пакет. Если в сети будет несколько компьютеров с одинаковыми mac-адресами, по пакет будет послан тому, кто отозвался на ARP-запрос последним.
Если же для связи компьютеров, коммутатор не используется, а вместо этого компьютеры подключены на прямую, то для доставки сообщения mac не имеет значения. Верно, он может быть и одинаковым.
Если же для связи компьютеров, коммутатор не используется, а вместо этого компьютеры подключены на прямую, то для доставки сообщения mac не имеет значения. Верно, он может быть и одинаковым.
> Существуют сети классов A, B, C, D и E.
Классы, к счастью, давно похоронили.
Классы, к счастью, давно похоронили.
Зашёл с тем же вопросом. Они где-нибудь ещё используются? Вроде и знаю, что нет, а вроде недавно видел статью пятилетней давности про настройку Цисок — и там вроде как адреса задавались без масок, подразумевалось, что роутер по классу должен маску определить...
Не совсем так, точнее не все классы одинаковы.
Возьмем 2 студентов и дадим им задание развернуть небольшую корпоративную сеть, но одному выделим IP адреса из класса C, другому — из класса D.
У кого больше шансов на успех?
Возьмем 2 студентов и дадим им задание развернуть небольшую корпоративную сеть, но одному выделим IP адреса из класса C, другому — из класса D.
У кого больше шансов на успех?
Существуют сети размером с сети классов A, B, C, D. Причем, по большому счету, многие (неграмотно) используют выражение «сеть класса C» как синоним «сеть на 256 адресов», тогда как по факту это означает «сеть IPv4 адресов с маской /24 в диапазоне от 192.0.0.0 до 223.255.255.255».
Исходя из мини ТЗ, размещённого до фотографии в начале статьи, думаю, что было бы уместно в начале пояснить правила обжатия UTP.
Давно не видел сокращения UTP, мозг услужливо подменил системе визуального распознавания UTP на UDP: ткнул ссылку посмотреть как обжимается, UDP :) уже хотел попкорн готовить
Ну вот как раз UTP и вообще физика в объяснение про основы TCPIP никак не подпадает. Вот если бы тематика была «основа построения сетей» — тогда бы хоть как-то.
Про коммутаторы Cisco Catalyst 1900/2900XL/2950, думаю, не стоит писать, так как они уже давно в прошлом. В примерах лучше использовать более свежие модели.
На 2950 и более свежих моделях порт может быть в терминах вендора только в двух основных режимах: access или trunk. А далее могут быть вариации: инкапсуляция ISL (на новых коммутаторах её уже нет) или dot1q, статическое назначение режима порта или динамическое (DTP) и пр.
Режим Multi-VLAN умер вместе с коммутаторами 2900XL/3500XL.
Видимо, это утверждение из каких-то старых времён.
В современных сетях все используют транковые порты. И это как раз правильный подход. А чтобы обеспечить доступ к серверу из нескольких сетей используется маршрутизация.
802.1q добавляет в заголовок Ethernet лишь дополнительные поля (тегирует кадр) для передачи информации о VLAN и приоритете (802.1p). Причём заголовок 802.1q вставляется в середину текущего заголовка Ethernet. Слово «стек» тут не совсем уместно.
Если это статья для студентов, лучше использовать какой-то один термин.
На тему, что подразумевать под словом пакет, можно развести тот ещё холивар. И если заявлять строго, что пакет — это уровень IP, то говорить про «порты», «особые пакеты, по протоколу ISL или 802.1Q» и прочие радости в разрезе пакета не стоит.
каждый пор может иметь пять режимов работы: Static Access, Multi-VLAN, Dynamic Access, ISL Trunk и 802.1Q Trunk
На 2950 и более свежих моделях порт может быть в терминах вендора только в двух основных режимах: access или trunk. А далее могут быть вариации: инкапсуляция ISL (на новых коммутаторах её уже нет) или dot1q, статическое назначение режима порта или динамическое (DTP) и пр.
Режим Multi-VLAN умер вместе с коммутаторами 2900XL/3500XL.
Во первых, использование транк-порта вызывает некоторые сложности и создаёт лишнюю работу при конфигурировании оборудования.А во вторых, и в самых главных — предположим, что наши «как бы сети» бухгалтеров, экономистов и диспетчеров хотят иметь одну на троих базу данных...
Видимо, это утверждение из каких-то старых времён.
В современных сетях все используют транковые порты. И это как раз правильный подход. А чтобы обеспечить доступ к серверу из нескольких сетей используется маршрутизация.
А протокол 802.1Q вставляется в стек протоколов между Ethernet и тем протоколом, по которому были сформированные данные
802.1q добавляет в заголовок Ethernet лишь дополнительные поля (тегирует кадр) для передачи информации о VLAN и приоритете (802.1p). Причём заголовок 802.1q вставляется в середину текущего заголовка Ethernet. Слово «стек» тут не совсем уместно.
… и такой фрейм будер разослан… называется кадром...
Если это статья для студентов, лучше использовать какой-то один термин.
Данные, сформированные в соответствии с IP протоколом, называются пакетами.
На тему, что подразумевать под словом пакет, можно развести тот ещё холивар. И если заявлять строго, что пакет — это уровень IP, то говорить про «порты», «особые пакеты, по протоколу ISL или 802.1Q» и прочие радости в разрезе пакета не стоит.
Раз уж статья ориентирована в.т.ч и на студентов, то зануда-кун уточняет:
Коннектор называется 8P8C.
коннектор формата RJ-45
Коннектор называется 8P8C.
Может уже хватит жить пережитками прошлого? Во всей современной литературе (даже по подготовке к CCNA, У. Одом) уже давно пишут что разъем и коннектор RJ-45, даже не беру в расчет магазины, где эти коннекторы покупаются и где просто косо посмотрят, если сказать «дайте мне 50 восемьпэвосемьцэ».
Нравится держать в голове лишнюю информацию и поучать людей — Ваш выбор, но в 2017 выглядит спорно.
Нравится держать в голове лишнюю информацию и поучать людей — Ваш выбор, но в 2017 выглядит спорно.
Опытный автослесарь при помощи одного слова и оттенков интонации может назвать до 50 деталей автомобиля. Это отличает его от опытного инженера, который доподлинно знает точное название каждой детали.
Я никому не навязываю своего мнения. Но своим слушателям всегда говорю: «В повседневной жизни, на работе, в обиходе вы можете пользоваться той терминологией, которая вам по душе, главное, чтобы вас понимали. Но, отвечая мне на экзамене, будьте добры пользоваться соответствующей терминологией».
Кроме того, на моих обжимных клещах вполне чётко написано на соответствующих отверстиях: 4P, 6P, 8P. Может, они застряли в прошлом веке? :)
Я никому не навязываю своего мнения. Но своим слушателям всегда говорю: «В повседневной жизни, на работе, в обиходе вы можете пользоваться той терминологией, которая вам по душе, главное, чтобы вас понимали. Но, отвечая мне на экзамене, будьте добры пользоваться соответствующей терминологией».
Кроме того, на моих обжимных клещах вполне чётко написано на соответствующих отверстиях: 4P, 6P, 8P. Может, они застряли в прошлом веке? :)
Веселит другое!
Тот кто может прописать адрес в коммутаторе, странно объяснять что такое разъем RJ-45 :)))
Тот кто может прописать адрес в коммутаторе, странно объяснять что такое разъем RJ-45 :)))
Крайне низкое качество схемы подключения. Microsoft Visio в помощь автору.
Повсеместно натыкаюсь на подобное разбиение vlan, по отделам. И ни у кого не смог получить ответ зачем? Зачем и с какой целью бить vlan именно по отделам, от куда эта странная практика и кто плодить её адептов? Я ещё готов с натяжкой понять такую логику для файловых ресурсов уровня отдела с очень, просто безумно интенсивной работой с файлами, возможно изоляция такого ресурса на l3 уровне может оказаться дорогой, но это просто сверх специфические задачи. Сейчас уже есть рекомендации по l3 access уровню, например cisco 3850 в классикации cisco access уровень.
Имхо на данный момент vlan это инструмент принудительного соответствия l2 и l3 структур. Плюс при изоляции vlan по отделам, не решается задача изоляция клиентов друг от друга, не ищолированными должны быть только сервисы.
Я подозреваю, что такая практика взялась от самой циски и ее сртификации. Удобство в этом, несомненно, есть для средних организаций. В больших конторах уже давным-давно ушли от такой практики — не должен сетевого админа волновать переход девушки из бухгалтерии в ахо и наоборот.
3850 циска позиционирует как свич с функционалом вай-фай контроллера, естественно это access и l3. Что до стационарной офисной сети l3 на access нет, да и вредно это. Будете каждый раз думать над количеством и расширением сетей в отдельном закутке организации. Выделять доп сети каждый раз — запутаетесь с ospf. Для конторы больше 1k сотрудников вообще придется создавать под это отдельные штатки.
3850 циска позиционирует как свич с функционалом вай-фай контроллера, естественно это access и l3. Что до стационарной офисной сети l3 на access нет, да и вредно это. Будете каждый раз думать над количеством и расширением сетей в отдельном закутке организации. Выделять доп сети каждый раз — запутаетесь с ospf. Для конторы больше 1k сотрудников вообще придется создавать под это отдельные штатки.
Валентин, не совсем понял, как связана сегментация на VLANы по отделам и «не должен сетевого админа волновать переход девушки из бухгалтерии в ахо и наоборот».
Если сеть плоская, тут действительно адрес не меняется. Но вряд ли большая организация будет иметь плоскую сеть. Более того в больших сетях обычно используется DHCP и вопрос смены адреса не требует каких-то вмешательств со стороны администратора. Основные трудозатраты обычно представлены в виде бюрократических процедур (служебки и пр.), а не технические перенастройки оборудования.
L3 access в первую очередь не используется из-за дороговизны. Ставить на access коммутатор с поддержкой динамической маршрутизации (даже ограниченной EIGRP stub или OSPF Routed Access) могут себе позволить очень не многие. На практике в больших сетях на уровне доступа можно встретить ещё тот зоопарк из различных недорогих устройств (L2 или максимум с поддержкой static routing).
Что касается самого подхода к дизайну, то L3 access в классическом варианте рекомендуется в противовес сети с STP. Но если используется стекирование на уровне распределения, никто не против и L2, так как линков, заблокированных STP, уже не будет.
Если же смотреть на новомодный Campus Fabric, то L3 access является обязательным требованием, так как он будет транспортом для оверлейной сети. И как раз минимально нам в этом случае подойдёт 3850 (с поддержкой VXLAN, LISP).
В случае L3 access крайне желательно на этапе планирования правильно проработать адресацию в сети, особенно если сеть большая. Что в дальнейшем не было проблем с суммаризацией и выделением новых подсетей. Хотя это справедливо и для случая, когда L3 начинается на уровне распределения.
Что касается сегментации на VLAN'ы, действительно в курсе CCDP (возможно, и в других местах) приводилась формулировка, что VLAN'ы можно привязывать, например, к департаментам. Но основной посыл всегда был в том, что главное её делать (если не ошибаюсь, Cisco рекомендует иметь не больше 100 хостов в одном широковещательном сегменте). А как именно — это уже второй вопрос, зависящий от различных условий. Главное помнить, что сегментация сети позволяет изолировать домены отказа.
Микросегментацию можно делать protected-портами, private-VLAN'ами, или же использовать TrustSec (на уровне SG-ACL). Это может быть никак не связано с VLANами. Правда в случае trustsec на access придётся ставить всё те же 3650/3850, линейкой 2960 не отделаешься.
Если сеть плоская, тут действительно адрес не меняется. Но вряд ли большая организация будет иметь плоскую сеть. Более того в больших сетях обычно используется DHCP и вопрос смены адреса не требует каких-то вмешательств со стороны администратора. Основные трудозатраты обычно представлены в виде бюрократических процедур (служебки и пр.), а не технические перенастройки оборудования.
L3 access в первую очередь не используется из-за дороговизны. Ставить на access коммутатор с поддержкой динамической маршрутизации (даже ограниченной EIGRP stub или OSPF Routed Access) могут себе позволить очень не многие. На практике в больших сетях на уровне доступа можно встретить ещё тот зоопарк из различных недорогих устройств (L2 или максимум с поддержкой static routing).
Что касается самого подхода к дизайну, то L3 access в классическом варианте рекомендуется в противовес сети с STP. Но если используется стекирование на уровне распределения, никто не против и L2, так как линков, заблокированных STP, уже не будет.
Если же смотреть на новомодный Campus Fabric, то L3 access является обязательным требованием, так как он будет транспортом для оверлейной сети. И как раз минимально нам в этом случае подойдёт 3850 (с поддержкой VXLAN, LISP).
В случае L3 access крайне желательно на этапе планирования правильно проработать адресацию в сети, особенно если сеть большая. Что в дальнейшем не было проблем с суммаризацией и выделением новых подсетей. Хотя это справедливо и для случая, когда L3 начинается на уровне распределения.
Что касается сегментации на VLAN'ы, действительно в курсе CCDP (возможно, и в других местах) приводилась формулировка, что VLAN'ы можно привязывать, например, к департаментам. Но основной посыл всегда был в том, что главное её делать (если не ошибаюсь, Cisco рекомендует иметь не больше 100 хостов в одном широковещательном сегменте). А как именно — это уже второй вопрос, зависящий от различных условий. Главное помнить, что сегментация сети позволяет изолировать домены отказа.
Микросегментацию можно делать protected-портами, private-VLAN'ами, или же использовать TrustSec (на уровне SG-ACL). Это может быть никак не связано с VLANами. Правда в случае trustsec на access придётся ставить всё те же 3650/3850, линейкой 2960 не отделаешься.
Для начинающих нужно написать еще фразу: IP это протокол связи между устройствами, а TCP между программами.
UFO just landed and posted this here
>> Модель OSI вызывает зевоту и полное отторжение
если студентов сызмальства не приучать к правильной терминологии и структурированию (а модель OSI для передачи данных — это фундаментальные азы), то потом у них в головах получается наглядное пособие к произведению М.Ю.Лермонтова: «смешались в кучу кони, люди...»
начинается путаница и подмена понятий: интерфейсы, протоколы, кадры, пакеты, сообщения…
в Вашей статье есть фраза «протокол Ethernet», если бы мне на работе кто-то такое сказал, я бы его отправил читать книжки или гуглить
на мой взгляд, это то же самое, что при обучению английскому плевать на грамматику, главное словарный запас. Понимать Вас будут, но скорее всего не так, как Вы это задумали
извините за возможно резковатый тон, но оправдывать сознательное упрощение и подмену понятий ленью студентов, мне кажется, не стоит
если студентов сызмальства не приучать к правильной терминологии и структурированию (а модель OSI для передачи данных — это фундаментальные азы), то потом у них в головах получается наглядное пособие к произведению М.Ю.Лермонтова: «смешались в кучу кони, люди...»
начинается путаница и подмена понятий: интерфейсы, протоколы, кадры, пакеты, сообщения…
в Вашей статье есть фраза «протокол Ethernet», если бы мне на работе кто-то такое сказал, я бы его отправил читать книжки или гуглить
на мой взгляд, это то же самое, что при обучению английскому плевать на грамматику, главное словарный запас. Понимать Вас будут, но скорее всего не так, как Вы это задумали
извините за возможно резковатый тон, но оправдывать сознательное упрощение и подмену понятий ленью студентов, мне кажется, не стоит
в Вашей статье есть фраза «протокол Ethernet», если бы мне на работе кто-то такое сказал, я бы его отправил читать книжки или гуглить
А что вас смущает?
Protocol suite: Ethernet
модель OSI — это бюрократические фантазии, как можно было бы строить сети, если забить на существующую практику :-)
И, главное, в дальнейшем у вас нет никакого желания становиться профессионалом в этой области. Тогда эта статья для вас.
Электрик в женском общежитии.
Честно говоря — какая-то каша получилась. А всё потому, что Вы ставите перед собой внутренне противоречивую задачу:
"Наймите профессионала!"
Из основных недостатков статьи я бы выделил следующи:
Вам поставили задачу: в быстрые сроки построить информационную сеть на небольшом предприятии.Так вот, в этой ситуации вместо всей этой статьи надо написать всего одну фразу:
И, главное, в дальнейшем у вас нет никакого желания становиться профессионалом в этой области
"Наймите профессионала!"
Из основных недостатков статьи я бы выделил следующи:
- Не сказано про модель OSI. Да, она довольно кривая (например, TCP точно относится к четвёртому уровню — а UPD должен быть на третьем, там же, где и IP) — но ничего лучше у нас нет.
- Вы рассказываете про Ethernet и IP, но ничего не говорите про альтернативы типа TokenRing и IPX. Это значит, что студентам всё равно будет непонятно, зачем сделано именно так, а не иначе; и как вообще бывает иначе. Это не говоря уж о том, что не рассказано про соединения «точка-точка» типа PPP или SLIP, где нет MAC-адресов.
- Не рассказано про QoS и DHCP.
- Не рассказано об IP-маршрутизации, т.е. о назначении IP-адресов. А если Вы пишете про VLAN — то IP-маршрутизация необходима.
потому что модель OSI не имеет никакого отношения к сложившейся практике построения сетей
p.s. ладно, дёрнули оттуда пару-тройку идей, в частности коммутаторы вместо хабов, но это довольно косвенное влияние
p.s. ладно, дёрнули оттуда пару-тройку идей, в частности коммутаторы вместо хабов, но это довольно косвенное влияние
Модель OSI была попыткой осмысления и обобщения существовавших на тот момент технологий. Понятно, что при построении модели многое было отброшено ради упрощения — но сама модель строилась на реальности.
Далее те люди, которые проектировали сети, обычно были знакомы с этой моделью — и строили новые сети под эту модель.
В модели OSI почти всё хорошо. Главное, что в ней плохо — это отсутствие описания взаимодействия, когда не требуется подтверждение доставки данных, а взаимодействие клиента и сервера (ну или кто там общается по сети) успешно происходит в условиях неполной доставки данных. (Когда я преподавал в МФТИ, то разбирал н алекциях, в каких случаях это возможно и даже нужно.)
Далее те люди, которые проектировали сети, обычно были знакомы с этой моделью — и строили новые сети под эту модель.
В модели OSI почти всё хорошо. Главное, что в ней плохо — это отсутствие описания взаимодействия, когда не требуется подтверждение доставки данных, а взаимодействие клиента и сервера (ну или кто там общается по сети) успешно происходит в условиях неполной доставки данных. (Когда я преподавал в МФТИ, то разбирал н алекциях, в каких случаях это возможно и даже нужно.)
Почитайте сам стандарт OSI/ISO. Взять хотя бы вступление:
Это не обобщение, а ПЕРЕосмысление существовавших на тот момент технологий. Это довольно проработанные рекомендации по разработке. Естественно в рекомендации не включены явно костыльные (или не особо явно), неудачные, плохо себя зарекомендовавшие на практике, решения.
В основе идей OSI/ISO лежит коммутация каналов, в основе TCP/IP — маршрутизация пакетов. Эти концепции противоречат друг другу.
И если отойти от конкретного содержания, то ваше утверждение выглядит примерно так:
Европейский институт электротехники описал своими словами сетевые наработки американских военных, зарегистрировал как свой стандарт и теперь продаёт это за деньги :-)
This reference model provides a common basis for the coordination of standards development for the purpose of systems interconnection, while allowing existing standards to be placed into perspective within the overall reference model.
Это не обобщение, а ПЕРЕосмысление существовавших на тот момент технологий. Это довольно проработанные рекомендации по разработке. Естественно в рекомендации не включены явно костыльные (или не особо явно), неудачные, плохо себя зарекомендовавшие на практике, решения.
В основе идей OSI/ISO лежит коммутация каналов, в основе TCP/IP — маршрутизация пакетов. Эти концепции противоречат друг другу.
И если отойти от конкретного содержания, то ваше утверждение выглядит примерно так:
Европейский институт электротехники описал своими словами сетевые наработки американских военных, зарегистрировал как свой стандарт и теперь продаёт это за деньги :-)
Это не обобщение, а ПЕРЕосмысление существовавших на тот момент технологий.Обобщение существующих технологий — это первый этап переосмысления. Ибо чтобы переосмыслить что-то существующее — надо его знать, причём не просто знать первичный сырой материал, а провести анализ и выделить общие закономерности.
Это довольно проработанные рекомендации по разработке.А выработка рекомендация по разработке — это вторая часть переосмысления, когда на основе анализа были выведены суждения о том, что в существующих решениях хорошо, и это надо применять; а что плохо, и этого надо избегать.
Естественно в рекомендации не включены явно костыльные (или не особо явно), неудачные, плохо себя зарекомендовавшие на практике, решения.Т.е. UDP — это неудачное решение???
В основе идей OSI/ISO лежит коммутация каналов, в основе TCP/IP — маршрутизация пакетов. Эти концепции противоречат друг другу.Коммутация каналов не нуждается в пакетировании. Т.е. датаграммный уровень модели OSI противоречит концепции коммутация каналов.
И если отойти от конкретного содержания, то ваше утверждение выглядит примерно так:Видите ли, тут надо заменить «американских военных» на «американских военных и многих других разработчиков». Причем американские военные тут явно были не на первом месте.
Европейский институт электротехники описал своими словами сетевые наработки американских военных, зарегистрировал как свой стандарт и теперь продаёт это за деньги :-)
А что Вы подразумеваете под «UPD»? И почему оно должно быть на третьем уровне OSI?
Разумеется, это была очепятка: я имел в виду «UDP».
3rd lvl OSI — это уровень датаграмм (в IP и в IPX — это называется «пакет»).
4th lvl OSI — это уровень гарантированной доставки данных, уровень сессионных соединений.
Очевидно, что UDP — это отдельные датаграммы/пакеты, никак не выстроенные в сессию.
Если мы говорим про реализацию NFS over UDP (есть две реализации NFS — «over UDP» и «over TCP»; меня тут интересует только первая) или NetBIOS over IPX — то там работа по организации сессии вынесена в протокол, работающий поверх UDP/IPX. Получается, что четвёртый и пятый уровни модели OSI совмещены в одном протоколе.
Что же касается протокола типа DNS — то там вообще нет никакой сессии: при отсутствии ответа клиент тупо повторяет запрос так, как будто первого запроса и не было. То же самое — в Ping (правда, он не имеет отношения к UDP, а работает по ICMP) и в ARP (этот вообще на третьем уровне OSI).
В DHCP есть убогое подобие сессии. И оно вынесено в протокол, работающий поверх UDP.
Т.е. по факту мы имеем несоответствие реальных протоколов модели OSI.
Кстати, есть особый протокол NBT — NetBIOS over TCP. Он отличается от обычного NetBIOS (который over IPX или NetBEUI) тем, что возлагает доставку данных на TCP, и за это заслуживает отельного имени.
3rd lvl OSI — это уровень датаграмм (в IP и в IPX — это называется «пакет»).
4th lvl OSI — это уровень гарантированной доставки данных, уровень сессионных соединений.
Очевидно, что UDP — это отдельные датаграммы/пакеты, никак не выстроенные в сессию.
Если мы говорим про реализацию NFS over UDP (есть две реализации NFS — «over UDP» и «over TCP»; меня тут интересует только первая) или NetBIOS over IPX — то там работа по организации сессии вынесена в протокол, работающий поверх UDP/IPX. Получается, что четвёртый и пятый уровни модели OSI совмещены в одном протоколе.
Что же касается протокола типа DNS — то там вообще нет никакой сессии: при отсутствии ответа клиент тупо повторяет запрос так, как будто первого запроса и не было. То же самое — в Ping (правда, он не имеет отношения к UDP, а работает по ICMP) и в ARP (этот вообще на третьем уровне OSI).
В DHCP есть убогое подобие сессии. И оно вынесено в протокол, работающий поверх UDP.
Т.е. по факту мы имеем несоответствие реальных протоколов модели OSI.
Кстати, есть особый протокол NBT — NetBIOS over TCP. Он отличается от обычного NetBIOS (который over IPX или NetBEUI) тем, что возлагает доставку данных на TCP, и за это заслуживает отельного имени.
То что реальные протоколы не соответствуют модели OSI и TCP/IP общее известный факт. Обе модели не идеальны. Из TCP/IP взяты стеки протоколов. Модель же OSI используется в основном в образовательных целях для описания работы сети.
Вы правильно заметили, не все протоколы укладываются в модель OSI. Но это и понятно, так как OSI сугубо образовательная вещь. По многим из них можно долго дискутировать, куда отнести. Например, для таких протоколов, как ARP, MPLS даже придуманы новые уровни — 2.5, так как их нельзя однозначно определить ни к канальному, ни к сетевому.
Если мы говорим про UDP, то он с натяжкой но всё-таки укладывается в описание транспортного уровня OSI. Именно поэтому, если мы посмотрим в книги Таненбаума, Олифера, различные вендорные материалы, данный протокол мы увидим именно на транспортном уровне. UDP обеспечивает связь между приложениями(программами) на хостах. Он является прослойкой между сетевым уровнем, отвечающим за маршрутизацию пакетов в сети, и приложением/сеансовым уровнем.
Вы правильно заметили, не все протоколы укладываются в модель OSI. Но это и понятно, так как OSI сугубо образовательная вещь. По многим из них можно долго дискутировать, куда отнести. Например, для таких протоколов, как ARP, MPLS даже придуманы новые уровни — 2.5, так как их нельзя однозначно определить ни к канальному, ни к сетевому.
Если мы говорим про UDP, то он с натяжкой но всё-таки укладывается в описание транспортного уровня OSI. Именно поэтому, если мы посмотрим в книги Таненбаума, Олифера, различные вендорные материалы, данный протокол мы увидим именно на транспортном уровне. UDP обеспечивает связь между приложениями(программами) на хостах. Он является прослойкой между сетевым уровнем, отвечающим за маршрутизацию пакетов в сети, и приложением/сеансовым уровнем.
Это сейчас модель OSI используется в образовательных целях. А вот когда её создавали — предполагалось, что её будут использовать как «скелет», на который будет навешена реализация. Но так получилось, что попытки строить сети по схеме OSI давали дорогой, ненадёжный, медленный и вообще неэффективный результат. Ну и пришлось оставить модель OSI в качестве исторического казуса и в виде некой схемы, используемой в образовании — причём при переносе её в образование модель исказили, натягивая на реальность.
Я упорно не понимаю, каким образом ARP впихивают в «уровень 2.5». Чтобы быть там, ARP должен работать поверх уровня 2 (это выполняется), а поверх ARP должен работать хоть один протокол уровня 3. Однако, в ARP не инкапсулируется ни один из протоколов 3-го уровня модели OSI.
ARP для IP играет примерно такую же роль, как DNS — для WWW/FTP/Telnet/etc: При отсутствии нужной информации в кэше делается запрос, информация вносится в кэш, а дальше ARP и DNS не нужны. Более того: информацию можно внести в кэш, минуя эти протоколы (статические ARP-записи или файл hosts соответственно).
UDP никак не может попасть на 4-й уровень OSI — ибо там требуется обеспечивать надёжную доставку данных.
Задача UDP — это не обеспечение связи/сеанса. UDP обеспечивает исключительно разделение приложений по портам — т.е. он обладает той же функциональностью, что и IP (возможны пропажа и дублирование пакетов, возможно изменение порядка пакетов и возможны проблемы с MTU), добавляя к этому только «порт» (тот, который для DNS = 53).
Я упорно не понимаю, каким образом ARP впихивают в «уровень 2.5». Чтобы быть там, ARP должен работать поверх уровня 2 (это выполняется), а поверх ARP должен работать хоть один протокол уровня 3. Однако, в ARP не инкапсулируется ни один из протоколов 3-го уровня модели OSI.
ARP для IP играет примерно такую же роль, как DNS — для WWW/FTP/Telnet/etc: При отсутствии нужной информации в кэше делается запрос, информация вносится в кэш, а дальше ARP и DNS не нужны. Более того: информацию можно внести в кэш, минуя эти протоколы (статические ARP-записи или файл hosts соответственно).
UDP никак не может попасть на 4-й уровень OSI — ибо там требуется обеспечивать надёжную доставку данных.
Задача UDP — это не обеспечение связи/сеанса. UDP обеспечивает исключительно разделение приложений по портам — т.е. он обладает той же функциональностью, что и IP (возможны пропажа и дублирование пакетов, возможно изменение порядка пакетов и возможны проблемы с MTU), добавляя к этому только «порт» (тот, который для DNS = 53).
ARP явно протокол не канального уровня. И уж точно не сетевого, так как не обеспечивает передачу данных между сетями. Вот и получается подобие уровня 2.5.
На четвёртом уровне OSI слово «надёжность» может варьироваться в очень больших пределах. Во всяком случае, так обычно пишут. Может быть, все дружно врут. Лично сам стандарт не читал (ISO просят по-дружески 198 швейцарских франков в качестве дара на развитие новых стандартов, пока думаю :)).
Но допустим, что UDP отнесли к сетевому уровню. Разве он позволит нам определить кратчайший маршрут и дальше обеспечить передачу данных между сетями? Нет. Получается, что на сетевом уровне ему тоже не место. Бедный UDP.
На четвёртом уровне OSI слово «надёжность» может варьироваться в очень больших пределах. Во всяком случае, так обычно пишут. Может быть, все дружно врут. Лично сам стандарт не читал (ISO просят по-дружески 198 швейцарских франков в качестве дара на развитие новых стандартов, пока думаю :)).
Но допустим, что UDP отнесли к сетевому уровню. Разве он позволит нам определить кратчайший маршрут и дальше обеспечить передачу данных между сетями? Нет. Получается, что на сетевом уровне ему тоже не место. Бедный UDP.
ARP явно протокол не канального уровня. И уж точно не сетевого, так как не обеспечивает передачу данных между сетями.С первой фразой я полностью согласен.
А вот аргумент «не обеспечивает передачу данных между сетями» я отказываюсь принять, ибо есть протоколы типа NetBEUI, которые не имеют задачи объединять сети, но при этом прекрасно работают именно на третьем уровне.
На четвёртом уровне OSI слово «надёжность» может варьироваться в очень больших пределах.Надёжность UDP — точно такая же, как у IP. Как-то нелогично говорить о надёжности четвёртого уровня. если всё, что для этого сделано — сделано ещё на третьем уровне.
Лично сам стандарт не читал (ISO просят по-дружески 198 швейцарских франков в качестве дара на развитие новых стандартов, пока думаю :)).Неужто никто из тех, кто получил доступ к этому стандарту, не выложил его в открытый доступ?
Разве {UDP} позволит нам определить кратчайший маршрут и дальше обеспечить передачу данных между сетями?Простите, а разве обязательно определять кратчайший маршрут? Сеть м.б. вполне работоспособной даже если данные (пакеты) доставляются не кратчайшим маршрутом.
UDP — это как бы дополнение к IP. Т.е. эти два протокола вместе обеспечивают ту функциональность, которую разработчики модели OSI поместили на третий уровень.
Вот тут на третий уровень засунули протоколы динамического роутинга. Это феерично! Они же работают поверх TCP или UDP!!!
Транспортный уровень OSI не обязательно должен быть надёжным. Но вот получить данные от верхнего уровня, упаковать их и обеспечить передачу в отрыве от сетевого уровня должен. TCP и UDP со 100% точностью не укладываются в определение транспортного уровня модели OSI, так как они разрабатывались в отрыве от неё. Но общепринято эти оба протокола относить именно к нему.
Протоколы динамической маршрутизации относят к протоколам, обеспечивающим работу других уровней, например, сетевого. Обычно их не пытаются уложить в какой-то уровень модели OSI. Даже в приведенной ссылке не присутствует такое заявление. Максимум указывают поверх какого уровня они работают (например: IS-IS — поверх канального, OSPF — сетевого, RIP или BGP — транспортного).
Протоколы динамической маршрутизации относят к протоколам, обеспечивающим работу других уровней, например, сетевого. Обычно их не пытаются уложить в какой-то уровень модели OSI. Даже в приведенной ссылке не присутствует такое заявление. Максимум указывают поверх какого уровня они работают (например: IS-IS — поверх канального, OSPF — сетевого, RIP или BGP — транспортного).
Но вот получить данные от верхнего уровня, упаковать их и обеспечить передачу в отрыве от сетевого уровня должен.Хм-м-м… А разве TCP и UDP способны работать поверх другого протокола (типа IPX или NetBEUI)? Мне всегда казалось, что TCP и UDP разработаны в жёсткой привязке к IP; в частности, при переходе к IPv6 пришлось переделывать и TCP.
Но общепринято эти оба протокола {TCP и UDP} относить именно к нему.Ну, с этим я как раз не спорю. Просто у меня формулировка другая: «Общепринятое представление о модели OSI и о распределении протоколов по её уровням — это достаточно кривое натягивание некой „идеальной“ (в представлении теоретиков о том, как оно должно быть) схемы на реальность. А реальность сильно расходится с представлениями создателей модели OSI.»
Протоколы динамической маршрутизации относят к протоколам, обеспечивающим работу других уровней, например, сетевого.А вот и нет!!!
Тут Вы путаете «службу динамического роутинга» (т.е. совокупность программ, вносящих поправки в таблицы роутинга) и «протоколы динамического роутинга» (т.е. формат пакетов, переносяхих информацию между разными компонентами службы).
Иерархия протоколов — это строго инкапсeляция: HTML-страница запихивается в HTTP-конверт (т.е. к HTML-странице дописываются заголовки), HTTP-конверт с содержимым запихивается в TCP-сессию, TCP-сессия распихивается по IP-пакетам, каждый IP-пакет запихивается в Ethernet-кадр, Ethernet-кадр кодируется в электрический сигнал Manchester-II.
А протоколы динамического роутинга могут достаточно долго (прядка нескольктих минут) «молчать» — при том, что IP-трафик может идти хоть с гигабитной скоростью. Или программа динамического роутинга может вообще отключиться, и всё будет продолжать работать до тех пор, пока не потребуется её вмешательство, а это обычно вызывается изменением топологии сети. Инкапсуляции тут и близко нет.
Аналогично нет инкапсуляции IP в ARP, нет инкапсуляции HTTP/FTP/Telnet/etc в DNS.
PS: Если Вы хотите от меня оперативных ответов — помогите мне вернуть статус «захабреный». А то задержка в один час между ответами сильно мешает.
Вложность протоколов (в данном случае TCP поверх IP поверх Ethernet) называется стеком протоколов.
Вы полагаете, люди, которые ввели в оборот «стек» просто не знали слов «вложенность», «инкапсуляция» и т.п.? Стек в данном случае это набор абстрактных уровней, которые надо добавлять/интерпретировать последовательно (по принципу LIFO) в процессе передачи/обработки данных. Протоколам не обязательно быть вложенными, как например упомянутый вами VLAN — отдельный (под)уровень в стеке, но реализован как тэг/поле данных.
Несколько замечаний
т.е. в сети могут быть только компьютеры? А как же другие сетевые устройства?
Нет не всем. Вы что-нибудь про «штормы» слышали и как их избегают?
сможет, если на 3м уровне не будет никаких запретов. Ведь VLAN-ы это всего лишь L2 (привет OSI)
На самом деле там конечно все сложнее, ибо есть понятия Master browser и т.п. вещи, но объяснять основы сетей на таком примере, это вообще за гранью добра и зла, имхо. А потом у пользователей начинается паническая атака, когда они не видят сетевого окружения ;)
ну очень сильно зависит от программы и используемого протокола. Если у вас используется веб сервер, тот же nginx, с чего он вдруг будет генерировать широковещательные сообщения?
особо ленивые администраторы настраивают 802.1X (с dynamic vlan assignment) и ничего не меняют
вы, например, про ICMP что нибудь слышали?
а потом на собеседовании ты задаешь вопросы, а человек начинает плавать. Самый простой вопрос — «Два компьютера не видят друг друга. Как найти причину неисправности» и тут без знания модели OSI (да да, те самые физические и канальные уровни) начинается плаванье
я дико извиняюсь, возможно такой уровень подачи подойдет для каких-нибудь бухгалтеров, но в специализированном институте с ИТ уклоном, это не приемлемо. И уж тем более нанимать человека для построения сети предприятия недопустимо, имхо
В протоколе Ethernet находятся номер сетевого адаптера отправителя (MAC-адрес)может все таки идентификатор ну или адрес? Ибо звучит как то совсем дико. "A media access control address (MAC address) of a computer is a unique identifier assigned to network interfaces for communications at the data link layer of a network segment."
Существуют сети классов A, B, C, D и E. Они различаются по количеству компьютеров и по количеству возможных сетей/подсетей в них.
т.е. в сети могут быть только компьютеры? А как же другие сетевые устройства?
К примеру, компьютер с ip адресом 192.168.30.110 хочет отправить информацию другому компьютеру с номером 3, находящемуся в той же логической подсети. Это значит, что ip адрес получателя будет такой: 192.168.30.3что это еще за номер 3?!
Коммутатор, получив такой широковещательный фрейм, отправляет его всем компьютерам сети, как бы обращаясь ко всем с вопросом: «если Вы владелец этого ip адреса (ip адреса назначения), пожалуйста сообщите мне Ваш mac адрес».Почему нет упоминанию про таблицу mac адресов у самого коммутатора?
Такой адрес называется широковещательным, и такой фрейм будер разослан всем «интерфейсам на кабеле», т.е. всем компьютерам, подключённым к коммутатору.
Нет не всем. Вы что-нибудь про «штормы» слышали и как их избегают?
VLAN-ы помогают решить одно из требований к безопасности сети, а именно разграничение сетевых ресурсов. Так, студен из одной аудитории не сможет проникнуть на компьютеры другой аудитории или компьютер ректора, т.к. они находятся в фактически разных сетях.
сможет, если на 3м уровне не будет никаких запретов. Ведь VLAN-ы это всего лишь L2 (привет OSI)
Например, когда вы заходите в «Сетевое окружение» (ОС Windows), ваш компьютер посылает ещё несколько ШС со специальной информацией, сформированной по протоколу NetBios, что бы просканировать сеть на наличие компьютеров, находящихся в той же рабочей группе. После чего ОС рисует найденные компьютеры в окне «Сетевое окружение» и вы их видите.
На самом деле там конечно все сложнее, ибо есть понятия Master browser и т.п. вещи, но объяснять основы сетей на таком примере, это вообще за гранью добра и зла, имхо. А потом у пользователей начинается паническая атака, когда они не видят сетевого окружения ;)
Так же стоит заметить, что во время процесса сканирования той или иной программой, ваш компьютер отсылает ни одно широковещательное сообщение, а несколько, к примеру для того, что бы установить с удалёнными компьютерами виртуальные сессии или ещё для каких либо системных нужд, вызванных проблемами программной реализации этого приложения.
ну очень сильно зависит от программы и используемого протокола. Если у вас используется веб сервер, тот же nginx, с чего он вдруг будет генерировать широковещательные сообщения?
И для того, что бы она со своего нового места могла по прежнему пересылать файлы своим коллегам, администратор должен удалить из второго списка число 20 и добавить число 23.
особо ленивые администраторы настраивают 802.1X (с dynamic vlan assignment) и ничего не меняют
Для передачи информации другому компьютеру, в отправляемом пакете информации надо указать три идентификационных значения — mac адрес, ip адрес и порт. Условно говоря, порт — это номер, который, выдаёт операционная система каждой программе, которая хочет отослать данные в сеть.
вы, например, про ICMP что нибудь слышали?
Модель OSI вызывает зевоту и полное отторжение у целевой аудитории этой статьи
а потом на собеседовании ты задаешь вопросы, а человек начинает плавать. Самый простой вопрос — «Два компьютера не видят друг друга. Как найти причину неисправности» и тут без знания модели OSI (да да, те самые физические и канальные уровни) начинается плаванье
Статья опробована на реальных студентах. Я давал им прочитать часть статьи и оценить на понятность. Затем редактировал и упрощал материал до тех пор, пока он ни стал понятен даже самым отпетым двоечникам.
я дико извиняюсь, возможно такой уровень подачи подойдет для каких-нибудь бухгалтеров, но в специализированном институте с ИТ уклоном, это не приемлемо. И уж тем более нанимать человека для построения сети предприятия недопустимо, имхо
UFO just landed and posted this here
Sign up to leave a comment.
Основы TCP/IP для будущих дилетантов