Тунел RSVP-TE ради, али клијентски L3VPN нема путању

Два тима могу истовремено бити у праву када клијент пријави да је VPN пао, а транспортни тим пријави да је тунел у реду. LSP са инжењерингом саобраћаја и MPLS L3VPN одговарају на различита питања: један преноси означене пакете кроз језгро, други одлучује којем контексту рутирања пакет припада. Када се помешају, расправа се врти у круг, јер свака страна мери различит објекат и оба мерења су валидна.

Транспорт ради, а услуга не – то је нормално стање

LSP може бити успостављен, преносити саобраћај и бити видљив у сваком систему надзора, док клијентска услуга остаје неупотребљива. У овој комбинацији нема ничег противречног, јер тунел нема мишљење о томе да ли удаљени префикс постоји, да ли га је политика увоза прихватила или да ли прикључено коло пропушта оквире.

Симптом који обично разоткрива забуну је асиметричан: пинг са PE loopback-а успева, док домаћин на клијентовом LAN-у не добија ништа, или обрнуто. Запишите које су адресе радиле пре него што створите теорију. Када приметите да тестирате два различита објекта, следећи корак је да прочитате стек ознака, уместо да се расправљате чији је граф тачан. Две адресе, два власника и обично две различите особе, од којих свака верује да је друга нешто покварила.

Читајте стек као две одговорности

Доња ознака припада услузи, а горња ознака путањи. RFC 4364 једноставно описује редослед: прво се намеће ознака VPN руте, затим се тај означени пакет тунелира ка следећем хопу BGP-а, где тунел са инжењерингом саобраћаја ставља своју ознаку одозго.

На удаљеном 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-а или правило приступа одредишту, и уништава доказ који вам је првобитно рекао да је транспорт здрав.