Навчання · 1 травня 2015, 11:01 1877

Пупена Александр

Прошу покритикувати лекції по Ethernet та TCP/IP

Доброго дня.
Започаткував відкритий курс (+відео) по «Промисловим мережам та інтеграційним технологіям» в області промислової автоматизації. Нещодвано дійшов до Ethernet та TCP/IP, так як він теж вже зайняв домінуюче місце і в наших АСУТП-шних системах. Щодо наповнення курсу — воно сформовано згідно специфіки області компетенцій спеціаліста з промислової автоматизації.

Прошу спеціалістів з мережних технологій зробити критику, так як від «своїх» такої не почув. Можна звичайно зробити критику щодо мови викладання (у великій кількості суржик), але мене більш цікавить критика щодо змісту і форми.
Дякую.
Посилання на матеріали asu.in.ua/...iewtopic.php?f=194&t=1052 Розділ 4.

Теми: Ethernet, tcp ip, навчання

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Пупена Александр 11.05.2015 18:41

Коротко, підсумки того, що рекомендували («ок» — буду працювати над виправленнями, «ні» — не буду)
-обжим (кольори, кросовість, диференціація між типами) == ок
-10,100,1000 об’єднати в одному контексті == ок
-вказати про випадкову генерацію МАС == ок
-навести приклади на Linux == ні, курс для АСУТП + з Лінукс не працюю
-комутатор не обов’язково мікропроцесорний == ок
-комутатор не обов’язково міст (згідно 802.1D) == ок
-10BaseT не особливо виділяти == ок
-не вказані мультикасти та резервний блок == ні, вони вказані в таблиці діапазонів класових адрес
-добавити в приватні 169.254/16 від Майкрософта == ок
-OSI викинути == ні, обговорення чому приводив
-перевантаженість слайдів == ок, але бажано щоб слайди читалися без відео (повторення матеріалу)
-наводити англомовні терміни == ок
-виправити «в структурі IP адреси не визначено де номер підмережі а де вузла...» на «однозначно не визначено» == ок
-інші зауваження стосується того, що планується давати: VLAN, TAP(???), STP, RSTP

Що забув?

Відповісти

Підтримати

Пупена Александр 11.05.2015 16:39

продовження dou.ua/forums/topic/13600

Відповісти

Підтримати

Пупена Александр 04.05.2015 10:02

Дуже радий, що спільнота підключилася до обговорення матеріалу. Через два тижні планується дати другу частину IP, потім піде TCP та UDP, потім протоколи верхніх рвнів, після цього планується дати другу частину Ethernet, а потім промислове виконання та RTE (Real Time Ethernet). Буду намагатися викласти презентації хоча б за 2 дні до лекцій вже з урахуванням рекомендацій до них (наприклад щодо IPv6). Старі презентації постараюся теж виправити, принаймні систематизую усі зауваження і скажу про них слухачам.
Хочу ще раз наголосити, що лекції читаються в контексті «промислових мереж» для автоматчиків, тому перелік та глибина тем вибирається з урахуванням цього.
Ще раз дякую за конструктивну критику, навіть забарвлену емоційними фразами (не перший раз ;-) )

Відповісти

Підтримати

Roman Brunets Программист в контрактор 04.05.2015 08:40

По слайду 9.

Логика обжима витой пары:
1. Порядок пар. Это дефакто стандарт для всех кабелей (в том числе на 20, 50 и т.д. пар) первые четыре пары всегда таких цветов — 1я пара синий, 2я оранжевый, 3я зеленый и 4я коричневый.
2. Порядок обжима. Первая пара (синий) это телефон. Поэтому он в центре — в RJ-45 без проблем втыкается RJ-11 и ваш телефон прекрасно работает. Потом по порядку слева направо исключая два центральных — 2я (оранжевый) пара Tx, 3я пара Rx и последняя PoE.

Вот тот бардак на слайде, который вы представили, говорит только о том, что вы не понимаете того, что преподаете студентам. Не нужно перекидывать в 10BaseT телефон на PoE — там меняются местами только 2я и 3я пары. На рисунке показан кросс от 1000BaseT, но там он уже не имеет смысла, насколько я помню.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 09:08

первые четыре пары всегда таких цветов — 1я пара синий, 2я оранжевый, 3я зеленый и 4я коричневый.

Исторически, вторая пара как раз 3-6 для 8P8C (1-4 для 4P4C), так что зелёная.

Не нужно перекидывать в 10BaseT телефон на PoE — там меняются местами только 2я и 3я пары.

Согласен.

На рисунке показан кросс от 1000BaseT, но там он уже не имеет смысла, насколько я помню.

Скорее от 1000baseTX (их часто путают, TX использовал 2 пары с выделенными направлениями, но на высокой частоте; T использует 4 пары, стороны делятся по частоте), но даже для него не нужно кроссировать все 4.

Відповісти

Підтримати

Roman Brunets Программист в контрактор 04.05.2015 17:06

Исторически, вторая пара как раз 3-6 для 8P8C (1-4 для 4P4C), так что зелёная.

При чем здесь коннекторы? Речь шла именно о кабелях. Вроде такого:
ru.wikipedia.org/...pair_color_code_chart.svg

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 22:14

Да, теперь понятно. Фигня в том, что описанному Вами порядку соответствует 568A. Там вся логика соответствует этим цветам, если правильно нумеровать пары (1 — центральная => синяя, 2 — вокруг центральной => оранжевая, 3,4 — дополнительные по бокам => зелёная и коричневая).
А у нас принят за основной по какому-то странному недоразумению 568B, который получается из 568A кроссом линий 1<->3 и 2<->6 (то есть 2й пары с 3й). У него эта цветовая логика, соответственно, сбита.

Відповісти

Підтримати

Пупена Александр 04.05.2015 09:36

