D'una ruta RIP del CE a una VRF remota: on es produeix l'exportació

Una actualització RIPv2 arriba a la vora del proveïdor, cau en una taula d'encaminament VRF i s'hi atura llevat que alguna cosa l'exporti explícitament. Tres decisions es produeixen en seqüència, i cadascuna pot rebutjar el prefix pel seu propi motiu. Llegir-les com un sol esdeveniment és la raó per la qual la gent busca la caixa equivocada quan un lloc remot no pot arribar a una xarxa que el CE anuncia clarament. Seguiu la ruta a través del PE i la seqüència es fa evident.

Què fa el PE amb una actualització RIP

El PE rep l'actualització a la interfície VRF, comprova que l'origen sigui un veí permès i instal·la el prefix a la taula d'encaminament VRF amb un recompte de salts derivat de l'anunci. Aquesta taula és una taula d'encaminament normal, amb les seves pròpies distàncies administratives i la seva pròpia elecció del millor camí. Si el CE anuncia el mateix prefix dues vegades amb mètriques diferents, només el millor sobreviu a la taula. Res d'aquest pas no implica la xarxa troncal del proveïdor.

El prefix ara existeix dins del context d'encaminament d'un sol client, cosa que és molt lluny de ser abastable en qualsevol altre lloc.

L'exportació és un acte de política, no una conseqüència del protocol

Per sortir de la VRF, una ruta s'ha de redistribuir al procés MP-BGP que transporta rutes VPN, i necessita una comunitat estesa de tipus route target que identifiqui quines VRF remotes la poden importar. L'arquitectura de RFC 4364 manté aquests intercanvis separats del protocol CE-a-PE exactament per aquest motiu. Utilitzar RIP a la vora no diu res sobre què ha de travessar la xarxa del proveïdor.

Escriviu el contracte d'exportació abans de configurar res: els prefixos del client que han de ser abastables remotament, les rutes que han de quedar-se locals i qualsevol ruta per defecte, més específica o excepció de servei compartit. Compareu aquest contracte amb la VRF real i no amb una de nom similar que pertanyi a un altre client.

El costat d'importació és una segona política amb els seus propis route targets, i una exportació coincident amb una importació no coincident produeix un prefix que existeix a la xarxa troncal i no apareix a cap taula remota.

La redistribució i l'origen explícit es comporten de manera diferent

La redistribució pren rutes que ja existeixen a la taula VRF i les copia a BGP, filtrades per un mapa de rutes. El mapa decideix quins prefixos són elegibles i quins atributs porten, i la mètrica s'ha d'establir explícitament perquè un recompte de salts RIP no té cap significat com a mètrica BGP. Tot el que deixeu sense establir s'hereta d'una manera que normalment sorprèn la persona que llegeix la configuració sis mesos després.

La redistribució mútua és on es produeix el dany silenciós. Un prefix exportat a BGP pot tornar per un segon punt de redistribució, i sense etiquetes ni filtres la ruta oscil·la mentre les dues taules semblen plausibles en qualsevol instant. Filtreu per etiquetes aplicades a la vora en lloc de confiar que la topologia impedeixi el camí de tornada.

L'origen explícit sembla més net i no és incondicional. Una declaració de xarxa normalment necessita una ruta coincident a la taula d'encaminament abans que el prefix s'origini, de manera que l'anunci desapareix en el moment que el CE deixa d'anunciar-lo. Sovint aquest és el comportament que voleu, i no és el mateix que una ruta estàtica que queda configurada per sempre. Comproveu la regla real de la plataforma en lloc de suposar cap dels dos comportaments.

De qualsevol manera, la pregunta que cal fer sobre cada prefix és quin origen actiu el fa elegible i què passa quan aquest origen desapareix.

Verifiqueu la cadena en quatre punts

Mireu l'anunci del CE, la taula d'encaminament VRF, la taula de rutes VPN amb el seu route target i la importació de la VRF remota, en aquest ordre. A IOS això vol dir la sortida del veí CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, i la mateixa ordre al PE remot. A IOS-XR la sortida equivalent es troba sota show bgp vrf CUSTOMER ipv4 unicast. Els noms de les ordres difereixen, els quatre punts de control no.

Comproveu un prefix que hauria de ser rebutjat amb tant de cura com un que hauria de passar, perquè una política que ho permet tot és idèntica a una de correcta fins que arriba la primera excepció. Després observeu una retirada: tanqueu la interfície del CE i confirmeu que l'entrada remota desapareix dins del temporitzador esperat en lloc de romandre.

Registreu qui és propietari de cada política. Quan el proveïdor gestiona el CE, el comportament lliurat pertany al contracte de servei, i un protocol o una política de retirada diferents al dispositiu gestionat són un problema de documentació abans que un problema d'encaminament.