There are no per-process APIs for sockets at all, just per-socket APIs and global kernel configurations.
But you don't need to modify the scale settings directly. You just need to set the socket receive buffer size you want prior to connecting. Then the appropriate window scale is negotiated during the connect handshake. If you want mo window scaling! make sure your socket receive buffer is < 64k before connecting. In the case of accepted sockets, that is set on the listening socket.
Это тоже можно увидеть в выхлопе дебага айперфа и косвенно в дампе.
Помнится еще до iou-web был проект route-reflector (не путать с BGP RR) — там топологию нужно было вколачивать в текстовом виде. Тут есть история от первоисточника www.routereflector.com/unetlab
EVE-NG распространяется под собственной лицензией в бесплатной однопользовательской и платной профессиональной или обучающей версиях
На самом деле это не совсем так — бесплатная версия тоже многопользовательская.
Хотелось бы полохматить бабушку. Кейс такой — то что выгружается сейчас судя по всему это список отсюда eais.rkn.gov.ru. Однако есть еще такой список blocklist.rkn.gov.ru — и вот они двое ни разу не синхронизированы. Вопрос такой — есть ли какой-то способ объединить эти два списка в решении из этой статьи?
Сотни адресов требуются например на баланисровщиках нагрузки, когда на одном балансере крутятся тысячи сервисов (не обязательно HTTP), бывает по разным причинам нужно выделять некоторым сервисам разные адреса. То что вам не нужен балансер — рад за вас, если не понадобится в будущем еще болше рад. Моя цель не доказать вам что ваше решение неработоспособно, а доказть то что оно немасштабируемо. По приведенной ссылке ровно об этом и говорится.
Например — у вас всего один маршрутизатор и два сервера. А если для отказоустойчивости понадобится несколько маршрутизаторов, раскиданных по разным цодам и с десяток балансеров/фронтов — вы тоже будете на всем этом статику делать?
Прочитайте внимательно комментарий — я писал про пару сотен адресов, а не про пару сотен серверов. Также в первом комментарии была фраза «у BGP или любого протокола динамической маршрутизации» — так вот OSPF включается двумя строчками для минимальной конфигурации — руками соседей настраивать не нужно, да и рисовать BGP соседей руками тоже никто не заставляет — есть масса способов автоматизации процесса.
> У статики это — место для в памяти для маршрута и пару сообщений каждые 10 секунж.
Я о чем и пишу выше — у BGP также.
Безопасность статики? Вы серьезно? В каком месте там есть такая базовая вещь безопасности как аутентификация? Вот в протоколах динамической маршрутизации например есть аутентификация соседа в полный рост. Вобщем не увидел ни одного плюса статики пока. Единственный вариант для чего она может быть полезна в современных сетях, тем более с заявкой на продакшен, хайлоад, фолт-толеранс и т.п. — это backup route на случай аварийного режима работы.
IP SLA тоже потребляет ресурсы и еще не факт что будет потреблять меньше ресурсов чем два BGP соседа с одним префиксом каждый. Если привести конкретно цифры, то 1 маршрут в BGP таблице занимает 120 байт памяти (в реализации Cisco по крайней мере). Что касательно нагрузки на процессор — если ничего в сети не меняется, то и обновлений таблиц не происходит, так что нагрузка будет только на поддержание ТСР соединения, что тоже не факт что будет потреблять ресурсов больше чем пинги в вашей конфигурации IP SLA.
Плюсы относительно статики — легко масштабировать, например если понадобится добавить еще несколько адресов для балансировки, или несколько сотен адресов — вы будете это всё вколачивать статикой? Мониторить состояние сервиса с сетевой железки — такое себе решение, для этого существуют системы мониторинга, а задача сетевого оборудования побыстрее передавать пакеты из одного порта в другой. Ничего не мешает мониторить состояние сервиса чем угодно и по результату HTTP GET того же можно очень разными способами снимать анонс адреса с хоста где крутится сервис.
> Принцип работы основан на приоритете короткого маршрута в протоколе bgp.
«короткого» — видимо тут имеется в виду атрибут BGP AS-PATH, хотя он далеко не единственный и даже не первый в алгоритме выбора лучшего маршрута. А еще BGP не обязан выбирать только один лучший маршрут, а может выбрать их два, три, четыре и больше — и все они будут с одинаковыми «длинами» и прочими атрибутами кроме next-hop, что приведет к балансировке.
> Как с помощью anycast резервировать ресурсы на одной площадке не совсем понятно.
Легко и просто, абсолютно никакой разницы находятся ресурсы в пределах одной стойки или разнесены по разным континентам.
Более того если использовать EIGRP то можно добиться неравномерного распределения трафика подкручивая метрики.
Уточните какие минусы есть у BGP или любого протокола динамической маршрутизации относительно статических маршрутов? Кстати да, ECMP умеет не только статика или BGP, а в принципе любой современный протокол.
Тогда придется этот простой скрипт переделывать под каждую железку, тогда как SNMP достаточно универсальный способ, но в любом случае рад был помочь, даже если показал пример как не надо делать.
Выглядит лаконично и несложно, кроме одного «но» — если логи по каким-то причинам перестанут приходить, вы никогда об этом не узнаете, то есть и изменения состояний соседей не увидите. Да, с SNMP TRAP/INFROM точно такая же проблема.
«Сложно» понятие субъективное, мне вот кажется что сложнее пилить свой скрипт, чем использовать встроенные в мониторинг, ну и в вашем случае сдается мне придется на каждого соседа руками создавать Item, что боль когда соседей несколько сотен.
Можно, но ставить рядом вторую систему мониторинга из-за одного сложного параметра это как-то оверкилл. Система то вроде неплохая по возможностям и поддержке, но мне не нравится по двум причинам — она только под винду (по крайней мере я нигде не нашел её под *nix), и у неё тормозная и перегруженная морда — что веб, что консольный вариат.
Точнее после выполнение restore с файлом .backup сертификаты уже будут лежать в виде файлов и после этого можно делать import + decrypt, отдельно выдергивать сертификаты в виде файлов не нужно.
Нашел еще такое на просторах:
Это тоже можно увидеть в выхлопе дебага айперфа и косвенно в дампе.
У меня два предположения:
iperf3 в обход системных настроек и все-таки включает tcp window scaling
iperf3 выставляет начальное значение окна, достаточное чтобы прокачать гигабитный линк даже без scaling
Это можно проверить если включить дебаг в iperf3 (он покажет какое окно выставляет) и/или посмотреть в дампе что там на самом деле улетает в сеть.
Если проблема была в отключенном tcp_window_scaling, то почему вы не увидели того, что при тестировании через iperf скорость также не растет?
На самом деле это не совсем так — бесплатная версия тоже многопользовательская.
Например — у вас всего один маршрутизатор и два сервера. А если для отказоустойчивости понадобится несколько маршрутизаторов, раскиданных по разным цодам и с десяток балансеров/фронтов — вы тоже будете на всем этом статику делать?
> У статики это — место для в памяти для маршрута и пару сообщений каждые 10 секунж.
Я о чем и пишу выше — у BGP также.
Безопасность статики? Вы серьезно? В каком месте там есть такая базовая вещь безопасности как аутентификация? Вот в протоколах динамической маршрутизации например есть аутентификация соседа в полный рост. Вобщем не увидел ни одного плюса статики пока. Единственный вариант для чего она может быть полезна в современных сетях, тем более с заявкой на продакшен, хайлоад, фолт-толеранс и т.п. — это backup route на случай аварийного режима работы.
Плюсы относительно статики — легко масштабировать, например если понадобится добавить еще несколько адресов для балансировки, или несколько сотен адресов — вы будете это всё вколачивать статикой? Мониторить состояние сервиса с сетевой железки — такое себе решение, для этого существуют системы мониторинга, а задача сетевого оборудования побыстрее передавать пакеты из одного порта в другой. Ничего не мешает мониторить состояние сервиса чем угодно и по результату HTTP GET того же можно очень разными способами снимать анонс адреса с хоста где крутится сервис.
«короткого» — видимо тут имеется в виду атрибут BGP AS-PATH, хотя он далеко не единственный и даже не первый в алгоритме выбора лучшего маршрута. А еще BGP не обязан выбирать только один лучший маршрут, а может выбрать их два, три, четыре и больше — и все они будут с одинаковыми «длинами» и прочими атрибутами кроме next-hop, что приведет к балансировке.
> Как с помощью anycast резервировать ресурсы на одной площадке не совсем понятно.
Легко и просто, абсолютно никакой разницы находятся ресурсы в пределах одной стойки или разнесены по разным континентам.
Более того если использовать EIGRP то можно добиться неравномерного распределения трафика подкручивая метрики.
В вашем способе я правда не заметил чтобы отдельным образом сохранялись сертификаты или проглядел между строк?
Разве? В виде файлов сертификаты как-раз останутся, только их придется заново импортировать и потеряются их имена.