UA.PON v3.0

[argus78 114]

Вопрос, сплиттеры (планарные, сварные) идут уже оконеченные SC? если да, то затухание на сплиттер указано уже с учетом коннектора? И почему где-то проскакивала рекомендация стараться не использовать сварные сплиттеры, якобы у них больше, и не  всегда предсказуемое затухание, хотя судя по таблице делитель 1х2 - затухание 4,3, делитель 50/50 - затухание 3,17?

[wladd 382]

Данные с таблицу забивались из расчета затухания без учета коннекторов.

Специально привожу сканы паспортов. В паспортах тоже данные измерений без коннекторов.

Можно сказать что Данные по затуханиям PLC чуть  завышенные, но тем не менее, факт в том,

что действительно сварные сплиттеры имеют меньшие затухания.

 

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

- сварной сплиттер только 1х2 является компактным, любой большего номинала деления, будет выглядеть как

среднего размера пластиковая коробка.

- статистически сплитеры 1х2 используются редко, могу подтвердить это на основе статистики продаж

(все и FBT и PLC) Они просто не нужны в схемах 8х8, 4х16, 4х4х4 итд, итп.

[forerunner 84]

А подскажите, пожалуйста, уважаемые ПОНоводы, пропустит ли прозрачно мультикаст связка olt-onu, в схеме mrouter - olt - onu - client?

Изменено 2013-02-15 17:38:03 пользователем forerunner

[Den_LocalNet 1 474]

А подскажите, пожалуйста, уважаемые ПОНоводы, пропустит ли прозрачно мультикаст связка olt-onu, в схеме mrouter - olt - onu - client?

прозрачно работать не будет

вернее будет точно так же как mrouter - мыльница - client

[forerunner 84]

 

А подскажите, пожалуйста, уважаемые ПОНоводы, пропустит ли прозрачно мультикаст связка olt-onu, в схеме mrouter - olt - onu - client?

прозрачно работать не будет

вернее будет точно так же как mrouter - мыльница - client

Как-то эти два утверждения противоречат друг другу :\

 

Мыльница мультикаст пропустит запросто. А olt-onu?

Изменено 2013-02-15 21:12:46 пользователем forerunner

[Гайджин 574]

А подскажите, пожалуйста, уважаемые ПОНоводы, пропустит ли прозрачно мультикаст связка olt-onu, в схеме mrouter - olt - onu - client?

прозрачно работать не будет

вернее будет точно так же как mrouter - мыльница - client

Не будет оно так работать. - это первое что я проверял. ОЛТ igmp join-ы срезает, если не настраивать его MVR.

[forerunner 84]

 

 

А подскажите, пожалуйста, уважаемые ПОНоводы, пропустит ли прозрачно мультикаст связка olt-onu, в схеме mrouter - olt - onu - client?

прозрачно работать не будет

вернее будет точно так же как mrouter - мыльница - client

 

Не будет оно так работать. - это первое что я проверял. ОЛТ igmp join-ы срезает, если не настраивать его MVR.

Спасибо за ответ. Пусть и не очень радостный .. А точно olt срезает? Слышал, что разные onu на одном и том же olt'e ведут себя по разному с мультикастом.

[Гайджин 574]

Фу Бл#... Вот что склероз проклятый с людьми делает после литры вискаря на троих.

 

Вспомнил я наконец что за грабли были. Это были мои первые эксперименты с этим железом. Я просто подключил ОНУ к дереву, при этом ОЛТ был с дефолтным конфигом, и попытался подписаться на группу. Подписка прошла удачно - т.е. join прошел и поток полился. Однако по прошествию 6 секунд произошел обрыв потока. Еще через пару секунд STB снова переподписалась и через 6 секунд снова срыв. И так по кругу.

 

Я сначала не понял в чем дело и полез на вышестоящий от ОЛТа ДЛинк и обнаружил что поток действительно штатно завершается на нем каждуе 6 секунд. Тут уже стало понятно, что 6 секунд это 2 интервала квери. (Да, у нас квери интервал 3 секунды - так надо). Осталось только проверить предположение.

 

