Enrutamento de sucursais MPLS: que aprende a CE e de quen

Un host dunha sucursal abre unha conexión cun servidor doutra, e ambas as sedes están detrás da mesma VPN MPLS de nivel 3 xestionada. O host só coñece a súa propia pasarela predeterminada e nada máis, o que é correcto. O importante é que o borde de cliente local entregue o paquete cara ao seu borde de provedor, e que o estado de enrutamento VPN do provedor o leve á sucursal que posúe o prefixo de destino.

Percorrer un paquete polo camiño é a forma máis rápida de ver que parte é responsabilidade do cliente e que parte pertence ao servizo.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Onde remata o traballo de cada salto

A CE-A necesita unha ruta para a LAN remota que apunte á súa conexión local co provedor, non ao enderezo WAN da sucursal remota. Despois o provedor transporta o paquete polo seu propio núcleo usando o estado de enrutamento VPN, e a CE-B entrégao na LAN de destino. En ningún momento un host necesita entender etiquetas, VRF nin o circuíto de internet do outro extremo.

O erro que aparece unha e outra vez nos tickets é configurar o enderezo WAN da sucursal B como seguinte salto na sucursal A. Ambas as sucursais compraron o mesmo servizo, así que parece que deberían ser veciñas. Non o son: un seguinte salto debe ser alcanzable a través do deseño de enrutamento que realmente ten, e a CE remota adoita estar a moitos saltos de distancia, detrás de equipamento que vostede non administra. Unha ruta estática construída sobre esa suposición aparece como activa e non resolve a nada, o que é peor ca unha ruta ausente porque na táboa parece correcta.

A RFC 4364 separa o intercambio entre o borde de cliente e o do provedor da distribución de rutas VPN que fai o provedor, e esa é exactamente a fronteira da que trata este manual. O traballo do cliente é dicirlle ao seu borde que pode entregar e aceptar a alcanzabilidade que o servizo ofrece de volta.

En que debe poñerse de acordo a entrega

Escolla o mecanismo co provedor, non ás súas costas. As rutas estáticas, BGP ou un acordo de protocolo de enrutamento entre a CE e a PE son todos lexítimos, e OSPF ten un modelo MPLS VPN definido para esa entrega. Nada diso é motivo para construír unha adxacencia OSPF entre dous bordes de cliente remotos a través dun núcleo de provedor non especificado, que é un deseño que o provedor non aceptou e non pode soportar.

Antes de poñer en servizo unha LAN nova, anote catro cousas: o prefixo, a ruta local seguinte na CE, o anuncio que o provedor aceptará e as rutas que o provedor devolverá. Engada calquera filtrado, límite de prefixos ou restrición entre sedes que impoña o contrato. Unha adxacencia sa é unha canle para intercambiar información, e non é proba de que se aceptase un prefixo concreto; a sesión pode estar activa mentres a súa nova subrede está dentro dun filtro.

Despois siga a resposta. A sucursal B necesita unha ruta de volta á LAN de orixe, e o host do lado receptor necesita a súa propia pasarela e os seus propios permisos de servizo. Unha ruta que aparece na CE-A establece medio viaxe de ida e volta, e medio viaxe é a razón pola que unha dirección dunha proba de ping parece sa mentres a aplicación segue fallando.

Comprobe as dúas entregas antes de asinar

Reúna o estado de enrutamento nos dous bordes de cliente, confirme co provedor que os prefixos de LAN previstos se aceptaron na VPN e despois probe unha aplicación permitida en cada dirección. As táboas de rutas por si soas non demostran que a aplicación funcione, e unha proba de aplicación por si soa non lle di que plano de control fallou cando non funciona.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lea as tres saídas en conxunto. A primeira di que cre o borde, a segunda di que aprendeu e de que veciño, e a terceira di que reenviará realmente. A discrepancia entre elas adoita ser un problema de política ou de recursión máis ca un anuncio ausente, e merece resolverse antes de pedir ao provedor que investigue. Leve esas tres saídas á chamada co operador, porque responden á maioría das preguntas que un enxeñeiro de soporte lle faría doutro xeito.

Saiba que non ofrece o servizo

Isto é acceso enrutado de nivel 3. Non é un circuíto de nivel 2 que estenda difusións entre oficinas, así que os protocolos de descubrimento, as aplicacións dependentes de difusión e as suposicións de segmento compartido non viaxan con el. A impresión, o exame de nomes e calquera cousa que dependa dun segmento local necesitan o seu propio deseño.

A separación de VPN tampouco é cifrado. A conmutación de etiquetas mantén os clientes separados dentro da rede do provedor, e non fai confidencial a carga útil se o contrato esixe confidencialidade. Onde iso importa, a aplicación ou unha capa superposta debe achegala.

Por último, manteña o modelo de servizo escrito xunto á configuración de enrutamento da sede. O seguinte enxeñeiro que engada unha subrede debería poder ler que prefixos se anuncian, quen os acepta e cal é o camiño de volta esperado: a especificación BGP/MPLS IP VPN é a referencia do modelo que hai detrás de todo isto.