ufm

Я сегодня еще ковырялся в этой теме. Попытаюсь обобщить. Наблюдаю следующее: Если попытаться двунаправленно раскачать канал сквозь ONU+OLT, до скоростей близких к скорости насыщения порта ONU, то RTT вырастает до 200 мс и более. Как одно из предположений, было выдвинуто то, что механизмы TDMA перестают корректно работать при переполнении буфера порта ONU. Было принято решение попробовать ограничить скорость на портах средствами самой ONU чуть ниже физической скорости порта. При ограничении скорости rate-limit-ом и попытатке двунаправленно раскачать канал сквозь ONU+OLT, до скоростей бл

На самом деле не столь категорично, но доступ к ОНУ будет "при определенных условиях". У меня подход очень простой - "дайте мне кирпич управляемый только с головы или дайте мне тупую голову а управление всё с самой ONU".

А как тогда у людей получалось 30Mbit качнуть по нескольким портам? не знаю. У меня - не получалось.

Я не помню откуда у меня эта информация, и я могу заблуждаться, но: 1. Свитч-марица у 1004 - 200М 2. Скорость в сторону PON - 125М (судя по цифре - канальная, т.е. это обычные 100М) Т.е. это очень похоже на обычный 5-ти портовый 100М свич, в один из портов которого воткнут PON. Мало того, и ведет оно себя именно так. Я думаю 1504 должна себя вести как гигабитный свич. Впрочем этого зверя я еще в руках не держал.

1. Я вижу полностью работоспособную 100М сеть почти с максимальной пропускной способностью. 2. Я вижу немного странную работу QoS. Но не смертельно странную.

epon sla upstream pir 1000000 cir 512 epon sla downstream pir 1000000 cir 512 в настройках ONU немного помогает.

+100500 Мне просто в паре мест критичен этот баг на столько, что я готов проапгрейдить ОНУ на столе и отвезти их туда. А апдейтить вот так все 1004 - упаси бог.

Влад, ты не понял. Еще раз - это не заплатка. Я, конечно, допускаю мысль, что китайцы напрягутся и сделают прошику, которая будет менять и uboot и накатывать сразу поаледнюю прошивку, причем не надо будет накатывать промежуточную. Но верю в это очень мало. Еще раз, первым обновляется uboot. Он, кстати, через OLT не шьётс впринципе. Только непосредственно с ONU. Дальше накатывается первая версия. И ONU становится вот такой: Release : 10.0.8A 1098 (F23-BG) Build : 15:05:50, Dec 12 2012 после чего накатывается следующая версия и ОНУ становится такой: Release

С одной стороны - я не понимаю с чего ты решил что будет еще какая-то "полная версия". Это вполне себе полная версия. Просто её ставить надо в три прохода. Сначала обновлять uboot, потом ставить предыдущую, потом последнюю. Это ты эджкоры никогда не обновлял. Там и 6 проходов бывает. С другой стороны - у меня на 99.9% уверенность, что после обновления эта онушка будет недоступна через management vlan. С третьей стороны - шить ОНУ лучше через UNI (доступ через тот самый 10.0.0.10). Интересно, что они тут отломают? P.S. забыл написать - тем не менее ARP действительно начинает ходи

1501 - собственно теже яйца. Interfaces: [LAN - Admin] MAC Address : FC:FA:F7:9D:02:F6 Share Mode : Share IP Mode : Static IP Address : 10.0.0.10 IP Mask : 255.0.0.0 Gateway : 0.0.0.0 DNS Server : 0.0.0.0

Я не то что бы против. Но вот прямо сейчас мне приходится обновлять ONU с неё самой по tftp. Причем с ethernet-а, так как по PON порту оно обновляться, почему-то, не захотело.

Да вот есть у меня подозрение, что не перетянет. Или не всё. Или нужна будет перезагрузка.

