Пользователь
0,0
рейтинг
5 июня 2009 в 18:34

Администрирование → Multicast routing для IPTV

Один очень близкий мне человек, поклонник Хабра, захотел внести вклад в развитие блога Cisco. Являясь яростным поклонником того, что создает эта корпорация, он захотел поделиться опытом. =) Надеемся росчерк пера удался.

Относительно недавно мне посчастливилось познакомить и даже поконфигурять multicast routing для IPTV. Изначально, я с этой темой была совершенно не знакома, и это заставило меня вылакать горлышко от цистерны водки перекопать огромное количество документации, чтобы войти в курс дела.

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

Мне не удалось обнаружить такую статью. Это побудило меня написать эту статейку для тех, кто также как и я столкнется с вопросом, что это за зверь IPTV и как с ним бороться.

Введение


Это моя самая первая статья (но не последняя! есть еще много зверей), постараюсь изложить все как можно доступнее.

Первым делом озвучим несколько понятий, чтоб исключить дальнейшие недопонимания. Существует три вида трафика:
  • unicast — одноадресный, один источник потока один получатель
  • broadcast — широковещательный, один источник, получатели все клиенты в сети
  • multicast — многоадресный, один отправитель, получатели некоторая группа клиентов

Какой вид трафика использовать для IPTV?

unicast broadcast multicast
Особенности применительно к IPTV получаем дублирование трафика, для каждого абонента создается свой поток клиентское оборудование вынуждено обрабатывать весь поток каналов, который может быть совсем не несколько килобит абонент получает только тот поток, который запрашивает



Очевидно, что для вещания каналов наибольшее предпочтение отдается multicast.
Любой TV-канал, который мы хотим вещать в сеть, характеризуется адресом группы, который выбирается из диапазона, зарезервированного для этих целей: 224.0.0.0 – 239.255.255.255.

Для работы IPTV необходим роутер, поддерживающий multicast (далее MR). Он будет отслеживать членство того или иного клиента в определенной группе, т.е. постоянно следить какому клиенту какой отправлять TV-канал.

Для того чтобы клиент смог зарегистрироваться в одной из этих групп и смотреть TV-канал используется протокол IGMP (Internet Group Management Protocol).

Немного о том, как работает IGMP.


Есть сервер, который включен в роутер MR. Этот сервер вещает несколько TV-мультиков, например:

224.12.0.1 канал 1 News
224.12.0.2 канал 2 History
224.12.0.3 канал 3 Animals


Клиент включает канал News, тем самым, сам не подозревая, он отправляет запрос на MR для подключения к группе 224.12.0.1. С точки зрения протокола IGMP это запрос “JOIN 224.12.0.1”.

Если пользователь переключается на другой канал, то он сначала отправляет уведомление MR, что он отключает канал News или покидает эту группу. Для IGMP это “LEAVE 224.12.0.1”. А затем повторяет аналогичный запрос JOIN для нужного канала.

MR иногда спрашивает всех: “а какой группе кто подключен?”, чтобы отключать тех клиентов, с которыми оборвалась связь и они не успели отправить уведомление LEAVE. Для этого MR использует запрос QUERY.

Ответ абонента на этот запрос это MEMBERSHIP REPORT, который содержит список всех групп, в которых состоит клиент.

Настройка multicast routing.



Предположим, что клиенты одной группы смотрят один и тот же мультик, но находятся они в разных сегментах сети (network A и network B). Для того, чтобы они получили свой мультик и придуман multicast routing.

Пример настройки роутеров MR1 и MR2.

Network A 10.1.0.0/24
Network B 10.2.0.0/24
Network C 10.3.0.0/24



MR1 MR2
MR1#sh run

ip multicast-routing
!
interface Ethernet 0
description Multicast Source
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network A
ip address 10.1.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 2
description Network B
ip address 10.2.0.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 3
description Link to MR2
ip address 10.10.10.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.0.0.2 IPTV override
!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3
MR2#sh run

