fet4

Т.е. с рабочих 3310 берем конфиги ону и на тестовом 36xx вбиваем mac=llid на нужном порту и вносим конфиги без включенных онух, не меняя epon onu-authen-method ?

Кто обновлял загрузчик удаленно?

Так вы пробовали данный вариант?

Предложите ближайшую замену, которая решит вопрос.

Дело в том что сейчас так и работает, но работает не так как нужно мне. Мой edge core 4612 не позволяет менять тип хеширования и он равен EtherChannel, на основе хэш-функции над MAC-адресом, IP-адресом или TCP и UDP портом источника или получателя. В итоге если сравнить два графика, двух портов с этого ЛАГ, то исход с маршрутизатора равномерно балансируется, а вот вход на него идет с большим перекосом. Маршрутизатор выполняет роль браса, там Л2 (pppoe,ipoe) и по идее нужно использовать хэш-функцию только над MAC-адресом, а не IP. Кстати есть еще бордер на этом же свиче там уже Л

Привет всем. Кто-то использовал бондинг в режиме balance-alb? Если да, расскажите конфигурацию? На свитче нужно настраивать агрегацию?

Вы знаете у меня олт перегружался даже когда я ip прописывал в неправильном формате на онушку.

А кто изменял формат строки circuit-id ? Сейчас такое прилетает Circuit-ID 00:06:00:65:00:01:00:0b:01:06:00:e0:b1:be:0b:d9 Remote-ID 00:06:00:e0:b1:be:0b:d9 А хотелось бы типа такого Circuit-ID 00:04:00:65:00:02 Remote-ID 00:06:dc:d2:fc:5c:bf:e8

Прошейся на 46085. Сам использую эту прошивку уже 2 месяца, полет нормальный. Перешивался так же по причине глюков.

Не знаю как у вас, а у нас через минуту пропажи канала уже 30 человек в телефонной очереди. Ну и как-бы пережить 5-минутный лизтайм еще как-то можно, если-бы отвалившийся брас всегда отваливался физически, а такое далеко не всегда. Чаще физические линки браса не падают, оспф маршруты не перестраивает и приходится пинать все ручками. У меня по крону, раз в минуту пингом в 30 запросов/ответов проверяются 2 канала т.к. бгп нет. За минуту люди не успевают начать звонить если один отвалился и все переключились на другой, возможно у Вас больше клиентов. Раньше стояло раз 5 мин., тогда уже появл

Поддержу pablabor, хотя я сам тоже за простоту, за чистый ethernet в том виде в каком он придуман, без лишних "надстроек", но интересно бы было увидеть это горячее переключения, даже Вас послушал бы о достижениях в данной области , интересный ход мысли, т.к. мысли об этом были и если Вы это реализовали у себя то Вы молодец! Вообще стандарта ipoe как такового нет, кто как хочет так и крутит. pavlabor так, другой по-другому кто как видит так и делает. кому как проще. Но все так спорят, доказывают свою точку зрения как будто должно быть так и не иначе, аж страшно В переинициализации сессии в

Как по мне это вообще единственный правильный вариант когда с трафиком работаешь в плотную. qos, шейпинг, nat и т.д. не реально сделать на одной тачке адекватными способами, приходится изощряться разными способами imq,ifb, маркировки, патчинги и т.д. а это уже костыли. А когда это разделено как минимум на 2 тачки, архитектура управления трафиком становится прозрачней и понятней в разы. На железные решения пока смотрю косо т.к. голый Linux удовлетворяет почти полностью и в принципе стабилен, бывают конечно и приколы, например месяц назад NAT на 4.9 начал выпадать в кернел паник проработавши ме

Не смешите мои тапочки. Что я видел по Ленинском району, не думаю что в других районах что-то другое. А именно: - 70% идет сраная белая витуха в окно по крыше обмотанная об Ваши магистрали оптические, тупо сопли по которым стекает вода в порты клиентам. Не знаю как еще жильцы терпят это. - 70 % ящиков открыты и обмотаны той же витухой никакой культуры монтажа ни на крыше ни в подъезде. - почти все rj-45 обжаты на жилы и вставлены в натянутом виде. -2-3 порта точно горелые. Снимите розовые очки.

Чувак выставь тех. задание и найдутся те кто его выполнит, а если не выполнит он будет в "плохом свете" как сейчас ты. На форуме тоже помогут, но нужно с конкретными вопросами обращаться и показывать, что делал и что не получилось.

Почему она должна быть? Он же пишет /dhcpr-database Вы об этой ? #show ip dhcp-relay snooping binding Hardware Address IP Address Surplus Time Type VLAN Intf ----------------- --------------- ------------ ------- ---- ---------- d4:6e:0e:53:d5:2d 10.194.132.24 960 DHCP_SN 132 epon0/4 c4:6e:1f:61:ca:f1 10.194.132.5 1020 DHCP_SN 132 epon0/4 b4:74:43:7b:71:67 10.194.130.49 1380 DHCP_SN 130 epon0/2 18:a6:f7:3b:c1:71 10.194.129.20 1020 DHCP_SN 129 epon0/1 f4:f2:6d:3c:dc:91 10.194.130.10 1020 DHCP_SN 130 epon0/2 d4:6e:0e:96:5

Как вы авторизуете клиента? #show ip dhcp-relay snooping ip dhcp-relay snooping ip dhcp-relay snooping vlan 129-132 ip arp inspection vlan 129-132 ip verify source vlan 129-132 ip dhcp-relay snooping log DHCP Snooping trust interface: g0/1 ARP Inspect trust interface: g0/1 IP source guard trust interface: g0/1 DHCP Snooping deny interface: ip dhcp-relay snooping db-file /dhcpr-database

Не понял тогда вашего вопроса - "А они работают?"

Работают, очищаю периодически не используемые ОНУ. На 33463 цпу так же был в полке потери на олт были огромные, видимо из-за этой проблемы.

Две полные головы по дхцп. Прошивка 46085. Нет вышеописанных проблем. Опции включены.

Скачай startup-config удали с него все кроме нужных конфигураций для доступа к коммутатору vlan,ip,interfaces и тд. Удали все кроме switch.bin и tiger.blob и залей отредактированный startup-config. reboot

Удали все кроме switch.bin и tiger.blob. перезагрузить.

Да я ошибся, есть круглый диэлектрик 2.7 кн ОКТ-д. Рассчитан до 180м

Окадт 2.7кН выдержит все 200м, вы б его видели. Берите не пожалеете, гораздо легче троса на данной прочности.

Version 10.1.0E 33463 не бывает. только BD_3310C_10.1.0D_33463_en.bin скорей всего это лишь их внутренняя нумерация. Я думаю ничего не произойдет если вы перешьете вниз. Я так делал. Но я бы советовал сразу шить BD_3310C_10.1.0E_46085_en.bin

Прошивка 46085 решает вопрос с загрузкой cpu, иных косяков не было замечено.