ufm

Я сегодня еще ковырялся в этой теме. Попытаюсь обобщить. Наблюдаю следующее: Если попытаться двунаправленно раскачать канал сквозь ONU+OLT, до скоростей близких к скорости насыщения порта ONU, то RTT вырастает до 200 мс и более. Как одно из предположений, было выдвинуто то, что механизмы TDMA перестают корректно работать при переполнении буфера порта ONU. Было принято решение попробовать ограничить скорость на портах средствами самой ONU чуть ниже физической скорости порта. При ограничении скорости rate-limit-ом и попытатке двунаправленно раскачать канал сквозь ONU+OLT, до скоростей близких к скорости rate-limit-, то RTT вырастает до 200 мс и более. Причем это наблюдается даже если зажать rate-limit-ом скорость на 10 МБит/с. Та же самая картина наблюдается если попытаться применить sla. Делаю вывод, что похоже rate-limit тесно взаимосвязан с механизмами TDMA, и вылечить одно за счет другого не получится. Тогда предпринимаю попытку ограничить скорость внешними средствами. Создаю не сервере B (схема с прошлого раза не менялась) низходящий двухполосый щейпер. Первая полоса имеет приоритет в 8 раз выше чем вторая и в нее помещается технологический TCP трафик (ACK) - т.е. я "кондициорирую" трафик (обеспечиваю ему улучшенные условия для двунаправленного обмена). Для восходящего трафика создаю полисер. Параметры дискриминации трафика подбираю во время экспериментов. На приведенном ниже скриншоте в левом маленьком окне пинг с сервера B на серевер A, в правом маленьком окне пинг с сервера B на серевер Mag250, в нижнем окне двусторонний промер с сервера A на B, на заднем плане консоль сервера B. На выхлопе я добиваюсь того, что при зажимании скорости в обеих направлениях на 80 МБит/с я получаю нормальный RTT. Именно таким он должен быть без всяких манипуляций с моей стороны, не будь у ONU своего видения на жизнь. Вопрос для китайцев: Хочу, что бы было вот так, как выделено жирным шрифтом. p.s. На этом я заканчиваю свои эксперименты на ближайшее время. Вопрос - а если убрать (или поиграться с параметрами) волшебную команду "epon dba hardware cycletime 25000 discovery-frequence 60 discovery-length 1024"?

На самом деле не столь категорично, но доступ к ОНУ будет "при определенных условиях". У меня подход очень простой - "дайте мне кирпич управляемый только с головы или дайте мне тупую голову а управление всё с самой 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 : 10.0.8A 1103 (F23-BG) Build : 10:36:20, Jan 24 2013 Кстати, из менеджмент влана ОНУ пропадает потому что (ТА-ДАМММММ) перестает отвечть на arp запросы. Если ручками внести в arp таблицу что-то типа arp -s 10.222.11.252 fc:fa:f7:96:11:87 temp то оно вполне себе пингается. ufm@ufm-ws ~ $ ping 10.222.11.252 PING 10.222.11.252 (10.222.11.252) 56(84) bytes of data. 64 bytes from 10.222.11.252: icmp_req=1 ttl=62 time=192 ms 64 bytes from 10.222.11.252: icmp_req=2 ttl=62 time=1.85 ms 64 bytes from 10.222.11.252: icmp_req=3 ttl=62 time=1.93 ms 64 bytes from 10.222.11.252: icmp_req=4 ttl=62 time=1.88 ms Т.е. китайцы немного перестарались.

С одной стороны - я не понимаю с чего ты решил что будет еще какая-то "полная версия". Это вполне себе полная версия. Просто её ставить надо в три прохода. Сначала обновлять 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 eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 11:16:25.841161 fc:fa:f7:9d:02:f9 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:f9, length 46 11:16:25.852119 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.119 tell 192.168.1.1, length 42 11:16:25.855643 fc:fa:f7:9d:02:5b > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:5b, length 46 11:16:25.855663 fc:fa:f7:9d:02:6c > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:6c, length 46 11:16:25.855669 fc:fa:f7:9d:02:54 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:54, length 46 11:16:25.855675 fc:fa:f7:9d:02:fd > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:fd, length 46 11:16:25.855679 fc:fa:f7:9d:02:6d > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:6d, length 46 11:16:25.855684 fc:fa:f7:9d:02:5f > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:5f, length 46 11:16:25.855688 fc:fa:f7:9d:02:d8 > 80:71:1f:d6:7f:80, ethertype ARP (0x0806), length 60: Reply 10.0.0.10 is-at fc:fa:f7:9d:02:d8, length 46 11:16:25.884662 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.2 tell 192.168.1.1, length 42 11:16:25.937308 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.101 tell 192.168.1.1, length 42 11:16:25.960796 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.201 tell 192.168.1.1, length 42 11:16:26.073268 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 42 11:16:26.106997 00:25:90:53:35:5e > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 53, p 0, ethertype ARP, Request who-has 31.129.160.86 tell 31.129.160.85, length 42 11:16:26.161216 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.8 tell 192.168.1.1, length 42 11:16:26.165957 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.130 tell 192.168.1.1, length 42 11:16:26.172954 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.100 tell 192.168.1.1, length 42 11:16:26.186186 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.5 tell 192.168.1.1, length 42 11:16:26.259921 90:e2:ba:07:c7:f0 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 2318, p 0, ethertype ARP, Request who-has 192.168.1.10 tell 192.168.1.1, length 42 И сейчас BDCOM скажет - покажите конфиг. А я не хочу показывать конфиг, я привёл _достаточно_ информации для того, что бы было понятно, что происходит лажа.

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

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

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