На тот момент я не использовал функционал миррора портов ОЛТа (который, кстати как потом оказалось, несколько глючит именно с этим типом трафика - я тут уже писал про это (поищите в моих постах в этой теме)), поэтому я взял "тупой" свич и поставил его выше ОЛТа и воткнул в него порт хоста с tcpdump-ом.

Мультикастный трафик в "тупом" свиче разливается по всем портам, по этому я видел весь процесс подписки и трансляции. Раз в три секунды я наблюдал квери идущие от квериера, но вот ответов от STBшки на эти квери не было - именно поэтому вышестоящий ДЛинк и считал, что тут все умерли и прекращал трансляцию потока.

После этого я перенес "тупого"свича ниже - т.е. воткнул его между портом ОНУ и STB. Подключил к нему хост со снифером и обнаружил, что тех самых квери от квериера нет. Соответсвенно STBшке как бы не начно отвечать, а раз она не продляет подписку, то ДЛинк абсолютно штатно тушит поток.

 

Из всего выше сказанного следует только одна - нужно проверять кто резал квери. Ибо варианта два - если их нет на epon-порту, значит режет ОЛТ. Если же они там есть - Значит ОНУ. Только вот беда в том, что глюкик функционалла миррора портов как раз и располагаются в данной плоскости и по сути своим глазам и снифферу в данном случае верить нельзя.

 

 

P.s. мне одно не понятно, зачем Вам мультикаст в пользовательском влане? Почему не mvr? То что китайцы называют mvr-ом реально работает и работает достаточно стабильно.

Изменено 2013-02-16 07:08:51 пользователем Гайджин

[forerunner 84]

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

А все эти мысли появились после информации, что с одним и тем же конфигом ону 1004 работает с мультикастом нормально, а, например, 1504, прочие китайские модели  - нет. Что ставит в зависимость от наличия одной единственной модели ону на рынке.

[sadmin 7]

Добавлю: когда с китайцами решали проблемы по мультикасту, то они давали команды включения дебага для мультикаста чтобы я их ввел на ОЛТ и помониторил что происходит: тогда видны все мультикаст запросы и ответы.

Так что включайте и дебажьте на голове!

Изменено 2013-02-16 09:50:40 пользователем sadmin

[forerunner 84]

Добавлю: когда с китайцами решали проблемы по мультикасту, то они давали команды включения дебага для мультикаста чтобы я их ввел на ОЛТ и помониторил что происходит: тогда видны все мультикаст запросы и ответы.

Так что включайте и дебажьте на голове!

 

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

 

Что смутило:

 

- почему мультикаст влан должен быть switchport pvid??? Ведь нэтив влан в транке ходит нетэгированым...

 

- в свете первого пункта хождение мультикаста с командой switchport trunk vlan-untagged none также вызывает удивление.

 

- ip mcst mc-vlan 100 range 239.10.10.1 - 239.10.10.100 - как olt определяет из какого именно влана брать эти группы и тулить во влан 100 ?? Ведь нигде не указан mvr vlan (что будет если из нескольких вланов придут потоки с одинаковыми адресами?)

Изменено 2013-02-16 10:06:04 пользователем forerunner

[Гайджин 574]

Добавлю: когда с китайцами решали проблемы по мультикасту, то они давали команды включения дебага для мультикаста чтобы я их ввел на ОЛТ и помониторил что происходит: тогда видны все мультикаст запросы и ответы.

Так что включайте и дебажьте на голове!

Ну так было бы не плохо если бы Вы их озвучили.

[Гайджин 574]

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

А все эти мысли появились после информации, что с одним и тем же конфигом ону 1004 работает с мультикастом нормально, а, например, 1504, прочие китайские модели  - нет. Что ставит в зависимость от наличия одной единственной модели ону на рынке.

Более подробно об этой информации можно? - ибо я про это не слышал.

[FonOdinus 92]

Панове, можно ли увидеть примеры монтажа? Уже который раз интересуюсь.

[kha0s 112]

Всё есть в теме. Этой и предыдущей.

[Den_LocalNet 1 474]

 что с одним и тем же конфигом ону 1004 работает с мультикастом нормально, а, например, 1504, прочие китайские модели  - нет.

 

Кто сказал 1504 нет? кто сказал прочие китайские модели нет?

