CTH MPLS 2016 Print

consulteach
CURSO
REDES MPLS
Sobre plataformas IOS
consulteach 1
1.- INTRODUCCIÓN Y CONCEPTOS MPLS
Definiciones y conceptos MPLS
Labels y Label Stack
AGENDA Aplicaciones MPLS
LABORATORIO: Visualización y análisis de PDUs con rótulos MPLS
2.- IMPLEMENTACIÓN MODO FRAME EN CISCO IOS
Cisco CEF
Configuración modo Frame en plataformas Cisco IOS
Monitoreo del modo Frame
Diagnóstico
LABORATORIO: Configuración de una red de servicios MPLS, identificando los CEs, PEs
y Ps. Monitoreo de las operaciones Visualización de las PDUs
3.- ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS
Prohibida su reproducción total o parcial no sin previo consentimiento de consulteach.

Descubrimiento de vecinos LDP
Distribución de labels en modo Frame
Este documento es propiedad de consulteach. consulteach@cnsulteach.com.ar

Convergencia en modo Frame
LABORATORIO: Configuración y verificación de las operaciones con rótulos.
Visualización de las PDUs
4.- TECNOLOGÍA MPLS VPN
Redes VPN
Arquitectura MPLS VPN
Modelo de enrutamiento MPLS VPN
Envío de paquetes MPLS VPN
LABORATORIO: Análisis del soporte de los elementos de red para las redes VPN.
Requerimientos de configuración (bloques funcionales) en PEs y Ps
5.- IMPLEMENTACIÓN MPLS VPN
Mecanismos MPLS VPN del IOS
Sesión MP-BGP entre routers PE
Preparado por: Ing. Julio César Carossella

Tablas VRF
Enrutamiento entre routers PE y CE (pequeña escala, OSPF y BGP
Monitoreo de operaciones MPLS VPN
Diagnóstico MPLS VPN
LABORATORIO: Configuración de una red MPLS-VPN.
Buenos Aires, Junio 2016

Monitoreo de las operaciones. Diagnósticos
6.- MPLS VPNs Avanzadas
Overlapping MPLS-VPN
Central Services
Servicio Routers CE gestionado
LABORATORIO: Configuración de una red VPN overlapping.
Configuración de un CE gestionado
7.- ACCESO A INTERNET
Combinación Acceso Internet y MPLS VPN
Implementación de Acceso Internet en MPLS VPN
Servicio Routers CE gestionado
LABORATORIO: Configuración de una red MPLS-VPN con acceso a Internet..
Verificación de la operación. Visualización de PDUs
8.- INGENIERÍA DE TRÁFICO MPLS
Componentes MPLS-TE y Operaciones MPLS-TE
Configuración MPLS-TE en plataformas IOS
Monitoreo MPLS TE en plataformas IOS
LABORATORIO: Configuración MPLS-TE en plataformas IOS. Monitoreo MPLS TE en
plataformas IOS. Visualización de PDUs
consulteach 2
REPASO DE CONCEPTOS LEGADOS
Switching – Routing – Líneas dedicadas
INTRODUCCIÓN Y CONCEPTOS MPLS

NEXT NEXT
RED IF RED IF
HOP HOP
10.1.1.0 10.1.0.0
/24 S0/0 R2 /24 S0/0 R1
10.1.0.0 10.1.1.0
/24 F0/0 conectada /24 F0/0 conectada
encapsulation hdlc
IP IP
10.1.1.1 10.1.1.1
IP
10.1.1.1
IP
10.1.1.1
1.- PC 10.1.0.1 2.- R1 2.- R2

Datagrama IP Æ 10.1.1.1 a) Verifica H y T Ethernet a) Verifica H y T HDLC
a) Determina destino red remota b) Consulta Tabla Rutas b) Consulta Tabla Rutas
b) Obtiene MAC del DG (ARP) c) Define interface de salida c) Define interface de salida (local)
c) Agrega Header y Trailer Ethernet d) Agrega encapsulación (HDLC) d) Obtiene MAC de destino (ARP)
d) Envía e) Envía e) Agrega encapsulación (Ethernet)
f) Envía
La función de switching Ethernet y las VLANs (capa 2) son típicas en el acceso de los
usuarios
La función de ROUTING permite el envío de paquetes desde un origen en una subredes
hacia su destino en otra subred. Multitud de opciones y protocolos están disponibles para que
ello suceda.
Si
Si
Si Si
Si Si
consulteach 3
REPASO DE CONCEPTOS LEGADOS
Modelos VPN Overlay

El SP provee servicio de enlaces punto-a-punto o circuitos
virtuales a través de su propia red, entre los routers de los
clientes.
SP no tiene conocimiento de las rutas de los clientes.
No existe relación de rutas entre los equipos

del SP y del cliente. Desde la perspectiva de
la conectividad del cliente, los routers
aparecen conectados directamente.
Estos servicios punto-a-punto podrían ser de capa 1 (tales como Time Division Multiplexing (TDM), E1, E3, SONET, y enlaces
SDH), 2 (ATM, Frame Relay) ó 3 (X.25, IP).
El servicio overlay puede brindarse sobre una red IP, usando túneles (PPTP, L2TP, L2F o GRE). GRE permite enrutar tráficos no IP
sobre la red IP del Service Provider.
FRAME RELAY
RA(config)#interface s0.34 point-to-point
RA(config-subif)#ip address 1.1.1.1 /24
RA(config-subif)#frame-relay interface-dlci 34
INT DLCI INT DLCI

RB(config)#interface s0.22 point-to-point
SWITCH FR 6 RB(config-subif)#ip address 1.1.1.2 /24
3 22 2 65 RB(config-subif)#frame-relay interface-dlci 22
SWITCH FR 5
3 65 2 44
SWITCH FR 2
3 44 1 31
SWITCH FR 1
2 31 1 34
consulteach 4
DEFINICIONES Y CONCEPTOS MPLS
Modelos VPN: Peer-to-Peer

Enrutamiento aislado
entre VPNs
Tabla enrutamiento
VPN A VRF para VPN A
Tabla enrutamiento
VPN B VRF para VPN B
Tabla enrutamiento
■ El cliente comparte la responsabilidad del routing con el SP.
Global Global ■ Los PE deben soportar funciones extra.
En el modelo VPN peer-to-peer, los routers del SP no sólo transportan los datos de los
clientes a través de su red, sino que también participan en la función de enrutamiento de sus
clientes. Los dispositivos de red del SP establecen relaciones de enrutamiento con los
dispositivos de red de los clientes, a nivel de capa 3.
El resultado es que los protocolos de enrutamiento establecen adyacencias entre los equipos
de SP y del cliente.
Antes de la existencia de MPLS, el modelo VPN peer-to-peer podía lograrse creando
enrutamiento peering entre los routers del cliente y el SP. Para proveer privacidad o
aislamiento entre diferentes clientes se configuran filtros de paquetes (ACLs), o configurar
filtros de rutas para controlar el anuncio de rutas entre las redes. O también aplicar ambos
métodos simultáneamente.
Antes de MPLS, era mucho más común desplegar el modelo VPN overlay que el peer-to-
peer, porque este último demandaba una gran carga de aprovisionamiento, y muchos
cambios de configuración en muchos sitios.
Un router del cliente, denominado router CE (Customer Edge), se conecta a nivel de IP con al
menos un router del proveedor denominado router PE (Provider Edge).
La privacidad en las redes MPLS VPN se logra utilizando el concepto VRF (Virtual
Routing/Forwarding) y el hecho de que los datos son transmitidos en el backbone como
paquetes rotulados.
VRF asegura que la información de enrutamiento de clientes diferentes se mantengan
aisladas, y MPLS en el backbone asegura que los paquetes sean transmitidos en base a la
información de los rótulos y no del header IP
consulteach 5
MPLS y el Modelo OSI

Modo Frame
Shim header
Protocolo de Nombre del identificador de

Valor (Hexa)
Encapsulación Capa 2 protocolo de Capa 2
PPP Campo protocolo PPP 0281
Ethernet/802.3
Valor Ethertype 8847
LLC/SNAP
HDLC Protocolo 8847
NLPID (ID de protocolo de capa de
Frame Relay 80
Red)
Label switching significa que las unidades de información (PDUs) ya no son paquetes IPv4,
IPv6, ó tramas de capa2: son unidades de información rotuladas (labeled).
El rótulo se aplica entre el encabezamiento (header) de la capa transportada y el

encabezamiento de la capa 2.
La capa 2 de encapsulación podría ser PPP, HDLC, Ethernet, FR, etc. Por consiguiente
surgen nuevos valores para el campo “protocolo” de las capas de enlace de datos, indicando
que lo que sigue es un paquete rotulado de MPLS.
ATM está ausente del cuadro porque utiliza una única manera de encapsular el rótulo.
El header SNAP contiene el identificador OUI 0x000000 y el Ethertype 0x8847
El protocolo transportado podría ser, teóricamente cualquiera, tanto de capa 3 (IPv4, IPv6,
etc) ó de capa 2 (Frame Relay, PPP, HDLC, ATM y Ethernet).
Entonces, MPLS no es un protocolo de capa 2 (porque el encabezamiento de capa 2 original

todavía está presente), ni tampoco de capa 3 (porque el protocolo transportado también
mantiene su encabezamiento), por lo que suele indicarse que MPLS es un protocolo de capa
2,5 (y por eso el nombre de shim header o separador).
consulteach 6
Labels (rótulos) y Label Stack (Pila)
0 -------------------------------------------------------------------------19-20—22--23--24-----------------------------31

El bit 23 es el Bottom of Stack, y posee el valor 0 para todos los rótulos, excepto el
último rótulo de la pila que tendrá el valor 1.
En el ejemplo, se proveen servicios TE (Traffic Engineering y VPN.
Los routers siempre miran el último (OUTER)
El rótulo es una estructura de 32 bits, donde los primeros 20 bits son el valor del rótulo. De los posibles
220 valores, los primeros 16 valores se encuentran reservados con un significado especial.
Los bits 20 a 22 constituyen el campo EXP, el cual es en realidad la QoS.
El bit 23 es el Bottom of Stack, cuyo valor es 0 para todos los rótulos, excepto el último de la pila.
Los bits 24 a 31 son el TTL (con la misma función que el campo homónimo de IP).
Los LSR podrían necesitar agregar más de un rótulo para enrutar exitosamente un paquete a través de
la red MPLS. El primer rótulo se denomina Top, y el último Bottom. En medio de ellos podrían existir
cualquier número posible de otros rótulos.
Cuando existen rótulos múltiples, el OUTER apunta al LSR de egreso.
Una vez que el tráfico llega a un LSR en particular, un segundo rótulo es utilizado para determinar el
destinatario final o el componente que debe procesar ese paquete.
En caso de VPNs, el top label apunta al router de egreso, y el segundo indentifica a la VPN, con
significado sólo para los routers de edge.
El label exterior (outer label) se utiliza para transportar el paquete MPLS a través de la red.
El rótulo TE apunta al extremo del túnel TE, definiendo la manera en la que los paquetes son enviados
a través de la red. Todos los LSR intermedios utilizan este rótulo, ignorando todos los otros rótulos
interiores.
El segundo rótulo se usa para apuntar al router de egreso, y al llegar al mismo, entonces el tercer rótulo
identifica a la VPN.
En cualquier caso, los rótulos son utilizados para conducir el tráfico hacia los destinos deseados, sobre
trayectos en el dominio MPLS.
Pero también pueden utilizarse los rótulos como segregadores de tráfico.
Una trama Ethernet, sin rótulos, posee un EtherType: 0x0800, para identificar que la carga (payload) es
un paquete IP.
Las tramas Ethernet poseen un identificador 0x8847 para identificar paquetes MPLS routulados.
consulteach 7
DEFINICIONES Y CONCEPTOS MPLS LSP = Label Switched Path
Labels (rótulos) y Label Stack (Pila) CE = Customer Edge

PE = Provider Edge

P = Provider
LSR = Label switching Router
LER = Label Edge Router
LDP = Label Distribution Protocol
FEC = Forwarding Equivalence Class
PUSH SWAP SWAP POP

(imposing 129) (129 Æ 17) (17 Æ 33) (disposing 33)
Un LSR es un router con capacidad de entender los rótulos MPLS, y recibir/transmitir

paquetes rotulados.
Existen tres tipos de LSRs: Ingreso (reciben y rotulan paquetes sin rotular y los transmiten
rotulados), egreso reciben y remueven los rótulos de paquetes rotulados y los transmiten sin
rotular) e intermedios (reciben paquetes rotulados, realizan alguna operación y los transmiten
rotulados).
Un LSR puede realizar tres tipos de operaciones: pop (remover uno o más rótulos del tope de
la pila), push (agregar uno o más rótulos), o swap (reemplazar el rótulo del tope de la pila por
otro).
Un LSR que coloca rótulos sobre un paquete aún no rotulado se denomina imposing LSR
(Ingress LSR), mientras que el LSR que remueve todos los rótulos se denomina disposing
LSR (Egress LSR).
En el caso de redes MPLS VPN, los LSR de ingreso y egreso se denominan PE (Provider
Edge), y los LSR intermedios se denomina P (Provider). Estos términos son tan populares
que suelen denominarse de esta manera aún cuando la red MPLS no este corriendo VPN.
Un LSP (Label Switched Path) es una secuencia unidireccional de LSRs que indican el
trayecto de conmutación de un paquete rotulado en la red MPLS.
Pueden existir LSPs anidados, de manera que el LSR de ingreso de un LSP no es
necesariamente el imposing LSR.
consulteach 8
Operaciones con Labels (rótulos)

Las posibles operaciones de los LSR sobre los rótulos, son: swap, push y pop.
Los LSR toman en cuenta el rótulo top del paquete rotulado recibido y verifican una entrada
para dicho valor en la LFIB, con lo que encuentra como debe reenviar dicho paquete.
Al mismo tiempo, el LSR determina qué operación ejecutar (swap, push o pop), y cual es el
LSR next-hop hacia donde debe forwardear el paquete.
La operación de swap significa que el rótulo top de la pila de rótulos debe ser reemplazado
por otro.
La operación de push involucra el reemplazo del rótulo top y la incorporación de otro rótulo
adicional que pasa a ser en nuevo top.
La operación pop significa quitar o remover el rótulo top.
consulteach 9
LSP y FEC

FEC (Forwarding Equivalence Class): grupo o flujo de paquetes, transmitidos con
similar tratamiento, sobre un LSP.
FEC => RÓTULO (LABEL)
RÓTULO => FEC {EXP}
LSP (Label Switched Path): secuencia unidireccional de LSRs que indican el

trayecto de conmutación de un paquete rotulado en la red MPLS
Todos los paquetes pertenecientes al mismo FEC poseen el mismo valor de rótulo (aunque no
todos los paquetes con el mismo rótulo pertenecen al mismo FEC, porque puede diferir el EXP o
tratamiento). FEC => LABEL
El LSR de ingreso clasifica y rotula los paquetes, definiendo su FEC, como por ejemplo:
■ Paquetes con un mismo prefijo de destino IP
■ Paquetes con el mismo grupo de multicast
■ Paquetes con el mismo tratamiento de envío, en base al código DiffServ ó precedencia
■ Tramas recibidas por un VC o subinterface del LSR de ingreso y transmitidas por un VC ó
subinterface del LSR de egreso
■ Paquetes con un mismo destino IP pertenecientes a un grupo de prefijos BGP, y con el mismo
valor de Next Hop (es decir que reciben un mismo rótulo dependiendo del router BGP de destino)
El LSR de ingreso consulta su tabla de forwarding (envío) para todas las direcciones de destino de
los paquetes IP recibidos. Todas las direcciones en la tabla de enrutamiento pertenecientes a un
mismo conjunto de prefijos se conocen como prefijos BGP.
A todos los paquetes con prefijos BGP que posean el mismo LSR de egreso como dirección next-
hop, se les impone el mismo FEC.
consulteach 10
Distribución de Labels (rótulos) – Envío de tráfico

