Рассмотрим простейшую схему:



есть маршрутизатор cisco, за одним интерфейсом расположен компьютер с программой, принимающей потоковую передачу (например, VLC Player), за другим - передающая станция, вещающая поток (например, видео) на некоторый мультикастовый адрес.

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

Задача1: можно ли заставить компьютер принять поток, не прибегая к мультикастовой машрутизации?
Задача2: можно ли заставить принять поток с условием, что вы вообще не знаете, что такое мультикаст, как работает и как настраивается?

Дать доступ на порт с пометкой any?

На маршрутизаторе и так всё пропущено. Никаких ACL нет.

1. Может вбить в сетевуху MAC=01-00-5E+(23 нижних бита мультикаст-IP-адреса) ?

2. А может применить destination NAT трансляцию ?

ip nat pool POOL1 10.1.1.100 10.1.1.100 prefix-length 8
access-list 1 permit host <multicast-IP-address>
ip nat inside destination list 1 pool POOL1

День добрый!
А не будет решением задачи бриджинг?

hostname R1
bridge 1 protocol ieee
no bridge irb

int fa 0/0
no ip address
bridge-group 1
no shutdown

int fa 0/1
no ip address
bridge-group 1
no shutdown

2. ip nat inside source static 10.1.1.100 <multicast-IP-address>

пакеты проходят

2 LAG: Бриджинг - интересная мысль. Думаю, что пробросить пакет будет можно. Но по условиям задачи там всё же маршрутизатор. Т.е. от L3 отказываться нельзя . Я выдрал задачу из контекста, поэтому получилось не точно, наверно.

2 mechanical: а больше на маршрутизаторе ничего не прописывать?

2 Fedia:

int fa0/0
ip address 192.168.1.1 255.255.255.0
no shutdown
ip nat outside

int fa0/1
ip address 10.1.1.1 255.0.0.0
no shutdown
ip nat inside

ip nat inside source static 10.1.1.100 <multicast-IP-address>

в принципе этого хватит чтоб пакеты начали бегать на клиента

хотя это будет работать только если на сервере прописан шлюз 192.168.1.1
в ином случае сервер будет слать фреймы с MAC-destination=01-00-05-..... и fa0/0 их убьет
проблема : как заставить fa0/0 принимать мультикастовые фреймы ...

Да, мысль абсолютно верная. Это и есть та засада, о которой я говорил.

В НАТе ошибок нет. Именно его и предлагалось догадаться использовать

Т.е. я правильно Вас понял, что обойти эту засаду в рамках условий задачи невозможно?
И кстати, какую задачу решает статик-НАТ? 1-ую или 2-ую? Потому что лично я не вижу разницы в задачах.

НАТ используется как составная часть при решении обеих задачек.

Разница там в том, что засаду можно обойти двумя способами: зная, как работает мультикаст (и некоторые команды настройки) и не зная этого вовсе, т.е. зная лишь отрывочные данные уровня CCNA.

ip igmp static-group <multicast-address> ?

Отлично!
Да, вкупе с предложенным mechanical НАТом это будет решением первой задачи. Здорово!

А вторую? Она имеет решение, но довольно неочевидное )

кусок конфига

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat outside
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.1.1.1 255.0.0.0
ip nat outside
duplex auto
speed auto
!
router rip
version 2
network 192.168.1.0
!
!
ip nat inside source static 10.1.1.100 224.0.0.9

Вообще ip nat outside на fa0/1 не нужен, но благодаря именно этой опечатке, метод заработал. Причем с ip nat inside на fa0/1 способ работать не хочет
поэтому правильный конфиг такой:

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat outside
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.1.1.1 255.0.0.0
duplex auto
speed auto
!
router rip
version 2
network 192.168.1.0
!
!
ip nat inside source static 10.1.1.100 224.0.0.9
!

Вынужден признать вашу полную и безоговорочную победу!

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

Вот только мне всё таки кажется, что указание на внутреннем Eth ip nat inside обязательно: циска не создает трансляций между парой интерфейсов, если они не помечены ip nat inside и ip nat outside

У меня во время тестирования заработала именно такая схема.

Да, схема с инсайдом работает. Только есть одна проблема, которая в этой задаче не принципиальна.

В случает статического ната ip nat outside указывает тот интерфейс, над входящими пакетами которого будет проведена трансляция поля IPdest = 224.0.0.9 -> 10.1.1.100. При чем, как показал эксперимент, не важно какой интерфейс будет в этот момент инсайдом, трансляция входящих пакетов от этого не зависит никак.

