Есть большая вероятность, что это сработает, особенно если у обоих одинаковые ОС и ЦП. Я считаю, что между процессорами Intel и AMD может быть разница, и если у вас разные версии процессоров, такие как Red Lake и KB Lake, шансы на его работу уменьшаются.
Если вы работаете в Windows, шансы на то, что она заработает, довольно малы, поскольку Windows регистрирует аппаратную конфигурацию машины, на которой она установлена, и не загружается, если эта конфигурация изменится.
Другая проблема, с которой вы, вероятно, столкнетесь, заключается в том, что если есть какая-либо разница в периферийных устройствах, у вас не будет драйверов для этих периферийных устройств при замене дисков.
Лучше всего попробовать это на двух компьютерах с одинаковой конфигурацией оборудования и операционной системой. В таких условиях, наверное, сработает.
Удачи!
Таблица маршрутизации сделает ваш маршрут постоянным (, чтобы избежать его повторного/ручного добавления после аварийного переключения коммутатора ); Сначала создайте именованную таблицу маршрутизации. В качестве примера мы могли бы использовать «mgmt».
echo '200 mgmt' >> /etc/iproute2/rt_tables
Просто для более подробного ознакомления с приведенным выше решением: ядро поддерживает множество таблиц маршрутизации и ссылается на них уникальными целыми числами с номерами 0 -255. Для таблицы также определено имя mgmt. Ниже следует взгляд на /etc/iproute2/rt_tables
по умолчанию, показывающий, что некоторые номера зарезервированы. Выбор в этом ответе 200 произволен; можно использовать любое число, которое еще не используется, 1 -252.
# reserved values
255 local
0 unspec
Во-вторых, отредактируйте post-up
правило (в /etc/network/interfaces )следующим образом
post-up ip route add 10.1.0.0/24 dev eth0.101 table mgmt
post-up ip route add default via 10.1.2.1 dev eth0.101 table mgmt
post-up ip rule add from 10.1.0.0/24 table mgmt
post-up ip rule add to 10.1.0.0/24 table mgmt
В качестве альтернативы другим решением может быть фоновый bash-скрипт, проверяющий существование маршрута и добавляющий его обратно, если он отсутствует, скрипт может проверять результат ip route add 10.1.0.0/24 via 10.1.2.1 dev eth0.101
скрипт может быть настроен в цикле или cron
ip route add 10.1.0.0/24 via 10.1.2.1 dev eth0.101
if [ $? -eq 0 ]; then
echo "Route added again"
sleep 10;
command-to-call-the-script-again
else
echo "Route exists"
sleep 10;
command-to-call-the-script-again
fi
Ваше описание немного расплывчато в отношении имеющейся установки :Как ситуация с "отказоустойчивостью коммутатора" влияет на сетевое устройство вашего сервера? потеря связи? простое прерывание пересылки пакетов? какое-то явное уведомление, такое как LACP, может сделать? или что еще? Кроме того, какие интерфейсы у вас есть в auto
и allow-hotplug
? физическое устройство? или интерфейс vlan? или оба ?
Дело в том, что описанное поведение на самом деле не имеет смысла только с точки зрения описанной установки. Например, простой потери связи обычно недостаточно, чтобы удалить маршруты или отключить интерфейсы, если только не существует какой-либо дополнительной настройки, которая явно делает это.
Я бы также сказал, что эта дополнительная, но не упомянутая настройка не может быть стандартной ifplugd
или netplugd
, которые воздействуют на события связи (, такие как подключение/отключение кабеля ), потому что они обычно вызывают ifup
и ifdown
для этих событий, и, таким образом, ваша команда post-up
будет выполнена, когда ссылка восстановится, если их конфигурация соответствует вашему интерфейсу vlan.
Обратите внимание, что параметр allow-hotplug
ifupdown относится к устройству , а не к кабелю, а это означает, что он действует в основном только во время загрузки -(, т.е.когда ядро обнаруживает наличие устройства в первый раз )и / или если ваше сетевое устройство, например. USB-ключ, и вы подключаете / отключаете его от / от USB-порта вашего сервера.
Поэтому я бы предположил, что на вашем сервере работает какая-то специальная служба, которая, возможно, обнаруживает потерю сети с помощью какого-либо зонда, возможно, периодического ping
или TCP-соединения, установленного специально, который удаляет ваш маршрут, как только он обнаруживает потерю сети, но не добавляет ее обратно, когда это тестовое соединение восстанавливается.
Чтобы ответить на ваш конкретный вопрос:
How can I configure an interface to restore routes to networks that where lost, but, to quote the old song, have now been found?
Это зависит от того, что означает для вашего приложения "потеря сетевого подключения" и, следовательно, что означает его восстановление. Если состояния ссылки на интерфейс достаточно, вы можете просто положиться на ifplugd
или netplugd
или эквивалент (, в зависимости от того, что вы предпочитаете или лучше всего соответствует вашим требованиям ):вашей команды post-up
достаточно, если она связана с " Интерфейс ifupdown" vlan, который просто всегда существует поверх своего главного устройства или который настроен так, чтобы следовать судьбе своего мастера.