Switching por etiquetas multiprotocolo (MPLS) : Switching por etiquetas multiprotocolo por ATM (MPLS over ATM)

Flujo de paquetes en un entorno de VPN MPLS

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento ilustra el flujo de paquetes a través de una nube de la Virtual Private Network (VPN) de Multiprotocol Label Switching (MPLS). También presenta el concepto de poseer varias etiquetas dentro de un paquete.

VPN, cuando se utiliza con MPLS, permite la interconexión transparente entre varios sitios a través de la red de un proveedor de servicio. Una red proveedora de servicios puede ofrecer soporte a varias VPN IP diferentes Cada una de éstas le aparece a sus usuarios como una red privada, separada de todas las otras redes. Dentro de una VPN, cada sitio puede enviar paquetes IP a cualquier otro sitio dentro de la misma VPN

Cada VPN está asociada con uno o más casos de reenvío o ruteo VPN (VRF). Un VRF consiste de una tabla de IP Routing, una tabla de Cisco Express Forwarding (CEF) y un conjunto de interfaces que usen estas tablas de reenvío.

El router mantiene un ruteo separado y una tabla CEF para cada VRF. Esto impide que la información se envíe fuera de la VPN y permite que pueda usarse la misma subred en varias VPN sin causar problemas de dirección IP duplicada

El router que utiliza el Border Gateway Protocol (BGP) distribuye la información de ruteo VPN utilizando las comunidades extendidas BGP.

Para más información con respecto a la difusión de actualizaciones con un VPN, refiera a estos documentos:

La característica del MPLS VPN fue introducida en el Software Release 12.0(5)T del½ del¿Â del Cisco IOSïÂ.

Antes de comenzar

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

prerrequisitos

No hay requisitos previos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Diagrama de la red

Para entender cómo funciona una VPN MPLS, observemos el siguiente ejemplo de configuración:

/image/gif/paws/10474/mpls-packflow-01.gif

En esta configuración:

  • Rapid y Pound son los dispositivos de borde del cliente (CE) que no ejecutan MPLS. Se asocian al VPN VRF101. Para mayor simplicidad, aquí sólo utilizamos un VRF.

  • Farm y Medina son los dispositivos de borde del proveedor (PE).

  • Miles y Yard son routers LightStream 1010. Éstos constituyen la red troncal de MPLS.

El proceso del flujo de paquetes

El resultado siguiente muestra lo que sucede cuando Rapid envía los paquetes al Pound dentro del VRF101 VPN:

rapid#ping 11.5.5.5
      
     Type escape sequence to abort.
     Sending 5, 100-byte ICMP Echos to 11.5.5.5, timeout is 2 seconds:
     !!!!!
     Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

     rapid#show ip route 11.5.5.5
     Routing entry for 11.5.5.4/30
       Known via "rip", distance 120, metric 1
       Redistributing via rip
       Last update from 150.150.0.1 on FastEthernet0/1, 00:00:16 ago
       Routing Descriptor Blocks:
       * 150.150.0.1, from 150.150.0.1, 00:00:16 ago, via FastEthernet0/1
           Route metric is 1, traffic share count is 1

Farm obtiene la dirección 11.5.5.5 de Med ina a través de los anuncios BGP:

Farm#show ip bgp vpnv4 vrf vrf101 11.5.5.5 
     BGP routing table entry for 1:101:11.5.5.4/30, version 56 
        Paths: (1 available, best #1, table vrf101) 
        Not advertised to any peer 
        Local 
          125.2.2.2 (metric 4) from 125.2.2.2 (125.2.2.2) 
            Origin incomplete, metric 1, localpref 100, valid, internal, best 
            Extended Community: RT:1:101 

     Farm#show ip route vrf vrf101 11.5.5.5 
     Routing entry for 11.5.5.4/30 
        Known via "bgp 1", distance 200, metric 1, type internal 
        Redistributing via rip 
        Advertised by rip metric 0 
        Last update from 125.2.2.2 01:29:20 ago 
        Routing Descriptor Blocks: 
        * 125.2.2.2 (Default-IP-Routing-Table), from 125.2.2.2, 01:29:20 ago      
            Route metric is 1, traffic share count is 1      
            AS Hops 0 

Nota: 125.2.2.2 es un loopback en el Medina y se utiliza para crear la sincronización de BGP con Farm.

Para enviar el paquete destinado a 11.5.5.5 a Medina, Farm usa dos etiquetas. Para ver esto, observe la tabla de reenvío de etiquetas de CEF y de VPN en Farm:

Farm#show tag forwarding
-table vrf vrf101 11.5.5.5 detail 
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     None   2/91        11.5.5.4/30       0          AT4/0.1    point2point  
             MAC/Encaps=4/12, MTU=4466, Tag Stack{2/91(vcd=69) 40}
             00458847 0004500000028000

     Farm#show ip cef vrf vrf101 11.5.5.5
     11.5.5.4/30, version 25, cached adjacency to ATM4/0.1
     0 packets, 0 bytes
       tag information set
         local tag: VPN-route-head
         fast tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40}
       via 125.2.2.2, 0 dependencies, recursive
         next hop 10.0.0.14, ATM4/0.1 via 125.2.2.2/32
         valid cached adjacency
         tag rewrite with AT4/0.1, point2point, tags imposed: {2/91(vcd=69) 40}

