Você está na página 1de 25

MPLS VPN

1. Conceptos bsicos de MPLS y de VPNs basadas en MPLS.

Una de las aplicaciones de uso ms popular de MPLS es la creacin de una red privada virtual o
VPN. En lo que concierne a los proveedores de servicios de Internet o ISP, MPLS ha simplificado
la configuracin e implementacin de soluciones VPN para sus usuarios. MPLS tambin facilita la
interconexin de diferentes usuarios, cuando ellos as lo soliciten. A continuacin se describe la
manera como viajaran los paquetes (IPv4) dentro de un ncleo (backbone) MPLS VPN. Para tener
una mejor idea de cmo funciona MPLS, se recomienda la lectura de los primeros captulos de
MPLS Fundamentals. Tambin hay otros recursos disponibles en la web: Introduction to MPLS,
MPLSTutorial.com.

La figura anterior ha sido tomada del libro Cisco Press MPLS Fundamentals (MPLS
Fundamentals). Dicha figura ilustra la manera como se aplican las etiquetas o labels al paquete IP
que viaja a travs de una red MPLS VPN. En el enrutador de ingreso PE (Ingress PE), se introducen
(push) dos etiquetas o labels al paquete IP proveniente del enrutador CE del usuario. En primer
lugar, se introduce la etiqueta de VPN o VPN label (la etiqueta ms interna, cuyo valor para este
ejemplo es de 30), la cual determinar cul ser el enrutador PE de salida que recibir el paquete
(cul ser el Egress PE de entre muchos posibles nodos de destino). En segundo lugar, se introduce
una etiqueta externa label (que en este ejemplo es la 16) encima de la anterior (top), dicha
etiqueta determinar cul ser el enrutador P (de varios nodos posibles) que har las veces de
prximo salto en el camino normal de MPLS (dicho camino tambin se denomina LSP o Labeled
Switch Path, el cual suponemos ya se ha establecido previamente). Esta etiqueta externa es
cambiada por cada enrutador P que forme parte del LSP (de 16 a 33 para el primer P de este
ejemplo), hasta ser extrada y eliminada por el penltimo enrutador P de la red MPLS VPN, es
decir, por el enrutador que precede al enrutador PE de salida (Egress PE), quedando de esta manera
el paquete con solamente el valor del VPN label (30 en este ejemplo) antes de ser enviado hacia el
enrutador de salida (Egress PE). En el enrutador de salida (Egress PE), el VPN label del paquete
(30 para este ejemplo) sirve para seleccionar al router CE del usuario apropiado (de varios posibles
usuarios) hacia el cual dicho paquete debe ser enviado usando el software de enrutamiento IP
tradicional, antes de enviarse el paquete IP al usuario apropiado, se procede a eliminar el VPN label
del mismo.

Cualquier enrutador P que est dentro del LSP (Labeled Switch Path) no tendr conocimiento de las
tablas de enrutamiento IP ni de las etiquetas VPN (VPN labels) entuneladas a travs de ellos e
intercambiadas entre los enrutadores PE (de borde). Esto es importante de entender puesto que si
por error en la configuracin, un enrutador P recibe un paquete etiquetado con un valor
correspondiente a la VPN de algn usuario especfico (algn VPN label), dicho equipo no tendr
idea de qu hacer con el paquete y por lo tanto tendr que descartarlo.

En la medida en que se revisa el tema de VPNs basadas en MPLS, encontraremos nuevos trminos
que necesitamos entender y tambin notaremos que se debe tener una mirada un poco diferente a la
funcin que tradicionalmente realiza un protocolo exterior como lo es el protocolo BGP (Borde
Gateway Protocol). Para empezar, la funcin tradicional que realiza el protocolo BGP es la de
permitir la interconexin de dos sistemas autnomos (que pertenecen a diferentes autoridades o
dominios administrativos) mediante el uso de una conexin TCP establecida entre dos enrutadores
de borde (un enrutador por cada sistema autnomo) previamente designados por cada sistema
autnomo para inyectar las rutas anunciadas por un sistema autnomo hacia el otro y viceversa. En
suma, BGP permite interconectar dos sistemas autnomos y cada sistema autnomo tiene la libertad
de escoger el protocolo de enrutamiento interno (RIP, OSPF, etctera) de acuerdo a lo que defina su
autoridad administrativa. Posteriormente en el desarrollo de un ejemplo usaremos BGP en la
conexin PE-a-CE.

La otra mirada de BGP en el contexto de redes VPN basadas en MPLS es que el protocolo BGP
permite intercambiar rutas dentro de una misma VPN (intercambiadas entre PE-a-PE). Cuando BGP
est funcionando de esta manera, con frecuencia se le refiere con el nombre MP-BGP
(Multiprotocol BGP). BGP es el protocolo preferido por su flexibilidad (extensibility). Las rutas
transportadas dentro de MP-BGP se conocen como rutas VPNv4. Como veremos, BGP se refiere a
IPv4, Ipv6, VPNv4, etctera, como familias de direcciones (address families). Esto es lo que
permite que BGP pueda distinguir cul tipo de rutas est viendo (enviando o recibiendo). Esto
tomar ms sentido en la medida que avancemos en nuestro ejemplo.

Las rutas VPNv4 (enviadas y recibidas) son esencialmente rutas Ipv4 (enviadas y recibidas) que
tienen un valor adicional apuntillado (tacked) en el frente de la ruta, el valor anexado se conoce con
el nombre de Route Distinguisher (RD). El formato tpico de un RD es ASN:nn (ASN representa
el acrnimo de Autonomous System Numbers), algunas veces el RD tiene la forma IPv4 Address:nn
donde el valor IPv4 address corresponde al valor de un rango de direcciones pblicas asignadas.
El valor RD se usa para designar y distinguir la instancia VRF (Virtual Routing and Forwarding)
a la que pertenece una ruta IPv4 especifica (es comn que al usuario 1, le corresponde la instancia
VRF 1 y que dicha instancia se distinga de otras instancias mediante un RD de 1). Los VRF son
bsicamente enrutadores virtuales dentro de un enrutador fsico. Una instancia VRF contiene una
tabla de enrutamiento que est completamente separada (y es independiente) tanto de otras tablas de
enrutamiento correspondiente a otros VRF como de la tabla de enrutamiento principal del enrutador.
Una vez un enrutador de borde PE (que est participando en el intercambio de rutas VPNv4) reciba
una ruta VPNv4, este eliminar el RD de la ruta VPNv4 recibida y colocar la ruta IPv4 original
(recibida en la ruta VPNv4) en la tabla de enrutamiento de la instancia VRF correspondiente al RD
recibido.

