IPv6 nunha VPN MPLS: tres decisións, non unha soa familia de enderezos
As rutas da VPN do cliente, a sesión BGP entre os PE e o transporte do núcleo son decisións separadas. Unha sesión pode ir nunha familia e levar outra.
Diga «executa unha IPv6 L3VPN sobre IPv6 BGP» nunha revisión de deseño e dentro desa soa frase escóndense tres decisións separadas. Que prefixos pertencen á VPN do cliente, que enderezos levan a sesión de encamiñamento entre as beiras do provedor e que núcleo move o paquete etiquetado son eleccións independentes. Todas poden ser IPv6, poden estar mesturadas, e mesturalas está permitido a propósito. Desenredar as tres é o que converte un requisito vago en algo contra o que se pode probar unha plataforma.
Separe as tres tarefas
A primeira tarefa é a ruta do cliente: prefixos IPv6 que pertencen a un contexto de encamiñamento da VPN e deben quedar fóra de calquera outro contexto. A segunda é a conexión de encamiñamento entre os routers de beira do provedor que intercambian eses prefixos. A terceira é o transporte que leva o paquete etiquetado do cliente polo núcleo ata a beira remota. Nomear só unha delas aínda non é un deseño.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Cada tarefa ten a súa propia familia de enderezos, as súas propias formas de fallar e a miúdo o seu propio equipo. A táboa é útil precisamente porque unha soa frase nun documento de deseño tende a colapsar as tres filas nunha.
A familia da ruta é VPN-IPv6, non IPv6 unicast
RFC 4659 define a familia BGP/MPLS IPv6 VPN, e pertencer a ela é máis específico do que suxire a palabra IPv6. Unha ruta alí é un distinguidor de ruta unido a un prefixo IPv6, codificado baixo AFI 2 e SAFI 128. O IPv6 unicast ordinario é outra familia, así que un anuncio que nun looking glass parece un prefixo pode non ser o mesmo obxecto en absoluto. Ler mal a familia é a primeira forma en que este deseño sae mal.
A diferenza morde na beira, onde unha ruta ten que aterrar no contexto de VPN correcto antes de facer nada. Recibir un prefixo demostra que o intercambio ocorreu e non di nada sobre a instalación. Esa fenda produce o informe clásico no que a sesión está arriba e o cliente segue ás escuras.
A sesión pode ir nunha familia distinta da VPN
Nada obriga a conexión BGP entre dúas beiras a usar a familia propia da VPN. A especificación permite unha sesión IPv4 ou IPv6, e o transporte de IPv6 VPN está definido el mesmo sobre ambos tipos de núcleo. Por tanto, unha sesión IPv6 non di nada sobre a familia do que leva, e tampouco escolle o plano de datos. Tres bits independentes, e o deseño debería levar os tres por separado.
Iso libera e ao mesmo tempo lese mal con facilidade. As rutas de cliente IPv6 poden ir sobre unha sesión con enderezo IPv4, e as rutas IPv4 sobre unha IPv6, sempre que a plataforma admita a combinación e o seguinte salto se resolva. O que non debe pasar é deixar que a sesión implique a carga útil, nin no documento de deseño nin na monitorización que despois demostra o servizo.
O seguinte salto nun núcleo IPv4 ten a súa propia codificación
Cando o núcleo baixo a VPN é IPv4, a ruta non aparece cun seguinte salto que a beira de entrada poida usar directamente. Chega en forma de IPv6 mapeada a IPv4, e así é como a especificación expresa a beira de saída cando o transporte por baixo é IPv4. O router de entrada ten entón que converter ese enderezo mapeado en algo que realmente poida acadar polo núcleo, e a resolución é o paso que falla en silencio.
Léao como unha dependencia de reenvío e non como unha cadea que se copia entre equipos. Confirme tres cousas na plataforma que realmente opera: o seguinte salto anunciado resólvese nun camiño utilizábel, a pila de etiquetas acéptase e o destino aterra no contexto de VPN previsto. Calquera delas que falle deixa unha sesión que parece sa, e non reenvía nada, e por iso a comprobación pertence á proba de aceptación e non a un incidente posterior.
Escriba o requisito en catro liñas
Un requisito que merece probarse nomea catro cousas: a familia da VPN, o transporte da sesión, a codificación do seguinte salto e a disposición do núcleo. Despois nomea un prefixo de cliente que seguir de extremo a extremo: polo intercambio, a instalación, a resolución de etiquetas e o camiño de volta. «Admite IPv6 BGP» non cobre ningunha das catro e agocha onde vive realmente o desaxuste.
Unha sesión sa sen o intercambio VPN-IPv6 está incompleta, e unha ruta VPN recibida sen reenvío funcionando está igualmente incompleta. Manter esas como liñas de aceptación separadas fai curta a seguinte conversa de diagnóstico, porque a liña que falla xa está escrita.