AMPLIACIÓN DE REDES PRÁCTICA 1: FRAME RELAY Y ...

AMPLIACIÓN DE REDES
PRÁCTICA 1: FRAME RELAY Y CONTROL DE TRÁFICO
1.- Descripción general
Autores: Santiago Felici
Hipólito Alós
Rogelio Montañana
En esta práctica se pretende que los alumnos se familiaricen con la configuración y funcionamiento de
una red con conexiones WAN con tecnología Frame Relay que interconecta una serie de LANs mediante
la modalidad de tramas enrutadas. Los alumnos trabajarán con un emulador de conexiones Frame Relay
al que conectarán tres routers formando topologías en froma de malla y de estrella. Los routers, que
soportan el protocolo IP, se comunicarán entre ellos mediante circuitos virtuales permanentes o PVCs
(Permanent Virtual Circuits) y utilizarán el protocolo de enrutamiento EIGRP propietario de Cisco
Systems para intercambiar información de rutas . Los alumnos probarán diferentes aspectos, como el
protocolo de gestión LMI (Link Management Interface), control de tráfico y el funcionamiento del
enrutamiento con balanceo de tráfico entre rutas de diferente distancia o métrica.
Material requerido para la práctica:
1. Tres routers Cisco con una interfaz LAN tipo Ethernet y una WAN (enlaces series síncronos),
con sistema operativo IOS versión superior a 11.2 de Cisco Systems
2. Un emulador de conexiones WAN marca Adtran modelo Atlas 550.
3. Tres ordenadores con conexión de red y puerto serie, con programa de emulación de terminal
para realizar conexiones de consola a los equipos
4. Tres latiguillos Ethernet RJ45 cruzados
5. Tres cables de consola planos negros con conectores RJ-45 en los extremos. Los ordenadores
deberán tener instalados adaptadoresde RJ-45 a DB-9 en el puerto COM1
6. Tres cables serie con conector ‘Smart Serial’ en el lado del router y conector ‘Winchester’
macho (intefaz V.35 estándar) en el lado del emulador Frame Relay.
Descripción del emulador WAN Adtran modelo Atlas 550.
El emulador Adtran Atlas 550 (figuras 1 y 2) es un equipo que emula conexiones de líneas analógicas y
RDSI (con interfaces básicos), así como interfaces síncronas V.35 para conexiones Frame Relay. Estas
últimas, que son las únicas que nos interesan en esta práctica, aparecen en la parte trasera como un
conjunto de cuatro conectores Winchester (V.35) numerados 1/1, 1/2, 2/1 y 2/2. El equipo se entrega a
los alumnos preconfigurado con los tres PVCs bidireccionales que se indican en la tabla 1.
Figura 1. Vista frontal del Adtran Atlas 550
P1-1

