tux-tm

Организовали балансировку - каждый рекурсор из пула получает лишь часть запросов, которые клиенты шлют на IP балансировщика. Двухуровневое кеширование - это не обязательно и вначале работало без него, но кеширование на балансировщике очень хорошо снижает кол-во запросов далее на рекурсоры, а следовательно и нагрузку. Устаревание в кеше - по факту на балансировщике обычно первее т.к. на нем настройка ограничения по максимальному времени кеширования и выставлено время небольшое. До внедрения балансировщика схема была именно как Вы описали - просто 2 кеширующих рекурсора (Unbound тоже пробовали), при этом бывали периодически случаи что в Сети какие-то DNS блокировали часть запросов с IP одного из рекурсоров. И конечно же клиенты по большей части шлют запросы на первый из выданных IP-адресов DNS. В результате - перекос по загрузке примерно 4:1 первый и второй DNS Unbound ранее неоднократно подводил, в итоге не используем. Сейчас точно не вспомню, но вроде как переставал отвечать и требовался перезапуск процесса. Ещё ранее использовали решение из пакета djbdns - dnscache. Простой, надежный, быстрый, но IPv6 тогда там был только в виде сторонних патчей, сейчас не знаю как у него с IPv6. Резервирование - не менее важно, причем, как тут уже писали, роутеры абонентов часто второй DNS даже не используют. Ну а подход "пусть клиентский софт сам с этим разбирается." - точно не добавит симпатий клиентов к провайдеру. 3-й и далее адрес DNS далеко не весь клиентский софт воспримет, не говоря уже про BNG/BRAS и т.п. Огромное спасибо! Сам бы и не догадался.

Опечатался, по факту так "Каждый из рекурсоров балансировщиков DNSDist обращается минимум к 2-м рекурсорам ..." Алгоритм выбора рекурсоров - leastOutstanding, в настройках есть и другие варианты алгоритма. p.s. На этом форуме у меня почему-то не работают кнопки "цитата" и "ответить с цитированием". Пробовал разные браузеры - реакция одинаковая, все кнопки имеют ссылку вида "https : // forum.nag.ru /index.php?/topic/188617-strannosti-v-dns-u-abonentov-dnsdist/page/2/#" При нажатии показывает верх темы и никакой цитаты не делает, только вручную приходится делать.

Зачем умножать нагрузку и задержки в разы??? Балансировщику достаточно получить ответ от любого - первый не ответил, зато второй ответил и дальше нет смысла спрашивать "все 6 шт например". А вы на нем кеширование точно включали? Без кеширования (в дефолте не включено) - будет и тормознее и загрузка больше.

Не совсем понимаю что именно имеется ввиду под "пересылать всем"? И что именно внимательно наблюдать? В переходных процессах с недоступностью/переключением сервисов, как например если IP резервируется по VRRP (в моменты "переезда" виртуального IP, если предположим мастер-сервер ушел в перезагрузку) какие-то запросы от абонентов естественно могут быть и не обработаны. Допустим ответа не поступило, но ведь хосты умеют перезапросить, это не смертельно и бывает раз в несколько месяцев. Задача ведь в том чтобы максимально зарезервировать сервис на случай локальных форс-мажоров (иногда и подсети могут отвалиться и железо не вечное и не безгрешное на нем ПО) и для возможности безболезненного вывода частей сервиса на обслуживание. В большой сети какой-то подобный переходной процесс с 0,1% необработанных запросов в течение пары секунд, который происходит раз в пару месяцев (допустим перезапускали виртуалку с рекурсором) - это настолько несущественный фактор, что реально его никто не заметит, тем более что одновременно на обеих выданных адресах DNS такое не происходит (ситуации полного фолрс-мажора не рассматриваем) А вообще кто какое решение использует в качестве DNS-балансировщика? Прям интересно стало. С 2017 года примерно искал софт для DNS, который можно из коробки использовать под IPv6 и плюсом чтобы автоматизировать рутинные операции с изменениями записей в зонах DNS. (а не лезть каждый раз и ручками править файлики и потом указывать процессу демона "перечитай конфиг") И на тот момент решения от PowerDNS устроило более чем на 100%. Там есть и рекурсор и авторитетный DNS и балансировщик. Есть еще и WEB-интерфейс PowerAdmin (отдельное решение) для работы с записями зон. Ну и в принципе можно хоть пачкой записи менять скриптами - это же просто записи в БД, всё на лету делается. Все эти решения на базе PowerDNS из коробки прекрасно работают с дуалстэком (IPv4 + IPv6). Для нас это важно т.к. по факту 25-30% абонентов реально используют дуалстэк в нашей сети. В этом плане из ШПД-провайдеров в РФ - мы по факту лидируем, больше процент только у сотовиков и хостингов по понятным причинам. p.s. А dnsmasq - это разве балансировщик с пулом рекурсоров? Я просто сам не использовал, но по той же википедии - это какой-то комбайн "всё в одном" для небольших сетей. "Dnsmasq — легковесный и быстроконфигурируемый DNS-, DHCP- и TFTP-сервер, предназначенный для обеспечения доменными именами и связанными с ними сервисами небольших сетей"

