Сложность заключалась как раз в том, что все точки находятся рядом, практически в одном радиодомене
Мне понравилось где-то увиденное выражение что "раньше wifi строили для coverage, а сейчас для density" . По скриншоту видно что 60% были в 2.4 где мало частот и это действительно проблема, в пятёрке тоже было меньше открыто. Сейчас 90-99% клиентов в пятёрке где частот больше и уже не такая большая проблема "наставить точек плотно" с небольшой мощностью и разнести по частотам. Даже в случае офисных точек без секторных антенн.
Тут тоже есть нюанс что на таких мероприятиях "все меняют ландшафт одновременно с тобой". Сегодня ты сделал идеальный частотный план и расставил частоты руками не полагаясь на автоматику. Завтра ребята на сцене/в зоне NNN влупили какую-то свою балалайку, за час до старта мероприятия смотришь занятость спектра и понимаешь что весь план улетел псу под хвост, надо всё менять:)
1) проблемы с фильтрацией мусора и мультикаста может частично решить dhcp/igmp snooping, сейчас оно встречается даже в недорогих системах типа юбиков.
2) указано 70 AP но на скрине видно 99 :) Как выше уже написали это очень смело на 15тыс клиентов. Даже сейчас на точках wifi 5-6 это очень мало, даже учитывая что занятость эфирного времени на AC/AX меньше чем на N в 2014 году.
Интересно какой пиковый суммарный трафик/какой канал дал оператор. 100Мбит/с?
3) подозреваю что сейчас в масштабах "1-2тыс клиентов" на выездных мероприятиях 7750 и "линукс на сервере" для L3 задач dhcp-nat-шейпинг-немного приоритезации/лимитов можно заменить на какой-нибудь Mikrotik CCR (или парочку - один под управление, второй для пользователей) или CHR накатить на сервак где ядра пободрее и их побольше. Заодно и питания потребуется меньше :)
и одновременно с тобой ландшафты меняют все другие подрядчики-монтажники-строители на площадке, так что вчера смонтированную тобой AP сегодня могут зашить в железную конструкцию/завесить зеркальными материалами/закрыть LED экраном/etc...И так во всём :)
я удивлён потому что по-моему половина QTECH, ZRJ и SNR (кроме их собственных серий 5ххх), сошли с одного конвеера крупного китайского производителя и отличаются только брендированием, ценой и (что немаловажно) наличием/качеством локального саппорта.
Удивлён что в статье есть QTECH и не так давно появившийся ZRJ и нет SNR, у которого есть как железки-близнецы, так и серии коммутаторов полностью собственной разработки, включая модели с ТОРП.
похожее поведение у какого-то популярного dns-клиента-сервера в soho роутерах. Кажется это dnsmasq но это не точно. Там прямо в мануале написано что для скорости ресолва (клиет же не может подождать дополнительные 10мс!!!!) он шлёт запрос сразу ко всем серверам которые знает и довольствуется первым ответом, закрывая сокет. Соотв-но на все остальные пришедшие от днсов ответы линух роутера шлёт icmp port unreach. И авторы не считают это чем-то плохим. Лавров.жпг, как говорится.
очень мало ICMP в которых src ip не совпадает с указанным в icmp айпишником недостижимого хоста. Тех в которых они совпадают процентов 90 а то и все 99. Может быть иногда волнами прилетает несовпадающие (как пул отресолвит кому-то ip моего сервера) но всё-же их мало.
А вот запросов с special purpose адресов хватает. Я у себя смотрел дампы (и сейчас перепроверил). Например дампим два варианта
icmp and net 100.64.0.0/10
port 123 and net 100.64.0.0/10
за минуту мне не пришло ни одного icmp из этой сетки и под сотню запросов на 123 порт. Отвечаем, наш ответ улетает куда-то по роутингу и часто на такой ответ мы получаем icmp о закрытом порте, например. Это одна из причин получения лишних icmp на сервер. Малая часть icmp, на которую мы можем напрямую повлиять со стороны сервера, просто отсекая запросы из таких подсетей.
Ждём когда Яндекс поднимет свои сервера и озаботится проблемой icmp :-)
Таким образом, выглядит это как определённое рукожопие от провайдеров и администраторов конторских сетей - где-то псевдоинтеллектуальный фаервол воспринял это как атаку и начал резать ответы, вместо запросов, где-то администраторы такое же придумали в ручном режиме, где-то могли подрезать размеры таблиц statefull nat для NTP, чтобы NTP их не выжирал, и клиенты хоть как-то жили.
я примерно такого мнения. Насчёт фаерволов и правил, написанных администраторами я думаю что они бы делали просто молчаливый дроп, реджектить с icmp всякий флуд ни к чему. С другой стороны я видел множество весьма странно себя ведущих soho роутеров и уже ничему не удивлюсь. Встречаются экземпляры которые услышав броадкастовый arp reqeuest с адресом не из своей подсети начинают валить в ответ icmp redirect O_o.
Серые/CGNAT и RFC6890 можно смело дропать, отвечать на них не надо (исключение - серые внутри своего провайдера и локалки, да и то можно с ограничениями по ttl).
Надо учитывать что роутинг/форвардинг работает по dst и далеко не все фильтруют src. Поэтому запрос с серым src может прилететь с другого конца шарика. А ответ улетит куда-то к ближайшему по роутингу хосту с таким Ip и будет его "заваливать незапрошенным мусором" на который он тоже может прислать icmp unreach. Поэтому лучше сразу их дропать и не пытаться эти запросы обрабатывать сервером и слать ответы.
Вопрос как в iptables залезть внутрь icmp чтобы считать оттуда какой host unreach (icmp source и указанный в нём host unreach могут отличаться если пакет прибили где-то на транзите) чтобы его тоже добавить в блок и не отвечать некоторое время.
Про чтение ntp'шного rfc - писатели не читатели :) Их клиент по описанию похож на sntp и там может быть что угодно. Я вот rfc тоже не читал. На деле криво заполненные поля запроса это не сказать что прям беда-беда. В то-же время некоторые сервера типа ntpsec могут просто дропать не-RFC'шно сформированные запросы. Значит будут колоночки тупить. Штош.
Для чистоты эксперимента надо всё-же разобраться кто шлёт эти icmp - сама колонка или нет. Пока неясно.
есть уверенность что это именно станция? Дамп снят непосредственно с линка станции? Если нет, это вполне может быть и поведение роутера, а станция внутри за натом ответа так и не получила. Избавиться от этих ICMP на сверере тоже хочется :)
нет, icmp были и до этой и до предыдущей статьи. У меня было около 25% пакетов это icmp port unreachable (кстати они содержат в себе и исходный пакет ntp-ответа что увеличивает объём входящего).
Часть запросов приходит из за NAT с одинаковыми source ip или кривые ntp-клиенты шлют запросы очень часто (типа как Алиса раньше), где-то может быть и дудосы. Часть пакетов приходит от транзитных узлов, как будто "защищающих" того куда сервер ответил (но по идее защита тупо дропает без icmp так что непонятно). В демонах ntp-серверов есть рейтлимитер, ограничивающий ответы на слишком частые запросы с одного ip. Поэтому демон сервера отвечает не всем, дропая часть ответов. Уже поэтому исходящий pps меньше входящего.
В комментариях к предыдущему посту есть правила для iptables (и там-же ниже объяснения их работы) чтобы банить на некоторое время присылающих icmp type 3 + рейтлимитить тех кто шлёт слишком много запросов прямо в iptables, не допуская до ntp-демона.
Стандартной для кварцевых часов является точность в пределах ±20 секунд в месяц, а лучшие из наручных кварцевых часов показывают результат ± 5 секунд в год.
Я думаю что у часов компа точность примерно такая-же, что там что там недорогой "кварц". Как выше отметили - у часов "показывать время" это основная задача и всё-таки подстраивать руками всё равно приходится. У рядового десктопа точность кварца и хода часов не так критична т.к. автоматически подстроить проще. Ну и прям миллисекундная точность на компах не нужна, просто процесс синхронизации довольно простой, поэтому скорее тут руководствуются мыслью "чё бы не подсчитать drift и не стабилизироваться?"
по-моему аппаратный сервер типа Meinberg'а стоит условно 100-300тыр (сейчас может и миллион, но есть наши аналоги), он умеет в GNSS (спутники) и содержит TCXO/OCXO который способен продолжительное время поддерживать точный ход, даже если спутники пропали или выдают чушь. Ну в конце концов цезиевые/рубидиевые источники можно купить у того-же ВНИИФТРИ.
Ставим N штук в кластер, на них завязываем уже машины с ntpd/chrony способные держать гигабиты трафика. Поехали.
вчера тоже про это думал. Ask Bjørn Hansen (админ/вледелец пула) по-моему живёт в США.
В связи с инцидентом и самизнаетечем, Яндекс может родить аналогичный проект национального масштаба. Правда смысла в этом немного, если только у операторов потом сделать pool.ntp.org CNAME pool.ntp.рф но хайджекинг записей это невесело
в той теме о коллапсе пула вчера отписывался сотрудник поддержки с заявлением в духе " колонки ведут себя нормально, просто им нужно очень точное время иначе будильник может зазвонить не вовремя". Конечно, на него слегка накинулись :)
Вчера в netflow логах ещё видел сотни пользователей, генерирующих запросы к ntp каждые 5 сек. Сегодня их уже не осталось. Похоже что да, апдейт докатился до всех. УРА! Нагрузка на пул стабилизировалась, это вижу и сам, об этом в телеге мне отписался администратор ещё одного сервера :)
Остались вопросы:
Я.девайсы примерно каждые 20-30 сек ресолвили DNS-записи [0-5].ru.pool.ntp.org (я видел это своими глазами) + люди писали что колонка периодически запрашивает SOA зоны. Зачем ей это? Может тоже баг?
В твоём топике на хабре также были озвучены предложения к Яндексу:
выделить сервера для общего пула
зарегистрировать в пуле свою vendor-зону для своих дейвайсов (см https://www.ntppool.org/ru/vendors.html). Хотя тут есть и плюсы и минусы. Без зоны есть плюс в том что трафик запросов ходит до ближайших серверов (иногда это будет сервер прямо у провайдера) а не в интернеты на сервера Яндекса.
Вопросы по пулу и трафику в целом:
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp. Это спуфинг или ковровые блокировки ntp-протокола? По идее блокировки делались бы drop'ом без отправки icmp.
Нормальные ntp-клиенты после запуска опрашивают сервер времени часто, высчитывает "уплывание" собственных часов и начинает корректировать свои часы, изредка (обычные настройки по умолчанию - раз в 17 минут) сверяясь с эталоном - внешними серверами. Это нормальный принцип работы ntp, он позволяет поддерживать расхождение времени с эталоном на уровне миллисекунд!!!!
Никакая синхронизация раз в 5 секунд не нужна, это явно косяк или отсутствие мозга у разработчиков. Пожалуйста, подключите к обсуждению вопроса реальных разрабов.
@kkursor, мне московские сервера ВНИИФТРИ перестали отвечать, я думаю что они в последнее время сильно ограничивают активность запросов, замечал что после перезапуска демон до них не может достучаться по несколько часов. Имеет смысл указывать в конфиге только один из серверов ВНИИФТРИ + ntp.msk-ix.ru + использовать больше "облачных"/CND источников, например
server time.google.com server time.facebook.com server time.cloudflare.com
они тоже могут оказаться заблокированными на ТСПУ, интересно что cloudflare отдаёт stratum 3
РКН
закукожилсостарил сервера Google и Viber, сервера WhatsApp ожидают очереди на устаревание.Не понимаю как в топ могут войти SSD на QLC и HDD с SMR.
Мне понравилось где-то увиденное выражение что "раньше wifi строили для coverage, а сейчас для density" . По скриншоту видно что 60% были в 2.4 где мало частот и это действительно проблема, в пятёрке тоже было меньше открыто. Сейчас 90-99% клиентов в пятёрке где частот больше и уже не такая большая проблема "наставить точек плотно" с небольшой мощностью и разнести по частотам. Даже в случае офисных точек без секторных антенн.
Тут тоже есть нюанс что на таких мероприятиях "все меняют ландшафт одновременно с тобой". Сегодня ты сделал идеальный частотный план и расставил частоты руками не полагаясь на автоматику. Завтра ребята на сцене/в зоне NNN влупили какую-то свою балалайку, за час до старта мероприятия смотришь занятость спектра и понимаешь что весь план улетел псу под хвост, надо всё менять:)
1) проблемы с фильтрацией мусора и мультикаста может частично решить dhcp/igmp snooping, сейчас оно встречается даже в недорогих системах типа юбиков.
2) указано 70 AP но на скрине видно 99 :) Как выше уже написали это очень смело на 15тыс клиентов. Даже сейчас на точках wifi 5-6 это очень мало, даже учитывая что занятость эфирного времени на AC/AX меньше чем на N в 2014 году.
Интересно какой пиковый суммарный трафик/какой канал дал оператор. 100Мбит/с?
3) подозреваю что сейчас в масштабах "1-2тыс клиентов" на выездных мероприятиях 7750 и "линукс на сервере" для L3 задач dhcp-nat-шейпинг-немного приоритезации/лимитов можно заменить на какой-нибудь Mikrotik CCR (или парочку - один под управление, второй для пользователей) или CHR накатить на сервак где ядра пободрее и их побольше. Заодно и питания потребуется меньше :)
«Пока противник рисует карты наступления, мы меняем ландшафты, причём вручную. Когда приходит время атаки, противник теряется на незнакомой местности»© ДМБ.и одновременно с тобой ландшафты меняют все другие подрядчики-монтажники-строители на площадке, так что вчера смонтированную тобой AP сегодня могут зашить в железную конструкцию/завесить зеркальными материалами/закрыть LED экраном/etc...И так во всём :)
я удивлён потому что по-моему половина QTECH, ZRJ и SNR (кроме их собственных серий 5ххх), сошли с одного конвеера крупного китайского производителя и отличаются только брендированием, ценой и (что немаловажно) наличием/качеством локального саппорта.
Удивлён что в статье есть QTECH и не так давно появившийся ZRJ и нет SNR, у которого есть как железки-близнецы, так и серии коммутаторов полностью собственной разработки, включая модели с ТОРП.
похожее поведение у какого-то популярного dns-клиента-сервера в soho роутерах. Кажется это dnsmasq но это не точно. Там прямо в мануале написано что для скорости ресолва (клиет же не может подождать дополнительные 10мс!!!!) он шлёт запрос сразу ко всем серверам которые знает и довольствуется первым ответом, закрывая сокет. Соотв-но на все остальные пришедшие от днсов ответы линух роутера шлёт icmp port unreach. И авторы не считают это чем-то плохим. Лавров.жпг, как говорится.
очень мало ICMP в которых src ip не совпадает с указанным в icmp айпишником недостижимого хоста. Тех в которых они совпадают процентов 90 а то и все 99. Может быть иногда волнами прилетает несовпадающие (как пул отресолвит кому-то ip моего сервера) но всё-же их мало.
А вот запросов с special purpose адресов хватает. Я у себя смотрел дампы (и сейчас перепроверил). Например дампим два варианта
icmp and net 100.64.0.0/10
port 123 and net 100.64.0.0/10
за минуту мне не пришло ни одного icmp из этой сетки и под сотню запросов на 123 порт. Отвечаем, наш ответ улетает куда-то по роутингу и часто на такой ответ мы получаем icmp о закрытом порте, например. Это одна из причин получения лишних icmp на сервер. Малая часть icmp, на которую мы можем напрямую повлиять со стороны сервера, просто отсекая запросы из таких подсетей.
Ждём когда Яндекс поднимет свои сервера и озаботится проблемой icmp :-)
я примерно такого мнения. Насчёт фаерволов и правил, написанных администраторами я думаю что они бы делали просто молчаливый дроп, реджектить с icmp всякий флуд ни к чему. С другой стороны я видел множество весьма странно себя ведущих soho роутеров и уже ничему не удивлюсь. Встречаются экземпляры которые услышав броадкастовый arp reqeuest с адресом не из своей подсети начинают валить в ответ icmp redirect O_o.
Серые/CGNAT и RFC6890 можно смело дропать, отвечать на них не надо (исключение - серые внутри своего провайдера и локалки, да и то можно с ограничениями по ttl).
Надо учитывать что роутинг/форвардинг работает по dst и далеко не все фильтруют src. Поэтому запрос с серым src может прилететь с другого конца шарика. А ответ улетит куда-то к ближайшему по роутингу хосту с таким Ip и будет его "заваливать незапрошенным мусором" на который он тоже может прислать icmp unreach. Поэтому лучше сразу их дропать и не пытаться эти запросы обрабатывать сервером и слать ответы.
Вопрос как в iptables залезть внутрь icmp чтобы считать оттуда какой host unreach (icmp source и указанный в нём host unreach могут отличаться если пакет прибили где-то на транзите) чтобы его тоже добавить в блок и не отвечать некоторое время.
Про чтение ntp'шного rfc - писатели не читатели :) Их клиент по описанию похож на sntp и там может быть что угодно. Я вот rfc тоже не читал. На деле криво заполненные поля запроса это не сказать что прям беда-беда. В то-же время некоторые сервера типа ntpsec могут просто дропать не-RFC'шно сформированные запросы. Значит будут колоночки тупить. Штош.
Для чистоты эксперимента надо всё-же разобраться кто шлёт эти icmp - сама колонка или нет. Пока неясно.
есть уверенность что это именно станция? Дамп снят непосредственно с линка станции? Если нет, это вполне может быть и поведение роутера, а станция внутри за натом ответа так и не получила. Избавиться от этих ICMP на сверере тоже хочется :)
нет, icmp были и до этой и до предыдущей статьи. У меня было около 25% пакетов это icmp port unreachable (кстати они содержат в себе и исходный пакет ntp-ответа что увеличивает объём входящего).
Часть запросов приходит из за NAT с одинаковыми source ip или кривые ntp-клиенты шлют запросы очень часто (типа как Алиса раньше), где-то может быть и дудосы. Часть пакетов приходит от транзитных узлов, как будто "защищающих" того куда сервер ответил (но по идее защита тупо дропает без icmp так что непонятно). В демонах ntp-серверов есть рейтлимитер, ограничивающий ответы на слишком частые запросы с одного ip. Поэтому демон сервера отвечает не всем, дропая часть ответов. Уже поэтому исходящий pps меньше входящего.
В комментариях к предыдущему посту есть правила для iptables (и там-же ниже объяснения их работы) чтобы банить на некоторое время присылающих icmp type 3 + рейтлимитить тех кто шлёт слишком много запросов прямо в iptables, не допуская до ntp-демона.
Стандартной для кварцевых часов является точность в пределах ±20 секунд в месяц, а лучшие из наручных кварцевых часов показывают результат ± 5 секунд в год.Я думаю что у часов компа точность примерно такая-же, что там что там недорогой "кварц". Как выше отметили - у часов "показывать время" это основная задача и всё-таки подстраивать руками всё равно приходится. У рядового десктопа точность кварца и хода часов не так критична т.к. автоматически подстроить проще. Ну и прям миллисекундная точность на компах не нужна, просто процесс синхронизации довольно простой, поэтому скорее тут руководствуются мыслью "чё бы не подсчитать drift и не стабилизироваться?"
где-то тут Яндекс уже писал что стереопары находят друг друга и синхронизируются друг с другом по отдельному ими разработанному протоколу.
по-моему аппаратный сервер типа Meinberg'а стоит условно 100-300тыр (сейчас может и миллион, но есть наши аналоги), он умеет в GNSS (спутники) и содержит TCXO/OCXO который способен продолжительное время поддерживать точный ход, даже если спутники пропали или выдают чушь. Ну в конце концов цезиевые/рубидиевые источники можно купить у того-же ВНИИФТРИ.
Ставим N штук в кластер, на них завязываем уже машины с ntpd/chrony способные держать гигабиты трафика. Поехали.
вчера тоже про это думал. Ask Bjørn Hansen (админ/вледелец пула) по-моему живёт в США.
В связи с инцидентом и самизнаетечем, Яндекс может родить аналогичный проект национального масштаба. Правда смысла в этом немного, если только у операторов потом сделать pool.ntp.org CNAME pool.ntp.рф но хайджекинг записей это невесело
в той теме о коллапсе пула вчера отписывался сотрудник поддержки с заявлением в духе " колонки ведут себя нормально, просто им нужно очень точное время иначе будильник может зазвонить не вовремя". Конечно, на него слегка накинулись :)
Вчера в netflow логах ещё видел сотни пользователей, генерирующих запросы к ntp каждые 5 сек. Сегодня их уже не осталось. Похоже что да, апдейт докатился до всех. УРА! Нагрузка на пул стабилизировалась, это вижу и сам, об этом в телеге мне отписался администратор ещё одного сервера :)
Остались вопросы:
Я.девайсы примерно каждые 20-30 сек ресолвили DNS-записи [0-5].ru.pool.ntp.org (я видел это своими глазами) + люди писали что колонка периодически запрашивает SOA зоны. Зачем ей это? Может тоже баг?
В твоём топике на хабре также были озвучены предложения к Яндексу:
выделить сервера для общего пула
зарегистрировать в пуле свою vendor-зону для своих дейвайсов (см https://www.ntppool.org/ru/vendors.html). Хотя тут есть и плюсы и минусы. Без зоны есть плюс в том что трафик запросов ходит до ближайших серверов (иногда это будет сервер прямо у провайдера) а не в интернеты на сервера Яндекса.
Вопросы по пулу и трафику в целом:
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp. Это спуфинг или ковровые блокировки ntp-протокола? По идее блокировки делались бы drop'ом без отправки icmp.
первые три это тоже ВНИИФТРИ в других локациях
Можно взять облачные/CDN (гугл и фейсбук отдают stratum1, cloudflare - stratum3)
server time.google.com (говорят он как-то по-особенному работают и лучше не использовать)
server time.facebook.com
server time.cloudflare.com
Нормальные ntp-клиенты после запуска опрашивают сервер времени часто, высчитывает "уплывание" собственных часов и начинает корректировать свои часы, изредка (обычные настройки по умолчанию - раз в 17 минут) сверяясь с эталоном - внешними серверами. Это нормальный принцип работы ntp, он позволяет поддерживать расхождение времени с эталоном на уровне миллисекунд!!!!
Никакая синхронизация раз в 5 секунд не нужна, это явно косяк или отсутствие мозга у разработчиков. Пожалуйста, подключите к обсуждению вопроса реальных разрабов.
@kkursor, мне московские сервера ВНИИФТРИ перестали отвечать, я думаю что они в последнее время сильно ограничивают активность запросов, замечал что после перезапуска демон до них не может достучаться по несколько часов. Имеет смысл указывать в конфиге только один из серверов ВНИИФТРИ + ntp.msk-ix.ru + использовать больше "облачных"/CND источников, например
server time.google.com
server time.facebook.com
server time.cloudflare.com
они тоже могут оказаться заблокированными на ТСПУ, интересно что cloudflare отдаёт stratum 3
ещё из российских был, похоже уже не отвечает
server stratum1.net
от хабровчанина @gag_fenix https://habr.com/ru/articles/118266/