Гайджин

Упаси бог. Смысл ловить баги в предыдущей прошивке? Не-не-не.... Уплочено.... Щаз.... Кстати, обновлялись на боевой голове? С развесистым конфигом? Проблемы были? Упаси бог. Нету у меня еще боевой, "комнатная" она пока.

Я! Я! Можно я отблагодарю?!

to UFM: Вы сильно ответ на вопрос хотите узнать? - Т.е. мне перешиться на ночь глядя, на 10.1.0B Build 9545?

Ну вестимо что 10.1.0B Build 10732 - с оффлайновыми темплейтами. pony1_config_epon0/1:1#switchport port-security ? mode -- Security port mode static -- Security port static config dynamic -- Security port dynamic config pony1_config_epon0/1:1#switchport port-security mode ? static -- Security port static mode dynamic -- Security port dynamic mode pony1_config_epon0/1:1#switchport port-security mode

Так? pony1# pony1#conf pony1_config#int e0/1:1 pony1_config_epon0/1:1#switchport port-security block mac 0007.e90c.4f06 switchport port-security block mac 0007.e90c.4f06 ^ Too many parameters pony1_config_epon0/1:1#switchport ? disable-learning -- Port based mac learning setting enhanced-link -- Enable enhanced link status check lec -- Link Error Check port-security -- Security port config pony1_config_epon0/1:1#switchport port-security ? mode -- Security port mode static -- Security port static config dynamic -- Security port dynamic config pony1_config_epon0/1:1#switchport port-security Или прямо на ОНУ исполнить надо?

Не в ОНУ-интерфейсе, а в епон-интерфейсе: ! interface EPON0/1 epon pre-config-template epon0/1 binded-onu-llid 1-64 epon bind-onu mac fcfa.f796.174e 1 epon bind-onu mac fcfa.f796.14ad 2 switchport trunk vlan-allowed 487,1008-1009 switchport trunk vlan-untagged none switchport mode trunk switchport protected switchport port-security block mac 0007.e90c.4f06 !После ввода команды нечего не ребутнулось.

- Поручик, скажите, а как Вы с девушками знакомитесь? - Девушка, а можно Вам впердолить? - Нууу поручик, так можно и по е#альнику получить! - Можно и получить, а можно и впердолить. Я думаю смысл Вам понятен.

Я думаю тем, кому интересна эта информация, и так все прекрасно знают. Как бы не тихушничали.

Геля, Геля... Боже, Боже... - Большой брат следит за тобой...

Влад, так я и не говорил что Тобою работы не проводиться. Я говорил о том, что создается впечатление что китайцы сами вообще ничего не тестируют. Т.е. как в том анекдоте - "чукча не читатель, чукча писатель." Вот в том то и странность, что главного инженера еще и уговаривать приходится. Да понятно что для них было бы идеальным - но ведь согласись, не мы им схемотехнику делали. Могли бы уж и осознать что тяжко будет еще до того как ежа с ужом крестить начали. Насколько я понял из твоих слов, что в итоге они все таки сделают прошивку с правильной работой и АРП и вланов? Обещают увеличить диапазоны мультикаст групп? - а как же ограничение чипсета и все такое? Что же касается НГ - ну а что тут поделать? - мы гуляли, теперь их очередь.

почему жалко? у вас на 1 подезд будет больше 10 абонов? или у вас 64*10=640 абонов скушают 1Г(очень сомневаюсь даже при тарифах 80-100 мбит,не говоря что 640 ешё подключить нужно) ? плюс никто не отменял МРТЖ, и когда будет впиратся в 0.8Г то работы на 5 минут чтобы запустить с отдельной ПОН башки ещё один 1Г Зачем в такие дебри вдаваться - считайте укрупненно, т.е. по домам. Если Вы будете ставить 1 ТКД на подъезд, то при среднем размере дома в 4 подъезда, получается 16 домов. Т.е. две ветки ПОНа могут накрыть район в 32 дома. Есть у меня район такого размера - потребление где то 1.8Г. Т.е. с емкостью проблем не будет. Особенно если оставшиеся 2 порта оставить как резерв. Однако о полном отсутствии проблемы говорить наверное все же рано. И вообще, я не понимаю, в каком месте вы тут экономите?

Ребят! Вы такие взрослые, а ёщё верите в сказки. Да не бывает так, бесплатным бывает только сыр в мышеловке Капитан очевидность?

Ну тут подвиг Тринити только UFM повторить пытается. Остальные к ПОНу более традиционно подходят.

Уж не презентацию ли с КРОСа 2011 Вы нам расказываете? - Славный город Мариуполь?

Возможно, но если честно, то мне кажется, что имея схему тестового стенда и скриншоты его выполнения можно прийти к выводам самостоятельно, не имея вообще никаких описаний. И вообще, складывается такое впечатление, что данные изделия самими Китайцами практически не тестировались и в самом Китае не эксплуатируются (по Интернету ПОН от БДКома ищется только в Украине, Росиии, Польше ну и чуток в Китае), а если и эксплуатируются, то с иным ПО на борту. Ну я пока вопросов не видел, но если вопросы наводящие и по теме, то я ничего не вижу в этом плохого. p.s. Но это все лирика... В "подводную лодку" мы все уже сели, "люки задраены" и мы "на перископной глубине". Изходя из этого путей назад уже не очень то есть. Отсюда вопрос - может быть таки можно нажать на нашых раскосых друзей и сказать - Чуваки, вы сами придумали сделать менеджемент влан на данных ОНУ (вас за язык никто не тянул), а АРП это вообще часть основопологающего протокола (без которого ваше обурудование вообще смысла не имеет). Так что будьте так любезны и исполните то, что должно быть, и вами же заявлено.

