Le ecureuil

Там передергивание занимает сотню миллисекунд, скорее всего не заметите даже

Такова жизнь - IKEv1 сервер очень недружелюбен ко множественным конфигурациям.

Переходите на IKEv2 везде для site-to-site туннелей, оставляйте IKEv1 только для Virtual IP. И все будет хорошо

У вас слегка несовместимые настройки, IKEv1 плохо работает с несколькими туннелями сразу как ответчик с разными PSK. Попробуйте везде перейти на IKEv2, должно помочь.

Это невозможно, все что мы могли - прикреплено в 3 посте темы.

Команда будет только в 2.10, в 2.09 добавлять новое уже запрещено. Но это будет уже скоро

@Cha-Cha в выходящем draft должно быть реализовано, проверяйте. UPD: версия 2.09.A.7.0-3.

@HolodN @Amigokot ПОЛНОСТЬЮ НА ВАШ СТРАХ И РИСК собрал 2.08.C.2-0 с полным набором компонентов с разными версиями прошивки LTE-модема. Полного кирпича получиться не должно, все прошивки загрузились и firmware модема везде выдало "USIM card is not inserted" (проверял без sim-карты), однако рекомендую сделать бекап прошивки, конфига и не прошивать устройства, которые находятся не в шаговой доступности. Эти комбинации NDMS и прошивки никто вообще не проверял (кроме первой). 1. Версия с текущей прошивкой LTE модуля (05_00_02_00_56_TF) :https://www.dropbox.com/s/3yv5mvned164ocn/20170512_1445_Firmware-Keenetic_LTE-v2.08[AATF.0]C2_56.bin?dl=0 2. Версия с предыдущей прошивкой LTE-модуля, которая использовалась до октября 2016 (05_00_02_00_49_TF): https://www.dropbox.com/s/vrvib8l5b33olq2/20170512_1509_Firmware-Keenetic_LTE-v2.08[AATF.0]C2_49.bin?dl=0 3. Версия с самой старой прошивкой LTE-модуля, которая использовалась в v1 (04_05_06_10_87_TF): https://www.dropbox.com/s/r61xn3cg7n7o5vm/20170512_1511_Firmware-Keenetic_LTE-v2.08[AATF.0]C2_04_87.bin?dl=0 Пробуйте, возможно кому-то повезет

Да, спасибо большое за отладку, будем искать проблему.

В посте выше специально было указано, что cifs и nfs - это принципиально разные вещи, объем функционала у которых несравним. Назовите хоть одно реально заметное техническое преимущество NFS над CIFS/AFP, которое перевесило бы стоимость его официальной поддержки, тогда посмотрим. А также заодно могу напомнить насчет тысяч тем на форумах о том, что при "отвале" NFS сервера у людей "встают колом" клиентские ОС. Насчет религиозного отношения к технологиям - это в курилку.

MTU у virtual-ip изменить нельзя, поскольку у него нет интерфейса. Попробуйте задать не автоматическое, а ручное управление TCP MSS: > crypto map <server_name> set-tcpmss 1200

Да, в базовом варианте диагностика добавлена - все будет сообщено в логе. В дальнейшем диагностику расширим, если у кого-то останутся вопросы или будет просто отключено "без объявления войны".

Да, можно.

Получилось реализовать быстрее, чем изначально думалось. В следующем draft при задании команды > system set net.core.eoip_allow_fragment 1 Будет включен режим фрагментации (отключается через задание 0). При этом MTU на EoIP-интерфейсе фактически будет игнорироваться, в него можно будет слать хоть фреймы в 10К, они будут разбиты по нескольким фрагментам IP-пакета и отправлены в виде фрагментов корректного размера. Кстати, предыдущая реализация имеет возможность принимать такие пакеты, но не сможет отправлять (то есть сторона-ответчик со старой прошивкой нормально их примет, но ответ больше, чем MTU у EoIP в нее по-прежнему не пролезет). Просьба кстати проверить совместимость этой фичи с Mikrotik, да и вообще ее "погонять".

@r13 в следующем draft будет реализовано следующее поведение: если у Bridge меняется состояние (up/down), то интерфейс EoIP, включенный в Bridge тоже делает up/down. В итоге можете спокойно настраивать ping-check прямо на интерфейс Bridge, главное только адрес проверки указывайте доступный через EoIP-туннель. При его недоступности ping-check перезапустит Bridge, и EoIP-интерфейс вместе с ним, и произойдет переподключение. Внимание! Если на EoIP настроен VLAN и этот VLAN включен в Bridge, то это не сработает. Работает только непосредственное включение EoIP в Bridge.

В следующей сборке draft будет (на мой взгляд) самый оптимальный вариант с проверкой совместимости. Если у кого-то будут проблемы с подключением - просьба заново пересоздать их (через web), чтобы убедиться, что конфиг записался верно.

Нужно повторить и приложить вывод команд >show interface ge0/4 stat >show interface ge0/5 stat до и после теста.

Разницы в скорости практически нет для основных сценариев использования.

Используйте CIFS в Linux, и все будет хорошо. NFS - это не комплексное решение, навроде cifs или afp. В нем отсутствуют многие вещи навроде кросплатформенного разграничения прав, шифрования, обзора устройств в сети и прочего. При этом CIFS намного лучше решает все эти вопросы. На корни ndms вообще параллельно, единственное что важно - число пользователей. Число пользователей CIFS - чуть ниже 99%, AFP - приближается к 10%. Число же возможных пользователей NFS... короче и к 1% пока только-только подходит. Почистил мусор в теме, кто еще будет постить непотребство - получит по шапке.

nfs есть в Entware, мало?

Огромное спасибо за помощь в воспроизведении, все починено и появится во всех ближайших сборках.

Конкретно ваш случай исправлен, появится в ближайшей сборке.

Спасибо за ценный дебаг, кажется я нашел где был упущен один маленький момент в реализации...

А можно попродробнее, прямо с тестовым конфигом с которого начинаем и командами в CLI, исполняемыми по порядку? Есть шанс, что сейчас заборем это дело.

linked key for crypto map был практически сразу же починен.