El laboratori MPLS L3VPN no fa ping? Comproveu aquests cinc salts

Dos encaminadors de client, un parell de caixes provider edge i un ping que mor sense cap missatge d’error. En un laboratori MPLS L3VPN petit, la fallada gairebé sempre se seu en un dels cinc punts de control, i cadascun té una ordre que mostra si la dependència funciona o si falta. L’error és reiniciar BGP cada vegada que falla el ping en lloc de provar les dependències en ordre. Si salteu directament a la configuració de la VRF, podeu passar una hora en un problema que va començar amb un salt següent no resolt dos equips més enllà.

Treballa la llista de baix a dalt. Un punt de control que passa es queda aprovat, i la primera fallada és la que val la pena depurar.

Punt de control u: els PE es poden abastar

Cada PE necessita una ruta cap al loopback de l’altre PE, i aquesta ruta s’ha de resoldre a través d’alguna cosa real. Un interior gateway protocol és la manera habitual d’arribar-hi, però una ruta estàtica també funciona sempre que la cerca recursiva caigui en una adjacency viva. En equips d’estil IOS, show ip route 10.0.0.2 seguit de show ip cef 10.0.0.2 indica si el prefix existeix i si hi ha una adjacency resolta al darrere. Una ruta a la taula sense adjacency al darrere no és abastabilitat.

Comproveu els dos sentits. Costos IGP asimètrics, una passive interface al costat equivocat o una distribute list que filtra el loopback trenquen cadascun només un sentit, i un sentit prou per matar la sessió. Si els loopbacks responen al ping però la sessió BGP es queda en Active, mireu la update source abans de tocar res més.

Punt de control dos: hi ha un camí d’etiquetes

Una ruta IP cap al loopback remot no demostra que el transport hi posarà una etiqueta. En un disseny LDP, confirmeu que el loopback remot té una binding local i una de remota, i que l’etiqueta de sortida apareix a la taula de forwarding. show mpls ldp bindings 10.0.0.2 32 mostra les parelles d’etiquetes, i show mpls forwarding-table 10.0.0.2 mostra què hi posarà realment la line card. Quan la segona ordre no mostra cap etiqueta o recau en IP, el transport no porta el trànsit VPN tal com el disseny suposa.

La distinció ve de com MPLS separa l’estat de forwarding dels prefixos de destinació, el model que es descriu a la RFC 3031. Si el vostre laboratori fa servir RSVP-TE o etiquetes adjacents a BGP en lloc de LDP, comproveu l’estat propi d’aquest mecanisme; suposar que LDP distribueix cada etiqueta de sota és una manera habitual de perseguir un error fantasma. Un camí d’etiquetes trencat sol aparèixer més tard com una ruta VPN present però inutilitzable.

Punt de control tres: la ruta VPN va arribar intacta

Mireu la ruta VPNv4 o VPNv6 del prefix de client exacte, no el resum de sessió. show bgp vpnv4 unicast all 10.10.1.0/24 hauria de mostrar el route distinguisher, el next hop fixat al loopback del PE remot i una etiqueta. Si falta el prefix, la política d’exportació al PE d’origen o la política d’importació al PE receptor és el primer sospitós, i les route targets són el culpable habitual.

Llegiu la comprovació de route target per separat de la recepció BGP. Una ruta pot arribar amb el next hop correcte i no aterrar a la VRF perquè l’import target no coincideix. Al PE receptor, show ip route vrf CUSTOMER 10.10.1.0 és la prova que importa; la taula BGP només demostra que la ruta va travessar el pla de control.

Punt de control quatre: l’interface és dins la VRF

Una definició de VRF amb un route distinguisher i route targets no hi mou cap interface. L’interface del costat CE necessita l’assignació de VRF, i show ip vrf interfaces o show ip interface brief l’hauria de llistar sota la instància correcta. Aquest és el punt de control on una configuració copiada falla més sovint, perquè el bloc de VRF sembla complet mentre l’interface encara se seu a la taula global.

Després confirmeu que el PE ha après el prefix de client local en aquesta VRF, i que el CE té una ruta de tornada pel punt de connexió. Una default estàtica al CE apuntant al PE n’hi ha prou per a un laboratori, sempre que la VRF del PE tingui una ruta cap a la LAN del CE. Si falta qualsevol de les dues meitats, el ping falla abans que es posi cap etiqueta.

Punt de control cinc: la resposta troba el camí de casa

Seguiu el paquet d’anada i després el de tornada, perquè fan servir taules diferents. Al PE d’entrada, l’origen del client s’ha de resoldre dins la VRF cap al prefix remot amb l’etiqueta remota. Al PE de sortida, la destinació s’ha de resoldre dins la mateixa VRF cap a l’interface del costat CE. Un ping llançat des del mateix PE no és cap prova: pot sortir per la taula global o per una altra adreça d’origen, i per això ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 és la prova que cal executar.

Els tallafocs dels amfitrions, el reverse-path filtering i les llistes d’accés del CE continuen aplicant-se. Si el camí d’anada funciona i la resposta mor, el problema és una ruta o un filtre al costat de tornada, no el transport MPLS.

Manteniu una línia per punt de control amb la primera dependència que va fallar. Aquesta línia converteix la queixa que el client no pot fer ping en una pregunta concreta sobre abastabilitat, estat d’etiquetes, importació de rutes, pertinença d’interfície o camí de tornada, i evita que la sessió de depuració següent repeteixi les mateixes cinc ordres en el mateix ordre.