Найкраща практика комбінації HSRP та ECMP

Поєднання ECMP (або інших причин асиметричного шляху) та HSRP за замовчуванням розбивається в Cisco IOS; поведінка за замовчуванням у цьому дизайні надмірно затоплює одноразовий трафік.

Яка найкраща практика використання HSRP з ECMP для запобігання невідомого одноразового затоплення?

Деталі / передумови

У нас є топологія HSRP, схожа на першу схему нижче, для багатьох наших об'єктів. Наші маршрутизатори Cisco WAN мають маршрути з рівними витратами на всі інші сайти; таким чином, ми можемо бачити асиметричні ефекти маршрутизації весь час. Зазвичай ми призначаємо R1 як первинний HSRP, але ECMP дозволяє повернути трафік через R1 або R2.

Проблема полягає в тому, що коли PC1 монтує віддалений диск iSCSI по всій WAN, трафік залишає сайт через R1, але може повернутися через R2. Поки трафік iSCSI повертається через R1, проблем не виникає.

Проблема виникає, коли трафік PC1 повертається через R2. Припустимо, що сеанс iSCSI починається о 8:00:00, і обидва маршрутизатори та обидва комутатори вивчають mac PC1 одночасно. Між 8:00 та 8:00:05 проблем із затопленням немає, оскільки обидва комутатори все ще мають мак-адресу PC1 у своїй таблиці CAM.

Через п’ять хвилин після початку сеансу iSCSI, запис CAM S2 для mac PC1 закінчується з таблиці CAM, а S2 заповнює трафік PC1 з усіх портів (у цьому випадку на Po1, Gi0 / 3 та Gi0 / 4). Якщо сеанс iSCSI PC1 вимагає великої пропускної здатності, це невідоме одноразове затоплення може витягнути нетривіальну ємність із посилань на PC3 та PC4.

Комутатори Cisco IOS мають таймер CAM за замовчуванням 300 секунд ...

S2# show mac address-table aging-time
Vlan Aging Time
---- ----------
1    300
17   300

Однак ARP-таймер інтерфейсу Cisco IOS за замовчуванням становить 4 години ...

R2# show interface gi0/0
GigabitEthernet0/0 is up, line protocol is up 
  Hardware is AmdP2, address is 000a.dead.beef (bia 000a.dead.beef)
  Internet address is 172.17.1.252/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00       <--------------

Тому S2 починає затоплювати трафік iSCSI PC1 через п'ять хвилин.

Проста відповідь полягає в тому, щоб зробити таймер CAM рівним або трохи довшим, ніж відповідний таймер ARP інтерфейсу , але є щонайменше три різні варіанти для вибору з ...

Варіант 1: Опустіть усі таймери інтерфейсу ARP

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

• На всіх інтерфейсах Ethernet IOS, що стоять перед комутатором Ethernet: arp timeout 240
• На всіх інтерфейсах Ethernet IOS, що стикаються з комутатором Ethernet: hold-queue 200 inі hold-queue 200 outщоб уникнути падіння пакетів ARP під час періодичного оновлення ARP (ці обмеження можуть бути вищими або нижчими залежно від того, скільки оновлень ARP ви вважаєте, що вам потрібно буде обробити одразу). Якщо ви коригуєте значення селективної відмови пакетів , то слід дотримуватися вказівок у роботі, яку я пов’язував.

Це змушує Cisco IOS оновлювати таблицю ARP протягом чотирьох хвилин, якщо це не сталося інакше для заданого запису ARP. Очевидним недоліком є ​​те, що це не так добре, якщо у вас багато записів ARP ... обмеження залежать від платформи. Я використовував це з декількома сотнями ARP на маршрутизатор на Catalyst 4500/6500 (SVI Layer3) без жодних проблем.

Варіант 2: Збільшити таймери перемикача CAM

Цей параметр найкраще працює, якщо у вас є велика кількість записів ARP (тобто тисячі, наприклад, інтенсивне середовище VMWare).

