Virtual Connect използва двустепенна архитектура на главата, където равнините на маршрутизиране и GRE се осигуряват от едно устройство, а IPSec контролната равнина се осигурява от друго.

При завършване на Виртуална връзка свързаност, ще бъдат създадени два тунела GRE през IPSec между корпоративната мрежа на Клиента и центровете за данни на Cisco за специален екземпляр. По един за всеки излишен център за данни в рамките на съответния регион. Допълнителните мрежови елементи, необходими за пиринга, се обменят от Партньорът или Клиентът към Cisco чрез формуляра за активиране на Control Hub Virtual Connect.

Фигура 1 показва пример за модел за разгръщане на Virtual Connect за опцията с 2 концентратора от страна на клиента.

Виртуално свързване – VPN е дизайн на хъб, при който хъб сайтовете на клиента са свързани към DC1 и DC2 на центровете за данни на Специализиран инстанция в рамките на определен регион.

Два сайта на Hub се препоръчват за по-добро дублиране, но един сайт Hub с два тунела също е поддържан модел за разгръщане.

Пропускателната способност на тунел е ограничена до 250 Mbps.

Отдалечените сайтове на Клиента в рамките на същия регион ще трябва да се свържат обратно към сайта(ите) на центъра през WAN на Клиента и Cisco не носи отговорност за тази свързаност.

Очаква се партньорите да работят в тясно сътрудничество с клиентите, като гарантират, че е избран най-оптималният път за региона на обслужване „Virtual Connect“.

Фигура 2 показва пиринговите региони за свързаност в облак за специален екземпляр.

добавка за маршрутизиране за Virtual Connect се реализира с помощта на външен BGP (eBGP) между Специализирано инстанция и оборудването на клиента (CPE). Cisco ще рекламира своята съответна мрежа за всеки излишен DC в рамките на региона на CPE на клиента и CPE трябва да обяви маршрут по подразбиране до Cisco.

• Cisco поддържа и възлага

  • IP адресиране на тунелен интерфейс (преходна връзка за маршрутизиране) Cisco присвоява от определено споделено адресно пространство (непублично маршрутизирано)

  • Адрес на местоназначение за тунелен транспорт (от страната на Cisco)

  • Частни автономни системни номера (ASN) за конфигурация на клиентска BGP маршрутизация

    • Cisco присвоява от определения обхват за частна употреба: 64512 до 65534

• eBGP се използва за обмен на маршрути между Специализиран инстанция и CPE

  • Cisco ще раздели назначената /24 мрежа на 2/25 за всеки DC в съответния регион

  • Във Virtual Connect всяка /25 мрежа се рекламира обратно към CPE от Cisco през съответните VPN тунели от точка до точка (преходна връзка)

  • CPE трябва да бъде конфигуриран със съответните съседи на eBGP. Ако се използва един CPE, ще се използват два съседа на eBGP, като единият сочи към всеки отдалечен тунел. Ако използвате два CPE, тогава всеки CPE ще има един съсед eBGP, насочващ към единичния отдалечен тунел за CPE.

  • Cisco страната на всеки GRE тунел ( IP на тунелен интерфейс) е конфигурирана като BGP съсед на CPE

  • CPE се изисква за рекламиране на маршрут по подразбиране над всеки от тунелите

  • CPE е отговорен за преразпределянето, ако е необходимо, на научените маршрути в рамките на корпоративната мрежа на клиента.

• При условие за отказ на връзката без повреда, един CPE ще има два активни/активни тунела. За два CPE възела, всеки CPE ще има един активен тунел и двата CPE възела трябва да са активни и преминаващи трафик. При сценарий без повреда трафикът трябва да се раздели на два тунела, които отиват до правилните /25 дестинации, ако един от тунелите падне, оставащият тунел може да пренесе трафика и за двата. При такъв сценарий на неуспех, когато мрежата /25 не работи, тогава мрежата /24 се използва като резервен маршрут. Cisco ще изпраща клиентски трафик през своя вътрешен WAN към DC, който загуби връзка.

Договарянето на IPsec тунел включва две фази, фаза IKEv2 и фаза IPsec. Ако договарянето на фазата на IKEv2 не завърши, тогава няма иницииране на втора фаза на IPsec. Първо, издайте командата "show crypto ikev2 sa" (на оборудване на Cisco ) или подобна команда на оборудването на трета страна, за да проверите дали сесията IKEv2 е активна. Ако сесията IKEv2 не е активна, потенциалните причини могат да бъдат:

• Интересният трафик не задейства IPsec тунела.