Para aclarar el concepto del funcionamiento de la pareja RD/VPNv4, asumamos que se tienen dos
usuarios conectados al mismo enrutador PE y que cada uno de ellos tiene una red con direccin de
red 192.168.1.0/24 directamente conectada al enrutador PE. Digamos que desde otro enrutador llega
un datagrama IP al enrutador PE y que dicho datagrama IP tiene como direccin IP destino el valor
192.168.1.5. Sin el RD, el enrutador PE no tendr manera de saber cual es el usuario correcto al que
se le debe reenviar dicho datagrama IP. Ahora, partiendo de que el RD entra en operacin en el
enrutador PE y suponiendo que dicho enrutador usa un VRF con RD 5:1 para uno de los usuarios
(Usuario A) y que para el otro usuario usa un VRF con RD 260:1 (Usuario B). El resultado es que
una vez se adicione el RD (asignado a cada usuario) a la direccin de red IPV4 original (de cada
usuario), se podrn tener dos rutas diferentes. Con la sintaxis VPNv4, la ruta hacia la red
192.168.1.0/24 del usuario A se distinguir con 5:1:192.168.1.0/24 y la ruta hacia la red
192.168.1.0/24 del usuario B se distinguir con 260:1:192.168.1.0/24.

El RD es el que permite que las direcciones de red de los usuarios del ncleo VPN MPLS puedan
traslaparse.

Ahora abordaremos otro concepto importante en redes VPN MPLS: El RT (Route Target). El RT
entra en juego cuando necesitamos crear una extranet entre usuarios de diferentes VPN. El RT es un
tag cuyo valor designa cules rutas VPNv4 se importan y exportan en un VRF. El RT es llevado
dentro de BGP como un atributo extendido, su sintaxis es muy similar a la del RD y con frecuencia
tiene el mismo valor. En la mayora de casos, cuando no se necesita proporcionar acceso entre
usuarios de diferentes VPN, un solo RT es tanto importado como exportado hacia un VRF. Pero si
entre dos usuarios necesitan mutuamente tener acceso a las redes del otro usuario, cada usuario
requiere importar el RT exportado por el otro.

Refirindonos al ejemplo anterior, supongamos que el usuario A (el cual est importando y
exportando un RT de 5:1) y el usuario B (importando y exportando un RT de 260:1) mutuamente
necesitan que desde algunas de sus oficinas se pueda acceder a algunas de las redes del otro. En los
enrutadores PE a los que se conectan dichas oficinas, se requiere importar el RT 5:1 hacia el VRF
del usuario B e importar el RT 260:1 hacia el VRF del usuario A. De esta manera dichos usuarios
podrn intercambiar rutas VPNv4 entre ellos con el fin de permitir la comunicacin entre las redes
de las oficinas conectadas a los PE (en los cuales se importa el RT).

Es importante indicar que MP-BGP funciona de una manera similar al BGP normal. Como
consecuencia, si no se conforma una malla completa de conexiones (full mesh) entre enrutadores
PE pares (de igual a igual), se necesitar implementar una tcnica conocida como route reflection.
Por ahora solamente sealaremos que despus de haber desarrollado los fundamentos y conceptos
bsicos, pasaremos a un ejemplo que nos permita familiarizarnos con las redes VPN MPLS.

Para empezar, abordaremos la configuracin bsica de MPLS con el fin de obtener un ambiente de
conmutacin de etiquetas completamente funcional en el ncleo MPLS de un ISP hipottico. Este
ser nuestro punto de inicio sobre el cual profundizaremos.

Una vez conformado el ncleo MPLS representado en la figura 1 y en la figura 2, se pueden


conectar dos usuarios (Customer A y Customer B) a dicho ncleo, cada usuario posee dos
sucursales (oficinas) ubicadas en sitios diferentes (respecto del ncleo MPLS), tal como se puede
apreciar en la figura 3 y en la figura 4. Como se observa en dichas figuras, dependiendo de la
ubicacin y del papel que juegan los enrutadores en la red, se le asignan diferentes nombres:

CE (Customer Edge): Para un enrutador IPv4 en el borde del usuario.


PE (Provider Edge): Para un enrutador IPv4 y MPLS en el borde del proveedor.
P (Provider): Para un enrutador MPLS en el ncleo del proveedor.
Los enrutadores P pueden conectarse solamente con enrutadores PE y con otros enrutadores P. Los
enrutadores PE pueden conectarse con enrutadores P, PE y CE. Finalmente, los enrutadores CE
pueden conectarse solamente a enrutadores PE (y probablemente a enrutadores internos del mismo
usuario). Los enrutadores CE no ejecutan por s mismo ningn tipo de proceso de conmutacin de
etiquetas.

2. Desarrollo de una red VPN MPLS

2.1. Configuracin del ncleo MPLS: LDP (Label Discovery Protocol)

Cubriremos el protocolo LDP (Label Discovery Protocol) y su interoperacin con el protocolo de


enrutamiento interior OSPF (que usaremos en el ncleo MPLS). Observaremos cmo se
construyen la LIB (Label Information Base o Base de Informacin de Etiquetas) y la LFIB (Label
Forwarding Information Base o Base de Informacin de Reenvo basada en Etiquetas). Tambin
la manera cmo dichos tem trabajan en conjunto con CEF (Cisco Express Forwarding).

Brevemente, LIB y LFIB son respectivamente las versiones MPLS de RIB (Routing Information
Base) y de FIB (Forwarding Information Base) encontradas en un enrutador estndar de Ipv4 (tabla
CEF). Ellas bsicamente sirven para funciones similares a las realizadas en IPv4: la LIB equivale a
la tabla de enrutamiento y la LFIB acta como tabla de conmutacin que recibe y enva
paquetes del enrutador. Cuando ocurre un cambio en la LIB (debido a la falla de un enlace, retiro de
un enrutador de la red, etctera), la LFIB se actualiza adecuadamente.