ip multicast-routing
!
interface Ethernet 0
description Link to MR1
ip address 10.10.10.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet 1
description Network C
ip address 10.3.0.1 255.255.255.0
ip pim sparse-mode
!
ip pim rp-address 10.0.0.2 IPTV override
!
ip access-list standard IPTV
permit 224.11.0.0 0.0.0.3
!
ip route 10.0.0.0 255.255.255.0 10.10.10.1

Команда "ip multicast-routing" включает соответствующий routing, если же он выключен, то роутер не пересылает multicast пакеты, т.е. они не дойдут до недоумевающего зрителя мультиков.

Остановимся чуть поподробнее на команде "ip pim sparse-mode".

Про режимы протокола PIM и сам протокол.


PIM (Protocol Independent Multicast) — протокол маршрутизации multicast рассылки. Он заполняет свою таблицу multicast маршрутизации на основе обычной таблицы маршрутизации. Эти таблицы можно просмотреть с помощью команд “sh ip mroute” и “sh ip route” соответственно. Целью протокола PIM является построение дерева маршрутов для рассылки multicast сообщений.


У протокола PIM существует два основных режима: разряженный (sparse mode) и плотный (dense mode). Таблица multicast маршрутизации для них выглядит немного по-разному. Иногда эти режимы рассматривают как отдельные протоколы — PIM-SM и PIM-DM.

В нашей конфигурации на интерфейсах мы указали режим "ip pim sparse-mode".



(config-if)# ip pim?

dense-mode Enable PIM dense-mode operation
sparse-dense-mode Enable PIM sparse-dense-mode operation
sparse-mode Enable PIM sparse-mode operation
………

В чем же разница?


PIM-DM использует механизм лавинной рассылки и отсечения (flood and prune). Другими словами. Роутер MR отправляет всем все multicast потоки, которые на нем зарегистрированы. Если клиенту не нужен какой-то из этих каналов, то он от него отказывается. Если все клиенты, висящие на роутере, отказались от канала, то роутер пересылает “спасибо, не надо” вышестоящему роутеру.

PIM-SM изначально не рассылает зарегистрированные на нем TV-каналы. Рассылка начнется только тогда, когда от клиента придет на нее запрос.

Т.е. в PIM-DM MR отправляет всем, а потом убирает ненужное, а в PIM-SM MR начинает вещание только по запросу.

Если члены группы разбросаны по множеству сегментов сети, что характерно для IPTV, PIM-DM будет использовать большую часть полосы пропускания. А это может привести к снижению производительности. В этом случае лучше использовать PIM-SM.

Между PIM-DM и PIM-SM существуют еще отличия.
PIM-DM строит дерево отдельно для каждого источника определенной multicast группы, т.е. multicast маршрут будет характеризоваться адресом источника и адресом группы. В multicast таблице маршрутизации будут записи вида (S,G), где S — source, G — group.



У PIM-SM есть некоторая особенность. Этому режиму необходима точка рандеву (RP — rendezvous point) на которой будут регистрироваться источники multicast потоков и создавать маршрут от источника S (себя) до группы G: (S,G).

Таким образом, трафик идет с источника до RP по маршруту (S,G), а далее до клиентов уже по общему для источников определенной группы дереву, которое характеризуется маршрутом (*,G) — "*" символизирует «любой источник». Т.е. источники зарегистрировались на RP, и далее клиенты уже получают поток с RP и для них не имеет значения, кто был первоначальным источником. Корнем этого общего дерева будет RP.



Точкой рандеву является один из multicast роутеров, но все остальные роутеры должны знать “кто здесь точка RP”, и иметь возможность до нее достучаться.

Пример статического определения RP (MR1). Объявим всем multicast роутерам, что точкой рандеву является 10.0.0.1 (MR1):

ip pim rp-address 10.0.0.1 IPTV override указываем адрес RP и access-list IPTV access-list определяет какие группы
ip access-list standard IPTV регистрироваться на данной точке рандеву
permit 224.11.0.0 0.0.0.3