1/1 1/2
2/1 2/2
Práctica 1: Frame Relay y Control de Tráfico
Figura 2. Vista trasera del Adtran Atlas 550
Puerto entrante DLCI entrante Puerto saliente DLCI saliente
1/1 (Valencia) 102 1/2 (Alicante) 201
1/1 (Valencia) 103 2/1 (Castellón) 301
1/1 (Valencia 104 2/2 (Vacío) 401
1/2 (Alicante) 201 1/1 (Valencia) 102
1/2 (Alicante) 203 2/1 (Castellón) 302
2/1 (Castellón) 302 1/2 (Alicante) 203
2/1 (Castellón) 301 1/1 (Valencia) 103
2/2 (Vacío) 401 1/1 (Valencia) 104
Tabla 1.- PVCs que tiene configurado el Adtran Atlas 550
Los DLCIs pueden estar entre 0 y 1023. Los valores utilizables son del 16 al 992 ya que el resto está
reservado para funciones especiales.
Descripción de los routers
Los routers que se utilizan en esta práctica son Cisco modelo 1721 basados en un procesador RISC de
alto rendimiento (ver figura 4). Todos tienen instalado el IOS versión 12. Estos routers dejaron de
fabricarse en agosto de 2003. Tienen de fábrica una interfaz Fast Ethernet 10/100 BASE-T. Además
incorporan dos ranuras de expansión para WICs, WIC 0 y WIC 1 (WIC = WAN Interface Card).
Instalando las WIC adecuadas este router permite incorporar interfaces RDSI, ADSL, o funciones de
encriptación por hardware para túneles VPN, por ejemplo. En nuestro caso sólo está ocupada la primera
ranura (WIC 0) que tiene un módulo denominado 2A/S que incorpora dos interfaces serie de baja
velocidad (hasta 128 Kbps). Las interfaces serie tienen un conector propietario multinorma denominado
Smart Serial que combina él solo las señales correspondientes a varias interfaces estándar (V.35, RS-232,
RS-449, X.21 y RS-530). En función del tipo de cable utilizado se eligen unas u otras señales. Nosotros
utilizaremos los cables que corresponden a la interfaz V.35, que es la más habitual (ver figura 3). A
efectos de configuración del equipo la interfaz Fast Ethernet se denomina ‘FastEthernet 0’ y las dos
interfaces serie del WIC 0, ‘Serial 0’ y ‘Serial 1’. Nosotros solo utilizaremos la Fast Ethernet y la Serial
0. Los routers disponen además de un puerto consola (CONSOLE) con conector RJ45. En la figura 4 se
muestra una vista frontal y trasera de un 1721, así como un esquema de la parte trasera de un router
configurado con un WIC, como los que se utilizan en esta práctica.
Conector Smart Serial
Conector Winchester
Macho (DTE)
Figura 3. Cable serie V.35 DTE de un router Cisco 1721
P2-2

Interfaz
Serial 1
Interfaz
Serial 0
Práctica 1: Frame Relay y Control de Tráfico
WIC 0
(2A/S)
LED
WIC 0
OK
Figura 4. Vista frontal, trasera y esquema de un router Cisco 1721
2.- Desarrollo de la práctica
LEDs
FDX/100/LIN
Interfaz Fast
Ethernet 0
(10/100 BASE-T)
La práctica simula el establecimiento de una red formada por tres sucursales en Valencia, Alicante y
Castellón, ubicando en cada una de ellas un router de forma que los tres quedan enlazados por
conexiones Frame Relay contratadas a una operadora. La red Frame Relay de la operadora es sustituida
en la práctica por el Adtran Atlas 550.
La práctica consta de una serie de pasos que vamos a enumerar a continuación.
Paso 1: Interconexión física de los equipos
K
Puerto
Consola
WIC 1
(vacío)
LED
Módulo
OK
Interruptor
Enchufe
fuente
alimentación
En esta parte los alumnos realizan las conexiones de cables necesarias para la práctica. La interconexión
de los equipos se muestra en la figura 4. Todos los equipos deberán estar apagados en el momento de
proceder a conectarlos.
P2-3

Valencia
Fast
Ethernet 0
Fast
Ethernet 0
Castellón
Práctica 1: Frame Relay y Control de Tráfico
Figura 4: Esquema de las conexiones de la práctica.
El Adtran tiene configurados los PVCs indicados en la Tabla 1, de forma que permite a cada router
comunicar directamente con los otros dos.
Conexiones de consola (RS-232)
Cada ordenador debe actuar de consola de su router. Para la conexión debemos utilizar un cable negro
plano con dos conectores RJ-45 que no suministrará el profesor (para esta conexión no debemos utilizar
un latiguillo Ethernet normal ni cruzado). El cable se conectará mediante un adaptador DB-9 al puerto
serie (COM1) del ordenador y al puerto CONSOLE del router (conector RJ45).
Conexiones Ethernet en cable UTP
Serial 0
Serial 0
Como solo vamos a conectar un ordenador a la interfaz Fast Ethernet del router utilizaremos un latiguillo
UTP cruzado que nos suministrará el profesor. El latiguillo paralelo (no cruzado) que conecta el
ordenador a la roseta de la pared lo descoenctaremos del ordenador y lo dejaremos conectado a la roseta.
Conexiones serie en cable V.35-Smart Serial
1/1
2/1
Las conexiones serie V.35 estan ya preparadas tanto en el Adtran como en los routers.
En esta práctica el Adtran desempeña la función de DCE, es decir dicta la señal de reloj a los routers. El
Adtran está configurado con una señal de reloj de 64 Kb/s en todas sus interfaces.
Encendido de los equipos y comprobación de las conexiones
Ahora procederemos a encender los equipos y comprobar que son correctas las conexiones.
En primer lugar encenderemos los ordenadores. Cuando termina el arranque de la BIOS aparece un menú
para elegir el sistema operativo; allí seleccionaremos la opción ‘linux redes’ que corresponde (a pesar de
1/2
2/2
Serial 0
Fast
Ethernet 0
Alicante
P2-4

Práctica 1: Frame Relay y Control de Tráfico
su nombre) a una instalación de linux capaz de funcionar sin conexión a la red de la Universidad, que es
como se desarrolla esta práctica.
Una vez arrancado el sistema operativo entraremos con el usuario root y la password que nos indique el
profesor.
Ahora en el ordenador abriremos una ventana del intérprete de comandos shell y pondremos en marcha en
ella el programa de emulación de terminal minicom mediante el comando ‘minicom –s’, pulsando a
continuación la tecla escape. En caso de que la conexión no funcione o tenga algún problema deberemos
comprobar los parámetros de configuración del minicom, para lo cual procedemos de la siguiente forma:
Tecleamos ‘CTRL/A’ seguido de ‘Z’ para entrar en los comandos del minicom. Tecleamos ‘O’ para
elegir configuración. De las opciones que aparecen elegimos ‘Serial port setup’. Los parámetros que
aparecen deben tener los siguientes valores:
? Dispositivo de entrada: /dev/ttyS0
? Velocidad 9600 bits/s
? 8 bits de datos, un bit de parada, sin paridad (8N1)
? Control de flujo: ninguno
(El uso del dispositivo ttyS0 se debe a que estamos utilizando la interfaz COM1 del ordenador.)
A continuación encenderemos el Adtran. El Adtran tarda algo menos de un minuto en inicializarse,
cargar el software y la configuración. Al final del proceso las luces que deben quedar encendidas son las
siguientes:
? Parte izqueirda: POWER y SYSTEM en verde permanente
? Columna NETWORK 1: ERROR, rojo intermitente. ALARM, rojo permanente. Esto es normal
ya que corresponde a las interfaces RDSI que no están conectadas
? Módulo 1: STATUS y ONLINE en verde permanente
? Módulo 2: STATUS y ONLINE en verde permanente
? Módulo 3: STATUS en verde permanente
? Módulo 4: STATUS en rojo permanente, ONLINE en verde permanente
Con el programa minicom en marcha procederemos a encender el router. Veremos entonces aparecer por
consola la secuencia de mensajes de carga del software IOS (Internetwork Operating System) que es algo
similar a lo siguiente:
System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
(varios mensajes omitidos)
(al cabo de un minuto aproximadamente...)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
Press RETURN to get started! (RETURN)
Router>
Una vez obtenemos el prompt ‘>’ podemos teclear comandos de IOS. Para familiarizarnos con el
funcionamiento del IOS podemos consultar el apéndice I.
P2-5

Práctica 1: Frame Relay y Control de Tráfico
Normalmente los routers deben tener en memoria NVRAM una configuración por defecto que cargan en
memoria RAM al arrancar Si por alguna razón se hubiera perdido dicha configuración el router no
cargará ninguna y nos aparecerá en consola el ‘System Configuration Dialog’. En este caso deberemos
restaurar la configuración por defecto siguiendo el procedimiento que se explica en el apéndice II.
Paso 3: Asignación de direcciones IP de las LANs
La asignación de direcciones IP en las LAN se hará según se indica en la Tabla 2:
Ubicación Red Máscara IP Router (Ethernet 0) IP Host (eth0)
Valencia 192.168.1.0 255.255.255.0 192.168.1.1 192.168.1.2
Alicante 192.168.2.0 255.255.255.0 192.168.2.1 192.168.2.2
Castellón 192.168.3.0 255.255.255.0 192.168.3.1 192.168.3.2
Paso 4: Configuración IP de los hosts
Tabla 2.- Asignación de direcciones IP a las LANs
En este paso los alumnos deben configurar en su host la dirección IP y la ruta por defecto.
Para asignar la dirección IP utilizaremos el comando UNIX ‘ifconfig eth0 inet dirección_IP netmask
máscara’ (este comando lo teclearemos en una ventana de shell, no en la ventana minicom). Para
comprobar que la asignación se ha efectuado correctamente ejecutaremos el comando ’ifconfig eth0’.
Para introducir la ruta por defecto utilizaremos el comando ‘route add default gw dirección_IP’,
poniendo como dirección IP la de la interfaz Fast Ethernet correspondiente al router al que se conecta ese
host. Para comprobar que la definición se ha hecho correctamente utilizaremos el comando ‘route –n’.
Algunos comandos linux cuando se utilizan direcciones IP intentan realizar la resolución inversa de las
direcciones en el DNS, para averiguar el nombre correspondiente. En algunos comandos (por ejemplo
‘ping’, ‘route’ o ‘traceroute’) esto puede evitarse con la opción ‘–n’, pero en otros comandos como
‘telnet’ no existe esta opción, por lo que es necesario esperar a que expire el timeout del DNS (unos 30
segundos aproximadamente). Para evitar este retardo cuando utilicemos el comando telnet cambiaremos
de nombre el fichero resolv.conf en el directorio /etc mediante el comando ‘mv /etc/resolv.conf
/etc/resolv.conf.old’. De esta forma evitamos la consulta al DNS y por tanto la espera (si no existe dicho
fichero no tendremos este problema por lo que podremos seguir sin mas). Podemos prescindir entonces de
la opción ‘–n’ en los comandos ‘ping’, ‘route’ o ‘traceroute’.
Paso 5: Configuración de los routers en red multiacceso
En esta práctica probaremos diversas formas de realizar las conexiones entre los routers a través de la red
Frame Relay, simulada en este caso por el Adtran.
En primer lugar configuraremos las interfaces serie de los routers en una red multiacceso, de forma que
las tres interfaces formen parte de una misma subred y cualquier router pueda hablar directamente con
los otros dos. Esto es posible ya que el Adtran tiene configurados tres PVCs que conectan los tres routers
entre sí. Lo que vamos a hacer a continuación es un ejemplo de las denominadas redes NBMA (Non
Broadcast Multi Access), que significa que hay conectividad directa (a un salto de distancia) entre dos
routers cualesquiera, pero el medio no es broadcast, de forma que si queremos hacer un envío broadcast
tenemos que generar una copia del datagrama para cada destinatario, en este caso una copia diferente por
cada PVC.
Para las interfaces serie utilizaremos la red 192.168.10.0/29. Al ser una red /29 nos suministra seis
direcciones útiles (de la 1 a la 6) de las que únicamente utilizaremos las tres primeras (con una red /30
habríamos obtenido sólo dos direcciones útiles, lo cual habría resultado insuficiente). La asignación de
direcciones se hará según se detalla en la siguiente tabla:
Ubicación Dirección IP Máscara
Valencia 192.168.10.1 255.255.255.248
P2-6

Práctica 1: Frame Relay y Control de Tráfico
Alicante 192.168.10.2 255.255.255.248
Castellón 192.168.10.3 255.255.255.248
Tabla 3. Asignación de direcciones IP a las interfaces serie de los routers
Esta topología se muestra de forma esquemática en la Figura 5.
Castellón
192.168.10.3/29
S0
192.168.10.1/29
S0
Valencia
192.168.10.2/29
S0
Alicante
Figura 5. Topología de la red Frame Relay en configuración multipunto (NBMA)
Ahora procederemos a introducir la configuración en los routers utilizando los comandos de IOS
pertinentes. Para ello introduciremos las direcciones IP y máscaras de las dos interfaces (Fast Ethernet 0
y Serial 0) indicando en la interfaz serie que deseamos encapsulado Frame Relay.
Además definiremos el protocolo de routing EIGRP en el sistema autónomo 65000 mediante el comando
‘ROUTER EIgrp 65000’. En el modo Configuración de routing declaramos mediante comandos
‘NETwork’ las dos redes que conoce el router, que son las que corresponden a sus dos interfaces, Fast
Ethernet 0 y Serial 0.
A modo de ejemplo mostramos a continuación cual sería la configuración del router de Valencia y como
se introduciría. En los otros routers la única diferencia serían las direcciones en el comando ‘Ip
ADdress’ para las interfaces y el ‘NETwork’ correspondiente en la ‘ROUTER EIgrp’:
Router>ENable
Router#CONFigure Terminal
Router(config)#HOstname Valencia
Valencia(config)#NO IP DOMAIN-LOokup
Valencia(config)#IP SUbnet-zero
Valencia(config)#IP Classless
Valencia(config)#Interface Fastethernet 0
Valencia(config-if)#Ip ADdress 192.168.1.1 255.255.255.0
Valencia(config-if)#NO SHutdown
Valencia(config-if)#Interface Serial 0
Valencia(config-if)#Ip ADdress 192.168.10.1 255.255.255.248
Valencia(config-if)#ENcapsulation Frame-relay
Valencia(config-if)#Frame-relay INVerse-arp INterval 15
Valencia(config-if)#NO SHutdown
Valencia(config-if)#Exit
P2-7

Práctica 1: Frame Relay y Control de Tráfico
Valencia(config)#ROUTER EIgrp 65000
Valencia(config-router)#NETwork 192.168.1.0
Valencia(config-router)#NETwork 192.168.10.0
Valencia(config-router)#EXit
Valencia(config)#LIne Vty 0 4
Valencia(config-line)#PASsword genios
Valencia(config-line)#EXIt
Valencia(config)#EXIt
Valencia#
El comando ’NO IP DOMAIN-LOokup’ sirve para evitar las búsquedas en el DNS, que no existe en
esta red experimental.
El comando ‘IP SUbnet-zero’ indica que al hacer subredes queremos disponer de la primera y la
última subredes. El comando ‘IP Classless’ significa que el router permitirá cualquier máscara en
cualquier rango de direcciones unicast, si bien por defecto seguirá realizando la interpretación tradicional
de clases A, B y C. Estos dos comandos están por defecto en el IOS versión 12, que es el que estamos
utilizando, por lo que a partir de ahora no los pondremos.
El comando ’ENcapsulation Frame-relay’ le al router indica que esa interfaz serie está
conectada a una red Frame Relay, para que utilice el formato de trama adecuado. Además mediante un
parámetro opcional que puede ser ‘Ietf’ o ‘Cisco’ (por defecto se supone ‘Cisco’) se le indica
cual de los dos formatos de encapsulado posibles se utilizará. Como nosotros no hemos indicado este
parámetro se utilizará el formato propietario de Cisco. Si en la red hubiera routers de otros fabricantes
deberíamos utilizar el fo rmato estándar, especificado en el RFC1490, especificando el encapsulado IETF
(’ENcapsulation Frame-relay Ietf’). Puesto que este es un parámetro que se especifica a
nivel de la interfaz el formato de trama debe ser el mismo en todos los routers con los que se establecen
conexiones a través de esta interfaz.
El comando ‘Frame-relay INVerse-arp INterval 15’ sirve para reducir el intervalo de
tiempo entre mensajes Inverse ARP que envían los routers, de forma que no tengamos que esperar tanto
tiempo en las pruebas que realziaremos durante la práctica
Los comandos ‘LIne Vty 0 4’ y ‘PASsword genios’ nos permiten el acceso vía telnet al
router en modo Usuario. De esta forma los compañeros desde otros hosts podrán ejecutar si lo desean
algunos comandos en nuestro router, pero no podrán acceder al modo Privilegiado y por tanto no podrán
modificar nuestra configuración, ya que no hemos configuradouna password de enable.
En este momento la interfaz Fast Ethernet ya deberá estar ya operativa (FastEthernet 0 is up,
line protocol is up) y debe responder a los pings. Es posible que la interfaz Serie aun no
responda a los pings. Ahora utilizaremos el comando ‘Show INterfaces’ para obtener un resumen
informativo de las características de las interfaces. El comando ‘Show INterfaces’ nos muestra un
resumen de las caracterísiticas a nivel físico y de enlace de cada interfaz, por ejemplo el ancho de banda,
retardo, tipo de encapsulado, funciones LMI disponibles, etc. Resulta interesante comparar los valores de
esos parámetros en la interfaz Fast Ethernet y la Serie. También nos muestra una serie contadores de
tráfico enviado, recibido, errores detectados y otras situaciones excecpionales. Si lanzamos un ping desde
el host a la interfaz Fast Ethernet del router podremos ver como esos contadores se incrementan
paulatinamente. Se puede hacer show de una interfaz específica, por ejemplo para ver el estado y las
características de la interfaz Serial 0:
Valencia#Show INterface Serial 0
Serial0 is up, line protocol is up
Hardware is PowerQUICC Serial
Internet address is 192.168.10.1/29
MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY, loopback not set
Keepalive set (10 sec)
!
P2-8

Práctica 1: Frame Relay y Control de Tráfico
Toda la salida generada por el comando ‘Show INterfaces’ se encuentra explicada en el apéndice
III
Paso 6: Uso de comandos de IOS relacionados con Frame Relay y prueba de la
configuración
Frame Relay dispone de un conjunto de funciones avanzadas denominado LMI (Link Management
Interface), que permiten flexibilizar y simplificar la configuración. Los routers Cisco soportan tres tipos
de LMI: el ANSI T 1.617 Annex D, el ITU-T Q.933 Annex A y uno propietario de Cisco. El Adtran está
configurado con el tipo ANSI. Para un correcto funcionamiento de LMI los routers deben utilizar el
mismo tipo que el conmutador Frame Relay al que están conectados. Desde el IOS 11.2 los routers al
inicializar su interfaz serie detectan el tipo de LMI utilizado por la red y se adaptan automáticamente. Por
tanto en este caso los routers deben haber elegido el tipo ANSI. Esto lo podemos comprobar mediante el
comando ‘Show FRAMe-relay Lmi’:
Valencia#Show FRAMe-relay Lmi
LMI Statistics for interface Serial0 (Frame Relay DTE) LMI TYPE = ANSI
Invalid Unnumbered info 0 Invalid Prot Disc 0
Invalid dummy Call Ref 0 Invalid Msg Type 0
Invalid Status Message 0 Invalid Lock Shift 0
Invalid Information ID 0 Invalid Report IE Len 0
Invalid Report Request 0 Invalid Keep IE Len 0
Num Status Enq. Sent 2523 Num Status msgs Rcvd 2522
Num Update Status Rcvd 0 Num Status Timeouts 7
Si tuviéramos un router con IOS anterior a 11.2 habría sido necesario especificar el tipo de LMI en la
configuración de la interfaz serie mediante el comando ‘FRAMe-relay Lmi-type Ansi’.
El intercambio de información necesario para desarrollar las funciones LMI se se realiza a través de un
PVC que se establece entre el Adtran y el router en el momento de conectarlos. Este PVC utiliza un
número de DLCI reservado. En cierto modo LMI desempeña en Frame Relay una función equivalente a
la que realiza ILMI en ATM.
A los routers no les hemos puesto en la configuración ninguna información sobre los PVCs existentes, ni
sobre sus números de DLCI. Estos datos los obtienen del Adtran mediante mensajes LMI. Podemos
comporbar que los routers han ‘descubierto’ esa información mediante el comando ‘Show FRAMerelay
Pvc’:
Castellon#Show FRAMe-relay Pvc
PVC Statistics for interface Serial0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 2 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 301, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 676 output pkts 470 in bytes 92211
out bytes 86466 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 372 out bcast bytes 76274
pvc create time 03:32:04, last time pvc status changed 03:32:04
DLCI = 302, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0
input pkts 433 output pkts 436 in bytes 81309
out bytes 82942 dropped pkts 0 in FECN pkts 0
in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
P2-9

Práctica 1: Frame Relay y Control de Tráfico
in DE pkts 0 out DE pkts 0
out bcast pkts 371 out bcast bytes 76182
pvc create time 03:32:05, last time pvc status changed 03:32:05
En la información de DLCIs que aparece el estado activo (PVC STATUS = ACTIVE) indica que hay
conexión extremo a extremo a través de ese PVC, es decir conexión DTE-DTE con el router del otro lado
del PVC. Si el router del otro extremo no está operativo solo habrá comunicación con el Adtran
(conexión DTE-DCE); en ese caso el DLCI correspondiente aparece en estado inactivo (PVC STATUS
= INACTIVE).
Una vez identificados los PVCs existentes, los routers envían mensajes Inverse ARP por ellos con el fin
de averiguar las direcciones IP del otro extremo. Podemos ver por consola cuando se intercambian los
mensajes Inverse ARP si activamos el debug de Frame Relay con el comando en modo Privilegiado
‘DEBug FRame-relay EVents’ (para desactivarlo debemos utilizar el comando en modo
Privilegiado ‘NO DEBug ALL’). Una vez se han obtenido las respuestas a los mensajes Inverse ARP
los routers pueden completar el mapa de equivalencias entre DLCIs y direcciones IP. Podemos averiguar
esta equivalencia mediante el comando ‘Show FRAMe-relay Map’:
Castellon#Show FRAMe-relay Map
Serial0 (up): ip 192.168.10.1 dlci 301(0x10,0x400), dynamic,
broadcast,, status defined, active
Serial0 (up): ip 192.168.10.2 dlci 302(0x11,0x410), dynamic,
broadcast,, status defined, active
El atributo ‘dynamic’, que aparece asociado a las direcciones IP, nos indica que estas han sido obtenidas
por medio de Inverse ARP. Cabe destacar también el atributo ‘broadcast’ que indica que el circuito
virtual correspondiente permite el envío de paquetes broadcast o multicast. Este tipo de envíos a
direcciones de grupo lo utilizan, entre otros, los protocolos de routing unicast.
El Inverse ARP es un protocolo similar a ARP y RARP, salvo que en vez de hacer envíos broadcast
manda un mensaje unicast por cada PVC preguntando quien está al otro lado. En este caso en vez de la
dirección MAC se asocia el número de DLCI con la dirección IP. Desde el punto de vista del router los
DLCIs identifican los diferentes PVCs que tiene establecidos, por cada uno de los cuales accede a una
dirección IP diferente en el otro extremo.
El proceso de envío de mensajes LMI y posteriormente de mensajes Inverse ARP puede tardar unos
minutos. El proceso termina cuando vemos aparecer las direcciones de los routers remotos en el comando
‘Show FRAMe-relay Map’. En caso de que después de unos cinco minutos no aparezcan las
entradas previstas deberemos proceder a comprobar la configuración y si aun así no funciona
reinciaremos la interfaz serie del router mediante el comando ’SHutdown’ seguido de ’NO
SHutdown’ (ambos comandos se deben ejecutar en modo Configuración de Interfaz). Si así tampoco
reiniciaremos el Adtran y si así tampoco funciona pediremos ayuda al profesor.
Con la información mostrada en los tres routers por el comando ‘Show FRAMe-relay Map’ los
alumnos deben identificar los DLCI existentes en cada uno y anotarlos en la tabla 4 (además de obtener
la información de su router cada equipo hará telnet a los otros dos en modo Usuario para obtener la
información correspondiente). Además deberán comprobar que los DLCIs se corresponden con las
direcciones IP de los routers y comprobar que la información así obtenida es coherente con la mostrada
en la Tabla 1.
Origen -> Valencia
Destino
Alicante Castellón
Valencia -
Alicante -
Castellón -
Tabla 4. Relación de DLCI origen-destino
P2-10

Práctica 1: Frame Relay y Control de Tráfico
Si la configuración se ha introducido correctamente y ya vemos las direcciones IP remotas en el comando
‘Show FRAMe-relay Map’ entonces ya debe ser posible comunicar (por ejemplo con un ‘ping’)
con los demás routers de la red, tanto a sus interfaces Serie como a las Fast Ethernet utilizando las
direcciones IP adecuadas. También debe ser posible hacer ‘ping’ o ‘traceroute’ desde los hosts a los
routers y a los otros hosts. Si alguna de estas pruebas no funciona deberemos localizar el problema
haciendo ping a las direcciones IP intermedias y analizando a partir de qué punto se interrumpe la
comunicación. Al tratarse de conexiones multipunto es normal que la dirección IP de nuestra propia
interfaz serie no nos responda a los pings, por ejemplo no funcionará un ping desde Valencia a la
dirección 192.168.10.1. Esto comportamiento aparentemente extraño se debe a que la dirección IP de la
interfaz serie del propio router no está ‘mapeada’ con ningún DLCI (no aparece listada en el ‘Show
FRAMe-relay Map’) y por tanto no sabe por donde enviar el paquete ICMP. En una línea punto a
punto la propia interfaz serie sí que responde a los pings, pero en ese caso el paquete ICMP va al router
remoto y éste, al ver la dirección de destino, lo devuelve al router de donde vino. Es decir, en realidad el
ping en una línea serie funciona gracias a la función de loopback que realiza el router remoto (por eso si
desconectamos el router remoto el ping a nuestra interfaz serie deja de funcionar).
Podemos también probar a hacer un ping a la dirección broadcast de la red de las interfaces serie desde el
propio router (comando ‘Ping dirección_IP’) y veremos como nos responden únicamente las
interfaces serie de los routers remotos, no la nuestra.
Ahora el alumno debe completar la información que falta en la Figura 6.
IP interface
Fa0:
192.168.3.1
Castellón
IP: 192.168.3.2
IP interface S0:
192.168.____._
_
Valencia
IP interface S0:
192.168.____._
_
Frame Relay
Figura 6. Completa: 1º) las IPs de tu interface 2º) los mapas frame-relay de tu router
3º·) haz telnet a los otros routers y completa el resto de datos.
En los routers también podemos utilizar el comando ping extendido, que nos permite introducir una serie
de parámetros adicionales (por ejemplo pedir que se registre la ruta). Para utilizar el ping extendido hay
que teclear simplemente el comando ‘Ping’, sin argumentos; a continuación el router nos va pidiendo
los diferentes parámetros. Por ejemplo:
Valencia#Ping
Protocol [ip]: (RETURN)
Target IP address: 192.168.10.2
Repeat count [5]: 1
Datagram size [100]: (RETURN)
Timeout in seconds [2]: (RETURN)
Extended commands [n]: Yes
Source address or interface: 192.168.1.1
IP interface
Fa0:
IP: 192.168.1.2
IP interface S0:
192.168.____._
_
Alicante
IP interface
Fa0:
192.168.2.1
IP: 192.168.2.2
P2-11

