Перейти до

Bdcom P3310 option 82 replace, keep


Рекомендованные сообщения

Пытаюсь внедрять опцию 82 на ПОНе. Пон у нас гибридный. Т.е. за онушкой может быть управляемый свитч(вплоть до 3120SC).

 

Оказалось что голова опцию 82 заменяет на свою. Нигде не могу найти возможность, делать "keep".

 

Есть соображения?

Ссылка на сообщение
Поделиться на других сайтах

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

Відредаговано prototip
Ссылка на сообщение
Поделиться на других сайтах

Ну так и в чем проблема то ?  Ту онушку , что работает на клиента в один влан , а ту что на ящик - в другой влан . Опт 82 бдкома работает на влане в котором онушка на клиента , а второй влан живет себе без опт 82 бдкома , там опт82 лепит ваш говнолинк аля 3200-...  И залетает  это все как правило на какоето там сисько аля 3700 , где вы можете и keep.... В третий влан можно еще и РРРоЕ втулить , еще более "нагибридив"

Відредаговано prototip
Ссылка на сообщение
Поделиться на других сайтах

Прекрасно работает в продакшн более года .

Відредаговано prototip
Ссылка на сообщение
Поделиться на других сайтах

прекрасно все работает, как минимум на стенде проблем не было.

 

что именно?

Ссылка на сообщение
Поделиться на других сайтах

 

прекрасно все работает, как минимум на стенде проблем не было.

 

что именно?

 

 

 

Схема гибрд pon\fttp наверное.

 

vlan 1,2,3,4,5,6,715,741-743,1000

!
ip dhcp-relay snoopingip dhcp-relay snooping vlan  715,741-743
ip dhcp-relay snooping information option format cm-type
ip dhcp-relay agent
ip dhcp-relay helper-address 172.16.1.1 vlan 715,741-743
!

Вы просто указывайте для каких вланов инкапсулировать 82 опцию на самом OLT-е для ONUшек юзерских, а те что для свитчей просто пропускаете "прозрачно".

 

Ссылка на сообщение
Поделиться на других сайтах

 

но ведь у бдкома dhcp snooping включеный на одном влане автоматом врубается на всех вланах

Хм, у себя не замечал такого. 

 

в теме ua-pon было обсуждение об этом, щас врятле найду пост, но это reaminator_ua подтвердил

а поведение keep/replace с какой-то прошивки должны были допилить, тоже в ua-pon обсуждалось

Відредаговано l1ght
Ссылка на сообщение
Поделиться на других сайтах

Сам придумал или книжек сташных начитался аля "на всех вланах" ....  Не вносите смуту , все там работает , а вот ежели хотите приморочки  аля  keep , replase  так написано выше че делать 

Відредаговано prototip
Ссылка на сообщение
Поделиться на других сайтах

Сам придумал или книжек сташных начитался аля "на всех вланах" ....  Не вносите смуту , все там работает , а вот ежели хотите приморочки  аля  keep , replase  так написано выше че делать 

дорогой, то что память короткая или рюмка на тебя так влияет - моей вины нет

включение снупинга сразу во всех вланах

политика разбора dhcp пакетов головой bdcom

Ссылка на сообщение
Поделиться на других сайтах

Теоретики, лучше бы проверили, реально ли на ваших прошивках такое поведение.

мне опция 82 нафиг не упала на бдкоме

если нужна вешаю в точке терминации (на циске)

Ссылка на сообщение
Поделиться на других сайтах

 

Теоретики, лучше бы проверили, реально ли на ваших прошивках такое поведение.

мне опция 82 нафиг не упала на бдкоме

если нужна вешаю в точке терминации (на циске)

 

И шо, влан на онушку и выдача адреса только на основании номера влана ?

Ссылка на сообщение
Поделиться на других сайтах

 

 

Теоретики, лучше бы проверили, реально ли на ваших прошивках такое поведение.

мне опция 82 нафиг не упала на бдкоме

если нужна вешаю в точке терминации (на циске)

 

И шо, влан на онушку и выдача адреса только на основании номера влана ?

 

ну у меня да, пара remote-id циски + номер влана

Ссылка на сообщение
Поделиться на других сайтах

Сделал отдельный влан. прогнал юзера до dhcp сервера 

 

 

Jan 4 16:06:42 123 dhcpd: DHCPDISCOVER from 14:cc:20:d5:dd:d1 (TL-WR841N) via eth5.82
Jan 4 16:06:42 123 dhcpd: DHCPOFFER on 10.2.2.157 to 14:cc:20:d5:dd:d1 (TL-WR841N) via eth5.82
Jan 4 16:06:42 123 dhcpd: ***
Jan 4 16:06:42 123 dhcpd: *raw option-82 info is CID: 0.4.0.82.0.6 AID: 0.6.54.e6.fc.a2.bf.47

 

