RFC 4364

Estado de esta nota
Este documento especifica un protocolo de seguimiento de estándares

de Internet para
Comunidad de Internet, y solicita discusión y sugerencias para
mejoras. Por favor, consulte la edición actual de "Internet"
Estándares oficiales de protocolo "(STD 1) para el estado de
estandarización
y el estado de este protocolo. La distribución de este memo es
ilimitada.
Aviso de copyright
Copyright (C) The Internet Society (2006).
Abstracto
Este documento describe un método por el cual un proveedor de

servicios puede usar
una red troncal IP para proporcionar redes privadas virtuales (VPN)
IP para su
clientes. Este método utiliza un "modelo de pares", en el que los
clientes
los enrutadores de borde (enrutadores CE) envían sus rutas al
proveedor de servicios
enrutadores de borde (enrutadores PE); no hay una "superposición"
visible para el
el algoritmo de enrutamiento del cliente y los enrutadores CE en
diferentes sitios lo hacen
no mirar el uno al otro. Los paquetes de datos se tunelizan a
través del
backbone, para que los enrutadores centrales no necesiten conocer
la VPN
rutas
Este documento obsoleto RFC 2547 .
Rosen & Rekhter Standards Track [Página 1]
RFC 4364 BGP / MPLS IP VPN Febrero de 2006
Tabla de contenido
1 . Introducción .................................................
... 3
1.1 . Redes privadas virtuales
................................... 4
1.2 . Borde del cliente y borde del proveedor
............................ 5
1.3 . VPN con espacios de direcciones superpuestos
....................... 6
1.4 . VPN con diferentes rutas para el mismo sistema
.............. 7
1.5 . Enrutadores SP Backbone
.................................... 7
1.6 . Seguridad
................................................. .. 8
2 . Sitios y CE ...............................................
.... 8
3. VRF: Múltiples tablas de reenvío en PE ........................
9
3.1 . VRF y circuitos de conexión
............................... 9
3.2 . Asociación de paquetes de IP con VRF
.......................... 10
3.3 . Poblando los VRF .......................................
11
4 . Distribución de rutas VPN a través de BGP
................................. 12
4.1 . La familia de direcciones VPN-IPv4
............................... 13
4.2 . Codificación de Distinguishers de ruta
.......................... 14
4.3 . Control de la distribución de rutas
............................ 15
4.3.1. El atributo de destino de ruta
......................... 15
4.3.2 . Distribución de rutas entre PE por BGP
................ 17
4.3.3 . Uso de Reflectores de ruta
............................ 20
4.3.4 . Cómo se lleva VPN-IPv4 NLRI en BGP ................
22
4.3.5 . Creación de redes privadas virtuales utilizando
destinos de ruta .................. 23
4.3.6 . Distribución de ruta entre VRF en un solo PE
....... 23
5 . Reenvío ................................................. ....
23
6 . Mantener el aislamiento apropiado de VPNs
........................... 26
7. Cómo aprenden los PE las rutas desde los CE
.................................. 27
8 . Cómo los CE aprenden rutas de PE
.................................. 30
9 . Operadores de transportistas
............................................. 30
10 . Redes troncales Multi-AS
............................................ 32
11 . Acceder a Internet desde una VPN
.............................. 34
12 . VPN de gestión ...............................................
36
13 . Consideraciones de seguridad
................................... 37
13.1 . Plano de datos
............................................... 37
13.2 . Plano de control
............................................ 39
13.3 . Seguridad de los dispositivos P y PE
.............................. 39
14 . Calidad del servicio
............................................ 39
15 . Escalabilidad
................................................. .. 40
16 . Consideraciones IANA
........................................... 40
17 . Agradecimientos ..............................................
41
18 . Contribuyentes
................................................. . 41
19 . Referencias normativas
.......................................... 44
20 . Referencias informativas
........................................ 45
Rosen & Rekhter Normas Track [Página 2]
1 . Introducción
Este documento describe un método por el cual un proveedor de

servicios puede usar
una red troncal IP para proporcionar redes privadas virtuales (VPN)
IP para su
clientes. Este método utiliza un "modelo de pares", en el que los
clientes
los enrutadores de borde (enrutadores CE) envían sus rutas al
proveedor de servicios
enrutadores de borde (enrutadores PE). Border Gateway Protocol
(BGP)
[ BGP , BGP-MP ] luego es utilizado por el proveedor de servicios
para intercambiar
rutas de una VPN particular entre los enrutadores PE que están
conectados a
esa VPN. Esto se hace de una manera que asegura que las rutas desde
diferentes VPN siguen siendo distintas y separadas, incluso si dos
VPN tienen una
superposición de espacio de direcciones. Los enrutadores PE
distribuyen, al CE
enrutadores en una VPN en particular, las rutas de otros
enrutadores CE en
esa VPN. Los enrutadores CE no tienen igual entre sí, por lo tanto,
hay
no hay "superposición" visible para el algoritmo de enrutamiento de
la VPN. El término "IP"
en "IP VPN" se usa para indicar que el PE recibe datagramas de IP
desde el CE, examina sus encabezados de IP y los dirige en
consecuencia.
A cada ruta dentro de una VPN se le asigna una conmutación de

etiquetas multiprotocolo
(MPLS) etiqueta [ MPLS-ARCH , MPLS-BGP , MPLS-ENCAPS ]; cuando BGP
distribuye
una ruta VPN, también distribuye una etiqueta MPLS para esa ruta.
Antes de que un paquete de datos del cliente viaje a través del
proveedor del servicio
backbone, está encapsulado con la etiqueta MPLS que corresponde, en
la VPN del cliente, a la ruta que mejor se adapta a la
dirección de destino del paquete. Este paquete MPLS está más allá
encapsulado (por ejemplo, con otra etiqueta MPLS o con un IP o
genérico
Enrutamiento del encabezado del túnel de encapsulación (GRE) [
MPLS-in-IP-GRE ]) para que
se canaliza a través de la red troncal hacia el enrutador PE
apropiado. Así,
los enrutadores principales de red troncal no necesitan conocer las
rutas VPN.
El objetivo principal de este método es respaldar el caso en el que

el cliente obtiene servicios de backbone IP de un proveedor de
servicios o
Proveedores de servicios con los que mantiene relaciones
contractuales.
El cliente puede ser una empresa, un grupo de empresas que
necesitan una
extranet, un proveedor de servicios de Internet, un servicio de
aplicaciones
proveedor, otro proveedor de servicios VPN que utiliza este mismo
método para
ofrecer VPN a sus propios clientes, etc. El método lo hace muy
simple para que el cliente use los servicios troncales. También es
muy
escalable y flexible para el proveedor de servicios, y permite
Proveedor de servicios para agregar valor.

1.1 . Redes privadas virtuales
Considere un conjunto de "sitios" que están conectados a una red

común que
lo llamamos "la columna vertebral". Ahora aplique alguna política
para crear un número de
subconjuntos de ese conjunto e imponen la siguiente regla: dos
sitios pueden
tener interconectividad IP sobre esa red troncal solo si al menos
uno de
estos subconjuntos los contienen a ambos.
Estos subconjuntos son redes privadas virtuales (VPN). Dos sitios

tienen IP
conectividad sobre la red troncal común solo si hay alguna VPN que
los contiene a ambos. Dos sitios que no tienen VPN en común no
tienen
conectividad sobre esa columna vertebral.
Si todos los sitios en una VPN son propiedad de la misma empresa,

la VPN
puede considerarse como una "intranet" corporativa. Si los diversos
sitios en
una VPN es propiedad de diferentes empresas, se puede pensar en la
VPN
como una "extranet". Un sitio puede estar en más de una VPN; por
ejemplo, en un
intranet y en varias extranets. En general, cuando usamos el
término
"VPN" no distinguiremos entre intranets y extranets.
Nos referimos a los propietarios de los sitios como los "clientes".

Nos referimos a
los propietarios / operadores de la red troncal como los
"Proveedores de servicios"
(SP) Los clientes obtienen "servicio VPN" de los SP.
Un cliente puede ser una sola empresa, un conjunto de empresas, un

Proveedor de servicios de Internet, Proveedor de servicios de
aplicaciones, otro
SP que ofrece el mismo tipo de servicio VPN a sus propios clientes,
etc.
Las políticas que determinan si una colección particular de sitios