Práctica 1: Frame Relay y Control de Tráfico
Type of service [0]: (RETURN)
Set DF bit in IP header? [no]: (RETURN)
Validate reply data? [no]: (RETURN)
Data pattern [0xABCD]: (RETURN)
Loose, Strict, Record, Timestamp, Verbose[none]:Record
Number of hops [ 9 ]: (RETURN)
Loose, Strict, Record, Timestamp, Verbose[RV]: (RETURN)
Sweep range of sizes [n]: (RETURN)
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.10.2, timeout is 2 seconds:
Packet has IP options: Total option bytes= 39, padded length=40
Record route:
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
Reply to request 0 (8 ms). Received packet has options
Total option bytes= 40, padded length=40
Record route:
(192.168.1.1)
(192.168.10.2)
(192.168.10.2)
(192.168.1.1) )
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
(0.0.0.0)
End of list
Success rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms
Valencia#
En este ejemplo se ha enviado un paquete de 100 bytes a la dirección 192.168.10.2 y se ha pedido
registrar la ruta seguida a la ida y a la vuelta por medio de la opción ‘record route’ en la cabecera de los
paquetes, función equivalente al ‘ping –R’ de linux. Además el paquete se ha enviado poniendo como
dirección de origen la 192.168.1.1. Normalmente el router pone como dirección de origen la de la
interfaz por la que sale el paquete, pero con el ping extendido es posible fijar como dirección de origen la
de cualquiera de las interfaces que el router tiene operativas en ese momento. Esta función es
especialmente útil cuando se trata de determinar problemas que tienen que ver con el routing.
Una vez hayamos conseguido el correcto funcionamiento de la red podemos probar el comando ‘Show
IP INterface Brief’, que nos muestra un resumen de la situación de cada interfaz del equipo en
relación con su configuración IP.
Otro comando interesante es el ‘Show IP ROute’, que nos muestra la tabla de rutas activa. Lo que
aparece por pantalla es similar a lo siguiente:
Alicante#Show IP ROute
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
P2-12