Все остальные роутеры должны знать маршрут до RP:
ip route 10.0.0.0 255.255.255.0 10.10.10.1

Существуют так же и другие способы определения RP, это auto-RP и bootstarp router, но это уже тема для отдельной статьи (если кому-нибудь будет интересно – пожалуйста)?

Посмотрим, что будет происходить после настройки роутеров.


Мы по-прежнему рассматриваем схему с роутерами MR1 (RP) и MR2. Как только включаем линк между роутерами MR1 и MR2, то должны увидеть в логах сообщения

Для MR1:
%PIM-5-NBRCHG: neighbor 10.10.10.2 UP on interface Ethernet3

Для MR2:
%PIM-5-NBRCHG: neighbor 10.10.10.1 UP on interface Ethernet0

Это говорит о том, что роутеры установили отношение соседства по протоколу PIM друг с другом. Проверить это также можно с помощью команды:

MR1#sh ip pim neighbor

PIM Neighbor Table
Mode: B — Bidir Capable, DR — Designated Router, N — Default DR Priority, S — State Refresh Capable

Neighbor Address Interface Uptime/Expires Ver DR Prio/Mode
10.10.10.2 Ethernet3 00:03:05/00:01:37 v2 1 / DR S


Не забываем про TTL.


В качестве тестового сервера мне было удобно использовать плеер VLC. Однако, как позже обнаружилось, даже если выставить через GUI достаточный TTL, он все равно (надеюсь только в использованной мной версией) упорно отправлял multicast пакеты с TTL=1. Запускать упрямого пришлось с опцией «vlc.exe –ttl 3» т.к. у нас на пути будет два роутера, каждый из которых уменьшает TTL пакета на единицу.

Как же все таки обнаружить проблему с TTL? Один из способов. Пусть сервер вещает канал 224.12.0.3 с TTL=2, тогда на роутере MR1 пакеты проходят нормально, а за роутером MR2 клиенты уже не смогут смотреть свой мультик.

Обнаруживается это с помощью команды «sh ip traffic» на MR2. Смотрим на поле “bad hop count” – это число пакетов, которые “умерли”, как им и отмеряно, по TTL=0.

MR2#sh ip traffic

IP statistics:
Rcvd: 36788 total, 433 local destination
0 format errors, 0 checksum errors, 2363 bad hop count
……………………………………

Если этот счетчик быстро увеличивается, значит — проблема в TTL.

Show ip mroute


После включения вещания трех каналов на сервере в таблице multicast маршрутизации наблюдаем следующее:

MR1# sh ip mroute

(*, 224.12.0.1), 00:03:51/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.1), 00:03:52/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.2), 00:00:45/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.2), 00:00:45/00:02:50, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 224.12.0.3), 00:00:09/stopped, RP 10.0.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.0.0.2, 224.12.0.3), 00:00:09/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list: Null

Видим, что появились маршруты вида (S,G), например (10.0.0.2, 224.12.0.3), т.е. зарегистрировался источник 10.0.0.2, который вещает для группы 224.12.0.3. А так же маршруты с RP до клиента: (*,G), например (*, 224.12.0.3) – которые они будут использовать, так называемое общее для всех дерево.

Как только на интерфейс MR1 (RP) приходит запрос на получение канала 1, в multicast таблице маршрутизации происходят следующие изменения:

MR1#sh ip mroute

…………………
(*, 224.12.0.1), 00:33:16/00:02:54, RP 10.0.0.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

(10.0.0.2, 224.12.0.1), 00:33:17/00:03:25, flags: T
Incoming interface: Ethernet0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3, Forward/Sparse, 00:02:37/00:02:53

Стало видно, что приходят запросы на эту группу с порта Ethernet3.

RPF проверка


Возможна ситуация, когда роутер получает multicast поток на двух интерфейсах. Кого из этих двух интерфейсов роутер будет считать источником?