es una VPN son las políticas de los clientes. Algunos clientes
querrán
la implementación de estas políticas para ser completamente
responsabilidad del SP. Otros clientes pueden querer compartir con
el
SP es responsable de implementar estas políticas. Este documento
especifica los mecanismos que se pueden usar para implementar estas
políticas.
Los mecanismos que describimos son lo suficientemente generales
como para permitir estas políticas
para ser implementado por el SP solo o por un cliente VPN
junto con el SP. La mayor parte de la discusión se centra en la
caso anterior, sin embargo.
Los mecanismos discutidos en este documento permiten la
implementación de
una amplia gama de políticas. Por ejemplo, dentro de una VPN dada,
uno puede
permitir que cada sitio tenga una ruta directa a cualquier otro
sitio ("completo
malla "). Alternativamente, uno puede forzar el tráfico entre
ciertos pares
de sitios a enrutar a través de un tercer sitio. Esto puede ser
útil, por ejemplo, si
se desea que el tráfico entre un par de sitios pase a través de
un firewall, y el firewall está ubicado en el tercer sitio.
En este documento, restringimos nuestra discusión al caso en el que

el cliente está comprando explícitamente el servicio VPN desde un
SP, o desde un
conjunto de SP que han acordado cooperar para proporcionar el
servicio VPN.
Es decir, el cliente no está simplemente comprando acceso a
Internet desde
un SP, y el tráfico VPN no pasa por una colección aleatoria
de redes SP interconectadas.
También restringimos nuestra discusión al caso en el que la columna

vertebral
proporciona un servicio IP al cliente, en lugar de, por ejemplo,
una capa 2
servicio como Frame Relay, modo de transferencia asincrónica (ATM),
ethernet, control de enlace de datos de alto nivel (HDLC) o punto a
punto
Protocolo (PPP). El cliente puede conectarse a la red troncal a
través de uno de
estos (u otros) servicios de capa 2, pero el servicio de capa 2 es
terminado en el "borde" de la red troncal, donde el IP del cliente
los datagramas se eliminan de cualquier encapsulación de capa 2.
En el resto de esta introducción, especificamos algunas propiedades

que
VPN debería tener. El resto de este documento especifica un
conjunto de
mecanismos que se pueden implementar para proporcionar un modelo
VPN que tenga todo
estas propiedades. Esta sección también presenta algunos de los
aspectos técnicos
terminología utilizada en el resto del documento.
1.2 . Borde del cliente y borde del proveedor

Los enrutadores se pueden conectar entre sí, o para sistemas
finales, en una
variedad de formas diferentes: conexiones PPP, circuitos virtuales
ATM
(VCs), Frame Relay VCs, interfaces de ethernet, área local virtual
Redes (VLAN) en interfaces ethernet, túneles GRE, Capa 2
Tuneling Protocol (L2TP) túneles, túneles IPsec, etc. Utilizaremos
el término "circuito de conexión" para referirse en general a
algunos de tales medios
de conectarse a un enrutador. Un circuito de conexión puede ser el
tipo de
conexión que generalmente se considera como un "enlace de datos", o
puede ser
un túnel de algún tipo; lo que importa es que sea posible para dos
dispositivos para ser compañeros de capa de red sobre el circuito
de conexión.
Cada sitio VPN debe contener uno o más dispositivos Edge de cliente
(CE).
Cada dispositivo CE está conectado, a través de algún tipo de
circuito de conexión, a
uno o más enrutadores Provider Edge (PE).
Los enrutadores en la red del SP que no se conectan a los

dispositivos CE son
conocido como "enrutadores P".
Los dispositivos CE pueden ser hosts o enrutadores. En un caso

típico, un sitio
contiene uno o más enrutadores, algunos de los cuales están
conectados a PE
enrutadores Los enrutadores de sitio que se conectan a los
enrutadores PE
ser los dispositivos CE, o "enrutadores CE". Sin embargo, no hay
nada que
evitar que un host sin enrutamiento se una directamente a un
enrutador PE, en
qué caso el host sería un dispositivo CE.
A veces, lo que está conectado físicamente a un enrutador PE es una

capa 2
cambiar. En este caso, NO decimos que el interruptor de capa 2 es
un CE
dispositivo. Por el contrario, los dispositivos CE son los hosts y
enrutadores que
comunicarse con el enrutador PE a través del interruptor de capa 2;
la capa
2 la infraestructura es transparente. Si la infraestructura de capa
2
proporciona un servicio multipunto, luego múltiples dispositivos CE
pueden ser
conectado al enrutador PE sobre el mismo circuito de conexión.
Los dispositivos CE son lógicamente parte de la VPN de un cliente.
Enrutadores PE y P
son lógicamente parte de la red del SP.
El circuito de conexión sobre el que viaja un paquete al pasar de

CE
PE se conoce como "circuito de conexión de ingreso" de ese paquete,
y el
PE como el "ingreso PE" del paquete. El circuito de conexión sobre
el cual
el paquete viaja cuando se pasa de PE a CE se conoce como paquete
de
"circuito de conexión de salida", y el PE como "salida PE" del
paquete.
Diremos que un enrutador PE está conectado a una VPN particular si

es
conectado a un dispositivo CE que se encuentra en un sitio de esa
VPN. Del mismo modo, nosotros
dirá que un enrutador PE está conectado a un sitio en particular si
es
conectado a un dispositivo CE que se encuentra en ese sitio.
Cuando el dispositivo CE es un enrutador, es un par de enrutamiento

del PE (s) para
que está conectado, pero NO es un par de enrutamiento de
enrutadores CE en
otros sitios. Los enrutadores en diferentes sitios no intercambian
directamente
enrutamiento de información entre ellos; de hecho, ni siquiera
necesitan
saber el uno del otro en absoluto. Como consecuencia, el cliente no
tiene
backbone o "backbone virtual" para administrar, y no tiene que
tratar
con cualquier problema de enrutamiento entre sitios. En otras
palabras, en el esquema
descrito en este documento, una VPN NO es una "superposición" en la
parte superior de la
Red de SP.
Con respecto a la administración de los dispositivos de borde,

despeje
los límites administrativos se mantienen entre el SP y su
clientes. Los clientes no están obligados a acceder a los
enrutadores PE o P
para fines de gestión, ni se requiere el SP para acceder al CE
dispositivos para fines de gestión.
1.3 . VPN con espacios de direcciones superpuestos
Si dos VPN no tienen sitios en común, entonces pueden tener

superposición
espacios de direcciones. Es decir, una dirección determinada podría
usarse en VPN V1 como
la dirección del sistema S1, pero en VPN V2 como la dirección de un
sistema completamente diferente S2. Esta es una situación común
cuando
Las VPN utilizan cada una un espacio de direcciones privadas RFC
1918 . Por supuesto, dentro
cada VPN, cada dirección debe ser inequívoca.
Incluso dos VPN que tienen sitios en común pueden tener

superposición
espacios de direcciones, siempre que no haya necesidad de ninguna
comunicación
entre sistemas con tales direcciones y sistemas en los sitios
comunes.
1.4 . VPN con diferentes rutas para el mismo sistema
Aunque un sitio puede estar en múltiples VPN, no es necesariamente

el
caso de que la ruta a un sistema dado en ese sitio debe ser la
misma
en todas las VPN. Supongamos, por ejemplo, que tenemos una intranet
que consiste en los sitios A, B y C, y una extranet que consiste en
A, B,
C, y el sitio "extranjero" D. Supongamos que en el sitio A hay un
servidor, y queremos que los clientes de B, C o D puedan usar ese
servidor. Supongamos también que en el sitio B hay un firewall.
Queremos
todo el tráfico del sitio D al servidor para pasar por el
firewall, para que el tráfico de la extranet pueda ser controlado
por acceso.
Sin embargo, no queremos que el tráfico de C pase a través del
firewall en
el camino al servidor, ya que este es el tráfico de la intranet.
Es posible configurar dos rutas al servidor. Una ruta, usada

por los sitios B y C, toma el tráfico directamente al sitio A. El
segundo
La ruta, utilizada por el sitio D, lleva el tráfico al firewall en
sitio B. Si el firewall permite que pase el tráfico, entonces
aparece
ser tráfico procedente del sitio B y seguir la ruta al sitio A.
1.5 . Enrutadores SP Backbone
La red troncal del SP consiste en los enrutadores PE, así como en

otros
enrutadores ("enrutadores P") que no se conectan a los dispositivos
CE.
Si cada enrutador en la red troncal de un SP tuviera que mantener

el enrutamiento
información para todas las VPN admitidas por el SP, habría
severos problemas de escalabilidad; la cantidad de sitios que
podrían ser
compatible estaría limitado por la cantidad de información de
enrutamiento que
podría mantenerse en un solo enrutador. Por lo tanto, es importante
que
la información de enrutamiento sobre una VPN en particular solo
necesita estar presente
en los enrutadores PE que se conectan a esa VPN. En particular, el
P
los enrutadores no necesitan tener CUALQUIER información de
enrutamiento por VPN
lo que. (Esta condición puede necesitar relajarse un tanto cuando
el enrutamiento multicast es considerado. Esto no se considera más
adelante en
este documento, pero se examina en [ VPN-MCAST ].)
Entonces, así como los propietarios de VPN no tienen una red

troncal o "virtual"
backbone "para administrar, los SP no tienen un separado
backbone o "backbone virtual" para administrar para cada VPN. Site-
to-
el enrutamiento del sitio en la red troncal es óptimo (dentro de
las limitaciones de
las políticas utilizadas para formar las VPN) y no está restringido
de ninguna manera
por una "topología virtual" artificial de túneles.
La Sección 10 discute algunos de los problemas especiales que

surgen cuando
backbone abarca varios proveedores de servicios.
1.6 . Seguridad
VPN del tipo que se discute aquí, incluso sin hacer uso de
medidas de seguridad criptográficas, están destinadas a
proporcionar un nivel de
seguridad equivalente a la que se puede obtener cuando una capa 2
de la columna vertebral (por ejemplo,
Frame Relay). Es decir, en ausencia de una mala configuración o
la interconexión deliberada de diferentes VPN, no es posible
sistemas en una VPN para obtener acceso a sistemas en otra VPN. De
Por supuesto, los métodos aquí descritos no encriptan ellos mismos
datos para privacidad, ni proporcionan una manera de determinar si
los datos
ha sido manipulado en el camino. Si esto es deseado, criptográfico
se deben aplicar medidas adicionales. (Ver, por ejemplo, [MPLS /
BGP-IPsec]).
La seguridad se analiza con más detalle en la Sección 13 .
2 . Sitios y CE
Desde la perspectiva de una red troncal particular, un conjunto de

IP
los sistemas pueden considerarse como un "sitio" si esos sistemas
tienen IP mutua
interconectividad que no requiere el uso de la red troncal. En
En general, un sitio consistirá en un conjunto de sistemas que
están en
proximidad geográfica Sin embargo, esto no es universalmente
cierto. Si dos
las ubicaciones geográficas están conectadas a través de una línea
arrendada, sobre la cual se abre
El protocolo de ruta más corta (OSPF) [ OSPFv2 ] se está
ejecutando, y si eso
línea es la forma preferida de comunicación entre las dos
ubicaciones,
entonces las dos ubicaciones se pueden considerar como un solo
sitio, incluso si cada
la ubicación tiene su propio enrutador CE. (Esta noción de "sitio"
es
topológico, en lugar de geográfico. Si la línea arrendada se cae,
o de lo contrario deja de ser la ruta preferida, pero las dos áreas
geográficas
las ubicaciones pueden seguir comunicándose mediante el uso de la
red troncal VPN, luego
un sitio se ha convertido en dos).
Un dispositivo CE siempre se considera que está en un solo sitio

(aunque como
veremos en la Sección 3.2 , un sitio puede consistir en múltiples
"virtuales
sitios "). Sin embargo, un sitio puede pertenecer a múltiples VPN.
Un enrutador PE puede conectarse a dispositivos CE desde cualquier

cantidad de diferentes
sitios, ya sea que esos dispositivos CE estén en el mismo o en
diferentes VPN.
Un dispositivo CE puede, por su robustez, conectarse a múltiples
enrutadores PE, de
el mismo o de diferentes proveedores de servicios. Si el
dispositivo CE es un
enrutador, el enrutador PE y el enrutador CE aparecerán como
enrutador
adyacencias entre sí.
Mientras hablamos principalmente de "sitios" como la unidad básica

de
interconexión, nada aquí impide un grado más fino de granularidad
en el control de la interconectividad. Por ejemplo, ciertos
sistemas en
un sitio puede ser miembros de una intranet así como miembros de

uno o
más extranets, mientras que otros sistemas en el mismo sitio pueden
ser
restringido a ser miembros de la intranet solamente. Sin embargo,
esto
podría requerir que el sitio tenga dos circuitos de conexión al
backbone, uno para la intranet y otro para la extranet; que podría
Además, se requiere que la funcionalidad del cortafuegos se aplique
en el
circuito de conexión extranet.
3 . VRF: Múltiples tablas de reenvío en PE
Cada enrutador PE mantiene varias tablas de reenvío separadas. Uno

de las tablas de reenvío es la "tabla de reenvío predeterminada".
los
otros son "tablas de enrutamiento y reenvío de VPN" o "VRF".
3.1 . VRF y circuitos de conexión
Cada circuito de conexión PE / CE está asociado, por configuración,

con
uno o más VRF. Un circuito de conexión que está asociado con un
VRF se conoce como un "circuito de conexión VRF".
En el caso más simple y en el caso más típico, un archivo adjunto

PE / CE
el circuito está asociado con exactamente un VRF. Cuando un paquete
de IP es
recibido a través de un circuito de conexión particular, su IP de
destino
la dirección se busca en el VRF asociado. El resultado de eso
la búsqueda determina cómo enrutar el paquete. El VRF utilizado por
un
la PE del ingreso del paquete para enrutar un paquete en particular
se conoce como el
paquete de "ingreso VRF". (También existe la noción de un paquete
"eress VRF", ubicado en la salida PE del paquete; esto se discute
en
Sección 5 )
Si un paquete IP llega a un circuito de conexión que no es

asociado con cualquier VRF, se mira la dirección de destino del
paquete
en la tabla de reenvío predeterminada, y el paquete se enruta
en consecuencia. Paquetes reenviados según el reenvío
predeterminado
tabla incluye paquetes de enrutadores P o PE vecinos, así como
paquetes de circuitos de conexión orientados al cliente que no han
sido
asociado con VRF.
Intuitivamente, uno puede pensar en la tabla de reenvío

predeterminada como
conteniendo "rutas públicas", y de los VRF que contienen "privado
rutas ". Uno puede pensar de manera similar en los circuitos de
enlace VRF como
"privado", y de los circuitos de conexión no VRF como "públicos".
Si un circuito de conexión VRF particular conecta el sitio S con un

PE
enrutador, entonces la conectividad desde S (a través de ese
circuito de conexión) puede ser
restringido al controlar el conjunto de rutas que se ingresan en el
VRF correspondiente. El conjunto de rutas en ese VRF debe ser
limitado
al conjunto de rutas que conducen a sitios que tienen al menos una
VPN en
común con S. Entonces un paquete enviado desde S sobre un archivo

adjunto VRF
el circuito solo puede ser enrutado por el PE a otro sitio S 'si S'
está en
una de las mismas VPN que S. Esto es, comunicación (a través de
enrutadores PE)
se evita entre cualquier par de sitios VPN que no tengan VPN en
común. La comunicación entre los sitios VPN y los sitios que no son
VPN es
impidió mantener las rutas a los sitios VPN fuera del valor
predeterminado
mesa de reenvío
Si hay varios circuitos de conexión que van de S a uno o

más enrutadores PE, entonces podría haber múltiples VRF que podrían
ser utilizados
para enrutar el tráfico desde S. Para restringir adecuadamente la
conectividad de S,
el mismo conjunto de rutas debería existir en todos los VRF.
Alternativamente, uno podría imponer diferentes restricciones de
conectividad
sobre un circuito de conexión diferente de S. En ese caso, algunos
de los
Los VRF asociados con los circuitos de conexión de S contendrían
diferentes conjuntos de rutas que algunos de los otros.
Permitimos el caso en el que un solo circuito de conexión está

asociado
con un conjunto de VRF, en lugar de con un solo VRF. Esto puede ser
útil si se desea dividir una sola VPN en varias
"sub-VPN", cada una con diferentes restricciones de conectividad,
donde algunos
característica de los paquetes del cliente se utiliza para
seleccionar entre
las sub-VPN. Por simplicidad, usualmente hablamos de un
circuito de conexión como asociado a un solo VRF.
3.2 . Asociación de paquetes de IP con VRF
Cuando un enrutador PE recibe un paquete de un dispositivo CE, debe

determinar el circuito de conexión sobre el cual llegó el paquete,
como
esto determina a su vez el VRF (o conjunto de VRF) que se puede
usar para
reenviando ese paquete. En general, para determinar el archivo
adjunto
circuito sobre el cual llegó un paquete, un enrutador PE toma nota
del
interfaz física a través de la cual llegó el paquete, y
posiblemente también
toma nota de algún aspecto del encabezado de capa 2 del paquete.
por
ejemplo, si el circuito de conexión de entrada de un paquete es un
Frame Relay
VC, la identidad del circuito de conexión se puede determinar a
partir de
interfaz física Frame Relay a través de la cual llegó el paquete,
junto con el campo Identificador de conexión de enlace de datos
(DLCI) en el
Encabezado de Frame Relay del paquete.
Aunque la conclusión de la PE de que un paquete en particular llegó

a un
circuito de conexión particular puede estar parcialmente
determinado por el
encabezado de capa 2 del paquete, debe ser imposible para un
cliente, por
escribiendo los campos del encabezado, para engañar al SP y hacerle
pensar que un paquete
que se recibió en un circuito de conexión realmente llegó a través
de un
uno diferente. En el ejemplo anterior, aunque el circuito de
conexión
se determina parcialmente mediante la inspección del campo DLCI en
el Marco
Encabezado de transmisión, este campo no puede ser configurado
libremente por el cliente.

Por el contrario, debe establecerse en un valor especificado por el
SP, o bien el
el paquete no puede llegar al enrutador PE.
En algunos casos, el cliente puede dividir un sitio en particular

en
varios "sitios virtuales". El SP puede designar un conjunto
particular de
VRF que se utilizarán para enrutar paquetes de ese sitio y pueden
permitir el
cliente para establecer algunas características del paquete, que
luego se utiliza
para elegir un VRF particular del conjunto.
Por ejemplo, cada sitio virtual puede realizarse como una VLAN. El
SP
y el cliente podría estar de acuerdo en que los paquetes que llegan
de un
CE particular, ciertos valores de VLAN se usarían para identificar
ciertos
VRFs. Por supuesto, los paquetes de ese CE serían descartados por
el PE
si llevan valores de etiqueta de VLAN que no están en el conjunto
acordado.
Otra forma de lograr esto es usar direcciones de origen de IP. En
En este caso, el PE usa la dirección de origen de IP en un paquete
recibido
del CE, junto con la interfaz sobre la cual se encuentra el paquete
recibido, para asignar el paquete a un VRF particular. Nuevamente,
el
el cliente solo podrá seleccionar entre el conjunto particular
de VRF que ese cliente puede usar.
Si se desea tener un host particular en múltiples virtuales

sitios, entonces ese host debe determinar, para cada paquete, qué
virtual
el sitio al que está asociado el paquete. Puede hacer esto, por
ejemplo, enviando
paquetes de diferentes sitios virtuales en diferentes VLAN, o fuera
diferentes interfaces de red.
3.3 . Poblando los VRF
¿Con qué conjunto de rutas se llenan los VRF?
Como ejemplo, permita que PE1, PE2 y PE3 sean tres enrutadores PE,
y deje que
CE1, CE2 y CE3 serán tres enrutadores CE. Supongamos que PE1
aprende, desde
CE1, las rutas que se pueden alcanzar en el sitio de CE1. Si PE2 y
PE3 son
adjuntas, respectivamente, a CE2 y CE3, y hay algunas VPN V
que contiene CE1, CE2 y CE3, luego PE1 usa BGP para distribuir a
PE2
y PE3 las rutas que aprendió de CE1. Uso de PE2 y PE3
estas rutas para poblar los VRF que asocian, respectivamente,
con los sitios de CE2 y CE3. Rutas de sitios que no están en VPN
V no aparecen en estos VRF, lo que significa que los paquetes de
CE2 o
CE3 no se puede enviar a sitios que no están en VPN V.
Cuando hablamos de una PE "aprendiendo" rutas desde un CE, no somos

presuponiendo cualquier técnica de aprendizaje particular. El PE
puede aprender
rutas por medio de un algoritmo de enrutamiento dinámico, pero
también puede
"aprender" rutas al tener esas rutas configuradas (es decir,
estática
enrutamiento). (En este caso, decir que el PE "aprendió" las rutas
del CE es tal vez para ejercer un poco de licencia poética.)
Los PE también necesitan aprender, de otros PE, las rutas que

pertenecen a un
dado VPN. Los procedimientos que se utilizarán para poblar los VRF
con
los conjuntos adecuados de rutas se especifican en la Sección 4 .
Si hay múltiples circuitos de conexión que conducen desde un

particular
Enrutador PE a un sitio en particular, todos podrían estar
asignados al mismo
mesa de reenvío Pero si la política lo dicta, podrían asignarse a
diferentes tablas de envío. Por ejemplo, la política podría ser que
un circuito de conexión particular de un sitio se usa solo para
intranet
tráfico, mientras que otro circuito de conexión desde ese sitio se
usa solo
para el tráfico de extranet (Tal vez, por ejemplo, el CE adjunto a
la
el circuito de conexión extranet es un cortafuegos, mientras que el
CE está conectado a
el circuito de conexión de la intranet no lo es). En este caso, los
dos
los circuitos de conexión se asociarían con diferentes VRF.
Tenga en cuenta que si dos circuitos de conexión están asociados

con el mismo
VRF, luego los paquetes que recibe el PE sobre uno de ellos podrán
para llegar exactamente al mismo conjunto de destinos que los
paquetes que el PE
recibe sobre el otro. Entonces dos circuitos de conexión no pueden
ser
asociado con el mismo VRF a menos que cada CE esté en el mismo
conjunto exacto
de VPNs como es el otro.
Si un circuito de conexión conduce a un sitio que está en múltiples

VPN,
el circuito de conexión aún puede estar asociado con un solo VRF,
en
En ese caso, el VRF contendrá rutas del conjunto completo de VPN de
de la cual el sitio es miembro.
4 . Distribución de rutas VPN a través de BGP
Los enrutadores PE usan BGP para distribuir rutas VPN entre sí (más
con precisión, para hacer que las rutas VPN se distribuyan entre
sí).
Permitimos que cada VPN tenga su propio espacio de direcciones, lo

que significa que
la dirección dada puede denotar diferentes sistemas en diferentes
VPN. Si dos
las rutas al mismo prefijo de la dirección IP son en realidad rutas
a diferentes
sistemas, es importante asegurarse de que BGP no los trate como
comparable. De lo contrario, BGP podría optar por instalar solo uno
de ellos,
haciendo que el otro sistema sea inalcanzable Además, debemos
asegurarnos de que
POLICY se utiliza para determinar qué paquetes se envían en qué
rutas;
dado que BGP instala varias de estas rutas, solo una de ellas
debe aparecer en cualquier VRF particular.
Cumplimos estos objetivos mediante el uso de una nueva familia de

direcciones, tal como se especifica
abajo.
4.1 . La familia de direcciones VPN-IPv4
Las Extensiones Multiprotocolo BGP [ BGP-MP ] permiten a BGP llevar

rutas
de múltiples "familias de direcciones". Introducimos la noción de
"Familia de direcciones VPN-IPv4". Una dirección VPN-IPv4 es una
cantidad de 12 bytes,
comenzando con un Distinguidor de ruta de 8 bytes (RD) y terminando
con un
Dirección IPv4 de 4 bytes. Si varias VPN usan la misma dirección
IPv4
prefijo, los PE traducen estos en dirección única VPN-IPv4
prefijos. Esto asegura que si se usa la misma dirección en varios
diferentes VPNs, es posible que BGP lleve varios completamente
diferentes rutas a esa dirección, una para cada VPN.
Dado que las direcciones VPN-IPv4 y las direcciones IPv4 son

direcciones diferentes
familias, BGP nunca los trata como direcciones comparables.
Un RD es simplemente un número, y no contiene ningún inherente

información; no identifica el origen de la ruta o el conjunto
de las VPN a las que se distribuirá la ruta. El propósito de
RD es únicamente para permitir que uno cree rutas distintas a un
IPv4 común
prefijo de dirección Se usan otros medios para determinar dónde
redistribuir la ruta (ver Sección 4.3 ).
El RD también se puede usar para crear múltiples rutas diferentes

al
mismo sistema Ya hemos discutido una situación en la que
la ruta a un servidor en particular debería ser diferente para el
tráfico de intranet
que para el tráfico de extranet Esto se puede lograr creando dos
diferentes rutas VPN-IPv4 que tienen la misma parte IPv4, pero
diferentes
RDs. Esto permite a BGP instalar múltiples rutas diferentes al
mismo sistema, y permite que se use la política (ver Sección 4.3.5
) para
decidir qué paquetes usan qué ruta.
Los RD están estructurados para que cada proveedor de servicios

pueda administrar
su propio "espacio de numeración" (es decir, puede hacer sus
propias asignaciones de
RDs), sin entrar en conflicto con las asignaciones de RD realizadas
por cualquier otro
Proveedor de servicio. Un RD consta de tres campos: un tipo de 2
bytes
campo, un campo de administrador y un campo de número asignado. los
el valor del campo de tipo determina las longitudes de los otros
dos
campos, así como la semántica del campo de administrador. los
El campo de administrador identifica una autoridad de número
asignada, y el
El campo de número asignado contiene un número que ha sido
asignado, por
la autoridad identificada, para un propósito particular. Por
ejemplo, uno
podría tener un RD cuyo campo de administrador contiene un autónomo
Número de sistema (ASN) y cuyo campo de número (4 bytes) contiene
un
número asignado por el SP al que pertenece ese ASN (habiendo sido
asignado a ese SP por la autoridad apropiada).
Los RD tienen esta estructura para asegurar que un SP que

proporciona el servicio de red troncal de VPN siempre puede crear
un RD único cuando

necesita hacerlo Sin embargo, la estructura no es significativa

para BGP;
cuando BGP compara dos de estos prefijos de dirección, ignora la
estructura
enteramente.
Un PE debe configurarse de manera que las rutas que conducen a un

particular CE se asocia con un RD particular. los
la configuración puede causar que todas las rutas que conducen al
mismo CE sean
asociado con el mismo RD, o puede causar rutas diferentes para ser
asociados con diferentes RD, incluso si conducen a la misma CE.
4.2 . Codificación de Distinguishers de ruta
Como se indicó, una dirección VPN-IPv4 consiste en una ruta de 8

bytes
Distinguador seguido de una dirección IPv4 de 4 bytes. Los RD están
codificados
como sigue:
- Tipo de campo: 2 bytes

- Campo de valor: 6 bytes
La interpretación del campo Valor depende del valor del

tipo campo En la actualidad, tres valores del campo tipo son
definido: 0, 1 y 2.
- Tipo 0: el campo Valor consta de dos subcampos:
* Subcampo del administrador: 2 bytes

* Subcampo del número asignado: 4 bytes
El subcampo Administrador debe contener un Sistema Autónomo

número. Si este ASN es del espacio público de ASN, debe tener
ha sido asignado por la autoridad apropiada (uso de valores ASN
desde el espacio ASN privado se recomienda enfáticamente). los
El subcampo Número asignado contiene un número de un espacio de
numeración
que es administrado por la empresa a la que ha sido asignado el
ASN
asignado por una autoridad apropiada.

El subcampo Administrador debe contener una dirección IP. Si

esto
La dirección IP proviene del espacio de direcciones IP
públicas, debe haber sido
asignado por una autoridad apropiada (uso de direcciones del
el espacio de direcciones IP privadas no se recomienda). El
Asignado
Subcampo número contiene un número de un espacio de numeración
que es
administrado por la empresa a la cual la dirección IP ha sido
asignado

El subcampo Administrador debe contener un Autónomo de 4 bytes

Número de sistema [ BGP-AS4 ]. Si este ASN es del público ASN
espacio, debe haber sido asignado por la autoridad
correspondiente
(el uso de valores ASN del espacio ASN privado es fuertemente
desanimado). El subcampo Número asignado contiene un número
desde un espacio de numeración administrado por la empresa para
el ASN ha sido asignado por una autoridad apropiada.
4.3 . Control de la distribución de rutas
En esta sección, discutimos la forma en que la distribución del

Las rutas VPN-IPv4 están controladas.
Si un enrutador PE está conectado a una VPN en particular (al estar

conectado a
un CE particular en esa VPN), aprende algunas de las rutas IP de
esa VPN
desde el enrutador CE adjunto. Rutas aprendidas de un par de
enrutamiento CE
sobre un circuito de conexión particular se puede instalar en el
VRF
asociado con ese circuito de conexión. Exactamente qué rutas son
instalado de esta manera está determinado por la forma en que el PE
aprende rutas desde el CE. En particular, cuando el PE y CE son
Pares de protocolo de enrutamiento, esto está determinado por el
proceso de decisión de
el protocolo de enrutamiento; esto se discute en la Sección 7 .
Estas rutas se convierten en rutas VPN-IP4 y se "exportan" a

BGP. Si hay más de una ruta a una dirección VPN-IP4 en particular
prefijo, BGP elige el "mejor", utilizando el proceso de decisión
BGP.
Esa ruta luego es distribuida por BGP al conjunto de otros PE que
necesito saber sobre eso En estos otros PE, BGP volverá a elegir el
mejor ruta para un prefijo de dirección VPN-IP4 en particular.
Entonces el elegido
Las rutas VPN-IP4 se convierten nuevamente en rutas IP e
"importadas" en
uno o más VRF. Si están realmente instalados en los VRF
depende del proceso de decisión del método de enrutamiento
utilizado entre
el PE y aquellos CE que están asociados con el VRF en cuestión.
Finalmente, cualquier ruta instalada en un VRF se puede distribuir
a la
routers CE asociados.
4.3.1 . El atributo de destino de ruta
Cada VRF está asociado con uno o más objetivos de ruta (RT)
atributos.
Cuando se crea una ruta VPN-IPv4 (desde una ruta IPv4 que el PE
tiene
aprendido de un CE) por un enrutador PE, está asociado con uno o
más
Ruta de los atributos de destino. Estos se llevan en BGP como

atributos de
la ruta.
Cualquier ruta asociada con Route Target T debe distribuirse a cada

Enrutador PE que tiene un VRF asociado con el objetivo de ruta T.
Cuando tal
ruta es recibida por un enrutador PE, es elegible para ser
instalado en
aquellos de los VRF de PE que están asociados con Route Target T.
(Si realmente se instala depende del resultado de la
Proceso de decisión BGP, y sobre el resultado del proceso de
decisión de
el IGP (es decir, el protocolo de enrutamiento dentro del dominio)
que se ejecuta en el
Interfaz PE / CE.)
Se puede considerar que un atributo de destino de ruta identifica

un conjunto de
sitios. (Aunque sería más preciso pensar en ello como
identificar un conjunto de VRF.) Asociar un objetivo de ruta
particular
atributo con una ruta permite que esa ruta se coloque en los VRF
que se utilizan para enrutar el tráfico que se recibe del
sitios correspondientes.
Hay un conjunto de Destinos de ruta que un enrutador PE une a una

ruta
recibido del sitio S; estos pueden llamarse los "Objetivos de
exportación". Y
hay un conjunto de Destinos de ruta que usa un enrutador PE para
determinar
si una ruta recibida desde otro enrutador PE podría ubicarse en
el VRF asociado con el sitio S; estos pueden llamarse "Importar
Objetivos ". Los dos conjuntos son distintos y no es necesario que
sean iguales.
que una determinada ruta VPN-IPv4 solo es elegible para su
instalación en
un VRF particular si hay algún objetivo de ruta que sea a la vez
los Destinos de ruta de la ruta y uno de los Objetivos de
importación de VRF.
La función realizada por el atributo de destino de ruta es similar

a
realizado por el atributo BGP Communities. Sin embargo, el formato
de este último es inadecuado para los propósitos actuales, ya que
permite
solo un espacio de numeración de 2 bytes. Es deseable estructurar
el
formato, similar a lo que hemos descrito para los RD (ver Sección
4.2) ),
para que un campo de tipo defina la longitud de un campo de
administrador,
y el resto del atributo es un número del especificado
espacio de numeración del administrador. Esto se puede hacer usando
BGP Extended
Comunidades. Los destinos de ruta discutidos en este documento
están codificados como BGP
Destinos de ruta de la comunidad extendida [ BGP-EXTCOMM ]. Están
estructurados
de manera similar a los RD.
Cuando un altavoz BGP ha recibido más de una ruta a la misma VPN-

Prefijo IPv4, las reglas BGP para preferencia de ruta se utilizan
para elegir
qué ruta VPN-IPv4 está instalada por BGP.
Tenga en cuenta que una ruta solo puede tener un RD, pero puede
tener múltiples
Route Targets. En BGP, la escalabilidad se mejora si uno tiene un
solo
ruta con múltiples atributos, a diferencia de múltiples rutas. Uno
podría eliminar el atributo de ruta de destino creando más rutas

(es decir, utilizando más RD), pero las propiedades de escala
serían menos
favorable.
¿Cómo determina un PE qué atributos de destino de ruta asociarse?

con una ruta dada? Hay una serie de diferentes formas posibles.
El PE se puede configurar para asociar todas las rutas que conducen
a un
sitio especificado con un objetivo de ruta especificado. O el PE
podría ser
configurado para asociar ciertas rutas que conducen a un sitio
específico
con un objetivo de ruta, y cierto con otro.
Si el PE y el CE son en sí mismos pares BGP (ver Sección 7 ),

entonces
el SP puede permitir al cliente, dentro de los límites, especificar
cómo se
las rutas deben ser distribuidas. El SP y el cliente necesitarían
acordar de antemano el conjunto de RT que se pueden adjuntar a
las rutas VPN del cliente. El CE podría adjuntar uno o más de
esos RTs a cada ruta IP que distribuye al PE. Esto da
el cliente tiene la libertad de especificar en tiempo real, dentro
de lo acordado
límites, sus políticas de distribución de rutas. Si el CE está
permitido
adjuntar RTs a sus rutas, el PE DEBE filtrar todas las rutas que
contienen RT que el cliente no puede usar. Si el CE es
no se le permite adjuntar RT a sus rutas, pero de todos modos lo
hace, el PE
DEBE eliminar la RT antes de convertir la ruta del cliente a una
VPN-
Ruta IPv4
4.3.2 . Distribución de rutas entre PE por BGP
Si dos sitios de una VPN se unen a PE que están en la misma

Autónoma
Sistema, los PE pueden distribuir rutas VPN-IPv4 entre sí por
de una conexión IBGP entre ellos. (El término "IBGP" se refiere a
la
conjunto de protocolos y procedimientos utilizados cuando hay una
conexión BGP
entre dos altavoces BGP en el mismo Sistema Autónomo. Esto es
se distingue de "EBGP", el conjunto de procedimientos utilizados
entre dos BGP
altavoces en diferentes Sistemas Autónomos). Alternativamente, cada
uno puede
tener una conexión IBGP a un reflector de ruta [ BGP-RR ].
Cuando un enrutador PE distribuye una ruta VPN-IPv4 a través de

BGP, utiliza su
propia dirección como el "BGP next hop". Esta dirección está
codificada como
Dirección VPN-IPv4 con un RD de 0. ([ BGP-MP ] requiere que el
siguiente
la dirección de salto debe estar en la misma familia de direcciones
que la capa de red
Información de Accesibilidad (NLRI)). También asigna y distribuye
un
Etiqueta MPLS. (Básicamente, los enrutadores PE no distribuyen las
rutas VPN-IPv4,
pero con las rutas VPN-IPv4 etiquetadas. Cf. [ MPLS-BGP ].) Cuando
los procesos de PE
un paquete recibido que tiene esta etiqueta en la parte superior de
la pila, el PE
abrirá la pila y procesará el paquete de manera apropiada.
El PE puede distribuir el conjunto exacto de rutas que aparece en

el
VRF, o puede realizar un resumen y distribuir agregados de
esas rutas, o puede hacer algo de una y parte de la otra.
Supongamos que un PE ha asignado la etiqueta L a la ruta R, y tiene

distribuyó este mapeo de etiquetas a través de BGP. Si R es un
agregado de un
conjunto de rutas en el VRF, el PE sabrá que los paquetes del
la red troncal que llega con esta etiqueta debe tener su destino
direcciones buscadas en un VRF. Cuando el PE busca la etiqueta en
su
Label Information Base, aprende qué VRF se debe utilizar. Sobre el
Por otro lado, si R no es un agregado, entonces cuando el PE mira
hacia arriba,
etiqueta, aprende el circuito de conexión de salida, así como
encabezado de encapsulamiento para el paquete. En este caso, no hay
búsqueda en el
VRF está hecho.
Es de esperar que el caso más común sea el caso donde

la ruta NO es un agregado. El caso donde es un agregado puede ser
muy útil, aunque si el VRF contiene una gran cantidad de rutas de
host
(por ejemplo, como en el acceso telefónico), o si el VRF tiene un
área local asociada
Interfaz de red (LAN) (donde hay una capa de salida 2 diferente
encabezado para cada sistema en la LAN, pero una ruta no se
distribuye
cada uno de esos sistemas).
Si o no cada ruta tiene una etiqueta distinta es una implementación

importar. Hay una serie de algoritmos posibles que uno podría usar
para
determinar si a dos rutas se les asigna la misma etiqueta:
- Uno puede elegir tener una sola etiqueta para un VRF completo,
de modo que
una sola etiqueta es compartida por todas las rutas desde ese
VRF. Entonces
cuando el PE de egreso recibe un paquete con esa etiqueta, debe
busca la dirección IP de destino del paquete en ese VRF (el
"salida VRF" del paquete), para determinar la salida del
paquete
circuito de conexión y la correspondiente encapsulación de
enlace de datos.
- Uno puede elegir tener una sola etiqueta para cada archivo
adjunto
circuito, de modo que una sola etiqueta sea compartida por
todas las rutas con
el mismo "circuito de conexión saliente". Esto permite a uno
evitar hacer una búsqueda en el VRF de egreso, aunque algún
tipo de
es posible que deba realizarse una búsqueda para determinar el
enlace de datos
encapsulación, por ejemplo, una búsqueda de Protocolo de
resolución de direcciones (ARP).
- Se puede elegir tener una etiqueta distinta para cada ruta.

Entonces sí
una ruta es potencialmente alcanzable en más de un archivo
adjunto
circuito, el enrutamiento PE / CE puede cambiar la ruta
preferida para un
ruta de un circuito de conexión a otro, sin que haya
cualquier necesidad de distribuir una nueva etiqueta para esa
ruta.
Puede haber otros algoritmos posibles también. La elección de

algoritmo está enteramente a discreción del egreso PE, y es
de lo contrario, transparente.
Al usar etiquetas MPLS distribuidas por BGP de esta manera,

presuponemos
que un paquete MPLS que lleva dicha etiqueta se puede tunelizar
desde el
enrutador que instala la ruta distribuida BGP correspondiente a la
enrutador que es el siguiente salto BGP de esa ruta. Esto requiere
cualquiera
que existe una ruta de etiqueta conmutada entre esos dos
enrutadores o de lo contrario
que alguna otra tecnología de tunelización (p. ej., [ MPLS-in-IP-
GRE ]) puede ser
usado entre ellos.
Este túnel puede seguir una ruta de "mejor esfuerzo", o puede

seguir un
ruta de ingeniería de tráfico. Entre un par dado de enrutadores,
puede haber
ser uno de esos túneles, o puede haber varios, tal vez con
diferentes
Características de calidad de servicio (QoS). Todo lo que importa
para el
La arquitectura VPN es que existe tal túnel. Para asegurar
interoperabilidad entre los sistemas que implementan esta
arquitectura VPN
utilizando trayectos conmutados de etiqueta MPLS como tecnología de
tunelización, todos los
los sistemas DEBEN soportar el Protocolo de Distribución de
Etiquetas (LDP) [ MPLS-LDP ].
En particular, el modo Downstream Unsolicited DEBE ser compatible
con
interfaces que no son ATM con control de etiqueta (LC-ATM) [ MPLS-
ATM ]
ni interfaces de Frame Relay Frame Relay controlado (LC-FR) [ MPLS-
FR ], y
El modo Downstream On Demand DEBE ser compatible con las interfaces
LC-ATM y
Interfaces LC-FR.
Si el túnel sigue una ruta de mejor esfuerzo, entonces el PE

encuentra el
ruta al punto final remoto buscando su dirección IP en el
tabla de reenvío predeterminada.
Un enrutador PE, A MENOS que sea un reflector de ruta (ver Sección

4.3.3 ) o un
Enrutador de borde del sistema autónomo (ASBR) para una VPN entre
proveedores (ver
Sección 10 ), no debe instalar una ruta VPN-IPv4 a menos que tenga
al menos un VRF con un objetivo de importación idéntico a uno de
los
Ruta de los atributos de destino. El filtrado entrante debe usarse
para causar
tales rutas para ser descartadas Si un nuevo objetivo de
importación se agrega más tarde
a uno de los VRF de PE (una operación "VPN Join"), debe entonces
adquirir las rutas que previamente pudo haber descartado. Esto
puede ser
hecho utilizando el mecanismo de actualización descrito en [ BGP-
RFSH ]. los
El mecanismo de filtrado de ruta saliente de [ BGP-ORF ] también se
puede usar para
ventaja para hacer el filtrado más dinámico.
Del mismo modo, si un objetivo de importación particular ya no está

presente en ningún
de los VRF de un PE (como resultado de una o más operaciones de
"VPN Prune"),
el PE puede descartar todas las rutas que, como resultado, ya no
tienen ninguna
de los objetivos de importación del VRF de PE como uno de sus
objetivos de ruta
atributos.
Un enrutador que no está conectado a ninguna VPN y que no es una

ruta
Reflector (es decir, un enrutador P) nunca instala ninguna ruta
VPN-IPv4 en
todas.
Tenga en cuenta que las operaciones VPN Join y Prune no son

disruptivas y no
requiere que se bajen todas las conexiones BGP, siempre queSe usa
el
mecanismo de actualización de [ BGP-RFSH ].
Como resultado de estas reglas de distribución, nadie PE nunca

necesita
mantener todas las rutas para todas las VPN; esta es una
escalabilidad importante
consideración.
4.3.3 . Uso de Reflectores de ruta
En lugar de tener una malla de IBGP completa entre los PE, es

ventajoso utilizar BGP Route Reflectors [ BGP-RR ] para mejorar
escalabilidad. Todas las técnicas usuales para usar reflectores de
ruta para
mejorar la escalabilidad (p. ej., jerarquías de reflector de ruta)
son
disponible.
Reflectores de ruta son los únicos sistemas que necesitan tener

enrutamiento
información para VPNs a las que no están conectados directamente.
Sin embargo, no es necesario tener un reflector de una ruta saber
todo
las rutas VPN-IPv4 para todas las VPN soportadas por la red
troncal.
Describimos a continuación dos formas diferentes de dividir el

conjunto de VPN-IPv4
rutas entre un conjunto de reflectores de ruta.
1. Cada reflector de ruta está preconfigurado con una lista de

ruta
Objetivos Para la redundancia, más de un reflector de ruta
puede ser
preconfigurado con la misma lista. Un reflector de ruta usa
el
lista preconfigurada de objetivos de ruta para construir su
entrada
filtrado de ruta El reflector de ruta puede usar las técnicas
de
[ BGP-ORF ] para instalar en cada uno de sus pares
(independientemente de
si el par es otro reflector de ruta o PE) el conjunto de
Filtros de ruta de salida (ORF) que contiene la lista de su
Destinos de ruta preconfigurados. Tenga en cuenta que los
reflectores de ruta deberían
aceptar ORFs de otros reflectores de ruta, lo que significa
que la ruta
los reflectores deben anunciar la capacidad de ORF a otra
ruta
reflectores
Un proveedor de servicios puede modificar la lista de rutas

preconfiguradas
Objetivos en un reflector de ruta. Cuando esto se hace, la
ruta
reflector modifica los ORF que instala en todos sus IBGP
pares. Para reducir la frecuencia de los cambios de
configuración en
reflectores de ruta, cada reflector de ruta puede
preconfigurarse
con un bloque de Route Targets. De esta manera, cuando una
nueva ruta
El objetivo es necesario para una nueva VPN, ya existe una o
más
reflectores de ruta que están (pre) configurados con esta

ruta
Objetivo.
A menos que un PE dado sea un cliente de todos los

reflectores de ruta, cuando
se agrega una nueva VPN al PE ("VPN Join"), necesitará
convertirse
un cliente de reflector (es) de ruta que mantiene rutas para
esa VPN. Del mismo modo, eliminar una VPN existente del PE
("VPN
Prune ") puede resultar en una situación en la que el PE ya
no necesita
ser un cliente de algún reflector (es) de ruta. En cualquier
caso, el
La operación Join or Prune no es disruptiva (siempre que
[ BGP-RFSH ] se usa, y nunca requiere una conexión BGP para
ser
derribado, solo para ser devuelto nuevamente.
(Al "agregar una nueva VPN a una PE", realmente queremos

agregar una nueva
importar Route Target a uno de sus VRF, o agregar un nuevo
VRF
con un destino de ruta de importación no tenido por
cualquiera de los otros PE
VRFs)
2. Otro método es hacer que cada PE sea un cliente de algún

subconjunto de
los reflectores de ruta. Un reflector de ruta no está
preconfigurado
con la lista de objetivos de ruta, y no realiza el ingreso
el filtrado de ruta de las rutas recibidas de sus clientes
(PE);
más bien, acepta todas las rutas recibidas de todos sus
clientes (PE). El reflector de ruta realiza un seguimiento
del conjunto de
los Destinos de ruta transportados por todas las rutas que
recibe. Cuando
el reflector de ruta recibe de su cliente una ruta con un
Ruta de destino que no está en este conjunto, este objetivo
de ruta es
inmediatamente agregado al conjunto. Por otro lado, cuando el
reflector de ruta ya no tiene ninguna ruta con un particular
Ruta de destino que está en el conjunto, el reflector de ruta
debe
retrasar (en unas pocas horas) la eliminación de este
objetivo de ruta de
el conjunto.
El reflector de ruta usa este conjunto para formar la ruta de

entrada
filtros que aplica a rutas recibidas de otra ruta
reflectores El reflector de ruta también puede usar ORFs para
instalar
el filtrado de ruta de salida apropiado en otra ruta
reflectores Al igual que con el primer enfoque, una ruta
el reflector debería aceptar ORF de otros reflectores de
ruta. A
lograr esto, un reflector de ruta anuncia la capacidad de ORF
para
otros reflectores de ruta.
Cuando el reflector de ruta cambia el conjunto, debe

inmediatamente
cambiar su filtrado de ruta entrante. Además, si la ruta
reflector utiliza ORFs, entonces los ORF deben ser
inmediatamente
cambiado para reflejar los cambios en el conjunto. Si la ruta
reflector no usa ORFs, y se agrega un nuevo destino de ruta a
el conjunto, el reflector de ruta, después de cambiar su ruta

de entrada
filtrando, debe emitir BGP Refresh a otros reflectores de
ruta.
La demora de "unas pocas horas" mencionada anteriormente

permite una ruta
reflector para mantener las rutas con una RT dada, incluso
después de
pierde el último de sus clientes que están interesados en tal
rutas Esto protege contra la necesidad de volver a adquirir
todos los
rutas si la "desaparición" de los clientes es solo temporal.
Con este procedimiento, las operaciones VPN Join y Prune

también son
sin interrupciones
Tenga en cuenta que esta técnica no funcionará correctamente

si algún cliente
PE tiene un VRF con un destino de ruta de importación que no
es uno de
exportar objetivos de ruta.
En estos procedimientos, un enrutador PE que se conecta a una VPN
en particular
"descubre automáticamente" los otros PE que se conectan a la misma
VPN. Cuando un
Se agrega un nuevo enrutador PE, o cuando un enrutador PE existente
se conecta a un
nueva VPN, no se necesita reconfiguración de otros enrutadores PE.
Así como no hay un enrutador PE que necesite conocer todo el VPN-

IPv4
rutas compatibles con la red troncal, estas reglas de distribución
garantizan
que no hay un Reflector de Ruta (RR) que necesite conocer todo el
Rutas VPN-IPv4 soportadas por la red troncal. Como resultado, el
total
número de rutas que pueden ser soportadas por la red troncal no es
limitada por la capacidad de cualquier dispositivo individual, y
por lo tanto puede
aumentar virtualmente sin límite.
4.3.4 . Cómo se lleva VPN-IPv4 NLRI en BGP
Las Extensiones Multiprotocolo BGP [ BGP-MP ] se utilizan para

codificar el
NLRI. Si el campo Identificador de familia de direcciones (AFI)
está establecido en 1, y
el campo Identificador de familia de dirección posterior (SAFI)
está establecido en 128,
el NLRI es una dirección VPN-IPv4 etiquetada MPLS. AFI 1 se usa
desde
el protocolo de capa de red asociado con el NLRI sigue siendo IP.
Tenga en cuenta que esta arquitectura VPN no requiere la capacidad
de
distribuir direcciones VPN-IPv4 sin etiqueta.
Para que dos altavoces BGP intercambien NLRI VPN-IPv4 etiquetados,

debe usar BGP Capabilities Advertisement para asegurarse de que
ambos estén
capaz de procesar adecuadamente tal NLRI. Esto se hace como se
especifica
en [ BGP-MP ], utilizando el código de capacidad 1 (multiprotocolo
BGP), con un
AFI de 1 y un SAFI de 128.
El VPN-IPv4 NLRI etiquetado se codifica como se especifica en

[ MPLS-BGP ], donde el prefijo consiste en un RD de 8 bytes seguido
de un
Prefijo IPv4.

4.3.5 . Creación de VPN utilizando destinos de ruta
Al configurar los Objetivos de importación y Objetivos de

exportación correctamente, uno puede
construir diferentes tipos de VPN.
Supongamos que se desea crear un grupo cerrado de usuarios

completamente mallados,
es decir, un conjunto de sitios donde cada uno puede enviar tráfico
directamente al
otro, pero no se puede enviar ni recibir tráfico desde otros
sitios.
Luego, cada sitio se asocia con un VRF, un único destino de ruta
atributo se elige, ese objetivo de ruta se asigna a cada VRF como
tanto el objetivo de importación como el objetivo de exportación, y
ese objetivo de ruta
no está asignado a ningún otro VRF como el objetivo de importación
o el
Objetivo de exportación.
Alternativamente, supongamos que se desea, por cualquier razón,

crear un
tipo de "hub and spoke" tipo de VPN. Esto podría hacerse mediante
el uso de dos
Los valores de ruta de destino, uno significa "Hub" y uno que
significa "Spoke". A
los VRF adjuntos a los sitios del concentrador, "Hub" es el
objetivo de exportación y
"Habló" es el objetivo de importación. En los VRF adjuntos al radio

sitio, "Hub" es el objetivo de importación y "Spoke" es el objetivo
de exportación.
Por lo tanto, los métodos para controlar la distribución de

enrutamiento
la información entre varios conjuntos de sitios es muy flexible,
que en
turn proporciona una gran flexibilidad en la construcción de VPN.
4.3.6 . Distribución de ruta entre VRF en un solo PE
Es posible distribuir rutas de un VRF a otro, incluso si

ambos VRF están en el mismo PE, aunque en este caso no se puede
decir
que la ruta ha sido distribuida por BGP. Sin embargo, el
decisión de distribuir una ruta particular de un VRF a otro
dentro de un solo PE es la misma decisión que se tomaría si el
VRF estaban en diferentes PE. Es decir, depende del objetivo de la
ruta
atributo que se asigna a la ruta (o se le asignaría si
ruta fue distribuida por BGP), y el objetivo de importación de la
segunda
VRF.
5 . Reenvío
Si los enrutadores intermedios en la red troncal no tienen ningún

información sobre las rutas a las VPN, cómo se reenvían los
paquetes
de un sitio VPN a otro?
Cuando un PE recibe un paquete IP de un dispositivo CE, elige un

un VRF particular en el que buscar la dirección de destino del
paquete.
Esta elección se basa en el circuito de conexión de ingreso del
paquete.
Suponga que se encuentra una coincidencia. Como resultado,

aprendemos el paquete
"siguiente salto".
Si el próximo salto del paquete se alcanza directamente sobre un

archivo adjunto VRF
circuito desde este PE (es decir, el circuito de conexión de salida
del paquete es
en el mismo PE como su circuito de conexión de entrada), entonces
el paquete es
enviado en el circuito de conexión de egreso, y no se empujan
etiquetas MPLS
en la pila de etiquetas del paquete.
Si los circuitos de conexión de entrada y salida están en el mismo

PE, pero
están asociados con diferentes VRF, y si la ruta es la mejor
coincide con la dirección de destino en el circuito de conexión de
entrada
VRF es un agregado de varias rutas en el archivo adjunto de egreso
VRF del circuito, puede ser necesario buscar el paquete
dirección de destino en el VRF de salida también.
Si el próximo salto del paquete NO se alcanza a través de un

archivo adjunto VRF
circuito, entonces el paquete debe viajar al menos un salto a
través del
columna vertebral. El paquete tiene un "BGP Next Hop" y el BGP Next
Hop
tendrá asignada una etiqueta MPLS para la ruta que mejor se adapte
a la
dirección de destino del paquete. Llame a esta etiqueta la
"etiqueta de ruta VPN".
El paquete IP se convierte en un paquete MPLS con la etiqueta de
ruta VPN
como la única etiqueta en la pila de etiquetas.
El paquete se debe tunelizar al BGP Next Hop.
Si la red troncal admite MPLS, esto se hace de la siguiente manera:
- Los enrutadores PE (y cualquier enrutador de borde del Sistema

Autónomo) que
redistribuir direcciones VPN-IPv4 necesita insertar / 32
dirección
prefijos para sí mismos en las tablas de enrutamiento IGP de la
columna vertebral. Esto habilita MPLS, en cada nodo en la red
troncal
red, para asignar una etiqueta correspondiente a la ruta a cada
PE
enrutador Para garantizar la interoperabilidad entre diferentes
implementaciones, se requiere que admita LDP para configurar el
etiquetar las rutas conmutadas a través de la red troncal. Sin
embargo, otros métodos
de configurar estas rutas etiquetadas también son posibles.
(Algunos de estos otros métodos pueden no requerir la presencia
del
/ 32 prefijos de direcciones en el IGP.)
- Si hay túneles de ingeniería de tráfico para el siguiente salto

de BGP,
y si uno o más de ellos está disponible para su uso por el
paquete en
pregunta, uno de estos túneles es elegido. Este túnel será
asociado con una etiqueta MPLS, la "etiqueta del túnel". El
tunel
etiqueta se empuja en la pila de etiquetas MPLS, y el paquete
es
reenviado al próximo salto del túnel.
- De lo contrario,
* El paquete tendrá un "IGP Next Hop", que es el próximo

salto
a lo largo de la ruta IGP al BGP Next Hop.
* Si el BGP Next Hop y el IGP Next Hop son iguales, y si

se usa penultimate hop popping, el paquete se envía a
el siguiente salto de IGP, llevando solo la etiqueta de
ruta VPN.
* De lo contrario, IGP Next Hop tendrá asignada una etiqueta

para
la ruta que mejor coincide con la dirección del BGP Next
Hop.
Llamar a esto la "etiqueta del túnel". La etiqueta del
túnel se empuja
como la etiqueta superior del paquete. El paquete se
reenvía
al IGP Next Hop.
- MPLS llevará el paquete a través de la red troncal al BGP

Siguiente salto, donde se examinará la etiqueta VPN.
Si la red troncal no es compatible con MPLS, el paquete MPLS solo

lleva
la etiqueta de la ruta VPN se puede tunelizar al BGP Next Hop
usando el
técnicas de [ MPLS-in-IP-GRE ]. Cuando el paquete emerge del
túnel, estará en BGP Next Hop, donde la etiqueta de ruta VPN
será examinado.
En BGP Next Hop, el tratamiento del paquete depende de la VPN

etiqueta de ruta (ver Sección 4.3.2 ). En muchos casos, el PE podrá
para determinar, a partir de esta etiqueta, el circuito de conexión
sobre el que
paquete debe ser transmitido (a un dispositivo CE), así como el
apropiado
encabezado de capa de enlace de datos para esa interfaz. En otros
casos, el PE
solo puede determinar que la dirección de destino del paquete
necesita ser buscado en un VRF particular antes de ser enviado a un
Dispositivo CE. También hay casos intermedios en los que la ruta
VPN
etiqueta puede determinar el circuito de conexión de salida del
paquete, pero una
búsqueda (por ejemplo, ARP) aún debe hacerse para determinar el
cabecera del enlace de datos del paquete en ese circuito de
conexión.
Información en el encabezado MPLS en sí, y / o información asociada

con la etiqueta, también se puede usar para proporcionar QoS en la
interfaz para
el CE.
En cualquier caso, si el paquete era un paquete IP sin etiqueta

cuando
llegó a su ingreso PE, volverá a ser un paquete sin etiqueta cuando
deja su salida PE.
El hecho de que los paquetes con etiquetas de ruta VPN se tunelizan

a través del
backbone es lo que hace posible mantener todas las rutas VPN fuera
de
los enrutadores P Esto es crucial para garantizar la escalabilidad
de la
esquema. La red troncal ni siquiera necesita tener rutas a los CE,

solo a los PE.
Con respecto a los túneles, vale la pena señalar que esto
especificación:
- NO requiere que los túneles sean punto a punto; multipunto

a punto puede ser utilizado;
- NO requiere que haya una configuración explícita de los

túneles,
ya sea a través de señalización o mediante configuración
manual;
- NO requiere que haya ninguna señalización específica del túnel;
- NO requiere que haya ningún estado específico del túnel en el P

enrutadores PE, más allá de lo necesario para mantener el
enrutamiento
información y (si se usa) la información de la etiqueta MPLS.
Por supuesto, esta especificación es compatible con el uso de

Túneles de punto a punto que deben configurarse y / o señalizarse
explícitamente,
y en algunas situaciones puede haber razones para usar dichos
túneles.
Las consideraciones que son relevantes para elegir un particular

la tecnología de tunelización está fuera del alcance de esta
especificación.
6 . Mantener un aislamiento adecuado de VPN
Para mantener el aislamiento adecuado de una VPN de otra, es

importante
que ningún enrutador en la red troncal acepta un paquete de túnel
desde afuera
la red troncal, a menos que sea seguro que ambos puntos finales de
ese túnel
están fuera de la columna vertebral.
Si MPLS se está utilizando como tecnología de túnel, esto significa

que una
enrutador en la red troncal NO DEBE aceptar un paquete etiquetado
de
dispositivo no troncal adyacente a menos que se cumplan las dos
condiciones siguientes
sostener:
1. la etiqueta en la parte superior de la pila de etiquetas era

en realidad
distribuido por ese enrutador de red troncal a esa red no
troncal
dispositivo, y
2. el enrutador de la red troncal puede determinar que el uso de

esa etiqueta
hacer que el paquete salga de la red troncal antes de que las
etiquetas bajen
en la pila será inspeccionado, y antes de que el encabezado
IP
ser inspeccionado
La primera condición asegura que cualquier paquete etiquetado

recibido de
Los enrutadores no troncales tienen una etiqueta legítima y
correctamente asignada en
la parte superior de la pila de etiquetas. La segunda condición

asegura que el
Los enrutadores centrales nunca mirarán debajo de esa etiqueta
superior. Por supuesto,
la forma más sencilla de cumplir estas dos condiciones es
simplemente tener el
los dispositivos de red se niegan a aceptar paquetes etiquetados de
red no troncal
dispositivos.
Si no se usa MPLS como tecnología de túnel, entonces filtrando

debe hacerse para garantizar que un paquete MPLS-in-IP o MPLS-in-
GRE pueda
ser aceptado en la red troncal solo si el destino IP del paquete
la dirección hará que se envíe fuera de la red troncal.
7 . Cómo los PE aprenden las rutas desde los CE
Los enrutadores PE que se conectan a una VPN en particular

necesitan saber, para cada
circuito de conexión que lleva a esa VPN, cuál de las direcciones
de la VPN
debe alcanzarse sobre ese circuito de conexión.
El PE traduce estas direcciones en direcciones VPN-IPv4, utilizando

un
configurado RD. El PE luego trata estas rutas VPN-IPv4 como entrada
a
BGP. Las rutas desde un sitio VPN NO se filtran en el IGP de la red
troncal.
Exactamente qué técnicas de distribución de rutas PE / CE son

posibles
depende de si un EC particular está o no en una "VPN de tránsito".
UN
"tránsito VPN" es uno que contiene un enrutador que recibe rutas
desde
un "tercero" (es decir, desde un enrutador que no está en la VPN,
pero es
no es un enrutador PE) y eso redistribuye esas rutas a un enrutador
PE.
Una VPN que no es una VPN de tránsito es una "VPN de código
auxiliar". La gran mayoría
de VPN, incluidas casi todas las redes empresariales corporativas,
se esperaría que fueran "stubs" en este sentido.
Las posibles técnicas de distribución PE / CE son:
1. Se puede usar el enrutamiento estático (es decir, la

configuración). (Esto es
es probable que solo sea útil en VPN de código auxiliar).
2. Los enrutadores PE y CE pueden ser Routing Information

Protocol (RIP)
[ RIP ] pares, y el CE puede usar RIP para decirle al
enrutador PE
conjunto de prefijos de direcciones accesibles en el
enrutador CE
sitio. Cuando RIP está configurado en el CE, se debe tener
cuidado de
asegurar que los prefijos de dirección de otros sitios (es
decir, dirección
prefijos aprendidos por el enrutador CE desde el enrutador
PE) nunca son
anunciado para el PE. Más precisamente: si un enrutador PE,
por ejemplo,
PE1, recibe una ruta VPN-IPv4 R1, y como resultado distribuye
una ruta IPv4 R2 a un CE, luego R2 no se debe distribuir de
vuelta
desde el sitio de ese CE a un enrutador PE, digamos, PE2,
(donde PE1 y
PE2 puede ser el mismo enrutador o enrutadores diferentes), a
menos que PE2
asigna R2 a una ruta VPN-IPv4 que es diferente a (es decir,
contiene un RD diferente que) R1.
3. Los enrutadores PE y CE pueden ser pares OSPF. Un enrutador

PE que es
un par OSPF de un enrutador CE aparece, al enrutador CE, para
ser un
enrutador de área 0 Si un enrutador PE es un par OSPF de
enrutadores CE
que están en distintas VPN, por supuesto, el PE debe estar
ejecutándose
instancias múltiples de OSPF.
Las rutas IPv4 que el PE aprende del CE a través de OSPF son

redistribuido en BGP como rutas VPN-IPv4. Comunidad extendida
atributos se utilizan para llevar, junto con la ruta, todo el
información necesaria para permitir que la ruta se distribuya
a
otros enrutadores CE en la VPN en el tipo apropiado de enlace
OSPF
Anuncio estatal (LSA). El etiquetado de ruta OSPF se usa para
asegúrese de que las rutas recibidas desde la red troncal
MPLS / BGP no sean
enviado de vuelta a la columna vertebral.
Especificación del conjunto completo de procedimientos para

el uso de
OSPF entre PE y CE se puede encontrar en [ VPN-OSPF ] y
[ OSPF-2547-DNBIT ].
4. Los enrutadores PE y CE pueden ser pares BGP, y el enrutador

CE puede
use BGP (en particular, EBGP para decirle al enrutador PE el
conjunto de
prefijos de direcciones que se encuentran en el sitio del
enrutador CE. (Esta
La técnica se puede usar en redes privadas virtuales (VPN) o
VPN de tránsito.
Esta técnica tiene una serie de ventajas sobre las demás:
a) A diferencia de las alternativas de IGP, esto no

requiere el PE
ejecutar múltiples instancias de algoritmo de
enrutamiento para
hablar con múltiples CE.
b) BGP está explícitamente diseñado para esta función:

pasar información de enrutamiento entre sistemas
ejecutados por
diferentes administraciones.
c) Si el sitio contiene "puertas traseras BGP", es decir,

enrutadores con
Las conexiones BGP a enrutadores que no sean
enrutadores PE, esto
El procedimiento funcionará correctamente en todas las
circunstancias. los
otros procedimientos pueden o no funcionar, dependiendo
de la
circunstancias precisas
d) El uso de BGP hace que sea fácil para el CE pasar

atributos de
las rutas hacia el PE. Una especificación completa de
conjunto de atributos y su uso está fuera del alcance
de
este documento. Sin embargo, algunos ejemplos de la
forma en que esto
se pueden usar son los siguientes:

- El CE puede sugerir un objetivo de ruta particular
para cada
ruta, de entre los Destinos de ruta que el PE es
autorizado a adjuntar a la ruta. El PE entonces
adjunte solo el objetivo de ruta sugerido, en lugar
de
el conjunto completo. Esto le da al administrador
de CE algunos
control dinámico de la distribución de rutas desde
el CE.
- Tipos adicionales de atributos de comunidad

extendida pueden
ser definido, donde la intención es tener esos
atributos pasados transparentemente (es decir, sin
ser
cambiado por los enrutadores PE) de CE a CE. Esto
sería
Permitir que los administradores de CE implementen
una ruta adicional
filtrado, más allá de lo que hacen los PE.
Este filtrado adicional no requeriría
coordinación con el SP.
Por otro lado, usar BGP puede ser algo nuevo para el CE
administradores.
Si un sitio no está en una VPN de tránsito, tenga en cuenta

que no necesita tener una
único número de sistema autónomo (ASN). Cada CE cuyo sitio es
no en una VPN de tránsito puede usar el mismo ASN. Esto puede
ser elegido
desde el espacio ASN privado, y será eliminado por el
EDUCACIÓN FÍSICA. Los bucles de enrutamiento se evitan
mediante el uso del sitio de origen
atributo (ver a continuación).
¿Qué sucede si un conjunto de sitios constituye una VPN de

tránsito? Esta voluntad
generalmente será el caso solo si la VPN es ella misma una
Internet
La red del Proveedor de servicios (ISP), donde el ISP es en
sí mismo
comprar servicios troncales de otro SP. El último SP puede
ser
llamado "transportista del transportista". En este caso, la
mejor manera de
proporcionar la VPN es tener los enrutadores CE soportan
MPLS, y
use la técnica descrita en la Sección 9 .
Cuando no necesitamos distinguir entre las diferentes formas en que

un PE puede ser informado de los prefijos de direcciones que
existen en un determinado
sitio, simplemente diremos que el PE ha "aprendido" las rutas desde
ese sitio. Esto incluye el caso donde el PE ha sido manualmente
configurado con las rutas
Antes de que un PE pueda redistribuir una ruta VPN-IPv4 aprendida

de un sitio,
debe asignar un atributo de Destino de ruta (ver Sección 4.3.1 ) al
ruta, y puede asignar un atributo de Sitio de origen a la ruta.
El atributo de Sitio de origen, si se usa, está codificado como

Origen de ruta
Comunidad extendida [ BGP-EXTCOMM ]. El propósito de este atributo
es
identificar de manera única el conjunto de rutas aprendidas de un
particular
sitio. Este atributo es necesario en algunos casos para garantizar

que una ruta
aprendido de un sitio en particular a través de una conexión PE /
CE particular es
no distribuido de vuelta al sitio a través de un PE / CE diferente
conexión. Es particularmente útil si se usa BGP como el
Protocolo PE / CE, pero diferentes sitios no han sido asignados
ASNs.
8 . Cómo los CE aprenden las rutas de los PE
En esta sección, suponemos que el dispositivo CE es un enrutador.
Si el PE coloca una ruta particular en el VRF usa para enrutar

paquetes recibidos de un CE particular, luego, en general, el PE
puede
distribuir esa ruta a la CE. Por supuesto, el PE puede distribuir
esa ruta al CE solo si esto está permitido por las reglas del
Protocolo PE / CE. (Por ejemplo, si un protocolo PE / CE particular
tiene
"horizonte dividido", ciertas rutas en el VRF no se pueden
redistribuir
de vuelta al CE.) Agregamos una restricción más en la distribución
de
rutas de PE a CE: si el atributo Lugar de origen de una ruta
identifica un sitio en particular, esa ruta nunca debe ser
redistribuida
a cualquier CE en ese sitio.
En la mayoría de los casos, sin embargo, será suficiente para el PE

simplemente
distribuye la ruta predeterminada al CE. (En algunos casos, incluso
puede
ser suficiente para que el CE se configure con una ruta
predeterminada
señalando el PE.) Esto generalmente funcionará en cualquier sitio
que lo haga
no necesita distribuir la ruta predeterminada a otros sitios.
(Por ejemplo, si un sitio en una VPN corporativa tiene acceso de la
corporación a
Internet, ese sitio podría tener que tener distribución
predeterminada a la
otro sitio, pero no se pudo distribuir por defecto a ese sitio
sí mismo.)
Cualquiera que sea el procedimiento utilizado para distribuir rutas

de CE a PE,
también se utilizará para distribuir rutas de PE a CE.
9 . Portadores de portadores
A veces, una VPN puede ser la red de un ISP, con su propio

políticas de peering y enrutamiento. A veces, una VPN puede ser la
red de
un SP que ofrece servicios de VPN a sus propios clientes.
Las VPN como estas también pueden obtener el servicio de red
troncal desde otro SP, el
"transportista del transportista", utilizando esencialmente los
mismos métodos descritos en
este documento. Sin embargo, es necesario en estos casos que el CE
los enrutadores admiten MPLS. En particular:
- Los enrutadores CE deben distribuir a los enrutadores PE

SOLAMENTE aquellos
rutas que son internas a la VPN. Esto permite que la VPN sea
manejado como un trozo VPN.

RFC 4364

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFC 4364

Uploaded by

Copyright:

Available Formats

Estado de esta nota

Este documento especifica un protocolo de seguimiento de estándares

Copyright (C) The Internet Society (2006).

Este documento describe un método por el cual un proveedor de

Este documento obsoleto RFC 2547 .

Rosen & Rekhter Standards Track [Página 1]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

Rosen & Rekhter Normas Track [Página 2]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

Este documento describe un método por el cual un proveedor de

A cada ruta dentro de una VPN se le asigna una conmutación de

El objetivo principal de este método es respaldar el caso en el que

Rosen & Rekhter Normas Track [Página 3]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

Considere un conjunto de "sitios" que están conectados a una red

Estos subconjuntos son redes privadas virtuales (VPN). Dos sitios

Si todos los sitios en una VPN son propiedad de la misma empresa,

Nos referimos a los propietarios de los sitios como los "clientes".

Un cliente puede ser una sola empresa, un conjunto de empresas, un

Las políticas que determinan si una colección particular de sitios

Rosen & Rekhter Normas Track [Página 4]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

En este documento, restringimos nuestra discusión al caso en el que

También restringimos nuestra discusión al caso en el que la columna

En el resto de esta introducción, especificamos algunas propiedades

1.2 . Borde del cliente y borde del proveedor

Los enrutadores en la red del SP que no se conectan a los

Los dispositivos CE pueden ser hosts o enrutadores. En un caso

Rosen & Rekhter Normas Track [Página 5]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

A veces, lo que está conectado físicamente a un enrutador PE es una

El circuito de conexión sobre el que viaja un paquete al pasar de

Diremos que un enrutador PE está conectado a una VPN particular si

Cuando el dispositivo CE es un enrutador, es un par de enrutamiento

Con respecto a la administración de los dispositivos de borde,

1.3 . VPN con espacios de direcciones superpuestos

Si dos VPN no tienen sitios en común, entonces pueden tener

Rosen & Rekhter Normas Track [Página 6]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

Incluso dos VPN que tienen sitios en común pueden tener

1.4 . VPN con diferentes rutas para el mismo sistema

Aunque un sitio puede estar en múltiples VPN, no es necesariamente

Es posible configurar dos rutas al servidor. Una ruta, usada

1.5 . Enrutadores SP Backbone

La red troncal del SP consiste en los enrutadores PE, así como en

Si cada enrutador en la red troncal de un SP tuviera que mantener

Entonces, así como los propietarios de VPN no tienen una red

Rosen & Rekhter Normas Track [Página 7]

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

La Sección 10 discute algunos de los problemas especiales que

Desde la perspectiva de una red troncal particular, un conjunto de

Un dispositivo CE siempre se considera que está en un solo sitio

Un enrutador PE puede conectarse a dispositivos CE desde cualquier

Mientras hablamos principalmente de "sitios" como la unidad básica

RFC 4364 BGP / MPLS IP VPN Febrero de 2006

un sitio puede ser miembros de una intranet así como miembros de

3 . VRF: Múltiples tablas de reenvío en PE

Cada enrutador PE mantiene varias tablas de reenvío separadas. Uno

3.1 . VRF y circuitos de conexión

Cada circuito de conexión PE / CE está asociado, por configuración,

En el caso más simple y en el caso más típico, un archivo adjunto

Si un paquete IP llega a un circuito de conexión que no es

Intuitivamente, uno puede pensar en la tabla de reenvío