ufm

Там много интересного, но иногда оно имеет мало отношения к действительности, к сожалению.

Для интересующихся дупами. Победил. Оказалась проблема в волокне на участке "до абонента". С одной стороны - ОЛТ про это явно говорило, показывая ошибки на ПОН порту. С другой - из диагностики _только_ ошибки на ПОН порту и иногда, когда уж совсем пц-пц - дупы всех пакетов, идущих с этой онушки. Т.е. онушка не отваливалась, затухание - в норме. И это пичалька. Если бы у меня на этом дереве было 64 ОНУ-шек и просело-бы где-то волокно, то я-бы упарился это ловить.

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

Проблема, которую я упоминал, но подробно не описывал. Имеем настройки: ... no spanning-tree ... interface EPON0/1 epon bind-onu fcfa.f796.08b5 3 switchport mode trunk switchport trunk vlan-allowed 1120,2315 no spanning-tree ... interface EPON0/1:3 onu-configuration no spanning-tree ... (т.е. STP выключен как на OLT так и на ONU и вобще где только можно) тем не менее видим на порту, подключенному к ОНУ: 17:28:19.809936 STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward], bridge-id 8000.fc:fa:f7:96:08:b5.8004, length 47 17:28:21.901721 STP 802.1w, Rapid STP, Flag

Отличные новости!!! Правда, я подозреваю, у меня будут еще проблемы к следующей версии Но вот эта фраза "after research the PON chips, we found it support flow control" меня повеселила изрядно. "ВНЕЗАПНО мы обнаружили, что чип, на котором сделана наша железка, поддерживает флоуконтрол"... )

Ну т.е. дупов - нет. Смое смешное - что на другой ветке у меня с этой-же ону тоже всё нормально. Т.е. я действительно начинаю подозревать волокно. Но с учетом что я не понимаю происходящего процесса - у меня когнитивный диссгонанс. Кстати, а какая у Вас версия железа? А по поводу времен пингов - ну я вобще на практически пустом оборудовании сейчас играюсь. Может быть из-за этого

Поставил на "долгий пинг" по результатам отпишусь. А у меня встречный вопрос, а какие значения пинга у Вас? какое среднее и какой разнос? 10366 packets transmitted, 10366 packets received, +2286 duplicates, 0.0% packet loss round-trip min/avg/max/stddev = 1.070/1.659/26.063/1.061 ms Вот в другом месте: 12636 packets transmitted, 12610 received, 0% packet loss, time 639555ms rtt min/avg/max/mdev = 0.844/1.965/3.146/0.134 ms

Коллеги, нужна ваша помощь. Если не трудно, не могли-бы вы поставить под "долгий пинг" какого нибудь из абонентов? Меня смущает следующее: "7074 packets transmitted, 7074 packets received, +113 duplicates, 0.0% packet loss" Причем это уже другая ОНУшка. Т.е. замена помогла (предыдущая дупила практически каждый второй пакет). но проблему до конца не решила. Мне интересно, это особенности новых ОНУшек, новой ОЛТ, волокна или еще чего-то.

Такое ощущение, что прошивку китайцы не сами писали а у индусов оутсорсили. Switch#show inter e0/1:3 EPON0/1:3 is up, line protocol is up Description: 3.pon.mgn Hardware is GigaEthernet-LLID, address is 00e0.0fde.d388 (bia 00e0.0fde.d388) MTU 1500 bytes, BW 100000 kbit, DLY 2000 usec Encapsulation ARPA Full-duplex, Auto-Speed(1000Mb/s) flow-control off 5 minutes input rate 228303909 bits/sec, 0 packets/sec 5 minutes output rate 0 bits/sec, 0 packets/sec Received 0 packets, 8589934592 bytes

У меня по 1 влану тоже ходит. Надо по 888.

О как: Switch#ethernet oam remote-loopback start interface e0/1:1 This is a intrusive loopback. While loopback, you will be unable to pass traffic across that link. Proceed with Remote Loopback(y/n)?y Switch#ethernet oam remote-loopback test 64 99 interface e0/1:1 Switch#show ethernet oam loopback-test-result int e0/1:1 Loopback test result: Out of Seqance frames: 144 99 packets transmitted, 163 received, -64% packet loss rtt min/avg/max = 10/18/30 ms Два вопроса: 1. Не сталкивался ли кто нибудь с тким поведением ОНУ? 2. К Владу: если я зменю ОНУ и другая с точно таким-же

