Достаточно часто автономные системы пытаются балансировать входящий трафик между несколькими провайдерами, используя тот же механизм primary-backup. Для некоторых префиксов один канал настраивается в качестве первичного, а остальные служат резервными, тогда как для других префиксов в качестве основного может быть выбран другой канал.
Пример такой ситуации показан на рисунке 2:
+----+peer peer+----+ |AS 3|--------------------------|AS 4| +----+ +----+ |provider provider| | | | customer| |customer | +----+ +----+ |AS 2| |AS 5| +----+ +----+ |provider provider| | | | | |customer customer| +-----------------+ +----------+ | | backup (192.0.2.0/25) | |primary service (192.0.2.0/25) primary (192.0.2.128/25)| |backup service (192.0.2.128/25) +----+ |AS 1| +----+ Рисунок 2
В преднамеренной конфигурации весь входящий трафик для блока адресов 192.0.2.0/25 приходит по каналу из AS5, а трафик для блока 192.0.2.128/25 — из AS2.
В данном случае при разрыве канала между AS3 и AS4 автономная система AS3 будет получать оба маршрута от AS2, а AS4 — от AS5. Поскольку маршруты от заказчиков являются предпочтительными по сравнению с маршрутами от партнеров (peer route), при восстановлении связи между AS3 и AS4 ни AS3, ни AS4 не будут менять свое поведение относительно маршрутов AS1. В данном случае описанным выше способом не удастся восстановить преднамеренное состояние, поскольку здесь нет eBGP-партнера для разрыва сессии, способного восстановить состояние. Это один из примеров BGP Wedgie.
Способ восстановления в этом случае заключается в том, что AS1 прекращает анонсировать резервные соединения в оба канала и работает некоторое время без резервирования, после чего восстанавливает анонсы своих префиксов в резервные пути. Продолжительность интервала работы без резервирования невозможно определить заранее и этот интервал должен быть достаточно продолжительным, чтобы AS2 и AS5 узнали дополнительный путь в AS1. После этого можно восстанавливать анонсы маршрутов.