rm_

Как вариант, заменить древние карты реалтек с рукожоп-дровами на что-то нормальное. По TCP будет работать с наименьшим из двух размером пакетов. А разрабы протоколов поверх UDP обычно и не закладываются, что там джамбо-фреймы могут быть вообще.

С прямой видимостью и без лицензий вроде же обычно советуют 60 ГГц, почему никто не вспомнил? Или дорого будет?

Есть откуда, у мегафона может быть NAT64. Если адрес начинается с 64:ff9b::, это он и есть. Очень похоже.

Может числится за Sweden, но по факту трейсится в Чикаго, США.

На первом скрине вероятно обратный трафик к вам из Японии идёт через США или через Европу. Совет дали правильный - писать РТК. Что они должны сделать - могу предположить, должны анонсировать ваши адреса на японских пирингах. Они это делают не для всех даже своих диапазонов, в результате чего трафик из Японии примерно до Новосибирска будет идти через линк с Японией, а для адресов дальше в сторону Европы - уже вокруг Земли. Не факт что вам понадобится объяснить им их же работу, думаю можно надеяться что подобный случай для работающих на ДВ сотрудников NOC'а РТ будет не первым, и как чинить они сами знают.

Есть на 8 портов 2.5G с одним 10G, на Али около 7 т.р.

Думаю самая дешевая стоимость мульти-гигабитного порта. Если вам просто неуправляемый свитч, уже сегодня есть и дешевле.

tty -s && echo терминал || echo хз вроде нет Но мне кажется когда скрипт запущен через screen, там всегда будет терминал, даже когда к screen никто не подключён. Вам это надо проверять? Не будет терминала только если запущен из crontab, например. Может кстати лучше так и сделать, чтобы скрипт запускался раз в 5 минут из крона? И добавить проверку на работу предыдущей копии и выход, если какой-то из запусков занял дольше пяти минут.

А там ls или mkdir не трупы случайно? А то держите в курсе. Работают. AoE правда уже не пользуюсь, но NBD - отличная не-overengineered версия iSCSI.

В порядке убывания сложности/навороченности: 1) iSCSI 2) NBD 3) AoE (ATA over Ethernet) Результат у всех один и тот же, ровно тот что вы хотели: удалённые диски с трёх серверов доступны на четвёртом сервере как блочные устройства. Дальше делаете из них программный RAID средствами mdadm или LVM. Если вы таки передумали решать на уровне блочных устройств, можете расшарить на трёх серверах каталоги по CIFS (Samba) или NFS, их примонтировать на четвёртом, и объединить в одну логическую сущность с помощью mergerfs.

Проверьте с помощью httping, есть ли такие же потери при обращении к сайтам на хостинге по HTTP(S). По такому выводу пинга, на какой-либо осознанный лимитер сильно непохоже. Но раз жалоб нет, может и правда TCP не затронут проблемой, что всё же было бы довольно странно.

Можно упростить строку ниже (какой же неудобный редактор постов). iptables -A INPUT -p tcp --dport 179 -m set --match-set bgp src -j ACCEPT Здесь же про INPUT, зачем ещё фильтровать по dst. Также для экспериментов заменить её на безусловный "iptables -A INPUT -p tcp --dport 179 -j ACCEPT", и посмотреть помогло ли это.

Не знаю как насчёт вмвари, но в полноценной ОС доступен вариант соединить сервера по 10G друг с другом, также каждый по 1G с общей сетью, сетевые карты объединить в бридж, и на нём включить STP. При таком подключении есть минус: один из серверов будет ходить в общую сеть через другой. Пока тот жив. Если тот упадёт, то весьма быстро перестроится и пойдёт напрямую. Зато на логическом уровне всё абсолютно прозрачно, та же самая общая L2-локалка, те же IP. Если без бриджа, то разруливать вручную, "вот эта подсеть IP-адресов чисто для связи серверов друг с другом, вот эта - остальная сеть".

Именно это сказывается, WG откусывает часть от MTU на свои служебные расходы, если OpenVPN об этом не знает, и пытается слать полноразмерные пакеты в расчёте на стандартный MTU 1500, каждый из них будет разбиваться на тело и маленький хвост. Понизить MTU на OpenVPN-туннеле.

