×

Предупреждение

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

DMVPN: migration network from Hub-to-spoke to spoke-to-spoke topology.

Блог

пн, 04/13/2015 - 02:00
апр 7th, 2015
User Badges:
  • Почетные Знаки Сообщества,

    Лучшая публикация, Июнь 2015

Всем привет! И всем успехов в работе по построению замечательных сетей совместно с компанией Cisco!

Собирался долго и решил написать немного об опыте внедрения DMVPN phase 3  (spoke-to-spoke)технологии наших российских реалиях. Решил написать в основном ради того, что если кто будет эту технологию внедрять меньше встретил проблем и предостеречь от бесполезной траты сил и времени.

Кто-то уже это давно сделал и я для Вас ничего нового не скажу. Респект вам   и рад за Вас, но эта статья для тех, кто еще на подступах к этому непростому делу.  Надеюсь, что она поможет в особенности тем, кто собирается мигрировать с DMVPN Phase1 (Hub-to-Spoke) на Spoke-to-Spoke (Phase3) .

Итак, что мы имеем:

Сеть с 60- 70 локациями, разбросанными по нашей широкой стране от Магадана, Хабаровска до Мурманска и Калининграда и пара DMVPN  Hub-центров. Говоря техническим языком: Два Single DMVPN cloud, каждое со своим Single- Hub и Single mGRE tunnel. А на spoke получалось соответственно по 2 туннеля и каждый Spoke участвовал в 2-ух DMVPN cloud-ах.

Мотивация и задача: почему решили переходить на Spoke-to-Spoke модель? 

  1. 20-25% транзитного трафика шло через Hub – дополнительная ненужная  нагрузка на Hub.
  2.  Задержки передачи пакетов сильно увеличивались из-за  имеющейся топологии. Так, например, траффик из г. Белово Кемеровской области в г. Кемерово через Hub (Москва) шел в среднем (RTT) 150мс., конечно это не оптимально.

Итак  мы решили перейти на модель, такую, чтобы spoke между собой могли строить туннели. Что нам рекомендуется Cisco  вначале – prepare- приготовиться, спланировать, разработать дизайн, а потом уже внедрять. Вот я и начал искать документацию по этому вопросу.

Документация:

Сразу скажу, что с документацией, которая нужна для внедрения –  а не общетеоретического познания принципов работы DMVPN  -есть проблемы.  Что я нашел:

  1. Чтобы понять, что такое DMVPN? Как это работает? Чем отличается Phase 3 от Phase 1 – имеются отличные презентации на www.ciscolive365.com. Заходим в «Solution center», набираем «DMVPN phase3»  и получаем список авторов и сессий. Мне друг рекомендовал смотреть Mike Sullenberger, он как бы deepest diving person в этом вопросе. Берем, например DMVPN Deployment Models презентацию и смотрим, а можно и слушать.  Вообще, www.ciscolive365.com  в этом смысле отличный ресурс. Проблема: пример конфига для IPv6 есть, а для IPv4 – нет. Есть какие-то кусочки, отдельные строки про разные фичи, а цельного примера в части DMVPN – для IPv4 – нет.
  2. Google нас выведет еще на несколько полезных ссылок на сайте Cisco:

Итак,  я все просмотрел (конечно по - диагонали – времени –то нет читать все подробно) и кое-какое представление приобрел. Не  все так уж мне понятно было- вроде- все просто – пару команд добавил, одну убрал и наслаждайся новым дизайном. Но с другой стороны я тогда даже четко и не видел различия между Phase 2 и Phase 3.  Но как говорил Наполеон- «Главное ввязаться в бой, а там …»  и я ввязался.

Стартовый дизайн:

Итак,  до начала внедрения мы имели стройную структуру состоящую из Dual DMVPN Single Hub Single tunnel on Hub, two on spokes- точно соответствует правой картинке на слайде 65 DMVPN Deployment Models – презентации. Т.е.DMVPN Phase1 – Hub-to-Spoke topology.  Это нормальный рекомендованный Cisco дизайн и его смело можно внедрять. Обычно больших проблем при этом нет.

Отказоустойчивость - обеспечивалась наличием 2-х  Hub в дата-центрах, 2-х туннелей на Spoke и работой EIGRP.

Балансировка и распределение трафика поддерживались за счет регулировки метрики (delay) для EIGRP и offset-list, если нужно было поменять что-то для отдельной локации.


Конфигурация туннелей была примерно следующей: 