Práctica 1: Frame Relay y Control de Tráfico
C 192.168.10.0/29 is directly connected, Serial0
D 192.168.1.0/24 [90/20514560] via 192.168.10.1, 00:00:03, Serial0
C 192.168.2.0/24 is directly connected, FastEthernet0
D 192.168.3.0/24 [90/20514560] via 192.168.10.3, 00:00:05, Serial0
En esta tabla encontramos dos tipos de rutas: por un lado están las marcadas con una ‘C’ (Connected)
que corresponden a redes directamente conectadas, esto es las que el router ha descubierto por la
asignación que hemos hecho de direcciones IP y máscaras en la configuración de las interfaces. Por otro
lado las rutas marcadas con una ‘D’ (EIGRP) son las que el router ha conocido de sus vecinos por medio
de EIGRP, que es el protocolo de routing que estamos utilizando.
La información que nos suministra el ‘Show IP ROute’ incluye algunos datos interesantes. Por un
lado vemos que aparecen dos números entre corchetes [90/20514560]. El primero (90) es la distancia
administrativa cuyo significado no vamos a explicar aquí. El segundo número (20514560) es la métrica
de esa ruta. En caso de haber más de una ruta posible a un mismo destino EIGRP siempre elige por
defecto únicamente la que tiene una métrica más baja, sin intentar realizar ningún balanceo de tráfico
(más tarde veremos como puede modificarse este comportamiento). También podemos ver el tiempo que
hace que se ha recibido la última actualización relativa a cada ruta (en el ejemplo anterior ese tiempo es
de 3 segundos en la primera ruta y de 5 segundos en la segunda).
Si toda la información de rutas se ha generado y propagado correctamente cada router debe tener ahora
dos redes directamente conectadas, su Fast Ethernet y su Serie, y dos redes conocidas por EIGRP, que
corresponden a las LANs de los otros dos routers.
Paso 7: Configuración manual de la correspondencia entre direcciones IP y DLCIs
(Esperar que el resto de compañeros lleguen a este punto para continuar)
Hay ocasiones en las que interesa restringir las posibilidades de autoconfiguración de los routers, por
ejemplo porque no queramos que se utilicen determinados PVCs aunque estén configurados. En otros
casos el router no soporta las funciones de autoconfiguración, o las que soporta son incompatibles con la
red que estamos utilizando. Por eso a veces interesa configurar los routers de forma manual, que es lo
que haremos en este apartado de la práctica. Salvo ese detalle vamos a realizar una topología idéntica a la
anterior, es decir las tres interfaces serie inmersas en la misma subred IP de tipo NBMA, formada a partir
de los tres PVCs uniendo los tres routers entre sí.
Además en este caso vamos a cambiar el encapsulado. Utilizaremos uno conforme con los estándares del
IETF (RFCs 1490 y 2427) mediante el comando ’ENcapsulation Frame-relay Ietf’.
La configuración a introducir, por ejemp lo en el router de Alicante, será la siguiente:
Alicante#CONFigure Terminal
Alicante(config)#Interface Serial 0
Alicante(config-if)#ENcapsulation Frame-relay Ietf
Alicante(config-if)#FRAMe-relay MAp Ip 192.168.10.1 201 Broadcast
Alicante(config-if)#FRAMe-relay MAp Ip 192.168.10.3 203 Broadcast
Alicante(config-if)#CTRL/Z
Alicante#
Obsérvese que en este caso hemos salido del submodo Configuración de Interfaz utilizando CTRL/Z en
vez de ‘Exit’. La diferencia es que con Exit salimos a modo Configuración Global, mientras que con
CTRL/Z salimos directamente a modo Privilegiado.
Aquí solo hemos mostrado los comandos que habría que introducir para hacer los cambios en la
configuración suponiendo que el router mantiene la configuración del paso 5. En este caso los cambios
afectan únicamente a la interfaz Serial 0.
El comando ’FRAMe-relay MAp Ip 192.168.10.1 201 Broadcast’ sirve para informar al
router de que la dirección 192.168.10.1 (Valencia) se encuentra accesible a través del DLCI 201. En una
P2-13

Práctica 1: Frame Relay y Control de Tráfico
conexión real el proveedor del servicio Frame Relay nos suministraría los DLCI que deberíamos utilizar
en cada extremo de cada PVC.
Una vez introducida la nueva configuración en los tres routers deberíamos tener conectividad total, como
antes. Podemos repetir los comandos anteriores y comparar el resultado obtenido. Por ejemplo el
comando ‘Show INterfaces Serial 0’ ahora nos dirá ’Encapsulation FRAME-RELAY
IETF’.
El ‘Show FRAMe-relay Map’ ahora no muestra el atributo ‘dynamic’ puesto que el mapeo de
DLCI a dirección IP no se ha descubierto vía Inverse ARP, sino que se ha conocido por configuración.
Por lo demás la información es la misma que teníamos antes:
Castellon#Show FRAMe-relay Map
Serial0 (up): ip 192.168.10.1 dlci 301(0x10,0x400), static,
broadcast,
IETF, status defined, active
Serial0 (up): ip 192.168.10.2 dlci 302(0x11,0x410), static,
broadcast,
IETF, status defined, active
El comando ‘Show FRAMe-relay Pvc’ muestra prácticamente la misma información que antes.
Paso 8: Configuración de subinterfaces
(Esperar que el resto de compañeros lleguen a este punto para continuar)
En los pasos anteriores asociábamos a la interfaz Serial 0 de cada router los dos PVCs. Esto obligaba a
que ambos compartieran una serie de atributos y características. En ocasiones se quiere tener máxima
independencia entre los PVCs, pero sin tener por ello que asociarlos a interfaces físicas diferentes.
En esos casos se crean subinterfaces, o interfaces virtuales. Las subinterfaces siempre van asociadas a
una interfaz física, y se configuran de forma parecida a las interfaces, pero tienen la ventaja de que
pueden crearse y destruirse a voluntad, sin necesidad de modificar el hardware del router. Las
subinterfaces son muy utilizadas en redes Frame Relay y ATM, pero también en LANs cuando se tienen
VLANs y los routers se conectan a puertos configurados en modo ‘trunk’. En redes Frame Relay lo
normal es crear una subinterfaz diferente para cada PVC al que se conecta el router.
Para probar la configuración de subinterfaces en los routers vamos a realizar inicialmente una topología
con sólo dos PVCs en estrella centrada en Valencia, estableciendo una conexión Valencia -Alicante y otra
Valencia -Castelllón, pero no Alicante-Castellón. Es decir, aunque hay un PVC configurado en el Adtran
entre Alicante y Castellón nosotros no lo definiremos en los routers, con lo que ese PVC ahora no se
utilizará. Por tanto la comunicación entre Alicante y Castellón solo podrá realizarse a través del router de
Valencia. En la práctica esto podría tener sentido como estrategia para ahorrar costes en un escenario en
el que hubiera poco tráfico entre Castellón y Alicante (recordemos que en Frame Relay se paga por cada
PVC contratado). Sin embargo esto introduce un punto único de fallo en la red puesto que si el router de
Valencia falla ya no será posible ninguna comunicación.
Debemos pues definir dos subinterfaces en Valencia (una por cada PVC), una en Castellón y una en
Alicante. Cada PVC estará asociado a dos subinterfaces, una por cada extremo. A las dos subinterfaces
que se conectan a un mismo PVC les haremos corresponder una subred /30, como si el PVC fuera una
línea punto a punto.
Para especificar subinterfaces se utiliza el número de la interfaz correspondiente seguido del número de
la subinterfaz separado por un punto. El número de la subinterfaz se puede elegir arbitrariamente.
Nosotros hemos seguido el convenio de asignar el mismo número que el DLCI correspondiente.
Así pues la asignación de subinterfaces y direcciones IP a cada PVC será la siguiente:
P2-14

Práctica 1: Frame Relay y Control de Tráfico
PVC Subred
Extremo local (Valencia) Extremo remoto
IP DLCI Subinterf IP DLCI Subinterf
Valencia -
Alicante
192.168.10.0/30 192.168.10.1 102 Serial0.102 192.168.10.2 201 Serial0.201
Valencia -
Castellón
192.168.10.4/30 192.168.10.5 103 Serial0.103 192.168.10.6 301 Serial0.301
Tabla 5. Configuración de la red con subinterfaces
El esquema de la red que se quiere configurar es el que se muestra en la figura 7.
Castellón
Figura 7. Esquema de la red con subinterfaces y dos PVCs
Las subinterfaces pueden ser punto a punto (point-to-point) o multipunto (multipoint). En nuestro caso
deben ser punto a punto pues deseamos asociar un solo PVC, y por tanto un único destino, con cada
subinterfaz.
Ahora introduciremos la nueva configuración, diseñada de acuerdo con los datos de la tabla 5. pero antes
debemos ejecutar en la interfaz serial 0 los comandos ‘NO Ip ADdress’ y ‘NO ENcapsulation
Frame-relay’ para borrar la información de la configuración anterior. En el caso de Valencia los
comandos a teclear son los siguientes:
En Alicante:
192.168.10.6/30
S0.301
192.168.10.5/30
S0.103
Valencia
192.168.10.1/30
S0.102
192.168.10.2/30
S0.201
Alicante
Valencia#CONFigure Terminal
Valencia(config)#Interface Serial 0
Valencia(config-if)#NO Ip ADdress
Valencia(config-if)#NO ENcapsulation Frame-relay
Valencia(config-if)#ENcapsulation Frame-relay
Valencia(config-if)#Interface Serial 0.103 Point-to-point
Valencia(config-subif)#Ip ADdress 192.168.10.5 255.255.255.252
Valencia(config-subif)#Frame-relay INTerface-dlci 103
Valencia(config-fr-dlci)#Interface Serial 0.102 Point-to-point
Valencia(config-subif)#Ip ADdress 192.168.10.1 255.255.255.252
Valencia(config-subif)#Frame-relay INTerface-dlci 102
Valencia(config-fr-dlci)#CTRL/Z
Valencia#
P2-15

Y en Castellón:
Práctica 1: Frame Relay y Control de Tráfico
Alicante#CONFigure Terminal
Alicante(config)#Interface Serial 0
Alicante(config-if)#NO Ip ADdress
Alicante(config-if)#NO ENcapsulation Frame-relay
Alicante(config-if)#ENcapsulation Frame-relay
Alicante(config-if)#Interface Serial 0.201 Point-to-point
Alicante(config-subif)#Ip ADdress 192.168.10.2 255.255.255.252
Alicante(config-subif)#Frame-relay INTerface-dlci 201
Alicante(config-fr-dlci)#CTRL/Z
Alicante#
Castellon#CONFigure Terminal
Castellon(config)#Interface Serial 0
Castellon(config-if)#NO Ip ADdress
Castellon(config-if)#NO ENcapsulation Frame-relay
Castellon(config-if)#ENcapsulation Frame-relay
Castellon(config-if)#Interface Serial 0.301 Point-to-point
Castellon(config-subif)#Ip ADdress 192.168.10.6 255.255.255.252
Castellon(config-subif)#Frame-relay INTerface-dlci 301
Castellon(config-fr-dlci)#CTRL/Z
Castellon#
Obsérvese que el comando de declaración de subinterfaz (‘Interface Serial 0.301’) cambia el
prompt a ‘(config-subif)#’ indicando que entramos en un submodo nuevo, y lo mismo ocurre
con el comando ‘Frame-relay INTerface-dlci’. Aunque podemos salir de estos submodos
mediante el comando ‘Exit’ no es necesario pues el intérprete de comandos sale de forma automática
cuando detecta que el comando tecleado pertenece al modo superior (en este caso ‘Interface
Serial 0’).
El comando ‘Frame-relay INTerface-dlci’ sirve para asociar la subinterfaz con el PVC que le
corresponde.
Ahora, podemos probar los comandos ‘Show FRAMe-relay Map’ y ‘Show FRAMe-relay
Pvc’ comparando el resultado obtenido con los anteriores. Al haber definido las subinterfaces como
punto a punto con una subred diferente para cada subinterfaz ya no es necesario realizar el mapeo del
DLCI con la dirección IP ni por Inverse ARP ni por medio del comando ‘FRAMe-relay MAp’ en la
configuración, como hacíamos anteriormente.
También podemos probar el comando ‘Show INterface Serial 0.301’ y ver información
relativa a una subinterfaz concreta. Aunque no se nos brinda el mismo nivel de detalle que con el
comando ‘Show INterface Serial 0’ podemos obtener algunos datos de interés de forma
individualizada para cada PVC. En este caso el estado ‘up’ de la subinterfaz indica que ese PVC está
activo y que hay comunicación con el router del otro extremo.
Una vez se han propagado todas las rutas debe ser posible acceder desde cualquier host a cualquier otro.
Podemos utilizar los comandos ‘ping –R’ o ‘traceroute’ desde el host de Alicante o Castellón para
comprobar que la comunicación entre ellos pasa por el router de Valencia. En caso de que alguna
comunicación no funcione se deberá determinar el origen del problema y resolverlo.
Podemo s ahora probar a hacer un ping a nuestra propia subinterfaz (o subinterfaces) y veremos que, a
diferencia de lo que ocurría antes, ahora sí nos responde. Esto se debe a que las subinterfaces punto a
punto son equivalentes a líneas punto a punto.
Ahora ejecutaremos el comando ‘Show IP ROute’ en el router de Castellón y en el de Alicante.
Deberemos ver cinco rutas, dos directamente conectadas que corresponden a la LAN propia y al PVC
local, y tres conocidas vía EIGRP, las dos LANs remotas y la red del PVC re moto. También deberemos
P2-16