[forerunner 84]

 

 что с одним и тем же конфигом ону 1004 работает с мультикастом нормально, а, например, 1504, прочие китайские модели  - нет.

 

Кто сказал 1504 нет? кто сказал прочие китайские модели нет?

 

Человек, который тестировал. У Вас есть обратная информация? Конфиг тот же использовали? Был бы благодарен, если бы обнародовали.

[forerunner 84]

 

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

А все эти мысли появились после информации, что с одним и тем же конфигом ону 1004 работает с мультикастом нормально, а, например, 1504, прочие китайские модели  - нет. Что ставит в зависимость от наличия одной единственной модели ону на рынке.

Более подробно об этой информации можно? - ибо я про это не слышал.

Пока тестировалось на скорую руку, с конфигом аналогичным распространенному в этой теме. Конфига под рукой сейчас нет, если надо - укажу позже. Результат прост: на 1004 завелось, на нескольких гиговых моделях, включая 1504 - нет. Поэтому и стал смотреть в сторону прозрачного пропускания мультикаста.

[Гайджин 574]

 

Более подробно об этой информации можно? - ибо я про это не слышал.

Пока тестировалось на скорую руку, с конфигом аналогичным распространенному в этой теме. Конфига под рукой сейчас нет, если надо - укажу позже. Результат прост: на 1004 завелось, на нескольких гиговых моделях, включая 1504 - нет. Поэтому и стал смотреть в сторону прозрачного пропускания мультикаста.

У меня в руках побывали BDCom 1004b, HG-300 Feixun, PHICOM HG-304, с ними я видел всякое, но вот мультикаст (то что они называют mvr-ом) работал нормально, со следующим конфигом:

!
interface EPON0/1
 epon bind-onu mac fcfa.f796.174e 1
 switchport trunk vlan-allowed 487,1008-1009
 switchport trunk vlan-untagged none
 switchport mode trunk
 switchport protected
!
interface EPON0/1:1
 onu-configuration
 epon sla upstream pir 1000000 cir 15000
 epon sla downstream pir 1000000 cir 15000
  epon onu port 1 ctc vlan mode tag 1009
  epon onu port 2 ctc vlan mode tag 1009
  epon onu port 3 ctc vlan mode tag 1009
  epon onu port 4 ctc vlan mode tag 1009
  no epon onu spanning-tree
  epon onu port 1 loopback detect
  epon onu port 1 storm-control mode 1 threshold 256
  epon onu port 2 loopback detect
  epon onu port 2 storm-control mode 1 threshold 256
  epon onu port 3 loopback detect
  epon onu port 3 storm-control mode 1 threshold 256
  epon onu port 4 loopback detect
  epon onu port 4 storm-control mode 1 threshold 256
  epon onu port 1 ctc mcst tag-stripe enable
  epon onu port 1 ctc mcst mc-vlan add 487
  epon onu port 2 ctc mcst tag-stripe enable
  epon onu port 2 ctc mcst mc-vlan add 487
  epon onu port 3 ctc mcst tag-stripe enable
  epon onu port 3 ctc mcst mc-vlan add 487
  epon onu port 4 ctc mcst tag-stripe enable
  epon onu port 4 ctc mcst mc-vlan add 487
!!onu-configuration-end
!
!
vlan 410
 name mgmt
!
vlan 487
 name iptv
!
vlan 1008
 name mikh50
!
vlan 1009
 name ryaz100
!
vlan 1,410,487,1008-1009
!
ip mcst enable
ip mcst mc-vlan 487 range 239.1.0.0 - 239.1.0.255
!

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

[forerunner 84]

На первый взгляд все то же самое. Завтра подброшу точный кофиг и описание.

 

ПС прошивку использовали Version 10.1.0B Build 9545?

[Den_LocalNet 1 474]

 Build 9545?

да

[Кузьменко. 15]

а хтось тестив, скільки МБіт пропускає один пон порт? бо ГБіт Гбітом, ВіФі 300 МБітний пропускає тільки МБіт 40

 

якщо зі всіх портів качати по максимуму, якої швидкості можна добитись і що каже пінг?

[Гайджин 574]

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

Ну тут вы  не одиноки - у меня тоже такое впечатление сложилось. Т.е. в настоящий момент никто из нас толком не знает как работает этот пара-mvr.

