Тунелът RSVP-TE работи, но клиентският L3VPN няма път
Транспортът и услугата са отделни решения. Прочетете стека от етикети, проверете отделно резолюцията на следващия хоп и прикачването на VRF, след което тествайте един реален клиентски поток.
Два екипа могат да са едновременно прави, когато клиентът съобщава, че VPN не работи, а транспортният екип – че тунелът е наред. LSP с инженеринг на трафика и MPLS L3VPN отговарят на различни въпроси: едното пренася маркирани пакети през ядрото, другото решава към кой маршрутизиращ контекст принадлежи пакетът. Когато ги смесят, спорът се върти в кръг, защото всяка страна измерва различен обект и двете измервания са валидни.
Транспортът работи, а услугата не – това е нормално състояние
LSP може да е установен, да пренася трафик и да се вижда във всяка система за мониторинг, докато клиентската услуга остава неизползваема. В тази комбинация няма нищо противоречиво, защото тунелът няма мнение дали отдалечен префикс съществува, дали политика за внос го е приела или дали прикачената верига пропуска кадри.
Симптомът, който обикновено разкрива объркването, е асиметричен: пингването от PE loopback минава, докато хост в клиентската LAN не получава нищо, или обратното. Запишете кои адреси са работили, преди да си съставите теория. Щом забележите, че тествате два различни обекта, следващата стъпка е да прочетете стека от етикети, вместо да спорите чия графика е вярна. Два адреса, двама собственици и обикновено двама различни души, всеки от които вярва, че другият е счупил нещо.
Четете стека като две отговорности
Долният етикет принадлежи на услугата, а горният – на пътя. RFC 4364 описва последователността просто: първо се налага етикетът на VPN маршрута, после този маркиран пакет се тунелира към следващия хоп на BGP, където тунелът с инженеринг на трафика поставя своя етикет отгоре.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
На далечния PE етикетът на услугата избира обработката, която може да е търсене в VRF или решение за прикачване. Този етикет не може да бъде заменен с такъв, който просто пресича ядрото, и двата не са взаимозаменяеми, дори когато и двата се появяват в един и същ стек на един и същ интерфейс.
Какво доказва успехът на RSVP и какво не
RSVP-TE установява LSP с явен маршрут, със или без резервация на ресурси, което е конкретна и полезна гаранция за пътя на пакета през ядрото. Това не е твърдение за клиентските маршрути и конфигурирано име на тунел изобщо не е маршрут.
Наличието на RSVP също не дава обещание за производителност от край до край. Резервацията на честотна лента върху един LSP не казва нищо за прикачената верига, за собствената линия за достъп на клиента или за поведението на опашката в далечния край. Отнасянето към нея като към гаранция дава уверени отговори на въпроси, които никой не е задавал. Ако изискването наистина е ангажимент за честотна лента, той трябва да се сглоби от частите, които реално го налагат, а LSP е само средата на тази верига.
Проверявайте по ред, после спрете
Работете от транспорта навън и спрете на първата стъпка, която се провали, защото всяка следваща стъпка предполага, че предишните са издържали. Първо потвърдете, че LSP е установен и че записът за препращане на префикса на услугата наистина сочи към него. След това потвърдете, че VPN маршрутът съществува в правилната таблица, че обвързването на етикета му е налично и че политиката за внос го е приела. След това потвърдете прикачването: интерфейса, инкапсулацията и, където е приложимо, идентификатора на VLAN, който принадлежи на този договор.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMERСинтаксисът на командите зависи от платформата, така че третирайте тези четири реда като четирите въпроса, а не като скрипт. Важното е, че всеки от тях разпитва различен обект и именно това кара даден провал да сочи към конкретен собственик.
Проследете една разрешена заявка и запазете добрите доказателства
Завършете с една реална клиентска заявка, разрешена от политиката, и отговора към нея. Един работещ поток от край до край решава повече от страница с показания на броячи и упражнява комбинацията, а не всяка част поотделно.
Когато по-късен етап се провали, запазете успешното наблюдение на LSP, вместо да престроявате транспорта. Прекрояването на работещ тунел не може да поправи липсващ отдалечен префикс, грешно прикачване на VRF или правило за достъп до дестинация и унищожава доказателствата, които първоначално са ви казали, че транспортът е здрав.