1. “Cargar” los rótulos sobre un protocolo de enrutamiento existente
■ Sólo se han desarrollado extensiones para iBGP, y se utiliza en las redes MPLS VPN
2. Utilizar un protocolo de distribución de rótulos separado

■ Tag Distribution Protocol (TDP) - Propietario de Cisco: obsoleto
■ Label Distribution Protocol (LDP) - El protocolo utilizado
■ Resource Reservation Protocol (RSVP) - Sólo utilizado por MPLS TE
El primer rótulo (1 o +) lo impone el LSR de ingreso: ese rótulo pertenece y define un LSP. Los LSR
intermedios cambian ese rótulo (swap) para enviar el paquete a lo largo del LSP hasta el LSR de
egreso, remueve (pop) el rótulo y lo transmite fuera de la red.
Si MPLS corre sobre IPv4, los LSR deben correr algún IGP (OSPF, ISIS, ó EIGRP). El LSR de
ingreso consulta la dirección IPv4 de destino en su tabla de rutas, impone un rótulo y lo transmite
hacia su next-hop. Todos los LSR intermedios reciben el paquete rotulado, ejecutan el swap y lo
retransmiten hasta el LSR de egreso, quién extrae el rótulo.
Todos los LSR adyacentes deben ponerse de acuerdo en qué rótulo utilizar para cada prefijo,
mediante un proceso de comunicación y distribución de rótulos (mediante algún protocolos de
enrutamiento existente modificado o utilizando uno independiente.
Todos los LSR relacionan cada prefijo IPv4 en su tabla de rutas IGP con un rótulo (mapeo ó binding
local). Puede existir un rótulo por prefijo o un rótulo por prefijo y por interface (según el espacio de
rótulos).
Estos mapeos son distribuidos a todos sus vecinos LDP (mapeos o bindings remotos). Puede existir
más de un mapeo remoto por prefijo, recibidos de diferentes vecinos LDP.
Todos estos mapeos se almacenan en la LIB (Label Information Base).
De todos los mapeos remotos para un mismo prefijo, recibidos de los LSR downstream, el LSR sólo
escoge uno para determinar el rótulo saliente para ese prefijo. La tabla de enrutamiento RIB (Routing
Instance Base) determina el router next-hop.
Con toda esta información, cada LSR elabora la LFIB (Label Forwarding Information Base), a partir
de la cual puede manejarse sólo con rótulos.
La LFIB también podría poblarse con rótulos no asignados por LDP, como por ejemplo en MPLS TE
los rótulos son distribuidos por RSVP, y en MPLS VPN, los rótulos son distribuidos por MP-iBGP.
A los LSR intermedios no les interesa saber cual es el protocolo transportado porque sólo trabajan
con los rótulos, pero el LSR de egreso debe colocar en el campo protocolo de la capa 2 el
identificador correspondiente. ¿Cómo lo sabe? Porque él originó el LSP a partir del FEC.
consulteach 11
Modos MPLS – Espacio de Rótulos

■ Por Plataforma
Espacio de rótulos
■ Por Interface
■ Downstream-on-Demand (DoD)
Modo de distribución de rótulos
■ Unsolicited Downstream (UD)
■ Liberal (LLR)
Modo de retención de rótulos
■ Conservativo (CLR)
■ Independiente
Modo de control LSP
■Ordenado
Cada LSR solicita a su LSR downstream en el LSP un mapeo para el FEC que
DoD
necesita. Es decir que cada LSR sólo recibe un mapeo por cada FEC. La LIB sólo
contiene un mapeo remoto por prefijo.
Distribución
Cada LSR distribuye sus mapeos a sus LSR adyacentes (que participan en el
UD
protocolo LDP) sin ninguna solicitud previa. La LIB puede tener varios mapeos remotos
por prefijo.
El modo de distribución de rótulos utilizado depende de la interface y de la

implementación. El IOS de Cisco utiliza distribución UD para el modo Frame.
En modo LLR, los LSR mantienen todos los mapeos remotos en la LIB, aunque sólo
uno es el mapeo recibido del downstream LSR para ese FEC, y sólo ese es colocado
LLR
Retención
en la LFIB.
Mientras que en modo CLR, los LSR no mantiene todos los mapeos remotos en la LIB,
CLR
sino solamente el que está asociado con el LSR next-hop para ese FEC.
Cisco utiliza el modo LLR para todas las interfaces, excepto para LC-ATM.
En el modo de control LSP Independiente, cada LSR crea un mapeo local tan pronto
Indep
como reconoce cada FEC, independientemente de los otros LSRs. Por ejemplo para
cada ruta de la RIB.
Control
En el modo de control LSP Ordenado, cada LSR crea el mapeo local sólo si reconoce
Orden
que es el LSR de egreso para el FEC, o si ha recibido un mapeo del LSR next-hop
para ese FEC.
Cisco utiliza el modo Independiente, excepto en el modo Frame
consulteach 12
Rótulos reservados

Los valores 0 a 15 corresponden a rótulos reservados, y ningún LSR puede utilizar estos
valores en operaciones normales de envío de paquetes.
0 = Explicit NULL; 1 = Router Alert; 3 = Implicit NULL; 14 = OAM Alert: Resto = No asignados
Un LSR de egreso asigna el rótulo implicit NULL si no desea asignar un rótulo a ese FEC (el
LSR upstream realiza el pop). Por ejemplo asigna estos rótulos a todos su prefijos
conectados y sumarizados. Con esto evita realizar dos lookups (uno en la LFIB y otro en la
CEF).
Así, el anteúltimo LSR en el LSP se llama PHP (Penultimate Hop Popping)
El uso del implicit NULL se aplica en otras situaciones, por ejemplo cuando existen dos o más
rótulos en la pila, el LSR de egreso señaliza al PHP para que elimine un rótulo. El valor 3
nunca se debe ver en una pila y por eso se denomina implícito: no existe.
El inconveniente de usar el implicit NULL es que al quitar el rótulo, también desaparecen los
bits EXP. Si es necesario conservar el valor de Qos, debe utilizarse el explicit NULL (valor 0).
Así, el LSR de egreso recibe los paquetes rotulados con el valor 0, el cual quita para efectuar
el lookup en la CEF, con la ventaja de poder copiar los bits EXP del rótulo explicit NULL.
También el PHP puede copiar los bits EXP al campo precedence/DiffServ. O si la pila posee
varios rótulos, durante el pop off puede copiarse el EXP al próximo rótulo top.
consulteach 13
Rótulos reservados – Explicit Null

Los valores 0 a 15 corresponden a rótulos reservados, y ningún LSR puede utilizar estos
valores en operaciones normales de envío de paquetes.
0 = Explicit NULL; 1 = Router Alert; 3 = Implicit NULL; 14 = OAM Alert: Resto = No asignados
Un LSR de egreso asigna el rótulo implicit NULL si no desea asignar un rótulo a ese FEC (el
LSR upstream realiza el pop). Por ejemplo asigna estos rótulos a todos su prefijos
conectados y sumarizados. Con esto evita realizar dos lookups (uno en la LFIB y otro en la
CEF).
Así, el anteúltimo LSR en el LSP se llama PHP (Penultimate Hop Popping)

El uso del implicit NULL se aplica en otras situaciones, por ejemplo cuando existen dos o más
rótulos en la pila, el LSR de egreso señaliza al PHP para que elimine un rótulo. El valor 3
nunca se debe ver en una pila y por eso se denomina implícito: no existe.
El inconveniente de usar el implicit NULL es que al quitar el rótulo, también desaparecen los
bits EXP. Si es necesario conservar el valor de Qos, debe utilizarse el explicit NULL (valor 0).
Así, el LSR de egreso recibe los paquetes rotulados con el valor 0, el cual quita para efectuar
el lookup en la CEF, con la ventaja de poder copiar los bits EXP del rótulo explicit NULL.
También el PHP puede copiar los bits EXP al campo precedence/DiffServ. O si la pila posee
varios rótulos, durante el pop off puede copiarse el EXP al próximo rótulo top.
consulteach 14
Rótulos reservados – Router Alert

El rótulo Router Alert (1) no puede aparecer como BoS. Cuando es el top, alerta al LSR que
el paquete requiere especial atención, con lo que el mismo no se forwardea en hardware, sino
por un proceso de software.
El rótulo 1 se remueve y se realizan todas las operaciones normales, sólo que antes de
enviarlo se vuelve a colocar el rótulo 1 como top.
Se muestra la salida del comando debug mpls packet.
El valor 14 es el rótulo Alerta OAM (Operation and Maintenance), según la recomendación

ITU-T Recommendation Y.1711 y RFC 3429, para diferenciar los paquetes normales de
aquellos con propósitos de monitoreo de performance, detección y localización de fallas.
Cisco IOS ejecuta operaciones OAM MPLS pero no lo utiliza el rótulo 14.
Excepto por los rótulos 0 a 15, todos los otros valores pueden aparecer en el envío normal de
paquetes. En el IOS de Cisco, el rango por defecto es 16 a 100.000 (más que suficiente para
rotular los prefijos IGP). Ahora si es necesario trabajar con los prefijos BGP (Internet), puede
cambiarse ese número hasta el máximo permitido.
mpls label range min max command.
consulteach 15

TTL (Time To Live) es un mecanismo bien conocido tomado de IP. Un campo de 8 bits que
indica el tiempo de vida de un paquete. Cuando un paquete se envía, usualmente con el valor
255, el TTL se va decrementando en 1 en cada salto. Si llega a 0, el paquete es descartado.
En este caso, el router envía un mensaje ICMP tipo 11, código 0 (time exceeded) al
originador del paquete IP.
En MPLS, el uso del TTL es similar a IP, y su valor se propaga entre el header IP y el rótulo, y
viceversa.
En el IOS Cisco, el TTL MPLS no se copia al datagrama IP si su valor es mayor que el que
transporta el datagrama recibido con rótulo (es decir que siempre el valor tiene que
decrementarse).
Si la operación entre paquetes rotulados en un swap, el TTL del paquete recibido se
decrementa y se coloca en el rótulo swappeado.
Si la operación entre paquetes rotulados en un push (uno o más rótulos), el TTL del rótulo top
del paquete recibido se decrementa y se coloca en todos los rótulos agregados (pushed).
Si la operación es un pop, el valor TTL del rótulo top recibido se decrementa y se coloca en el
nuevo rótulo top (a menos que el valor TTL existente sea menor, en cuyo caso la copia no se
realiza).
Obviamente, todos los LSR intermedios sólo pueden operar sobre los valores en los rótulos
top de la pila, y no pueden cambiar el valor del campo TTL de los otros rótulos subyacentes
en la pila, como tampoco el del datagrama IP.
consulteach 16

Drop
Cuando un LSR recibe un paquete rotulado con TTL= 1, lo descarta y envía un mensaje
ICMP de Tiempo Excedido (tipo 11, código 0) hacia el originador del paquete IP.
Sin embargo, el mensaje ICMP no es enviado de regreso inmediatamente porque el LSR

intermedio seguramente no posee la información necesaria (en general, los routers P no
posee conocimiento de los prefijos IP, ya que sólo maneja rótulos). Entonces, el mensaje
ICMP se envía sobre el mismo LSP que seguía el paquete IP original, con la esperanza de
que llegue a un router al final del LSP que pueda retornar el mensaje hacia el origen.
En el caso de una red MPLS VPN, el mensaje ICMP es retornado por el LSR de egreso PE, o
por el router CE (Client Edge), ya que ambos poseen la información de las rutas.
Asimismo, es importante que el LSR P (donde expira el TTL) pueda identificar el tipo de carga
MPLS, ya que si no es un datagrama IPv4 (ó IPv6) no puede generar ningún mensaje ICMP,
y solamente le queda la acción de descartar el paquete, y nada más.
consulteach 17
MTU y MRU

Evitamos la fragmentación si las PDU MPLS
tendrán un máximo de 2 rótulos.
MTU (Maximum transmission unit) es el tamaño máximo de la unidad de datos que puede enviarse
por un enlace sin necesidad de fragmentación. Los enlaces de datos en las redes MPLS poseen
un MTU específico, apropiado para los paquetes rotulados. Cada rótulo incrementa el tamaño del
paquete en 4 bytes..
El parámetro MPLS, MRU (MPLS Maximun Receive Unit), lo usa la LFIB para fijar el tamaño
máximo de los paquetes rotulados que pueden enviarse sin necesidad de fragmentar.
El comando de interface “mtu” especifica el tamaño máximo del paquete de capa 3 que puede
enviarse por un enlace. Para Ethernet, MTU= 1500 bytes. Pero con rótulos, debe fragmentar.
Por ejemplo, si los paquetes enviados en el enlace poseen un máximo de 2 rótulos, y el MTU es
de 1500 bytes, puede configurarse MPLS MTU = 1508 bytes, para evitar la fragmentación.
MRU (Maximum receive unit) informa al LSR el tamaño máximo de un paquete rotulado, para
cierto FEC que puede ser enviado sin fragmentación. El valor aplica a cada FEC (o prefijo) y no a
la interface.. El tamaño máximo de los paquetes recibidos y transmitidos puede aumentar o
disminuir en función de las operaciones con los rótulos.
- MRU del prefijo 10.200.254.2/32 es 1512: el paquete puede ser de hasta 1512 bytes, porque un
rótulo es retirado antes de la transmisión.
- MRU de 10.200.254.3/32 es 1508: el tamaño no cambia porque sólo el rótulo top es swappeado.
- MRU del prefijo 10.200.254.4/32 es 1504: el paquete sólo puede ser de 1500 bytes porque se
agrega (push) un rótulo extra antes de enviarlo (aumenta 4 bytes).
Si el paquete rotulado, recibido por el LSR es demasiado grande, debe fragmentar. Quita la pila
de rótulos, fragmenta el datagrama, realiza las operaciones con los rótulos, reinstala la pila de
rótulos en todos los fragmentos y los transmite. Si posee “Don´t Fragment”, el paquete es
descartado y se genera un mensaje ICMP “Fragmentation needed and do not fragment bit set”
(ICMP type 3, code 4).
Para evitar fragmentación y problemas de performance, se usa el método Path MTU Discovery.
consulteach 18
Cisco CEF
Operaciones de lookup - CEF
Regenera
header capa 2
IMPLEMENTACIÓN MODO FRAME

Quita header
capa 2
IP A IP
IP A RÓTULO
LSR
RÓTULO A IP
RÓTULO A RÓTULO
PE1#show ip cef 10.1.1.1
10.0.0.0/8, version 44, epoch 0, cached adjacency 20.20.20.2
0 packets, 0 bytes
tag information set, all rewrites owned
local tag: 20
fast tag rewrite with Et0/0/0, 20.20.20.2, tags imposed {18}
via 20.20.20.2, Ethernet0/0/0, 0 dependencies
next hop 20.20.20.2, Ethernet0/0/0
valid cached adjacency
tag rewrite with Et0/0/0, 20.20.20.2, tags imposed {18}
Los paquetes son enviados por los routers utilizando 3 formas básicas:
1.- Process Switching (Proceso programado para ejecutarse ante la llegada de paquetes)
2.- Interrupt Switching (el procesador de Interface interrumpe a CPU para que conmute el paquete
utilizando una tabla o cache).
3.- ASIC (procesamiento por HW en base a tabla o cache)
Las tablas o cache pueden ser generadas por demanda (Fast Switching – ip route-cache) o pre-
generadas (CEF – ip cef)
Cuando un LSR recibe un paquete IP, la consulta (lookup) es sobre la tabla IP (CEF – Cisco
Express Forwarding). Si recibe un paquete rotulado, el lookup se realiza sobre la tabla LFIB.
¿Cómo reconoce el LSR la diferencia? --> Por el EtherType (o análogo de capa 2)
Ya sea mediante un lookup en la tabla CEF o LFIB, el router puede enviar el paquete rotulado
(mpls) o sin rotular (ip). Si un LSR recibe un paquete IP y lo envía rotulado, el caso se denomina
forwarding IP a rótulo.
Si un LSR recibe un paquete rotulado, puede aplicar la operación pop y enviarlo como un paquete
IP (forwarding Rótulo a IP) o puede aplicar swap o push, y enviarlo como un paquete rotulado
(forwarding Rótulo a Rótulo).
Paquetes IP que ingresan al LSR ingress, con destino 10.1.1.1 son enviados a través de la
interface Ethernet0/0/0, después de imponerle el rótulo 18, hacia el next-hop 10.200.200.2
Router# show ip cef summary
consulteach 19
Cisco CEF
Planos de Gestión, Control y Datos

Plano de Control
Protocolo de enrutamiento
IP Routing Table (RIB)
Protocolo de rótulos
LIB
Plano de Datos
IP Forwarding Table (FIB)
Label Forwarding Table (LFIB)
MPLS optimiza el uso de CEF (Cisco Express Forwarding) y los protocolos de enrutamiento IGP.
construye su propia estructura de datos sobre la base del mismo modelo de plano de control y
plano de datos.
El plano de control, el routing IP tradicional, es un área de trabajo de los protocolos de

enrutamiento para construir la base de información de enrutamiento (RIB) mediante el intercambio
de prefijos de destino. En términos similares, MPLS posee un área de trabajo denominada LIB
(Label Information Base), utilizada como área de staging en el intercambio de rótulos.
Cada entrada en la RIB genera un rótulo y una entrada en la LIB, y los rótulos son intercambiados
via protocolo de distribución de rótulos (por ejemplo LDP).
El plano de datos es un motor de forwarding, independiente del tipo de protocolo de enrutamiento
o de distribución de rótulos que se use.
El plano de datos envía los paquetes hacia las interfaces apropiadas en base a la información de
la FIB (Forwarding Information Base), la cuál es construida por CEF y los protocolos de
enrutamiento. Todo basado en la información de la LFIB (Label Forwarding Information Base).
Los LSR hacen lookups de rótulos (LFIB) y lookups de IP (FIB)
consulteach 20
Cisco CEF
Planos de Gestión, Control y Datos

Un LSR trabaja primariamente con paquetes rotulados. Aún cuando la FIB no se muestra en el
plano de datos del LSR, siempre está presente en los LSR. Porque las funciones primarias de un
LSR son intercambiar rótulos con otros LSRs, a través del protocolo LDP, y transmitir paquetes
rotulados, evitando el overhead del routing IP. En el plano de control del ejemplo, EIGRP
intercambia actualizaciones de rutas con otros routers (en este caso la red 10.0.0.0/8)
Para cada uno de los prefijos en la tabla de enrutamiento, se genera un rótulo. En el ejemplo, el
rótulo 17 ha sido generado por el router, y se anuncia a los otros routers mediante LDP.
Cuando el router recibe el rótulo 24, proveniente de un router downstream, se construye la LFIB,
asociando los rótulos 24 y 17. Así, cuando se reciba un paquete con label 24 en el plano de datos,
el LSR realizará el swap con el rótulo 17 y lo enviará hacia el próximo salto.
De manera que la información de ruteo se usa para generar la información de rótulos, la cual es
aplicada a los paquetes, en lugar de los headers IP.
consulteach 21
CONFIGURACIÓN MODO FRAME EN PLATAFORMAS CISCO IOS
Diagrama de red – Especificaciones y Configuración
Plan de direccionamiento:
> Red Serie: 10.0.0./24

S1/1
S1/1 > Red Loopback: 10.0.1.0/24
S1/0 > Redes Clientes: 10.1.0.0/24
S1/0
> Red MGMT: 192.168.0.0/24
Protocolo de enrutamiento IGP: EIGRP
ID de proceso EIGRP: 100
EIGRP [100] S1/0

S1/0 S1/3 S1/3
MPLS
S1/2 S1/1
S1/1
S1/1
S1/2
S1/1
VERIFICACIÓN
S1/0
Se utilizan 2 comandos para verificar el
funcionamiento de los LSRs.
S1/0 # show mpls ldp discovery
F0/0 # show mpls ldp neighbor
CONFIGURACIÓN EIGRP
router eigrp 100 ! Habilitar EIGRP con ID de proceso 100
network 10.0.0.0 0.0.0.255 ! Habilitar EIGRP en interfaces serie
network 10.0.1.X 0.0.0.0 ! Habilitar EIGRP en la interface Loopback0
eigrp router-id 10.0.1.X ! Forzar q la ID EIGRP sea la IP Loopback0
CONFIGURACIÓN MPLS
ip cef ! Habilitar CEF, aunque está habilitado por defecto
mpls ip ! Habilitar MPLS IP switching en el router
mpls label protocol ldp !Seleccionar el protocolo de rótulos (labels)
mpls ldp router-id loopback 0 force !Fijar la identificación LDP
interface S0/0 ! Habilitar MPLS en las interfaces IP
mpls ip
consulteach 22
MONITOREO DEL MODO FRAME
Sesiones LDP L0:10.0.1.6/32
LDP Id: 10.0.1.2:0
L0:10.0.1.5/32
LDP Id: 10.0.1.3:0

LDP Id: 10.0.1.2:0
LDP Id: 10.0.1.3:0
L0:10.0.1.2/32
L0:10.0.1.3/32
LDP Id: 10.0.1.1:0 LDP Id: 10.0.1.1:0
LDP Id: 10.0.1.3:0 LDP Id: 10.0.1.2:0
LDP Id: 10.0.1.5:0 LDP Id: 10.0.1.5:0
LDP Id: 10.0.1.6:0 LDP Id: 10.0.1.6:0

LDP Id: 10.0.1.2:0
L0:10.0.1.1/32
LDP Id: 10.0.1.2:0
LDP Id: 10.0.1.4:0
VERIFICACIÓN
# show mpls ldp discovery
# show mpls ldp neighbor
# show mpls ldp bindings LDP Id: 10.0.1.1:0 L0:10.0.1.4/32
Cada uno de los LSR establece una sesión LDP con sus vecinos:
# show mpls ldp neighbor
Cada LSR asigna un rótulo local a cada prefijo IGP en la tabla de rutas -> LOCAL LABEL
BINDING.
Estos LOCAL LABEL BINDING se almacenan en la tabla LIB del router:
# show mpls ldp bindings [local]
Cada uno de los labels y sus correspondientes prefijos son anunciados vía LDP a todos sus
vecinos con los que tenga una sesión LDP.
Estos bindings aparecen en los vecinos LDP como bindings remotos, los cuales también son
almacenados en la LIB.
VERIFICACIÓN Y MONITOREO DEL TRÁFICO

1.- Establecer sesión CLI con el LSR PE3. Testear con ping y trace hacia el LSR PE1.
2.- Capturar tráfico en en enlace 10.0.0.28/30. Monitorear las PDUs. ¿Qué observa en la
encapsulación? ¿Las PDUs tienen la misma encapsulación en ambos sentidos?
3.- Capturar tráfico en los enlaces 10.0.0.4/32 y 10.0.0.12/32. Monitorear las PDUs. Realizar
las mismas observaciones que en el punto anterior. ¿Cuáles son su conclusiones?
consulteach 23
DIAGNÓSTICOS
Falla de vecindad (sesión) LDP 3
2 PE2(config)#mpls ip
PE2#show mpls ldp discovery PE2(config)#mpls label protocol ldp
PE2# PE2(config)#mpls ldp router-id l0 force

PE2(config)#int s1/0
10.0.1.5 PE2(config-if)#mpls ip
S1 *Jun 2 14:00:18.655: %LDP-5-NBRCHG: LDP Neighbor 10.0.1.2:0 (1) is UP
PE2 /1
(.2 PE2(config-if)#int s1/1
2)
PE2(config-if)#mpls ip
*Jun 2 14:00:28.175: %LDP-5-NBRCHG: LDP Neighbor 10.0.1.3:0 (2) is UP
10
.0. PE2(config-if)#
0.2
1 /3 0 0 S1
/3
(.2
P3#show mpls ldp discovery 1)
Local LDP Identifier:
10.0.1.3:0 P3
10.0.1.3
Discovery Sources:
Interfaces: EXPLICACIÓN
Serial1/0 (ldp): xmit/recv
1.- La verificación en el LSR indica que no se ha descubierto ningún
LDP Id: 10.0.1.6:0 vecino LDP a través de la interface Serial 1/3 (sólo xmit)
Serial1/1 (ldp): xmit/recv 2.- Verificado el LSR PE2 se descubre que este LSR no tiene vecinos LDP
LDP Id: 10.0.1.2:0 No posee la configuración adecuada
Serial1/2 (ldp): xmit/recv 3.- Se configura el switching MPLS IP y el protocolo de rótulos LDP
LDP Id: 10.0.1.1:0 Inmediatamente aparecen mensajes de logging consola indicando que se
Serial1/3 (ldp): xmit han establecido las sesiones LDP con los LSR vecinos
Para que los LSRs puedan intercambiar la información de los rótulos generados localmente
para cada prefijo, es necesario que tengan sesiones LDP establecidas con sus vecinos.
Si, por cualquier motivo, la cadena de rótulos “esta rota” es decir que no existe un LSP hasta
el destino, el LSR intentará enviar el tráfico utilizando enrutamiento IP (si la red de destino se
encuentra en su tabla de rutas).
Luego que la sesion LDP es establecida, cada LDP peer recibe un paquete LDP o mensaje
keepalive. cada vez q un LDP peer recibe un paquete LDP o keepalive, el timer keepalive es
reseteado para ese peer. El comando para el mpls holdtime es #mpls ldp holdtime, por
defecto es 180 segundos. Para ver la sesion LDP entre dos peer se usa #show mpls ldp
neighbor 10.10.10.1 detail, se vera el puerto local TCP y el puerto remoto. TCP Connection
IP:puerto, ademas se veran el holdtime y el estado de la conexion.
El comando #mpls ldp discovery transport-address interface ip address, especifica una
direccion ip para ser usada para crear una sesion LDP. Esta direccion IP se anuncia en los
hellos LDP.
Cuando se usa per-platform label space se requiere solo una sesion LDP.
Los mensajes de notificación son necesarios para mantener solo las sesiones viva LDP,
Los mensajes de notificación pueden indicar: fatal error, anuncio de información.
Si ocurre un error fatal la sesión LDP se corta.
Mensajes pueden ser por malformación de protocolo, expiración de timer, término de
sesiones unilaterales, errores internos, loops, etc.
consulteach 24
DESCUBRIMIENTO DE VECINOS LDP
Protocolo LDP - Funciones
ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS

Descubrimiento de LSRs que corren LDP
■ Intercambio de mensajes HELLO (Hold Time)
■ IP Multicast 224.0.0.2 (UDP/646)
Establecimiento y mantenimiento de sesiones LDP

■ Sesión LDP (TCP/646)
■ Parámetros de sesión (timers, métodos, etc)
Anuncios de mapeos de rótulos

■ Anuncios, cambios y retracciones
Housekeeping mediante notificaciones

■ Mensajes de advertencia y error
■ Malformaciones
El fundamento de MPLS es que los paquetes están rotulados y que cada LSR debe realizar la
conmutación adecuada de rótulos (label swapping) para procurar que el tráfico llegue a su
destino.
Entonces es necesario contar con un mecanismo de distribución de rótulos, y para ello se
utiliza LDP (Label Distribution Protocol), que transporta los mapeos FEC (Forwarding
Equivalence Class) de los prefijos generados por tdos los IGP, excepto para BGP, porque
este transporta prefijos EGP (entre AS) y rótulos. Entonces, los mapeos para los prefijos IGP
son distribuidos por LDP, y los mapeos correspondientes a las rutas BGP son distribuidas por
BGP.
Para enviar paquetes sobre un LSP en la red MPLS, todos los LSR deben correr LDP para
intercambiar los mapeos de los rótulos,
Después que todos los LSR del LSP posean rótulos para un determinado FEC, los paquetes
pueden ser enviados por el LSP.
Los LSR consultan la LFIB para el envío de los paquetes. La LFIB toma los mapeos de la LIB.
Y la LIB es alimentada por los mapeos recibidos por LDP, RSVP, MP-iBGP, y mapeos
asignados estáticamente. Como RSVP distribuye rótulos sólo para MPLS TE, MP-iBGP lo
hace sólo para las rutas BGP, entonces sólo queda LDP para la distribución de los rótulos de
las rutas IGP.
Todos los LSRs directamente conectados deben establecer una sesión LDP entre pares para
intercambiar los mapeos (asociación de un rótulo a un FEC).
RFC 3036 es la extensa especificación LDP.
consulteach 25
Protocolo LDP - Descubrimiento L0: L0:
10.0.1.2/32 10.0.1.3/32

S1/2 (.9)
S1/1 (.10)
P2 P3
10.0.0.8
/30
VERIFICACIÓN
CONFIGURACIÓN
P2#show mpls interfaces s1/2
Interface IP Tunnel BGP Static Operational
P2#show running-config P3#show running-config
Serial1/2 Yes (ldp) No No No Yes
hostname P2 hostname P3
! !
P2#show mpls ldp discovery detail ip cef ip cef
Local LDP Identifier: ! !
10.0.1.2:0 mpls label protocol ldp mpls label protocol ldp
Discovery Sources: ! !
Interfaces: interface Loopback0 interface Loopback0
Serial1/2 (ldp): xmit/recv ip address 10.0.1.2 255.255.255.255 ip address 10.0.1.3 255.255.255.255
Enabled: Interface config ! !
Hello interval: 5000 ms; Transport IP addr: 10.0.1.2 interface Serial1/1 interface Serial1/1
LDP Id: 10.0.1.3:0 ip address 10.0.0.2 255.255.255.252 ip address 10.0.0.10 255.255.255.252
Src IP addr: 10.0.0.10; Transport IP addr: 10.0.1.3 mpls ip mpls ip
Hold time: 15 sec; Proposed local/peer: 15/15 sec ! !
Reachable via 10.0.1.3/32 mpls ldp router-id Loopback0 force mpls ldp router-id Loopback0 force
Los LSRs que corren LDP poseen un LDP ID (Identificador LDP) de 6 bytes, con 4 bytes para
identificar unívocamente al LSR (a través de una dirección IP tomada de una interface
operacional del LSR) y 2 bytes para identificar al espacio de rótulos que utiliza el LSR (si los
últimos dos bytes son 0, es espacio de rótulos por plataforma, si son distintos de 0, el espacio
utilizado es por interface).
En este ejemplo, se han tomado como LPD ID a la dirección de loopback 0 de los LSRs.
En el IOS de Cisco, el MPLS LPD router ID necesita estar presente en la tabla de rutas de los
LSRs vecinos, de lo contrario, la sesión LDP no se establece.
Por ejemplo, si la ruta a la dirección IP 10.1.1.3 (P3) no está presente en la tabla de rutas del
LSR P2, no se establecerá la sesión LDP entre P2-P3.
Previamente a cualquier configuración MPLS en los routers Cisco, debe habilitarse CEF
mediante el comando global: ip cef.
Los LSRs que corren LDP envían mensajes Hello por todos los enlaces habilitados para LDP
(comando de interface: mpls ip).
Los mensajes Hello son transportados por UDP (puerto 646) hacia la dirección de multicast
“todos los routers de esta subred”, es decir 224.0.0.2.
Un LSR que recibe mensajes Hello LDP sobre alguna de sus interfaces habilitadas queda
advertido de la presencia de un router LDP sobre ese enlace.
Ese mensaje contiene un temporizador Hold Time, y si el LSR no recibe una respuesta al
Hello antes de que ese tiempo expire, lo elimina de la lista de vecinos.
Para verificar si el LSR envía y recibe los Hello, el intervalo y el Hold Time puede usarse el
comando show mpls ldp discovery [detail].
consulteach 26
Protocolo LDP - Sesiones

P2#show mpls ldp parameters
Protocol version: 1
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
LDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
P2#show mpls ldp neighbor 10.0.1.3 detail

Peer LDP Ident: 10.0.1.3:0; Local LDP Ident 10.0.1.2:0
TCP connection: 10.0.1.3.55557 - 10.0.1.2.646
State: Oper; Msgs sent/rcvd: 58/55; Downstream; Last TIB rev sent 34
Up time: 00:33:20; UID: 3; Peer Id 2;
LDP discovery sources:
Serial1/2; Src IP addr: 10.0.0.10
holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer LDP Ident:
10.0.0.25 10.0.1.3 10.0.0.10 10.0.0.6
10.0.0.21
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
Si dos LSRs se han descubierto mutuamente, intentarán establecer una sesión LDP: uno de
ellos intentará abrir una conexión TCP (puerto 646) en el otro. Si la conexión se establece,
ambos LSRs negocian los parámetros de sesión intercambiando mensajes de inicialización
LDP.
■ Valor de los temporizadores
■ Método de distribución de rótulos
■ Rangos VPI/VCI para Label Controlled ATM (LC-ATM)
■ Rangos DLCI para LC-Frame Relay
Si acuerdan los parámetros, la sesión LDP queda establecida, de lo contrario inician una
serie de reintentos cada vez más renuentes (backoff).
Para el mantenimiento se utilizan mensajes KA (KeepAlive).
Las sesiones LDP son conexiones TCP establecidas entre dos direcciones IP de los LSRs.
Normalmente, estas mismas direcciones constituyen el ID LDP de los routers. Si se desea,
puede cambiarse esta dirección con el comando: mpls ldp discovery transport-address
{interface | ipaddress}.
consulteach 27
Protocolo LDP – Anuncio de mapeos

L0: L0:
10.0.1.2/32 10.0.1.3/32
S1/2 (.9)
S1/1 (.10)
P2 P3
10.0.0.8
/30
P2#show mpls ldp neighbor detail

TCP connection: 10.0.1.3.55557 - 10.0.1.2.646
State: Oper; Msgs sent/rcvd: 68/66; Downstream; Last TIB rev sent 34
Up time: 00:42:27; UID: 3; Peer Id 2;
Serial1/2; Src IP addr: 10.0.0.10
holdtime: 15000 ms, hello interval: 5000 ms
10.0.0.25 10.0.1.3 10.0.0.10 10.0.0.6
10.0.0.21
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
El anuncio de los mapeos (o label bindings) es el propósito principal de LDP. Las dos
posibilidades de cada uno de los tres diferentes modos de comportamiento de los LSRs,
brindan los seis modos ya vistos en Modos MPLS.
Los mapeos son conjuntos [LDP ID, Rótulo] por prefijo.
Un router LDP recibe múltiples mapeos por cada prefijo (uno por cada par LDP.
Todos estos mapeos se guardan en la LIB, aunque sólo existe un par LDP que es el
downstream LSR para ese prefijo en particular (sólo si se ha configurado balanceo de cargas
puede existir más de un LSR downstream).
El LSR downstream es hallado consultando el next-hop para eses prefijo en la tabla de rutas.
Solamente el mapeo remoto asociado con ese LSR next-hop debería ser usado para poblar la
LFIB.
Esto significa que sólo un rótulo, de todos los mapeos anunciados por los vecinos LDP de
este LSR debería ser usado como rótulo outgoing en la LFIB para ese prefijo.
El problema es que los mapeos son anunciados como [LDP ID, Rótulo], sin indicar la
dirección IP de las interfaces. Por consiguiente, para encontrar el rótulo outgoing para un
prefijo, debe procurarse la concordancia entre el LDP ID y la dirección IP de la interface (que
apunta a ese LSR) en el downstream LSR. Todas las direcciones IP son anunciadas por el
par LDP mediante mensajes Address y retiradas mediante mensajes Withdraw. Estas
direcciones figuran como bound addresses para el par LDP.
consulteach 28
Protocolo LDP – Tablas LDP - LIB
P1#show mpls ldp bindings P1#show mpls ip binding

lib entry: 10.0.0.0/30, rev 9 10.0.0.0/30
local binding: label: imp-null in label: imp-null
remote binding: lsr: 10.0.1.2:0, label: imp-null out label: imp-null lsr: 10.0.1.2:0 inuse
remote binding: lsr: 10.0.1.3:0, label: 20 out label: 20 lsr: 10.0.1.3:0
lib entry: 10.0.0.4/30, rev 10 10.0.0.4/30
local binding: label: imp-null label: imp-null
lib entry: 10.0.0.20/30, rev 17 10.0.0.20/30
local binding: label: 21 in label: 21
lib entry: 10.0.0.28/30, rev 11 10.0.0.28/30
lib entry: 10.0.1.1/32, rev 8 10.0.1.1/32
Cada LSR asigna un rótulo local a cada prefijo IGP de su tabla de ruteo (mapeo local).
Estos mapeos locales son almacenados en la LIB.
Los mapeos locales, junto a los prefijos, son anunciados vía LDP a los pares LDP. Estos
mapeos son los mapeos remotos de los pares LDP que son almacenados en la LIB.
Para cada prefijo, el LSR siempre tiene un mapeo local y un mapeo remoto de cada par LDP.
La entrada “in label” aplica al mapeo local. Las entradas “out label” aplica a los remotos.
Puede verse el rótulo y el identificador LDP del LSR que envió el mapeo remoto.
La ventaja el comando show mpls ip binding es que muestra cuál, de todos los posibles
mapeos remotos, es usado para enviar tráfico, mediante la indicación “inuse” (es el rótulo
outgoing en la LFIB para ese prefijo).
consulteach 29
Protocolo LDP - Sesiones L0:
10.0.1.6/32

PE3 10
S1 .0.
0
0.1
6 /0
(.2 /30 .12
.0. 0 8)
0
1 /3 (.1 6)
/1
L0: S1
10.0.1.2/32 7) S1 L0:
(.1 /0 10.0.1.3/32
/3 (.2
S1 5 )
10.0.0.8
S1/2 (.9) /30
S1/1 (.10)
P2 P3
10
S1 .0. 0.4 )
/1
(
0
/30 .12 .0. (.6
.26 10 /30 /2
) S1
L0:
S1 10.0.1.1/32 )
/1
(.2 (.5
/2
6) S1
P1
S1/0 (.29)
10.0.0.28
/30 S1/0 (.30)
L0:
10.0.1.4/32
PE1
En el ejemplo, se muestra la asociación entre las tablas RIB, LIB, LFIB y las direcciones
asociadas comunicadas por los pares LDP.
Se indica la construcción de la entrada LFIB para un FEC asociado al prefijo 10.0.1.6/32.
El rótulo incoming/local para el prefijo se encuentra directamente en la LIB, pero el rótulo
outgoing se encuentra a través de la RIB, las direcciones asociadas a los pares LDP y la LIB.
El LSR P1 recibe rótulos asociados al prefijo 10.0.1.6/32, de todos los vecinos con los que ha
establecido una sesión LDP, a saber: PE1, P2, y P3.
El LSR P1 asigna una rótulo local (que es el que él mismo propagará).
Como todos los rótulos son conservados, es necesario determinar y decidir cuál corresponde
a la mejor ruta, hacia cuál LSR vecino enviar el tráfico y por cuál interface.
Toda esa información, que se almacenará en la LFIB, surge del análisis de las tablas LIB,
RIB, y pares LDP.
consulteach 30
2 RIB
Protocolo LDP - Sesiones P1#show ip route 10.0.1.6 255.255.255.255
Routing entry for 10.0.1.6/32

LIB 1
Known via "eigrp 100", distance 90, metric 2809856, type internal
P1#show mpls ldp bindings 10.0.1.6 32
Last update from 10.0.0.2 on Serial1/1, 01:28:04 ago
lib entry: 10.0.1.6/32, rev 31
Routing Descriptor Blocks:
local binding: label: 28 0
* 10.0.0.6, from 10.0.0.6, 01:28:04 ago, via Serial1/2 3
remote binding: lsr: 10.0.1.4:0, label: 30
Route metric is 2809856, traffic share count is 1
6 10.0.0.2, from 10.0.0.2, 01:28:04 ago, via Serial1/1 3
Route metric is 2809856, traffic share count is 1
P1#show mpls ldp neighbor s1/2 4 P1#show mpls ldp neighbor s1/1 4
Peer LDP Ident: 10.0.1.3:0; Local LDP Ident 10.0.1.1:0 Peer LDP Ident: 10.0.1.2:0; Local LDP Ident 10.0.1.1:0
TCP connection: 10.0.1.3.25787
5 - 10.0.1.1.646 TCP connection: 10.0.1.2.56892
5 - 10.0.1.1.646
State: Oper; Msgs sent/rcvd: 121/145; Downstream State: Oper; Msgs sent/rcvd: 180/205; Downstream
PEERS LDP
LDP discovery sources: LDP discovery sources:
Serial1/2, Src IP addr: 10.0.0.6 Serial1/1, Src IP addr: 10.0.0.2
Addresses bound to peer LDP Ident: Addresses bound to peer LDP Ident:
10.0.0.25 10.0.1.3 10.0.0.10 10.0.0.6 10.0.0.21 10.0.0.13 10.0.1.2 10.0.0.2 10.0.0.9 10.0.0.17
LFIB
P1#show mpls forwarding-table 10.0.1.6 32
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
0 28 24 10.0.1.6/32 0 Se1/1 point2point
7
24 10.0.1.6/32 0 Se1/2 point2point
1.- En la LIB se encuentran todos los bindings (REMOTOS Y LOCALES). Esta tabla LIB
permite identificar el rótulo loca (28), pero existen rótulos remotos procedentes de los 3 LSRs
vecinos (10.0.1.2:0, 10.0.1.3:0 y 10.0.1.4:0).
2.- Para identificar cuál es el rótulo y la interface por la que debe enviar el tráfico, inspecciona
la RIB, donde existen dos rutas de igual costo (métrica 2809856) conocidas mediante EIGRP.
3.- Obtiene las interfaces
4.- Consulta la tabla de vecinos (peers) LDP
5.- Obtiene el ID del peer LDP y verifica que entre las direcciones que maneja cada LSR se
encuentran 10.0.0.2 y 10.0.0.6 que figuran en la tabla de enrutamiento RIB.
6.- Determina cuales son los rótulos (24 en ambos casos) con los que debe enviar el tráfico
hacia 10.0.1.2:0 y 10.0.1.3:0.
7.- Precisamente, esos son los datos que vuelca en la LFIB (Label Forwarding Information
Base ) y que utiliza para rotular el tráfico hacia 10.0.1.6, en este caso por ambos caminos.
consulteach 31
DISTRIBUCIÓN DE LABELS EN MODO FRAME
Tablas LDP: Mapeos sin split horizon

L0: L0:
10.0.1.2/32 10.0.1.3/32
S1/2 (.9)
S1/1 (.10)
P2 P3
10.0.0.8
/30
P2#show interfaces loopback 0

Loopback0 is up, line protocol is up
lib entry: 10.0.1.2/32, rev 26
Internet address is 10.0.1.2/32
local binding: label: 23
remote binding: lsr: 10.0.1.2:0, label: imp-null
lib entry: 10.0.1.2/32, rev 2
local binding: label: imp-null
Nótese que LDP asigna rótulos locales a todos los prefijos IGP, y anuncia los mapeos a todos
su pares LDP. No existe concepto de split horizon: un par LDP asigna su propio rótulo local a
un prefijo y lo anuncia nuevamente hacia el otro par LDP, aún cuando el otro LDP sea el
dueño del prefijo por ser una red directamente conectada, o que el otro par LDP sea el LSR
downstream.
El LSR P2, dueño del prefijo 10.0.1.2/32 por ser el prefijo de la interface loopback 0, anuncia
el mapeo de ese prefijo asociado al rótulo implicit-Null, a su vecino LDP junin. Aún así, rojas
recibe el mapeo remoto del prefijo 10.0.1.2/32 del LSR P3.
consulteach 32
LDP: Sesiones dirigidas

PE3#show mpls ldp neighbor 10.0.1.1 P1(config)#do show mpls ldp neighbor 10.0.1.6
Peer LDP Ident: 10.0.1.1:0; Local LDP Ident 10.0.1.6:0 Peer LDP Ident: 10.0.1.6:0; Local LDP Ident 10.0.1.1:0
TCP connection: 10.0.1.1.646 - 10.0.1.6.64053 TCP connection: 10.0.1.6.64053 - 10.0.1.1.646
State: Oper; Msgs sent/rcvd: 22/23; Downstream State: Oper; Msgs sent/rcvd: 30/30; Downstream
LDP discovery sources: LDP discovery sources:
Targeted Hello 10.0.1.6 -> 10.0.1.1, passive Targeted Hello 10.0.1.1 -> 10.0.1.6, active
Addresses bound to peer LDP Ident: Addresses bound to peer LDP Ident:
10.0.0.29 10.0.1.1 10.0.0.1 10.0.0.5 10.1.4.254 10.0.0.26 10.0.1.6 10.0.0.18
Normalmente, las sesiones LDP son establecidas entre LSRs directamente conectados, y en
una red cuyas rutas IGP necesitan estar rotuladas, ello es suficiente porque el label switching
de paquetes se realiza salto a salto. Y si los mapeos de rótulos son anunciados salto a salto
para las rutas IGP, los LSPs se establecen.
A veces, puede requerirse una sesión dirigida o targeted, es decir entre LSR que no están
directamente conectados (para redes AToM, y túneles TE).
Para vecinos LDP no directamente conectados, la sesión dirigida debe configurarse
manualmente en ambos routers.
Un vecino LDP remoto puede mejorar la convergencia de los rótulos en un escenario de
enlaces flappeando, comparado con el que se tendría los pares directamente conectados.
Los routers azul y rauch no están conectados directamente, pero se requiere una sesión LDP
entre ellos. Para eso pueden configurarse ambos routers como vecinos remotos, o también
podría configurarse el vecino remoto en uno solo de los routers y en el otro configurar la
aceptación de la sesión remota desde routers LDP específicos.
consulteach 33
LDP: Autenticación

L0: L0:
10.0.1.2/32 10.0.1.3/32
S1/2 (.9)
S1/1 (.10)
P2 P3
10.0.0.8
/30
Las sesiones LDP son sesiones TCP, y pueden ser atacadas inyectando segmentos
fraudulentos.
Para proteger las sesiones puede utilizarse autenticación Message Digest 5 (MD5). MD5
agrega un digesto a los segmentos.
La password debe ser común en ambos pares LDP.
Se muestran los mensajes de error en caso de que sólo el LSR rojas hubiese sido
configurado con autenticación MD5. Y también el mensaje de error que se recibiría si las
passwords ingresadas no fueran concordantes.
Show mpls interfaces

Show mpls ldp parameters
Show mpls ldp neighbor
Show mpls ldp bridging !LIB
Show mpls forwarding-table !LFIB
consulteach 34
LDP: Protección

Un problema común es cuando los enlaces de una red flapean (flapping links). Esto impacta
muy fuerte en la convergencia de la red. Las adyacencias del IGP y las sesiones LDP se
establecen sobre el enlace, y se pierden si el enlace se cae, aún cuando sólo es por un
período breve, porque el restablecimiento toma tiempo.
Se pueden proteger las sesiones LDP con una sesión remota (targeted), ya que si el enlace
se cae, la sesión se mantiene mientras se establece a través del enlace alternativo.
La sesión LDP no requiere un restablecimiento completo, y mejora el tiempo de convergencia.

El comando global para la protección es:
mpls ldp session protection [vrf vpn-name] [for acl] [duration segundos]
La ACL permite especificar los pares LDP a proteger (LDP Router ID de los vecinos).
La duración indica el tiempo que puede estar establecida esta sesión de protección (por
defecto es infinito). Debe configurarse en ambos LSRs (si no es posible se habilita en uno de
ellos, y en el otro se configura el comando “mpls ldp discovery targeted-hello accept”).
consulteach 35
REDES VPN
Esquema y terminología básica
TECNOLOGÍA MPLS VPN

MPLS VPN, o MPLS Virtual Private Networks, es la implementación más difundida de MPLS.
Aún cuando la mayoría de los SP la han implementado, en reemplazo de los servicios Frame
Relay y ATM (densamente utilizados mundialmente), las grandes empresas perciben esta
tecnología con mucho interés y como el próximo paso en sus diseños de networking.
MPLS VPN puede proveer escalabilidad y dividir la red en unidades separadas, si fuera
necesario, como para proveer redes aisladas a diferentes áreas y departamentos.
Muchos SP que han estado corriendo MPLS VPN por años, también interconectan sus redes
para aumentar la escalabilidad y facilidad de operación y provisionamiento para sus clientes
(Inter-Autonomous MPLS VPN y Carrier’s Carrier - CsC).
La seguridad de las MPLS VPN (sin crypto) es equivamente a FR/ATM.
Un PE es un router de borde del proveedor (Provider Edge), el cual posee conexión directa
con el router CE (Customer Edge) a nivel de capa 3, por lo tanto deben compartir un
protocolo de enrutamiento (o enrutamiento estático).
El router P (Provider) es interno a la red del proveedor, sin conexión directa con los routers
de los clientes.
En la implementación MPLS VPN, los routers P y PE deben correr MPLS (deben ser
capaces de distribuir rótulos y enviar paquetes rotulados.
El router C es un router de la red interna del cliente. Los routers C y CE no requieren MPLS.
Como los clientes pueden poseer el esquema de direccionamiento IP que prefieran, puede
ocurrir que dos o más clientes utilicen esquemas similares (overlapping IP addressing).
Los paquetes IP de los clientes son rotulados al ingresar a la red MPLS por los routers PE, y
la información es transportada por los routers P en base a los rótulos (los routers P no tienen
conocimiento de las VPNs).
consulteach 36
ARQUITECTURA MPLS VPN
Modelo MPLS VPN
TECNOLOGÍA MPLS VPN

192.168.1.0/ VPNA
24 VPNA PE3 SITIO 2
SITIO 1 MPLS
SERVICE VPN VRF
PROVIDER
CE CE
PE1
VRF
P1
VPNB VRF
SITIO 1 PE2
VPNB
SITIO 2
VRF
CE
Tabla enrutamiento CE
192.168.1.0/ VPN A VRF para VPN A
24
Tabla enrutamiento
VPN B VRF para VPN B
Tabla enrutamiento
Global Global
MPLS VPN requiere disponer de los siguientes bloques funcionales en los routers PE:
• VRF (Virtual Routing & Forwarding)
• RD (Route Distinguisher)
• RT (Route Targets)
• MP-BGP (Propagación de rutas)
• Forwarding de paquetes rotulados
VRF es una instancia de routing y forwarding VPN. Un router PE posee una instancia
VRF por cada VPN conectada.
VRF mantiene aislado el enrutamiento para cada cliente VPN del router PE. La interface
del router PE hacia el router CE sólo puede pertenecer a una VRF.
Entonces, existe una tabla de rutas VRF por cada VPN (y una VRF CEF asociada).
La tabla de enrutamiento VPNA posee prefijos que son incorporados a través de los
protocolos de enrutamiento dinámicos y estáticos, igual que en la tabla global (con los
mismos conceptos de métrica, distancia, next hop, etc.).
Las instancias VRF están asociadas a interfaces, y sólo los paquetes que entran al PE a
través de estas interfaces son enviados de acuerdo con la tabla VRF respectiva.
Los prefijos VPN son propagados a través de la red MPLS VPN mediante el protocolo
BGP (MPBGP), el cual requiere que los prefijos IPv4 sean únicos para toda la red.
consulteach 37
MECANISMOS MPLS VPN
Intranet MPLS VPN
IMPLEMENTACIÓN MPLS VPN

192.168.1.0/
24
192.168.1.0/
24
Si los clientes poseen direcciones IP similares, el enrutamiento podría fallar. Para resolver este
tema, se introdujo el concepto de RDs para que los prefijos fueran únicos.
Los prefijos de cada cliente reciben un identificador único (RD) para distinguirlo de cualquier
ocurrencia similar de otro cliente.
El prefijo resultante (prefijo IP + RD) se denomina prefijo vpnv4. MP-BGP transporta estos
prefijos vpnv4 entre los routers PE.
Cada instancia VRF en el router PE debe poseer un RD asignado.
Este valor de 64 bits (8 bytes) puede asumir dos posibles formatos:
• ASN:nn
• Dirección_IP:nn
El formato más común es ASN:nn, donde ASN es el número de Sistema Autónomo (asignado por
IANA al SP), y nn es un número arbitrario pero único que el SP asigna a la VRF. De todas
maneras, el RD puede ser libremente asignado por el SP.
Si se toma el prefijo IPv4 192.168.1.0/24 y el RD 1:1, el prefijo vpnv4 resultante es:
1:1:192.168.1.0/24
consulteach 38
MECANISMOS MPLS VPN
Intranet MPLS VPN - RD

Intranet MPLS VPN: RD
[8 bytes] [4 bytes]
1:1 192.168.1.0
RD IPv4
VPNv4
RD es un identificador de 64 bits (8 bytes), con dos posibles formatos:

1. ASN:nn
2. Dirección_IP:nn
Si los clientes poseen direcciones IP similares, el enrutamiento podría fallar. Para resolver este
tema, se introdujo el concepto de RDs para que los prefijos fueran únicos.
Los prefijos de cada cliente reciben un identificador único (RD) para distinguirlo de cualquier
ocurrencia similar de otro cliente.
El prefijo resultante (prefijo IP + RD) se denomina prefijo vpnv4. MP-BGP transporta estos
prefijos vpnv4 entre los routers PE.
Cada instancia VRF en el router PE debe poseer un RD asignado.
Este valor de 64 bits (8 bytes) puede asumir dos posibles formatos:
• ASN:nn
• Dirección_IP:nn
El formato más común es ASN:nn, donde ASN es el número de Sistema Autónomo (asignado por
IANA al SP), y nn es un número arbitrario pero único que el SP asigna a la VRF. De todas
maneras, el RD puede ser libremente asignado por el SP.
Si se toma el prefijo IPv4 192.168.1.0/24 y el RD 1:1, el prefijo vpnv4 resultante es:
1:1:192.168.1.0/24
RD= mantiene los prefijos de los clientes ÚNICOS.
consulteach 39
TABLAS VRF
Extranet MPLS VPN

VPNA
VPNA PE3 SITIO 2
SITIO 1 MPLS
SERVICE VPN VRF
PROVIDER
CE CE
PE1
VRF
S4/1: 10.10.4.1 P1
VPNB S5/1: 10.10.5.1
SITIO 1 PE2
VPNB
VRF
SITIO 2
VRF
CE
CE
Un RT (Route Target) es una comunidad extendida de BGP que indica que rutas vpnv4
deben ser importadas por MP-BGP en la tabla VRF y exportadas desde la tabla por
BGP.
RT controla las conexiones entre las VPNs (intranets), formando extranets.
Cuando se requiere configurar un VRF con varios sitios que pertenecen a la misma
VPN, sin necesidad de comunicación con sitios que pertenecen a otras VPN, se
configura sólo un RT para ser importado y exportado en todos los PE conectados a
sitios de esa VRF (Intranet).
En el caso de una extranet (permitir que sitios de una VPN se conecten a sitios de otra
VPN), entonces deben incluirse otros RT.
Obviamente, los sitios 1 y 2 de la VRF VPNA (RT 1:1) deben poder comunicarse (igual
que los sitios 1 y 2 de la VRF VPNB (RT 1:2).
Ahora supongamos que el sitio 1 de VPNA deba comunicarse sólo con el sitio 1 de
VPNB. Esto es posible configurando correctamente los RT.
El RT 100:1 es importado y exportado por el sitio 1 del VRF VPNA y el sitio 1 del VRF
VPNB por el PE1 (aunque también podrían haber sucedido entre PE, si los sitios
hubiesen estado conectados a PE diferentes).
consulteach 40
SERVICIO ROUTER CE GESTIONADO
Router Multi-VRF CE
MPLS VPNS AVANZADAS

SERVICE PROVIDER
PE
(sub)Interfaces VRF
Multi-VRF CE router
Multi-VRF CE
VR
FO
ro
VR
F
Az
ul
CE CE
RH CE CE MARK
VENTAS ING
La función Multi-VRF CE (ó VRF-Lite) permite extender la funcionalidad de la VPN al

router CE.
Por ejemplo, una empresa con un sitio central muy grande y varios otros sitios más
pequeños conectados por una red MPLS VPN. En el sitio central existen varios
departamentos separados que requieren conexión a sus respectivas áreas en los sitios
remotos.
Es posible segmentar los departamentos mediantes VLANs y mapearlas sobre una
subinterface VRF en el router PE, sólo que en lugar de utilizar un switch de capa 2 o un
router CE por departamento, se extiende la separación de VRFs en el router CE (sin
que tenga que soportar las otras funciones de MPLS).
El router Multi-VRF CE posee una interface VRF hacia cada router CE conectado, y
hacia el PE.
Pueden utilizarse interfaces físicas (muy caro), enlaces Fast/GigaEthernet, ó enlaces
seriales canalizadas, utilizando una subinterface por cda VRF.
Es necesario configurar tanto las interfaces VRF cómo los protocolos de enrutamiento
VRF en el router Multi-VRF CE.
consulteach 41
OVERLAPPING MPLS-VPN
Propagación de rutas – Plano de control
MPLS VPNS AVANZADAS

El PE recibe las rutas IPv4 del CE a través de algún protocolo IGP (RIP, OSPF, EIGRP,
estático) ó eBGP, y las coloca en tablas de enrutamiento VRF, separadas para cada
cliente.
Ahora, estos prefijos deben ser propagados a través de la red hasta los otros PE. Para
ello se utiliza el protocolo de enrutamiento MP-BGP, a partir de su transformación,
mediante el agregado del prefijo RD en prefijos vpnv4.
BGP distribuye los prefijos vpnv4 a todos los PE de la red MPLS VPN. En cada PE, se
extrae el RD y se colocan los prefijos IPv4 en las tablas de enrutamiento VRF, sólo si el
RT permite dicha importación a la VRF.
Finalmente, estas rutas IPv4 son anunciadas al router CE a través del protocolo de
enrutamiento que estén corriendo el PE y el CE.
consulteach 42
Propagación de rutas – Plano de control - Detallado
MPLS VPNS AVANZADAS

Update Ruta
192.168.1.0/24
LDP LDP
Update Ruta
192.168.1.0/24
Como la red MPLS VPN del SP está corriendo BGP en un AS, el protocolo que corre
entre los routers PE es iBGP.
La propagación de rutas entre eBGP (entre los routers PE y CE) hacia MP-iBGP en la
red MPLS, y viceversa es automática, sin necesidad de configuración adicional. Sin
embargo, la redistribución de MP-iBGP hacia el protocolo IGP entre el PE y CE no es
automática y debe realizarse manualmente.
Configuración OSPF en la VRF (entre PE-CE)

Configuración BGP/MPLS VPN (entre PEs)
Start OSPF en la VRF
Configuración:
Router(config)# router OSPF 5 VRF VPNA
Router(config)# virtual-router :VPNA ! VRF VPNA
Router(config)# router OSPF 5
Router(config)#domain-id 45
Router(config)# domain-tag 1200
Router(config)# redistribute bgp
Router(config)#router bgp 100
Router(config)#address-family ipv4 unicast vrf VPNA
Router(config)#redistribute OSPF
consulteach 43
Envío de paquetes – Plano de control
MPLS VPNS AVANZADAS

Los paquetes no pueden ser enviados como IP entre los sitios porque los routers P no
poseen la información VRF de cada sitio.
MPLS rotula los paquetes y entonces los routers P trabajan sólo en función de los
rótulos.
Lo más común es configurar LDP entre los routers P y PE.
De esta manera, los paquetes son enviados con un rótulo (Label IGP) desde el PE de
ingreso hasta el PE de egreso, y un router P jamás tiene que efectuar un búsqueda de
la dirección IP.
Ahora bien, como el router PE de egreso debe conocer a que VRF pertenece cada
paquete, el PE de ingreso incorpora un segundo rótulo en el stack de rótulos MPLS.
Este rótulo identifica el VRF.
De manera que todos los paquetes son enviados con dos rótulos: el rótulo IGP al tope, y
el rótulo VPN en el fondo (bottom).
La información del rótulo VPN que el PE de ingreso debe colocar en cada paquete es
recibida en el prefijo vpnv4, a través de MP-BGP, por lo que este rótulo suele
denominarse Label BGP).
consulteach 44
CENTRAL SERVICES
Funciones QoS
MPLS VPNS AVANZADAS

Funciones QoS Funciones de soporte IOS
Clasificación del tráfico Listas de Acceso ACL
Bits IP de precedencia
Marcado del tráfico IP DSCP (codificación DiffServ)
MPLS EXP (Experimental)
LLQ (Low-Latency Queueing)
Manejo de congestión
CBWFQ (Class-Based Weighted Fair Queueing)
Prevención de congestión WRED (Weighted Random Early Detection)
Acondicionamiento del tráfico Shaping y Policing
Quality of service (QoS) se ha vuelto muy popular durante los últimos pocos años.
Pocas, o quizás ninguna red, poseen recursos ilimitados (como el ancho de banda), y
por ello la congestión siempre es un riesgo en la red.
Además la convergencia de redes, plataformas, servicios y aplicaciones, requiere algún
método para calificar y brindar tratamientos adecuados a los diferentes flujos de tráfico,
en función de su criticidad, importancia, urgencia, seguridad, etc.
• QoS es necesario para priorizar tráficos.
• MPLS no define una nueva arquitectura QoS.
• Brinda soporte para las arquitecturas existentes.
• Aplica el mismo acondicionamiento de tráfico y comportamiento hop-per-hop.
• EXP = TOS
Sólo la clasificación cambia en el core MPLS
IP QoS = son aplicables queueing, policing, shaping, WRED, MDDR, etc
IETF ha designado dos maneras de implementar QoS en una red IP:
■ Integrated Services (IntServ): Utiliza RSVP para señalizar a la red las necesidades
QoS de los flujos de tráfico. Como los router deben conservar la información de estado
de los flujos, presenta serios problemas de escalabilidad, y su uso no es muy popular.
■ Differentiated Services (DiffServ): No se requiere protocolo de señalización, sino que
utiliza los bits DiffServ en el header IP para calificar al paquete con un QoS
determinado. Los routers prestan atención a estos bits para marcar, encolar, conformar
y fijar la precedencia de descarte.
Un buen ejemplo del uso de QoS es para el tráfico de VoIP. Para ello se prioriza el
tráfico VoIP y se implementan los mecanismos que permiten manejar las colas y la
política de descarte en caso de congestión.
consulteach 45
CENTRAL SERVICES
DiffServ en datagramas IP
MPLS VPNS AVANZADAS

Los bits de precedencia del datagrama IP son utilizados en QoS, pero sólo permiten 8
niveles de servicio diferentes.
IETF redefinió este campo, asignando 6 bits para DiffServ.
Se han definido dos tipos de clases de forwarding en el modelo DiffServ: EF (Expedited
Forwarding) y AF (Assured Forwarding).
EF significa baja pérdida, baja latencia, bajo jitter, bw asegurado, servicio end-to-end
sobre un dominio DiffServ.
AF define diferentes servicios de aseguramiento del forwarding a través de un dominio
DiffServ, con 4 clases AF, que se escriben: AFij. (donde i = 1 a 4, para la clase; j=1 a 3,
para la precedencia de descarte).
Los primeros 3 bits del campo DSCP definen la clase (4 clases para el tráfico), los dos
siguientes la precedencia de descarte (cuanto más alto mas probable el descarte), y el
último ha quedado reservado.
AF23, por ejemplo, indica la clase 2 y precedencia de descarte 3.
El valor recomendado del campo DiffServ para usar EF es 101110 (decimal 46). La
clase por defecto es 0 ó 000000 en binario.
consulteach 46
CENTRAL SERVICES
DiffServ en MPLS
MPLS VPNS AVANZADAS

Por defecto, en Cisco IOS, los bits de precedencia, o los primeros 3 bits
de DSCP se copian sobre los bits EXP de todos los rótulos impuestos por el LSR de ingreso.
EXP=3 EXP=3
Por defecto, en Cisco IOS, los bits EXP del rótulo top incoming son EXP=4 EXP=4
copiados sobre el rótulo swappeado outgoing, y sobre todo otro rótulo agregado (pushed).
DSCP=5 DSCP=5
Por defecto, en Cisco IOS, los bits EXP de un rótulo top incoming no
son copiados sobre el nuevo rótulo top cuando ese rótulo incoming es extraido (popped). Interface Interface
de ingreso de egreso
Por defecto, en Cisco IOS, los bits EXP de un rótulo top incoming no
son copiados sobre los bits de precedencia o DSCP cuando la pila de rótulos es removida,
exponiendo el header IP.
LSR
Cuando se cambian los valores de los bits EXP mediante

configuración, el valor de los bits EXP en otros rótulos diferentes del top, swapped, o
impuestos, así como los bits de precedencia o DSCP del header IP permanecen inalterados.
Existen sólo 3 bits EXP en el rótulo MPLS con el objetivo de QoS. En principio podrían
utilizarse de la misma manera que se usa el campo precedencia del datagrama IP.
En este caso el LSP se denomina E-LSP (indicando que el LSR usará los bits EXP para
forwardear los paquetes y decidir la precedencia de descarte).
Pero, en MPLS existe otra opción de implementar QoS en los paquetes rotulados, que
es utilizar el rótulo top para aplicar QoS para ese paquete. Ello determinaría asignar un
rótulo para cada clase y para cada flujo de tráfico entre dos puntos finales del LSP.
En consecuencia, el protocolo de señalización debe ser capaz de señalizar un rótulo
diferente para el mismo LSP o prefijo, con lo que tal LSP se denomina L-LSP (indicando
que el rótulo implícitamente retiene parte de la información QoS.
En el L-LSP, los bits EXP retienen la precedencia de descarte (la clase está en el valor
del rótulo), mientras que en el E-LSP los bits EXP contienen tanto la clase como la
precedencia de descarte.
Cisco IOS implementa sólo E-LSP.
Cuando un LSR envía un paquete rotulado, sólo necesita consultar el rótulo top en su
LFIB para determinar como forwardearlo.
Similarmente, con QoS, el LSR sólo necesita mirar los bits EXP del rótulo top para
determinar como tratarlo.
consulteach 47
CENTRAL SERVICES
Tratamiento de los bits EXP
MPLS VPNS AVANZADAS

Recordando que QoS implica el marcado del tráfico, manejo y prevención de la
congestión y acondicionamiento del tráfico, es posible utilizar LLQ, CBWFQ, WRED,
policing y shaping para implementarlo en los paquetes IP.
También es posible usar las mismas funciones para implementar QoS basado en los
bits EXP de los paquetes rotulados.
Por ejemplo, WRED ha sido modificado para considerar los bits EXP para determinar la
precedencia de descarte de los paquetes rotulados que son encolados. El método
preferido para configurar QoS en MPLS es por medio de MQC (Modular Quality of
Service Command Line Interface). MQC provee una manera sencilla de configurar
diferentes bloques constructivos QoS en el router.
Las figuras 1 y 2 muestran la reflexión TOS.
Por defecto, la precedencia IP (o los tres primeros bits del campo DSCP) es copiada en
todos los rótulos impuestos por el LSR de ingreso. Regla 1.
La figura 3 muestra como los bits EXP del rótulo top del paquete incoming son copiados
sobre los rótulos swappeados y los nuevos rótulos (pushed). Regla 2
Las figuras 4 y 5, también son ejemplos de la regla 2, pero ahora muestran que los bits
EXP de los rótulos que se encuentran debajo del top en la interface de ingreso no son
modificados. Regla 5.
La figura 6 muestra un ejemplo de la Regla 3
La figura 7 es un ejemplo de la Regla 4
consulteach 48
COMBINACIÓN ACCESO INTERNET Y MPLS VPN
Acceso a Internet mediante interfaces separadas
ACCESO A INTERNET
PE1#
ip vrf VPNA
rd 1:1
route-target both 1:1
! CE#
interface Serial 0 interface Tunnel1
ip vrf forwarding VPNA ip address 10.10.20.2 /24
ip address 10.10.2.2 /24 tunnel source 10.10.2.1
! tunnel destination 10.10.2.2
interface Tunnel1 !
ip address 10.10.20.1 /24 ip route 0.0.0.0 0.0.0.0 Tunnel1
tunnel source 10.10.2.2
tunnel destination 10.10.2.1
tunnel vrf VPNA
!
ip route 171.68.0.0 /16 Tunnel1
Una manera sencilla de proveer acceso a Internet a los routers CE, es colocar una
segunda interface entre el PE y el CE en el espacio de direccionamiento global.
Entonces, el encargado de realizar el enrutamiento (tráfico VPN hacia la interface VRF y
tráfico Internet hacia la interface global) es el CE.
La desventaja obvia es la necesidad de disponer de una segunda interface tanto en el
PE como en el CE, aunque bien pueden utilizarse sub-interfaces (si se tiene
encapsulación Frame Relay u 802.1q).
Si la encapsulación de capa 2 no permite sub-interfaces, también podría crearse un
túnel GRE en el espacio de enrutamiento global a través de la interface VRF.
La interface túnel en el PE requiere el comando “tunnel vrf VPNA” porque el punto final
del túnel no se encuentra en el espacio de enrutamiento global, sino en el VRF. Nótese
también, que el túnel no posee la sentencia “ip vrf forwarding VPNA”, y por lo tanto
pertenece al contexto de enrutamiento global.
Una ruta por defecto en el router CE apunta a la interface tunel para el acceso a
Internet. De manera que todo el tráfico que no posee una ruta específica se envía por el
túnel hacia el contexto de enrutamiento global del router PE.
Mientras que todo tráfico que posea entradas de rutas específicas en el router CE es
enviado por la interface que pertenece al contexto de la VRF (VPNA).
El tráfico proveniente de Internet hacia la red del cliente se envía utilizando una ruta
estática en el router PE que apunta a la interface túnel.
El SP envía el tráfico de Internet en el backbone, desde y hacia el ASBR utilizando
BGP.
consulteach 49
Acceso a Internet – Ruta en la VRF - Salida
ACCESO A INTERNET
PE1#
ip vrf VPNA
rd 1:1
!
interface serial 0
ip address 192.168.1.1 /24
ip vrf forwarding VPNA
!
router bgp 100
redistribution static
!
ip route vrf VPNA 0.0.0.0 /0 PE2 global
ip route 171.68.0.0 /16 serial 0
Es posible proveer acceso Internet a los clientes de la VPN enviando su tráfico hacia el
gateway Internet (ASBR) del SP. El ASBR es conocido por todos los routers PE porque
se encuentra en el espacio de enrutamiento global. El ASBR corre eBGP. Además, los
routers PE pueden estar corriendo iBGP con el ASBR.
Para poder proveer acceso Internet a la VRF, este tráfico debe ser enviado consultando
la tabla de enrutamiento global. Para ello, se crea una ruta estática en la tabla VRF del
PE, apuntando al ASBR que está en el contexto global (para ello es necesario ingresar
la palabra clave “global”).
Debe configurarse una ruta por defecto hacia el ASBR en el VRF en cada PE que
conecte sitios que requieran acceso a Internet.
consulteach 50
Acceso a Internet – Ruta en la VRF - Entrada
ACCESO A INTERNET
PE1#
ip vrf VPNA
rd 1:1
!
interface serial 0
ip address 192.168.1.1 /24
ip vrf forwarding VPNA
!
router bgp 100
redistribution static
!
ip route vrf VPNA 0.0.0.0 /0 PE2 global
ip route 171.68.0.0 /16 serial 0
Para el tráfico de regreso hacia la VRF, se configura una ruta estática en el PE,
apuntando hacia el CE. Esto se realiza en la tabla de enrutamiento global, y para
asegurar que el ASBR conozca esta ruta, debe redistribuirse a través de BGP (o el IGP
que se esté utilizando).
Este tráfico que fluye desde y hacia Internet, no es VPN-VPN, sino que es enrutado en
el contexto de enrutamiento global, y sólo posee un rótulo (a diferencia de Label Stack
de 2 que porta el tráfico VPN-VPN).
consulteach 51
Acceso a Internet – Sitio VRF
ACCESO A INTERNET
3
En lugar de que el tráfico de cada sitio VPN sea enviado directamente al ASBR, es
posible enviar todo el tráfico de Internet desde los sitios VRF a los routers CE de un sitio
VRF central en una VPN.
La ventaja es que las funciones de seguridad (servicios firewall, etc) y otros servicios
(NAT, etc) son implementados una sola vez en forma centralizada en este sitio VRF.
Entonces, el tráfico Internet entre los diferentes sitios VRF y el sitio central VRF es
enviado de la manera regular entre interfaces VRF de la red MPLS VPN.
También es el escenario preferido para las redes VPN Hub&Spoke.
En el sitio central VRF puede instalarse un firewall para verificar todo el tráfico de
Internet.
consulteach 52
Acceso a Internet – Servicio NAT VRF
ACCESO A INTERNET
Tabla NAT PE ASBR
VRF IP Source Global IP VRF Table-Id
10.1.1.1 24.1.1.1 VPNA
10.1.1.1 25.1.1.1 VPNB
ip nat pool POOL-VPNA 24.1.1.0 254.1.1.254 prefix-length 24

ip nat pool POOL-VPNB 25.1.1.0 254.1.1.254 prefix-length 24
!
ip nat inside source list NAT-VPNA pool POOL-VPNA vrf VPNA
ip nat inside source list NAT-VPNB pool POOL-VPNB vrf VPNB
!
ip access-list standard NAT-VPNA
permit 10.1.1.0 0.0.0.255
ip access-list standard NAT-VPNB
permit 10.1.1.0 0.0.0.255
!
ip route vrf VPNA 0.0.0.0 0.0.0.0 2.2.2.2 global
ip route vrf VPNB 0.0.0.0 0.0.0.0 2.2.2.2 global
Los clientes VPN podrían estar utilizando direcciones IP superpuestas (overlapping),

tales como 10.0.0.0/8).
Estos clientes deben “natear” (aplicar función NAT) al tráfico antes de acceder a
servicios “extranet”, “Internet”, o servicios compartidos (tales como VoIP, gestión,
contenido hosteado, etc).
Esa funcionalidad puede ser realizada en sus propios equipos, pero también el router
PE (tanto el PE local como el remoto) está en condiciones de realizar la función de NAT,
eliminando la necesidad de dispositivos específicos.
El PE posee la definición de la función de NAT, así como el pool de direcciones
Globales que debe utilizar para cada VRF, y las listas de acceso (ACL) que determinan
el rango de direcciones sobre las que se aplicará el NAT (es decir las direcciones a las
que se les permite salir a Internet).
ip nat pool POOL-VPNA 24.1.1.0 254.1.1.254 prefix-length 24
ip nat pool POOL-VPNB 25.1.1.0 254.1.1.254 prefix-length 24
!
ip nat inside source list NAT-VPNA pool POOL-VPNA vrf VPNA
ip nat inside source list NAT-VPNB pool POOL-VPNB vrf VPNB
!
ip access-list standard NAT-VPNA
permit 10.1.1.0 0.0.0.255
ip access-list standard NAT-VPNB
permit 10.1.1.0 0.0.0.255
!
ip route vrf VPNA 0.0.0.0 0.0.0.0 2.2.2.2 global
ip route vrf VPNB 0.0.0.0 0.0.0.0 2.2.2.2 global
consulteach 53
COMPONENTES MPLS-TE
Escenario de Ingeniería de Tráfico
INGENIERÍA DE TRÁFICO MPLS

LSR Upstream LSR Downstream
LSR Mid-point
LSP=R6-R1-R2-R5
LSR Head End
LSR Mid-point
LSR Tail End
Ingeniería de Tráfico (Traffic engineering - TE), es la habilidad de dirigir el tráfico de una

red (tradicionalmente FR o ATM) para conseguir que el transporte de información se
realice con el máximo aprovechamiento de los recursos disponibles.
En las redes FR y ATM, esta tarea aplicaba a la planificación y dimensionamiento del
tráfico para mapearlos sobre los circuitos virtuales.
En MPLS, TE permite aplicar mecanismos apropiados para:
•Manejar la congestión
•Utilizar mejor el BW disponible
•Aumentar la disponibilidad
•Brindar nuevos servicios
•Realizar el Capacity Planning
Actualmente, la infraestructura de las redes ya no es FR o ATM, sino IP ó IP sobre MPLS.
Aún cuando podría no ser posible una solución TE para las redes IP puras, si existe para
las redes IP/MPLS. El enrutamiento en las redes IP esta basado en el principio del menor
costo (las métricas varían con cada protocolo), gobernado por la necesidad de transferir
tráfico lo más rápido posible. Como resultado de este comportamiento, algunos enlaces
pueden sufrir congestión, mientras que otros se encuentran sub-utilizados. TE permite
ecualizar estas situaciones. Si todos los enlaces de la figura poseen el mismo costo, todo
el tráfico entre R1 y R5 utilizaría el trayecto e menor costo R1-R2-R5, y R1-R3-R4-R5 no
cursaría tráfico.
En una red real, pueden existir varios flujos de tráfico, haciendo variar la carga de los
enlaces. Podría lograrse mejor distribución variando los costos de los enlaces (haciendo
que el costo R1-R2-R5 = R1-R3-R4-R5), y permitiendo el balanceo de cargas, pero nunca
se llegaría a una distribución perfecta, porque también existe tráfico entre todos los otros
nodos.
consulteach 54
COMPONENTES MPLS-TE
Características de Ingeniería de Tráfico

■ MPLS TE difunde eficientemente el tráfico en la red, evitando la
sobre y sub utilización de los enlaces.
■ MPLS TE considera el ancho de banda configurado (estático) de
los enlaces.
■ MPLS TE considera los atributos de los enlaces (delay, jitter,
etc).
■ MPLS TE se adapta automáticamente a los cambios en el ancho

de anda y atributos de los enlaces.
■ Se aplica enrutamiento basado en el origen.
■ Se aplica enrutamiento basado en el origen.
MPLS TE permite un esquema TE donde el router Head End puede calcular el trayecto
más eficiente hacia el router Tail End de ese LSP.
Para esto, el router Head End debe conocer la topología de la red, y el ancho de banda
disponible de los enlaces.
El hecho de que se utilice conmutación de rótulos y no IP permite la aplicación del
enrutamiento por origen en lugar del enrutamiento por destino, clásico de IP.
Entonces, es el LSR Head End de un LSP quién puede determinar el enrutamiento del
paquete rotulado, después de que todos los LSRs han acordado que rótulos utilizar para
cada LSP.
Es posible implementar MPLS TE en redes que posean LSRs, y un protocolo de
enrutamiento Link State, ya que el BW y otros atributos de los enlaces debe ser
conocidos por el LSR Head End del LSP. Con un protocolo de enrutamiento Link State,
cada router construye un mapa topológico de la red, con lo que puede determinar el
LSP apropiado (source-based routing). Este LSP se denomina túnel MPLS TE, el cual, a
diferencia de GRE es unidireccional y sólo está configurado en el LSR Head End del
LSP (no en el Tail End).
Pueden habilitarse los túneles MPLS TE en forma permanente o a la demanda.
Por ejemplo en una red MPLS VPN se crean túneles TE entre cada para de LSRs PE
para dirigir el tráfico, evitar congestión y brindar las características BW, delay y jitter
requeridas.
Y por otro lado puede habilitarse MPLS TE en la red, de manera que los túneles sean
creados conforme a la demanda
consulteach 55
OPERACIONES MPLS-TE
Atributos de los enlaces

• Bw máximo reservable
• Flags de atributos
• Métrica TE
•Grupos de riesgo compartido
•Sub-pool Bw max reservable
Bw máximo reservable: Es el máximo ancho de banda reservable en el pool global

(utilizado por todos los túneles TE regulares).
Flags de atributos: Son 32 bits sin significado previo, asociados a los enlaces para
identificar recursos del enlace, capacidades (p.e. encripción), políticas administrativas,
etc. Se usan para verificar si un túnel TE con requerimientos específicos de recursos
puede utilizar un determinado enlace.
Métrica TE: Se usa para personalizar el peso de la métrica TE (diferente de la métrica
del protocolo IGP utilizado).
Grupos de riesgo compartido: SRLG( Shared Risk Link Groups) es una característica
asignada por el administrador para indicar que los enlaces comparten un sistema,
canalización o cualquier otro recurso que los pone en un mismo nivel de riesgo ante
incidentes.
Sub-pool de ancho de banda máximo reservable: Es una fracción del pool BW principal,
utilizado por los túneles TE basados en DiffServ para obtener BW.
consulteach 56
OPERACIONES MPLS-TE
Atributos del túnel TE

•Destino (LSR Tail-end)
•BW requerido
•Afinidad (bits/máscara)
•Prioridades (setup&hold)
•Reoptimización
•Opciones del trayecto
LSR Mid-point
LSR Head End
LSR Mid-point
LSR Tail End
El destino del túnel TE es el ID del LSR MPLS-TE Tail End.

El BW es el que corresponda a los requerimientos impuestos a ese túnel.
Los bits de afinidad son los que corresponden a los Flags de Atributos de los enlaces.
Las prioridades de setup y Holding del túnel (entre 0 y 7) identifican su importancia
respecto de otros túneles (determina si pueden prevalecer sobre otros túneles durante
la fase de establecimiento y retención).
La reoptimización indica si se requiere un análisis y acción de re-enrutamiento del túnel
(ya sea periódico, por eventos o manual).
La opción de establecimiento del túnel puede ser dinámico (sólo se indica el LSR tail-
end) ó explícito (se indican todos los LSR por donde debe pasar).
consulteach 57
OPERACIONES MPLS-TE
Distribución de la información TE

•IGP Link State
•Extensiones
• IS-IS (RFC 3784) + TLV
• OSPF (RFC 2370) + LSA
LSR Mid-point
LSR Head End
LSR Mid-point
LSR Tail End
DISTRIBUCIÓN VIA
IGP LINK STATE
Las restricciones y los recursos (BW y atributos especificados por el operador)

configurados en los enlaces son difundidos por el protocolo link state (OSPF o IS-IS con
extensiones).
Al configurar un túnel TE en un LSR, éste se convierte en TE LSP (Head End del túnel
TE), y también debe indicarse el Tail End y las restricciones que apliquen (por ejemplo
el BW).
En el IOS Cisco, se construye una base de datos TE con la información enviada por el
protocolo link state. Es decir todos los enlaces habilitados para MPLS TE y sus
características o atributos.
consulteach 58
OPERACIONES MPLS-TE
Cálculo del túnel

• PCALC
Algoritmo SPF usado por
MPLS TE
•SPF Æ CSPF
LSR Mid-point
LSR Head End
LSR Mid-point
LSR Tail End
PCALC es el algoritmo SPF especial utilizado por MPLS TE.

SPF es utilizado normalmente por IS-IS y OSPF para calcular el trayecto más corto a un
destino. Sin embargo, para TE deben considerarse otros criterios (especialmente las
propiedades/restricciones de los enlaces). PCALC toma en cuenta estos aspectos, de
modo que el algoritmo SPF se convierte en CSPF (constrained SPF).
A partir de la información recibida por el IGP con extensiones, PCALC (path calculation
ó constrained SPF es el algoritmo SPF modificado para MPLS TE) calcula la mejor ruta
entre los LSR Head End y Tail End, satisfaciendo todas las restricciones.
En el Head End, PCALC toma los requerimientos BW y atributos del túnel TE
configurado y busca todos los posibles trayectos cuyos atributos de enlace los
satisfagan, seleccionando el más corto.
consulteach 59
OPERACIONES MPLS-TE
Señalización del túnel TE - PATH

• RSVP - TE
LSR Mid-point
th q P
Lab ath
Pa l Re el R
LSR Head End P b e e q
Lab ath La
el R
eq
LSR Mid-point
LSR Tail End
Todos los LSR Mid-point del LSP necesitan conocer los rótulos de entrada y salida del
LSP para ese túnel TE. Este conocimiento se adquiere a través de un protocolo de
señalización: RSVP-TE (RSVP con extensiones para TE que permita transportar
información de rótulos y otra específica de TE).
RSVP con extensiones (RFC 3209) es el protocolo de señalización para los túneles TE.
El objetivo es asegurar que el túnel TE cruce por las interfaces de los LSR adecuadas a
los enlaces con los requisitos necesarios y la propagación de los rótulos salto a salto
(hop by hop) que deben ser usados por el tráfico que ingrese a ese túnel.
RSVP utiliza los mensajes PATH y RESV para señalizar el trayecto. El LSR Head End
envía el mensaje PATH hacia el LSR Tail End, mientras que el mensaje RESV sigue
exactamente el camino opuesto.
CR-LDP (constrained based LDP) ha dejado de usarse a tal objeto.
RSVP señaliza el túnel TE sobre el LSP, permitiendo incorporar la información de los
rótulos en los LSR.
consulteach 60
OPERACIONES MPLS-TE
Señalización del túnel TE - RESV

• RSVP - TE
LSR Mid-point
v
es 5
R el 2
LSR Head End b
La • RSVP - TE
R
R Ex esv
pN
Lab esv ull
el 3
LSR Mid-point
1 LSR Tail End
RSVP no sólo señaliza el trayecto para el túnel TE, sino que también transporta el rótulo
MPLS.
Los mensajes PATH transportan el objeto LABEL REQUEST, el cual al ser recibido por
el LSR Tail End, le indica que asigne un rótulo para el LSP del túnel TE y lo anuncia
hacia el LSR upstream mediante un objeto LABEL en el mensaje RESV.
Además de los mensajes PATH y RESV, el protocolo RSVP contempla otros mensajes
utilizados primariamente para señalizar la ocurrencia de distintos eventos de error.
consulteach 61
OPERACIONES MPLS-TE
Establecimiento del túnel TE

• Tráfico X hacia R5 por el túnel
Rótulo IN Æ Rótulo OUT
TE Æ rótulo 89 (R1)
65 Æ NULL (R5)
LSR Mid-point
LSR Head End
LSR Mid-point
LSR Tail End

89 Æ 65 (R2)
Ahora el LSR Head End puede enviar tráfico sobre el LSP generado sobre el túnel TE,
habilitando el routing por origen.
Este túnel TE es unidireccional (igual que el LSP), y solamente está configurado en el
LSR Head End.
consulteach 62
CONFIGURACIÓN MPLS-TE
Utilización del túnel

■ Enrutamiento estático
Gobal: ip route 1.1.1.1 255.255.255.0 tunnel 1
■ Enrutamiento por políticas (policy-based)

Global: route-map “nombre” permit “acl”
Interface: ip policy route-map “nombre”
■ Anuncios de autorutas (autoroute)

Tunnel Interface: tunnel mpls traffic-eng autoroute announce
■ Envío por adyacencia (forwarding adjacency)

Tunnel Interface: tunnel mpls traffic-eng forwarding adjacency
■ Mapeo directo de tráfico AToM en el túnel TE

Pseudowire: preferred-path interface tunnel 1
■ Selección del túnel en base a una clase (Class-based tunnel Selection -

CBTS)
Tunnel Interface: tunnel mpls traffic-eng exp [lista de valores exp]
Después de crear y colocar operativo el túnel TE, es necesario encauzar el tráfico por el
mismo. Existen 6 maneras diferentes.
1) Ruta estática: configurar una ruta estática en el LSR Head End.
2) Policy-based routing (PBR): requiere configurar una política [route-map “nombre”
permit “acl”] en la interface de entrada [ip policy route-map “nombre”] para enviar tráfico
(eligiendo destino, origen o protocolo) hacia un next hop específico.
3) Autoroute Announce: se habilita al LSR Head End para que utilice la interface tunel
TE como interface de salida [tunnel mpls traffic-eng autoroute announce].
4) Forwarding adjacency: es una funcionalidad propia de MPLS TE que habilita al IGP
para ver al túnel TE LSP como un enlace más, con una métrica asociadal, y que pueda
establecer relaciones de adyacencia con los routers vecinos, conectados a través del
túnel. Para que funciones correctamente debe configurarse un túnel en sentido
contrario.
5) Mapeo de tráfico AToM
6) Selección del túnel por clases (CBTS): es una función MPLS TE que permite enviar
tráfico con diferente CoS (Class of Service) sobre diferentes túneles, entre los mismos
LSR Head End y Tail End.
consulteach 63
CONFIGURACIÓN MPLS-TE
MPLS-TE FRR
Nodo

