Configuración del enrutamiento entre enrutadores PE y CE
En este tema, se proporciona información sobre cómo configurar el enrutamiento en enrutadores PE y CE \ en una VPN de capa 3.
Configuración del enrutamiento entre enrutadores PE y CE en VPN de capa 3
Para que el enrutador de PE distribuya rutas relacionadas con VPN hacia y desde enrutadores CE conectados, debe configurar el enrutamiento dentro de la instancia de enrutamiento VPN. Puede configurar un protocolo de enrutamiento (BGP, OSPF o RIP) o puede configurar el enrutamiento estático. Para la conexión a cada enrutador CE, solo puede configurar un tipo de enrutamiento.
En las siguientes secciones se explica cómo configurar el enrutamiento VPN entre los enrutadores PE y CE:
- Configuración del BGP entre los enrutadores PE y CE
- Configuración de OSPF entre los enrutadores de PE y CE
- Configuración de vínculos simulados de OSPF para VPN de capa 3
- Configurar un ID de dominio de OSPF
- Configuración de RIP entre los enrutadores de PE y CE
- Configuración de rutas estáticas entre los enrutadores de PE y CE
Configuración del BGP entre los enrutadores PE y CE
Para configurar el BGP como el protocolo de enrutamiento entre los enrutadores PE y CE, incluya la bgp instrucción:
bgp {
group group-name {
peer-as as-number;
neighbor ip-address;
}
}
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Nota:El
[edit logical-systems]nivel de jerarquía no es aplicable en enrutadores serie ACX.Tenga en cuenta las siguientes limitaciones con respecto a la configuración del BGP para instancias de enrutamiento:
En una instancia de enrutamiento VRF, no configure el número del sistema autónomo local (AS) mediante un número as que ya esté en uso por un par de BGP remoto en una instancia de enrutamiento VRF independiente. Al hacerlo, se crea un bucle de sistema autónomo en el que se ocultan todas las rutas recibidas de este par de BGP remoto.
Configure el número de AS local mediante la
autonomous-systeminstrucción en el[edit routing-instances routing-instance-name routing-options]nivel de jerarquía o lalocal-asinstrucción en cualquiera de los siguientes niveles de jerarquía:[edit routing-instances routing-instance-name protocols bgp][edit routing-instances routing-instance-name protocols bgp group group-name][edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
Configure el número del AS para un par de BGP mediante la
peer-asinstrucción en el[edit routing-instances routing-instance-name protocols bgp group group-name]nivel jerárquico.
Configuración de OSPF entre los enrutadores de PE y CE
Puede configurar OSPF (versión 2 o 3) para distribuir rutas relacionadas con VPN entre enrutadores PE y CE.
En las siguientes secciones se describe cómo configurar OSPF como protocolo de enrutamiento entre el PE y los enrutadores CE:
- Configuración de la versión 2 de OSPF entre los enrutadores PE y CE
- Configuración de OSPF versión 3 entre los enrutadores PE y CE
Configuración de la versión 2 de OSPF entre los enrutadores PE y CE
Para configurar OSPF versión 2 como el protocolo de enrutamiento entre un enrutador PE y CE, incluya la ospf instrucción:
ospf {
area area {
interface interface-name;
}
}
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Nota:El
[edit logical-systems]nivel de jerarquía no es aplicable en enrutadores serie ACX.
Configuración de OSPF versión 3 entre los enrutadores PE y CE
Para configurar OSPF versión 3 como el protocolo de enrutamiento entre un enrutador PE y CE, incluya la ospf3 instrucción:
ospf3 {
area area {
interface interface-name;
}
}
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Nota:El
[edit logical-systems]nivel de jerarquía no es aplicable en enrutadores serie ACX.
Configuración de vínculos simulados de OSPF para VPN de capa 3
Cuando configure OSPF entre los enrutadores PE y CE de una VPN de capa 3, también puede configurar vínculos simulados de OSPF para compensar los problemas relacionados con los vínculos dentro del área OSPF.
En las siguientes secciones se describen vínculos simulados de OSPF y cómo configurarlos:
- Descripción general de vínculos de OSPF Sham
- Configuración de vínculos simulados de OSPF
- Ejemplo de vínculos de OSPF Sham
Descripción general de vínculos de OSPF Sham
La Figura 1 proporciona una ilustración de cuándo puede configurar un vínculo simulado de OSPF. El enrutador CE1 y el enrutador CE2 se encuentran en el mismo área OSPF. Estos enrutadores CE están vinculados entre sí por una VPN de capa 3 a través del enrutador PE1 y el enrutador PE2. Además, los enrutadores CE1 y CE2 están conectados mediante un vínculo intra-área que se utiliza como respaldo.
OSPF trata el vínculo a través de la VPN de capa 3 como un vínculo entre áreas. De forma predeterminada, OSPF prefiere los vínculos entre áreas a los vínculos entre áreas, por lo que OSPF selecciona el vínculo de intraarea de respaldo como la ruta activa. Esto no es aceptable en configuraciones en las que el vínculo dentro del área no es la ruta principal esperada para el tráfico entre los enrutadores CE.
Un vínculo simulado de OSPF también es un vínculo dentro de área, con la excepción de que está configurado entre los enrutadores de PE, como se muestra en la Figura 1. Puede configurar la métrica para el vínculo simulado para asegurarse de que se prefiera la ruta a través de la VPN de capa 3 a una ruta de respaldo a través de un vínculo intra area que conecta los enrutadores CE.
simulado de OSPF
Debe configurar un vínculo simulado de OSPF en las siguientes circunstancias:
Dos enrutadores CE están vinculados entre sí por una VPN de capa 3.
Estos enrutadores CE se encuentran en el mismo área OSPF.
Se configura un vínculo dentro del área entre los dos enrutadores CE.
Si no hay ningún vínculo dentro del área entre los enrutadores CE, no es necesario configurar un vínculo simulado de OSPF.
Para obtener más información acerca de los vínculos simulados de OSPF, consulte el borrador de Internet draft-ietf-l3vpn-ospf-2547-01.txt, OSPF como protocolo PE/CE en VPN BGP/MPLS.
Configuración de vínculos simulados de OSPF
El enlace simulado es un vínculo intra-área de punto a punto no numerado y se anuncia mediante un anuncio de estado de enlace tipo 1 (LSA). Los vínculos simulados solo son válidos para instancias de enrutamiento y OSPF versión 2.
Cada vínculo simulado se identifica mediante una combinación de la dirección del punto de final del vínculo simulado local y remoto y el área OSPF a la que pertenece. Los vínculos simulados se deben configurar manualmente. Puede configurar el vínculo simulado entre dos enrutadores de PE, ambos dentro de la misma instancia de enrutamiento VRF.
Debe especificar la dirección del punto final local del vínculo simulado. Esta dirección se utiliza como el origen de los paquetes de vínculo simulados y también la utiliza el enrutador de PE remoto como el punto de extremo remoto del vínculo simulado.
La dirección local del vínculo simulado OSPF se debe especificar con una dirección de circuito cerrado para la VPN local. El BGP debe propagar la ruta a esta dirección. Especifique la dirección para el punto final local mediante la opción local de la instrucción sham-link :
sham-link { local address; }
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[editar protocolos routing-instance-name de instancias de enrutamiento ospf]
[editar protocolos de instancias de enrutamiento de sistemas logical-system-name lógicos routing-instance-name ospf]
La dirección remota del vínculo simulado OSPF se debe especificar con una dirección de circuito cerrado para la VPN remota. El BGP debe propagar la ruta a esta dirección. Para especificar la dirección del punto de extremo remoto, incluya la instrucción sham-link-remote :
sham-link-remote address <metric number>;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[editar área area-idospf de protocolos routing-instance-name de instancias de enrutamiento ]
[editar el área area-idospf de protocolos routing-instance-name de instancias de enrutamiento de sistemas logical-system-name lógicos ]
Opcionalmente, puede incluir la opción de métrica para establecer un valor de métrica para el punto de extremo remoto. El valor de la métrica especifica el costo de usar el vínculo. Se prefieren las rutas con métricas de ruta total más bajas que las que tienen métricas de ruta más altas.
Puede configurar un valor del 1 al 65 535. El valor predeterminado es 1.
Ejemplo de vínculos de OSPF Sham
En este ejemplo, se muestra cómo habilitar vínculos simulados de OSPF en un enrutador de PE.
La siguiente es la configuración de interfaz de circuito cerrado en el enrutador de PE. La dirección configurada es para el punto final local del vínculo simulado OSPF:
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
La siguiente es la configuración de la instancia de enrutamiento en el enrutador de PE, incluida la configuración para el vínculo simulado OSPF. La instrucción local sham-link está configurada con la dirección para la interfaz de circuito cerrado local:
[edit]
routing-instances {
example-sham-links {
instance-type vrf;
interface e1-1/0/2.0;
interface lo0.1;
route-distinguisher 3:4;
vrf-import vpn-red-import;
vrf-export vpn-red-export;
protocols {
ospf {
sham-link local 10.1.1.1;
area 0.0.0.0 {
sham-link-remote 10.2.2.2 metric 1;
interface e1-1/0/2.0 metric 1;
}
}
}
}
}
Configurar un ID de dominio de OSPF
Para la mayoría de las configuraciones de OSPF que implican VPN de capa 3, no es necesario configurar un ID de dominio OSPF. Sin embargo, para una VPN de capa 3 que conecta varios dominios OSPF, la configuración de los IDs de dominio de OSPF puede ayudarlo a controlar la traducción de LSA (para LSA tipo 3 y tipo 5) entre los dominios de OSPF y las rutas de puerta trasera. Cada tabla de enrutamiento y reenvío VPN (VRF) en un enrutador de PE asociado con una instancia de OSPF está configurada con el mismo ID de dominio de OSPF. El ID de dominio predeterminado de OSPF es el valor null 0.0.0.0. Como se muestra en la tabla 1, una ruta con un ID de dominio nulo se maneja de manera diferente a una ruta sin ningún ID de dominio en absoluto.
Ruta recibida |
ID de dominio de la ruta recibida |
ID de dominio en el enrutador receptor |
Ruta redistribuida y anunciada como |
|---|---|---|---|
Ruta tipo 3 |
A.B.C.D |
A.B.C.D |
LSA tipo 3 |
Ruta tipo 3 |
A.B.C.D |
E.F.G.H |
LSA tipo 5 |
Ruta tipo 3 |
0.0.0.0 |
0.0.0.0 |
LSA tipo 3 |
Ruta tipo 3 |
Null |
0.0.0.0 |
LSA tipo 3 |
Ruta tipo 3 |
Null |
Null |
LSA tipo 3 |
Ruta tipo 3 |
0.0.0.0 |
Null |
LSA tipo 3 |
Ruta tipo 3 |
A.B.C.D |
Null |
LSA tipo 5 |
Ruta tipo 3 |
Null |
A.B.C.D |
LSA tipo 3 |
Ruta tipo 5 |
No aplicable |
No aplicable |
LSA tipo 5 |
Puede configurar un ID de dominio de OSPF para la versión 2 y la versión 3 de OSPF. La única diferencia en la configuración es que se incluyen instrucciones en el nivel de jerarquía de [edit-instances routing-instance-name protocol ospf] para OSPF versión 2 y en el nivel de jerarquía de [edit-routing-instances routing-instance-name protocol ospf3] para OSPF versión 3. Las descripciones de configuración que siguen solo están presentes en la instrucción OSPF versión 2. Sin embargo, los subestados también son válidos para OSPF versión 3.
Para configurar un ID de dominio OSPF, incluya la instrucción domain-id :
domain-id domain-Id;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[editar protocolos routing-instance-name de instancias de enrutamiento ospf]
[editar protocolos de instancias de enrutamiento de sistemas logical-system-name lógicos routing-instance-name ospf]
Puede establecer una etiqueta VPN para las rutas externas del OSPF generadas por el enrutador de PE para evitar que se produzcan bucles. De forma predeterminada, esta etiqueta se calcula automáticamente y no necesita configuración. Sin embargo, puede configurar la etiqueta VPN de dominio para los LSA tipo 5 explícitamente incluyendo la instrucción domain-vpn-tag :
no-domain-vpn-tag number;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[editar protocolos routing-instance-name de instancias de enrutamiento ospf]
[editar protocolos de instancias de enrutamiento de sistemas logical-system-name lógicos routing-instance-name ospf]
El rango es de 1 a 4.294.967.295 (232 – 1). Si establece etiquetas VPN manualmente, debe establecer el mismo valor para todos los enrutadores de PE en la VPN.
Para obtener un ejemplo de este tipo de configuración, consulte Configurar un ID de dominio de OSPF para una VPN de capa 3.
VPN de capa 3 de hub-and-spoke e IDs de dominio OSPF
El comportamiento predeterminado de un ID de dominio OSPF causa algunos problemas en las VPN de capa 3 de concentrador y radio configuradas con OSPF entre el enrutador de PE de hub y el enrutador CE de concentrador cuando las rutas no se agregan. Una configuración de concentrador y radio tiene un enrutador de PE concentrador con vínculos directos a un enrutador CE de concentrador. El enrutador de PE de hub recibe actualizaciones de BGP de capa 3 de los otros enrutadores de PE de radio remoto, y estas se importan a la instancia de enrutamiento radial. Desde la instancia de enrutamiento radial, los LSA de OSPF se originan y se envían al enrutador CE del hub.
El enrutador CE de hub suele agregar estas rutas y, luego, envía estas LSA recién originadas de vuelta al enrutador de PE del hub. El enrutador de PE de hub exporta las actualizaciones del BGP a los enrutadores de PE radio remoto que contienen los prefijos agregados. Sin embargo, si hay LSA de resumen de tipo 3 no desglosados o LSA externos, surgen dos problemas con respecto a cómo se origina el enrutador PE de hub y envía LSA al enrutador CE de concentrador, y cómo el enrutador de PE de concentrador procesa los LSA recibidos del enrutador CE del hub:
De forma predeterminada, todos los LSA originados por el enrutador de PE de hub en la instancia de enrutamiento radial tienen el bit DN establecido. Además, todos los LSA originados externamente tienen el conjunto de etiqueta de ruta VPN. Esta configuración ayuda a evitar los bucles de enrutamiento. Para los LSA de resumen de tipo 3, los bucles de enrutamiento no son una preocupación, ya que el enrutador CE del hub, como enrutador de borde de área (ABR), reorigina los LSA con el bit DN despejado y los envía de vuelta al enrutador de PE del hub. Sin embargo, el enrutador CE del hub no reorigina los LSA externos, ya que tienen un alcance inundado de AS.
Puede originar los LSA externos (antes de enviarlos al enrutador CE de hub) con el bit DN claro y la etiqueta de ruta VPN establecida en 0 mediante la modificación de la configuración de la instancia de enrutamiento del enrutador DE PE del hub. Para borrar el bit DN y establecer la etiqueta de ruta VPN en cero en LSA externos originados por un enrutador de PE, configure 0 para la instrucción domain-vpn-tag en el nivel de jerarquía [edit-routing-instances routing-instance-name protocol ospf]. Debe incluir esta configuración en la instancia de enrutamiento en el enrutador de PE hub frente al enrutador CE de concentrador donde se envían los LSA. Cuando el enrutador CE de concentrador recibe LSA externos del enrutador de PE de hub y, luego, los reenvía al enrutador de PE de concentrador, el enrutador de PE de concentrador puede usar los LSA en su cálculo de ruta de OSPF.
Cuando los LSA inundados por el enrutador CE de concentrador llegan a la instancia de enrutamiento del enrutador de PE del hub, el enrutador de PE de hub, que actúa como ABR, no considera estos LSA en sus cálculos de ruta de OSPF, a pesar de que las LSA no tienen el conjunto de bits DN y las LSA externas no tienen una etiqueta de ruta VPN establecida. Se supone que los LSA provienen de un área troncal disjunta.
Puede cambiar la configuración de la instancia de enrutamiento del enrutador de PE para que el enrutador de PE actúe como un no ABR mediante la inclusión de la instrucción disable en el nivel de jerarquía [edit enrutamiento-instances routing-instance-name protocol ospf domain-id]. Haga este cambio de configuración al enrutador de PE de concentrador que recibe los LSA del enrutador CE del concentrador.
Al hacer este cambio de configuración, la instancia de enrutamiento del enrutador de PE actúa como una no ABR. Luego, el enrutador de PE considera que los LSA que llegan del enrutador CE del hub como si provenían de un área contigua no de núcleo.
Configuración de RIP entre los enrutadores de PE y CE
Para una VPN de capa 3, puede configurar RIP en el enrutador de PE para aprender las rutas del enrutador CE o para propagar las rutas del enrutador de PE al enrutador CE. Las rutas RIP aprendidas de los vecinos configurados en cualquier [edit routing-instances] nivel jerárquico se agregan a la tabla de la instancia de inet enrutamiento (instance_name.inet.0).
Para configurar RIP como el protocolo de enrutamiento entre el PE y el enrutador CE, incluya la rip instrucción:
rip {
group group-name {
export policy-names;
neighbor interface-name;
}
}
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name protocols][edit logical-systems logical-system-name routing-instances routing-instance-name protocols]Nota:El
[edit logical-systems]nivel de jerarquía no es aplicable en enrutadores serie ACX.
De forma predeterminada, RIP no anuncia las rutas que recibe. Para anunciar rutas desde un enrutador de PE a un enrutador CE, debe configurar una política de exportación en el enrutador de PE para RIP. Para obtener más información acerca de cómo definir políticas para RIP, consulte Política de importación de RIP.
Para especificar una política de exportación para RIP, incluya la export instrucción:
export [ policy-names ];
Puede incluir esta instrucción para RIP en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name protocols rip group group-name][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name]Nota:El
[edit logical-systems]nivel de jerarquía no es aplicable en enrutadores serie ACX.
Para instalar rutas aprendidas de una instancia de enrutamiento RIP en varias tablas de enrutamiento, incluya las rib-group instrucciones y group :
rib-group inet group-name;
group group-name {
neighbor interface-name;
}
Puede incluir estas instrucciones en los siguientes niveles jerárquicos:
[edit protocols rip][edit routing-instances routing-instance-name protocols rip][edit logical-systems logical-system-name protocols rip][edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip]
El [edit logical-systems] nivel de jerarquía no es aplicable en enrutadores serie ACX.
Para configurar un grupo de tabla de enrutamiento, incluya la rib-groups instrucción:
rib-groups group-name;
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-options][edit logical-systems logical-system-name routing-options]
El [edit logical-systems] nivel de jerarquía no es aplicable en enrutadores serie ACX.
Para agregar una tabla de enrutamiento a un grupo de tabla de enrutamiento, incluya la import-rib instrucción. El primer nombre de tabla de enrutamiento especificado bajo la import-rib instrucción debe ser el nombre de la tabla de enrutamiento que está configurando. Para obtener más información acerca de cómo configurar tablas de enrutamiento y grupos de tablas de enrutamiento, consulte Biblioteca de protocolos de enrutamiento de Junos OS.
import-rib [ group-names ];
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-options rib-groups group-name][edit logical-systems logical-system-name routing-options rib-groups group-name]
El [edit logical-systems] nivel de jerarquía no es aplicable en enrutadores serie ACX.
Las instancias rip solo se admiten para los tipos de instancia VRF. Puede configurar varias instancias de RIP solo para la compatibilidad de VPN. Puede usar RIP en el entorno de borde de proveedor de borde del cliente (CE-PE) para aprender rutas del enrutador CE y propagar las rutas de instancia del enrutador de PE en el enrutador CE.
Las rutas RIP aprendidas de los vecinos configurados en cualquier jerarquía de instancia se agregan a la tabla de enrutamiento de la instancia, instance-name.inet.0.
RIP no admite grupos de tabla de enrutamiento; por lo tanto, no puede importar rutas en varias tablas como lo hace el protocolo OSPF u OSPFv3.
Configuración de rutas estáticas entre los enrutadores de PE y CE
Puede configurar rutas estáticas (que no cambian) entre los enrutadores PE y CE de una instancia de enrutamiento VPN. Para configurar una ruta estática para una VPN, debe configurarla dentro de la configuración de instancia de enrutamiento VPN en el [edit routing-instances routing-instance-name routing-options] nivel jerárquico.
Para configurar una ruta estática entre los enrutadores PE y CE, incluya la static instrucción:
static {
route destination-prefix {
next-hop [ next-hops ];
static-options;
}
}
Puede incluir esta instrucción en los siguientes niveles jerárquicos:
[edit routing-instances routing-instance-name routing-options][edit logical-systems logical-system-name routing-instances routing-instance-name routing-options]
El [edit logical-systems] nivel de jerarquía no es aplicable en enrutadores serie ACX.
Para obtener más información acerca de cómo configurar protocolos de enrutamiento y rutas estáticas, consulte Biblioteca de protocolos de enrutamiento de Junos OS.
Configurar un ID de dominio OSPF para una VPN de capa 3
En este ejemplo, se muestra cómo configurar un ID de dominio OSPF para una VPN mediante el uso de OSPF como protocolo de enrutamiento entre los enrutadores PE y CE. Las rutas desde un dominio de OSPF necesitan un ID de dominio de OSPF cuando se distribuyen en BGP como rutas VPN-IPv4 en VPN con varios dominios OSPF. En una VPN que conecta varios dominios OSPF, las rutas de un dominio pueden superponerse con las rutas de otro.
El ID de dominio que se configura en una instancia de enrutamiento identifica el dominio de OSPF y se utiliza para identificar la originación de la ruta. El ID de dominio que se configura en una política de comunidad se utiliza para establecer rutas exportadas.
Para obtener más información acerca de los IDs de dominio de OSPF y VPN de capa 3, consulte Configuración del enrutamiento entre enrutadores PE y CE en VPN de capa 3.
La Figura 2 muestra la topología de configuración de este ejemplo. Solo se proporciona la configuración del enrutador PE1. La configuración del enrutador PE2 puede ser similar a la configuración del enrutador PE1. No hay requisitos de configuración especiales para los enrutadores CE.
de dominio OSPF
Para obtener información de configuración, consulte las siguientes secciones:
- Configuración de interfaces en el enrutador PE1
- Configuración de opciones de enrutamiento en el enrutador PE1
- Configuración de protocolos en el enrutador PE1
- Configuración de opciones de política en el enrutador PE1
- Configuración de la instancia de enrutamiento en el enrutador PE1
- Resumen de configuración para el enrutador PE1
Configuración de interfaces en el enrutador PE1
Debe configurar dos interfaces para el enrutador PE1: la interfaz para el so-0/0/0 tráfico al enrutador CE1 (San Francisco) y la interfaz para el so-0/0/1 tráfico a un enrutador P en la red del proveedor de servicios.
Configure las interfaces para el enrutador PE1:
[edit]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Configuración de opciones de enrutamiento en el enrutador PE1
En el [edit routing-options] nivel de jerarquía, debe configurar las router-id instrucciones y autonomous-system . La router-id instrucción identifica el enrutador PE1.
Configure las opciones de enrutamiento para el enrutador PE1:
[edit]
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Configuración de protocolos en el enrutador PE1
En el enrutador PE1, debe configurar MPLS, BGP, OSPF y LDP en el [edit protocols] nivel jerárquico:
[edit]
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
Configuración de opciones de política en el enrutador PE1
En el enrutador PE1, debe configurar políticas en el [edit policy-options] nivel jerárquico. Estas políticas garantizan que los enrutadores CE de la VPN de capa 3 intercambian información de enrutamiento. En este ejemplo, el enrutador CE1 de San Francisco intercambia información de enrutamiento con el enrutador CE2 de Chicago.
Configure las opciones de política en el enrutador PE1:
[edit]
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [target:10.255.14.216:11 domain-id:192.0.2.1:0];
community import-target-VPN-A members target:10.255.14.224:31;
}
Configuración de la instancia de enrutamiento en el enrutador PE1
Debe configurar una instancia de enrutamiento VPN de capa 3 en el enrutador PE1. Para indicar que la instancia de enrutamiento es para una VPN de capa 3, agregue la instance-type vrf instrucción en el [edit routing-instance routing-instance-name] nivel de jerarquía.
La domain-id instrucción se configura en el [edit routing-instances routing-options protocols ospf] nivel de jerarquía. Como se muestra en la figura 2, la instancia de enrutamiento del enrutador PE2 debe compartir el mismo ID de dominio que la instancia de enrutamiento correspondiente en el enrutador PE1 para que las rutas del enrutador CE1 al enrutador CE2 y viceversa se distribuyan como LSA tipo 3. Si configura diferentes IDs de dominio de OSPF en las instancias de enrutamiento para el enrutador PE1 y el PE2 del enrutador, las rutas de cada enrutador CE se distribuirán como LSA tipo 5.
Configure la instancia de enrutamiento en el enrutador PE1:
[edit]
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Resumen de configuración para el enrutador PE1
Configurar interfaces
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.19.1.2/30;
}
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.19.2.1/30;
}
family mpls;
}
}
}
Configurar opciones de enrutamiento
routing-options {
router-id 10.255.14.216;
autonomous-system 65069;
}
Configurar protocolos
protocols {
mpls {
interface so-0/0/1.0;
}
bgp {
group San-Francisco-Chicago {
type internal;
preference 10;
local-address 10.255.14.216;
family inet-vpn {
unicast;
}
neighbor 10.255.14.224;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/1.0;
}
}
ldp {
interface so-0/0/1.0;
}
}
Configurar la política de VPN
policy-options {
policy-statement vpn-import-VPN-A {
term term1 {
from {
protocol bgp;
community import-target-VPN-A;
}
then accept;
}
term term2 {
then reject;
}
}
policy-statement vpn-export-VPN-A {
term term1 {
from protocol ospf;
then {
community add export-target-VPN-A;
accept;
}
}
term term2 {
then reject;
}
}
community export-target-VPN-A members [ target:10.255.14.216:11 domain-id:192.0.2.1:0 ];
community import-target-VPN-A members target:10.255.14.224:31;
}
Instancia de enrutamiento para VPN de capa 3
routing-instances {
VPN-A-San-Francisco-Chicago {
instance-type vrf;
interface so-0/0/0.0;
route-distinguisher 10.255.14.216:11;
vrf-import vpn-import-VPN-A;
vrf-export vpn-export-VPN-A;
routing-options {
router-id 10.255.14.216;
}
protocols {
ospf {
domain-id 192.0.2.1;
export vpn-import-VPN-A;
area 0.0.0.0 {
interface so-0/0/0.0;
}
}
}
}
}
Descripción general de vínculos simulados de OSPFv2
Puede crear un vínculo intra-área o un vínculo simulado entre dos dispositivos de enrutamiento de borde de proveedor (PE) para que se prefiera la red troncal VPN sobre el vínculo de puerta trasera. Un vínculo de puerta trasera es un vínculo de respaldo que conecta los dispositivos de borde del cliente (CE) en caso de que la red troncal VPN no esté disponible. Cuando este vínculo de copia de seguridad está disponible y los dispositivos CE se encuentran en el mismo área OSPF, el comportamiento predeterminado es preferir este vínculo de copia de seguridad en lugar de la red troncal VPN. Esto se debe a que el vínculo de copia de seguridad se considera un vínculo dentro de área, mientras que la red troncal vpn siempre se considera un vínculo entre áreas. Siempre se prefieren los vínculos entre áreas sobre los vínculos entre áreas.
El vínculo simulado es un vínculo de área intrapunto a punto no numerado entre dispositivos de PE. Cuando la red troncal VPN tiene un vínculo intra-área simulado, se puede preferir este vínculo simulado sobre el vínculo de respaldo si el vínculo falso tiene una métrica OSPF más baja que el vínculo de copia de seguridad.
El vínculo falso se anuncia mediante anuncios de estado de vínculo (LSA) tipo 1. Los vínculos simulados solo son válidos para instancias de enrutamiento y OSPFv2.
Cada vínculo simulado se identifica mediante la combinación de una dirección de punto de conexión local y una dirección de punto de conexión remoto. La Figura 3 muestra un vínculo simulado OSPFv2. El enrutador CE1 y el enrutador CE2 se encuentran en el mismo área OSPFv2. Estos dispositivos de enrutamiento de borde de cliente (CE) están vinculados entre sí por una VPN de capa 3 a través del enrutador PE1 y el enrutador PE2. Además, los enrutadores CE1 y CE2 están conectados mediante un vínculo intra-área que se utiliza como respaldo.
OSPFv2
OSPFv2 trata el vínculo a través de la VPN de capa 3 como un vínculo entre áreas. De forma predeterminada, OSPFv2 prefiere los vínculos entre áreas a los vínculos entre áreas, por lo que OSPFv2 selecciona el vínculo de intraarea de respaldo como la ruta activa. Esto no es aceptable en una configuración en la que el vínculo dentro del área no es la ruta principal esperada para el tráfico entre los dispositivos de enrutamiento CE. Puede configurar la métrica para el vínculo simulado para asegurarse de que se prefiera la ruta a través de la VPN de capa 3 a una ruta de respaldo a través de un vínculo dentro del área que conecta los dispositivos de enrutamiento CE.
Para el punto de conexión remoto, puede configurar la interfaz OSPFv2 como un circuito de demanda, configurar la autenticación IPsec (se configura la autenticación IPsec real por separado) y definir el valor de la métrica.
Debe configurar un vínculo OSPFv2 simulado en las siguientes circunstancias:
Dos dispositivos de enrutamiento CE están vinculados entre sí por una VPN de capa 3.
Estos dispositivos de enrutamiento CE se encuentran en el mismo área OSPFv2.
Se configura un vínculo dentro del área entre los dos dispositivos de enrutamiento CE.
Si no hay ningún vínculo dentro del área entre los dispositivos de enrutamiento CE, no es necesario configurar un vínculo simulado OSPFv2.
En la versión 9.6 y posteriores de Junos OS OS, se instala un vínculo simulado OSPFv2 en la tabla de enrutamiento como una ruta oculta. Además, no se exporta una ruta BGP a OSPFv2 si hay disponible un vínculo simulado de OSPF correspondiente.
En junos OS versión 16.1 y posteriores, los vínculos simulados de OSPF se admiten en instancias predeterminadas. El costo del enlace simulado se establece dinámicamente en la métrica aigp de la ruta del BGP si el usuario no configura ninguna métrica en el vínculo simulado. Si la métrica aigp no está presente en la ruta del BGP, el costo del enlace simulado predeterminado a 1.
Ejemplo: Configuración de vínculos OSPFv2 Sham
En este ejemplo, se muestra cómo habilitar vínculos simulados OSPFv2 en un dispositivo de enrutamiento de PE.
Requisitos
No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar este ejemplo.
Visión general
El enlace simulado es un vínculo intra-área de punto a punto no numerado y se anuncia mediante un anuncio de estado de enlace tipo 1 (LSA). Los vínculos simulados solo son válidos para instancias de enrutamiento y OSPFv2.
Cada vínculo simulado se identifica mediante una combinación de la dirección del punto de conexión local y una dirección de punto de conexión remoto y el área OSPFv2 a la que pertenece. Puede configurar manualmente el vínculo simulado entre dos dispositivos de PE, ambos dentro de la misma instancia de enrutamiento de enrutamiento y reenvío (VRF) vpn, y especificar la dirección para el punto final local del vínculo simulado. Esta dirección se utiliza como origen de los paquetes de vínculo simulados y también la utiliza el dispositivo de enrutamiento de PE remoto como punto de final remoto de vínculo simulado. También puede incluir la opción opcional metric para establecer un valor de métrica para el punto de final remoto. El valor de la métrica especifica el costo de usar el vínculo. Se prefieren las rutas con métricas de ruta total más bajas que las que tienen métricas de ruta más altas.
Para habilitar vínculos simulados OSPFv2 en un dispositivo de enrutamiento de PE:
Configure una interfaz de circuito cerrado adicional en el dispositivo de enrutamiento de PE.
Configure la instancia de enrutamiento VRF que admite VPN de capa 3 en el dispositivo de enrutamiento de PE y asocie el vínculo simulado con un área OSPF existente. La configuración del vínculo simulado OSPFv2 también se incluye en la instancia de enrutamiento. Configure la dirección del punto de conexión local del vínculo simulado, que es la dirección de circuito cerrado de la VPN local, y la dirección del punto de conexión remoto, que es la dirección de circuito cerrado de la VPN remota. En este ejemplo, la instancia de enrutamiento VRF se denomina roja.
La Figura 4 muestra un vínculo simulado OSPFv2.
Topología
de vínculo simulado OSPFv2
Los dispositivos de la figura representan las siguientes funciones:
CE1 y CE2 son los dispositivos de borde del cliente.
PE1 y PE2 son los dispositivos de borde del proveedor.
P es el dispositivo proveedor.
La configuración rápida de CLI muestra la configuración de todos los dispositivos en la Figura 4. La sección Procedimiento paso a paso describe los pasos en el dispositivo PE1.
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
CE1
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.1/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.0.0.17/30 set interfaces lo0 unit 0 family inet address 192.0.2.1/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.1 set routing-options autonomous-system 1
PE1
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.2/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.5/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.2/24 set interfaces lo0 unit 1 family inet address 198.51.100.2/24 set protocols mpls interface fe-1/2/1.0 set protocols bgp group toR4 type internal set protocols bgp group toR4 local-address 192.0.2.2 set protocols bgp group toR4 family inet-vpn unicast set protocols bgp group toR4 neighbor 192.0.2.4 set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ldp interface fe-1/2/1.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/0.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.2 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.2 set routing-options autonomous-system 2
P
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.6/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.9/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 3 family inet address 192.0.2.3/24 set protocols mpls interface all set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface all set protocols ldp interface all set routing-options router-id 192.0.2.3
PE2
set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.10/30 set interfaces fe-1/2/0 unit 0 family mpls set interfaces fe-1/2/1 unit 0 family inet address 10.1.1.13/30 set interfaces fe-1/2/1 unit 0 family mpls set interfaces lo0 unit 0 family inet address 192.0.2.4/32 set interfaces lo0 unit 1 family inet address 198.51.100.4/32 set protocols mpls interface fe-1/2/0.0 set protocols bgp group toR2 type internal set protocols bgp group toR2 local-address 192.0.2.4 set protocols bgp group toR2 family inet-vpn unicast set protocols bgp group toR2 neighbor 192.0.2.2 set protocols ospf area 0.0.0.0 interface lo0.0 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 set protocols ldp interface fe-1/2/0.0 set protocols ldp interface lo0.0 set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp set policy-options policy-statement bgp-to-ospf term 1 then accept set policy-options policy-statement bgp-to-ospf term 2 then reject set routing-instances red instance-type vrf set routing-instances red interface fe-1/2/1.0 set routing-instances red interface lo0.1 set routing-instances red route-distinguisher 2:1 set routing-instances red vrf-target target:2:1 set routing-instances red protocols ospf export bgp-to-ospf set routing-instances red protocols ospf sham-link local 198.51.100.4 set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.2 metric 10 set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0 set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1 set routing-options router-id 192.0.2.4 set routing-options autonomous-system 2
CE2
set interfaces fe-1/2/0 unit 14 family inet address 10.1.1.14/30 set interfaces fe-1/2/0 unit 14 family mpls set interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30 set interfaces lo0 unit 5 family inet address 192.0.2.5/24 set protocols ospf area 0.0.0.0 interface fe-1/2/0.14 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-1/2/0.18 set policy-options policy-statement send-direct from protocol direct set policy-options policy-statement send-direct then accept set routing-options router-id 192.0.2.5 set routing-options autonomous-system 3
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Modificación de la configuración de Junos OS en la Guía del usuario de CLI.
Para configurar vínculos OSPFv2 sham en cada dispositivo PE:
-
Configure las interfaces, incluidas dos interfaces de circuito cerrado.
[edit interfaces] user@PE1# set fe-1/2/0 unit 0 family inet address 10.1.1.2/30 user@PE1# set fe-1/2/0 unit 0 family mpls user@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30 user@PE1# set fe-1/2/1 unit 0 family mpls user@PE1# set lo0 unit 0 family inet address 192.0.2.2/24 user@PE1# set lo0 unit 1 family inet address 198.51.100.2/24
-
Configure MPLS en la interfaz de núcleo.
[edit protocols mpls] user@PE1# set interface fe-1/2/1.0
-
Configure el BGP interno (IBGP).
[edit ] user@PE1# set protocols bgp group toR4 type internal user@PE1# set protocols bgp group toR4 local-address 192.0.2.2 user@PE1# set protocols bgp group toR4 family inet-vpn unicast user@PE1# set protocols bgp group toR4 neighbor 192.0.2.4
-
Configure OSPF en la interfaz de núcleo y en la interfaz de circuito cerrado que se utiliza en la instancia principal.
[edit protocols ospf area 0.0.0.0] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0 passive
-
Configure LDP o RSVP en la interfaz de núcleo y en la interfaz de circuito cerrado que se utiliza en la instancia principal.
[edit protocols ldp] user@PE1# set interface fe-1/2/1.0 user@PE1# set interface lo0.0
-
Configure una política de enrutamiento para su uso en la instancia de enrutamiento.
[edit policy-options policy-statement bgp-to-ospf] user@PE1# set term 1 from protocol bgp user@PE1# set term 1 then accept user@PE1# set term 2 then reject
-
Configure la instancia de enrutamiento.
[edit routing-instances red] user@PE1# set instance-type vrf user@PE1# set interface fe-1/2/0.0 user@PE1# set route-distinguisher 2:1 user@PE1# set vrf-target target:2:1 user@PE1# set protocols ospf export bgp-to-ospf user@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
-
Configure el vínculo simulado OSPFv2.
Incluya la interfaz de circuito cerrado adicional en la instancia de enrutamiento y también en la configuración del OSPF.
Observe que la métrica en la interfaz de enlace simulado está establecida en 10. En el vínculo OSPF de respaldo del dispositivo CE1, la métrica se establece en 100. Esto hace que el vínculo falso sea el vínculo preferido.
[edit routing-instances red] user@PE1# set interface lo0.1 user@PE1# set protocols ospf sham-link local 198.51.100.2 user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10 user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
-
Configure el número de sistema autónomo (AS) y el ID del enrutador.
[edit routing-options] user@PE1# set router-id 192.0.2.2 user@PE1# set autonomous-system 2
-
Si ha terminado de configurar el dispositivo, confirme la configuración.
[edit] user@R1# commit
Resultados
Confirme su configuración ingresando los show interfaces comandos y. show routing-instances Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
Salida para PE1:
user@PE1# show interfaces
fe-1/2/0 {
unit 0{
family inet {
address 10.1.1.2/30;
}
family mpls;
}
}
fe-1/2/1 {
unit 0 {
family inet {
address 10.1.1.5/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 192.0.2.2/24;
}
}
unit 1 {
family inet {
address 198.51.100.2/24;
}
}
}
user@PE1# show protocols
mpls {
interface fe-1/2/1.0;
}
bgp {
group toR4 {
type internal;
local-address 192.0.2.2;
family inet-vpn {
unicast;
}
neighbor 192.0.2.4;
}
}
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0;
interface lo0.0 {
passive;
}
}
}
ldp {
interface fe-1/2/1.0;
interface lo0.0;
}
user@PE1# show policy-options
policy-statement bgp-to-ospf {
term 1 {
from protocol bgp;
then accept;
}
term 2 {
then reject;
}
}
user@PE1# show routing-instances
red {
instance-type vrf;
interface fe-1/2/0.0;
interface lo0.1;
route-distinguisher 2:1;
vrf-target target:2:1;
protocols {
ospf {
export bgp-to-ospf;
sham-link local 198.51.100.2;
area 0.0.0.0 {
sham-link-remote 198.51.100.4 metric 10;
interface fe-1/2/0.0;
interface lo0.1;
}
}
}
}
user@PE1# show routing-options router-id 192.0.2.2; autonomous-system 2;
Verificación
Confirme que la configuración funciona correctamente.
- Verificar las interfaces de vínculo simulado
- Verificar los puntos de final locales y remotos del vínculo de Sham
- Verificar las adyacencias de enlace simuladas
- Verificar el anuncio de estado de vínculo
- Verificación de la selección de ruta
Verificar las interfaces de vínculo simulado
Propósito
Verifique la interfaz de enlace simulada. El vínculo simulado se trata como una interfaz en OSPFv2, con el nombre mostrado como shamlink.<unique identifier>, donde el identificador único es un número. Por ejemplo, shamlink.0. El vínculo simulado aparece como una interfaz de punto a punto.
Acción
Desde el modo operativo, ingrese el show ospf interface instance instance-name comando.
user@PE1> show ospf interface instance red Interface State Area DR ID BDR ID Nbrs lo0.1 DR 0.0.0.0 198.51.100.2 0.0.0.0 0 fe-1/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Verificar los puntos de final locales y remotos del vínculo de Sham
Propósito
Verifique los puntos de final locales y remotos del vínculo simulado. La MTU para la interfaz de vínculo simulado siempre es cero.
Acción
Desde el modo operativo, ingrese el show ospf interface instance instance-name detail comando.
user@PE1> show ospf interface shamlink.0 instance red Interface State Area DR ID BDR ID Nbrs shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 0, Cost: 10 Local: 198.51.100.2, Remote: 198.51.100.4 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None, No eligible backup Topology default (ID 0) -> Cost: 10
Verificar las adyacencias de enlace simuladas
Propósito
Compruebe las adyacencias entre los vínculos simulados configurados.
Acción
Desde el modo operativo, ingrese el show ospf neighbor instance instance-name comando.
user@PE1> show ospf neighbor instance red Address Interface State ID Pri Dead 10.1.1.1 fe-1/2/0.0 Full 192.0.2.1 128 35 198.51.100.4 shamlink.0 Full 198.51.100.4 0 31
Verificar el anuncio de estado de vínculo
Propósito
Compruebe que el LSA del enrutador originado por la instancia lleva la adyacencia del vínculo simulado como un vínculo de punto a punto sin numerar. Los datos de los vínculos simulado son varios que van desde el 0x80010000 hasta el 0x8001ffff.
Acción
Desde el modo operativo, ingrese el show ospf database instance instance-name comando.
user@PE1> show ospf database instance red
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 192.0.2.1 192.0.2.1 0x80000009 1803 0x22 0x6ec7 72
Router 192.0.2.5 192.0.2.5 0x80000007 70 0x22 0x2746 72
Router *198.51.100.2 198.51.100.2 0x80000006 55 0x22 0xda6b 60
Router 198.51.100.4 198.51.100.4 0x80000005 63 0x22 0xb19 60
Network 10.0.0.18 192.0.2.5 0x80000002 70 0x22 0x9a71 32
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 198.51.100.2 198.51.100.4 0x80000002 72 0xa2 0x343 36
Extern *198.51.100.4 198.51.100.2 0x80000002 71 0xa2 0xe263 36
Verificación de la selección de ruta
Propósito
Compruebe que se utiliza la ruta VPN de capa 3 en lugar de la ruta de copia de seguridad.
Acción
Desde el modo operativo, ingrese el traceroute comando del dispositivo CE1 al dispositivo CE2.
user@CE1> traceroute 192.0.2.5
traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets
1 10.1.1.2 (10.1.1.2) 1.930 ms 1.664 ms 1.643 ms
2 * * *
3 10.1.1.10 (10.1.1.10) 2.485 ms 1.435 ms 1.422 ms
MPLS Label=299808 CoS=0 TTL=1 S=1
4 192.0.2.5 (192.0.2.5) 1.347 ms 1.362 ms 1.329 ms
Significado
La operación traceroute muestra que la VPN de capa 3 es la ruta preferida. Si eliminara el vínculo simulado o modificara la métrica OSPF para preferir esa ruta de copia de seguridad, el traceroute mostraría que se prefiere la ruta de copia de seguridad.
Configurar sesiones multihop de EBGP entre enrutadores PE y CE en VPN de capa 3
Puede configurar una sesión multihop de EBGP o IBGP entre los enrutadores PE y CE de una VPN de capa 3. Esto le permite tener uno o más enrutadores entre los enrutadores PE y CE. El uso de IBGP entre enrutadores PE y CE no requiere la configuración de ninguna instrucción adicional. Sin embargo, el uso de EBGP entre los enrutadores PE y CE requiere la configuración de la multihop instrucción.
Para configurar una sesión multihop de BGP externa para la conexión entre los enrutadores PE y CE, incluya la multihop instrucción en el enrutador de PE. Para ayudar a evitar los bucles de enrutamiento, debe configurar un valor de tiempo de duración (TTL) para la sesión de varios cables:
multihop ttl-value;
Para obtener la lista de niveles de jerarquía en los que puede configurar esta instrucción, consulte la sección resumen de esta instrucción.
Configuración de una topología VPN LDP-over-RSVP
En este ejemplo, se muestra cómo configurar una topología VPN en la que los paquetes LDP se tunelan a través de un LSP RSVP. Esta configuración consta de los siguientes componentes (véase la figura 5):
Una VPN (VPN-A)
Dos enrutadores PE
LDP como el protocolo de señalización entre los enrutadores de PE y sus enrutadores P adyacentes
Un LSP RSVP entre dos de los enrutadores P sobre los cuales se tunelizó el LDP
VPN LDP-over-RSVP
Los pasos siguientes describen cómo se establece esta topología y cómo se envían los paquetes desde el enrutador CE2 al enrutador CE CE1:
Los enrutadores P1 y P3 establecen LSP RSVP entre sí e instalan sus direcciones de circuito cerrado en sus tablas de enrutamiento inet.3.
El enrutador PE PE1 establece una sesión LDP con el enrutador P1 sobre interfaz
so-1/0/0.0.El enrutador P1 establece una sesión LDP con la dirección de circuito cerrado del enrutador P3, la cual es accesible mediante el LSP RSVP.
El enrutador P1 envía sus enlaces de etiqueta, que incluyen una etiqueta para llegar al enrutador PE1, al enrutador P3. Estos enlaces de etiquetas permiten que el enrutador P3 dirija paquetes LDP al enrutador PE1.
El enrutador P3 establece una sesión de LDP con el enrutador PE2 a través de la interfaz
so0-0/0/0.0y establece una sesión de LDP con la dirección de circuito cerrado del enrutador P1.El enrutador P3 envía sus enlaces de etiqueta, que incluyen una etiqueta para llegar al enrutador PE2, al enrutador P1. Estos enlaces de etiquetas permiten que el enrutador P1 dirija paquetes LDP a la dirección de circuito cerrado del enrutador PE2.
Los enrutadores PE1 y PE2 establecen sesiones de IBGP entre sí.
Cuando el enrutador PE1 anuncia al enrutador PE2 las rutas que aprendió del enrutador CE1, incluye su etiqueta VPN. (El enrutador PE crea la etiqueta VPN y la vincula a la interfaz entre los enrutadores PE y CE.) De manera similar, cuando el enrutador PE2 anuncia rutas que aprendió del enrutador CE2, envía su etiqueta de VPN al enrutador PE1.
Cuando el enrutador PE2 desea reenviar un paquete al enrutador CE1, empuja dos etiquetas en la pila de etiquetas del paquete: primero la etiqueta VPN que está enlazada a la interfaz entre el enrutador PE1 y el enrutador CE1, luego la etiqueta LDP utilizada para llegar al enrutador PE1. Luego, reenvía los paquetes al enrutador P3 a través de la interfaz so-0/0/1.0.
Cuando el enrutador P3 recibe los paquetes del enrutador PE2, cambia la etiqueta LDP que está en la parte superior de la pila (según su base de datos LDP) y también inserta una etiqueta RSVP en la parte superior de la pila para que el paquete ahora pueda ser conmutado por el LSP RSVP. En este punto, hay tres etiquetas en la pila: la etiqueta interna (inferior) es la etiqueta VPN, el medio es la etiqueta LDP y la externa (superior) es la etiqueta RSVP.
El enrutador P2 recibe el paquete y lo cambia al enrutador P1 intercambiando la etiqueta RSVP. En esta topología, dado que el enrutador P2 es el penúltimo salto del LSP, abre la etiqueta RSVP y reenvía el paquete a través de la interfaz
so-1/1/0.0al enrutador P1. En este punto, hay dos etiquetas en la pila: la etiqueta interna es la etiqueta VPN y la externa es la etiqueta LDP.Cuando el enrutador P1 recibe el paquete, extrae la etiqueta externa (la etiqueta LDP) y reenvía el paquete al enrutador PE1 mediante la interfaz
so-1/0/0.0. En esta topología, el enrutador PE1 es el enrutador LDP de salida, por lo que el enrutador P1 abre la etiqueta LDP en lugar de intercambiarla con otra etiqueta. En este punto, solo hay una etiqueta en la pila, la etiqueta VPN.Cuando el enrutador PE1 recibe el paquete, abre la etiqueta vpn y lo reenvía como paquete IPv4 al enrutador CE1 a través de la interfaz
ge-1/1/0.0.
Se produce un conjunto similar de operaciones para los paquetes enviados desde el enrutador CE1 que están destinados al enrutador CE2.
La siguiente lista explica cómo, en el caso de los paquetes que se envían desde el enrutador CE2 al enrutador CE1, los distintos enrutadores anuncian las etiquetas LDP, RSVP y VPN. Estos pasos incluyen ejemplos de valores de etiqueta (ilustrados en la figura 6).
Etiquetas LDP
El enrutador PE1 anuncia la etiqueta LDP 3 para el enrutador P1.
El enrutador P1 anuncia la etiqueta LDP 100,001 para el enrutador PE1 al enrutador P3.
El enrutador P3 anuncia la etiqueta LDP 100,002 para el enrutador PE1 al enrutador PE2.
Etiquetas RSVP
El enrutador P1 anuncia la etiqueta RSVP 3 al enrutador P2.
El enrutador P2 anuncia la etiqueta RSVP 100 003 al enrutador P3.
Etiqueta DE VPN
El enrutador PE1 anuncia la etiqueta de VPN 100 004 al enrutador PE2 para la ruta del enrutador CE1 al enrutador CE2.
de etiquetas
Para un paquete enviado desde el host B en la Figura 6 al host A, los encabezados y las etiquetas del paquete cambian a medida que el paquete viaja a su destino:
El paquete que se origina en el host B tiene una dirección de origen de B y una dirección de destino de A en su encabezado.
El enrutador CE2 agrega al paquete un siguiente salto de interfaz
so-1/0/0.El enrutador PE2 intercambia el siguiente salto de interfaz
so-1/0/0y lo reemplaza con un siguiente salto de PE1. También agrega dos etiquetas para llegar al enrutador PE1, primero la etiqueta vpn (100 004) y luego la etiqueta LDP (100 002). La etiqueta VPN es, por lo tanto, la etiqueta interna (inferior) en la pila, y la etiqueta LDP es la etiqueta externa.El enrutador P3 intercambia la etiqueta LDP agregada por el enrutador PE2 (100 002) y la reemplaza con su etiqueta LDP para llegar al enrutador PE1 (100 001). También agrega la etiqueta RSVP para llegar al enrutador P2 (100 003).
El enrutador P2 elimina la etiqueta RSVP (100 003) porque es el penúltimo salto en el LSP MPLS.
El enrutador P1 elimina la etiqueta LDP (100,001) porque es el penúltimo enrutador LDP. También intercambia el siguiente salto de PE1 y lo reemplaza con la interfaz del siguiente salto,
so-1/0/0.El enrutador PE1 elimina la etiqueta de VPN (100 004). También intercambia la interfaz del próximo salto y la reemplaza por su interfaz de
so-1/0/0salto siguiente,ge-1/1/0.El enrutador CE1 elimina la interfaz del salto siguiente de
ge-1/1/0, y el encabezado del paquete ahora contiene solo una dirección de origen de B y una dirección de destino de A.
La sección final de este ejemplo consolida las instrucciones necesarias para configurar la funcionalidad de VPN en cada uno de los enrutadores P de servicio que se muestran en la figura 5.
En este ejemplo, se utiliza un número de AS privado para el distinguidor de ruta y el destino de la ruta. Este número se utiliza solo para la ilustración. Cuando configure VPN, debe usar un número de AS asignado.
En las siguientes secciones se explica cómo configurar la funcionalidad de VPN en los enrutadores PE y P. Los enrutadores CE no tienen ninguna información sobre la VPN, por lo que los configura con normalidad.
- Habilitación de un IGP en los enrutadores PE y P
- Habilitación de LDP en los enrutadores PE y P
- Habilitación de RSVP y MPLS en el enrutador P
- Configuración del túnel LSP MPLS entre los enrutadores P
- Configuración del IBGP en los enrutadores de PE
- Configuración de instancias de enrutamiento para VPN en los enrutadores de PE
- Configuración de la política de VPN en los enrutadores de PE
- Configuración de VPN LDP-over-RSVP resumido por enrutador
Habilitación de un IGP en los enrutadores PE y P
Para permitir que los enrutadores PE y P intercambien información de enrutamiento entre ellos, debe configurar un IGP en todos estos enrutadores o debe configurar rutas estáticas. Configure el IGP en la instancia principal del proceso de protocolo de enrutamiento (rpd) (es decir, en el [edit protocols] nivel de jerarquía), no en la instancia de enrutamiento VPN (es decir, no en el [edit routing-instances] nivel de jerarquía).
Puede configurar el IGP de manera estándar. Este ejemplo de configuración no incluye esta parte de la configuración.
Habilitación de LDP en los enrutadores PE y P
En este ejemplo de configuración, el LDP es el protocolo de señalización entre los enrutadores pe. Para que la VPN funcione, debe configurar LDP en los dos enrutadores de PE y en los enrutadores P que están conectados a los enrutadores de PE. Debe configurar LDP solo en las interfaces del núcleo de la red del proveedor de servicios; es decir, entre los enrutadores PE y P y entre los enrutadores P. No es necesario configurar LDP en la interfaz entre los enrutadores PE y CE.
En este ejemplo de configuración, se configura LDP en las interfaces de circuito cerrado de los enrutadores P, ya que estas son las interfaces en las que está configurado el LSP MPLS.
En los enrutadores de PE, también debe configurar family inet al configurar la interfaz lógica.
En el enrutador PE1, configure LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
}
[edit interfaces]
so-1/0/0 {
unit 0 {
family mpls;
}
}
En el enrutador PE2, configure LDP:
[edit protocols]
ldp {
interface so-0/0/0.0;
}
[edit interfaces]
so-0/0/1 {
unit 0 {
family mpls;
}
}
En el enrutador P1, configure LDP:
[edit protocols]
ldp {
interface so-1/0/0.0;
interface lo0;
}
En el enrutador P3, configure LDP:
[edit protocols]
ldp {
interface lo0;
interface so-0/0/0.0;
}
En el enrutador P2, aunque no es necesario configurar LDP, opcionalmente puede configurarlo para que proporcione una ruta LDP de reserva en caso de que el LSP RSVP no funcione:
[edit protocols]
ldp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Habilitación de RSVP y MPLS en el enrutador P
En el enrutador P2, debe configurar RSVP y MPLS porque este enrutador existe en la ruta LSP MPLS entre los enrutadores P1 y P3:
[edit]
protocols {
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
}
Configuración del túnel LSP MPLS entre los enrutadores P
En este ejemplo de configuración, el LDP se tunelizó a través de un LSP RSVP. Por lo tanto, además de configurar RSVP, debe habilitar la compatibilidad con ingeniería de tráfico en un IGP y debe crear un LSP MPLS para tunelización del tráfico LDP.
En el enrutador P1, habilite RSVP y configure un extremo del túnel LSP MPLS. En este ejemplo, la compatibilidad con ingeniería de tráfico está habilitada para OSPF y se configura MPLS en las interfaces con el LSP y el enrutador PE1. En la to instrucción, especifique la dirección de circuito cerrado del enrutador P3.
[edit]
protocols {
rsvp {
interface so-1/0/1.0;
}
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
}
En el enrutador P3, habilite RSVP y configure el otro extremo del túnel LSP MPLS. Una vez más, la compatibilidad con ingeniería de tráfico está habilitada para OSPF, y usted configura MPLS en las interfaces al LSP y al enrutador PE2. En la to instrucción, especifique la dirección de circuito cerrado del enrutador P1.
[edit]
protocols {
rsvp {
interface at-2/0/1.0;
}
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface so-0/0/0.0;
}
}
}
Configuración del IBGP en los enrutadores de PE
En los enrutadores de PE, configure una sesión de IBGP con las siguientes propiedades:
Familia VPN: para indicar que la sesión del IBGP es para la VPN, incluya la
family inet-vpninstrucción.Dirección de circuito cerrado :incluye la
local-addressinstrucción, que especifica la dirección de circuito cerrado del enrutador de PE local. La sesión del IBGP para VPN se ejecuta a través de la dirección de circuito cerrado. También debe configurar lalo0interfaz en el[edit interfaces]nivel de jerarquía. El ejemplo no incluye esta parte de la configuración del enrutador.Dirección de vecino(vecino): incluye la
neighborinstrucción, que especifica la dirección IP del enrutador de PE vecino, que es su dirección de circuito cerrado (lo0).
En el enrutador PE1, configure el IBGP:
[edit]
protocols {
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.200.2;
}
}
}
En el enrutador PE2, configure el IBGP:
[edit]
protocols {
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
}
Configuración de instancias de enrutamiento para VPN en los enrutadores de PE
Ambos enrutadores pes ofrecen VPN-A, por lo que debe configurar una instancia de enrutamiento en cada enrutador para la VPN en la que se defina lo siguiente:
Distinguidor de ruta, que debe ser único para cada instancia de enrutamiento en el enrutador de PE. Se utiliza para distinguir las direcciones de una VPN de las de otra VPN.
Tipo de instancia de
vrf, que crea la tabla VRF en el enrutador de PE.Interfaces conectadas a los enrutadores CE.
Las políticas de importación y exportación de VRF, que deben ser las mismas en cada enrutador de PE que abaste a la misma VPN. A menos que la política de importación contenga solo una
then rejectinstrucción, debe incluir referencia a una comunidad. De lo contrario, cuando intenta confirmar la configuración, se produce un error.Nota:En este ejemplo, se utiliza un número de AS privado para el distinguidor de ruta. Este número se utiliza solo para la ilustración. Cuando configure VPN, debe usar un número de AS asignado.
Enrutamiento entre los enrutadores PE y CE, que es necesario para que el enrutador de PE distribuya rutas relacionadas con VPN hacia y desde enrutadores CE conectados. Puede configurar un protocolo de enrutamiento (BGP, OSPF o RIP) o puede configurar el enrutamiento estático.
En el enrutador PE1, configure la siguiente instancia de enrutamiento para VPN-A. En este ejemplo, el enrutador PE1 usa RIP para distribuir rutas hacia y desde el enrutador CE al que está conectado.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
}
}
En el enrutador PE2, configure la siguiente instancia de enrutamiento para VPN-A. En este ejemplo, el enrutador PE2 usa OSPF para distribuir rutas hacia y desde el enrutador CE al que está conectado.
[edit]
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
}
}
Configuración de la política de VPN en los enrutadores de PE
Debe configurar las políticas de importación y exportación de VPN en cada uno de los enrutadores de PE para que instalen las rutas adecuadas en sus tablas VRF, que utilizan para reenviar paquetes dentro de una VPN. Para VPN-A, la tabla VRF es VPN-A.inet.0.
En la política de VPN, también se configuran las comunidades de destino de VPN.
En este ejemplo, se utiliza un número de AS privado para el destino de la ruta. Este número se utiliza solo para la ilustración. Cuando configure VPN, debe usar un número de AS asignado.
En el enrutador PE1, configure las siguientes políticas de importación y exportación de VPN:
Los calificadores de políticas que se muestran en este ejemplo son solo los necesarios para que la VPN funcione. Puede configurar calificadores adicionales, según sea necesario, en cualquier política que configure.
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
En el enrutador PE2, configure las siguientes políticas de importación y exportación de VPN:
[edit]
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Para aplicar las políticas de VPN en los enrutadores, incluya las vrf-export instrucciones y vrf-import cuando configure la instancia de enrutamiento en los enrutadores de PE. Las políticas de importación y exportación de VRF manejan la distribución de ruta en la sesión de IBGP que se ejecuta entre los enrutadores de PE.
Configuración de VPN LDP-over-RSVP resumido por enrutador
Enrutador PE1
Instancia de enrutamiento para VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface ge-1/0/0.0;
route-distinguisher 65535:0;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Protocolo de enrutamiento de instancia
protocols {
rip {
group PE1-to-CE1 {
neighbor ge-1/0/0.0;
}
}
}
Interfaces
interfaces {
so-1/0/0 {
unit 0 {
family mpls;
}
}
ge-1/0/0 {
unit 0;
}
}
Instancia de protocolo principal
protocols {
}
Habilitar LDP
ldp {
interface so-1/0/0.0;
}
Habilitar MPLS
mpls {
interface so-1/0/0.0;
interface ge-1/0/0.0;
}
Configurar EL IBGP
bgp {
group PE1-to-PE2 {
type internal;
local-address 10.255.1.1;
family inet-vpn {
unicast;
}
neighbor 10.255.100.1;
}
}
Configurar la política de VPN
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol rip;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:00;
}
Enrutador P1
Instancia de protocolo principal
protocols {
}
Habilitar RSVP
rsvp {
interface so-1/0/1.0;
}
Habilitar LDP
ldp {
interface so-1/0/0.0;
interface lo0.0;
}
Habilitar MPLS
mpls {
label-switched-path P1-to-P3 {
to 10.255.100.1;
ldp-tunneling;
}
interface so-1/0/0.0;
interface so-1/0/1.0;
}
Configurar OSPF para el soporte de ingeniería de tráfico
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-1/0/0.0;
interface so-1/0/1.0;
}
}
Enrutador P2
Instancia de protocolo principal
protocols {
}
Habilitar RSVP
rsvp {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Habilitar MPLS
mpls {
interface so-1/1/0.0;
interface at-2/0/0.0;
}
Enrutador P3
Instancia de protocolo principal
protocols {
}
Habilitar RSVP
rsvp {
interface at-2/0/1.0;
}
Habilitar LDP
ldp {
interface so-0/0/0.0;
interface lo0.0;
}
Habilitar MPLS
mpls {
label-switched-path P3-to-P1 {
to 10.255.2.2;
ldp-tunneling;
}
interface at-2/0/1.0;
interface so-0/0/0.0;
}
Configurar OSPF para el soporte de ingeniería de tráfico
ospf {
traffic-engineering;
area 0.0.0.0 {
interface at-2/0/1.0;
interface at-2/0/1.0;
}
}
Enrutador PE2
Instancia de enrutamiento para VPN-A
routing-instance {
VPN-A {
instance-type vrf;
interface so-1/2/0.0;
route-distinguisher 65535:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
}
}
Protocolo de enrutamiento de instancia
protocols {
ospf {
area 0.0.0.0 {
interface so-1/2/0.0;
}
}
}
Interfaces
interfaces {
so-0/0/0 {
unit 0 {
family mpls;
}
}
so-1/2/0 {
unit 0;
}
}
Instancia de protocolo principal
protocols {
}
Habilitar LDP
ldp {
interface so-0/0/0.0;
}
Habilitar MPLS
mpls {
interface so-0/0/0.0;
interface so-1/2/0.0;
}
Configurar EL IBGP
bgp {
group PE2-to-PE1 {
type internal;
local-address 10.255.200.2;
family inet-vpn {
unicast;
}
neighbor 10.255.1.1;
}
}
Configurar la política de VPN
policy-options {
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement VPN-A-export {
term a {
from protocol ospf;
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
community VPN-A members target:65535:01;
}
Configuración de una topología VPN de capa 3 basada en aplicaciones
En este ejemplo, se muestra un mecanismo basado en aplicaciones para reenviar tráfico a una VPN de capa 3. Por lo general, una o más interfaces se asocian con una VPN o están vinculadas a una VPN al incluirlas en la configuración de la instancia de enrutamiento VPN. Al enlazar la interfaz a la VPN, la tabla VRF de la VPN se utiliza para tomar decisiones de reenvío para cualquier tráfico entrante en esa interfaz. El enlace de la interfaz también incluye las rutas locales de la interfaz en la tabla VRF, que proporciona la resolución del salto siguiente para rutas VRF.
En este ejemplo, se utiliza un filtro de firewall para definir qué tráfico entrante de una interfaz se reenvía mediante la tabla de enrutamiento estándar, inet.0, y qué tráfico entrante se reenvía mediante la tabla VRF. Puede expandir este ejemplo de tal manera que el tráfico entrante de una interfaz se pueda redirigir a una o más VPN. Por ejemplo, puede definir una configuración para admitir una VPN que reenvíe tráfico basado en la dirección de origen, que reenvíe tráfico del Protocolo de transferencia de hipertexto (HTTP) o que reenvíe solo medios de transmisión.
Para que esta configuración funcione, se deben cumplir las siguientes condiciones:
Las interfaces que utilizan el reenvío basado en filtros no se deben vincular a la VPN.
El enrutamiento estático se debe utilizar como medio de enrutamiento.
Debe definir un grupo de tabla de enrutamiento de interfaz compartido entre inet.0 y las tablas VRF para proporcionar rutas locales a la tabla VRF.
Este ejemplo consta de dos hosts de cliente (cliente D y cliente E) que se encuentran en dos VPN diferentes y que quieren enviar tráfico tanto dentro de la VPN como a Internet. Las rutas se definen de la siguiente manera:
El cliente A envía tráfico al cliente E a través de VPN A con una ruta de retorno que también usa VPN A (mediante la tabla VRF de la VPN).
El cliente B envía tráfico al cliente D a través de VPN B con una ruta de retorno que utiliza enrutamiento estándar basado en destino (mediante la tabla de enrutamiento inet.0).
Los clientes B y C envían tráfico a Internet mediante enrutamiento estándar (mediante la tabla de enrutamiento inet.0), con una ruta de retorno que también utiliza enrutamiento estándar.
En este ejemplo, se muestra que hay una gran variedad de opciones para configurar una topología VPN de capa 3 basada en aplicaciones. Esta flexibilidad se aplica a muchas implementaciones de red que requieren que se reenvíe tráfico específico en un entorno de enrutamiento restringido.
En este ejemplo de configuración, se muestran solo las partes de la configuración para el reenvío basado en filtros, las instancias de enrutamiento y la política. No se muestra cómo configurar una VPN de capa 3.
La Figura 7 muestra la topología de red utilizada en este ejemplo.
Configuración en el enrutador A
En el enrutador A, configure la interfaz a los clientes A, B y C. La configuración evalúa el tráfico entrante para determinar si se va a reenviar mediante VPN o enrutamiento estándar basado en destino.
En primer lugar, se aplica un filtro de entrada y se configura la interfaz:
[edit]
interfaces {
fe-1/1/0 {
unit 0 {
family inet {
filter {
input fbf-vrf;
}
address 192.168.1.1/24;
}
}
}
}
Dado que las interfaces que utilizan el reenvío basado en filtros no se deben vincular a una VPN, debe configurar un método alternativo para proporcionar rutas de salto siguiente a la tabla VRF. Para ello, puede definir un grupo de tabla de enrutamiento de interfaz y compartir este grupo entre todas las tablas de enrutamiento:
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-A.inet.0 vpn-B.inet.0 ];
}
}
}
Aplique el siguiente filtro al tráfico entrante en la interfaz fe-1/1/0.0. El primer término coincide con el tráfico del cliente A y lo reenvía a la instancia de enrutamiento para VPN A. El segundo término coincide con el tráfico del cliente B que está destinado al cliente D y lo reenvía a la instancia de enrutamiento para VPN B. El tercer término coincide con el resto del tráfico, que se reenvía normalmente mediante reenvío basado en el destino según las rutas del inet.0.
[edit firewall family family-name]
filter fbf-vrf {
term vpnA {
from {
source-address {
192.168.1.1/32;
}
}
then {
routing-instance vpn-A;
}
}
term vpnB {
from {
source-address {
192.168.1.2/32;
}
destination-address {
192.168.3.0/24;
}
}
then routing-instance vpn-B;
}
}
term internet {
then accept;
}
A continuación, configure las instancias de enrutamiento para VPN A y VPN B. Observe que estas instrucciones incluyen todas las instrucciones necesarias para definir una VPN de capa 3, excepto para la interface instrucción.
[edit]
routing-instances {
vpn-A {
instance-type vrf;
route-distinguisher 172.21.10.63:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
}
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.63:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
}
}
Configuración en el enrutador E
En el enrutador E, configure una ruta predeterminada para llegar a Internet. Debe insertar esta ruta en la malla del IBGP local para proporcionar un punto de salida de la red.
[edit]
routing-options {
static {
route 0.0.0.0/0 next-hop so-2/2/2.0 discard
}
}
Configure la interfaz al cliente E para que todo el tráfico entrante en la interfaz fe-1/1/1.0 que coincida con la política de VPN se reenvíe a través de VPN A:
[edit]
routing-instances {
vpn-A {
interface fe-1/1/1.0
instance-type vrf;
route-distinguisher 172.21.10.62:100;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
routing-options {
static {
route 192.168.2.0/24 next-hop fe-1/1/1.0;
}
}
}
}
Configuración en el enrutador F
Una vez más, dado que las interfaces que utilizan el reenvío basado en filtros no se deben vincular a una VPN, configure un método alternativo para proporcionar rutas de salto siguiente a la tabla VRF mediante la definición de un grupo de tabla de enrutamiento de interfaz y compartir este grupo entre todas las tablas de enrutamiento. Para proporcionar una ruta de regreso a los clientes para el enrutamiento normal inet.0, debe definir una ruta estática para incluirla en inet.0 y redistribuir la ruta estática en BGP:
[edit]
routing-options {
interface-routes {
rib-group inet if-rib;
}
rib-groups {
if-rib {
import-rib [ inet.0 vpn-B.inet.0 ];
}
}
}
Para dirigir el tráfico de la VPN B al cliente D, configure la instancia de enrutamiento para vpn B en el enrutador F. Todo el tráfico entrante del cliente D en la interfaz so-3/3/3.0 se reenvía normalmente mediante la dirección de destino según las rutas en inet.0.
[edit]
routing-instances {
vpn-B {
instance-type vrf;
route-distinguisher 172.21.10.64:200;
vrf-import vpn-B-import;
vrf-export vpn-B-export;
routing-options {
static {
route 192.168.3.0/24 next-hop so-3/3/3.0;
}
}
}
}