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

P1-1

AMPLIACIÓN DE REDES

PRÁCTICA 1: FRAME RELAY Y CONTROL DE TRÁFICO

Autores: Santiago Felici Hipólito Alós

Rogelio Montañana 1.- Descripción general 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

Práctica 1: Frame Relay y Control de Tráfico

P2-2

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.

Figura 3. Cable serie V.35 DTE de un router Cisco 1721

Conector Smart Serial Conector Winchester Macho (DTE)

1/1 1/2

2/1 2/2


P2-3

Figura 4. Vista frontal, trasera y esquema de un router Cisco 1721 2.- Desarrollo de la práctica 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 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.

Interfaz Fast Ethernet 0

(10/100 BASE-T)

LEDs FDX/100/LIN

K LED WIC 0

OK

WIC 0 (2A/S)

Puerto Consola

WIC 1 (vacío) Interruptor

Enchufe fuente

alimentación

LED Módulo

OK

Interfaz Serial 1

Interfaz Serial 0


P2-4

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 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 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/1 2/1

1/2 2/2

Valencia

Alicante Castellón

Fast Ethernet 0

Serial 0

Serial 0

Serial 0

Fast Ethernet 0

Fast Ethernet 0


P2-5

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-6

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

Tabla 2.- Asignación de direcciones IP a las LANs

Paso 4: Configuración IP de los hosts 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-7

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.

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

Valencia

Alicante Castellón

192.168.10.3/29

192.168.10.1/29

192.168.10.2/29

S0 S0

S0


P2-8

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) ! <salida omitida>


P2-9

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 FRAMe-relay 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-10

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 -> Destino

Valencia Alicante Castellón

Valencia - Alicante - Castellón -

Tabla 4. Relación de DLCI origen-destino


P2-11

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.

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

Frame Relay

IP interface S0: 192.168.____.__

Castellón Alicante

IP interface S0: 192.168.____ .__

IP interface S0: 192.168.____.__

IP interface Fa0:

IP interface Fa0: 192.168.2.1

IP interface Fa0: 192.168.3.1

Valencia

IP: 192.168.2.2

IP: 192.168.1.2

IP: 192.168.3.2


P2-12

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-13

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-14

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-15

Extremo local (Valencia) Extremo remoto PVC Subred 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.

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:

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#

En Alicante:

Valencia

Alicante Castellón

192.168.10.6/30

192.168.10.5/30

192.168.10.2/30

192.168.10.1/30

S0.301 S0.201

S0.102 S0.103


P2-16

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#

Y en Castellón:

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-17

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.

Extremo local (Alicante) Extremo remoto (Castellón) PVC Subred 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.

Figura 8. Esquema de la red con subinterfaces y tres PVCs La configuración a añadir en Alicante será:

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

Valencia

Alicante Castellón

192.168.10.6/30

192.168.10.5/30

192.168.10.2/30

192.168.10.1/30

S0.301 S0.201

S0.102 S0.103

S0.302 S0.203 192.168.10.10/30 192.168.10.9/30


P2-18

Alicante(config-subif)#Frame-relay INTerface-dlci 203 Alicante(config-fr-dlci)#CTRL/Z Alicante#

Y en Castellón:

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-19

Paso 10: Modificación de rutas 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-20

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-21

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-22

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-23

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 Traffic-shaping’ 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 FRAMe-relay Pvc DLCI’, donde DLCI es el número del DLCI del que se quiere obtener la información.


P2-24

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 ‘(config-router)#’. 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-25

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:

? 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

Usuario ‘>’

Privilegiado ‘#’

Configuración Global ‘(config)#’

Configuración de Interfaz

‘(config-if)#’

Configuración de Routing

‘(config-router)#’

ENable EXIt

CONFigure Terminal EXIt o CTRL/Z

Exit Interface interfaz

ROUTER protocol

o

CTRL/Z CTRL/Z

Configuración de Línea

‘(config-line)#’

EXIt EXit LIne línea


P2-26

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-27

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-28

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-29

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-30

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-31

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.

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

Documents

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