NAT de Cisco IOS - Integración con MPLS VPN
Contenido
Introducción
El software de traducción de direcciones de red (NAT) de Cisco IOS® permite el acceso a servicios compartidos desde varias VPN MPLS, incluso cuando los dispositivos de las VPN utilizan direcciones IP que se superponen. Cisco IOS NAT está preparado para VRF y se puede configurar en los routers de borde del proveedor dentro de la red MPLS.
Nota: MPLS en IOS se soporta solamente con NAT heredada. En este momento, no hay soporte en Cisco IOS para NAT NVI con MPLS.
Se prevé que la implementación de VPN MPLS aumente rápidamente en los próximos años. Las ventajas de una infraestructura de red común que permita una rápida expansión y opciones de conectividad flexibles impulsarán sin duda un mayor crecimiento de los servicios que se pueden ofrecer a la comunidad de redes internas.
Sin embargo, todavía persisten obstáculos al crecimiento. IPv6 y su promesa de disponer de un espacio de direcciones IP que supere las necesidades de conectividad en un futuro próximo se encuentran todavía en las primeras fases de la implementación. Las redes existentes suelen utilizar esquemas de direccionamiento IP privados según lo definido en RFC 1918 
. La traducción de direcciones de red se utiliza a menudo para interconectar redes cuando los espacios de direcciones se superponen o se duplican.
Los proveedores de servicios y las empresas que disponen de servicios de aplicaciones de red que desean ofrecer o compartir con clientes y partners querrán minimizar cualquier carga de conectividad que pesen sobre el usuario del servicio. Es deseable, incluso obligatorio, extender la oferta a tantos usuarios potenciales como sea necesario para lograr los objetivos deseados o el retorno. El esquema de direccionamiento IP en uso no debe ser una barrera que excluya a los usuarios potenciales.
Al implementar Cisco IOS NAT en la infraestructura VPN MPLS común, los proveedores de servicios de comunicaciones pueden aliviar parte de la carga de conectividad de los clientes y acelerar su capacidad de vincular más servicios de aplicaciones compartidas a más consumidores de esos servicios.
Ventajas de NAT - Integración de MPLS
La integración de NAT con MPLS ofrece ventajas tanto para los proveedores de servicios como para sus clientes empresariales. Ofrece a los proveedores de servicios más opciones para implementar servicios compartidos y proporcionar acceso a esos servicios. Las ofertas de servicios adicionales pueden marcar la diferencia con respecto a la competencia.
| Para proveedor de servicios | Para VPN |
|---|---|
| Más ofertas de servicios | Reducción de costes |
| Más opciones de acceso | Acceso más sencillo |
| Aumento de los ingresos | Abordar la flexibilidad |
Los clientes empresariales que deseen externalizar parte de su carga de trabajo actual también pueden beneficiarse de ofertas más amplias de los proveedores de servicios. Cambiar la carga de realizar cualquier traducción de dirección necesaria a la red del proveedor de servicios los libera de una tarea administrativa complicada. Es posible que los clientes continúen utilizando el direccionamiento privado y, al mismo tiempo, mantengan el acceso a los servicios compartidos y a Internet. La consolidación de la función NAT dentro de la red del proveedor de servicios también puede reducir el costo total para los clientes empresariales, ya que los routers de borde del cliente no tienen que realizar la función NAT.
Aspectos del diseño
Al considerar los diseños que invocarán NAT dentro de la red MPLS, el primer paso es determinar las necesidades de servicio desde el punto de vista de una aplicación. Deberá tener en cuenta los protocolos utilizados y cualquier comunicación especial cliente/servidor impuesta por la aplicación. Asegúrese de que el soporte necesario para los protocolos empleados sea soportado y manejado por Cisco IOS NAT. En el documento Gateways de Capa de Aplicación NAT de Cisco IOS se proporciona una lista de los protocolos soportados.
A continuación, será necesario determinar el uso esperado del servicio compartido y la tasa de tráfico esperada en paquetes por segundo. NAT es una función de uso intensivo de la CPU del router. Por lo tanto, los requisitos de rendimiento serán un factor a la hora de seleccionar una opción de implementación determinada y determinar el número de dispositivos NAT involucrados.
Además, tenga en cuenta cualquier problema de seguridad y las precauciones que deban tomarse. Aunque las VPN MPLS, por definición, son tráfico privado y separado de manera efectiva, la red de servicio compartido es generalmente común entre muchas VPN.
Escenarios de implementación
Hay dos opciones para la implementación de NAT dentro del perímetro del proveedor MPLS:
-
Centralizado con NAT de salida PE
-
Distribuido con NAT PE de ingreso
Algunas ventajas para configurar la función NAT en el punto de salida de la red MPLS más cercana a la red de servicio compartido son:
-
Una configuración centralizada que fomenta un aprovisionamiento de servicios más sencillo
-
Resolución de problemas simplificada
-
Escalabilidad operativa mejorada
-
Disminución de los requisitos de asignación de direcciones IP
Sin embargo, las ventajas se compensan con una reducción de la escalabilidad y el rendimiento. Esta es la principal disyuntiva que debe considerarse. Por supuesto, la función NAT también se puede realizar dentro de las redes del cliente si se determina que la integración de esta función con una red MPLS no es deseable.
NAT PE de entrada
La NAT se puede configurar en el router PE de ingreso a la red MPLS como se muestra en la Figura 1. Con este diseño, la escalabilidad se mantiene en gran medida mientras que el rendimiento se optimiza mediante la distribución de la función NAT en muchos dispositivos periféricos. Cada NAT PE maneja el tráfico para los sitios conectados localmente a ese PE. Las reglas NAT y las listas de control de acceso o los mapas de ruta controlan qué paquetes requieren traducción.
Figura 1: NAT PE de entrada 
Hay una restricción que impide la NAT entre dos VRF al tiempo que proporciona NAT a un servicio compartido como se muestra en la Figura 2. Esto se debe al requisito de designar las interfaces como interfaces NAT "interna" y "externa". Se planifica el soporte para conexiones entre VRF en un único PE para una futura versión de Cisco IOS.
Figura 2: Empresa a empresa 
NAT PE de salida
La NAT se puede configurar en el router PE de salida de red MPLS como se muestra en la Figura 3. Con este diseño, la escalabilidad se reduce en cierta medida, ya que el PE central debe mantener rutas para todas las redes de clientes que acceden al servicio compartido. Los requisitos de rendimiento de la aplicación también deben tenerse en cuenta para que el tráfico no sobrecargue al router que debe traducir las direcciones IP de los paquetes. Debido a que la NAT se produce de forma centralizada para todos los clientes que utilizan esta ruta, los grupos de direcciones IP se pueden compartir; por lo tanto, se reduce el número total de subredes necesarias.
Figura 3: NAT PE de salida 
Se podrían implementar varios routers para aumentar la escalabilidad del diseño NAT PE de salida, como se muestra en la Figura 4. En esta situación, las VPN del cliente se podrían "aprovisionar" en un router NAT específico. La traducción de direcciones de red se produciría para el tráfico agregado hacia y desde el servicio compartido para ese conjunto de VPN. Por ejemplo, el tráfico de las VPN para los clientes A y B podría utilizar NAT-PE1, mientras que el tráfico hacia y desde la VPN para el cliente C utiliza NAT-PE2. Cada NAT PE transportaría tráfico solamente para las VPNs específicas definidas y solamente mantendría las rutas de regreso a los sitios en esas VPNs. Se pueden definir grupos de direcciones NAT separados dentro de cada uno de los routers NAT PE para que los paquetes se rutee desde la red de servicio compartido al PE NAT adecuado para la traducción y el ruteo de regreso a la VPN del cliente.
Figura 4: NAT PE de salida múltiple 
El diseño centralizado sí impone una restricción sobre cómo se debe configurar la red de servicio compartido. Específicamente, el uso de la importación/exportación de rutas VPN MPLS entre una VPN de servicio compartido y VPN de cliente no es posible. Esto se debe a la naturaleza de la operación MPLS según lo especificado por RFC 2547 . Cuando las rutas se importan y exportan usando las comunidades extendidas y los descriptores de ruta, NAT no puede determinar la VPN de origen del paquete que ingresa al PE de NAT central. El caso habitual es hacer de la red de servicio compartido una interfaz genérica en lugar de una interfaz VRF. A continuación, se agrega una ruta a la red de servicio compartido en el PE de NAT central para cada tabla VRF asociada a una VPN del cliente que necesita acceso al servicio compartido como parte del proceso de aprovisionamiento. Esto se describe con más detalle más adelante.
Opciones de implementación y detalles de configuración
Esta sección incluye algunos detalles relacionados con cada una de las opciones de implementación. Todos los ejemplos se toman de la red que se muestra en la Figura 5. Consulte este diagrama para ver el resto de esta sección.
Nota: En la red utilizada para ilustrar el funcionamiento de la NAT VRF para este documento, sólo se incluyen los routers PE. No hay routers "P" de núcleo. Sin embargo, todavía se pueden ver los mecanismos esenciales.
Figura 5: Ejemplo de Configuración de NAT de VRF 
NAT PE de salida
En este ejemplo, los routers de borde del proveedor marcados con gila y dragon se configuran como routers PE simples. El PE central cerca de la LAN de servicio compartido (iguana) está configurado para NAT. Cada VPN del cliente que necesita acceso al servicio compartido comparte un único conjunto NAT. La NAT se realiza solamente en los paquetes destinados al host de servicio compartido en 88.1.88.8.
Reenvío de datos NAT PE de salida
Con MPLS, cada paquete ingresa a la red en un PE de ingreso y sale de la red MPLS en un PE de egreso. La ruta de los routers de switching de etiquetas que pasan de entrada a salida se conoce como la ruta conmutada de etiquetas (LSP). El LSP es unidireccional. Se utiliza un LSP diferente para el tráfico de retorno.
Al utilizar NAT PE de salida, se define de forma eficaz una clase de equivalencia de reenvío (FEC) para todo el tráfico de los usuarios del servicio compartido. En otras palabras, todos los paquetes destinados a la LAN de servicio compartido son miembros de una FEC común. Un paquete se asigna a un FEC determinado una sola vez en el borde de ingreso de la red y sigue el LSP al PE de egreso. La FEC se designa en el paquete de datos mediante la adición de una etiqueta determinada.
Flujo de paquetes a servicio compartido desde VPN
Para que los dispositivos en varias VPN que tienen esquemas de direcciones superpuestas accedan a un host de servicio compartido, se requiere NAT. Cuando NAT se configura en el PE de salida, las entradas de la tabla de traducción de direcciones de red incluirán un identificador VRF para diferenciar las direcciones duplicadas y asegurar el ruteo adecuado.
Figura 6: Paquetes transmitidos a NAT PE de salida 
La figura 6 ilustra los paquetes destinados a un host de servicio compartido desde dos VPN de cliente que tienen esquemas de direccionamiento IP duplicados. La figura muestra un paquete que se origina en el Cliente A con una dirección de origen de 172.31.1.1 destinado a un servidor compartido a 88.1.88.8. Otro paquete del Cliente B con la misma dirección IP de origen también se envía al mismo servidor compartido. Cuando los paquetes llegan al router PE, se realiza una búsqueda de capa 3 para la red IP de destino en la base de información de reenvío (FIB).
La entrada FIB indica al router PE que reenvíe el tráfico al PE de salida usando una pila de etiquetas. El router PE de destino asigna la etiqueta inferior en la pila, en este caso, iguana del router.
iguana# show ip cef vrf custA 88.1.88.8 88.1.88.8/32, version 47, epoch 0, cached adjacency 88.1.3.2 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24} via 88.1.11.5, 0 dependencies, recursive next hop 88.1.3.2, Ethernet1/0 via 88.1.11.5/32 valid cached adjacency tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24}
iguana# show ip cef vrf custB 88.1.88.8
88.1.88.8/32, version 77, epoch 0, cached adjacency 88.1.3.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Et1/0, 88.1.3.2, tags imposed: {28}
via 88.1.11.5, 0 dependencies, recursive
next hop 88.1.3.2, Ethernet1/0 via 88.1.11.5/32
valid cached adjacency
tag rewrite with Et1/0, 88.1.3.2, tags imposed: {28}
iguana#
Podemos ver en la pantalla que los paquetes de VRF CastA tendrán un valor de etiqueta de 24 (0x18) y los paquetes de VRF CastB tendrán un valor de etiqueta de 28 (0x1C).
En este caso, como no hay routers "P" en nuestra red, no se ha impuesto ninguna etiqueta adicional. Si hubiera habido routers de núcleo, se habría impuesto una etiqueta externa y el proceso normal de intercambio de etiquetas habría tenido lugar dentro de la red de núcleo hasta que el paquete alcanzara el PE de salida.
Dado que el router gila está conectado directamente al PE de salida, vemos que la etiqueta se muestra antes de que se añada alguna vez:
gila# show tag-switching forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 88.1.1.0/24 0 Et1/1 88.1.2.2 Pop tag 88.1.1.0/24 0 Et1/0 88.1.3.2 17 Pop tag 88.1.4.0/24 0 Et1/1 88.1.2.2 18 Pop tag 88.1.10.0/24 0 Et1/1 88.1.2.2 19 Pop tag 88.1.11.1/32 0 Et1/1 88.1.2.2 20 Pop tag 88.1.5.0/24 0 Et1/0 88.1.3.2 21 19 88.1.11.10/32 0 Et1/1 88.1.2.2 22 88.1.11.10/32 0 Et1/0 88.1.3.2 22 20 172.18.60.176/32 0 Et1/1 88.1.2.2 23 172.18.60.176/32 0 Et1/0 88.1.3.2 23 Untagged 172.31.1.0/24[V] 4980 Fa0/0 10.88.162.6 24 Aggregate 10.88.162.4/30[V] 1920 25 Aggregate 10.88.162.8/30[V] 137104 26 Untagged 172.31.1.0/24[V] 570 Et1/2 10.88.162.14 27 Aggregate 10.88.162.12/30[V] \ 273480 30 Pop tag 88.1.11.5/32 0 Et1/0 88.1.3.2 31 Pop tag 88.1.88.0/24 0 Et1/0 88.1.3.2 32 16 88.1.97.0/24 0 Et1/0 88.1.3.2 33 Pop tag 88.1.99.0/24 0 Et1/0 88.1.3.2 gila#
gila# show tag-switching forwarding-table 88.1.88.0 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
31 Pop tag 88.1.88.0/24 0 Et1/0 88.1.3.2
MAC/Encaps=14/14, MRU=1504, Tag Stack{}
005054D92A250090BF9C6C1C8847
No output feature configured
Per-packet load-sharing
gila#
La siguiente visualización muestra los paquetes de eco recibidos por el router NAT PE de egreso (en la interfaz E1/0/5 en iguana).
From CustA:
DLC: ----- DLC Header -----
DLC:
DLC: Frame 1 arrived at 16:21:34.8415; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 00018
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 175
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 5EC0 (correct)
IP: Source address = [172.31.1.1]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = 4AF1 (correct)
ICMP: Identifier = 4713
ICMP: Sequence number = 6957
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
From CustB:
DLC: ----- DLC Header -----
DLC:
DLC: Frame 11 arrived at 16:21:37.1558; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 0001C
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 165
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 5ECA (correct)
IP: Source address = [172.31.1.1]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = AD5E (correct)
ICMP: Identifier = 3365
ICMP: Sequence number = 7935
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Estos pings resultan en que se crean las siguientes entradas en la tabla NAT en la iguana del router PE de salida. Las entradas específicas creadas para los paquetes que se muestran arriba pueden coincidir con su identificador ICMP.
iguana# show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.1.3:3365 172.31.1.1:3365 88.1.88.8:3365 88.1.88.8:3365 icmp 192.168.1.3:3366 172.31.1.1:3366 88.1.88.8:3366 88.1.88.8:3366 icmp 192.168.1.3:3367 172.31.1.1:3367 88.1.88.8:3367 88.1.88.8:3367 icmp 192.168.1.3:3368 172.31.1.1:3368 88.1.88.8:3368 88.1.88.8:3368 icmp 192.168.1.3:3369 172.31.1.1:3369 88.1.88.8:3369 88.1.88.8:3369 icmp 192.168.1.1:4713 172.31.1.1:4713 88.1.88.8:4713 88.1.88.8:4713 icmp 192.168.1.1:4714 172.31.1.1:4714 88.1.88.8:4714 88.1.88.8:4714 icmp 192.168.1.1:4715 172.31.1.1:4715 88.1.88.8:4715 88.1.88.8:4715 icmp 192.168.1.1:4716 172.31.1.1:4716 88.1.88.8:4716 88.1.88.8:4716 icmp 192.168.1.1:4717 172.31.1.1:4717 88.1.88.8:4717 88.1.88.8:4717
iguana#
show ip nat translations verbose
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.3:3365 172.31.1.1:3365 88.1.88.8:3365 88.1.88.8:3365
create 00:00:34, use 00:00:34, left 00:00:25, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:3366 172.31.1.1:3366 88.1.88.8:3366 88.1.88.8:3366
create 00:00:34, use 00:00:34, left 00:00:25, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:3367 172.31.1.1:3367 88.1.88.8:3367 88.1.88.8:3367
create 00:00:34, use 00:00:34, left 00:00:25, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:3368 172.31.1.1:3368 88.1.88.8:3368 88.1.88.8:3368
create 00:00:34, use 00:00:34, left 00:00:25, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:3369 172.31.1.1:3369 88.1.88.8:3369 88.1.88.8:3369
create 00:00:34, use 00:00:34, left 00:00:25, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.1:4713 172.31.1.1:4713 88.1.88.8:4713 88.1.88.8:4713
create 00:00:37, use 00:00:37, left 00:00:22, Map-Id(In): 1,
Pro Inside global Inside local Outside local Outside global
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:4714 172.31.1.1:4714 88.1.88.8:4714 88.1.88.8:4714
create 00:00:37, use 00:00:37, left 00:00:22, Map-Id(In): 1,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:4715 172.31.1.1:4715 88.1.88.8:4715 88.1.88.8:4715
create 00:00:37, use 00:00:37, left 00:00:22, Map-Id(In): 1,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:4716 172.31.1.1:4716 88.1.88.8:4716 88.1.88.8:4716
create 00:00:37, use 00:00:37, left 00:00:22, Map-Id(In): 1,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:4717 172.31.1.1:4717 88.1.88.8:4717 88.1.88.8:4717
create 00:00:37, use 00:00:37, left 00:00:22, Map-Id(In): 1,
flags:
extended, use_count: 0, VRF : custA
iguana#
Flujo de paquetes de un servicio compartido a una VPN de origen
A medida que los paquetes regresan a los dispositivos que han accedido al host de servicio compartido, la tabla NAT se examina antes del ruteo (paquetes que van desde la interfaz "externa" de NAT a la interfaz "interna"). Debido a que cada entrada única incluye el identificador VRF correspondiente, el paquete se puede traducir y rutear adecuadamente.
Figura 7: Paquetes devueltos al usuario de servicios compartidos 
Como se muestra en la Figura 7, la NAT examina primero el tráfico de retorno para encontrar una entrada de traducción coincidente. Por ejemplo, un paquete se envía al destino 192.168.1.1. Se busca en la tabla NAT. Cuando se encuentra la coincidencia, la traducción apropiada se realiza a la dirección "local interna" (172.31.1.1) y luego se realiza una búsqueda de adyacencia usando el ID de VRF asociado de la entrada NAT.
iguana# show ip cef vrf custA 172.31.1.0
172.31.1.0/24, version 12, epoch 0, cached adjacency 88.1.3.1
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Et1/0/5, 88.1.3.1, tags imposed: {23}
via 88.1.11.9, 0 dependencies, recursive
next hop 88.1.3.1, Ethernet1/0/5 via 88.1.11.9/32
valid cached adjacency
tag rewrite with Et1/0/5, 88.1.3.1, tags imposed: {23}
iguana# show ip cef vrf custB 172.31.1.0
172.31.1.0/24, version 18, epoch 0, cached adjacency 88.1.3.1
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Et1/0/5, 88.1.3.1, tags imposed: {26}
via 88.1.11.9, 0 dependencies, recursive
next hop 88.1.3.1, Ethernet1/0/5 via 88.1.11.9/32
valid cached adjacency
tag rewrite with Et1/0/5, 88.1.3.1, tags imposed: {26}
iguana#
La etiqueta 23 (0x17) se utiliza para el tráfico destinado a 172.31.1.0/24 en VRF custA y la etiqueta 26 (0x1A) se utiliza para los paquetes destinados a 172.31.1.0/24 en VRF custB.
Esto se ve en los paquetes de respuesta de eco enviados desde la iguana del router:
To custA:
DLC: ----- DLC Header -----
DLC:
DLC: Frame 2 arrived at 16:21:34.8436; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 0090BF9C6C1C
DLC: Source = Station 005054D92A25
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 00017
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 56893
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 4131 (correct)
IP: Source address = [88.1.88.8]
IP: Destination address = [172.31.1.1]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = 52F1 (correct)
ICMP: Identifier = 4713
ICMP: Sequence number = 6957
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Cuando el paquete alcanza el router PE de destino, la etiqueta se utiliza para determinar el VRF y la interfaz adecuados para enviar el paquete.
gila# show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 16 Pop tag 88.1.1.0/24 0 Et1/1 88.1.2.2 Pop tag 88.1.1.0/24 0 Et1/0 88.1.3.2 17 Pop tag 88.1.4.0/24 0 Et1/1 88.1.2.2 18 Pop tag 88.1.10.0/24 0 Et1/1 88.1.2.2 19 Pop tag 88.1.11.1/32 0 Et1/1 88.1.2.2 20 Pop tag 88.1.5.0/24 0 Et1/0 88.1.3.2 21 19 88.1.11.10/32 0 Et1/1 88.1.2.2 22 88.1.11.10/32 0 Et1/0 88.1.3.2 22 20 172.18.60.176/32 0 Et1/1 88.1.2.2 23 172.18.60.176/32 0 Et1/0 88.1.3.2 23 Untagged 172.31.1.0/24[V] 6306 Fa0/0 10.88.162.6 24 Aggregate 10.88.162.4/30[V] 1920 25 Aggregate 10.88.162.8/30[V] 487120 26 Untagged 172.31.1.0/24[V] 1896 Et1/2 10.88.162.14 27 Aggregate 10.88.162.12/30[V] \ 972200 30 Pop tag 88.1.11.5/32 0 Et1/0 88.1.3.2 31 Pop tag 88.1.88.0/24 0 Et1/0 88.1.3.2 32 16 88.1.97.0/24 0 Et1/0 88.1.3.2 33 Pop tag 88.1.99.0/24 0 Et1/0 88.1.3.2 gila#
Configuraciones
Se ha eliminado cierta información superflua de las configuraciones para su brevedad.
IGUANA: ! ip vrf custA rd 65002:100 route-target export 65002:100 route-target import 65002:100 ! ip vrf custB rd 65002:200 route-target export 65002:200 route-target import 65002:200 ! ip cef mpls label protocol ldp tag-switching tdp router-id Loopback0 ! interface Loopback0 ip address 88.1.11.5 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Loopback11 ip vrf forwarding custA ip address 172.16.1.1 255.255.255.255 ! interface Ethernet1/0/0 ip vrf forwarding custB ip address 10.88.163.5 255.255.255.252 no ip route-cache no ip mroute-cache ! interface Ethernet1/0/4 ip address 88.1.1.1 255.255.255.0 ip nat inside no ip mroute-cache tag-switching ip ! interface Ethernet1/0/5 ip address 88.1.3.2 255.255.255.0 ip nat inside no ip mroute-cache tag-switching ip ! ! interface FastEthernet1/1/0 ip address 88.1.88.1 255.255.255.0 ip nat outside full-duplex ! interface FastEthernet5/0/0 ip address 88.1.99.1 255.255.255.0 speed 100 full-duplex ! router ospf 881 log-adjacency-changes redistribute static subnets network 88.1.0.0 0.0.255.255 area 0 ! router bgp 65002 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 88.1.11.1 remote-as 65002 neighbor 88.1.11.1 update-source Loopback0 neighbor 88.1.11.9 remote-as 65002 neighbor 88.1.11.9 update-source Loopback0 neighbor 88.1.11.10 remote-as 65002 neighbor 88.1.11.10 update-source Loopback0 no auto-summary ! address-family ipv4 multicast no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 88.1.11.1 activate neighbor 88.1.11.1 send-community extended neighbor 88.1.11.9 activate neighbor 88.1.11.9 send-community extended no auto-summary exit-address-family ! address-family ipv4 neighbor 88.1.11.1 activate neighbor 88.1.11.9 activate neighbor 88.1.11.10 activate no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf custB redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf custA redistribute static no auto-summary no synchronization exit-address-family ! ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload ip nat inside source list 181 pool SSPOOL1 vrf custB overload ip classless ip route 88.1.88.0 255.255.255.0 FastEthernet1/1/0 ip route 88.1.97.0 255.255.255.0 FastEthernet5/0/0 88.1.99.2 ip route 88.1.99.0 255.255.255.0 FastEthernet5/0/0 88.1.99.2 ip route 192.168.1.0 255.255.255.0 Null0 ip route vrf custA 88.1.88.8 255.255.255.255 FastEthernet1/1/0 88.1.88.8 global ip route vrf custB 10.88.208.0 255.255.240.0 10.88.163.6 ip route vrf custB 64.102.0.0 255.255.0.0 10.88.163.6 ip route vrf custB 88.1.88.8 255.255.255.255 FastEthernet1/1/0 88.1.88.8 global ip route vrf custB 128.0.0.0 255.0.0.0 10.88.163.6 no ip http server ! access-list 181 permit ip any host 88.1.88.8 !
GILA: ! ip vrf custA rd 65002:100 route-target export 65002:100 route-target import 65002:100 ! ip vrf custB rd 65002:200 route-target export 65002:200 route-target import 65002:200 ! ip cef mpls label protocol ldp tag-switching tdp router-id Loopback0 ! interface Loopback0 ip address 88.1.11.9 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding custA ip address 10.88.162.5 255.255.255.252 duplex full ! interface Ethernet1/0 ip address 88.1.3.1 255.255.255.0 no ip mroute-cache duplex half tag-switching ip ! interface Ethernet1/1 ip address 88.1.2.1 255.255.255.0 no ip mroute-cache duplex half tag-switching ip ! interface Ethernet1/2 ip vrf forwarding custB ip address 10.88.162.13 255.255.255.252 ip ospf cost 100 duplex half ! interface FastEthernet2/0 ip vrf forwarding custA ip address 10.88.162.9 255.255.255.252 duplex full ! router ospf 881 log-adjacency-changes redistribute static subnets network 88.1.0.0 0.0.255.255 area 0 default-metric 30 ! router bgp 65002 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 88.1.11.1 remote-as 65002 neighbor 88.1.11.1 update-source Loopback0 neighbor 88.1.11.1 activate neighbor 88.1.11.5 remote-as 65002 neighbor 88.1.11.5 update-source Loopback0 neighbor 88.1.11.5 activate no auto-summary ! address-family ipv4 vrf custB redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf custA redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 88.1.11.1 activate neighbor 88.1.11.1 send-community extended neighbor 88.1.11.5 activate neighbor 88.1.11.5 send-community extended no auto-summary exit-address-family ! ip classless ip route vrf custA 172.31.1.0 255.255.255.0 FastEthernet0/0 10.88.162.6 ip route vrf custB 172.31.1.0 255.255.255.0 Ethernet1/2 10.88.162.14 !
El dragón del router tendría una configuración muy similar a gila.
Importación/Exportación de Destinos de Ruta no Permitidos
Cuando la red de servicio compartido se configura como una instancia VRF en sí, la NAT central en el PE de salida no es posible. Esto se debe a que los paquetes entrantes no se pueden distinguir y sólo una ruta de regreso a la subred de origen está presente en la NAT PE de salida.
Nota: Las visualizaciones que se muestran a continuación están pensadas para ilustrar el resultado de una configuración no válida.
La red de ejemplo se configuró de modo que la red de servicio compartido se definió como una instancia de VRF (nombre de VRF = servidor). Ahora, una visualización de la tabla CEF en el PE de ingreso muestra esto:
gila# show ip cef vrf custA 88.1.88.0
88.1.88.0/24, version 45, epoch 0, cached adjacency 88.1.3.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24}
via 88.1.11.5, 0 dependencies, recursive
next hop 88.1.3.2, Ethernet1/0 via 88.1.11.5/32
valid cached adjacency
tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24}
gila#
gila# show ip cef vrf custB 88.1.88.0
88.1.88.0/24, version 71, epoch 0, cached adjacency 88.1.3.2
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24}
via 88.1.11.5, 0 dependencies, recursive
next hop 88.1.3.2, Ethernet1/0 via 88.1.11.5/32
valid cached adjacency
tag rewrite with Et1/0, 88.1.3.2, tags imposed: {24}
gila#
iguana# show tag-switching forwarding vrftags 24 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 24 Aggregate 88.1.88.0/24[V] 10988 iguana#
Nota: Observe cómo el valor de etiqueta 24 se impone tanto para el VRF custA como para el VRF custB.
Esta visualización muestra la tabla de ruteo para la instancia de VRF de servicio compartido "sserver":
iguana# show ip route vrf sserver 172.31.1.1 Routing entry for 172.31.1.0/24 Known via "bgp 65002", distance 200, metric 0, type internal Last update from 88.1.11.9 1d01h ago Routing Descriptor Blocks: * 88.1.11.9 (Default-IP-Routing-Table), from 88.1.11.9, 1d01h ago Route metric is 0, traffic share count is 1 AS Hops 0
Nota: Solamente una ruta está presente para la red de destino desde la perspectiva del router PE de salida (iguana).
Por lo tanto, no se pudo distinguir el tráfico de varias VPN de clientes y el tráfico de retorno no pudo alcanzar la VPN adecuada. En el caso en que el servicio compartido se debe definir como una instancia VRF, la función NAT se debe mover al PE de ingreso.
NAT PE de entrada
En este ejemplo, los routers de borde del proveedor marcados con gila y dragon están configurados para NAT. Se define un conjunto NAT para cada VPN de cliente conectada que necesita acceso al servicio compartido. El conjunto apropiado se utiliza para cada una de las direcciones de red del cliente que son NATed. La NAT se realiza solamente en los paquetes destinados al host de servicio compartido en 88.1.88.8.
ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat pool SSPOOL2 192.168.2.1 192.168.2.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload ip nat inside source list 181 pool SSPOOL2 vrf custB overload
Nota: En este escenario, no se admiten grupos compartidos. Si la LAN de servicio compartido (en el PE de salida) está conectada a través de una interfaz genérica, el conjunto NAT puede ser compartido.
Un ping originado en una dirección duplicada (172.31.1.1) dentro de cada una de las redes conectadas a neuse y capefear8 da como resultado estas entradas NAT:
De gila:
gila# show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.1.1:2139 172.31.1.1:2139 88.1.88.8:2139 88.1.88.8:2139 icmp 192.168.1.1:2140 172.31.1.1:2140 88.1.88.8:2140 88.1.88.8:2140 icmp 192.168.1.1:2141 172.31.1.1:2141 88.1.88.8:2141 88.1.88.8:2141 icmp 192.168.1.1:2142 172.31.1.1:2142 88.1.88.8:2142 88.1.88.8:2142 icmp 192.168.1.1:2143 172.31.1.1:2143 88.1.88.8:2143 88.1.88.8:2143 icmp 192.168.2.2:676 172.31.1.1:676 88.1.88.8:676 88.1.88.8:676 icmp 192.168.2.2:677 172.31.1.1:677 88.1.88.8:677 88.1.88.8:677 icmp 192.168.2.2:678 172.31.1.1:678 88.1.88.8:678 88.1.88.8:678 icmp 192.168.2.2:679 172.31.1.1:679 88.1.88.8:679 88.1.88.8:679 icmp 192.168.2.2:680 172.31.1.1:680 88.1.88.8:680 88.1.88.8:680
Nota: La misma dirección local interna (172.31.1.1) se traduce a cada uno de los conjuntos definidos según el VRF de origen. El VRF se puede ver en el comando show ip nat translation verbose:
gila# show ip nat translations verbose
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.1:2139 172.31.1.1:2139 88.1.88.8:2139 88.1.88.8:2139
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:2140 172.31.1.1:2140 88.1.88.8:2140 88.1.88.8:2140
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:2141 172.31.1.1:2141 88.1.88.8:2141 88.1.88.8:2141
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:2142 172.31.1.1:2142 88.1.88.8:2142 88.1.88.8:2142
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:2143 172.31.1.1:2143 88.1.88.8:2143 88.1.88.8:2143
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.2.2:676 172.31.1.1:676 88.1.88.8:676 88.1.88.8:676
create 00:00:10, use 00:00:10, left 00:00:49, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.2.2:677 172.31.1.1:677 88.1.88.8:677 88.1.88.8:677
create 00:00:10, use 00:00:10, left 00:00:49, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.2.2:678 172.31.1.1:678 88.1.88.8:678 88.1.88.8:678
create 00:00:10, use 00:00:10, left 00:00:49, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.2.2:679 172.31.1.1:679 88.1.88.8:679 88.1.88.8:679
create 00:00:10, use 00:00:10, left 00:00:49, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.2.2:680 172.31.1.1:680 88.1.88.8:680 88.1.88.8:680
create 00:00:10, use 00:00:10, left 00:00:49, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
Estas visualizaciones muestran la información de ruteo para cada una de las VPN conectadas localmente para el cliente A y el cliente B:
gila# show ip route vrf custA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
I - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 88.1.11.1 to network 0.0.0.0
172.18.0.0/32 is subnetted, 2 subnets
B 172.18.60.179 [200/0] via 88.1.11.1, 00:03:59
B 172.18.60.176 [200/0] via 88.1.11.1, 00:03:59
172.31.0.0/24 is subnetted, 1 subnets
S 172.31.1.0 [1/0] via 10.88.162.6, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B 10.88.0.0/20 [200/0] via 88.1.11.1, 00:03:59
B 10.88.32.0/20 [200/0] via 88.1.11.1, 00:03:59
C 10.88.162.4/30 is directly connected, FastEthernet0/0
C 10.88.162.8/30 is directly connected, FastEthernet2/0
B 10.88.161.8/30 [200/0] via 88.1.11.1, 00:04:00
88.0.0.0/24 is subnetted, 2 subnets
B 88.1.88.0 [200/0] via 88.1.11.5, 00:04:00
B 88.1.99.0 [200/0] via 88.1.11.5, 00:04:00
S 192.168.1.0/24 is directly connected, Null0
B* 0.0.0.0/0 [200/0] via 88.1.11.1, 00:04:00
gila# show ip route vrf custB
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
I - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
64.0.0.0/16 is subnetted, 1 subnets
B 64.102.0.0 [200/0] via 88.1.11.5, 1d21h
172.18.0.0/32 is subnetted, 2 subnets
B 172.18.60.179 [200/0] via 88.1.11.1, 1d21h
B 172.18.60.176 [200/0] via 88.1.11.1, 1d21h
172.31.0.0/24 is subnetted, 1 subnets
S 172.31.1.0 [1/0] via 10.88.162.14, Ethernet1/2
10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
B 10.88.194.16/28 [200/100] via 88.1.11.1, 1d20h
B 10.88.208.0/20 [200/0] via 88.1.11.5, 1d21h
B 10.88.194.4/30 [200/100] via 88.1.11.1, 1d20h
B 10.88.163.4/30 [200/0] via 88.1.11.5, 1d21h
B 10.88.161.4/30 [200/0] via 88.1.11.1, 1d21h
C 10.88.162.12/30 is directly connected, Ethernet1/2
11.0.0.0/24 is subnetted, 1 subnets
B 11.1.1.0 [200/100] via 88.1.11.1, 1d20h
88.0.0.0/24 is subnetted, 2 subnets
B 88.1.88.0 [200/0] via 88.1.11.5, 1d21h
B 88.1.99.0 [200/0] via 88.1.11.5, 1d21h
S 192.168.2.0/24 is directly connected, Null0
B 128.0.0.0/8 [200/0] via 88.1.11.5, 1d21h
Nota: Desde la configuración estática se ha agregado una ruta para cada uno de los conjuntos NAT. Estas subredes se importan posteriormente en el VRF del servidor compartido en la iguana del router PE de salida:
iguana# show ip route vrf sserver
Routing Table: sserver
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
I - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
64.0.0.0/16 is subnetted, 1 subnets
B 64.102.0.0 [20/0] via 10.88.163.6 (custB), 1d20h
172.18.0.0/32 is subnetted, 2 subnets
B 172.18.60.179 [200/0] via 88.1.11.1, 1d20h
B 172.18.60.176 [200/0] via 88.1.11.1, 1d20h
172.31.0.0/24 is subnetted, 1 subnets
B 172.31.1.0 [200/0] via 88.1.11.9, 1d05h
10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks
B 10.88.194.16/28 [200/100] via 88.1.11.1, 1d20h
B 10.88.208.0/20 [20/0] via 10.88.163.6 (custB), 1d20h
B 10.88.194.4/30 [200/100] via 88.1.11.1, 1d20h
B 10.88.162.4/30 [200/0] via 88.1.11.9, 1d20h
B 10.88.163.4/30 is directly connected, 1d20h, Ethernet1/0/0
B 10.88.161.4/30 [200/0] via 88.1.11.1, 1d20h
B 10.88.162.8/30 [200/0] via 88.1.11.9, 1d20h
B 10.88.162.12/30 [200/0] via 88.1.11.9, 1d20h
11.0.0.0/24 is subnetted, 1 subnets
B 11.1.1.0 [200/100] via 88.1.11.1, 1d20h
12.0.0.0/24 is subnetted, 1 subnets
S 12.12.12.0 [1/0] via 88.1.99.10
88.0.0.0/24 is subnetted, 3 subnets
C 88.1.88.0 is directly connected, FastEthernet1/1/0
S 88.1.97.0 [1/0] via 88.1.99.10
C 88.1.99.0 is directly connected, FastEthernet5/0/0
B 192.168.1.0/24 [200/0] via 88.1.11.9, 1d20h
B 192.168.2.0/24 [200/0] via 88.1.11.9, 01:59:23
B 128.0.0.0/8 [20/0] via 10.88.163.6 (custB), 1d20h
Configuraciones
Se ha eliminado cierta información superflua de las configuraciones para su brevedad.
GILA: ip vrf custA rd 65002:100 route-target export 65002:100 route-target export 65002:1001 route-target import 65002:100 ! ip vrf custB rd 65002:200 route-target export 65002:200 route-target export 65002:2001 route-target import 65002:200 route-target import 65002:10 ! ip cef mpls label protocol ldp !
interface Loopback0 ip address 88.1.11.9 255.255.255.255 ! interface FastEthernet0/0 ip vrf forwarding custA ip address 10.88.162.5 255.255.255.252 ip nat inside duplex full ! interface Ethernet1/0 ip address 88.1.3.1 255.255.255.0 ip nat outside no ip mroute-cache duplex half tag-switching ip ! interface Ethernet1/1 ip address 88.1.2.1 255.255.255.0 ip nat outside no ip mroute-cache duplex half tag-switching ip ! interface Ethernet1/2 ip vrf forwarding custB ip address 10.88.162.13 255.255.255.252 ip nat inside duplex half ! router ospf 881 log-adjacency-changes redistribute static subnets network 88.1.0.0 0.0.255.255 area 0 default-metric 30 ! router bgp 65002 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 88.1.11.1 remote-as 65002 neighbor 88.1.11.1 update-source Loopback0 neighbor 88.1.11.1 activate neighbor 88.1.11.5 remote-as 65002 neighbor 88.1.11.5 update-source Loopback0 neighbor 88.1.11.5 activate no auto-summary ! address-family ipv4 vrf custB redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf custA redistribute connected redistribute static no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 88.1.11.1 activate neighbor 88.1.11.1 send-community extended neighbor 88.1.11.5 activate neighbor 88.1.11.5 send-community extended no auto-summary exit-address-family ! ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat pool SSPOOL2 192.168.2.1 192.168.2.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload ip nat inside source list 181 pool SSPOOL2 vrf custB overload ip classless ip route vrf custA 172.31.1.0 255.255.255.0 FastEthernet0/0 10.88.162.6 ip route vrf custA 192.168.1.0 255.255.255.0 Null0 ip route vrf custB 172.31.1.0 255.255.255.0 Ethernet1/2 10.88.162.14 ip route vrf custB 192.168.2.0 255.255.255.0 Null0 ! access-list 181 permit ip any host 88.1.88.8 !
Nota: Las interfaces que se enfrentan a las redes del cliente se designan como interfaces "internas" NAT y las interfaces MPLS se designan como interfaces "externas" NAT.
iguana: ip vrf custB rd 65002:200 route-target export 65002:200 route-target export 65002:2001 route-target import 65002:200 route-target import 65002:10 ! ip vrf sserver rd 65002:10 route-target export 65002:10 route-target import 65002:2001 route-target import 65002:1001 ! ip cef distributed mpls label protocol ldp !
interface Loopback0 ip address 88.1.11.5 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Ethernet1/0/0 ip vrf forwarding custB ip address 10.88.163.5 255.255.255.252 no ip route-cache no ip mroute-cache ! interface Ethernet1/0/4 ip address 88.1.1.1 255.255.255.0 no ip route-cache no ip mroute-cache tag-switching ip ! interface Ethernet1/0/5 ip address 88.1.3.2 255.255.255.0 no ip route-cache no ip mroute-cache tag-switching ip ! interface FastEthernet1/1/0 ip vrf forwarding sserver ip address 88.1.88.1 255.255.255.0 no ip route-cache no ip mroute-cache full-duplex ! router ospf 881 log-adjacency-changes redistribute static subnets network 88.1.0.0 0.0.255.255 area 0 ! router bgp 65002 no synchronization no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 88.1.11.1 remote-as 65002 neighbor 88.1.11.1 update-source Loopback0 neighbor 88.1.11.9 remote-as 65002 neighbor 88.1.11.9 update-source Loopback0 neighbor 88.1.11.10 remote-as 65002 neighbor 88.1.11.10 update-source Loopback0 no auto-summary ! address-family ipv4 multicast no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 88.1.11.1 activate neighbor 88.1.11.1 send-community extended neighbor 88.1.11.9 activate neighbor 88.1.11.9 send-community extended no auto-summary exit-address-family ! address-family ipv4 neighbor 88.1.11.1 activate neighbor 88.1.11.9 activate neighbor 88.1.11.10 activate no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf sserver redistribute connected no auto-summary no synchronization exit-address-family ! address-family ipv4 vrf custB redistribute connected redistribute static no auto-summary no synchronization exit-address-family
El dragón del router tendría una configuración muy similar a gila.
Paquetes que llegan a PE central después de NAT PE de entrada
Los seguimientos a continuación ilustran el requisito de conjuntos NAT únicos cuando la red de servicio compartido de destino se configura como una instancia VRF. Una vez más, consulte el diagrama de la Figura 5. Los paquetes que se muestran a continuación fueron capturados cuando ingresaron a la interfaz IP MPLS e1/0/5 en la iguana del router.
Eco del cliente A VPN
Aquí, vemos una solicitud de eco proveniente de la dirección IP de origen 172.31.1.1 en VRF custA. La dirección de origen se ha traducido a 192.168.1.1 según lo especificado por la configuración NAT:
ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload
DLC: ----- DLC Header -----
DLC:
DLC: Frame 1 arrived at 09:15:29.8157; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 00019
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 0
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 4AE6 (correct)
IP: Source address = [192.168.1.1]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = 932D (correct)
ICMP: Identifier = 3046
ICMP: Sequence number = 3245
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
Eco desde VPN del cliente B
Aquí, vemos una solicitud de eco proveniente de la dirección IP de origen 172.31.1.1 en VRF custB. La dirección de origen se ha traducido a 192.168.2.1 según lo especificado por la configuración NAT:
ip nat pool SSPOOL2 192.168.2.1 192.168.2.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL2 vrf custB overload
DLC: ----- DLC Header -----
DLC:
DLC: Frame 11 arrived at 09:15:49.6623; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 00019
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 15
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 49D6 (correct)
IP: Source address = [192.168.2.2]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = AB9A (correct)
ICMP: Identifier = 4173
ICMP: Sequence number = 4212
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Nota: El valor de la etiqueta MPLS es 0019 en ambos paquetes mostrados arriba.
Respuesta de eco al cliente A VPN
A continuación, vemos una respuesta de eco que vuelve a la dirección IP de destino 192.168.1.1 en VRF custA. La dirección de destino es traducida a 172.31.1.1 por la función NAT de PE de ingreso.
To VRF custA:
DLC: ----- DLC Header -----
DLC:
DLC: Frame 2 arrived at 09:15:29.8198; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 0090BF9C6C1C
DLC: Source = Station 005054D92A25
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 0001A
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 18075
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = C44A (correct)
IP: Source address = [88.1.88.8]
IP: Destination address = [192.168.1.1]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = 9B2D (correct)
ICMP: Identifier = 3046
ICMP: Sequence number = 3245
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
ICMP:
Respuesta de eco a VPN del cliente B
Aquí, vemos una respuesta de eco que vuelve a la dirección IP de destino 192.168.1.1 en VRF custB. La dirección de destino es traducida a 172.31.1.1 por la función NAT de PE de ingreso.
To VRF custB:
DLC: ----- DLC Header -----
DLC:
DLC: Frame 12 arrived at 09:15:49.6635; frame size is 118 (0076 hex) bytes.
DLC: Destination = Station 0090BF9C6C1C
DLC: Source = Station 005054D92A25
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 0001D
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 37925
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 75BF (correct)
IP: Source address = [88.1.88.8]
IP: Destination address = [192.168.2.2]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = B39A (correct)
ICMP: Identifier = 4173
ICMP: Sequence number = 4212
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Nota: En los paquetes devueltos, los valores de etiqueta MPLS se incluyen y difieren: 001A para VRF custA y 001D para VRF custB.
Eco del cliente A VPN - El destino es una interfaz genérica
Este siguiente conjunto de paquetes muestra la diferencia cuando la interfaz a la LAN de servicio compartido es una interfaz genérica y no parte de una instancia VRF. Aquí, la configuración se ha cambiado para utilizar un conjunto común para ambas VPN locales con direcciones IP superpuestas.
ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload ip nat inside source list 181 pool SSPOOL1 vrf custB overload
DLC: ----- DLC Header -----
DLC:
DLC: Frame 1 arrived at 09:39:19.6580; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 00019
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 55
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 4AAF (correct)
IP: Source address = [192.168.1.1]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = 0905 (correct)
ICMP: Identifier = 874
ICMP: Sequence number = 3727
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Eco desde VPN cliente B: el destino es una interfaz genérica
Aquí, vemos una solicitud de eco proveniente de la dirección IP de origen 172.31.1.1 en VRF custB. La dirección de origen se tradujo a 192.168.1.3 (del conjunto común SSPOOL1) según lo especificado por la configuración NAT:
ip nat pool SSPOOL1 192.168.1.1 192.168.1.254 prefix-length 24 ip nat inside source list 181 pool SSPOOL1 vrf custA overload ip nat inside source list 181 pool SSPOOL1 vrf custB overload
DLC: ----- DLC Header -----
DLC:
DLC: Frame 11 arrived at 09:39:26.4971; frame size is 118 (0076 hex)
bytes.
DLC: Destination = Station 005054D92A25
DLC: Source = Station 0090BF9C6C1C
DLC: Ethertype = 8847 (MPLS)
DLC:
MPLS: ----- MPLS Label Stack -----
MPLS:
MPLS: Label Value = 0001F
MPLS: Reserved For Experimental Use = 0
MPLS: Stack Value = 1 (Bottom of Stack)
MPLS: Time to Live = 254 (hops)
MPLS:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 75
IP: Flags = 0X
IP: .0.. .... = may fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 4A99 (correct)
IP: Source address = [192.168.1.3]
IP: Destination address = [88.1.88.8]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 8 (Echo)
ICMP: Code = 0
ICMP: Checksum = 5783 (correct)
ICMP: Identifier = 4237
ICMP: Sequence number = 977
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Nota: Cuando la interfaz en el PE de salida es una interfaz genérica (no una instancia VRF), las etiquetas impuestas son diferentes. En este caso, 0x19 y 0x1F.
Respuesta de eco al cliente A VPN - El destino es una interfaz genérica
A continuación, vemos una respuesta de eco que vuelve a la dirección IP de destino 192.168.1.1 en VRF custA. La dirección de destino es traducida a 172.31.1.1 por la función NAT de PE de ingreso.
DLC: ----- DLC Header -----
DLC:
DLC: Frame 2 arrived at 09:39:19.6621; frame size is 114 (0072 hex)
bytes.
DLC: Destination = Station 0090BF9C6C1C
DLC: Source = Station 005054D92A25
DLC: Ethertype = 0800 (IP)
DLC:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 54387
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 3672 (correct)
IP: Source address = [88.1.88.8]
IP: Destination address = [192.168.1.1]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = 1105 (correct)
ICMP: Identifier = 874
ICMP: Sequence number = 3727
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Respuesta de eco a VPN del cliente B: el destino es una interfaz genérica
Aquí, vemos una respuesta de eco que vuelve a la dirección IP de destino 192.168.1.3 en VRF custB. La dirección de destino es traducida a 172.31.1.1 por la función NAT de PE de ingreso.
DLC: ----- DLC Header -----
DLC:
DLC: Frame 12 arrived at 09:39:26.4978; frame size is 114 (0072 hex)
bytes.
DLC: Destination = Station 0090BF9C6C1C
DLC: Source = Station 005054D92A25
DLC: Ethertype = 0800 (IP)
DLC:
IP: ----- IP Header -----
IP:
IP: Version = 4, header length = 20 bytes
IP: Type of service = 00
IP: 000. .... = routine
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = ECT bit - transport protocol will ignore the CE
bit
IP: .... ...0 = CE bit - no congestion
IP: Total length = 100 bytes
IP: Identification = 61227
IP: Flags = 4X
IP: .1.. .... = don't fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 254 seconds/hops
IP: Protocol = 1 (ICMP)
IP: Header checksum = 1BB8 (correct)
IP: Source address = [88.1.88.8]
IP: Destination address = [192.168.1.3]
IP: No options
IP:
ICMP: ----- ICMP header -----
ICMP:
ICMP: Type = 0 (Echo reply)
ICMP: Code = 0
ICMP: Checksum = 5F83 (correct)
ICMP: Identifier = 4237
ICMP: Sequence number = 977
ICMP: [72 bytes of data]
ICMP:
ICMP: [Normal end of "ICMP header".]
Nota: Dado que las respuestas están destinadas a una dirección global, no se imponen etiquetas VRF.
Con la interfaz de salida al segmento de LAN de servicio compartido definido como una interfaz genérica, se permite un conjunto común. Los pings resultan en estas entradas NAT en el router gila:
gila# show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 192.168.1.3:4237 172.31.1.1:4237 88.1.88.8:4237 88.1.88.8:4237 icmp 192.168.1.3:4238 172.31.1.1:4238 88.1.88.8:4238 88.1.88.8:4238 icmp 192.168.1.3:4239 172.31.1.1:4239 88.1.88.8:4239 88.1.88.8:4239 icmp 192.168.1.3:4240 172.31.1.1:4240 88.1.88.8:4240 88.1.88.8:4240 icmp 192.168.1.3:4241 172.31.1.1:4241 88.1.88.8:4241 88.1.88.8:4241 icmp 192.168.1.1:874 172.31.1.1:874 88.1.88.8:874 88.1.88.8:874 icmp 192.168.1.1:875 172.31.1.1:875 88.1.88.8:875 88.1.88.8:875 icmp 192.168.1.1:876 172.31.1.1:876 88.1.88.8:876 88.1.88.8:876 icmp 192.168.1.1:877 172.31.1.1:877 88.1.88.8:877 88.1.88.8:877 icmp 192.168.1.1:878 172.31.1.1:878 88.1.88.8:878 88.1.88.8:878 gila#
gila# show ip nat tr ver
Pro Inside global Inside local Outside local Outside global
icmp 192.168.1.3:4237 172.31.1.1:4237 88.1.88.8:4237 88.1.88.8:4237
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:4238 172.31.1.1:4238 88.1.88.8:4238 88.1.88.8:4238
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:4239 172.31.1.1:4239 88.1.88.8:4239 88.1.88.8:4239
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:4240 172.31.1.1:4240 88.1.88.8:4240 88.1.88.8:4240
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.3:4241 172.31.1.1:4241 88.1.88.8:4241 88.1.88.8:4241
create 00:00:08, use 00:00:08, left 00:00:51, Map-Id(In): 2,
flags:
extended, use_count: 0, VRF : custB
icmp 192.168.1.1:874 172.31.1.1:874 88.1.88.8:874 88.1.88.8:874
create 00:00:16, use 00:00:16, left 00:00:43, Map-Id(In): 3,
Pro Inside global Inside local Outside local Outside global
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:875 172.31.1.1:875 88.1.88.8:875 88.1.88.8:875
create 00:00:18, use 00:00:18, left 00:00:41, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:876 172.31.1.1:876 88.1.88.8:876 88.1.88.8:876
create 00:00:18, use 00:00:18, left 00:00:41, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:877 172.31.1.1:877 88.1.88.8:877 88.1.88.8:877
create 00:00:18, use 00:00:18, left 00:00:41, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
icmp 192.168.1.1:878 172.31.1.1:878 88.1.88.8:878 88.1.88.8:878
create 00:00:18, use 00:00:18, left 00:00:41, Map-Id(In): 3,
flags:
extended, use_count: 0, VRF : custA
gila# debug ip nat vrf IP NAT VRF debugging is on gila# .Jan 2 09:34:54 EST: NAT-TAGSW(p) : Tag Pkt s=172.18.60.179, d=10.88.162.9, vrf=custA .Jan 2 09:35:02 EST: NAT-TAGSW(p) : Tag Pkt s=172.18.60.179, d=10.88.162.13, vrf=custB .Jan 2 09:35:12 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custA .Jan 2 09:35:12 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:12 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custA .Jan 2 09:35:12 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:12 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custA .Jan 2 09:35:12 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:12 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custA .Jan 2 09:35:12 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:12 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custA .Jan 2 09:35:12 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:19 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custB .Jan 2 09:35:19 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:19 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custB .Jan 2 09:35:19 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:19 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custB .Jan 2 09:35:19 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:19 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custB .Jan 2 09:35:19 EST: NAT-ip2tag: Punting to process .Jan 2 09:35:19 EST: NAT-ip2tag : Tag Pkt s=172.31.1.1, d=88.1.88.8, vrf=custB .Jan 2 09:35:19 EST: NAT-ip2tag: Punting to process gila#
Ejemplo de servicio
En la Figura 8 se muestra un ejemplo de un servicio PBX IP virtual compartido. Esto ilustra una variante de los ejemplos de ingreso y egreso descritos anteriormente.
En este diseño, el servicio VoIP compartido es de extremo frontal por un conjunto de routers que realizan la función NAT. Estos routers tienen varias interfaces VRF usando una función conocida como VRF-Lite. El tráfico entonces fluye al clúster compartido de Cisco CallManager. Los servicios de firewall también se proporcionan por empresa. Las llamadas entre empresas deben pasar a través del firewall, mientras que las llamadas dentro de la empresa se gestionan a través de la VPN del cliente mediante el esquema de direccionamiento interno de la empresa.
Figura 8: Ejemplo de Servicio PBX Virtual Administrado 
Disponibilidad
El soporte NAT de Cisco IOS para VPNs MPLS está disponible en la versión 12.2(13)T del IOS de Cisco y está disponible para todas las plataformas que soportan MPLS y pueden ejecutar esta versión de implementación temprana.
Conclusión
La NAT de Cisco IOS cuenta con funciones que permiten la implementación escalable de servicios compartidos en la actualidad. Cisco continúa desarrollando compatibilidad con el gateway de nivel de aplicación (ALG) NAT para protocolos importantes para los clientes. Las mejoras en el rendimiento y la aceleración del hardware para las funciones de traducción garantizarán que NAT y ALG proporcionen soluciones aceptables durante algún tiempo. Cisco supervisa todas las actividades relacionadas con estándares y las acciones de la comunidad. A medida que se desarrollen otros estándares, su uso se evaluará en función de los deseos, los requisitos y la aplicación del cliente.
Comentarios