Я б не был так кактегоричен. Вы нашли ошибку, за это спасибо, но вот для этого я и запостил, чтобы общественность поправила, а не для того чтобы обвиняла в некомпетентности. Или Вы считаете что такого материала валом в Интернете и не нужно его делать? Или может Вы пойдёте в преподаватели и начнете читать о промышленных сетях? Вы многое понимаете в пром. сетях? Может Вы сможете мне объяснить как работает Profinet, Ethernet/IP и иже с ними (это только те, которые базируются на Ethernet) и все сервисы на них? Это ж Вам не нужно, правда ведь, ведь это не Ваше? Если же я ошибаюсь, я с удуовльствием Вас выслушаю и буду давать Ваши лекции свои студентам. Пока такого материала нет, приходится делать всё самому.
По поводу разключения, занес в копилку критики, буду дополнительно разбираться.

Відповісти

Підтримати

Roman Brunets Программист в контрактор 04.05.2015 17:23

Вы конечно же правы. Моих искренних извинений будет достаточно?

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

Еще раз мои извинения, я был груб и не прав.

Відповісти

Підтримати

Пупена Александр

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 09:42

Дивився тільки слайди.

Ethernet:
«10baseT: перехрестне зʼєднання» — для 100baseT те ж саме, я б узагальнив.
Слайд 12: краще перекласти репліку в бульбашці.
Унікальна MAC-адреса: зараз є систематичні випадки генерації випадкового MAC локального типу (46 битів випадковості), наприклад, для внутрішніх віртуальних адаптерів LXC- або VZ-контейнерів; є мережі, де таких більшість. У Вас локальне призначення адреси вказано одною малозначною реплікою, його не помітять.
Приклади — туди б ще Linux крім Windows.
«Комутатор — багатопортовий мультипроцесорний міст» — чому «мультипроцесорний», це невірно для малих комутаторів, яких в кожному домашньому wifi раутері, наприклад.
Винесення 100baseT з його специфікою (як переговори щодо носія) — застаріла структура. Це слід було зробити головним варіантом вже давно.

IP:
«Спрощена маршрутизація» про IP6 — це що? Про /64 на локальному рівні? Тоді це невірно, тому що на вищих всі ті ж проблеми, що для IP4, та й для нижчих /64 це тільки типова рекомендація.
«Адресація на канальному рівні враховується в IP адресі» для IP6 — знову невірно. Вона _може_ враховуватись і це використовується при автоматичному призначенні адрес для клієнтських систем (те, що замістило DHCP у найбільш простому режимі налаштування). Але ніхто не зобовʼязує їх так використовувати. І для серверів це ніхто не робить, тому що серверу треба адресу, незалежну від конкретного адаптера. Подивіться на IP6 адреси будь-якого публічного сервісу (від кореневих DNS серверів до гугла з фейсбуком) — у всіх друга половина фіксована і не зроблена з MAC адреси. f.root-servers.net == 2001:500:2f::f, для прикладу.
Слайд 17 — не вказано ні мультикасти, ні резервний блок 240.0.0.0-255.255.255.254.
В приватні IP адреси слід добавити 169.254/16, хоч вона і не від IANA, а від Microsoft.
Не вказано аналогів приватних мереж для IP6 (таких, як ULA).

Сумуючи: забагато фактичних помилок та неточностей, недовказаностей. Потребує значного коректування.

Відповісти

Підтримати

Пупена Александр 03.05.2015 11:07

Не сумуйте, для цього і спитав, щоб ви вказували на ці помилки та неточності. Я ж не ITшник а автоматчик. Я навіть не знаю, де мені реально IPv6 знадобиться, а Linux я взагалі не знаю. Всі зауваження щодо Ethernet врахую на 2-й ітерації, щодо IP — буде ще 2-га частина. Там буде і IPv6 в тому числі. Буду намагатися зробитиза деклька днів до лекції, якщо буде Ваша ласка — зможете поправити. Щодо перекладу фраз в бульбашках — це Ви про мову, чи про зміст фрази? У мене подібні картинки по всьому курсу, бувають на російській бувають на українській.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 11:15

Щодо перекладу фраз в бульбашках — це Ви про мову, чи про зміст фрази?

Про мову.

У мене подібні картинки по всьому курсу, бувають на російській бувають на українській.

Бачив. Деякі надто складніше замінити, але в даному випадку це зможе довільний студент:)

Не сумуйте,

Я в сенсі «суммировать», а не «тосковать». Так, дивна омонімія.

Відповісти

Підтримати

Пупена Александр

Пупена Александр 03.05.2015 11:19

Картинки я сам придумовував, так що сам можу й перекласти. Але я спеціально так робив. Про «сумуючи» смішно вийшло :)

Відповісти

Підтримати

Valentin Nechayev

Отважный Заяц 03.05.2015 14:46

Если вы не ITшник, то найдите его.
На вашей кафедре их предостаточно.

Відповісти

Підтримати

Пупена Александр

Oleg Korol POWER Ops, again 03.05.2015 18:09

«Комутатор — багатопортовий мультипроцесорний міст»

це взагалі невірно

Відповісти

Підтримати

Valentin Nechayev

Dmytro Tsapko Engineer в Qbox 03.05.2015 18:24

Что-что? Если это

це взагалі невірно

, как вы будете описывать данное устройство TL-SF1005D.(это Ethernet коммутатор)
При том, что автор последовательно идёт от физического уровня и выше.
Как вы опишите это устройство, после кратого рассказа о физическом уровне и обзорного об MAC уровне?

Відповісти

Підтримати

Oleg Korol POWER Ops, again 03.05.2015 19:05

если считаете себя инженером, то хотя бы почитайте как работает коммутатор и мост
там ключевые отличия не только в кол-ве портов и уж тем более процессоров :-)
P.S. самолет — это автомобиль, но с крыльями? :-)
такие правда есть :-) но значительно меньше 1% летного парка

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 03.05.2015 19:52