И так по циклу. DHCPDISCOVER - DHCPOFFER

 

соответственно ip не присваивается.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від Rakim
      Продам кабель оптичний RCI S-CFP(NA)Fda-001 E9/125 - 1 волокно, на підвіс, діелектрик. Новий, в бухтах по 2км. Ціна - 4грн/м. Можливий продаж від ФОП.

    • Від Rakim
      Продам оптичні бокси Crosver FOB-04-16. Нові. Ціна - 400грн/шт. Можливий продаж від ФОП. 
       
      Продам оптичні бокси Crosver FOB-05-24АH. Нові. Ціна - 450грн/шт. Можливий продаж від ФОП. 



    • Від Rakim
      Продам затискач натяжний анкерний H3-SN (нові). Ціна - 9грн/шт. Можливий продаж від ФОП. 
       
      Продам затискач натяжний анкерний H3D (нові). Ціна - 12грн/шт. Можливий продаж від ФОП. 
       



    • Від Emanon
      Приветствую форумчан. Есть проблема и суть ее такова:
      В топологии одной провайдерской сети сделали определенные изменения. Некоторые access-коммутаторы (edge core ec3528M) в домах, решили подключить по gpon-у. Тоесть, если ранее все это дело шло ветками от одного свича к другому, то теперь ответственность, за их агрегацию , частично лягла на olt bdcom gp3600.
      Если схематически : свич -> onu -> olt -> свич агрегации -> bras (accel ipoe) ну и далее уже в ядро. Onu кстати - bdcom gp1701. Вопросы о том, зачем все это и насколько целесообразно - можно оставить для другого разговора.
      А пока что хотелось бы в кое чем разобраться. Недавно, начали идти заявки от НЕКОТОРЫХ абонентов одного и того же дома с одного и того же узла с жалобой на нестабильный интернет. Это через неделю-две после изменения топологии и соответственно, переключения их коммутатора к pon-сети.
      Техник, осмотрев происходящее, заявлял что рандомно, раз в минуту-две, начинаются потери пакетов. Проверял целостность линий,  подключался напрямую ноутом. Результат один и тот же. Линк между свичом и роутером не падает. Не падает линк и между onu и свичом. Проблем с режимами (half duplex, full duplex) портов тоже не было. Если уже далеко зайти, сам домовой свич, olt, коммутатор агрегации, без проблем пингуются (правда находятся в отдельном управляющем vlan). Очевидные проблемы, вроде роста cpu и утечек памяти, в их работе не наблюдались. В логах все чисто. В мониторинге видно, что канал не нагружен (download и upload не превышают 250 Мбит как по pon так и выше, нет аномальных значений pps как для broadcast, так для unicast и multicast). Да и для остальных пользователей, кроме проблемных, не было вопросов. У всех вроде работает, кроме некоторых ребят с конкретного узла. Трасса упорно показывает, что проблемный участок как раз между роутером и bras. Логи на роутерах тоже ничего вразумительного не пишут. При этом, стоило подключить вместо абонентского tp link archer ax12, c64 или keenetic titan, какой то древний роутер, вроде dlink dir300 или tp link tl-wr841n, как все работало стабильно, без потерь. 
      Со стороны bras сессии не рвутся, но через tcpdump действительно обнаруживается, что при пинге ( как 32 байта, так и побольше) часть icmp пакетов от проблемных абонентов не доходит. 
      Менялись mac  абонентских устройств, пытались найти mac flapping, менялся mac aging, менялся абонентский ip. Без результатов. Mac таблица за onu не забивается кстати, там не более 8 устройств. Проверялись оптические уровни. Конечно, onu rx -24 и olt rx -26 - это уже почти на грани. 
      И наверное это отчасти играет роль. Но нюанс с тем, что происходит при замене роутеров, заставляет задуматься. Возможно то, что такое вылезло именно после перехода на gpon - это совпадение. Но есть подозрения, что связь все таки есть. И проблема довольно странная, ранее не встречал.
      Ещё стоит сказать, что это далеко уже не первый домовой свич, подключенный по такой схеме. Но проблема пока вылезла именно тут. В общем, хотелось бы услышать мнения опытных ребят, с чем конкретно связаны проблемы.
      Прошу не судить сильно по части некоторых решений и высказываний. Я пока не имею солидного опыта и большого багажа знаний. Но буду благодарен за помощь
    • Від pytnik82
      продам по 350 грн



×
×
  • Створити нове...