- Начало
- /
- Статия
Благодарим за обратната връзка.
Специална инстанция-виртуална връзка
В тази статия
Обратна връзка?Virtual Connect е допълнителна опция за добавка за облачна свързаност към Webex Calling специален екземпляр. Virtual Connect позволява на клиентите сигурно да разширят своята частна мрежа през интернет, като използват IP VPN тунели от точка до точка. Тук обсъждаме поръчката, активирането и конфигурирането за Virtual Connect.
Въведение
Virtual Connect е допълнителна опция за добавка за облачна свързаност към специален екземпляр за Webex Calling (специален екземпляр). Virtual Connect позволява на клиентите сигурно да разширят своята частна мрежа през интернет, използвайки IP VPN тунели от точка до точка. Тази опция за свързване осигурява бързо установяване на връзка с частна мрежа чрез използване на съществуващото оборудване за клиентски помещения (CPE) и интернет свързаност.
Cisco хоства, управлява и осигурява излишни IP VPN тунели и необходимия достъп до интернет в региона (ите) на центъра за данни на Cisco, където се изисква услугата. По същия начин Администраторът отговаря за съответните им CPE и интернет услуги, които са необходими за създаването на Virtual Connect.
Всеки ред на Virtual Connect в определен регион на специален инстанция ще включва два общи тунела за капсулиране на маршрутизиране (GRE), защитени от IPsec криптиране (GRE през IPsec), по един към всеки център за данни на Cisco в избрания регион.
Virtual Connect има ограничение на честотната лента от 250 Mbps на тунел и се препоръчва за по-малки внедрявания. Тъй като се използват два VPN тунела от точка до точка, целият трафик към облака трябва да премине през CPE на клиента и следователно може да не е подходящ там, където има много отдалечени сайтове. За други алтернативни опции за пиъринг вижте Свър заност в облака.
Преди да изпратите заявката за пиъринг за Virtual Connect, уверете се, че услугата Специален екземпляр е активирана в съответния регион.
Предпоставки
Предпоставките за създаване на Virtual Connect включват:
-
Клиентът предоставя
-
Интернет връзка с достатъчно налична честотна лента, за да поддържа внедряването
-
Публичен IP адрес (и) за два IPsec тунела
-
GRE транспортни IP адреси от страна на клиента за двата GRE тунела
-
-
Партньор и клиент
-
Работете заедно, за да оцените изискванията за честотна лента
-
Уверете се, че мрежовите устройства поддържат маршрутизиране на Border Gateway Protocol (BGP) и дизайн на тунел GRE през IPsec
-
-
Партньорът или Клиентът предоставя
-
Мрежов екип с познания за технологиите за VPN тунели от сайт до сайт
-
Мрежов екип с познания по BGP, eBGP и общите принципи на маршрутизиране
-
-
Cisco
-
Cisco присвоява частни автономни системни номера (ASN) и преходно IP адресиране за GRE тунелни интерфейси
-
Cisco присвоява публична, но не маршрутизируема интернет мрежа от клас C (/24) за адресиране в облак със специален екземпляр
-
Ако клиентът има само 1 CPE устройство, тогава двата тунела към центровете за данни на Cisco (DC1 и DC2) във всеки регион ще бъдат от това CPE устройство. Клиентът също има опция за 2 CPE устройства, след което всяко CPE устройство трябва да се свързва с 1 тунел само към центровете за данни на Cisco (DC1 и DC2) във всеки регион. Допълнително съкращаване може да бъде постигнато чрез прекратяване на всеки тунел в отделен физически обект/място в рамките на инфраструктурата на Клиента.
Технически детайли
Модел на внедряване
Virtual Connect използва двустепенна хеденд архитектура, където равнините за управление на маршрутизацията и GRE се осигуряват от едно устройство, а контролната равнина IPsec се осигурява от друго.
След завършване на свързаността на Virtual Connect ще бъдат създадени два GRE през IPsec тунела между корпоративната мрежа на Клиента и центровете за данни на Cisco със специал изираната инстанция. По един към всеки излишен център за данни в съответния регион. Допълнителните мрежови елементи, необходими за пиъринга, се обменят от П артньора или Клиента на Cisco чрез формуляра за активиране на Control Hub Virtual Connect.
Фигурата по-долу показва примера на модела за внедряване на виртуално свързване за опцията с 2 концентратор от страна на клиента.
Virtual Connect - VPN е дизайн на хъб, при който сайтовете на Хъб на Клиента са свързани към DC1 и DC2 на центровете за данни на специализираната инстанция в определен регион.
Два сайта на Hub се препоръчват за по-добро съкращаване, но One Hub сайт с два тунела също е поддържан модел за внедряване.
Честотната лента на тунел е ограничена до 250 Mbps. За да се осигури ефективно превключване, комбинираният трафик през двата тунела не трябва да надвишава 250 Mbps, тъй като целият трафик ще бъде насочен през един тунел в случай на повреда.
Отдалечените сайтове на Клиента в рамките на същия регион ще трябва да се свържат обратно към сайта (ите) на Хъб чрез WAN на Клиента и не е отговорност на Cisco за тази свързаност.
Очаква се партньорите да работят в тясно сътрудничество с Клиентите, като гарантират, че е избран най-оптималният път за региона на услугите на Virtual Connect.
Фигурата по-долу показва партньорските региони за свързаност в облака със специален инстанция.
Маршрутизиране
Добавката за маршрутизиране на 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, който загуби свързаност.
Виртуално свързване на трафика
Поток на трафик, когато двата тунела са нагоре
Това изображение илюстрира мрежова архитектура на Virtual Connect, описваща подробно потока на трафика, когато функционират както първичните, така и вторичните тунели.
Той представлява модел на активна свързаност за клиента за достъп до UC приложения, хоствани в центровете за данни на Cisco, като използва двойни GRE/IPSEC тунели през интернет с BGP за обмен на маршрути.
Определения:
- Клиентско помещ ение:
- Това представлява мрежата на клиента на място, където се намират потребителите и техните устройства (например IP телефони, компютри, работещи с UC клиенти).
- Трафикът, произхождащ от тук, трябва да достигне до UC приложенията, хоствани в центровете за данни на Cisco.
- Cisco Webex CallingЦентрове за данни със специален екземпляр (специален екземпляр) (WXC-Di
DC-A и WXC-Di D C-B):
- Това са центровете за данни на Cisco, хостващи UC приложенията.
- DC-A и DC-B са географски различни, осигурявайки излишък.
- Всеки център за данни има собствена подмрежа за UC приложения:
- DC-A подмрежа: X.X.x.0/25
- DC-B подмрежа: X.X.X.128/25
- GRE/IPsec тунели (тунел 1 и тунел 2):
- Това са защитените, криптирани връзки между помещението на клиента и центъра за данни на Cisco през обществения интернет.
- GRE (Generic Routing Encapsulation): Този протокол се използва за капсулиране на различни протоколи на мрежови слоеве във виртуални връзки от точка до точка. Той позволява маршрутизиращи протоколи като BGP да работят над тунела.
- IPsec (Internet Protocol Security): Този набор от протоколи предоставя криптографски услуги за сигурност (удостоверяване, цялост, поверителност) за IP комуникации. Той криптира GRE капсулирания трафик, осигурявайки сигурно предаване на данни през интернет.
- Прото@@ кол за граничен шлюз (BGP):
- BGP е маршрутизаторният протокол, използван за обмен на информация за маршрутизиране между помещението на клиента и центровете за данни на Cisco.
Както е показано на горната диаграма, устройствата, разположени в помещенията на клиентите, трябва да създадат два GRE/IPSEC тунела.
Конвенциите за именуване, използвани по-долу с XX/ YY, DC-A DC-B, са общи за всички региони, където се предлага специална инстанция. Тези стойности ще бъдат уникални за всеки регион и действителните стойности за всеки регион. Специфичните стойности се предоставят по време на активирането на виртуалното свързване.
От страна на Cisco тунелите IPsec и GRE ще бъдат прекратени на различни устройства. Така че клиентът трябва да се увери, че е конфигурирал съответно IPsec дестинацията и GRE дестинационните IP адреси на устройствата. Клиентите могат да използват същия IP за GRE и IPSEC, ако той се поддържа на техните устройства. Вижте диаграмата по-горе. Стойностите, свързани с IP, се предоставят по време на активирането на виртуалното свързване на портала.
- Тунел 1: Свързва помещението на клиента с „Специален екземпляр DC-A“ (център за данни A) чрез интернет. Този тунел използва BGP AS:64XX1 от страна на клиента и BGP AS:64XX2 от страната на специализираната инстанция DC- A. Конфигурациите на източника на тунели IPSEC и GRE са разделени между предоставени от клиента и предоставени от Cisco подробности.
- Тунел 2: Свързва помещението на клиента с „Специален екземпляр DC-B“ (Център за данни B) чрез интернет. Този тунел използва BGP AS:64YY1 от страна на клиента и BGP AS:64YY2 от страната на специалния екземпляр DC-B . Подобно на тунел 1, конфигурациите на източника на тунели IPSEC и GRE се споделят между клиента и Cisco.
В BGP AS: 64XX и BGP AS:64YY, XX и YY са специфични за определен регион.
След като тунелите GRE/IPSEC бъдат създадени за центрове за данни със Webex Calling специална инстанция (A и B), клиентът трябва да получи следните маршрути, рекламирани от Cisco през съответните BGP сесии.
- За DC-A: Маршрутите, рекламирани от Cisco, ще бъдат X.X.X.0/25 и X.X.x.0/24. По желание, ако IaaS е поискан и конфигуриран за клиентските маршрути, Y.Y.0/25 и Y.Y.0/24 ще бъдат рекламирани от Cisco.
- За DC-B: Маршрутите, рекламирани от Cisco, ще бъдат X.X.X.128/25 и X.X.x.0/24. По желание, ако IaaS е поискан и конфигуриран за клиентските маршрути, Y.Y.128/25 и Y.Y.0/24 ще бъдат рекламирани от Cisco.
- Клиентът трябва да рекламира маршрута 0.0.0./0 до Cisco през двете връзки (тунели)
- Клиентът трябва да следва най-дългите префиксни маршрути (/25), за да изпрати трафик до Cisco през съответните тунели, когато двата тунела са изправени.
- Cisco ще върне трафика през същите тунели, за да поддържа трафика симетричен.
Поток на трафика:
- Трафикът, предназначен за „DC-A UC Apps“ (X.X.X.0/25) от помещението на клиента, преминава през тунел 1.
- Трафикът, предназначен за „DC-B UC Apps“ (X.X.X.128/25) от помещението на клиента, преминава през тунел 2.
Сценарий за неуспех: поток на трафика, когато един от тунелите е спуснат
Както е показано на горната диаграма, когато тунелът към DC-A е надолу, bgp, установен през тунела до DC-A, ще слезе надолу.
Въздействие върху BGP: Когато тунел 1 падне, сесията на BGP над този тунел също ще слезе . Следователно DC-A вече няма да може да рекламира своите маршрути (по-специално X.X.X.0/25) на клиента по този път. Следователно маршрутизаторът на клиента ще открие пътя като недостижим.
Сега, тъй като Tunnel 1 не работи, клиентският маршрутизатор в помещението на клиента автоматично ще премахне маршрутите, научени чрез Tunnel 1, от своята таблица за маршрутизиране или ще ги маркира като недостъпни.
- След това трафикът, предназначен за мрежата за приложения на UC (X.X.X.0/24) или подмрежата DC-A (X.X.X.0/25), ще бъде пренасочен през работния тунел към DC-B, който продължава да рекламира X.X.X.0/24, който включва мрежата X.X.X.0/25.
- Подобно поведение ще се наблюдава, ако тунелът към DC-B е надолу, докато тунелът към DC-A все още е нагоре.
Процес на свързване
| 1 | |
| 2 | |
| 3 | |
| 4 |
Стъпка 1: Поръчка на CCW
Virtual Connect е добавка за специален екземпляр в CCW.
| 1 |
Отидете до сайта за поръчка на CCW и след това щракнете върху Вход, за да влезете в сайта: |
| 2 |
Създайте оценка. |
| 3 |
Добавете код „A-FLEX-3". |
| 4 |
Изберете Опции за редактиране. |
| 5 |
В раздела за абонамент, който се показва, изберете Опции и добавки. |
| 6 |
Под Допълнителни добавки поставете отметка в квадратчето до „Виртуална връзка за специален екземпляр“. Името на SKU е „A-FLEX-DI-VC“. |
| 7 |
Въведете количеството и броя региони, в които се изисква виртуална връзка. Количеството Virtual Connect не трябва да надвишава общия брой региони, закупени за специален екземпляр. Също така е разрешена само една поръчка за Virtual Connect за регион. |
| 8 |
Когато сте доволни от избора си, щракнете върху Проверка и Запазване в горната дясна част на страницата. |
| 9 |
Щракнете върху Запазване и Продължи, за да финализирате поръчката си. Вашата финализирана поръчка вече се появява в мрежата за поръчки. |
Стъпка 2: Активиране на виртуална връзка в контролния център
| 1 |
Влезте в контролния център https://admin.webex.com/login. |
| 2 |
В секцията У слуги отидете на Обаждания > Специални Instacnce > Облачна свързаност. |
| 3 |
В картата Virtual Connect е посочено закупеното количество Virtual Connect. Администраторът вече може да щракне върху А кти виране, за да инициира активирането на Virtual Connect. 
Процесът на активиране може да бъде задействан само от администратори с ролята „Пълен администратор на клиента“. Докато администратор с Роля „Администратор само за четене на клиента“ може да преглежда само състоянието. |
| 4 |
Когато щракнете върху бутона А кти виране, се показва формуляр Активиране на виртуалното свърз ване, за да може администраторът да предостави техническите подробности за виртуалното свързване, необходими за конфигурациите на пиъринг от страна на Cisco. Формулярът също така предоставя статична информация от страна на Cisco, въз основа на избрания регион. Тази информация ще бъде полезна за администраторите на Клиента, за да конфигурират CPE от тяхна страна, за да установят свързаността. |
| 5 |
Щракнете върху бутона Акти виране, след като всички задължителни полета бъдат попълнени. |
| 6 |
След като формулярът за активиране на виртуална връзка бъде попълнен за отделен регион, клиентът може да експортира формуляра за активиране от Control Hub, Обаждане > Специален екземпляр > Раздел Свързаност в облака и да щракне върху Експортиране на настройки. 
Поради съображения за сигурност Удостоверяването и паролата за BGP няма да бъдат налични в експортирания документ, но администраторът може да ги прегледа в Control Hub, като щракне върху Настрой ки за преглед в Контролен център, Обаждане > Специален екземпляр > Раздел Свързаност в облака. |
Стъпка 3: Cisco извършва мрежова конфигурация
| 1 |
След като формулярът за активиране на виртуална връзка бъде попълнен, състоянието ще бъде актуализирано до Активизи ране в процес на повик ване > Специален екземпляр > Карта за виртуално свързване с облака. |
| 2 |
Cisco ще завърши необходимите конфигурации на страничното оборудване на Cisco в рамките на 5 работни дни. При успешно завършване състоянието ще бъде актуализирано до „Активирано“ за този конкретен регион в Control Hub. |
Стъпка 4: Клиентът извършва мрежова конфигурация
|
Състоянието се променя на „Активирано“, за да уведоми администратора на Клиента, че страната на конфигурациите на Cisco за IP VPN свързаността е завършена въз основа на входовете, предоставени от Клиента. Но се очаква администраторът на клиента да завърши своята страна на конфигурациите на CPE и да тества маршрутите за свързване, за да може тунелът Virtual Connect да бъде онлайн. В случай на проблеми, с които се сблъскват по време на конфигурирането или свързаността, клиентът може да се обърне Cisco TAC за помощ. |
Отстраняване на проблеми
IPsec Първа фаза (договаряне на IKEv2) Отстраняване на неизправности и валидиране
Преговорите за тунела IPsec включват две фази, фазата IKEv2 и фазата IPsec. Ако преговорите по фазата на IKEv2 не завършат, тогава няма започване на втора фаза на IPsec. Първо, издадете командата „show crypto ikev2 sa“ (на оборудване на Cisco) или подобна команда на оборудването на трета страна, за да проверите дали сесията IKEv2 е активна. Ако сесията на IKEv2 не е активна, потенциалните причини могат да бъдат:
-
Интересният трафик не задейства тунела IPsec.
-
Списъкът за достъп до тунели IPsec е погрешно конфигуриран.
-
Няма свързаност между клиента и IP крайната точка на тунела IPsec на специален екземпляр.
-
Параметрите на сесията на IKEv2 не съвпадат между страната на специален екземпляр и страната на клиента.
-
Защитна стена блокира UDP пакетите IKEv2.
Първо проверете регистрационните файлове на IPsec за съобщения, които показват напредъка на преговорите за тунела IKEv2. Дневниците могат да показват къде има проблем с преговорите с IKEv2. Липсата на съобщения за регистриране може също да показва, че сесията на IKEv2 не се активира.
Някои често срещани грешки при преговорите с IKEv2 са:
-
Настройките за IKEv2 от страна на CPE не съвпадат със страната на Cisco, проверете отново споменатите настройки:
-
Проверете дали версията на IKE е версия 2.
-
Проверете дали параметрите за криптиране и удостоверяване съответстват на очакваното криптиране от страната на специалния екземпляр.
Когато се използва шифърът „GCM“, протоколът GCM обработва удостоверяването и задава параметъра за удостоверяване на NULL.
-
Проверете настройката за продължителност на живота.
-
Проверете групата на модулите на Diffie Hellman.
-
Проверете настройките на псевдослучайната функция.
-
-
Списъкът за достъп за крипто картата не е зададен на:
-
Разрешение GRE (местен_тунел_транспорт_ip) 255.255.255.255 (отдалечен_тунел_транспорт_ip) 255.255.255" (или еквивалентна команда)
Списъкът за достъп трябва да е специално за протокола „GRE“ и протоколът „IP“ няма да работи.
-
Ако регистрационните съобщения не показват никаква дейност по договаряне за фазата на IKEv2, тогава може да е необходимо заснемане на пакети.
Страната на специалната екземпляра не винаги може да започне обмена на IKEv2 и понякога може да очаква клиентската CPE страна да бъде инициатор.
Проверете страничната конфигурация на CPE за следните предпоставки за иницииране на сесия на IKEv2:
-
Проверете за IPsec списък за крипто достъп за GRE трафик (протокол 50) от IP за транспортиране на тунела CPE до IP за транспортиране на тунела със специален инстанция.
-
Уверете се, че интерфейсът на GRE тунела е активиран за GRE Keepalives, ако оборудването не поддържа GRE Keepalives, Cisco ще бъде уведомен, защото GRE Keepalives ще бъдат активирани от страната на специален екземпляр по подразбиране.
-
Уверете се, че BGP е активиран и конфигуриран със съседния адрес на IP тунела за специален инстанция.
Когато се конфигурира правилно, следното започва тунела IPsec и първата фаза на преговорите за IKEv2:
-
GRE пази от страничния GRE тунел интерфейс на CPE до интерфейса на GRE тунел на страничния GRE за специален инстанция.
-
BGP съседната TCP сесия от страна на CPE BGP съседа до BGP съседа на страната на специализираната инстанция.
-
Пинг от IP адреса на страничния тунел CPE към IP адреса на страничния тунел на специален екземпляр.
Ping не може да бъде IP на тунелния транспорт до IP на тунелния транспорт, той трябва да бъде IP на тунела до тунелния IP.
Ако е необходимо проследяване на пакети за трафика на IKEv2, задайте филтъра за UDP и порт 500 (когато няма NAT устройство в средата на IPsec крайните точки) или порт 4500 (когато NAT устройство е поставено в средата на IPsec крайните точки).
Проверете дали UDP пакетите IKEv2 с порт 500 или 4500 се изпращат и получават от и от DI IPsec IP адреса.
Центърът за данни със специален екземпляр може да не винаги стартира първия пакет IKEv2. Изискването е CPE устройството да може да инициира първия пакет IKEv2 към страната на специалния екземпляр.
Ако локалната защитна стена го позволява, опитайте и пинг към отдалечения IPsec адрес. Ако пингът не е успешен от локален към отдалечен IPsec адрес, тогава изпълнете маршрут за проследяване, за да помогнете, и определете къде е изпуснат пакетът.
Някои защитни стени и интернет оборудване може да не позволяват проследяване на маршрута.
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 не съвпадат със страната на специален екземпляр, проверете отново настройките:
-
Проверете дали параметрите за криптиране и удостоверяване съответстват на настройките на страната на специален екземпляр.
-
Проверете настройките за Perfect Forward Secret и дали настройките съвпадат от страната на специален екземпляр.
-
Проверете настройките за живот.
-
Проверете дали IPsec е конфигуриран в режим на тунела.
-
Проверете източника и местоназначението на IPsec адресите.
Отстраняване и валидиране на интерфейса на тунела
Когато сесиите IPsec и IKEv2 са проверени като нагоре и активни, GRE тунелните пакети могат да протичат между крайните точки на тунела на специалния екземпляр и CPE. Ако интерфейсът на тунела не показва състоянието, някои често срещани проблеми са:
-
Транспортният VRF на тунелния интерфейс не съвпада с VRF на интерфейса за обратна връзка (ако конфигурацията на VRF се използва на интерфейса на тунела).
Ако конфигурацията на VRF не се използва в интерфейса на тунела, тази проверка може да бъде игнорирана.
-
Keepalives не са активирани на интерфейса на страничния тунел CPE
Ако паметните файлове не се поддържат от CPE оборудването, тогава Cisco трябва да бъде уведомен, така че папаливите по подразбиране от страната на специалния екземпляр също са деактивирани.
Ако се поддържат Keepalives, проверете дали паметниците са активирани.
-
Маската или IP адресът на интерфейса на тунела не са правилни и не съответстват на очакваните стойности на специален екземпляр.
-
Адресът за транспортиране на тунел източник или местоназначение не е правилен и не съответства на очакваните стойности за специален екземпляр.
-
Защитна стена блокира GRE пакети, изпратени в тунела IPsec или получени от тунела IPsec (тунелът GRE се транспортира през тунела IPsec)
Пинг тестът трябва да провери дали локалният тунелен интерфейс е включен и свързаността е добра с интерфейса на отдалечения тунел. Извършете проверката на пинг от IP на тунела (не транспортния IP) до IP на отдалечения тунел.
Списъкът с крипто достъп за тунела IPsec, който пренася трафика на тунела GRE, позволява само GRE пакети да преминават. В резултат на това пинговете няма да работят от IP за транспортиране на тунели до IP за отдалечен транспорт на тунели.
Проверката на пинг води до GRE пакет, който се генерира от IP за транспортиране на тунел източник до IP за транспортиране на тунел на дестинацията, докато полезният товар на GRE пакета (вътрешният IP) ще бъде IP на източника и местоназначението на тунела.
Ако тестът за ping не е успешен и предходните елементи са проверени, тогава може да се наложи улавяне на пакети, за да се гарантира, че icmp ping води до GRE пакет, който след това се капсулира в IPsec пакет и след това се изпраща от източника IPsec адрес до местоназначения IPsec адрес. Броячите на интерфейса на тунела GRE и броячите на сесиите IPsec също могат да помогнат за показване. ако пакетите за изпращане и получаване се увеличават.
В допълнение към трафика на пинг, заснемането трябва да показва и Keepalive GRE пакети дори по време на трафик на празен ход. И накрая, ако BGP е конфигуриран, пакетите BGP keepalive също трябва да бъдат изпращани като GRE пакети, капсулирани в IPSEC пакети, както и през VPN.
BGP Отстраняване на неизправности и проверка
BGP сесии
BGP се изисква като маршрутизиращ протокол през тунела VPN IPsec. Местният BGP съсед трябва да установи eBGP сесия със съседа BGP на специализираната инстанция. Съседните IP адреси на eBGP са същите като локалните и отдалечените IP адреси на тунела. Първо се уверете, че BGP сесията е завършена и след това проверете дали правилните маршрути се получават от специален екземпляр и правилният маршрут по подразбиране е изпратен до специален екземпляр.
Ако тунелът GRE е нагоре, проверете дали пингът е успешен между локалния и отдалечения IP на GRE тунела. Ако пингът е успешен, но BGP сесията не се появява, тогава проучете BGP дневника за грешки при установяване на BGP.
Някои от най-често срещаните проблеми с преговорите за BGP са:
-
Отдалеченият AS номер не съвпада с AS номера, който е конфигуриран от страната на специален екземпляр, проверете отново съседната AS конфигурация.
-
Локалният AS номер не съвпада с това, което очаква страната на Dedictaed Instance, проверете дали локалният AS номер съответства на очакваните параметри на специален екземпляр.
-
Защитна стена блокира BGP TCP пакети, капсулирани в GRE пакети, да бъдат изпращани в тунела IPsec или получаване от тунела IPSEC
-
Отдалеченият BGP съседен IP не съвпада с IP отдалечения GRE тунел.
Обмен на маршрути на BGP
След като BGP сесията бъде проверена и за двата тунела, уверете се, че правилните маршрути се изпращат и получават от страната на специализираната инстанция.
Решението за VPN на специализираната инстанция очаква да бъдат създадени два тунела от страна на клиент/партньора. Първият тунел сочи към центъра за данни за специален инстанция A, а вторият тунел сочи към центъра за данни със специален инстанция B. И двата тунела трябва да са в активно състояние и решението изисква активно/активно разполагане. Всеки център за данни със специален екземпляр ще рекламира своя локален маршрут /25, както и маршрут за архивиране /24. Когато проверявате входящите маршрути на BGP от специален екземпляр, уверете се, че BGP сесията, свързана с тунела, сочещ към Център за данни за специален екземпляр A, получава локалния маршрут на Центъра за данни за специален инстанция А/25, както и маршрута за архивиране /24. Освен това се уверете, че тунелът, сочещ към Център за данни за специален екземпляр B, получава локалния маршрут на Центъра за данни за специален инстанция B/25, както и маршрута за архивиране /24. Обърнете внимание, че маршрутът за архивиране /24 ще бъде същият маршрут, рекламиран от Центъра за данни за специален екземпляр A и Център за данни за специален екземпляр B.
Съкращаването се предоставя на център за данни със специален екземпляр, ако интерфейсът на тунела към този център за данни се прекъсне. Ако свързаността със специален инстанционен център за данни A е загубена, трафикът ще бъде препратен от Център за данни за специален екземпляр B към център за данни A. В този сценарий тунелът към центъра за данни B ще използва маршрута на центъра за данни B/25 за изпращане на трафик към център за данни B, а тунелът към център за данни B ще използва маршрута за архивиране /24 за изпращане на трафик до центъра за данни А чрез център за данни Б.
Важно е, когато и двата тунела са активни, тунелът за център за данни A да не се използва за изпращане на трафик към център за данни B и обратно. При този сценарий, ако трафикът се изпраща до център за данни A с дестинация на център за данни B, център за данни A ще препрати трафика към център за данни B и след това център за данни B ще се опита да изпрати трафик обратно към източника чрез тунела в центъра за данни B. Това ще доведе до неоптимално маршрутизиране и може също да наруши защитните стени, преминаващи през трафика. Ето защо е важно двата тунела да са в активна/активна конфигурация по време на нормална работа.
Маршрутът 0.0.0.0/0 трябва да бъде рекламиран от страна на клиента до страната на Центъра за данни със специална инстанция. По-конкретни маршрути няма да бъдат приети от страната на специализираната инстанция. Уверете се, че маршрутът 0.0.0.0/0 е рекламиран както от тунела „Център за данни за специален инстанция A“, така и от тунела „Център за данни за специален инстанция B“.
Конфигурация на MTU
В страната на специален екземпляр са активирани две функции за динамично регулиране на MTU за големи размери на пакети. Тунелът GRE добавя повече заглавки към IP пакетите, преминаващи през VPN сесията. Тунелът IPsec добавя допълнителните заглавки отгоре на GRE заглавките, което допълнително ще намали най-големия MTU, разрешен над тунела.
Тунелът GRE регулира функцията MSS и пътят на тунела GRE в функцията за откриване на MTU е активирана от страната на специалния екземпляр. Конфигурирайте „ip tcp ajust-mss 1350" или еквивалентна команда, както и „tunnel path\ u0002mtu-Discovery“ или еквивалентна команда от страна на клиента, за да помогнете при динамичното регулиране на MTU на трафика през VPN тунела.