"Я не вижу профита от DNSDist в сравнении с Unbound." Ну не знаю почему, профит там очень хороший если использовать по назначению. Потому что Unbound - комбайн, в данном случае рассматривается это как рекурсор (вероятно кеширующий), так? А DNSDist - это балансировшик рекурсоров, и причем лучше его использовать тоже с кешем, хоть и не большим. DNSDist - это буфер-пушка по производительности и обеспечение непрерывной работы DNS-резолвинга в сети. Ставим парами DNSDist с резервированием по VRRP, т.е. у них общий мигрирующий IP и это дает свой профит, например с теми же роутерами "с памятью на один DNS адрес" Каждый из рекурсоров (опечатался имелся ввиду балансировщик DNSDist) обращается минимум к 2-м рекурсорам (у нас их больше), неважно к каким - PowerDNS Recursor (мой вариант), Unbound(тоже пробовал, но после очередного обновления периодически начал подвисать), другие на вкус. Можете публичные DNS указывать но при этом на балансировщике кэш обязателен (в дефолтном конфиге его нет). Все рекурсоры и балансировщики территориально разнесенные, а не на одной площадк - это прибавляет выживаемости в целом. В итоге можно не бояться повисаний отдельных рекурсоров, вы можете выводить из работы любой из рекурсоров и любой из балансировщиков - никто этого не заметит вообще. NS-сервис становится непрерывным даже при обновлении ПО, перезагрузках и т.п. так как они не одновременно делаются. А т.к. балансировщик сам ничего не резолвит рекурсивно, а лишь передает эту работу рекурсорам и после кеширует полученный от них результат - его заDDoS-сить очень сложно, он из памяти выплевывает почти полностью сформированный закешированный пакет в большинстве случаев. Ещё там можно очень гибко настраивать пулы рекурсоров, пулы клиентов и т.п. и по разному отправлять запросы по составленным условиям в ACL. С 2018 примерно года DNSDist используем - никогда не подвисал и не подводил. Под 100к один активный рекурсор обслуживает не напрягаясь. от 100к сессий абонентов обрабатывается примерно 20-30к запросов в секунду, загрузка CPU (4 ядра далеко не топового Интела в виртуалке) - около 40%. Подобного как у автора топика - ни разу не видели. Поскольку IP-адрес выданного абонам DNS никогда не умирает за счет VRRP - нет проблем с роутерами, использующими только один из выданных DNS. В целом с DNS бывают вопросы редко и в основном точечные, и как выясняется каждый раз - по причинам не имеющим отношения к балансировщику. Обычно из-за рукожопов-владельцев зон DNS, кривой работы ТСПУ, РКН и прочего.

Великолепно описано.В своё время более 12лет назад настраивали MSTP на связке D-Link + ExtremeОчень не хватало адекватного описания как это делать. Грабельки собрали еще и потому что у вендоров есть нюансы и докучи собрать все не всегда получается

столкнулись с проблемой когда не работает на порту это switchport mac-address dynamic maximum 1 и показывает 6 МАС-ов с отличием в последней цифре SNR-S2990G-48T#sh mac-address-table int Ethernet1/0/48 Read mac address table.... Vlan Mac Address Type Creator Ports ---- --------------------------- ------- ------------------------------------- 948 04-8d-38-8d-d3-40 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-41 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-42 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-43 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-44 DYNAMIC Hardware Ethernet1/0/48 948 04-8d-38-8d-d3-45 DYNAMIC Hardware Ethernet1/0/48 Обновление до свежей версии ничего не дало SNR-S2990G-48T Device, Compiled on Oct 26 16:35:51 2021 ... SoftWare Version 7.0.3.5(R0102.0318) BootRom Version 7.1.41 HardWare Version R01 Починил при добавлении в конфиг mac-address-learning cpu-control Но это наверное не самый лучший вариант решения.

Спасибо за оперативный ответ - заработало по вашей рекомендации. Настройки сбрасывал когда первый раз накатывал, и перед откатом их в файлик слил, теперь снова из файлика вернул и поправил. Может Apple и исправили этот баг в новых ОС, но я не в курсе т.к. пользую еще 10.9.5 релиз. Обновиться не могу до последнего релиза по ряду причин, одна из решающих - глаза не выносят новомодный контрастный и плоский GUI...

