Два канали, один router: DMVPN з двома cloud, який використовує обидві лінії

Більшість філій з двома WAN-каналами використовують один із них. Другий стоїть як резерв, оплачується щомісяця і вмикається лише тоді, коли перший виходить з ладу, і це ж перший момент, коли хтось дізнається, чи failover справді працює. З DMVPN і BGP ви можете використовувати обидва канали весь час, перемикатися між ними, не замислюючись, і довести, що обидва несуть трафік. Ось метод.

Коротко про DMVPN

Ми запускаємо BGP поверх DMVPN (mGRE, NHRP, IPsec), тож додавання або втрата майданчика є подією маршрутизації, а не переналаштуванням.

Звичний дизайн для резервування: два hub на одному cloud. Це захищає від відмови hub. Воно нічого не дає spoke з двома каналами, бо єдиний tunnel interface spoke походить від одного з них.

Дизайн з двома cloud

Виправлення: другий, незалежний DMVPN cloud, що походить від другого каналу. Звичне заперечення: це означає нові публічні адреси, нові правила firewall і нову конфігурацію hub. Не обов’язково, якщо розділити cloud за допомогою tunnel key. GRE несе key у своєму заголовку, тож hub може термінувати два multipoint тунелі на тому самому фізичному інтерфейсі й тій самій публічній адресі й усе одно їх розрізняти.

На hub другий cloud є копією першого з власною підмережею тунелю, network ID NHRP і key:

interface Tunnel1
 ip address 10.10.1.1 255.255.255.0
 ip nhrp network-id 1
 ip nhrp authentication <secret>
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 1
 tunnel protection ipsec profile DMVPN-PROF shared
!
interface Tunnel2
 ip address 10.10.2.1 255.255.255.0
 ip nhrp network-id 2
 ip nhrp authentication <secret>
 ip nhrp redirect
 tunnel source GigabitEthernet0/0/0
 tunnel mode gre multipoint
 tunnel key 2
 tunnel protection ipsec profile DMVPN-PROF shared

Ключове слово shared у профілі захисту має значення, коли два тунелі ділять джерело: без нього security associations IPsec двох тунелів зіткнуться.

На spoke Tunnel1 походить від першого каналу, а Tunnel2 від другого, кожен вказує на ту саму адресу hub зі своїм key. Для будь-якого іншого spoke нічого не змінюється.

Змусьте маршрутизацію використовувати обидва

Два тунелі дають вам дві сесії BGP до hub, а отже два шляхи до кожного призначення. За замовчуванням BGP усе одно обирає один. Два налаштування це змінюють:

router bgp 65010
 address-family ipv4
  maximum-paths 2
  maximum-paths ibgp 2

Обидві сесії мають потрапляти в ту саму таблицю маршрутизації, щоб шляхи були справді рівними. Потім переконайтеся, що hash пересилання розподіляє потоки, а не цілі пари джерело-призначення. Hash, який враховує порти 4-го рівня, розкладає паралельні потоки між тими самими двома хостами на різні канали, що й потрібно для backup і реплікації:

ip cef load-sharing algorithm include-ports source destination

Доведіть, а не припускайте

show ip route із двома next hop доводить, що multipath налаштовано. Воно не доводить, що трафік використовує обидва канали. Єдиний прийнятний доказ: тест пропускної здатності з кількома паралельними потоками, який досягає в кожному напрямку більше, ніж міг би нести будь-який канал сам, поки ви спостерігаєте, як лічильники на обох фізичних інтерфейсах зростають разом:

iperf3 -c <far-end> -P 8 -t 60
iperf3 -c <far-end> -P 8 -t 60 -R
show interfaces GigabitEthernet0/0/1 | include rate
show interfaces GigabitEthernet0/0/2 | include rate

Якщо всю роботу робить один інтерфейс, дивіться на hash і на те, чи справді встановлені обидва шляхи BGP.

Розраховуйте від crypto engine, а не від ліцензії

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

На нашому backbone ця виміряна цифра становить близько 11 Гбіт/с шифрованого трафіку на hub. Коли клієнту потрібно більше між майданчиками, ми не чекаємо на більшу коробку: ми розподіляємо трафік між кількома hub через equal-cost multipath, що підіймає шифровану ємність до 30 до 40 Гбіт/с. Той самий принцип, що змушує філію використовувати обидва канали, змушує backbone використовувати всі свої hub.

Ми використовуємо віртуальні routers для тихих майданчиків і апаратні routers для завантажених.

Резервні hub, які не заважають

Standby hub має бути тихим, доки не знадобиться. Дайте йому власний BGP AS або свідому вихідну de-preference, щоб spoke віддавали перевагу основному, і використовуйте BFD на тунелях, щоб мертвий основний hub виявлявся за секунди, а не за hold timer BGP. Spoke тоді перемикаються самою лише маршрутизацією. Ніхто не торкається router філії через те, що змінився hub.

Чекліст для вашого власного WAN

• Чи кожен майданчик з двома каналами використовує обидва і чи можете ви показати це тестом пропускної здатності?
• Чи розділені два cloud за tunnel key, із захистом IPsec shared?
• Чи ввімкнено BGP multipath і чи враховує hash пересилання порти?
• Чи працює BFD на кожному тунелі?
• Чи знаєте ви виміряну стелю шифрування на hub, а не ліцензовану?
• Чи вимагала б відмова hub торкнутися бодай одного spoke?

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

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

Related

Пов’язане: Шифрований backbone між майданчиками: DMVPN mesh · Приватне підключення: VPN gateways і виділені лінії · Моніторинг мережі та докази