Все можно, не бывает ничего не возможного (т.е. мы же не 40Г интерфейс в ОНУ вставить просим.) - просто похоже, что слишком много переписывать, т.е. ошибка очень глубоко. Вот и лепят горбатого.

Ну я же сразу сказал что смотреть надо чего пациентура вытворяет. А тут - айпи, айпи, нат, нат...

+100500 - Это совершенно нормальное поведение для устройства типа CPE.

Пробовал - и параметрами играл и убирать пробовал (сам же прекрасно понимаешь, то она на самом деле не убирается, а принимает какие то дефолтные значения), не помогает. p.s. мне кажется что в этом команде только первый параметр как то более менее ощутимо влияет. но при его увеличении RTT ростет.

Можно я промолчу по поводу того что я думаю об их ответе? - Ибо в противном случае меня опять в асоциальном поведении обвинят. Не понял - сейчас есть прошивка ONU с починено-поломаным ARP (одно починено, второе поломано) и через два дня будет новая прошивка (с каким функционалом)? Считаю что демократия в данном случае более вредна, чем полезна. В результате всего этого трым-пырым видно, что ОНУ должно быть устройством молчаливым (особенно со стороны пользователя), управляться посредством OAMа (нехрен по ней шляться телнетом), сливать всю статистику на ОЛТ посредством OAMа же, а уже с ОЛТа эту статистику что бы можно было по snmp забраться. p.s. Кстати, а как вообще китайцы объясняют зачем на ОНУ сделана возможность доступа телнетом? Спрашиваю потому, что не понимаю необходимости. Но при этом в оборудовании PON другого вендора такая возможность тоже есть. И в доке про нее пишут следующее: Before disconnecting ONU Customer Premises Equipment (CPE) from system, IP address must be assigned to ONU CPE, and then perform ONU CPE configuration. There are two ways to assign IP address to ONU CPE: ¦ Dynamically assigned by DHCP server. ¦ Manually assigned, see <ONU CPE Operation Manual> for details.

Я сегодня еще ковырялся в этой теме. Попытаюсь обобщить. Наблюдаю следующее: Если попытаться двунаправленно раскачать канал сквозь 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. На этом я заканчиваю свои эксперименты на ближайшее время.

Предъявлять пока что то рано - причины этого явления пока не ясны. Нужно дополнительно работать над этим, а у меня как раз время кончается - мне сеть новую запускать ехать надо. Так что может быть все же толпой на этот баг навалимся?

Влад, да не в этом дело. - Мы все чего то не знаем, а чего то знаем, и причем все по разному. Но суммарно мы знаем гораздо больше чем каждый в отдельности. Вот я возвал к коллективному разуму - мужики, кто что думает по этому поводу? Т.е. почему подобные финты ушами (такой причудливый рост пинга) могут происходить? То что это ненормально я сам прекрасно понимаю - мне интересно докопаться до причин. Без осознания причин китайцев не отпиннаешь в копчик, и они ничего не исправят. Мне же в ответ вместо того, что бы каких нибудь интересных мыслей покинуть - да ты типа за%%%л ("...Ваш поезд сьехал в тупик неадекватности..."), все и так оху%%но, "при съемках данного фильма ни одно животное не пострадало", и вообще "в Багдаде все спокойно". Т.е. креативных мыслей аж два вагона. Я х%%ю, уважаемая редакция. Так вот господа, не все спокойно в Багдаде - вчера коллега провел подобный моему тест (нагрузил восходящий канал черз ONU->OLT и пингал хост ниже ONU) и вот результаты у него следующие - 94.7 Mbits/sec и RTT 1-3 мс, без подскоков и падений. Вот это я нахожу нормальным поведением. Но вот только беда в том, что тест проводился на PON оборудовании другого вендора. И при этом - в Багдаде все спокойно... p.s. И вообще, лично мне кажется, что обсуждение подобных тем в формате форума весьма неудобно. Нужна обычная система баг-трекинга, что типа вот такого. Что бы не было как сегодня с утра - протрахался два часа в попытках насадить на ONU ip-адрес управления. И только потом обнаружил, что наши раскосые друзья в последней прошивке заброс ARPа из влана во влан починили. Но вот только горюшко то в том, что похоже на этом баге и держались все эти приколы типа "влан управления может быть любой, но не тегированный". Создается впечатление, что туда ARP тоже забрасывало, на этом и жило, а теперь перестало - вот менеджмент и отвалился. Вернее ARP в менеджмент влане. А вот теперь внимание вопрос: еще тут я просил объяснить подробней, что наблюдали и к чему пришли; было это 4 дня назад; не уже ли так тяжело было ответить?! Ведь минимум два человека знали и четко понимали о чем речь. Получи я ответ вовремя, я бы вместо двух часов кувыкрков осознал бы в чем дело за 5 минут. Ось така х%ня малята, на добраніч, діти...

Не один - а единственный озвученный. И до тех пор пока другие не озвучены, можно считать что их не сущемтвует.

Если раньше было через раз, то терерь каждый заход требует выполнять логин.