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

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

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

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

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

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

Фигурата по-долу показва регионите за пиъринг на свързаност в облака на Dedicated Instance.

Маршрутизирането за добавка 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 фаза. Първо, издайте командата „show 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 keepalives от GRE тунелния интерфейс от страната на CPE към GRE тунелния интерфейс от страната на специалния екземпляр.

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

• Изпратете команда „ping“ от IP адреса на тунела от страната на CPE устройството до IP адреса на тунела от страната на специалния екземпляр.

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

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

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

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

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

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

Настройките от страната на CPE не съвпадат с тези от страната на Dedicated Instance, проверете отново настройките:

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

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

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

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

• Проверете IPsec адресите на източника и получателя.

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

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

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

• Функциите за поддържане на връзката (keepalive) не са активирани на интерфейса на тунела от страната на CPE.

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

  Ако се поддържат keepalive функции, проверете дали keepalive функциите са активирани.

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

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

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

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

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

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

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

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

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