Для розуміння цього потрібно зрозуміти, як влаштована маршрутизація між складовими частинами великого Інтернету.
Тепер усложним ситуацію. Аплинк у нас не один, а кілька. І в кожен ми Анонси себе. Звідки в цьому випадку буде приходити трафік? Протокол BGP в цьому випадку визначає поняття найкращого шляху (best path) і резервних шляхів на випадок відмови цього самого кращого. Природно, трафік буде приходити з того аплинка, який буде в найкращому шляху до нас для джерела цього трафіку. В ідеалі, якщо у нас, скажімо, три аплинка і користувачі звертаються до різних ресурсів з однаковою ймовірністю - то трафіку з усіх трьох АПЛІНК буде порівну. Але це - в ідеалі. Розглянемо, що ж є цей самий найкращий шлях з точки зору протоколу BGP.
Найкращим вважається той шлях, при якому пакет проходить по дорозі найменше число автономних систем. От і все. На жаль. Не враховуються ні затримки, ні втрати пакетів, ні ширина каналів, ні число роутерів всередині кожної автономної системи. Тому шлях трафіку в протоколі BGP і називається AS-шлях (AS-path). У ньому перераховано список автономних систем по дорозі до нашої мережі.
Ясна річ, що на практиці в більшості випадків нас така справа не влаштовує. Для часткового виправлення ситуації в BGP були придумані методи, що дозволяють використовувати і адміністративні критерії для управління трафіком. Ці критерії отримали назву local-pref і prepend. Якщо ми бачимо, що з одного каналу йде 70% трафіку, а з інших - по 15%, то ми розуміємо, що з цим треба чогось робити. В першу чергу звичайно це означає, що той аплинк, від якого надходить більше трафіку, краще включений в мережу Інтернет сам (тобто середній BGP AS-шлях менше). Якщо ми все ж хочемо, щоб трафіку з цього лінка було менше - ми вставляємо один або два препенда в AS-шлях. Це означає, ми штучно подовжує AS-шлях на 1-2 AS, як ніби-то нашу мережу анонсуємо не ми, а хтось на 1-2 автономних системи далі. Тоді частина маршрутизаторів, раніше вважали шлях через цей аплинк кращим, виберуть інші шляхи. Так можна балансувати завантаження своїх вхідних каналів. Тепер припустимо, що у нас є основний (як правило, найдешевший) аплинк і запасний аплинк. Як зробити запасний аплинк резервним? А практично так само. Додаємо в анонси в резервний аплинк 3-5 препендов, і робимо штучно шлях через цей аплинк зовсім вже довгим у порівнянні з основним. Тоді якщо раптом зв'язність з основним аплінком зникне, то BGP-сесія з ним порветься, основний аплинк перестане від нас отримувати анонси наших мереж, і відповідно перестане їх анонсувати далі. Тоді основний шлях зникне з таблиць маршрутизації прикордонних Рутер мережі Інтернет, а залишиться тільки той довгий шлях через резервний лінк. Він і буде обраний в якості кращого: інших-то варіантів немає! І все це відбудеться автоматично, без втручання системного адміністратора, скриптів або чогось ще!
Варто зазначити, що таким шляхом ми лише знижуємо ймовірність того, що резервний шлях буде обраний як найкращий. Гарантувати це не можна ніяким числом препендов. А все тому, що крім технічних критеріїв вибору шляху є ще й адміністративні. І як би не був довгий резервний шлях, він тим не менше може бути обраний. Наприклад, багато хто вибирає шлях через точки обміну трафіком кращим, ніж через аплинк, тому що він дешевше і швидше. АПЛІНК вибирають завжди прямий шлях до своїх клієнтів, навіть при наявності інших шляхів. У деяких країнах законодавчо заборонено використовувати шлях через закордон при наявності шляху всередині країни. І так далі. Як правило, через резервний лінк буде проходити 5-10% трафіку від основного линка. Але все залежить від того, як ці лінки включені в світовий Інтернет. До речі, на практиці в колишньому СРСР відповідь на це питання, на жаль, звучить так - однаково погано.
А ще можна будувати пиринге. Це коли безпосередньо будується лінк до сусідньої мережі, приймаються маршрути її мереж, і віддаються маршрути власних. Так народжується міжмережевий обмін "по-дорослому". А участь в точці обміну трафіком означає, що ми віддаємо туди маршрути до своїх мереж, а отримуємо і приймаємо маршрути до мереж учасників безпосередньо, народжуючи міжмережевий обмін масштабу міста або навіть країни.