Гайджин

А Вы смотреть пытались, может быть Ваши абоненты действительно какую то нетрадиционную сексуальность к яндексу проявляют?

Фигли тут определять? - RFC прост: пинговать все что пингуется, "шить" все что "шьется", "варить" все что "варится", протоколировать все что протоколируется, записывать все что записывается, пить все что горит, шевелить все что шевелиться, не шевеляещееся расшивеливать и тут же начинать "шить", "варить" и пингать! Ну а если в итоге оно получится жидкое, то пить. Т.е. изходить из принципа - много не мало.

epon sla upstream pir 1000000 cir 512 epon sla downstream pir 1000000 cir 512 в настройках ONU немного помогает. У меня стоит: epon onu-config-template epon0/1 cmd-sequence 1 epon sla upstream pir 1000000 cir 15000 cmd-sequence 2 epon sla downstream pir 1000000 cir 15000 Не вижу смысла описывать cir ниже этого значения ибо 1000000/64=15625. Т.е. сумма "циров" (при полном дереве) будет чуть меньше "пир"-а, что IMHO есть логичным.

Ну так как "пациенты" у нас зачастую ушлые, а тариф "соточка за чирик", то запросто может возникнуть прецедент когда какое нибудь тело начнет выносить мозг техподдержке - "а у меня спидтест на аплоад более 60 мегабит не показывает". А он действительно сквозь ОНУшку так показывает. Вот и хочется как то разобраться почему и сохранить мозг техподдержке. Я пока вокруг этой проблемы кручусь, но внятного еще ничего сказать не могу. Не нащупал еще в чем дело.

На каком типе трафика? торентом с 0day качал тремя ноутами в трех портах ону + в 4-ом порту был "ноут-инвалид" - я им пингал Торрент был с поддержкой "мютипи" (mTP)? - Ибо я на UDP трафике вчера разогнал ее двумя портами до 180 мегабит в дуплексе, т.е. 2 * 90 туда и обратно одновременно. Больше просто хостов под руками не было. При этом пинг на тестовые хосты выше 2-3 мс не поднимался. Но вот с TCP трафиком прям какая то беда. Без увеличения размера "окна" апстрим с сотрочного порта ноута более 60 мегабит не раскачегаривается, при этом пинг взвивается в заоблачные высоты. Пробовал к

Ну так а какой тогда помощи хотите?

Ну насколько я понимаю с железом выбор не велик. А с планированием - так а что не понятно то?

Не... Их связь в другом месте.

На каком типе трафика? Если 30 Мбайт/с, то о каких 125 Мбит/с в доках на дропбоксе пишут? p.s. Просто я сегодня ее на эту тему погонять надумал и у меня сложилось такое впечатление, что у нее либо HOL Prevention просто нет, либо он не работает и его как то включать надо.

По TCP? Одновременно в обе стороны? А сколько получилось? И что было не в лоб?

Господа, а 1004b на пропускную способность тестировали? У кого какие результаты? - Особенно интересно в восходящий канал.

Там не трубы а именно опоры - воьмигранные. Если память не изменяет, то Mabo.Ну и вроде бы как оптика там совсем не УТ.

Ну если нужно "понюхать" порт прямо таки на месте, т.е. Вы рядом со свичем, то втыкаться в свободный порт свича и выполнят port mirroring. Если же это нужно выполнить дистанционно, то необходимо применять функционал RSPAN.

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

Вот тут как то популярней можно изложить? Из какого менеджмент влана? В каком виде в этот момент ОНУ - отключена от ОЛТа или подключена? Т.е. изложите плиз более доходчиво.

Все что на левом берегу Днепра - все Донбасс!

Консоль у них есть? - Если есть, то лезте на дом, втыкайтесь в свич и смотрите чего у него в голове происходит.

Почему же не клеится? - как раз клеится. Вы представьте себе, что им крышу сдуло совсем и этот DHCP Request не какой то чужой, а их собственный - т.е. они для себя ip просят. p.s. Это то как раз проверить не сложно. Нужно выбрать какой то MAC свича, и наблюдать на снифере DHCP активность. При этом послать на свич ремонтника и заствить его выдернуть все присоединения из этого свича, кроме аплинка. Если DHCP Request быдут иметь место и после этого, то значит это сам свич головой об стенку бьется.

Боюсь что в Донбассе вы одним свичем не отделаетесь. Скорее всего придется разместить минимум три - в Днепре, Донецке и Луганске. В Донецке - ул. Постышева 60, 4 этаж, "комната операторов". Так большинство присутствует.

Согласен, при сконфигурированом влане управления маков коммутатора не должно быть видно ни где кроме него. Но опять же - если этот влан сконфигурирован. Может они просто массово "сбросились"?

Все лямбды заняты! В очередь не становиться! Все равно на всех не хватит!

Ну этим "и другие современные и востребованные в Triple Play сетях функции" все сказано.

Хорошо, ну а мне допустим "опт82, снупинг" не тарахтели ни разу, а нужна поддержка TR-101. Да, и пускай "что бы оно работало и была техподдержка(форум телефон почта и т.д)". Ну и что Вы на это скажите? Надеюсь я доходчиво намекнул на то что Ваши предположения мягко говоря не состоятельны? вы так всё выбирает на может быть завтра понадобится, я заметил на доступе коммутаторы по два года больше не задерживаются (уже по третьему кругу меняю у себя), я про то что 90 процентам нужен будет урезаный функционал без TR-101 )))) и в 90 процентах можно решить стандарным набором L2 А теперь м

Ну так лямбда же занята!

Ну вы тоже выдыхайте - ОТТ штука тоже не дешевая в изготовлении.