Эк её плющит-то, похоже... Aug 1 22:24:07 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to down Aug 1 22:24:07 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to down Aug 1 22:24:08 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to up Aug 1 22:24:08 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to up Aug 1 22:24:21 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to down Aug 1 22:24:21 %LINK-UPDOWN: Line on Interface EPON0/1:1 onu uni 4, changed state to down И пакеты с этой он

Коллеги, у меня вопрос: Switch#show interface e0/1 EPON0/1 is up, line protocol is up Hardware is GigaEthernet-PON, address is 00e0.0fde.d388 (bia 00e0.0fde.d388) MTU 1500 bytes, BW 1000000 kbit, DLY 2000 usec Encapsulation ARPA Full-duplex, Auto-Speed(1000Mb/s) flow-control off 5 minutes input rate 0 bits/sec, 0 packets/sec 5 minutes output rate 0 bits/sec, 0 packets/sec Received 0 packets, 0 bytes 0 broadcasts, 0 multicasts 0 discard, 217 error, 0 PAUSE 0 align, 0 FCS, 0 symbol 0 carriersense Transmited 36 packets, 3682 bytes 22 broadcasts, 14 mu

Похоже что да.

А вот может быть что таки да, таки это мой misconfiguration. Нет. Нифига. Что-то я торможу на жаре. Собственно это как раз выводит management vlan в нетегированный режим для порта. И всё бы ничего, но мне нужно этот vlan еще и за онушку пробросить. Вобщем завтра я еще поиграюсь - напишу. не, не буду играться. Буду ждать следующую прошивку:

А вот может быть что таки да, таки это мой misconfiguration. Нет. Нифига. Что-то я торможу на жаре. Собственно это как раз выводит management vlan в нетегированный режим для порта. И всё бы ничего, но мне нужно этот vlan еще и за онушку пробросить. Вобщем завтра я еще поиграюсь - напишу.

А вот может быть что таки да, таки это мой misconfiguration.

Влад, не переживайте. Нормальный рабочий режим. Кстати, что-то китайцы напрямую со мной замолчали. Давайте-ка я и через вас продублирую проблему. Авось поможет. I have config: ------ !version 10.1.0A build 6558 service timestamps log date service timestamps debug dateip default-gateway 10.222.0.1 ip name-server 10.128.0.5 no spanning-tree ! ip access-list standard httpd-acl permit any ! epon dba hardware cycletime 25000 discovery-frequence 60 discovery-length 1024 !no epon encryption ! !!slot 0 84 interface GigaEthernet0/1 switchport mode trunk switchport trunk vlan-allowed 1-40

5 старушек - рубль. Да и стоит APC дороже. На самом деле мне просто интересно - откуда взялся миф про меньшее затухание на APC коннекторах. Ну не считая производителей - им оно понятно выгоднее.

Отраженный сигнал для цифры по большому счету - по барабану, пока он не превышает полезный. Для КТВ - беда-беда. Вот ровно для кетевешников оно и было сделано.

Покажите мне, пожалуйста, документы, где написано что APC дает меньше потери. Везде про них написано ровно одно - отраженный сигнал вводится из волокна и нужно только для аналогового сигнала. Всё. Никакого приемущества по затуханию АPC не даёт. Мало того:

Покажите мне, пожалуйста, документы, где написано что APC дает меньше потери. Везде про них написано ровно одно - отраженный сигнал вводится из волокна и нужно только для аналогового сигнала. Всё. Никакого приемущества по затуханию АPC не даёт.

Для интересующихся: Прямой переход с синего на зеленый разъем дает примерно 3 dB затухание минимум. P.S. Это я тут затухометр приобрёл - играюсь.

А не сложно будет узнать, модели P2008, P2016 и P2024 какой суммарной производительностью ограничены?

интересно зачем клиентам чайна телеком доступ к онушкам? Я бы даже задал несколько вопросов: 1. Каким боком доступ к ОНУ пересекается с доступом из одного порта в другой 2. Каким образом получение ARP ответа от ONU помогает с доступом к ONU 3. А они не переели рыбного супа, явно нарушать стандарты? Впрочем, если сделают эту фичу отключаемой - бог с ними.