Можно ссылку на дискуссию? Звучит как бред, давайте ещё PPPoE уберём, или SIT-туннели, а чо, тоже шифрования нету, нибизапаснае(!!!11)

Купите у китайцев реле с задержкой включения https://aliexpress.ru/item/32877105138.html Чтобы после отключения электричества и повторной его подачи, нагрузка подключалась скажем минут через пять, а не сразу. И морганий света у вас больше не будет. Заодно прикроет от скачков напряжения или некорректных его уровней, которые могут быть поданы в момент включения. Это такой бомж-вариант защиты от всяких неожиданностей (который и сам использую), если не хочется ставить и постоянно обслуживать UPS.

Подобные интеловские селероны это уже и есть SoC давным давно. SoC = система-на-чипе: проц, видео, северный-южный мост, контроллер памяти, всё интегрировано на одном чипе. Может вы не это имели ввиду, тогда сформулируйте иначе,что именно хочется. Я так понимаю нечто в духе embedded, чтобы обычного BIOS, диска и ОС не было, а грузилось некое *WRT с встроенной флешки. Отчасти понятны перечисленные плюсы, но мне кажется будет сильно некомфортно впердоливать в подобную ограниченную, обрезанную систему задачи чуть сколь-либо сложнее самых базовых. Кроме того, если вы возьмёте некий микротик или что-то подобное, там будет пара ядер старого MIPS и памяти 128-256. Ресурсов может просто и не хватить, на Wireguard как минимум. Может таки взять "ПК", и на него OpenWRT-x86 поставить?

Какие-то микротики, WRT, гигабитные порты в 2023, звучит как "вы до сих пор кипятите". Посоветую смотреть сюда: https://aliexpress.ru/item/1005004680185160.html на предыдущем проце и с 4 портами вместо 6, есть от ~10 т.р. (поиск на Али по слову "pfsense").

Т.е. признавать что v6 нужен и ничего другого не будет, Но при этом обязательно ныть, саботировать, цепляться за все столбы и углы и ждать пока в v6-будущее вас приволокут за ногу. Это точно наиболее продуктивный способ работы?

Здесь потыкайте, статистика запросов к сайтам за CloudFlare: https://radar.cloudflare.com/adoption-and-usage/?range=28d Вверху можно выбрать страну. В Южной Корее 20%, в Китае 24%. США среднее 48% с пиками до 54%. А всего глобально по миру сейчас 35%.

А он-то тут каким боком? Учитывая что у человека он уже работает, очевидно что все эти затраты уже проведены. Проблема с входящими коннектами, подозреваю в РТ завелись те же самые "безопасники" в плохом смысле слова что и в некоторых госконторах. Разумный компромисс блочить только 0-1024, давая и это отключить в ЛК.

Для управления через интернет. Конечно не всегда нужно, но легко могу представить случаи когда где-нибудь в удалённом офисе это избавит от лишней коробочки рядом. И не только самим свитчем управлять, но через него прокидывать SSH-туннели ещё на что-нибудь.

Хотел ещё дописать, становятся доступны все пакеты от OpenWRT, а это практически любой сетевой и серверный софт: DNS, DHCP, NTP, почта, веб, PPPoE, VPN любой, от OpenVPN до WireGuard. Многое из этого на свитче не применишь, но например VPN может быть полезен для удалённого управления, и т.д.

"Что даёт" иметь полные исходники софта и возможность их посмотреть, пропатчить, пересобрать как вздумается и зашить в железку? И не зависеть по багфиксам от Длинка и его планов по срокам поддержки моделей, и не гадать где там какие вендорские пароли зашиты, или просто дыры безопасности. Что даёт, это вы серьёзно щас? К сожалению уже распродал все свои Длинки, как раз потому что для них ничего этого ещё не было, и была только вендорская прошивка, так что на практике не смогу протестить.

Подсказали, из российских хостеров есть у JustHost локация в Гонконге, из Хабаровска у меня выходит 70мс. Может чем-то поможет и она? https://justhost.ru/services/vps/tariffs IP: 91.149.237.213 IPv6: 2605:e440:15::2:7b