Гайджин

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

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

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

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

Сегодня удаленно проверял свое вчерашнее предположение - мысли мои крутятся вокруг офлайновой конфигурации ONU. Стартовая конфигурация OLT-а: После этого пытаюсь исполнить следующие команды (осуществить конфигурирование ONU которая не подключена к дереву - в моем случае ее вообще не существует в природе, т.е. MAC левый) Все логично - как вы все тут и говорили, OLT отказывается исполнять конфигурирование того чего нет, заявляя что "У данной ONU нет uni портов." Дальше я выгружаю на tftp-сервер startap-config. Обратите внимание именно startap-config, а не running-config. В running-config-е bind-onu выполнен для трех ONU, а в startap-config-е для двух. После этого, я на сервере вношу в файл со startap-config-ом следующие изменения, т.е. добавляю bind-onu и конфигурацию EPON0/1:3: После чего загружаю этот файл обратно в OLT и перегружаю его. После перезагрузки OLT содержит в себе следующий running-config: В вот теперь, господа обратите внимание на то, что конфигурация несуществующей и не подключенной к дереву ONU находится в памяти OLTa. Из этого я делаю вывод, что она там находится может и функционал для ее там размещения в программном обеспечении OLTа есть. Поэтому я предлагаю доказать китайцам, что добавить функционал "оффлайновой корфигурации ONU" исполнить не сложно, ибо частично функционал уже есть в OLTе. Как доказать? - предложить им объяснить как конфигурация несуществующей ONU попадает в пямять OLTа из startap-config-а. Ну и предложить им сделать "оффлайновую корфигурацию ONU" так: 1. ONU не подключено к деревьям - на OLTе выполняем: epon bind-onu mac [bla-bla-bla] [num] 2. Создается интерфейс interface EPON0/1:[num]. Заходим в него и начинаем конфигурировать ONU. 3. Если OLT не может исполнить те команды которые мы вводим немедленно (из за отсутсвия ONU), он их записывает в оперативную пямять (туда же куда он startap-config сожрал) и на этом успокаеватся. 4. Когда ONU приходит и коннектиться на OLT, OLT ведет себя как обычно - выберает из памяти кусок конфига касающейся данной ONU (согласно bind-onu mac) и отдает ей его на исполнение. Мне кажется, что это будет самый что ни на есть "нативный" метод конфигурирования.

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

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

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

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

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

Я бы не стал так говорить, я тоже наверняка не знаю как оно работает внутри коробки. Подозреваю: мультик с тегами приходит в олт, по запросу олт наливает этот тегированный трафик в нужный порт нужной ону, предварительно сняв тег (процедура 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 страници, до первой не знаю доберусь ли - не кажется ли вам, господа, что надо как то разбить темы по направлениям?) Что же касается фичи - мы же с Вами прекрасно понимаем, что это бред - какой нафиг клиент, глюк же классический. Не должен коммутатор себя так вести, как впрочем и полезного применения подобной "фиче" ни один суперпупер телеком не найдет ибо его быть просто не может. Что же касается объемов, то мне кажется, что тут не в объемах дело, а в возможностях самих китайцев. Ну не могут они похоже это рихтануть быстро и не напряжно - возможно пол прошвы на это завязано. Вот и лепят горбатого. Кстати, если уж зашел, разговор о возможностях братьев наших желтолицых, то у меня вопрос - в нерешенных проблемах значится вопрос о изменении механизма прошивки ONUшек. Так вот мне интересно, а просто попросить их добавить флеша в OLT или прикрутить к OLTу USB (SD Card) порт не проще бы было? - Они же с софтом не дружат, зато паяют быстро. Я не думаю что это сильно бы удорожало OLT. Если честно, то мне кажется, что traffic segmentation тут вторично - включай его, не включай, результат один будет если ARPы сами по себе по вланам размазываются. Т.е. если починить первое, то второе само вылечится.

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