Если вы считаете себя инженером, не пишите глупых смайликов и не приводите глупые сравнения с самолётиками.
Конкретно по пунктам укажите разницу между Ethernet bridge и простейшим Ethernet switch, который не поддерживает stp, vlans и прочие технологии.
И не забывайте что вы отвечаете в конксте подготовленного материала для чтения студентам. Если

це взагалі невірно

, то как правильно?

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 21:04

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

Сравнение абсолютно корректное.

то как правильно

Правильно — разделять в принципе мост и коммутатор, потому что есть устройства, которые коммутатор, но не мост. Не верите — почитайте стандарт IEEE 802.1d (lдоступен бесплатно), который явно утверждает:

> A MAC Bridge for which conformance to this standard is claimed shall
[...]
> f) Implement the Rapid Spanning Tree Protocol, as specified in Clause 17.
> g) Encode transmitted BPDUs and validate received BPDUs as specified in Clause 9.

Даже если мы возьмём более ранние версии, в которых требовалось не RSTP, а просто STP, суть не изменится — в стандартах вообще не предполагается коммутатора, который не посылает BPDU и не отрабатывает по ним STP.

Поэтому та коробочка, которая стоит у 90% читателей данного и кормит вайфаем лаптоп, а с другой стороны имеет какой-то вариант выхода в интернет — содержит в себе коммутатор, но не мост.
Sad but true :) Именно это и следовало бы указать в курсе, не сбивая с толку утверждением типа «коммутатор это <куча положительных эпитетов, означающих крутизну> мост».

Відповісти

Підтримати

Пупена Александр 03.05.2015 21:28

Я не могу с Вами спорить, так как не являюсь профи в этом деле (уже начал повторяться). Первоначально я базировался на книге Олиферов (www.twirpx.com/file/1486488/, где изложение принципов работы идет именно от моста до коммутатора. Вся инфа взята оттуда. Проверял ли я её — нет, да и не знаю чем, стандарты читать довольно долго, и не для автоматчиков они написаны, подозреваю что даже не для IT, скореедля разработчиков сетевых девайсов. Один раз засомневался в одновременной передаче по одной линии туда и обратно в Гигабитном Ethernet — залез в стандарт, увидел нужную фразу, и понял, что в книге правильно. Остальную инфу не проверял. Читаю я ваши комменты относительно моста, и до конца не могу понять. Может ткните мне ссылками, но только не стандартами.
Спасибо за комменты.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 21:38

Я не могу с Вами спорить, так как не являюсь профи в этом деле (уже начал повторяться).

Хм, ну я спорил вообще-то не с вами :) хотя основную пользу всё это должно дать именно вам.

Может ткните мне ссылками, но только не стандартами.

Увы, я их давно не собираю. Но есть, например, книги от Cisco по подготовке к экзаменам, книга Таненбаума по сетям, и многое аналогичное.

Відповісти

Підтримати

Пупена Александр

Пупена Александр 03.05.2015 21:40

Таненбаума я читал. Посмотрю еще раз. Заодно и в стандарт IEEE 802.1d гляну.

Відповісти

Підтримати

Valentin Nechayev

Roman Romaniuk Senior Software Engineer в SoftServe 04.05.2015 22:36

Посмотрите тогда ещё и курс Cisco CCNA. Я по нему учился и его сдавал. Вот там структура подачи материала от_простого_к_сложному идеальна.

Відповісти

Підтримати

Пупена Александр

Oleg Korol POWER Ops, again 04.05.2015 00:17

дело в том что bridge и switch — это изначально разные устройства (я уже выше приводил пример с самолетами и автомобилями), по назначению, несмотря на действительно схожую логику работы
bridge изначально были предназначены для соединения сетевых сегментов с изоляцией коллизионных доменов между ними
и если разница, например в том, что коммутаторы могут работать в режимах как store-and-forward так и cut-through и их вариациях, а мосты только — store-and-forward, то это уже следствие, а не причина
и увеличение кол-ва интерфейсов более 2 не превратит bridge в switch (подобная формулировка совершенно не корректна), будет multi port/ multi point bridging (последнее используется в наши дни в wifi-сетях)
вообще технология bridge исходит из DEC — en.wikipedia.org/...iki/Bridging_(networking
модульный многопортовый bridge — decdoc.itsx.net/dec94mds/defebps2.pdf

Відповісти

Підтримати

Пупена Александр

Dmytro Tsapko Engineer в Qbox 04.05.2015 11:25

Я с вами согласен в том, что исторически bridge объединял большие сегменты сети.
Но это не делает разницу между transparent bridge и switch.
Я веду речь о transparent bridge, а вы приводите ссылку на translating bridge. Или для вас разницы нет?

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 03.05.2015 23:16

Спасибо за конструктивный ответ.
1) В англоязычной литературе как таковые термины Ethernet switch/MAC Bridge/Ethernet Bridge, как я вижу взаимозаменяемые.
2)Первый разработанный компанией DEC Ethernet Bridge не поддерживал протокол STP ни в каком виде. Но при этом первая же модель Ethernet Bridge от этой же компании котаря поступила в продажу, уже поддерживала STP.
3) Согласен с вами, что на данный момент Ethernet switch он же MAC Bridge определён в стандарте 802.1d. Но при том выходит, что по факту Ethernet(MAC) Bridge и Ethernet switch это одно и то же.

Но вы выразились

Правильно — разделять в принципе мост и коммутатор, потому что есть устройства, которые коммутатор, но не мост.

Можно поподробнее, где Ethrernet bridge может быть не Ethernet switch. Или вы имели виду бриджи wifi/ethernet, ethernet/token ring и прочее?

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 07:36

Можно поподробнее, где Ethrernet bridge может быть не Ethernet switch.