Figura 1. Topologa bsica del ncleo MPLS de un ISP que identifica cada uno de los puertos
usados.
Figura 2. Topologa bsica del ncleo MPLS de un ISP que muestra el direccionamiento IP.

Antes de empezar la configuracin de MPLS, debemos acordar cmo va a estar configurado


inicialmente nuestro ISP hipottico. El ISP inicialmente estar ejecutando el protocolo de
enrutamiento OSPF (IGP) en una sola rea (rea 0) y no transportar trfico de usuario. Con esto
pretendemos que dicho ISP apenas est iniciando su operacin y que an no tiene usuarios
conectados, por ahora el trfico es completamente interno. Por ejemplo, de acuerdo a la figura 1 y a
la figura 2, la configuracin de los enrutadores puede ser:

R3:

hostname R3
!
ip cef
!
interface Loopback0
ip address 150.1.3.3 255.255.255.255
!
mpls ip
!
interface Serial1/1
ip address 192.168.36.1 255.255.255.252
mpls ip
serial restart-delay 0
!
interface Fa2/0
ip address 192.168.34.1 255.255.255.252
mpls ip
!
router ospf 100
log-adjacency-changes
network 150.1.0.0 0.0.255.255 area 0
network 192.168.36.0 0.0.0.255 area 0
network 192.168.34.0 0.0.0.255 area 0
R4:

hostname R4
!
ip cef
!
interface Loopback0
ip address 150.1.4.4 255.255.255.255
!
mpls ip
!
interface Fa2/0
ip address 192.168.34.2 255.255.255.252
mpls ip
!
interface Fa2/1
ip address 192.168.45.2 255.255.255.252
mpls ip
!
router ospf 100
log-adjacency-changes
network 150.1.0.0 0.0.255.255 area 0
network 192.168.34.0 0.0.0.255 area 0
network 192.168.45.0 0.0.0.255 area 0

R5:

hostname R5
!
ip cef
!
interface Loopback0
ip address 150.1.5.5 255.255.255.255
!
mpls ip
!
interface Fa2/0
ip address 192.168.45.1 255.255.255.252
mpls ip
!
interface Serial1/1
ip address 192.168.56.1 255.255.255.252
mpls ip
serial restart-delay 0
!
router ospf 100
log-adjacency-changes
network 150.1.0.0 0.0.255.255 area 0
network 192.168.45.0 0.0.0.255 area 0
network 192.168.56.0 0.0.0.255 area 0

R6:

hostname R6
!
ip cef
!
interface Loopback0
ip address 150.1.6.6 255.255.255.255
!
mpls ip
!
interface Serial1/0
ip address 192.168.36.2 255.255.255.252
mpls ip
serial restart-delay 0
!
interface Serial1/1
ip address 192.168.56.2 255.255.255.252
mpls ip
serial restart-delay 0
!
router ospf 100
log-adjacency-changes
network 150.1.0.0 0.0.255.255 area 0
network 192.168.36.0 0.0.0.255 area 0
network 192.168.56.0 0.0.0.255 area 0

Una vez configurado OSPF, podemos revisar la tabla de enrutamiento de R6 para tener una idea del
estado de la red, para ello se usa el comando sh ip route.

R6# sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.45.0/30 is subnetted, 1 subnets


O 192.168.45.0 [110/65] via 192.168.56.1, 01:40:57, Serial1/1
192.168.56.0/30 is subnetted, 1 subnets
C 192.168.56.0 is directly connected, Serial1/1
192.168.36.0/30 is subnetted, 1 subnets
C 192.168.36.0 is directly connected, Serial1/0
192.168.34.0/30 is subnetted, 1 subnets
O 192.168.34.0 [110/65] via 192.168.36.1, 01:40:57, Serial1/0
150.1.0.0/32 is subnetted, 4 subnets
C 150.1.6.6 is directly connected, Loopback0
O 150.1.5.5 [110/65] via 192.168.56.1, 01:40:57, Serial1/1
O 150.1.4.4 [110/66] via 192.168.56.1, 01:40:58, Serial1/1
150.1.4.4 [110/66] via 192.168.36.1, 01:40:58, Serial1/0
O 150.1.3.3 [110/65] via 192.168.36.1, 01:40:58, Serial1/0
En la tabla de enrutamiento podemos verificar que los enrutadores han aprendido sobre la existencia
de todas las redes conectadas al ncleo MPLS (incluyendo las direcciones de Loopback) por medio
de OSPF, excepto para los enlaces que se conectaran a futuros usuarios. Note tambin que R6 tiene
dos caminos de igual costo hacia la direccin de loopback de R4 (150.1.4.4). Esto pronto tendr
consecuencias.

Para habilitar MPLS en los enrutadores se realizan tres pasos. Primero, MPLS no funcionar si no
se habilita CEF, se requiere ejecutar el comando global ip cef en cada enrutador sobre el cual se
planee implementar MPLS. Segundo, se requiere habilitar MPLS de manera global por medio del
comando mpls ip. Finalmente, se configura el protocolo de distribucin de etiquetas sobre las
interfaces conectadas al ncleo MPLS con el fin de habilitar el intercambio de etiquetas entre los
enrutadores, esto se hace a travs del comando mpls ip pero por cada interfaz (en el modo de
configuracin de cada interfaz). En la mayora de las redes, se usa LDP como protocolo de
distribucin de etiquetas. Cisco soporta un viejo protocolo propietario denominado TDP (Tag
Distribution Protocol), pero es considerado un protocolo heredado (legacy). LDP es el protocolo por
defecto en la versin 12.4 o posterior del IOS. De tal suerte que con la configuracin anterior hemos
habilitado MPLS en todos los enrutadores e interfaces que se conectan al ncleo MPLS. Para
verificar la configuracin en R6, se usa el comando show mpls interfaces.

R6# show mpls interfaces


Interface IP Tunnel Operational
Serial1/0 Yes (ldp) No Yes
Serial1/1 Yes (ldp) No Yes