Если правильно помню, то здесь первый влан это нейтив, нетегированый, остальные с тегами. Тупо так как мне в таких схемах нейтив нафиг не сдался - приходилось туфту писать. Господа, сдается мне что я баг нашел - похоже что наши Китайские друзья даже 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,1008-1009 switchport trunk vlan-untagged none switchport mode trunk switchport pvid 487 ! ! 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 ! interface EPON0/1:1 onu-configuration description test onu 1 epon onu port 1 ctc vlan mode tag 1009 epon onu port 1 loopback detect epon onu port 1 ctc mcst tag-stripe enable epon onu port 1 ctc mcst mc-vlan add 487 !!onu-configuration-end ! vlan 410 name mgmt-kino ! vlan 487 name iptv-kino ! vlan 1008 name mikh50 ! vlan 1009 name ryaz100 ! vlan 1,410,487,1008-1009 ! ip mcst enable ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255 ! Кофигурация простая - с L3 коммутатора, выполняющего роль PIM SM роутера, подаем на OLT четыре влана - управление, мультикастовый и два "пациентских". Управляющий влан осаживаем на OLTе (создаем управляющий IP интефейс), а остальные три через ЕПОН порт отправляем в первое дерево. MVR, в иcполнении BDCom-а настроен - в первом порту тестовой ONU живет MAG-250 который бодренько крутит тестовый поток. Во второй порт воткнут сниффер для наблюдения за происходящим. Так как второй порт ONU никаким особым образом не конфигурировался, то значит он находится в "transparent mode" (в разрезе вланов). С L3 коммутатора пытаемся пинговать три несуществующих хоста в трех вланах - мультикастовом и двух "пациентских", что вызывает порождение ARP запросов типа who-has "вася" в рамках этих вланов. На сниффере наблюдаем ожидаемую картину - arp запросы в тегированном виде: 15:35:47.773905 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46 15:35:49.942103 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 487, p 7, ethertype ARP, Request who-has 172.31.28.28 tell 172.31.28.254, length 46 15:35:49.942527 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46 Эксперимент 2: ! interface GigaEthernet0/1 switchport trunk vlan-allowed 410,487,1008-1009 switchport trunk vlan-untagged none switchport mode trunk switchport pvid 487 ! ! 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 ! interface EPON0/1:1 onu-configuration description test onu 1 epon onu port 1 ctc vlan mode tag 1009 epon onu port 2 ctc vlan mode tag 487 epon onu port 1 loopback detect epon onu port 1 ctc mcst tag-stripe enable epon onu port 1 ctc mcst mc-vlan add 487 !!onu-configuration-end ! vlan 410 name mgmt-kino ! vlan 487 name iptv-kino ! vlan 1008 name mikh50 ! vlan 1009 name ryaz100 ! vlan 1,410,487,1008-1009 ! ip mcst enable ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255 ! В конфигурацию внесены изменения - epon onu port 2 ctc vlan mode tag 487. Согласно bdcom\Configuration Manual\23-ONU Management Settings.pdf (раздел 3.2, стр. 26, "tag mode") ожидаем поведения "Forward the packet to the corresponding UNI port according to VID, remove the tag; if the VLAN ID of a downlink tagged packet is not the configured VID, this packet will be dropped." - Т.е. "пакет форвардится на соответствующий UNI порт с соответсвующим влан тегом, при этом тег удаляетя; если нужный влан тег не обнаружен - пакет дропается". Т.е. на выходе из второго порта мы должны наблюдать нетегированные ARP запросы в 487 влане и все - т.е. 2й UNI порт это классический access port в терминологии Cisco. На сниффере же наблюдаем: 16:37:58.078762 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.31.28.28 tell 172.31.28.254, length 46 16:37:58.079182 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46 16:37:59.910210 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46 Опа! Нежданчик! - Обнаружен заброс бродкастного трафика из вланов 1008 и 1009, которого быть не должно. Эксперимент 3: ! interface GigaEthernet0/1 switchport trunk vlan-allowed 410,487,1008-1009 switchport trunk vlan-untagged none switchport mode trunk switchport pvid 487 ! ! 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 ! interface EPON0/1:1 onu-configuration description test onu 1 epon onu port 1 ctc vlan mode tag 1009 epon onu port 2 ctc vlan mode trunk 487 1008 epon onu port 1 loopback detect epon onu port 1 ctc mcst tag-stripe enable epon onu port 1 ctc mcst mc-vlan add 487 !!onu-configuration-end ! vlan 410 name mgmt-kino ! vlan 487 name iptv-kino ! vlan 1008 name mikh50 ! vlan 1009 name ryaz100 ! vlan 1,410,487,1008-1009 ! ip mcst enable ip mcst mc-vlan 487 range 239.11.0.0 - 239.11.1.255 ! В конфигурацию внесены изменения - epon onu port 2 ctc vlan mode trunk 487 1008. В мануале bdcom\Configuration Manual\23-ONU Management Settings.pdf на тему vlan mode trunk обнаружен болт на 18. Однако судя по подсказкам CLI и stan77, на сниффере мы должны увидеть нетегированные пакеты (идущие в 487 влане) и тегированные пакеты в влане 1008 - и все! Пакеты в влане 1009 должны отсутсвовать. На сниффере же наблюдаем ту же картину, как и в эксперименте 2: 16:40:27.916171 fc:75:16:b8:a4:01 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1008, p 7, ethertype ARP, Request who-has 10.79.188.188 tell 10.79.188.1, length 46 16:40:30.084295 fc:75:16:ba:28:04 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.31.28.28 tell 172.31.28.254, length 46 16:40:30.084716 fc:75:16:ba:28:02 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 1009, p 7, ethertype ARP, Request who-has 10.79.194.194 tell 10.79.192.2, length 46 Опаньки! Как говориться - Добрый вечер! Опять заброс широковещательного трафика из 1009-го влана. Резюме: В наличии имеем криво реализованную коммутацию на L2 уровне. Баг не смертельный - заброса юникастного трафика не просиходит (я проверял - просто тут описывать не стал). Однако господа, реализующие схему vlan per customer (с Catalist-ом выше OLT-а) я вас поздравляю - ARP запросы вашего L3 свича дублируются и размазываются тонким слоем во все ONU дерева. P.s. на этом на сегодня все - завтра я планирую разобрать шедевральное поведение MVR-а в реализации BDCom.

Вижу что можно... Но что это за бл%?: 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.... - Убивал бы за такое кли и доки.