А к чему этот вопрос в таком виде? Я ни словом не утверждал, что такое возможно. Я утверждал, что не каждый свич — мост, но не наоборот. Это уже к ТС (и то, он уже признался, что недостаточно разбирается, и будет исправлять).

Чисто формально, я считаю, такой вариант возможен, если устройство будет работать с BPDU и отрабатывать STP, но не будет иметь forwarding table и рассылать все обычные пакеты во все стороны. На практике так иногда получается; это случай, когда или в таблице форвардинга неизвестно, где получатель, или она переполняется и для части получателей не хватает места. Но представить себе, чтобы кто-то намеренно конструировал устройство, которое так работает в принципе — последние 15 лет не получается: если оно достаточно умное, чтобы отрабатывать STP, оно будет достаточно умным, чтобы иметь и применять хотя бы небольшую forward table, тем более, что это резко снизит избыточный трафик в сети. Но, повторюсь, формально такое возможно.

(Тут уже мы можем влезть в тонкости понятий «мост» и «коммутатор», где они определены, и как. Я всё-таки не хочу на это тратить много времени, перебирать источники определений... Для данного курса надо подходить с практической стороны. Я бы разделил «мост» и «коммутатор» в соответствии с текущей практикой, а не стандартами — для того, чтобы студенты поняли, что, например, нельзя делать циклы в системах из дешёвых неуправляемых коробочек: те в принципе не способны определить и отсечь лишние петли; а если нужно дублировать — то надо переходить на более высокий уровень аппаратуры. Вот это — полезное практическое понимание, и соответствующее текущей практике.)

Или вы имели виду бриджи wifi/ethernet, ethernet/token ring и прочее?

Это, безусловно, тоже следует иметь в виду, хотя практическая ценность тут крошечная (увидеть вживую token ring вряд ли доведётся хоть одному слушателю, а wifi формально тут тот же ethernet, хоть и по другому транспорту).

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 04.05.2015 11:38

а wifi формально тут тот же ethernet, хоть и по другому транспорту

то, что ethernet и wifi имеют разные среды, методы доступа к среде, формат кадра, способы аутентификации, вас не смущает?
Назовите то общее между этими технологиями которое делает для вас эти технологии один и тем же.

Чисто формально, я считаю, такой вариант возможен, если устройство будет работать с BPDU и отрабатывать STP, но не будет иметь forwarding table и рассылать все обычные пакеты во все стороны. На практике так иногда получается; это случай, когда или в таблице форвардинга неизвестно, где получатель, или она переполняется и для части получателей не хватает места. Но представить себе, чтобы кто-то намеренно конструировал устройство, которое так работает в принципе — последние 15 лет не получается: если оно достаточно умное, чтобы отрабатывать STP, оно будет достаточно умным, чтобы иметь и применять хотя бы небольшую forward table, тем более, что это резко снизит избыточный трафик в сети. Но, повторюсь, формально такое возможно.

Все ethernet коммутаторы работают на основе технологии transparent bridging и все те ситуации которые вы описали являются частью этой технологии. Если у свитча нет mac address table то о какой коммутации или stp идёт речь? Это будет уже просто транслятор.

Я бы разделил «мост» и «коммутатор» в соответствии с текущей практикой, а не стандартами

разве есть разница между стандартами и практикой?

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 11:54

то, что ethernet и wifi имеют разные среды, методы доступа к среде, формат кадра, способы аутентификации, вас не смущает?

Не смущает, пока 99.999% использующих wifi использует только транспорт Ethernet поверх него, и их не интересует, что там внутри у wifi.

Назовите то общее между этими технологиями которое делает для вас эти технологии один и тем же.

См. предыдущую реплику.

Все ethernet коммутаторы работают на основе технологии transparent bridging и все те ситуации которые вы описали являются частью этой технологии.

Вы фразу про требования к мосту в 802.1d прочитали?

Если у свитча нет mac address table то о какой коммутации или stp идёт речь? Это будет уже просто транслятор.

И опять Вы не хотите слушать, о чём речь. У того, что у каждого в квартире, есть mac address table, и есть коммутация, но нет умения STP. Как правильно это назвать, если оно вполне себе коммутатор, но не мост?
И это уже явно не транслятор из ваших понятий.

разве есть разница между стандартами и практикой?

Её полно. Начиная с того, что передача IP (которая составляет почти 100% реальной потребности среднего пользователя) использует совершенно нестандартный Ethernet II формат фрейма, а на стандартные 802.3 и SNAP авторы Internet плевали с высокой колокольни. И такое здесь ходит пачками.

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 04.05.2015 12:12

и их не интересует, что там внутри у wifi.

если так рассуждать, то пусть OTV будет MPLS, потому что где-то заголовки пересекаются, «и никого не интересует, что там внутри».

И опять Вы не хотите слушать, о чём речь. У того, что у каждого в квартире, есть mac address table, и есть коммутация, но нет умения STP. Как правильно это назвать, если оно вполне себе коммутатор, но не мост?
И это уже явно не транслятор из ваших понятий.

согласен.

Её полно. Начиная с того, что передача IP (которая составляет почти 100% реальной потребности среднего пользователя) использует совершенно нестандартный Ethernet II формат фрейма, а на стандартные 802.3 и SNAP авторы Internet плевали с высокой колокольни. И такое здесь ходит пачками.

Тот же ethernet v2 был стандартизирован IEEE ещё 97 году выходит это не только практика но и стандарт.
Студента нужно ознакомить со всеми популярными форматами того же ethernet кадра. Я не раз видел тот же SNAP заголовок в захваченном траффике(например тот же cisco CDP).
Именно по этому я считаю, что рассказывать не нужно подробно только о вымерших технологиях и о технологиях мертоврождённых. Всё остальное нужно рассмотреть.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 12:39

если так рассуждать, то пусть OTV будет MPLS, потому что где-то заголовки пересекаются, «и никого не интересует, что там внутри».