Hub1:
interface Tunnel501
description DMVPN MSK1
ip address 10.50.1.1 255.255.255.0
no ip redirects
ip mtu 1438
no ip split-horizon eigrp 100
ip flow ingress
ip flow egress
ip nhrp authentication Cle
ip nhrp map multicast dynamic
ip nhrp network-id 501
ip tcp adjust-mss 1398
ip summary-address eigrp 100 10.50.0.0 255.255.0.0
load-interval 60
delay 10000
qos pre-classify
tunnel source GigabitEthernet0/1
tunnel mode gre multipoint
tunnel key 501
tunnel protection ipsec profile VPN-3DES
 
router eigrp 100
network 10.50.1.0 0.0.0.255
passive-interface default
no passive-interface Tunnel501
 
2-й Hub c аналогичной конфигурацией Tunnel, только другое имя туннеля, key, subnet
 
 Spoke:
interface Tunnel501
 description TUNNEL TO MSK1
 ip address 10.50.1.58 255.255.255.0
 ip mtu 1438
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle
 ip nhrp map 10.50.1.1 217.x.x.237
 ip nhrp map multicast 217.x.x.237
 ip nhrp network-id 501
 ip nhrp holdtime 15
 ip nhrp nhs 10.50.1.1
 ip tcp adjust-mss 1398
 ip summary-address eigrp 100 10.58.0.0 255.255.0.0 5
 delay 10000
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel destination 217.x.x.237
 tunnel key 501
 tunnel protection ipsec profile VPN-3DES
 
На этом же маршрутизаторе Spoke - аналогичный 2-й tunnel только с соответствующими:  key, subnet, NHS,  destination IP, NHRP map.
 
router eigrp 100
 network 10.50.1.0 0.0.0.255
network 10.10.1.0 0.0.0.255
 network 10.58.0.0 0.0.255.255
 passive-interface default
 no passive-interface Tunnel501
no passive-interface Tunnel502
 eigrp stub summary
 

Step-by-step или «Подводные камни»:

Опишу мои шаги и переходы для лучшего понимания того, к чему стоит быть готовым при внедрении данного решения, какие могут быть ошибки, траблы.

1-й шаг – перевел один из хабов (тот что был backup и трафик через него обычно не ходил) на phase2 и несколько споков вначале, все вроде работает. Перевел все туннели данного хаба на споках в режим tunnel mode gre multipoint вместо  tunnel destination x.x.x.x и на части споках перевел трафик на этот туннель – вроде все работает – туннели между ними строятся, трафик по ним идет.

1-й подводный камень: внезапно начали несколько роутеров, не из тех на которых были активными туннели с режимом gre multipoint. Крашились роутеры так скоро, что после перезагрузки я только успевал на них зайти и начать смотреть -5 сек  ивсе снова падало. Поменял один из них на запасной с таким же IOS и этот почти сразу начал падать как и предыдущий- это был день кошмара. Потом как-то логически у меня связалось это с новым DMVPN туннелем – я отключил его на споке и он перестал крашиться. Нашел баг по этому поводу, который разрешался заменой IOS на более новый или переведением всех туннелей в режим mGRE. Проблема происходила тогда, когда спок с mGRE строил (пытался) туннель к туннелю, у которого только один tunnel destination.  

Решение: Перевел оба Hub и все spokes в режим gre multipoint.

2-й подводный камень. Когда я перевел оба туннеля, в вышеназванный режим, то через некоторое время заметил, что на споках у меня почему-то по одну соседству EIGRP. Или через один или через другой, но по одному. Проблема заключалась в том, что я сделал на разных туннелях (и хабах соответсвенно) разное время ip nhrp holdtime.

Решение: выставил одинаковое время ip nhrp holdtime – везде.

3-й подводный камень вылез где-то здесь тоже когда переводил туннели на новый режим. У меня они оба использовали один и тот же profile для шифрования и никакого shared не требовалось, а тут IOS закапризничал – нет и все, только с shared давай.

Решение: Сделал на второй интерфейс новый profile с тем-же абсолютно методом шифрования, прописал на туннеле с shared на всякий случай –

 tunnel protection ipsec profile VPN-3DES2 shared  - все прошло нормально.

4-подводный камень обнаружился на следующий день.

 Появилась black hole для начала передачи трафика между Spokes. Выглядело это так – кто-то из spoke  звонил в другой spoke не слышал его, перезванивает через пару минут – все слышно нормально. Проблема заключалась в том, что в Phase 2  после открытия туннеля (с помощью NHRP) – EIGRP устанавливает новое соседство и получает через него маршруты стоящие за новым соседом. Пока он все это проворачивает – для трафика получается black hole и он теряется (скорее всего это связано с каким-то багом, т.к. по дизайну DMVPN, пока трафик не переключится на другой туннель, он должен идти по через Hub). Когда все построено- трафик будет идти нормально.