Broadcom BCM43xx Ща еще раз накачу прошивку и проверю...

Обновил дуалбендовую модель на версию 4.8.17 и получил блокирование любого трафика через 5Ггц WiFi, хотя к беспроводке как и раньше цепляется, DHCP-адреса и даже IPv6 получает. Но ни сама железка и что-то далее за ней даже в LAN-сети недоступно. Через LAN и WiFi 2.4Ггц - нормальная связь. Причем даже со сбросом всех настроек такая хрень на открытых дефолтных SSID. Клиентский девайс MacBook, если это критично... Откатил прошивку на 4.6.8 - снова заработало.

Писать почти бесполезно. Это чистый Китай.

Спасибо, это и было причиной. Замотался и некогда было проверить. Девайсы отлично заработали после отключения мультикастовой обработки на CPE.

Коллеги, скорее всего у меня не чистый Миракаст, почитал и понял что там такой зоопарк в этих донглах - EzCast, AnyCast, MiraScreen(у меня такой) и т.д. Так что пока не напрягайтесь, сначала я помучаю сам девайс, комбинации настроек и т.п.

Тестировал всё в одном диапазоне - 2.4Гц, хотя конечно пробовал и в разных диапазонах Miracast - на 2.4GHZ, Nexus5 - на 5GHZ. Разницы никакой - точно так же Miracast сначала определяется, но после кратковременного коннекта сразу же отваливается. IP адресация была одинаковой как на старом роутере TP-Link WR1043ND HW ver1.0 , так и на D-Link DIR-620 (оба прошиты в OpenWRT 15.03) - подсеть везде одна и та же 192.168.10.0/24. Так что дело точно не в этом. И еще когда оно работает, то и Miracast (в виде HDMI-свистка в телевизоре) и Nexus одновременно имеют доступ в Интернет через роутер (TP-Link WR1043ND). То что этот протокол на стадии старта реализован через L2 и броадкаст - какие сомнения? ведь оно работает без внешнего DHCP-сервера. Там же сами устройства выступают в качестве DHCP-сервера, а DHCP-протокол как известно начинает свою работу c обмена броадкастовыми пакетами DHCP-Discover, DHCP-Offer. К тому же на стадии обнаружения Miracast устройств в сети IP-адреса WiFi-роутера точно не используются. Для WiFi-роутера весь этот трафик уж точно не является L3, но как-то же его присутствие в качестве AP эту связь нарушает. Попробую на время отключить DHCP-сервис на SNR-CPE, а не всю AP. Если причина в DHCP - это сработает.

Столкнулся с проблемой отказа в работе протокола Miracast (беспроводной экран) в диапазоне 2.4Гц. Работает оно насколько я понял без IP-адресов, чисто на уровне L2, т.е. по коммутации и наверняка там обнаружение девайса на броадкасте реализовано. Причем обнаружил это при замене старого роутера TP-Link на черненький SNR-CPE-MD1, я так понимаю это MT7610-1T1R-5GHZ ? C TP-Link всё работало нормально, а после замены на SNR подключиться не получается. Что интересно, при попытке подключиться смартфон кратковременно подключается к Miracast и сразу же связь разрывается. Но если перед подключением обесточить WiFi-роутер SNR-CPE-MD1 - то связь устанавливается и работает несмотря на то что телефон Google Nexus5 и девайс с Miracast изначально подключены как клиенты к WiFi точке доступа - всё как по шпаргалке к девайсу. Игрался разными параметрами WiFi - ничего не помогает, ни смена канала, ни стандарт WiFi - b,g,n Не могу сказать баг ли это или требуется какая-то тонкая настройка, но точно знаю что не работает именно с MT7610-1T1R. Совместно с MT7620 2.4GHZ не проверял т.к. пока нет под рукой. С роутером на OpenWRT тоже не замечено проблем. Готов предоставить удаленный доступ к роутеру, или другую посильную помощь. В Сети тезисно описана работа этого протокола так: Используя Wi-Fi direct, устройства находят друг друга (обычно — источник видео-данных находит устройство отображения) Используя ту или иную форму аутентификации (в нашем случае — pbc) устройства объединяются в P2P-группу Одно из устройств получает IP-адрес по DHCP (в нашем случае — это источник видео-данных) На источнике данных на порту 7236 запускается RTSP-сервер Клиент подключается к RTSP-серверу, и запрашивает некий предопределенный URL (/wfd1.0/streamid=0) RTSP-сервер начинает передавать видео (и, возможно, аудио) данные в форме MPEG-TS упакованных в RTP-пакеты. Клиент распаковывает данные и отображает их на устройстве вывода. Может быть связано с конфликтом/блокировкой DHCP-пакетов Miracast и WiFi-роутера ?