Protegido
• Tráfico X hacia R5 por el túnel

TE Æ rótulo 89 (R1)
65 Æ NULL
LSR Mid-point
PLR
LSR Head End
MP
LSR Mid-point
LSR Tail End

89 Æ 65 (R2)

89 Æ (POP)
Push Æ 23 (R3)
NNHOP

Rótulo IN Æ Rótulo OUT 32 Æ (POP-R5)
23 Æ 32 (R4)
NHOP
Con FRR (Fast Re-route) se crea anticipadamente un túnel de backup para cada
nodo/enlace protegido (se evita la pérdida de tiempo durante el establecimiento).
Tanto en el esquema de protección de enlaces como en el de nodos, la reparación
local, y se realiza tan cerca del punto de falla como sea posible (esto lo hace muy
rápido, en el orden de algunas decenas de milisegundos).
PLR= Point of Local Repair
NHOP= Next Hop bypass tunnel
NNHOP= Next-Next Hop bypass tunnel
MP= Merge Point (donde converge el túnel protegido y el de backup)
El PLR debería utilizar el túnel de backup para transportar los TE LSPs sólo
efímeramente.
La protección es temporaria porque la falla del enlace/nodo dispara que el PLR envíe
mensajes PATHERR hacia el LSR Head End, para que recalcule un nuevo trayecto
para el túnel LSP y proceda a señalizarlo, momento en que todo el LSP será enrutado
sobre otro túnel TE, liberando el de backup.
El IGP también señaliza la falla, de manera que el LSR utiliza el túnel de backup para
enrutar los mensajes PATH para el nuevo túnel protegido sobre el túnel de backup,
mientras éste se encuentre en uso.
consulteach 64
OTROS SERVICIOS MPLS
Servicio VPLS