Решение – workaround: подняли ip nhrp holdtime 600 до максимума 65500. Теперь у нас туннели как построились с утра, так и стояли 18 часов. Не красивое, конечно, решение. Но временно работало.

5-й шаг. Тут я стал эксперта из московского Cisco TAC расспрашивать – что-то говорю технология у Cisco не продуманная какая-то, работает с задержками и вообще, если она так работает – лучше обратно откачусь. Я уже стал получать от пользователей заявки на плохую телефонию и т.д. А эксперт мне говорит не должно так быть – это что-то не то. Есть там у тебя на туннелях ip nhrp redirect, ip nhrp shortcut? Я говорю – нет. Так значит у тебя там не Phase3, а Phase2. Читай документацию снова, говорит, смотри презентации – тебе надо Phase3- это более функциональное и производительное решение. Пришлось глубже вникать в документацию и готовиться к следующему рывку.

5-й подводный камень. Тут пока я все это проходил, я помнил, что баг у меня был с crash – вот я и решил обновлять IOS потихоньку на будущее. Но здесь оказалось не один подводный камень, а целые рифы какие-то. Короче, обновляю IOS на  29xx на 154-2.T2 и на 155-1.T – одни из последних и на 9 роутерах все проходит хорошо. Обновляю на 10-м на нем EIGRP neighbors поднимаются на 15 сек и падают, через некоторое время опять поднимаются и снова падают. Cisco phones зарегистрироваться с CUCM не могут – ушли в бесконечный цикл. На 11-м роутере 29xx – интернет трафик приблизился к 4Mbps – роутер по CPU ушел 90%, трафик к 4,5Mbps- CPU -100%. Все висит- кое-как отправил в reload.

Решение: откатился на предыдущий IOS. Будет время поисследую еще и обновлю. Тут мне и коллеги стали говорить – Николай, хорош сеть портить – мы хотим на Новогодних дома посидеть спокойно.

6-й шаг. Перевел оба Hub-а и все туннели на Phase 3, у него NHRP еще больше на себя берет чем в phase2. NHRP здесь и  в таблице маршрутизации прописывает сети на другие споки и в FIB-е проставляет физический интернет адрес – куда туннель строить.  В общем- красивая технология. И главное black hole у него нет- если туннель еще не построился (или по каким-то причинам на другой спок в принципе не строится), то трафик идет через hub. А если туннель уже построился, то через него. И сбоев в этом я пока не видел ни разу- или так или так, но ничего не пропадает. Пользователи про телефоны жаловаться перестали.

6-й подводный камень. Продолжая свое внедрение этой технологии решил я испытать-  как тут у меня отказоустойчивость будет работать, т.е. если один из Hub станет недоступен. Положил я его, а пинги запустил и до сети в Hub и до другого спока. И тут я был разочарован кое в чем. До hub и из Hub все работало красиво- потерялось может -1-2 пакета и все. Проверяю как строятся туннели между споками. Не все так просто. DMVPN облака- то у меня разные и получались разные проблемы связанные с этим обстоятельством. Описывать их сложно и утомительно будет читать. Поэтому подробно это делать не буду. Скажу лишь что появлялась опять black hole между споками, они наблюдались при определенной ситуации – после возврата основного hub в работу. И заканчивались только когда «протухала» crypto сессия между этими споками- она все равно не работала нормально в это время и трафика по ней не шло.

Решение-workaround: вот тут мы воспользовались crypto ipsec security-association idle-time – параметром – занизили его до 60сек. И он честно отрабатывал – удалял сессию и новый туннель строился вполне работоспособным.

7-й шаг. Пришлось снова читать и смотреть презентации про DMVPN – понял, что нигде так не рекомендуется внедрять Phase3 – c двумя не зависимыми облаками и hub, а рекомендуется делать Dual-hub. Так мы и сделали – перевели оба Hub в одно облако (одна подсеть для адресации всех туннелей). На spoke получился только один туннель в конфиге, а Neighboring у EIGRP по 2 – т.е. на каждый hub, т.е. все честно. Отказоустойчивость работает при этом нормально. Туннели между spokes строятся при наличии двух или одного hub одинаково быстро и вполне функциональны. Потери пакетов в сеть за hub могут появляться только на время перестроения EIGRP, но это не связано с работой DMVPN уже никак.

7-й подводный камень, с которым я столкнулся – как управлять трафиком со стороны spoke- на какой хаб ему идти со spoke. Так как теперь, если мы меняем delay на туннеле, то это распространяется на оба туннеля. Более того было интересное наблюдением, что не смотря на то что, она одинаковая для обоих – один все же имел чуть лучшую метрику чем другой. 

