rm_

@maa1 если хотите что-то попробовать для решения проблемы на своей стороне, попробуйте другие TCP Congestion Control алгоритмы, думаю bbr или illinois гораздо больше прокачают даже через провайдеров навроде тех, что вам здесь хамят в этой ветке. Ну только TCC нужно выставлять на машине отправляющей данные, а если вам с винды, тогда ничего не выйдет. Ну хотя бы на линуксовом серваке поменять, померять уже с него iperf, и ради спортивного интереса убедиться, что это помогло (или нет).

Если роутер один, то RA тоже придёт один, только с двумя префиксами в нём. Можно контролировать, с адресов в котором префиксе клиенты ходить не будут, выставляя этому префиксу preferred lifetime = 0. Соотв-но они всегда будут ходить с другого, и задача таким образом будет решена. А приоритеты есть у самих роутеров (но это надо больше одного роутера) и у маршрутов (недефолтных), у префиксов нету.

Вероятно qemu-nbd кто-то прибивает после завершения скрипта из крона. А если добавить ему "--fork"? Ещё, если это всё в пределах одной машины -- может лучше сделать не через nbd, а просто loop device (losetup)? По крайней мере это будет быстрее. Правда там поддержка разделов по умолчанию вроде не включена, надо передать модулю max_part=16 (например).

Посмотрите на строчки "longterm" в списке на https://www.kernel.org/. После 4.14 вышло уже две новые лонгтерм-серии: 4.19 и 5.4. Если вы всё равно задумываете апгрейд, не лучше ли сразу на последнюю из доступных? А то выглядит как отрубание хвоста по частям. Всё равно когда-то придётся и на неё, а значит снова риск, эксперименты, тестирование, возможный откат. Сам не так давно перешёл везде с 4.14 на 5.4, значительных проблем не припомню. Впрочем у меня и не PPPoE-сервер, и масштабы наверное поскромнее провайдерских.

Ну речь шла про связь между корпусами одного учреждения, сомневаюсь что там именно удалёнка. А так да, пинг для RDP и подобного очень важен, смотреть надо и на него. Если госучреждение, то там небось ещё и через госзакупки надо объявлять конкурс на 200-рублёвую VPS. Но мне кажется это уже не мы с вами должны об этом задумываться, главное что техническое решение [которое можно попробовать] - существует. А в итоге может окажется вариантом просто на имя кого-то из сотрудников (или директора) это купить.

Можно купить VPS или выделенный сервер в ДЦ, до которого скорость будет нормальной из обоих точек, и установить VPN-сервер+роутер там. цены начинаются от 200 р/мес за безлимитный канал 100-200 мегабит, вам отроутить 100-мегабитный VPN хватило бы. Например https://veesp.com/, https://vscale.io/

17.01 ещё можно пользоваться, и даже добавить пакет или пару-тройку пакетов можно, несколько сот КБ по embedded меркам - это дофига. 18.06 уже нет, там навалили блоатвари, HTTPS в веб-интерфейс на роутере это очень важно, да.

Домру падал дважды за неделю, по симптомам - пинг 1500-3000мс докуда угодно, кроме того же самого города. Про первый раз говорили что обрыв под Нижним Новгородом, про второй не говорили ничего (и он был короче). 5 апреля в воскресенье с 14 до 20 мск (да, шесть часов!). 8 апреля с 14мск до 14:30. хотя если у вас прям сегодня, то наверное уже не оно.

As of 16 March 2020, at least 712 out of the 3,711 passengers and crew had tested positive for the virus. As of March 24, ten of those who were on board have died from the disease. https://en.wikipedia.org/wiki/Diamond_Princess_(ship) ДВАДЦАТЬ ПРОЦЕНТОВ от всех находившихся на борту заболели, смертность 1.5% Теперь конкретно по поводу вашего поста: Публичное распространение под видом достоверных сообщений заведомо ложной информации об обстоятельствах, представляющих угрозу жизни и безопасности граждан https://russian.rt.com/russia/news/733336-feiki-koronavirus-tyurma https://govoritmoskva.ru/news/229689/ Минимальный штраф для физического лица составит 300 тысяч. Аккуратнее.

Фрагментируйте. Лично проверял WireGuard с большим MTU, и внутри него VXLAN. Фрагментация средствами WG, в результате внутри ходили полные джамбо-фреймы в 9000 байт. Но работало что-то не очень, при крупных трансферах происходили странные затыки. GRETAP внутри WG работал лучше. Идеально беспроблемной работы ожидать всё равно не стоит, но порой полезно передать полные 9000, прежде всего если на обеих концах требуется добавить это в бридж с JF-локалкой.

Ну да, тоже так делаю. Кстати, на файлах, как и на thin LV, легко увидеть, работает ли внутри виртуалки TRIM. Размер файла, возвращаемый "du", будет уменьшаться на оттримленную область. Для хранения образов VM я бы порекомендовал XFS. Там теперь работают рефлинки, то есть можно с помощью "cp -a --reflink" делать мгновенные полные копии VM-образов (ну, не физически копии, а логически), причём даже запущенных виртуалок, т.к. делается это атомарно, получается по сути аналог снапшота. Хотя у вас в старом CentOS наверное это ещё и близко не завезли.

Из перечисленного ни у одного из этапов нет проблем с пропуском TRIM дальше, на следующий. Поэтому, будет работать. Только я бы всё равно сократил их количество, во-первых нафига внутри виртуалки свой LVM, во-вторых нахрена её образ держать в файле на ext4, а не в виде LV на хост-сисеме.

Запоминают одну кнопку вечером в день покупки, и дальше пользуются только ею. Шта? Кмк здесь только если дату/время выставить, и то сильно не факт.

Не совсем ясно, в чём состоит вопрос. Если что, внутренние IPv6 в данной ситуации не нужны, можно сразу прописывать публичные.

А сжатый вид отображения так и не починили, с этим кто-нибудь разбирается? или "да кто им пользовался вообще"?