passer

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

Гуглится по epon dba algorithm, но на аглицком.

А в чем сложность? Абы напряжение и разъем подходил. Взять подходящее (12В 0.8-1А) и пользоваться. Нагуглится минут за 5.

Настройки на дебилинке какие? vlan, lacp, link_agg и все что еще посчитаете нужным.

Обсуждалось. Сравнили цены и постановили: онушка+роутер(какой нравится) будет дешевле и доступнее.

Описано дважды: в рекомендациях по настройке у Влада и в официальной документации. Ключевое слово protected. Дальше сами.

Это еще смотря какой DES-3200. На ревизии A1 у меня с некоторыми вендорами не взлетело.

Тьфу - а зачем олт пинговать? В чем он провинился?

Телепаты в отпуске, поэтому определить что в ваших настройках нереально без вашей помощи. Возможно это ваш случай: http://local.com.ua/forum/topic/55942-высокий-пинг-на-хосты-за-onu/

После первой команды следует сообщение олта о том, что онушка ушла в ребут, а потом дождаться пока она зарегится и прошить второй раз. Какой-то странный вывод у вас.

Перегружать онушку не надо. Сама перегрузится после прошивки. epon update onu image onufw.bin interface EPON0/1:1 epon update onu image onufw.bin interface EPON0/1:1 epon commit-onu-image-update interface EPON0/1:1

На счет порта порта онушки не уверен, возможно ли такое у bdcom. С микротиком не знаком, поэтому могу подсказать только где и как получить некоторые данные из опции82, но реализацию не подскажу, но по-моему микровтык такого не умеет.

А что надо-то сделать?

Процы в комплекте или это радиаторы просто установлены?

Эм, а как 400kpps получится на гигабитном сетевом интерфейсе на живом трафике если средний размер пакетов не менее 600байт обычно? У меня выходило 130-140kpps (in+out до 250kpps) на гигабитном интерфейсе забитом в полку.

Кстати, кто-нибудь делал уже NAT на Xeon e3-12xx и 10G? Сколько pps, сессий (желательно с указанием поколения проца) вытянул?

Да не умирают 574 на 600М. Хотя от проца много зависит. У меня неделю 2 lacp'а 574+579 и 576+576 грузились на 1.6-1.7G, потом снял часть трафа, что полки не допускать. Процессор e3-140v2.

Отловить пару кошек и кота и оставить в качестве грелки. Или лампочку Ватт на 20-30 рядом повесить: и светлее и онушке теплее.

Так что не уверен, что автору поможет сей свитч.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB22943&actp=search&viewlocale=en_US&searchid=1299714873379 Это табличка с описанием алгоритма хэширования на джуниперах. Меня в свое время весьма порадовало

Решение на базе этой фигни технологии я уже видел. Продаются якобы в России. Но как выше написал тема не подразумевает транскодирование потоков, а, значит, и нагрузка на проц в разы меньше.

http://software.intel.com/forums/topic/386795 Но в контексте данной проблемы речь о перекодировании не идет. Фактически это переупаковка того же потока что пришел.

Ваабчетто у intel есть акселератор для кодирования mpeg2 и mpeg4 h.264 и с ним можно больше навоевать, но без испытаний о никакой оценке речи быть не может. А мой конфиг был для других целей.

Почти 82576EB, но без какой-то поддержки IPsec. И разница таки описана в даташите на 82576.

Во во. Знать бы характер трафика, возможно хэш по l4 поможет. А учитывая, что d-link дает свое железо на тест - можно с него начать.