Sitio
Metro 1
Sitio
Metro 2
PE
CE
VPLS
Sitio PE
Central PE
VPLS (Virtual Private LAN Service) emula un segmento LAN a través del backbone MPLS, sobre pseudocables
o circuitos virtuales. VPLS crea una o más LANs aisladas para cada cliente del servicio.
La figura muestra los sitios Ethernet de un cliente en diferentes ciudades, interconectados por un SP que corre
el servicio VPLS.
Para el cliente, sus dispositivos aparecen como conectados mediante un switch

Ethernet virtual.
Emergen dos opciones para interconectar los sitios Ethernet, dependiendo si a los
BPDU de STP se les permite el tránsito por el switch virtual. Si no pueden pasar, el STP
de cada sitio Ethernet termina en el PE. Si pueden pasar, el STP cruza el backbone
MPLS (switch virtual) y una única instancia de STP corre en todos los sitios.
Este servicio es similar a EoMPLS (Ethernet over MPLS), aún cuando este servicio es
punto-a-punto, y VPLS (emulando una LAN) es un servicio punto-multipunto.
VPLS es un servicio IP centric de emulación de LAN Ethernet.
Ningún otro tráfico de capa 3 puede ser transportado sobre MPLS con este servicio
VPLS.
AToM (Any Transport over MPLS) no está limitado al transporte de IP, sino que permite
transportar cualquier protocolo de capa 3, así como tramas de capa 2. Pero posee la
desventaja de ser un servicio punto-a-punto.
Entre cada par de Pes existe un pseudocable (dos LSPs, uno en cada dirección) que
transportan los frames de capa 2.
Las redes Metro Ethernet han tenido tremendo éxito durante los pasados años porque
es económico, flexible, omnipresente y de fácil provisionamiento.
Si un cliente desea conectar sus segmentos Ethernet desde diferentes sitios a través
del backbone MPLS de un SP, aún podría utilizar EoMPLS, pero con conexiones punto-
a-punto.
Si los diferentes sitios Ethernet están ubicados en proximidad, el cliente podría
desplegar un switch Ethernet entre los segmentos. Pero si están lejanos, VPLS podría
proveer la funcionalidad emulando una red Ethernet o actuando como un bridge lógico
obre MPLS.
consulteach 65
OTROS SERVICIOS MPLS - VPLS
Servicio VPLS – Bridge lógico