Una vez completada la configuracin de todos los enrutadores conectados al ncleo, podemos
verificar que se han establecido las sesiones LDP y que se estn comunicando. Usaremos para ello
un par de comandos:

R6# sh mpls ldp discovery


Local LDP Identifier:
150.1.6.6:0
Discovery Sources:
Interfaces:
Serial1/0 (ldp): xmit/recv
LDP Id: 150.1.3.3:0
Serial1/1 (ldp): xmit/recv
LDP Id: 150.1.5.5:0

R6# sh mpls ldp neighbor


Peer LDP Ident: 150.1.3.3:0; Local LDP Ident 150.1.6.6:0
TCP connection: 150.1.3.3.646 - 150.1.6.6.18851
State: Oper; Msgs sent/rcvd: 14/14; Downstream
Up time: 00:02:02
LDP discovery sources:
Serial1/0, Src IP addr: 192.168.36.1
Addresses bound to peer LDP Ident:
192.168.36.1 192.168.34.1 150.1.3.3
Peer LDP Ident: 150.1.5.5:0; Local LDP Ident 150.1.6.6:0
TCP connection: 150.1.5.5.646 - 150.1.6.6.44185
State: Oper; Msgs sent/rcvd: 13/13; Downstream
Up time: 00:01:11
LDP discovery sources:
Serial1/1, Src IP addr: 192.168.56.1
Addresses bound to peer LDP Ident:
192.168.56.1 192.168.45.1 150.1.5.5

Un par de aspectos claves para mencionar. Primero, note el LDP Id en la salida del comando show
mpls ldp discovery. Dicha direccin ha sido escogida de manera similar a como se escoge el
router-id en la mayora de protocolos: Se escoge la direccin ms alta de la interfaz de Loopback
del enrutador, y si no se tiene ni una interfaz de Loopback, entonces se escoge la direccin ms alta
de las interfaces fsicas. Lo importante es saber que si dicha direccin no es alcanzable (is not
reachable), no se podr formar la adyacencia LDP. Es decir, hay que asegurarse que dichas
direcciones se puedan alcanzar desde los otros equipos vecinos de la red.

Algo ms para resaltar es que LDP se comunica mediante TCP usando el puerto 646. Esto es
importante de recordar en caso de que se tenga alguna medida de seguridad implementada entre
enlaces (ACLs, firewalls, etctera).

Revisemos la LIB y la correspondiente LFIB sobre el enrutador R6:

R6# show mpls ip binding


150.1.3.3/32
in label: 20
out label: imp-null lsr: 150.1.3.3:0 inuse
out label: 20 lsr: 150.1.5.5:0
150.1.4.4/32
in label: 19
out label: 20 lsr: 150.1.3.3:0 inuse
out label: 19 lsr: 150.1.5.5:0 inuse
150.1.5.5/32
in label: 18
out label: 19 lsr: 150.1.3.3:0
out label: imp-null lsr: 150.1.5.5:0 inuse
150.1.6.6/32
in label: imp-null
out label: 18 lsr: 150.1.3.3:0
out label: 18 lsr: 150.1.5.5:0
192.168.34.0/30
in label: 17
out label: imp-null lsr: 150.1.3.3:0 inuse
out label: 17 lsr: 150.1.5.5:0
192.168.36.0/30
in label: imp-null
out label: imp-null lsr: 150.1.3.3:0
out label: 16 lsr: 150.1.5.5:0
192.168.45.0/30
in label: 16
out label: 16 lsr: 150.1.3.3:0
out label: imp-null lsr: 150.1.5.5:0 inuse
192.168.56.0/30
in label: imp-null
out label: 17 lsr: 150.1.3.3:0
out label: imp-null lsr: 150.1.5.5:0

R6# sh mpls forwarding-table


Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 192.168.45.0/30 0 Se1/1 point2point
17 Pop tag 192.168.34.0/30 0 Se1/0 point2point
18 Pop tag 150.1.5.5/32 0 Se1/1 point2point
19 19 150.1.4.4/32 0 Se1/1 point2point
20 150.1.4.4/32 0 Se1/0 point2point
20 Pop tag 150.1.3.3/32 0 Se1/0 point2point

Se han resaltado un par de rutas para ilustrar lo que muestran las tablas. Primero observamos la ruta
192.168.45.0/30. La LIB muestra que los paquetes enviados con destino hacia 192.168.45.0/30,
llegaran con una etiqueta (label) marcada con el nmero 16. Hay dos posibles caminos de salida
para dichos paquetes: a travs de R3 (LSR Id 150.1.3.3) o a travs de R5 (LSR Id 150.1.5.5). R5 ha
sido escogido, como lo muestra la notacin in-use . Esto es porque es el mejor camino de acuerdo
al protocolo IGP (OSPF). La etiqueta saliente (outgoing tag) es Imp-null, lo cual significa un
valor NULL implicito. Esto se refiere al hecho de que R6 realmente elimina (POP) la etiqueta antes
de enviar el paquete a R5. Esto es llamado eliminacin de la etiqueta en el penltimo salto
Penultimate Hop Popping (PHP) y es una funcin habilitada por defecto en los enrutadores Cisco.
En esencia, el enrutador R6 evita que el enrutador R5 tenga que hacer un procesamiento extra
(eliminar la etiqueta 16) puesto que la red 192.168.45.0 est directamente conectada a R5. R5 no
tendr que gastar tiempo precioso de CPU para buscar la etiqueta; este solamente recibe el paquete
como un paquete normal de capa 3. Esto tambin es indicado en la LFIB con 16 Pop tag como la
etiqueta saliente.

Tambin es de inters observar el camino hacia 150.1.4.4/32. Como se puede ver, hay dos caminos
hacia la direccin de loopback de R4 con igual costo. Entonces, la LFIB opera de manera similar a
la FIB cuando se habilita CEF y permite el balanceo de carga por dichos caminos.

Hasta ahora se ha habilitado MPLS en el ncleo de la red del ISP. Esto es todo respecto a la
configuracin bsica de MPLS. MPLS en en si misma solo se torna interesante cuando se corren
aplicaciones sobre ella. Una vez se configuran VPNs e Ingeniera de trfico (Traffic Engineering),
se puede apreciar su poder. Por ahora, se puede pasar a implementar esta red. Experimente con
diferentes comandos y lograr mayor entendimiento de cmo opera MPLS.
2.2. Configuracin de dos VPN MPLS

