[kriks]

Кусок статистики

krik@junos.gw> show pim statistics

 

PIM Message type Received Sent Rx errors

V2 Hello 0 6 0

V2 Register 0 0 0

V2 Register Stop 0 0 0

V2 Join Prune 0 0 0

V2 Bootstrap 0 0 0

V2 Assert 0 0 0

V2 Graft 0 0 0

V2 Graft Ack 0 0 0

V2 Candidate RP 0 0 0

V1 Query 0 0 0

V1 Register 0 0 0

V1 Register Stop 0 0 0

V1 Join Prune 0 0 0

V1 RP Reachability 0 0 0

V1 Assert 0 0 0

Для пробы взял порт fe-0/0/2, на него кинул vlan.4 в него воткнулся компом, получил айпи 10.66.101.164, при включенном PIMе изобрадение не идет, как только тушу просто ПИМ, начинает все работать.

Что делать, куда дальше рыть?

[agr]

 

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

 

 

Нет, не достаточно. По-умолчанию PIM встанет в спарс-мод и без нужного upstream state ничего форвардить не будет.

А нужного upstream state там не будет, потому что нет соседства.

 

Зачем включать пим на интерфейсе в сторону получателя?

 

На источнике, чтобы входящие мультикаст пакеты попадали в кеш,

 

 

Какой кеш?

 

Мультикаст кэш. Когда на интерфейсе прописан pim, то если на него приходит поток определенной интенсивности, то он попадает в специальный мультикаст кэш. Его можно посмотреть в show route table inet.1. Из этого мультикаст кэша пакеты и пойдут получателю, если он подпишется на группу. Поэтому роутеру не обязательно устанавливать pim соседство с источником, достаточно, что поток просто будет литься на pim интерфейс. Не каждый же источник мультикаста поддерживает pim протокол в конце концов!

 

На интерфейсе получателе включать pim имеет смысл, если к порту подключен не непосредственно сам получатель, а есть еще например промежуточный свич аля cisco с поддержкой igmp snooping. В случае если во влане ходят pim hello, то cisco для себя определит интерфейс с которого они приходят как quirer.

 

 

krik@junos.gw> show multicast usage

 

krik@junos.gw>

 

плохо. А show route table inet.1 ?

 

И еще уточнить хочу, ваш источник точно льет поток постоянно или он только по igmp запросам это делает? Я так понял из изначальной задачи, что постоянно.

 

Завтра если будет время на тестовом srx'е ваш конфиг опробую.

[kriks]

krik@junos.gw> show route table inet.1

 

krik@junos.gw>

 

Щас посмотрел на провайдерской железке, поток идет по IGMP запросам.

 

Завтра если будет время на тестовом srx'е ваш конфиг опробую.

Ок, буду благодарен.

P.S Я как-то больше по Д-линкам :) Но Джиниперы гораздо интересней Длинков.

[Tima]

krik@junos.gw> show pim statistics

 

PIM Message type Received Sent Rx errors

V2 Hello 0 6 0

 

Вот и я о том же. Hello отправляем, а в ответ не получаем.

[Tima]

Мультикаст кэш. Когда на интерфейсе прописан pim, то если на него приходит поток определенной интенсивности, то он попадает в специальный мультикаст кэш. Его можно посмотреть в show route table inet.1. Из этого мультикаст кэша пакеты и пойдут получателю, если он подпишется на группу.

 

 

А вот вы о чем.

На самом деле это не кэш, а forwarding table. Это то же самое, что и sh multicast route. В случае mvpn там будут также и метки.

Записи там появляются после успешной RPF проверки. Подозреваю термин cache в документации из-за того, что таблица наполняется динамически в процессе появления источников мультикаста.

 

 

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

 

 

Вероятно, не каждый. Но если источник не поддерживает PIM, он не сможет в sparse сети зарегистрироваться на RP. А Dense сети уже никто не строит. Придется его прятать за чем-то что умеет PIM.

 

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

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

Я бы еще попробовал настроить интерфейс наверх в sparse-dense режиме и прописать dense-group

 

 

На интерфейсе получателе включать pim имеет смысл, если к порту подключен не непосредственно сам получатель, а есть еще например промежуточный свич аля cisco с поддержкой igmp snooping. В случае если во влане ходят pim hello, то cisco для себя определит интерфейс с которого они приходят как quirer.

 

Для того чтобы интерфейс стал querier, с него должны прилетать соответственно IGMP query, pim для этого не нужен.

Вообще, настройка PIM в сторону получателей выглядит для меня как дыра. Найдется хомяк, который попытается поднять pim и налить что-нибудь.

[agr]

krik@junos.gw> show route table inet.1

 

krik@junos.gw>

 

Щас посмотрел на провайдерской железке, поток идет по IGMP запросам.

 

 

Ну тогда все понятно, извиняюсь, ошибся в исходных данных. Тогда надо как писал Tima поднимать pim соседство с источником. А что из себя представляет источник?

 

Для того чтобы интерфейс стал querier, с него должны прилетать соответственно IGMP query, pim для этого не нужен.

Вообще, настройка PIM в сторону получателей выглядит для меня как дыра. Найдется хомяк, который попытается поднять pim и налить что-нибудь.

Тьфу ты черт, я запутался совсем в определениях: PIM нужен не для определения querier интерфейса, а для mrouter интерфейса.

У меня раньше мультикаст на аксессе через MVR отдавалася. В этом случае в клиентские вланы PIM не сможет просочиться.

[Andrey Shepelev]

Извиеняюсь, не пробиваются.

 

уважаемый вы меня нагло обманули "joke"

 

вот конфиг с срх:

lab@host1-a# show | compare 
[edit protocols]
+   igmp-snooping {
+       vlan mv0 {
+           proxy {
+               source-address 10.0.0.1;
+           }
+           data-forwarding {
+               receiver {
+                   install;
+               }
+           }
+       }
+       vlan v2 {
+           data-forwarding {
+               receiver {
+                   source-vlans mv0;
+               }
+           }
+       }
+   }

[edit]
lab@host1-a# 

 

ну и соответственно настраиваем там ваши влан как вам надо и наслаждаемся и не изобретаем велосипедов с PiM и прочим )))

[kriks]

Извиеняюсь, не пробиваются.

 

уважаемый вы меня нагло обманули "joke"

 

вот конфиг с срх:

lab@host1-a# show | compare 
[edit protocols]
+   igmp-snooping {
+       vlan mv0 {
+           proxy {
+               source-address 10.0.0.1;
+           }
+           data-forwarding {
+               receiver {
+                   install;
+               }
+           }
+       }
+       vlan v2 {
+           data-forwarding {
+               receiver {
+                   source-vlans mv0;
+               }
+           }
+       }
+   }

[edit]
lab@host1-a# 

 

ну и соответственно настраиваем там ваши влан как вам надо и наслаждаемся и не изобретаем велосипедов с PiM и прочим )))

Спасибо. на SRX 210 все гуд, а вот на SRX 100 команды

igmp-snooping

нет. И на этом спасибо. буду местами менять железки :)

[Andrey Shepelev]

The IgMP snooping and Q-in-Q feature is not available for the SrX100

 

ну ладно хорошо ) srx100 видимо совсем простенькая коробочка. обидно досадно. ну ладно )

[uralservis]

Добрый день.

Столкнулся с необходимостью настройки igmp proxy для работы iptv от провайдера.

Подскажите пожалуйста, что обозначает в приведенном выше конфиге следующее:

-для какого именно интерфейса мы настраиваем proxy

-что обозначает source-address 10.0.0.1

 

Заранее благодарю за помощь