Práctica 1: Frame Relay y Control de Tráfico
comprobar que la métrica hacia la LAN de Valencia es un poco menor que hacia la otra LAN remota
(Alicante o Castellón). Esto es lógico ya que para acceder a Valencia atravesamos un solo PVC, mientras
que para llegar a la LAN remota hay que pasar por dos PVCs. Pero sin embargo la métrica no es el doble
en un caso que en otro. Esto se debe a que la métrica se calcula como la suma de dos términos: uno es
proporcional al retardo de la ruta, calculado como la suma de los retardos de las interfaces por las que
pasa; al pasar por dos PVCs este término se duplica (las interfaces serie tienen todas por defecto un
retardo de 20 mseg). El otro término, que en este caso es el dominante, es inversamente proporcional al
ancho de banda, que por defecto son 128 Kb/s, pero solo se toma en cuenta el valor más bajo de las
interfaces por las que pasa, por lo que en este caso este término vale lo mismo tanto si se atraviesa un
PVC como si se atraviesan dos.
En el router de Valencia el comando ‘Show IP ROute’ nos mostrará tres redes directamente
conectadas (la LAN local y los dos PVCs) y dos conocidas por EIGRP, las LANs remotas. En este caso
la métrica a cada LAN deberá ser la misma pues la situación es simétrica, ambos PVCs tienen los
mismos parámetros.
Paso 9: Circuito virtual redundante Alicante-Castellón
Ahora vamos a configurar un tercer circuito virtual correspondiente al PVC que está configurado en el
Adtran y que no hemos utilizado en el paso anterior, Para ello configuraremos una segunda subinterfaz
en Alicante y Castellón. De esta forma constituimos un anillo, que es la topología redundante mínima
para tener protección contra fallos en una red.
La asignación de direcciones IP y subinterfaces la haremos según se indica en la Tabla 6.
PVC Subred
Extremo local (Alicante) Extremo remoto (Castellón)
IP DLCI Subinterf IP DLCI Subinterf
Alicante-
Castellón
192.168.10.8/30 192.168.10.9 203 Serial0.203 192.168.10.10 302 Serial0.302
Tabla 6. Configuración del PVC adicional
El esquema de la red, tal como quedará ahora, es el que se muestra en la figura 8.
Castellón
192.168.10.6/30
192.168.10.5/30
S0.103
Figura 8. Esquema de la red con subinterfaces y tres PVCs
La configuración a añadir en Alicante será:
Valencia
192.168.10.1/30
S0.102
192.168.10.2/30
S0.301 S0.201
S0.302 S0.203
192.168.10.10/30 192.168.10.9/30
Alicante
Alicante#CONFigure Terminal
Alicante(config)#Interface Serial 0.203 Point-to-point
Alicante(config-subif)#Ip ADdress 192.168.10.9 255.255.255.252
P2-17

Y en Castellón:
Práctica 1: Frame Relay y Control de Tráfico
Alicante(config-subif)#Frame-relay INTerface-dlci 203
Alicante(config-fr-dlci)#CTRL/Z
Alicante#
Castellon#CONFigure Terminal
Castellon(config)#Interface Serial 0.302 Point-to-point
Castellon(config-subif)#Ip ADdress 192.168.10.10 255.255.255.252
Castellon(config-subif)#Frame-relay INTerface-dlci 302
Castellon(config-fr-dlci)#CTRL/Z
Castellon#
Aquí, además de definir las nuevas subinterfaces y asignarles sus correspondientes direcciones IP, hemos
añadido como siempre la nueva red (192.168.10.8) al proceso de routing EIGRP.
Una vez esté todo correctamente configurado podremos comprobar la conectividad y la tabla de
encaminamiento en cada router con el comando ‘Show IP ROute’. Como ahora tenemos una
situación simétrica el resultado debe ser equivalente en los tres, cada router debe tener directamente
conectadas tres redes (su LAN y las subredes de los dos PVCs que le unen con sus vecinos) y conocer
tres redes por EIGRP (las dos LANs remotas y la subred del PVC al que no está conectado). Las métricas
para las tres redes remotas deben ser las mismas.
En el ‘Show IP ROute’ aparece una red con dos posibles rutas que tienen la misma métrica. Los
alumnos deben anotar a continuación la información relativa a dicha red, su métrica e interfaz de salida:
Dirección de red: ____.____.____.____ coste EIGRP: ___________ interfaz de salida: ______
coste EGRP: ___________ interfaz de salida: ______
¿Por qué tiene esta red la misma métrica por los dos caminos?
Ahora deben anotar las otras redes que aparecen, su métrica e interfaz de salida:
Dirección de red: ____.____.____.____ coste EGRP: ___________ interface de salida: ______
Dirección de red: ____.____.____.____ coste EGRP: ___________ interface de salida: ______
Si ahora si fallara algún PVC el EIGRP detectaría la situación y reencaminaría el tráfico a través de los
otros dos, siguiendo la ruta alternativa. En nuestro caso no podemos hacer pruebas de desconexión física
ya que por cada cable circula tráfico de los dos PVCs hasta el Adtran y si lo cortamos no queda ruta
alternativa. Pero podemos ‘simular’ el fallo de un PVC desactivando una subinterfaz en uno de los
routers y comprobando mediante pings o mediante el comando ‘Show IP ROute’ que, aunque la red
deconectada queda momentáneamente fuera de servicio, el servicio se restablece a los pocos segundos.
Para descativar una subinterfaz debemos utilizar el comando ‘SHutdown’ en modo Configuración de
Subinterfaz, por ejemplo para desactivar en el router de Alicante el PVC con Valencia teclearemos:
Alicante#CONFigure Terminal
Alicante(config)#Interface Serial 0.201 Point-to-point
Alicante(config-subif)#SHutdown
Alicante(config-subif)#CTRL/Z
Alicante#
Antes de ejecutar los comandos anteriores deberíamos lanzar un ping desde el host de Alicante al de
Valencia para observar el tiempo que tarda el EIGRP en habilitar la ruta alternativa.
Una vez realizada la prueba deberemos poner nuevamente en ‘NO Shutdown’ la subinterfaz.
P2-18

Paso 10: Modificación de rutas
Práctica 1: Frame Relay y Control de Tráfico
En este paso vamos a ver como podemos influir en las decisiones que toma EIGRP respecto a la ruta
óptima. EIGRP basa todas sus decisiones en el valor de la métrica, que como ya hemos comentado se
calcula como la suma de dos términos, uno calculado a partir del ancho de banda (bandwidth) y el otro a
partir del retardo (delay). Siempre se utilizan los valores de las interfaces de salida, no tomándose en
cuenta los valores de las interfaces de entrada. Puede por tanto ocurrir que las métricas no sean simétricas
si las dos subinterfaces que están conectadas en un PVC no tienen configurados los mismos valores de
bandwidth y delay. El delay se va sumando a lo largo de la ruta mientras que para el cálculo del
bandwidth solo se toma en cuenta el valor más bajo, ignorándose todos los demás.
Los valores de bandwidth y delay de una interfaz o subinterfaz se pueden averiguar por medio del
comando ‘Show INterfaces’. Ambos parámetros tienen valores por defecto que dependen del tipo
de interfaz y que pueden modificarse en modo Configuración de Interfaz por medio de los comandos
‘BANdwidth’ y ‘DELay’. El bandwidth se expresa en Kb/s y el delay en decenas de microsegundos.
Por ejemplo para indicar un bandwidth de 64 Kb/s se utilizaría el comando ‘BANdwidth 64’ y para
expresar un retardo de 5 mseg se emplearía el comando ‘DELay 500’.
Debido a la forma como EIGRP calcula las métricas es difícil predecir las consecuencias exactas de un
cambio en algún parámetro de alguna interfaz, especialmente si lo que se modifica es el bandwidth, ya
que su efecto es inverso (a más bandwidth menor métrica) y además los cambios en el bandwidth de una
interfaz solo afectan la métrica de las rutas para las que dicho bandwidth es el mínimo, en caso contrario
el cambio no tiene efecto alguno en la métrica de la ruta. Por eso cuando se quiere influir en las métricas
que calcula EIGRP se recomienda modificar el delay y dejar que el bandwidth refleje el ancho de banda
real de los enlaces (o de los circuitos).
Vamos ahora a hacer una prueba para demostrar que EIGRP calcula la métrica de forma independiente
para cada sentido. Para ello haremos modificaciones en el delay de las subinterfaces de forma no
simétrica, es decir no aplicaremos los mismos cambios a los dos extremos de cada PVC.
Ahora los alumnos deberán modificar el delay de sus subinterfaces con el objeto de que todo el tráfico
fluya en el sentido de las agujas del reloj únicamente, es decir:
? Desde Castellón se utilizará la subinterfaz serial0.301, tanto para ir hacia Valencia como hacia
Alicante.
? Desde Valencia se utilizará la subinterfaz serial0.102 para ir hacia Alicante o hacia Castellón
? Desde Alicante se utilizará la subinterfaz serial0.203 para ir hacia Castellón o hacia Valencia
Para conseguir esto asignaremos un retardo de 9 mseg (comando ‘DELay 900’) a las siguientes
subinterfaces:
? En Castellón a la serial 0.301
? En Valencia a la serial 0.102
? En Alicante a la serial 0.203
Por ejemplo en Castellón se debería utilizar la siguiente secuencia de comandos:
Castellon#CONFigure Terminal
Castellon(config)#Interface Serial 0.301
Castellon(config-subif)#DELay 900
Castellon(config-subif)#CTRL/Z
Castellon#
Para comprobar que las definiciones han tenido el efecto deseado utilizamos el comando ‘Show
INterfaces Serial 0.301’:
Router#Show INterface Serial 0.301
Serial0.1 is up, line protocol is up
Hardware is PowerQUICC Serial
P2-19

