Ser

Подскажите, кто знает. Возможно ли настроить интерфейс клиента, чтобы одновременно работало - инициация сессии по src IP и dhcp-relay op82 (forward-only)?

@orlik Тогда подробнее.. У нас в сети используется qinq влан на клиента svid.cvid сейчас сделано на linux-bras, но хотелось бы переехать на MX Хочется в клиентском влане слушать dhcp-discover/request и пересылать вставляя в op82 текст cvid.svid Клиент может получить, если захочет так адрес или не получить, если сам себе впишет адрес. Есть такие юрики, чтоб им нужен белый адрес, который они вписываю сами. А уже аутентификация, тарификация и тд по src-ip первого пакета и последующих. Мне кажется схема универсальная и лаконичная. Я не понимаю почему нужно категорично делить dhcp или нет dhcp. Мне нужно dhcp-relay с forward-only, а сессии в джунике по src-ip. Да. именно так, но вставлять op82. Так возможно?

@orlik Не совсем так. Мне нужен L2 BRAS Аутентификация по src-IP И просто dhcp-relay op82 без каких либо авторизаций и тд. ПРОСТО пересылка пакетов и вставка OP82. Суть в том, чтобы клиенты могли получить адрес и первый пакет прошел аутентификацию. Клиенты могли сами вписывать себе ip-адрес на роутере. В нашем биллинге ip-адреса статические и никогда не меняются. за исключением когда клиенту меняется адрес на белый и обратно. Я даже согласен заранее все интерфейсы на клиентов создать заранее.

@StSphinx Клиенты L2 connected, инициация сессии по src IP(без DHCP). А как в таком случае сделать dhcp-relay на джунике? Для меня было бы идеально инициация по src-IP и просто dhcp-relay op82 как вспомогательная функция в каждом влане до клиента. Возможно такое?

Спасибо. /var/lib/unbound/root.key идет в комплекте при установке пакета?

А можно конфиг боевой unbound увидеть?

Спасибо. Поставил servfail-ttl 10; теперь 1 раз в 10 сек у клиента долгий ответ в 10 сек. Может другие dns сервера умеют в фоне делать рекурсию, а клиенту отвечают ВСЕГДА быстро?

Первый и последующие запросы ведут себя одинаково - 10 сек вот конфиг options { directory "/etc/bind/zones"; listen-on port 53 { х.х.х.х; 127.0.0.1; }; notify yes; check-names master ignore; check-names slave ignore; check-names response ignore; max-ncache-ttl 600; recursive-clients 20000; allow-recursion { none; }; listen-on-v6 { none; }; };

Помогите BIND9 настроить. чтобы он отвечал быстро на подобные запросы.

Всем привет. Помогите правильно настроить BIND9 для роли обычного кеша для клиентов. 8.8.8.8 отвечает за 38 мсек. А мой сервер отвечает с паузой 10 сек. Как сделать, чтобы BIND9 отвечал быстро. # time dig @8.8.8.8 www.tvzavr.ru ; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @8.8.8.8 www.tvzavr.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29158 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.tvzavr.ru. IN A ;; Query time: 38 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Чт янв 19 08:20:00 MSK 2023 ;; MSG SIZE rcvd: 42 real 0m0,063s user 0m0,013s sys 0m0,009s # time dig @127.0.0.1 www.tvzavr.ru ; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @127.0.0.1 www.tvzavr.ru ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22486 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: d1b8e141441660401d2ed20263c8d310cb15e3794309441e (good) ;; QUESTION SECTION: ;www.tvzavr.ru. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Чт янв 19 08:20:16 MSK 2023 ;; MSG SIZE rcvd: 70 real 0m10,022s user 0m0,008s sys 0m0,012s Лог 08:19:18.136 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.93.34#53 08:19:18.163 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.31#53 08:19:18.187 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.93.33#53 08:19:18.217 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.93.36#53 08:19:18.240 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.33#53 08:19:18.272 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.36#53 08:19:18.303 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.34#53 08:19:18.344 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.93.31#53 08:19:18.375 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.30#53 08:19:18.414 info: REFUSED unexpected RCODE resolving 'www.tvzavr.ru/A/IN': 89.104.95.35#53

спасибо, попробую прикрутить щас

Привет всем... Накрылся медным тазом модуль платежей от UTM Netup Пишет в логах valid since: "11:10:39 16 Янв 2018 MSK" and till: "11:10:39 21 Дек 2022 MSK". и отказывается работать. Тут надо или сломать этот модуль Либо перейти на php по приему платежей. У нас используется простой протокол ОСМП Может есть у кого скрипт php по разбору параметров get и выполнению бинаря самого платежа? Помогите...

Спасибо. Попробую разобраться.

А мне бы для монтажников нужно в чате телеграмм писать только Recent Alarm. Если данный список изменился, то удалять все записи в чате и писать новый обновленный список аварий. Есть идеи как это можно реализовать?

Думаю, проблема в том, что пакет на продление лизы отсылается клиентом на ip dhcp сервера UNICAST-пакетом. Вам нужно просто разрешить прохождение этих пакетов туда и обратно. Может маршрутов не хватает. К примеру, свичи snr не перехватывают unicast-пакеты и не добавляют Op82. А вот свичи длинки перехватывают любые пакеты dhcp. Я тоже долго боролся и в итоге сделал лизу на 10 суток и перерыв связи на время продления стали редкими и клиенты не жалуются.