Задача использования нескольких альтернативных каналов связи (основного и резервного/-ых) с сетями общего пользования для устройств, которые используются конечным абонентом, существенно отличается от классической постановки для операторских устройств. Применение динамической маршрутизации в данном случае не представляется возможным, поскольку требует, для начала, наличия у клиента собственного IP-адреса или пространства адресов, независимого от того, через какого оператора он в данный момент подключён. (В терминах IP-сетей, сеть абонента должна являться автономной системой.) Это достаточно сложная и дорогая услуга, доступная в реальности только операторам связи и крупным корпоративным пользователям. (По крайней мере, до широкого распространения протокола IPv6 — т.е. до морковкина заговения.) Обыкновенные конечные абоненты получают IP-адреса из пула адресов того или иного оператора, поэтому адреса будут свои для каждого соединения и принципиально не могут быть одними и теми же.

Как следствие вышесказанного, услуги протоколов динамической маршрутизации конечным абонентам не предоставляются ввиду их бессмысленности в такой ситуации.

Задача усложняется ещё более, если конечным пользователям выделяются не реальные статические, а динамические и/или приватные IP-адреса в сетях операторов, что является ныне общепринятой практикой. В этом случае абонент виден в Интернет под, вообще говоря, непредсказуемым и непостоянным адресом из пула оператора.

По этим причинам конечному абоненту приходится идти существенно другим путём: контролировать состояние доступных каналов связи и из фактически работающих выбирать один по некоторым приоритетам. Задача, таким образом, распадается на две:

• Регулярный мониторинг состояния каналов связи
• Переключение трафика с основного канала на резервный и обратно

В относительно простых ситуациях эти задачи решаются штатными средствами стека IP. В более сложных (более двух каналов связи с разными приоритетами, и/или отсутствие средств контроля для всех или некоторых каналов) приходится прибегать к помощи дополнительных скриптов. Но даже в этом случае возникает ещё и третья составляющая проблемы: при переключении на другой канал (или даже при переподключении по прежнему) клиент получает новый IP-адрес. Для серверов, с которыми он работает, он становится, как правило, уже новым клиентом, старая пользовательская сессия должна быть разорвана, и установлена новая. Переустанавливать сессию прозрачным образом (т.е. незаметно для прикладного трафика) в таких условиях могут не все типы туннелей; в частности, это Wireguard и OpenVPN.