Що робити, коли не працює prepend



Хочемо поділитися перекладом серії заміток з блогу Расса Уайта (Russ White), де він піднімає питання використання AS-PATH Prepend при підключенні до Інтернет-провайдерів за BGP.
При підключенні організації до двох і більше провайдерів за BGP можуть виникати кілька завдань. Наприклад, уникнути асиметричної маршрутизації, тобто, домогтися, щоб відповідні пакети поверталися через того ж провайдера, через якого ініціюється сесія. Або, навпаки, домогтися рівномірного розподілу трафіку каналами провайдерів, не беручи до уваги асиметричну маршрутизацію. В обох випадках впливати на маршрутизацію Інтернет-провайдерів у бік корпоративної мережі можна за допомогою BGP-атрибуту AS-PATH. Але, на жаль, такий підхід далеко не завжди допомагає домогтися потрібного результату. Про проблеми використання AS-PATH Prepend як раз і піде мова.

Чому не працює AS-Path Prepend?

Отже, ви хочете поліпшити розподіл навантаження на вхідних каналах. Пошукавши в Інтернеті, ви досить швидко знайдете сайт, де пояснюється, як налаштувати для даної задачі AS-Path Prepend. Під час наступних профілактичних робіт ви все це зробите і… виявите, що якась кількість трафіку перенаправляється, але не так багато, як хотілося б. Ви чекаєте наступних планових робіт на каналі і налаштовуєте ще кілька prepend-ів. Знову запускаєте і… бачите, що майже нічого не змінилося. Чому так? Є кілька причин, за якими prepend не завжди виявляється ефективним. Але головним чином це пов'язано з тим, що сам по собі влаштований Інтернет. В якості прикладу мережі візьмемо зображення нижче.


Ви знаходитесь в AS65000 і намагаєтеся відбалансувати трафік між каналами 65001->65000 та 65004->65000. Припустимо, prepend ви налаштували для AS65001, оскільки цей провайдер шле вам більше трафіку. Припустимо, що AS65003 приймає маршрути від AS65001 і AS65004 на рівних умовах. Налаштувавши prepend, ви зробили так, що маршрут до мереж в AS65000, з точки зору AS65003, став виглядати довше через AS65001. Тут перший prepend спрацює.

Але що буде, якщо ми додамо ще один додатковий prepend? Чи вплине він як-небудь на потік трафіку? У AS65003 є тільки два можливих шляхи до пунктів призначення: один через AS65001, другий через AS65004. Він може вибрати тільки один з цих двох маршрутів. Якщо тут спрацював один prepend, другий вже нічого не зробить. Це підводить нас до першої проблеми з використанням prepend: він ефективний тільки коли заданий в межах реалістичних параметрів AS-Path. Додаткові 256 prepend-ів у цій мережі не дадуть більшого ефекту, ніж той, що був від першого них.

Якщо ефективність використання prepend пов'язана з загальною довжиною маршруту по мережі, то перше питання, яке слід задати — яка середня довжина маршруту в Інтернеті? Виявляється, є організації, які проводять такі виміри регулярно і вже досить давно (за мірками Інтернету). Приміром, у аналітиків CAIDA, RIPE і Potaroo є дані масштабних вимірювань, поведених в Internet Default-Free Zone (DFZ). Ось графік середньої довжини AS Path в DFZ з 1998 року:


Як бачимо, середня довжина Path AS мало змінилася за останні 8 років — навіть незважаючи на те, що кількість маршрутів і підключених автономних систем за цей же час разюче зросла. Це дозволяє зрозуміти, що в більшості випадків перший AS-path prepend матиме найбільший ефект, другий вплине менше, а всі інші вже будуть просто для краси.

Є дві причини, чому prepend може взагалі не працювати.

Перша: візьмемо з'єднання між AS65001 і AS65004. Ми знаємо, що між ними існують якісь пірингові взаємини: можливо, з оплатою, можливо, без — це нам невідомо. Але ми знаємо напевно, що AS65001 завжди віддасть перевагу ваш маршрут, отриманий від вас, цим же маршрутом, отриманого від AS65004. І це перевагу налаштоване у AS65001 через LOCAL_PREF, пріоритет у якого завжди буде вище, ніж у вашого AS-Path Prepend. Висновок? Як не намагайтеся, у вас не вийде направити трафік по шляху 65004->65001 з допомогою prepend.

Друга: зверніть увагу на AS65002 в кутку. AS65001 завжди буде віддавати перевагу маршруту до клієнта, отриманим від самого клієнта. Так що, крім вищесказаного, вам також ніяк не змусити трафік від AS65002 йти через AS65004 замість AS65001.