«Если так рассуждать», то имеет смысл углубляться в детали wifi или когда нужно научить работать с wifi не только на уровне «нашёл SSID, задал пароль и включился» — или как админу, или как программисту (для передачи чего-то именно по wifi с его стилем). Если это нужно в данном курсе, то пусть будет. Иначе — wifi как транспорт для ethernet вполне удовлетворит.

Тот же ethernet v2 был стандартизирован IEEE ещё 97 году выходит это не только практика но и стандарт.

Какой номер стандарта? И, пусть так, но долго его отказывались принять.

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

В принципе — да. Но — 1) в современном ключе. 2) то, что таки актуально для курса.
10Gbit/s, пожалуй, сюда не ложится, а вот 10Mbit/s — вполне. Коаксиал — забыть (разве что при пояснении исторических причин некоторых особенностей). Ну и так далее.

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 04.05.2015 12:50

EThernet v2. As this industry-developed standard went through a formal IEEE standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard.

Прочёл на en.wikipedia.org/wiki/Ethernet_frame , там же есть ссылки на стандарт.

Відповісти

Підтримати

Valentin Nechayev

Пупена Александр 04.05.2015 09:47

Нашел этот пункнт, действительно даже по формальным признакам обычный комутатор не является МАС-мостом. Олиферы были не правы. :) Правда весь стандарт не читал, надеюсь это не вырвано с какого-то противоречащего контекста.

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 09:49

Со вводной части, которая ещё не имеет никакого контекста, кроме собственно данного стандарта.

Відповісти

Підтримати

Пупена Александр

anonymous 02.05.2015 18:40

-

Відповісти

Підтримати

Пупена Александр 02.05.2015 18:45

В усіх каталогах промислові мережі наводять в контексті OSI, при тому, що для них є і своя МЕКовська модель, де тільки 3 рівні фізичний, канальний і прикладний. Ви пропонуєте всі давати в контексті моделі TCP/IP? Я ж на лекціях не обмежуюсь тільки цими темами, там ще Modbus, Profibus, Canopen, де ні транспортного ні мережного (міжмережного) немає. Тому, я даю в кнтексті OSI, при цьому за 5-й та 6-й рівні забуваю.

Відповісти

Підтримати

anonymous 02.05.2015 18:53

-

Відповісти

Підтримати

Пупена Александр

Пупена Александр 02.05.2015 19:10

Не зрозумів. У мене курс «Промислові мережі та інтеграційні технології».

Відповісти

Підтримати

anonymous 02.05.2015 20:14

-

Відповісти

Підтримати

Пупена Александр

Пупена Александр 02.05.2015 20:22

Я зрозумів що це сарказм, але я не зрозумів чому. Декілька картинок нагуглив на «Profibus layers»: us.profinet.com/...014/01/Ethernet_model.png, www.ats-global.com/..._profibus-technology.html Так само можна нагуглити на інші промислові мережі. Всі в контексті ISO OSI. Яка б вона не була «непрактичною», але розробники при описі користуються нею, а отже нею буду користуватися і я. Тим більше, як я вже сказав, TCP/IP модель окрім Ethernet + TCP/IP для інших «наших» мереж не годиться. Крмі того є промислові рішення на базі Ethernet без того ж TCP/IP, як тоді їх прдеставляти? Чи Ви якусь іншу модель мали на увазі, не TCP/IP?

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 03.05.2015 12:44

Она не нужна, в случае если курс будет читаться детям десяти лет. Если курс будет читаться будущим инженерам, то модель OSI обязательна.

Відповісти

Підтримати

Пупена Александр

anonymous 03.05.2015 22:14

-

Відповісти

Підтримати

Пупена Александр

Dmytro Tsapko Engineer в Qbox 03.05.2015 22:38

Если бы модель OSI не была нужна, то я не слышал бы от тех. поддержки различных вендоров, от специалистов различных интеграторов и компаний, фразы следующего плана: «шторм в этом L2 сегменте сети», «проблемы на физическом уровне», «ошибки на канальном уровне», «наш балансировщик поддерживает балансировку L4-L7 траффика», " эта версия прошивки фаервола поддерриживает L4-L7 инспекцию протоколов, «L3 свитч», и т. д
Вывод: понимание зон ответственности уровней модели OSI, и какие протоколы какой функционал каких уровней модели OSI выполняет — важно для IT инженера.
Например, если я не слышал о стандарте/протоколе MIME, но мне скажут, что проблемы на presentation layer с этим протоколом, то я уже буду понимать направление в котором нужно «рыть». Либо если мне сообщают о проблемах на физическом уровне, я даже ещё не услышал название технологии и сегмента сети, но уже понимаю какого плана проблема.

Відповісти

Підтримати

anonymous 03.05.2015 23:04

-

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 03.05.2015 23:15

З чого ви взяли, що MIME — це presentation layer?

Учил OSI.
TLS — размазан по L5 -L6.

А cookie куди?

туда же куда и HTTP.

А якщо application може працювати поверх tcp, а може через http поверх tcp, або взагалі через WebAPI поверх http поверх tcp?

Пусть себе работает.

Відповісти

Підтримати

anonymous 03.05.2015 23:37

-

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 08:00

Задайте собі питання — якби ви не знали моделі OSI, як би змінилося ваше уявлення про стек, на якому працює сучасний інтернет?

Воно б було значто менш чітким і ясним, і ставило би в глухий кут у відповідь на кожну зміну якоїсь деталі (як мідь на оптику, TCP на SCTP, HTTP на HTTPS, і так далі).

Відповісти

Підтримати

anonymous 04.05.2015 10:44

-

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 12:02

Та ладно? Яка різниця application, що є транспортом? Хоч tcp, хоч http, хоч named pipes.