Se aplican dos etiquetas a los paquetes que egresan del bloque y están destinados a 11.5.5.5. Se pueden representar de esta manera:

/image/gif/paws/10474/mpls-packflow-02.gif

Se agrega la etiqueta 40 al paquete y, a continuación, se segmenta en celdas con 2/91 como valores VPI/VCI. Esto significa que la etiqueta se denomina también 2/91.

Nota: Al recibir una trama con varias escrituras de la etiqueta, el dispositivo receptor marca solamente el primer uno.

Las etiquetas se asignan de la siguiente manera:

  • Yard asigna la 2/91, que corresponde a la dirección 125.2.2.2. Este direccionamiento se utiliza para crear la sincronización de BGP con Farm. Refiera al MPLS VPN sobre la atmósfera: con el BGP o RIP en el sitio del cliente para más información. La etiqueta se usa en el núcleo MPLS para enviar tramas desde el bloque de servidores hasta 125.2.2.2 en Medina.

  • Medina asigna 40 a 11.5.5.5. Cuando un PE (Medina en este caso) conoce un prefijo de IP desde un CE (Pound), el PE asigna una etiqueta específica a esta ruta. La etiqueta depende del VRF de VPN que la ruta haya detectado. Anuncia la ruta y la etiqueta a los otros PE utilizando comunidades BGP mejoradas.

Echemos una vistazo a Medina:

Medina#show tag forwarding
-table vrf vrf101 11.5.5.5 detail
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     40     Untagged    11.5.5.4/30[V]    570        Et1/1      11.3.3.2     
             MAC/Encaps=0/0, MTU=1500, Tag Stack{}
             VPN route: vrf101
         Per-packet load-sharing

Ahora que sabemos de adónde las escrituras de la etiqueta vienen, podemos ver qué sucede a los paquetes destinados para 11.5.5.5. La granja envía el paquete dividido en segmentos sobre el VC 2/91. La yarda recibe esto. Para ver lo que Yard hace con estas células, utilice el siguiente comando:

Yard#show tag atm
-tdp bindings 125.2.2.2 32
      Destination: 125.2.2.2/32
         Transit ATM0/1/1 2/91 Active -> ATM4/0/0 1/82 Active

Al recibir estas celdas en el VC 2/91 (celdas destinadas a 125.2.2.2, también conocida como Medina), Yard conmuta estas celdas hacia Miles mediante el VC saliente 1/82.

Nota: La yarda no ha marcado o la escritura de la etiqueta modificada 40.

Los mismo sucede con Miles, ya que conmuta las celdas a Medina en el VC 1/33:

Miles#show tag atm
-tdp bindings 125.2.2.2 32
      Destination: 125.2.2.2/32
         Transit ATM0/1/3 1/82 Active -> ATM0/1/1 1/33 Active

El paquete que llega a Medina puede representarse así:

/image/gif/paws/10474/mpls-packflow-03.gif

Al recibir las células en el VC 1/33, el Medina marca la escritura de la etiqueta 1/33 y ve que esta escritura de la etiqueta es local al router. Al hacerlo, Median observa que el paquete está destinado para una de sus propias direcciones:

Medina#show tag
-switching atm-tdp bindings local-tag 1 33
      Destination: 125.2.2.2/32
         Tailend Router ATM2/0.66 1/33 Active, VCD=406

Medina, entonces, elimina la primera etiqueta (1/33) y verifica que el paquete tiene otra etiqueta (40). Luego evalúa a qué corresponde esta etiqueta y conmuta el paquete en forma adecuada:

Medina#show tag
-switching forwarding-table tags 40
     Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop    
     tag    tag or VC   or Tunnel Id      switched   interface              
     40     Untagged    11.5.5.4/30[V]    570        Et1/1      11.3.3.2

En este caso, el Medina ve que el paquete es destinado para un sitio conectado por un link IP ordinario. Descarta la etiqueta y envía el paquete de IP de la interfaz ethernet 1/1.


Información Relacionada


Document ID: 10474