Práctica 1: Frame Relay y Control de Tráfico
Internet address is 192.168.10.10/30
MTU 1500 bytes, BW 128 Kbit, DLY 9000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation FRAME-RELAY
Router#
Una vez hechos los cambios los alumnos deberán comprobar por medio del comando ‘Show IP
ROute’ que EIGRP modifica su decisión respecto de la ruta óptima. Es to tarda unos pocos segundos.
Una vez hechos los cambios se verán las mismas redes que antes pero habrán cambiado algunas métricas
y con ellas algunas interfaces. Los alumnos deben anotar las nuevas métricas e interfaces, y ver si los
cambios corresponden con lo esperado.
El comando ‘Show IP ROute’ sólo muestra en cada caso la ruta elegida como óptima. Si utilizamos
el comando ‘Show IP Eigrp Topology’ podremos ver las otras rutas posibles con métrica peor
que EIGRP de momento tiene en ‘reserva’ por si la ruta elegida como óptima falla. Esto es lo que se
conoce como un ‘sucesor factible’..
Los alumnos deberían probar ahora que los cambios realizados en el retardo de las interfaces tienen el
efecto esperado ejecutando entre los hosts el comando ‘ping –R -n’.
Una vez terminada esta prueba volveremos a poner en todas las subinterfaces que habíamos modificado
el delay por defecto mediante el comando ‘NO DELay’.
Paso 11: Balanceo de carga
Además de tener un sistema tolerante a fallos al tener tres PVCs podemos introducir mecanismos de
balanceo de carga, es decir, aprovechando que tenemos una red mallada podemos repartir dinámicamente
el tráfico entre las dos rutas para conseguir una mayor capacidad.
Supongamos que tenemos necesidad de intercambiar una gran cantidad de tráfico entre Valencia y
Alicante en un momento en que Castellón no esta generando ningún tráfico. En ese caso podemos
utilizar, además del PVC que comunica Valencia con Alicante directamente, la ruta alternativa que nos
permite llegar a Alicante vía Castellón. De esta forma podemos casi duplicar el rendimiento.
Pero la ruta vía Castellón tiene una métrica peor. En principio EIGRP solo balancea tráfico entre dos
rutas cuando su métrica es exactamente la misma. Para que EIGRP reparta tráfico entre rutas con
métricas diferentes es preciso configurar un parámetro conocido como varianza. La varianza es un valor
numérico que indica hasta que punto estamos interesados en aprovechar rutas con una métrica peor. Por
ejemplo si especificamos una varianza 4 cuando la métrica óptima hacia un destino dado es 10.000 el
router tomará en consideración todas las rutas hacia ese mismo destino cuya métrica sea igual o inferior a
40.000, y repartirá tráfico por todas ellas. Además el router intentará en lo posible repartir el tráfico de
forma inversamente proporcional a la métrica de cada ruta; por ejemplo si hay tres rutas con métricas
10.000, 20.000 y 40.000 se enviará por la primera el 57% del tráfico, por la segunda el 29 % y por la
tercera el 14% restante.
El valor por defecto de la varianza es 1, que significa que el tráfico sólo se envía por la ruta de métrica
más baja, ignorando todas las demás. Con una varianza de 1 solo se utilizarán varias rutas cuando la
métrica calculada sea idéntica para todas ellas.
La varianza se especifica en modo configuración de routing. Por tanto tiene validez solo para el router y
en el proceso de routing (es decir en el sistema autónomo) en el que se define. Vamos a introducir ahora
una varianza 4 en el EIGRP del sistema autónomo 65000 utilizando las siguientes instrucciones:
Valencia#CONFigure Terminal
Valencia(config)#ROUTER EIgrp 65000
Valencia(config-router)#Variance 4
Valencia(config-router)#CTRL/Z
Valencia#
Esta modificación la haremos en Valencia y en Alicante únicamente.
P2-20

Práctica 1: Frame Relay y Control de Tráfico
Además de la condición impuesta por la varianza el balanceo de tráfico tiene otro requisito. Para que la
segunda ruta se tome en consideración es necesario que el siguiente router tenga una mejor métrica que el
router actual. Por ejmplo en nuestro caso la métrica de Castellón hacia Alicante es la misma que la de
Valencia a Alicante, pues en ambos casos se atraviesa un enlace de las mismas características (bandwidth
128, delay 2000). En estas condiciones , sea cual sea el valor de la varianza, Valencia nunca enviará
tráfico hacia Alicante vía Castellón, pues la métrica que le presenta Castellón no es más baja que la suya
propia. Por tanto para que la ruta vía Castellón sea tomada en cuenta tenemos que darle alguna ventaja en
la métrica, aunque sea pequeña, al PVC Castellón-Alicante. Para ello bajaremos a 19ms el retardo de la
subinterfaz Serial 0.302 en Castellón y el de la Serial 0.203 en Alicante. De esta forma conseguimos que
el PVC Castellón-Alicante presente una métrica ligeramente inferior que los otros dos.
Ahora en el ‘Show IP ROute’ ejecutado en el router de Valencia veremos aparecer también la ruta
vía Castellón. Los alumnos deben anotar los valores que corresponden a la LAN de Alicante.
Con esto ya debe haber reparto de tráfico entre los dos PVCs, como podremos comprobar si hacemos un
‘ping –R –n’ entre el host de Valencia y el de Alicante. Pero aunque el ‘ping –R -n’ nos muestra un
aparente reparto de tráfico entre las dos rutas, si enviamos un número elevado de paquetes con el ‘ping –
f’ y miramos los contadores de las interfaces del router RS observaremos que todo el tráfico sale por una
misma interfaz (podemos utilizar el comando ‘CLEar COunters’ para hacer más fácilmente el
seguimiento). ¿A que se debe este comportamiento? La explicación es la siguiente: los routers
normalmente no consultan la tabla de routing para cada paquete que envían por sus interfaces sino que,
para acelerar el proceso de enrutamiento, construyen una tabla en memoria cache en la que a cada
dirección IP de destino le asocian una interfaz de salida, y solo una. Esto se conoce como conmutación
por destino o también ‘fast switching’ (conmutación rápida). Podemos ver la tabla de cache de routing
mediante el comando ‘Show IP CAche’ donde comprobaremos que la dirección IP hacia la que iban
dirigidos los pings está asociada a la interfaz por la que estaba saliendo todo el tráfico con el ‘ping –f’.
Como todos los paquetes los estamos enviando hacia una misma dirección IP el uso de la IP cache
impide en la práctica el balanceo de tráfico entre los dos PVCs. Si hiciéramos pings a direcciones
diferentes veríamos que unas se asocian con una subinterfaz y otras con la otra, produciéndose un
efectivo reparto de tráfico entre ambos PVCs.
Para conseguir el reparto de tráfico entre más de una ruta cuando todos los paquetes van dirigidos a un
mismo destino, comoen nuestro caso, tenemos que deshabilitar la conmutación por destino, es decir
deshabilitar la tabla de routing IP cache. Esto lo haremos en modo Configuración de Interfaz para la
interfaz Serial 0 mediante el comando ‘NO IP ROute-cache’. Con esto esa interfaz y todas sus
subinterfaces pasan a funcionar en el modo conmutación por paquete, también llamado ‘process
switching’ (conmutación por proceso) y balancean tráfico paquete a paquete, aún en el caso de que todo
vaya destinado a la misma dirección IP. Podemos comprobar que hemos desactivado la cache de routing
con el comando ‘Show IP CAche’ o con el comando ‘Show IP INterface subinterfaz’
que nos dirá ‘IP fast switching is disabled’.
Una vez desactivado el fast switching repetiremos el ‘ping –f’ entre Valencia y Alicante y
comprobaremos que ahora sí que hay reparto de tráfico entre ambas subinterfaces. Además podremos
comprobar que el reparto no es homogéneo, sino inversamente proporcional al valor de la métrica de
cada ruta. Para ver esto debemos proceder de la siguiente forma:
1. Lanzamos el ‘ping –f’ del host de Valencia al de Alicante.
2. Ejecutamos un ‘CLEar COunters’ (de todas las interfaces).
3. Esperamos medio minuto aproximadamente (que corresponde a unos 3000 paquetes) y
abortamos el ping con CTRL/C.
4. Ejecutamos un ‘Show Interfaces Serial 0.103’ y ‘Show Interfaces
Serial 0.102’ y observamos los contadores de paquetes transmitidos por cada subinterfaz.
En principio deberíamos fijarnos únicamente en los paquetes transmitidos, ya que son estos los que
dependen de los valores de las métricas (el reparto de tráfico entrante depende de los valores de las
métricas en los otros routers, Castellón y Alicante). De cualquier modo como en este caso tenemos una
situación simétrica los contadores de paquetes recibidos deberían seguir el mismo reparto.
P2-21

Práctica 1: Frame Relay y Control de Tráfico
La conmutación por paquete requiere que todo el proceso de conmutación lo realice la CPU, por eso se le
llama ‘process switching’. En cambio la conmutación por destino simplifica y por tanto acelera el
proceso, de ahí la denominación de ‘fast switching’. Por eso es este el modo por defecto. En una
situación real los paquetes que salen del router van dirigidos a muchos destinos diferentes, con lo que la
tabla IP cache contiene múltiples entradas que se reparten entre ambas interfaces, consiguiendo así el
balanceo de tráfico con el fast switching activado. El process switching consume mucha más CPU y
puede hacer que la CPU del router se convierta en el cuello de botella de la comunicación, por lo que
normalmente el proces switching sólo se utiliza en líneas de baja velocidad (512 Kb/s o menos) ya que en
este caso la ocupación de la CPU del router no supone un problema.
Nos queda por aclarar por qué el ‘ping –R –n’ que hicimos en un principio balanceó el tráfico, a pesar de
que en ese momento estaba activado el fast switching. La explicación es sencilla: el fast switching no
puede utilizarse cuando el paquete tiene opciones en la cabecera IP (la opción –R del ping hace uso de la
opción ‘record route’); en este caso se recurre automáticamente al process switching, con lo que se
produce automáticamente el balanceo de tráfico por paquete.
Paso 12: Conformado de tráfico
Siguiendo con la topología en anillo de los pasos anteriores vamos ahora a introducir mecanismos de
conformado de tráfico en los routers. En una red Frame Relay real la línea punto a punto conectaría el
DTE (router) a la red con una determinada velocidad (en nuestro caso los 64 Kb/s que fija la señal de
reloj del Adtran), y sobre esa línea punto a punto se definirían una serie de PVCs con unos parámetros
que especificarían los caudales de CIR (Commited Information Rate) y de EIR (Excess Information
Rate). Hasta aquí hemos ignorado la existencia del CIR y el EIR, nuestros routers no tenían otra
limitación que los 64 Kb/s de la línea física que les imponía el Adtran.
Supongamos ahora que nuestros PVCs tuvieran configurado en el Adtran un CIR y un EIR de 4,8 Kb/s.
Dado que no hemos configurado estos valores en las subinterfaces asociadas a los PVCs los routers no
estan ejerciendo ningún tipo de regulación o conformado de tráfico (traffic shaping). Si los hosts generan
una ráfaga de paquetes los routers la enviarán en la medida que se lo permita la línea de 64 Kb/s que les
une con el Adtran. Como los routers estarían en es e caso enviando tráfico a un caudal superior al
permitido por el CIR + EIR los buffers empezarían a llenarse y si la situación persistiera durante el
tiempo suficiente se produciría descarte de paquetes. Por tanto en estas circunstancias es conveniente
configurar los parámetros CIR y EIR en la subinterfaz a fin de que el router se autoregule, es decir
aplique técnicas de conformado de tráfico.
Conviene mencionar que en nuestro caso concreto la no regulación por parte del router no supone un
problema pues el Adtran no está aplicando técnicas de policía de tráfico (traffic policing), es decir no
tiene configurados unos caudales máximos en los PVCs que hay definidos. Sin embargo vamos a
imaginar a modo de ejercicio que sí los tuviera y que por tanto nos viéramos en la necesidad de
configurar esos caudales en los routers.
Para tener una referencia comparativa del caudal, antes y después de introducir los parámetros de
conformado de tráfico vamos a lanzar en primer lugar tres pings siguendo el triángulo, es decir del host
de Castellón al de Valencia, del de Valencia al de Alicante y del de Alicante al de Castellón, con el
comando ‘ping –s 1400 dirección_IP’ (un paquete de 1400 bytes cada segundo) que ejecutaremos desde
el host en una ventana de shell distinta a la de configuración del router. Debemos fijarnos en el valor del
tiempo de ida y vuelta (Round Trip Time) obtenido. Este ping lo dejaremos en marcha indefinidamente,
para observar como cambia el tiempo de ida y vuelta cuando introduzcamos los parámetros de
conformado de tráfico.
Vamos a suponer ahora que los enlaces contratados tienen un CIR de 4,8 Kb/s y un EIR también de 4,8
Kb/s. Primero debemos configurar en los tres routers una clase (con el comando ‘MAP_Class’) que
defina esta configuración. Esto se realiza a través de los siguientes comandos:
Router#CONFigure Terminal
Router(config)#MAP-Class Frame-relay cir-4800
Router(config-map-class)#Frame-relay Traffic-rate 4800 9600
Router(config-map-class)#CTRL/Z
Router#
P2-22