Hay muchas formas de conseguir que las rutas que conoce el enrutador CE de un usuario especfico
lleguen a la respectiva tabla VRF del enrutador PE (con el cual se conecta directamente el enrutador
CE). Para intercambiar rutas entre un PE y los enrutadores CE que l reciba, podemos usar rutas
estticas, OSPF, RIP, etctera,. Usaremos BGP puesto que en la vida real dicho protocolo es el de
uso ms comn en las conexiones entre el PE y el CE. Esto tambin nos evitar tener que
redistribuir rutas hacia MP-BGP (MP-BGP va a ser usado posteriormente entre PEs), debido a que
cada conexin PE-a-CE es esencialmente una conexin EBGP.

Como primer paso, hay que configurar los VRFs en cada enrutador PE. Puesto que cada sucursal
tiene su propio nmero de sistema autnomo o AS. Ms exactamente, el usuario B tiene al BGP AS
1 para una de sus sucursales y al BGP AS 8 para la otra sucursal (ver figura 3). De acuerdo a lo
anterior, la convencin escogida en el presente ejemplo es usar el valor ms bajo de los AS usados
por cada usuario para asignarlo a su respectivo RD (1 para el Customer B y 2 para el Customer A).
Con ello la configuracin de los VRFs en los enrutadores PE R3, R5 y R6 queda (R4 no requiere de
una configuracin adicional puesto que desempea el papel de un equipo P):

R3:

ip vrf CustB
description Customer B
rd 1:1
route-target export 1:1
route-target import 1:1

R5:

ip vrf CustA
description Customer A
rd 2:1
route-target export 2:1
route-target import 2:1
!
ip vrf CustB
description Customer B
rd 1:1
route-target export 1:1
route-target import 1:1

R6:

ip vrf CustA
description Customer A
rd 2:1
route-target export 2:1
route-target import 2:1
Ahora que se tienen configurados los VRFs en los enrutadores PE, estos VRFs se aplican a las
interfaces de cada enrutador PE que est recibiendo a un enrutador CE, pero teniendo en cuenta al
respectivo usuario recibido por cada interfaz. Algo de notar es que si previamente se ha configurado
la direccin IP en estas interfaces, al realizar la aplicacin de los VRF sobre ellas, borrar sus
direcciones IP y por lo tanto se tendrn que volver a configurar dichos valores. La aplicacin de los
VRFs y la configuracin de las direcciones IP (teniendo en cuenta las figuras 3 y 4) en las interfaces
queda:

R3:

interface Serial1/0
ip vrf forwarding CustB
ip address 192.168.13.1 255.255.255.252

R5:

interface Serial1/0
ip vrf forwarding CustA
ip address 192.168.25.1 255.255.255.252

interface Serial1/2
ip vrf forwarding CustB
ip address 192.168.58.1 255.255.255.252

R6:

interface Serial1/2
ip vrf forwarding CustA
ip address 192.168.67.1 255.255.255.252

Podemos verificar que los VRF han sido aplicados de forma correcta de la siguiente manera (en R3
como ejemplo):

R3# sh ip vrf CustB


Name Default RD Interfaces
CustB 1:1 Se1/0

Despus de tener los VRFs configurados y activos, es momento de realizar la configuracin BGP.
Empezaremos con la configuracin bsica de BGP en los enrutadores CE, es decir, en todos los
equipos de borde del usuario (R1- con AS 1, R2 con AS 2, R7 con AS 7 y R8 con AS 8.). Note
que el ncleo MPLS va a operar internamente con MP-BGP y AS 101. En nuestro ejemplo, con el
objetivo de simplificar la obtencin de las redes de los diferentes usuarios por parte de cada PE (un
usuario puede tener muchas redes detrs de su equipo CE), tan solo vamos a redistribuir hacia BGP
(en cada CE) las rutas de las redes directamente conectadas a los enrutadores CE (esencialmente la
red local de cada usuario).
Figura 3. Topologa VPN MPLS que identifica los puertos usados.

Figura 4. Topologa VPN MPLS que identifica las direcciones IP de las interfaces.
R1:

interface loopback 0
ip address 150.1.1.1 255.255.255.255

interface fastEthernet 0/0


ip address 172.31.1.1 255.255.255.0

interface Serie 1/0


ip address 192.168.13.2 255.255.255.252

router bgp 1
bgp router-id 150.1.1.1
redistribute connected
neighbor 192.168.13.1 remote-as 101
no auto-summary

R8:

interface loopback 0
ip address 150.1.8.8 255.255.255.255

interface fastEthernet 0/0


ip address 172.31.8.1 255.255.255.0

interface Serie 1/0


ip address 192.168.58.2 255.255.255.252

router bgp 8
bgp router-id 150.1.8.8
redistribute connected
neighbor 192.168.58.1 remote-as 101
no auto-summary

R2:

interface loopback 0
ip address 150.1.2.2 255.255.255.255

interface fastEthernet 0/0


ip address 172.31.2.1 255.255.255.0

interface Serie 1/0


ip address 192.168.25.2 255.255.255.252

router bgp 2
bgp router-id 150.1.2.2
redistribute connected
neighbor 192.168.25.1 remote-as 101
no auto-summary
R7:

interface loopback 0
ip address 150.1.7.7 255.255.255.255

interface fastEthernet 0/0


ip address 172.31.7.1 255.255.255.0

interface Serie 1/0


ip address 192.168.67.2 255.255.255.252

router bgp 7
bgp router-id 150.1.7.7
redistribute connected
neighbor 192.168.67.1 remote-as 101
no auto-summary

Lo que sigue es configurar los enrutadores PE para que formen adyacencias BGP con los
enrutadores CE. Pondremos la configuracin PE-a-PE y PE-a-CE bajo un solo proceso BGP, de tal
manera que haya un solo aspecto por abordar. Cuando se configura MP-BGP, se requiere modificar
la familia-de-direcciones (address-family) que por defecto es IPv4. Lo anterior porque el proceso
BGP de los enrutadores PE ahora tendr que tratar con familias- de-direcciones IPv4 y VPNv4, para
ello se requiere aplicar el comando no bgp default ipv4-unicast bajo el modo de configuracin de
BGP:

