Достаточно часто автономные системы пытаются балансировать входящий трафик между несколькими провайдерами, используя тот же механизм 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. После этого можно восстанавливать анонсы маршрутов.