Тепер, знаючи, чому prepend не завжди спрацьовує, давайте подумаємо, що ми можемо зробити.

Що робити?

Коли ми визначили, що AS-Path prepend нам вже нічим не допоможе, які наші подальші дії?

Маршрутизація ґрунтується на виборі найдовшого префікса, що збігається з адресою призначення. Це вірно і при порівнянні BGP маршрутів, безвідносно AS-PATH. Так що, один з варіантів тут — розділити ваше адресний простір на більш довгі анонсуються префікси і анонсувати частина кожному з ваших вищих провайдерів (для забезпечення відмовостійкості можна налаштувати анонсування префікса через іншого провайдера на основі умови недоступності першого — BGP conditional advertisement feature — прим. ред.). На рис. 3 показано, що AS65000 розділяє свій /44 IPv6-префікс на два і анонсує їх AS65001 і AS65004 відповідно, із-за чого половина трафіку підмережі AS65000 приходить від одного конкретного провайдера. Цей прийом можна використовувати разом з AS-Path prepend, щоб ефективніше розподіляти навантаження.


Використання більш довгих префіксів для залучення трафіку з кращого вхідному каналу — вже непоганий крок до формування бажаного патерну вхідного трафіку. Деякі сценарії вимагають більш гранулярного управління.

Але що робити, якщо у нас немає можливості створювати більш довгі префікси у вашій ASN (наприклад, в /24 для IPv4 /48 для IPv6)? У таких випадках нам може допомогти атрибут community протоколу BGP. Використання community дозволяє впливати на те, як ASN анонсується всередині мережі нашого вищого провайдера та його учасникам. Приклад можна бачити на рис. 4. AS65002 — клієнт AS65001, відповідно до політики маршрутизації всередині 65001, префікси, що отримані від клієнтів, мають пріоритет над тими, що отримані від BGP-бенкетів. Це означає, що незважаючи на AS prepend, анонсований для AS65001 з нашого каналу, AS65002 все одно буде використовувати 1-гігабітний канал. Якщо AS65002 шле нам багато трафіку, ми можемо зіткнутися з перевантаженням вхідного з'єднання через AS65001. З допомогою BGP community можна зробити так, щоб AS65001, незважаючи на власну політику, направляв трафік до AS65004.


У більшості провайдерів є документ, в якому зазначено, які community він приймає і використовує для таких завдань — майже ніхто з провайдерів не використовує community, позначені в RFC1998. Приміром, ось старий документ по L3, і ось список політик BGP community, які зараз використовує провайдер JT. Кращий спосіб з'ясувати такі речі — запитати безпосередньо у провайдера.

AS prepend, поділ префіксів і BGP community можна використовувати одночасно, але при цьому дуже важливо добре продумати політику BGP.

Стабільність, яку дасть більш складна політика, може позначитися на стійкості системи в разі відмови або породити зайву складність у налаштуванні, логіку якої буде непросто зрозуміти в два ночі. Головне питання, яким повинен задатися інженер при створенні політики — що буде, якщо що-небудь відвалиться? На рис. 5 політики з рис. 3 і рис. 4 застосовані одночасно. Про що відразу слід подумати:

  • Потрібно нам анонсувати агрегований маршрут разом з нашими довгими префіксами? Підказка: відповідь на це питання майже завжди позитивна.
  • Немає у AS65004 суперечливої політики внутрішньої маршрутизації?
  • Що відбудеться у випадку відмови каналу?
  • Повинні відповіді на вихідні пакети повертатися по тим же каналам (stateful firewalling або NAT)?

Про що варто задуматися, перш ніж вирішувати проблему?

Цей невеликий цикл почався з простою проблеми — що робити, якщо у нас не від балансовано вхідний трафік на двох каналах з виходом в Інтернет. Іншими словами, як реалізувати розподіл навантаження в BGP. Перша частина стосувалася проблем з AS-Path prepend, а друга – деагрегации і використання атрибута communitу для модифікації local preference в мережі вашого провайдера.

В останній частині ми знову торкнемося деагрегации. Анонсування більш довгих префіксів — це «важка артилерія» маршрутизації. З анонсуванням більшого числа префіксів слід бути обережніше. Default Free Zone — це суспільна власність. Таблиця маршрутизації в Інтернеті нікому не належить, але всі нею користуються. Деагрегация не варто вам нічого, але всім іншим доводиться розплачуватися. Додати ще один маршрут в таблицю маршрутизації нескладно, але пам'ятайте, що більш довгий префікс, який ви додасте, буде видно всьому Інтернету. За рішення своєї проблеми ви розраховуєтесь невеликою кількістю пам'яті з кожного маршрутизатора в світі, підключеного до DFZ. Якщо всі почнуть бездумно деагрегировать — всім доведеться купувати більш потужні маршрутизатори і додаткову пам'ять. Включаючи вас.