R3:

router bgp 101


bgp router-id 150.1.3.3
no bgp default ipv4-unicast
neighbor 192.168.13.2 remote-as 1
!
address-family ipv4 vrf CustB
neighbor 192.168.13.2 remote-as 1
neighbor 192.168.13.2 activate
exit-address-family

R5:

router bgp 101


bgp router-id 150.1.5.5
no bgp default ipv4-unicast
neighbor 192.168.25.2 remote-as 2
neighbor 192.168.58.2 remote-as 8
!
address-family ipv4 vrf CustA
neighbor 192.168.25.2 remote-as 2
neighbor 192.168.25.2 activate
exit-address-family
!
address-family ipv4 vrf CustB
neighbor 192.168.58.2 remote-as 8
neighbor 192.168.58.2 activate
exit-address-family

R6:

router bgp 101


bgp router-id 150.1.6.6
no bgp default ipv4-unicast
neighbor 192.168.67.2 remote-as 7
!
address-family ipv4 vrf CustA
neighbor 192.168.67.2 remote-as 7
neighbor 192.168.67.2 activate
exit-address-family

Como se puede ver, la configuracin anterior es un poco diferente que la configuracin BGP
estndar. En primer lugar, se requiere configurar un vecino (neighbor) bajo la configuracin general
de BGP para establecer la adyacencia con el CE. En segundo lugar, se crea una familia-de-
direcciones IPV4 por cada VRF. Bajo cada familia-de-direcciones, se requiere usar de nuevo el
comando neighbor para configurar el CE como vecino.

Para verificar que R5 (un enrutador PE) est recibiendo informacin de sus vecinos R2 y R8
(enrutadores CE) a travs de BGP, se usa el comando sh ip bgp vpnv4 all:

R5# sh ip bgp vpnv4 all


BGP table version is 4, local router ID is 150.1.5.5
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path


Route Distinguisher: 1:1 (default for vrf CustB)
*> 150.1.8.8/32 192.168.58.2 0 0 8?
*> 172.31.8.0/24 192.168.58.2 0 0 8?
r> 192.168.58.0/30 192.168.58.2 0 0 8?
Route Distinguisher: 2:1 (default for vrf CustA)
*> 150.1.2.2/32 192.168.25.2 0 0 2?
*> 172.31.2.0/24 192.168.25.2 0 0 2?
r> 192.168.25.0/30 192.168.25.2 0 0 2?

De la salida anterior observamos que R5 est recibiendo rutas de los usuarios por medio del
protocolo EBGP y que dichas rutas estn siendo asociadas con los respectivos VRFs previamente
configurados. Mediante el comando sh ip route vrf CustA podemos observar las tablas VRF,
usando al usuario A como ejemplo:
R5# sh ip route vrf CustA

Routing Table: CustA


Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.25.0/30 is subnetted, 1 subnets


C 192.168.25.0 is directly connected, Serial1/0
172.31.0.0/24 is subnetted, 1 subnets
B 172.31.2.0 [20/0] via 192.168.25.2, 00:10:22
150.1.0.0/32 is subnetted, 1 subnets
B 150.1.2.2 [20/0] via 192.168.25.2, 00:10:22

Como se puede ver, dentro del enrutador R5 las redes de cada usuario estn separadas a nivel lgico
de las redes de otros usuarios.

Hasta ahora todo pudo resultar muy bien, pero no ser de mucha utilidad hasta que se logre que las
sucursales de cada usuario del ISP se puedan comunicar mutuamente. Vamos a configurar parejas
VPNv4 (VPNv4 peerings) entre los enrutadores PE con el fin de que entre ellos se intercambien
rutas VPNv4. Para simplificar las cosas, se crear una malla completa full mesh entre todos los
enrutadores PE y de esa manera no habr que preocuparse del reflector de rutas route reflectors
(RR). Para nuestro caso de ejemplo, esto no ser un problema mayor; pero un ISP real
definitivamente tendr que usar reflectores de rutas (RRs). Observe que simplemente por razones de
disponibilidad (o elasticidad ), en la configuracin se est estableciendo la vecindad peering a la
direccin de loopback0 de cada PE:

R3:

router bgp 101


neighbor 150.1.5.5 remote-as 101
neighbor 150.1.5.5 update-source lo0
neighbor 150.1.6.6 remote-as 101
neighbor 150.1.6.6 update-source lo0
!
address-family vpnv4
neighbor 150.1.5.5 activate
neighbor 150.1.5.5 send-community extended
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended
exit-address-family
R5:

router bgp 101


neighbor 150.1.3.3 remote-as 101
neighbor 150.1.3.3 update-source lo0
neighbor 150.1.6.6 remote-as 101
neighbor 150.1.6.6 update-source lo0
!
address-family vpnv4
neighbor 150.1.3.3 activate
neighbor 150.1.3.3 send-community extended
neighbor 150.1.6.6 activate
neighbor 150.1.6.6 send-community extended
exit-address-family

R6:

router bgp 101


neighbor 150.1.3.3 remote-as 101
neighbor 150.1.3.3 update-source lo0
neighbor 150.1.5.5 remote-as 101
neighbor 150.1.5.5 update-source lo0
!
address-family vpnv4
neighbor 150.1.3.3 activate
neighbor 150.1.3.3 send-community extended
neighbor 150.1.5.5 activate
neighbor 150.1.5.5 send-community extended
exit-address-family

Con la configuracin anterior hemos pretendido formar adyacencias entre enrutadores PE y


adicionado la familia-de-direcciones VPNv4. Adems de activar la familia-de-direcciones, nos
debemos asegurar que la configuracin incluya el comando send-community extended. Esto es
debido a que como ya lo anotamos, los RT (route targets) se envan dentro de BGP como una
comunidad extendida. A continuacin tenemos un ejemplo que muestra esto:

R5# sh ip bgp vpnv4 vrf CustB 150.1.1.1