Sitio
Metro 1
Sitio
Metro 2
CE
Sitio
Central
El cliente “ve” sus dispositivos como conectados mediante un switch Ethernet virtual.
Para ello, el SP debe proveer un servicio que emule la LAN o la funcionalidad de un
switch Ethernet, es decir:
■ Forwarding de frames Ethernet
■ Forwarding de tramas unicast con dirección de destino MAC desconocida
■ Replicación de tramas broadcast y multicast sobre varios puertos
■ Prevención de loops
■ Aprendizaje dinámico de las direcciones MAC
■ Envejecimiento y eliminación de las direcciones MAC
consulteach 66
Arquitectura VPLS – Modelo

Cliente-1
Sitio
Metro 1
Cliente-1
Sitio
Metro 2
Cliente-1
Cliente-1
LSP PE
CE LSP
Sitio PE PseudoWires
Central PE
VPLS
Los routers PE involucrados con la instancia VPLS Cliente-1.

El cliente posee varios sitios, todos conectados a un router PE. Los PE poseen PW
(PseudoWires) entre ellos para transportar las tramas Ethernet.
Cada PW consiste de un LSP en cada dirección.
Si el CE o Switch envía un BC al PE, el frame se replica y transmite a todos los puertos
físicos y PW del PE que pertenecen a la instancia VPLS (dominio BC). Los MC se
replican y transmiten a todos los puertos físicos y PW que son parte de ese grupo
multicast.
Si los PE no están completamente meshed para una instancia VPLS, se requiere STP
para mantener la topología de capa 2 libre de loops.
Pero si los PE están completamente mallados (meshed), se usa un mecanismo más
sencillo: Split Horizon en capa 2 (un frame inundado que se recibe en un PW nunca
será forwardeado a otros PW). En realidad, VPLS requiere un mallado total de PW entre
los PE de cada instancia VPLS.
consulteach 67
Arquitectura VPLS – Configuración