Є тонка грань між використанням громадського ресурсу і зловживанням нею. Якщо всі будуть зловживати громадським ресурсом, тому що їм це «нічого не варто», результат буде згубним для цього ресурсу. А зруйнувавши суспільну власність, буде дуже непросто відновити початкові довірчі відносини, завдяки яким вона з'явилася. Так що, перш ніж настроювати деагрегацию, подумайте, чи дійсно без цього вам не обійтися.

чи Так це необхідно? Дійсно так важливо відбалансувати ці два вхідних каналу? На те можуть бути фінансові причини, наприклад, вартість використання двох каналів або ціна перевищення трафіку на одному з них. Звичайно, це лише припущення, але, бути може, було б розумніше змінити ширину доступних каналів, ніж впроваджувати технічне рішення, яке потрібно буде обслуговувати і підтримувати.

Пам'ятайте, що все, що ви налаштовуєте, одного разу відмовить. А відмови нерідко виливаються у дзвінки вночі. Розгляньте різні варіанти, перш ніж настроювати оптимізацію.

Як мені зменшити шкоду суспільній власності?


Повертаючись до мережі з нашого першого прикладу — чи можна реалізувати деагрегацию так, щоб перевести трафік з AS65001 на AS65004, не впливаючи на розмір таблиці у всіх, до кого підключені ці провайдери? Власне, більшість провайдерів не тільки приймають надіслані вами community для налаштування local preference в їх AS, але також дозволяють блокувати анонсування своїм учасникам будь-якого зазначеного маршруту. Вам може знадобитися трохи пограти з цими community, щоб зрозуміти, як вони впливають на потік вхідного трафіку. Наприклад, як позначиться блокування анонсування більш довгих префіксів транзитним бенкетам вищестоящого провайдера, в порівнянні з блокуванням анонсування цих префіксів для певної групи клієнтів провайдера. Оскільки ви не можете безпосередньо визначити, як і де підключений цей провайдер, можна зв'язатися з ним і з'ясувати, що і де варто анонсувати, щоб мінімізувати глобальний вплив, або ж спробувати різні поєднання і в процесі визначити кращий варіант.

чи Правильно у мене влаштований пірінг? Ще один варіант — звернути увагу, через яких провайдерів ви підключаєтеся в глобальній мережі. Припустимо, що це один регіональний і один глобальний провайдер. В такому разі, те, який з них шле вам більше трафіку, буде сильно залежати від вашої клієнтської бази.

Наприклад, якщо ви місцева компанія зразок регіонального банку або медичного закладу, то більшість ваших клієнтів буде підключено до регіонального провайдера (а не до tier-1), і, швидше за все, більшу частину трафіку ви будете отримувати з його каналу. Якщо ж ваш бізнес не так прив'язаний до географічному розташуванню, то від регіонального провайдера трафіку буде приходити не так багато — здебільшого від людей, які заходять в вашу мережу, перебуваючи у вашому регіоні. У таких випадках нерівномірне навантаження на цих двох каналах — річ цілком очікувана.

Якщо ситуація саме така, можливо, було б правильніше налагодити взаємодію з двома провайдерами так, щоб воно зближувало вас з вашими клієнтами. Якщо ваші клієнти знаходяться по всьому світу, швидше за все, вам краще бути підключеним до двох провайдерам національного або глобального рівня, ніж до одного регіонального і глобального. По можливості, краще балансувати вхідний трафік, відштовхуючись від того, хто ваші клієнти і як краще їх охопити, замість того, щоб йти на різні інженерні хитрощі, намагаючись змусити мережі двох провайдерів абсолютно різного типу слати вам однакову кількість трафіку.

Висновок тут такий: інженерне рішення повинно бути останнім виходом, коли більше нічого не допомагає. Зрозуміло, всі ми тут інженери, і для нас ніщо так не виправдовує гроші, витрачені на купівлю залозок, як витончений і об'ємний набір команд і конфігурацій цих залозок, з допомогою якого ми вирішили проблему високої завантаження каналу. Але все ж справжнє інженерне мистецтво — знаходити першоджерело, заглиблюючись у саму суть проблеми, а не боротися з вторинними наслідками.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.