Гайджин

Гигантского размера?

Первого Вы не говорили, второе в теории, третье вроде бы... - Занятно...

Ты шо не видиш? - Это лекторат перепирает.

Ну я изучал сети Киевстара в двух городах - нет 32 свича на одной паре волокон не видел. На одном кабеле - да. Ну я не телепат, и по одному сообщению уровень знаний определить не могу.

Сегодня удаленно проверял свое вчерашнее предположение - мысли мои крутятся вокруг офлайновой конфигурации ONU. Стартовая конфигурация OLT-а: После этого пытаюсь исполнить следующие команды (осуществить конфигурирование ONU которая не подключена к дереву - в моем случае ее вообще не существует в природе, т.е. MAC левый) Все логично - как вы все тут и говорили, OLT отказывается исполнять конфигурирование того чего нет, заявляя что "У данной ONU нет uni портов." Дальше я выгружаю на tftp-сервер startap-config. Обратите внимание именно startap-config, а не running-confi

Не видите смысла, потому что это сложнее и эксплуатировать это тоже сложнее. Но зато когда оно ебнет где нибудь, то Вы побежите как в ж#пу раненый, а тут можно будет не спеша собираться. На одно волокно можно спокойно повесить и 3 ТКД - будет практически то же самое. Единственное чего делать не следует, так это повторять ошибок проектирования Киевстара - на одну пару волокон (SFP у них двухглазые) они и 8 ТКД повесить могли. При этом оба кабеля входа в район могли заходить по одному дому - ебни их и целый район без Интернета. 32 свича в одно кольцо? Какие нах минусы? Вы о диаметре кольца в

А вот теперь, любезный, то же самое но в кольцах - что бы Вы так сильно не эммоционировали. Вводные: 1. 1 ТКД на три подъезда, при 9ти этажах. 2. 1 ТКД на пять подъездов, при 5 этажах. 3. Всего ТКД на схеме - 32 шт. 4. Исполнение волоконно-оптической распределительной сети по крышам. 5. ТКД размещяются на домах сверху - чердак, лифтовая, рядом с лифтовой или как то так. 6. Включение абонентов производится медью, по подъезду. Вертикальная канализация или слаботочка - это уже по вкусу. 7. На одном волокне распредсети сидит не более 2х ТКД (т.е. идеальный случай). Легенда: 1. Желт

Какая этажность каких домов, откуда приходит аплинк, где видится агрегация, какие дома нужно покрыть?

В теории это не верно, но на практике это работает с ОС семейства Вин. В таблице маршрутизации там ничего особого небудет.

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

Я бы не стал так говорить, я тоже наверняка не знаю как оно работает внутри коробки. Подозреваю: мультик с тегами приходит в олт, по запросу олт наливает этот тегированный трафик в нужный порт нужной ону, предварительно сняв тег (процедура tag-stripe). Это то тривиально и понятно. Гораздо более интересный вопрос в том как выполняется igmp join - верне как продвигается этот пакет. Вот тут очень нестандартная бизнеслогика похоже применяется.

Давно? Давно.подобное наблюдал лет 10 назад. на самом деле все тривиально - в рамках одного широковещательного эзернет клауда поднято несколько ip-сетей. в данном случае винда видит что адрес получателя лежит вне "домашней" ip-сети и дает в сеть arp request - а кто тут шлюз (согласно того адреса шлюза который сконфигурировали). вывод - работать будет, хоть это и не правильно.

Т.е. они предлагают создавать в конфигурации какой то темплейт и крепить его к привязанной вручную ОНУ? - Я правильно понимаю? Так а сколько таких темплейтов создать можно будет? - 256 штук можно?

Ну ты про него уже в курсе - вместе считай нашли.

Боле чем нормальный срок. p.s. Можно следующий "косячок" озвучивать или не все еще от прошлого отошли?

Господа, а кто нибудь из вас понимает как вообще работает MVR на P3310B? - То что есть "хау-ту" я знаю. (В нем легкая недосказанность.) Но меня интересует, может ли кто то на пальцах обрисовать как происходит подписка и вещание мультикастовой группы - т.е. какие пакеты куда движутся и что с ними делается в дороге.

Почему?

После апгрейда софта в P3310B до 10.1.0B Build 9545 явно изменился синтаксис некоторых команд: Например в предыдущей версии софта "username name [privilege level]" работало, а сейчас этой команды нет - а как бы хотелось. У всех так? Кто нибудь нашел как определить привилегии пользователям?

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

Ага... Значит я на эти грабли не первый наступил - это радует, а то зачастую как раскопаешь какой нибудь глюк, а его никто с роду не видел. Печалит другое - данная проблема ни в "решенных" ни в "не решенных" на дропбоксе проекта не значится. Вы сами обращались к китайцам? - Если да, то хотелось бы увидеть ответ. (Возможно он конечно где то в недрах веток UA.PON хранится, но если честно господа, то их так в перемешку завали техническим, коммерческими и околопоновыми вопросами, что там найти что либо тяжело. Третью версию прочитал всю, вторую до 15 страници, до первой не знаю доберусь ли - н

Влад, я конечно дико извиняюсь, но Вы выкладываете результаты теста, которые довольно часто содержать фразу "команда работает" - у меня вопрос: так "команда работает" или все же функционал конфигурируемый этой командой работает? Т.е. производилось серьезное тестирование работоспособности функционала?

Если правильно помню, то здесь первый влан это нейтив, нетегированый, остальные с тегами. Тупо так как мне в таких схемах нейтив нафиг не сдался - приходилось туфту писать. Господа, сдается мне что я баг нашел - похоже что наши Китайские друзья даже L2 коммутацию нормально реализовать не смогли. Записки постороннего (часть первая). Схема стенда: D-Link DGS-3626g [port2] | [GE0/1] BDCom P3310B (10.1.0B Build 9545) [EPON0/1] | BDCom P1004 (10.0.8A1082) | [uNI:1] - MAG250 [uNI:2] - tcpdump Эксперимент 1: ! interface GigaEthernet0/1 switchport trunk vlan-allowed 410,487,100

Вижу что можно... Но что это за бл%?: Switch_config_epon0/1:1#epon onu port 2 ctc vlan mode trunk 487 ? WORD -- old VLAN IDs such as (1,3,5,7) Or (1,3-5,7) Or (1-7) Какой старый влан?

Лучше отдавать все три влана с тегом, а на свитче уже снимать с нужных пакетов тег. На каком свиче? - Клиентском? Так нет его...

Ну т.е. классический аксесс порт. По поводу выделенного я бы добавил - он выпускается через соответствующий порт не тегированным. Первая половина понятно - т.е. перемаркируется клиентский тег (какой бы влан клиент не подал). Вторая нет - с каким тегом должен прийти пакет на пон-порт, и на какой тег он будет перемаркирован если параметров один. update: Тьфу блин! В этой команде параметр один, но есть еще и другая с параметром translation-entry.... - Убивал бы за такое кли и доки.