Cuando se configura una instancia VPLS en el PE, también deben especificarse sus
vecinos VPLS. Los PE establecen sesiones LDP remotas (targeted) entre ellos en una
red mallada.
Estas sesiones LDP remotas señalizan los VC (o PW) entre cada para de PE y se
anuncian los rótulos VC.
Si se asigna un instancia VPLS a una interface VLAN en el PE local, se genera un VC
ID local para dicha instancia. El VC ID es el identificador de la VPN (VPN ID) que debe
configurarse a esa instancia VPLS. Cada PW entre un par de PE para esa instancia
VPLS posee el mismo VC ID (aunque el rótulo VC que el PE asigna a cada instancia
VPLS es diferente para cada PW).
consulteach 68
Arquitectura VPLS – Verificación vecinos LDP

Sitio Cliente-1
Metro 1
CE2
Sitio Cliente-1
VPLS-PE2
Metro 2
1.1.1.2/32
VPLS-PE1 VPLS-PE3
Cliente-1 1.1.1.1/32 1.1.1.3/32
S0
2.2.2.1
S2
CE1 2.2.2.2 CE3
S0 S0
Sitio 2.2.1.1 2.2.3.1
Central S1 S3
2.2.1.2 2.2.3.2
LSR-P
1.1.1.4/32
VPLS-PE1#show mpls ldp neighbor