• На всіх комутаторах IOS: mac address-table aging-time 14400або mac address-table aging-time 14400 vlan <vlan-id>для будь-якого Vlan, який викликає занепокоєння.

Ця зміна коригує таймери, які, як вважають, більшість людей фіксуються на 300 секунд (на Cisco IOS), тому обов'язково включіть це в документи про безперервність. Побічним ефектом цього є те, що записи таблиці CAM затримуються протягом 4 годин після видалення ПК (що може бути як добрим, так і поганим, залежно від рівня PoV). Якщо 4 години занадто довгі, дивіться наступний варіант ...

Варіант 3: Зміна як таймерів ARP інтерфейсу, так і комутаторів таймерів CAM

Ця опція дозволяє уникнути жахливо тривалих таймерів CAM у варіанті 2 за рахунок більшої конфігурації. Ви можете вибрати, чи потрібні вам 900 секунд, 1800 секунд чи що завгодно ... просто переконайтеся, що ваші таймери CAM і ARP відповідають; Таким чином, вам потрібно буде налаштувати як Варіант 1, так і Варіант 2 у своїх топологіях.

Для мене ECMP є справжньою проблемою тут - тому крім вищезазначених кроків для обмеження невідомого однотопного затоплення, ви також можете налаштувати показники маршруту до WAN, щоб R1 було віддано перевагу R2 для зворотного трафіку. Один із способів досягти цього - через список розповсюдження на R2 наступним чином: (EIGRP використовується лише для прикладу; те ж саме можна досягти з OSPF або BGP за допомогою інших команд)

!
ip префікс-список R1-PREFER seq 5 дозволяють 172.17.1.0/24
!
карта маршруту R1-PREFER-MAP дозвіл 10
 відповідність префіксу списку ip адреси R1-PREFER
 встановити метрику 1 1 1 1 1
... (дозволити всі інші маршрути)
!
маршрутизатор eigrp 1
 ….
 розподілити-список маршрутної карти R1-PREFER-MAP out Ser1 / 0
 ….
!

Це призведе до того, що WAN буде перенаправляти весь трафік за 172.17.1.0 на R1. Якщо R1 Se1 / 0 не вдається, маршрут буде встановлений у напрямку R2. Ви можете додатково налаштувати ці показники, щоб резервний шлях на R2 насправді був можливим наступником для швидшого відмови. HSRP та відстеження дбають про вихідний трафік.

Ідея, якщо не використовувати ECMP, якщо HSRP використовується, може бути нормальним для СЕРВЕРІ, коли вхідний трафік може бути більшим, ніж вихідний трафік, в ситуації з ПК ВЗАГАЛЬНО вхідний трафік з WAN (відповідей) вище, ніж вихідний трафік (вхід). Нам подобається, що більшість людей просто встановлюють таймери ARP. Ви можете поплутатися з таймерами CAM, але якщо ви скажете MDF з перемикачем шару 3 та IDF з 2 перемикачами колекції і скажімо, 5 перемикачів доступу, це налаштування на L3 SVI легше, ніж робити всі комутатори доступу.

Можна було б використовувати стек комутаторів, щоб зменшити цю проблему із закінченням терміну введення MAC-адреси у другому комутаторі.

Ага, я пам’ятаю цю. Тижні веселощів мали справу з цим ще кілька робочих років тому. Однією зморшкою є те, що події STP переведуть владу в режим швидкого старіння, тому встановлення таймера MAC довше, ніж таймер ARP, не допоможе

Я вирішив цю проблему, відтіснивши ECMP назад із серверів, створивши два плаваючих HSRP-шлюзи, з одним основним на кожному маршрутизаторі. Потім ми налаштували обидва шлюзи на кожному хості. Примушуючи таким чином трафік хоста до R1 та R2, ми будемо впевнені, що R2 ніколи не визреє MAC-адреси.

В ідеалі це не буде проблемою, якщо L2 / 3 комутатори очищають записи ARP, пов'язані зі застарілими MAC-адресами. Наступний пакет IP-адреси призведе до нового запиту ARP, заповнивши кеш ARP та таблицю MAC. Я думаю, що Cisco врешті реалізував це, але не можу сказати точно.