Решение: Посмотрел еще один интересный ресурс: от LabMinutes на youtube и воспользовались увеличением administrative distance для определенного hub. Ну и все заработало. Выбирается тот, который нужно туннель для передачи трафика. В результате получилось вот так:


Hub
interface Tunnel501
 description DMVPN MSK8
 ip address 10.50.1.2 255.255.255.0
 no ip redirects
 ip mtu 1438
 ip pim dense-mode
 no ip split-horizon eigrp 100
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle
 ip nhrp map multicast dynamic
 ip nhrp network-id 501
 ip nhrp holdtime 65500
 ip nhrp redirect
 ip tcp adjust-mss 1398
 ip summary-address eigrp 100 10.0.0.0 255.0.0.0
 ip igmp join-group 239.255.255.250
 delay 10000
 qos pre-classify
 tunnel source Loopback3
 tunnel mode gre multipoint
 tunnel key 501
 tunnel protection ipsec profile VPN-3DES
 
Spoke:
interface Tunnel501
 description TUNNEL TO MSK
 ip address 10.50.1.58 255.255.255.0
 no ip redirects
 ip mtu 1438
 ip flow ingress
 ip flow egress
 ip nhrp authentication Cle#11
 ip nhrp map multicast dynamic
 ip nhrp map 10.50.1.2 130.x.z.37
 ip nhrp map multicast 130.x.z.37
 ip nhrp map multicast 217.x.y.237
 ip nhrp map 10.50.1.1 217.x.y.237
 ip nhrp network-id 501
 ip nhrp holdtime 65500
 ip nhrp nhs 10.50.1.1
 ip nhrp nhs 10.50.1.2
 ip nhrp shortcut
 ip nhrp redirect
 ip summary-address eigrp 100 10.58.0.0 255.255.0.0
 ip tcp adjust-mss 1398
 delay 9800
 qos pre-classify
 tunnel source GigabitEthernet0/1
 tunnel mode gre multipoint
 tunnel key 501
 tunnel protection ipsec profile DMVPN-3DES shared
 
Второй (Tunnel 502) теперь не нужен - его удаляем.
 
router eigrp 100
 network 10.50.1.0 0.0.0.255
 network 10.58.0.0 0.0.255.255
 distance 90 10.50.1.1 0.0.0.0
 passive-interface default
 no passive-interface Tunnel501
 eigrp stub summary
 
Результаты:
  1. Сейчас через hub проходит порядка около 5% транзитного трафика.
  2. RTT между близкими spokes уменьшился существенно: траффик из г. Белово Кемеровской области в г. Кемерово через spoke-to-spoke туннель идет в среднем (RTT) 25мс, т.е. на 125 мс. меньше.  Красивый результат, хотя и не везде будет такой, так как у некоторых провайдеров каналы пересекаются физически не близко – тогда это не будет так наглядно

Выводы по поводу внедрения новых технологий Cisco:

  1. Убедись, что это действительно необходимо и даст полезный эффект, а то быстро вернешься назад.
  2. Подробно рассмотри – как предлагает внедрять технологию тот кто ее придумал и внедряй только так, все остальное будет иметь много подводных камней и неожиданных результатов.
  3. Не стоит внедрять что-то новое не имея поддержки вендора, хотя бы для того чтобы скачать новый IOS (без Bugs обнаруженных в процессе внедрения). Потому что Bugs  скорее всего всплывут.
  4. Одна голова – хорошо, а с Cisco TAC – лучше.  Заручись поддержкой Cisco TAC или кого-то из экспертов, скорее всего понадобится обсудить с кем-то промежуточные результаты, с кем–то надо будет рассматривать Bugs и просто хорошо когда кто-то может подсказать тебе, что почитать и где посмотреть.
  5. То, что красиво работает у другого в сети – не факт, что будет так работать у тебя. Все сети и все роутеры – разные в каком-то смысле. Не только по версии IOS, но и по config и по нагрузке, модулям, контенту трафика и тогда.
  6. Хорошо, когда новую технолдогию ты можешь проверить сначала где-то в лаборатории, чтобы понять как это должно работать. Меньше будет подводных камней. Но они все равно могут быть потому что лаборатория и большая сеть – это разные условия.
  7. Заручись поддержкой руководства и коллег, потому что могут быть всякие black hole – и на тебя будут жаловаться твоему начальнику. Лучше, чтобы он был к этому готов.

Всем успехов и удовлетворения от внедрения новых решений! 

Loading.

Действия

Информация о блоге

Related Content