TCP connection: 1.1.1.4.11046 - 1.1.1.1.646
State: Oper; Msgs sent/rcvd: 4438/4481; Downstream
Up time: 2d16h
Serial 0, Src IP addr: 2.2.1.2
1.1.1.4 2.2.1.2 2.2.2.2 2.2.3.2
TCP connection: 1.1.1.2.11526 - 1.1.1.1.646
Up time: 2d16h
Targeted Hello 1.1.1.1 -> 1.1.1.2, active, passive
1.1.1.2 2.2.2.1 3.3.2.1
TCP connection: 1.1.1.3.11001 - 1.1.1.1.646
Up time: 00:18:24
Targeted Hello 1.1.1.1 -> 1.1.1.3, active, passive
1.1.1.3 2.2.3.1 3.3.3.1
consulteach 69
OTROS SERVICIOS MPLS -VPLS
Arquitectura VPLS – Verificación VCs – Verificación LFIB

VPLS-PE1#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Untagged l2ckt(1) 2469636 F0/1 point2point
17 Untagged l2ckt(1) 104971374 F0/1 point2point
18 Pop tag 2.2.2.0/24 0 Serial0 point2point
20 17 1.1.1.2/32 0 Serial0 point2point
22 18 1.1.1.3/32 0 Serial0 point2point
VPLS-PE1#show mpls l2transport summary VPLS-PE1#show mpls l2transport vc 1 detail