ip nat inside указывает тот интерфейс, над входящими пакетами которого будет проведена трансляция
IPsrc = 10.1.1.100 -> 224.0.0.9
но в этом случае на выходе получается пакеты с мультикастовым источником, что не есть хорошо. Конкретно это приводит отбрасыванию сервером пинг-эха возвращенного от клиента.

если ip nat inside убрать, то трансляции IPsrc не происходит, пакеты выходят наружу с нормальным IPsrc = 10.1.1.100

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

В продолжение темы есть реальная задачка из жизни :)

Имеем Интрентет+ТВ от Стрим(ADSL), циску 877, один PC + декодер для телевидения (ethernet). Схема простая:

интернет/iptv
|
|
(adsl)
cisco 877(eth) -- (eth)Decoder -- TV
(eth)
|
|-> PC (VLC)

Задача: Иметь возможность смотреть телевидение на PC из VLC (сохраняя доступ в интернет) и на декодере, одновременно.

Методом научнного тыка было сделано следующее:

ip multicast-routing
no ip igmp snooping vlan 2 - снупинг в влане с декодером-приставкой со временем убивает вещание :-(
!
bridge irb
!
interface ATM0
no ip address
no atm ilmi-keepalive
dsl operating-mode auto
!
interface ATM0.150 point-to-point
bandwidth 6144
no snmp trap link-status
pvc 1/50
pppoe-client dial-pool-number 1
!
!
Далее следуют интерфейсы VOD/MCAST, можно объединить в multipoint.
!
interface ATM0.191 point-to-point
no snmp trap link-status
pvc 1/91
encapsulation aal5snap
!
bridge-group 2
!
interface ATM0.192 point-to-point
no snmp trap link-status
pvc 1/92
encapsulation aal5snap
!
bridge-group 2
!
На 0-ом порту сидит декодер(приставка)
!
interface FastEthernet0
switchport access vlan 2
no keepalive
spanning-tree portfast
!
interface FastEthernet1
spanning-tree portfast
!
interface FastEthernet2
spanning-tree portfast
!
interface FastEthernet3
spanning-tree portfast
!
interface Vlan1
ip address 192.168.0.1 255.255.255.0
ip pim sparse-dense-mode - режим работы мульткаст роутинга
ip nat inside
ip virtual-reassembly
ip igmp helper-address 43.31.0.1 - igmp запросы бросаем на iptv-шлюз стрима
!
interface Vlan2
no ip address
bridge-group 2
bridge-group 2 spanning-disabled
!
interface Dialer0
ip address negotiated
ip mtu 1452
ip nat outside
ip virtual-reassembly
encapsulation ppp
ip tcp adjust-mss 1452
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap pap callin
ppp chap hostname ***@mtu
ppp chap password 7 1***
ppp pap sent-username ***@mtu password 7 ***
!
interface BVI2
ip address dhcp client-id FastEthernet0 - получаем лишний адрес из iptv-dhcp пула провайдера
ip pim sparse-dense-mode
!
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip mroute 0.0.0.0 0.0.0.0 43.31.0.1 - мультикаст трафик направляем опять же на iptv-шлюз провайдера
ip nat inside source list 100 interface Dialer0 overload
!
access-list 100 deny ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 100 permit ip 192.168.0.0 0.0.0.255 any
dialer-list 1 protocol ip permit
!
bridge 2 protocol ieee
bridge 2 route ip
!

Проблема: как видно, приходится забирать из iptv-dhcp пула провайдера 2 адреса, что не есть гуд, ибо за декодерами и их мак-адресами суппорт вроде как послеживает. Тем более, используя vlc, как выяснилось, открываются некоторые э...скрытые, скажем так, возможности :)

Что пытался сделать:

Сделал еще один vlan, настроенный по аналогии с vlan 1, в него засунул уже локальный dhcp пул исключительно для приставки-декодера, на бриджевый интерфейс bvi2 назначил nat outside, сделал еще одно правило для NAT-а уже с учетом адресации нового vlan. В итоге: с адресов нового vlan пингуем iptv-шлюз, приставка-декодер получает адрес из локального пула, однако сервер iptv она (как утверждает) найти не может. Это помимо того, что интерфейс bvi2 теперь своим dhcp client-id косит под декодер :)

Сильно прошу не ругать, с мультикастом сталкиваюсь впервые, по работе занимаюсь в основном voip :)

Хм, забавно!

Не очень понятно только, зачем мульткастовый 0/0 маршрут прописан: там вроде как мультикаст только ОТ сервера идёт, а igmp пробрасывается хелпером.