Что смутило:

- почему мультикаст влан должен быть switchport pvid??? Ведь нэтив влан в транке ходит нетэгированым...

 При таком конфиге:

interface GigaEthernet0/1
 switchport trunk vlan-allowed 410,487,1008-1009
 switchport trunk vlan-untagged none
 switchport mode trunk
 switchport pvid 487 

Igmp join пакеты будут выходить из порта GigaEthernet0/1 в тегированном виде, с тегом 487.

 

Прикол заключается в том, что смысл команд выделеных жирным команд несколько отличается от того к чему мы все привыкли. - Если их убрать, то igmp join пакеты будут выходить из интерфейса в нетегированном виде, что бы Вы там еще в конфиге не писали. Команда switchport trunk vlan-untagged none говорит о том, что все пакеты выходящие из порта будут тегированными и после ее исполнения igmp join пакеты будут выходить из интерфейса в тегированном виде с тегом 1. И вот только команда switchport pvid 487 меняет тег 1 на тег 478. Т.е. создается впечатление что действует какая то извращенная логика - команда воздействует не на входящие пакеты, а на изходящие.

При этом, однако, хотелось бы обратить внимание на то, что данный функционал должен исполняться на ОЛТе (по логике вещей), так что врядли это может повлиять на неработоспособность пара-mvr на разных типах ОНУ.

- ip mcst mc-vlan 100 range 239.10.10.1 - 239.10.10.100 - как olt определяет из какого именно влана брать эти группы и тулить во влан 100?? Ведь нигде не указан mvr vlan (что будет если из нескольких вланов

придут потоки с одинаковыми адресами?)

 

Ну насколько я тут понял, означает какой влан тег пришивать к идущему от клинета igmp join пакету - т.е. в какой влан его направлять. Соответвенно в какой влан igmp join ушол из такого должно и вернуться.

Вот только какой бы мы тут mc-vlan не определяли, ОЛТ по дефолту передает igmp join в GigaEthernet0/1 в не тегированном виде (что на мой взгляд является багом), и только манипуляции описанные выше позволяют их тегировать тем тегом которым мы хотим. Вот и получается что mc-vlan может быть любым вланом описынным на ОЛТе и на базе этой баго-фичи народ реализует нечто напоминающее мультикаст фильтрацию, вместо того что бы напрягать китайцев реализовать таки команду ip mcst permission uni uni-index range A.B.C.D&<1-n> {permit | preview| forbidden} - которая в документации есть, а в ПО ОЛТа нет.

 

Т.е. на мой взгляд ситуация очен напоминает ситуацию с забросом АРП - почини одно, отвалится второе. Т.е. глюки где то глубоко в идеологии.

Изменено 2013-02-17 19:10:41 пользователем Гайджин

[Гайджин 574]

ПС прошивку использовали Version 10.1.0B Build 9545?

Version 10.1.0B Build 9545 и  Version 10.1.0B Build 10732 - в поведении с мультикастом они идентичны.

[forerunner 84]

 

 При таком конфиге: ... Igmp join пакеты будут выходить из порта GigaEthernet0/1 в тегированном виде, с тегом 487.

 

Вот когда я это увидел, то дальше искать логику в настройке перехотелось полностью. Т.к. если увежаемые китайцы пишут, что switchport mode trunk, то они какбэ согласны работать в поле стандарта 802.1q, где native vlan (switchport pvid) ходит в транке нетэгированным + команда switchport trunk vlan-untagged none подразумевает запрет хождения нетэгированного траффика. Это я к тому, что пакеты с тэгом pvid на выходе ставят с ступор полностью.

 

Но ты вроде как не сдаешься и лезешь в мануал! И тут получаешь второй удар серпом по яйцам:

 

 

 To configure port VLAN of in the access mode, use the switchport pvid command.

 

А я то, дурак, эту команду применял на транковом порту, чтобы там ходил мультикаст с тэгом в нетэгированном влане! 

 

Ну да ладно, то такое .. Согласен, что это не должно влиять на ONU. Но с:

 

 

Т.е. глюки где то глубоко в идеологии.

 

Согласен на все сто.