• Списъкът за списък за достъп до тунел IPsec е неправилно конфигуриран.

• Няма свързаност между клиента и IPsec на крайната точка на тунела на специален IP.

• Параметрите на сесията на IKEv2 не съвпадат между страната на Специализирания модел и страната на клиента.

• Защитна стена блокира IKEv2 UDP пакетите.

Първо проверете регистрационните файлове на IPsec за съобщения, които показват напредъка на договарянето на IKEv2 тунел. Регистрите могат да показват къде има проблем с договарянето на IKEv2. Липсата на съобщения за регистриране може също да означава, че IKEv2 сесията не се активира.

Някои често срещани грешки при договарянето на IKEv2 са:

• Настройките за IKEv2 от страната на CPE не съвпадат със страната на Cisco , проверете отново споменатите настройки:

  • Проверете дали версията на IKE е версия 2.

  • Проверете дали параметрите за шифроване и удостоверяване съвпадат с очакваното криптиране от страна на Специализирания екземпляр.

    Когато се използва шифърът "GCM", протоколът GCM обработва удостоверяването и задава параметъра за удостоверяване на NULL.

  • Проверете настройката за продължителност на живота.

  • Проверете модулната група на Diffie Hellman.

  • Проверете настройките на псевдослучайната функция.

• списък за достъп за крипто картата не е настроен на:

  • Разрешете GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (или еквивалентна команда)

    Списъкът за списък за достъп трябва да е специално за протокола "GRE" и протоколът "IP" няма да работи.

Ако регистрационните съобщения не показват никаква активност на договаряне за фазата IKEv2, тогава може да е необходимо прихващане на пакети .

Страната на специализирания модел може не винаги да започне IKEv2 обмен и понякога може да очаква CPE страната на клиента да бъде инициатор. Проверете конфигурацията от страна на CPE за следните предпоставки за иницииране на IKEv2 сесия: Проверете за списък за достъп за GRE трафик (протокол 50) от транспортния IP тунел на CPE до транспортния IP на тунел за специален инстанция. Уверете се, че интерфейсът на тунела GRE е активиран за поддържане на GRE, ако оборудването не поддържа поддържане на GRE, тогава Cisco получава известие, тъй като GRE поддържането на активността ще бъде активирано от страната на Специалния екземпляр по подразбиране. Уверете се, че BGP е активиран и конфигуриран със съседния адрес на тунелния IP адрес на специален екземпляр.

Когато е конфигурирано правилно, следното започва IPsec тунела и договарянето на IKEv2 от първата фаза:

• GRE поддържа активност от GRE тунелния интерфейс от страната на CPE към интерфейса на GRE тунела от страна на специална инстанция.

• BGP съсед TCP сесия от страна на CPE BGP съсед към BGP съсед от страна на Специализиран екземпляр.

• Изпратете пинг от IP адреса на тунелния страничен CPE към IP адрес IP адрес на тунелния страничен екземпляр.

  Ping не може да бъде IP от тунелен транспорт към тунелен IP, той трябва да бъде IP от тунел.

Ако е необходимо проследяване на пакети за трафика IKEv2, задайте филтъра за UDP и порт 500 (когато няма NAT устройство в средата на крайните точки на IPsec) или порт 4500 (когато NAT устройство е вмъкнато в средата на IPsec крайни точки).

Проверете дали IKEv2 UDP пакети с порт 500 или 4500 се изпращат и получават до и от DI IPsec IP адрес.

Центърът за данни със специален екземпляр не винаги може да започне първия IKEv2 пакет. Изискването е CPE устройството да може да инициира първия IKEv2 пакет към страната на Специализирания екземпляр. Ако локалната защитна стена го позволява, опитайте и пинг до отдалечения IPsec адрес. Ако пингът не е успешен от локален към отдалечен IPsec адрес, извършете маршрут за проследяване, за да помогнете и определете къде е изпуснат пакетът. Някои защитни стени и интернет оборудване може да не позволяват проследяване на маршрут.

Проверете дали първата фаза на IPsec (тоест асоциацията за сигурност IKEv2) е активна, преди да отстраните неизправности във втората фаза на IPsec. Изпълнете „show crypto ikev2 sa“ или еквивалентна команда, за да проверите сесията на IKEv2. В изхода проверете дали сесията IKEv2 е била активна за повече от няколко секунди и че не отскача. Времето на работа на сесията се показва като "Активно време" на сесията или еквивалентно на изхода.

