EN ESTA PÁGINA
Configuración del enrutamiento entre enrutadores PE y CE en VPN de capa 3
Configuración de un ID de dominio OSPF para una VPN de capa 3
Configuración de sesiones de múltiples saltos de EBGP entre enrutadores PE y CE en VPN de capa 3
Configuración de una topología VPN de capa 3 basada en aplicaciones
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 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, sólo puede configurar un tipo de enrutamiento.
En las secciones siguientes se explica cómo configurar el enrutamiento VPN entre los enrutadores PE y CE:
- Configuración de BGP entre los enrutadores PE y CE
- Configuración de OSPF entre los enrutadores PE y CE
- Configuración de vínculos falsos OSPF para VPN de capa 3
- Configuración de un ID de dominio OSPF
- Configuración de RIP entre los enrutadores PE y CE
- Configuración de rutas estáticas entre los enrutadores PE y CE
Configuración de BGP entre los enrutadores PE y CE
Para configurar BGP como 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 los enrutadores de la serie ACX.Tenga en cuenta las siguientes limitaciones en relación con la configuración de 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 BGP remoto en una instancia de enrutamiento VRF independiente. Al hacerlo, se crea un bucle de sistema autónomo donde se ocultan todas las rutas recibidas de este par BGP remoto.
El número de AS local se configura 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]
El número AS para un par BGP se configura mediante la
peer-asinstrucción en el nivel de[edit routing-instances routing-instance-name protocols bgp group group-name]jerarquía.
Configuración de OSPF entre los enrutadores PE y CE
Puede configurar OSPF (versión 2 o versión 3) para distribuir rutas relacionadas con VPN entre enrutadores PE y CE.
En las secciones siguientes se describe cómo configurar OSPF como protocolo de enrutamiento entre los enrutadores PE y CE:
- Configuración de OSPF versión 2 entre los enrutadores PE y CE
- Configuración de OSPF versión 3 entre los enrutadores PE y CE
Configuración de OSPF versión 2 entre los enrutadores PE y CE
Para configurar OSPF versión 2 como 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 los enrutadores de la serie ACX.
Configuración de OSPF versión 3 entre los enrutadores PE y CE
Para configurar OSPF versión 3 como 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 los enrutadores de la serie ACX.
Configuración de vínculos falsos 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 falsos de OSPF para compensar problemas relacionados con los vínculos intraárea de OSPF.
En las secciones siguientes se describen los vínculos falsos de OSPF y cómo configurarlos:
- Descripción general de OSPF Sham Links
- Configuración de vínculos falsos de OSPF
- Ejemplo de enlaces falsos de OSPF
Descripción general de OSPF Sham Links
La figura 1 proporciona una ilustración de cuándo puede configurar un vínculo simulado de OSPF. Los enrutadores CE1 y CE2 se encuentran en la misma área de OSPF. Estos enrutadores CE están unidos entre sí por una VPN de capa 3 sobre el enrutador PE1 y el enrutador PE2. Además, los enrutadores CE1 y CE2 están conectados por un vínculo intraárea que se utiliza como copia de seguridad.
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 dentro de área a los vínculos entre áreas, por lo que OSPF selecciona el vínculo intraárea de respaldo como la ruta activa. Esto no es aceptable en configuraciones en las que el vínculo intraá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 intraárea, excepto 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 a fin de asegurarse de que la ruta a través de la VPN de capa 3 sea preferible a una ruta de respaldo a través de un vínculo dentro de área que conecte los enrutadores CE.
falso de OSPF
Debe configurar un vínculo falso de OSPF en las siguientes circunstancias:
-
Dos enrutadores CE están unidos entre sí por una VPN de capa 3.
-
Estos enrutadores CE se encuentran en la misma área OSPF.
-
Se configura un vínculo intraárea entre los dos enrutadores CE.
Si no hay ningún vínculo intraárea entre los enrutadores CE, no es necesario configurar un vínculo falso OSPF.
Para obtener más información acerca de los vínculos falsos 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 falsos de OSPF
El enlace falso es un enlace intraárea punto a punto no numerado y se anuncia mediante un anuncio de estado de enlace tipo 1 (LSA). Los vínculos falsos 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 final del vínculo simulado local y remoto y el área OSPF a la que pertenece. Los vínculos falsos deben configurarse manualmente. Configure el vínculo simulado entre dos enrutadores PE, ambos dentro de la misma instancia de enrutamiento VRF.
Debe especificar la dirección para el punto de conexión local del vínculo falso. Esta dirección se utiliza como origen para los paquetes de vínculo simulado y también es utilizada por el enrutador de PE remoto como el punto de conexión remoto de vínculo simulado.
La dirección local del vínculo falso de OSPF debe especificarse con una dirección de circuito cerrado para la VPN local. BGP debe propagar la ruta a esta dirección. Especifique la dirección del extremo 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 de instancias routing-instance-name de enrutamiento ospf]
[editar protocolos de instancias routing-instance-name de enrutamiento de sistemas logical-system-name lógicos OSPF]
La dirección remota del vínculo falso de OSPF debe especificarse con una dirección de circuito cerrado para la VPN remota. BGP debe propagar la ruta a esta dirección. Para especificar la dirección del 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 de instancias routing-instance-name de enrutamiento]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id]
Opcionalmente, puede incluir la opción de métrica para establecer un valor de métrica para el punto de conexión remoto. El valor de la métrica especifica el costo de usar el vínculo. Las rutas con métricas de ruta total más bajas son preferibles a aquellas con métricas de ruta más altas.
Puede configurar un valor del 1 al 65.535. El valor predeterminado es 1.
Ejemplo de enlaces falsos de OSPF
En este ejemplo se muestra cómo habilitar vínculos falsos de OSPF en un enrutador PE.
La siguiente es la configuración de la interfaz de circuito cerrado en el enrutador PE. La dirección configurada es para el extremo local del vínculo falso de OSPF:
[edit]
interfaces {
lo0 {
unit 1 {
family inet {
address 10.1.1.1/32;
}
}
}
}
A continuación se muestra la configuración de la instancia de enrutamiento en el enrutador PE, incluida la configuración del vínculo falso de OSPF. La instrucción local sham-link se configura con la dirección de 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;
}
}
}
}
}
Configuración de un ID de dominio 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 ID de dominio OSPF puede ayudarle a controlar la traducción de LSA (para LSA de tipo 3 y tipo 5) entre los dominios OSPF y las rutas de puerta trasera. Cada tabla de enrutamiento y reenvío VPN (VRF) en un enrutador PE asociado a una instancia de OSPF está configurada con el mismo ID de dominio OSPF. El ID de dominio OSPF predeterminado es el valor nulo 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.
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 |
Nulo |
0.0.0.0 |
LSA tipo 3 |
Ruta tipo 3 |
Nulo |
Nulo |
LSA tipo 3 |
Ruta tipo 3 |
0.0.0.0 |
Nulo |
LSA tipo 3 |
Ruta tipo 3 |
A.B.C.D |
Nulo |
LSA tipo 5 |
Ruta tipo 3 |
Nulo |
A.B.C.D |
LSA tipo 3 |
Ruta tipo 5 |
No aplica |
No aplica |
LSA tipo 5 |
Puede configurar un ID de dominio 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 [edit routing-instances routing-instance-name protocols ospf] para OSPF versión 2 y en el nivel de jerarquía [edit routing-instances routing-instance-name protocols ospf3] para OSPF versión 3. Las descripciones de configuración siguientes sólo presentan la instrucción OSPF versión 2. Sin embargo, las subinstrucciones también son válidas 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 de instancias routing-instance-name de enrutamiento ospf]
[editar protocolos de instancias routing-instance-name de enrutamiento de sistemas logical-system-name lógicos OSPF]
Puede establecer una etiqueta VPN para las rutas externas OSPF generadas por el enrutador PE para evitar 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 LSA de 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 de instancias routing-instance-name de enrutamiento ospf]
[editar protocolos de instancias routing-instance-name de enrutamiento de sistemas logical-system-name lógicos OSPF]
El rango es de 1 a 4,294,967,295 (232 – 1). Si configura las etiquetas VPN manualmente, debe establecer el mismo valor para todos los enrutadores PE de la VPN.
Para obtener un ejemplo de este tipo de configuración, consulte Configuración de un ID de dominio OSPF para una VPN de capa 3.
VPN de capa 3 radial e ID de dominio OSPF
El comportamiento predeterminado de un ID de dominio OSPF causa algunos problemas para las VPN radiales de capa 3 configuradas con OSPF entre el enrutador PE del concentrador y el enrutador CE del concentrador cuando las rutas no se agregan. Una configuración radial tiene un enrutador PE concentrador con vínculos directos a un enrutador concentrador CE. El enrutador de PE del concentrador recibe actualizaciones de BGP de capa 3 de los otros enrutadores de PE radiales remotos, que se importan a la instancia de enrutamiento radial. Desde la instancia de enrutamiento radial, los LSA OSPF se originan y se envían al enrutador CE del concentrador.
El enrutador del concentrador CE normalmente agrega estas rutas y, a continuación, envía estas LSA recién originadas de vuelta al enrutador del concentrador PE. El enrutador PE del concentrador exporta las actualizaciones de BGP a los enrutadores de PE radiales remotos que contienen los prefijos agregados. Sin embargo, si hay LSA de resumen de tipo 3 no agregados o LSA externos, surgen dos problemas con respecto a cómo se origina y envía el enrutador de PE del concentrador al enrutador CE del concentrador, y cómo el enrutador de PE del concentrador procesa los LSA recibidos del enrutador del concentrador CE:
De forma predeterminada, todos los LSA originados por el enrutador PE del concentrador en la instancia de enrutamiento radial tienen el bit DN establecido. Además, todos los LSA originados externamente tienen la etiqueta de ruta VPN establecida. La configuración del bit DN y la etiqueta de ruta VPN ayudan a evitar bucles de enrutamiento. Para los LSA de resumen de tipo 3, los bucles de enrutamiento no son una preocupación porque el enrutador CE del concentrador, como enrutador de borde de área (ABR), vuelve a originar los LSA con el bit DN claro y los envía de vuelta al enrutador PE del concentrador. Sin embargo, el enrutador del concentrador CE no reorigina los LSA externos, ya que tienen un ámbito de inundación de AS.
Puede originar los LSA externos (antes de enviarlos al enrutador del concentrador CE) con el bit DN claro y la etiqueta de ruta VPN establecida en 0 modificando la configuración de la instancia de enrutamiento del enrutador PE del concentrador. Para borrar el bit DN y establecer la etiqueta de ruta VPN en cero en LSA externos originados por un enrutador PE, configure 0 para la instrucción domain-vpn-tag en el nivel de jerarquía [edit routing-instances routing-instance-name protocols ospf]. Debe incluir esta configuración en la instancia de enrutamiento en el enrutador PE del concentrador frente al enrutador CE del concentrador al que se envían los LSA. Cuando el enrutador del concentrador CE recibe LSA externos del enrutador del concentrador PE y, a continuación, los reenvía de vuelta al enrutador del concentrador PE, el enrutador del concentrador PE puede utilizar los LSA en su cálculo de ruta OSPF.
Cuando los LSA inundados por el enrutador del concentrador CE llegan a la instancia de enrutamiento del enrutador del concentrador PE, el enrutador del concentrador PE, actuando como una ABR, no tiene en cuenta estos LSA en sus cálculos de ruta OSPF, aunque los LSA no tengan los bits DN establecidos y los LSA externos no tengan 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 PE para que el enrutador PE actúe como un no ABR incluyendo la instrucción disable en el nivel jerárquico [edit routing-instances routing-instance-name protocols ospf domain-id]. Este cambio de configuración se realiza en el enrutador PE del concentrador que recibe los LSA del enrutador del concentrador CE.
Al realizar este cambio de configuración, la instancia de enrutamiento del enrutador PE actúa como una no ABR. Luego, el enrutador PE considera los LSA que llegan desde el enrutador CE del concentrador como si vinieran de un área contigua que no es troncal.
Configuración de RIP entre los enrutadores PE y CE
Para una VPN de capa 3, puede configurar RIP en el enrutador PE para aprender las rutas del enrutador CE o para propagar las rutas del enrutador PE al enrutador CE. Las rutas RIP aprendidas de vecinos configurados en cualquier [edit routing-instances] nivel de jerarquía se agregan a la tabla () de la instancia de inet enrutamiento (instance_name.inet.0).
Para configurar RIP como 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 los enrutadores de la serie ACX.
De forma predeterminada, RIP no anuncia las rutas que recibe. Para anunciar rutas desde un enrutador PE a un enrutador CE, debe configurar una política de exportación en el enrutador PE para RIP. Para obtener 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 los enrutadores de la 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 los enrutadores de la serie ACX.
Para configurar un grupo de tablas 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 los enrutadores de la serie ACX.
Para agregar una tabla de enrutamiento a un grupo de tablas de enrutamiento, incluya la import-rib instrucción. El primer nombre de tabla de enrutamiento especificado en 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 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 los enrutadores de la serie ACX.
Las instancias RIP solo se admiten para tipos de instancias VRF. Puede configurar varias instancias de RIP solo para compatibilidad con VPN. Puede utilizar RIP en el entorno perimetral del proveedor perimetral del cliente (CE-PE) para aprender rutas del enrutador CE y propagar las rutas de instancia del enrutador 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 tablas 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 PE y CE
Puede configurar rutas estáticas (sin cambios) 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 nivel jerárquico [edit routing-instances routing-instance-name routing-options] .
Para configurar una ruta estática entre el PE y los enrutadores 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 los enrutadores de la serie ACX.
Para obtener más información acerca de la configuración de protocolos de enrutamiento y rutas estáticas, consulte Biblioteca de protocolos de enrutamiento de Junos OS.
Configuración de un ID de dominio OSPF para una VPN de capa 3
En este ejemplo se muestra cómo configurar un identificador de dominio OSPF para una VPN utilizando OSPF como protocolo de enrutamiento entre los enrutadores PE y CE. Las rutas de un dominio OSPF necesitan un ID de dominio 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 identificador de dominio que se configura en una instancia de enrutamiento identifica el dominio OSPF y se utiliza para identificar el origen de la ruta. El ID de dominio que se configura en una directiva de comunidad se utiliza para establecer rutas exportadas.
Para obtener más información acerca de los ID de dominio OSPF y las 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 del enrutador PE1. No existen requisitos de configuración especiales para los enrutadores CE.
de dominio OSPF
Para obtener información de configuración, consulte las secciones siguientes:
- Configuración de interfaces en el enrutador PE1
- Configuración de las opciones de enrutamiento en el enrutador PE1
- Configuración de protocolos en el enrutador PE1
- Configuración de opciones de directiva 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 las opciones de enrutamiento en el enrutador PE1
En el nivel jerárquico [edit routing-options] , 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 nivel jerárquico [edit protocols] :
[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 directiva en el enrutador PE1
En el enrutador PE1, debe configurar las políticas en el nivel jerárquico [edit policy-options] . Estas políticas garantizan que los enrutadores CE en la VPN de capa 3 intercambien 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 nivel de [edit routing-instance routing-instance-name] jerarquía.
La domain-id instrucción se configura en el nivel jerárquico [edit routing-instances routing-options protocols ospf] . Como se muestra en la figura 2, la instancia de enrutamiento en el 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 de tipo 3. Si configura diferentes ID de dominio OSPF en las instancias de enrutamiento para el enrutador PE1 y el enrutador PE2, las rutas de cada enrutador CE se distribuirán como LSA de 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 directiva 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 OSPFv2 Sham Links
Puede crear un vínculo dentro de área o un vínculo simulado entre dos dispositivos de enrutamiento perimetral 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 dicho vínculo de copia de seguridad está disponible y los dispositivos CE se encuentran en la misma área OSPF, el comportamiento predeterminado es preferir este vínculo de copia de seguridad sobre la red troncal VPN. Esto se debe a que el enlace de respaldo se considera un enlace intraárea, mientras que la red troncal VPN siempre se considera un enlace entre áreas. Los enlaces intraárea siempre son preferidos a los enlaces entre áreas.
El enlace simulado es un vínculo intraárea punto a punto no numerado entre dispositivos PE. Cuando la red troncal de VPN tiene un vínculo dentro de área falso, se puede preferir este vínculo falso sobre el vínculo de copia de seguridad si el vínculo falso tiene una métrica OSPF más baja que el vínculo de copia de seguridad.
El enlace falso se anuncia mediante anuncios de estado de enlace (LSA) de tipo 1. Los vínculos falsos solo son válidos para instancias de enrutamiento y OSPFv2.
Cada vínculo falso se identifica mediante la combinación de una dirección de extremo local y una dirección de punto de conexión remota. La figura 3 muestra un vínculo falso de OSPFv2. Los enrutadores CE1 y CE2 se encuentran en la misma área de OSPFv2. Estos dispositivos de enrutamiento perimetral del 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 por un vínculo intraárea que se utiliza como copia de seguridad.
falso de 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 dentro de área a los vínculos entre áreas, por lo que OSPFv2 selecciona el vínculo de área de respaldo como la ruta activa. Esto no es aceptable en una configuración en la que el vínculo intraá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 a fin de asegurarse de que la ruta a través de la VPN de capa 3 sea preferible a una ruta de respaldo a través de un vínculo intraárea que conecte los dispositivos de enrutamiento CE.
Para el extremo remoto, puede configurar la interfaz OSPFv2 como un circuito de demanda, configurar la autenticación IPsec (puede configurar la autenticación IPsec real por separado) y definir el valor de la métrica.
Debe configurar un vínculo falso de OSPFv2 en las siguientes circunstancias:
Dos dispositivos de enrutamiento CE están unidos entre sí por una VPN de capa 3.
Estos dispositivos de enrutamiento CE se encuentran en la misma área OSPFv2.
Se configura un vínculo intraárea entre los dos dispositivos de enrutamiento CE.
Si no hay ningún vínculo intraárea entre los dispositivos de enrutamiento CE, no es necesario configurar un vínculo simulado OSPFv2.
En Junos OS versión 9.6 y posteriores, se instala un vínculo falso OSPFv2 en la tabla de enrutamiento como una ruta oculta. Además, una ruta BGP no se exporta a OSPFv2 si hay disponible un vínculo falso de OSPF correspondiente.
En Junos OS versión 16.1 y posteriores, los vínculos falsos de OSPF se admiten en las instancias predeterminadas. El costo del enlace simulado se establece dinámicamente en la métrica aigp de la ruta BGP si el usuario no configura ninguna métrica en el enlace simulado. Si la métrica aigp no está presente en la ruta BGP, el valor predeterminado del enlace simulado es 1.
Ejemplo: configuración de vínculos falsos de OSPFv2
En este ejemplo se muestra cómo habilitar vínculos simulados OSPFv2 en un dispositivo de enrutamiento 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 falso es un enlace intraárea punto a punto no numerado y se anuncia mediante un anuncio de estado de enlace tipo 1 (LSA). Los vínculos falsos 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 remota y el área OSPFv2 a la que pertenece. Puede configurar manualmente el vínculo simulado entre dos dispositivos PE, ambos dentro de la misma instancia de enrutamiento y reenvío VPN (VRF) y especificar la dirección para el extremo local del vínculo simulado. Esta dirección se utiliza como origen para los paquetes de vínculo simulado y también es utilizada por el dispositivo de enrutamiento de PE remoto como punto de conexión remoto de vínculo simulado. También puede incluir la opción opcional metric de establecer un valor de métrica para el punto de conexión remoto. El valor de la métrica especifica el costo de usar el vínculo. Las rutas con métricas de ruta total más bajas son preferibles a aquellas con métricas de ruta más altas.
Para habilitar vínculos falsos de OSPFv2 en un dispositivo de enrutamiento de PE:
Configure una interfaz de circuito cerrado adicional en el dispositivo de enrutamiento PE.
Configure la instancia de enrutamiento VRF que admita VPN de capa 3 en el dispositivo de enrutamiento PE y asocie el vínculo falso 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 extremo local del vínculo simulado, que es la dirección de circuito cerrado de la VPN local, y la dirección del extremo 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 de OSPFv2.
Topología
de vínculo falso OSPFv2
Los dispositivos de la figura representan las siguientes funciones:
CE1 y CE2 son los dispositivos perimetrales del cliente.
PE1 y PE2 son los dispositivos perimetrales 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. En la sección Procedimiento paso a paso se describen los pasos del 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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener 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 la CLI.
Para configurar vínculos falsos de OSPFv2 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 orientada al núcleo.
[edit protocols mpls] user@PE1# set interface fe-1/2/1.0
-
Configurar 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 orientada al 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 orientada al 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 utilizarla 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 falso de OSPFv2.
Incluya la interfaz de circuito cerrado adicional en la instancia de enrutamiento y también en la configuración de 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 enlace falso sea el enlace 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 la configuración introduciendo los show interfaces show routing-instances comandos y. Si el resultado no muestra la configuración deseada, repita las instrucciones de 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.
- Comprobación de las interfaces de vínculos simulados
- Comprobación de los puntos finales locales y remotos del vínculo falso
- Verificación de las adyacencias de vínculos falsos
- Verificación del anuncio de estado de vínculo
- Comprobación de la selección de ruta
Comprobación de las interfaces de vínculos simulados
Propósito
Compruebe la interfaz de vínculo falso. 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 falso aparece como una interfaz 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
Comprobación de los puntos finales locales y remotos del vínculo falso
Propósito
Compruebe los extremos locales y remotos del vínculo falso. 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
Verificación de las adyacencias de vínculos falsos
Propósito
Compruebe las adyacencias entre los vínculos falsos 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
Verificación del anuncio de estado de vínculo
Propósito
Verifique que el LSA del enrutador originado por la instancia lleve la adyacencia de vínculo simulado como un vínculo punto a punto no numerado. Los datos de enlace para enlaces falsos son un número que va del 0x80010000 al 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
Comprobació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 tuviera que quitar el vínculo falso o si modificara la métrica OSPF para preferir esa ruta de copia de seguridad, traceroute mostraría que se prefiere la ruta de copia de seguridad.
Configuración de sesiones de múltiples saltos de EBGP entre enrutadores PE y CE en VPN de capa 3
Puede configurar una sesión multisalto 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 instrucciones adicionales. 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 de múltiples saltos BGP externa para la conexión entre los enrutadores PE y CE, incluya la multihop instrucción en el enrutador PE. Para ayudar a evitar los bucles de enrutamiento, debe configurar un valor de tiempo de vida (TTL) para la sesión multisalto:
multihop ttl-value;
Para obtener la lista de niveles de jerarquía en los que puede configurar esta instrucción, vea la sección resumen de esta instrucción.
Configuración de una topología VPN LDP a través de RSVP
En este ejemplo se muestra cómo configurar una topología VPN en la que los paquetes LDP se tunelizan a través de un LSP RSVP. Esta configuración consta de los siguientes componentes (consulte la figura 5):
Una VPN (VPN-A)
Dos enrutadores PE
LDP como protocolo de señalización entre los enrutadores PE y sus enrutadores P adyacentes
Un LSP RSVP entre dos de los enrutadores P sobre los que se tuneliza LDP
VPN LDP sobre RSVP
Los pasos siguientes describen cómo se establece esta topología y cómo se envían los paquetes desde el enrutador CE 2 al enrutador CE CE1:
Los enrutadores P P1 y P3 establecen RSVP LSP 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 a través de la interfaz
so-1/0/0.0.El enrutador P1 establece una sesión LDP con la dirección de circuito cerrado del enrutador P3, a la que se puede acceder mediante el LSP RSVP.
El enrutador P1 envía sus enlaces de etiquetas, que incluyen una etiqueta para llegar al enrutador PE1, al enrutador P3. Estos enlaces de etiqueta permiten al enrutador P3 dirigir paquetes LDP al enrutador PE1.
El enrutador P3 establece una sesión LDP con el enrutador PE2 a través de la interfaz
so0-0/0/0.0y establece una sesión LDP con la dirección de circuito cerrado del enrutador P1.El enrutador P3 envía sus enlaces de etiquetas, que incluyen una etiqueta para llegar al enrutador PE2, al enrutador P1. Estos enlaces de etiqueta permiten que el enrutador P1 dirija los 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 las rutas del enrutador PE2 que aprendió del enrutador CE1, incluye su etiqueta VPN. (El enrutador PE crea la etiqueta VPN y la enlaza a la interfaz entre los enrutadores PE y CE). Del mismo modo, cuando el enrutador PE2 anuncia rutas que aprendió del enrutador CE2, envía su etiqueta VPN al enrutador PE1.
Cuando el enrutador PE2 desea reenviar un paquete al enrutador CE1, inserta 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 y, a continuación, 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, intercambia la etiqueta LDP que está en la parte superior de la pila (de acuerdo con su base de datos LDP) y también empuja 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, la del 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 enrutador del penúltimo salto del LSP, extrae 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 muestra la etiqueta LDP en lugar de intercambiarla por 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 reenvía el paquete como un paquete IPv4 al enrutador CE1 a través de la interfaz
ge-1/1/0.0.
Un conjunto similar de operaciones se produce para los paquetes enviados desde el enrutador CE1 destinados al enrutador CE2.
En la siguiente lista se explica cómo, para los paquetes que se envían del 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 sí mismo 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 VPN
El enrutador PE1 anuncia la etiqueta VPN 100.004 al enrutador PE2 para la ruta del enrutador CE1 al enrutador CE2.
etiquetas
Para un paquete enviado desde el host B de 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 por 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). Por lo tanto, la etiqueta VPN es la etiqueta interna (inferior) de 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 por su etiqueta LDP para llegar al enrutador PE1 (100.001). También agrega la etiqueta RSVP para alcanzar el 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 VPN (100.004). También intercambia la interfaz del próximo salto y
so-1/0/0la reemplaza por su interfaz del siguiente salto,ge-1/1/0.El enrutador CE1 elimina la interfaz del siguiente salto de , y el encabezado del
ge-1/1/0paquete ahora solo contiene una dirección de origen de B y una dirección de destino de A.
En la sección final de este ejemplo se consolidan las instrucciones necesarias para configurar la funcionalidad VPN en cada uno de los enrutadores de servicio P que se muestran en la figura 5.
En este ejemplo, se usa un número de AS privado para el diferenciador de ruta y el destino de ruta. Este número se utiliza sólo a título ilustrativo. Cuando configure VPN, debe usar un número de AS asignado.
En las siguientes secciones se explica cómo configurar la funcionalidad VPN en los enrutadores PE y P. Los enrutadores CE no tienen ninguna información sobre la VPN, por lo que los configura normalmente.
- 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 de IBGP en los enrutadores PE
- Configuración de instancias de enrutamiento para VPN en enrutadores PE
- Configuración de la política VPN en los enrutadores PE
- Configuración de VPN LDP a través de RSVP resumida 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 sí, debe configurar un IGP en todos estos enrutadores o debe configurar rutas estáticas. El IGP se configura en la instancia principal del proceso de protocolo de enrutamiento (rpd) (es decir, en el [edit protocols] nivel de jerarquía), no dentro de la instancia de enrutamiento VPN (es decir, no en el [edit routing-instances] nivel de jerarquía).
El IGP se configura de forma 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 PE y en los enrutadores P que están conectados a los enrutadores 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 son las interfaces en las que se configura el LSP de MPLS.
En los enrutadores 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 proporcionar una ruta de LDP de reserva en caso de que el LSP del RSVP deje de funcionar:
[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 P P2, debe configurar RSVP y MPLS, ya que este enrutador existe en la ruta LSP de MPLS entre los enrutadores P 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, LDP se tuneliza 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 tunelizar el tráfico LDP.
En el enrutador P1, habilite RSVP y configure un extremo del túnel LSP de MPLS. En este ejemplo, la compatibilidad con ingeniería de tráfico se habilita para OSPF y se configura MPLS en las interfaces al LSP y al 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 su confirmación de asistencia y configure el otro extremo del túnel LSP de MPLS. De nuevo, la compatibilidad con ingeniería de tráfico está habilitada para OSPF y se 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 de IBGP en los enrutadores PE
En los enrutadores PE, configure una sesión IBGP con las siguientes propiedades:
Familia VPN: para indicar que la sesión de IBGP es para la VPN, incluya la
family inet-vpninstrucción.Dirección de circuito cerrado: incluye la
local-addressinstrucción y especifica la dirección de circuito cerrado del enrutador de PE local. La sesión de IBGP para VPN se ejecuta a través de la dirección de circuito cerrado. También debe configurar lalo0interfaz en el nivel jerárquico[edit interfaces]. El ejemplo no incluye esta parte de la configuración del enrutador.Dirección del vecino: incluya la
neighborinstrucción, especificando la dirección IP del enrutador 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 enrutadores PE
Ambos enrutadores PE dan servicio a VPN-A, por lo que debe configurar una instancia de enrutamiento en cada enrutador para la VPN en la que defina lo siguiente:
Distinguidor de ruta, que debe ser único para cada instancia de enrutamiento en el enrutador PE. Se utiliza para distinguir las direcciones en una VPN de las de otra VPN.
Tipo de instancia de
vrf, que crea la tabla VRF en el enrutador PE.Interfaces conectadas a los enrutadores CE.
Políticas de importación y exportación de VRF, que deben ser las mismas en cada enrutador PE que dé servicio a la misma VPN. A menos que la política de importación contenga solo una
then rejectinstrucción, debe incluir una referencia a una comunidad. De lo contrario, cuando intente confirmar la configuración, se producirá un error en la confirmación.Nota:En este ejemplo, se usa un número de AS privado para el distinguidor de ruta. Este número se utiliza sólo a título ilustrativo. 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 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 utiliza 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 utiliza 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 VPN en los enrutadores PE
Debe configurar las directivas de importación y exportación de VPN en cada uno de los enrutadores 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 directiva VPN, también se configuran las comunidades de destino VPN.
En este ejemplo, se usa un número de AS privado para el destino de la ruta. Este número se utiliza sólo a título ilustrativo. 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 directiva que se muestran en este ejemplo son solo los necesarios para que la VPN funcione. Puede configurar calificadores adicionales, según sea necesario, para cualquier directiva 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 directivas de VPN en los enrutadores, incluya las vrf-export instrucciones y vrf-import cuando configure la instancia de enrutamiento en los enrutadores PE. Las políticas de importación y exportación de VRF manejan la distribución de rutas a través de la sesión de IBGP que se ejecuta entre los enrutadores PE.
Configuración de VPN LDP a través de RSVP resumida 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 instancias
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 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 directiva 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 la compatibilidad con 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 la compatibilidad con 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 instancias
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 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 directiva 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
Este ejemplo ilustra un mecanismo basado en aplicaciones para reenviar tráfico a una VPN de capa 3. Normalmente, una o más interfaces están asociadas o enlazadas a una VPN incluyéndolas en la configuración de la instancia de enrutamiento VPN. Al enlazar la interfaz a la VPN, la tabla VRF de la VPN se usa 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 próximo salto para las rutas VRF.
En este ejemplo, se utiliza un filtro de firewall para definir qué tráfico entrante en 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 ampliar este ejemplo de manera que el tráfico entrante en 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 el tráfico según la dirección de origen, que reenvíe el tráfico del Protocolo de transferencia de hipertexto (HTTP) o que reenvíe solo medios de streaming.
Para que esta configuración funcione, deben cumplirse las condiciones siguientes:
Las interfaces que usan reenvío basado en filtros no deben estar enlazadas a la VPN.
El enrutamiento estático debe utilizarse como medio de enrutamiento.
Debe definir un grupo de tablas de enrutamiento de interfaz que se comparta 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 desean 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 la VPN A con una ruta de retorno que también usa la 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 ilustra que hay una gran variedad de opciones para configurar una topología VPN de capa 3 basada en aplicaciones. Esta flexibilidad tiene aplicación en 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 ilustra cómo configurar una VPN de capa 3.
La figura 7 ilustra la topología de red utilizada en este ejemplo.
Configuración en el enrutador A
En el enrutador A, configure la interfaz para 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, aplique un filtro de entrada y configure 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 usan el reenvío basado en filtros no deben estar enlazadas a una VPN, debe configurar un método alternativo para proporcionar rutas del próximo salto a la tabla VRF. Para ello, defina un grupo de tablas de enrutamiento de interfaz y comparta 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 filtro siguiente 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 de la VPN A. El segundo término coincide con el tráfico del cliente B destinado al cliente D y lo reenvía a la instancia de enrutamiento para la VPN B. El tercer término coincide con todo el resto del tráfico, que se reenvía normalmente por medio del reenvío basado en el destino de acuerdo con las rutas en 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. Tenga en cuenta que estas instrucciones incluyen todas las instrucciones necesarias para definir una VPN de capa 3, excepto 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 inyectar esta ruta en la malla de 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 con el cliente E para que todo el tráfico entrante en la interfaz fe-1/1/1.0 que coincida con la directiva de VPN se reenvíe a través de la 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
De nuevo, dado que las interfaces que usan reenvío basado en filtros no deben estar enlazadas a una VPN, configure un método alternativo para proporcionar rutas de salto siguiente a la tabla VRF definiendo un grupo de tablas de enrutamiento de interfaz y compartiendo este grupo entre todas las tablas de enrutamiento. Para proporcionar una ruta de regreso a los clientes para el enrutamiento normal de inet.0, defina una ruta estática para incluirla en inet.0 y redistribuya 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 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 por medio de la dirección de destino basada en 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;
}
}
}
}