Мак приставки прилетит в том случае если ОНА САМА будет запрашивать адрес (режим роутера), а не клиент который сидит за ней (ваш случай с режимом бридж).

Это и ежу понятно.
Но по сути это не "мак приставки", мак dhcp-клиента.

И какой смысл его иметь в опции82 я категорически не понимаю.

Пример: NTU-SFP воткнутая в управляемый коммутатор в порты которого подключены клиенты это как один из вариантов

Мак клиента и так есть в запросе.

Я лично считаю что это баг

А что за биллинг если не секрет?

Наколенный с фрирадиусом

Ну тогда какая проблема выдавать адрес основываясь не на мак адресе, а положим на основания ip olt, gpon port, ont id? Я так делал, на случай ntu-sfp можно дополнительно мак проверять. Гораздо более гибко выходит

Речь была о том что работает не так как должно

а вы любите старый софт?)

Добрый день, коллеги!
Тестирую Eltex MES7048 - столкнулся с проблемой, L3 интерфейсы на физических портах не хотят подниматься. Может быть кто-то знает в чем может быть проблема?
Ip routing глобально включен, routing на интерфейсе тоже. Физический линк, разумеется, есть.

sw-eltex-stack#show running-config interface 1/0/2

!Current Configuration:
!
interface  1/0/2
no shutdown
routing
ip address 192.168.10.1 255.255.255.0
exit
sw-eltex-stack#show ip interface 1/0/2

Routing interface status....................... Down
Primary IP address............................. 192.168.10.1/255.255.255.0
Method......................................... Manual
Routing Mode................................... Enable
Administrative Mode............................ Enable
Forward Net Directed Broadcasts................ Disable
Proxy ARP...................................... Enable
Local Proxy ARP................................ Disable
Active State................................... Active
Link Speed Data Rate........................... 10000 Full
MAC address.................................... E8:28:C1:AE:C6:03
Encapsulation Type............................. Ethernet
IP MTU......................................... 1500
Bandwidth...................................... 10000000 kbps
Destination Unreachables....................... Enabled
ICMP Redirects................................. Enabled
Interface Suppress Status...................... Unsuppressed
Unicast Reverse Path Forwarding Mode........... Disabled
Unicast Reverse Path Forwarding Allow-Default.. False

Здравствуйте! Такой странный вопрос у меня. В сети 60 телефонов qtech qvp-90p. Настройки у всех идентичны. Ставим телефон в один кабинет, через некоторое время перестает работать трубка. Громкая связь работает. Меняю телефон, через некоторое время та же история, трубка молчит. Телефон который забрал из того кабинета работает на новом месте. Что это может быть? Место проклятое?

Коллеги, добрый день! Подскажите, можно ли настроить между TAU-4M.IP и CUCM обычный sip-транк? Без регистраций. Цель - из центрального узла (CUCM) звонить в удаленные узлы (поставить там TAU-4M.IP) ну и в обратную сторону. Со стороны CUCM всё понятно - настраиваешь sip-trunk  c destination в виде ip-адреса TAU, диал-план и так далее. А вот на стороне TAU как ? Примет ли он звонок по SIP со стороны CUCM на свои FXS-порты? И в обратную сторону  - можно ли на нем прописать что-то типа dial-peer .T  в сторону адреса CUCM ?

попробуй в плане набора что-то типа 1[0-6]x@ipaddr. где ipaddr, адрес станции

это для исх связи

искать такие номера вот на таком ip

вроде все тау такое могут

питание проверь там

То есть на тау прописываем на fxs портах короткие номера типа 3001 и 3002, делаем маршрут в сторону кукма и оно звонит? Это было бы прекрасно. Просто эти тау еще в руках не держал ни разу.

вы хотите просто внутреннюю связь без выхода в город сделать?