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

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

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

Virtual Connect - VPN е дизайн на концентратор, където Сайтовете на центъра на клиента са свързани към DC1 и DC2 на дейтацентровете на Dedicated Instance в рамките на определен регион.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Проверете модулната група на Дифи Хелман.

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

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

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

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

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

При правилно конфигуриране започва тунела на IPsec и първата фаза на IKEv2 преговори:

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

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

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

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

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

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

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

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

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

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

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

• Потвърдете настройките на Perfect Forward Secrecy и дали съвпадат настройките от страна на специализирания екземпляр.

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

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

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

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

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

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

• Не са активирани поддържащи функции в интерфейса на тунела от страната на CPE

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

  Ако се поддържат опашки, проверете дали опашките са разрешени.

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

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

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

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

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

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

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

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

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