Práctica 1: Frame Relay y Control de Tráfico
En el comando ‘Frame-relay Traffic-rate’ el primer argumento (4800) corresponde al CIR y
el segundo (9600) al CIR+EIR. Este comando dispone de otros argumentos opcionales que no
utilizaremos, como por ejemplo uno para configurar el uso del bit BECN (Backward Explicit Congestion
Notification). Podemos ver, solo por curiosidad, la lista de argumentos que admite este comando
tecleando ’Frame-relay ?’.
Si observamos ahora el ping que hemos dejado en marcha veremos que la creación del mapa no afecta en
nada al RTT, ya que el mapa no se ha aplicado todavía a ninguna interfaz.
Una vez definida en los routers la map-class que hemos denominado ‘cir-4800’ debemos aplicarla a las
subinterfaces. Para ello utilizamos el comando ‘Frame-relay Class cir-4800’ en el modo
Configuración de Subinterfaz. Pero para que esto funcione antes tenemos que habilitar el conformado de
tráfico en la interfaz física, para lo cual utilizamos el comando ‘FRame-relay Trafficshaping’
en el modo Configuración de Interfaz. Para evitar interferencias del tráfico generado por los
demás routers solo aplicaremos la map-class que hemos definido en una subinterfaz de cada router:
? En Castellón lo aplicaremos a la serial 0.301
? En Valencia a la serial 0.102
? En Alicante a la serial 0.203
La secuencia de comandos por ejemplo en el router de Alicante sería la siguiente:
Alicante#CONFigure Terminal
Alicante(config)#Interface Serial 0
Alicante(config-if)#FRame-relay Traffic-shaping
Alicante(config-if)#Interface Serial 0.203 Point-to-point
Alicante(config-subif)#Frame-relay Class cir-4800
Alicante(config-subif)#BANdwidth 10
Alicante(config-subif)#CTRL/Z
Alicante#
En este caso, hemos especificado con el parámetro bandwidth el caudal máximo disponible (CIR+EIR),
para que la modificación introducida por el conformado de tráfico se refleje adecuadamente en el cálculo
de las métricas. Como el bandwidth ha de ser un valor entero y se especifica en Kb/s hemos elegido 10,
que es el valor que más se aproxima a 9,6 Kb/s.
Al aplicar el conformado de tráfico observaremos que el tiempo de ida y vuelta del ping que habíamos
dejado lanzado en el host empieza a crecer sin parar. Además se pierden muchos paquetes. Esto se
explica por la retención de tráfico que están efectuando los routers que hace que las colas de las
interfaces vayan creciendo, ya que el tráfico que está generando el ping supera el caudal del CIR+EIR.
Aunque el Adtran no está aplicando ningún control sobre el tráfico entrante (es decir, no aplica ningún
‘traffic policing’) el router sí que está aplicando conformado de tráfico (‘traffic shaping’) reteniendo en
su buffer los paquetes para no superar el valor de CIR+EIR, hasta que llega al punto que tiene que
descartarlos.
Sabiendo que el caudal máximo utilizable con la configuración actual es de 9,6 Kb/s los alumnos
deberían ahora calcular para que tamaño de paquete del ping no se produciría ninguna o casi ninguna
retención, y comprobarlo en la práctica.
Para obtener información sobre el conformado de tráfico puede utilizarse el comando ‘Show FRAMerelay
Pvc DLCI’, donde DLCI es el número del DLCI del que se quiere obtener la información.
P2-23

Práctica 1: Frame Relay y Control de Tráfico
Apéndice I. Introducción a la interfaz de comandos del IOS y configuración de
routers.
El IOS (Internetworking Operating System) es un sistema operativo propietario de Cisco Systems que
incorporan todos sus routers y muchos de sus conmutadores y otros equipos.
Para interaccionar con el IOS el usuario dispone de una interfaz de línea de comandos que puede utilizar
desde un terminal conectado al puerto de consola del router. Para ello puede utilizarse cualquier
ordenador personal con un programa de emulación de terminal, por ejemplo el Hyperterminal, el
TeraTerm o el Minicom. En este caso el ordenador estará conectado al puerto de consola del router por un
puerto RS-232, normalmente COM1.
La interfaz de línea de comandos del router dispone de varios entornos o modos, cada uno de ellos
identificado por un prompt diferente. El prompt ‘>’ identifica el llamado modo Usuario, que es el modo
no privilegiado al que accedemos inicialmente. Mediante el comando ‘enable’ podemos pasar al modo
Privilegiado, con lo que el prompt cambia a ‘#’; dependiendo de la configuración que tenga el
conmutador es posible que al pasar a modo Privilegiado nos pida una password de acceso, en cuyo caso
deberemos consultar el guión de la práctica o preguntar al profesor. En el modo Privilegiado se pueden
usar todos los comandos del modo Usuario más otros solo accesibles en modo Privilegiado. Del modo
Privilegiado podemos volver en cualquier momento al modo Usuario con el comando ‘exit’. También
podemos pasar del modo Privilegiado al modo llamado Configuración Global mediante el comando
‘CONFigure Terminal’. El modo Configuración Global se caracteriza por el prompt
‘(config)#’. Como su nombre indica el modo Configuración Global permite hacer cambios globales
en la configuración del equipo, para lo cual dispone de un conjunto de comandos completamente
diferente al modo Privilegiado. Del modo Configuración Global se puede volver al modo Privilegiado
mediante el comando ‘exit’, o pasar a uno de varios modos de configuración particulares (realmente
submodos del modo Configuración Global) que son los siguientes:
? Modo Configuración de Interfaz. Este modo se utiliza para configurar una interfaz específica
del router y se accede a él desde el modo Configuración Global mediante el comando
‘INterface int’ donde ‘int’ corresponde al nombre de una interfaz del equipo (por
ejemplo ‘INterface Fastethernet 0’ o ‘Interface Serial 0’). El modo
Configuración de Interfaz se caracteriza por el prompt ‘(config-if)#’. Podemos volver de
este modo al modo Configuración Global mediante el comando ‘Exit’, o directamente al
modo privilegiado pulsando CTRL/Z.
? Modo Configuración de Línea. Este modo permite configurar el acceso a través del puerto de
consola del equipo y también el acceso por red vía telnet. Se accede a él mediante el comando
‘LIne línea’ donde línea indica el tipo de línea que se quiere configurar. Normalmente este
modo solo se utiliza para habilitar el acceso vía telnet al router, para lo cual se emplea la línea
vty (virtual terminal) es decir el comando ‘LIne Vty’. Análogamente al caso anterior
podemos volver de este modo al modo Configuración Global mediante el comando ‘EXIt’, o
directamente a modo Privilegiado pulsando CTRL/Z.
? Modo Configuración de Routing . Este modo se utiliza para configurar los parámetros
relacionados con el protocolo de routing utilizado. Podemos acceder a él mediante el comando
‘router protocolo’ donde protocolo es cualquier protocolo de routing soportado por ese
router (por ejemplo ‘router eigrp 65000’). En este caso el prompt es ‘(configrouter)#’.
Como siempre podemos volver de este modo al modo Configuración Global
mediante el comando ‘EXit’, o directamente al modo Privilegiado pulsando CTRL/Z.
Esquemáticamente la conmutación de modos se desarrolla según la siguiente secuencia:
P2-24

Interface
interfaz
CTRL/Z
Configuración
de Interfaz
‘(config-if)#’
Práctica 1: Frame Relay y Control de Tráfico
Usuario ‘>’
ENable EXIt
Privilegiado ‘#’
CONFigure Terminal EXIt o CTRL/Z
Configuración Global ‘(config)#’
Exit
LIne
línea
Configuración
de Línea
‘(config-line)#’
En todos los modos existe una ayuda en línea que se puede consultar tecleando ‘?’ con lo que aparecen
todos los comandos permitidos en ese modo. Para solicitar ayuda sobre los posibles argumentos de un
comando en particular se puede teclear ‘comando ?’. Así por ejemplo ‘Show ?’ nos muestra todos
los posibles argumentos del comando ‘show’.
Otras funciones interesantes del intérprete de comandos son las siguientes:
CTRL/Z
ROUTER
protocol
o
Configuración
de Routing
‘(config-router)#’
EXIt EXit
? Los comandos previamente tecleados se almacenan en un buffer del que pueden recuperarse
mediante las teclas flecha hacia arriba (?) y flecha abajo (? ). Las teclas flecha derecha (? ) e
izquierda (? ) permiten editar la línea de comandos.
? Los comandos y los argumentos pueden abreviarse, normalmente al número mínimo de letras
que permita identificar el comando sin ambigüedad. (Esa parte mínima es la que representamos
en mayúsculas, los comandos mismos pueden teclearse en mayúsculas o minúsculas
indistintamente). Si se escribe una parte de un comando o de un argumento y se pulsa la tecla
tabulador el sistema termina de escribir el comando o argumento correspondiente, siempre y
cuando el significado no sea ambiguo.
? Cuando la salida generada por un comando en consola ocupa más de una pantalla el terminal se
bloquea al mostrar la primera de ellas, indicándolo con el texto ‘more’ al final de la pantalla.
Para avanzar a la siguiente pantalla debemos pulsar la barra espaciadora y así sucesivamente
hasta agotarlas todas. También puede pulsarse la tecla ‘RETURN’, con lo que el avance se
realiza línea a línea. La salida por pantalla puede abortarse en cualquier momento pulsando
CTRL/C.
Una característica importante del IOS es que el router tiene en todo momento dos copias de la
configuración, una en memoria RAM, volátil y otra en memoria NVRAM, permanente. Cuando se realiza
un cambio en la configuración, bien sea en modo Configuración Global o alguno de sus submodos
(Configuración de Interfaz, Configuración de Línea o Configuración de Routing), el cambio se aplica a la
configuración en RAM y tiene efecto de forma inmediata, pero no se graba en la NVRAM, de modo que
si el router se apaga y enciende, o si se reinicia con el comando ‘RELoad’ (en modo Privilegiado),
volverá a cargar la configuración que tuviera antes de los cambios. Los routers que se utilizan en prácticas
tienen grabada una configuración por defecto en la NVRAM. Todos los cambios realizados en la
configuración se almacenan en la RAM, pero no deben salvarse nunca en la NVRAM. De esta forma
cuando se quiere volver a la configuración por defecto basta con apagar y encender el router o ejecutar el
P2-25