Саме так! Коли йому нема різниці, що є транспортом, якщо цей транспорт виконує його потреби — це й є гідне розділення на шари. Ви підтвердили мою позицію.

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 04.05.2015 11:51

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

Ким розмазаний? Тим, хто натягував презерватив на глобус?

Разработчиками протокла.

Правда? А чого ж ви MIME засовуєте на якийсь інший рівень?

Когда я вёл лекции по сетевым технологиям, то модель OSI рассказывал на первых лекциях. И когда мы изучали разные протоколы, возможность закрепления протокла за уровнем(уровнями) модели OSI помогает сформировать чёткую картину.
Пример: Взяли мы SMTP, поговорили о проблематике которую он решает, об самом протоколе. Далее можно говорить о его расширениях и развитии и о том, что тот же MIME добавляет к SMTP возможности разделять данные которые передаются в сообщении.
И уже потом когда будем изучать протокол HTTP можем опять упомянуть MIME который и с этим протоклом тоже используется
для возможности разделить данные по типу.

Відповісти

Підтримати

Пупена Александр 04.05.2015 12:19

А я ISO OSI дав вже після реалізації фізичного рівня (у нас там розглядалися інтерфейси RS232, RS422, R485) та Modbus RTU/ASCII (там канальний та прикладний). Вже на тих лекціях оперував з назвами і пояснював призначеннями, навіть про невеличку розмитість казав. А потім вже давав тему моделей, де вказав ISO OSI, TCP/IP та МЕКовську. А вже після цього ми дійшли до Ethernet.

Відповісти

Підтримати

Dmytro Tsapko Engineer в Qbox 04.05.2015 12:30

Мне было удобнее давать сначала OSI, и потом всё остальное мапить на неё, но я читал лекции сетевикам/админам, это другой профиль.

Відповісти

Підтримати

Пупена Александр

Пупена Александр 04.05.2015 13:05

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

Відповісти

Підтримати

anonymous 04.05.2015 16:05

-

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 07:59

Де сесії? Невже на L5?

Якщо сесіями названа взаємодія двох сторін у межах цільового протоколу, то саме так.

З чого ви взяли, що MIME — це presentation layer?

Тому, що воно використовується для представлення даних. Якщо заперечуєте, наведіть свої аргументи.

А якщо application може працювати поверх tcp, а може через http поверх tcp, або взагалі через WebAPI поверх http поверх tcp?

Як я вже говорив, тунелювання є розширенням того, що провадить ISO у власних реалізаціях, але не скасовує саму схему рівней.

TLS?

TLS — це власний багаторівневий прошарок, який служить транспортним рівнем для цільових застосувань.

А cookie куди?

І які саме з ними проблеми? Розʼясніть.

Відповісти

Підтримати

anonymous 04.05.2015 10:42

-

Відповісти

Підтримати

Valentin Nechayev

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 12:00

Сесії є як на рівні tsp, так і на рівні tls, так і зверху http.

Саме так. І це ніяк не протирічить сказаному мною.

Воно не використовується для представлення даних. Це всього лише підказка для браузера. Це не окремий шар, це паралельний набір даних.

MIME — «паралельний набор даних»? Мабуть, Ви не знаєте, що це.

RFC2045 для початкового читання, і наступне за ним.

Підтягування практики до теорії. ISO не дозволяє тунелювання.

Мабуть, навпаки — теорії до практики? Так, ISO не дозволяє, і я це відкрито вказав. У чому Ваше заперечення?

Ну якщо ви називаєте mime рівнем, то назвіть і cookies рівнем.

Спочатку Ви розберіться, що таке MIME. Тоді продовжимо.
(Я вже, мабуть, зʼясував, що Ви в ньому невірно зрозуміли. Але зачекаю на відповідь.)

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 07:53

Ніхто за більш ніж 20 років не реалізував модель OSI — всі промислові мережі будують так, як вирішать їх автори, а потім євангелісти вирішують, а як же рівні натягнути на рівні моделі OSI.

Всі промислові мережі (щонайменше, які я бачив) практично повністю відповідають моделі OSI, коли вже побудовані, і ніякого євангелізму тут не треба. Це не тому, що під них якось підлажуються, а тому, що їх в принципі не можна обійти так, щоб побудувати щось працююче і стабільне.

Інше питання, що модель OSI, як вона пропагандується самим ISO, має декілька рис, які в практиці втрачаються. ISO не дозволяє інверсії порядку рівней; будь-яке тунелювання є такою інверсією. ISO формально не дозволяє керування нижчого рівню вищим; у нішій практиці таке на кожному кроку (наприклад, BGP керує 3-м рівнем, а сам має всі аж до 7-го). З такими поправками модель стає працюючою. І вже для такого виду я не бачив жодного випадку, коли б реалізація не відповідала йому. Деякі називають це «народним OSI», я не проти. Але стверджувати, що воно зовсім не реалізовано — маячня від модних блогерів, які не потратили 5 хвилин на те, щоб подумати. Шкода, що за ними так багато повторюють.

Якщо хочете заперечити — наведіть конкретні приклади: який саме протокольний стек побудований так, що його треба явно з зусиллями «натягувати» на модель OSI, тоді обговоримо.

В практичних цілях ніякого смислу в моделі OSI немає

До речі, є реалізації власне стеку ISO і вони працюють. Наприклад, всі перші банкомати тут були саме на них. І зараз можна їх застосувати (хоча б для перевірки своїх ідей). Деякі риси в них з самого початку були більш адекватні, ніж в TCP/IP — як наявність зʼєднання формату «впорядкований потік повідомлень з забезпеченням доставки».

Відповісти

Підтримати

anonymous 04.05.2015 10:37

-

Відповісти

Підтримати

Valentin Nechayev

flyman 04.05.2015 10:47

я собесідувався в одну фірму, яка хотіла натягнути CANbus на OSI,
але як на мене, то придурки а не эвангелісти

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 11:55

