Jump to content
Калькуляторы

olafff

Пользователи
  • Content Count

    10
  • Joined

  • Last visited

About olafff

  • Rank
    Абитуриент

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Доброго всем дня! Извините за возможно глупый вопрос, но может кто подскажет как сделать так, чтобы не слетали привязки онушек к номеру порта после смены епон порта.. Дело в следующем, подключаю онушку fcfa.f7c5.ab30 на epon0/1 с ручной аутентификацией, авторизую ее к примеру на 1 порт - epon bind-onu mac fcfa.f7c5.ab30 1 Если эту онушку теперь переподключить на epon0/2, причем чисто физически, не авторизуя, то вышеуказанная связка на epon0/1 в конфиге сразу затирается. Как же запретить затирать записи или менять номер порта для онушек в подобных ситуациях? Кто знает как решается данный вопрос?
  2. Доброго всем дня! Только решилась одна заморочка с OLT BDCOM 3608, как тут же вылезла другая. Настраиваем связку UTM5 + BDCOM 3608 + OPT82 с авторизацией клиента по маку ОНУ-шки, номеру влана и порту ОЛТ-а. В конфиге включаю: ip dhcp-relay snooping ip dhcp-relay snooping vlan 100 ip dhcp-relay snooping information option format hn-type ip dhcp-relay snooping log где vlan 100 - клиентский влан. в профиле оборудования (нашел в сети) для DBCOM на опцию 82 прописано следующее: Remote-id - тип бинарный, расположение agent-remote-id, смещение 2, длина 6 Порт - тип бинарный ЛЕ, расположение - agent-circuit-id, смещение 6 , длина 1 vlan id - тип бинарный БЕ, расположение - agent-circuit-id, смещение 2 , длина 2 Но в логах: option [dhcp-message-type]: 01 option [dhcp-client-identifier]: 0100e04c360459 option [host-name]: l option [dhcp-class-identifier]: MSFT 5.0 option [dhcp-parameter-request-list]: 010f03062c2e2f1f2179f92b option [relay-agent-info]: 010500d8000c0102069845622ae9d3090d00000cf808010653769746368 Feb 14 16:15:14 ?Debug : 3fefe700 BindingManager: mac: 98:45:62:2a:e9:d3 switchid: 5 port_id: 1 vlan_id: 100 Feb 14 16:15:14 ?Debug : 3fefe700 BindingManager: binding #38 MAC not matched Мак онушки - option [relay-agent-info]: 010500d8000c0102069845622ae9d3090d00000cf808010653769746368 Если я правильно понимаю, то смещение у него 9, длина 6, прописывал и так в профиль, но та же ошибка. Предполагаю, что проблема все же с профилем, может кто уже настраивал подобное и подскажет где ошибочка?
  3. да, добавление роута решило этот вопрос, запросы посыпали на dhcpd сервер, спасибо за подсказку!)
  4. интересный момент, сейчас добавлю маршрутик. отпишусь по результату, спасибо.
  5. А почему он должен идти на 172.20.0.216? Разве ему не достаточно видеть 192.168.0.40 на "аплинк" порту?
  6. Та же проблема, OLT релаит запросы от клиента броадкастом, как заставить работать его юникастом ума не приложу(
  7. Люди добрые! Где скачать этот гребанный Relaying? По этой ссыле http://deineka.net/2010/12/06/relaying-multicast-v-http-i-obratno/ только бла-бла, а линк то на скачку где? Кто может расшарить или дать ссылочку на скачивание?
  8. Инфа для провайдеров, что выбирает себе биллинг. Мы купили себе NETUP пару лет назад, функционал конечно у него не плохой, хотя подобные вещи есть сейчас почти в каждом биллинге, но вот саппорт и его работа - это нечто конченное!!! Фактически ни один вопрос даже при платной поддержке не был решен со стороны компании! Все баги, что были изначально с момента покупки до сих пор не пофиксили разработчики! Общение с клиентами снобское высокомерное с высока. Поэтому если вы все таки решили приобрести подобные биллинг - будьте готовы, что допиливать вам придется его самим, а баги воспринимать как некие изюминки данной системы. Вообщем настоятельно не рекомендую, особенно для задач с ipv6 и dhcp+option82 авторизации, вытреплете себе все нервы да и только, если у вас только dial-up для абонов, то данная система вполне подойдет, хотя большая часть биллинга на данной услуге тупо не работает!) Надеюсь кому-то этот пост поможет предотвратить страшное))