Práctica 1: Frame Relay y Control de Tráfico
comando ‘RELoad’. Esta forma de funcionamiento presenta el inconveniente de que si el router se
apaga accidentalmente se pierde toda la configuración que se haya introducido.
En modo Privilegiado es posible ver en cualquier momento la configuración actual del router (es decir la
de la RAM) mediante el comando ‘Show RUnnng-config’.
Muchos de los comandos utilizados en los modos Configuración Global, Configuración de Interfaz y
Configuración de Routing, admiten ser tecleados con el prefijo ‘no’. Esto indica que se desea la acción
contraria a la que normalmente ejecuta el comando. Por ejemplo el comando ‘SHutdown’ ejecutado en
el modo Configuración de Interfaz deshabilita una interfaz. Para habilitar una interfaz se debe utilizar el
comando ‘NO SHutdown’.
El comando ‘Show VErsion’ nos ofrece información resumida del router, la versión de software que
tiene, el tiempo que lleva encendido, etc. La salida que genera por pantalla es similar a la siguiente:
Router>Show VErsion
Cisco Internetwork Operating System Software
IOS (tm) C1700 Software (C1700-SV3Y-M), Version 12.1(4), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 30-Aug-00 10:59 by cmong
Image text-base: 0x80008088, data-base: 0x8084EBE0
ROM: System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
Router uptime is 6 minutes
System returned to ROM by reload
System image file is "flash:c1700-sv3y-mz.121-4"
cisco 1750 (MPC860) processor (revision 0x601) with 29492K/3276K bytes of memory.
Processor board ID JAD04250112 (3399530869), with hardware revision 0000
M860 processor: part number 0, mask 32
Bridging software.
X.25 software, Version 3.0.0.
1 FastEthernet/IEEE 802.3 interface(s)
1 Serial(sync/async) network interface(s)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
Router>
La segunda línea indica la versión de IOS (en este ejemplo la 12.1(4)). Este es importante ya que algunos
detalles y comandos o argumentos pueden depender de la versión de IOS.
La palabra que precede al prompt (‘Router’ en el ejemplo anterior) corresponde al nombre asignado al
router en la configuración mediante el comando ‘HOstname’. Por ejemplo si al router le hemos
asignado el nombre ‘Valencia’ (comando ‘HOstname Valencia’ en modo Configuración Global)
el prompt en modo Usuario será ‘Valencia>’ y en modo Privilegiado ‘Valencia#’.
A menudo es interesante poder acceder a la consola de un router a través de la red, vía telnet. Para esto es
necesario haber asignado una dirección IP a la interfaz por la que queremos acceder y tener comunicación
con ella, pero además es preciso configurar una password para el acceso por terminal virtual. Esto es una
medida de seguridad para evitar que cualquier usuario de la red pueda acceder libremente a un router que
no tiene configurada password. Para asignar la password para acceso vía telnet se utiliza el comando
‘password password’ en el modo Configuración de Línea al cual accedemos mediante el comando
‘line vty’. Por ejemplo la siguiente secuencia de comandos configura un router para que nos permita
mantener hasta un máximo de cinco sesiones simultáneas (de la 0 a la 4) vía telnet accediendo con la
password ‘genios’:
Router#CONFigure Terminal
P2-26

Práctica 1: Frame Relay y Control de Tráfico
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#LIne Vty 0 4
Router(config-line)#PASsword genios
Router(config-line)#CTRL/Z
Router#
00:50:38: %SYS-5-CONFIG_I: Configured from console by console
Con esto cualquier usuario que sepa la pasword puede acceder al router en modo Usuario. Si además
quisiéramos permitir el acceso vía telnet en modo Privilegiado tendríamos que configurarle al router una
password de enable con el comando ‘enable password password’. Para evitar posibles
problemas nunca asignaremos esta password en las configuraciones, con lo que no permitiremos el acceso
vía telnet en modo Privilegiado a los routers del laboratorio. Así cualquier modificación de las
configuraciones deberá hacerse siempre desde el ordenador que actúa de consola.
P2-27

Práctica 1: Frame Relay y Control de Tráfico
Apéndice II. Restauración de la configuración por defecto en un router.
Excepcionalmente puede suceder que un router no tenga en su NVRAM la configuración por defecto
esperada. Esto puede deberse a que por error se haya borrado la que había, dejándolo sin ninguna
configuración en la NVRAM, o a que se haya grabado una configuración diferente. Si no detecta ninguna
configuración en la NVRAM el router entra al arrancar en el ‘System Configuration Dialog’. En ese caso
debemos abandonar el diálogo y arrancar el router sin configuración. El router entonces genera y carga en
RAM la configuración por defecto, que deberemos salvar en la NVRAM mediante el comando ‘COPy
Running-config Startup-config’. La secuencia de comandos a teclear y mensajes que
aparecen es más o menos la siguiente:
System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
(varios mensajes omitidos)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog?
[yes/no]: No
Would you like to terminate autoinstall? [yes]: (RETURN)
Press RETURN to get started!
(varios mensajes omitidos)
Router>ENable
Router#COPy Running-config Startup-config
En el caso de que la configuración grabada en la NVRAM no sea la configuración por defecto deberemos
borrarla mediante el comando ‘Erase Startup-config’ y luego reiniciar el router, con lo que
estaremos en el caso anterior y seguiremos a partir de ese punto el procedimiento antes descrito. La
secuencia será la siguiente:
Router>ENable
Router#ERase Startup-config
Erasing the nvram filesystem will remove all files! Continue?
[confirm] (RETURN)
[OK]
Erase of nvram: complete
Castellon#RELoad
Proceed with reload? [confirm](RETURN)
00:02:04: %SYS-5-RELOAD: Reload requested
System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
(varios mensajes omitidos)
32K bytes of non-volatile configuration memory.
8192K bytes of processor board System flash (Read/Write)
--- System Configuration Dialog ---
P2-28

Práctica 1: Frame Relay y Control de Tráfico
Would you like to enter the initial configuration dialog?
[yes/no]: No
Would you like to terminate autoinstall? [yes]: (RETURN)
Press RETURN to get started!
(varios mensajes omitidos)
Router>ENable
Router#COPy Running-config Startup-config
El conjunto de opciones y comandos que tiene por defecto el IOS varía con la versión y con el modelo de
router. Por tanto no debemos extrañarnos si la configuración por defecto en dos routers no es idéntica.
P2-29

Práctica 1: Frame Relay y Control de Tráfico
Apéndice III. Explicación de la salida generada por el comando ‘show interface’.
La salida generada por el comando ‘Show INterfaces’ tiene un aspecto similar al siguiente:
RS1(B)#Show INterfaces FastEthernet 0
[1] FastEthernet0 is up, line protocol is down
[2] Hardware is PQUICC_FEC, address is 000c.851f.8ed5 (bia 000c.851f.8ed5)
[3] Internet address is 192.168.9.2/24
[4] MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
[5] reliability 128/255, txload 1/255, rxload 1/255
[6] Encapsulation ARPA, loopback not set
[7] Keepalive set (10 sec)
[8] Full-duplex, 100Mb/s, 100BaseTX/FX
[9] ARP type: ARPA, ARP Timeout 04:00:00
[10] Last input never, output 00:00:08, output hang never
[11] Last clearing of "show interface" counters 00:20:22
[12] Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
[13] Queueing strategy: fifo
[14] Output queue :0/40 (size/max)
[15] 5 minute input rate 0 bits/sec, 0 packets/sec
[16] 5 minute output rate 0 bits/sec, 0 packets/sec
[17] 0 packets input, 0 bytes
[18] Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
[19] 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
[20] 0 watchdog
[21] 0 input packets with dribble condition detected
[22] 122 packets output, 7320 bytes, 0 underruns
[23] 122 output errors, 0 collisions, 0 interface resets
[24] 0 babbles, 0 late collision, 0 deferred
[25] 122 lost carrier, 0 no carrier
[26] 0 output buffer failures, 0 output buffers swapped out
RS1(A)#Show INterfaces Serial 0
[1] Serial0 is up, line protocol is up
[2] Hardware is PowerQUICC Serial
[3] Internet address is 192.168.0.1/30
[4] MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
[5] reliability 255/255, txload 1/255, rxload 1/255
[6] Encapsulation HDLC, loopback not set
[7] Keepalive set (10 sec)
[10] Last input 00:00:06, output 00:00:01, output hang never
[11] Last clearing of "show interface" counters 00:00:37
[12] Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
[13] Queueing strategy: fifo
[14] Output queue :0/40 (size/max)
[15] 5 minute input rate 0 bits/sec, 0 packets/sec
[16] 5 minute output rate 0 bits/sec, 0 packets/sec
[17] 9 packets input, 1666 bytes, 0 no buffer
[18] Received 9 broadcasts, 0 runts, 0 giants, 0 throttles
[19] 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
[22] 5 packets output, 484 bytes, 0 underruns
[23] 0 output errors, 0 collisions, 0 interface resets
[24] 0 output buffer failures, 0 output buffers swapped out
[25] 2 carrier transitions
[26] DCD=up DSR=up DTR=up RTS=up CTS=up
RS1(A)#
P2-30

Práctica 1: Frame Relay y Control de Tráfico
A continuación describimos los campos más importantes:
[1.] Indica si a nivel físico está operativa la interfaz o no (p. ej. si recibe señal de ‘link’ del hub, o si
recdibe señal de reloj del DCE). Si está ‘adminstratively down’ significa que la interfaz está
shutdown en la configuración.
[2.] Indica el tipo de hardware. En Ethernet indica también la dirección MAC.
[3.] Indica la dirección IP y máscara asignadas a esta interfaz (si la interfaz no tiene dirección asignada
esta línea no aparece)
[4.] Indica:
? MTU: La MTU de esa interfaz (tamaño máximo de paquete que se puede enviar por ella).
Configurable con el comando mtu. El valor por defecto depende del tipo de interfaz. En Ethernet
y Serial es 1500, que es el máximo.
? BW: El bandwidth de la interfaz. Configurable con el comando bandwidth. El valor por defecto
depende del tipo de interfaz. Ej.: en Ethernet de 10 Mb/s es 10000.
? DLY: El retardo de la interfaz. Configurable con el comando delay. El valor por defecto depende
del tipo de interfaz. En Ethernet 1 ms, en Serial 20 ms.
[5.] Indica:
? Reliability: Fiabilidad, estimada a partir de la tasa de error, en una escala relativa sobre un
máximo de 255
? txload: la carga, estimada a partir del tráfico saliente (transmit) en una escala relativa sobre un
máximo de 255.
? rxload: la carga, estimada a partir del tráfico entrante (receive) en una escala relativa sobre un
máximo de 255.
[6.] Indica:
? Encapsulation: Tipo de encapsulado. En Ethernet siempre se usa ARPA (Ethernet V. 2.0). En
Serial se puede usar HDLP o PPP.
? Loopback not set: Indica cuando la interfaz está en modo loopback (para diagnóstico de errores).
[7.] [Keepalive set: Indica si la interfaz envía mensajes de keepalive, y con que período (por defecto uno
cada 10 seg).
[8.] En Ethernet indica como se ha negociado el funcionamiento 10/100 Mb/s y half-Full Dúplex.
[9.] En Ethernet indica el tipo de mensajes ARP que utilizará y tiempo de caducidad de las entradas en la
ARP cache (por defecto 4 horas)
[11.] Tiempo transcurrido desde la última vez que se borraron contadores con ‘CLEar Counters’
[15.] Tráfico medio entrante en esa interfaz los últimos cinco minutos, en bits/s y paquetes/s
[16.] Tráfico medio saliente en esa interfaz en los últimos cinco minutos, en bits/s y paquetes/s
[17.] Paquetes y bytes recibidos por esa interfaz. Paquetes descartados por falta de espacio en buffer
de entrada del sistema
[22.] Número total de paquetes y bytes transmitidos por esa interfaz. Los bytes se contabilizan a nivel
de trama MAC.
P2-31