Ніякого «зусилля» після того, що я описав, нема — вкладається без проблем.

Хоча по суті (як історично, так і теоретично) TCP/IP це паралельне до моделі OSI.

Отак, напрям нумерації рівнів протилежний :)

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 09:15

Вона не мертва тим, що впорядковує наше уявлення, дає йому базис для розвитку.

Відповісти

Підтримати

Євген Лесько Competency manager в ELEKS 01.05.2015 16:40

По поводу “Протоколи IP (частина 1)”. Я читал подобную лекцию студентам о сокетах. Если Ваши лекции предназначены для обучения, несут новые знания, а не являются обобщением и повторением пройденного, то тогда думаю следовало бы поменять порядок материала. Я имею в виду, что стек TCP/IP на сетевом уровне использует протокол IP, а последний состоялся во многом благодаря тому, что придумали IP-адресацию. Т.е. идти “от истоков” :) Аналогично, сначала представить уровни модели OSI, потом — уровни стека TCP/IP и сравнить их.
Т.о. после общих определений (и возможно очень коротких исторических справок) я бы начал с IP-адресации (типы адресов, развитие в IPv6 и пр.). Слайд № 11 корректнее назвать просто “IP адресация”, без привязок к TCP/IP. Потом рассказать о маршрутизации, затем идти по уровням стека: протокол ARP, потом IP протокол и вспомогательные. Ньюанс — если Вы уделяете время адресации IPv6, то уделите чуть и для протокола ICMPv6 наряду с ARP. Затем я бы добавил по одному слайду — для протоколов TCP и UDP, и еще один — их сравнение (вместо слайда № 4). Тогда слайды №№ 2 и 3 будут логическим обобщением лекции. Отаке ИМХО.
Еще три пожелания.
— Ваши слайды действительно перегружены, некоторые — не читабельны. Подозреваю что АСУТПшники такие же люди с такой же остротой зрения и восприятия :) Например, второй слайд нужно определенно разбить на два, и таблички увеличить. Если не делится или не впихуется — увеличивайте схемы, а текста оставляйте по минимуму, остальное — у себя на шпаргалке :)
— Не стесняйтесь приводить англоязычные термины. Вы это делаете (например слайд 17, я встречал переводы термина “broadcast” и как “широкомовне”, и как “трансляційне”), но важно дать их на первых слайдах тоже, там где термин встречается впервые.
— Слайд 13, исправьте фразу “в структурі IP адреси не визначено де номер підмережі а де вузла...”. Все визначено, Вы сами на 15-м слайде об этом говорите :) По крайней мере, в свою фразу добавьте слово “однозначно не визначено”.
Литература — я искал источники в интернете. Можно в англоязычных статьях википедии (как правило, они полнее) смотреть на список литературы, я часто так нахожу толковые источники.

Відповісти

Підтримати

Пупена Александр 01.05.2015 16:51

Спасибо.
На счет перегруженности — буду учитывать. Хотя преследовал несколько целей: не хотелось плодить слайдов и хотелось дать возможность повторить без просмотра видео, ну и конечно забыть (что можно и в шпаргалку).
До этих занятий есть темы, где рассматривались ISO OSI. TCP и UDP будут в отдельной теме.

Відповісти

Підтримати

Євген Лесько

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 01.05.2015 13:01

Просмотрел побыстрому.
Несколько замечаний сходу:
1. 10base5, 10baseT — это уже довольно давно предметы в основном истории и не стоит заострять на них столько внимания. Особенно в ущерб 10Gb интерфейсам, которые уже практически стандарт для энтерпрайз топологий.
2. Выкиньте описание «моста». Оно мало того, что неправильное (в индустрии этим словом называют интерфейс-конвертеры, а не фильтры), так еще и бесполезное по причине отсутствия таких устройств.
3. Уделите больше внимания layer-2 коммутации, в том числе STP и протоколам предотвращения STP-loop. Невзирая на кажущуюся простоту — на практике с этой проблемой рано или поздно встречаются 70-80% сетевиков при росте топологии и-или использовании оборудования нескольких производителей и обнаружение-разруливание должно быть доведено до автоматизма.
4. Опишите кратко устройства типа «TAP» и их программную реализацию в коммутаторах (span-ports).
5. Опишите VLAN.
6. Опишите подробнее 10Gb топологию и интерфейсы. Остановитесь подробнее на параметре latency и его важности для производственных систем, а также методах hardware offloading для оконечных устройств.
7. Опишите методы и стандартные топологии резервирования-высокой доступности.

Ну и одно общее замечание не по сути — не старайтесь впихнуть в один слайд много информации, тем более если полусается мелко. Лучше сделайте несколько слайдов с более крупным текстом-таблицами-рисунками, так будет лучше восприниматься.

Відповісти

Підтримати

Пупена Александр 01.05.2015 13:18

Материал дается для АСУТПшников от АСУТПшника :) . Тяжело найти границу докуда копать, мы ж все-таки не ITшники, но приходится иметь дело с Ethernet. Первая часть по Ethernet прочитана, но это только первая итерация, по-этому и спросил. Вторая часть Ethernet предвидит в т.ч п.3,5.
Всё остальное взял на зметку.
Может подскажете еще хороший материал для проработки?
Спасибо.

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 01.05.2015 16:48

Тяжело найти границу докуда копать,

Это понятно — видится как минимум базовый траблшутинг и описание причин возникновения наиболее частых проблем.

Вторая часть Ethernet предвидит в т.ч п.3,5

Отлично, видимо не дошел до этой презентации, сорри.

Может подскажете еще хороший материал для проработки?

К сожаленю — за давностью и спецификой работы помню только курсы вендоров, где давали подробную информацию. Возможно — Cisco Network Aсademy (не знаю правда можно ли оттуда распространять информацию).