Для этого он выполняет проверку RPF (Reverse Path Forwarding) — проверяет по обычной unicast таблице маршрутизации маршрут до источника и выбирает тот интерфейс, через который идет маршрут до этого источника. Эта проверка необходима для того чтобы избежать образования петель.



Отследить, как источник проходит проверку RPF можно с помощью команды:

MR2#sh ip rpf ?
Hostname or A.B.C.D IP name or address of multicast source

MR2#sh ip rpf 10.0.0.2

RPF information for? (10.0.0.2)
RPF interface: Ethernet0
RPF neighbor:? (10.10.10.1)
RPF route/mask: 10.0.0.0/24
RPF type: unicast (static)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Ну, вот и появилась та статейка, которую я бы с удовольствием нашла, на начальном этапе изучения multicast routing’а для IPTV. Я не волшебник, я только учусь… Потому, с радостью выслушаю все пожелания, замечания и советы. А так же, очень надеюсь, что для кого-то она окажется полезной. =)

UPD: Разрешите представить ее. Елена Сахно — lena_sakhno

Дмитрий Вихарев @vikds
карма
215,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (51)

  • +1
    Спасибо. Интересная общеобразовательная статья.
  • +3
    Еще бы аналогичную инструкцию для обычного linux шлюза :)
  • +1
    Отличная статья, спасибо! Полезность пока чисто теоретическая, кладу в полезные закладки :)
  • 0
    Большое спасибо за ваши отзывы! =)
    Хочется еще поделиться своим опытом работы с сетями, но к сожалению пока публикуюсь от имени другого человека. За что ему огромнейшее спасибо! А задумка на следующую статью уже сгенерировалась, если кому-то будет интересно почитать про pppoe, dsl, загадочные параметры vpi/vci в dsl-модеме, буду только рада! =) Либо могу продолжить про технологию multicast vlan registration, или про anything касательно сетей =)
    • 0
      Было бы замечательно ;-) А то в эпоху развития безлимитного интернета как раз с использованием (в том числе) вышеуказанных технологий не все знают, что это такое
    • 0
      Думаю лучше с логической точки зрения закончить про multicast, а потом уже следующие технологии тронуть.

      Статья очень понравилась, надо будет эмулятор CISCO поставить, потыкать настройки.
    • +1
      отдаю голос за MPLS/MPLS-VPN)
      • +1
        С великим удовольствием напишу статью про MPLS-VPN, занималась им, но только, к сожалению совсем не несколько дней назад, надо освежить эту тему =) А это действительно очень интересная технология, которую осваивают провайдеры
  • +1
    Статья полезная, спасибо. На будущее: когда говорят росчерк пера, то имеют в виду подпись))
    • 0
      Спасибо большое! ценное замечание. «Держали в уме» пробу пера, а написали такой вот ляп =)
  • 0
    Freebsd+pf+mrouting не удаётся завести. Если pf заменить на ipfw, всё работает. Если у кого работает в связке с pf, напишите success story.
  • 0
    Спасибо за статью.
    Только единственное, что не понял зачем описывается вот этот акцесс лист?
    • 0
      Промазал… вот этот…

      ip access-list standard IPTV
      permit 224.11.0.0 0.0.0.3
      • 0
        С помощью данного access-list мы указываем какие группы будут регистрироваться на данной RP. Дело в том, что в сети может быть несколько RP, на которых будут регистрироваться другие группы, какие именно указывается опять же с помощью аналогичного access-list.
        • +1
          Я примерно так и подумал. Но у вас в примерах везде 224.12.0.0.
          Видимо просто опечатка?
          • 0
            Спасибо за Вашу наблюдательность! =) Очень приятно!

            Да. К сожалению, я немного ошиблась. =) Статью писала несколько дней, списывая настройки с тестовых конфигураций. Чуть-чуть «промазала». Действительно в config'е должно быть 224.12.0.0.
            • 0
              Всегда пожалуйста ;)
              Было бы еще интересно почитать нечто похожее по теме роутинга мультикаст внутри VRF. С использованием MDT и пр.
              • 0
                с VRF мне тоже очень интересно поразбираться (что сейчас и делаю) — как только будут результаты сообщу (статьей)! =)
  • 0
    Для полноты стоило бы добавить anycast тип трафика
    • 0
      Спасибо за поправку.
      Действительно, хорошо будет упомянуть про anycast.
      anycast в основном используется для таких сервисов как DNS, обеспечивая high availability и load-balancing. Т.е. когда от клиента поступает запрос, то первый «услышавший» его сервер отвечает. Лично для меня anycast больше ассоциируется с IPv6.
      • +1
        Я дополню. «услышавший» — в интернете это обычно ближашии по кол-ву хопов сервер.
  • 0
    А если поднять такое в домовых сетях(например у Корбины), то не получится ли такой неприятности, что мне на сутки порежут порты за мультикаст?
    • 0
      Обычно уважающие себя провайдеры блокируют вещание мультикаста, поступающего со стороны клиентских портов.
  • +1
    для адресации мультикаст-групп рекомендуется руководствоваться RFC3180(2770) — GLOP: tools.ietf.org/html/rfc3180
  • +1
    Отличная статья, спасибо!
  • 0
    Мб кто тут подскажет кто в Питере может предоставить услугу IPTV для провайдера. Уже голову сломал в поисках.
    • 0
      можешь здесь спросить: bcc.ru
    • 0
      oft-media.ru
  • 0
    Уважаемое сообщество, Извините за очень нескромную просьбу. Просто моя девушка тоже хотела бы быть частью сообщества Хабра и под своим именем публиковать статьи по сетям. В планах написать про:
    — регистрацию RP (чтобы немного автоматизировать)
    — multicast vlan registration
    — PPPoE DSL (чем почти мы все пользуемся)
    — параметры настройки домашних DSL-модемов
    — …
    — (что будет интересно)

    Если кому-нибудь интересно услышать про это, не найдется ли ни у кого небольшой файлик для того, чтобы поделиться опытом настройки ISP?

    Мы уже направили запрос на регистрацию IPS — это Дальневосточная «Новая Телфонная Компания», НТК. Являющаяся оператором сотовой связи и доступа в интернет (пока по DSL). Так же она там разбирается с WiFi. Есть о чем рассказать. =) Заранее благодарны. =)

    Если кому-нибудь интересно услышать про это, не найдется ли ни у кого небольшой файлик для того, чтобы поделиться опытом настройи ISP?

    Мы уже направили запрос на регистрацию IPS — это Дальневосточная «Новая Телфонная Компания», НТК. Являющаяся оператором сотовой связи и доступа в интернет (пока по DSL). Так же она там настраивает WiFi. Есть о чем рассказать. =) Заранее премного благодарны (да помилуют нас боги). =)
    • 0
      Извините… у нас уже 2 часа ночи. Целый день сидели возле Хабры для того, чтобы оперативно отвечать на комментарии… =)
      • +1
        Могу дать инвайт за такую монументальную работу. Если нужен, присылайте email автора ;)
        • 0
          Чрезмерно благодарны за отзывчивость! Спасибо! =))
          Будет продолжение в блоге CISCO очень постараемся!

          Спасибо за инвайт!
  • 0
    Спасибо огромное Хабра-сообществу за отзывы!
    И отдельное спасибо boh за приглашение.

    Автор данной статьи — теперь с нами! Разрешите представить ее.
    Елена Сахно — lena_sakhno
  • +1
    Спасибо всем огромное за поддержку и добрый прием! =)
    • +1
      Отличная статья, спасибо.
  • +1
    Очень интересно! Я бы еще почитал про vpi vci
  • 0
    Видимо уже надо собирать все интересующие темы вместе. Затем, каждому взять себе по теме, которую он хорошо знает.
    После чего все пишем статьи =)
  • +1
    Статья хорошая, мне понравилась :)

    Всякие мелкие помарки не считаем — сведено воедино всё грамотно. Правда, чтобы это легко читалось надо уже половину знать :) Но те, кто уже поковырялся, как раз половину и знают :)

    ЗЫ sparce — разрЕженный, как воздух, а не как ружьё :))
    • 0
      Действительно! =) Правильнее разрЕженный. Спасибо! =)
  • 0
    Кстати, возник вопрос.
    Как я понял строчкой
    ip pim rp-address 10.0.0.2 IPTV override
    мы указываем на адрес ПК, с которого идет вещание.
    А можно не указывать? Что делать когда например IP это компа не известен или его попросту нет? (Есть оборудование которое вещает просто на порт и все, не имея традиционного IP).
    • 0
      Можно.

      Мультикастовый трафик от сервера вещания придёт на рутер и он станет RP, т.к. будет знать, кто (конкретный адрес) шлёт тот или иной поток. А дальше эту ценную инфу он передаст тем, кто обращается к нему, как к RP
      • 0
        Подскажите, пожалуйста, мне неграмотному, на вот этот IP/TV сервер CISCO вещать с компьютера можно по средствам VLC?
        • 0
          Да, в качестве сервера, вещающего мультикаст можно использовать VLC. В настройках надо указать адрес группы (мультикаст адрес) и порт, через который будет происходить вещание.
          • 0
            интересно, а как можно организовать что то вроде биллинга? например для отдельного юзера разрешить \ запретить отдельные каналы.
            И смотреть количество смотрящих ТВ.
  • 0
    а можно такое же на 501 пиксе с ios 6.03?
    • 0
      нет, на пиксе это сделать не получится, там и с обычным роутингом туго, на сколько я помню, а с мультикастом и подавно
  • 0
    Нехватало только ещё описания динамических механизмов выбора RP, таких как auto-rp и bootstrap.

  • 0
    За упоминание о TTL отдельное спасибо!
    Никак не мог разобраться, почему конкретный мультикаст не проходит через роутер, решил разобраться с sparse, sparse-dense, dense и passive, открыл вашу статью — и дело конечно было в TTL :)
  • 0
    Молодец, добавить еще можно мод: sparse-dense-mode — использующий shared tree(*,G) для тех кто знает о RP, и source-tree или(shortest-path tree) -> (S,G) для тех кто RP не нашел. Как правило используется на цисках на пару с auto-RP или BSR. Ну а если вообще современным)) то помоему сейчас все сидят на SSM и IGMPv3 и не забивают себе голову разными модами.

  • 0
    Я бы дополнил статью тем фактом, что в режиме PIM-sparse общее дерево, корнем которого является точка рандеву, используется только в начале мультикастовой рассылки. Как только скорость мультикастового потока превышает параметр, заданный командой ip pim spt-threshold kbps, роутер, к которому подключены конечные получатели, переходит на source-tree, т.е. на дерево, построенное напрямую от источника и которое может гнать трафик мимо точки рандеву. Если в этом случае произойдёт отключение точки рандеву, мультикастовый поток не будет прерван, маршрут (S,G) остаётся активен. Если в команде ip pim spt-threshold указать нулевое значение, то переключение на STP будет выполнено сразу же. Если указать значение infinity, то всегда, независимо от скорости потока, будет использоваться общее дерево (*,G). Что интересно, в режиме sparse-dense данная команда не работает, всегда строится дерево до источника (SPT).
  • 0
    Добрый день!
    Про TTl — абсурд в разряде охоты на ведьм.
    Посмотрите в суть происходящего!
    Мультикаст идет с TTL =1 по определению, т.к. мультикаст на подсеть 224.0.0.0/24 всегда локальные — в рамках широковещательного домена.
    Данный трафик и не должен переходить через маршрутизаторы.
    А в чем смысл PIM, в таком случае, если бы трафик проходил через маршрутизаторы?

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