Necessita VPNv4 MPLS al nucli? No necessàriament

Activar la família d’adreces VPNv4 entre dos encaminadors només crea un context de distribució de rutes, i res més. No instal·la cap camí de reenviament ni indica quin encapsulament portarà un paquet de client fins al punt final remot. Un cop separats aquests dos fets, la pregunta «cal MPLS al nucli» es converteix en una qüestió més estreta i resoluble sobre el pla de dades que admet la plataforma.

Què negocia realment la família d’adreces

BGP multiprotocol transporta la informació d’accessibilitat de la capa de xarxa VPNv4 sota AFI 1 i SAFI 128, i cada entrada empareja un distingidor de ruta amb un prefix i una etiqueta. La sessió negocia que tots dos interlocutors poden codificar i descodificar aquesta informació. El que no negocia és un pla de dades. Tot el que ve després d’aquest paràgraf fa referència al reenviament, i res d’això no ho decideix l’aixecament de la sessió.

Així, una sessió correcta és una prova de capacitat del pla de control, no del reenviament. Un encaminador pot mantenir milers d’entrades VPNv4 i tot i així descartar cada paquet de client, i per això les dues classes de fallada es confonen d’entrada.

Fixeu-vos en l’etiqueta de l’NLRI. És una etiqueta de servei, lligada a un prefix dins d’una VRF, i té un paper de reenviament quan el paquet arriba al punt final de sortida. Si algun dispositiu de trànsit la llegeix és una decisió de disseny a part.

Rebuda, importació i reenviament són tres passos

Rebre una ruta, tenir permís per usar-la i poder reenviar-hi es fan en parts diferents de l’equip. BGP emmagatzema el que sent; la política d’importació i la coincidència d’objectiu de ruta decideixen quina VRF la pot considerar; després el pla de reenviament ha de resoldre el següent salt anunciat en alguna cosa que realment pugui posar en un cable.

És en aquest pas intermedi on viuen les fallades més sorprenents. Una ruta pot ser present a la taula BGP, vàlida i fins i tot la millor, mentre la taula de rutes de la VRF queda buida perquè cap objectiu de ruta no ha coincidit amb la llista d’importació. Res no registra un error de protocol, perquè no s’ha produït cap error de protocol.

L’últim pas és on es nota el suport de la plataforma. Un següent salt abastable a la capa subjacent no es resol automàticament com a transport de servei VPN, i l’equip pot exigir un tipus de túnel concret, una operació d’etiqueta concreta o totes dues coses. Llegir l’estat de resolució és més informatiu que llegir el recompte de rutes.

Un nucli IP pot portar una pila que mai no commuta

La distinció que val la pena conservar és entre «el nucli no executa MPLS» i «no hi ha cap etiqueta enlloc del servei». Són afirmacions diferents, i només la primera parla dels dispositius de trànsit. El RFC 4023 defineix el transport d’MPLS per túnels IP o GRE, i aquest és el mecanisme que fa possible la segona afirmació en un nucli totalment IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Els encaminadors de trànsit reenvien per la destinació IP exterior i no necessiten ni els prefixos de client ni la commutació d’etiquetes nativa. A l’extrem llunyà es retira el túnel exterior i l’etiqueta de servei reprèn la seva feina. El nucli ha mogut una càrrega opaca, que és exactament per a què serveix una xarxa IP.

El que aquest disseny no us dona és una garantia universal. No és cap prova que cada encaminador resolgui cada següent salt VPNv4 per qualsevol interfície GRE, ni és cap motiu per esborrar una configuració MPLS nativa que funciona. És un contraexemple a l’afirmació universal, i la pregunta pràctica continua sent local a la plataforma. Anoteu aquesta pregunta com una limitació de la plataforma i no com una regla del protocol.

Recorreu la cadena a l’equip fins que es trenqui

Comenceu per la ruta rebuda i atureu-vos al primer pas que falli, perquè els passos posteriors no es poden diagnosticar mentre un d’anterior està trencat. Quatre ordres cobreixen bona part d’això en una implementació típica.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Llegiu-les com una seqüència i no com quatre comprovacions independents. La primera confirma que la família és activa i que el veí intercanvia rutes; la segona mostra si el prefix ha arribat amb un següent salt utilitzable; la tercera demostra l’elegibilitat per a la importació; la quarta mostra si el pla de reenviament hi ha lligat una etiqueta o un túnel.

Després proveu el camí de càrrega en totes dues direccions, amb una MTU que sobrevisqui a l’encapsulament. GRE afegeix bytes de capçalera, i un camí que supera sondes petites pot fallar en paquets de mida completa només en una direcció, cosa que sembla una fallada d’aplicació i no de transport.

Dues notes operatives tanquen el cercle. GRE és encapsulament, no confidencialitat, així que una xarxa de trànsit no fiable necessita una disposició de seguretat admesa a sobre i no una suposició. I anoteu quin encapsulament admet realment la plataforma abans de la revisió de disseny, perquè aquesta única resposta decideix si un nucli només IP és una opció vàlida o un pla que no pot reenviar.