Відповісти

Підтримати

Пупена Александр

Пупена Александр 01.05.2015 17:00

Второй части пока нет :) Эти лекции создаются в «реал-тайме» :)
На следующий раз продолжение IP+утилиты, потом UDP/TCP+утилиты, потом немного о прикладных протоколах, потом только 2-я часть Ethernet. Планирую до этого поиграться с каким-то управляемым комутатором, а потом промышленный и Real Time Ethernet (RTE — обзор). Где-то так.
Вобще тема для меня не самая выгодная, инфы много, надо оттуда забрать именно то, что надо нам. По-этому по максимуму смотрю что есть в сетевых настройках «наших» девайсов (как правило PLC и шлюзов) и софта (дрова для SCADA). Учитывая что RTE — это «наше», Ethernet со всем добром TCP/IP автоматически тоже уже наше.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 03.05.2015 09:49

10base5, 10baseT — это уже довольно давно предметы в основном истории и не стоит заострять на них столько внимания. Особенно в ущерб 10Gb интерфейсам, которые уже практически стандарт для энтерпрайз топологий.

+100. На сейчас всё, что не витая пара и не оптика, должно уйти в отдельную историческую секцию, а оставшиеся — рассматриваться сразу в одновременном применении 10, 100 и 1000 Mbit/s, а то и 10GB сразу.

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

Тоже согласен. Мостов, которые не коммутаторы, не осталось, а коммутаторы есть у каждого дома. Тут же лучше всего было бы взять сфоткать какой-нибудь TP-Link TL841N или близкую модель и нарисовать внутреннюю схему (коммутатор двух разных media — медь и wifi — плюс маршрутизатор, в одной коробочке).

Опишите кратко устройства типа «TAP» и их программную реализацию в коммутаторах (span-ports).

Какой именно TAP имеется в виду?

Опишите VLAN.

Да, это обязательно.

Опишите подробнее 10Gb топологию и интерфейсы. Остановитесь подробнее на параметре latency и его важности для производственных систем, а также методах hardware offloading для оконечных устройств.

Offloading стартовало уже с 100Mbit/s, так что к 10GB я бы его не привязывал. Но это тема немного другого раздела.

Відповісти

Підтримати

Oleg Korol POWER Ops, again 03.05.2015 18:54

в индустрии этим словом называют интерфейс-конвертеры

если речь про физические интерфейсы, то это все же — media converter-ы
а мосты с разными типами интерфейсов/протоколов — это translating bridges

отсутствия таких устройств

xDSL-модемы в основном используют в режиме bridge
и на последней миле они все еще не редкость

Відповісти

Підтримати

flyman 04.05.2015 09:18

10Gb

в АСУТП?
там ще УАРТ на 9,6 Кбод рулить, а перехід на 10baseT езернет — квантовий стрибок.
3.4.5.6.7
для чого?

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 10:01

а перехід на 10baseT езернет — квантовий стрибок.

Який був пройдений років 10-20 тому. Якщо Ви згадуєте типове пострадянське підприємство, що в 90-х автоматизувало технологіями 80-х круг станків 50-х — так, там буде UART на 9600. Але як щось більш сучасне — там буде ethernet.

Відповісти

Підтримати

flyman 04.05.2015 10:03

Який був пройдений років 10-20 тому

Да ти шо.
Може бути що завгодно, польових шин море, а Езернет — не польова шина, скоріше для міжцехової взаємодії.
Візьми привід АВВ чи Шнайдера або Сіменса, там скоріше за все або Профібас або CANbus і ніякого Езернета.

Відповісти

Підтримати

Valentin Nechayev

Пупена Александр 04.05.2015 10:14

Неправда, в них ще до приводу є карта Ethernet (ще з початку 2000-х). Просто це недешеве задоволення. Siemens доречі вже практично не приховує, що ProfibusDP — це минуле, всі сили кинуті на Profinet (ProfinetIO — саме для поля). Шнейдер те саме, сили кинуті на Ethernet/IP, усі нові модулі ПЛК з Ethernet підтримують цей стек протоколів, ну і Modbus TCP/IP для м’яких реал-тайм рішень.

Відповісти

Підтримати

Valentin Nechayev архімаггриб в Дарницькі печери 04.05.2015 12:08

Я під UART зрозумів лише RS-232. Якщо малось на увазі щось більш придатне для виробничих умов, то непорозуміння саме в цьому.

Відповісти

Підтримати

Пупена Александр 04.05.2015 12:23

UART викоритсовується також разом з RS422 та RS485. У ProfibusDP теж асинхронна передача на класичному 11-бітному символі, однак бітова швидкість там до 12 Мбіт/с (на RS-485).

Відповісти

Підтримати

Valentin Nechayev

Пупена Александр 04.05.2015 10:09

На самому ділі, є і 9600/19200 і Ethernet, правда поки бачив максимум тільки Гігабітний, як правило 10/100 Мбіт/с. Доречі більшість АСУТПшників до сих пір вважають, що в сучасному Ethernet працює CSMA/CD, а адресація вузлів в Ethernet йде по IP.
Щодо протоколів та рішень, то там їх просто неміряно. От наприклад деякі з них fb.asu.in.ua/...rnet/2.png?attredirects=0

Відповісти

Підтримати

Valentin Nechayev

flyman 04.05.2015 10:21

так тож Industrial Ethernet, який до офісного езернету має мало відношення

а адресація вузлів в Ethernet йде по IP.

Модель ОСІ розроблена для інтернету, тобто багаторангових мереж.
Що таке вузол у вашому розумінні?
Із адресацію не все так просто, в межах однієї мережі можна і по МАС адресі, але на міжмережевому рівні адресація (і маршрутизація) іде по ІР.

Відповісти

Підтримати

Пупена Александр

Підписатись на коментарі

Ваша пошта

Не підписуватись