Destination address: 1.1.1.2, total number of vc: 1 Local interface: VFI cliente-1 up
0 unknown, 1 up, 0 down, 0 admin down Destination address: 1.1.1.2, VC ID: 1, VC status: up
1 active vc on MPLS interface Serial 0 Tunnel label: 17, next hop point2point
Output interface: Serial 0, imposed label stack {17 18}
Destination address: 1.1.1.3, total number of vc: 1
Create time: 2d17h, last status change time: 01:04:54
0 unknown, 1 up, 0 down, 0 admin down
Signaling protocol: LDP, peer 1.1.1.2:0 up
1 active vc on MPLS interface Serial 0
MPLS VC labels: local 16, remote 18
Group ID: local 0, remote 0
VPLS-PE1#show mpls l2transport binding MTU: local 1500, remote 1500
Destination Address: 1.1.1.2, VC ID: 1 Remote interface description:
Local Label: 16 Sequencing: receive disabled, send disabled
Cbit: 0, VC Type: Ethernet, GroupID: 0 VC statistics:
MTU: 1500, Interface Desc: n/a packet totals: receive 23964, send 23699
Remote Label: 18 byte totals: receive 2440105, send 2511957
Cbit: 0, VC Type: Ethernet, GroupID: 0 packet drops: receive 0, send 0
MTU: 1500, Interface Desc: n/a Local interface: VFI cust-one up
Destination address: 1.1.1.3, VC ID: 1, VC status: up
Destination Address: 1.1.1.3, VC ID: 1
Tunnel label: 18, next hop point2point
Local Label: 17
Output interface: Serial 0, imposed label stack {18 16}
Cbit: 0, VC Type: Ethernet, GroupID: 0
Create time: 2d17h, last status change time: 00:16:02
MTU: 1500, Interface Desc: n/a Signaling protocol: LDP, peer 1.1.1.3:0 up
Remote Label: 16 MPLS VC labels: local 17, remote 16
Cbit: 0, VC Type: Ethernet, GroupID: 0 Group ID: local 0, remote 0
MTU: 1500, Interface Desc: n/a MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 105057, send 123145
byte totals: receive 103022139, send 105052493
packet drops: receive 0, send 0
consulteach 70
OTROS SERVICIOS MPLS - ATOM
Conceptos AToM

ATM
ATM
FR
FR
ROUTER HDLC ROUTER
HDLC
/SWITCH PPP /SWITCH
PPP
ETH
ETH
PSN = Packet Switched Network
AToM transporta tramas de capa de enlace de datos (capa 2) sobre un backbone

MPLS, permitiendo al SP conectar sitios de clientes que utilizan redes de capa 2
mediante una única infraestructura integrada, basada en paquetes, en lugar de
requerirse redes separadas, con sus respectivos sistemas de gestión, logística, etc.
Soporta los siguientes tipos de transporte:
• ATM Adaptation Layer Type-5 (AAL5) sobre MPLS
• ATM Cell Relay sobre MPLS
• Ethernet sobre MPLS (puertos y VLANs)
• Frame Relay sobre MPLS
• PPP sobre MPLS
• High-Level Data Link Control (HDLC) sobre MPLS
En realidad, existe otra forma de transportar los frames de capa 2 sobre redes PSN
(Packet switched network): utilizando L2TPv3 (Layer 2 Tunneling Protocol, versión 3)
sobre un backbone IP.
Para ambos casos se utiliza una arquitectura similar (basada en pseudowires), sólo que
la red de transporte es diferente.
Los PW (pseudowires) son conexiones entre PEs que emulan circuitos para el
transporte de las tramas de capa 2.
AToM utiliza las sesiones LDP entre PE para establecer y mantener las conexiones.
El forwarding tiene lugar mediante el uso de dos niveles de rótulos entre los PE.
El rótulo top (o rótulo de túnel) enruta el paquete sobre el backbone MPLS desde el PE
de ingreso hasta el PE de egreso.
El rótulo bottom (rótulo VC ó circuito virtual) indica la interface de egreso, relacionando
la interface de egreso de la capa 2 con el rótulo del túnel.
consulteach 71
Arquitectura AToM – Plano de control

VC ID 100
VC ID 100
Señalización vía LDP o RSVP
Los PW son señalizados mediante una sesión LDP dirigida (targeted) entre los PE.
Esencialmente, el protocolo de señalización LDP establece y mantiene los PW entre los
PE.
LDP ha sido extendido con nuevos campos TLVs (Type Length Value) para estas
tareas, principalmente para anunciar los rótulos VC (circuitos virtuales) asociados con el
PW.
El rótulo se anuncia en un mensaje de mapeo de rótulo (LABEL MAPPING) utilizando el
modo de anuncio uD (unsolicited label advertisement mode), y anuncia la información
necesaria en los TLVs.
El anuncio tiene efecto desde el PE de egreso hacia el PE de ingreso para el AC

identificado mediante el VC ID 100, sobre una sesión LDP dirigida (targeted).
El rótulo del túnel es el que se anuncia normalmente desde el PE de egreso hacia el PE
de ingreso por LDP (se está utilizando PHP, es decir rótulo 3).
consulteach 72
Arquitectura AToM – Plano de datos

ROUTER ROUTER
/SWITCH /SWITCH
S0 E0
El PE de ingreso recibe frames de CE1 y los transmite a través del backbone MPLS
hacia el PE de egreso con dos rótulos: el del túnel y el del circuito virtual.
En una red AToM, cada par de PE deben establecer una sesión LDP targeted entre
ellos para señalizar las características del PW (sobre todo el rótulo VC).
El rótulo VC es siempre el BoS, ya que define el AC de egreso en el PE de egreso. El
rótulo del túnel es el top, con las mismas funciones comunes de la red MPLS.
PE1 primero realiza un PUSH del rótulo VC (rótulo 45), y a continuación realiza el
PUSH del rótulo del túnel (rótulo 27), asociado con el IGP, el cual identifica el prefijo de
PE2.
Los LSRs P nunca requieren acceso al rótulo VC, y no necesitan ninguna inteligencia al
respecto (los LSR P no tienen conocimiento de la solución AToM).
No se requiere ningún protocolo especial para la distribución de rótulos (LDP ó RSVP-
labels).
La asociación del AC a través del VC se realiza mediante la sesión LDP dirigida.
consulteach 73

CTH MPLS 2016 Print

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CTH MPLS 2016 Print

Încărcat de

Drepturi de autor:

Formate disponibile

consulteach

Sobre plataformas IOS

Prohibida su reproducción total o parcial no sin previo consentimiento de consulteach.

Este documento es propiedad de consulteach. consulteach@cnsulteach.com.ar

Preparado por: Ing. Julio César Carossella

Buenos Aires, Junio 2016

INTRODUCCIÓN Y CONCEPTOS MPLS

1.- PC 10.1.0.1 2.- R1 2.- R2

INTRODUCCIÓN Y CONCEPTOS MPLS

No existe relación de rutas entre los equipos

INT DLCI INT DLCI

INTRODUCCIÓN Y CONCEPTOS MPLS

INTRODUCCIÓN Y CONCEPTOS MPLS

Protocolo de Nombre del identificador de

El rótulo se aplica entre el encabezamiento (header) de la capa transportada y el

Entonces, MPLS no es un protocolo de capa 2 (porque el encabezamiento de capa 2 original

INTRODUCCIÓN Y CONCEPTOS MPLS

Labels (rótulos) y Label Stack (Pila) CE = Customer Edge

INTRODUCCIÓN Y CONCEPTOS MPLS

PUSH SWAP SWAP POP

Un LSR es un router con capacidad de entender los rótulos MPLS, y recibir/transmitir

INTRODUCCIÓN Y CONCEPTOS MPLS

INTRODUCCIÓN Y CONCEPTOS MPLS

FEC => RÓTULO (LABEL)

RÓTULO => FEC {EXP}

LSP (Label Switched Path): secuencia unidireccional de LSRs que indican el

INTRODUCCIÓN Y CONCEPTOS MPLS

2. Utilizar un protocolo de distribución de rótulos separado

INTRODUCCIÓN Y CONCEPTOS MPLS

El modo de distribución de rótulos utilizado depende de la interface y de la

INTRODUCCIÓN Y CONCEPTOS MPLS

INTRODUCCIÓN Y CONCEPTOS MPLS

Así, el anteúltimo LSR en el LSP se llama PHP (Penultimate Hop Popping)

INTRODUCCIÓN Y CONCEPTOS MPLS

El valor 14 es el rótulo Alerta OAM (Operation and Maintenance), según la recomendación

INTRODUCCIÓN Y CONCEPTOS MPLS

INTRODUCCIÓN Y CONCEPTOS MPLS

Sin embargo, el mensaje ICMP no es enviado de regreso inmediatamente porque el LSR

INTRODUCCIÓN Y CONCEPTOS MPLS

IMPLEMENTACIÓN MODO FRAME

IMPLEMENTACIÓN MODO FRAME

IP Routing Table (RIB)

IP Forwarding Table (FIB)

Label Forwarding Table (LFIB)

El plano de control, el routing IP tradicional, es un área de trabajo de los protocolos de

IMPLEMENTACIÓN MODO FRAME

IMPLEMENTACIÓN MODO FRAME

EIGRP [100] S1/0

IMPLEMENTACIÓN MODO FRAME

LDP Id: 10.0.1.1:0 LDP Id: 10.0.1.1:0

LDP Id: 10.0.1.3:0 LDP Id: 10.0.1.2:0

LDP Id: 10.0.1.5:0 LDP Id: 10.0.1.5:0

LDP Id: 10.0.1.6:0 LDP Id: 10.0.1.6:0

VERIFICACIÓN Y MONITOREO DEL TRÁFICO

IMPLEMENTACIÓN MODO FRAME

ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS

 Establecimiento y mantenimiento de sesiones LDP

 Anuncios de mapeos de rótulos

 Housekeeping mediante notificaciones

ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS

ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS

P2#show mpls ldp neighbor 10.0.1.3 detail

ASIGNACIÓN Y DISTRIBUCIÓN DE LABELS

Establecimiento y mantenimiento de sesiones LDP

Anuncios de mapeos de rótulos

Housekeeping mediante notificaciones