Метрика. Штатный и простейший инструмент управления выбором маршрутов — это метрики. В таблице маршрутизации одновременно могут находиться несколько маршруты с разными метриками, приоритетен тот, у которого метрика меньше. Если приоритетный интерфейс переходит в состояние DOWN или удаляется, этот маршрут удаляется из таблицы и из-под него всплывает маршрут с бóльшей метрикой. Он будет действующим до тех пор, пока приоритетный маршрут снова не перейдёт в состояние UP. Очевидно, что резервных маршрутов в такой схеме может быть несколько. Очевидно также, что она работоспособна только в том случае, если приоритетный интерфейс имеет встроенные средства для мониторинга соединения на физическом и/или канальном уровне (либо их эквивалентах для туннелей).

Для статических маршрутов метрика назначается вручную. Для маршрутов, получаемых динамически (по протоколам PPP, DHCP и т.п.), также предусмотрен соответствующий параметр. Пример:

port
: m1
: : type                       = "3g"
: : encapsulation              = "ppp"
: : ppp
: : : main
: : : : default-route          = true
: : : : default-route-metric   = 1
: m2
: : type                       = "3g"
: : encapsulation              = "ppp"
: : ppp
: : : main
: : : : default-route          = true
: : : : default-route-metric   = 3

В данном случае порт m1 является основным. Порт m2 живёт своей собственной жизнью, падает, восстанавливается, и никак не используется до тех пор, пока работает основной порт.

Скрипты netping. Механизм netping в NSG Linux предусматривает два произвольных скрипта — на случай пропадания связности и её восстановления. В скриптах можно использовать любые команды оболочки bash ОС Linux, а также вызов nsgsh в пакетном режиме, с оглядкой на права доступа для исполнения требуемых команд. Для управления маршрутами рекомендуется использовать непосредственно утилиты route или (рекомендуется) ip route, не затрагивая nsgsh и прав доступа в ней. Однако для этого необходимо знать, хотя бы с минимальном объёме, синтаксис их команд:

ip route add X.X.X.X/M dev интерфейс
ip route add X.X.X.X/M via G.G.G.G 
ip route del X.X.X.X/M dev интерфейс
ip route del X.X.X.X/M via G.G.G.G 
ip route add default dev интерфейс
ip route add default via G.G.G.G 
ip route del default dev интерфейс
ip route del default via G.G.G.G 

Если удаляемый маршрут — единственный в данную сеть, то выходной интерфейс и адрес шлюза указывать необязательно, например:

ip route del default

Подробное описание синтаксиса ip route см. в man pages.

События интерфейса. Любой из IP-интерфейсов в NSG Linux можно рассматривать как генератор событий, которые, в свою очередь, могут анализироваться обработчиком событий и приводить к исполнению заданных скриптов. Явной необходимости в манипулировании таблицей маршрутизации при помощи данного механизма нет, поскольку маршруты добавляются и удалятся автоматически. Однако его можно использовать, например, для управления сложной маршрутизацией на основе правил, или для каких-либо других действий.

Рестарт портов и туннелей. Одно из возможных действий при переходе с одного канала связи на другой — переустановление туннелей по новому маршруту. Это может потребоваться по двум причинам:

• Для возобновления работы с новым IP-адресом клиента, под которым он виден серверу. При этом на стороне сервера следует использовать механизмы DPD, keepalive и т.п., чтобы своевременно удалять "мёртвые" сессии.
• Для создания необходимых записей NAT на промежуточных узлах, например, на выходе из приватной сети поставщика услуг в публичный Интернет.

Также может потребоваться рестарт проблемного порта, как тупой и надёжный способ восстановить его работу.

Для рестарта портов и туннелей в командных оболочках NSG Linux имеется команда restart в этих узлах. Команда выполняется с правами пользователя и, следовательно, может применяться в скриптах без ограничений.