Короткий зміст: MC-LAG або HSRP GARP

Я ніколи не був прихильником настроювання таймерів. Таймери встановлюються певним чином, як правило, з багатьох причин. Змінення їх:

• потенційно оперативно інтенсивно підтримувати всюди те саме
• робить речі складнішими та складнішими
• як показав останній коментатор, може мати несподівані побічні ефекти
• може не «грати добре» з майбутніми вдосконаленнями Cisco

По черзі:

1. Використовуйте MC-LAG (він же "MEC" в документації Cisco). Це ваш найкращий варіант, хоча ви повинні розуміти сценарії розгортання, коли MC-LAG можна використовувати (це не універсальне рішення, і його слід розгорнути лише після відповідних досліджень та тестувань). Варіанти MC-LAG залежать від обладнання. Приклади:

   а. Укладання (Cat 3k)

   б. VSS (Cat4k / 6k)

   c. VPC (Nexus)

   г. Псевдо mLACP (ASR1k)

   е. MC-LAG (ASR9k)

   f. Кластеризація (ASA)

2. Увімкніть HSRP періодично надсилати безкоштовні пакети ARP . Зрозуміло, це схоже на зміну таймерів, але це набагато витонченіша зміна, ніж маніпулювання таблицею CAM та таймерами ARP. (Однак зауважте, що це залежить від вашої апаратної та програмної комбінації, але не всі реалізації HSRP пропонують це.)

   За замовчуванням HSRP надсилає 3 GARP через 0, 2 та 4 секунди після того, як маршрутизатор стане шлюзом для пересилання. Однак є параметр конфігурації, який дозволяє вибрати кількість GARP (включаючи "нескінченний") та інтервал.

Я використовую MC-LAG досить широко, зокрема VSS, VPC та кластеризація (я не прихильник складання).

Там, де я не можу використовувати MC-LAG або GLBP, це те, що я застосовую до моїх прикордонних маршрутизаторів L2 / L3 (у мене є кампус на 350 будівель, тому я дуже активно використовую Cat6k):

Cat6k-v15(config)#interface vlan 100
Cat6k-v15(config-if)#standby arp ?
  gratuitous  Setup gratuitous ARP interval and count

Cat6k-v15(config-if)#standby arp gratuitous ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count ?
  <0-60>  Number of gratuitous ARPs to send after group is activated (0 for continuous)

Cat6k-v15(config-if)#standby arp gratuitous count 0 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval ?
  <3-1800>  Gratuitous ARP Interval (sec)

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 ?
  count     Set HSRP gratuitous ARP count
  interval  Set HSRP gratuitous ARP interval
  <cr>

Cat6k-v15(config-if)#standby arp gratuitous count 0 interval 60 

(Я розміщую посилання на все це, але у мене немає достатньо високої "репутації" на цьому веб-сайті, щоб розміщувати більше двох URL-адрес.)

Я щойно зрозумів, що мій оригінальний коментар є дійсним - але, на жаль, неповним. Рекомендація щодо нейтрального дизайнера - будувати трикутники, а не прямокутники. Так:

1. Не тільки MC-LAG, але й MC-LAG на обох шарах. Тоді ви маєте справу зі спільною таблицею CAM як на рівні комутатора, так і на рівні маршрутизатора.

2. Якщо ви не можете цього зробити, MC-LAG або маршрутизатор, або комутатор, і MC-LAG на інший шар з додатковою ланкою (тобто повна сітка між маршрутизаторами і комутаторами). STP забезпечить топологію без циклу.

3. Якщо ви не можете цього зробити, все одно заповніть маршрутизатори та комутатори. STP забезпечить топологію без циклу, а таблиці CAM комутаторів все ще будуть знати всі відповідні правила переадресації MAC. Сервер завжди надсилатиме його MAC, і якщо ви налаштовуєте HSRP GARP з інтервалом в 1 хв, комутатори також не забудуть HSRP vMAC.

Кращі параметри в такому порядку. Але принаймні встановіть цю додаткову пару посилань.