facepalm.jpg настройки онушки 1004, если её отключить от PON и перегрузить: [LAN - Admin] MAC Address : FC:FA:F7:96:11:C0 Share Mode : Share IP Mode : Static IP Address : 10.0.0.10 IP Mask : 255.0.0.0 Имя и пароль, вестимо, admin/admin И вся эта красота доступна со стороны UNI порта.

Я.

я за это. по второму вопросу не готов что-то сказать... я даже готов предложить синтаксис: epon rebind-onu mac <mac-addr> <num> выполняет перерегистрацию ранее зарегестрированной ОНУ на другом порту. При этом конфигурационная секция этой ОНУ должна остаться без изменений принимается - добавляю в ТЗ. Дополнение: или на том-же самом порту, но с другим номером. Тоже иногда бывает нужно.

я за это. по второму вопросу не готов что-то сказать... я даже готов предложить синтаксис: epon rebind-onu mac <mac-addr> <num> выполняет перерегистрацию ранее зарегестрированной ОНУ на другом порту. При этом конфигурационная секция этой ОНУ должна остаться без изменений

Нет свитча - нет проблем Ну чем-то оно теги-то снимает Хотя есть у меня подозрение, что я поторопился с выводами о безглюкавости 1501. Завтра проверю. Проверил. 1501 ведет себя как лапочка и зайка и пропускает через себя только указанные вланы. (ну почти, но я подозреваю, что в обычной сети не бегают пакеты в _тегированном_ первом влане)

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

Нет свитча - нет проблем Ну чем-то оно теги-то снимает

на 1501 этой проблемы нет.

Кстати, Влад, любимый тобой PHICOMM. Сильно лучше, да, но не без косяков: 12:27:15.673154 da:76:74:01:30:c1 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 60: vlan 1120, p 0, ethertype IPv4, 0.0.0.0 > 224.0.0.1: igmp query v2 12:27:15.875886 00:27:22:48:45:68 > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100), length 60: vlan 888, p 0, ethertype IPv4, 0.0.0.0 > 224.0.0.1: igmp query v2 Настройка ровно такая-же.

Влад, я всегда рад накапывать, ты-же знаешь. Но BDCOM на каждый чих требуют предоставить им показывать ж#пу и риносить унитаз. А я не люблю делать работу, цель которой я не понимаю. Вот например: имеем настройки ONU: pon2.sw.mgn_config_epon0/3:63#show ru int e0/3:63 Building configuration... Current configuration: ! interface EPON0/3:63 onu-configuration epon onu port 3 ctc vlan mode tag 3333 epon onu port 4 ctc vlan mode tag 4000 no epon onu spanning-tree !!onu-configuration-end И имеем на 4-том порту вот такой п-ц: ufm@ufm-ws /mnt/ufm/Documents/LDAP/Magnus $ sudo tcpdump -eni

Когда я с этой проблемой обращался в bdcom, мне было сказано, что это не бага, это фича, это сделано для какого-то большого китайского клиента, и никто ради меня, простого хлопчика, ничего менять не будет. Я вот думаю, что в связи с увеличением объёмов Владу стоит еще раз потрясти bdcom. Потому что ARP_овые бродкасты ходят не только между вланами, но и между портами ONU с включенным (точнее - с невыключенным) traffic segmentation.

epon sla upstream pir 1000000 cir 512 epon sla downstream pir 1000000 cir 512

Абонентам пофиг на качество и на обслуживаение. Они понимают две цифры - "цена" и "скорость". А конкурировать с "большим интернетом" услугами - смысла уже нет. Если у меня дома 100М, то мне, по большому счету, всё равно откуда выкачивать киношку. Чтобы мы правильно понимали друг-друга, ответьте на вопросы: 1) В зоне покрытия вашей сети сколько у вас конкурентов? 2) Вы владелец бизнеса или технический специалист, приближенный к владельцу бизнеса? Не считая общеукраинских - 4. Мне прям интересно чем Ваш ответ будет отличаться, поэтому, если не сильно затруднит, напишите ответ для обои