Як fabric EVPN знає, де ваш сервер

Класична комутована мережа знаходить сервер криком: розіслати кадр усюди, побачити, хто відповість, запам’ятати порт. Fabric BGP EVPN знаходить його, бо їй про це кажуть. Ця єдина різниця пояснює, чому fabric EVPN масштабуються, швидко перемикаються при відмові і піддаються аудиту, і її варто розуміти, навіть якщо ви ніколи не налаштовуватимете таку самі.

Проблема flood and learn

Традиційний Layer 2 вивчає MAC-адреси з трафіку. Коли комутатор не знає, де живе призначення, він розсилає кадр з кожного порту у VLAN. Spanning tree потім блокує достатньо лінків, щоб зупинити нескінченне зациклення розсилання, а це означає, що чимала частка кабелів, за які ви заплатили, простоює. Розтягніть цей VLAN на багато стійок, і ви отримаєте великі домени відмов, повільну збіжність і мережу, яку ніхто не може повністю описати, бо її стан живе в таблицях, які самі заповнюються і спорожнюються.

VXLAN сам по собі вирішує проблему транспорту: він загортає кадри Ethernet в UDP, щоб сегмент Layer 2 міг перетнути маршрутизований underlay з усіма активними лінками. Але простий VXLAN усе одно розсилає, щоб вивчати. EVPN замінює це вивчення площиною керування.

Що насправді анонсує EVPN

EVPN є сімейством адрес BGP. Кожен leaf-комутатор, до якого під’єднані сервери, діє як кінцева точка тунелю VXLAN (VTEP) і повідомляє іншим leaf те, що знає, за допомогою невеликої кількості типів маршрутів. Три з них роблять більшу частину роботи:

• Тип 2, анонс MAC та IP. Коли сервер надсилає свій перший кадр або ARP, локальний leaf вивчає його MAC (і зазвичай IP) і анонсує його кожному іншому leaf зі своєю власною адресою VTEP як next hop. Тепер кожен leaf знає, де цей сервер, без жодного розсилання.
• Тип 3, inclusive multicast. Кожен leaf оголошує, в яких сегментах він бере участь. Це будує список VTEP, які мають отримувати broadcast і невідомий трафік для кожного сегмента. З ingress replication leaf-відправник робить unicast-копію для кожного з них, тож underlay узагалі не потребує multicast.
• Тип 5, префікс IP. Маршрутизовані підмережі, наприклад блок публічних адрес за firewall клієнта, анонсуються як префікси у VRF орендаря.

Route targets вирішують, хто що імпортує. Маршрути сегмента несуть його route target, і лише leaf, налаштовані з цим target, імпортують їх. Саме тут насправді забезпечується ізоляція орендарів, і тому нумерація сегментів і route targets заслуговує на справжню дисципліну (більше про це нижче).

Anycast-шлюзи: той самий маршрутизатор усюди

У fabric EVPN кожен leaf, що несе сегмент, може бути його шлюзом за замовчуванням, використовуючи ту саму IP і той самий віртуальний MAC. Перший hop сервера завжди є комутатором, у який він увімкнений. Якщо цей leaf відмовляє, bond сервера перемикається на інший leaf пари, який уже відповідає на ту саму адресу і MAC шлюзу. Нічого на сервері не змінюється, жоден протокол шлюзу не має нікого обирати, і навантаження можуть переміщуватися між стійками, зберігаючи свій шлюз.

У поєднанні з парами leaf, що працюють з virtual port-channel, це дає кожному хосту два фізичні комутатори за одним логічним bond. На NX-OS мінімальний anycast-шлюз виглядає так:

fabric forwarding anycast-gateway-mac 0000.2222.3333
interface Vlan210
  vrf member TENANT-A
  ip address 192.0.2.1/26
  fabric forwarding mode anycast-gateway

Відстеження хоста: команди, що мають значення

Коли щось не доходить туди, куди має, ось команди, з яких ми починаємо на Cisco Nexus, приблизно в такому порядку:

show nve peers                         ! are the other VTEPs up?
show nve vni                           ! is the segment up, control plane learning?
show l2route evpn mac all              ! which MACs are local, which are remote, and from which peer
show bgp l2vpn evpn <mac-or-ip>        ! the actual route, its RD, RT and next hop
show ip arp suppression-cache detail   ! is ARP being answered locally?
show vpc consistency-parameters vlans  ! do both leaves of the pair agree?

Історія, яку вони розповідають, зазвичай коротка. MAC, який локальний на одному leaf, але ніколи не з’являється в BGP на інших, вказує на локальне вивчення або конфігурацію сегмента. Маршрут, який присутній, але не імпортований, вказує на route targets. VTEP, якого бракує у show nve peers, вказує на underlay. Читати стан fabric отак можливо лише тому, що EVPN тримає цей стан у BGP, де він видимий і консистентний, а не в таблицях, вивчених розсиланням.

Нумерація є засобом безпеки

Кожному сегменту потрібен ідентифікатор мережі VXLAN (VNI) і route targets, і fabric прийме будь-яке число, яке ви введете. Два сегменти, що випадково ділять ідентифікатор, мовчки з’єднуються мостом, а помилково введений VNI, який випадково належить іншому сегменту, виглядає цілком легітимно на кожному екрані.

Захист: правило і машина, яка його перевіряє. Оберіть фіксоване правило виведення, наприклад VNI дорівнює фіксованому зсуву плюс номер локального VLAN, з route targets, виведеними з VNI, і потім перевіряйте це автоматично:

• Читайте карту VLAN до VNI з кожного leaf за графіком.
• Підтверджуйте, що кожен запис дотримується правила.
• Підтверджуйте, що кожен leaf, який має нести ті самі сегменти, несе ідентичні карти.
• Порівнюйте відбиток усієї карти з підписаним базовим рівнем у системі контролю версій, щоб навмисна зміна потребувала свідомого повторного підпису з автором, а ненавмисна викликала інженера.

Ми проганяємо саме цю перевірку на нашій fabric щогодини. Вона коштує кілька секунд доступу лише на читання і перетворює клас невидимих помилок на тривогу.

Що запитати про вашу власну fabric

• Чи ваші шлюзи anycast на кожному leaf, чи ними володіє одна пара комутаторів?
• Чи кожен хост під’єднаний до пари leaf двома лінками, чи лише дорогі?
• Чи хешують агреговані хости за рівнями 3 і 4, з узгодженою стороною комутатора, щоб обидва лінки справді несли трафік?
• Чи є записане правило нумерації VNI і route target, і чи щось його забезпечує?
• Чи може інженер показати вам, командами на кшталт наведених вище, де саме живе ваш сервер і як його трафік залишає стійку?

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

cta: Поговоріть з інженером

Related

• /what-we-do/network/datacenter-fabric/
• /what-we-do/network/change-discipline/
• /what-we-do/network/layer-2-extension/