След като сесията на IKEv2 се потвърди, че е активна, проучете сесията на IPsec. Както при сесията IKEv2, изпълнете „show crypto ipsec sa“ или еквивалентна команда, за да проверите IPsec сесията. И сесията IKEv2, и сесията IPsec трябва да са активни, преди да се установи тунелът GRE. Ако сесията на IPsec не се показва като активна, проверете регистрационните файлове на IPsec за съобщения за грешки или грешки при договаряне.

Някои от по-често срещаните проблеми, които могат да се срещнат по време на преговорите за IPsec, са:

Настройките от страната на CPE не съвпадат със страната за специален екземпляр, проверете отново настройките:

• Уверете се, че параметрите за шифроване и удостоверяване съвпадат с настройките от страната на Специализиран екземпляр.

• Проверете настройките за перфектна препращана секретност и дали настройките за съвпадение от страната на Специализирания екземпляр.

• Проверете настройките за целия живот.

• Проверете дали IPsec е конфигуриран в тунелен режим.

• Проверете IPsec адресите на източника и местоназначението.

Когато сесиите IPsec и IKEv2 са проверени като активирани и активни, пакетите за поддържане на активност на тунела GRE могат да преминават между крайните точки на Специализирания екземпляр и CPE тунела. Ако интерфейсът на тунела не показва състояние, някои често срещани проблеми са:

• Транспортният VRF на тунелния интерфейс не съвпада с VRF на интерфейса за обратна връзка (ако VRF конфигурацията се използва на интерфейса на тунела).

  Ако VRF конфигурацията не се използва на интерфейса на тунела, тази проверка може да бъде игнорирана.

• Keepalives не са разрешени в интерфейса на страничния тунел на CPE

  Ако поддържането на активността не се поддържа от CPE оборудването, тогава Cisco трябва да бъде уведомен, така че поддържащите активности по подразбиране от страна на Специализирания екземпляр също да бъдат деактивирани. Ако поддържането на активността се поддържа, проверете дали поддържането на активността е активирано.

• Маската или IP адрес на интерфейса на тунела не е правилен и не съответства на очакваните стойности за специален екземпляр.

• Транспортният адрес на тунела на източник или местоназначение не е правилен и не съответства на очакваните стойности за специален екземпляр.

• Защитна стена блокира изпращането на GRE пакети в тунела IPsec или получени от тунела IPsec (тунелът GRE се транспортира през тунела IPsec)

Пинг тестът трябва да потвърди, че интерфейсът на локалния тунел е активиран и връзката е добра с интерфейса за отдалечен тунел. Извършете проверката на ping от тунелния IP (не транспортния IP) до отдалечения IP на тунела.

Списъкът за крипто списък за достъп за тунела IPsec, който пренася трафика на GRE тунела, позволява преминаването само на GRE пакети. В резултат на това пинговете няма да работят от тунелен транспортен IP към отдалечен тунелен транспортен IP.

Проверката на ping води до GRE пакет, който се генерира от изходния IP транспортен тунел до IP транспортен тунел на местоназначение, докато полезният товар на GRE пакета (вътрешният IP) ще бъде IP адресът на тунела на източника и дестинацията.

Ако ping тестът не е успешен и предходните елементи са проверени, тогава може да се изисква прихващане на пакети , за да се гарантира, че icmp ping води до GRE пакет, който след това се капсулира в IPsec пакет и след това се изпраща от изходния IPsec адрес до IPsec адреса на местоназначението. Броячите на интерфейса на тунела GRE и броячите на IPsec сесиите също могат да помогнат за показването. ако пакетите за изпращане и получаване се увеличават.

В допълнение към ping трафика, прихващането трябва да показва и поддържащи активност GRE пакети дори по време на неактивен трафик. И накрая, ако BGP е конфигуриран, пакетите за поддържане на активността на BGP също трябва да се изпращат като GRE пакети, капсулирани в IPSEC пакети, както и през VPN.

В страната за специален екземпляр са активирани две функции за динамично регулиране на MTU за големи размери на пакети. GRE тунелът добавя още заглавки към IP пакетите, преминаващи през VPN сесията. Тунелът IPsec добавя допълнителните заглавки върху заглавките GRE, което допълнително ще намали най-големия разрешен MTU през тунела.

Тунелът GRE настройва функцията MSS, а пътят на тунела GRE в функцията за откриване на MTU е активиран от страната на Специализирания екземпляр. Конфигурирайте "ip tcp adjust-mss 1350" или еквивалентна команда, както и "tunnel path\u0002mtu-discovery" или еквивалентна команда от страна на клиента, за да помогнете при динамичното регулиране на MTU на трафика през VPN тунела.