BGP routing table entry for 1:1:150.1.1.1/32, version 13
Paths: (1 available, best #1, table CustB)
Advertised to update-groups:
2
1
150.1.3.3 (metric 3) from 150.1.3.3 (150.1.3.3)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1:1
mpls labels in/out nolabel/21
En este punto, se debe tener completa conectividad extremo-a-extremo (end-to-end) entre las redes
de cada usuario del ISP. En el siguiente ejemplo, podemos ver las redes del sitio AS 1 (R1) que
pertenecen al usuario B, desde la tabla de enrutamiento del sitio AS 8 (R8), sitio que tambin
pertenece al usuario B:

R8# sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

192.168.13.0/30 is subnetted, 1 subnets


B 192.168.13.0 [20/0] via 192.168.58.1, 00:10:21
192.168.58.0/30 is subnetted, 1 subnets
C 192.168.58.0 is directly connected, Serial1/0
172.31.0.0/24 is subnetted, 2 subnets
B 172.31.1.0 [20/0] via 192.168.58.1, 00:10:21
C 172.31.8.0 is directly connected, FastEthernet0/0
150.1.0.0/32 is subnetted, 2 subnets
C 150.1.8.8 is directly connected, Loopback0
B 150.1.1.1 [20/0] via 192.168.58.1, 00:10:21

Este punto concluye nuestra ligera aventura hacia las VPN basadas en MPLS. Se espera que se
haya ganado conocimiento y experiencia slida con esta actividad. En el futuro se pueden explorar
otros aspectos de VPNs basadas en MPLS para ampliar los horizontes. Por ahora, se le invita a
desarrollar el punto 3.

3. Configuracin de acceso a la Internet pblica desde la red VPN MPLS (+).

Modificacin de la Topologa.

A la topologa obtenida despus de finalizar el punto 2 (Desarrollo de una red VPN MPLS ),
adicione el enrutador R9 (con AS 9), el cual se supone representar un ISP o proveedor de acceso a
la Internet pblica de la red MPLS existente. Conecte la interfaz serie S0/0 de R9 con la interfaz
serie S1/3 de R6, como se representa a continuacin.

Loopback0 (10.1.1.1/24)----- | R9 | s0/0---.1-----~~192.168.69.0/30~~-----.2---s1/3 | R6 |

Suponga que la direccin de la Internet Pblica queda representada por la direccin de red de la
interfaz Loopback0 de R9; es decir, por la direccin 10.1.1.0/24.

Adicione en R1 la interfaz Loopback1 con la direccin 192.168.1.1/24, y suponga que la direccin


de la red 192.168.1.0/24 representa el rango de direcciones pblicas asignadas al usuario CustB
para acceder a la Internet Pblica.
Su meta es configurar los equipos que sean necesarios para lograr que el siguiente comando tenga
una respuesta exitosa:

R1# ping 10.1.1.1 source 192.168.1.1

Lo cual comprobara que la red del usuario CustB tiene acceso a la Interner Pblica.

(+). Aunque existen muchas posibles soluciones, una de estas se puede basar en las siguientes
Fuentes Bibliogrficas de referencia o de ayuda para desarrollar el presente punto.

(a) MPLS Fundamentals (Luc De Ghain). Ttulo: <<Internet Access Through the Global Routing
Table with Static Routes>>, pp 239-240.

(b) CCNP ROUTE Lab Manual. Ttulo: <<Step 3: Configure BGP on ISP routers>>, p 269.

References
BGP and MPLS-Based VPNs
RFC 2858 -Multiprotocol Extensions for BGP-4
Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4
Jeff Doyles great blog articles on MPLS topics
Anexo A: los siguientes comandos permiten obtener varias salidas en las diferentes tablas de los
enrutadores involucrados en el procesamiento de un datagrama IP cuando al nodo R3 le llega un
datagrama IP desde la red 172.31.1.0/24 con destino a la red 172.31.8.0/24, dichas salidas
permiten explicar los cambios que sufre el datagrama en los siguientes cuatro pasos.

Paso 1: La entrada correspondiente a la red destino 172.31.8.0/24 en la tabla ip bgp vpnv4 vrf
CustB labels del nodo R3, le adiciona al datagrama IP la etiqueta interna 22, la entrada tambin
indica que el paquete MPLS resultante se debe enviar al LSR 150.1.5.5.

Paso 2: En el nodo R3, la asociacin MPLS con IP indica que si se quiere llegar al LSR
150.1.5.5/32, hay que insertar la etiqueta externa 17 y enviar el paquete MPLS al LSR 150.1.4.4:0.
De alguna manera lo mismo se indica en la tabla MPLS de reenvo del nodo R3.

Paso 3: La tabla MPLS de reenvo del nodo R4 indica que todo paquete MPLS que llegue con
etiqueta 17, se le extrae dicha etiqueta y se reenva al LSR 150.1.5.5/32. Al salir el paquete del nodo
R4, solamente tendr la etiqueta 22.

Paso 4: La tabla MPLS de reenvo del nodo R5 indica que todo paquete MPLS que llegue con
etiqueta 22 se deje sin etiqueta y se enva a la red 172.31.8.0/24[V]. La tabla VRF de CustB en
alguna medida indica lo mismo.

R3# sh ip bgp vpnv4 vrf CustB labels


Network Next Hop In label/Out label
Route Distinguisher: 1:1 (CustB)
150.1.1.1/32 192.168.13.2 24/nolabel
150.1.8.8/32 150.1.5.5 nolabel/21
172.31.1.0/24 192.168.13.2 23/nolabel
172.31.8.0/24 150.1.5.5 nolabel/22 (paso 1)
192.168.13.0/30 192.168.13.2 22/aggregate(CustB)
192.168.58.0/30 150.1.5.5 nolabel/23

R3# sh mpls forwarding-table


Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 150.1.6.6/32 0 Se1/1 point2point
17 Pop tag 150.1.4.4/32 0 Fa2/0 192.168.34.2
18 20 192.168.56.0/30 0 Fa2/0 192.168.34.2
19 Pop tag 192.168.45.0/30 0 Fa2/0 192.168.34.2
20 17 150.1.5.5/32 0 Fa2/0 192.168.34.2
22 Aggregate 192.168.13.0/30[V] \
0
23 Untagged 172.31.1.0/24[V] 0 Se1/0 point2point
24 Untagged 150.1.1.1/32[V] 0 Se1/0 point2point
R3# sh mpls ip binding
. Salida Truncada......
150.1.4.4/32
in label: 17
out label: imp-null lsr: 150.1.4.4:0 inuse
out label: 16 lsr: 150.1.6.6:0
150.1.5.5/32
in label: 20
out label: 17 lsr: 150.1.4.4:0 inuse (paso 2)
out label: 20 lsr: 150.1.6.6:0

. Salida Truncada......

R4# sh mpls forwarding-table


Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 16 150.1.6.6/32 0 Fa2/1 192.168.45.1
16 150.1.6.6/32 267 Fa2/0 192.168.34.1
17 Pop tag 150.1.5.5/32 3937 Fa2/1 192.168.45.1 (paso3)
18 Pop tag 150.1.3.3/32 3668 Fa2/0 192.168.34.1
19 Pop tag 192.168.36.0/30 0 Fa2/0 192.168.34.1
20 Pop tag 192.168.56.0/30 0 Fa2/1 192.168.45.1

R6# sh ip bgp vpnv4 vrf CustA labels


Network Next Hop In label/Out label
Route Distinguisher: 2:1 (CustA)
150.1.2.2/32 150.1.5.5 nolabel/24
150.1.7.7/32 192.168.67.2 26/nolabel
172.31.2.0/24 150.1.5.5 nolabel/25
172.31.7.0/24 192.168.67.2 25/nolabel
192.168.25.0/30 150.1.5.5 nolabel/26
192.168.67.0/30 192.168.67.2 24/aggregate(CustA)

R6# sh mpls forwarding-table


Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 17 150.1.4.4/32 0 Se1/1 point2point
17 150.1.4.4/32 0 Se1/0 point2point
17 Pop tag 150.1.3.3/32 0 Se1/0 point2point
18 Pop tag 192.168.45.0/30 0 Se1/1 point2point
19 Pop tag 192.168.34.0/30 0 Se1/0 point2point
20 Pop tag 150.1.5.5/32 0 Se1/1 point2point
24 Aggregate 192.168.67.0/30[V] \
0
25 Untagged 172.31.7.0/24[V] 0 Se1/2 point2point
26 Untagged 150.1.7.7/32[V] 0 Se1/2 point2point
R5# sh ip bgp vpnv4 vrf CustB labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1 (CustB)
150.1.1.1/32 150.1.3.3 nolabel/24
150.1.8.8/32 192.168.58.2 21/nolabel
172.31.1.0/24 150.1.3.3 nolabel/23
172.31.8.0/24 192.168.58.2 22/nolabel (paso 4)
192.168.13.0/30 150.1.3.3 nolabel/22
192.168.58.0/30 192.168.58.2 23/aggregate(CustB)

R5# sh ip bgp vpnv4 vrf CustA labels


Network Next Hop In label/Out label
Route Distinguisher: 2:1 (CustA)
150.1.2.2/32 192.168.25.2 24/nolabel
150.1.7.7/32 150.1.6.6 nolabel/26
172.31.2.0/24 192.168.25.2 25/nolabel
172.31.7.0/24 150.1.6.6 nolabel/25
192.168.25.0/30 192.168.25.2 26/aggregate(CustA)
192.168.67.0/30 150.1.6.6 nolabel/24

R5# sh mpls forwarding-table


Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 150.1.6.6/32 0 Se1/1 point2point
17 Pop tag 150.1.4.4/32 0 Fa2/0 192.168.45.2
18 18 150.1.3.3/32 139 Fa2/0 192.168.45.2
19 19 192.168.36.0/30 0 Fa2/0 192.168.45.2
20 Pop tag 192.168.34.0/30 0 Fa2/0 192.168.45.2
21 Untagged 150.1.8.8/32[V] 0 Se1/2 point2point
22 Untagged 172.31.8.0/24[V] 0 Se1/2 point2point (paso 4)
23 Aggregate 192.168.58.0/30[V] \
0
24 Untagged 150.1.2.2/32[V] 0 Se1/0 point2point
25 Untagged 172.31.2.0/24[V] 0 Se1/0 point2point
26 Aggregate 192.168.25.0/30[V] \
0
# Basic MPLS Topology

autostart = False
ghostios = True

[localhost]

[[7200]]
image = \Program Files\Dynamips\images\C7200-SP.BIN
npe = npe-400
ram = 160

[[ROUTER R3]]
s1/1 = R6 s1/0
fa2/0 = R4 fa2/0
model = 7200

[[ROUTER R4]]
fa2/1 = R5 fa2/0
model = 7200

[localhost:7201]
udp = 11000

[[7200]]
image = \Program Files\Dynamips\images\C7200-SP.BIN
npe = npe-400
ram = 160

[[ROUTER R5]]
s1/1 = R6 s1/1
model = 7200

[[ROUTER R6]]
model = 7200
# MPLS VPN Topology

autostart = False
ghostios = True

[localhost]

[[7200]]
image = \Program Files\Dynamips\images\C7200-SP.BIN
npe = npe-400
ram = 160

[[ROUTER R1]]
fa0/0 = S1 1
s1/0 = R3 s1/0
model = 7200

[[ROUTER R2]]
s1/0 = R5 s1/0
fa0/0 = S1 2
model = 7200

[[ROUTER R3]]
s1/1 = R6 s1/0
fa2/0 = R4 fa2/0
model = 7200

[[ROUTER R4]]
fa2/1 = R5 fa2/0
model = 7200

[localhost:7201]
udp = 11000

[[7200]]
image = \Program Files\Dynamips\images\C7200-SP.BIN
npe = npe-400
ram = 160

[[ROUTER R5]]
s1/1 = R6 s1/1
s1/2 = R8 s1/0
model = 7200

[[ROUTER R6]]
s1/2 = R7 s1/0
model = 7200

[[ROUTER R7]]
fa0/0 = S1 7
model = 7200

[[ROUTER R8]]
fa0/0 = S1 8
model = 7200

[[ETHSW S1]]
1 = access 1
2 = access 2
7 = access 7
8 = access 8

Você também pode gostar