OSPF-roetetipe oor 'n VPN: nie altyd ekstern nie

’n Klantprefiks steek die diensverskaffer se wolk as ’n BGP-VPN-roete oor en kom by die verre perseel aan soos ’n eksterne OSPF-roete, wat baie ingenieurs verwag, maar dit is nie die enigste moontlike uitkoms nie. Wat die verre CE sien, hang af van die OSPF-domein waaruit die prefiks kom en van sy oorspronklike roetetipe, en albei reis saam met die VPN-roete. Die aanname dat elke herverdeelde prefiks in Tipe 5 verander, lei tot voorkeurveranderings wat nie kan werk nie. Vergelyk eers die domeinidentifiseerder, nie die administratiewe afstand nie.

Die PE-CE-model dra genoeg konteks sodat die ontvangende PE ’n OSPF-advertensie kan rekonstrueer eerder as om een te versin.

Wat saam met die roete reis

RFC 4577 definieer die OSPF-eienskappe wat ’n VPN-roete vergesel: die domeinidentifiseerder, die metriek en die roetetipe van die oorsprongperseel. Die ontvangende PE gebruik hulle om te besluit hoe ’n geskikte prefiks aan sy plaaslike OSPF-proses moet verskyn. Sonder daardie eienskappe sou die verre PE geen grondslag hê vir enigiets behalwe ’n eksterne herverdeling nie. Daarom kan ’n roete as ’n tussen-area-LSA aankom, selfs al het BGP dit intussen gedra.

Die area-tipe maak ook saak. ’n Stub- of NSSA-area beperk watter LSA's mag binnekom, so dieselfde VPN-roete kan anders aangebied word na gelang van waar die ontvangende OSPF-instansie sit. Gekonfigureerde uitvoerbeleid kan ook die verstekaanbieding oorheers, wat ’n doelbewuste keuse is eerder as ’n newe-effek.

Dieselfde domein, ander aanbieding

’n Intra-area- of tussen-area-roete uit dieselfde domein kom gewoonlik by die verre perseel aan as ’n tussen-area-roete, ’n Tipe 3-LSA. ’n Prefiks uit ’n ander domein, ’n oorsprong wat nooit OSPF gepraat het nie, of ’n aanvanklik eksterne OSPF-advertensie volg eerder die eksterne reëls, en dit is waar Tipe 5 en sy NSSA-ekwivalent verskyn. Albei gedrag is korrek; die inset verskil. Vergelyk domeinidentifiseerders en geadverteerde eienskappe voordat jy voorkeurwaardes aanraak.

Administratiewe afstand kies tussen bronne op een router. Dit herskryf nie ’n LSA-tipe nie en skep nie die domeinverhouding wat ontbreek nie.

Wanneer ’n sham-koppeling die regte antwoord is

Stel jou twee persele in dieselfde area voor wat deur ’n direkte agterdeur-koppeling verbind is. OSPF hou daardie intra-area-pad eerder as die tussen-area-pad wat deur die diensverskaffer gebied word, selfs wanneer gekonfigureerde koste die diensverskafferpad aantreklik sou maak. ’n Sham-koppeling verteenwoordig ’n intra-area-verhouding oor die VPN sodat koste aan die besluit kan deelneem. Dit bestaan vir daardie spesifieke padkeuseprobleem, nie om elke roete uit dieselfde domein intern te laat lyk nie.

’n Sham-koppeling benodig bereikbare eindpunte en wedersydse konfigurasie op albei PE's. As jy dit net aan een kant opstel, ontstaan ’n verhouding wat nooit vorm nie, en die roetertabel hou sy ou voorkeur, wat lyk asof die funksie niks gedoen het nie.

Moenie die lusbeskerming breek nie

Die PE-CE-model stel die DN-bis op roetes wat dit versprei, sodat ’n prefiks nie deur ’n ander CE kan terugkeer en ’n tweede keer herverdeel word nie. Daardie beskerming is wat keer dat ’n prefiks tussen persele wat ’n OSPF-domein deel, in ’n lus beland. Om dit te verwyder of te ignoreer om ’n roete intern te laat lyk, kan presies die lus skep waarvoor dit ontwerp is. Wanneer ’n prefiks verkeerd lyk, behandel die DN-bis as inligting eerder as as ’n hindernis.

Dieselfde versigtigheid geld vir herverdelingsfilters en roetekaarte wat gemeenskappe stroop. Elkeen verwyder konteks wat die verre kant nodig het, en die gevolglike advertensie kan geloofwaardig lyk terwyl dit verkeerd is. Verander een eienskap op ’n slag en kyk wat die verre CE werklik installeer.

Verifieer dan van die verre perseel af: die LSA-tipe, die adverterende router en die pad wat dit gekies het. Daardie bewyse beantwoord die vraag wat die kaartjie gevra het.