GP EnrutadoresCisco PDF

Enrutadores Cisco
Enrutadores Cisco
Antonio Gallego
GUÍAS PRÁCTICAS
Responsable editorial:
Eugenio Tuya Feijoó
Diseño de cubierta:
???????????????????????????
Realización de cubierta:
Cecilia Poza Melero ?????????????????
Reservados todos los derechos. El contenido

de esta obra está protegido por la Ley, que
establece penas de prisión y/o multas, además
de las correspondientes indemnizaciones por
daños y perjuicios, para quienes reproduje-
ren, plagiaren, distribuyeren o comunica-
ren públicamente, en todo o en parte, una
obra literaria, artística o científica, o su
transformación, interpretación o ejecución
artística fijada en cualquier tipo de soporte o
comunicada a través de cualquier medio, sin
la preceptiva autorización.
© EDICIONES ANAYA MULTIMEDIA (GRUPO ANAYA, S.A.), 2009

Juan Ignacio Luca de Tena, 15. 28027 Madrid
Depósito legal: ???????????????????????
ISBN: ?????????????????????????
Printed in Spain
Impreso en: ???????????????????????
Para Nieves, por Nieves (¡y Oscar!).
Agradecimientos
Nadie escribe un libro sin ayuda. Quiero mostrar mi agra-
decimiento a las muchas personas que han contribuido de
forma directa o indirecta a que el lector tenga entre sus manos
esta obra:
En primer lugar a los lectores de la primera edición. Gracias
también a Lorena Ortiz y Eugenio Tuya de Anaya Multimedia
por darme la oportunidad de poner al día el libro.
Mi familia, y especialmente Cecilia Gallego, Mario Sánchez-
Herrero, Hertha Gallego, Quino Torre, Mercedes Durán y José
María Prieto han tenido una enorme paciencia conmigo antes
y durante la redacción del libro. Gracias también a mi padre,
por ser un ejemplo de trabajo y superación.
Esta obra sería muy distinta sin haber tenido el privilegio de
contar con la amistad y los consejos de Francisco José Serrano
Simón, un administrador de sistemas fuera de serie y una de las
pocas personas que conozco que nunca deja nada a medias.
Matt Baxter me dió permiso para usar los elegantes
diagramas que muestran la estructura de las cabeceras
TCP/IP y Randall "xkdc" Munroe me permitió usar el ingenioso
diagrama fractal para explicar el reparto del espacio IP en el
segundo capítulo. Matt, Randall, thanks!!!
Jose Antonio Suárez y Sergio Parras de Networkstest me
ayudaron con la parte de MPLS, aparte de compartir durante
cuatro estupendos años trinchera conmigo. Mención especial
también para Samuel Bonete por sus valiosos consejos.
Otros amigos a los que no quiero dejar de mencionar son
Oscar Puerta Calvo (Trucos), Javier Arroyo Méndez (Jarroyom),
Josep Diaz Ribas (Jos), Randy del Corro (AluminiuM), Juan
Ignacio Rodríguez de León (Euribates) y José Frechín (Túnel
Carpiano). En concreto, ver a Jarroyom analizar logs de Cisco
y salidas de tcpdump como si fueran datos astrofísicos es una
experiencia inolvidable.
Quiero también transmitir mi agradecimiento a dos anti-
guos profesores de la UNED: Emiliano Herrero, por conseguir
durante dos años que los lunes fueran buenos, y Alfonso
Medina, maestro y amigo.
Pero por encima de todo este libro está dedicado a mi mujer,
Nieves Prieto, que además de tomarse con gran filosofía el
tiempo que este proyecto nos ha restado (y ha sido mucho)
me ha dado a Nievitas y a Oscar, nuestros hijos. A los tres,
todo mi cariño.
Sobre el autor
Antonio Gallego tiene
más de 10 años de expe-
riencia administrando
redes Cisco para organiza-
ciones grandes y pequeñas,
entre ellas Capgemini, Net-
workstest, Telefónica Data
y British Telecom, donde
ha desplegado y mante-
nido entornos complejos de
redes y seguridad usando
equipos Cisco, Checkpoint, Stonegate, Nortel y Entrust. Ac-
tualmente es coordinador del área de soporte técnico de
seguridad perimetral e infrastructura de clave pública en el
Grupo SIA. Es autor del libro “Enrutadores Cisco” publicado
por Anaya Multimedia (Madrid 2003). A lo largo de estos
años ha obtenido diversas certificaciones técnicas, entre ellas
el CCNP (Cisco Certified Network Professional), CCDA (Cisco
Certified Design Associate) y CCNA (Cisco Certified Network
Associate). Los lectores pueden visitar su blog que se encuentra
en la dirección http://wanlinksniper.blogspot.com/
o ponerse en contacto con él en la dirección de correo electrónico
redesyseguridad@gmail.com.
Índice
Introducción................................................................................. 15
Cómo usar este libro................................................................... 19
1. Los routers: qué son y cómo funcionan.............................. 23
1.1. ¿Qué es un router?........................................................... 23
1.2. Elementos de interconexión de redes........................... 25
1.3. Cómo funciona un router............................................... 30
1.3.1. Aspectos generales............................................... 30
1.3.2. La tabla de rutas.................................................... 32
1.4. Un ejemplo de red........................................................... 34
1.5. Modelos de routers Cisco............................................... 39
1.5.1. Routers de Servicios Integrados
(Integrated Services Routers)............................ 40
1.5.2 Routers de Agregación (Aggregation)............... 42
1.5.3 Routers para ISPs (Service Aggregation)........... 42
1.6. Cisco, la empresa ............................................................ 43
2. TCP/IP..................................................................................... 45
2.1. Un poco de historia......................................................... 45
2.2. Estructura del protocolo TCP/IP.................................. 47
2.3. La capa de aplicación...................................................... 50
2.4. La capa de transporte...................................................... 50
2.4.1. TCP......................................................................... 51
2.4.2. UDP........................................................................ 55
2.5. La capa Internet............................................................... 57
2.5.1. IP............................................................................. 58
2.5.2. ICMP....................................................................... 60
2.6. La capa de acceso a la red............................................... 63
9
2.6.1. ARP......................................................................... 63
2.6.2. Proxy ARP............................................................. 65
2.6.3. Gratuitous ARP..................................................... 67
2.6.4. Reverse ARP.......................................................... 67
2.7. Direccionamiento IPv4. VLSM. Subnetting................. 68
2.8. Movimiento de paquetes en un enlace......................... 71
2.9. El futuro inmediato de IP: IPv6..................................... 73
2.10. Los RFC........................................................................... 75
3. Operación de un router Cisco............................................... 77
3.1.Componentes de los routers Cisco................................. 77
3.1.1. Componentes Hardware..................................... 77
3.1.2. Componentes Software........................................ 79
3.1.3. Arquitectura.......................................................... 80
3.1.4. Sistema de ficheros del Router........................... 86
3.1.5. Arranque del router............................................. 88
3.2. Instalación y configuración Inicial............................... 89
3.2.1. Instalación inicial.................................................. 89
3.2.1. Métodos de conexión al router .......................... 93
Modo Set-Up................................................................... 99
3.2.4. La línea de comandos ó CLI.............................. 102
3.2.5. Configuraciones Startup vs. running.............. 108
Configuración inicial básica........................................ 111
3.3 Procedimiento de recuperación de contraseñas........ 112
4. Estableciendo conectividad................................................. 119
4.1. Aspectos generales de la configuración
de interfaces................................................................... 120
4.2. Conectividad LAN........................................................ 125
4.2.1. Ethernet (IEEE 802.3).......................................... 126
4.2.2. FastEthernet......................................................... 129
4.2.3. GigaEthernet....................................................... 132
4.2.4. ATM...................................................................... 134
4.2.5. TokenRing (IEEE 802.5)..................................... 137
4.2.6. Wireless (IEEE 802.11)........................................ 138
4.2.7. Power Line Communication (PLC).................. 142
4.3. Conectividad WAN....................................................... 142
4.3.1. Interfaz Serie........................................................ 144
4.3.2. Conexiones Punto a Punto................................ 146
4.3.3. Frame Relay......................................................... 150
4.3.4. RDSI...................................................................... 160
10
4.3.5. ADSL y xDSL...................................................... 165
4.3.6. Cable y DOCSIS.................................................. 167
4.3.7. MPLS.................................................................... 169
4.4. Interfaces Lógicas.......................................................... 172
4.4.1. Terminales Virtuales (VTY).............................. 173
4.4.2. Loopback Interface............................................. 175
4.4.3. Null Interface...................................................... 176
4.4.4. Interfaces de túnel (tunnel)............................... 177
4.5. Interfaces Especiales...................................................... 178
4.5.1. El Puerto de Consola (CON)............................. 178
4.5.2. El Puerto Auxiliar (AUX).................................. 178
4.5.3. Interfaces de voz................................................. 179
4.5.4. Puertos asíncronos (TTY).................................. 181
5. Protocolos de Enrutamiento............................................... 183
5.1. Conceptos básicos del enrutamiento.......................... 183

5.1.1. La tabla de rutas.................................................. 185
5.1.2. Convergencia....................................................... 186
5.1.3. Métrica.................................................................. 187
5.1.4. Distancia administrativa.................................... 187
5.1.5. Tipos de enrutamiento....................................... 188
5.1.6. Enrutamiento: problemas y soluciones........... 193
5.2. Rutas Estáticas............................................................... 194
5.2.1. Conceptos............................................................ 194
5.2.2. Configuración...................................................... 194
5.2.3. Escenarios............................................................ 196
5.3. RIP.................................................................................... 199
5.3.1. Conceptos............................................................ 199
5.3.2. RIP en acción....................................................... 200
5.3.3. Configuración...................................................... 202
5.3.4. Escenarios............................................................ 204
5.4. EIGRP.............................................................................. 205
5.4.1. Conceptos............................................................ 205
5.4.2. EIGRP en acción: DUAL.................................... 209
5.4.3. Configuración...................................................... 210
5.4.4. Escenarios............................................................ 210
5.5. OSPF........................................................................ 212
5.5.2. OSPF en acción.................................................... 213
5.5.3. Configuración...................................................... 218
5.5.4. Escenarios............................................................ 221
11
5.6. BGP.................................................................................. 222
5.6.1. Conceptos............................................................ 222
5.6.2. BGP en acción...................................................... 225
5.6.2. Configuración...................................................... 226
5.6.3. Escenarios............................................................ 228
5.7. Enrutamiento no IP....................................................... 228
5.7.1. Enrutamiento con IPX........................................ 228
5.7.2. Enrutamiento con AppleTalk........................... 230
5.7.3. Otros protocolos de enrutamiento................... 232
5.8. Policy Routing................................................................ 232
5.9. Passive interface............................................................ 234
5.10. Redistribución y filtrado............................................. 234
5.11. Resumen....................................................................... 236
6. Seguridad............................................................................... 237
6.1. Medios, Motivos y Oportunidades............................. 237

6.2. Listas de acceso.............................................................. 242
6.2.1. Listas de acceso estándar................................... 244
6.2.2. Listas de acceso extendidas............................... 252
6.2.3. Listas de acceso con nombre............................. 256
6.2.4. Controlando el acceso al router........................ 257
6.2.5. Ejemplos............................................................... 258
6.3. Autenticación................................................................. 261
6.3.1. Creación de cuentas en el router...................... 263
6.3.2. Gestión centralizada de contraseñas................ 265
6.3.3. Cifrado de passwords........................................ 266
6.3.4. Precauciones generales al configurar
contraseñas......................................................... 267
6.4. Desactivación de servicios (hardening)...................... 268
6.4.1. Finger.................................................................... 270
6.4.2. tcp small-servers/udp small-servers............... 271
6.4.3. http-server........................................................... 271
6.4.4. CDP (Cisco Discovery Protocol)....................... 272
6.4.5. ip redirects/ip source-route.............................. 273
6.4.6. ip directed-broadcast......................................... 273
6.4.7. Banner.................................................................. 273
6.4.8. validate-update-source...................................... 274
6.4.9. Limitación de los tiempos
de las sesiones.................................................... 275
6.5. Logs................................................................................. 275
12
6.6. Criptografía e IPSec....................................................... 277
6.6.1. Criptografía......................................................... 278
6.6.2. IPSec..................................................................... 278
7. Configurando servicios........................................................ 281
7.1. NAT................................................................................. 281
7.1.1. Fundamentos....................................................... 281
7.1.2. Configuración...................................................... 283
7.1.3. Monitorización.................................................... 290
7.2. Interfaces de respaldo y HSRP.................................... 291
7.2.1. Fundamentos....................................................... 292
7.2.2. Configuración...................................................... 294
7.2.3. Monitorización.................................................... 295
7.3. DHCP.............................................................................. 296
7.3.1. Fundamentos....................................................... 296
7.3.2. Configuración...................................................... 296
7.3.3. Monitorización.................................................... 297
7.4. SNMP.............................................................................. 298
7.4.1. Fundamentos....................................................... 298
7.4.2. Configuración...................................................... 298
7.4.3. Monitorización.................................................... 300
7.5. NTP.................................................................................. 301
7.5.1. Fundamentos....................................................... 301
7.5.2. Configuración...................................................... 301
7.5.3. Monitorización.................................................... 302
7.6. SLB................................................................................... 302
7.6.1. Fundamentos....................................................... 302
7.6.2. Configuración...................................................... 303
7.6.3. Monitorización.................................................... 304
8. Resolución de Problemas.................................................... 307
8.1. Aspectos y métodos generales..................................... 307
8.1.1. Entender el problema......................................... 309
8.1.2. Diseñar un plan................................................... 310
8.1.3. Ejecutar el plan.................................................... 310
8.1.4. Comprobar la solución...................................... 311
8.2. Métodos específicos...................................................... 311
8.2.1. Comprobando el nivel físico............................. 312
8.2.2. Comprobando el nivel de enlace...................... 322
8.2.3. Comprobando el nivel de red........................... 325
8.2.3. Comprobando los niveles superiores.............. 331
13
8.3. Herramientas y documentación el sistema................ 335
8.3.1. Documentación................................................... 335
8.3.2. Mapas de la red................................................... 336
8.3.3. Configuraciones.................................................. 336
8.3.4. Internet como herramienta de resolución
de problemas...................................................... 337
A. Apéndice................................................................................ 339
A.1. Planos de funcionamiento de un router.................... 339
A.2. Red MPLS-BGP-Frame Relay..................................... 340
A.3. RED RIP......................................................................... 355
A.4. PUERTOS TCP/UDP................................................... 361
A.5. Procedimiento de recuperación de contraseñas...... 366
A.6. Cabeceras de los protocolos........................................ 371
Índice alfabético........................................................................ 375
14
Introducción
"No es adecuado pensar en las redes en términos de conexión

de ordenadores. Más bien, las redes conectan a la gente a través
de ordenadores. El gran éxito de Internet no es técnico, sino
humano". RFC-1336, David Clark.
Hace unos pocos años los ordenadores personales eran

aparatos aislados dotados de un único procesador que no
hacían más de una tarea a la vez. Las redes de ordenadores
quedaban para las grandes organizaciones, como los bancos, y
consistían fundamentalmente en caros y lentos enlaces contra
los ordenadores centrales. Todo esto ha cambiado. El sostenido
aumento de la potencia de los microprocesadores unido al
abaratamiento de los sistemas de interconexión ha llevado a
que una más de las tareas rutinarias de los informáticos consista
en instalar y mantener redes de ordenadores que permitan el
acceso simultáneo de múltiples clientes a toda clase de recursos.
Los usuarios han asimilado la nueva forma de trabajar asociada
a los sistemas distribuidos y ya no se concibe el trabajar sin
el correo electrónico, compartiendo información, accediendo
a bases de datos situadas en cualquier lugar y, por supuesto,
navegando por Internet. Los vendedores necesitan conectarse
a los recursos corporativos desde diferentes ubicaciones y las
delegaciones se encuentran continuamente conectadas con la
red central de la empresa.
A la hora de diseñar una red local contamos con distintos
elementos de red. Tenemos por un lado los hubs, que actúan
como repetidores. También tenemos dispositivos de red como
los bridges, que dividen la red en segmentos, de forma que
los paquetes que circulan por un segmento no chocan con los
que circulan por los otros. Mayores posibilidades ofrecen los
15
switches, una mezcla de hub y bridge. Pero a la hora de interco-
nectar redes locales separadas geográficamente se necesitan
dispositivos capaces de tomar decisiones más complejas.
Estos aparatos son los routers, verdaderos ordenadores que
se dedican a aprender redes y a tomar decisiones basadas en
la tabla de rutas (los mapas de carreteras de la red) que van
construyendo.
Una forma de entender el papel de los routers consiste en
pensar en las redes locales como ciudades y en los routers como
sus aeropuertos. Cuando un paquete tiene que viajar a otra red,
localiza el "aeropuerto" local, pasa los controles necesarios y
finalmente es transportado hasta otro "aeropuerto" cercano a
su destino. Los paquetes forman colas antes de poder despegar
y, de nuevo al aterrizar, sufren en camino las perturbaciones
del "mal tiempo", etcétera. Existen paquetes que falsifican su
documentación, algunos que viajan con más equipaje que otros,
tenemos primera clase y turista, y por supuesto hay una torre
de control coordinando todas las operaciones.
Cada vez es más habitual contar con al menos un router en
cada red local. De hecho, para conectarnos a Internet por banda
ancha los proveedores nos mandan un router ADSL o un cable
modem y cuando visitamos nuestras páginas web favoritas la
información es encaminada a través de estos aparatos, algunos
con nombres tan sonoros como MAE-WEST.
Se espera de un administrador que sepa cómo manejar
todos estos dispositivos. Pero mientras que los switches son
elementos que a menudo se pueden conectar directamente sin
que se precise una mayor configuración (al menos en entornos
sencillos), los routers no se pueden conectar sin más. Necesitan
una configuración mínima para poder funcionar y, en redes
de cierta complejidad, puede llegar a ser necesaria una cierta
administración si esperamos que aprenda a obtener informa-
ción de las redes y recursos remotos.
En este libro mostramos cómo se trabaja con routers
Cisco, pero los principios aplicados al trabajar con los routers
de esta popular marca son los mismos que se utilizan para
manejar los de cualquier otra, por ejemplo Juniper o Nortel.
Los conceptos fundamentales son los mismos, y a lo largo
del libro insistiremos en un conjunto de ideas básicas que
no varían, independientemente de la marca de router que
estemos utilizando.
Si existen otras marcas ¿por qué centrarnos en Cisco?
Aprender el manejo de los routers Cisco es particularmente
útil debido a que un gran porcentaje de los routers instalados
16
son de esta marca. Son fiables, su manejo es sencillo, imple-
mentan una enorme cantidad de protocolos y funciones, sus
prestaciones aumentan de forma continua y la oferta de mo-
delos es sencillamente impresionante. Los routers Cisco usan
un sistema operativo común a todos ellos denominado IOS,
de forma que lo gran parte de lo aprendido sobre un router
pensado para la pequeña oficina como el Cisco 877 nos servirá
cuando tengamos que enfrentarnos a un router de gama alta
como un Cisco 7200. De hecho no sólo los routers Cisco sino
gran parte de los switches Cisco Catalyst también usan el
sistema operativo IOS, y la interfaz de los PIX Firewalls y los
Cisco Adaptative Security Appliances tiene muchos puntos en
común con la interfaz IOS usada por los routers Cisco.
17
Cómo usar este libro
"Fue como si alguien hubiese levantado la tapa de la vida

para mostrarle el mecanismo". Dashiell Hammett, El Halcón
Maltés.
El objetivo de este libro es levantar la tapa de las redes para

mostrar su mecanismo. El hilo conductor son los routers Cisco,
cuyo funcionamiento iremos desgranando a lo largo de los
ocho capítulos en los que el libro está dividido:
El primer capítulo tiene por objetivo explicar qué es un
router y qué función cumple en una red. Se presentan los
conceptos fundamentales a través de sencillo ejemplo.
El segundo capítulo presenta el protocolo TCP/IP, que es
el usado en la mayoría de los ejemplos del libro y el estándar
predominante en la industria de las telecomunicaciones.
El objetivo del tercer capítulo es enseñar a manejar un router
Cisco. Al terminar de leer este capítulo conoceremos diversas
opciones para acceder al router, habremos visto en detalle la
interfaz de comandos, y sabremos introducir una configuración
básica. También veremos como realizar operaciones frecuentes
de administración del router tales como la obtención de copias
de seguridad de los archivos que se albergan en el router o el
procedimiento de recuperación de contraseñas.
En el cuarto capítulo examinaremos la configuración de las
interfaces del router y aprenderemos a establecer conectividad
LAN y WAN entre dispositivos.
El quinto capítulo entra de lleno en el núcleo de la admi-
nistración de los routers. Veremos los conceptos del routing y
describiremos cómo se configuran algunos de los principales
protocolos de enrutamiento (RIPv2, EIGRP, OSPF y BGPv4).
19
El sexto capítulo trata un tema cada vez más importante: la
seguridad de redes. Se estudian las listas de acceso, los meca-
nismos de autenticación, autorización y auditoría (AAA), ve-
remos cómo deshabilitar servicios innecesarios y se presentan
conceptos de criptografía, túneles encriptados y VPNs.
En el séptimo capítulo vemos cómo configurar diversos
servicios en el router tales como el NAT, DHCP, HSRP, NTP,
SLB, interfaces de respaldo...
En el capítulo octavo se presentan varias estrategias orien-
tadas a la resolución de problemas de redes, se propone
un método general y se ven a fondo las herramientas más
importantes que tenemos a nuestra disposición a la hora de
resolver incidencias.
Los apéndices del libro muestran las configuraciones com-
pletas de varios de los ejemplos, así como tablas, procedi-
mientos e información que conviene tener a mano.
El material aquí presentado se asimilará mejor si el lector
tiene acceso a una red en la que existan routers Cisco, pero
conviene hacer aquí una advertencia: aunque muchos de los
comandos (especialmente los de tipo "show") pueden ejecu-
tarse sin problemas sobre un router, se debe tener presente
que cambios mínimos en la configuración de una máscara de
red o una lista de acceso o ciertas pruebas como los "debug"
pueden comprometer la estabilidad de la red y provocar una
incomunicación parcial e incluso total. No conviene experi-
mentar con una red en producción sin tener una idea clara
de cómo dar marcha atrás los cambios realizados llegado el
momento. En caso de duda conviene ejercitar la prudencia,
preguntar al responsable o al administrador de la red y pedir
los permisos necesarios.
Asimismo, aunque se ha puesto el máximo cuidado en la
elaboración de los ejemplos, cada administrador deberá evaluar
la solución adecuada a su entorno. Los ejemplos utilizados no
pretenden ser soluciones únicas u óptimas a los problemas
que se plantean, y se ha antepuesto el sentido didáctico en
todos los casos.
A lo largo del libro se han incluido enlaces a diversas
páginas Web en las que ampliar la información. Conviene no
obstante mencionar ahora dos fuentes de información funda-
mentales: la primera es la página Web de Cisco, accesible en
la dirección http://www.cisco.com/. Esta página es de
consulta obligada para los administradores de redes basadas
en los equipos de esta marca. La otra fuente de información
esencial la constituyen los RFC (Request For Comments). Las
20
"Peticiones de Comentarios" son los documentos que establecen
los estándares de los protocolos de Internet y se pueden con-
sultar en la dirección http://www.rfc-editor.org/. A medida
que presentemos los diversos protocolos iremos dando los
RFC correspondientes.
Y ahora, ¡ configure terminal", "enable" y "show
RoutersCisco2009"!
21
1
Los routers: qué son
y cómo funcionan
En este capítulo vamos a ver qué es un router y el lugar

que ocupa dentro de varios modelos de referencia de inter-
conexión de redes. También examinamos cómo funcionan los
routers desde distintas perspectivas y terminamos el capítulo
revisando la familia de routers Cisco.
1.1. ¿Qué es un router?

Un router es un ordenador que mantiene conexiones con
varias redes, permitiendo y regulando la comunicación entre
ellas.
Los routers se sitúan en la frontera de las redes, uniendo
y separando a la vez unas redes de otras. Como nos vamos a
dedicar durante el resto del libro a ver la forma de interconectar
redes mediante routers, nos detendremos primero unos ins-
tantes a definir qué entendemos por redes y ver los principales
elementos que las componen.
Las redes están constituidas por un conjunto de sistemas
finales o nodos, unidos mediante una serie de elementos de
interconexión a través de los cuales, los sistemas finales se
interconectan e intercambian mensajes. La transmisión de los
mensajes está gobernada por un conjunto de reglas a las que
se conoce como el "protocolo de red".
De los sistemas finales poco más tenemos que decir por
ahora. Se trata de los ordenadores personales, PDAs, impre-
soras... que albergan las aplicaciones que hacen uso de la red
(transferencia de ficheros, correo electrónico, navegación,
juegos...). Estas aplicaciones se apoyan a su vez en los sis-
temas operativos correspondientes (Windows, Linux, Mac OS
23
X, Symbian, Android...) que, entre otras cosas, proporcionan a
las aplicaciones las herramientas necesarias para conectarlas
a las redes. Estos nodos se unen entre si mediante una serie
de elementos de conexión a través de los cuales los sistemas
finales se comunican e intercambian mensajes. La transmisión
de los mensajes está gobernada por un conjunto de reglas a las
que se conoce como el "protocolo de red".
Para que los sistemas puedan comunicarse no basta con
que haya unos emisores y receptores por un lado (ordena-
dores) y un medio de transmisión por otro (cables, routers...).
El emisor tiene que ser capaz de identificar con claridad al
receptor del mensaje, debe asegurarse de que el receptor esté
preparado para recibir y almacenar la información, y debe
haber un acuerdo en cuanto al formato que este mensaje
debe tener. Los sistemas que forman parte de una red de
comunicaciones deben, en definitiva, cooperar para que el
intercambio de información tenga lugar. Se denomina pro-
tocolo al conjunto de reglas que definen qué, cómo y cuándo
se comunica.
Los sistemas que participan en las redes deben manejar
muchos aspectos de la comunicación tales como el formato de
los datos (sintaxis), la señalización de control y el manejo de
errores (semántica) o la definición de velocidades y la secuen-
ciación correcta (temporización)... Integrar todas estas tareas
en un único componente, sea hardware o software, no resulta
práctico. El diseño, construcción y manejo de sistemas de redes
monolíticos resultaría demasiado difícil. Una aproximación
adecuada consiste en dividir los problemas en otros más sim-
ples. Concretamente los sistemas de redes tradicionalmente se
dividen en capas (layers), y cada una de estas capas se comunica
con su homóloga en el sistema receptor. Esta división de tareas
puede hacerse de distintas formas, dando lugar a las distintas
arquitecturas de red.
Las arquitecturas de red dividen las tareas a realizar en
módulos o capas. Uno de los modelos más extendidos, el
modelo OSI, divide el proceso de comunicación en 7 capas o
niveles. Cada una de estas capas reúne una serie de funciones
conceptualmente similares, proporcionando servicios a la capa
superior y recibiendo servicios de la inferior. La ventaja fun-
damental de aislar estas funciones del resto en una capa inde-
pendiente es que el resto de módulos no tienen que ocuparse
de las características concretas de la red a la que el ordenador
está conectado, proporcionando abstracción e independencia
ante posibles cambios.
24
Tabla 1.1. Modelo OSI.
Nivel Descripción Unidad de Ejemplo
Físico Maneja las especifi- bit Hub

caciones físicas,
eléctricas.
Enlace Proporciona una Frame, Bridge,
conexión sin errores marco switch
Red Direcciona, conmuta Paquetes Router
y enruta
Transporte Garantiza la conexión Segmentos Router NAT,
de extremo a extremo. o Firewall
datagramas
Sesión Administra las Mensajes
sesiones entre hosts.
Presentación Traduce formatos, Mensajes
comprime y encripta
Aplicación Facilita a las aplica- Mensajes
ciones servicios de
acceso a la red.
A medida que la información va "bajando" desde las apli-

caciones hasta el nivel físico cada capa va empaquetando los
datos recibidos junto con información adicional correspon-
diente a esa capa. Este proceso se llama encapsulación.
Nota: En la práctica la arquitectura dominante es la pila de

protocolos TCP/IP, que veremos a fondo en el capítulo 2.
De los tres elementos que conforman las redes (sistemas

finales, elementos de interconexión y protocolos) este libro
se centra específicamente en los routers como elementos de
interconexión mediante el protocolo de red TCP/IP.
1.2. Elementos de interconexión

de redes
Para conectar los nodos, equipos y redes disponemos de
diferentes elementos de interconexión. Los más básicos que
podemos usar para esta tarea son los hubs o concentradores.
25
Los hubs actúan como repetidores. Para conectar un equipo
a la red local basta con tirar un cable desde su tarjeta de red
hasta una boca disponible del concentrador. Los concentra-
dores no necesitan ser configurados para empezar a usarlos.
El principal inconveniente de los concentradores se encuentra
en su misma sencillez. Los concentradores proporcionan una
forma de compartir el medio físico de transmisión. Se trata de
dispositivos que funcionan en la capa física o nivel 1 del mo-
delo OSI, y no evitan los problemas derivados de las colisiones
en las redes: cuando dos o más equipos transmiten a la vez, se
produce una colisión entre los paquetes que ponen en la red y
se pierden los dos mensajes. En redes con muchos equipos la
comunicación puede llegar a degradarse en extremo debido
a este problema.
Figura 1.1. Las colisiones son malas para el tráfico en general.
Para hacer frente al problema de las colisiones tenemos los

bridges ó puentes. Los puentes dividen las redes en segmentos,
cada uno de los cuales constituye un dominio de colisión: los
paquetes que circulan por un segmento no chocan con los que
circulan por los otros segmentos.
Los puentes funcionan usando la información adicional de
la capa 2 del modelo OSI, lo que permite identificar el origen
y el destino de los paquetes de datos mediante un sistema
de direcciones. Cada tarjeta de red lleva grabada de fábrica
una dirección única (la dirección MAC) que la identifica.
Los puentes construyen tablas y aprenden "en qué lado" se
encuentra cada equipo en función de dicha dirección MAC.
Cada "lado" representa un dominio de colisión. Los dominios
de colisión no chocan entre sí y de esta forma evitan que de-
26
terminados paquetes ocupen el medio de las redes a las que
no están destinados.
La evolución natural de los puentes son los switches o con-
mutadores, una mezcla de concentrador y puente. En redes
sencillas estos puentes y conmutadores no precisan ninguna
configuración inicial para empezar a funcionar.
Sin embargo queda un problema por resolver que los
puentes que los switches no solucionan: muchos de los men-
sajes que circulan por las redes no tienen un único destinatario.
Son los llamados paquetes de broadcast o de difusión, que
transportan mensajes dirigidos a múltiples receptores. Estos
paquetes atraviesan hubs y switches y pueden producir pro-
blemas de tráfico en las redes. Estos problemas ocasionados
por las difusiones se notan especialmente a la hora de conectar
redes locales separadas geográficamente. Los enlaces entre
redes distantes son bastante lentos en relación con la velocidad
de las redes locales. Si dichos enlaces se inundan de difusiones
la comunicación se degradaría hasta límites insoportables,
sobre todo al trabajar con redes con cientos de hosts y domi-
nios de broadcast enormes, en los que hay una gran cantidad
de tráfico que ha de ser procesado por todos los hosts.
Los switches algo más avanzados permiten agrupar con-
juntos de puertos o interfaces en LANs virtuales (o VLANs),
que separan el tráfico y mantienen las difusiones controladas.
En el ejemplo de la Figura 1.2 vemos una red de hubs inter-
conectada por medio de un switch central, que separa la red
física en dos redes virtuales: la VLAN 10 y la VLAN 20. Las
redes así formadas no se ven entre sí, Al quedar aislado cada
dominio de difusión hará falta un dispositivo de capa 3 (como
un router) para interconectar las VLANs así formadas.
Se necesitan dispositivos capaces de tomar decisiones más
complejas, que hagan un uso eficiente del ancho de banda de las
costosas y relativamente lentas líneas de comunicaciones. Estos
aparatos son los routers ó enrutadores, que usan la información
del nivel 3 del protocolo OSI (capa de red). Los routers son
ordenadores que se dedican a aprender qué redes hay, dónde
están esas redes y a tomar decisiones basadas en la tabla de
rutas (los mapas de carreteras de las redes) que van constru-
yendo. Los routers, al igual que los switches, dividen las redes
en dominios de difusión, bloqueando el paso de los paquetes
que no tengan un destino específico. En la Figura 1.3 vemos los
elementos de interconexión de los que hemos hablado junto
con el icono con el que suelen representarse en los diagramas
de red y la capa el modelo OSI en la que funcionan.
27
Figura 1.2. Dominios de Colisión y de Difusión
Figura 1.3. Cada elemento de interconexión trabaja

con la información específica de una capa del modelo OSI.
La aplicación [1] en el Host A (cliente) quiere conectarse

con un servicio alojado en el Host B [6] (servidor). La informa-
ción baja por la pila de protocolos hasta que la tarjeta de red
del Host la pone en la red [2]. Ahí es recibida y amplificada
primero por un hub [3], básicamente un repetidor que trabaja
"a nivel físico" amplificando señales (los pulsos eléctricos que
representan los bits). Luego los paquetes son recibidos por
un switch [4] que usa la información contenida "a nivel de en-
lace" en las cabeceras de los paquetes (por ejemplo direcciones
28
MAC) para separar el tráfico. A continuación la información
es recibida por un router [5] que trabaja "a nivel de red", de
forma que los paquetes suben hasta la capa de red de la pila de
protocolos del router para extraer las direcciones de red (típi-
camente direcciones IP) y se decide cómo se deben distribuir
(por qué interfaz de red se debe sacar el paquete). El paquete
llega finalmente al servidor [6], que lo procesa hasta llegar a
la aplicación final.
A lo largo resto del libro veremos lo que se puede hacer
con un router, pero quisiera destacar aquí dos aspectos carac-
terísticos de los routers:
Por un lado, los routers son capaces de interconectar redes
de tipos distintos. Es frecuente, por ejemplo, que los routers
ADSL conecten una red local con una red ADSL y que a la vez
sirvan de punto de acceso inalámbrico. Es este caso el router
estaría conectando tres clases distintas de medios de redes
(Ethernet, ATM y WiFi), cada una de ellas regida por su sis-
tema de reglas o protocolo de capa 2.
Figura 1.4. Los routers tienen una dirección

para cada red a la que se conectan
La segunda característica de los routers es que tienen una

dirección en cada una de las redes a las que están conectados.
El router central de la Figura 1.4 posee dos direcciones IP, la
192.168.1.1/30 y la 192.168.2.1/30, con las que se presenta
correctamente en cada una de las redes a las que está conec-
tado. Los sistemas que componen una red están localizados
por un mecanismo de direcciones. Parte de estas direcciones
identifica la red y es común a todos los elementos que la com-
ponen, y parte de la dirección identifica de forma única cada
uno de los elementos individuales. Los routers se pueden ver
como puertas entre las distintas redes. Cada una de las redes
conectadas a un router "ve" su lado de "la puerta". La dirección
del router dentro de cada red sería el picaporte de la puerta.
Cuando los equipos de una red necesitan comunicarse con los
de otras redes envían la información al router, y este se encarga
29
de reenviarla hacia la red de destino, comunicándose con otros
routers intermedios si es necesario.
1.3. Cómo funciona un router
1.3.1. Aspectos generales

Los routers realizan fundamentalmente dos funciones: por
un lado deben mantener actualizada la información de las rutas
disponibles en una serie de tablas, siendo la más importante la
tabla de enrutamiento, y por otro lado tienen que mover física-
mente (conmutar) los paquetes de una interfaz a otra.
Desde un punto de vista hardware, un router es un orde-
nador con muchas tarjetas de red (Ethernet, WiFi, WAN), alta-
mente especializado pero cuya arquitectura interna no difiere
de forma fundamental de la cualquier ordenador "tradicional".
Así, posee un procesador, memorias de varias clases, buses
de conexión de los distintos elementos y conectores para dife-
rentes tipos de redes locales y extensas. Es el software el que
le proporciona al router su especial personalidad. El sistema
operativo de los routers Cisco es el IOS (Internetwork Operative
System). Se trata de un sistema operativo especialmente creado
para conmutar paquetes de datos de la forma más rápida y
eficiente posible.
IOS parte de los mismos conceptos que otros sistemas
operativos, proporcionando a los desarrolladores una capa de
abstracción del hardware así como los elementos de gestión
de los recursos del dispositivo (CPU, memoria, disco…) que
permiten que éstos sean compartidos entre las distintas aplica-
ciones que corren en el router. Precisamente una función central
de IOS es la de permitir la ejecución concurrente de distintos
procesos. Para ello proporciona mecanismos de planificación
(scheduling) para decidir qué proceso pasa a ejecutarse en un
momento dado.
Nota: Una de las características más interesantes del IOS

es que ofrece una forma común de administración de los
dispositivos a través de un intérprete de comandos (el CLI
ó Command Line Interface) compartido por múltiples plata-
formas. La mayoría de lo aprendido sobre un Cisco 2600 es
perfectamente válido al enfrentarnos a un 7400.
30
Otra forma típica de organizar las funciones de los routers es
en Planos. Así, las funciones relacionadas con el mantenimiento
de las tablas de enrutamiento o routing caería dentro del Plano
de Control, y las funciones relacionadas con la conmutación
o switching de los paquetes entre interfaces caerían dentro del
Plano de Datos. Hay otros dos planos más, el Plano de Gestión
y el Plano de Servicios.
Figura 1.5. Planos de control de los routers
Nota: El Plano de Control se encarga de ejecutar protocolos

de enrutamiento, mantener tablas de rutas, interpretar y
ejecutar comandos (CLI), incrementar contadores, ICMP…
mientras que el Plano de Datos se encarga de la regeneración
de la señal (capa 1, física), reescribir las cabeceras y el valor
CRC (capa 2, enlace), decrementar el campo TTL y recalcular
el CRC (capa 3, red)… En el Apéndice A "Planos de funcio-
namiento de un router" describimos en detalle esta división
de las funcionalidades de los routers en planos.
La función central del router, como el resto de elementos

de transmisión, es la de mover los paquetes entre los distintos
segmentos de red a los que pertenece. Al margen del resto de
las funciones realizadas por los routers, todo gira en torno a la
capacidad del router de recibir un paquete en una de sus in-
terfaces, almacenarlo (store) en una memoria temporal (buffer),
inspeccionar la dirección de destino del paquete comparándola
con las direcciones a las que el router sabe enviar paquetes y, si
se encuentra un destino en las tablas manejadas por el router,
reenviar (forward) el paquete por la interfaz correspondiente.
El router no sólo recibe, almacena y retransmite los pa-
quetes, sino que por el camino regenera la señal física, reescribe
las cabeceras, decrementa contadores (concretamente el pará-
31
metro tiempo de vida, TTL o Time to Live del paquete) y recal-
cula las sumas de control (CRCs) de los paquetes resultantes.
En realidad el problema no es tanto cómo realizar todas
estas funciones, sino realizarlas rápido. De hecho, la capacidad
de conmutación de los routers es una de las características más
publicitadas. Los routers Cisco han ido incorporando meca-
nismos de conmutación de paquetes cada vez más complejos
(Process Switching, Fast Switching, Optimum Switching, Cisco
Express Forwarding…)
Pero si importante es conmutar paquetes, también lo
es el mantener una estructura de datos con la que tomar
decisiones acerca de los paquetes. El Plano de Control del
router ejecuta los protocolos de enrutamiento escuchando la
información proporcionada por los routers vecinos e infor-
mándoles a su vez de los cambios que detecte en la red. Con
la información recibida elabora y mantiene actualizadas las
tablas de rutas.
1.3.2. La tabla de rutas

Enrutar consiste en encontrar caminos entre el emisor y el
receptor de la información. Mientras el mensaje permanece
dentro de una red, el encaminamiento de la información es
resuelto por la tecnología específica de la red. Pero cuando los
mensajes deben pasar de un origen en una red a un destino en
otra distinta aparece la necesidad de enrutamiento.
En tal caso el mensaje debe encontrar y atravesar la puerta
de enlace, o router, que interconecta ambas redes. Si las redes
no son adyacentes el mensaje podría pasar a través de varias
redes y de las puertas de enlace que las interconectan. Una vez
que el mensaje llega a un router que está en la misma red que
el destinatario estamos de nuevo en el caso inicial, responsa-
bilizándose la tecnología de la red local de llevar el mensaje
hasta el receptor basándose en las direcciones de capa 2, por
ejemplo las direcciones MAC.
Hay dos formas básicas de enrutamiento: estático y diná-
mico. Las rutas estáticas se configuran en el router y envían
los paquetes por puertos determinados de antemano. Entre sus
ventajas está la seguridad que proporcionan y el uso óptimo
de los recursos del router (no consumen ancho de banda en el
intercambio de rutas, ahorran ciclos de la CPU, precisan muy
poca memoria…), pero tienen un grave inconveniente: si la
red falla o cambia es tarea del administrador el reprogramar
manualmente los routers de acuerdo con los cambios.
32
Los protocolos de enrutamiento dinámico son usados por
los routers para descubrir automáticamente nuevas rutas. El
uso de estos protocolos permite a los administradores de red
centrarse en otras tareas como las de diseño o mejora de la
calidad del servicio.
Los routers organizan las rutas (programadas estática-
mente u obtenidas dinámicamente) en una tabla de rutas. En
estas tablas almacenan las direcciones de las redes junto con
la información de la interfaz por la cual se alcanza cada red, la
métrica (o coste) para alcanzar el destino y otros datos con los
que el router calcula las mejores rutas. Las principales métricas
usadas son los saltos (número de redes que hay que atravesar
para alcanzar el destino), la velocidad de los enlaces (el ancho
de banda), tiempos…
La tercera parte del libro estudia el enrutamiento estático
y dinámico en profundidad pero, mientras tanto, veamos el
aspecto que tiene una tabla de rutas y la información que se
puede extraer de la misma.
Nota: A continuación vamos a mostrar algunos comandos

y salidas de routers, ¡y todavía no hemos explicado como se
entra en ellos! En el capítulo 3 veremos en detalle las distintas
formas de acceder a los routers y todo lo necesario para trabajar
con ellos.
Para ver la tabla correspondiente al protocolo IP introdu-

cimos el comando "show ip route":
Router#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 10.0.0.100 to network 0.0.0.0

C 10.0.0.0/24 is directly connected, Ethernet0
C 172.16.0.0/24 is directly connected, Serial0
R 192.168.1.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
R 192.168.2.0/24 [120/2] via 172.16.0.2, 00:00:04, Serial0
R 192.168.3.0/24 [120/2] via 10.0.0.2, 00:00:16, Ethernet0
[120/2] via 172.16.0.2, 00:00:04, Serial0
R 192.168.4.0/24 [120/1] via 10.0.0.2, 00:00:16, Ethernet0
R 192.168.5.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
R 192.168.6.0/24 [120/2] via 10.0.0.2, 00:00:17, Ethernet0
R 192.168.7.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
S* 0.0.0.0/0 [1/0] via 10.0.0.100
Tras introducir el comando aparece una leyenda que nos

permite interpretar la primera columna de la tabla. Se trata de
33
los códigos que identifican al sistema de aprendizaje de rutas.
Vemos en el ejemplo rutas de tres clases: unas marcadas con una
R que representa las rutas hacia redes aprendidas mediante el
protocolo dinámico RIP, otras marcadas con una C, que son las
redes que el router conoce por que está directamente conectado
a ellas (tiene interfaces configuradas con direcciones de esas
redes) y una ruta estática, marcada con una S. Esta última ruta es
además la ruta por defecto y viene indicada con un asterisco.
A continuación aparecen las redes aprendidas, junto con
la máscara de red. Los números entre corchetes identifican la
distancia administrativa y la métrica de la ruta. "Via" indica
la dirección del router de próximo salto para llegar a la red
destino. Finalmente se especifica el tiempo transcurrido desde
que la ruta fue actualizada y la interfaz a través de la cual se
puede alcanzar la red remota.
Se puede extraer mucha más información de la tabla de
rutas, información que iremos comprendiendo a lo largo de
este libro: por ejemplo, la tabla indica que el router posee (al
menos) una interfaz Serie (Serial0) y una interfaz Ethernet
(Ethernet0). Otra observación que podría hacerse es que la
red a la que pertenece este router es una red particular: todas
las direcciones IP utilizadas pertenecen al espacio reservado
para uso privado (10.0.0.0, 172.16.0.0, 192.168.x.0). Podemos
pensar que para salir a Internet usan el dispositivo que tiene la
dirección interna 10.0.0.100, como vemos en la línea "Gateway
of last resort is 10.0.0.100 to network 0.0.0.0" Esta línea indica la
ruta que tomaran por defecto los paquetes cuyos destinos no
aparezcan especificados en la tabla, la ruta usada como último
recurso para alcanzar las redes desconocidas.
1.4. Un ejemplo de red

Llegados a este punto vemos a dejar la teoría a un lado para
ver cómo aprenden e intercambian información un conjunto
de routers en una red sencilla. No se preocupe si no entiende
todo lo que describimos, el resto del libro elabora todos los
puntos aquí tratados.
Nota: La red de la ilustración es la red ARPAnet inicial, en

1969. ARPAnet fue la red precursora directa de Internet.
Inicialmente constaba de 4 routers, entonces denominados IMP
(Interface Message Processors) instalados en la Universidad de
34
California - Los Ángeles (UCLA), el Stanford Research Institute
(SRI), en la Universidad de California – Santa Bárbara (UCSB)
y en la Universidad de Utah. Nosotros vamos a modernizar un
poco la red del dibujo, añadiendo direccionamiento IP y usando
routers Cisco en lugar de los IMPs, lo que nos permitirá crear
una red mediante interfaces y protocolos que en realidad no
aparecieron hasta unos años más tarde.
Figura 1.6. ARPAnet Diciembre, 1969
Cada uno de estos routers posee una conexión con una

red local tipo Ethernet. Además, cada uno de ellos posee uno
(UTAH), dos (UCLA, UCSB) o tres (SRI) interfaces Serie. El
router SRI constituye el nodo central de esta pequeña red,
manteniendo una conexión dedicada, punto a punto, con cada
uno de los otros dispositivos.
En el apéndice podemos ver las configuraciones de cada
uno de los routers de este ejemplo. Ahora, para ver la lista de
las interfaces de cada uno de estos routers, usaremos mediante
la orden "show ip interfaces brief"
UCLA#show ip interfaces brief
Interface IP-Address OK? Method Status Protocol
Ethernet0 192.168.1.1 YES manual up up
Serial0 172.16.0.1 YES manual up up
UCSB#show ip interfaces brief

SRI#show ip interfaces brief

FastEthernet0 192.168.2.1 YES manual up up
35
UTAH#show ip interfaces brief

Podemos ver el nombre (o hostname) de cada uno de los

routers antes del símbolo "#", que indica que somos adminis-
tradores de los mismos. Con la orden "show ip interfaces brief"
obtenemos una serie de tablas que muestran la denominación
de la interfaz (tipo y número: Ethernet, FastEthernet, Serial…),
la dirección de red (IP address) de dicha interfaz, el estado ope-
racional desde el punto de vista del router (OK? YES), cómo
adquirió la interfaz su configuración (en este caso de forma
manual) así como el estado a nivel físico (status, capa 1) y de
enlace (protocol, capa 2).
Nota: las interfaces usadas en este ejemplo son conectores

físicamente diferenciados. Veremos más adelante que el nodo
central no necesita tener tantas interfaces físicas como routers
con los que se conecta, sino que se puede dividir una interfaz
física en varias subinterfaces lógicas o virtuales.
A continuación vemos la tabla de rutas que construyen

cada uno de estos routers. Hemos escogido deliberadamente
el protocolo de enrutamiento RIP, un protocolo del tipo vector
de distancia algo anticuado pero que tiene la virtud de mostrar
claramente las redes conocidas por el router, la interfaz por la
cual se accede a las mismas y la distancia en saltos (o número
de routers que hay que atravesar) para alcanzarlas:
SRI#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
172.16.0.0/30 is subnetted, 4 subnets
C 172.16.0.12 is directly connected, Serial2
R 172.16.0.4 [120/1] via 172.16.0.1, 00:00:05, Serial1
[120/1] via 172.16.0.9, 00:00:20, Serial0
R 192.168.4.0/24 [120/1] via 172.16.0.14, 00:00:04, Serial2
R 192.168.1.0/24 [120/1] via 172.16.0.1, 00:00:05, Serial1
C 192.168.2.0/24 is directly connected, FastEthernet0
R 192.168.3.0/24 [120/1] via 172.16.0.9, 00:00:21, Serial0
UCLA# show ip route

36
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
R 172.16.0.12 [120/1] via 172.16.0.2, 00:00:02, Serial0
R 172.16.0.8 [120/1] via 172.16.0.2, 00:00:02, Serial0
[120/1] via 172.16.0.6, 00:00:13, Serial1
R 192.168.4.0/24 [120/2] via 172.16.0.2, 00:00:02, Serial0
R 192.168.2.0/24 [120/1] via 172.16.0.2, 00:00:03, Serial0
R 192.168.3.0/24 [120/1] via 172.16.0.6, 00:00:14, Serial1
UCSB#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
R 172.16.0.12 [120/1] via 172.16.0.10, 00:00:01, Serial0
R 172.16.0.0 [120/1] via 172.16.0.5, 00:00:19, Serial1
[120/1] via 172.16.0.10, 00:00:01, Serial0
R 192.168.4.0/24 [120/2] via 172.16.0.10, 00:00:01, Serial0
R 192.168.1.0/24 [120/1] via 172.16.0.5, 00:00:19, Serial1
R 192.168.2.0/24 [120/1] via 172.16.0.10, 00:00:03, Serial0
UTAH#show ip route
R 172.16.0.8 [120/1] via 172.16.0.13, 00:00:27, Serial0
R 172.16.0.4 [120/2] via 172.16.0.13, 00:00:27, Serial0
R 172.16.0.0 [120/1] via 172.16.0.13, 00:00:27, Serial0
R 192.168.1.0/24 [120/2] via 172.16.0.13, 00:00:27, Serial0
R 192.168.2.0/24 [120/1] via 172.16.0.13, 00:00:27, Serial0
R 192.168.3.0/24 [120/2] via 172.16.0.13, 00:00:00, Serial0
Podemos ver entre corchetes la distancia administrativa

y la métrica usada para construir estas tablas, en formato
[distancia, métrica]. En concreto la métrica que usa RIP es
el número de saltos que hay que dar para alcanzar una red,
siendo cada router un salto. Así, examinando la tabla de rutas
de UTAH vemos que este router está directamente conectado
a las redes 192.168.4.0 y 172.16.0.12, que puede alcanzar las
redes 172.16.0.8, 172.16.0.0 y 192.168.2.0 de un salto y llegar a
las redes 172.16.0.4, 192.168.1.0 y 192.168.3.0 de dos saltos.
Todas las tablas están completas y muestran una perspec-
tiva coherente de la red. Podemos afirmar que el protocolo
37
de red ha convergido en una visión estable. Para verificar el
correcto funcionamiento de la red disponemos de la herra-
mienta de chequeo de conectividad por excelencia, ping. Cada
exclamación "!" indica un paquete de verificación que ha sido
contestado por la máquina destino.
UCLA#ping 192.168.2.1 source 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms
UCLA#ping 192.168.3.1 source 192.168.1.1

!!!!!
UCLA#ping 192.168.4.1 source 192.168.1.1

!!!!!
Nota: En realidad en los ejemplos anteriores usamos un

ping extendido o ping de LAN a LAN. Más sobre ping en el
capítulo 4
Para terminar con nuestro ejemplo provocaremos un pe-

queña "catástrofe" en el entorno deshabilitando selectivamente
una de las conexiones punto a punto de la red. Por ejemplo, si
tumbamos la interfaz Serial0 de UCLA,
UCLA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
UCLA(config)# int serial 0
UCLA(config-if)# shutdown
UCLA(config-if)# ^Z
01:29:48: %SYS-5-CONFIG_I: Configured from console by console
01:29:50: %LINK-5-CHANGED: Interface Serial0, changed state to administratively down
01:29:51: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
La pérdida de la red punto a punto se refleja de forma di-

námica en el resto de los routers. UTAH, por ejemplo, pasa a
ver la red de la siguiente forma:
UTAH#sh ip route
38
R 172.16.0.8 [120/1] via 172.16.0.13, 00:00:06, Serial0
R 172.16.0.4 [120/2] via 172.16.0.13, 00:00:06, Serial0
R 192.168.1.0/24 [120/3] via 172.16.0.13, 00:00:03, Serial0
R 192.168.2.0/24 [120/1] via 172.16.0.13, 00:00:06, Serial0
R 192.168.3.0/24 [120/2] via 172.16.0.13, 00:00:06, Serial0
Se observa que UTAH ahora ve la red 192.168.1.0 a 3 saltos

de distancia. Con traceroute, otra de las herramientas clásicas
de comprobación de conectividad, podemos verificar los tres
routers (saltos) que los paquetes deben dar para llegar a su
destino:
UTAH#traceroute
Protocol [ip]:
Target IP address: 192.168.1.1
Source address: 192.168.4.1
Numeric display [n]: y
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Tracing the route to 192.168.1.1
1 172.16.0.13 12 msec 8 msec 8 msec
2 172.16.0.9 36 msec 16 msec 20 msec
3 172.16.0.5 40 msec * 24 msec
Entender cómo construye y utiliza el router la tabla de rutas

es entender de redes.
Volveremos a hablar más extensamente sobre el enruta-
miento y sus posibilidades en el capítulo cinco.
1.5. Modelos de routers Cisco

Cisco tiene una gran oferta de equipos de red que no sólo
incluye una amplia gama de routers sino también de switches,
firewalls, telefonía IP y un largo etc…
La oferta de routers abarca una amplia gama de escenarios:
hay routers para el hogar y la oficina, la denominada categoría
Branch, a la que pertenecen los Cisco Integrated Services
Routers (series 800, 1800, 2800 y 3800).
Vienen a continuación los pesos medios de los routers, que
suelen englobarse en la categoría Aggregation (series 7200,
7300, 7600 y ASR 1000). Generalmente ubicados en las cen-
39
trales de las empresas y proveedores de servicios de datos, se
trata de routers capaces de adaptarse a una amplia variedad
de medios, distribuir el tráfico entre las oficinas y enlazar con
el núcleo de la red corporativa. En la cima, y dentro de la ca-
tegoría Service Provider, se encuentran los routers de frontera
(series 7600, 10700 y 12000), caracterizados por su alta densidad
de puertos de gran velocidad, escalables y adaptables a todo
tipo de tecnologías de transporte.
Nota: La oferta de Cisco está en permanente evolución. La

forma más efectiva de conocer los modelos y sus capacidades
consiste en visitar su página Web http://www.cisco.
com/go/routers/, enlace en el que podemos comparar
los diversos equipos
A la hora de escoger un router, debemos considerar di-
versos factores, como el número y tipo de interfaces así cómo
el número de paquetes y megabits que puede conmutar, para
poder predecir el rendimiento que el equipo va a dar. Para
tomar decisiones disponemos de varias herramientas.
La Guía de Referencia Rápida de Productos de Cisco
http://www.cisco.com/go/guide/ es una útil y com-
pacta referencia que incluye breves descripciones de los pro-
ductos, sus características fundamentales, los part numbers, así
como especificaciones técnicas abreviadas de muchos de los
productos Cisco. Se trata de una información muy útil a la hora
de decidir qué necesitamos para un proyecto.
Nota: en este momento la versión Summer/Fall 2008 está

disponible para su descarga en formato PDF y HTML desde
el Document center en el enlace https://www.nations-
print.com/clients/cpqrg/. Otra útil herramienta a
la hora de determinar el rendimiento potencial de un router es
el siguiente documento de Cisco, muy interesante a la hora de
definir el equipo que necesitemos: http://www.cisco.
com/web/partners/downloads/765/tools/
quickreference/routerperformance.pdf
1.5.1. Routers de Servicios Integrados

(Integrated Services Routers)
Son routers que se adaptan tanto el hogar como a la oficina,
conformando la categoría Branch. Los "servicios integrados"
que denominan estos hacen referencia a las funciones que se
40
pueden encontrar en estos routers que van más allá del enruta-
miento puro y duro. Estos servicios añadidos son la evolución
de los antiguos routers que "sólo" enrutaban.
La serie 800 está orientada a las pequeñas oficinas, permi-
tiendo ejecutar de forma simultánea múltiples servicios: Stateful
Inspection Firewall, encriptación hardware, VPNs, Soporte
opcional de redes inalámbricas, conexiones a redes de banda
ancha (cable, DSL).
La serie 1800 se presenta tanto en formatos fijos como mo-
dulares y ofrece una amplia oferta de opciones LAN y WAN.
Las arquitecturas fijas ofrecen interfaces Ethernet 10/100,
ADSL tanto sobre telefonía convencional como sobre RDSI,
interfaces WAN G.SHDSL, interfaces RDSI BRI así como
interfaces de backup sobre modem convencional analógico.
El acceso Inalámbrico (WLAN) via IEEE 802.11 a/b/g está
disponible en todos los modelos de la serie 1800, así como las
Unified Communications para el Cisco 1861.
La serie 2800 está optimizada para tratar concurrentemente
datos, voz y vídeo a PYMES (SMB, small and medium-sized busi-
ness) y ofrecen un alto rendimiento (hasta 6 enlaces T1/E1), se-
guridad avanzada (Stateful Firewall, IPS, VPN y Cisco Network
Admission Control), soporte nativo a diversos esquemas de
encriptación (DES, 3DES y AES), puntos de acceso IEEE 802.11
a/b/g e interfaces WAN de alta velocidad (HWICs).
La serie Cisco 3200 es una línea más resistente (rugged)
de alto rendimiento que proporciona servicios integrados
en entornos móviles, industriales y al aire libre, soportando
voz, vídeo y datos sobre Ethernet, serial, fibra e interfaces
inalámbricos. Está diseñada para operar en entornos indus-
triales bajo un amplio rango de temperaturas (de –40 a 74°C),
soporte wireless (modos bridge y access-point). Están dise-
ñados para cumplir con el estandar industrial PC/104+ para
routers empotrados en diseños a medida, y ofrecen soporte
avanzado de seguridad, calidad de servicio (QoS), movilidad
y Telefonía IP.
En la gama alta tenemos la serie Cisco 3800 que ofrece un
alto rendimiento, altas densidades de puertos y la capacidad
de mover de forma concurrente datos, voz vídeo con seguridad
y calidad de servicio a velocidades de cable (wire speed) hasta
T3/E3. disponen de alta disponibilidad en caliente, fuentes
de alimentación redundantes, HWICs, seguridad avanzada,
memoria expandida con detección y corrección de errores
(SDRAM ECC DDR) así como puntos de acceso HWIC IEEE
802.11 a/b/g.
41
1.5.2 Routers de Agregación (Aggregation)
Son routers generalmente ubicados en las centrales de las
empresas y proveedores de servicios de datos, se adaptan a
múltiples medios, distribuyen el tráfico entre las sedes y las
enlazan con el núcleo de la red corporativa. Suelen englobarse
en la categoría Aggregation.
La serie Cisco ASR 1000 dispone de chasis que soportan
diversos SPA (shared-port adapters) y procesadores (RP1,
ESP5/10 - Embedded Services Processor 5/10), y capaci-
dades como Cisco IOS Software redundancy, Network-Based
Application
Recognition (NBAR) y Cisco IOS Flexible Packet Matching
(FPM), session border controller (SBC).
Las series 7200/7300 soportan OC-3/Gigabit Ethernet junto
con una alta modularidad, rendimiento y escalabilidad. Vienen
en diferentes chasis (1RU, 3RU), pueden equipar diversos
procesadores (NPEs ó network processing engines) y poseen
conectividad Gigabit Ethernet (en cobre y fibra).
La serie 7600 consolida redes WAN, MAN y LAN en una
plataforma única. Con su ancho de banda del backplane es-
calable de 32 a 720 Gbps, sus rendimientos de 30 a 400 Mpps
(RSP720) y una amplia gama de interfaces WAN / MAN
(desde N x DS-0, T1 y T3 hasta OC-192), serial, high-speed
serial, channelized, Packet over SONET/SDH (PoS), ATM y
Ethernet… son routers ideales para ISPs, Metrolanes y triple-
play (data, voz y video). Además soportan los módulos de las
series Catalyst 6500 y Cisco 7200/7500.
1.5.3 Routers para ISPs (Service Aggregation)

Conforman la categoría Service Provider (Internet Service
Providers) ofrecen una alta densidad de puertos, velocidad,
escalabilidad y adaptación a las tecnologías de transporte más
punteras.
La serie Cisco 10700 ofrece routers de la clase "metro" para
ISPs . Están optimizados para servicios next-generation metro
Ethernet, con una alta densidad de puertos Ethernet para
acceso del lado cliente y OC-48c/STM-16c, Dynamic Packet
Transport/Resilient
Packet Ring (DPT/RPR) o Packet over SONET (PoS) para
el lado metro.
El Cisco XR 12000 y la serie 12000 son routers multiservicio
para ISPs, con hasta 10-G de subida sostenida, múltiples op-
42
ciones de chasis, un amplio portfolio de fuentes de alimentación
y refrigeración, procesadores, line cards, SPAs (Packet over
SONET/SDH - PoS, ATM, Ethernet, Dynamic Packet Transport/
Resilient Packet Ring - DPT/RPR…) y funcionalidades de Layer
2/3 VPN y QoS que diferencian el tráfico y aseguran la conse-
cución de los acuerdos de nivel de servicio (ANS, SLA).
1.6. Cisco, la empresa

Cisco Systems es una multinacional líder mundial en solu-
ciones de red e infraestructuras para Internet. Con sede en San
Jose, California, Cisco Systems fue fundada en 1984 por el ma-
trimonio formado por Leonard Bosack y Sandra Lerner, ambos
de la Universidad de Stanford. Bosack adaptó el software para
routers multiprotocolo escrito originalmente por William
Yeager, también de la Universidad de Stanford, creando el
primer router multiprotocolo comercial de éxito.
La gama de productos Cisco es amplia y comprende dispo-
sitivos de interconexión de redes (routers, switches, hubs), de
seguridad como (firewalls, concentradores VPN), telefonía IP,
software de gestión de red, equipos para el almacenamiento
en red (NAS)…
Además de invertir en I+D, Cisco Systems sigue una estra-
tegia de adquisiciones de empresas con las que tradicional-
mente ha complementado las áreas consideradas críticas en
cada momento, obteniendo la tecnología y el talento necesarios
para crecer. Cisco ha demostrado saber integrar con éxito las
empresas adquiridas en su estructura, constituyendo algunas
de ellas ramas fundamentales de la actividad actual de Cisco.
Algunos ejemplos de empresas adquiridas que han tenido
un gran impacto en las operaciones de Cisco son Crescendo,
Kalpana y Grand Junction (switches Catalyst), Celsius en Voz
sobre IP, Network Translation en firewalls (PIX), Ironport en
securización del correo electrónico (Ironmail), Linksys en pro-
ductos para el hogar, Scientific Atlanta en dispositivos para
cable y WebEx o Jabber en servicios de conferencia.
Nota: En abril de 2008 Cisco Systems llevaba adquiridas

127 empresas. En el enlace: http://en.wikipedia.
org/wiki/List_of_acquisitions_by_Cisco_
Systems podemos consultar las empresas adquiridas y el
área de negocio a la que pertenecen.
43
2
TCP/IP
En este capítulo examinamos el conjunto de protocolos

TCP/IP, la familia de protocolos en la que se basa Internet.
TCP/IP toma su nombre de los dos protocolos más impor-
tantes de la familia: el Protocolo de Control de Transmisión
(TCP) y el Protocolo de Internet (IP). Conoceremos su historia
y estructura, examinaremos sus principales componentes, nos
detendremos a examinar el direccionamiento IPv4 y termi-
namos el capítulo analizando el movimiento de los paquetes
a través de una conexión TCP/IP.
2.1. Un poco de historia.

El 4 de Octubre de 1957 la Unión Soviética lanzaba el primer
satélite artificial, el Sputnik I, inaugurando la carrera espacial.
Los Estados Unidos interpretaron el lanzamiento como una
prueba de que se estaban quedando atrás en ciencia y tecno-
logía y respondieron creando unos pocos meses más tarde la
Agencia de Investigación de Proyectos Avanzados de Defensa
(DARPA por sus siglas en inglés).
DARPA pronto mostró interés por los sistemas operativos
de tiempo compartido. Así, por ejemplo, financió el desarrollo
de Multics, predecesor directo del sistema operativo UNIX.
Las pruebas iniciales para conectarse remotamente a estos
sistemas fueron positivas, pero también mostraron que las
técnicas de conmutación de circuitos, típicas de la telefonía
convencional, no eran las adecuadas para este tipo de inter-
conexiones. DARPA se fijó en las técnicas de conmutación de
paquetes postuladas por Leonard Kleinrock en su tesis doctoral
de 1964 en la que estableció una teoría matemática de las redes
de paquetes de datos.
45
Nota: Conmutación de circuitos vs. Conmutación de paquetes:
Las redes basadas en conmutación de circuitos son la base de
la telefonía convencional y eran la infraestructura previa a la
invención de las redes basadas en la conmutación de paquetes.
Según este modelo, se debe establecer un circuito entre los
participantes en la comunicación, lo que precisa que los recursos
necesarios se reserven para cada par de usuarios finales. Esto
implica que los recursos reservados para esa comunicación no
estarán disponibles al resto de usuarios mientras dure la comu-
nicación, lo que conlleva un uso ineficiente del ancho de banda
en los casos en los que el intercambio de información ocurre de
forma intermitente. Las redes de conmutación de circuitos son
útiles en contextos de aplicaciones en tiempo real. En el modelo
de comunicación basado en conmutación de paquetes la voz, el
vídeo y los datos se tratan igual, en un modelo también llamado
red integrada de datos. En estas redes los mensajes digitalizados
se fragmentan en una o varias unidades, denominadas paquetes,
cada una con una cabecera en la que lleva información de
control tal como las direcciones de origen y destino. Además de
hacer un uso eficiente del ancho de banda, las conversaciones
individuales no monopolizan los recursos de la red, que pasan
a ser compartidos por el resto de usuarios.
Figura 2.1. ARPAnet Diciembre, 1969.
A finales de los 60 se encargó a la consultora BBN el diseño

y construcción de los primeros routers, denominados IMPs
(Interface Message Processors), y en 1969 se creaba la red ARPAnet.
Esta red conectaba 4 sistemas instalados en la Universidad de
California - Los Ángeles (UCLA), el Instituto de Investigación de
Stanford (SRI), en la Universidad de California – Santa Bárbara
46
(UCSB) y en la Universidad de Utah. El protocolo original de
ARPAnet era el NCP (Network Control Program), desarrollado
por Vinton Cerf. Basándose en la experiencia adquirida con el
NCP, Vinton Cerf y Robert Kahn diseñaron en 1973 un modelo
de interconexión abierto que hiciese posible unir todo tipo de
redes con independencia de sus características. Un elemento
central de este modelo es un router, con conexiones a cada una
de las redes que conecta y reenvía paquetes. En los siguientes
años desarrollaron sucesivamente cuatro versiones del nuevo
protocolo mejorado: TCP v1, TCP v2, TCPv3 / IPv3, y por fin
TCP/IP versión 4, el estándar que todavía reina en Internet.
Figura 2.2. Evolución de los usuarios de Internet 1995-2009

(Datos: http://www.internetworldstats.com/emarketing.htm).
2.2. Estructura del protocolo TCP/IP

TCP/IP está organizado en cuatro capas: la capa de acceso a
la red, la capa Internet, la capa de transporte y la capa de aplica-
ción. Cada una de las capas resuelve un problema relacionado
con la transmisión de información, además de proporcionar
una serie de servicios bien definidos a los protocolos de las
47
capas superiores. Así, cada una de las capas de la pila TCP/
IP implementa servicios de control de errores (haciendo más
fiable el canal de comunicación), de control de flujo (evitando
inundar de tráfico otros nodos más lentos), de fragmentación
(dividiendo la información en piezas más pequeñas, y uniendo
éstas cuando se reciben), de multiplexación (permitiendo que
varias sesiones de nivel superior compartan una única conexión
de un nivel inferior), de gestión del establecimiento de la co-
nexión, así como de direccionamiento y nomenclatura.
Nota: La organización de TCP/IP está descrita en el RFC 1122

"Requirements for Internet Hosts - Communication Layers"
(http://tools.ietf.org/html/rfc1122).
En la figura 2.3 vemos la relación entre los modelos TCP/

IP y OSI. Igual que en el modelo OSI, los datos bajan por la pila
de protocolos del sistema emisor y suben por la del extremo re-
ceptor. Cada capa de la pila, antes de enviar los datos a la capa
inferior, añade información de control denominada cabecera. Al
proceso por el que se añade esta información de control se le de-
nomina encapsulación (figura 2.4). Cuando los datos se reciben
tiene lugar el proceso inverso: a medida que los datos ascienden
por la pila se eliminan las cabeceras correspondientes.
Figura 2.3. Relación entre los modelos TCP/IP y OSI.
Entre las distintas capas del modelo se establece una co-

nexión virtual, excepto en la capa de acceso a la red, dónde
realmente se establece una conexión física entre los elementos
de la red mediante el intercambio de bits (figura 2.5).
48
Figura 2.4. Encapsulación de los datos en TCP/IP.
Figura 2.5. Relación entre las capas TCP/IP
49
2.3. La capa de aplicación
Esta capa es el punto de acceso a los servicios de TCP/IP.
La capa de aplicación aglutina las capas de sesión, presentación
y aplicación del modelo OSI, proporcionando una interfaz a
través de la cual las aplicaciones de los usuarios pueden acceder
a la red. Algunas de las aplicaciones más conocidas de esta capa
son la navegación por la web HTTP, HTTPS, la transferencia de
ficheros FTP, TFTP, el chat IRC, el correo, IMAP, NTP, POP3,
RTSP, SMTP, SNMP, TELNET... Los juegos en red también
tienen su protocolo de aplicación. Vemos en la figura 2.6 la
salida de Wireshark, el analizador de protocolos, correspon-
diente a la capa de transporte de un paquete DNS.
Figura 2.6. Captura en Wireshark de la

capa de transporte de un paquete DNS.
2.4. La capa de transporte
Seguimos subiendo por la pila de protocolos TCP/IP y nos

encontramos con la capa de Transporte. Dentro de esta capa
destacan dos protocolos, TCP (Transmission Control Protocol) y
UDP (User Datagram Protocol)
50
2.4.1. TCP
TCP es uno de los protocolos centrales de la pila de proto-
colos Internet, hasta el punto de constituir la mitad de una de
las denominaciones habituales de este modelo: TCP/IP.
Nota: La especificación de TCP se encuentra recogida en el

RFC 793, disponible en http://www.ietf.org/rfc/
rfc793.txt
Si IP se encarga de resolver la transmisión de paquetes de

nodo en nodo a lo largo de su viaje por Internet hasta llegar
al destino, TCP opera a un nivel conceptual más alto, y sólo
"ve" los sistemas finales, por ejemplo un navegador Web y el
servidor Web al que se conecta. TCP abstrae la complejidad
subyacente de la red, proporcionando a las aplicaciones co-
nexiones fiables y ordenadas entre programas en distintos
ordenadores.
TCP es un protocolo orientado a la conexión, lo que significa
que requiere un establecimiento de la comunicación. TCP es
fiable (gestiona los acuses de recibo, las retransmisiones y los
tiempos muertos, e intenta repetidamente el envío fiable de
información, pidiendo los fragmentos que faltan), ordenado
(si los paquetes llegan en el orden incorrecto TCP los retiene
hasta poder liberar la información en el orden correcto a las
aplicaciones), pesado (TCP requiere el intercambio de tres pa-
quetes para establecer la comunicación antes de que cualquier
información sea intercambiada, confirmaciones de recepción
de los datos, etc…) y orientado al flujo (la información es en-
viada como parte de un flujo o stream, y la información que
dicho flujo contiene puede ser fragmentada o unida para su
transmisión en paquetes de forma arbitraria).
TCP se usa de forma generalizada por muchos de los ser-
vicios de Internet más populares: navegación (World Wide
Web), correo electrónico (E-mail), transferencia de ficheros (File
Transfer Protocol), conexiones remotas (telnet, ssh) y streaming
multimedia.
TCP usa el concepto de puertos para identificar a las aplica-
ciones que actúan como puntos de emisión y recepción de los
mensajes (Internet sockets). Cada lado de la conexión TCP lleva
asociado un número entero de 16 bits, que queda reservado
para la aplicación emisora o receptora. Los paquetes TCP son
identificados como pertenecientes a una determinada conexión
en virtud su socket, conformado por la dirección IP de origen,
51
el número de puerto de origen, la dirección IP de destino y el
número de puerto de destino. De esta forma un único servidor
puede atender múltiples clientes simultáneamente, incluso de
una misma dirección IP, siempre y cuando los clientes inicien
conexiones desde diferentes números de puerto.
Figura 2.7. Cabecera TCP (cortesía de

Matt Baxter http://www.fatpipe.org/~mjb/Drawings/).
Vemos en la figura 2.7 la cabecera TCP. Los campos Source

Port y Destination Port indican respectivamente los puertos de
origen y destino del paquete TCP. El Sequence Number es el nú-
mero de secuencia del primer octeto de datos en este segmento.
Acknowledgment Number es un campo de 32 bits que indica el
valor del siguiente número de secuencia que el transmisor
de un segmento espera recibir. El campo Data Offset indica la
posición de los datos dentro del paquete. Los siguientes 6 bits
están reservados para futuro uso, y actualmente deben tener
el valor a cero.
A continuación tenemos los bits de control (TCP Flags):
URG, un bit que denota la urgencia del paquete; PSH, bit que
obliga al receptor del segmento a enviar los datos directamente
a la aplicación sin esperar sucesivos envíos hasta el llenado
del buffer. RST, bit usado para resetear la conexión, bien por
problemas en el host u otra razón, así como para rechazar
52
un segmento invalido o una conexión; SYN, usado para sin-
cronizar los números de secuencias; ACK, para informar a la
otra parte de la recepción de los paquetes y FIN, usado para
finalizar la conexión.
El campo Windows indica el número de octetos de datos
que está dispuesto a aceptar. El campo Checksum se utiliza
para controlar la integridad de los datos mediante una suma
de comprobación. El Urgent Pointer apunta al número de se-
cuencia del octeto que contiene datos de tipo urgente y sólo es
tenido en cuenta cuando el bit URG está activado.
Una comunicación TCP/IP va pasando por una serie de
estados (LISTEN, ESTABLISHED, CLOSING…) y los bits de
control (TCP Flags) sirven para indicar las transiciones entre
estados. La figura 2.8 muestra la máquina de estados TCP.
Figura 2.8. Máquina de estados TCP
En una comunicación típica TCP/IP entre cliente y servidor

hay una "coreografía" típica. Primero viene un intercambio a
tres vías (handshake) en el que el sistema que inicia la conexión
manda un paquete SYN, que es respondido con un paquete con
las banderas SYN-ACK activas. El cliente termina de establecer
la conexión mandado un ACK. En ese punto cliente y servidor
están conectados, listos para intercambiar datos (PUSH, ACK).
Una vez concluido el intercambio de información la conexión
53
se cierra mediante un paquete FIN que es confirmado con un
ACK. El diagrama de secuencia de la figura 2.9 recoge toda
esta transacción.
Figura 2.9. Transacción TCP
Vemos en la figura 2.10 la salida del analizador de pro-

tocolos para la parte de la capa de transporte. La unidad de
trabajo de esta capa es el mensaje.
TCP está optimizado para entregar la información de forma
correcta, no rápida. TCP a veces puede mostrar retardos per-
ceptibles mientras espera que lleguen los paquetes fuera de
54
orden y las retransmisiones de los paquetes que se han per-
dido. Para aplicaciones en tiempo real cómo la voz sobre IP el
protocolo TCP puede no resultar el más adecuado; para estas
aplicaciones en las que la pérdida de algunos paquetes no re-
sulta crítica pero en las que es preciso una respuesta inmediata
se recomienda otros protocolos, entre los que destaca UDP.
Figura 2.10. Salida de Wireshark correspondiente

a la capa de transporte de un paquete HTTP.
2.4.2. UDP
UDP (User Datagram Protocol) es otro de los protocolos
fundamentales de la pila Internet. UDP permite a las apli-
caciones enviar mensajes, denominados datagramas, a otros
dispositivos sin requerir el establecimiento de un canal de
transmisión previo.
Nota: UDP fue diseñado por David P. Reed en 1980 y está

descrito en el RFC 768 (http://tools.ietf.org/html/rfc768)
Al igual que TCP, UDP usa sockets para establecer las co-
municaciones entre hosts. Estos sockets unen la aplicación a
un puerto que actúa como punto de contacto para la transmi-
sión. Un puerto es una estructura software identificada por un
número entero de 16 bits, el número de puerto.
55
UDP usa un modelo de transmisión simple que no requiere
establecimiento de la conexión (la negociación en tres pasos o
handshake del TCP), es unidireccional y evita las comproba-
ciones de todo tipo: no ofrece fiabilidad, orden o integridad
de los datos, los datagramas pueden llegar o no y además
hacerlo en cualquier orden. Si hay necesidad de comprobar
errores en la comunicación UDP delega esa responsabilidad
en las aplicaciones. Ligero y rápido, UDP es usado por mu-
chas aplicaciones como DNS (Domain Name System), VoIP
(Voz sobre IP), TFTP (Trivial File Transfer Protocol), SNMP
(Simple network management protocol), DHCP (Dynamic
Host Configuration Protocol) o el protocolo de enrutamiento
RIP (Routing Information Protocol).
En la figura 2.11 vemos la cabecera UDP
Figura 2.11. Cabecera UDP (cortesía de

Comparada con TCP, la cabecera UDP es extremadamente

simple: tenemos el puerto de origen (source port), el puerto
de destino (destination port), la longitud del paquete en bytes
(length) y una suma de control (checksum). Con un lenguaje de
programación como Python resulta sencillo escribir un par
de pequeños scripts que se comuniquen vía UDP. Un servidor
muy simple sería algo similar a lo siguiente:
import socket
port = 1234
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("", port))
print "Esperando en el puerto:", port
while True:
data, addr = s.recvfrom(1024)
print "Recibido:", data, "desde", addr
Para el lado cliente se pueden escribir programas mucho

más complicados que el siguiente script:
56
import socket
port = 1234
host = "localhost"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto("Routers Cisco vía UDP", (host, port))
La captura de Wireshark de la figura 2.12 muestra la capa

UDP de un paquete DNS.
Figura 2.12. Captura en Wireshark que

muestra la capa UDP de un paquete DNS.
2.5. La capa Internet

La capa de Internet agrupa los métodos, protocolos y es-
pecificaciones usados para transportar paquetes entre el nodo
emisor y el destinatario atravesando otros nodos y redes inter-
medias si es preciso. Los nodos se identifican por su dirección
en la red o dirección IP, tal como se define en el Protocolo
Internet o IP. La capa Internet facilita la interconexión de
múltiples redes a través de los routers (también denominados
puertas de enlace o gateways).
Nota: El protocolo IP está descrito en el RFC 791 (http://tools.

ietf.org/html/rfc791). En el punto 3.2 de este RFC aparece un as-
pecto crucial de Internet, conocido como Principio de Robustez:
57
"En general la implementación de IP debe ser conservadora
en su comportamiento emisor y liberal en su comportamiento
receptor, o lo que es lo mismo, debe ser cuidadosa y enviar
paquetes bien formado pero debe aceptar los paquetes que
puede interpretar y no objetar a los errores técnicos cuando el
significado está claro"
La capa Internet selecciona para los paquetes salientes el

siguiente salto (next hop) y transmite el paquete al nodo en-
contrado en el paso anterior. Para ello transfiriere el paquete
a los controladores de nivel de enlace apropiados, además de
capturar paquetes y pasar su carga útil (payload) al módulo
apropiado del nivel superior (la capa de transporte), detectar
errores y ofrecer capacidades diagnósticas.
Los protocolos fundamentales de la capa Internet son IP
(Internet protocol), en sus versiones IPv4 e IPv6, y el proto-
colo de control de Internet (ICMP, Internet Control Message
Protocol), que proporciona funciones de control de errores y
diagnósticas. Cuando se diseño el protocolo IP la seguridad
de las comunicaciones no era el problema en el que se ha ter-
minado convertiendo. IPsec (Internet Protocol Security) agrupa
una serie de protocolos que aseguran las comunicaciones IP
proporcionando servicios de autenticación y encriptación de
los paquetes IP. IPSec se diseñó originalmente para IPv6 (RFC
1825, RFC 1829) pero fue rápidamente adaptado a IPv4.
2.5.1. IP
La versión 4 del Protocolo de Internet (IPv4) es capaz de
fragmentar (y posteriormente volver a unir) paquetes basán-
dose en aspectos como la unidad máxima de transmisión del
enlace (MTU, maximum transmission unit). En la versión 6 del
protocolo, IPv6, esta función no existe dado que los nodos de-
terminan el mínimo MTU y transmiten de la transmisión de
extremo a extremo bajo ese MTU.
IP por si mismo no garantiza la transmisión, de forma que
no asegura ni la llegada del paquete al destino ni el orden de
llegada de los paquetes. Esta falta de fiabilidad, lejos de ser un
defecto es una de las razones de la resistencia y escalabilidad de
Internet ante fallos de enlaces. IP se separa en este sentido de los
protocolos de Arpanet originales y considera que las redes no
son fiables y que la responsabilidad de proporcionar fiabilidad
debe recaer en los protocolos de capas superiores como TCP
(Transmission Control Protocol) en el nivel de Transporte.
58
Figura 2.13. Cabecera Ipv4 (cortesía de
Matt Baxter http://www.fatpipe.org/~mjb/Drawings/)
A continuación vemos los principales campos de la cabecera

IPv4 (Figura 2.13):
Versión: Siempre vale lo mismo (0100, 4 en binario). Este
campo describe el formato de la cabecera utilizada.
Tamaño Cabecera (IHL): Longitud de la cabecera, en pa-
labras de 32 bits. Su valor mínimo es de 5 para una cabecera
correcta, y el máximo de 15.
Tipo de Servicio: Indica una serie de parámetros sobre la
calidad de servicio deseada durante el tránsito por una red.
Algunas redes ofrecen prioridades de servicios, considerando
determinado tipo de paquetes "más importantes" que otros (en
particular estas redes solo admiten los paquetes con prioridad
alta en momentos de sobrecarga).
Longitud Total: tamaño total, en octetos, del datagrama,
incluyendo el tamaño de la cabecera y el de los datos. El ta-
maño máximo de los datagramas usados normalmente es de
576 octetos (64 de cabeceras y 512 de datos). Una máquina no
debería enviar datagramas mayores a no ser que tenga la cer-
teza de que van a ser aceptados por la máquina destino. En
caso de fragmentación este campo contendrá el tamaño del
fragmento, no el del datagrama original.
Identificador: Identifica de forma única el datagrama. Se
utilizará, en caso de que el datagrama deba ser fragmentado,
59
para poder distinguir los fragmentos de un datagrama de los
de otro. El emisor del datagrama debe asegurar un valor único
para la pareja origen-destino y el tipo de protocolo durante el
tiempo que el datagrama pueda estar activo en la red.
Indicadores: utilizado sólo para especificar valores relativos
a la fragmentación de paquetes
Posición de Fragmento: en paquetes fragmentados indica
la posición, en unidades de 64 bits, que ocupa el paquete actual
dentro del datagrama original. El primer paquete de una serie
de fragmentos contendrá en este campo el valor 0.
Tiempo de Vida (TTL): indica el máximo número de routers
que un paquete puede atravesar. Cada vez que algún nodo
procesa este paquete disminuye su valor en, como mínimo, un
routers. Cuando llegue a ser 0, el paquete no será reenviado.
Veremos luego como la aplicación traceroute hace un uso par-
ticularmente ingenioso de este campo.
Protocolo: indica el protocolo de siguiente nivel utilizado
en la parte de datos del datagrama.
Suma de Control de Cabecera: se recalcula cada vez que
algún nodo cambia alguno de sus campos (por ejemplo, el
Tiempo de Vida). El método de cálculo (intencionadamente
simple) consiste en sumar el complemento a 1 de cada palabra
de 16 bits de la cabecera y hacer el complemento a 1 del valor
resultante.
IP de origen y IP de destino: Direcciones de 32 bits.
Dedicamos el apartado 2.7 a hablar del direccionamiento
IPv4.
Opciones: aunque no es obligatoria la utilización de este
campo, cualquier nodo debe ser capaz de interpretarlo. Puede
contener un número indeterminado de opciones, que tendrán
dos posibles formatos:
Vemos en la figura 2.14 la salida del analizador de proto-
colos correspondiente a la parte de la capa de red. La unidad
de trabajo de esta capa es el paquete.
2.5.2. ICMP
ICMP (Internet Control Message Protocol) especifica una
serie de mensajes cuyo propósito es el de gestionar la red. Los
mensajes ICMP se clasifican en errores, peticiones y respuestas.
Los paquetes se identifican por su tipo ("type"), algunos de los
cuales a su vez se subdividen en códigos ("codes"). En la figura
2.15 vemos la cabecera de los paquetes ICMP.
60
Figura 2.14. Captura en Wireshark que
muestra la capa IP de un paquete HTTP.
Nota: El protocolo ICMP es descrito en el RFC 792 (http://tools.

ietf.org/html/rfc792).
Figura 2.15. Cabecera ICMP (cortesía de

Dos de los mensajes ICMP más conocidos son Echo Request

(Figura 2.16) y Echo Reply (Figura 2.17) ambos usados por la
61
orden ping, posiblemente la herramienta más importante a la
hora de comprobar la conectividad entre sistemas en red.
Figura 2.16. Captura Wireshark

de un paquete ICMP Echo Request
Figura 2.17. Captura Wireshark de

un paquete ICMP Echo Reply
62
Otros tipos de mensajes ICMP importantes son Router
Advertisement y Router Selection, tipos 9 y 10, usados por
el protocolo IRDP (Router Discovery Protocol) y Redirect,
ICMP tipo 5, usado por routers para notificar a los equipos de
la existencia de otro router que debe ser usado para alcanzar
una red concreta.
2.6. La capa de acceso a la red

La capa de acceso a la red, a veces denominada capa de
enlace (Link Layer), agrupa los métodos, protocolos y espe-
cificaciones más cercanos a los componentes físicos de la red
usados para interconectar dispositivos. Esta capa combina los
niveles físico y de enlace de la pila OSI y abarca funciones de
exploración de la topología de la red, de descubrimiento de
rutas y de nodos vecinos.
Los protocolos fundamentales pertenecientes a esta capa
son el protocolo de resolución de direcciones (ARP, Address
Resolution Protocol), su primo el Protocolo de Resolución
Inversa de Direcciones (RARP, Reverse Address Resolution
Protocol), y el protocolo de descubrimiento de vecinos (NDP,
Neighbor Discovery Protocol), un servicio similar a ARP para
IPv6. La versión del protocolo de enrutamiento OSPF para
IPv6 (Open Shortest Path First) se considera que trabaja en este
nivel de la pila de protocolos (aunque la versión para IPv4 se
considera que pertenece a la capa de red o Internet). La capa
de enlace agrupa también los métodos de acceso al medio tales
como Ethernet y el resto de protocolos de encapsulación IEEE
802, Frame Relay, ATM, MPLS, Token Ring, HDLC y PPP.
Vemos en la figura 2.18 la parte de la salida de un paquete
capturado con un analizador de protocolos correspondiente
a la capa física y de acceso al medio. La unidad de trabajo de
esta capa es el marco (frame)
2.6.1. ARP
La capa de acceso a la red usa un sistema de direcciones
diferente al usado por el protocolo IP. Por ejemplo Ethernet,
posiblemente el protocolo más utilizado en redes locales, usa
direcciones de 48 bits (las direcciones MAC). Los paquetes de
datos intercambiados en una red Ethernet usan estas direc-
ciones de 48 bits para determinar a qué sistema van dirigidos.
63
El driver de la tarjeta de red examina los paquetes que fluyen
por la red y sólo mira (o debería mirar) los paquetes cuya di-
rección MAC coincide con la propia.
Figura 2.18. Captura Wireshark mostrando la parte de un

paquete correspondiente a la capa física y de acceso al medio.
El protocolo ARP proporciona un mecanismo que relaciona

("mapea") las direcciones IP de 32 bits con las direcciones de
la capa de acceso a la red, por ejemplo las direcciones MAC
de 48 bits.
Nota: El protocolo ARP está definido en el RFC 826 (http://tools.

ietf.org/html/rfc826).
Cuando un dispositivo necesita encontrar la dirección de la

capa de enlace de otro dispositivo, crea una petición ARP con
la dirección IPv4 del dispositivo a encontrar y las direcciones
IPv4 y de enlace (dirección MAC) del emisor. La petición ARP
se encapsula en un paquete con la MAC del emisor como origen
y la dirección de 0.0.0.0 como destinatario. Este proceso aparece
representado de forma gráfica en la figura 2.19.
Todos los equipos en el enlace procesarán el paquete con
la petición ARP (Figura 2.20) y examinarán su contenido. El
dispositivo cuya dirección IPv4 corresponda con la del receptor
de la petición ARP contestará al emisor proporcionándole su
64
dirección MAC (Figura 2.21). El resto de sistemas descartará
el paquete.
Figura 2.19. Mecanismo ARP de petición y respuesta.
Figura 2.20. Captura Wireshark mostrando la petición ARP.
2.6.2. Proxy ARP

Proxy ARP permite a un router responder peticiones ARP
"escuchadas" en una de las redes a las que está conectado di-
rigidas a un equipo que se encuentra en otra de sus redes. El
65
emisor de la petición ARP cree que el router es el equipo al
que va dirigida la petición, cuando en realidad el destino se
encuentra en otra "pata" del router.
El router actúa como un representante, o proxy, en nombre
del equipo final, retransmitiendo los paquetes entre las dis-
tintas redes.
Figura 2.21. Captura Wireshark mostrando la respuesta ARP.
En una situación típica un equipo 192.168.1.1/24 quiere

enviar un paquete al equipo 192.168.2.2/24, pero no tiene
configurada un puerta de enlace y no sabe como alcanzar al
router que lo puede llevar hasta la red de destino. Emitiendo
una petición ARP dirigida al 192.168.2.2 el router local, al es-
cuchar la petición contesta al equipo 192.168.1.1 mandandole
un ARP Reply con su propio identificador de enlace. Cuando
le empiezan a llegar al router los paquetes destinados al
192.168.2.2 los retransmite a la red final.
Nota: Proxy ARP, también denominado ARP promiscuo,

está descrito en los RFCs 925 y 1027.
Proxy ARP está habilitado por defecto en la IOS y puede

ser deshabilitado a nivel de interfaz mediante la orden "no
ip proxy-arp"
66
2.6.3. Gratuitous ARP
A veces un equipo envía una consulta ARP en busca de su
propia dirección IP. Esto puede ocurrir cuando la interfaz se
configure al arrancar el equipo (bootstrap). A este tipo de ARP
se le llama ARP gratuito (gratuitous ARP) y tiene varios usos.
Por ejemplo, un ARP gratuito puede utilizarse para detector
direcciones IP duplicadas: un dispositivo que emita una peti-
ción ARP con su propia IP como destino sabrá que esa IP está
duplicada si escucha una respuesta ARP de otro equipo.
Un ARP gratuito puede también utilizarse para anunciar
una nueva dirección de enlace. Cuando un equipo recibe una
petición ARP para una dirección IPv4 que ya está en su caché
ARP, esta caché se actualiza con la nueva dirección de enlace
del emisor. Esta situación se produce por ejemplo cuando un
router que ejecuta el protocolo HSRP toma el rol de router ac-
tivo emite un ARP gratuito para actualizar las tablas ARP de
los equipos de las redes a las que está conectado.
Nota: Veremos más sobre HRSP (Hot Standby Router

Protocol) en el capítulo 7.
Los ARP gratuitos se encuentran deshabilitados por defecto

en IOS pero se pueden habilitar con la orden "ip gratui-
tous-arps".
2.6.4. Reverse ARP

En vez de mapear la dirección de hardware con direcciones
IPv4, el ARP inverso (RARP) mapea direcciones IPv4 a direc-
ciones de enlace conocidas. Existen dispositivos que pueden
desconocer su dirección IPv4 al arrancar. Si estos equipos
emiten una petición ARP con su propia dirección de enlace
pueden recibir una respuesta de un sevidor RARP que les
asigne una dirección IPv4.
Nota: RARP está definido en el RFC 903 (http://tools.ietf.

org/html/rfc903).
RARP ha sido sustituido por protocolos como Bootstrap

Protocol (BootP) y sobre todo Dynamic Host Configuration
Protocol (DHCP).
67
2.7. Direccionamiento IPv4.
VLSM. Subnetting.
Para saber qué parte de la dirección pertenece a la red y qué
parte a las máquinas, las direcciones IP contienen una clave
capaz de separar la parte correspondiente a la red y la parte que
identifica a los equipos concretos de la red. Los diseñadores del
protocolo IP dividieron el espacio de direcciones disponible en
tres grandes grupos. Si el primer bit de una dirección IP es 0 se
trata de una dirección de clase A y la división red-equipos cae
entre el 7º y el 8º bit. Si los dos primeros bits son 1-0 estamos
ante una dirección de clase B y el punto de separación cae entre
el 15º y 16º bit. Las direcciones de clase C se caracterizan porque
los tres primeros bits son 1-1-0 y la división cae entre el 23º y el
24º bit. Este esquema simplificó el mecanismo de enrutamiento
en los albores de Internet. A las máscaras predeterminadas de
cada clase se les llama máscaras "naturales". Los mecanismos
de enrutamiento que descansan en la distinción "histórica" de
clases se denominan protocolos con clase (classfull).
Una forma de aprovechar mejor el espacio de direcciones
(y simplificar las tablas de rutas) consiste en que los protocolos
de enrutamiento transporten junto con las rutas una "máscara"
que identifique qué parte representa la red y qué parte los
equipos. La máscara es otro número de 32 bits, que lleva unos
en la parte de red y ceros en la de máquina.
El truco para comprender el funcionamiento de las máscaras
y las direcciones está en pasar ambas a binario y ver que los
ceros de la máscara coincidan con ceros en la dirección. Veamos
un ejemplo con la dirección 192.168.0.32 255.255.255.240, que
equivale a 192.168.0.32/28 (barra 28, porque al convertir la
máscara a binario que contiene 28 "unos" seguidos):
Tabla 2.1.
Decimal Binario
192.168.0.32 11000000 . 10101000 . 00000000 . 00100000

255.255.255.240 11111111 . 11111111 . 11111111 . 11110000
Los unos de la máscara corresponden con la parte de la

dirección que especifica la red. Los ceros de la máscara corres-
ponden con la parte de la dirección que identifica máquinas
concretas. Hay dos direcciones especiales de ese espacio de host
68
reservado a los equipos: la dirección todo unos (difusión, broad-
cast) y todo ceros (identifica una red o subred completa). En el
ejemplo anterior vemos que "11000000 . 10101000 . 00000000 .
0010" es la dirección de subred, y que el resto de la dirección es
todo ceros. Esto identifica la subred 192.168.0.32, con espacio
para 14 equipos (del 1 al 14, en binario del 0001 al 1110). Las
dos direcciones restantes son la 0 (bin 0000), que identifica la
subred completa, y la 15 (bin 1111) de difusión.
En realidad la operación que hacen las máscaras con las
direcciones es la Y lógica, y el resultado es la dirección de
red:
Tabla 2.2.
11000000101010000000000000100101 IP
11111111111111111111111111110000 Máscara
11000000101010000000000000100000 Red
La siguiente analogía (aunque algo local) terminará de

aclarar el concepto de máscara de red: si ve el número de te-
léfono 34918110065 sabrá que el teléfono es de España (34) y
más concretamente de Madrid (91). Esto es porque ha aplicado
la "máscara natural" (11110000000) que le ha permitido saber
qué parte es la del país y ciudad (3491) y qué parte la de abo-
nado (8110065). Como sería técnicamente inviable distribuir de
forma aleatoria los 9999999 teléfonos posibles, lo que se hace es
usar parte de los números de abonado para especificar la zona
(la "subred"). De hecho, la "máscara de subred" que aplicamos
es 11111110000.
Puede que no sepa a qué "subred" pertenece el 811 dentro
de la "red principal" 91, pero intuitivamente usamos este
tipo de mecanismos para saber si la llamada que vamos a
realizar es local (directa), provincial (a través de uno o más
routers), etc... Esto no es casual: la red telefónica es un cla-
rísimo ejemplo de red jerárquica con el que todos estamos
muy familiarizados.
La figura 2.22, perteneciente a xkdc, el "webcomic de ro-
mance, sarcasmo, matemáticas y lenguaje" de Randall Munroe,
muestra el reparto de direcciones de Internet sobre un plano
usando una técnica fractal que preserva la agrupación. Pueden
apreciarse los grandes bloques correspondientes a las clases
A (IBM la 9/8, HP la 15/8, Apple la 17/8...) en el cuadrante
superior izquierdo del esquema.
69
Figura 2.22. Representación del reparto
del espacio IPv4 (cortesía de Randall "xkdc" Munroe)
Nota: Inspirados por xkdc investigadores del grupo CAIDA

(Cooperative Association for Internet Data Analysis) esca-
nearon Internet, mapeando el espacio unidimensional IPv4
sobre una matriz bidimensional de 4096 x 4096 pixeles usando
una curva de Hilbert de dimensión 12. Puede explorar el
resultado en http://wanlinksniper.blogspot.com/2009/03/
70
representacion-fractal-del-espacio-ip.html. Una base de datos
como ipindex (http://ipindex.homelinux.net/)
puede ayudar a explorar el espacio IP desde una perspectiva
más tradicional.
El espacio de direcciones IPv4 se está agotando. El RFC

1918 (http://tools.ietf.org/html/rfc1918) surgió
como respuesta a esta circunstancia y propone el uso de las
redes 10.0.0.0, 172.16.0.0 a 172.31.255.255 y 192.168.0.0 para
uso privado (son direcciones que cualquiera puede usar sin
necesidad de registrarlas). El mecanismo de traducción de di-
recciones NAT (Network Address Translation) también permite
que muchas máquinas internas (que pueden usar direcciones
RFC 1918) compartan una única dirección pública, que son un
recurso escaso.
Nota: Veremos NAT en el capítulo 7.
La solución definitiva a la escasez de direcciones es la

progresiva implantación del protocolo IPv6, que utiliza direc-
ciones de 128 bits frente a los 32 de IPv4. Esto no significa que
el espacio de direcciones sea cuatro veces mayor: un espacio
de direcciones de 128 bits permitiría que cada usuario actual
tuviese un conjunto de direcciones para su uso exclusivo del
tamaño de Internet, y seguirían sobrando. No obstante, IPv6
preveé formas más eficientes de reparto de direcciones que las
dispuestas para IPv4.
2.8. Movimiento de paquetes

en un enlace.
Recapitulemos mediante el ejemplo de la figura 2.23 todo lo
que hemos aprendido. Tenemos un PC1 que quiere mandar un
paquete al Servidor Web. Vemos a continuación los pasos que
debe dar el paquete en la red y las decisiones que deben tomar los
elementos de la red para que el paquete alcance su destino.
El PC1 tiene un paquete para Servidor Web. Comparando
la dirección IP del servidor con la dirección y máscara propia
determina que el destino se encuentra en una red distinta.
Comprueba la tabla ARP y busca la dirección de capa 2 o MAC
del gateway por defecto, y genera un paquete Ethernet con IP
de destino de Servidor Web pero con la MAC de Router1.
71
Figura 2.23. Red de ejemplo
Cuando el Router1 recibe la trama Ethernet la procesa, dado

que viene con la MAC de una de sus interfaces, sin embargo
al desencapsular el paquete y examinar la dirección IP se en-
cuentra con que la dirección IP de destino no pertenece ni a sí
mismo ni a ninguna de las redes a las que está directamente
conectado. Mira en su tabla de rutas y encuentra una para la
red destino a través de una interfaz serie que tiene una conexión
punto a punto contra Router2. Vuelve a encapsular el paquete
en esta ocasión en una trama HDLC, con la IP de Servidor1
como destino pero con dirección destino 0x8F (en los enlaces
serie no hay direcciones MAC)
Cuando el paquete llega a Router2 repite las operaciones
anteriores. Desencapsula el paquete HDLC, ve que la IP de
destino ni le pertenece y tiene conexión directa con esa red,
mira la tabla de rutas, encuentra una y encapsula de nuevo el
paquete, esta vez en una trama Frame Relay. Como dirección
de enlace de destino usará el valor del DLCI que interconecta
el Router 2 con el 3 como identificador de direccionamiento
de capa 2 del protocolo Frame Relay.
El Router 3 si que tiene conexión directa con la red a la que
pertenece la IP del Servidor Web. Es posible que en la tabla
ARP no haya una entrada para Servidor1, si es preciso Router3
hará una petición de resolución ARP para añadir la MAC de
Servidor Web a su tabla ARP. Finalmente una trama Ethernet
72
llegará al Servidor Web, que desencapsulará y procesará el
paquete hasta el nivel de aplicación correspondiente.
2.9. El futuro inmediato de IP: IPv6.

El protocolo IPv6 es una nueva versión de IP (Internet
Prococol) diseñada para reemplazar a la versión 4 (IPv4) ac-
tualmente en uso. IPv6 está destinado a sustituir a IPv4, cuyo
límite en el número de direcciones de red admisibles está empe-
zando a restringir el crecimiento de Internet. El nuevo estándar
mejorará el servicio globalmente proporcionando por ejemplo
direcciones propias y permanentes a dispositivos móviles.
IPv6 fue propuesto por el Internet Engineering Task Force en
1994. IPv6 ofrece además servicios de forma nativa tales como
Calidad de Servicio (QoS) y seguridad.
El cambio más grande de IPv4 a IPv6 es la longitud de las
direcciones de red. Las direcciones IPv6, definidas en el RFC
2373 y RFC 2374, son de 128 bits; esto corresponde a 32 dígitos
hexadecimales, que se utilizan normalmente para escribir las
direcciones IPv6.
IPv4 posibilita 232 (4.294.967.296) direcciones de red dife-
rentes. Es un número grande pero insuficiente para asignar una
dirección a cada persona del planeta, y menos a cada vehículo,
teléfono o PDA. IPv6 admite 2128 direcciones
232 = 4.294.967.296
2128 = 340.282.366.920.938.463.463.374.607.431.768.211.456
En muchas ocasiones las direcciones IPv6 están compuestas
por dos partes de 64 bits, un prefijo y un identificador de
interfaz (casi generado a partir de la dirección MAC de la
interfaz)
Los 128 bits de las direcciones IPv6 se suelen representar en
ocho grupos de cuatro dígitos hexadecimales, por ejemplo:
2001:0db8:85a3:08d3:1319:8a2e:0370:7334
Si un grupo de cuatro dígitos toma el valor "0000" puede
ser comprimido con "::", quedando la dirección anterior
2001:0db8:85a3::1319:8a2e:0370:7344
Si más de dos grupos consecutivos son nulos, pueden com-
primirse como "::", pero si la dirección tiene más de una serie
de grupos nulos consecutivos la compresión sólo se permite
73
en uno de ellos. Así, las siguientes son todas representaciones
válidas de la misma dirección:
2001:0DB8:0000:0000:0000:0000:1428:57ab
2001:0DB8:0000:0000:0000::1428:57ab
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab
pero en cambio
2001::25de::cade
no es válida porque no puede saberse cuántos grupos nulos
hay en uno de los "::".
Los ceros iniciales en un grupo pueden ser omitidos:
2001:0DB8:02de::0e13
2001:DB8:2de::e13
Figura 2.24. Cabecera IPv6 (cortesía de Matt Baxter

http://www.fatpipe.org/~mjb/Drawings/).
Vemos en la figura 2.24 la cabecera IPv6. Este protocolo hace

uso de un formato flexible de cabeceras de extensión opcionales
que permite ir añadiendo funcionalidades a medida que vayan
haciendo falta. Existen verios tipos de cabeceras de extensión,
74
donde la cabecera fija y las cabeceras de extensión opcionales
incluyen el campo de cabecera siguiente que identifica el tipo
de cabeceras de extensión que viene a continuación o el identi-
ficador del protocolo de nivel superior. Luego las cabeceras de
extensión se van encadenando utilizando el campo de cabecera
siguiente que aparece tanto en la cabecera fija como en cada
una de las citadas cabeceras de extensión.
En el momento de publicar el libro estos son los 8 tipos
de cabaceras IPv6: Cabecera principal, Cabecera de opciones
de salto a salto (Hop-by-Hop), Cabecera de encaminamiento
(Routing), Encaminamiento desde la fuente, Cabecera de frag-
mentación (Fragment), Cabecera de autenticación (Authentication
Header), Cabecera de encapsulado de seguridad de la carga útil
(Encapsulating Security Payload) y Cabecera de opciones para
el destino (Destination).
2.10. Los RFC

Al hablar de los protocolos de Internet resulta inevitable
hacer mención a los RFCs (del inglés Request For Comments o
Peticiones de Comentarios). Cada RFC es un documento pu-
blicado por la IETF (Internet Engineering Task Force) a través del
cual uno o varios autores proponen nuevos estándares o ideas.
El que se denominen "Peticiones de Comentarios" resulta algo
confuso, dado que en la práctica los RFCs constituyen las leyes
de facto de Internet. El término deriva de la función original de
los RFCs como mecanismo de solicitud de revisión por parte
de la comunidad Internet.
Existen diversas categorías de RFCs: Estándar (Standards track
o STD), a su vez divididos en Proposed Standard, Draft Standard
e Internet Standard, constituyen las especificaciones oficiales
de los protocolos. Informativos (Informational), Experimentales
(Experimental), Mejores Prácticas (Best Current Practice o BCP)
que constituyen las recomendaciones oficiales del IETF y los
RFC Históricos (Historic), que han sido dejados obsoletos por
versiones más modernas del protocolo que describen.
Los candidatos a RFC se presentan como borradores (Internet
drafts), y pasan por un ciclo de edición y revisión. Cualquiera
puede mandar un borrador informativo o experimental para
ser revisado, pero los Standards track y los BCP deben venir de
un grupo de trabajo del IETF (IETF working group). El proceso
es minucioso dado que una vez publicados no se modifican. El
75
editor de los RFCs asigna a cada RFC un número que ya no se
borra ni cambia. Si es preciso modificar el RFC se publica otro
RFC con un nuevo número que complementa o hace obsoleto
el anterior. El proceso de publicación está descrito, cómo no,
en un RFC: el RFC 2026.
Aunque los RFCs se pueden obtener en muchos sitios, el mejor
es la propia web de IETF, en la dirección Web http://tools.
ietf.org/html/.
Los RFC poseen un formato bien definido. En la figura 2.25
mostramos la cabecera de los RFC, donde disponemos de la
siguiente información
1. Barra de color indica el status (amarillo experimental,
rojo borrador…)
2. Enlace al borrador original (Internet draft).
3. Actualizaciones a este RFC desde su publicación
4. Grupo de trabajo IETF
5. Número de serie
6. RFCs al que éste actualiza o deja obsoleto
7. Status
8. Enlace a las correciones menores.
9. Autor(es)
10. Fecha
11. Título
Figura 2.25. Cabecera RFC (Request For

Comments o Peticiones de Comentarios).
76
3
Operación de
un router Cisco
En este capítulo aprenderemos a manejar un router Cisco.

Tras revisar la estructura interna del mismo, presentamos las
diversas opciones disponibles para acceder al router, el fun-
cionamiento de la interfaz de comandos y cómo introducir
una configuración básica. También veremos cómo realizar
operaciones frecuentes de administración del router y el pro-
cedimiento de recuperación de contraseñas.
3.1.Componentes de los routers Cisco

Como cualquier ordenador, los routers Cisco se componen
de una serie de elementos hardware y software. Veamos a con-
tinuación los componentes más característicos de los routers.
3.1.1. Componentes Hardware.

El corazón del router es el microprocesador o CPU, que le
permite ejecutar las instrucciones del sistema operativo. La
CPU ejecuta las instrucciones definidas en el sistema operativo
IOS, creando y manipulando las estructuras de datos necesa-
rias. Estas instrucciones y datos se almacenan en la memoria
del router, de la que existen distintos tipos.
La memoria flash es un tipo de memoria no volátil donde
se guarda una copia del sistema operativo de los routers Cisco,
la IOS. Este tipo de memoria además permite que múltiples
posiciones de memoria sean escritas o borradas en una misma
operación de programación mediante impulsos eléctricos,
frente a otros tipos de memoria que sólo permiten escribir o
borrar una única celda cada vez.
77
Figura 3.1. Estructura interna de un router.
Otra memoria característica de los routers es la NVRAM

(Non Volatile RAM), una memoria permanente donde se al-
macena la configuración de arranque del router (la startup
configuration).
Cuando se conecta el router, el microprocesador busca y
ejecuta las instrucciones contenidas en la memoria ROM (Read
Only Memory), una memoria de sólo lectura, no volátil. En esta
memoria, generalmente tipo EPROM (Erasable programmable
read-only memory), se almacena de forma permanente el ROM
Monitor, un software que proporciona un conjunto mínimo
de órdenes con las que recuperar el sistema o indicarle cómo
arrancar, y el RxBoot, el programa encargado de encontrar y
cargar una copia de la IOS en la RAM.
La memoria RAM (Random Access Memory) es una me-
moria volátil de alta velocidad en la que al arrancar el router
se almacena una copia del sistema operativo IOS junto con
la configuración del router. La RAM se divide a nivel lógico
en memoria principal (Main Processor memory) y en memoria
compartida de entrada/salida (Shared Input/Output).
Las interfaces son los puntos de conexión de los routers con
el exterior. Los routers conectan redes de distintos tipos, y para
conectarlas ofrecen interfaces o puertos adecuados a cada tec-
nología de red. Según el modelo de router las interfaces pueden
ser fijas, modulares o una combinación de ambas. Los routers
modulares incorporan ranuras de expansión (slots) donde se
insertan las tarjetas de red (módulos).
78
Nota: Los routers modulares tienen slots de expansión, puertos
en los que conectar diferentes WIC (WAN interface cards).
Estas WIC son tarjetas de red especializadas que permiten al
router conectarse y transmitir datos a través de una red WAN.
Las WIC pueden tener una CSU/DSU (Data Service Unit)
integrada que proporciona correción de errores y monitorización
de la línea. Algunos modelos especializados son las WICs de
alta velocidad HWICs (High-Speed WAN Interface Cards) y
las VWICs (Voice WAN Interface Cards) para voz y datos.
Todas ellas usan una serie de controladores especializados
basados en circuitos integrados desarrollados específicamente
para realizar la tarea que tienen encomendada denominados
ASICs (Application-Specific Integrated Circuits).
El puerto de consola (CONSOLE) permite al administrador

conectarse al router mediante un ordenador directamente.
Algunos modelos también poseen un puerto auxiliar (AUX)
que permite la conexión de un módem para acceder en caso
necesario. Veremos los detalles concretos en los siguientes
apartados.
Los distintos elementos hardware del router se interco-
nectan a través de una serie de canales de datos (buses), a través
de los cuales se transfieren las instrucciones y datos entre los
componentes del router. Hay un bus de la CPU de alta velo-
cidad a través del cual el procesador tiene acceso directo a la
memoria RAM, a la Boot ROM, a la NVRAM, a la memoria
Flash así como a las WIC. El I/O bus permite al procesador
controlar los dispositivos de Entrada/Salida mediante canales
serie (Serial Communication Channels, SCC), entre los que se
incluyen controladores Ethernet, WAN y UART (Universal
Asynchronous Receiver/Transmitter).
No sorprenderá indicar en este punto que los routers también
tienen fuente de alimentación, y en algunos casos, varias.
3.1.2. Componentes Software.

En el apartado anterior mencionamos dos importantes pro-
gramas de los routers Cisco, el ROMmon (o ROM monitor) y
el Bootstrap (o RxBoot).
El ROM monitor o ROMmon es un programa diagnóstico
que proporciona al operador un conjunto de órdenes que per-
miten realizar procedimientos de recuperación, típicamente
de contraseñas, pero también de imágenes corrompidas o
79
erróneas de la IOS. Este modo también permite modificar el
registro de configuración del equipo y realizar actualizaciones
del sistema operativo.
El Bootstrap o RxBoot es un programa cuya función es en-
contrar y cargar una copia de la IOS en la RAM, para lo que se
basa en el registro de configuración. Según esté configurado
el registro RxBoot buscará la IOS en la Flash, en una tarjeta
PCMCIA o la obtendrá por la red mediante el protocolo TFTP
(Trivial File Transfer Protocol). Lo más normal es que la IOS esté
en una memoria tipo Flash.
Sin embargo, el programa más importante de los routers
Cisco es su sistema operativo, IOS (Internetwork Operative
System). IOS proporciona las funciones generales que cual-
quier sistema operativo moderno y multitarea debe pro-
porcionar: abstracción del hardware a los desarrolladores y
gestión de los recursos compartidos (ciclos de la CPU, me-
moria, discos…). Pero IOS no es un sistema operativo cual-
quiera, sino un software especializado en conmutar paquetes
de la forma más rápida y eficiente. Cisco IOS es el software
usado en casi todos los routers y switches Cisco (algunos
switches usaban originalmente otro sistema operativo, el
Catalyst Operative System o CatOS).
De los múltiples procesos que IOS gestiona hay uno, el
parser, que se encarga de crear el resto de procesos. El parser
es invocado a través de la CLI (command line interface), la ca-
racterística línea de comandos de los routers. La línea de com-
mandos de Cisco ha sido imitada por muchos otros produtos
de redes y seguridad.
A través de la línea de commandos IOS proporciona un
conjunto de órdenes determinado por el "modo" en que se
encuentra (global, interfaz) y el "nivel de privilegios" del ad-
ministrador, nivel que va del 0 ó mínimo a 15 o control total.
3.1.3. Arquitectura.
En todas las versiones IOS el enrutamiento (routing) y el
reenvío (forwarding) son procesos diferentes. El enrutamiento
contribuye a crear la tabla RIB (Routing Information Base), que
a su vez es procesada para generar la tabla de reenvío FIB
(Forwarding Information Base).
IOS posee una arquitectura "monolítica", lo que significa
que se ejecuta como una única imagen, compartiendo todos los
procesos el mismo espacio de memoria. No hay protección de
80
memoria entre los procesos con lo que los errores de IOS pueden
corromper los datos usados por otros procesos. Tiene un algo-
ritmo de planificación de tipo completo (completion scheduler): el
kernel no expulsa (pre-empt) los procesos en ejecución, siendo el
proceso responsible de ceder el uso de la CPU mediante unalla-
mada al kernel para que otros procesos puedan ejecutarse.
Cisco ha desarrollado para las gamas altas una nueva
versión de IOS denominada IOS XR que ofrece modularidad
y protección de memoria, hilos, planificación con expulsión
(pre-emptive scheduling) y otras características propias de los
sistemas operativos emergidos en los últimos 15 años. QNX, el
microkernel de IOS XR, y una gran parte de los procesos IOS
fueron reescritos para sacar partido de las características que
ofrece el nuevo sistema. La arquitectura microkernel saca del
kernel los procesos innecesarios y los ejecuta como procesos
con privilegios similares a los del resto de aplicaciones.
IOS empezó siendo un pequeño sistema operativo empo-
trado, pero con el tiempo se ha convertido en el sistema ope-
rativo de una gran cantidad de plataformas: existen múltiples
versiones, de forma que hace tiempo se han establecido dos
conjuntos de nomenclaturas para identificar las imágenes IOS,
el sistema clásico (legacy) y el sistema actual.
Nota: En el enlace http://www.cisco.com/warp/

public/620/1.html podemos ver las características de
ambos sistemas.
IOS: nomenclatura clásica

Cisco describía las versiones de IOS anteriores a la 12.3
usando una combinación de letras y números al que ahora se
conoce como el "Legacy Naming" o sistema clásico. Un ejemplo
aclarará cómo funcionaba este sistema. La siguiente salida es
parte de un "show version" extraido de un router 2611:
System image file is "flash:c2600-ik9o3s3-mz.122-15.bin"
Este nombre se interpreta de la siguiente forma: c2600 in-
dica que la plataforma es la serie 2600, la i en ik9o3s3 indica
que es una versión "IP routing", k9 indica el uso de encripta-
ción 3DES en esta versión de IOS, o3 indica que esta versión
tiene funcionalidades Firewall/IDS, s3 indica que se trata de
la versión "Basic limited routing / limited memory", mz indica
que esta IOS se ejecuta desde la RAM y está comprimida y
122-15 indica que ésta es una IOS versión 12.2 con un nivel de
parcheado (patch level) 15.
81
En las tablas 3.1, 3.2 y 3.3 podemos ver algunos de los có-
digos usados para interpretar las denominaciones propias de
este sistema.
Tabla 3.1. Letras al comienzo.

Identificador Significado
a2 ATM
a3 SNASW
b Appletalk Routing
c Remote Access Server
d Desktop routing
g5 Enterprise Wireless (7200)
i IP routing
j Enterprise
n IPX Routing (low-end routers)
p Service Provider (or DOCSIS for uBR)
r(x) IBM
telco Telco
y/y5 IP Routing
y7 IP ADSL.
Tabla 3.2. Letras centrales.

56i Criptografía (DES)

ent Plus
k1 BPI
kx Criptografía (DES=k8, 3DES=k9)
o Firewall
o3 Firewall e IDS
s Plus "LAN Only" (Cat6K/7600)
s2 Vo i c e I P t o I P Vo i c e G a t e w a y
(26xx/36xx/37xx)
s3 "Basic" limitado, IP routing, 26xx, 36xx
s4 "Basic" sin switching
t Telco
82
v VIP
w6 Wireless
x MCM
Tabla 3.3. Letras finales.

l La imagen se ejecuta desde la Flash

m La imagen se ejecuta desde la RAM
z La imagen se encuentra comprimida
IOS: nomenclatura nueva

El sistema nuevo simplifica el esquema anterior y permite
establecer rápidamente las características de las imágenes IOS.
En este sistema las imágenes se identifican por un código tipo
PPPPP-FFFF-MM, donde PPPPP representa la plataforma,
FFFF las características y MM el tipo de memoria donde corre
y la forma de compresión. El siguiente ejemplo está extraido
de router Cisco de la serie 3700.
C3725-entbase-mz.124-6.bin
Este nombre se interpreta de la siguiente forma: C3725 in-
dica el hardware, entbase el conjunto de características o "fea-
ture set", mz el tipo de compresión y 124-6 el número de versión
(12.4 de maintenance release y 6 como individual release).
Las IOS en la actualidad se presentan en los siguientes
paquetes de características o "feature sets": IP Base, IP Voice,
Enterprise Base, Advanced Security, SP Services, Advanced
IP Services, Enterprise Services y Advanced Enterprise
Services.
Así, la versión mostrada antes c2600-ik9o3s3-mz sería en el
sistema nuevo una c2600-advsecurityk9-mz. El Advsecurity
es el paquete Advanced Security que posee las características de
Firewall, IPSEC, 3DES, VPN y SSH.
Los paquetes anteriores se pueden agrupar a su vez en Base
(nivel de entrada , donde irían los paquetes IP Base y Enterprise
Base); Services (donde van los paquetes SP Services y Enterprise
Services y se añade soporte de telefonía IP, MPLS, Voz sobre IP,
Voz sobre Frame Relay y ATM); Advanced (donde irían los
83
paquetes Advanced Security y Advanced IP Services que añaden
soporte de VPN, Cisco IOS Firewall, criptografía 3DES, SSH,
Cisco IOS IPsec e Intrusion Detection Systems); y Enterprise (pa-
quetes Enterprise Base y Enterprise Services que añaden soporte
multiprotocolo: IBM, IPX, AppleTalk…)
La tabla 3.4 muestra las denominaciones de las distintas
IOS en función de sus características (Feature Set).
Tabla 3.4. Características (Feature Sets).

cxxxx-ipbase-mz IP Base
cxxxx-ipvoice-mz IP Voice
cxxxx-advsecurityk9-mz Advanced Security
cxxxx-spservicesk9-mz Service Provider
cxxxx-entbase-mz Enterprise Base
cxxxx-advipservicesk9-mz Advanced IP Services
cxxxx-entservicesk9-mz Enterprise Services
cxxxx-adventerprisek9-mz Advanced Enterprise Services
En ambos sistemas "k9" en una imagen siempre significa

criptografía fuerte, como por ejemplo Triple DES o AES. El
código "xxxx" determina la plataforma (por ejemplo: c2600-
ipbase-mz), c2600 nos indica que se trata de un Cisco 2600. En
la tabla 3.5 mostramos algunas plataformas.
Tabla 3.5. Plataformas.

as Access Server 5200 series

c800 Cisco 800
c1600 Cisco 1600
c2500 Cisco 2500-2525 routers
c2600 Cisco 2610-2613 series routers
c2800 Catalyst 2800
c2900 Cisco 2910, 2950
c29atm Cisco 2900 ATM
c3620 Cisco 3620
84
c3640 Cisco 3640

c3800 Cisco 3800
c5200 AS5300
c4000 Cisco 4000 series routers
c5rsm Catalyst 5000 RSM
c6400s Cisco 6400 NSP, Cisco 6400 NRP
c6400r Cisco 6400 NSP, Cisco 6400 NRP
c7000 Cisco 7000, 7010
c7200 Cisco 7200
Igs IGS, 2500, 3000, and 5100 series routers
gs3 AGS and AGS+ gateway routers
gs7 7000 series gateway routers
Gsr Gigabit Switch Router (12000)
RSP Cisco 7500 series
Tabla 3.6. Características.

A APPN
A2 ATM
B AppleTalk
BOOT Boot image
C Remote Access Server
D Desktop subset (SNMP, IP, BRIDGING, WAN,
IPX, ATALK)
F FRAD subset
G RDSI
I IP subset
J Enterprise
K Criptografía
M RMON
N IPX
85
O Firewall
P Service provider (IP RIP/IGRP/EIGRP/OSPF/
BGP CLNS ISIS/IGRP)
R RSRB (remote source route bridging)
S Source route switch (SNMP, IP, BRIDGING,
SRB)
V VIP y soporte RSP
X X.25 (11.1), Frame Relay (11.2)
X H.323 Gatekeeper/Proxy (2500, 3620, 3640,
MC3810)
Y Reduced IP: SNMP, IP RIP/IGRP/EIGRP,
BRIDGING, ISDN, PPP
Tabla 3.7. Lugar de ejecución.

Identificador Características
C Flash card (PCMIA)

F Flash
L Imagen reubicable
M RAM
R ROM
Z X W Imagen comprimida
3.1.4. Sistema de ficheros del Router

El sistema operativo IOS proporciona un sistema de fi-
cheros (filesystem) en el que almacenar los diferentes archivos
necesiarios para el funcionamiento del sistema. Hay tres clases
de filesystems
Tabla 3.8. Lugar de ejecución.

Clase Plataformas
Clase A 7000 series, C12000 y LightStream 1010

Clase B 1003, 1004, 1005, 2500, 2600, 3600, 4000,
AS5200, 800
Clase C 3810, disk0 del SC3640
86
El más habitual es el B. La diferencia entre ellos está en los
comandos que soportan
Tabla 3.9. Comandos según sistema de ficheros.

Comando Sistema Descripción
de Ficheros
cd Todos Cambia el directorio de trabajo

delete Todos Borra un fichero.
dir Todos Muestra los contenidos, admite la
opción /all.
erase A, B Borra el filesystem por completo
format A, C Formatea el filesystem.
fsck C Verifica la consistencia del
filesystem
mkdir C Crea un nuevo directory.
more Todos Muestra los contenidos de un
fichero
pwd Todos Muestra posición actual dentro
del FS
rename C Renombra un fichero
rmdir C Borra un directorio
show file Todos Muestra los descrip-
descriptors tores de los ficheros abiertos
show file Todos Informa del tamaño y localización
information del fichero
show file Todos Muestra los filesystems
system disponibles
squeeze A Defragmenta, comprime y purga
el FS
tftp-server Todos Hace que el dispositivo actúe como
un servidor TFTP.
undelete A, B Recupera ficheros borrados.
verify Todos Verifica el checksum de un fichero
Todos ellos usan una notación similar a las URL para espe-
cificar los nombres y la localización de los ficheros:
prefijo:ruta/nombre
prefijo://servidor/ruta/nombre
prefijo://usuario:contraseña@servidor/ruta/fichero
87
En la práctica las tres órdenes más usadas para mover ficheros
de un lado a otro son "copy tftp flash", "copy rcp flash"
y "copy slot0: slot1:". Veamos un ejemplo configurando el
routerA (IP 10.1.1.1) como servidor TFTP para que comparta la
imagen "c2500-js-l.122-9a" y el routerB como cliente TFTP.
RouterA#configure terminal
RouterA(config)# tftp-server flash:/c2500-js-l.122-9a
RouterB#copy tftp flash

Address or name of remote host []?10.1.1.1
Source filename []?/c2500-js-l.122-9a
Destination filename [c2500-js-l.122-9a ]?
Accessing tftp://10.1.1.1//c2500-js-l.122-10a...
Erase flash: before copying? [confirm]
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeee ...erased
Loading /c2500-js-l.122-10a from 10.1.1.1 (via Ethernet0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!
[OK - 15694836/16777216 bytes]
Verifying checksum... OK (0x36D1)
El prefijo indica dónde está el fichero. La ruta el directorio

donde se encuentra el fichero Algunos prefijos como ftp o tftp
denotan servidores a los que es preciso acceder con un usuario
y una contraseña.
Tabla 3.10. Prefijos.

Prefijo Definición
bootflash Memoria Bootflash

flash Memoria Flash.
ftp Servidor FTP
null Papelera.
nvram Memoria no volátil
rcp Servidor RCP.
slot0 Primera tarjeta flash PCMCIA
slot1 Segunda tarjeta flash PCMCIA
system Memoria volátil del sistema.
tftp Servidor TFTP
3.1.5. Arranque del router

Describimos en esta sección la secuencia de arranque de
un router Cisco. Aunque cada modelo de router posee una
secuencia de arranque propia este ejemplo del arranque de
88
un router la serie 1600 es muy representativo de la forma de
arrancar de los routers Cisco en general.
En primer lugar se ejecuta la boot ROM, una memoria de
sólo lectura que lanza el proceso. En función del valor del re-
gistro de configuración almacenado en la NVRAM el router
ejecuta el programa ROMmon o el programa RxBoot.
El programa ROMmon permite controlar el registro de con-
figuración, cambiar parámetros de la consola, ejecutar pruebas
diagnósticas del hardware y restaurar la imagen IOS cuando por
alguna razón la que está en el router no permite arrancar.
RxBoot analiza el hardware y en función del registro de
configuración carga la imagen IOS (si es preciso a través de
la red), ejecutándola desde la PCMCIA Flash o en la memoria
RAM. Esta imagen IOS vuelve a analizar el hardware. El fi-
chero de configuración del router almacenado en la memoria
NVRAM puede contener llamadas de arranque (boot system
commands) del tipo "boot system flash slot0:c1600-
sy-l.122-1a.bin" que fuerza al RxBoot a buscar la imagen
c1600-sy-l.122-1a.bin en la memoria Flash insertada en el slot
número 0. La orden "boot system" del fichero de configura-
ción toma preferencia sobre el registro de configuración.Si no
hay un "boot system" en la configuración y el registro está
en su valor por defecto RxBoot carga la primera imagen que
encuentra en la Flash y, si esto falla, carga una imagen mínima
que viene en la boot ROM.
Finalizadas las comprobaciones hardware, IOS crea una
serie de estructuras de datos tales como IDBs (Interface Descriptor
Blocks), así como asignaciones de buffers patra las interfaces y
otros procesos (buffers I/O), y carga y ejecuta la configuración
desde la NVRAM.
3.2. Instalación y configuración Inicial

3.2.1. Instalación inicial
Junto con su router Cisco, y dependiendo del modelo adqui-
rido, vendrán una serie de elementos. Típicamente encontrará
un cable de consola de color azul claro; si el cable de consola
tiene conectores RJ45 a ambos lados vendrán adaptadores
DB-25 a RJ-45 y DB-9 a RJ45; la fuente de alimentación con
su cable de corriente y finalmente la documentación y CDs.
Nosotros debemos aportar los cables serie, Ethernet, transceivers
y WICs (WAN Interface Cards).
89
Una vez desembalado todo y comprobado que no falta
nada, procederemos a instalar las interfaces WAN (WIC), co-
nectar el router a la red local (LAN) y a la línea WAN (Punto
a Punto, Frame relay, ADSL, RDSI…) y finalmente conectar
el router a la red eléctrica. Según el modelo se encenderán una
serie de LEDs mostrando el estado en el que se encuentra el
router. Estos LEDs pueden estar tanto en la parte frontal como
en la trasera del router, y encontraremos en la documentación
del router el significado concreto de cada LED, aunque el verde
en general es buena señal ("green is good"). Los indicadores típicos
que aparecen en el frontal son los que indican el correcto funcio-
namiento del equipo (OK), la actividad de la red local (LAN),
detección de portadora ADSL (CD) o RDSI (ISDN CH1/CH2),
indicadores de transmisión (TXD) y recepción (RXD). En la parte
trasera conviene fijarnos en el indicador de conexión (LNK) que
aparece junto a los distintos conectores Ethernet y Serie.
En lo que respecta a la conexión del router con la red local,
tenemos varias posibilidades. La más normal es la de conectar
el router a un hub o switch Ethernet, y en este caso necesita-
remos un cable Ethernet RJ-45 a RJ-45 plano o directo, el usado
para conectar dispositivos desiguales. Si en cambio conectamos
el router directamente a un PC o portátil necesitaremos un
cable Ethernet RJ-45 a RJ-45 cruzado (como el que usaríamos
para conectar dos PCs directamente entre si).
Nota: En el capítulo 4 dedicamos el apartado 4.2 a la conexión

y configuración de las interfaces LAN.
Recordemos como reconocer cada tipo de cable. En la figura

3.2 vemos los pines de un conector RJ-45 (Registered Jack)
En el diagrama de la Figura 3.3 vemos la relación entre los
pines de los distintos cables.
Figura 3.2. Detalle del patillaje eléctrico (pines) de un conector RJ-45
90
Figura 3.3. Conexionado eléctrico
(pines) de un conector RJ-45.
Para reconocer el tipo de cable RJ-45 que estamos mane-

jando debemos sostener frente a nuestros ojos ambos extremos
del cable de forma que los conectores presenten la misma
orientación, como en la Figura 3.4.
En un cable plano (también llamado directo, patch o straight)
la relación es del pin 1 al 1, del 2 al 2, etc…
91
En un cable cruzado (crossover) la regla "13-26" (pin 1 al 3 y
2 al 6) sirve para reconocer un cable cruzado de forma rápida,
aunque luego sigue cruzando el 4 con el 7 y el 5 con el 8, así
que la relación completa es "13-26-47-58".
Figura 3.4. Comparando pines: cable

cruzado (pines 1 al 3 y 2 al 6).
Un cable de consola (rollover) va completamente cruzado:

el 1 al 8, el 2 al 7, 3 al 6, etc
En lo que respecta a la conexión WAN, usaremos el cable
que nos indique el proveedor del circuito. Por ejemplo en un
router ADSL con conector ADSLoPOTS (ADSL over Plain
Old Telephone System) usaremos un cable estándar RJ-11. Si
tenemos una conexión serie necesitaremos un cable específico
según la interfaz del router y la que presente la unidad de
terminación de red (CSU/DSU) del proveedor de servicios
de telecomunicaciones.
A continuación, la figura 3.5 muestra algunos de los prin-
cipales cables utilizados en esta situación.
Nota: En el capítulo 4 dedicamos el apartado 4.3 a la conexión

y configuración de los enlaces WAN.
92
Figura 3.5. Cables Serie.
3.2.1. Métodos de conexión al router

Puede acceder al router conectándose directamente al
mismo por el puerto de consola, mediante la aplicación es-
tándar telnet, a través de un navegador Web (como Firefox
o Explorer) o en algunos modelos a través de una aplicación
específica (SDM).
Conexión al router por consola

Una posibilidad para acceder al router consiste en conec-
tarse directamente a través del puerto de consola con un orde-
nador. Si hemos perdido la gestión de un router o lo estamos
configurando por primera vez esta será la opción usada.
Necesitaremos para conectarnos al router un cable especial
denominado cable rollover. Como ya vimos en el apartado an-
terior, este cable lleva una distribución de conectores (pines)
distinta a la de los cables RJ-45 directos o cruzados, siendo la
asignación de pines de extremo a extremo la siguiente: 1 a 8, 2
a 7, 3 a 6, 4 a 5, 5 a 4, 6 a 3, 7 a 2 y 8 a 1. También necesitaremos
un software de emulación de terminal, como Hyperterminal,
SecureCRT o Putty.
Nota: El programa Hyperterminal forma parte de todas las

versiones de Windows. Puede obtener una copia de evaluación
de SecureCRT en la dirección www.vandyke.com así
como descargar Putty de la página oficial http://www.
chiark.greenend.org.uk/~sgtatham/putty/
93
Con un extremo del cable conectado a un puerto serie
(COM) del ordenador y el otro conectado al puerto de con-
sola del router (CONSOLE), se arranca el Hyperterminal y
se configura para usar el puerto COM adecuado. Fijamos los
parámetros de velocidad de la conexión a "9600/8-N-1" (9600
de velocidad, 8 bits de datos, sin bit de paridad y un stop bit)
tal como se muestra en la figura 3.6.
Nota: La tendencia en la mayoría de los portátiles modernos

es la de no incluir el puerto serie para ahorrar espacio y costes.
Si éste es nuestro caso, necesitaremos un adaptador USB
a RS-232. Más detalles en http://wanlinksniper.blogspot.
com/2008/01/96008-n-1-n-conexin-cisco-por-consola.html
Figura 3.6. Hyperteminal: Configuración del puerto serie.
Los 9600 bits por segundo de velocidad incluyen bits de

control (stop bits, paridad, etc...) con lo que la tasa efectiva
de transmisión es menor. Para una codificación 8-N-1, sólo el
80% de los bits están disponibles para datos (por cada 8 bits
de datos, se envían 10 sobre la línea serie: un start bit, los ocho
bits de datos y un stop bit).
Una vez que tenemos el programa terminal configurado a
9600/8-N-1, se enciende el router y si es preciso se le da a la
tecla Intro un par de veces. El router irá mostrando una serie
de mensajes relativos al proceso de arranque hasta llegar final-
mente a ofrecer la línea de comandos del router (prompt).
94
System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
Copyright (c) 1999 by cisco Systems, Inc.
C1600 platform with 8192 Kbytes of main memory

program load complete, entry point: 0x4020060, size: 0x165eac
%SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader.
program load complete, entry point: 0x2005000, size: 0x21f936
Self decompressing the image : #################################################
######################### [OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is

subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.

170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software

IOS (tm) 1600 Software (C1600-Y-M), Version 12.0(12), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Mon 10-Jul-00 19:59 by htseng
Image text-base: 0x02005000, data-base: 0x0245E484
cisco 1601 (68360) processor (revision C) with 6144K/2048K bytes of memory.

Processor board ID 23099315, with hardware revision 00000003
Bridging software.
X.25 software, Version 3.0.0.
1 Ethernet/IEEE 802.3 interface(s)
1 Serial(sync/async) network interface(s)
System/IO memory with parity disabled
8192K bytes of DRAM onboard
System running from RAM
7K bytes of non-volatile configuration memory.
4096K bytes of processor board PCMCIA flash (Read/Write)
Router>
Conexión al router vía Telnet

También podemos conectarnos al router y administrarlo
mediante Telnet. Telnet es un protocolo que permite conectar
una máquina (cliente) con otra máquina (servidor). En vez de
usar el puerto serie y un enlace por cable como cuando nos
conectamos al puerto de consola, telnet permite comunicar
máquinas a través de redes de datos. Los terminales creados
por el servidor telnet del router a los cuales nos conectamos son
virtuales. Un router Cisco convencional permite la conexión
simultánea de 5 usuarios vía telnet. Los terminales virtuales
creados son vty0, vty 1, vty 2, vty 3 y vty4.
Nota: La aplicación telnet viene incluida en UNIX y sus

variantes. Windows dispone de esta aplicación, accesible me-
diante la secuencia Inicio>Ejecutar>CMD o directamente
95
Inicio>Ejecutar>telnet y en el cuadro de texto que aparece
escribiendo "telnet" seguida por la dirección IP del equipo
y opcionalmente el puerto TCP (telnet usa por defecto el puerto
TCP 23). Puede consultar los detalles de la implementación de
telnet en los RFC 854 y 855 disponibles en ftp://ftp.rfc-
editor.org/in-notes/rfc854.txt y ftp://ftp.
rfc-editor.org/in-notes/rfc855.txt. Con un
"telnet 193.202.115.241" podemos ver una curiosa
versión de la Guerra de las Galaxias en versión ASCII Art.
Este router presenta una pantalla de bienvenida (banner) y

a continuación pide un nombre de usuario y clave de acceso.
Con esto se accede al router, que en este caso se llama POE. El
router le está presentando el CLI o intérprete de comandos. En
este momento espera que le introduzca su primer comando.
telnet 172.17.201.54
Trying 172.17.201.54...
Connected to 172.17.201.54.
Escape character is '^]'.
Bienvenido a Poe.
O
O
o \''/
/o '))
/_/\_ss))
|_ss))/|
|__ss))_|
|__sss))_|
|___ss))\|
|_ss))
)_s))
('( /_s))
(_\/_s))
(\/))
User Access Verification
Username: antonio
Password: ******
POE>
Conexión al router con un navegador

Puede controlar el router con su navegador de Internet fa-
vorito, apuntando con el navegador a la IP del router tal como
se muestra en la figura 3.5. Para acceder al router por medio
96
de un navegador necesitamos que esté preparado con la orden
de configuración global "ip http server". Opcionalmente
se puede especificar con la orden "ip http port #" un puerto
TCP diferente al usado por el protocolo http de forma estándar
(TCP 80).
Sagan(config)# configure terminal
Sagan(config)# ip http server
Sagan(config)# ip http port 80
Sagan(config)# exit
Sagan#
Figura 3.7. Conexión al router con un navegador.
Conexión al router vía SDM

El SDM (Security Device Manager) es una herramienta web
que permite configurar y administrar el router de forma gráfica.
SMD simplifica la gestión de los routers Cisco, proporcionando
asistentes que ayudan a realizar configuraciones, aumentar la
seguridad del sistema, facilitar la resolución de problemas o
comprobar el estado del router.
SDM sólo puede gestionar un dispositivo a la vez. Si el
router no tiene instalado SDM de serie lo podemos preparar
para que SDM pueda acceder:
Router(config)# username usuario privilege 15 secret cisco
Router(config)# ip http authentication local
Router(config)# ip http secure-server
97
Router(config)# line console 0
Router(config-line)# login local
Router(config)# line vty 0 15
Router(config-line)# privilege level 15
Router(config-line)# transport input telnet ssh
Router(config)# ip domain name wanlinksniper.net
Router(config)# crypto key generate rsa general-keys
Choose the size of the key modulus in the range of 360 to 2048
for your General Purpose Keys. Choosing a key modulus greater
than 512 may take a few minutes.
How many bits in the modulus [512]:
% Generating 512 bit RSA keys ...[OK]
En el caso de querer ejecutar el SDM desde el router los

ficheros necesarios son:
Router#show flash:
System flash directory:
File Length Name/status
1 9283820 c2600-ipbase-mz.123-6f.bin
2 1007616 common.tar
3 812544 es.tar
4 1038 home.shtml
5 113152 home.tar
6 1652 sdmconfig-26xx.cfg
7 4049920 sdm.tar
Los ficheros 2 al 7 son necesarios para SDM. 1 y 6 variarán

en función de la versión del sistema operativo (IOS) y del fi-
chero de configuración del router.
Para acceder al SDM navegaremos hasta la dirección
http://10.10.10.1 (la IP por defecto en los que traen el
SDM de fábrica). Inicialmente accedemos a SDM Express (un
asistente que permite configurar el router de forma similar
al "setup" de la línea de comandos que vemos en el siguiente
apartado). Allí indicaremos parámetros generales tales como
el nombre del equipo, usuarios y contraseñas, interfaces LAN
y WAN del router, DNS, NTP, DHCP. Una vez completada la
configuración inicial las veces siguientes accederemos direc-
tamente al SDM.
SDM ofrece dos modos: configuración y monitorización
(Figura 3.8). Cada modo va asociado a un panel con sus asis-
tentes específicos. Con el botón "refrescar" se sincroniza la
configuración activa del router con el SDM, y con el botón
"salvar" almacenaremos la configuración activa en la NVRAM
del router.
Entre los asistentes de configuración tenemos asistentes
para configuración de interfaces y conexiones (LAN, DHCP,
PPP, Frame Relay y HDLC), Firewall y ACL, VPNs de distintos
98
tipos, Auditoría de seguridad, Enrutamiento (RIP, OSPF e
EIGRP), NAT, Prevención de intrusos y Calidad de servicio.
Los asistentes de monitorización permiten ver una descrip-
ción general del estado del router así como el estado específico
de las interfaces, firewall, VPNs, Calidad de Servicio (QoS) y
Control de Acceso (NAC).
Los asistentes ofrecen la opción de ver las órdenes que
se mandarán al router antes de que se ejecuten realmente en
el mismo.
Figura 3.8. SDM
Modo Set-Up
Al arrancar el router por primera vez disponemos de la
opción de entrar en el modo "Initial Configuration Dialog", más
conocido como modo setup. El siguiente ejemplo muestra una
secuencia de arranque completa en la que se ha accedido al
modo setup.
Cuando nos pregunta si queremos acceder este modo
"Would you like to enter the initial configuration dialog?", si con-
testamos "yes" accedemos al modo setup:
99
System Bootstrap, Version 12.0(3)T, RELEASE SOFTWARE (fc1)
program load complete, entry point: 0x4020060, size: 0x165eac
%SYS-6-BOOT_MESSAGES: Messages above this line are from the boot loader.
program load complete, entry point: 0x2005000, size: 0x21f936
Self decompressing the image : ##############################################
###
######################### [OK]

cisco Systems, Inc.


IOS (tm) 1600 Software (C1600-Y-M), Version 12.0(12), RELEASE SOFTWARE (fc1)
Compiled Mon 10-Jul-00 19:59 by htseng
Image text-base: 0x02005000, data-base: 0x0245E484
cisco 1601 (68360) processor (revision C) with 6144K/2048K bytes of memory.

Processor board ID 23099315, with hardware revision 00000003
Bridging software.
System/IO memory with parity disabled
8192K bytes of DRAM onboard
System running from RAM
4096K bytes of processor board PCMCIA flash (Read/Write)
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]: yes
Setup a continuación nos preguntará el nombre que le

queremos dar al router "Enter host name", la contraseña para
cambiar a modo privilegiado "Enter enable secret" y "Enter enable
password", la password de terminal "Enter virtual terminal pas-
sword", la comunidad SNMP "Community string [public]".
At any point you may enter a question mark '?' for help.
Use Control-C to abort configuration dialog at any prompt.
Default settings are in square brackets '[]'.
Basic management setup configures only enough connectivity

for management of the system, extended setup will ask you
to configure each interface on the system
100
Would you like to enter basic management setup? [yes/no]: yes
Configuring global parameters:
Enter host name [Router]: mirouter
The enable secret is a password used to protect access to

privileged EXEC and configuration modes. This password, after
entered, becomes encrypted in the configuration.
Enter enable secret: password1
The enable password is used when you do not specify an

enable secret password, with some older software versions, and
some boot images.
Enter enable password: password2
The virtual terminal password is used to protect

access to the router over a network interface.
Enter virtual terminal password: password3
Configure SNMP Network Management? [yes]: yes
Community string [public]: abc12345
A continuación se nos muestran las interfaces disponibles

y una vez seleccionada la que queremos configurar le daremos
una dirección IP "IP address for this interface" y su correspon-
diente máscara de red "Subnet mask for this interface".
Current interface summary
Any interface listed with OK? value "NO" does not have a valid configuration

Ethernet0 unassigned NO unset up down
Serial0 unassigned NO unset down down
Enter interface name used to connect to the management network from the above
interface summary: Ethernet0
Configuring interface Ethernet0:
Configure IP on this interface? [yes]: yes
IP address for this interface: 192.168.1.1
Subnet mask for this interface [255.255.255.0] : 255.255.255.240
Class C network is 202.144.158.0, 28 subnet bits; mask is /28
Setup termina mostrando la configuración obtenida a través

de este proceso.
The following configuration command script was created:
hostname mirouter
enable secret 5 $1$Tk3z$5NlqsaYCojkq4cNoXl6sG1
enable password password2
line vty 0 4
password password3
snmp-server community abc12345
!
no ip routing
!
interface Ethernet0
101
no shutdown
ip address 192.168.1.1 255.255.255.240
!
interface Serial0
shutdown
no ip address
!
end
Llegados a este punto Setup nos ofrece salir a la línea de

comandos sin grabar [0], volver a empezar con el aistente [1]
o guardar la configuración obtenida [2].
[0] Go to the IOS command prompt without saving this config.
[1] Return back to the setup without saving this config.
[2] Save this configuration to nvram and exit.
Enter your selection [2]: 2

Building configuration...
Use the enabled mode 'configure' command to modify this
configuration.
Press RETURN to get started!
mirouter>
3.2.4. La línea de comandos ó CLI

La interfaz IOS está organizada en torno a la idea modos.
El administrador del router se mueve a través de distintos
modos muientras configura el router, y el modo determina
los comandos disponibles. La figura 3.9 muestra los distintos
modos y la forma de movernos entre ellos. En los siguientes
apartados explicamos este diagrama.
En cualquier momento tecleando un interrogante ("?") el
router mostrará las órdenes disponibles.
Router>?
Modo usuario y modo privilegiado

Al conectar al router por primera vez se introduce la contra-
seña y se accede al modo EXEC o modo no privilegiado. Este
modo es identificado por el ">" de la línea de órdenes. En este
punto podemos empezar a trabajar con el router con órdenes
los comandos show para obtener información básica acerca
del sistema. Por ejemplo con "show version" podemos ver
que versión de IOS tenemos en el router, el tiempo que lleva
encendido, la causa por la que se reinició la última vez... Otros
show que podemos probar son los siguientes…
102
Router#show interfaces
Router#show ip protocols
Router#show ip route
Router#show ip arp
Figura 3.9. Modos del router.
Con estas órdenes podremos ver las interfaces disponi-

bles, los protocolos de enrutamiento en ejecución, la tabla de
rutas y la tabla ARP del router respectivamente. En general
con "?" podemos ver todos los comandos a los que podemos
tener acceso.
Router>?
Para hacer cosas más interesantes debemos pasar al modo

privilegiado. Para ello usaremos la orden "enable". Lo más
normal es que este modo esté protegido por contraseña. Cuando
pasamos del modo no privilegiado el prompt cambia a "#" para
identificar el nuevo modo en el que nos encontramos:
Router>enable
Router#
Si en este modo privilegiado usamos de nuevo la ayuda

veremos que tenemos muchísimos más comandos a nuestra
disposición.
Router#?
103
Con "disable" salimos del modo privilegiado y volvemos
al modo no privilegiado:
Router#disable
Router>
Una de las características del CLI es que no hace falta intro-

ducir los comandos completos. Tan pronto como hemos intro-
ducido la parte del comando que lo identifica sin ambigüedad
podemos pasárselo al intérprete.
Router>ena
Router#dis
Router>
Un par de anotaciones acerca del uso de la ayuda. Para

ver todos los comandos que empiezan por "s" tecleamos
"s?" (junto).
POE#s?
*s=show sdlc send setup show
slip start-chat systat
El asterisco nos indica que la "s" sola equivale al comando

show, si dejamos un espacio entre la "s" y el "?" nos mostrará
las opciones de la orden show (equivale a teclear "sh ?", "sho
?" o "show ?".
POE#s ?
access-expression List access expression
access-lists List access lists
accounting Accounting data for active sessions
aliases Display alias commands
arp ARP table
[Parte de la salida omitida]
whoami Info on current tty line
x25 X.25 information
De hecho, la salida es tan grande que ocupa más de una

pantalla. En un momento dado aparecerá la línea "--More--".
printers Show LPD printer information
privilege Show current privilege level
processes Active process statistics
protocols Active network routing protocols
--More--
En este punto podemos darle al espacio para que nos

muestre la siguiente pantalla, o darle a la tecla "Q" y parar la
salida.
104
Modo configuración global
Con la orden "configure terminal" accedemos al modo
de configuración global del router. El saludo del router cambia
(config) para indicar que podemos empezar a insertar co-
mandos de configuración.
Router#configure terminal
Router(config)#
En este modo global de configuración podemos emitir

órdenes de confuguración generales. Por ejemplo podemos
cambiar el nombre al router:
Router(config)# hostname POE
POE(config)#
Nada más introducir la orden el cambio toma efecto, re-

flejándose inmediatamente en este caso en un cambio en el
"prompt" del router. Otras órdenes típicas de configuración
global son las que permiten configurar una contraseña para
el modo privilegiado así como nombrar la dirección del ser-
vidor DNS
POE(config)# ip name-server 10.1.1.1
POE(config)# enable secret abc123
POE(config)# Control-Z
POE#
Al introducir "Control-Z" (o al teclear "exit") volvemos al

modo privilegiado.
Modo configuración específico

Para configurar una interfaz debemos seleccionarla escri-
biendo su nombre
POE(config)# interface ethernet0
POE(config.if)#
La indicación (config.if) indica que estamos en modo con-

figuración dentro de un interfaz.
POE(config.if)# no shutdown
Con las órdenes "no shutdown" y "shutdown" habilitamos

y deshabilitamos la interfaz seleccionada. La primera vez
que accedemos a configurar un router debemos acceder en
modo configuración a las interfaces y teclear el comando "no
shutdown". Inhabilitar (o coloquialmente "tirar") una interfaz
105
usando el comando "shutdown" cierra todas las comunica-
ciones por esa interfaz.
Nota: Poner en shutdown el interfaz por el que hemos acce-

dido al router es la forma más fácil de perder la gestión de un
router. Si alguna vez le pasa, una solución consiste en apagar
y encender el router para que recupere la configuración con
la que le arrancó la última vez. Todos los cambios que haya
realizado por medio los habrá perdido. Si usted está en Madrid
y el router bloqueado está en Sevilla, y además son las 3 de la
madrugada, considérelo como un rito de iniciación.
Hay un aspecto importante de la orden anterior: el uso de

"no" delante de un comando. Si configuramos un parámetro
del router podemos desconfigurarlo volviendo a escribir la
orden antecediéndola con la instrucción "no". Un ejemplo: si
tenemos configurado RIP (que veremos en el capítulo 5) como
protocolo de enrutamiento,
POE (config)# router rip
POE(config.router)# network 10.0.0.0
POE(config.router)# network 192.168.16.0
para quitar la red 10.0.0.0 de RIP

POE(config)# router rip
POE(config.router)# no network 10.0.0. 0
Es diferente a
POE (config)# no router rip
Ya que en este último caso habremos eliminado de la confi-

guración las tres líneas anteriores (tanto la que hemos negado
como las que dependen de dicho servicio).
Un par de trucos
Como indicamos antes podemos usar abreviaturas donde
no exista ambigüedad con otros comandos. Así, es típico
usar "sh" y "no sh" en vez de "shutdown" y "no shutdown".
Hemos visto en el apartado anterior el uso de abreviaturas de
comandos. Podemos usar las abreviaturas a partir del punto en
el que no exista ambigüedad con otras órdenes. También po-
demos completarlos mediante el uso de la tecla del tabulador.
En el ejemplo siguiente indicamos mediante "Tab" la pulsación
del tabulador y con el símbolo de subrayado la posición donde
queda el cursor a continuación:
106
POE#sh "Tab"
POE#show_
POE#show ip int"Tab"
POE#show ip interfaces_
POE#show ip interfaces brie"Tab"
POE#show ip interfaces brief_
Resulta muy útil el uso de las teclas de cursor. El router

guarda los últimos comandos y permite recuperarlos con las
teclas flecha arriba, flecha abajo, flecha derecha y flecha iz-
quierda. Esto es muy útil cuando hemos cometido un error:
POE#show closk
^
% Invalid input detected at '^' marker.
POE# "Flecha arriba" "Supr" "Supr"ck
POE#show clock
*12:36:50.403 MET Sun Mar 21 1993
Al intentar ver la hora del sistema, hemos confundido una

letra. El sistema nos indica mediante el indicador "^" la posi-
ción del error. Observe que el router del ejemplo no está en
hora, así que las entradas del LOG habrá que compararlas con
la hora que marca el sistema.
Otros atajos útiles son las combinaciones Control-A, que
sitúa el cursor al inicio de la línea, Control-E, que lo coloca al
final, y Control-X, que borra todos los caracteres desde el cursor
hasta el inicio. Lo mejor para familiarizarse con estas combina-
ciones de teclas es practicar. Por ejemplo para quitar órdenes
de la configuración las negamos. Una forma rápida de quitar
una orden que acabamos de introducir es invocarla de nuevo
con la flecha arriba, usar la combinación Control-A para ir al
comienzo de la instrucción y añadir un "no" delante del todo
(indico con el símbolo subrayado la posición del cursor):
POE(config)#router eigrp 100
POE(config.router)#autosummary
POE(config.router)#"Flecha arriba"
POE(config.router)#autosummary_ "Control-A"
POE(config.router)#_autosummary
POE(config.router)#no autosummary
Vamos acabando: mediante la redirección (pipe, "|") podemos

canalizar cualquier comando a través de una "tubería", y filtrar
la salida con las opciones "begin", "include" y "exclude":
Router#sh running-config | ?
begin Begin with the line that matches
exclude Exclude lines that match
include Include lines that match
107
Con "begin" nos muestra la parte de la orden a partir de la
primera línea que contiene la expresión buscada:
Router#sh running-config | begin route
ip route 0.0.0.0 0.0.0.0 192.168.1.2
!
logging trap debugging
logging 10.2.2.2
!
line con 0
transport input none
stopbits 1
line vty 0 4
password 7 14141B180F0B
login
!
end
La salida, filtrada con "include", nos mostrará únicamente

las líneas que contengan la expresión:
Router#sh running-config | include interface
interface Loopback1
interface Ethernet0
interface BRI0
Finalmente, con "exclude" obtenemos el efecto contrario:

Router#show ip int brie
BRI0 unassigned YES NVRAM administratively down down
BRI0:1 unassigned YES unset administratively down down
BRI0:2 unassigned YES unset administratively down down
Ethernet0 192.168.1.1 YES NVRAM administratively down down
Loopback1 9.0.0.1 YES NVRAM up up
Router#show ip int brie | exclude admin
3.2.5. Configuraciones Startup vs. running

El router cargará al arrancar la configuración almacenada en
la memoria NVRAM en la memoria RAM. Los cambios que ha-
gamos en la configuración tendrán efecto inmediato en el com-
portamiento del sistema, pero los estaremos haciendo sobre la
copia que se ejecuta en la memoria RAM. Si no grabamos los
cambios, cuando se apague el router se perderán. Veamos la
configuración en ejecución mediante "show running-config":
POE#show running-config
Current configuration:
!
108
version 12.0
!
hostname POE
!
enable last-resort password
enable password cisco
!
interface Ethernet0
ip address 192.168.8.1 255.255.255.0
!
interface Serial0
description Conexion con Sevilla
ip address 172.27.201.5 255.255.0.0
!
router eigrp 1
network 172.27.0.0
network 192.168.8.0
!
banner motd *
Bienvenido a Poe.
O
O
o \''/
/o '))
/_/\_ss))
|_ss))/|
|__ss))_|
|__sss))_|
|___ss))\|
|_ss))
)_s))
('( /_s))
(_\/_s))
(\/))
*
!
line con 0
password cisco
login
!
line vty 0 4
password cisco
login
!
end
Para ver la configuración de arranque del router usaremos

la orden "show startup-config". Sabremos que es la configu-
ración almacenada por la línea "Using xx out of yy bytes"
109
en lugar de "Building configuration... Current con-
figuration":
POE#sh startup-config
Using 4853 out of 32762 bytes
!
! Last configuration change at 12:15:43 DST Sun Aug 25 2002
! NVRAM config last updated at 13:46:40 DST Sun Aug 25 2002
!
version 12.0
service timestamps debug datetime localtime show-timezone
[parte de la salida omitida]
Nota: A medida que van saliendo nuevas versiones de IOS

aparecen nuevas formas de invocar órdenes que ya existían.
En muchos casos se mantienen ambas formas, aunque es reco-
mendable aprender las nuevas sintaxis. Por ejemplo, puede que
observe que los técnicos que llevan algún tiempo manejando
Cisco (en concreto versiones de IOS anteriores a la 10.3) usan
el comando "write terminal". Este comando es equivalente
a "show running-config" Pasa lo mismo con "show
startup-config", antes era "show configuration".
Otros comandos que han variado son los comandos "copy":
la orden "copy running-config startup-config"
antes era "write" (ó "wr"). Las órdenes han evolucionado
hacia una sintaxis homogénea (IFS o sistema de archivos IOS).
Algunos comandos incluso no están documentados oficialmente,
es el caso de las órdenes "who" y "where", equivalentes a las
órdenes "show users" y "show sessions".
Para grabar la configuración en ejecución de forma que la

próxima vez que encendamos el router la utilice, use la orden
"copy running-config startup-config" (copy origen
destino):
POE#copy running-config startup—config
[OK]
POE#
Un truco: podemos mostrar parte de la configuración del

router indicando la parte de la misma a continuación del "show
running", así:
Router#show running-config interface ethernet 0
Current configuration : 75 bytes
!
110
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
shutdown
end
Configuración inicial básica

Recapitulando, una configuración básica de un router debe
cubrir una serie de aspectos: darle nombre al router ("host-
name"), poner contraseñas ("enable secret", "password"),
habilitar accesos ("login"), dar (al menos) una ruta por defecto
("ip route"), configurar las interfaces y habilitarlas ("no shut-
down"), poner un mensaje de entrada ("banner motd")…
Para verificar el estado de la configuración que está en fun-
cionamiento usaremos "show running-config"
POE#show running-config
hostname POE
!
enable secret clavesecreta
!
interface Ethernet0
description Red Local de Madrid
ip address 192.168.8.1 255.255.255.0
!
interface Serial0
description Conexion con Tenerife
ip address 172.27.201.1 255.255.255.252
!
ip route 0.0.0.0 0.0.0.0 172.27.201.2
!
banner motd *
Prohibido el acceso no autorizado
*
!
line con 0
password abc123
login
!
line vty 0 4
password abc123
login
!
end
Una vez que todo esté en orden grabaremos con "copy

running-config startup-config". Algunas de estas
órdenes ya las hemos visto, el resto las examinaremos a lo
largo del libro.
111
POE#copy running-config startup—config
[OK]
POE#
3.3 Procedimiento de recuperación

de contraseñas
Es inevitable. Antes o después tendremos que acceder a un
router de cuya contraseña nadie se acuerda.
Nota: El siguiente ejemplo de recuperación de contraseñas

es válido sobre un Cisco 2611 y un Cisco 801, pero la esencia
del proceso es la misma para la mayoría. Aún así, es muy
conveniente buscar en Google "Cisco xxxxx password reco-
very" dónde xxxxx es el modelo a recuperar, e inmediatamente
daremos con la página de Cisco en la que se menciona la
recuperación de contraseñas de ese modelo concreto.
En primer lugar nos conectamos con un software de emu-

lación de terminal como Hyperterminal o Putty al puerto de
consola del router con los parámetros habituales:
• Velocidad 9600 (baud rate)
• Sin paridad (No parity)
• Ocho bits de datos (8 data bits)
• Un bit de parada (1 stop bit)
• Sin control de flujo (No flow control)
Apagamos y encendemos el router y paramos la secuencia
de arranque con "Control+Break" en los sesenta segundos
transcurridos desde el encendido.
Nota: "Control+Break" suele funcionar, pero en caso nece-

sario podemos buscar el documento de Cisco "Standard Break
Key Sequence Combinations During Password Recovery"
donde aparecen muchas combinaciones de parada en función
el sistema y software utilizados.
Accedemos al modo ROMMON y cambiamos el valor del

registro de configuración con la orden "confreg 0x2142" de
forma que el router cargue desde la flash, saltandose la confi-
guración de arranque donde las passwords se almacenan. Con
un "reset" reiniciamos el sistema
112
*** System received an abort due to Break Key ***
signal= 0x3, code= 0x500, context= 0x813ac158
PC = 0x802d0b60, Vector = 0x500, SP = 0x80006030
rommon 1 > confreg 0x2142
You must reset or power cycle for new config to take effect
rommon 2 > reset
En un Cisco 801, en cambio, al "romper" la secuencia de

arranque entramos en modo BOOT.
En estos modelos usaremos "set ios-conf=" y "boot"
para hacer el trabajo:
TinyROM version 1.4(1)
19:37 11/07/00
All rights reserved.
POST ............ OK. 4MB DRAM, 8MB Flash.
boot# show
TinyROM version 1.4(1)
19:37 11/07/00
All rights reserved.
serial-no: JAD05270QP3
Type: C801
DRAM: 4MB
Flash: 8MB
set baud =9600

set data-bits =8
set parity =none
set stop-bits =1
set console-flags =0
set mac-address =00B0.C28D.0A78
set unit-ip =0.0.0.0
set serv-ip =0.0.0.0
set netmask =0.0.0.0
set gate-ip =0.0.0.0
set pkt-timeout =4
set tftp-timeout =16
set boot-action =flash
set file-name ="c800-y6-mw_121-4.bin"
set watchdog =off
set prompt ="boot"
set ios-conf =0x2102
boot#
boot#set ios-conf=0x2142
boot#boot
En cualquier caso al reiniciar el router éste ignora la confi-

guración almacenada. Iremos contestando "no" o directamente
113
"Control-C" para saltarnos el proceso setup de configuración
inicial.
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
TAC:Home:SW:IOS:Specials for info
program load complete, entry point: 0x80008000, size: 0x6fdb4c
Self decompressing the image : ###############################

##############################################################
##############################################################
##############################################################
############################### [OK]

cisco Systems, Inc.


IOS (tm) C2600 Software (C2600-IS-M), Version 12.0(7)T, RELEASE
SOFTWARE (fc2)
Compiled Tue 07-Dec-99 02:21 by phanguye
Image text-base: 0x80008088, data-base: 0x80C524F8
cisco 2611 (MPC860) processor (revision 0x202) with 26624K/6144K bytes

of memory.
Processor board ID JAB031202NK (3878188963)
M860 processor: part number 0, mask 49
Bridging software.
Basic Rate ISDN software, Version 1.1.
1 ISDN Basic Rate interface(s)
8192K bytes of processor board System flash partition 1 (Read/Write)
Would you like to enter the initial configuration dialog? [yes/no]: no
00:00:19: %LINK-3-UPDOWN: Interface BRI0/0, changed state to up

00:00:19: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
114
00:00:19: %LINK-3-UPDOWN: Interface Serial0/0, changed state to down
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0,
changed state to down
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0,
changed state to up
changed state to up
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0,
00:00:50: %SYS-5-RESTART: System restarted --
SOFTWARE (fc2)
00:00:50: %LINK-5-CHANGED: Interface BRI0/0,
changed state to administratively down
00:00:52: %LINK-5-CHANGED: Interface Ethernet0/0,
00:00:52: %LINK-5-CHANGED: Interface Serial0/0,
Router>
Con "enable" nos hacemos usuarios privilegiados del

router sin necesidad de contraseña.
Router>enable
Router#
Ya está… casi. Ahora viene el momento más delicado.

Con la orden "copy startup-config running-config"
copiamos la configuración de la RAM no volátil (NVRAM) a
la memoria.
Nota: *NO* lo haga al revés. Si copiamos la running-config

sobre la startup-config borraremos la configuración de
arranque del router, algo que casi con total seguridad no es
lo que queremos hacer en este momento.
Router#copy startup-config running-config
Destination filename [running-config]?
1324 bytes copied in 2.35 secs (662 bytes/sec)
00:01:24: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0:1,
115
Llegados a este punto con "show running-config" po-
demos ver la configuración inicial del router. Las interfaces
aparecerán todas en "shutdown"y las contraseñas pueden
estar en texto claro o encriptadas. En todo caso con "con-
figure terminal" accedemos al modo de configuración y
con "enable secret <password>" cambiamos la contraseña del
modo privilegiado:
Router(config)# enable secret cisco
Router(config)# ^Z
Ahora sólo queda darle un "no shutdown" a las inter-

faces
Router#show ip interface brief

Ethernet0/0 10.200.40.37 YES TFTP administratively down down
Serial0/0 unassigned YES TFTP administratively down down
BRI0/0 193.251.121.157 YES unset administratively down down
BRI0/0:1 unassigned YES unset administratively down down
Ethernet0/1 unassigned YES TFTP administratively down down
Loopback0 193.251.121.157 YES TFTP up up
Router(config)# interface Ethernet0/0
Router(config-if)# no shutdown
changed state to up
Router(config-if)# interface BRI0/0
00:02:26: %LINK-3-UPDOWN: Interface BRI0/0:1, changed state to down
00:02:115964116991: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/0,
TEI 68 changed to up
Router(config-if)# ^Z
Guardamos el trabajo realizado con "write memory" o

"copy running-config startup-config"
Router#copy running-config startup-config
Destination filename [startup-config]?
[OK]
Queda un último detalle. Necesitamos volver a dejar el re-

gistro de configuración como estaba originalmente "0x2102"
para que el router al reiniciarse cargue la configuración desde
la NVRAM.
116
Router#show version
SOFTWARE (fc2)
ROM: System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
Router uptime is 3 minutes

System returned to ROM by abort at PC 0x802D0B60
System image file is "flash:c2600-is-mz.120-7.T"
cisco 2611 (MPC860) processor (revision 0x202)

with 26624K/6144K bytes of memory.
Bridging software.
Configuration register is 0x2142
Router(config)# config-register 0x2102
Router(config)# ^Z
Router#show version
SOFTWARE (fc2)


Bridging software.

117
Configuration register is 0x2142 (will be 0x2102 at next reload)
Router#
Aunque puede parecer elaborado, los pasos anteriores

pueden llevarse a cabo en tres minutos, de lo que se deduce
que si alguien tiene acceso físico a sus routers, tiene muy fácil
hacerse administrador de los mismos, y desde ahí cambiar
listas de acceso, desviar tráfico o hacer cualquier cosa que le
parezca conveniente. Por eso es necesario proteger físicamente
sus routers y demás dispositivos de red. Hablaremos de la se-
guridad de los routers en el capítulo 6 del libro. Antes veremos
cómo se configuran las principales interfaces de los routers y
la forma de establecer conectividad entre redes.
118
4
Estableciendo conectividad
En el presente capítulo vamos a ver cómo conectar routers

entre sí, configurándolos para que puedan mandar y recibir
tráfico. Aprenderemos a configurar el protocolo TCP/IP en las
interfaces habituales de los routers, las principales características
de las interfaces y de los protocolos de interconexión así como
los comandos básicos que permitirán comprobar el correcto fun-
cionamiento de las comunicaciones que hemos establecido. Los
router Cisco ofrecen muchos tipos de interfaces. Esta variedad
de medios impide hablar de todos en una guía de bolsillo como
ésta, de forma que nos centraremos en las interfaces y protocolos
más frecuentes. Una primera clasificación de las interfaces puede
hacerse en función del tipo de red que conectan: LAN para redes
de área local y WAN para conexión con redes extensas.
Tabla 4.1. Interfaces según el tipo de red.

Tipo de red Interfaces disponibles
LAN Ethernet (10/100/Gigabit,10Giga)
Integrated Switching (4/8/16/24/48 puertos)
PoE (Power over Ethernet)
ATM
Token Ring
Cable DOCSIS2.0
Wireless
WAN ADSLoPOTS
Serie (Punto a Punto, Frame Relay)
HSSI (Interfaz Serie de alta velocidad)
ISDN BRI/PRI S/T/U (RDSI)
PRI (RDSI Primario)
Analógico (POTS)
ATM OC-3 , OC-12, T1/E1
119
Nota: A la hora de determinar las interfaces y el resto de
características disponibles en un router Cisco concreto po-
demos consultar la "Guía de Referencia Rápida de Productos
de Cisco" ("Cisco Product Quick Reference Guide") en la
dirección http://www.cisco.com/go/guide. Se trata
de una referencia útil y compacta que incluye breves descrip-
ciones de los routers, switches, firewalls y en general de todos
los productos Cisco, junto con sus principales características,
especificaciones técnicas abreviadas y los part numbers nece-
sarios para hacer un pedido. Para obtener la última versión de
la guía en formato electrónico basta con registrarse en la pá-
gina https://www.nationsprint.com/clients/
cpqrg/. Tras un breve proceso de registro se recibe un correo
electrónico con las instrucciones para proceder a la descarga
de la guía en formato PDF. La guía correspondiente a otoño
2008 ocupa algo más de 3MB. También se pueden obtener las
guías de años anteriores, algo muy útil a la hora de verificar
las características de equipos descontinuados.
4.1. Aspectos generales de la

configuración de interfaces
Hay una serie de consideraciones generales a tener en
cuenta al configurar interfaces, sean del tipo que sean. Debemos
tener privilegios de administración ("enable"), poner el sis-
tema en modo de configuración ("configure terminal"
o, de forma abreviada, "conf t") y seleccionar la interfaz
concreta mediante el comando "interface" especificando
el tipo e identificándolo mediante un número: "interface
ethernet 0".
La primera vez que se configura una interfaz hay que ha-
bilitarla para su uso mediante la orden "no shutdown", y ya
puestos podemos aprovechar para añadir una descripción de
la función del enlace mediante el comando "description".
Nota: El número de interfaz puede estar determinado por su

ubicación física en los routers modulares o venir asignado
de fábrica en los routers de chasis fijo. Así, en los casos más
sencillos basta con especificar el puerto para identificar la
interfaz: "serial 1", "ethernet 0". En los routers modulares se
debe especificar la ranura y el puerto: "serial 1/0". También
120
existen routers que para identificar las interfaces usan 3
parámetros: ranura, adaptador y puerto: "serial 1/1/0". La
numeración es necesaria dado que un router puede tener
varias interfaces del mismo tipo.
Si tiene acceso físico al router, un vistazo a la parte trasera

del mismo le aclarará el tipo de conectores y/o módulos que
posee. En cualquier caso la mejor opción a la hora de verificar las
interfaces disponibles es mediante la orden "show version":
Router#show version
IOS (tm) C2600 Software (C2600-IK9O3S-M), Version 12.2(12a),
RELEASE SOFTWARE (fc1)
Compiled Tue 24-Sep-02 02:05 by pwade
Image text-base: 0x8000808C, data-base: 0x8127FF40
Router uptime is 22 hours, 30 minutes

System returned to ROM by reload
System restarted at 13:16:33 EST Thu Feb 12 2006
System image file is "flash:c2600-ik9o3s-mz.122-12a.bin"
cisco 2621 (MPC860) processor (revision 0x102) with 45056K/4096K

bytes of memory.
Bridging software.
2 FastEthernet/IEEE 802.3 interface(s)
2 Serial network interface(s)
32K bytes of nonvolatile configuration memory.
16384K bytes of processor board System flash (Read/Write)
Configuration register is 0x2102
En la salida anterior vemos como este Cisco 2621 dispone

de dos interfaces FastEthernet (2 FastEthernet/IEEE 802.3 in-
terfaces) y dos interfaces Serie (2 Serial network interfaces). En la
tabla 4.2 podemos consultar las principales interfaces con las
que nos vamos a encontrar:
Tabla 4.2. Interfaces Cisco.

Interfaz Descripción
Async Líneas para conexiones modem (dial-in/out). El

puerto AUX es una lína asíncrona. Algunos
modelos denominados "terminal servers" tienen
numerosas líneas async para conectar bancos
de modems.
121
Interfaz Descripción
Async Tradicionalmente los Cisco 2509 con 8 puertos

(continuación) asíncronos y el 2511 con 16 han cumplido con
esta función, cubierta actualmente por el modelo
2610XM-16TS de 16 puertos asíncronos.
ATM ATM (Asynchronous Transfer Mode), interfaz
usada para conectar el router con switches ATM,
lo que incluye conexiones ADSL.
BRI BRI (Basic Rate Interface) para RDSI (2B + D).
Cable?modem Puerto para conexión Cable (estándar
DOCSIS).
Ethernet Puerto Ethernet que soporta 10 megabits por
segundo.
FastEthernet Puerto Ethernet que soporta 100 megabits por
segundo.
FDDI Interfaz tipo Fiber Distributed Data Interconnect.
GigabitEthernet Puerto Ethernet que soporta 1000 megabits por
segundo
Hssi High-Speed Serial Interface (Interfaz Serie de
Alta Velocidad).
Hub Un hub integrado en el router y tratado como una
interface.
Loopback Una interfaz virtual del router.
null La "papelera", equivale al /dev/null de UNIX. Todo
lo que se manda a esta interfaz lógica se des-
carta. Se usa para filtado de enrutamiento
simple.
Serial Interfaz Serie, a menudo conectada a una CSU/
DSU, para conexiones punto a punto, Frame
Relay...
Tokenring Interfaz Token Ring de IBM
vlan LAN Virtual.
Con la orden "show interfaces" obtendremos mucha

más información acerca de las interfaces:
Router#show interfaces
FastEthernet0/1 is up, line protocol is up
Hardware is AmdFE, address is 0001.9670.b781 (bia 0001.9670.b781)
Internet address is 172.22.1.3/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
122
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
265295 packets input, 21235441 bytes
Received 105678 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
1337306 packets output, 125379250 bytes, 0 underruns
0 output errors, 0 collisions, 8 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Serial0/0 is up, line protocol is up

Hardware is PowerQUICC Serial
Encapsulation FRAME-RELAY, loopback not set
LMI enq sent 108260, LMI stat recvd 108252, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE
Broadcast queue 0/64, broadcasts sent/dropped 306266/2, interface broadcasts 306266
Last clearing of "show interface" counters 1w5d
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/3/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 1158 kilobits/sec
934269 packets input, 83226465 bytes, 0 no buffer
1 input errors, 0 CRC, 1 frame, 0 overrun, 0 ignored, 0 abort
16 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up
En los próximos apartados aprenderemos a interpretar estas

salidas. Otra orden muy útil es "show ip interface", un co-
mando que muestra información de red (ip address) de las inter-
faces disponibles. En concreto "show ip interface brief"
hace un resumen de las interfaces disponibles, dirección IP y
estado operacional a nivel físico (status) y de enlace (protocol):
Router1#show ip interface brief
FastEthernet0/0 unassigned YES NVRAM up up
FastEthernet0/0.1 172.25.1.15 YES NVRAM up up
FastEthernet0/0.2 172.16.2.11 YES NVRAM up up
Serial0/0 unassigned YES NVRAM up up
Serial0/0.1 172.25.2.11 YES NVRAM up up
Serial0/0.2 172.20.1.11 YES manual up up
123
FastEthernet0/1 172.22.1.13 YES NVRAM up up
Serial0/1 10.1.1.12 YES NVRAM up up
Si especificamos una interfaz, como en "show ip inter-

face FastEthernet 0/0", obtendremos detalles de la con-
figuración IP de la interfaz en concreto:
Router1#show ip interface FastEthernet0/0
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.1 224.0.0.2
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is enabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Probe proxy name replies are disabled
Policy routing is disabled
Network address translation is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled
Otras dos órdenes muy útiles se obtienen añadiendo los pa-

rámetros "stats" y "switching" a la orden "show interfaces".
En concreto "show interfaces FastEthernet0/1 stats"
muestra las estadísticas de conmutación de paquetes de la inter-
face en paquetes y bytes tanto de entrada como de salida:
124
Router0#show interfaces FastEthernet0/0 stats
FastEthernet0/0
Switching path Pkts In Chars In Pkts Out Chars Out
Processor 294567 18704930 239526 22219870
Route cache 7758 681257 48303 6129834
Total 302325 19386187 287829 28349704
La orden "show interfaces FastEthernet0/1 swit-

ching" desglosa la información anterior en function del pro-
ceso del router que ha conmutado el paquete:
Router1#show interfaces FastEthernet0/1 switching
FastEthernet0/1
Throttle count 0
Drops RP 0 SP 0
SPD Flushes Fast 0 SSE 0
SPD Aggress Fast 0
SPD Priority Inputs 40510 Drops 0
Protocol Path Pkts In Chars In Pkts Out Chars Out

Other Process 11562 1022965 18730 1123800
Cache misses 0
Fast 0 0 0 0
Auton/SSE 0 0 0 0
IP Process 102271 8491851 220342 21066444
Cache misses 0
Fast 7758 681257 48304 6129962
Auton/SSE 0 0 0 0
ARP Process 1819 109140 467 31756
Cache misses 0
Fast 0 0 0 0
Auton/SSE 0 0 0 0
Casi todos los ejemplos del libro se basan en el protocolo

TCP/IP, pero es posible que otros protocolos estén disponibles
(depende de la versión de IOS). Los habilitaremos mediante
la orden de configuración global "protocolo routing" ("ip
routing", "ipx routing", "appletalk routing", etc…).
Para examinar qué protocolos tiene habilitados usaremos
"show protocol":
Router#show protocol
Global values:
Internet Protocol routing is enabled
X.25 routing is enabled
IPX routing is enabled
Appletalk routing is enabled
4.2. Conectividad LAN

Las redes de área local (LAN, de Local Area Network) se ca-
racterizan por abarcar zonas geográficas de tamaño moderado.
Lo más normal es que este tipo de redes sean propiedad del
125
organismo que las utiliza, que se encarga también de su gestión
y mantenimiento. Las más populares son las redes Ethernet
con sus distintas velocidades (Ethernet estándar a 10Mb/s,
FastEthernet a 100Mb/s, GigaEthernet a 1000Mb/s). También
resulta cada vez más frecuente encontrarse con redes inalám-
bricas ó WiFi. A continuación veremos cómo se configuran
los principales parámetros que necesitamos especificar y los
comandos básicos para comprobar su funcionamiento.
Recordemos que debemos habilitar administrativamente la
interfaz mediante la orden "no shutdown", darle una direc-
ción de red y una máscara consistente con la dirección de la
red a la que dicha interfaz se encuentra conectada y proceder a
configurar los parámetros propios de la tecnología correspon-
diente (velocidades, tipos de conector, etc…). Según el modelo
de router accederemos al modo configuración especificando
el número de interfaz, slot, adaptador y puerto:
Router(config)# interface ethernet número
Router(config)# interface ethernet slot/puerto
Router(config)# interface ethernet slot/adaptador/puerto
Router(config)# interface fastethernet número
Router(config)# interface fastethernet slot/puerto
Router(config)# interface fastethernet slot/adaptador/puerto
Router(config)# interface gigabitethernet slot/puerto
4.2.1. Ethernet (IEEE 802.3)

De todas las tecnologías de interconexión de redes locales
Ethernet es la más extendida. Esto se debe a su bajo coste, a su
extensión (todos los ordenadores salen de fábrica equipados
con una tarjeta Ethernet 100/1000) y a su muy aceptable ren-
dimiento en condiciones normales.
Ethernet se basa en el protocolo CSMA-CD (Carrier Sense
Multiple Access - Collision Detect, acceso múltiple por detección
de portadora con detección de colisiones). Éste es un sistema
llamado "de contienda", en el que los equipos compiten si-
multáneamente por el acceso al medio (Multiple Access). Si un
equipo quiere mandar información, escucha para determinar
si el medio está disponible detectando la portadora (Carrier
Sense) y, en caso afirmativo, envía sus datos. Si, pese a todo,
dos equipos transmiten a la vez se producirá una colisión. El
protocolo está preparado para detectar las colisiones (Collision
Detect) y las estaciones implicadas la resuelven retransmi-
tiendo el mensaje, dejando cada estación pasar un intervalo
de tiempo aleatorio.
126
Figura 4.1. Ethernet según su inventor, Robert Metcalfe.
Nota: El nacimiento de la tecnología de redes locales Ethernet

tuvo lugar en 1973 cuando Bob Metcalfe, del Xerox PARC
(Palo Alto Research Center), presentó un memorándum
describiendo cómo conectar los ordenadores e impresoras del
centro. Metcalfe llamó a esta tecnología Ethernet haciendo
referencia al éter, el hipotético medio universal que los cien-
tíficos del siglo XIX creían necesario para la propagación de
la luz. Metcalfe consideró que el éter era una metáfora válida
para un medio que propaga información. El diagrama de la
Figura 4.1 pertenece al propio Metcalfe. Durante estos 35
años Ethernet se ha estandarizado (IEEE 802.3), pasando de
los 3 Mbit/s originales hasta los actuales 10 Gigabits. Por
medio están los clásicos 10Mbit/s, 100 (Fast Ethernet) y 1000
(Gigabit Ethernet). Por el camino Ethernet se ha llevado por
delante a tecnologías competidoras como Token Ring, FDDI
y ARCNET. Metcalfe, por su parte, dejó Xerox PARC en
1979 para fundar 3Com (Computers, Communication and
Compatibility).
Veamos un ejemplo de configuración de una interfaz

Ethernet:
POE#conf t
POE(config)# interface ethernet 0
POE(config.if)# ip address 10.130.7.1 255.0.0.0
POE(config.if)# media-type auto-select
Hemos habilitado administrativamente la interfaz y le

hemos dado una dirección de red. Mediante el comando
"media-type" indicamos el tipo de medio al que la interfaz
se conecta. A veces no basta con dejar que el router lo detecte
automáticamente "auto-select", y se hace necesario in-
dicar explícitamente el tipo de medio al que la interfaz está
conectada:
POE(config.if)# media-type 10BaseT
127
También podemos configurar más de una dirección de red
mediante el uso de direcciones secundarias:
POE(config.if)# ip address 172.20.0.1 255.255.0.0 secondary
Esta posibilidad resulta particularmente útil cuando nece-

sitamos cambiar las direcciones de una red. Gracias al meca-
nismo de direcciones secundarias, podemos mantener durante
el periodo de transición varias direcciones en un mismo seg-
mento de red. Cuando la migración ha tenido lugar se elimina
la dirección secundaria y los usuarios que no han realizado los
cambios requeridos protestarán rápidamente para indicar que
la línea se ha venido abajo. Si son muchos los que se quejan,
podemos dar marcha atrás al cambio y replantearnos de paso
nuestra política de comunicación de cambios en la red.
Para comprobar el estado de la interfaz disponemos de
varias órdenes. La primera y más importante es "show in-
terfaces Ethernet":
POE#show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c0f.6fbf (bia 0000.0c0f.6fbf)
MTU 1500 bytes,BW 10000 Kbit,DLY 1000 usec,rely 255/255,load 14/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
Last clearing of "show interface" counters 00:12:12
Output queue 0/40, 0 drops; input queue 50/75, 181 drops
Received 378348 broadcasts, 0 runts, 0 giants
Fijémonos en la línea "Ethernet0 is up, line protocol is up". La pri-

mera parte ("Ethernet0 is up") nos indica si la interfaz está activa
físicamente (si no hubiésemos habilitado administrativamente
la interfaz mediante el comando "no shutdown", nos encon-
traríamos con la línea "Ethernet0 is administratively down, line
protocol is down" y la interfaz estaría caída). La segunda parte de
la línea ("line protocol is up") indica si la interfaz se encuentra en
un estado utilizable a nivel de enlace. El router realiza pruebas
de actividad para decidir si el estado del protocolo es correcto.
Si fallan tres pruebas consecutivas, el protocolo de la interfaz
128
se marca como caído. El protocolo se puede caer por varios mo-
tivos: el cable de la red local puede estar desconectado, puede
que esté conectado pero de forma incorrecta, puede tratarse de
un cable estropeado o distinto al requerido, el hub o el switch
al que el router se conecta estar apagado, etc…
A continuación aparece la dirección de red ("Internet Address
si 10.1.150.1/8"). La tercera línea muestra varios parámetros
de la interfaz: El máximo tamaño de paquete (MTU), fijado a
1500 bytes; el ancho de banda (bandwidth, BW), fijado a 10000
Kbit; la demora de la interfaz (delay, DLY), fijada en 1000 mi-
crosegundos, la fiabilidad de la interfaz (rely) indicada por el
valor 255/255, que significa que la interfaz tiene una fiabilidad
del 100 por 100, y la carga (load) de la interfaz, en el ejemplo
14/255 (del 5%).
En la cuarta línea vemos el tipo de encapsulado de la in-
terfaz (en nuestro caso ha tomado por defecto la encapsulación
ARPA), y la indicación acerca del estado del modo de bucle
("loopback not set") y del modo de actividad ("keepalive set").
La línea "Last clearing of show interface counters 00:12:12"
indica que los contadores se han limpiado hace 12 minutos y
12 segundos: todos los valores que vienen a continuación son
estadísticas para esos 12 minutos. Muy interesantes resultan
las líneas "5 minute input rate 579000 bits/sec, 621 packets/sec" y
"5 minute output rate 565000 bits/sec, 604 packets/sec" que mues-
tran el promedio del tráfico de esta interfaz para los últimos
5 minutos.
4.2.2. FastEthernet
La tecnología Ethernet ha evolucionado en respuesta a las
demandas de una mayor velocidad. Las interfaces FastEthernet
proporcionan conexiones con redes locales de alta velocidad
(100Mbps). Por lo demás, estas interfaces se configuran de
forma muy similar a las interfaces Ethernet: hay que habilitarla
administrativamente y proporcionarle una dirección válida:
POE(config)# interface FastEthernet0/0
POE(config.if)# ip address 172.19.128.60 255.255.248.0
Con el parámetro "speed" podemos forzar la velocidad del

enlace a 10Mbps, a 100Mbps o dejar que la interfaz negocie au-
tomáticamente la velocidad con el switch al que se encuentre
conectado. Con la orden "full-duplex" o "half-duplex"
especificamos el tipo de transmisión.
129
POE(config.if)# speed ?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration
Por defecto la mayoría de las interfaces FastEthernet de-

tectarán el tipo de medio, la velocidad y el modo dúplex. En
el siguiente ejemplo configuramos de forma explícita todos
estos aspectos:
Router(config)# interface FastEthernet0/0
Router(config-if)# media-type 100BaseX
Router(config-if)# duplex full
Router(config-if)# speed 100
Router(config-if)# exit
Router(config)# end
Router#
También podemos ajustar la dirección MAC de la interfaz,

así como los tiempos de la caché ARP y del los "saludos" (kee-
palives):
Router(config-if)# mac-address 0ABC.ABCD.0204
Router(config-if)# arp timeout 7200
Router(config-if)# keepalive 3
Router(config)# end
Router#
Todas las tarjetas Ethernet vienen de fábrica con un identi-

ficador único de 48 bits de longitud grabado "a fuego", de ahí
que a veces se denomine a este número como BIA (burned-in
address), aunque la denominación más frecuente que recibe
esta dirección de capa 2 es MAC (Media Access Control). Puede
ocurrir en algunas circunstancias que necesitemos cambiar la
dirección MAC, por ejemplo para saltar una lista de acceso
que filtre por dirección MAC, o para adaptar la conexión a un
equipo o software anticuado. La orden "mac-address" nos
permite hacerlo.
Nota: Si al cambiar la MAC dos equipos de la misma red

terminan con la misma dirección de enlace ambos tendrán
problemas de comunicaciones. Las direcciones MAC deben
ser únicas.
130
La tabla ARP del router relaciona o "mapea" las direcciones
IP con las direcciones MAC. Por defecto las entradas duran
14400 segundos en la tabla (4 horas). Si por alguna razón este
tiempo no es aceptable se puede modificar con la orden "arp
timeout" seguido de un valor especificado en segundos.
La orden "keepalive" regula la frecuencia con que se en-
vían "saludos" por la interfaz indicando su "estado de salud".
Por defecto es 10 segundos, pero se puede regular con la
orden "keepalive" seguida del número de segundos entre
"saludos".
El parámetro "keepalive" fijado a 0 segundos equivale a
"no keepalive". En este caso el router deja de mandar kee-
palives y considera que la interfaz está levantada pase lo que
pase. Esto resulta muy útil para forzar un estado "up/up" en
una interfaz Ethernet cuando configuramos un router y todavía
no tenemos nada conectado en dicha interfaz. Otro uso muy
frecuente lo encontramos cuando una interfaz Ethernet queda
en estado up/down (FastEthernet1/0 is up, line protocol is down).
Este estado se denomina "caída a nivel de protocolo" y a veces
hay que demostrar que no es el router el que está caído sino la
red local que hay detrás de la interfaz Ethernet. Si "levantamos"
la interfaz con un "no keepalive" esta se levantará con lo que
se podrá hacer ping a la dirección IP de la interfaz Ethernet
(desde "fuera", claro, ya que la LAN sigue caída).
Si se aprecia con un "show interface FastEthernet0/0"
que las colisiones van en aumento debe revisar la velocidad y
el tipo de conexión (full/half), dado que una mala configuración
de los mismos puede provocar que la conexión se degrade
excesivamente.
RAVEN#sh int fastEthernet 1/0
Hardware is AmdFE, address is 0007.8901.2930 (bia 0007.8901.4354)
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
Half-duplex, 100Mb/s, 100BaseTX/FX
16027499 packets input, 2616886732 bytes
0 watchdog, 0 multicast
131
4.2.3. GigaEthernet
Los modelos de gamas superiores soportan interfaces
Gigabit Ethernet (1000 Mbps). Por ejemplo los routers Cisco
2821 y 2851 así como la plataforma 3800 Integrated Service
Router disponen de dos interfaces Gigabit Ethernet de cobre.
En otros routers modulares como los 2811, 2821, 2851, 3825 y
3845 se puede usar un módulo como el HWIC-1GE-SFP (High-
Speed WAN Interface Card, Giga Ethernet, Small Form-Factor
Pluggable) al que conectar adaptadores SFP (Small Factor
Pluggable) de cobre o fibra con los que proporcionar conecti-
vidad Gigabit Ethernet.
Una interfaz Gigabit Ethernet proporciona un enlace rá-
pido con el que enrutar entre VLANes, en un esquema como
el mostrado en la figura 4.2.
Figura 4.2. InterVLAN routing a través

de una conexión GigaEthernet.
Estas interfaces también se usan para agregar VLANes e

interconectarlas a través de redes privadas virtuales (VPNs)
132
como muestra la figura 4.3. Además el sistema operativo IOS
permite aplicar en estas redes características de calidad de ser-
vicio (QoS) tales como traffic shaping e inspección de paquetes
NBAR (Network-Based Application Recognition).
Figura 4.3. VPN entre oficinas.
En cualquier caso la forma de configurar la interfaz es igual

a la ya descrita en los casos anteriores. Se especifica la interfaz
Gigabit Ethernet:
Router(config)# interface gigabitethernet slot/port
Router(config)# interface gigabitethernet slot/port-adapter/port
y se entra al modo configuración:

Router#interface gigabitethernet 4/0/0
Router(config-if)# negotiation auto
Router(config-if)# mtu 1501
Router(config-if)# end
Igualmente para comprobar la configuración de la interfaz

usaremos las órdenes "show" ya conocidas:
Router#show interfaces gigabitethernet 0/0
GigabitEthernet0/0 is up, line protocol is up
Hardware is 82543 (Livengood), address is a0d0.afb6.ac00 (bia a0d0.afb6.ac00)
Encapsulation ARPA, loopback not set
Full-duplex mode, link type is autonegotiation, media type is SX
output flow-control is on, input flow-control is on
ARP type:ARPA, ARP Timeout 04:00:00
Queueing strategy:fifo
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
133
0 lost carrier, 0 no carrier, 0 pause output
4.2.4. ATM
ATM (siglas de Asynchronous Transfer Mode o Modo de
Transferencia Asíncrono) es un protocolo que encontraremos
en los entornos más diversos. Su tecnología camaleónica se
adapta por igual a redes de área local (LANE), metropolitanas
(enlaces T-1, T-3, OC-48) y de área amplia, siendo una tecno-
logía muy popular para construir el backbone de los provee-
dores de Frame Relay, xDSL, SONET/SDH, etc… Dada esta
disparidad de usos no sorprende encontrar interfaces ATM
en toda clase de routers, desde los pequeños Cisco 827 que
llevan una interfaz ATM/ADSL de fábrica hasta los routers
más avanzados de la serie 12000.
Nota: El ATM Forum, del que Cisco es miembro fundador,

se creó en 1991 para estandarizar y promover el uso del
Asynchronous Transfer Mode. En su día llegó a establecer más
de 200 acuerdos de implementación. El acuerdo de Anchorage
(Anchorage Accord) aprobado por el ATM Forum en 1996
sentó las bases definitivas del protocolo ATM. En 2004 el
ATM Forum se unió a la alianza MPLS & Frame relay para
formar el MFA Forum, que más tarde se integró en el IP/MPLS
Forum. En el siguiente enlace podrá encontrar más informa-
ción acerca de ATM http://www.ipmplsforum.org/
tech/atm_specs.shtml.
ATM realiza pocos controles de flujo y errores en compa-

ración con otros protocolos, por lo que resulta muy rápido.
Además permite la multiplexación de varias conversaciones
lógicas sobre una conexión física. ATM usa celdas de tamaño
fijo (53 bytes), de los cuales 5 están reservados para la cabecera
y los 48 restantes son usados para transportar lo datos de los
protocolos superiores. Este tamaño pequeño y fijo permite
una conmutación eficiente y facilita la implementación de
mecanismos de priorización. Otra ventaja de las celdas ATM
es que sus características permiten que el mecanismo de de-
tección de errores no sólo detecte sino que corrija los errores
más simples.
134
Nota: Las celdas pequeñas y de tamaño fijo reducen los
retardos variables (jitter) en la multiplexación de múltiples
flujos de datos. Reducir el jitter y los retardos de extremo a
extremo es muy importante en procesos en tiempo real como el
transporte de voz. Los codecs encargados de las conversiones
funcionan mejor ante flujos de datos regulares.
ATM es un protocolo de nivel 2. La información de las

capas superiores es encapsulada en celdas que contienen los
identificadores necesarios para que el proveedor del servicio
encamine la información hasta su destino.
La unidad básica de conmutación ATM es el VCC (Conexión
de Canal Virtual, Virtual Channel Conection). Los circuitos vir-
tuales ATM pueden ser permanentes (PVC) o conmutados
(SVC). Los VCCs se agrupan en VPCs (Conexión de Camino
Virtual, Virtual Path Connection) que tienen el mismo origen y
destino. Esta agrupación permite conmutar simultáneamente
las celdas que comparten un determinado trayecto y así reducir
el coste de procesamiento.
Para identificar un circuito virtual usaremos dos valores: el
VPI es el identificador de camino virtual (Virtual Path Identifier)
y el VCI es el identificador de canal virtual (Virtual Channel
Identifier). Puede pensar que el VPI identifica un conjunto de
circuitos (el VPC), y el VCI uno concreto de ese conjunto (el
VCC). Lo que todo esto significa en la práctica es que el pro-
veedor del servicio ATM nos asignará uno o varios circuitos
que vendrán identificados por un par de valores VPI/VCI.
Veamos un ejemplo de configuración de un PVC sobre
ATM: tenemos que seleccionar una interfaz ATM, habilitarla
administrativamente, darle una dirección IP y asignarla a un
circuito vpi/vci. Además tenemos que dar un encapsulado
(se trata de un protocolo de nivel 2) y mapear la dirección IP
remota con el PVC. Dejaremos que el router descubra por si
mismo la IP del otro extremo por medio de ARP inverso:
Router(config)# interface ATM0
Router(config-if)# interface ATM0.1
Router(config-subif)# ip address 172.16.0.1
255.255.255.0 inarp 5
Router(config-subif)# atm pvc 10 2 40 aal5snap
Para este ejemplo hemos creado una subinterfaz (ATM0.1).

Con la opción "inarp 5" hemos habilitado explícitamente el
mecanismo ARP inverso para que intercambie información de
135
los mapeos cada 5 minutos (en ATM el ARP inverso está des-
habilitado por defecto). A continuación hemos usado la orden
"atm pvc" para crear un PVC que localmente identificaremos
con el número 10, usando los valores pvi/vci que nos propor-
cione el proveedor del servicio, en este ejemplo 2/40. A con-
tinuación proporcionamos un encapsulado ATM (aal5snap).
En ATM los encapsulados están relacionados con la capa de
adaptación de ATM (AAL , ATM Adaptation Layer). Dos de los
encapsulados disponibles son aal5snap (para los casos en los
que todo el tráfico vaya por un único circuito ATM) y aal5mux
ppp (que permite crear un PVC por cada protocolo).
Podemos comprobar el funcionamiento de la interfaz ATM
con la orden "show atm" seguida de alguna de las posibilidades
que nos ofrece el router:
Ramanujan#sh atm ?
arp-server ATM ARP Server Table
class-links ATM vc-class links
ilmi-configuration Display Top level ILMI
ilmi-status Display ATM Interface ILMI information
interface Interfaces and ATM information
map ATM static mapping
pvc ATM PVC information
route ATM route
traffic ATM statistics
vc ATM VC information
vp ATM VP information
Podemos comprobar el estado de la interfaz ATM0 con la

orden "show atm interface atm 0":
Ramanujan#sh atm interface atm 0
Interface ATM0:
AAL enabled: AAL5 , Maximum VCs: 24, Current VCCs: 15
Maximum Transmit Channels: 0
VCIs per VPI: 256,
Max. Datagram Size: 4528
PLIM Type: VALID - 320Kbps, Framing is Unknown,, TX clocking: LINE
955524 input, 899288 output, 18411566 IN fast, 17489177 OUT fast
Avail bw = 320
Config. is ACTIVE
Podemos comprobar el estado de los circuitos virtuales con

"show atm pvc":
Ramanujan#sh atm pvc
VCD / Peak Avg/Min Burst
Interface Name VPI VCI Type Encaps SC Kbps Kbps Cells Sts
0.1 1 2 40 PVC SNAP UBR 320 UP
Para ver estadísticas de tráfico ATM usaremos "show atm

traffic":
136
Ramanujan#sh atm traff
19367177 Input packets
18388545 Output packets
0 Broadcast packets
0 Packets received on non-existent VC
0 Packets attempted to send on non-existent VC
226240 OAM cells received
F5 InEndloop: 226155, F5 InSegloop: 1, F5 InAIS: 79, F5 InRDI: 5
F4 InEndloop: 0, F4 InSegloop: 0, F4 InAIS: 0, F4 InRDI: 0
226241 OAM cells sent
F5 OutEndloop: 226177, F5 OutSegloop: 0, F5 OutRDI: 79
F4 OutEndloop: 0, F4 OutSegloop: 0, F4 OutRDI: 0
0 OAM cell drops
Si está habilitado el mecanismo OAM (Mantenimiento y

Operación, Operation and Maintenance), podremos ver cómo
tiene lugar el intercambio de estas celdas. Vemos que en el
ejemplo de las "OAM cells received" y las "OAM cells sent" au-
mentan a la par, sin que haya descartes (drops).
4.2.5. TokenRing (IEEE 802.5)

IBM mostró su topología Token Ring en 1982 cuando pre-
sentó la documentación para el proyecto 802 del Institute of
Electrical and Electronics Engineers (IEEE). En 1984 anunció un
producto, Token Ring, y un año más tarde se convertía en el
estándar IEEE 802.5, que define una red de área local (LAN) en
configuración de anillo (Ring), con método de paso de testigo
(Token) como control de acceso al medio.
Cuando escribimos la primera edición de esta guía ya di-
jimos que las redes Token Ring estaban menos extendidas que
las redes Ethernet. En la actualidad es bastante infrecuente
encontrarnos con una red de este tipo. Su funcionamiento se
basa en el paso de un testigo (token) entre las estaciones que
se encuentran conectadas a la red, que tiene una topología ló-
gica de anillo (ring). En un momento dado sólo una estación
(la que posea el testigo) puede transmitir. Al no competir por
el acceso al medio como en el caso de las Ethernet se resuelve
el problema de las colisiones, y para cargas medias y altas de
tráfico el rendimiento de las redes basadas en paso de testigo
es mejor. Los mecanismos deterministas aplicados por las
redes Token Ring permiten conocer el tiempo que tardará en
transmitir una estación cualquiera.
Las redes Token Ring funcionan a dos velocidades, 4Mbps
y 16Mbps. Esta velocidad se configura mediante la orden
"ring-speed":
137
Router(config)# interface TokenRing0
Router(config-if)# ip address 192.41.3.1 255.255.255.0
Router(config-if)# ring-speed 16
Una mala configuración de la velocidad de la interfaz puede

impedir que el router se inserte en el anillo.
4.2.6. Wireless (IEEE 802.11)

La comunicación inalámbrica (Wireless) consiste en la trans-
misión de información sin usar conductores eléctricos o cables.
Las WLAN (Wireless LANs) son una alternativa a las redes lo-
cales basadas en cableado en las que el estandar 802.11 toma
el lugar del estandar Ethernet, permitiendo a los usuarios gran
mobilidad en el entorno de trabajo.
Las redes inalámbricas se basan en el uso de ondas electro-
magnéticas tales como ondas de radio, y trabajan en el nivel
físico y de enlace de la pila de protocolos. Las WLAN están
normalizadas en el conjunto de estándares IEEE 802.11, per-
tenecientes al comité LAN/MAN (IEEE 802).
802.11 usa la técnica CSMA/CA (Carrier Sense Multiple
Access/Collision Avoidance). En la práctica las transmisiones
son preanunciadas, y los sistemas participantes se escuchan
entre ellos intentando reconocer colisiones. CA usa una fun-
ción denominada DFC (Distributed Coordination Function)
que implementa contadores y retardos para asegurar la co-
operación.
Tabla 4.3. Estándares Wifi.

Estándar Descripción
IEEE 802.11 Estándar WLAN original, 1 y 2 Mbit/s, 2.4

GHz RF.
IEEE 802.11a 54 Mbit/s, 5 GHz
IEEE 802.11b Mejoras al 802.11 para soportar 5.5 and
11 Mbit/s
IEEE 802.11g 54 Mbit/s, 2.4 GHz
IEEE 802.11p WAVE - Wireless para ambulancias y
coches.
IEEE 802.11u Interconexión con redes no-802 (por ej.
redes celulares)
138
Nota:Wi-Fi es una marca registrada de la Wi-Fi Alliance
(http://wi-fi.org/), una asociación que reúne unos 300 miem-
bros y se dedica a promocionar el uso de las WLANs. La
Wi-Fi Alliance proporciona un programa de certificaciones y
pruebas con el objeto de garantizar la interoperabilidad de los
productos WLAN basados en la especificación IEEE 802.11.
Aunque se tiende a usar Wi-Fi y red inalámbrica (WLAN)
de forma intercambiable, en la práctica hay productos WLAN
que no tienen la certificación Wi-Fi, lo que puede deberse a los
costes del programa de certificación.
El aire es un conductor de ondas electromagnéticas muy

pobre, introduciendo una gran atenuación de la señal, aparte
de suponer una mala guía para las ondas. La señal no está
confinada a un medio físico de propiedades predecibles (como
una fibra óptica), lo que supone pérdidas, dispersión y en la
práctica limita la distancia de transmisión.
El espectro de frecuencia que permite una buena comunica-
ción inalámbrica está muy limitado, de forma que un problema
importante a resolver es el de cómo repartir entre los usuarios
el uso del canal de comunicación para que puedan tener lugar
varias comunicaciones a la vez. Sin organización aparecerían
interferencias que pueden llegar a impedir la comunicación.
Las técnicas de multiplexado o de control de acceso al medio
se han desarrollado precisamente para permitir a un número
de usuarios suficientemente grande compartir el limitado re-
curso que es el medio de transmisión. Las tres pricipales son
la multiplexación por división de tiempo (Time-division multi-
plexing o TDM), la multiplexación por división de frecuencia
(Frequency-division multiplexing o FDM) y la multiplexación por
división de código (Code-division multiple access o CDMA)
En el caso de la TDM (multiplexación por división de tiempo)
múltiples usuarios se turnan para acceder al ancho de banda,
pero cada usuario lo acapara por completo durante el tiempo
asignado. En un acceso equitativo N usuarios acceden al ancho
de banda B, pero sólo la enésima fracción del tiempo total. TDM
es simple y puede manejar muchos usuarios, pero requiere sin-
cronización de todos los usuarios, y no garantiza que los huecos
o slots de tiempo asignados a casa usuario sean realmente utili-
zados (reparte ciegamente y no entre quien lo necesita)
En la multiplexación por división de frecuencia o FDM
todos los usuarios acceden al canal todo el tiempo, pero el
espectro disponible se divide entre los usuarios. No garantiza
139
un gran ancho de banda, pero a cambio asegura a cada usuario
su trocito de espectro.
En tercer lugar tenemos la multiplexación por división de
código o CDMA. Esta técnica, más conocida como espectro
expandido o spread spectrum, emplea un esquema de codifica-
ción por el que la señal se esparce por todo el ancho de banda,
asignándosele a cada transmisor un código único: el receptor
capta las señales emitidas por todos los transmisores al mismo
tiempo, pero gracias al esquema de codificación que emplea
códigos únicos puede seleccionar la señal de interés.
Una analogía que permite diferenciar los tres esquemas de
multiplexación es el de una habitación (el canal de transmisión)
llena de gente que quiere comunicarse entre si (emisores y
receptores). Pueden tomar turnos (TDM), hablar en tonos di-
ferentes (FDM), o hablar distintos idiomas (CDMA). Entre las
ventajas del CDMA están los menores consumos necesarios por
las antenas con respecto a los requisitos de los sistemas TDM
o FDM, reduce las interferencias, mejora la reutilización de las
frecuencias en áreas geográficas cercanas, y facilita el traspaso
(handoff) entre celdas en los usuarios móviles.
Nota:¿Qué tienen que ver las redes inalámbricas, las pianolas

y la que fue considerada en los años 30 y 40 del pasado siglo
como la mujer más bella del mundo?
Durante la Segunda Guerra Mundial uno de los grandes retos
consistía en la fabricación de un misil teledirigido. Sin embargo
este tipo de misiles no se desarrollaban debido al temor a que las
señales de control fueran interferidas por el enemigo, inutili-
zando el misil o incluso volviéndolo en contra del atacante.
La actriz Hedy Lamarr (Viena, 1913 – Hollywood, 2000)
patentó junto con al compositor George Antheil un sistema de
comunicaciones por radio que no podía ser interceptado por el
enemigo. Hedy diseñó un equipo de radio que iba cambiando
de canal continuamente, una versión temprana del salto de
frecuencias (la técnica de modulación de señales en espectro
expandido o spread spectrum). El sistema usaba un par de
tambores perforados y sincronizados, a modo de pianola, para
cambiar entre 88 frecuencias.
Las autoridades de la época, sin embargo, no consideraron
viable el invento. Se trataba de una idea adelantada a la
tecnología de su tiempo, y algunas de las metáforas mu-
sicales que habían adjuntado en la documentación de la
patente posiblemente no contribuyeron a despejar las dudas
140
de los militares, que se quedaron estupefactos al ver cómo les
proponían meter una pianola en un torpedo. El invento fué
olvidado hasta que, años más tarde, las nuevas tecnologías
electrónicas permitieron su implementación eficaz, siendo la
base actual de inventos tan omnipresentes como los teléfonos
móviles o el Wifi.
En 1997 Hedy Lamarr recibió el premio "Pioneer Award", de
la Electronic Frontier Foundation.
A continuación veremos un ejemplo práctico de configu-

ración de un dispositivo wireless. Entramos en modo privile-
giado con la orden "configure terminal" para acceder al
modo global de configuración, a continuación seleccionamos
la interfaz radio "interface dot11radio { 0 | 1 }" (radio
0 para 2.4-GHz, radio1 para la banda 5-GHz) para, una vez en
el modo de configuración de interfaz radio, proporcionar el
identificador de red con la orden "ssid". El SSID (Service Set
Identifier) es una cadena de hasta 32 caracteres, alfanumérica,
en la que se distingue entre mayúsculas y minúsculas. Con
la orden "no shutdown" habilitamos la interfaz radio y con
"copy running-config startup-config" grabamos la
configuración en la memoria permanente del router.
A continuación vemos un ejemplo completo:
dot11 ssid routers_cisco2009
vlan 1
authentication open
authentication key-management wpa
wpa-psk ascii 0 12345678
!
dot11 priority-map avid
!
bridge irb
!
interface Dot11Radio0/0/0
no ip address
encryption vlan 1 mode ciphers tkip
ssid routers_cisco2009
speed basic-1.0 basic-2.0 basic-5.5 basic-11.0 24.0 36.0 48.0 54.0
station-role root bridge
!
interface Dot11Radio0/0/0.1
encapsulation dot1Q 1 native
no snmp trap link-status
bridge-group 1
bridge-group 1 spanning-disabled
!
interface BVI1
ip address 9.0.0.1 255.0.0.0
!
141
ip route 0.0.0.0 0.0.0.0 9.0.0.5
!
bridge 1 route ip
En el enlace http://tinyurl.com/67r47w "Configuring

Radio Settings" podemos encontrar explicaciones de muchos
parámetros y modos de configurar estas interfaces radio.
4.2.7. Power Line Communication (PLC)

Terminamos la sección relativa a las LAN mencionando una
tecnología alternativa, la Power-line communication o PLC. Se
trata de una tecnología que permite interconectar dispositivos
usando el cableado eléctrico existente para la distribución de
potencia eléctrica. Su carácter plug-and-play y el hecho de per-
mitir usar una infrastructura ya existente hacen del PLC una
alternativa interesante en el hogar (donde de momento no ha
desplazado al WiFi), así como en el lado de los proveedores
de Internet, como alternativa al ADSL y al cable.
En el PLC los datos se envían sobre cables eléctricos, ocu-
pando una banda mucho más alta que la usada por la señal
eléctrica (50 Hz en Europa, 60 Hz en Estados Unidos). El pro-
blema a resolver en este caso es la amplitud de la señal eléctrica,
al lado de la cual la de la señal de datos es minúscula. Las dos
señales coexisten en el mismo medio, y los datos se separan
por dispositivos finales análogos a un modem.
En España las eléctricas Iberdrola y Endesa ofrecieron du-
rante un tiempo la posibilidad de conectarse a Internet a través
del PLC. Sin embargo Endesa, a principios de 2006, e Iberdrola
a mediados de 2007 rescindieron el servicio a la mayoría de sus
clientes ante la escasa competitividad del PLC frente al ADSL.
Las empresas eléctricas han aprovechado no obstante sus inver-
siones en este campo para reutilizar el PLC como herramienta
de gestión y control de averías de sus redes energéticas.
PLC lo tiene difícil para competir con el ADSL y el cable, sin
embargo puede resultar competitivo en áreas donde las líneas
eléctricas están más desarrolladas que las telefónicas.
4.3. Conectividad WAN

Las redes de área amplia (redes WAN, de Wide Area
Network) conectan el router con dispositivos situados en di-
ferentes ubicaciones. Las redes de área amplia se diferencian
142
en varios aspectos de las redes de área local. Por ejemplo, las
velocidades de los enlaces WAN son menores en relación con
las que se alcanzan en una red local.
Otro aspecto en el que se diferencian las LAN de las WAN
es en el de la gestión de los enlaces: mientras que una red local
suele ser administrada por las propias empresas, las WAN
se contratan a proveedores de servicios de red (compañías
telefónicas, de cable...).
Existen distintos tipos de enlaces WAN: líneas punto a
punto (enlaces reservados por el proveedor de servicios para
el uso privado del usuario), circuitos conmutados (disponibles
durante la duración de la conexión, caso de los enlaces RDSI) y
enlaces basados en conmutación de paquetes (que permiten la
compartición del medio mediante el uso de circuitos virtuales
sobre enlaces físicos, caso de Frame Relay).
Al hablar del modelo OSI ya mencionamos el proceso de
encapsulado de datos. Al configurar enlaces WAN debemos
especificar el tipo de encapsulado de nivel de enlace (nivel 2
del modelo OSI). En función de la tecnología WAN que usemos
y de los equipos de comunicaciones, configuraremos un tipo
de encapsulado.
En el ejemplo siguiente consultamos los encapsulados dis-
ponibles para una interfaz serie en un router Cisco 2501 con
una IOS versión 12.0.(8):
Sagan(config)# interface serial 1
Sagan(config-if)# encapsulation ?
atm-dxi ATM-DXI encapsulation
bstun Block Serial tunneling (BSTUN)
frame-relay Frame Relay networks
hdlc Serial HDLC synchronous
lapb LAPB (X.25 Level 2)
ppp Point-to-Point protocol
sdlc SDLC
sdlc-primary SDLC (primary)
sdlc-secondary SDLC (secondary)
smds Switched Megabit Data Service (SMDS)
stun Serial tunneling (STUN)
x25 X.25
El encapsulado a este nivel realiza una serie de funciones

necesarias para el correcto funcionamiento del enlace: control
de flujo (evita la sobrecarga de las entidades receptoras con un
exceso de datos), control de errores (detecta y corrige los bits
erróneos), gestión (inicia, mantiene y cierra el enlace) y control
de sincronía de las comunicaciones.
143
4.3.1. Interfaz Serie
Las interfaces serie constituyen uno de los principales me-
canismos para conectar los routers con las redes WAN.
Los dispositivos utilizados para procesar información no
suelen conectarse directamente a la red de transmisión sino que
utilizan unos dispositivos intermediarios denominados DSU/
CSU, por ejemplo los módem o las unidades de terminación
de red (UTR). Un dispositivo CSU/DSU (Channel Service Unit/
Data Service Unit) interconecta un equipo terminal DTE, por
ejemplo un router, con un circuito digital, por ejemplo una
línea T1. Un DCE es el dispositivo que se encuentra entre el
DTE y el circuito de transmisión de datos. Como regla general
el DCE proporciona una señal de reloj (reloj interno) a la que
el DTE se sincroniza (reloj externo).
A los equipos que procesan información se les denomina
DTE (Data Terminal Equipment, equipos terminal de datos). A los
equipos que transmiten y reciben los bits, uno a uno, a través de
la red se les denomina DCE (Data Circuit-terminating Equipment,
equipo terminal de circuito de datos). Los DCE realizan varias
funciones: interaccionan entre sí a través de la red estableciendo
enlaces con los conmutadores (switches) de comunicaciones del
proveedor, se comunican con los equipos DTE locales y poseen
una serie de funciones de prueba y diagnóstico (indicando el
estado de la línea mediante una serie de indicadores luminosos).
En la figura 4.4 vemos dos equipos DTE que se comunican a
través de la red de switches del proveedor del servicio de co-
municaciones. Los usuarios no tenemos control sobre dichos
elementos de transporte de datos, y muchas veces esa red de
switches es representada gráficamente como una nube.
Figura 4.4. Equipos DTE, DCE y switches del proveedor.
144
El equipo que hace de DTE se ocupa de poner las señales
DTR (Data Terminal Ready) y RTS (Request to Send), mientras
que el equipo que hace de DCE se encarga de poner las señales
DCD (Data Carrier Detect), DSR (Data Set Ready) y CTS (Clear
to Send). Podemos ver el estado de estas señales al final de la
salida de la orden "show interface serial 0". En caso de
avería podemos ver qué señales faltan para determinar qué
equipo es el que deja de poner sus señales:
Edgar#sh interface serial 0/0
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 8w0d, output 8w0d, output hang never
Input queue:0/75/162540(size/max/drops);Total output drops: 2762884
Output queue:0/1000/64/2762882 (size/max total/threshold/drops)
164 input errors, 31 CRC,126 frame, 0 overrun, 0 ignored, 6 abort
Las interfaces serie tienen múltiples usos. Por ejemplo se

usan para conectar al router con controladoras de primarios
de RDSI (PRI) o con controladoras X25. En estos casos el
router tiene varias interfaces serie: una será utilizada para la
conexión WAN y otra para conectar con una tarjeta X25. En la
conexión WAN el router hará la función de DTE, recibiendo
la señal de reloj del conmutador de red del proveedor. En la
conexión con la tarjeta controladora hará de DCE, poniendo
la señal de sincronía. En cada caso el router se encargará de
poner las señales correspondientes. Por ejemplo, en el caso
de una conexión X25 en la que el router hace las funciones de
DCE seleccionamos la interfaz, configuramos la encapsulación,
indicando que la interfaz hace la función DCE y damos una
velocidad al enlace:
Sagan(config)# interface serial 1
Sagan(config-if)# encapsulation x25 dce
Sagan(config-if)# clock rate 64000
Existe otra situación típica en la que será necesario con-

figurar una interfaz serie como DCE: en entornos en los que
145
se quiera conectar varios routers a través de sus interfaces
serie, una configuración denominada "back to back", en una
disposición típica de los entornos de laboratorio en los que
se simula la conexión WAN. En este caso el router que se en-
carga de poner la señal de reloj tiene conectado el lado DCE
de un cable DTE-DCE y deberá tener configurada una velo-
cidad de transferencia mediante el comando "clock rate".
A continuación, en los siguientes apartados veremos usos
concretos de la interfaz serie en conexiones punto a punto
y Frame Relay.
4.3.2. Conexiones Punto a Punto

Los circuitos punto a punto son enlaces reservados por el
proveedor de servicios para el uso privado del usuario. Este
tipo de enlaces dedicados no tienen los problemas de los en-
laces compartidos, pero su coste es mayor.
Los pasos generales para configurar interfaces serie consisten
en seleccionar la interfaz, habilitarla administrativamente, pro-
porcionar una dirección de red y elegir un encapsulado (un
protocolo de enlace). Opcionalmente podemos darle a la in-
terfaz una descripción.
Para las conexiones punto a punto disponemos de los en-
capsulados HDLC y el PPP. HDLC es un protocolo estándar
de enlace de datos cuya especificación deja más flecos que la
de PPP, lo que puede provocar problemas de interoperabilidad
entre equipos de distintos fabricantes. Por ejemplo, al no tener
un campo de protocolo presenta problemas para el soporte de
múltiples protocolos sobre un mismo enlace. Cisco implementa
una versión propietaria mejorada de HDLC que cuenta con un
campo de protocolo y supera el inconveniente de la versión
estándar, pero al ser propietaria sólo se usa entre dispositivos
Cisco o capaces de interpretar el tipo de trama de Cisco. El
encapsulado HDLC mejorado es el utilizado por defecto en
las líneas serie. HDLC es menos general pero más eficiente
que el protocolo PPP.
El protocolo PPP permite comunicar dispositivos con
independencia del fabricante. Usa un sistema mejorado de
corrección de errores, puede comprimir el tráfico y hace un
uso eficiente del ancho de banda disponible. Además de la
compresión y corrección de errores el protocolo PPP ofrece
otros servicios como los de autenticación y la capacidad de
establecimiento de enlaces múltiples (multilink).
146
Nota: Por ejemplo, un protocolo de compresión de PPP es el
GFZACP (Gandalf FZA Compression Protocol) descrito en el
RFC 1993, y un protocolo de encriptación de PPP es el ECP
(Encryption Control Protocol), descrito en el RFC 1968.
Veamos un ejemplo de configuración (figura 4.5). Hemos

representado la red del proveedor de servicios como una nube.
Para cada router especificamos un nombre (con "hostname") y
el nombre del equipo remoto junto con la contraseña compar-
tida (con "username xxx password yyy"). A continuación
habilitamos la interfaz ("no shutdown"), la describimos y asig-
namos una dirección IP a cada router. Para indicar el encapsu-
lado usamos la orden "encapsulation" y para especificar el
tipo de autenticación "ppp authentication".
Figura 4.5. Conexión punto a punto.
Router1(config)# username Router2 password lamisma

Router1(config)# interface serial 0
Router1(config-if)# encapsulation ppp
Router1(config-if)# ppp authentication chap
Router2(config)# username Router1 password lamisma

Router2(config)# interface serial 0
Router2(config-if)# encapsulation ppp
Router2(config-if)# ppp authentication chap
Con la orden "debug ppp auth" y "debug ppp negotia-

tion" podemos ver todo el proceso de establecimiento de este
protocolo. Para desactivar los debugs, "undebug all".
00:19:29: %LINK-3-UPDOWN: Interface Serial0, changed state to up
00:19:29: Se0 PPP: Treating connection as a dedicated line
00:19:29: Se0 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
00:19:29: Se0 LCP: O CONFREQ [Closed] id 58 len 15
00:19:29: Se0 LCP: AuthProto CHAP (0x0305C22305)
00:19:29: Se0 LCP: MagicNumber 0x02294082 (0x050602294082)
00:19:29: Se0 LCP: I CONFREQ [REQsent] id 47 len 15
00:19:29: Se0 LCP: MagicNumber 0xE02F58A8 (0x0506E02F58A8)
147
00:19:29: Se0 LCP: O CONFACK [REQsent] id 47 len 15
00:19:29: Se0 LCP: MagicNumber 0xE02F58A8 (0x0506E02F58A8)
00:19:29: Se0 LCP: I CONFACK [ACKsent] id 58 len 15
00:19:29: Se0 LCP: MagicNumber 0x02294082 (0x050602294082)
00:19:29: Se0 LCP: State is Open
00:19:29: Se0 PPP: Phase is AUTHENTICATING, by both [0 sess, 1 load]
00:19:29: Se0 CHAP: O CHALLENGE id 127 len 28 from "router1"
00:19:29: Se0 CHAP: I CHALLENGE id 124 len 28 from "router2"
00:19:29: Se0 CHAP: O RESPONSE id 124 len 28 from "router1"
00:19:29: Se0 CHAP: I RESPONSE id 127 len 28 from "router2"
00:19:29: Se0 CHAP: O SUCCESS id 127 len 4
00:19:29: Se0 CHAP: I SUCCESS id 124 len 4
00:19:29: Se0 PPP: Phase is UP [0 sess, 1 load]
00:19:29: Se0 CDPCP: O CONFREQ [Closed] id 2 len 4
00:19:29: Se0 IPCP: O CONFREQ [Closed] id 2 len 10
00:19:29: Se0 IPCP: Address 10.1.1.1 (0x03060A010101)
00:19:29: Se0 IPCP: I CONFREQ [REQsent] id 2 len 10
00:19:29: Se0 IPCP: O CONFACK [REQsent] id 2 len 10
00:19:29: Se0 CDPCP: I CONFREQ [REQsent] id 2 len 4
00:19:29: Se0 CDPCP: O CONFACK [REQsent] id 2 len 4
00:19:29: Se0 CDPCP: I CONFACK [ACKsent] id 2 len 4
00:19:29: Se0 CDPCP: State is Open
00:19:29: Se0 IPCP: I CONFACK [ACKsent] id 2 len 10
00:19:29: Se0 IPCP: State is Open
00:19:29: Se0 IPCP: Install route to 10.1.1.2
00:19:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0,
changed state to up
Indicábamos antes que había una forma de conectar dos

routers Cisco directamente a través de sus puertos serie parti-
cularmente útil en entornos de laboratorio y pruebas. En estos
casos se usa un cable serie especial denominado back to back,
que tiene un lado DTE y un lado DCE (Figura 4.6.)
Figura 4.6. Conexión Back to Back.
En el lado DCE debemos añadir la señal de reloj con la orden

"clock rate". El Router1 queda configurado así:
Router1(config)# interface Serial0
Router1(config-if)# ip address 5.0.2.1 255.255.255.0
Router1(config-if)# clock rate 64000
148
Seguidamente, el Router2 queda configurado de la si-
guiente manera:
Router2(config)# interface Serial1
Router2(config-if)# ip address 5.0.2.2 255.255.255.0
Con "show controllers" podemos ver el tipo de cable y

la velocidad de reloj configurada:
Router1#show controllers serial 0
HD unit 1, idb = 0xF22E4, driver structure at 0xF7778
buffer size 1524 HD unit 0 1, V.35 DCE cable, clockrate 64000
…
Router2#show controllers serial 1

HD unit 1, idb = 0x24824C, driver structure at 0x24F828
buffer size 1524 HD unit 1, V.35 DTE cable
…
Con "show interfaces" comprobamos la encapsulación y

el estado de las distintas señales (DCD, DSR, DTR, RTS y CTS).
En este caso, como no hemos especificado una encapsulación,
usamos por defecto HDLC:
Router1#show interfaces serial 0
Serial1 is up, line protocol is up
Hardware is HD64570
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Un ping nos asegurará de que las comunicaciones son

correctas:
Router2#ping 5.0.2.1
!!!!!
149
4.3.3. Frame Relay
Las conexiones punto a punto son caras y no siempre re-
sultan prácticas para las necesidades de muchas empresas e
instituciones que necesitan mantener conexiones permanentes
con múltiples delegaciones. Una solución más atractiva con-
siste en usar redes públicas de conmutación de paquetes,
creando conexiones virtuales a través de la red del proveedor
de telecomunicaciones.
Frame Relay (FR) es un protocolo que se encarga de definir
los detalles de acceso a estas redes públicas, permitiendo la
conexión de los equipos del cliente con el punto de acceso a la
red más cercano. Ese punto de acceso a la red es el conmutador
o switch de FR. La red pública de conmutación de paquetes
usará internamente las tecnologías que sean precisas para
mandar los paquetes a su destino.
Nota: Seguiremos teniendo una conexión punto a punto con

el proveedor, pero a un precio menor dado que se tratará de
un enlace mucho más corto. La conexión punto a punto con
la red FR del proveedor puede ser a través de una línea punto
a punto con una CSU/DSU, mediante un acceso ADSL o a
través de una llamada RDSI establecida permanentemente o
bajo demanda, entre otras posibilidades.
Otra ventaja fundamental de FR sobre las líneas punto a

punto es que permite crear sobre una interfaz física múltiples
conexiones virtuales (subinterfaces) mediante técnicas de mul-
tiplexación estadística.
Nota: Frame Relay es descendiente directo del protocolo X25,

el estándar original para conmutación de paquetes. El servicio
más característico de X25 es la multiplexación. X25 permite
al equipo DTE establecer 4095 circuitos virtuales con otros
tantos DTEs a través de una única interfaz DTE-DCE. El
protocolo X25 contiene mecanismos redundantes de control
de flujo y de errores que las continuas mejoras en la calidad de
las líneas de comunicaciones han hecho innecesarios. Frame
Relay y ATM se apoyan en la fiabilidad de los enlaces actuales
para delegar muchos mecanismos de control en los protocolos
de capas superiores.
Frame Relay es un protocolo de nivel 2. La información de

las capas superiores es encapsulada en tramas FR que contienen
150
los identificadores necesarios para que la red del proveedor
encamine la información hasta su destino de una forma alta-
mente eficiente.
Figura 4.7. Elementos de Frame Relay.
Frame Relay tiene una terminología propia que debemos

conocer antes de pasar a ver los detalles de su configuración
(figura 4.7): los enlaces FR permiten que tengamos varios cir-
cuitos virtuales (VC) sobre un único circuito físico mediante la
técnica de multiplexación. Estos circuitos se denominan PVCs
(de permanent virtual circuit, circuitos virtuales permanentes), o
SVC (de switched virtual circuit, circuitos virtuales conmutados).
Los PVCs son provisionados de forma permanente por la com-
pañía que presta el servicio, de forma similar a las líneas punto
a punto, mientras que los SVCs son creados y liberados bajo
demanda, de forma análoga a una llamada telefónica. En este
libro nos ocuparemos exclusivamente de los PVC.
Cada uno de los extremos de esos circuitos virtuales
viene identificado por un valor denominado DLCI (Data Link
Connection Identifier, Identificador de Conexión de Enlace de
Datos). Dicho valor es usado por el switch FR para mantener
las distintas conexiones entre los equipos terminales. Los DLCI
tienen sentido local, lo que significa que routers de la misma red
situados en puntos distintos pueden poseer el mismo DLCI.
151
Entre el switch FR y el router se establece un intercambio de
información que permite establecer el estado de los circuitos
virtuales. El protocolo encargado de este diálogo se denomina
LMI (Layer Management Interface, Protocolo de Gestión de
Capa). Aunque las versiones modernas de IOS son capaces de
detectar automáticamente el tipo de LMI pueden darse casos
concretos en los que sea necesario configurarlo manualmente.
El proveedor de servicios de comunicaciones nos indicará el
tipo de LMI que debemos configurar. El LMI también tiene
sentido local, de forma que cada delegación puede tener con-
figurado un tipo de LMI distinto (dicho en otras palabras, el
tipo de LMI no tiene que coincidir de extremo a extremo, sino
entre switch FR y router)
Son características fundamentales de un enlace FR su velo-
cidad medida en Kbps (kilobits por segundo), y el caudal con-
tratado o CIR (Committed Information Rate), que es la cantidad
de información por unidad de tiempo que el proveedor se com-
promete a dejar pasar en todos los casos. Una de las ventajas
de FR proviene de su capacidad de asignar dinámicamente los
recursos de ancho de banda disponibles, de forma que puede
asimilar ráfagas de tráfico por encima del CIR. Específicamente
un dispositivo puede transmitir hasta alcanzar una velocidad
CBIR (Committed Burst Information Rate) y contar con que esa
información transmitida por encima de lo contratado llegue
en un gran porcentaje de los casos. No obstante, cuando se
transmite por encima del CIR los paquetes serán marcados en
su bit DE (Discard Eligiblility bit): si un nodo sufre congestión
y debe descartar paquetes, empezará a hacerlo con aquellos
que lleven activado el bit DE.
Nota: La diferencia entre el CIR y el CBIR se denomina

EIR (Exceed Information Rate). Un circuito con un CIR de
32 y un CBIR de 128 tiene un EIR de 96 (CBIR-CIR). En
condiciones normales este circuito puede transmitir a más de
32Kbps, pero lo que mande por encima de esta velocidad (del
"compromiso" o caudal contratado) saldrá marcado como
"elegible para descarte" (con el bit DE a 1).
Los nodos de la red pública usan un mecanismo de notifi-

cación basado en el estado de varios bits de los paquetes FR.
En concreto, un paquete será marcado en su bit FECN (Forward
Explicit Congestion Notification) cuando los switches FR estén
experimentando congestión en el sentido del flujo de informa-
ción. El dispositivo situado en el origen de la congestión será
152
notificado (se marcan los paquetes que vayan hacia allí con el
bit BECN, de Backward Explicit Congestion Notification).
Figura 4.8. Notificación de la congestión en Frame Relay.
Nota: En 1990 Cisco Systems, StrataCom, Northern Telecom,

y Digital Equipment Corporation formaron un consorcio para
enfocar el desarrollo de la tecnología Frame Relay y acelerar la
introducción de productos Frame Relay interoperables. Este
consorcio, el Frame Relay Forum, desarrolló una especificación
conforme al protocolo básico de Frame Relay ANSI y ITU-T, pero
extendiéndolo con características que proporcionan capacidades
adicionales para entornos complejos de red. Estas extensiones
de Frame Relay son conocidas colectivamente como la Interface
de Dirección Local (LMI = Local Management Interface).
Actualmente el IP/MPLS Forum integra los intereses de ATM,
MPLS y Frame Relay. En el siguiente enlace podrá encontrar
información original acerca de Frame Relay http://www.
ipmplsforum.org/tech/fr_ia.shtml.
Vemos cómo se traducen estos conceptos en configura-

ciones. FR se configura sobre una interfaz serie, dado que en el
nivel físico Frame Relay tiene las características de una interfaz
serie. FR es fundamentalmente un protocolo de nivel de enlace
o nivel 2, lo que se manifiesta en las órdenes para definir el en-
capsulado. Para especificar la encapsulación usamos la orden
"encapsulation frame-relay" seguida del tipo específico
de encapsulado ("cisco"o "ietf").
Nota: El encapsulado "cisco"es el predeterminado,

y es la opción adecuada para interconectar equipos de Cisco.
El encapsulado "ietf" implementa el estándar descrito
en los RFC 1490 y RFC 2427, y permite conectar equipos
de distintos fabricantes. Puede obtener dichos documentos
en los sitios ftp://ftp.rfc-editor.org/in-notes/rfc1490.txt y
ftp://ftp.rfc-editor.org/in-notes/rfc2427.txt.
153
Usamos la orden "frame-relay lmi-type" para confi-
gurar el tipo de LMI que van intercambiar el router y el switch
FR. A continuación le mostramos varias opciones.
POE (config-if)# frame-relay lmi-type ?
cisco
ansi
q933a
A partir de la versión IOS 11.2 del router es capaz de detectar

automáticamente el tipo de LMI usado por el switch FR, ha-
ciendo innecesario configurar el tipo de LMI en muchos casos.
Un último detalle: Frame Relay es un protocolo de nivel de
enlace. Los routers, como dispositivos de nivel 3 que son, usan
direcciones de red: hay que asociar las direcciones de capa de
red (IP) con los parámetros de la capa de enlace (DLCI). Esta
operación puede ser realizada de forma automática por el
router mediante el mecanismo inverse-arp, que se encuentra
habilitado por defecto. Tenga en cuenta que no siempre la
red soporta inverse-arp. Si por alguna razón se encuentra
deshabilitado, podemos volver a activarlo mediante la orden
"frame-relay inverse-arp [protocolo] [dlci]" donde
protocolo puede ser ip, ipx o appletalk (entre otros) y el DLCI
es proporcionado por el proveedor.
Estas asociaciones pueden ser también asignadas de forma
estática mediante el comando "frame-relay map ip". Este
último sistema permite controlar las difusiones asociadas al
establecimiento de estas asociaciones.
frame-relay map ip [IP remota] [dlci] [broadcast]
Donde la IP remota es la IP de la interfaz del router destino,

el dlci es un parámetro asignado por el proveedor y la opción
broadcast permite el paso de difusiones necesarias para el
funcionamiento de los protocolos de enrutamiento dinámico.
Consulte la ayuda para ver todas las opciones disponibles
para esta orden.
Veamos una serie de ejemplos donde se usan todas estas
órdenes:
!SAN JOSE, CAL.
interface Serial0
description Conexión con Boston, Mass. ID. Circuito CA-SJ01
no shutdown
ip address 172.16.0.1 255.255.255.252
bandwidth 64
encapsulation frame-relay ietf
frame-relay lmi-type ansi
154
!BOSTON, MASS.
interface Serial1
description Conexión con San José, Cal. ID. Circuito MS-BS01
no shutdown
ip address 172.16.0.2 255.255.255.252
bandwidth 64
frame-relay lmi-type q933a
Usamos direcciones con máscara /30 (255.255.255.252),

práctica habitual para este tipo de enlaces punto a punto.
También hemos dado una descripción a la interfaz con el objeto
de facilitar las tareas posteriores de mantenimiento y diagnós-
tico. La descripción es un lugar excelente para indicar los datos
administrativos del circuito (el número que lo identifica ante
nuestro proveedor). Por ejemplo Telefónica de España iden-
tifica algunos de sus circuitos mediante un valor denominado
NRI o Número de Ruta Iberpac. Al describir de esta forma los
enlaces tendremos a mano los datos que los identifican para el
caso de que lo necesitemos para abrir incidencia al proveedor
de telecomunicaciones o por cualquier otra razón.
Hemos configurado el ancho de banda mediante la orden
"bandwidth". El valor del ancho de banda va especificado
en kilobits por segundo. Este valor es usado para la construc-
ción de la tabla de rutas, siendo la velocidad real del enlace
independiente del valor que configuremos con esta orden. Al
configurar el ancho de banda tenga en cuenta que en el caso
de los interfaces punto a punto debemos configurar el ancho
de banda con el valor del CIR contratado y que en el caso de
los interfaces punto multipunto hay que configurar este pará-
metro con la suma de todos los CIR.
El que acabamos de ver es un ejemplo sencillo en el que
quedan expuestas las órdenes fundamentales, pero en la
práctica querremos sacar partido de la posibilidad de man-
tener múltiples "conversaciones" sobre un único enlace físico.
Vemos en el siguiente ejemplo un caso más frecuente con una
central y dos delegaciones. Cada PVC posee su propia subred
y hacemos uso de subinterfaces punto a punto (point-to-point).
Entre Madrid y París configuramos la red 172.16.4.0/24 y entre
Madrid y Buenos Aires la red 172.16.8.0/24.
hostname MADRID
interface Serial0
no shutdown
no ip address
interface Serial0.16 point-to-point
155
ip address 172.16.4.1 255.255.255.0
bandwidth 64
frame-relay interface-dlci 16
ip address 172.16.8.1 255.255.255.0
bandwidth 64
Configuramos París:
hostname PARIS
interface Serial0
no shutdown
no ip address
ip address 172.16.4.2 255.255.255.0
bandwidth 64
Y configuramos Buenos Aires:

hostname BUENOS_AIRES
interface Serial0
no shutdown
no ip address
ip address 172.16.8.2 255.255.255.0
bandwidth 64
El número de subinterfaz no tiene por qué coincidir con

el DLCI, pero no es mala idea darle ese valor (al fin y al cabo
hay que darle un valor, no está mal tener decidido cuál vamos
a darle de una forma consistente). Ahora volvamos sobre el
ejemplo anterior, pero esta vez configurando todos los enlaces
dentro de la misma subred. Usaremos para ello subinterfaces
multipunto (multipoint), y todos los routers formarán una
misma red (la 172.16.8.0)
hostname MADRID
interface Serial0
no shutdown
no ip address
interface Serial0.1 multipoint
156
ip address 172.16.8.1 255.255.255.0
bandwidth 64
frame-relay map ip 172.16.8.2 16 broadcast
frame-relay map ip 172.16.8.3 17 broadcast
hostname PARIS
interface Serial0
no shutdown
no ip address
ip address 172.16.8.2 255.255.255.0
bandwidth 64
hostname BUENOS_AIRES
interface Serial0
no shutdown
no ip address
ip address 172.16.8.3 255.255.255.0
bandwidth 64
Alternativamente, podríamos anunciar los DLCIs dis-

ponibles, y dejar que el mecanismo de arp inverso haga su
trabajo:
hostname MADRID
interface Serial0
no shutdown
no ip address
interface Serial0.1 multipoint
ip address 172.16.8.1 255.255.255.0
bandwidth 64
Nota: La decisión de configurar las subinterfaces como punto

a punto o punto multipunto tiene implicaciones en el funcio-
namiento del mecanismo de enrutamiento. Concretamente
el mecanismo de horizonte dividido (split horizon) puede
provocar que las actualizaciones de rutas no se propaguen de
la forma deseada por la red.
157
Dispone de varias órdenes para examinar el estado de la
conexión FR. Por ejemplo, con "show interface serial
0/0" observará en la cuarta línea el tipo de encapsulación FR,
y a continuación el tipo de LMI, estadísticas del intercambio
de LMI con el switch FR, si hace de DTE o DCE, etc…
hardy#show interface serial 0/0
Encapsulation FRAME-RELAY IETF,loopback not set,keepalive set(10 sec)
Carrier delay is 20 sec
LMI enq sent 3257, LMI stat recvd 3257, LMI upd recvd 0, DTE LMI up
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0
LMI DLCI 0 LMI type is CCITT frame relay DTE
[…parte de la salida omitida…]
Examine el estado de los PVCs con la orden "show frame-

relay pvc". Fíjese en la información de estado (STATUS): un
PVC puede estar ACTIVE como el PVC 20 (en funcionamiento),
DELETED como el PVC 21 (configurado en el router pero no
encontrado en red) o INACTIVE como el PVC 22 (caído). Es
muy importante la información DE (paquetes recibidos con la
marca de descarte) y los FECN y BECN (congestión en la red).
Dispone de tiempos de actividad y estadísticas agregadas de
tráfico.
Hardy#sh frame pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)Show frame pvc
DLCI=20 , DLCI USAGE=LOCAL , PVC STATUS=ACTIVE, INTERFACE=Serial0/0.20
input pkts 9344 output pkts 9272 in bytes 695603
out bytes 708482 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 7584 out bcast bytes 606443
pvc create time 12w6d, last time pvc status changed 1w1d
DLCI=21 , DLCI USAGE=LOCAL, PVC STATUS=DELETED, INTERFACE=Serial0/0.21

pvc create time 12w6d, last time pvc status changed 1w1d
DLCI=22, DLCI USAGE=LOCAL, PVC STATUS=INACTIVE, INTERFACE=Serial0/0.23

pvc create time 12w6d, last time pvc status changed 2d16h
Con la orden "show frame-relay lmi" puede obtener in-

formación detallada del intercambio de mensajes LMI entre el
158
router y el switch FR. Es importante que los parámetros "Num
Status Enq. Sent" y "Num Status msgs Rcvd" aumenten al mismo
ritmo, como es el caso del ejemplo. Los demás valores estarán
a cero o con valores bajos en condiciones normales.
hardy#show frame lmi
LMI Statistics for interface Serial0/0 (Frame Relay DTE) LMI TYPE = CCITT
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 3251 Num Status msgs Rcvd 3251
Num Update Status Rcvd 0 Num Status Timeouts 0
Para terminar veremos una interesante opción gracias a

la cual podemos practicar con el protocolo Frame Relay en
un entorno de laboratorio. Si disponemos de un router con
varias interfaces serie podemos configurarlo como un switch
Frame Relay. Para ello habilitaremos la conmutación FR con
la orden "frame-relay switching".
Configuraremos las interfaces como DCE con "frame-
relay intf-type dce" y pondremos la señal de reloj con
"clock rate" (no podremos completar esta tarea a no ser
que usemos cables DCE en las interfaces correspondientes).
A continuación definiremos los circuitos virtuales mediante
órdenes "frame-relay route", con lo que crearemos los
PVCs entre los distintos sitios.
NubeFrameRelay#configure terminal
NubeFrameRelay(config)# frame-relay switching
NubeFrameRelay(config)# interface Serial0
NubeFrameRelay(config-if)# description Conexión FR con sitio central - DLCI 100
NubeFrameRelay(config-if)# encapsulation frame-relay
NubeFrameRelay(config-if)# clock rate 125000
NubeFrameRelay(config-if)# frame-relay lmi-type cisco
NubeFrameRelay(config-if)# frame-relay intf-type dce
NubeFrameRelay(config-if)# frame-relay route 101 interface Serial1 100
NubeFrameRelay(config-if)# exit
NubeFrameRelay(config-if)# description Conexión FR con Sitio1 - DLCI 101
NubeFrameRelay(config-if)# description Conexión FR con Sitio 2 - DLCI 102
NubeFrameRelay(config)# end
159
4.3.4. RDSI
Algunos modelos de router Cisco tienen interfaces que
permiten la conexión con la Red Digital de Servicos Integrados
(RDSI). Las líneas RDSI se caracterizan frente a las líneas de
telefonía convencional por dar conectividad digital de extremo
a extremo. Al digitalizar el bucle local, eliminando el tramo
analógico entre el abonado y la red de comunicaciones, se
hacen innecesarias las conversiones analógico-digitales que
estos tramos acarrean. Las líneas RDSI permiten el transporte
simultáneo de voz y datos.
Las interfaces de acceso básico o interfaces BRI (Basic Access
Interface) proporcionan 2 canales a 64 Kbps (canales B) y un
canal de señalización fuera de banda a 16Kbps (canal D). Los
canales B proporcionan voz digital (PCM a 64Kbps), una (en
su momento) alta velocidad de datos, fax e incluso servicios
de vídeo de baja velocidad. El canal D proporciona señaliza-
ción y permite servicios que no precisan alta velocidad como
teletexto, conexiones de terminal o telemetría.
Nota: También existen interfaces de acceso primario (PRI)

que proporcionan 30 canales B y un canal D (lo que equivale
a un acceso E1 a 2048Mbps). Generalmente conectaremos el
router con un dispositivo convertidor proporcionado por el
proveedor del servicio (una unidad de servicio de datos o de
canal). Usaremos la orden "controller" para configurar
la controladora del primario. Los detalles de la configuración
de estas controladoras de líneas E1y T1 exceden el carácter
introductorio de este libro.
Las especificaciones de la RDSI definen una serie de equipos

y puntos de referencia que separan grupos de funciones (figura
4.9). Tenemos por un lado una serie de agrupaciones funcio-
nales: un ET1 es un dispositivo con interfaz RDSI nativa (un
ordenador, un teléfono digital), un ET2 es un dispositivo que
precisa de un adaptador de terminal (AT), la TR1 ("punto 1
de Terminación de Red") realiza funciones físicas, eléctricas
y de mantenimiento, la TR2 concentra y conmuta (realizando
funciones de enlace y de red) y un AT transforma las señales
de adaptadores no RDSI (como por ejemplo conectores V35,
EIA-232-E) en señales RDSI.
Por otro lado se definen los siguientes puntos de referencia:
R, entre un dispositivo no RDSI y un adaptador de terminal
(AT); S, una interfaz de terminal individual RDSI; T, equiva-
160
lente eléctricamente al punto S (de hecho algunas interfaces
RDSI se denominan BRI S/T) y U, que es el punto donde co-
mienza el bucle local entre el abonado y el conmutador (switch)
RDSI de la central.
Figura 4.9. Puntos de referencia de RDSI.
Las líneas RDSI son extremadamente versátiles: podemos

configurarlas para que establezcan conexiones punto a punto
dedicadas (normalmente con tarifas planas), para que esta-
blezcan conexiones bajo demanda en situaciones concretas
(DDR o Dial on Demand Routing) como por ejemplo para que
sirvan de respaldo de otra interfaz (backup interface) bien
porque haya fallado el enlace o porque la carga de tráfico
sea lo suficientemente alta como para hacer preciso un ancho
de banda adicional. También podemos configurar interfaces
RDSI capaces de devolver llamadas entrantes (Callback). En
este capítulo nos centramos en cómo configurar llamadas
bajo demanda básicas. Veremos cómo configurar interfaces
de backup más adelante.
Las interfaces RDSI vienen identificadas en los routers me-
diante las siglas ISDN (Integrated Service Digital Network) o BRI
(Basic Access Interface). Para configurar una interfaz RDSI debe
indicar en primer lugar el tipo de conmutador (switch) usado
en la central por el proveedor. Ejemplos de switches RDSI son
"basic-dms100" y "basic-net3". Al contratar el servicio le
161
indicarán qué conmutador debe configurar. Esta orden puede
ser configurada tanto en modo global (config) como en modo
interfaz (config-if).
isdn switch-type [tipo de switch del proveedor]
Recuerde que con "isdn switch-type ?" en modo con-

figuración puede consultar los distintos tipos de conmutador
RDSI que su IOS es capaz de reconocer.
Nota: Además de recabar información acerca del conmutador

RDSI debe saber que existen conmutadores como el DMS-100
que precisan que configuremos unos valores denominados
SPID. El proveedor nos proporcionará estos parámetros SPID
(uno por cada canal B de datos).
Hay una serie de pasos necesarios para establecer una lla-

mada bajo demanda: hay que indicar al router la ruta que debe
tomar para alcanzar el destino (a través de la interfaz RDSI),
debemos especificar qué tráfico será el que levante la llamada
(el tráfico de interés) y por supuesto debemos proporcionar
al router la información necesaria para que haga la llamada y
negocie con el router remoto la conexión.
Hay una serie de órdenes que hemos incluido en la confi-
guración para que ésta sea completa, pero que tocan aspectos
que todavía no hemos tratado. Por ejemplo, para indicar al
router que la ruta a tomar para alcanzar el destino es a través
de la interfaz RDSI usamos rutas estáticas, que veremos en
profundidad en el siguiente capítulo. Una ruta estática se es-
pecifica con la orden "ip route" seguida de la red a alcanzar
y la máquina a través de la cual se llega a ella. Así, la ruta:
ip route 150.150.0.0 255.255.0.0 172.49.3.1
significa que para alcanzar la red 150.150.0.0/16 (la LAN de

Sevilla) el router debe mandar los paquetes a la máquina
172.49.3.1 (la IP de la interfaz RDSI del router de Sevilla, que
forma una red con la interfaz RDSI local 172.49.3.2). Para espe-
cificar el tráfico de interés capaz de hacer la llamada usaremos
una orden "dialer-list" como:
dialer-list 1 protocol ip permit
que significa que el tráfico IP es capaz de "levantar" la lla-

mada. Una regla así, que "levanta" la llamada con cualquier
paquete IP, puede ser excesiva. Podemos especificar qué tráfico
puede disparar una llamada por medio de la orden "dialer-
162
list 1 protocol ip list" seguido de un número de lista
de acceso que permita y deniegue ciertos flujos. Por ejemplo,
la lista de acceso extendida 110 tiene dos reglas: la primera
impide (deny) que el tráfico de difusión (tráfico broadcast,
255.255.255.255) dispare la llamada. La segunda regla deja
pasar (permit) todo lo demás.
access-list 110 deny ip any 255.255.255.255 0.0.0.0
access-list 110 permit ip any any
dialer-list 1 protocol ip list 110
Tenga en cuenta que esta lista sólo influye en el tipo de

paquetes que pueden disparar la llamada. Una vez estable-
cida la conexión telefónica estas reglas no se comprueban y
las difusiones podrían atravesar el enlace y mantenerlo en
funcionamiento.Veremos las listas de acceso más adelante.
Para aplicar estas reglas en la interfaz RDSI usaremos la orden
"dialer-group":
interface BRI0
dialer-group 1
Para terminar debemos debemos proporcionar al router la

información necesaria para que haga la llamada y negocie con
el router remoto la conexión. Especificamos esta información
acerca del nombre e IP del router remoto junto con el teléfono
que permite establecer comunicación con el mismo mediante
la instrucción "dialer map":
dialer map ip 172.49.3.1 name SEVILLA broadcast 954123456
Vemos ahora como queda todo junto:

hostname MADRID
username SEVILLA password cisco
!
!
isdn switch-type basic-net3
interface BRI0
ip address 172.49.3.2 255.255.255.0
encapsulation ppp
dialer idle-timeout 300
dialer map ip 172.49.3.1 name SEVILLA broadcast 954123456
dialer-group 1
ppp authentication chap
!
! Consulte las rutas estáticas en el siguiente capítulo
!
ip route 150.150.0.0 255.255.0.0 172.49.3.1
163
!
! Definimos el tráfico "interesante"
! En este ejemplo dejamos que cualquier paquete IP
! levante la llamada. Eso puede ser excesivo.
!
Puede comprobar las conexiones activas en un momento

dado con la orden "sh isdn active":
Spade#sh isdn active
-------------------------------------------------------------
ISDN ACTIVE CALLS
-------------------------------------------------------------
History Table MaxLength = 100 entries
History Retain Timer = 15 Minutes
-------------------------------------------------------------
Call Calling Called Duration Remote Time until
Type Number Number Seconds Name Disconnect
-------------------------------------------------------------
In 911234567 577 SEVILLA
-------------------------------------------------------------
Puede examinar las últimas llamadas realizadas con la

orden "sh isdn history":
Spade#sh isdn history
-------------------------------------------------------------
ISDN CALL HISTORY
-------------------------------------------------------------
History Table MaxLength = 100 entries
History Retain Timer = 15 Minutes
-------------------------------------------------------------
Call Calling Called Duration Remote Time until
Type Number Number Seconds Name Disconnect
-------------------------------------------------------------
Out 911234567 2889 MADRID
-------------------------------------------------------------
Puede obtener más información de la llamada con la ins-

trucción "sh dialer":
Spade#sh dialer
BRI2 - dialer type = ISDN
Rotary group 1, priority = 0
Dial String Successes Failures Last called Last status
0 incoming call(s) have been screened.
BRI2: B-Channel 1
Idle timer (180 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Time until disconnect 179 secs
Connected to 931234567 (Brigid)
BRI2: B-Channel 2
Idle timer (180 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
164
En ocasiones podrá ver con esta última orden la razón de
la llamada (dial reason), generalmente el paquete que levantó
la llamada en la forma s=IP origen y d=IP destino. Esta infor-
mación puede resultar muy valiosa para determinar por qué
tienen lugar ciertas llamadas.
Nota: Ciertos fallos de configuración de las RDSI pueden
resultar caros. Por ejemplo, un error en las contraseñas CHAP
puede ser la causa de que un router llame continuamente a
otro intentando establecer una sesión RDSI y que éste último
le cuelgue reiteradamente al fallar la fase de autenticación.
Verifique periódicamente el LOG del router con "show
logg" y use las órdenes anteriores para verificar que no se
están realizando llamadas indebidas. Si nota cambios de ve-
locidad, actividad inusual en los indicadores luminosos (leds)
de las interfaces RDSI, etc…compruebe el estado de las líneas
RDSI. Recuerde: si no tiene una tarifa plana para la RDSI
puede llevarse un disgusto con la factura de la línea.
4.3.5. ADSL y xDSL

DSL (Digital Subscriber Line) es la denominación genérica
que recibe un conjunto de tecnologías que usan el ancho de
banda no utilizados por la voz en el par de cobre que conecta
el teléfono del abonado (subscriber) y la central telefónica (CO,
central office).
Figura 4.10. Puntos de referencia ADSL.
165
DSL es un enlace dedicado que da acceso de banda ancha
a través de un adaptador instalado en el domicilio del cliente.
En esta conexión directa entre el cliente y el proveedor, la voz
viene de un switch de voz de Clase 5 (local exchange), y los datos
de un DSLAM (DSL access multiplexer). La señal combinada
(voz y datos) viaja en el par de cobre hasta llegar al domicilio
del cliente donde se divide gracias a un filtro que separa las
frecuencias altas donde van los datos de las bajas (donde va
la voz convencional). Un router DSL proporciona una interfaz
local (NIC) a los equipos del cliente.
Nota: Encontrará mucha información acerca de xDSL en la

web del DSL Forum http://www.dslforum.org, el
consorcio encargado de promocionar la estandarización y uso
de los protocolos xDSL.
En el siguiente ejemplo vemos la configuración de un router

Cisco 877 con IP dinámica (el router negocia con el proveedor
ADSL para obtener una dirección IP con la orden "ip address
negotiated"). La interfaz Ethernet es un poco especial, al
tener este modelo un switch de 4 puertos agrupados bajo la
interfaz "Vlan1". La interfaz ADSL, sobre la que configuramos
los detalles a nivel físico (OSI capa 1) es una interfaz "ATM"
de tipo ADSLoPOTS (ADSL over Plain Old Susbcriber Line, o
ADSL sobre línea telefónica convencional). Los detalles de la
conexión a nivel de enlace los configuramos sobre la interfaz
lógica "Dialer1".
interface ATM0
mtu 1492
no ip address
no ip route-cache cef
no ip route-cache
no ip mroute-cache
no atm ilmi-keepalive
pvc 8/32
encapsulation aal5snap
protocol ip inarp
pppoe-client dial-pool-number 1
!
dsl operating-mode auto
!
interface Vlan1
ip address 10.0.0.2 255.255.255.0
ip nat inside
ip virtual-reassembly
!
166
interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap pap callin
ppp chap hostname usuario
ppp chap password contraseña
ppp pap sent-username usuario password contraseña
!
ip route 0.0.0.0 0.0.0.0 Dialer1
ip nat inside source list 1 interface Dialer1 overload
!
access-list 1 permit 10.0.0.0 0.0.0.255
Nota: En este ejemplo también hay una serie de instrucciones

para configurar la traducción de direcciones internas de forma
que la red privada interna tenga acceso a Internet mediante el
mecanismo NAT. Veremos NAT en detalle en el capítulo 6.
En los logs vemos como sincroniza:

*Mar 1 02:08:32.903: %LINK-3-UPDOWN: Interface ATM0, changed state to up
*Mar 1 02:08:33.903: %LINEPROTO-5-UPDOWN: Line protocol on Interface
ATM0, changed state to up
*Mar 1 02:08:45.183: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
*Mar 1 02:08:45.195: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
state to up
Y aquí vemos como al poco tiempo la interfaz ya tiene asig-

nada su dirección IP.
Router#show ip interfaces brief
Interface IP-Address OK? Method Status
Protocol
ATM0 unassigned YES NVRAM up up
Dialer1 82.40.1.1 YES IPCP up up
Vlan1 10.0.0.2 YES manual up
4.3.6. Cable y DOCSIS

DOCSIS son las siglas en inglés de Especificación de Interfaz
para Servicios de Datos sobre Cable (Data Over Cable Service
Interface Specification). La especificación actual va por la ver-
sión 2.0. DOCSIS define varios componentes: CM, CMTS,
BackOffice Services…
El CM (Cable Modem) es el dispositivo CPE que termina la
conexión en el lado cliente, modulando y demodulando las
167
señales hacia el CMTS (Cable Modem Termination System), el
dispositivo que modula la señal hacia el CM en el lado del
proveedor. Los Backoffice services proporcionan servicios
esenciales para el mantenimiento de la instalación: TFTP para
la subida y bajada de configuraciones a los CM, DHCP para
asignarles IP de forma dinámica, ToD para proporcionar ser-
vicios horarios.
Veamos un ejemplo. Los detalles de configuración de la
conexión cable se realizan sobre la interfaz "cable?modem0".
Su proveedor de cable le proporcionará los parámetros exactos
necesarios para establecer la conexión.
service times tamps debug uptime
service timestamps log uptime
no service password?encryption
!
hostname cableRouter
!
!
ip subnet?zero
no ip finger
!
interface Ethernet0
ip address 10.1.1.1 255.255.255.0
ip nat inside
!
interface cable?modem0
ip nat outside
cable?modem downstream saved channel 555000000 42 1
cable?modem mac?timer t2 80000
no cable?modem compliant bridge
!
ip default?gateway 172.16.30.1
ip nat inside source list 1 interface cable?modem0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.30.1
!
access?list 1 permit 10.1.1.0 0.0.0.255
!
line con 0
transport input none
line vty 0 4
password cisco
login
!
end
Comprobamos que la interfaz está levantada a nivel físico
y de enlace,
168
cableRouter#sh ip int brief
Interface IP?Address OK? Method Status Protocol
cable?modem0 172.16.30.20 YES unset up up
Y chequeamos los detalles de la tecnología.

cableRouter # show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 11 online 2287 0.25 5 0 10.1.1.25 0050.a366.2a23
Cable2/0/U0 12 online 2812 0.25 5 0 10.1.1.28 0001.a659.4b15
Cable2/0/U0 13 online 2810 -0.50 5 0 10.1.1.20 0030.a6f9.6cd9
Cable2/0/U0 14 online 2290 0.50 5 0 10.1.1.26 0050.7a66.2d21
Cable2/0/U0 15 online 2292 0.25 5 0 10.1.1.30 0050.73a6.1eb9
Cable2/0/U0 16 online 2815 0.00 5 0 10.1.1.27 0001.9a59.4f61
4.3.7. MPLS
El Multiprotocol Label Switching o MPLS es una tecnología de
conmutación de paquetes que utiliza etiquetas (labels) en lugar
de direcciones IP para tomar las decisiones de enrutamiento.
MPLS fue diseñado para proporcionar a los routers una mayor
velocidad evitando la inspección paquete a paquete tradicional.
Con MPLS el análisis de capa 3 se hace la primera vez que el
paquete accede la red MPLS, y en las siguientes ocasiones se
examina la etiqueta. Sobre MPLS se han desarrollado servi-
cios como Redes Privadas Virtuales (VPN - Virtual Private
Networking) y Calidad de Servicio (QoS - Quality of Service)
Nota: MPLS trabaja entre las capas 2 y 3 (Enlace y Red) del

modelo OSI. Es frecuente referirse al protocolo MPLS como
de capa 2 y medio.
Muy por encima, el proceso MPLS es el siguiente: el primer

router MPLS encontrado al acceder a la nube (o dominio)
MPLS examina la dirección IP del paquete y le añade una
etiqueta que determina el camino que el paquete va a seguir
dentro del dominio. A medida que los paquetes progresan a
lo largo del camino los routers MPLS examinan las etiquetas,
las reescriben y reenvían los paquetes de dispositivo a dispo-
sitivo hasta alcanzar un router en el borde de la nube a través
del cual se accede a la red destino. En este punto la etiqueta
MPLS se elimina y el paquete se entrega de nuevo al cliente.
A continuación pondremos nombres y apellidos a todos estos
elementos.
El router CE (Customer Edge) es el último router del cliente
antes de entrar en la red MPLS del proveedor. En este punto
169
el cliente proporciona sus rutas internas al proveedor, que
las recibe en el router PE (Provider Edge). En este router PE el
proveedor además de recibir el direccionamiento del cliente
añade o quita una etiqueta según entre o salga el tráfico de la
red MPLS. Dentro de la nube MPLS, sin conexión directa con
los clientes en el borde (Edge) están los routers P (Provider),
que no añaden ni quitan etiquetas a los paquetes, sino que los
reenvían tras reescribir las etiquetas.
Figura 4.11. Elementos MPLS.
Los routers P y PE son routers LSR (Label Switching Router):

un router LSR es cualquier router o switch que conmute en
función de las etiquetas (label switching). Los LSR reciben un
paquete etiquetado, reesciben la etiqueta con el nuevo destino
y reenvían el paquete por la interfaz adecuada.
Los routers LSR conforman un dominio MPLS. Dentro de
estos dominios los paquetes atraviesan unas rutas denomi-
nadas LSP (Label Switched Path). El primer router con el que se
encuentra un paquete al acceder al dominio MPLS es el ingress
router. Este router es el responsable de añadir al paquete la eti-
queta MPLS. El router por el que el paquete sale del dominio
MPLS es el egress router, que elimina la etiqueta MPLS del pa-
quete antes de remitirlo al destino final.
Reescribamos de nuevo el proceso MPLS poniendo los
nombres del modelo: Los routers capaces de etiquetar paquetes
conforme al protocolo MPLS son los routers LSR y en su con-
junto conforman un dominio MPLS. El ingress router, el primer
router PE encontrado al acceder al dominio MPLS, examina la
dirección IP del paquete y le añade una etiqueta que determina
el path que el paquete va a seguir dentro del dominio. A me-
dida que los paquetes progresan a lo largo del path los routers
170
P examinan las etiquetas, las reescriben y reenvían los paquetes
de dispositivo a dispositivo hasta alcanzar otro router PE, el
egress router, a través del cual se sale del dominio y se accede
a la red destino. En este punto la etiqueta MPLS se elimina y
el paquete se entrega de nuevo al cliente.
Un concepto del modelo MPLS es el de subida y bajada
(Upstream y Downstream): los paquetes de datos destinados a
una red concreta "bajan" hacia ella (downstream). Las actuali-
zaciones de los protocolos de enrutamiento y los protocolos
de etiquetado "suben" (upstream).
Los routers MPLS Cisco necesitan ejecutar el proceso CEF
(Cisco Express Forwarding). CEF construye dos tablas: la tabla
FIB (Forwarding Information Base) y la tabla de adyacencias. La
tabla FIB mantiene la IP del siguiente salto para cada entrada en
la tabla de rutas. La tabla de adyacencia mantiene información
de enlace (capa 2) para cada entrada de la tabla FIB, evitando
resoluciones ARP para cada dirección IP. CEF une las direc-
ciones IP de siguiente salto con las direcciones físicas (MAC)
de la interfaz correspondiente, lo que permite conmutación a
capa 3 (layer 3 switching).
Una configuración elemental de MPLS consiste en habilitar
el protocolo CEF (Cisco Express Forwarding) mediante la orden
global "ip cef" y a continuación habilitando el proceso MPLS
mediante la orden "mpls"
! Habilita el Cisco Express Forwarding
ip cef
!
! Arranca el proceso MPLS en la interfaz, IOS 12.x
interface fastethernet0/1
mpls ip
En las versiones de IOS anteriores a la 12.0 el comando para

habilitar MPLS en una interfaz era "tag-switching"
! Arranca el proceso MPLS en la interfaz, versiones IOS 11.x
interface fastethernet0/1
tag-switching ip
Una buena forma de migrar una red a MPLS consiste en ir

habilitando el protocolo de de forma progresiva, de dos en dos
routers, empezando por el núcleo de la red y expandiendose
a lo largo de los paths entre routers adyacentes. A cada paso
vamos definiendo nuevos routers ingress y egress.
Para verificar la operación MPLS usamos las órdenes "show
mpls interfaces" que muestra qué interfaces ejecutan el
protocolo MPLS,
171
router# show mpls interfaces
Interface IP Tunnel Operational
Ethernet0/1/1 Yes (tdp) No No
Ethernet0/1/2 Yes (tdp) No No
Ethernet0/1/3 Yes (tdp) Yes Yes
POS2/0/0 Yes (tdp) No No
ATM0/0.1 Yes (tdp) No No (ATM labels)
ATM1/0.1 Yes (ldp) No Yes (ATM labels)
y "show mpls forwarding-table", que muestra el con-

tenido de la tabla de reenvío MPLS.
Router# show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
26 Untagged 10.1.0.0/16 0 Et0/1/1 192.168.32.4

28 1/30 10.2.0.0/16 0 AT0/0.1 point2point
29 Pop tag 10.3.0.0/16 0 Hs5/0 point2point
En la salida "show mpls forwarding-table"cvemos

las etiquetas locales (local tag) y de salida (outgoing tag). La
"outgoing tag" es la etiqueta asignada por el router que está a
continuación. Puede ser "untagged" o "pop". "Untagged" significa
que no hay etiqueta para el destino o que la etiqueta no está
disponible. "Pop" significa que el siguiente salto anuncia una
etiqueta nula que hace que el router la descarte.
Terminamos esta sección mencionando una de las carac-
terísticas más sobresalientes de MPLS, la posibilidad de crear
redes privadas virtuales o MPLS VPN. Ello nos permitirá crear
VPNs perfectamente separadas dentro de un mismo dominio
MPLS, cada una de las cuales es vista por los clientes como
una intranet privada. Dado que para configurar los distintos
routers que componen un dominio MPLS sobre el que se
crean VPNs es preciso hacer uso de conceptos que todavía no
hemos visto tales como routing interior, exterior y listas de
acceso, dejaremos para el apéndice final la elaboración de las
configuraciones de los routers VPN sobre MPLS del siguiente
ejemplo, (figura4.12).
4.4. Interfaces Lógicas

En la tabla 4.2 vimos como algunas interfaces del router
eran clasificadas como virtuales o lógicas. Para terminar con la
presentación de las principales tipos de interfaces vemos en este
apartado las interfaces virtuales. Estas interfaces son creadas
mediante el uso de recursos software, y no se corresponden
con interfaces físicas del router.
172
Figura 4.12. MPLS VPN.
4.4.1. Terminales Virtuales (VTY)

Las conexiones VTY (Virtual Terminal) son las conexiones
lógicas que el router ofrece para conectarnos al mismo. Cuando
desde la red queremos establecer una sesión contra el router
vía telnet, SSH o rlogin, el router arranca un proceso EXEC que
ofrece un intérprete de comandos para servir esa conexión.
Las terminales virtuales no están asociadas a ningún enlace
físico específico. Las VTY quedan habilitadas una vez que han
sido configuradas. Si no lo están, las conexiones lógicas hacia
el router son rechazadas. Conviene configurar todas las líneas
VTY de la misma manera, dado que no tenemos control acerca
de a cuál de los terminales virtuales accederemos.
Con la orden "show line" se muestran las líneas dispo-
nibles en un router determinado. La orden "show user all"
muestra qué usuarios están conectados y por qué línea:
Sagan#sh user all
Line User Host(s) Idle Location
0 con 0 00:00:00 Edificio 1 Planta 3
1 aux 0 00:00:00
* 2 vty 0 antonio idle 00:00:00 10.0.0.2
3 vty 1 00:00:00
4 vty 2 00:00:00
5 vty 3 00:00:00
6 vty 4 00:00:00
173
Para configurar un router para que se pueda acceder vía
telnet, usamos la orden "line vty":
Router(config-line)# line vty 0 ?
<1-4> Last Line Number
Router(config-line)# line vty 0 4
Router(config-line)# password abc123
Router(config-line)# login
Según la versión de IOS puede verse obligado a configurar

una contraseña con la orden "password" antes de configurar
la línea con "login"
2600(config-line)# login
% Login disabled on line until 'password' i2
s set
Si intentamos acceder a un router cuyas terminales están

habilitadas ("login") pero que no tienen obtendremos un
error indicándolo:
#telnet Router
Trying Router (10.0.0.1)…Open
Password required, but none set
[Connection to Router closed by foreign host]
En una configuración más completa seleccionamos todas las

líneas disponibles ("line vty 0 4") y las configuramos para
que acepten conexiones ("login") de cualquier tipo ("trans-
port input all"):
Router(config-line)# login
Router(config-line)# password abc123
Router(config-line)# transport input all
Router(config-line)# exit
Pese a fijar una contraseña se trata de una configuración

bastante poco segura. Podemos aumentar la seguridad del
dispositivo fijando un tiempo de vida de la sesión en caso de
inactividad de por ejemplo 30 minutos "exec-timeout 30
0". Aunque no hemos visto todavía las listas de acceso (que
presentaremos en el capítulo 6), en el ejemplo haremos uso de
una mediante las órdenes "access-list" y "access-class"
para limitar el acceso al router al equipo cuya dirección IP sea
la 10.1.1.1
Router(config-line)# exec-timeout 30 0
Router(config-line)# access-class 10 in
Router(config)# access-list 10 permit host 10.1.1.1
174
Si deshabilitamos telnet y forzamos el uso de un protocolo
seguro como ssh y además registramos los intentos de acceso
en un servidor syslog server estaremos aumentando notable-
mente nuestra seguridad. Veremos todo ello en el capítulo 6,
dedicado a la seguridad.
Terminamos indicando que la orden "line vty" nos per-
mite configurar más líneas de las que existen por defecto.
Por defecto la mayoría de los router proporcionan 5 líneas.
En ocasiones (especialmente en laboratorios y entornos de
pruebas) se precisa un número mayor de línas para que todos
los usuarios puedan acceder (a costa de usar recursos adionales
del sistema). Con la siguiente orden aumentamos el rango de
puertos VTY de 5 a 10:
4.4.2. Loopback Interface

Se trata de un tipo de interfaz lógica o virtual que una vez
creada permanece activa y no cae como puede hacerlo una
interfaz física. Para ciertas aplicaciones (como el enrutamiento
OSPF o para gestión SNMP) el que estas interfaces perma-
nezcan siempre activas resulta muy útil.
Sagan(config)# interface Loopback 0
Sagan(config-if)# ip address 10.0.0.1 255.255.255.255
Estas interfaces encuentran diversos usos. A veces se usan

en las conexiones serie punto a punto junto con la orden
"unnumbered" para ahorrar direcciones IP. Algunos proto-
colos de enrutamiento como OSPF y BGP, que veremos en
el siguiente capítulo, identifican los routers con un valor o
ID que tiene que ser la dirección de un enlace que siempre
esté "arriba". Finalmente, estas interfaces pueden servir para
identificar un router. Para saber si un router está activo, se
puede hacer ping o telnet a la IP de una interfaz, pero esa
interfaz puede estar caida por problemas de la conexión y
sin embargo el router estar funcionando. Configurando una
interfaz loopback con una dirección única y haciendo telnet
o ping a la misma nos aseguramos la respuesta con inde-
pendencia de por qué interfaz hayamos alcanzado el router.
Este ultimo uso hace las interfaces loopback especialmente
interesantes para ser usadas junto con software de gestión.
Estos programas pueden chequear si el router está "vivo"
"preguntando" por la interfaz loopback.
175
4.4.3. Null Interface
Se trata de una interfaz lógica a la que enviar los datos que
queramos descartar. Veremos en el próximo capítulo que la
forma básica de proporcionar información de enrutamiento
consiste en usar rutas estáticas. La forma de configurar una
ruta estática es mediante la orden "ip route <red destino>
<máscara> <interfaz/dirección salto siguiente>".
Pues bien, una forma directa (aunque poco sutil) de impedir el
tráfico hacia una red específica consiste en dirigir el tráfico con
ese destino a la interfaz nula, como en el siguiente ejemplo:
Sagan(config)# ip route 9.0.0.0 255.0.0.0 Null 0
Todo lo que vaya con destino 9.0.0.0/8 será descartado.

Frente a otras aproximaciones más sofisticadas para el tra-
tamiento de tráfico (listas de acceso estándar, extendidas o
reflexivas, enrutamiento basado en normas, etc…) ésta en
concreto presenta la ventaja de usar muy pocos recursos del
sistema, permitiendo ahorrar preciosos ciclos de procesa-
miento (CPU).
Nota: Las interfaces Null son interfaces "papelera", pero

no permita que la analogía le confunda: un paquete en-
viado a null es un paquete perdido. Los usuarios de UNIX
reconocerán inmediatamente el concepto y lo asociarán al
dispositivo /dev/null.
Esta interface sólo acepta un comando, "no ip unreacha-

bles". Por defecto, si un router recibe un paquete no broadcast,
destinado a si mismo, de un protocolo desconocido, responde
al origen con un mensaje ICMP tipo "Unreachable". Si el router
recibe un paquete que no es capaz de entregar al destino por
que desconoce la red, responde al origen con un paquete ICMP
"Host Unreachable".
Sagan(config)# interface null 0
Sagan(config.if)# no ip unreachables
La orden "no ip unreachables" deshabilita a nivel de

interfaz el envío de paquetes ICMP "unreachable". Para volver
a configurar en la interfaz este tipo de respuesta, usaremos la
orden "ip unreachables".
La interfaz nula también se usa como mecanismo para evitar
bucles de enrutamiento al sumarizar direcciones. Veremos
ejemplos en el próximo capítulo.
176
4.4.4. Interfaces de túnel (tunnel)
Existen ocasiones en las cuales tenemos que enviar datos de
un protocolo que no tiene información suficiente para ser trans-
portado (típicamente le falta información de red). Podemos
transportar este tipo de paquetes a través de "túneles IP"
creados entre el emisor y el receptor y encapsular los datos en
otro protocolo (como el GRE, Generic Router Encapsulation) para
proceder a su envío a través del túnel creado por esta vía.
Seleccionaremos una interfaz Túnel mediante la orden
"interface Tunnel [0-2147483647]". De las opciones
de configuración disponibles, la más interesante es la propia
orden "tunnel":
Sagan(config)# interface Tunnel 0
Sagan(config-if)# tunnel ?
Checksum comprueba integridad de paquetes

destination destino del túnel
key identificador del túnel
mode método de encapsulación del túnel
sequence-datagrams descarta paquetes desordenados
source orígen del túnel
Vemos que la orden "tunnel" permite configurar as-

pectos tales como el origen, destino, clave y comprobación de
errores de los paquetes que viajan a través del túnel. El modo
de encapsulación se especifica con la orden "tunnel mode"
seguida del método de encapsulación. Ambos extremos del
túnel deben compartir el método de encapsulado para que el
túnel funcione.
Sagan(config-if)# tunnel mode ?
Aurp encapsulación AppleTalk
Cayman encapsulación TunnelTalk (AppleTalk )
dvmrp Túnel DVMRP multicast
eon Túnel EON compatible CLNS
gre Protocolo de encapsulación genérico
ipip IP sobre IP
iptalk encapsulación Apple IPTalk
nos IP sobre IP (compatible KA9Q/NOS)
Veamos un ejemplo sencillo de configuración de un

túnel:
Sagan(config)# interface Tunnel10
Sagan(config.if)# tunnel source Serial0
Sagan(config.if)# tunnel destination 172.16.0.1
Sagan(config.if)# tunnel mode gre ip
177
4.5. Interfaces Especiales
4.5.1. El Puerto de Consola (CON)
Todos los routers poseen un puerto de consola (con 0) que
sirve para conectarse directamente al router. Necesitaremos
para conectarnos a través de este puerto un cable rollover. La
configuración por defecto del puerto de consola es terminal
VT100, velocidad 9600 bps, 8 bits de datos, sin paridad y 1
bit de parada. Podemos cambiar estos parámetros con las ór-
denes de línea "terminal", "speed", "databits", "parity"
y "stopbits", pero tendremos que cambiar la configuración
del programa de emulación de terminal de forma acorde para
tener acceso al router vía el puerto de consola.
En el siguiente ejemplo de configuración del puerto de
consola definimos y controlamos el acceso al router por este
puerto:
router#config terminal
router(config)# service linenumber
router(config)# line console 0
router(config-line)# location Edificio-1 Sala 3.2
router(config-line)# exec-timeout 30 0
router(config-line)# login
Mediante la orden "location" identificamos la situación

física del dispositivo, El comando "service linenumber" in-
dica al router que muestre dicha información a los usuarios al
conectarse. El comando "timeout" indica que se desconecte
la sesión a los 30 minutos de inactividad. También podemos
configurar un usuario y contraseña locales,
router(config)# username antonio password abc123
router(config)# line console 0
router(config-line)# login local
4.5.2. El Puerto Auxiliar (AUX)

El puerto auxiliar es un puerto asíncrono de baja velocidad.
Puede dar respaldo a otras líneas o al menos proporcionar
una vía de acceso al router para los casos en los que el enlace
principal esté caído. Es práctica habitual en algunas empresas
tener un módem en las delegaciones que se conecte al router
en caso de avería.
No tiene el rendimiento de una línea asíncrona estándar,
y su velocidad suele estar limitada sobre todo en los modelos
178
antíguos. Usa I/O por caracteres, lo que sobrecarga la CPU si
se usa de forma contínua.
El siguiente ejemplo muestra como configurar el puerto
AUX como respaldo de una conexión serie. Si la conexión
punto a punto establecida por dicha interfaz se cae, el router
se conectará usando el modem conectado al puerto AUX.
La línea AUX equivale a la interfaz async 4. Declaramos
la interfaz async 4 como la de respaldo de la interfaz serie
con la orden "backup interface async 4", y con la orden
"backup delay 20 3" indicamos que levante la conexión a los
20 segundos de caer la interfaz serie, y que la desconecte a los
3 segundos de restaurarse las comunicaciones:
interface serial0
ip address 10.1.1.1 255.255.255.0
backup interface async 4
backup delay 20 3
interface async 4
ip address 10.1.1.2 255.255.255.0
dialer in-band
dialer string 91-810-1234
dialer-group 1
async dynamic routing
Definimos el tráfico interesante capaz de disparar la llamada

medieçante la orden "dialer-list" (en este caso cualquier
paquete IP). El "1" del "dialer-list" se corresponde con el
"1" del "dialer-group" de la configuración de la interfaz
async4.
Para terminar, definimos el script del modem con "chat-
script" y configuramos el puerto AUX para que lo use
chat-script script1 "atdt 91-810-1234" timeout 60
"connected"
!
line aux 0
modem chat-script script1
modem inout
4.5.3. Interfaces de voz

Las interfaces de voz permiten usar la red de datos para
transmitir simultáneamente tráfico de voz y datos. Aplicaciones
típicas de voz son las llamadas telefónicas o los faxes. Los
routers que pueden equipar tarjetas de voz (VIC, de Voice
179
Interface Card) suelen ser modulares. Ejemplos de routers mo-
dulares con capacidad para aceptar módulos de voz son las
series 1700, 2600 y 3600.
Lo que permite que las tarjetas de voz realicen sus funciones
son los códec (codificadores-decodificadores). Los códec son
procesadores digitales de señal (DSP, de digital signal proces-
sors). Estos DSP permiten que el ancho de banda necesario para
la transmisión de un canal de voz (64Kbps mediante técnicas
tradicionales como la norma PCM G.711 a 8000 muestras/
segundo) pueda reducirse a menos de 8Kbps (mediante algo-
ritmos como el CELP, basado en técnicas de predicción lineal
y codificación vectorial).
Tabla 4.4. Puertos analógicos de voz.

Puertos FXS (Foreign Permiten la conexión directa
eXchange Station) con un teléfono estándar, un
fax, etc… Sus puertos son de
color gris.
Puertos E&M (Ear&Mouth) Conectan llamadas remotas con
una centralita (PBX) local. Sus
puertos son de color marrón.
Puertos FXO (Foreign Conectan llamadas locales con
una red telefónica o con una
centralita (PBX) sin soporte
E&M. Sus puertos son de color

rosa.
Tabla 4.5. Puertos RDSI.
Puertos PRI Utilizado en las centrales para conectar

con la PBX, soporta un alto número de
canales.
Puertos BRI Utilizado en las oficinas para conectar con
la PBX con pocos canales.
La identificación de los puertos de voz sigue el esquema

slot del router/slot de voz/puerto de voz, mediante la orden
port "port 2/0/0".
Aunque configurar dos routers para que permitan llamadas
de voz entre ellos no es una tarea compleja, la configuración de
una red de voz no es una tarea trivial, involucrando aspectos
180
avanzados de configuración y diseño: la voz tiene que transmi-
tirse en tiempo real y la calidad de la recepción es fácilmente
perceptible por el receptor. Factores que no afectan de forma
perceptible a otros tipos de tráfico, como son los retardos,
en el caso de la voz hacen aparecer efectos indeseables como
son el eco, ruido, etc… En muchos casos el encargado de im-
plementar una red de este tipo tendrá que "pelearse"con las
peculiaridades específicas de la centralita de voz (PBX) con la
que tenga que conectar, etc…
4.5.4. Puertos asíncronos (TTY)

Las líneas asíncronas se corresponden con las interfaces
asíncronas. Una interfaz asíncrona que incluyen todos los
routers es la correspondiente al puerto auxiliar (aux 0). Existen
routers de acceso (como los clásicos Cisco 2509 y 2511 o el
2610XM-16TS) que proporcionan 8 o 16 puertos asíncronos.
Veamos cómo hacer uso de estos puertos. En primer lugar
declaramos la secuencia de establecimiento por medio de co-
mandos estándar AT Hayes del módem.
chat-script marca "" "at" "OK" "atdt\T" TIMEOUT 45 "CONNECT"
En la interfaz asíncrona configuramos los aspectos lógicos:

dirección IP, protocolo ppp para encapsular a capa 2, informa-
ción de la llamada…
interface Async1
ip address 10.0.0.1 255.255.255.252
encapsulation ppp
ppp authentication chap
dialer map ip 10.0.0.2 name PARKER modem-script marca broadcast 918110065
y en la línea que corresponde a la interfaz asíncrona configu-

ramos los parámetros hardware: aplicamos el chat-script confi-
gurado antes, permitimos llamar y recibir (In/Out), aceptamos
todos los protocolos para conectar, fijamos las velocidades y
finalmente dejamos el control de flujo al módem:
line 1
script dialer marca
modem InOut
transport input all
rxspeed 38400
txspeed 38400
flowcontrol hardware
181
5
Protocolos de Enrutamiento
En este capítulo profundizamos en la función principal de

un router: el enrutamiento. En primer lugar presentamos los
conceptos generales del routing, así como varias formas de
clasificar los protocolos de enrutamiento. Después veremos
las principales técnicas mediante las cuales los routers evitan
los problemas más frecuentes que se pueden presentar, para
continuar examinando los conceptos y forma de configurar de
algunos de los principales protocolos de enrutamiento (RIP,
EIGRP, OSPF y BGP). Terminamos viendo los mapas de rutas
y otros mecanismos que nos permitirán ejercer un control más
preciso sobre los procesos de enrutamiento dinámico.
5.1. Conceptos básicos

del enrutamiento
Los routers se dedican a dirigir la información hacia su
destino. Para encaminar los paquetes de datos los routers ne-
cesitan información acerca de las rutas existentes para alcanzar
los distintos destinos. Esta información puede configurarse es-
táticamente en los routers, pero esta opción deja de ser práctica
cuando las redes no son pequeñas. Además, cuando las redes
configuradas estáticamente cambian o fallan, y antes o después
lo hacen, dependen de la reprogramación manual para seguir
funcionando. La segunda opción consiste en dejar que los routers
dialoguen entre sí e intercambien la información que conocen.
A los protocolos que definen el conjunto de reglas y convenios
que posibilitan el intercambio de información acerca de las rutas
existentes se les denomina protocolos de enrutamiento.
183
El router examina la cabecera de los paquetes que le llegan,
donde además de otros datos se encuentra almacenada la di-
rección del destinatario. Esta dirección está dividida en dos
partes: la primera parte identifica la red y la segunda parte
una máquina concreta dentro de esa red. El router extrae de
la dirección de destino la parte correspondiente a la red y la
compara con su tabla de rutas para determinar hacia dónde
mandar el paquete. En la tabla de rutas están almacenadas
las redes que el router conoce junto con la información acerca
del siguiente salto o "next hop" al que reenviar el paquete para
acercarlo a su destino.
Esta forma de trabajar es distinta a la usada por los switches,
que almacenan en una tabla la información acerca de cada má-
quina que aprenden. En la tabla de rutas el router almacena
información acerca de las redes que conoce junto con la direc-
ción del siguiente router en el camino hacia las mismas.
Nota: Decíamos antes que el router separa las direcciones en

dos partes, una de red y otra de máquina o host. Para saber
qué parte de la dirección corresponde a la red y qué parte al
host, el router usa las "máscaras" de red que acompañan a las
direcciones. Las máscaras son números binarios de la misma
longitud que las direcciones IP (32 bits en IP versión 4) que
contienen unos en la parte de red y ceros en la parte de host.
En el Capítulo 2 se repasa el protocolo TCP/IP.
Al intentar mandar un paquete a su destino pueden darse

dos situaciones: que el router tenga información acerca de la red
a la que van destinados los paquetes porque esté directamente
conectado a esa red o que necesite enviar los paquetes a otro
dispositivo, bien por que el administrador haya indicado que
ésa es la ruta a seguir o porque ese dispositivo haya anunciado
que conoce cómo alcanzar la red de destino.
En el primer caso, cuando el paquete va dirigido a una red
a la que el router se encuentra directamente conectado, el en-
caminamiento de la información es resuelto por la tecnología
específica de la red. Concretamente el router consultará otra
tabla, la tabla de resolución de direcciones (tabla ARP, Address
Resolution Protocol). En esta tabla se almacenan las direcciones
de nivel 3 de las máquinas (direcciones IP completas) junto con
las direcciones de nivel 2 de esas mismas máquinas (direcciones
MAC). Si el router no encuentra en la tabla ARP una entrada
para la IP que busca generará una petición ARP, consistente
en difundir un paquete especial en la red local para que la
184
máquina con la IP no encontrada conteste con su MAC. La
respuesta será incorporada a la tabla ARP y usada para enca-
minar la información a la máquina destino.
Nota: Puede consultar la tabla MAC del router con la orden

"show arp".
En los restantes casos el router deberá hacer uso de la in-

formación almacenada en la tabla de rutas para encaminar los
paquetes hacia su destino. Veamos qué contiene exactamente
una tabla de rutas.
5.1.1. La tabla de rutas

En el núcleo de todos los procesos del router se encuentra la
tabla de rutas, la base de datos en la que se almacena la infor-
mación de las redes conocidas, junto con las vías para llegar a
ellas y los costes que tienen esos caminos. Ya vimos en el primer
capítulo el aspecto de una tabla de rutas. A continuación exa-
minamos cada uno de los campos que la componen:
Alan#show ip route
Codes: C – connected,S - static,I - IGRP,R - RIP, M – mobile, B - BGP
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
Gateway of last resort is 10.0.0.100 to network 0.0.0.0

R 192.168.1.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
R 192.168.2.0/24 [120/2] via 172.16.0.2, 00:00:04, Serial0
R 192.168.3.0/24 [120/2] via 10.0.0.2, 00:00:16, Ethernet0
[120/2] via 172.16.0.2, 00:00:04,
Serial0
R 192.168.4.0/24 [120/1] via 10.0.0.2, 00:00:16, Ethernet0
R 192.168.5.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
R 192.168.6.0/24 [120/2] via 10.0.0.2, 00:00:17, Ethernet0
R 192.168.7.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
S* 0.0.0.0/0 [1/0] via 10.0.0.100
Tomemos una línea cualquiera:

R 192.168.5.0/24 [120/1] via 172.16.0.2, 00:00:04, Serial0
La "R" indica que el router ha aprendido esta ruta mediante

el protocolo de enrutamiento dinámico RIP, tal como podemos
185
comprobar en la leyenda que se imprime antes de la tabla
mostrando los posibles valores que puede tomar la primera
columna ("C" – directamente conectado, "S" – ruta estática,
"R" - RIP, "B" – BGP, "D" - EIGRP, "O" – OSPF, etc...). Después
aparece la red y la máscara a la que se refiere la línea. A conti-
nuación vienen dos números entre corchetes: el primer número
es la distancia administrativa para esta ruta (120 para RIP, tabla
5.1). El segundo número entre corchetes es la distancia a la
que se encuentra la red. Para RIP esta distancia es el número
de routers que hay que atravesar hasta llegar al destino, un
"salto" en este caso. La dirección que aparece después de la
palabra "via" es la del router que ha pasado esta ruta. Viene a
continuación el tiempo transcurrido desde que se recibió esta
información y finalmente se muestra la interfaz por la cual se
alcanza el router que actúa de "siguiente salto".
Una entrada interesante es la siguiente:
R 192.168.3.0/24 [120/2] via 10.0.0.2, 00:00:16, Ethernet0
[120/2] via 172.16.0.2, 00:00:04, Serial0
Esta doble entrada muestra que el router conoce cómo al-

canzar la red 192.168.3.0/24 de dos formas. Para el protocolo
en enrutamiento RIP ambas rutas son equivalentes dado que
tienen la misma métrica: la red está a la misma distancia me-
dida en saltos.
Las líneas "S* 0.0.0.0/0 [1/0] via 10.0.0.100" y "Gateway of last
resort is 10.0.0.100 to network 0.0.0.0" indican lo mismo: que se
ha configurado una ruta estática (S) que es la ruta por defecto
(*) que tomarán los paquetes cuyo destino no venga especifi-
cado en el resto de entradas de la tabla. Es la ruta usada como
último recurso ("Gateway of last resort"), en nuestro ejemplo la
máquina 10.0.0.100, seguramente la dirección de otro router
conectado con el nuestro a través de la red local.
5.1.2. Convergencia
La convergencia es el objetivo principal de todos los pro-
tocolos de enrutamiento. Cuando un conjunto de routers
converge significa que todos sus elementos se han puesto de
acuerdo y reflejan la situación real del entorno de red donde se
encuentran. La velocidad con la que los protocolos convergen
después de un cambio es una buena medida de la eficacia del
protocolo de enrutamiento.
Pueden darse casos en los que la topología o los costes
de los enlaces no se mantengan estables. Si los costes de los
186
enlaces son función del tráfico, y éste función de las rutas
elegidas, pueden crearse situaciones inestables en las que la
convergencia no sea posible. Los casos más extremos son los
bucles, en los que los paquetes quedan atrapados en círculos
cerrados (routing loops).
5.1.3. Métrica
Existen distintos algoritmos que resuelven el problema
del encaminamiento, y cada uno termina convergiendo en
una representación de la red diferente en función de las mé-
tricas que utilizan. Las métricas más utilizadas para calibrar
la "bondad" de las distintas alternativas para alcanzar una red
de destino son el número de saltos necesarios para llegar a la
misma, la fiabilidad de los enlaces que componen la ruta así
como la velocidad, retardo, ancho de banda, carga y coste de
los distintos enlaces.
5.1.4. Distancia administrativa

La distancia administrativa es una medida de la confianza
otorgada a cada fuente de información de enrutamiento. Cada
protocolo de enrutamiento lleva asociado una distancia ad-
ministrativa. Valores más bajos indican mayor fiabilidad. Un
router puede ejecutar varios protocolos de enrutamiento a la
vez, obteniendo información de una red por varias fuentes
(RIP, EIGRP, OSPF...). En estos casos usará la ruta que provenga
de la fuente con menor distancia administrativa. La tabla 5.1
muestra las distancias administrativas de los protocolos de
enrutamiento.
Tabla 5.1. Distancias administrativas.

Fuente de información Distancia administrativa
por defecto
Interfaz directamente conectada 0

Ruta estática 1
Resumen EIGRP 5
BGP externo 20
EIGRP interno 90
IGRP 100
187
por defecto
OSPF 110
IS-IS 115
RIP 120
EIGRP externo 170
BGP interno 200
Desconocido. Red inalcanzable. 255
5.1.5. Tipos de enrutamiento

Vemos en este apartado varias clasificaciones posibles de
los protocolos de enrutamiento existentes.
Estático o dinámico
Existen dos formas básicas de enrutamiento: estático y
dinámico. Las rutas estáticas se configuran manualmente en
el router y dirigen los paquetes con un destino especificado a
puertos predeterminados. Las ventajas de esta aproximación
son la seguridad, el ahorro de ancho de banda que supone el no
intercambiar información de enrutamiento y la poca memoria
que precisan. Su inconveniente radica fundamentalmente en
que si un enlace de la red falla o la estructura de la misma
cambia el administrador debe volver a programar los routers
de acuerdo con los cambios.
Los protocolos de enrutamiento dinámico son utilizados
por los routers para descubrir automáticamente nuevas rutas.
Estos protocolos permiten a los administradores dejar que la
red se regule de una forma más automática, pero al precio de un
mayor consumo de ancho de banda y potencia de procesador
en tareas de adquisición y mantenimiento de información de
enrutamiento.
Interno o externo
Otra clasificación de los protocolos de encaminamiento
puede realizarse en función de si son interiores (actúan dentro
de un sistema autónomo) o exteriores (conectan sistemas au-
tónomos).
Un sistema autónomo (AS) es un conjunto de routers que
intercambian información de redes mediante un protocolo de
188
enrutamiento común y que generalmente son administrados
por una misma entidad. Los sistemas autónomos poseen un
identificador numérico que es asignado por el RIPE-NCC
(Réseaux IP Européens Network Coordination Centre) para la
zona de Europa, por el ARIN (American Registry for Internet
Numbers) para América, Caribe y África y por el APNIC (Asia
Pacific Network Information Centre) para los países del Pacífico
asiático.
Nota: Puede encontrar enlaces con todas estas organizaciones

en la página Web de la IANA (Internet Assigned Numbers
Authority) en la dirección http://www.iana.org.
Los protocolos internos (IGP, Interior Gateway Protocol)

permiten el intercambio de información dentro de un sistema
autónomo. Ejemplos de protocolos internos son RIP (Routing
Information Protocol), RIPv2 (RIP version 2), IGRP (Inter-Gateway
Routing Protocol), EIGRP (Enhanced IGRP) y OSPF (Open Shortest
Path First).
Los protocolos externos (EGP, Exterior Gateway Protocol)
interconectan sistemas autónomos. El protocolo de enru-
tamiento externo por excelencia es BGPv4 (Border Gateway
Protocol, version 4).
Figura 5.1. Sistemas Autónomos.
189
En la figura 5.1 vemos dos dominios de routing, AS 65005
and AS 65010, y una región superpuesta que muestra la inter-
conexión en la frontera entre ambos dominios. Cada dominio
de routing es un sistema autónomo o AS. Cada AS cae bajo la
autoridad administrativa única. El AS 65005 podría usar in-
ternamente EIGRP como protocolo de routing, mientras que
el AS 65010 podría estar utilizando OSPF. Ambos dominios se
comunican mediante BGPv4.
En el siguiente apartado veremos las características y formas
de configurar de cada uno de estos protocolos.
Por vector de distancia o por estado del enlace.

Una tercera clasificación de los protocolos de enrutamiento
puede hacerse en función del algoritmo que utilizan. Hay dos
grandes categorías de algoritmos de enrutamiento: de vector
de distancia (distance vector) y de estado del enlace (link state).
También existen algoritmos híbridos, que combinan ambos
sistemas.
Los protocolos basados en el algoritmo de vector de dis-
tancia usan el algoritmo Bellman-Ford, mediante el cual cada
router anuncia las mejores rutas hacia todos los destinos co-
nocidos desde su propio punto de vista, a cada uno de sus
vecinos. A los enlaces entre los routers se les asigna un coste
o métrica que puede basarse en el número de saltos, ancho de
banda, retardo, fiabilidad, coste por uso, etcétera. La métrica
asociada con una ruta concreta es la suma de todos los costes
de cada uno de los enlaces que la componen, La ruta con menor
métrica es seleccionada.
Los dos protocolos de vector de distancia más conocidos son
RIP e IGRP. RIP usa una métrica simple, el número de saltos.
IGRP usa una métrica compuesta mucho más rica que tiene en
cuenta el ancho de banda, la máxima unidad de transmisión
(MTU), la fiabilidad de los enlaces y el retardo de los enlaces
que componen el camino.
Nota: El algoritmo de vector de distancia fue el empleado

inicialmente en la red ARPANET (la precursora de la actual
Internet). Este algoritmo es conocido como algoritmo Bellman-
Ford-Fulkerson en honor a sus creadores, y fue descrito por
Ford y Fulkerson en su obra Flows in Networks.
Los protocolos de routing de estado de enlace son más

sofisticados y requieren más memoria y procesador. Ofrecen
190
a cambio una convergencia más rápida, actualizaciones par-
ciales y una arquitectura jerárquica que hace que este tipo de
protocolos sean mucho más adecuados para grandes redes.
Los dos principales ejemplos de protocolos de este tipo son
OSPF e IS-IS.
Los routers que ejecutan este tipo de protocolos intercam-
bian pequeñas piezas de información acerca del estado de los
enlaces, link-state. Combinando la información así recibida
cada router extrae su interpretación topológica de la red. Al
responder de forma inmediata a los cambios de topología
los sistemas basados en el estado del enlace convergen en
segundos, frente a los minutos que pueden llegar a tardar los
sistemas basados en el vector de distancia. Los protocolos link-
state dividen las redes en áreas que constituyen un primer nivel
dentro de la jerarquía de routing. Las áreas se interconectan
a través de áreas troncales (backbone area). El enrutamiento a
través del troncal constituye un segundo nivel dentro de la
jerarquía de enrutamiento.
Dentro de cada área los routers comparten la información
de estado de enlace. Cada uno de los paquetes link-state se
almacena en una base de datos, en la que cada entrada consti-
tuye una pequeña pieza de un puzzle que el router posterior-
mente ordena a través del algoritmo del camino más corto, o
SPF (shortest path first).
Nota: El algoritmo SPF fue descrito por Dijkstra en su artículo

"A Note on Two Problems in Connection with Graphs".
Tanto los algoritmos de vector de distancia como los

de estado de enlace convergen en la misma solución si la
topología o los costos de los enlaces se mantienen estables.
No obstante pueden darse casos en los que los costes de los
enlaces sean función del tráfico, y éste función de las rutas
elegidas. El bucle así formado puede llevar hacia un escenario
inestable (o directamente caótico) en el que la convergencia
no es posible.
Por último hay protocolos de routing híbridos que usan
algoritmos que combinan las características más sobresalientes
del vector de distancia y del estado de enlace. Un protocolo
de enrutamiento híbrido es el EIGRP, propietario de Cisco.
EIGRP desciende de los protocolos de enrutamiento de vector
de distancia, pero toma de los protocolos basados en el estado
de enlace características como el descubrimiento automático
de vecinos.
191
Con clase o sin clase.
Se pueden clasificar los protocolos de enrutamiento en fun-
ción de si sus anuncios de redes transportan información acerca
de la máscara de subred. A los protocolos que acompañan las
actualizaciones de las redes con sus máscaras se les llama "sin
clase" (classless). Ejemplos de protocolos sin clase son RIPv2,
EIGRP y OSPF. Los protocolos que no intercambian información
de la máscara se denominan protocolos "con clase" (classfull).
RIPv1 e IGRP son ejemplos de protocolos con clase.
Los protocolos de enrutamiento con clase no acompañan
las actualizaciones de las redes que conocen con la máscara
de red que estas redes tienen configuradas. Los routers que
ejecutan protocolos con clase pueden usar máscaras de red
distintas a las naturales, pero tendrán que deducir la máscara
correspondiente a la actualización, y darán por sentado que
las máscaras usadas son constantes en toda la red.
Cuando llegue una actualización de enrutamiento si la clase
principal de la red anunciada coincide con la clase principal de
la dirección de la interfaz que recibe la actualización el router
usará como máscara de subred la configurada en dicha interfaz.
Si la actualización es acerca de una red principal diferente a la
configurada en la interfaz que recibe la actualización el router
incluirán en su tabla de rutas entradas con la máscara de red
predeterminada, la correspondiente a la clase principal. A estas
entradas se les llama resúmenes, y los resúmenes en los proto-
colos con clase siempre están en los límites "naturales". Vemos
en la Tabla 5.2 las clases de redes y sus valores "naturales".
Tabla 5.2. Clases de red.

Bits iniciales Máscara /x Rango de
natural Direcciones
CLASE A 0 255.0.0.0 /8 0 . 0 . 0 . 0 a
127.0.0.0
CLASE B 10 255.255.0.0 /16 128.0.0.0 a
191.255.0.0
CLASE C 110 255.255.255.0 /24 192.0.0.0 a
223.255.255.0
CLASE D 1110 255.255.255.255 /32 224.0.0.0 a
239.255.255.255
CLASE E 1111 255.255.255.255 /32 240.0.0.0 a
255.255.255.255
192
Si en una red basada en protocolos con clase se configuran
por descuido máscaras de subred de longitudes diferentes
terminarán apareciendo problemas de conectividad.
Los protocolos de enrutamiento sin clase comunican la
información de las máscaras de subred de forma explícita.
Los protocolos sin clase permiten que las tablas contengan
resúmenes de redes configurados de forma manual en cual-
quier posición de bit (la máscara del resumen no tiene por qué
coincidir con las máscaras "naturales"). En RIPv2 y EIGRP se
puede deshabilitar el resumen automático mediante la orden
"no autosummary" en los casos en los que haya que anun-
ciar subredes a través de otras redes. El uso de máscaras de
longitud variable, mecanismo conocido como VLSM (Variable
Length Subnet Masks), permite aprovechar mejor el espacio de
direcciones.
5.1.6. Enrutamiento: problemas y soluciones

Como indicamos antes, existen situaciones en las que los
fallos o cambios hacen que la convergencia del conjunto de
routers sea difícil o imposible. Un ejemplo típico sucede con
algunos protocolos de distancia vectorial: ante la caida de un
enlace, un router A puede creer que sigue teniendo una ruta
hacia una red R a través de otro router B, cuando en realidad
el router B ha aprendido cómo acceder a la red R a través del
router A.
Cuando esta situación se produce los procesos de enruta-
miento entran en una espiral o bucle (routing loop) en la que los
routers se intercambian información falsa terminando en una
condición conocida como cuenta al infinito (count to infinity).
Existen una serie de técnicas que, combinadas, evitan la apa-
rición de estos bucles de enrutamiento: el horizonte dividido
(split horizon) parte de la base de que no es una buena idea
mandar información de una ruta a la dirección de donde nos
ha venido la información de dicha ruta en primer lugar. Otra
técnica de prevención de bucles es el envenenamiento de rutas
(route poisoning) que consiste en que el router que detecta un
fallo en una red le asigna a la misma un coste infinito, dejando
de esta forma de ser vulnerable a actualizaciones incorrectas
de otros routers que pretendan conocer rutas alternativas hacia
la red caída. Otro mecanismo preventivo consiste en el uso
de temporizadores, relojes puestos en marcha por el router
para marcar una serie de tiempos durante los cuales las ac-
193
tualizaciones de rutas hacia redes que han tenido problemas
no son aceptadas si ofrecen peores métricas que la que tenía
originalmente.
Nota: Existen situaciones en las que mecanismos como el

horizonte dividido pueden interferir con el comportamiento
esperado de una red. Por ejemplo Frame Relay permite crear
sobre una misma interfaz física varias interfaces virtuales.
En este contexto el horizonte dividido puede impedir que
los routers situados al otro lado de los enlaces virtuales se
intercambien actualizaciones de enrutamiento.
5.2. Rutas Estáticas
5.2.1. Conceptos
Las rutas estáticas permiten al administrador de la red es-
pecificar la ruta que deben seguir los paquetes. Si sólo existe
un camino de salida o si la red es pequeña, las rutas estáticas
ahorran memoria y ciclos de procesador. Las rutas estáticas
dan seguridad y permiten al administrador de la red ejercer
un control muy alto sobre lo que ocurre (si habilitamos un pro-
tocolo dinámico corremos el riesgo de recibir actualizaciones
de redes que no reflejen nuestra política de red). A cambio de
su velocidad y seguridad las rutas estáticas requieren de la
presencia de un administrador pendiente de cambiar las rutas
siempre que sea necesario.
5.2.2. Configuración
La sintaxis de una ruta estática es la siguiente:
ip route red [máscara] interfaz/dirección [peso]
Lo que significa: para alcanzar la "red" con tal "máscara"

hay que enviar los paquetes por tal "interfaz" o "dirección". El
siguiente ejemplo indica al router que envíe los paquetes con
destino la red 10.0.0.0/8 a la máquina 172.24.12.1:
ip route 10.0.0.0 255.0.0.0 172.24.12.1
No hemos configurado un "peso" (es opcional). Recordemos

que en la Tabla 5.1 hemos indicado las principales distancias
administrativas. La Tabla 5.3 resume las distancias corres-
194
pondientes a interfaces directamente conectadas y a rutas
estáticas:
Tabla 5.3. Distancias administrativas (parcial).

por defecto
Interfaz directamente conectada 0

Ruta estática 1
Esto tiene implicaciones en el peso por defecto asignado

a una ruta estática. En caso de que el siguiente salto venga
indicado por una interfaz, como en "ip route 10.0.0.0
255.0.0.0 Serial0" el peso asignado a esta ruta es 0
Router(config)# ip route 10.0.0.0 255.0.0.0 Serial0
Router(config)# end
Router#
Si, en cambio, el siguiente salto viene indicado por una

dirección de red, como en "ip route 10.0.0.0 255.0.0.0
172.24.12.1" el peso de la ruta es 1. Tienen prioridad las
rutas con peso más bajo.
Router(config)# ip route 10.0.0.0 255.255.255.255 172.24.12.1
Router(config)# end
Router#
Si queremos borrar esta misma ruta, precederemos la misma

orden de un "no":
Router(config)# no ip route 10.0.0.0 255.255.255.255
172.24.12.1
Router(config)# end
Router#
Un error muy común consiste en indicar una dirección

de red incorrecta. Si tratamos de configurar la siguiente ruta
estática "ip route 10.0.0.1 255.0.0.0 172.24.0.5" el
router nos contestará inmediatamente "%Inconsistent address
and mask". Es fácil ver que 10.0.0.1/8 no especifica una red, sino
un equipo dentro de esa red. Si queremos configurar una ruta
195
estática para alcanzar sólo ese equipo, debemos usar una más-
cara /32 (255.255.255.255), para indicar una red de un solo host:
"ip route 10.0.0.1 255.255.255.255 172.24.0.5".
Esto tiene pleno sentido y el router lo aceptará sin problemas.
Con máscaras "no naturales" (distintas a /8, /16, /24 o /32)
puede ser un poco más difícil ver dónde está el fallo:
%Inconsistent address and mask
Especificando redes, todo funciona correctamente:

Podemos comprobar que nuestras rutas estáticas están

correctamente configuradas consultando la tabla de rutas me-
diante la orden "show ip route" (las rutas estáticas vienen
indicadas con una "S" en la tabla) o verificando mediante un
"show running-config" que aparecen en la configuración
del router. Podemos comprobar que funcionan mediante el uso
de las órdenes "ping" y "traceroute", de las que veremos
más al hablar de resolución de problemas en el capítulo 8. Una
precaución que podemos tomar siempre que configuremos una
ruta estática consiste en hacerle ping a la dirección del gateway y
comprobar la ruta recien configurada. Hay que tener en cuenta
que no todas las máquinas responden a "ping".
5.2.3. Escenarios
Pesos y máscaras
Tenemos un router que puede alcanzar las redes
172.16.1.0/24 y 172.16.2.0/24. Ambas redes se alcanzan a
través del router 10.0.0.1. Podemos agrupar ambas rutas en
una única orden:
Router(config)# end
Router#
Imaginemos que una tercera red, 172.16.3.0/24, alcanzable

a través del router 10.0.0.2:
196
Router(config)# end
Router#
Aunque la red 172.16.3.0/24 está contenida en la red

172.16.0.0/16, el router en estos casos resuelve el conflicto
aparente siguiendo la regla de la máscara de mayor longitud
(longest match)
Nota: El router seguirá la ruta más específica incluso si tiene

una distancia administrativa más alta que la ruta más general.
La distancia administrativa sólo resuelve entre rutas cuando
éstas tienen la misma longitud de máscara.
Ruta por defecto.

Un tipo muy especial de ruta estática es la ruta por defecto
(gateway of last resort), que se configura con la orden "ip route
0.0.0.0 0.0.0.0 interfaz/gateway". Por ejemplo con-
figurando un router de la siguiente forma los paquetes cuyo
destino no venga especificado en la tabla de rutas serán remi-
tidos a la máquina 172.16.0.1.
Router(config)# end
Router#
Esta ruta por defecto sólo es usada con aquellas aquellos

paquetes cuyas redes de destino el router desconoce (no las
tiene en su tabla de rutas).
Nota: Los protocolos de enrutamiento con clase como IGRP

o RIP no hacen uso de la ruta por defecto. Si quiere habilitar
el uso de la ruta predeterminada con estos protocolos con
clase necesitará emitir la orden de configuración global "ip
classless". Con esta orden configurada, los paquetes cuyo
destino sean una subred desconocida de una red conocida serán
encaminados con la ruta por defecto.
Rutas flotantes
En ocasiones podemos querer usar una ruta estática sólo si
la alternativa dinámica no está disponible. En estos casos usa-
remos rutas flotantes (floating static routes) fijando el "peso" de
197
la ruta por encima de la distancia administativa del protocolo
dinámico en cuestión.
Router(config)# ip route 10.0.0.0 255.0.0.0 192.168.1.1 190
Router(config)# end
Router#
En la tabla 5.1 vimos la distancia administrative de los dis-

tintos protocolos dinámicos. Un uso frecuente de este tipo de
rutas es para lanzar una conexión telefónica como enlace de
respaldo en caso de caída de la línea de conexión principal.
Router(config)# ip route 0.0.0.0 0.0.0.0 Dialer1 190
Router(config)# end
Router#
Ruta Nula (Null)

En ocasiones podemos necesitar descartar todos los pa-
quetes destinados a una red o máquina concreta. La siguiente
regla hace que el router descarte todos los paquetes destinados
a la máquina 192.168.1.1:
Router(config)# ip route 192.168.1.1 255.255.255.255 Null
Router(config)# end
Router#
Rutas permanentes
Con la palabra clave "permanent" podemos forzar la per-
manencia de una ruta en la tabla con independencia del estado
de la interfaz o del router al que la ruta apunta.
Router(config)# ip route 10.0.0.1 255.255.255.255 Serial0
permanent
Router(config)# end
Router#
Con ello podemos evitar que un protocolo de routing diná-

mico instale una ruta que por algún motivo no queramos usar.
Si por ejemplo tenemos una ruta a una red interna y ésta se
vuelve inaccessible, con "permanent" podemos evitar que los
routers encuentren una alternativa a través de Internet.
198
5.3. RIP
5.3.1. Conceptos
RIP (Routing Information Protocol) es un protocolo de enru-
tamiento basado en el algoritmo Bellman-Ford o de "vector de
distancia" que utiliza como única métrica el número de saltos.
RIP no ve más allá de 16 saltos.
Nota: Los saltos (hop) son el número de routers a ser atrave-

sados para llegar al destino.
RIP se presenta en dos versiones, RIPv1 y RIPv2, siendo

ambas versiones bastante ruidosas dado que propagan perió-
dicamente su tabla de rutas completa: en concreto RIP anuncia
(update) la tabla de rutas completa cada 30 segundos.
En RIP las rutas se marcan como inutilizables (Invalid) si no
se recibe una actualización en 180 segundos y se borran (flush)
de la tabla si no llega una actualización en 240 segundos. Otro
contador, hold-down, fijado por defecto a 180 segundos, evita
que se instalen rutas sospechosas en la tabla de rutas durante
ese tiempo.
RIP usa el puerto 520 del protocolo UDP para poder co-
municarse.
RIP versión 1
RIPv1 es un protocolo "con clase" (classfull), lo que supone
una importante restricción: sus actualizaciones no informan
de las máscaras de red. Al no llevar las máscaras de red no so-
porta VLSM (variable length subnet masking), y por consiguente
no soporta redes discontiguas. RIPv1 no usa actualizaciones
desencadenadas, por lo que su convergencia es lenta en com-
paración con otros protocolos.
Todo esto hace de RIPv1 un protocolo poco práctico para su
uso en Internet. RIPv1 utiliza broadcasts para enviar la infor-
mación de routing a través de todos los interfaces participantes
(por defecto, a la dirección 255.255.255.255).
Nota: RIPv1 fue descrito inicialmente en el RFC 1058,

un documento que ha quedado obsoleto y que tiene la cali-
ficación de Historic. No obstante puede consultarlo en la
dirección ftp://ftp.rfc-editor.org/in-notes/
rfc1058.txt.
199
RIP versión 2
Las restricciones de RIPv1 llevaron al desarrollo de RIP
versión 2. RIPv2 es un protocolo de enrutamiento "sin clase"
que soporta máscaras de longitud variable o VLSM, y con-
verge más rápido debido a la aplicación de un mecanismo de
actualizaciones desencadenadas ("triggered updates"). Es menos
ruidoso que RIPv1 al usar multicasts a la dirección 224.0.0.9 de
los interfaces participantes. Como la primera versión, RIPv2
está sujeto a la limitación de 16 saltos: cualquier router situado
a una distancia mayor es considerado inalcanzable.
Nota: Puede leer la especificación completa de RIPv2 en los RFC

1723 y 2453, disponibles en la dirección ftp://ftp.rfc-
editor.org/in-notes/rfc2453.txt. En el úl-
timo documento encontrará una descripción actualizada de
RIPv1.
5.3.2. RIP en acción.

Bucles de enrutamiento (Routing loops)
Figura 5.2. Propagación de las rutas.
Vemos en la figura 5.2 una pequeña red compuesta por tres

routers R1, R2 y R3. R3 anuncia D3 a R2 con una métrica de 1.
R2 asigna a D3 una métrica de 2 y se la anuncia a R1, que ahora
sabe que puede llegar a D3 con una métrica de 3 a través de
R2 (R2 es el next hop o siguiente salto).
Cuando R1 anuncia D3 al resto de routers lo hace a su vez
con una métrica de 4. Si este anuncio llega a R2, esta ruta no
200
será usada dado que R2 tiene una ruta mejor para ir a D3 a
través de R3 (dos saltos).
Figura 5.3. Bucle de routing.
Sin embargo, si el enlace R2 - R3 se cae (figura 5.3), R2 bo-

rrará la ruta original e instalará una nueva ruta a D3 con la
métrica de 4 a través de R1. Este router en realidad le devol-
verá los paquetes, creándose un círculo vicioso hasta que el
parámetro TTL (Time To Live) de los paquetes llegue a cero,
haciendo que expiren.
Cuenta al infinito (Counting to Infinity)

En el ejemplo anterior R1 y R2 podrían empezar a anun-
ciarse entre sí como alcanzar D3, sumando 1 a la métrica
recibida del otro antes de volvérsela a anunciar. A esta es-
piral se le llama Cuenta al infinito (Count to Infinity) y para
evitarla se implementa un valor límite por encima del cual
la métrica se considera infinita y la ruta inútil. RIP fija este
límite en 15.
Contención (Holddown)
El mecanismo de contención (holddown) retrasa la bús-
queda de alternativas cuando una ruta acaba de perderse.
El router entre en estado holddown y durante un tiempo ig-
nora las rutas alternativas que pueda tener o recibir. A su vez
anuncia la ruta en estado holddown con un valor infinito con
el objeto de purgarla de la red.
Si en nuestro ejemplo R2 pone a D3 en estado holddown,
R2 no usará la ruta alternativa propuesta por R1. Es más,
anunciará R3 como inalcanzable, con lo que R1 eliminará D3
de su tabla.
Para cuando el periodo de holddown expire tanto R1 como
R2 ya habrán borrado D3 de sus tablas de rutas.
201
Horizonte Dividido (Split Horizon)
Los bucles se originan cuando las rutas se anuncian de vuelta
a los routers que originalmente las anunciaron. El mecanismo de
horizonte dividido (split horizon) evita que un router anuncie
una ruta por la misma interfaz por donde la aprendió en primer
lugar. Con split horizon, R1 no anunciaría D3 a R2 por el enlace
por los une, dado que aprendió esa ruta por esa interfaz.
Envenenamiento inverso (Poison Reverse)

El envenenamiento inverso (Poison Reverse) combina el
mecanismo del horizonte dividido (split horizon) con la purga
de la contención (holddown). Permite que se anuncien las rutas
perdidas por las interfaces por las que originalmente se apren-
dieron pero con métrica infinita, "envenenando" la ruta. Con
este sistema R1 anuncia D3 a RT2 con una métrica infinita.
Actualizaciones desencadenadas (Triggered Updates)

Los protocolos de vector de distancia anuncian periódica-
mente sus tablas de rutas (RIP cada 30 segundos, IGRP cada 90).
Para evitar tener que esperar a uno de los anuncios periódicos,
los cambios de red pueden desencadenar (trigger) actualiza-
ciones (a veces llamadas flash updates), con lo que se evitan
las esperas y se acelera el tiempo global de convergencia.
Para configurar RIP en un router Cisco debemos habilitarlo
como protocolo de enrutamiento dinámico mediante la orden
"router rip". A continuación especificaremos mediante la
orden "network" las redes a las que el router se encuentra
conectado que queremos anunciar dinámicamente. Veamos un
ejemplo de configuración de una red con RIP (figura 5.4).
RouterA(config)# router rip
RouterA(config-router)# network 192.168.1.0
RouterB(config)# router rip

RouterB(config-router)# network 172.16.0.0
RouterC(config)# router rip

RouterC(config-router)# network 192.168.2.0
202
Figura 5.4. Red RIP.
Puede comprobar que RIP está habilitado mediante la orden

"show ip protocols":
RouterA# sh ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 5 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Default version control: send version 2, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 1 1 2
Serial0 1 1 2
Routing for Networks:
172.16.0.0
192.168.1.0
Distance: (default is 120)
La segunda línea indica que RIP está mandando anuncios

cada 30 segundos (el tiempo predeterminado) y que mandará
el próximo en 5 segundos. La tercera línea muestra los valores
de los temporizadores: "Invalid after 180 seconds" muestra los
segundos durante los cuales el router esperará una actualiza-
ción de un vecino antes de marcar las rutas aprendidas de él
como inválidas (y que aparecerán en la tabla de rutas como
"possibly down"), "hold down 180" indica el tiempo durante el
cual el router desconfía de una actualización acerca de una ruta
inválida y "flushed after 240" informa acerca de los segundos
sin recibir una actualización tras los cuales el router borra de
la tabla de rutas las entradas procedentes del vecino que ha
dejado de informar. Tras "Routing for Networks" aparecen las
redes que el proceso RIP anunciará.
Nota: Puede cambiar los valores de los temporizadores usando

la orden "timers basic updates invalid holddown
flush". Como ya hemos dicho el parámetro "updates" marca
203
el ritmo de envío de actualizaciones, "invalid" y "holddown"
deben ser al menos tres veces el valor de "update". El valor
"flush" debe ser al menos la suma de "invalid" y "holddown".
Si no está muy seguro de por qué va a variar estos tiempos
posiblemente no sea una buena idea que los cambie. De todas
formas, si experimenta con los valores recuerde que la siguiente
instrucción devuelve los valores iniciales de los temporizadores
de RIP: "timers basic 30 180 180 240".
También podemos comprobar que está aprendiendo rutas

por RIP consultando la tabla de rutas mediante la orden "show
ip route" (las rutas conocidas mediante RIP vienen indicadas
con una R en la tabla).
5.3.4. Escenarios
Por defecto un router RIP envía paquetes de la versión 1
pero recibe y procesa tanto paquetes RIPv1 como RIPv2. Con
la orden "versión" se puede especificar que el router envíe
y reciba paquetes de la versión especificada.
router rip
version 2
network 192.168.1.0
network 172.16.0.0
Mediante la orden "show ip protocols" podemos com-

probar la nueva configuración del protocolo:
RouterA#sh ip protocols
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 5 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Default version control: send version 2, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 1 2
Serial0 2 1 2
172.16.0.0
192.168.1.0
Distance: (default is 120)
RIP está enviando ahora actualizaciones construidas si-

guiendo la segunda versión del protocolo, pero escucha ac-
tualizaciones de cualquier versión.
Este comportamiento puede ser cambiado a nivel de interfaz
con las órdenes "ip rip send version [ 1 | 2 | 1 2]" e "ip
rip receive version [ 1 | 2 | 1 2]". Con "ip rip send
204
version" se puede hacer que por una interfaz determinada
sólo se envíen actualizaciones de la versión 1, 2 o de ambas.
Lo que se especifica a nivel de interfaz manda por encima
de lo especificado a nivel global con "router versión". De
forma similar con la orden "ip rip receive" se modifica la
conducta receptora del router.
interface serial 1
ip address 10.0.0.1 255.0.0.0
ip rip send version 1 2
ip rip receive version 1 2
Con la orden "passive-interface tipo número" se

especifica que una interfaz no envíe actualizaciones RIP (lo
que no impide que por esa misma interfaz se envíen o reciban
actualizaciones unicast).
router rip
network 10.0.0.0
passive-interface ethernet 0
Un importante comando específico de la versión 2 nos per-

mitirá deshabilitar la sumarización autromática de las rutas:
router rip
network 10.0.0.0
no auto-summary
La sumarización automática está habilitada por defecto.

Las subredes se agrupan o sumarizan en sus clases principa-
lers cuando se anuncian. Si hay redes discontiguas separadas
la sumarización automática debe deshabilitarse (aunque el
tamaño de las tablas crezca).
5.4. EIGRP
5.4.1. Conceptos
EIGRP (Enhanced Interior Gateway Routing Protocol, IGRP
mejorado) es un protocolo híbrido que usa el algoritmo DUAL
(Diffusing Update Algorithm) basado tanto en los algoritmos de
vector de distancia como en los de estado de enlace, para con-
seguir una convergencia muy rápida, almacenando rutas de
reserva y consultando a los routers vecinos para descubrir rutas
alternativas. EIGRP usa poco ancho de banda (es un protocolo
muy silencioso, que sólo propaga la información justa) e im-
205
plementa avanzados mecanismos para librarse de los bucles en
red. EIGRP es compatible con IGRP y, al igual que éste, es mul-
tiprotocolo (funciona sobre IP, IPX y Appletalk), por apuntar
sólo algunas de sus características más sobresalientes.
EIGRP es un protocolo propietario de Cisco que resulta
ideal para interconectar dispositivos de esta marca, pero pre-
cisamente por su carácter propietario tendremos que usar un
protocolo abierto (como RIP u OSPF) para intercambiar infor-
mación de enrutamiento con equipos de otros fabricantes.
Una característica de EIGRP que lo diferencia de RIP e
IGRP es que para enrutar construye y utiliza una tabla de la
topología de la red además de la tabla de rutas. Mediante esta
tabla topológica EIGRP consigue adaptarse a los cambios en
la red a veces de forma casi instantánea.
Nota: IGRP es un protocolo propietario de Cisco precursor

directo de EIGRP que en el momento de su aparición hacia
mediados de los años 80 supuso una mejora sustancial con
respecto al resto de protocolos de distancia vectorial. Es
multiprotocolo (enruta IP, IPX y AppleTalk), se trata de un
protocolo de enrutamiento con clase (no soporta VLSM),
permite más saltos que RIP (hasta 255) y utiliza una métrica
más rica que puede tener en cuenta hasta 5 parámetros (Ancho
de banda, Retraso, Fiabilidad, Carga y MTU). La distancia
administrativa de IGRP es 100.
EIGRP usa una métrica compuesta que toma en considera-

ción hasta 5 parámetros para calcular las métricas (Tabla 5.4)
Tabla 5.4. EIGRP: parámetros de la métrica.

Parámetro Descripción Unidades Uso
Ancho de Velocidad de la Kbps Se usa por

banda (BW) línea defecto
Retraso La suma de los microsegundos Se usa por
(DLY) retrasos de todos defecto
los tramos que
componen un
enlace
Fiabilidad Fiabilidad del 1 (mínima) a No se usa
(Rely) enlace de extremo 255 (100 %) por defecto
a extremo
206
Parámetro Descripción Unidades Uso
Carga) Carga del enlace 1 (mínima) a No se usa

(Load de extremo 255 (100 %) por defecto
a extremo
MTU El máximo tamaño bytes No se usa
de paquete que se por defecto
puede enviar sin
fragmentar
Estos parámetros se pueden obtener con la orden "show

interfaces":
Edgar#sh int se 0/0
Edgar#show interfaces ethernet 0

Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c08.6dbf (bia 0000.0c06.4dbc)
Edgar#sh int fastEthernet 1/0

Hardware is AmdFE, address is 0007.8901.2930 (bia 0007.8901.4354)
EIGRP usa de forma predeterminada dos de estos cinco va-

lores para calcular la métrica: el menor de los anchos de banda
y el retraso acumulado del enlace. Observe que en el ejemplo
mostrado de la interfaz serie el ancho de banda es de 1544 Kbps,
una velocidad equivalente a la de una línea T1. Generalmente
tendrá que configurar el ancho de banda que realmente tenga
la línea mediante el uso de la orden "bandwidth".
La orden para cambiar la forma predeterminada que tiene
EIGRP para calcular la métrica es "metric weights 0 k1 k2
k3 k4 k5". Estas variables k1..k5 se combinan con los cinco
parámetros de la Tabla 5.4 por medio de la fórmula mostrada
en la figura 5.5:
Cambiar estos parámetros puede no resultar una buena idea,
ya que es fácil acabar con bucles de enrutamiento y otros com-
portamientos inusuales. Para volver a dejar los valores predeter-
minados use la instrucción "metric weights 0 1 0 1 0 0".
207
Figura 5.5. Métrica EIGRP.
EIGRP establece relaciones de vecindad con el resto de

routers antes de emitir actualizaciones. Para comunicarse con
esos otros routers utiliza la dirección multicast 224.0.0.10. Si hay
vecinos definidos, EIGRP usa directamente su dirección uni-
cast. Una vez lanzado el proceso EIGRP con la orden "router
eigrp num" (donde "num" es un valor de 16 bits que identifica
el proceso EIGRP), el router empieza a mandar "saludos" (hello
packets) cada 5 segundos en medios LAN y WAN de alta velo-
cidad y cada 60 segundos en medios WAN "lentos".
Nota: El número de proceso que configuramos con "router

eigrp num" puede verse como un Sistema Autónomo. Este
valor entre 1 y 65535 debe ser compartido por los routers
que intercambian información EIGRP. Se pueden configurar
varios procesos EIGRP en un mismo router, cada uno con
su número de proceso. El router mantendrá los procesos
separados y para intercambiar información entre los distintos
procesos habrá que configurar redistribución de rutas. BGP,
que vemos en la sección 5.6, usa un valor similar, pero le otorga
un significado mucho mayor ya que lo usa para seguir la pista
a los sistemas autónomos que atraviesan las distintas rutas.
En BGP el Sistema Autónomo debe ser único, mientras que
en EIGRP el número de proceso no tiene significado fuera del
sistema autónomo.
EIGRP también usa una variante del concepto de holdtime,

manteniendo un contador para llevar la cuenta del tiempo
desde que se recibió un "hello". Superado el valor holdtime (por
defecto el triple del valor del hello), el vecino es declarado
como perdido.
Para que se establezca una relación de vecindad los routers
deben estar en el mismo sistema autónomo (el que usamos
al lanzar el proceso con "router eigrp núm"), los valores K
deben coincidir (pueden haber cambiado con la orden "metric
weights") y las interfaces emisora y receptora deben estar en
la misma subred.
208
5.4.2. EIGRP en acción: DUAL
El algoritmo DUAL (Diffusing Update Algorithm) sigue la
pista de todas las rutas anuncidas por los vecinos y selecciona
un camino libre de bucles hasta cada destino. Para ello DUAL
usa los conceptos de distancia viable o FD (Feasible distance) y
distancia reportada o RD (Reported Distance): FD es la métrica
mínima hasta la red destino y RD es la métrica hasta la misma
red tal como es anunciada por el router vecino (la FD del ve-
cino para esa ruta). La condición de viabilidad o FC (Feasibility
condition) se cumple cuando la métrica al destino del vecino
es menor que la propia, o lo que es lo mismo, cuando RD es
menor a FD. Esto garantiza un camino libre de bucles.
Calculados RD, FD y FC, el router EIGRP elige un sucesor
EIGRP (EIGRP succesor) y un sucesor viable (Feasible succesor). El
sucesor EIGRP es el router vecino que cumple con la condición
de viabilidad FC con la menor métrica al destino. Ese sucesor
se convierte en el siguiente salto (next hop) de los paquetes
hacia esa ruta. El sucesor viable es el vecino que cumple con la
condición FC pero tiene la siguiente mejor métrica, quedando
como ruta de respaldo en caso de que la ruta primaria caiga.
En función de lo anterior tendremos rutas pasivas (Passive
route) cuando el router tiene un sucesor válido, y rutas activas
(Active route) cuando no.
Cuando EIGRP pierde un sucesor o ruta primaria intenta
converger de nuevo mirando en sus tablas topológicas si existe
un sucesor viable. Si lo hay, EIGRP lo promociona a sucesor e
informa a los vecinos del cambio que ha tenido lugar. A este
proceso se le llama cálculo local (local computation).
Cuando el router EIGRP ha perdido un sucesor y carece
de sucesor viable, entra en estado activo y empieza a buscar
una ruta alternativa en un proceso denominado cálculo difuso
(diffused computation). En este estado el router EIGRP manda
paquetes a todos sus vecinos preguntando por la ruta perdida.
Los vecinos responden a la petición mandando información
acerca de una ruta alternativa si la tienen o reenviando la
petición a sus vecinos. Cuando el router que desencadenó el
proceso recibe las respuestas elige al vecino con mejor métrica
a la red perdida como nuevo next hop para esa red.
Nota: En estos casos en los que la ruta principal se ha perdido

y no hay sucesor viable empiezan a aparecer mensajes de error
"DUAL-3-SIA" que indican que el algoritmo DUAL se
encuentra "atrapado en activo" o SIA (Stuck In Active).
209
EIGRP usa un número de sistema autónomo que debe coin-
cidir entre los routers que tengan que intercambiar información
de enrutamiento, "100" en este ejemplo:
RouterA(config)# router eigrp 100
RouterA(config-router)# no auto-summary
RouterB(config)# router eigrp 100

RouterB(config-router)# no auto-summary
RouterC(config)# router eigrp 100

RouterC(config-router)# no auto-summary
Una observación: hemos añadido la orden "no auto-

summary" a cada uno de los procesos de enrutamiento (lo que
se refleja en la línea "Automatic network summarization is not in
effect"). Sin esta instrucción un router configurado con EIGRP
realiza un resumen automático cada vez que cruza la frontera
entre dos redes principales diferentes.
A partir de la versión Version 12.0(4)T de IOS se añadió
la posibilidad de proporcionar una máscara a la orden "net-
work", lo que permite precisar con mayor exactitud las in-
terfaces que participan en el proceso de enrutamiento. Estas
máscaras EIGRP funcionan al revés que las máscaras de red
"normales": los "0" indican las posiciones significativas y los
"1" las que se ignoran.
Router(config)# router eigrp 100
Router(config-router)# network 172.16.1.1 0.0.0.0
Router(config-router)# network 192.168.1.0 0.0.0.255
Router(config-router)# end
5.4.4. Escenarios
Verificación de EIGRP.
Para comprobar el funcionamiento de EIGRP, use "show
ip protocol":
210
Router_A#sh ip protocol
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1
Automatic network summarization is not in effect
192.168.1.0
172.16.0.0
Routing Information Sources:
Gateway Distance Last Update
172.16.1.1 90 09:13:42
Distance: internal 90 external 170
Los routers están ejecutando EIGRP, con un número de pro-

ceso "100", distribuyendo información de las redes 192.168.1.0 y
172.16.0.0. Podemos ver las relaciones de vecindad establecidas
con la orden "show ip eigrp neighbor":
RouterA#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 192.168.9.3 Et0 11 00:00:22 1 4500 0 7
0 192.168.9.5 Et1 10 00:00:23 372 2232 0 4
Para interpretar la salida de esta orden debemos saber el sig-

nificado de las distintas columnas: la columna "H" muestra una
lista de los vecinos en el orden en el que fueron aprendidos, la
columna "Address" indica la dirección IP del vecino, la columna
"Interface" indica la interfaz por la que se conoció al vecino,
la columna "Hold" marca el valor del contador "holddown" (si
llega a 0 la vecindad concluye, se resetea cada vez que llega
un hello). La columna "Uptime" lleva la cuenta del tiempo que
lleva establecida la vecindad, "SRTT" (Smooth Round Trip Time)
el tiempo medio en el que un paquete EIGRP es enviado y
recibido, "RTO" (Round Trip Timeout) lo que tardará el router
en restransmitir si falla una confirmación," Q Count" informa
del número de paquetes EIGRP esperando a ser enviados y
"Sequence Number" el número de secuencia del último paquete
EIGRP que se recibió del vecino.
Con la orden "show ip route eigrp" veremos las rutas
aprendidas a través del proceso EIGRP:
211
RouterA#show ip route eigrp
D 172.22.0.0/16 [90/2172416] via 172.25.2.1, 00:00:35, Serial0.1
172.25.0.0/16 is variably subnetted, 6 subnets, 4 masks
D 172.25.25.6/32 [90/2300416] via 172.25.2.1, 00:00:35, Serial0.1

D 172.25.25.1/32 [90/2297856] via 172.25.2.1, 00:00:35, Serial0.1
D 172.25.1.0/24 [90/2172416] via 172.25.2.1, 00:00:35, Serial0.1
D 172.25.0.0/16 is a summary, 00:03:10, Null0
D 10.0.0.0/8 [90/4357120] via 172.25.2.1, 00:00:35, Serial0.1
Por ejemplo, para alcanzar la red 172.25.1.0/24 lo haremos

a través del router 172.25.2.1 conectado a través de la interfaz
Serial0.1. Vemos la métrica de esta ruta (2172416) y la distancia
administrativa (90).
Autosumarización.
Ya indicamos antes el uso de la orden "no auto-summary"
en cada uno de los procesos de enrutamiento (lo que se refleja
en la línea "Automatic network summarization is not in effect").
Sin esta instrucción un router configurado con EIGRP realiza
un resumen automático cada vez que cruza la frontera entre
dos redes principales diferentes. El router que hace el resumen
anuncia la red completa, pero en su tabla de rutas añade a las
rutas de las subredes que conoce una entrada para el resumen
de la red principal apuntando hacia la interfaz nula (descarta
lo que no encaja con una subred conocida):
ConResumen#show ip route
[…Parte de la salida omitida…]
D 10.1.3.0/24 [90/10537472] via 10.1.1.2, 00:13:15, Serial1
D 10.0.0.0/8 is a summary, 00:13:14, Null0
Estos resúmenes, que minimizan el tamaño de las tablas

de enrutamiento, en determinadas circunstancias pueden
provocar incomunicaciones y por este motivo deshabilitar el
resumen automático puede resultar necesario tanto en EIGRP
como en RIPv2 ya que en estos protocolos "auto-summary"
se encuentra habilitado por defecto.
5.5. OSPF
5.5.1. Conceptos
OSPF (Open Shortest Path First) es un protocolo de enruta-
miento de estado de enlace, interior (pensado para funcionar
dentro de un sistema autónomo o AS) y abierto (no propie-
212
tario, a diferencia por ejemplo del EIGRP de Cisco). Los routers
OSPF usan una métrica basada en los costes de los enlaces, y
crean una base de datos de la topología del sistema autónomo
a partir de la cual construyen la tabla de rutas. Se trata de un
protocolo que converge rápidamente ante cambios topológicos
y que proporciona una mayor seguridad al permitir autentificar
las actualizaciones de enrutamiento. OSPF es un protocolo
exclusivamente IP y sin clase que soporta VLSM.
Nota: La especificación de OSPF está disponible en la RFC

2328, que puede obtener en la dirección ftp://ftp.rfc-editor.
org/in-notes/rfc2328.txt.
OSPF es un protocolo jerárquico que gira en torno al concepto

de "áreas de red". Las áreas OSPF permiten definir porciones de la
red que intercambian información de enrutamiento. La topología
de un área permanece oculta para el resto del sistema autónomo,
lo que reduce el tráfico de enrutamiento y protege las áreas de pro-
blemas de enrutamiento en otras zonas. Hay un área especial que
siempre tiene que existir en una red OSPF: se trata del backbone,
también denominado troncal o área 0, cuya función es interco-
nectar el resto de áreas. Un router puede estar conectado a más
de un área, manteniendo en este caso una base de datos separada
para cada área. Los routers conectados a múltiples áreas se deno-
minan routers de frontera (border routers). Los que tienen todas
sus interfaces dentro de un área se denominan routers internos
(internal routers). Las interfaces de los routers que se encuentran
dentro de la misma área son vecinas (neighbours) y pueden inter-
cambiar información de enrutamiento. Cada router OSPF tiene un
identificador de 32 bits, el ID, que identifica al router dentro de un
sistema autónomo. Se elige como ID la dirección IP más alta de las
interfaces activas del router. Es frecuente configurar una interfaz
loopback para este fin, tomando en este caso el router como ID la
dirección IP de esta interfaz virtual. Usar las interfaces loopback
tiene la ventaja de que siempre permanecen activas. OSPF utiliza
el protocolo IP número 89 para sus comunicaciones y las direc-
ciones multicast 224.0.0.5 y 224.0.0.6 para enviar actualizaciones
a los routers participantes.
5.5.2. OSPF en acción.

Ya hemos indicado que el concepto central de OSPF es el
de área, un grupo de routers que ejecutan este protocolo de
routing. Las áreas permiten la sumarización de las redes, y
213
como consecuencia tablas de rutas más paqueñas y convergen-
cias más rápidas. En OSPF se recomienda limitar las áreas a
unos 50 routers o 100 interfaces. Cada área tiene un número,
y siempre debe existir un área troncal, backbone o área 0, a la
que se conectan todas las demás. Hay también áreas Standard
que conectan con el backbone, áreas Stub que sólo necesitan
una ruta por defecto y un resumen de las redes y dentro de
estas últimas áreas Totally stubby que no aceptan resúmenes,
sólo una ruta por defecto, entre otras.
Dentro de estas áreas los routers reciben distintos nom-
bres en función del rol que ejercen. Así, tenemos los routers
backbone, que se caracterizan por tener una o más interfaces
conectadas al troncal OSPF (area 0), routers area-internal, que
tienen todas sus interfaces dentro de una única área, routers
ABR (area border router), routers con una o más interfaces co-
nectadas a diferentes áreas y routers ASBR (autonomous system
border router), un router con una o más interfaces conectadas a
una red externa o a un sistema autónomo diferente.
Así, en la Figura 5.6 tenemos tres áreas: un área 0 o backbone,
compuesta por tres routers R1, R2 y R3 que serían "backbone
routers". R1 sería además un "area internal router" (al igual que
R4 y R5). Los routers R2 y R3 serían "area border routers" co-
nectando el backbone con las áreas 1 y 2. Finalmente tenemos
un "autonomous system border router" (ASBR) que conecta con
un sistema autónomo diferente.
Figura 5.6. Red OSPF.
214
Además, en todos los segmentos de red multiacceso (por
ejemplo Ethernet) OSPF nombra un router designado (designated
router) o DR, que se encarga de propagar las actualizaciones a
todos los routers dentro del area, reduciendo de forma efectiva
el tráfico OSPF. En el mismo proceso de elección del DR se elige
un DR de respaldo denominado BDR (backup designated router),
que promociona a DR en caso de fallo del router designado.
Nota: Los enlaces Punto a punto y punto-multipunto no

requieren un DR o un BDR. En estos casos las adyacencias
se forman entre los dos routers que se encuentran a cada lado
de la conexión.
Cada router OSPF tiene un identificador único denominado

router ID que le identifica dentro de la red OSPF. Por defecto
este router ID es la dirección de la interfaz loopback, y en caso
de no haber una interfaz loopback definida la IP más alta de
cualquier interfaz activa. Los routers mandan paquetes "hello"
por todas las interfaces en las que tengan habilitado del pro-
tocolo OSPF. Si dos routers vecinos comparten una serie de
parámetros especificados en estos "hellos", se convertirán en
vecinos. Cada router OSPF tiene una tabla de vecinos.
Nota: Cuando se presentan problemas en OSPF muy a

menudo se manifiestan en (o directamente están causados
por) las relaciones de vecindad. La orden "debug ip ospf
adj" resulta muy útil para diagnosticar los problemas que
puedan aparecer.
Una vez establecida la vecindad, los routers conforman

adyacencias (enlaces virtuales entre routers OSPF). A través
de estas adyacencias los routers intercambian unos paquetes
denominados LSAs (link state advertisements) anunciando (ad-
vertise) el estado (state) de los enlaces (link)
Hay diferentes tipos de LSAs, que se envían cada vez que
hay un cambio en la red o por defecto cada 30 minutos:
Tabla 5.5. Tipos de LSA.

LSA Denominación Descripción
Tipo 1 Router Link Se mandan dentro de un

área y contienen toda la informa-
ción de los enlaces
215
LSA Denominación Descripción
Tipo 2 Network LSAs Continenen información específica

de redes, el "router designado"
manda este LSA a todos los routers
del área.
Tipo 3 Internal Contienen información de rutas y
Summary LSAs es mandada por los routers ABR
a todos los backbone routers.
Tipo 4 External Información para los routers
Summary ASBR.
Tipo 5 Autonomous Contienen información sobre redes
System externas y sólo son mandadas por
los routers ASBR.
Tipo 6 Multicast OSPF Un tipo especial de LSAs ignorado
por los routers Cisco.
Tipo 7 NSSA External Usadas por las áreas NSSAs
LSA (notso-stubby areas).
Al recibir las LSA de los vecinos los routers OSPF alma-

cenan la información en una base de datos de estado de enlace
(link state database) y reenvían una copia de la LSA al resto de
sus vecinos.
Eventualmente todos los routers del área terminan com-
partiendo las mismas LSAs, y en consecuencia, las mismas
link state databases. En este punto cada router ejecuta el al-
goritmo SPF (o de Dijkstra) para calcular un grafo libre de
bucles compuesto por los caminos más cortos a cada destino
conocido, situándose a sí mismo en la raíz. El grafo resultante
es el árbol SPF (SPF tree), y a partir del mismo se construye la
tabla de rutas.
A partir de este momento OSPF se vuelve un protocolo
silencioso. En ausencia de cambios topológicos tan sólo se
pueden ver "hellos" para mantener las conexiones ("keepalives")
y, cada 30 minutos, la retransmisión de las LSAs.
Los routers OSPF atraviesan una serie de estados que
mostramos en la figura 5.7: en primer lugar se encuentran
en un estado inicial "Down", y de ahí pasan a "Init", estado en
el que se envían "Hellos" para conformar una relación de ve-
cindad (Neighbour Relationship). Un paquete "Hello" portando
entre otras informaciones el router ID se envía a la dirección
224.0.0.5, por ejemplo cada 10 segundos (hello interval) por de-
216
fecto en redes Ethernet. Cuando dos router se "ven" entre si se
establece una comunicación bidireccciónal y entran en estado
"Two-way", donde los routers se añaden a sus respectivas ta-
blas de vecindad.
Nota: El "Dead Interval" es normalmente 4 veces el "Hello

interval" y es el tiempo que un router espera antes de declarar
un vecino como caído.
Figura 5.7. Estados OSPF.
217
A continuación en las redes multiacceso tiene lugar la
elección del DR y del BDR: el router con la prioridad más
alta (Router Priority) se convierte en el DR, y en caso de em-
pate el que tenga el router ID más alto. Tras la elección los
routers empiezan a crear la base de datos de estado de en-
lace. El descubrimiento de rutas corresponde a los estados
Exchange y Loading, momento en el que los routers se inter-
cambian Database Description Packets (DBDs) y Link State
Advertisements (LSAs).
Finalmente, una vez que los routers conocen la topología
de la red y sólo necesitan intercambiar "hellos" para mantener
las adyacencias se ha alcanzado el estado Full.
Para configurar OSPF debe usar la orden "router ospf
número_de_proceso", siendo el número_de_proceso un valor
de dos bytes comprendido entre 1 y 65535 que identifica el
proceso OSPF en el router.
En un router puede haber más de un proceso OSPF, y los
números de proceso no tiene por qué coincidir con los de otros
routers vecinos (en nuestro ejemplo el router A ejecuta el pro-
ceso 88 y el B el 99).
A continuación usamos la orden "network red máscara
area area_id" para configurar las redes que van a formar
parte de las actualizaciones OSPF. El área sí debe coincidir
entre interfaces que vayan a intercambiar actualizaciones.
El área es un valor de 4 bytes, y puede representarse como
un valor decimal de 0 a 4294967295 o como cuatro octetos en
formato de dirección IP. Por ejemplo, "area 6" puede escri-
birse como "area 0.0.0.6"
RouterA #conf t
RouterA (config)# router ospf 88
RouterA (config-router)# network 172.16.0.0 0.0.255.255 area 0
RouterB #conf t
RouterB (config)# router ospf 99
RouterB (config-router)# network 172.16.0.0 0.0.255.255 area 0.0.0.0
RouterB (config-router)# network 192.168.4.0 0.0.0.255 area 0.0.0.0
RouterC #conf t
RouterC (config)# router ospf 77
RouterC (config-router)# network 192.168.4.0 0.0.0.255 area 0
218
Es característico de OSPF el uso de máscaras "comodín"
(wildcard mask) para especificar la parte de red y la de host de
las direcciones. Los comodines de estas máscaras usan ceros
para indicar la parte que debe coincidir exactamente y unos
para indicar la parte cuyo contenido no se va a comprobar (vea
un ejemplo en la Tabla 5.6). Veremos al estudiar las listas de
acceso que usan este mismo tipo de máscaras.
Tabla 5.6. Redes y máscaras comodín (wildmask).

Decimal Binario
Dirección 172.16.0.0 1 0 1 0 11 0 0 . 0 0 0 1 0 0 0 0 . 0 0
000100.00000000
Máscara 0.0.255.255 00000000.00000000.1111111
1.11111111
Dirección 192.168.4.0 11000000.10101000.000001
00.00000000
Máscara 0.0.0.255 00000000.00000000.000000
00.11111111
El router ID juega un importante papel dentro de OSPF. El

ID toma el valor de la dirección IP más alta configurada en una
interfaz loopback, o de cualquier interfaz en caso de no haberlas
de tipo loopback. A partir de la IOS 12.0[1]T se puede confi-
gurar el OSPF ID con la orden "router-id dirección-IP",
tomando preferencia esta configuración por encima de los
valores de cualquier tipo de interfaz.
RouterOSPF (config)# router ospf num-proceso
RouterOSPF(config-router)# router-id dirección-IP
Se puede modificar la métrica OSPF de una interfaz por

medio de comandos "bandwidth" o "ip ospf cost": Por
ejemplo, las siguientes configuraciones son equivalentes:
RouterOSPF (config)# interface serial 0/0
RouterOSPF(config-if)# bandwidth 64
RouterOSPF (config)# interface serial 0/0

RouterOSPF(config-if)# ip ospf cost 1562
La relación entre velocidad y coste viene indicada por la

fórmula coste=108/bps.
A continuación, en la tabla 5.7 indicamos las principales
equivalencias
219
Tabla 5.7. OSPF: relación entre velocidad y coste.
Interfaz Velocidad(kbps) Coste
Fast Ethernet 100.000 1

Ethernet 10.000 10
E1 2.048 48
T1 1.544 64
128 781
64 1.562
56 1.785
Podemos manipular la elección DR/BDR modificando la

prioridad de las interfaces con "ip ospf priority".
Puede comprobar el estado de OSPF con las órdenes "show
ip protocols", "show ip route ospf" (que muestra las rutas
OSPF de la tabla de rutas) y "show ip ospf neighbours" (que
muestra el estado en el que se encuentra el proceso OSPF con
respecto a cada uno de sus vecinos, un estado FULL indica un
funcionamiento completo). Puede ver el ID del router, junto
con información relativa a un proceso específico OSPF con la
orden "sh ip ospf número-de-proceso".
Sagan#sh ip ospf 99
Routing Process "ospf 99" with ID 192.16.8.1
Supports only single TOS(TOS0) routes
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x0
Number of DCbitless external LSA 0
Number of DoNotAge external LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Area BACKBONE(0.0.0.0)
Number of interfaces in this area is 1
Area has no authentication
SPF algorithm executed 7 times
Area ranges are
Number of LSA 1. Checksum Sum 0x71F9
Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Vemos que para el proceso OSPF 99 el ID es

192.16.8.1 (también podríamos haberlo comprobado
con "show ip protocols"), el tipo de rutas que soporta, los
temporizadores básicos, datos acerca de los anuncios LSA (Link
State Advertisement) inundados en el dominio de enrutamiento,
220
el área a la que pertenece este proceso (BACKBONE 0.0.0.0), el
número de veces que el algoritmo SPF se ha ejecutado, etc…
5.5.4. Escenarios
Propagando rutas en OSPF
La implementación que los routers Cisco hacen del protocolo
OSPF no propaga al resto de la red una ruta aunque haya confi-
gurada una ruta estática como tal, a diferencia de lo que ocurre
con RIP o EIGRP. Si queremos anunciar una ruta por defecto
debemos usar "default-information originate"
Router(config)# router ospf 88
Router(config-router)# default-information originate metric
30 metric-type 1
Router(config-router)# exit
Router(config)# end
Si lo que queremos es propagar a través de OSPF las rutas

estáticas configuradas en un router determinado haremos uso
de la orden "redistribute static"
Router(config-router)# redistribute static
OSPF Virtual Links

A veces puede darse la situación de tener que conectar un
área fragmentada. Para ello crearemos un enlace virtual entre
dos routers.
Router(config-router)# area 10 virtual-link 10.0.0.1
Router(config-router)# exit
Router(config)# end
Router#
Por supuesto el router remoto debe tener una configuración

recíproca. Las direcciones IP configuradas con "virtual-
link" deben ser las del router ID OSPF del router con el que
queremos conectar, y debe haber conectividad entre ambas
direcciones (se debe poder hacer ping desde un router al router
ID del otro). Podemos comprobar el estado del enlace virtual
con la orden "show ip ospf virtual-links"
221
Router#show ip ospf virtual-links
Virtual Link OSPF_VL1 to router 10.0.0.1 is up
Run as demand circuit
DoNotAge LSA allowed.
Transit area 10, via interface Serial0/0, Cost of using 74
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:00
5.6. BGP
5.6.1. Conceptos
BGP es un protocolo de routing exterior, abierto, cuyas ac-
tualizaciones llevan una lista completa de las redes por las
que transitan. Estos caminos o "paths" son listas de los sistemas
autónomos (AS) necesarios para alcanzar una red. BGP detecta
y evita los bucles de routing buscando el número de AS local en
las listas de sistemas autónomos atravesados en el AS path.
Nota: BGP es clasificado a veces como de tipo "path vector",

para distinguirlo de los protocolos de vector distancia y de
estado de enlace.
BGP establece relaciones de vecindad (peering) con otros

routers denominados "pares" (peers) o iguales. Cuando las
relaciones se establecen con peers dentro del mismo AS se uti-
liza el BGP Interior (IBGP), mientras que con los AS externos
se usa el BGP Exterior (EBGP). IBGP intercambia información
acerca de cómo alcanzar redes y redistribuye información BGP
a los protocolos de routing interiores (IGPs como RIP, OSPF o
EIGRP). BGP usa el puerto TCP 179 para establecer comuni-
caciones fiables entre peers.
Nota: Puede consultar los detalles de BGP versión 4 en la

RFC 1771, disponible en la dirección ftp://ftp.rfc-
editor.org/in-notes/rfc1771.txt.
BGP precisa que cada sistema autónomo tenga un número

denominado ASN (Autonomous System Number), un valor de 16
bits (0-65535). Este identificador tiene valor global y debe ser
único ya que, como indicamos antes, BGP los usa para evitar
problemas de enrutamiento.
222
Figura 5.8. Peering BGP en el punto neutro Espanix.
(http://www.espanix.net/esp/peering.htm)
En el RFC 1930 se definen los ASN del 64,512 al 65,534 para

uso privado. Estos valores son similares en concepto a las redes
IP definidas en el RFC 1918 (10.x.x.x, 172.x.x.x, 192.168.x.x…).
Estos ASN se pueden usar internamente con la única restricción
de que no deben ser inyectados en Internet.
Otro concepto importante en BGP es el de los prefijos
(prefix), un bloque de direcciones IP sumarizado (por ejemplo,
las cuatro redes determinadas por los prefijos 172.25.4.0/24,
172.25.5.0/24, 172.25.6.0/24 y 172.25.7.0/24 puede sumarizarse
o agregarse en un único prefijo 172.25.4.0/22 que abarca los
cuatro prefijos anteriores.
BGP usa una serie de atributos asociados a cada prefijo.
Estos atributos contienen información acerca de las rutas.
Los atributos BGP se dividen en "bien conocidos" (Well known
attributes), que deben ser soportados por todas las implemen-
taciones BGP. Algunos de estos atributos son además "obli-
gatorios" (mandatory) y deben ser incluidos con cada ruta,
mientras que otros atributos son "discrecionales" (discretionary)
y aunque deben ser soportados por BGP su presencia no es
obligatoria.
Otros atributos BGP son "opcionales" (optional), y no son
soportados por todas las implementaciones. Dentro de los
opcionales distinguimos "transitivos" y "no transitivos". Un
223
router que reciba un una ruta con un atributo opcional tran-
sitivo lo pasará intacto, pero marcará una bandera indicando
que no ha hecho nada con el atributo. Un router que reciba
un atributo opcional no transitivo lo descartará sin más. En la
tabla 5.8 describimos algunos atributos de BGP:
Tabla 5.8. Atributos BGP

Atributo Tipo Descripción
ORIGIN Bien Conocido, Refleja cómo aprendió la
Obligatorio ruta el primer router BGP
que la originó. Los tres
posibles valores son 0 – IGP,
la ruta viene de un IGP
interno al AS original, 1 –
EGP, la ruta viene de un
EGP distinto a BGP y 2
–cualquier otro método
AS_PATH Bien Conocido, Lista de ASNs que
Obligatorio componen el path para
alcanzar la red de destino.
Hay dos tipos de AS_
PATH: AS_SEQUENCE,
que describe el camino
literal a tomar, y AS_SET,
que recoge una lista
desordenada de ASNs.
Cuando BGP pasa una
actualización de la ruta a
un peer eBGP, añade al
AS_PATH su propio ASN.
NEXT_HOP Bien Conocido, Almacena la dirección IP
Obligatorio del primer router BGP en el
path hacia la red destino.
Cuando el router instala
la ruta para un prefijo en su
tabla de rutas usa este
atributo para determinar el
siguiente salto (el next hop
router).
MULTI_EXIT._ Opcional, Valor de 32 bits usado para
DISC No transitivo diferenciar entre paths equi
valentes. MED es a veces
llamado la métrica BGP
224
Atributo Tipo Descripción
LOCAL_PREF Bien conocido, Usado para favorecer un
discrecional punto de salida particular
como vía de alcanzar una
red. La preferencia local sólo
se distribuye internamente,
y no se incluye en las ac-
tualizaciones eBGP.
ATOMIC_ Bien conocido, Atributo que los routers BGP
AGGREGATE discrecional marcan cuando sumarizan
(aggregate) prefijos con el
objeto de simplificar la tabla
de rutas, perdiendo inf0r-
mación.
AGGREGATOR Opcional, Indica que un router ha
Transitivo sumarizado un rango de
prefijos.
5.6.2. BGP en acción

BGP selecciona el mejor path a un destino siguiendo el si-
guiente procedimiento en el orden descrito:
• Si el siguiente salto es inaccesible, descarta la ruta.
• Entre dos rutas con pesos diferentes, prefiere el peso
más alto.
• A igualdad de pesos, escoge la que tiene la preferencia
local más alta.
• A igualdad de preferencia local, escoge la ruta originada
por el router local.
• Si todas son originadas en el propio router, prefiere la
que presenta el path más corto.
• A igualdad de longitud de path, escoge la que tenga un
origen menor (igp < egp < incompleto).
• A igualdad de orígenes, prefiere la ruta con el MED
más bajo.
• A igualdad de MEDs, prefiere una ruta externa a una
interna.
• Si la sincronización está deshabilitada y sólo quedan
paths internos, prefiere el path con el vecino IGP más
cercano.
• A igualdad de todo lo anterior, prefiere el camino más
antiguo y estable.
225
• Y si llega hasta aquí, desempata escogiendo la ruta del
BGP router con menor ID.
Vemos en la figura 5.9 los estados por los que atraviesa el
proceso BGP durante el establecimiento de las relaciones de
vecindad, así como las transiciones que el protocolo preveé.
Es frecuente encontrarse con los estados "Active", "Open" o
"Connect" y pensar que significan que la sesión está activa,
cuando en realidad significan que la relación entre peers se
encuentra caída o en fase de establecimiento. Estos estados se
pueden comprobar con la orden "show ip bgp summary", en
la columna "State/PfxRcd". Un número en esta columna indica
un estado "Established".
Figura 5.9. Estados BGP.
Vemos a continuación una sencilla configuración BGP que
permitirá comprobar el establecimiento de la conexión entre
dos routers.
RouterA(config)# interface Serial0
RouterA(config-if)# ip address 192.168.1.1 255.255.255.252
RouterA(config-if)# exit
226
RouterA(config)# router bgp 65500
RouterA(config-router)# neighbor 192.168.1.2 remote-as 65501
RouterA(config-router)# no synchronization
RouterA(config-router)# bgp dampening
RouterA(config-router)# exit
RouterA(config)# end
RouterB#configure terminal
RouterB(config)# interface Serial0
RouterB(config-if)# ip address 192.168.1.2 255.255.255.252
RouterB(config-if)# exit
RouterB(config)# router bgp 65501
RouterB(config-router)# network 172.16.16.0 mask 255.255.255.0
RouterB(config-router)# neighbor 192.168.1.2 remote-as 65500
RouterB(config-router)# no synchronization
RouterB(config-router)# bgp dampening
RouterB(config-router)# exit
RouterB(config)# end
Indicamos con "router bgp AS-núm"el sistema autó-

nomo que cada router representa, con "network" las redes
a anunciar (el router A anuncia una red completa con "net-
work 192.168.5.0", el router B una subred "network
172.16.16.0 mask 255.255.255.0") y con "neighbor
DirIP remote-as ASNúm" la dirección del peer y su sistema
autónomo.
En BGP la sincronización con las rutas de los IGP (proto-
colos de routing interiores como OSPF o EIGRP) está habili-
tada por defecto, con el resultado de que BGP sólo anuncia
rutas presentes tanto en las tablas de rutas de los IGP como
de BGP. Con "no synchronization" desactivamos esta
característica, lo que se recomienda a no ser que estemos
ejecutando un IGP y redistribuyendo las rutas entre BGP y
el IGP. La orden "bgp dampening" protege al router BGP
de los problemas derivados de la inestabilidad ("flapping")
de circuitos e interfaces. Esta opción se encuentra habilitada
por defecto en las versiones modernas de IOS, pero no está
de más explicitar su uso.
Comprobamos el funcionamiento con "show ip bgp sum-
mary":
RouterA#show ip bgp summary
BGP router identifier 192.168.88.8, local AS number 65500
BGP table version is 6, main routing table version 6
4 network entries and 4 paths using 484 bytes of memory
2 BGP path attribute entries using 196 bytes of memory
BGP activity 11/7 prefixes, 11/7 paths
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.2 4 65501 27 28 6 0 0 00:16:18 2
227
Nota: BGP está establecido si ve un número en la columna
"State/PfxRcd" de la orden "show ip bgp summary".
En el ejemplo tenemos una sesión BGP con el peer 192.168.1.2

desde hace 16 minutos. Tenga en cuenta que el establecimiento
de una conexión BGP puede llevar varios minutos. Si pasado
un tiempo el estado mostrado bajo "State/PfxRcd" es "Idle",
"Active", "Open" o "Connect" conviene revisar la configuración
tanto local como la del vecino para comprobar que las sen-
tencias "neighbor" tengan la dirección IP y el número de AS
remoto correctos, que se pueda hacer "ping" al vecino o que
no haya un firewall filtrando el puerto TCP 179.
5.6.3. Escenarios
BGP es un protocolo complejo que ofrece múltiples posi-
bilidades. Para profundizar en su estudio recomendamos la
lectura de "Internet Routing Architectures" de Sam Halabi (Cisco
Press, 2000).
En el Apéndice presentamos por cortesía de Jose Antonio
Suárez y Sergio Parras (Ingenieros de Nivel 3 de la empresa
Networkstest) un ejemplo completo que combina el uso de BGP,
RIPv2 como IGP y conexiones Frame Relay para acceder a una
nube MPLS, todo ello montado sobre el emulador GNS3.
5.7. Enrutamiento no IP
Cuando se publicó la primera edición de este libro en el
año 2003 el protocolo TCP/IP ya se había impuesto claramente
por encima del resto, pero todavía era relativamente habitual
encontrarse con redes IPX y Appletalk, y el autor recuerda con
cariño un encuentro que tuvo por aquella época con el proto-
colo DECNet a través de una curiosa incidencia. Hoy en día
tanto Novell como Apple han migrado a TCP/IP, y el autor
no ha vuelto a ver DECNet por lado alguno, pero como nunca
se sabe, aquí queda esta sección.
5.7.1. Enrutamiento con IPX

IPX usa direcciones de 80 bits, de los que 32 identifican
la red y los 48 restantes son para los host (máquinas). En IPX
el número de host es la dirección MAC, lo que hace que con
228
este protocolo no sea necesario un proceso que mapee direc-
ciones de nivel 3 (de red) con las de nivel 2 similar al ARP
de TCP/IP.
Para habilitar IPX en el router usaremos la orden de confi-
guración global "ipx routing". Necesitará una versión de IOS
que tenga soporte IPX. Vemos en el siguiente ejemplo cómo
hemos configurado la interfaz e0 con la dirección de red 9 y
la interfaz s0 con la 6.
interface Ethernet0
ipx encapsulation SAP
ipx network 9
!
interface Serial0
ipx network 6
Con la orden ipx encapsulation le damos una encapsula-

ción de nivel 2 a la interfaz (consulte los encapsulados IPX
disponibles con "ipx encapsulation ?"). Si examinamos la
configuración del router con un "show runn"veremos que a
la orden "ipx routing" se le ha añadido un número de red
(por ejemplo "ipx routing 0004.ddcc.c690"). Se trata
de la dirección de host del router. Las interfaces tendrán las
direcciones 9.0004.ddcc.c690 (ethernet) y 9A.0004.ddcc.c690
(serial). La interfaz serial toma "prestada" la dirección MAC
de la interfaz ethernet. Podemos probar un "ping ipx" desde
un router vecino:
vecino#ping ipx 9A.0004.ddcc.c690
Sending 5,100-byte IPX Novell Echoes to 9A.0004.ddcc.c690
timeout is 2 seconds:
!!!!!
Para examinar los servidores IPX que conoce el router

usamos la orden "sh ipx servers":
delegacion#sh ipx servers
Codes: S-Static, P-Periodic, E-EIGRP, N-NLSP, H-Holddown, +=detail
U - Per-user static
151 Total IPX Servers
Table ordering is based on routing and server info
Type Name Net Address Port Route Hops Itf
P 4 ServFicherosLocal 9.0030.g1d6.5987:451 7/01 1 Ethernet
P 7 ServImpresRemoto 7.0060.a071.4207:8060 7/01 2 Serial
Esta orden nos proporciona información de los servidores

IPX descubiertos por el router: nombre, tipo de servidor (Tabla
5.9), dirección IPX, distancia e interfaz a través de la cual se
llega el servidor, etc…
229
Tabla 5.9. Algunos tipos de servicio IPX/SPX
Servicio Función
1 Usuario
4 Servidor de archivos
7 Servidor de impresión
33 Pasarela SNA
39 Pasarela TCP/IP
152 Servidor de acceso NetWare.
311 Cola de impresión NetWare 386.
632 Servicio de directorio Netware 4.x
En IPX disponemos de RIP como protocolo de enruta-

miento. Se trata del protocolo habilitado por defecto. Con dar
los pasos descritos en el punto anterior (habilitación del proceso
IPX con "ipx routing", asignación de redes y encapsulados
con las órdenes de configuración de interfaz "ipx encapsu-
lation" e "ipx network") tendremos RIP funcionando en
nuestra red IPX.
RIP IPX es un protocolo de distancia vectorial. Usa como
métricas pulsos (una medida de tiempo) y saltos. Al igual
que RIP para IP, RIP IPX no ve redes situadas a una distancia
mayor de 15 saltos. Se trata de un protocolo "ruidoso" (difunde
las tablas una vez por minuto de forma predeterminada). RIP
IPX usa la técnica del horizonte dividido para escapar de los
bucles de enrutamiento, pero en situaciones de inestabilidad
es propenso a aceptar entradas erróneas en sus tablas.
NSLP (Netware Link Services Protocol) es el protocolo de en-
rutamiento IPX basado en el estado de enlace. Es más fiable
(usa información de primera mano para construir la tabla
de rutas), converge más rápido, es poco "ruidoso" y alcanza
redes situadas a 128 saltos de distancia, además de ser capaz
de detectar redes que usan RIP y mandarlas la información de
encaminamiento necesaria para mantener la conectividad.
5.7.2. Enrutamiento con AppleTalk

AppleTalk era el protocolo de red usado por los ordena-
dores de la marca Macintosh antes de pasar a usar TCP/IP de
forma generalizada. AppleTalk usa direcciones de 24bits, de
los que 16 identifican la red y los 8 restantes son para los host
230
(máquinas). Para habilitar AppleTalk en el router usaremos
la orden de configuración global "appletalk routing".
Necesitará una versión de IOS que tenga soporte AppleTalk.
En AppleTalk el número de host es asignado dinámicamente
a la máquina que "entra" en red mediante una negociación
que implica a los protocolos ZIP (Zone Information Protocol)
y AARP (AppleTalk ARP). Mediante ZIP el host descubre el
rango de direcciones de red válido. Mediante sondeos AARP
obtiene una dirección de host que ninguna otra máquina esté
usando. Con "appletalk cable-range" indicamos el rango
de direcciones de red existentes en un determinado medio.
Con "appletalk zone" creamos dominios que limitan las
difusiones. Una interfaz puede pertenecer a varias zonas si-
multáneamente.
interface ethernet 0
appletalk cable-range 200-210
appletalk zone contabilidad
appletalk zone imprenta
interface serial 0
appletalk zone imprenta
Una característica muy interesante de Appletalk es su ca-

pacidad de obtener de otros routers la información de la red.
Si configuramos una interfaz en "modo descubrimiento"…
interface serial 1
appletalk discovery
… posteriormente con "show running" veremos que el router

ha obtenido una dirección de red válida (aunque para ello
es necesario que en la red haya otro router servidor debida-
mente configurado). Podemos grabar la configuración en
ese momento.
Use las órdenes "show appletalk" para verificar los as-
pectos relativos a Appletalk. Concretamente la orden "show
appletalk global" le dará una visión completa del estado
del protocolo en el router.
Hay varios protocolos de enrutamiento dinámico para
AppleTalk: RTMP (Routing Table Maintenance Protocol), AURP
(AppleTalk Update Routing Protocol) y EIGRP. RTMP es un pro-
tocolo de distancia vectorial que, como RIP, difunde periódica-
mente sus tablas (cada 30 segundos de forma predeterminada).
Si no especifica ningún protocolo de enrutamiento, RTMP
quedará habilitado por defecto.
231
5.7.3. Otros protocolos de enrutamiento
Hemos visto en el presente apartado los protocolos de en-
rutamiento de uso más frecuente, pero cada pila de protocolos
tiene su propio mecanismo de descubrimiento de rutas. La suite
de protocolos Banyan Vines dispone del VRTP (VINES Routing
Update Protocol) y del VSRTP (Vines Sequenced RTP). La pila de
protocolos XNS hace uso del XNS RIP. DECNet tiene como
protocolo de enrutamiento el DRP (DECNet Routing Protocol).
La pila OSI cuenta con ES-IS (End System to Intermediate System
Routing), IS-IS (Intermediate System to Intermediate System
Routing) e IDRP (Interdomain Routing Protocol). SNA dispone del
NLP APPN (High Performance Routing Network Layer Protocol).
TCP/IP dispone, además de los protocolos de enrutamiento
ya estudiados, de MOSPF (Multicast OSPF), NHRP (Next Hop
Routing Protocol) y DVMRP (Distance Vector Multicast Routing
Protocol). El lector interesado encontrará en Internet informa-
ción adicional acerca de estos protocolos de enrutamiento si
hace uso de alguno de estos protocolos.
5.8. Policy Routing

Los mapas de rutas (route maps) nos permiten ejercer un
alto nivel de control sobre el tráfico que pasa por el router.
Esta técnica nos permite encaminar información en función de
combinaciones flexibles de características del tráfico: origen,
destino, tipo de servicio, etc…
Los mapas de rutas se construyen con listas de condiciones
("match") y acciones ("set"). En el ejemplo siguiente creamos
un mapa que llamamos "trafico_especial", e indicamos que los
paquetes que cumplan la condición expresada en la lista de
acceso 120 ("match ip address 120") sean enviados a la má-
quina 192.168.0.201 ("set ip next-hop 192.168.0.201"),
al margen de lo que especifique la tabla de rutas. Aplicamos
el mapa en la ethernet, de forma que los paquetes sujetos a la
serán esperados en dicha interfaz. Incluimos la lista de acceso
para completar la configuración, aunque las veremos a fondo
en el próximo capítulo. Las listas de acceso son el mecanismo
por excelencia de selección de tráfico en los routers Cisco.
Seleccionamos el tráfico con origen 172.16.0.60/32 y cual-
quier destino
access-list 120 permit ip host 172.16.0.60 any
232
A continuación definimos nuestra política mediante pares
de instrucciones "match"-" set" (condición-acción):
route-map trafico_especial
match ip address 120
set ip next-hop 192.168. 0.201
Y terminamos aplicando la política en la interfaz corres-

pondiente
interface Ethernet0
ip policy route-map trafico_especial
Las posibilidades de los mapas de rutas son inmensas, pero

este tipo de encaminamiento basado en reglas consume más
recursos del router y puede llegar a ralentizar el tráfico. Vemos
a continuación algunas de las posibilidades de configuración
de condiciones
("match"):
Sagan(config-route-map)# match ?
interface Match first hop interface of route
ip IP specific information
length Packet length
metric Match metric of route
route-type Match route-type of route
tag Match tag of route
Concretamente para ip:

Sagan(config-route-map)# match ip ?
address Match address of route or match packet
next-hop Match next-hop address of route
route-source Match advertising source address of route
Y ahora algunas de las posibilidades de configuración de

acciones ("set"):
Sagan(config-route-map)# set ?
default Set default information
interface Output interface
ip IP specific information
level Where to import route
metric Metric value for destination routing protocol
metric-type Type of metric for destination routing protocol
De nuevo para ip:

Sagan(config-route-map)# set ip ?
default Set default information
next-hop Next hop address
precedence Set precedence field
tos Set type of service field
233
5.9. Passive interface
La orden "passive interface interface" desha-
bilita el protocolo de enrutamiento en la interfaz indicada.
Dependiendo del protocolo esta deshabilitación puede ser
parcial (IGRP, RIP) o total (EIGRP, OSPF). Se entiende por
deshabilitación parcial que el protocolo escuche actualizaciones
por dicha interfaz pero no anuncie nada. Por deshabilitación
total queremos indicar que el protocolo deja de funcionar en
dicha interfaz (ni aprende ni propaga actualizaciones).
router rip
passive-interface Bri0
passive-interface Ethernet0
passive-interface Serial0
5.10. Redistribución y filtrado

Puede configurar rutas estáticas en un router y encon-
trarse con el problema de que el resto de routers no conoce
la información relativa a ese encaminamiento. Puede añadir
la redistribución a un protocolo de enrutamiento dinámico
como EIGRP e informar al resto de la red de la existencia de
dichas rutas:
ip route 172.16.5.0 255.255.255.0 10.1.1.2
ip route 172.16.16.0 255.255.255.0 10.1.1.2
router eigrp 10
redistribute static
Los routers que compartan el sistema autónomo 10 de

EIGRP aprenderán las rutas estáticas para alcanzar las redes
172.16.5.0/24 y 172.16.16.0/24. Con ayuda de los mapas de
rutas que vimos en el punto 4.4 podemos controlar de forma
muy precisa la información que queremos redistribuir:
router eigrp 10
redistribute static route-map REDES
route-map REDES permit 10

match ip address 99
ip route 172.16.5.0 255.255.255.0 10.1.1.2

ip route 172.16.16.0 255.255.255.0 10.1.1.2
234
Ahora el router sólo anunciará a sus vecinos EIGRP acerca
de la ruta hacia la red 172.16.5.0/24.
Puede ocurrir que tenga varios protocolos de enrutamiento
funcionando en un mismo router y necesite intercambiar in-
formación entre los distintos procesos. Al redistribuir unos
protocolos en otros necesitamos asignar una métrica a las rutas
importadas que sea. El siguiente ejemplo muestra cómo im-
portar información EIGRP a RIP. Hemos dado a estas rutas una
métrica RIP de valor 1. En general conviene dar métricas RIP
con valores bajos: más de 15 en RIP significa inalcanzable:
router rip
redistribute eigrp 99
default-metric 1
IGRP y EIGRP usan una métrica compuesta de 5 valores:

ancho de banda, retraso, fiabilidad, carga y tamaño de pa-
quete. Para indicar a IGRP/EIGRP que métrica deben dar a las
rutas importadas de otros protocolos (RIP en nuestro ejemplo)
usamos "default-metric 1000 100 255 1 1500"
router eigrp 99
redistribute rip
default-metric 1000 100 255 1 1500
También podríamos haber configurado lo anterior de esta

otra forma:
router eigrp 99
redistribute rip metric 1000 100 255 1 1500
Si no se especifica una métrica OSPF asigna una predeter-

minada de 20 a todos los protocolos excepto BGP, que recibe
una métrica de 1. En el siguiente ejemplo asignamos a las rutas
provenientes de eigrp 99 una métrica de 100. El uso opcional
de "subnets" permite permite distribuir subredes en OSPF.
router ospf 1
redistribute eigrp 99 metric 100 subnets
La redistribución prepara el terreno en el que pueden

aparecer problemas como bucles de enrutamiento y mala
convergencia. En general no debemos anunciar la informa-
ción adquirida por un proceso de enrutamiento por medio
del mismo proceso de enrutamiento (es la misma idea que
subyace al horizonte dividido). Por medio de la orden "dis-
tribute-list" podemos filtrar redes de las actualizaciones
que mandamos o recibimos por una interfaz determinada. Si
configuramos lo siguiente el proceso EIGRP 99 sólo aceptará
235
las actualizaciones que entren por la interfaz serial1 que pasen
el filtro impuesto por la lista de acceso 10 (denegar la red
192.168.10.0/24, permitir todo lo demás).
router eigrp 99
distribute-list 10 in serial1
access-list 10 deny 192.168.10.0 0.0.0.255
access-list 10 permit any
Por medio de "distribute-list" también podemos im-

plementar políticas para que determinados routers aprendan
y no hablen mientras que otros routers hablen pero no escu-
chen, con el objeto de reducir las tablas de rutas de los sistemas
centrales.
5.11. Resumen
Aunque los protocolos de enrutamiento deben resolver en
poco tiempo los complejos problemas que hemos apuntado
en los apartados anteriores, la configuración básica de estos
mecanismos en los routers Cisco es tan sencilla como habilitar
el protocolo de enrutamiento mediante la orden "router
protocolo" y especificar las redes que queremos anunciar
mediante la orden "network red". Generalmente habrá que
configurar cada router para que anuncie las redes a las que se
encuentre directamente conectado.
Podremos comprobar que un protocolo de enrutamiento
está correctamente configurado consultando la tabla de rutas
mediante la orden "show ip route" (la tabla muestra como ha
aprendido cada rutas mediante un código de letras). También
podemos verificar la configuración del router mediante "show
runn", ver con un "show ip protocols" que el router anuncia
las redes correctamente. Finalmente podemos comprobar que
hay conectividad usando "ping" y "traceroute", o probando
a conectarnos con un sistema remoto mediante "telnet".
236
6
Seguridad
"Hasta los paranoicos tienen enemigos"

Cheswick & Bellovin en "Firewall & Internet Security".
Las redes de comunicaciones dependen para su funciona-

miento de los routers. Al mismo tiempo los routers a menudo
están situados en las fronteras de las redes, conectados a sis-
temas desconocidos y expuestos a ataques. Dado que las redes
transportan información económica y personal es necesario
tomar las medidas necesarias para preservar la disponibilidad,
autenticidad, integridad y confidencialidad de la información
que transportan. Las medidas de seguridad que adoptemos
servirán también para evitar que nuestras redes se conviertan
en la plataforma desde la cual pueda orquestarse un ataque
contra otras redes. El objetivo del presente capítulo es dar
unas indicaciones que permitan alcanzar un nivel de segu-
ridad razonable, estableciendo contraseñas, deshabilitando
servicios innecesarios y controlando el tráfico en función de
sus características. Este tipo de protección básica hará desistir
a la mayoría de los atacantes casuales, que abandonarán sus
intentos e irán por otros objetivos más asequibles.
6.1. Medios, Motivos y Oportunidades

En los ataques informáticos confluyen medios, motivos y
oportunidades.
Los medios (las herramientas y los conocimientos necesarios
para su uso), están al alcance de cualquiera. Existen múltiples
listas de herramientas de seguridad informática, muchas de
doble uso, que pueden obtenerse con facilidad. La lista man-
237
tenida por el autor del scanner "nmap", Gordon "Fyodor" Lyon
(http://sectools.org/) es posiblemente una de las más com-
pletas. Por otro lado existen distribuciones de Linux de tipo
"LiveCD" con las que basta arrancar un PC y sin necesidad de
instalar nada se dispone de un entorno perfectamente funcional
con múltiples herramientas.
Nota: BackTrack (Figura 6.1) es una distribución GNU/

Linux "LiveCD" de gran popularidad en la comunidad de la
seguridad informática. BackTrack deriva de la unión de dos
distribuciones orientadas a la seguridad, Auditor y WHAX,
que a su vez son evoluciones de Whoppix (WhiteHat Knoppix).
Todas ellas incluyen una larga lista de herramientas de
seguridad listas para usar, entre las que destacan numerosos
scanners de puertos y vulnerabilidades, archivos de exploits,
sniffers, así como herramientas de análisis forense, auditoría
Wireless y específicas para auditar o directamente atacar
sistemas Cisco. BackTrack puede obtenerse de http://www.
remote-exploit.org/index.php/BackTrack.
Figura 6.1. Backtrack.
Con cientos de millones de personas conectadas a la red, los

motivos son múltiples. Aunque una de las principales motiva-
238
ciones que subyace al delito informático es el factor económico
(fraude, sabotaje, espionaje industrial), también hay elementos
políticos, religiosos y éticos englobados en el denominado
"hacktivismo" (la utilización de herramientas digitales ilegales
o legalmente ambiguas persiguiendo fines políticos mediante
desfiguraciones de webs, redirecciones, ataques de denega-
ción de servicio, robo de información…). Tampoco hay que
ignorar los aspectos relacionados con el vandalismo y la pura
inmadurez psicológica.
En cuanto a las oportunidades ahora que el acceso a la red
se ha universalizado son mayores que nunca, lo que unido a
la creciente complejidad de los sistemas y a la dificultad de
mantenerlos perfectamente configurados y parcheados con
las últimas revisiones proporciona múltiples oportunidades
a los atacantes.
La combinación de herramientas, información, motiva-
ciones diversas y globalización a la hora de acceder a la red
hacen de los intentos de intrusión informática algo inevitable.
La vigilancia y prevención constituyen una necesidad ante la
proliferación de amenazas contra la seguridad en la red.
Puede hacerse una primera clasificación de las amenazas
atendiendo al flujo de información y a como los distintos ata-
ques atentan contra la confidencialidad, integridad y disponi-
bilidad de los datos y recursos.
Vemos en la figura 6.2 el flujo normal de información entre
el emisor y el receptor.
Figura 6.2. Flujo de comunicación normal.
La interrupción (figura 6.3) es una agresión a la disponibi-

lidad de un recurso mediante la destrucción o inutilización del
mismo. El corte de una línea de fibra óptica o la saturación de
un enlace por medio de grandes cargas de tráfico son ejemplos
de este tipo de amenazas. El uso de líneas de respaldo es una
medida de protección contra este tipo de ataques.
239
Figura 6.3. Interrupción.
La intercepción (figura 6.4) es una amenaza a la confiden-

cialidad. La captura de tráfico mediante el uso de capturadotes
tráfico o sniffers es un ejemplo de estos ataques. La encriptación
de la información sensible es una medida de protección contra
estas agresiones.
Figura 6.4. Intercepción.
La fabricación (figura 6.5) es una amenaza a la autenticidad.

El secuestro (hijacking) de sesiones TCP es un ejemplo de este
tipo de ataque, en el que el atacante es capaz de deducir la
secuencia de identificadores TCP y sustituye al emisor en la
conversación. El uso de canales de comunicación encriptados
es una medida de protección contra estas agresiones.
240
Figura 6.5. Fabricación.
La modificación (figura 6.6) es una amenaza a la integridad.

El envío de paquetes con información falsificada acerca de su
origen, técnica conocida como IP spoofing, es un ejemplo de
este tipo de ataque, que saca partido del hecho de que la des-
cripción original del protocolo TCP/IP no posee mecanismos
de autentificación. La verificación sistemática del origen de
los paquetes impidiendo entrar en nuestra red paquetes cuya
dirección de origen sea la de nuestra red es una medida de
protección contra este tipo de agresiones.
Figura 6.6. Modificación.
También podemos clasificar las amenazas atendiendo a

su grado de estructuración: las amenazas no estructuradas
provienen de individuos con poca experiencia que usan he-
rramientas disponibles en la red (script kiddies) y las amenazas
241
estructuradas provienen de atacantes motivados y con mayores
competencias técnicas, que les permiten adaptar las herra-
mientas disponibles y e incluso desarrollar las suyas propias
En función del origen de la amenaza podemos hablar de
amenazas externas que provienen de individuos u organiza-
ciones ajenas a la empresa atacada y suelen usar Internet para
ganar acceso y amenazas internas que provienen de sujetos con
acceso a la red y autorización para trabajar sobre la misma.
Nota: El 2 de noviembre de 1988 un programa diseñado por

el estudiante Robert Morris Jr. que explotaba varias vulnera-
bilidades de los sistemas UNIX se descontroló atacando una
incipiente Internet en un ataque que en menos de 6 horas
dejó fuera de servicio unos 5000 sistemas, en aquel momento
el 10 por 100 de Internet, y afectando gravemente al resto
de la red. Este incidente, conocido como el Internet Worm
(Gusano Internet), marcó un antes y un después en materia
de seguridad en Internet. Entre las consecuencias directas
del ataque estuvo la aparición de los Grupos de Respuesta a
Emergencias Informáticas o CERT (Computer Emergency
Response Team), del que el RedIRIS CERT forma parte
(http://www.rediris.es/cert/).
6.2. Listas de acceso

Las listas de acceso son el mecanismo de los routers Cisco
para diferenciar los flujos de paquetes que pasan por las inter-
faces del router. Si las redes locales fueran ciudades y los routers
sus aeropuertos, podríamos decir que las listas de acceso cum-
plen con la función de los controles de aduanas, decidiendo si
los paquetes pueden viajar de una red a otra en función de la
política vigente: origen, destino, momentos, prioridades…
Nota: Las listas de acceso tienen muchos otros usos, no todos

relacionados con la seguridad: se pueden usan para priorizar
ciertos flujos de tráfico sobre otros (PQ, priority queing),
para enrutar en función de parámetros como el origen o del
protocolo (route map o mapas de ruta), para controlar la in-
formación del enrutamiento (distribute list) o para especificar
el tráfico "interesante" en una llamada bajo demanda (Dial
on Demand Routing, DDR), entre otras aplicaciones. En este
apartado nos centramos en el uso más frecuente de las listas
de acceso, el filtrado de tráfico.
242
Las reglas que componen las listas de acceso tienen tres
partes: un número que identifica la lista, una instrucción deny
o permit y una condición:
access-list número_identificador [permit|deny] condición
El número identifica el tipo de lista y permite que la ha-

gamos referencia en otros lugares de la configuración (por
ejemplo para aplicarla en líneas o interfaces concretas). Las
instrucciones "deny" y "permit" especifican si hay que per-
mitir o negar el tráfico que cumpla la condición especificada
seguidamente: origen de los paquetes, destino, protocolo,
momento del día o de la semana…
Si usamos listas numeradas tendremos que seleccionar el
número de un rango en función del uso que vayamos a hacer
de lista. La tabla 6.1 muestra los tipos de listas y los rangos
que usan.
Tabla 6.1. Tipos de listas de acceso y sus rangos numéricos.

Tipos de listas de acceso Rango numérico
IP Estándar <1-99>
IP Extendida <100-199>
Ethernet. (Tipo de protocolo <0x0-0xFFFF>) <200-299>
DECNet <300-399>
XNS Estándar <400-499>
XNS Extendidas <500-599>
Appletalk <600-699>
Dirección Ethernet (48 bit MAC) <700-799>
Novell <800-899>
Novell Extendida <900-999>
Novel SAP <1000-1099>
Dirección Ethernet (48 bit MAC) – Extendida <1100-1199>
IP Estándar (nuevo rango) <1300-1999>
IP Extendida (nuevo rango) <2000-2699>
Nosotros nos centraremos en las listas de acceso IP, y de

ellas las que usan tienen en cuenta el origen (rango 1-99) y
las listas extendidas que tienen en cuenta el origen, destino y
protocolos (rango 100-199).
243
6.2.1. Listas de acceso estándar
Las listas de acceso estándar son listas de acceso IP que
sólo tienen en cuenta el origen de los paquetes. La sintaxis de
una lista de acceso estándar es "access-list número ac-
ción red". La numeración permitida para este tipo de listas
va del 1 al 99. Las acciones permitidas son permitir (permit) o
denegar (deny). La red especifica el origen de los paquetes a
los que queremos aplicar la opción. Esta red puede ser desde
un equipo concreto a todo el tráfico IP posible. La mejor forma
de comprenderlas es a través de un ejemplo:
Figura 6.7 Red de ejemplo para listas de acceso.
Si queremos que la interfaz serial 0 del router Spade (figura

6.7) rechace los paquetes entrantes que tengan por origen la
red 172.24.0.0, tendremos que crear una lista de acceso
Spade#conf t
Enter configuration commands, one per line
Spade(config)# access-list 1 deny 172.24.0.0
Spade(config)# access-list 1 permit any
y luego aplicarla en la interfaz correspondiente (Serial 0)

Spade(config)# interface serial 0
Spade(config-if)# ip access-group 1 in
Independientemente del destino de los paquetes, la primera

instrucción de la lista de acceso 1 impide el paso a aquellos
paquetes que entren en el router Spade por su interfaz serial 0
que tengan por origen la dirección 172.24.0.0 (al no especificar
244
la máscara en la configuración el router le otorga una corres-
pondiente a su clase natural, la 255.255.0.0). El resto de paquetes
podrá atravesar en sentido de entrada la interfaz dado que no
cumplirán la primera regla y la segunda da permiso a cual-
quier otro paquete (any). Es importante indicar que si llegan
paquetes con origen 172.24.0.0 a otra interfaz del router no
tendrán problemas para atravesarla: la lista sólo está aplicada
en la interfaz serial 0. De hecho, esta lista tampoco tiene ningún
efecto sobre los paquetes que puedan salir por la interfaz serial
0, independientemente de su origen, dado que únicamente
examina los paquetes que entran por dicha interfaz.
Podemos precisar más nuestras listas con ayuda de más-
caras que especifiquen las redes y subredes concretas que
queremos comparar. A las máscaras utilizadas en las listas
de acceso se les llama máscaras comodín (wildcards) y ya las
encontramos al hablar de OSPF. Se configuran de una manera
algo especial: a diferencia de las máscaras de red convencio-
nales, las máscaras comodín usadas en las listas de acceso
usan ceros para indicar la parte relevante (que debe coincidir
exactamente) y unos para indicar la parte cuyo contenido no
se va a comprobar.
Por ejemplo, si tenemos la condición 10.10.10.0 0.0.0.255, al
pasar a binario la dirección y la máscara podemos ver qué parte
de la dirección será tenida en cuenta a la hora de determinar si
un paquete concreto cumple la condición (tabla 6.2).
Tabla 6.2. Direcciones y Máscaras comodín.

Decimal Binario
Dirección 10.10.10.0 00001010.00001010.0000101

0.00000000
Máscara 0.0.0.255 00000000.00000000.0000000
0.11111111
Esta condición selecciona las direcciones que comprenden

desde la 10.10.10.0 hasta la 10.10.10.255, o dicho de otra forma
las direcciones de la forma 10.10.10.x. Por ejemplo la dirección
10.10.9.7 no cumple la condición (el tercer byte de la direc-
ción es distinto en la dirección y en la condición, y este tercer
byte es relevante, tal como se indican los ceros de la máscara
para este tercer octeto) pero la dirección 10.10.10.254 si que
cumpliría las condiciones especificadas por la condición del
ejemplo.
245
El uso adecuado de las máscaras comodín puede ayudarnos
a seleccionar subconjuntos de direcciones. En el siguiente
ejemplo (tabla 6.3) queremos crear una lista de acceso capaz
de seleccionar las redes.
Tabla 6.3. Redes a sumarizar.

Decimal Binario
10.1.32.0/24 00001010.00000001.00100000.0000000
0/11111111.11111111.11111111.00000000
10.1.33.0/24 00001010.00000001.00100001.0000000
0/11111111.11111111.11111111.00000000
10.1.34.0/24 00001010.00000001.00100010.0000000
0/11111111.11111111.11111111.00000000
10.1.35.0/24 00001010.00000001.00100011.0000000
0/11111111.11111111.11111111.00000000
10.1.36.0/24 00001010.00000001.00100100.0000000
0/11111111.11111111.11111111.00000000
10.1.37.0/24 00001010.00000001.00100101.0000000
0/11111111.11111111.11111111.00000000
10.1.38.0/24 00001010.00000001.00100110.0000000
0/11111111.11111111.11111111.00000000
10.1.39.0/24 00001010.00000001.00100111.00000000
/11111111.11111111.11111111.00000000
Está claro que la diferencia radica en el tercer octeto. Si exa-

minamos la columna correspondiente al mismo en su forma
binaria, separando las partes variables de las fijas.
Tabla 6.4. Sumarizando subredes.

Decimal Binario
32 00100 000
33 00100 001
34 00100 010
35 00100 011
36 00100 100
37 00100 101
38 00100 110
39 00100 111
00000 111
246
En la tabla 6.4 podemos observar que la parte común a
todas estas direcciones es la que comprende los cinco bits
de la derecha (los que ponemos a cero en la última fila. La
dirección de red que comprende las subredes del ejemplo
será en binario
00001010.00000001.00100000.00000000
usando para construirla los bits comunes a todas las subredes

y el resto a cero. Construiremos la máscara inversa o comodín
usando ceros para la parte que queremos seleccionar y unos
para la que nos es indiferente que cambie:
00001010.00000001.00100000.00000000
00000000.00000000. 00000111.11111111
El valor del tercer octeto de la máscara es en este caso

00000111, y pasado a decimal es 7. Para el conjunto de redes
de nuestro ejemplo la máscara 0.0.7.255 es capaz de seleccionar
todas las subredes.
En el ejemplo siguiente, permitiremos la entrada por la
interfaz serial 0 de aquellos paquetes que provengan de las
redes 172.16.5.0/24 y 172.16.6.0/24, denegando el resto del
tráfico (figura 6.8):
Figura 6.8. Red de ejemplo para listas de acceso.
Spade #conf t
Spade (config)# access-list 2 permit 172.24.5.0 0.0.0.255
Spade (config)# access-list 2 deny any
Spade (config)# interface serial 0
Spade (config-if)# ip access-group 2 in
247
La lista de acceso 2 está compuesta por tres reglas que se
procesan en el mismo orden en el que han sido configuradas.
Tan pronto como un paquete cumple una de las condiciones
de la lista, se permite o deniega su paso inmediatamente. Se
trata de un mecanismo de tipo "la que primero encaje" (first
fit), no "la que mejor encaje" (best fit).
Si ve la máscara comodín (0.0.0.255) como una especie de
antimáscara de subred, va por el buen camino: la máscara
comodín es exactamente la inversa de la que usaría para es-
pecificar la máscara de subred. Al filtrar una clase de subred
completa esta operación es sencilla: 172.16.5.0/24 (172.16.5.0
255.255.255.0) se traduciría en 172.16.5.0 0.0.0.255 (hemos cam-
biado todos los unos por ceros y todos los ceros por unos).
Pero al igual que con las máscaras de subred, las máscaras
comodín pueden resultar poco obvias de primeras. La tabla
6.5 muestra la relación existente entre las máscaras de subred
y su correspondiente máscara comodín.
Tabla 6.5. Relación entre máscaras de

subred y máscaras comodín (wildcard masks).
A B C D
0 00000000 11111111 255

128 10000000 01111111 127
192 11000000 00111111 63
224 11100000 00011111 31
240 11110000 00001111 15
248 11111000 00000111 7
252 11111100 00000011 3
254 11111110 00000001 1
255 11111111 00000000 0
La tabla 6.5 tiene 4 columnas. Las columnas A y B mues-

tran las máscaras de subred en decimal y binario respecti-
vamente. Las filas C y D muestran las máscaras comodín en
binario y decimal respectivamente. Si tenemos la máscara
255.255.224.0 (una /19, o 19 unos seguidos de 13 ceros), la
máscara comodín será la 0.0.31.255 (255 se convierte en 0, 224
en 31 y el 0 en 255.
Veamos otro ejemplo: ahora queremos permitir en el serial
0 la salida del tráfico con origen en las redes 172.24.16.0/20,
248
172.24.32.0/20 y 172.24.48.0/20. Dado que la máscara de su-
bred /20 equivale a la máscara 255.255.240.0 usando la tabla 6.5
podemos comprobar que la máscara comodín es la 0.0.15.255,
quedando la configuración:
Spade #conf t
Spade (config-if)# ip access-group 3 out
Como queremos comprobar el tráfico de salida, aplicamos

la lista 3 en la interfaz serial, de salida (out). En general, cal-
cular la máscara comodín consiste en pasar la correspondiente
máscara de subred a binario, invertirla y volverla a pasar a
decimal. Tenga en cuenta que el router no realiza chequeos
acerca de la consistencia de la máscara comodín similares a
los que hace con la máscara de subred.
Ahora queremos modificar la configuración del ejemplo
anterior. Vamos a permitir el paso de la red 172.24.64.0/20,
configurando:
Spade #conf t
Pese a haber añadido esta línea en la configuración, los

usuarios pertenecientes a esta red nos remitirán sus quejas
cuando intenten pasar a través de la interfaz dónde la lista 3
está aplicada. Un "show access-list" o un "show running"
nos revelará lo que está pasando:
Nuestra nueva instrucción se ha situado detrás del "deniega

todo" (deny any) de la cuarta instrucción. La instrucción any
equivale a la dirección 0.0.0.0 255.255.255.255. Como las listas
se procesan por orden, nunca llegará a examinarse la quinta
instrucción (la cuarta deniega todo lo que no haya encajado
con las tres primeras condiciones).
Hay que tener en cuenta que la lista siempre contiene al
final la denegación implícita: si tenemos una lista que permite
249
el tráfico con origen en la red X, podemos interpretar esa misma
lista como que deniega todo menos lo que tenga origen la red
X. Son dos formas de expresar lo mismo, pero en determinadas
circunstancias este matiz cobra un sentido inesperado: ima-
ginemos que queremos configurar desde la máquina 10.0.0.2
conectada con el router a través de la red local una lista de
acceso que deje entrar en la interfaz ethernet lo que tenga por
origen las máquinas 10.0.0.2 y 10.0.0.3. Para ello necesitamos
las siguientes órdenes:
Sagan(config)# interface ethernet 0
Sagan(config)# ip access-group 1 in
Sagan(config)# access-list 3 permit host 10.0.0.3
Antes de nada hay que aclarar un atajo que hemos usado:
"host 10.0.0.3" equivale a "10.0.0.3 0.0.0.0", y sirve
para especificar una máquina concreta. Si configuramos lo an-
terior en ese mismo orden nos llevaremos una sorpresa:
Sagan#conf t
Enter configuration commands, one per line.End with CNTL/Z.
Sagan(config)# interface ethernet 0
Sagan(config-if)# ip access-group 1 in
Sagan(config-if)# exit
No pasaremos de este punto. Nada más procesar la primera

instrucción de la lista de acceso el router rechazará nuestra
máquina al tener ya aplicada la lista a la interfaz por la que
accedemos (en ese punto de la configuración deja pasar lo que
provenga de la IP 10.0.0.3 y denegará todo lo demás). Si hubié-
semos configurado la lista cambiándola de orden (primero la
10.0.0.2 y luego la 10.0.0.3) no nos hubiésemos dado cuenta de
nada. Algunas posibles soluciones para recuperar la conexión:
acceder al router desde la 10.0.0.3, configurar nuestra máquina
con la IP 10.0.0.3, conectarnos al router por consola o resetearlo
(no se ha grabado este cambio).
Una lista de acceso aplicada en una interfaz (con "access-
group") que haya sido borrada (o que no haya sido creada) deja
pasar todo el tráfico. Pero según empecemos a configurar la lista
de acceso, y debido a que siempre al final de la lista hay un deny
any implícito, nada más empezar a configurarla la lista toma un
valor muy restrictivo. Conclusión: antes de tocar una lista de
acceso, desaplicarla de las interfaces donde está siendo usada
negando la instrucción "access-group" en la interfaz:
Spade (config-if)# no ip access-group 1 in
250
Al finalizar de configurar la lista volveríamos a aplicarla
en las interfaces correspondientes. Este ejemplo puede parecer
artificial, pero en la practica es frecuente tener que cambiar la
configuración de varios routers situados en una misma red
local, y es relativamente sencillo dejar colgado un router ju-
gando con las listas de acceso.
Un consejo: si no hay nadie en el lugar donde el router se
encuentra situado podemos usar la orden "reload in mi-
nutos" para programar un reencendido del equipo pasados los
minutos especificados. Por ejemplo, "reload in 10" hará que
el router se resetee en 10 minutos con la última configuración
grabada. Una vez hechos los cambios y comprobado que todo
está correcto podemos cancelar el reencendido con un "reload
cancel". Si se nos cuelga, bastará con esperar a que el router
se resetee con la última configuración estable.
Tampoco se pueden borrar, editar o cambiar líneas concretas
de las listas de acceso. Si probamos la siguiente instrucción:
Spade #conf t
Spade (config)# no access-list 3 permit 172.24.16.0 0.0.15.255
La lista se ha borrado entera (y estamos dejando pasar todo

el tráfico). Para añadir la red 172.24.64.0/20 al ejemplo ante-
rior, debemos borrar la lista entera y volverla a configurar en
el orden adecuado:
Spade #conf t
Spade (config)# no access-list 3
La forma más cómoda de trabajar con listas de acceso es

editarlas con un editor de textos como vi en UNIX o notepad
en Windows y pegarlas en la configuración del router. De
esta forma mantendremos además una copia de seguridad de
nuestras listas en un fichero de texto.
Recuerde que si aplica una lista de acceso en una interfaz
que le está dando en ese momento a Usted acceso al router (un
caso típico, dado que los routers son equipos de red y general-
mente se gestionan de forma remota) es muy fácil crear una
lista de acceso que filtre más de la cuenta, u olvidarse de dar
paso a los paquetes con origen la red local desde la que gestiona
el equipo. Nada más aplicar la lista el router le echará. No se
251
lo tome a mal, es casi como un rito de iniciación. La situación
tiene varios remedios, de los que mencionamos el botonazo,
"reload" y "loopback":
Puede llamar a la delegación remota y pedir que reinicien el
router. Quedará con la configuración que tenía la última vez que
se grabó con "write" o con "copy running startup". Por su-
puesto habrá perdido las últimas configuraciones realizadas.
Una segunda alternativa es el uso de la orden de IOS "re-
load in"o "reload at", por ejemplo "reload in 5" (que
reinicia el router a los 5 minutos) o "reload at 22:15" (que
reinicia el equipo a la hora especificada). Programe un "reload",
haga sus cambios y cancele el reinicio con "reload cancel". El
router le avisará un minuto antes del reinicio. Puede ver como
anda de tiempo con "show reload". La tercera vía es algo más
sofisticada. Sin entrar en muchos detalles, sabiendo la lista con-
figurada, puede crear una interfaz virtual ("loopback inter-
face") con una dirección de las que permite la lista de acceso
(porque... ¿puso un permit, no?) y hacer un telnet extendido al
router, "saltándose" la lista de acceso ("telnet ip_router /
source-interface loopback_número").
Con las listas de acceso se filtra el tráfico: los efectos de
las listas de acceso en la practica son bastante potentes, y los
usuarios que se ven afectados por ellas lo manifestarán de
forma muy clara. En general, antes de hacer cambios en listas
de acceso desaplique la lista de donde esté en uso, cree la lista
con un editor de texto y copiela en el router una vez creada, y
finalmente aplique la lista en la interfaz, línea o proceso donde
tenga pensado usarla.
6.2.2. Listas de acceso extendidas

Las listas de acceso extendidas permiten filtrar tráfico
en función del origen, destino, protocolo, puerto y otros
parámetros. La sintaxis de una lista de acceso estándar es
"access-list número acción protocolo red_origen
puerto_origen red_destino puerto_destino". La
numeración permitida para este tipo de listas va del 100 al
199. Las acciones permitidas son permitir (permit) o denegar
(deny). El protocolo puede ser ip, tcp, udp o icmp. Las redes y
los puertos especifican el origen y el destino de los paquetes a
los que queremos aplicar la opción. De nuevo, la mejor forma
de comprenderlas es a través de algunos ejemplos:
access-list 100 permit ip host 192.168.90.220 192.168.30.0 0.0.0.255
access-list 100 deny ip any any
252
La lista de acceso 100 permite el tráfico IP entre la máquina
192.168.90.220 y cualquier máquina de la red 192.168.30.0/24.
A continuación negamos el resto del tráfico IP. En realidad esta
instrucción no es necesaria dado que el router la añade auto-
máticamente (deny any implícito). Vemos otro ejemplo:
access-list 103 permit tcp any host 192.168.60.10
La lista 103 permite las conexiones TCP con cualquier origen

que tengan por destino la máquina 192.168.60.10. Podemos
especificar aún más esta lista:
access-list 105 permit tcp any host 192.168.60.10 eq 25
access-list 105 permit tcp any host 192.168.60.10 eq 80
La lista 105 permite las conexiones TCP con origen en

cualquier equipo y destino la máquina 192.168.60.10 para los
protocolos que usan el puerto 80 (HTTP, Hyper Text Transfer
Protocol) y el 25 (SMTP, Simple Mail Transfer Protocol). Esta
misma lista se podría escribir de forma simplificada
access-list 105 permit tcp any host 192.168.60.10 eq 25 eq 80
Y de una forma todavía más visual y compacta:

access-list 105 permit tcp any host 192.168.60.10 eq smtp www
Hemos usado en esta última lista los nombres de los pro-

tocolos en vez del número de puerto. En la tabla 6.6 tenemos
los identificadores de los protocolos más corrientes ordenados
por el número de puerto.
Tabla 6.6. Algunos puertos de protocolos y sus identificadores.

Identificador Protocolo Puerto TCP / UDP
Echo Echo 7 TCP/UDP

Discard Discard 9 TCP/UDP
Daytime Daytime 13 TCP
Chargen Character generator 19 TCP
ftp-data FTP data connections 20 TCP
ftp File Transfer Protocol 21 TCP
telnet Telnet 23 TCP
Smtp Simple Mail Transport 25 TCP
Protocol
Time Time 37 TCP/UDP
Whois Nickname 43 TCP
253
Tacacs TAC Access 49 TCP/UDP

Control System
Domain Domain Name 53 TCP/UDP
Service
Bootps Bootstrap Protocol 67 UDP
(BOOTP) server
Bootpc Bootstrap Protocol 68 UDP
(BOOTP) client
Tftp Trivial File Transfer l 69 UDP
Protoco
Gopher Gopher 70 TCP
Finger Finger 79 TCP
www World Wide 80 TCP
Web(HTTP)
hostname NIC hostname server 101 TCP
pop2 Post Office Protocol v2 109 TCP
pop3 Post Office Protocol v3 110 TCP
sunrpc Sun Remote 111 TCP/UDP
Procedure Call
Ident Ident Protocol 113 TCP
nntp Network News l 119 TCP
Transport Protoco
Ntp Network Time Protocol 123 UDP
netbios-ns NetBios name service 137 UDP
netbios-dgm NetBios datagram 138 UDP
service
netbios-ss NetBios session 139 UDP
service
Snmp Simple Network 161 UDP
Management Protocol
snmptrap SNMP Traps 162 UDP
xdmcp X Display Manager 177 UDP
Control Protocol
Bgp Border Gateway 179 TCP
Protocol
Irc Internet Relay Chat 194 TCP
254
Dnsix DNSIX security 195 UDP

protocol auditing
mobile-ip Mobile IP registration 434 UDP
pim-auto-rp PIM Auto-RP 496 TCP/UDP
isakmp Internet Security 500 UDP
Association and
Key Management
Protocol
Biff Biff 512 UDP
Exec Exec 512 TCP
Who Who service 513 UDP
Login Login 513 TCP
ryslog/cmd Syslog (System 514 TCP/UDP
Logger) & Remote
Commands
Lpd Printer service 515 TCP
Talk Talk 517 TCP/UDP
Rip Routing Information 520 UDP
Protocol
Uucp Unix-to-Unix Copy 540 TCP
Program
Klogin Kerberos login 543 TCP
Kshell Kerberos shell 544 TCP
Nota: Puede consultar la lista completa de los "puertos bien

conocidos" en la base de datos que mantiene la IANA (Internet
Assigned Numbers Authority) en la web http://www.
iana.org/assignments/port-numbers.
La siguiente lista de acceso muestra otra interesante posi-

bilidad de las listas extendidas. Si queremos controlar el tipo
de sesiones que puedan empezar desde el exterior debemos
usar una lista como la siguiente:
access-list 110 permit tcp any any eq www
access-list 112 permit tcp any any gt 1023 established
interface serial 0
ip access-group 110 out
ip access-group 112 in
255
Con la lista 110 permitimos el tráfico web saliente. Con
la lista 112 permitimos las respuestas, que serán en puertos
"altos" (mayores que el 1023), y que deben corresponderse con
sesiones establecidas. La orden "established" hace que el
router bloquee aquellas sesiones que no se hayan originado
en nuestra red. Comprobando los bits de la cabecera TCP
permite sólo aquellas sesiones que aparentemente estén ya
establecidas. Estas listas de acceso no proporcionan un nivel
alto de seguridad frente a ataques sofisticados, pero des-
cartan rápidamente tráfico que no debe tener lugar. A estas
listas de acceso se les llama filtros estáticos. Veremos que las
listas de acceso con nombre permiten filtrar dinámicamente
el tráfico, siguiendo la pista a las sesiones TCP en marcha en
un momento dado.
Para las listas de acceso extendidas valen las mismas ob-
servaciones hechas acerca de las listas estándar: se procesan
en el mismo orden en el que están configuradas, la primera
condición que encaja es la que permite o deniega el tráfico
sin que se continúe procesando la lista, al configurar una
lista el router se añade automáticamente la denegación im-
plícita (deny any) y si intentamos borrar parte de la lista la
borraremos entera.
6.2.3. Listas de acceso con nombre

Las listas de acceso con nombre permiten identificar los
filtros utilizados de una forma más descriptiva, terminan con
la limitación artificial que imponen los rangos numéricos y
ofrecen nuevas posibilidades de configuración cómo el filtrado
dinámico. Otra ventaja de las listas de acceso con nombre es
que permiten eliminar entradas concretas sin necesidad de
borrarla entera y volver a a configurar (aunque no podremos
cambiar el orden de la lista).
Para crear una lista con nombre usaremos la instrucción "ip
access-list tipo nombre" donde tipo puede ser "stan-
dard" o "extended" y nombre la denominación de nuestra
lista, seguida de nuestras reglas permit y deny:
ip access-list extended filtro
permit ip host 192.168.58.153 host 192.168.58.154
permit ip 192.168.37.0 0.0.0.255 host 192.168.114.17
permit ip 192.168.2.0 0.0.0.255 host 192.168.114.17
permit udp 192.168.40.0 0.0.1.255 host 192.168.184.49 eq 1701
permit udp 192.168.158.0 0.0.1.255 host 192.168.184.49 eq 1701
deny ip any any
256
Se aplican de forma similar a las listas de acceso vistas
hasta ahora.
interface Ethernet0
ip access-group filtro in
Este tipo de listas permiten filtrados dinámicos:

ip access-list extended filtro_salida
permit tcp any any reflect tabla_estado_tcp
ip access-list extended filtro_entrada
evaluate tabla_estado_tcp
interface serial 0
ip access-group filtro_salida out
ip access-group filtro_entrada in
Con estas instrucciones hemos creado dos filtros: el de salida

permite el tráfico TCP y crea una tabla de estado, que llamamos
tabla_estado_tcp, que será usada por el router para seguir la pista
a las sesiones TCP establecidas. El filtro de entrada evalúa la tabla
de estados para decidir si el tráfico entrante se corresponde a
una entrada en dicha tabla, en cuyo caso es permitido. Este tipo
de listas acerca las posibilidades de los routers a las de los cor-
tafuegos (firewalls). Podemos comprobar las listas aplicadas de
entrada (Inbound) y de salida (Outgoing) a una interfaz concreta
con "show ip interface interfaz":
Sagan#sh ip int se 0
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is filtro_salida
Inbound access list is filtro_entrada
[…]
6.2.4. Controlando el acceso al router

Podemos usar las listas de acceso no sólo para controlar
el tráfico que pasa a través del router sino el que va al router
mismo. Aplicando las listas de acceso a las líneas (CON, VTY,
AUX) podemos especificar el tráfico "legal":
access-list 1 permit host 10.0.0.2
line vty 0 4
access-class 1 in
257
Estas instrucciones sólo permiten acceder al router vía
telnet desde las máquinas cuyas direcciones IP son 10.0.0.2
o 10.0.0.3. Para aplicar la lista de acceso a las líneas debemos
utilizar la instrucción "access-class", a diferencia de la
instrucción "access-group" que es la empleada para aplicar
listas a las interfaces.
Nota: mediante las listas de acceso podemos controlar ciertos

paquetes que no deberían circular por nuestra red. Por ejemplo,
nunca deberíamos dejar entrar a nuestra red paquetes cuyo
origen sea nuestra propia red. Además, e independientemente
de su origen, únicamente deberían poder entrar en nuestra red
paquetes que tengan por destino direcciones de nuestra red.
Esto se debe a que los usuarios locales suelen tener privilegios
y acceso a servicios a los que una máquina externa puede in-
tentar acceder haciéndose pasar por un sistema de la red local.
En el sentido de salida, no debemos dejar salir paquetes cuya
dirección de origen no pertenezca a nuestra red. Esto hace que
desde nuestra red sea más difícil originar un ataque.
6.2.5. Ejemplos
Repasemos las posibilidades de las listas de acceso basán-
donos en la red de la figura 6.9.
Figura 6.9. Red de ejemplo.
Podemos realizar un filtrado extendido, por ejemplo para

dejar pasar los paquetes con origen en la LAN del router A
hostname RouterB
!
interface ethernet0
ip access?group 101 in
!
access?list 101 permit ip 10.208.60.0 0.0.0.255 10.208.48.0 0.0.0.255
258
Con la orden show line puede ver las líneas de acceso al
router, tales como las líneas virtuales (VTY), el puerto de con-
sola (CON), el puerto Auxiliar (AUX) y las líneas Asíncronas
(ASYNC). Podemos filtrar todas estas líneas y puertos por
medio de la instrucción access-class. La siguiente lista permite
el acceso por los cinco terminales virtuales (del 0 al 4) a aquellas
máquinas que tengan por origen la LAN de A
access?list 20 permit 10.208.60.0 0.0.0.255
access?list 20 deny any
!
line vty 0 4
access-class 20 in
login
Si queremos filtar el acceso Telnet (puerto 23) al routerC:

<Listados>hostname RouterC
!
interface serial0
!
access?list 105 deny tcp any any eq 23
access?list 105 permit ip any any
Queremos dejar navegar por internet , pero poder hacer

telnet y acceder al correo:
hostname RouterB
!
interface Serial0
!
access?list 120 permit tcp any any eq www
access?list 120 permit tcp any any eq telnet
access?list 120 permit tcp any any eq smtp
access?list 120 permit tcp any any pop3
Una lista como la anterior no dejaría pasar el tráfico ftp,

por ejemplo. A veces podemos ser víctimas de un ataque de
denegación de servicio distribuido, por ejemplo siendo inun-
dados con peticiones ping (ICMP) de muy diversos origenes.
Probemos con lo siguiente:
hostname RouterC
!
interface serial0
!
access?list 130 deny icmp any any
259
Un uso muy interesante es el de la instrucción log, si po-
nemos
access?list 130 deny icmp any any log
quedarán registrados en el log del router ("show logg") todos

los origenes y destinos de los paquetes que encajan con la con-
dición. Podemos convertir el router en un sencillo analizador
de tráfico con un par de instrucciones:
hostname RouterB
!
interface serial0
ip access?group 150 out
!
access?list 140 permit ip any any log
access?list 150 permit ip any any log
Más ejemplos: con listas de acceso horarias podemos con-

trolar el uso de determinados servicios en función de la hora
time-range bloquear-internet
periodic weekdays 8:30 to 17:45
!
access?list 150 deny any any eq www time-range bloquear-internet
access?list 150 permit any any
!
interface ethernet0
A veces queremos que en función del origen los paquetes

vayan por una ruta (es distinto a usar rutas estáticas, porque
estas miran el destino, no el origen de los paquetes). Esto se
logra mediante el policy routing, un ejemplo del cual vemos
en ña siguiente configuración que hace que los paquetes
que llegan por la interfaz serial 0 sean reenviados al router
10.208.48.15
access-list 120 permit ip 10.208.60.0 0.0.0.255 any
!
route-map AL_FIREWALL permit 10
match ip address 120
set ip next-hop 10.208.48.15
!
interface serial 0
ip policy route-map AL_FIREWALL
Las listas de acceso sirven también para especificar el tráfico

interesante capaz de lanzar una llamada bajo demanda, por
ejemplo tipo RDSI:
260
interface Dialer1
dialer-group 1
!
dialer-list 1 protocol ip list 8
El 1 de la instrucción "dialer-group 1" conecta con el 1

de la orden "dialer-list 1", que en nuestro caso permite
lanzar aquellas llamadas que cumplan con la condición expre-
sada en la lista de acceso 8.
Otra interesante aplicación es el uso de listas de acceso en
la redistribución de rutas entre protocolos de enrutamiento.
Por ejemplo, la siguiente configuración propagará junto con
los anuncios de enrutamiento EIGRP las rutas estáticas confi-
guradas en el router que encajen con la condición expresada
en la lista de acceso 10:
router eigrp 1
redistribute static route-map filtro
!
route-map filtro permit 10
match ip address 10
Sobre el protocolo de traducción de direcciones NAT

(Network Address Translation) hablaremos en detalle en el capí-
tulo 7, pero de momento podemos ir viendo como mediante el
uso de listas de acceso se especifica el origen de los paquetes a
traducir, en nuestro ejemplo se procesarán mediante NAT los
paquetes que encajen con la lista de acceso 9, y serán traducidos
a una dirección del pool denominado TRADUCCION (que
consta de una única dirección "pública", la IP 152.24.58.254):
ip nat pool TRADUCCION 152.24.58.254 152.24.58.254
netmask 255.255.255.0
ip nat inside source list 9 pool TRADUCCION
!
ip nat inside
!
interface serial 0
ip nat outside
6.3. Autenticación
Una medida básica de seguridad consiste en solicitar un
nombre (username) y una contraseña (password) a los usuarios
que acceden al router. La combinación de nombre y contraseña
cumple una doble función: por un lado pide al usuario que se
261
identifique, y por otro, desafía al usuario a demostrar que es
quien dice ser.
Una buena política de elección de contraseñas debe estar
en la base de nuestra estrategia de seguridad. Existen ciertas
contraseñas que no son adecuadas por predecibles: el propio
nombre de usuario (escrito del derecho o del revés), la fecha
de nacimiento o el número de teléfono son ejemplos de claves
débiles. Tampoco es conveniente usar ciertos pares de nombre/
contraseña del tipo cisco/cisco. La peor contraseña es la que
no se pide en absoluto.
Las contraseñas deben tener una longitud mínima, y en
función del nivel de privilegios al que den acceso la longitud
debe variar. Así, una contraseña normal debe tener un mínimo
de 7 caracteres, pero una contraseña que dé acceso al nivel
privilegiado debe tener una longitud mayor. La contraseña
debe estar compuesta por una mezcla de letras (idealmente
mayúsculas y minúsculas) y números. La edad de la contra-
seña (el tiempo durante el cual es válida) también es un factor
importante. Hay que tener en cuenta que una frecuencia de
cambio de contraseñas muy alta hace que los usuarios anoten
las claves, generalmente cerca de los terminales donde las usan.
Expirada la contraseña, el usuario no debería poder volver a
usar la misma hasta haber elegido al menos una cierta cantidad
de contraseñas distintas (esto implica mantener un histórico
de contraseñas por usuario).
Lo mejor es usar contraseñas que no aparezcan escritas en
ninguna parte (lo que las hace más resistentes a los llamados
"ataques de diccionario"). Un truco que permite crear contra-
señas eficaces consiste en elegir una frase ("El buey solo bien se
lame"), y tomar las iniciales de las palabras ("ebsbsl"). Podemos
fortalecer la contraseña alternando el uso de mayúsculas y mi-
núsculas ("EbSbSl") o insertando números ("E1b2S3b4S5l").
De poco sirve proteger el acceso al router con contraseñas
si éste no está protegido "físicamente" de forma adecuada.
Cualquiera que tenga acceso físico al router puede saltarse
la protección aplicando el procedimiento de recuperación de
contraseñas (Password Recovery Procedure), del que hablamos en
el capítulo 3 y de nuevo en los apéndices del libro. Los detalles
específicos varían según el modelo de router, pero para hacer
uso de este recurso es preciso tener acceso físico al router.
Menos conocido es que algunos modelos disponen de un
comando que permite deshabilitar la recuperación de contra-
señas. Los dispositivos permanecen accesibles a los administra-
dores que tengan las credenciales correctas, pero si se pretende
262
recuperar el acceso de root (level 15), al realizar un Password
Recovery Procedure se borra la configuración del dispositivo. Se
trata de un comando no documentado y por estar considerado
peligroso se encuentra escondido de la ayuda contextual:
R1(config)# no service pass?
password-encryption
R1(config)# no service password-recovery
WARNING:
Executing this command will disable password recovery mechanism.
Do not execute this command without another plan for password recovery.
Are you sure you want to continue? [yes/no]: y
R1(config)# ^Z
R1# reload
Proceed with reload? [confirm]
System Bootstrap, Version 12.2(8r)T2, RELEASE SOFTWARE (fc1)
TAC Support: http://www.cisco.com/tac
c3725 processor with 262144 Kbytes of main memory
Main memory is configured to 64 bit mode with parity disabled
Readonly ROMMON initialized
PASSWORD RECOVERY FUNCTIONALITY IS DISABLED
...
Deshabilitar el mecanismo de recuperación de contraseñas

puede añadir un nivel extra de seguridad, pero es preciso
tener copias de seguridad de las configuraciones de los dis-
positivos.
6.3.1. Creación de cuentas en el router

Para crear un usuario y darle una contraseña usaremos la
orden "username":
username nombre password contraseña
Para conseguir que el router utilice la información almace-

nada en las órdenes username configuraremos en las líneas de
acceso al router la orden "login local":
line vty 0 4
login local
Es necesario especificar local si queremos que el router use

los usuarios y claves configurados en el router mediante la
orden "username". Tenga en cuenta que si configura "login
local" sin dar ningún par username/password al router no
podrá conectar con el mismo (obtendrá un "% Login invalid"
por respuesta).
Podemos especificar con mayor detalle el nivel de privi-
legios que queremos dar a un usuario concreto. El router nos
263
ofrece 16 niveles de acceso, que podemos especificar mediante
"privilege" al especificar el password:
username jos privilege 15 password dashiell
username ornitorrinco privilege 5 password samuel
username AluminiuM privilege 1 password hammett
username oscar privilege 0 password tulip
username roberto nopassword
Así, al acceder al router, Jos tendrá acceso total a los recursos

del sistema, Ornitorrinco podrá realizar algunas tareas de ope-
ración en el router pero no todas, AluminiuM entrará en modo
usuario ">" y podrá, por poner un ejemplo, hacer ping para
verificar la conectividad, pero el ping no podrá ser extendido,
y Oscar apenas podrá hacer otra cosa que desconectarse del
router. Roberto es un ejemplo de una mala política de contra-
señas: accede directamente al sistema.
Podemos consultar nuestro nivel de privilegios con la orden
"show privilege":
Sagan#sh privilege
Current privilege level is 5
Ahora que cada usuario tiene su nombre podemos ver quién

está conectado al router con la orden "show users":
Sagan>sh users
* 0 con 0 idle 00:00:00
2 vty 0 manolo idle 00:01:53 10.0.0.2
4 vty 2 juan idle 00:02:08 10.0.0.2
El asterisco indica cuál es nuestra sesión (en este ejemplo

estamos conectados al router por el puerto de consola, con 0).
Podemos mandar un mensaje al usuario del terminal virtual
2 (Juan, en el vty 2) con la orden "send":
Sagan#send vty 2
Enter message, end with CTRL/Z; abort with CTRL/C:
Necesito cambiar la IP de la interfaz BRI. Avísame cuando acabes.^Z
Send message? [confirm] y
El mensaje le aparecerá a Juan en su terminal:

Sagan>
***
***
*** Message from tty0 to tty4:
***
Necesito cambiar la IP de la interfaz BRI. Avísame cuando

acabes.
264
También podemos enviar un mensaje a todos los usuarios
conectados (similar a la orden "wall" de Unix):
Sagan#send vty *
Enter message, end with CTRL/Z; abort with CTRL/C:
En 2 minutos vamos a proceder con un reload del sistema^Z
Send message? [confirm] y
Los nombres de usuario nos permiten saber quién hace
qué y cuándo:
sagan#clear counter
Clear "show interface" counters on all interfaces
[confirm] y
Sagan#
*Mar 1 00:05:09.787: %CLEAR-5-COUNTERS: Clear counter on
all interfaces by antonio on vty0 (10.0.0.2)
6.3.2. Gestión centralizada de contraseñas

Hemos visto en el apartado anterior que podemos confi-
gurar un router para que mantenga una lista local de usua-
rios y contraseñas ("login local"). Cuando el número de
usuarios crece, este mecanismo de verificación se hace im-
practicable. La solución consiste en usar un sistema central
en el que se almacena la información y consultarlo. Se han
diseñado varios protocolos de control de acceso: Kerberos,
TACACS (Terminal Controller Access Control System), XTACACS
(Extended TACACS), Radius (Remote Authentication Dial-In
Service)… Vemos a continuación cómo configurar un router
para que valide las contraseñas con un servidor XTACACS.
Especificamos la IP del servidor TACACS
tacacs-server host 192.168.1.1
tacacs-server extended
Si no está accesible, usar la contraseña de enable como úl-
timo recurso
tacacs-server last-resort password
Notificamos al servidor de XTACACS las conexiones TCP,
quíen entra de "enable", quíen sale y el uso de SLIP y PPP.
tacacs-server notify connections always
tacacs-server notify enable always
tacacs-server notify logout always
tacacs-server notify slip always
Gracias a la línea "tacacs-server last-resort pas-
sword" seguimos accediendo al router incluso cuando el ser-
vidor no está disponible:
265
Username: luis
Password: ******
No response from TACACS authentication server - please enter enable password
Con la orden "show tacacs" podemos obtener estadís-

ticas del uso de estos protocolos. Puede obtener información
detallada de los paquetes que se intercambia el router con
el servidor TACACS usando la instrucción "debug tacacs
events".
*Nov 22 02:06:23.079: TAC: Sending xtacacs packet (user "luis"):
*Nov 22 02:06:23.083: TAC: xtacacs packet dump:
version: 0x80
type: 0x1
trans: 0x1C76 (7286)
namelen: 0x4
pwlen: 0x4
response: 0x0
reason: 0x0
uuid: 0x0 (0)
dhost: 10.0.0.2
dport: 0x0
lport: 0x2
flags: 0x0
acl: 0x0 (0)
*Nov 22 02:06:24.967: TAC: retransmit type ENABLE (6) to 192.168.1.1, Id 8668
Pare la depuración con la instrucción "undebug all".
6.3.3. Cifrado de passwords

Si después de configurar con username un nombre de
usuario y contraseña utiliza la orden "show running" obser-
vará que entre la orden password y la contraseña el router
ha insertado un cero: "username antonio password 0
cisco". El router nos indica con el cero que la contraseña se
ha almacenado en su memoria sin usar ningún mecanismo de
cifrado. Si alguien tiene acceso a la configuración del router,
podrá leer los nombres de los usuarios y sus contraseñas.
Cisco proporciona un servicio de encriptación de contra-
señas. Al configurar un router con la orden global "service
password-encryption" las contraseñas ahora aparecerán
cifradas, como en el ejemplo siguiente: "username antonio
password 7 104D000A0618". El siete entre la orden pas-
sword y la clave indica el tipo de cifrado usado, en este caso
un método poco fuerte (se trata de un cifrado Vigenère, una
sustitución polialfabética que no resiste un criptoanálisis mo-
derno). Existen programas (figura 6.10) capaces de extraer la
clave original a partir de la cadena de caracteres cifrada de
forma instantánea.
266
Figura 6.10. GetPass! en acción.
La clave que hay que proteger especialmente es la que da

acceso a la configuración del router, la especificada mediante
"enable password clave". Existe la posibilidad de especificar
cifrados más potentes para esta clave, usando la orden "enable
secret clave". Si están ambas órdenes configuradas, la clave
que se empleará para acceder al modo enable será la especificada
con secret. Ahora la orden "enable secret" va seguida de un
5 que indica el uso del método de cifrado MD5, un cifrado de
una sola vía, tipo hash, bastante más potente. De todas formas las
claves así cifradas son todavía susceptibles de ser recuperadas
mediante los llamados ataques de diccionario, en los cuales el
atacante encripta una extensa lista de palabras con el método de
cifrado y compara la lista así obtenida con la clave protegida. El
programa "john" (http://www.openwall.com/john/) es
un clásico en este frente.
root@0[john-1.6.37]# cat pass.txt
user:078D486A55E9922772C7F6F46113038E4800D6EDF4D31720
root@0[john-1.6.37]# john -w:password.lst pass.txt
Loaded 1 password hash (Salt SHA1 [salt-sha1])
barlow (user)
guesses: 1 time: 0:00:00:00 100% c/s: 752 trying: 12345 – pookie
6.3.4. Precauciones generales

al configurar contraseñas.
Siempre que cambie la configuración de contraseñas ve-
rifique que sigue teniendo acceso. Pruebe a abrir una nueva
sesión sin cerrar aquella desde la que está configurando el
router. Un error al teclear una contraseña puede dejarle sin
acceso al sistema. En general, no grabe los cambios en la con-
figuración hasta que esté seguro de que sigue teniendo acceso
267
al router. Si ha perdido el acceso apague y encienda el equipo.
Recuerde que como último recurso existe un procedimiento
de recuperación de contraseñas (password recovery procedure)
descrito en el capítulo 3 y los apéndices del libro. Debe seguir
el procedimiento correspondiente al modelo de router.
Una de las primeras tareas de configuración consiste en
especificar la clave para acceder al modo enable ("#"). Hágalo
mediante las órdenes "enable password clave" ó "enable
secret clave". Tenga en cuenta que si están configuradas
ambas órdenes en el mismo router la que se usará como clave
de enable será la especificada mediante "secret".
Si no está la orden "login" configurada en las líneas de
acceso ("line vty 0 4") el router dará directamente paso al
modo normal (">") sin solicitar ningún tipo de contraseña,
aunque tengamos especificados pares de usuarios y claves
mediante la orden "username".
Si damos la orden "login", el router nos pedirá la contra-
seña que hayamos configurado (con la orden "password") en
las líneas de terminal ("line vty 0 4"). Si no proporcionamos
dicha contraseña al router el router nos responderá con el men-
saje "Password required, but none set", se requiere contraseña,
pero no se ha especificado ninguna), y rechazará la conexión.
Siempre es conveniente configurar la orden "enable last-
resort password", que pide la clave de enable en caso de
que no funcionen los demás mecanismos.
Es importante destacar que si damos la orden "login
local" pero no tenemos configurado ningún par usuario/
contraseña al router no podrá conectar con el mismo (obtendrá
un "% Login invalid" por respuesta).
Para terminar, si damos la orden "login tacacs" sin es-
pecificar el servidor, el router no podrá validar los usuarios
que quieran acceder, y obtendrá el mensaje "No response from
TACACS authentication server - please enter enable password". Use
"tacacs-server last-resort password" para poder ac-
ceder al router con la clave de enable en caso de que el servidor
no está bien configurado o no esté disponible (por ejemplo, por
problemas en las líneas de comunicaciones).
6.4. Desactivación de servicios (hardening)

Los routers son ordenadores que están continuamente eje-
cutando varios programas a la vez. Puede ver los procesos ac-
tivados en el router mediante la orden "show processes".
268
Router#show processes
CPU utilization for five seconds: 0%/1%; one minute: 0%; five minutes: 0%
PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process
1 Csp 2FB64 0 100 0 3736/4096 0 Load Meter
2 M* 0 1816 305 595410392/12288 0 Exec
3 Lst 1989D4 304 60 5066 7960/8192 0 Check heaps
4 Cwe 190978 4 1 4000 7784/8192 0 Chunk Manager
5 Cwe 19DF74 0 1 0 7816/8192 0 Pool Manager
6 Mst 12426C 0 2 0 7784/8192 0 Timers
7 Lwe 1FC380 4 10 400 7792/8192 0 ARP Input
8 Mwe 266730 8 2 4000 7784/8192 0 DDR Timers
9 Mwe 27E598 4 2 200011896/12288 0 Dialer event
10 Lwe 2835BC 12 2 6000 7832/8192 0 Entity MIB API
11 Mwe 3FE058 0 2 0 7792/8192 0 Serial Backgroun
12 Mwe 402364 0 1 0 7832/8192 0 SERIAL A'detect
13 Cwe 1A32D0 0 1 0 7824/8192 0 Critical Bkgnd
14 Mwe 1C2C30 156 189 82510880/12288 0 Net Background
15 Lwe 11B0A4 60 21 285711168/12288 0 Logger
16 Msp 137E20 100 492 203 7728/8192 0 TTY Background
17 Msp 1C2294 8 497 1611800/12288 0 Per-Second Jobs
18 Mwe F1F60 4 38 105 7800/8192 0 LED Timers
19 Mwe 22E89C 44 63 698 6872/8192 0 CDP Protocol
20 Mwe 2E0E84 32 13 246111920/12288 0 IP Input
21 Mwe 3AD438 4 1 4000 7976/8192 0 PPP IP Add Route
PID QTy PC Runtime (ms) Invoked uSecs Stacks TTY Process
22 Mwe 373D90 36 2 18000 7648/8192 0 DHCPD Receive
23 Mwe 2AD9D8 0 1 0 7984/8192 0 HTTP Timer
24 Mwe 32B9B8 92 24 383311592/12288 0 IP Background
25 Lsi 3144A4 0 9 0 7960/8192 0 IP Cache Ager
26 Mwe 32B85C 0 1 0 7832/8192 0 RARP Input
27 Hwe 3721A8 0 1 0 7968/8192 0 Socket Timers
28 Mst 37E21C 4 1 400012144/12288 0 TCP Timer
29 Lwe 382AD8 4 1 400012088/12288 0 TCP Protocols
30 Mwe 4E1B10 8 2 4000 7792/8192 0 Emulator
31 Mwe 4D9FE4 0 1 024360/24576 0 ISDN Timer
32 Mwe 4652E4 0 1 0 7960/8192 0 CallMIB Backgrou
33 Mwe 4ECB40 0 1 0 7960/8192 0 ISDNMIB Backgrou
34 Hwe 1C249C 4 1 4000 7816/8192 0 Net Input
35 Csp 1C93EC 4 103 38 7816/8192 0 Compute load avg
36 Msp 1C22E0 416 9 46222 8040/8192 0 Per-minute Jobs
38 Mwe 2570F0 4 5 800 7952/8192 0 DHCPD Timer
39 Msi 25D9AC 8 138 57 7240/8192 0 DHCPD Database
Esta orden es similar al ps (o top) de UNIX o al

Administrador de tareas de Windows. Al comparar la confi-
guración del router con los procesos que éste ejecuta se dará
cuenta de que no ha necesitado invocar muchos de ellos: están
activados por defecto. La orden "show processes" seguida
de "cpu" o "memory" nos proporcionará información adicional
acerca del uso que los procesos hacen del procesador y de
la memoria.
Router#show processes cpu
CPU utilization for five seconds: 0%/1%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 0 109 0 0.00% 0.00% 0.00% 0 Load Meter
2 2116 316 6696 0.08% 0.35% 0.36% 0 Exec
3 340 65 5230 0.57% 0.09% 0.03% 0 Check heaps
4 4 1 4000 0.00% 0.00% 0.00% 0 Chunk Manager
5 0 1 0 0.00% 0.00% 0.00% 0 Pool Manager
6 0 2 0 0.00% 0.00% 0.00% 0 Timers
7 4 10 400 0.00% 0.00% 0.00% 0 ARP Input
8 8 2 4000 0.00% 0.00% 0.00% 0 DDR Timers
9 4 2 2000 0.00% 0.00% 0.00% 0 Dialer event
10 12 2 6000 0.00% 0.00% 0.00% 0 Entity MIB API
[… parte de la salida omitida…]
269
Router#
Router#show processes memory
Total: 3760128, Used: 1660224, Free: 2099904
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 100084 1504 912208 0 0 *Init*
0 0 176 42800 176 0 0 *Sched*
0 0 2309632 610452 0 236860 0 *Dead*
1 0 276 276 13132 0 0 Load Meter
2 0 19288 17796 22816 0 0 Exec
3 0 0 0 17228 0 0 Check heaps
4 0 20248 0 37476 0 0 Chunk Manager
5 0 96 0 17324 0 0 Pool Manager
6 0 276 276 17228 0 0 Timers
7 0 96 336 17324 0 0 ARP Input
8 0 276 276 17228 0 0 DDR Timers
9 0 276 276 21324 0 0 Dialer event
10 0 2972 676 19524 0 0 Entity MIB API
[… parte de la salida omitida…]
38 0 0 0 17228 0 0 DHCPD Timer
39 0 152 0 17380 0 0 DHCPD Database
1659864 Total
Cada uno de estos programas proporciona una prestación,

pero en determinadas circunstancias estos servicios pueden
constituir un lujo innecesario. Cada proceso de más que un
router ejecuta es un programa que puede ser explotado por un
atacante para conseguir información de nuestra red o realizar
un ataque de denegación de servicio. Veamos algunos de los
servicios que conviene desactivar, especialmente en los routers
expuestos a ataques externos.
6.4.1. Finger
Finger es un servicio que proporciona información acerca
de los usuarios conectados a la máquina. Finger proporciona
sus servicios a través del puerto TCP 79. En la siguiente fi-
gura vemos el efecto que tiene hacerle un telnet al puerto 79
de un router que tiene habilitado el servicio finger ("telnet
10.0.0.1 79")
router1#telnet 192.168.1.1 79
Trying 192.168.1.1, 79 ... Open

0 con 0 idle 00:00:55
* 1 vty 0 idle 00:00:00 192.168.1.2
Interface User Mode Idle Peer Address
[Connection to 192.168.1.1 closed by foreign host]
La primera línea indica que hay una sesión de consola

establecida. Cualquiera que tenga acceso físico al router
tiene cerca un ordenador con dicha sesión esperándole. Pero,
además, Finger nos da el nombre de los usuarios conectados al
270
sistema, y la dirección desde la que están establecidas dichas
conexiones. Un atacante con esta información tiene mucho
camino recorrido (posee un nombre de usuario y conoce una
dirección de origen válida).
Para desactivar este servicio use la orden de configuración
global "no ip finger". No todas las versiones de IOS permiten
desactivar este servicio.
6.4.2. tcp small-servers/udp small-servers

Las órdenes "service tcp small-servers" y "service
udp small-servers" habilitan una serie de servicios diagnós-
ticos. Por ejemplo, el servicio date en el puerto 13, da la hora
Router#telnet 192.168.1.1 13
Trying 192.168.1.1, 13 ... Open
Friday, June 26, 2009 00:23:43-UTC
[Connection to 192.168.1.1 closed by foreign host]
El servicio echo, que trabaja en el puerto 7, refleja los ca-

racteres ASCII que recibe. El servicio chargent (generador de
caracteres, Character Generator), que trabaja en el puerto 19,
emite continuamente caracteres ASCII. (Puede probar estos
servicios haciendo "telnet IP_router puerto", por ejemplo
"telnet 10.0.0.5 7".) Una forma de denegación de servicio
(DoS) muy efectiva consiste en mandar tráfico al puerto 19
falsificando el origen de los paquetes (spoofing) de forma que
parezca que proviene del puerto 7 de otro sistema. Se genera tal
cantidad de tráfico entre los dos routers que la comunicación
se hace imposible. Estos servicios se deshabilitan mediante las
órdenes de configuración global "no service tcp small-
servers" y "no service udp small-servers".
6.4.3. http-server
Vimos en el segundo capítulo que se puede configurar el
router para que permita acceder al mismo mediante un nave-
gador Web. La orden para habilitar este servicio es "ip http
server". Tenemos la posibilidad de cambiar el puerto por
el que el router proporciona dicho servicio. Por defecto es el
puerto 80, pero mediante la orden "ip http port <puerto>"
podemos especificar el puerto por el que daremos el servicio.
Por ejemplo, si usamos las órdenes:
<Alan(config)# ip http server
Alan(config)# ip http port 10250
271
Ahora para acceder al router 10.0.0.1 a través de un na-
vegador, usaremos la dirección http://10.0.0.1:10250.Tenga
en cuenta de cambiar el puerto por el que el sistema presta
un determinado servicio no constituye una medida de segu-
ridad definitiva, dado que un scanner de puertos como "nmap"
(http://nmap.org/) puede descubrir por qué puerto se
ofrece cada servicio.
Para deshabilitar el servidor de http del router usaremos la
orden de configuración global "no ip http server".
6.4.4. CDP (Cisco Discovery Protocol)

CDP es un protocolo propietario de Cisco que obtiene y
ofrece información acerca de los dispositivos de red. Trabaja
a nivel de enlace o nivel 2 del modelo OSI, de forma que no es
necesario tener configuradas direcciones de red en las inter-
faces. Sólo anuncia vecinos inmediatos:
Pioners#show cdp neighbours
Capability Codes: R -Router, T -Trans Bridge, B -Source Route Bridge
S -Switch, H -Host, I -IGMP, r -Repeater
Device ID Local Intfce Holdtme Capabil Platform Port ID
Alan Eth 0 166 R 1610 Fas 1/0
John Ser 0.16 179 R 2500 Ser 0.16
Marvin Eth 0 134 R 2610 Fas 0/0
Niklaus Eth 0 124 R T 4700 Fas 0/0
Ada Eth 0 175 R 2500 Eth 0
Si usamos la orden "show cdp neighbours detail" ob-

tendremos mucha más información acerca de los dispositivos
Cisco del entorno.
Router#sh cdp neighbors detail
-------------------------
Device ID: router1
Entry address(es):
IP address: 192.168.4.1
Platform: Cisco C805 , Capabilities: Router
Interface: Ethernet0, Port ID (outgoing port): Ethernet0
Holdtime : 151 sec
Version :
IOS (tm) C805 Software (C805-SY6-MW), Version 12.2(2)T, RELEASE
SOFTWARE (fc1)
TAC Support: http://www.cisco.com/cgi-bin/ibld/view.pl?i=support
Compiled Sat 02-Jun-01 21:28 by ccai
advertisement version: 2
Duplex: half
272
Es posible que no quiera ejecutar este servicio en los
routers (y switches) situados en los límites de su red, allí
donde conectan con dispositivos gestionados por otras or-
ganizaciones.
Para deshabilitar este servicio en una interfaz determinada
use "no cdp enable".
interface serial 0
no cdp enable
Para deshabilitar este servicio en todas las interfaces use la

orden de configuración global "no cdp run".
6.4.5. ip redirects/ip source-route

Con la orden global "no ip source-route" indicamos
al router que descarte los paquetes que lleven en su cabecera
información de enrutamiento (source routing). No hay muchos
motivos legítimos por los que otros sistemas deban indicar a
nuestro router qué debe hacer con los paquetes que le llegan.
6.4.6. ip directed-broadcast
Cuando una interfaz recibe un paquete dirigido a la direc-
ción de difusión (172.16.255.255) la convierte en una difusión
local (FF-FF-FF-FF-FF-FF). La respuesta que esto genera por
parte de todas las máquinas de la red local puede degradar
enormemente el rendimiento del sistema, especialmente en
segmentos grandes. A este tipo de ataque se le llama Smurf
(del nombre del programa que extendió este ataque). La orden
"no ip directed-broadcast"deshabilita en la interfaz la
conversión de difusiones de red en difusiones locales.
Ellison(config)# int ethernet 0
Ellison(config-if)# no ip directed-broadcast
6.4.7. Banner
Mediante la instrucción "banner" configuramos un mensaje
para las personas que se conectan al router. Puede aprovechar
para dar la bienvenida, recordar a los posibles atacantes que sus
acciones quedarán registradas, etc. Use "banner carácter
mensaje carácter" para crear su mensaje. En nuestro caso
usamos el asterisco ("*") para "envolver" el mensaje:
273
Sagan#conf t
Enter configuration commands, one per line.End with CNTL/Z.
Sagan(config)# banner *
Enter TEXT message.End with the character '*'.
("'-''-/").___..--''"'-._
'6_ 6 '-.( ).'-.__.')
(_Y_.)'._ )'._ '. ''-..-'
_..'--'_..-_//--'_.' ,'
(il),-''(li),'((!.-'
OJO CON EL GATO...

*
Sagan(config)# exit
Sagan#exit
telnet 10.0.0.1
("'-''-/").___..--''"'-._
'6_ 6 ) '-. ( ).'-.__.')
(_Y_.)' ._ ) '._ '. ''-..-'
_..'--'_..-_/ /--'_.' ,'
(il),-'' (li),' ((!.-'
OJO CON EL GATO...

Username:
Aunque un banner como este puede resultar divertido, en

un entorno de producción puede necesitar algo más profe-
sional. Pida ayuda legal para construir uno a la medida de
sus necesidades:
Es un delito
1. Acceder al sistema sin autorización
2. Dañar, alterar, borrar o insertar información sin autorización

Username:
6.4.8. validate-update-source
En los protocolos de enrutamiento RIP e IGRP la orden
"validate-update-source" comprueba que la dirección
origen de las actualizaciones de enrutamiento esté en la
misma red que la dirección de la interfaz por la que entre la
actualización:
274
router rip
validate-update-source
router igrp 99
validate-update-source
6.4.9. Limitación de los tiempos

de las sesiones
El parámetro "exec-timeout" permite especificar el
tiempo que durará la sesión una vez que el usuario deja de
usarla. Este tiempo se especifica en minutos y segundos:
line vty 0 4
exec-timeout 5 30
Tenga mucho cuidado de no fijar un tiempo excesivamente
bajo. Podría tener problemas para conectarse de nuevo.
6.5. Logs
El registro (log) del router se habilita mediante la orden
"logging buffered" y se consulta con la instrucción "show
logging".
A la hora de configurar el log podemos indicar un tamaño y
la severidad de los eventos que queremos registrar: "logging
buffered [tamaño] [severidad]" El tamaño se especi-
fica en bytes (entre 4.096 y 2.147.483.647) y la severidad del
0 (máxima) al 7 (mínima). Se registrarán los eventos con una
gravedad igual o mayor a la especificada. La tabla 6.7 muestra
la severidad de los eventos.
Tabla 6.7. Niveles de severidad.

Nivel Severidad Descripción
0 Emergencias El sistema está caído
1 Alertas Se precisa intervención inmediata
2 Críticos Condiciones críticas
3 Errores Condiciones de error
4 Precaución Mensajes de precaución
5 Notificaciones Condiciones normales pero
significativas
6 Informativos Mensajes informativos
7 Debug Resultado de órdenes de depuración
275
Algunos procesos del router permiten enviar al registro
de eventos. Por ejemplo, si añadimos la instrucción log a la
lista de acceso, cómo en "access-list 1 permit host
10.0.0.3 log" se añadirán al registro de sucesos entradas
indicando los paquetes que encajan con la condición expre-
sada en la lista.
Algunos protocolos de routing permiten configurar el re-
gistro de eventos. Por ejemplo en EIGRP podemos registrar
los cambios de vecindad
router eigrp 120
eigrp log-neighbor-changes
eigrp log-neighbour-warnings
Y en OSPF los cambios de adyacencia
<Listados>router ospf 100
log-adjacency-changes
Es fundamental que junto con el evento se almacene el

momento exacto en que tuvo lugar. Para ello debemos con-
figurar el servicio horario (service timestamps) con las órdenes
globales "service timestamps debug" o "service times-
tamps log" opcionalmente seguidas de otras indicaciones. Por
ejemplo, las siguientes órdenes habilitan el registro horario in-
cluyendo fecha, hora, milisegundos y zona horaria, tanto para
el resultado de las tareas de depuración (debug) como para el
registro de eventos (log):
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
Un router no posee unidades de discos donde almacenar

los eventos. Una medida de seguridad adicional consiste en
almacenar el registro en una máquina distinta al router. Es
necesario disponer de un servidor capaz de almacenar la in-
formación y configurarlo adecuadamente, por ejemplo una
máquina UNIX que ejecute syslogd (Syslog Daemon).
Para habilitar el envío de eventos a la máquina que registra
la información use la orden "logging ip-del-servidor-
syslog". Puede mandar el registro a más de una máquina.
Para ello repita la orden indicando las direcciones de los otros
servidores.
Nota: "Tus directorios de seguridad se han reducido".

Tsutomu Shimomura, experto en seguridad informática,
narra en su libro Takedown cómo se dió cuenta de que habían
276
forzado sus ordenadores. Periódicamente su red almacenaba
un archivo con los eventos de seguridad. Era de esperar que de
una transmisión a otra los archivos resultasen más extensos,
de modo que cuando el fichero de registro se volvió inespera-
damente más corto concluyó que un intruso (Kevin Mitnick)
había accedido a sus ordenadores y borrado parte los registros
(logs) en un intento de cubrir sus huellas.
6.6. Criptografía e IPSec

Los protocolos que componen la suite TCP/IP no fueron
originalmente diseñados con la idea de proteger la confiden-
cialidad de los datos que transportaban, de forma que con un
analizador de protocolos podemos observar claramente la
información que transportan los paquetes.
Figura 6.11. Capturando texto en claro.
Con la misma facilidad que se reconoce el banner podemos

leer el nombre de usuario, contraseñas y cualquier otra infor-
mación que atraviese una red. Una forma de aumentar la se-
guridad de los datos consiste en protegerlos mediante técnicas
criptográficas.
277
6.6.1. Criptografía
Ronald Rivest, coinventor del sistema RSA de criptografía
pública (la R de RSA), indica que "la criptografía trata de la
comunicación en presencia de adversarios". Zimmerman, autor
del programa PGP (Pretty Good Privacy), define la criptografía
como "la ciencia de usar las matemáticas para encriptar y des-
encriptar datos". Kent y Atkinson, arquitectos del protocolo
IPSec, definen la encriptación como el "mecanismo de segu-
ridad utilizado para transformar datos de una forma inteli-
gible (texto claro) a una forma ininteligible (texto cifrado) para
proporcionar confidencialidad". Para terminar recordaremos
que Bruce Schneier, inventor del algoritmo de encriptación
Blowfish, indica que existen dos tipos de criptografía: "la que
impedirá que tu hermana lea tus ficheros, y la que impedirá
que un gobierno lea tus ficheros".
IPSec es una arquitectura criptográfica que proporciona a
los protocolos de red IPv4 e IPv6 servicios de seguridad entre
equipos de distintos fabricantes. El concepto de SA, central
en IPSec, hace referencia a una "Asociación de Seguridad"
(Security Association, SA), una conexión que consigue servi-
cios de seguridad para el tráfico transportado. IPSec es mo-
dular: algunos de sus componentes proporcionan seguridad
al tráfico, como los protocolos AH (Authentication Header) y
ESP (Encapsulating Security Payload). Otros protocolos como
IKE (Internet Key Exchange) solucionan el problema de la
distribución de claves usadas para autentificar a las partes y
garantizar la integridad de los datos. IPSec posee mecanismos
tanto manuales como automáticos para garantizar la distri-
bución de las claves.
6.6.2. IPSec
Vemos a continuación en ejemplo de configuración de
IPSec. Tenga en cuenta que para configurar este servicio en
un router Cisco necesitaremos una versión de IOS que soporte
estas características (generalmente indicadas por una "k" en la
denominación de la IOS).
En primer lugar usaremos la orden "crypto isakmp" para
permitir el intercambio de claves: indicamos que la clave com-
partida por ambos extremos ha sido previamente distribuida
(pre-shared), especificamos la longitud de la clave con "group 2"
(el grupo 1 utiliza una clave de 768 bits, el grupo 2 una clave de
1024, a mayor longitud, mayor fortaleza, pero también mayor
278
coste en tiempo y uso de procesador). Con "lifetime 7200"
indicamos la frecuencia con la que se debe crear una nueva
Asociación de Seguridad (SA).
Figura 6.12. Red de ejemplo para IPSec.
Finalmente con "crypto isakmp key clave_secreta

address 172.16.10.2" indicamos la clave y la IP del otro
extremo de la asociación:
crypto isakmp policy 5
! Los extremos deben coincidir en autenticación, grupo y
tiempos.
authentication pre-share
group 1
lifetime 7200
! el otro extremo estará configurado con 172.16.10.1
crypto isakmp key clave_secreta address 172.16.10.2
Pasamos a configurar las características de cifrado: con
"crypto ipsec transform-set" indicamos las opciones de
cifrado. A continuación especificamos con una lista de acceso
el origen y el destino del tráfico a encriptar, y creamos el mapa
de cifrado con "crypto map", dándole un nombre e indicando
cada cuanto tiempo debe generarse una nueva clase (en el
ejemplo cada 2 minutos). Dentro del "crypto map" indicamos
el otro extremo de la Asociación y precisamos qué opciones de
cifrado usar y con qué tráfico.
! Deben coincidir los extremos en las opciones
crypto ipsec transform-set opciones ah-md5-hmac esp-des esp-md5-hmac
access-list 140 permit ip 192.168.5.0 0.0.0.255 192.168.10.0 0.0.0.255
! deben coincidir ambos extremos en los tiempos
crypto map conexion_cifrada 120 ipsec-isakmp
! el otro extremo estará configurado con 172.16.10.1
set peer 172.16.10.2
set transform-set opciones
match address 140
Sólo queda aplicarlo en la interfaz adecuada:

interface serial 0
crypto map conexion_cifrada
279
Para verificar la correcta configuración de la red virtual
privada use las órdenes "show crypto"
Sagan# show crypto isakmp policy
Protection suite priority 1
encryption algorithm: DES-Data Encryption Standard (56 bit keys)
hash algorithm: Secure Hash Standard
authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
lifetime: 7200 seconds, no volume limit
Sagan# show crypto map interface serial 1
Crypto Map "conexion_cifrada" 2 ipsec-isakmp
Peer = 172.16.10.2
Extended IP access list 140
access-list 140 permit ip 192.168.5.0 0.0.0.255 192.168.10.0 0.0.0.255
Current peer: 172.16.10.2
Nota: puede consultar las especificaciones de los principales

protocolos de seguridad en los RFCs que van del 2401 al
2411, por ejemplo el RFC 2402 (IP Authentication Header
- AH), el RFC 2406 (IP Encapsulating Security Payload -
ESP) o el RFC 2409 (The Internet Key Exchange - IKE).
Puede conseguirlos en la dirección http://www.rfc-
editor.org/.
280
7
Configurando servicios
En el presente capítulo presentamos otras posibilidades de

los routers: en primer lugar vemos qué es el NAT y cómo se
configura. A continuación vemos como aumentar la disponi-
bilidad del sistema mediante el uso de interfaces de respaldo
y protocolos como HSRP. En las siguientes secciones presen-
tamos sucesivamente los protocolos DHCP, SNMP y NTP,
para terminar viendo cómo se puede convertir el router en un
balanceador de carga mediante el servicio SLB.
7.1. NAT
7.1.1. Fundamentos
NAT (Network Address Translation) es un mecanismo utili-
zado por los routers para hacer corresponder dos espacios de
direcciones, típicamente uno de uso interno o privado con uno
de uso externo o público.
NAT permite atajar tres importantes problemas de Internet:
la progresiva escasez de direcciones, los problemas de segu-
ridad derivados del uso comercial y la complejidad de gestión
del encaminamiento (routing). Estos problemas derivan de los
peculiares orígenes de Internet. NAT representa una magnífica
solución a corto plazo mientras se migra la red al nuevo (y
mucho más extenso) espacio de direcciones IPv6.
Las máquinas que se conectan a Internet se identifican por
medio de una dirección IP versión 4 (IPv4), un número de 32
bits que permite en principio identificar hasta 4.294.967.296
máquinas distintas. Sin embargo la forma de repartir esas
direcciones, agrupándolas en redes de distintas clases, junto
281
con la "generosidad" inicial en el reparto de direcciones así
como el éxito comercial e imprevisto de Internet ha conducido
hacia un progresivo agotamiento del espacio de direcciones
disponible.
La solución obvia, aumentar la longitud de las direcciones,
ya se está llevando a cabo: está en marcha la implantación de
la versión 6 del protocolo IP (IPv6) que utiliza direcciones de
128 bits. Esta versión también ha previsto mecanismos más
racionales de reparto del nuevo espacio de direcciones. No
obstante todavía llevará algunos años migrar la infraestructura
actual de Internet basada en IPv4 a IPv6.
NAT permite la "sobrecarga" (overload) de direcciones in-
ternas, permitiendo que muchas máquinas internas compartan
unas pocas direcciones públicas, quizás sólo una.
Esta dirección en muchos casos es "dinámica", una dirección
que forma parte de un conjunto (pool) más amplio propiedad
del ISP (Internet Service Provider, o Proveedor de Servicios de
Internet), que "alquilada" temporalmente al usuario, permite
una reutilización de la IP tan pronto como es liberada.
Como los sistemas de los usuarios finales siguen necesi-
tando tener una dirección única que los identifique pueden
usar en sus redes locales direcciones denominadas de uso
privado descritas en el RFC 1918 (Address Allocation for Private
Internets), que especifica que las redes 10.0.0.0 - 10.255.255.255,
172.16.0.0 - 172.31.255.255 y 192.168.0.0 - 192.168.255.255 no son
encaminadas por los routers en Internet, de forma que pueden
ser usadas sin conflicto por múltiples usuarios en distintos si-
tios. A la hora de salir a Internet el router NAT se encargará de
hacer las traducciones necesarias para que los "diálogos" con
el exterior de las máquinas con direcciones RFC 1918 parezcan
tener por origen la IP asignada por el ISP (de espacio público,
enrutable). De cara al exterior la red del usuario se presenta
como una única máquina.
Otra consecuencia derivada del crecimiento de Internet es
el aumento del tamaño de las tablas de rutas necesarias para el
encaminamiento (routing). Para que los paquetes viajen hasta
las máquinas destino los routers deben poseer rutas hacia los
destinos. Algunos de los routers del núcleo de Internet poseen
tablas de rutas de gran tamaño. El uso de NAT ha frenado el
crecimiento de estas tablas.
Al hablar de la administración de redes hay que mencionar
una importante ventaja de NAT, al permitir migrar redes de
forma transparente a los usuarios finales. Esto es especial-
mente útil cuando hay que unir dos redes que comparten el
282
mismo plan de numeración (redes superpuestas u "overlaping
networks"). El uso de redes de espacio RFC 1918 hace que estos
solapamientos ocurran de forma frecuente en las fusiones de
empresas.
Internet presenta una serie de problemas de seguridad que
han sido estudiados en diversas ocasiones. Estos problemas
pueden sorprender si consideramos que los orígenes militares
de Internet, pero se explican teniendo en cuenta el carácter
experimental de sus inicios, el énfasis en la funcionalidad por
encima de otros criterios y el entorno académico donde se
desarrollaron los protocolos fundamentales que componen la
pila de protocolos TCP/IP.
Al hacer pasar las comunicaciones por un punto común
(el router NAT) se puede concentrar una parte importante
del esfuerzo de seguridad en dicho punto. Desde el exterior
no será posible establecer comunicación con máquinas de la
red local si estas no han iniciado la conversación (el router
NAT no sabría a qué máquina interna remitir los paquetes
del exterior). Por supuesto que es posible definir traducciones
estáticas para ciertos servicios que necesitan ser identificados
con claridad, tales como servicios Web, FTP, etc... No obstante
la combinación de NAT con mecanismos de seguridad tales
como listas de acceso permiten ejercer un mayor control en el
uso de estos servicios.
Nota: La descripción original de NAT fué hecha en mayo

de 1994 el RFC 1631 "The IP Network Address Translator
(NAT)". Una revisión actualizada de este documento aparece
en el RFC 3022 "Traditional IP Network Address Translator
(Traditional NAT)". El protocolo IPv6 (también conocido
como IPng, de Next Generation) está descrito en el RFC
1883 "Internet Protocol, Version 6 (IPv6)". Las direcciones
reservadas por IANA para uso privado fueron definidas en el
RFC 1918 "Address Allocation for Private Internets".
Para eliminar ambigüedad definiremos las redes internas
como aquellas conectadas a las interfaces del router NAT defi-
nidas como "inside" (por medio de la órden "ip nat inside").
De forma similar denominaremos redes externas a las que
conectan con el router NAT por las interfaces definidas como
"outside" (por medio de la órden "ip nat outside").
283
Figura 7.1. NAT: Inside y Outside.
En función de a qué interfaces se conectan, las redes serán

internas o externas a efectos del NAT (Figura 7.1).
Figura 7.2. NAT: direcciones.
En NAT tenemos cuatro tipos de direcciones (véase la

figura 7.2):
284
Inside local address (interna local): la dirección IP asignada
a una máquina concreta de la red interna. Generalmente se
trata de una dirección de espacio reservado para uso privado
(RFC 1597).
Inside global address (interna global): la dirección IP que re-
presenta en el exterior una o más direcciones internas locales
(inside local address). Suelen ser direcciones IP públicas (en-
rutables) asignadas por un ISP.
Outside local address (externa local): la dirección IP de una
máquina externa tal como se ve desde la red interna. No tiene
por que ser una dirección IP pública, "legal".
Outside global address (externa global): la dirección IP de una
máquina externa tal como es asignada por el dueño de dicha
máquina. Esta IP es de espacio público.
Los paquetes originados en la parte interna de la red tienen
una "inside local address" como origen y una "outside local address"
como destino mientras el paquete viaja por la parte interna
de la red. Cuando el paquete es conmutado a la red externa el
origen del paquete es traducido a la "inside global address" y el
destino conocido como "outside global address" (Figura 7.3).
Figura 7.3. NAT: direcciones.
Otra forma de verlo: cuando el paquete viene de la parte ex-

terna de la red su dirección origen será la "outside global address"
y el destino será la "inside global address". Pero cuando el paquete
285
atraviese el router NAT y entre en la red interna el origen habrá
sido traducido por la "outside local address" y su destino como "in-
side local address" El encaminamiento (routing) de los paquetes en
un router NAT tiene lugar antes de la traducción cuando ésta es
de dentro a fuera (Inside-to-outside) y tiene lugar después cuando
la traducción es de fuera a dentro (Outside-to-inside).
Nota: Orden de Operación del NAT.
Sentido de Inside a Outside

• Si hay IPSec comprobar la lista de acceso de entrada
• Desencriptar (en caso de Cisco Encryption Technology
o IPSec)
• Comprobar listas de acceso de entrada
• Comprobar los límites de flujo sentido entrada
• Input Accounting
• Policy Routing
• Routing
• Redirección a web cache
• NAT inside a outside (traducción de local a global)
• Crypto (Comprobar map y marcar para encriptar)
• Comprobar listas de acceso de salida
• Inspeccionar (CBAC - Context-based Access Control)
• TCP intercept
• Encriptado
• Encolado (Queueing)
Sentido de Outside a Inside
• Si hay IPSec comprobar la lista de acceso de entrada
• Desencriptar (en caso de Cisco Encryption Technology
o IPSec)
• Comprobar listas de acceso de entrada
• Comprobar los límites de flujo sentido entrada
• Input Accounting
• NAT outside a inside (traducción de global a local)
• Policy Routing
• Routing
• Redirección a web cache
• Crypto (Comprobar map y marcar para encriptar)
• Comprobar listas de acceso de salida
• Inspeccionar (CBAC - Context-based Access Control)
• TCP intercept
• Encriptado
• Encolado (Queueing)
286
Hay dos clases de NAT: estático, en el que las direcciones
se mapean una a una de forma explícita, y dinámico, en el que
se crea un conjunto de direcciones disponibles (un pool) que se
usan y liberan cuando ya no se necesitan.
Figura 7.4. Red NAT.
Usamos la orden "ip nat inside source static" para

configurar mediante NAT estático cada uno de los pares de
direcciones:
ip nat inside source static 192.168.5.2 10.20.5.2
Sólo resta aplicar las conversiones específicas en las inter-

faces adecuadas. Lo haremos con "ip nat inside source"
en la interfaz ethernet y con "ip nat outside" en la interfaz
serie:
interface Ethernet0
ip address 192.168.5.1 255.255.255.0
ip nat inside
!
interface Serial0
ip address 10.20.5.1 255.0.0.0
ip nat outside
287
El ejemplo de NAT estático usado en el ejemplo anterior
es del tipo "nat inside source". En este tipo de NAT un paquete
con origen ip_local al atravesar una interfaz definida como
inside cambiará dicha ip origen por la ip_global. Igualmente, y
para que todo funcione correctamente, cuando un paquete con
destino ip_global llegue a una interfaz definida como outside
será cambiado a destino ip_local.
La forma general de la instrucción que permite definir este
mapeo es
ip nat inside source static ip_local ip_global
En el ejemplo siguiente las máquinas 10.0.0.1 a 10.0.0.4 co-

nectadas a la red local (ethernet) serán vistas desde el exterior
(por la interfaz serie) cómo 9.0.0.1 a 9.0.0.4
ip nat inside
interface serial 0
ip nat outside
Podemos consultar el estado de la tabla NAT por medio de

la instrucción "show ip nat translation"
Sagan#sh ip nat trans
Pro Inside global Inside local Outside local Outside global
--- 9.0.0.1 10.0.0.1 --- ---
--- 9.0.0.2 10.0.0.2 --- ---
--- 9.0.0.3 10.0.0.3 --- ---
--- 9.0.0.4 10.0.0.4 --- ---
Otra alternativa de configuración es la basada en "nat out-

side source". En este caso cuando el router recibe un paquete
con origen ip_global en su interfaz outside dicha dirección
es cambiada por la ip_local. De la misma forma, cuando un
paquete con destino ip_local atraviesa una interfaz definida
como inside será trasformado para que su destino sea la
ip_global. La forma general de la instrucción que permite
definir este mapeo es
ip nat outside source static ip_global ip_local
En el siguiente ejemplo el dispositivo 9.0.0.4 es conocido en

la red local local como 10.0.0.4
288
ip nat outside source static 9.0.0.4 10.0.0.4
interface serial 0
ip nat outside
ip nat inside
Podemos comprobar la traducción con

Sagan#sh ip nat trans
--- --- --- 10.0.0.4 9.0.0.4
Una forma simplificada de considerar los puntos anteriores

en la práctica consiste en estudiar las instrucciones de traduc-
ción "ip nat inside|outside source|destination
static" donde "inside|outside" hace referencia a
que interfaz debe atravesar el paquete (de qué red viene) y
"source|destination" hace referencia al campo del paquete
que será traducido (nuevo origen|destino).
Así, "ip nat inside source" cambia el origen de los
paquetes que vienen por la interfaz inside y que cumplen la
lista de acceso asociada al NAT (para el resto no se aplica el
NAT), y el destino de los que entran por la interfaz outside y
cumplen el NAT. La orden "ip nat inside destination"
cambiará el destino de los paquetes que vienen por la interfaz
inside y cumplen con la ACL del NAT, y el origen de los que
entran por la interfaz outside (y cumplen el NAT). Finalmente,
"ip nat outside source" cambiará el origen de los paquetes
que vienen por la interfaz definida como outside.
Veamos a continuación el ejemplo anterior usando NAT
dinámico. Para empezar creamos el "fondo" de direcciones
(address pool). Usamos las versátiles listas de acceso para es-
pecificar las direcciones internas y la orden "ip nat pool"
seguida del nombre del "fondo" para enumerar el rango de
direcciones externas:
ip nat pool CONVERSION 10.20.5.2 10.20.5.5 netmask 255.0.0.0
Conectamos ambos dominios de direcciones con la orden

"ip nat inside source", pero en esta ocasión:
ip nat inside source list 10 pool CONVERSION
Aplicamos la conversión como antes:

interface Ethernet0
ip address 192.168.5.1 255.255.255.0
ip nat inside
!
289
interface Serial0
ip address 10.20.5.1 255.0.0.0
ip nat outside
La sobrecarga (overload) permite que múltiples aplicaciones

o máquinas de la red interna "compartan" una cantidad menor
de direcciones (incluso una única IP). Se configura de forma
similar pero añadiendo la palabra clave "overload"
ip nat inside source list 10 pool CONVERSION overload
Otra interesante opción se nos presenta mediante el uso

de la opción "rotary", permitiéndonos configurar los routers
para que realicen un balanceo de carga simple.
Router(config-if)# ip nat inside
Router(config-if)# ip nat outside
Router(config)# ip nat pool SERVIDORES 192.168.1.101
192.168.1.105 netmask 255.255.255.0 type rotary
Router(config)# access-list 20 permit host 192.168.1.100
Router(config)# ip nat inside destination list 20 pool SERVIDORES
Router(config)# end
Router#
Tenemos unos servidores en el segmento FastEthernet0/0.

Definimos un pool de servidores llamado SERVIDORES que
incluye sus direcciones IP (de la 101 a la 105). Con una lista
de acceso definimos la IP virtual que usaran los dispositivos
para atacar al pool de servidores. Hacemos uso de nat "inside
destination", ya que en este caso son los clientes en el lado "out-
side" los que abren las comunicaciones contra los servidores
del lado "inside".
7.1.3. Monitorización
Para comprobar el funcionamiento del NAT usamos la
orden "show ip nat translation".
Sagan# show ip nat translations
--- 10.20.5.2 192.168.5.2 --- ---
--- 10.20.5.3 192.168.5.3 --- ---
--- 10.20.5.4 192.168.5.4 --- ---
--- 10.20.5.5 192.168.5.5 --- ---
290
A continuación esta otra salida corresponde al balanceo
con "rotary":
Router#show ip nat translations
tcp 192.168.1.100:80 192.168.1.101:80 192.168.2.27:11012 192.168.2.27:11012
tcp 192.168.1.100:80 192.168.1.102:80 192.168.2.27:11013 192.168.2.27:11013
tcp 192.168.1.100:80 192.168.1.103:80 192.168.2.27:11014 192.168.2.27:11014
tcp 192.168.1.100:80 192.168.1.104:80 192.168.2.27:11015 192.168.2.27:11015
tcp 192.168.1.100:80 192.168.1.105:80 192.168.2.27:11016 192.168.2.27:11016
tcp 192.168.1.100:80 192.168.1.101:80 192.168.2.27:11017 192.168.2.27:11017
tcp 192.168.1.100:80 192.168.1.102:80 192.168.2.27:11018 192.168.2.27:11018
Podemos hacer que el router reconstruya la tabla de tra-

ducciones con la orden "clear ip nat translation *".
Con "show ip nat statistics" podemos examinar las es-
tadísticas fundamentales de NAT como aciertos (hits), fallos
(missess) y traducciones expiradas (expired):
Sagan#sh ip nat statistics
Total active translations: 4 (0 static, 4 dynamic; 0 extended)
Outside interfaces: Serial0
Inside interfaces: Ethernet0
Hits: 20 Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
access-list 10 pool CONVERSION refcount 2
pool CONVERSION: netmask 255.0.0.0
start 10.20.5.2 end 10.20.5.5
type generic, total addresses 4, allocated 4 (100%), misses 0
7.2. Interfaces de respaldo y HSRP

Los sistemas de comunicaciones están expuestos a mu-
chas averías y perturbaciones. Por ello es importante conocer
como se pueden diseñar sistemas que puedan funcionar con
precisión y estabilidad en estas condiciones. La corrección de
errores de línea mediante la incorporación de un código de
redundancia cíclica (CRC) es un ejemplo de cómo se puede au-
mentar la fiabilidad de un medio de comunicación añadiendo
información extra.
Otra forma de proporcionar redundancia consiste en confi-
gurar una interfaz para que proporcione respaldo a otra en caso
de que la conexión caiga. Para ello se usa la orden "backup"en
la interfaz a la que queremos proporcionar respaldo, indicando
qué interfaz se lo dará. El siguiente ejemplo configura el router
para que active la interfaz BRI 0 en caso de que caiga la interfaz
serial 0. Con "backup delay" expresamos el tiempo en se-
gundos que el router debe esperar para que active el respaldo
291
y el tiempo que lo mantendrá una vez que recupere la línea
principal (10 y 120 segundos respectivamente)
interface serial 0
backup interface bri 0
backup delay 10 120
Podemos configurar una interfaz para que ayude a otra con

un "empujón" extra cuando su carga alcance un determinado
nivel. Usaremos para ello la orden "backup load" indicando
qué porcentaje de utilización debe alcanzar para levantar el res-
paldo y a qué nivel debe volver para dejar de usar la segunda
interfaz (80 y 40 por 100 en el siguiente ejemplo):
backup load 80 40
Nota: Recordamos de nuevo que al configurar una interfaz

RDSI para que de respaldo a otra una mala configuración
puede generar una gran factura. Debemos revisar periódica-
mente el registro de eventos del router ("show logg") para
detectar problemas con las líneas RDSI.
Con las interfaces de backup podemos resolver la situa-

ción en la que una línea falla, pero ¿y si es un router el que
falla? Veremos a continuación un protocolo diseñado para
ese caso.
7.2.1. Fundamentos
HSRP (Hot Standby Routing Protocol) es un protocolo de
Cisco que permite a un conjunto de routers crear uno o varios
routers virtuales de forma que se pueda mantener la dispo-
nibilidad del servicio ante fallos de elementos de elementos
del cluster.
Nota: La especificación del protocolo HSRP la encontrará en

el RFC 2281. Puede obtener este documento en la dirección
http://www.rfc-editor.org/.
Vemos en la figura 7.5 un contexto donde HSRP puede

ofrecer su servicio. El router A manda los paquetes al router
A' y el router B se comunica con el router B'. Si las conexiones
A-A' o B-B' caen (por fallos en la línea, interfaces o routers),
los protocolos de enrutamiento podrán detectar la situación
(por ejemplo EIGRP lo hará casi instantáneamente), pero los
292
sistemas finales como el PC1, configurados estáticamente para
seguir saliendo por su puerta de enlace (default gateway), no se
podrán ajustar a la nueva topología y habrá que cambiarlos a
mano para que sigan funcionando.
Figura 7.5. Red sin HSRP.
Figura 7.6. Router HSRP.
293
En la figura 7.6 se ha añadido un router "HSRP". Este
router no existe físicamente, sino que está creado por medio
del protocolo HSRP. Este protocolo permite a un conjunto de
routers crear un router virtual, un router lógico que posee
las mismas características de uno "auténtico": dirección IP,
dirección MAC, etc… Las máquinas de la red como el PC1
apuntarán al router virtual. El protocolo HSRP sigue la pista
al estado de los routers que "construyen" el router lógico y
en caso de fallo pasan el testigo al router que estaba en modo
de espera (standby) para que asuma las funciones del router
principal (active).
Tenemos dos routers RouterA y RouterB, con direcciones
IP 10.0.0.3 y 10.0.0.4 respectivamente. La siguiente configu-
ración consigue que entre ambos creen un router virtual con
dirección IP 10.0.0.1. Configuramos HSRP por medio de la
orden de configuración de interfaz "standby grupo ip ip-
virtual" y asignamos una prioridad con "standby grupo
priority".
RouterA(config)# interface FastEthernet 0/0
RouterA(config-if)# standby 1 ip 10.0.0.1
RouterA(config-if)# standby 1 priority 120
RouterB(config)# interface FastEthernet 0/0
RouterB(config-if)# standby 1 ip 10.0.0.1
RouterB(config-if)# standby 1 priority 110
Pero hay un problema con la configuración anterior: el

router de respaldo, al tener una prioridad menor, se pasa el
tiempo esperando a que el otro falle, mientras que todo el
tráfico se va por el router activo. La solución pasa por usar
grupos múltiples de HSRP con prioridades cruzadas, y for-
zando con "preempt" un router principal diferente en cada
grupo.
294
Nota: Para usar múltiples grupos de HSRP necesita un hard-
ware y una versión de IOS que soporten esta característica.
Vemos en el siguiente ejemplo cómo configuramos 2 routers

virtuales.
RouterA(config)#interface FastEthernet0/0
RouterA(config-if)# standby 1 preempt
RouterA(config-if)# standby 2 preempt
RouterB(config)# interface FastEthernet0/0
RouterB(config-if)# standby 1 preempt
RouterB(config-if)# standby 2 preempt
Esta configuración asegura que ambos routers se respalden

mutuamente. Habrá que configurar la mitad de los clientes
finales para que tengan por default gateway a la 10.0.0.1 y la
otra mitad la 10.0.0.2.
Con "show standby" comprobamos la información de los
grupos e interfaces:
RouterB#show standby
FastEthernet0/0 - Group 1
Local state is Standby, priority 110, may preempt
Hellotime 1 sec, holdtime 3 sec
Next hello sent in 0.251
Virtual IP address is 10.0.0.1 configured
295
Active router is 10.0.0.3, priority 255 expires in 1.325
Standby router is local
1 state changes, last state change 12:23:33
Con "show standby interfaz" podemos ver la informa-

ción HSRP para un interfaz concreto
RouterB#show standby FastEthernet 0/0
FastEthernet0/0 - Group 1
Local state is Standby, priority 110, may preempt
Hellotime 1 sec, holdtime 3 sec
Next hello sent in 0.015
Virtual IP address is 10.0.0.1 configured
Active router is 10.0.0.3, priority 255 expires in 1.096
Standby router is local
1 state changes, last state change 12:25:01
Y con "show standby brief" vemos un resumen por

grupos:
RouterB#show standby brief
Interface Grp Prio P State Active addr Standby addr Group addr
Fa0/0 1 110 P Standby 10.0.0.3 local 10.0.0.1
Fa0/1 2 120 P Active local 10.0.0.4 10.0.0.2
7.3. DHCP
7.3.1. Fundamentos
El protocolo DHCP (Dynamic Host Configuration Protocol)
se usa para permitir que los dispositivos finales consigan su
configuración de red de forma automática. Se basa en un pro-
tocolo anterior denominado BOOTP (Bootstrap Protocol), y usa
los puertos UDP 67 y 68.
Nota: DHCP está definido en los RFC 2131 y 2132.
Para configurar un router Cisco como servidor DHCP de-
bemos decidir en primer lugar cual es el rango de direcciones
a repartir, en nuestro caso 10.0.0.0/24 a continuación configu-
raremos las órdenes "service dhcp" e "ip dhcp"
Router(config)# service dhcp
Router(config)# ip dhcp pool DHCPLOCAL
296
Router(dhcp-config)# network 10.0.0.0 255.255.255.0
Router(dhcp-config)# default-router 10.0.0.1
Router(dhcp-config)# exit
Router(config)# ip dhcp excluded-address 10.0.0.1 10.0.0.30
Router(config)# ip dhcp excluded-address 10.0.0.200 10.0.0.255
Router(config)# end
En este ejemplo lanzamos el proceso proceso DHCP con

"service dhcp", declaramos el rango de direcciones dándole
un nombre "ip dhcp pool DHCPLOCAL", declaramos el rando
de direcciones con "network" y excluimos con "ip dhcp
excluded-address" dos serie de bloques de Ips, las bajas
generalmente para servidores, impresoras y dispositivos de
red que precisan una IP fija así como otro bloque al final para
uso futuro. Además no sólo proporcionamos una dirección
IP y una máscara de red a los clientes DHCP sino que con la
orden "default-router 10.0.0.1" les pasamos una puerta
de enlace indicándoles el router a utilizar.
Puede ocurrir que no queramos que el router haga de ser-
vidor DHCP y reparta direcciones sino que el propio router
sea un cliente DHCP, tomando una dirección de un servidor
DHCP. Para ello usaremos la orden "ip address dhcp":
Router(config-if)# ip address dhcp
Router(config-if)# end
Router#
Interface FastEthernet0/1 assigned DHCP address 10.0.0.31, mask 255.255.255.0
En ocasiones podemos necesitar que un router deje pasar

peticiones DHCP de los sistemas de una red a un servidor
DHCP localizado en otra red. Con la orden "ip helper-
address" reenviamos estas peticiones DHCP.
Router(config)# interface Ethernet0
Router(config-if)# ip helper-address 172.16.1.1
Router(config-if)# ip helper-address 172.16.1.7
Router(config)# end
Router#
Una vez que el servidor DHCP está funcionandoel router
empieza a repartir IPs a los dispositivos, llevando la pista de
las direcciones repartidas a través de un proceso denbominado
297
binding, por el que enlaza las direcciones MAC de los dispo-
sitivos con las Ips disponibles en el pool. Con la orden "show
ip dhcp binding" podemos ver como va el reparto:
Router1#show ip dhcp binding
IP address Hardware address Lease expiration Type
172.16.1.51 0100.02a5.85e9.77 Jun 10 2005 06:45 PM Automatic
172.16.1.52 0100.20ba.216e.a1 Jun 10 2005 06:46 PM Automatic
172.16.1.53 0100.31c1.aeb1.e1 Jun 10 2005 06:48 PM Automatic
Las direcciones MAC tienen un aspecto inusual: DHCP

le añade un código delante para indicar el tipo de dirección
repartida (en este caso 01, para indicar que se trata de una
Ethernet MAC).
7.4. SNMP
7.4.1. Fundamentos
Una red se compone de muchos equipos distintos y dis-
persos. El protocolo SNMP (Simple Network Management
Protocol) proporciona un método para gestionar todos estos
equipos. La gestión puede ir desde la simple monitorización
(estado de las líneas, tráfico, condiciones ambientales) hasta
cambios remotos de la configuración. Un dispositivo SNMP
puede generar bajo determinadas circunstancias paquetes
SNMP (un trap) con información acerca del evento que lo ha
disparado.
Nota: El protocolo SNMP es descrito en los RFCs que van

del 2570 al 2580. El RFC 2578 "Structure of Management
Information Version 2 (SMIv2)" describe el estado actual
del protocolo. Puede conseguirlo en el sitio Web ftp://ftp.
rfc-editor.org/in-notes/rfc2578.txt. SNMP usa los puertos
UDP 161 y 162.
La orden para configurar el protocolo SNMP es "snmp-
server":
snmp-server community patos RO 10
snmp-server community salvajes RW 20
snmp-server contact redesyseguridad@gmail.com
snmp-server location Edificio1
298
snmp-server chassis-id 156258255AA
snmp-server host 10.0.0.1 salvajes

access-list 20 permit 172.16.10.1
Con "snmp-server community" especificamos la co-

munidad (una especie de contraseña), el nivel de privilegios
(RW da permisos de lectura y escritura - Read/Write y RO da
permisos sólo de lectura - Read Only) y la lista de acceso que
especifica las máquinas que disfrutarán de esos privilegios
(RO la red 172.16.0.0, RW la máquina 172.16.10.1). Piense en
la comunidad como si fuera una contraseña.
No es recomendable utilizar como comunidad las cadenas
public y private, dado que muchos equipos las llevan habili-
tadas por defecto. Son corrientes los ataques en los que se
mandan comandos SNMP con la comunidad "privada" indi-
cando al dispositivo que se resetee o entregue información
confidencial.
Nota: "Onesixtyone" es una herramienta para llevar a

cabo ataques de diccionario contra máquinas SNMP. Si el
ataque brute force identifica la cadena de la comunidad ésta
es mostrada junto con información acerca del sistema.
BT onesixtyone-0.3.2 #onesixtyone -c dict.txt 10.1.1.175

Scanning 1 hosts, 64 communities
10.1.1.175 [enable] Cisco Internetwork Operating System
Software IOS (tm) C2600 Software (C2600-IK9O3S3-M),
Version 12.2(15)T17, RELEASE SOFTWARE (fc1) Technical
Support: http://www.cisco.com/techsupport Copyright (c)
1986-2005 by cisco Systems, Inc. Compiled Fri 12-Aug
10.1.1.175 [Cisco] Cisco Internetwork Operating System
Software IOS (tm) C2600 Software (C2600-IK9O3S3-M),
Version 12.2(15)T17, RELEASE SOFTWARE (fc1) Technical
Support: http://www.cisco.com/techsupport Copyright (c)
1986-2005 by cisco Systems, Inc. Compiled Fri 12-Aug
La información de contacto, localización y chasis es op-

cional. Mediante la orden "snmp-server enable traps"
indicamos cuales son los eventos que resultarán en el envío de
una interrupción al servidor SNMP central. El servidor SNMP
se configura con la orden "snmp-server host IP traps
Comunidad [puerto UDP] [identificador de trap]".
En la tabla 7.1 tenemos una lista de identificadores de trap que
podemos especificar.
299
Tabla 7.1. Interrupciones de SNMP.
Identificador Acción
Bgp Permite interrupciones BGP

Bstun Permite interrupciones bstun
Config Permite interrupciones SNMP
Dlsw Permite interrupciones dlsw
Dspu Permite interrupciones dspu
Entity Permite interrupciones entity
frame-relay Permite interrupciones Frame-Relay
Isdn Permite interrupciones RDSI
Rsrb Permite interrupciones rsrb
Rtr Permite interrupciones RTR
Sdlc Permite interrupciones sdlc
Sdllc Permite interrupciones sdllc
Snmp Permite notificaciones SNMP
Stun Permite interrupciones stun
tty Permite interrupciones TCP
Para ver el estado del protocolo SNMP usaremos "show
snmp"
Sagan#show snmp
Chassis: 156258255AA
Contact: redesyseguridad@gmail.com
Location: Edificio1
40581 SNMP packets input
0 Bad SNMP version errors
306 Unknown community name
0 Illegal operation for community name supplied
0 Encoding errors
298532 Number of requested variables
38 Number of altered variables
39854 Get-request PDUs
685 Get-next PDUs
38 Set-request PDUs
41722 SNMP packets output
0 Too big errors (Maximum packet size 1500)
0 No such name errors
0 Bad values errors
0 General errors
300
40275 Response PDUs
1447 Trap PDUs
SNMP logging: enabled

Logging to 10.0.0.1.162, 0/10, 1280 sent, 167 dropped.
7.5. NTP
7.5.1. Fundamentos
Vimos en apartados anteriores que el router puede regis-
trar eventos, pero para que estos queden registrados con la
hora correcta es preciso un mecanismo automático que per-
mita configurar la hora de una forma fiable y consistente en
los distintos dispositivos de red. El protocolo NTP (Network
Time Protocol) es un protocolo diseñado para sincronizar una
red de máquinas. NTP consigue la hora de una fuente fiable y
la distribuye. El protocolo NTP usa una medida que describe
a cuantos pasos (stratum) está una determinada máquina de
una fuente fiable. "stratum 1" toma la hora directamente de un
reloj atómico, "stratum 2" recibe vía NTP información directa
de un dispositivo "stratum 1", etc...
Nota: Puede consultar la especificación del protocolo NTP en

el RFC 1305: "Network Time Protocol (Version 3)". Puede
conseguirlo en la dirección ftp://ftp.rfc-editor.org/in-notes/
rfc1305.txt.
Para configurar NTP use la orden "ntp access-group
peer" seguido de un número de lista de acceso. Con esta
orden permitimos al sistema que se sincronice con un sistema
cuya dirección pase el criterio indicado en la lista de acceso.
Con "ntp server" indicamos las fuentes de información NTP.
Indicamos en la lista de acceso las direcciones de las fuentes
de información horaria.
ntp access-group peer 5
ntp server 192.168.100.5
ntp server 192.168.100.6
301
Podemos comprobar el funcionamiento de NTP con las ór-
denes "show ntp status" y "show ntp association":
Sagan#sh ntp status
Clock is synchronized, stratum 5, reference is 192.168.200.60
nominal freq 249.5901 Hz,actual freq 250.0002 Hz,precision 2**16
reference time is C196B9F5.DC1980F5 (06:04:53.859 MET Tue Jun 3 2009)
clock offset is 465.9890 msec, root delay is 73.56 msec
root dispersion is 1229.55 msec, peer dispersion is 775.79 msec
Sagan#sh ntp association

address ref clock st when poll reach delay offset disp
+~192.168.100.5 10.0.2.144 2 22 64 77 70.7 478.56 609.1
*~192.168.100.6 10.0.2.144 2 36 64 77 70.5 453.42 582.4
* master(sync),# master(unsync),+ selected,- candidate,~ configured
7.6. SLB
El servicio SLB (Server Load Balancer) permite agrupar
una serie de servidores ofreciendo al exterior una IP virtual
a la que los clientes se conectan. A medida que se establecen
nuevas conexiones al servidor virtual SLB reparte las peti-
ciones entre los servidores mediante un mecanismo de re-
parto de carga.
7.6.1. Fundamentos
Existen varios mecanismos de reparto de carga. Tenemos
"Weighted round robin" por el que a cada servidor real se le
asigna un valor que indica cuantas conexiones recibirá hasta
que el balanceo pasa al siguiente servidor del pool, "Weighted
least connections" por el que SLB redirige la nueva conexión al
servidor real que presenta un menor número de conexiones
activas.
Se puede configurar el servidor virtual para que responda
a todos lo puertos TCP y UDP de la granja, o sólo a puertos
concretos. Mediante el mecanismo de conexiones persistentes
("Sticky connections") se puede configura SLB para que las
nuevas conexiones de un cliente ya existente se redirijan al
último servidor real que el cliente utilizó. SLB permite sacar
servidores de la granja "en caliente" (por ejemplo por nece-
sidades de mantenimiento), y previene algunos ataques de
denegación de servicio (SYN floods)
302
Figura 7.7. Router SLB.
Tenemos un router SLB con IP local 10.0.0.1 e IP pública
9.1.1.1.
interface fastethernet 0/0
description Granja de servidores
ip address 10.0.0.1 255.255.255.0
interface Serial 0/0

description Red de clientes
ip address 9.1.1.1 255.255.255.0
Los servidores, agrupados bajo la denominación GranjaWeb,

tienen las direcciones IP 10.0.0.10, 10.0.0.11, 10.0.0.12 y 10.0.0.13.
Damos a dos de los servidores un peso de 32, un peso de 16 a
otro y al último un peso de 8.
ip slb serverfarm GranjaWeb
predictor leastconns
nat server
real 10.0.0.10
weight 32
inservice
real 10.0.0.11
weight 32
inservice
303
real 10.0.0.12
weight 16
inservice
real 10.0.0.13
weight 8
inservice
y configuramos el servidor virtual

ip slb vserver BalanceadorCisco
serverfarm GranjaWeb
virtual 172.30.29.100 tcp www
client 172.16.0.0 255.255.0.0
sticky 120
synguard 700 1000
inservice
Veamos la configuración línea a línea: al servidor virtual

le llamamos BalanceadorCisco, le damos la IP 9.1.1.100 y le
indicamos que balanceé sólo el tráfico web.
ip slb vserver BalanceadorCisco
serverfarm GranjaWeb
virtual 9.1.1.100 tcp www
Sólo permitimos conectarse a la granja a los clientes de la

red 200.0.0.0/16
client 200.0.0.0 255.255.0.0
Las conexiones son persistentes (sticky), de forma que si ha

habido una conexión anterior entre ese cliente y un servidor
de la granja en los dos minutos anteriores SLB lo pasa a ese
servidor
sticky 120
También configuramos "SYN guard" para prevenir ataques

de denegación de servicio, limitando el número de peticiones
TCP SYN a 700 por segundo (1000ms)
synguard 700 1000
Y ponemos todo en marcha

inservice
Mediante la orden "show ip slb vserver" podemos ver la
información referente al servidor virtual, tales como su estado
o el número de conexiones.
304
router #show ip slb vserver
slb vserver protocal virtual state conns
----------------------------------------------------------------------
GranjaWeb TCP 9.1.1.100/32:80 OPERATIONAL 4
Con la orden "show ip slb reals" podemos conocer el

estado de la granja de servidores, el "predictor" utilizado para
realizar el balanceo (en este ejemplo round robin por defecto).
router#show ip slb serverfarm
server farm predictor nat reals bind id
-----------------------------------------------------------------
GranjaWeb ROUNDROBIN none 2 0
Si es preciso podemos ver el funcionamiento interno del SLB

mediante la orden "debug ip slb connections". Recuerde
desactivarlo cuando termine con la orden "undebug all".
1d12h: SLB_CONN_DEBUG: TCP event= SYN_CLIENT,
state= INIT -> SYNCLIENT
1d12h: v_ip= 9.1.1.100:80 (5), real= 10.0.0.10
1d12h: client= 200.0.0.15:35006
1d12h: SLB_CONN_DEBUG: TCP event= SYNACK_SERVER,
state= SYNCLIENT -> ESTAB
1d12h: v_ip= 9.1.1.100:80 (5), real= 10.0.0.10
1d12h: client= 200.0.0.15:35006
1d11h: SLB_CONN_DEBUG: TCP event= DATA_CLIENT,
state= ESTAB -> ESTAB
1d11h: v_ip= 9.1.1.100:80 (5), real= 10.0.0.10
1d11h: client= 200.0.0.15:34999
1d11h: SLB_CONN_DEBUG: TCP event= DATA_SERVER,
state= ESTAB -> ESTAB
1d11h: v_ip= 9.1.1.100:80 (5), real= 10.0.0.10
1d11h: client= 200.0.0.15:34999
305
8
Resolución de Problemas
"Los problemas al principio son difíciles de detectar y fáciles

de corregir, y al final terminan siendo fáciles de percibir y
difíciles de arreglar." El Príncipe. Maquiavelo.
Un router es un ordenador, los ordenadores son máquinas

y las máquinas terminan fallando. Antes o después las redes
se estropean, las líneas de comunicaciones se cortan, las insta-
laciones se inundan, las tormentas rompen routers, switches
y ordenadores, los cables de la red local se deterioran y, por
supuesto, se cometen fallos al configurar y trabajar con los
equipos: direcciones o máscaras erróneas, encapsulados in-
consistentes y malentendidos (o sobreentendidos) a la hora de
acordar quién se ocupa de qué son sólo algunos de los muchos
problemas que las redes pueden presentar. En este capítulo
empezamos presentando algunas estrategias de resolución
de problemas de carácter general para pasar a proponer un
método de trabajo específico para tratar problemas de routers
y redes. A lo largo del capítulo veremos algunas de las herra-
mientas de trabajo del administrador de redes.
8.1. Aspectos y métodos generales

Tenemos un problema cuando aceptamos una tarea sin saber
de antemano cómo resolverla. Partiendo de un estado inicial
de incertidumbre dirigimos nuestros esfuerzos hacia un estado
final: la meta o solución del problema. Los problemas difieren
unos de otros en su complejidad, en la bondad de su definición
e incluso en la modestia (o ambición) de su alcance.
307
Para solucionar problemas de forma sistemática y efectiva no
sólo hacen falta técnicas: hay que seguir un método, una estra-
tegia que dirija las tácticas en la dirección adecuada. Cada per-
sona desarrolla un sistema propio basándose en su experiencia,
conocimientos y en observación. A medida que nos enfrentamos
a más problemas vamos aprendiendo de nuestros éxitos y fallos
y mejoramos. Vamos a examinar el método propuesto por el
matemático húngaro George Pólya en su libro "Cómo resolverlo".
Su sistema consta de cuatro pasos: entender el problema, diseñar
un plan, ejecutarlo y comprobar la solución.
Figura 8.1. Estrategia general de resolución

de problemas (George Pólya, "Cómo resolverlo").
308
Nota: En una larga entrevista publicada en el libro
"Programadores en acción" (Susan Lammers, Anaya
Multimedia 1988) Charles Simonyi, programador jefe de
Microsoft y responsable de productos como Word, des-
cribía como los programadores que contrataban recibían
dos libros el primer día de trabajo: "Uno de ellos, llamado
"Cómo resolverlo", de George Pólya [...] es como una lista
de comprobaciones para la resolución de problemas. Esto es
la lista de comprobaciones de prevuelo, la de despegue y la
de aterrizaje. No significa que esta lista vaya a enseñarte a
volar; pero, si no haces lo que dice, puedes estrellarte incluso
si ya sabes volar".
Puede leer en la página http://programmersatwork.wor-
dpress.com/programmers-at-work-charles-simonyi/ la en-
trevista original.
8.1.1. Entender el problema

Lo primero que hay que hacer a la hora de resolver un pro-
blema es comprenderlo. No se puede pretender resolver un
problema sin saber lo que significa. Identificar con claridad la
incógnita y los datos de partida, hacer un esquema o dibujo de
la situación o usar una notación adecuada son pasos necesarios
para no perdernos antes de empezar. No conviene especular
o actuar sin comprender cuál es el objetivo, la meta hacia la
cuál dirigir nuestros esfuerzos. Conviene tener una imagen
clara del objetivo, por eso se dice que el astuto empieza al final
mientras que el necio termina al comienzo. La comprensión
del problema tiene un sentido estratégico.
Para los usuarios finales de un sistema interconectado el
problema (y su solución) suele ser percibido como algo sen-
cillo: la conexión va lenta o no va en absoluto. Depende de la
habilidad del administrador el hacer las preguntas necesarias
para extraer la información que le permita definir el problema:
¿Ha habido algún cambio? ¿Falla desde todas las máquinas
o desde algunas? ¿Falla siempre o esporádicamente? ¿Ha
habido problemas eléctricos? ¿Cómo están los aparatos?
¿Muestran actividad? ¿Están encendidos? Posiblemente de
todas estas preguntas la de si ha cambiado algo recientemente
sea la más útil de todas, aunque no siempre el usuario sea
capaz de decírnoslo.
Un problema especial lo constituyen los problemas en
los cuales un servicio nunca ha funcionado o siempre lo ha
309
hecho mal. En estos casos el objetivo consiste en proporcionar
un nuevo servicio (de correo, de navegación, de descarga de
ficheros…) o en mejorar las condiciones en las que ese ser-
vicio se presta. En este contexto puede parecer innecesario el
preguntarse si ha habido cambios, pero si nos planteamos la
mejora de un servicio o su provisión como una tarea a realizar
de forma gradual y vamos probando cada paso de forma sis-
temática entonces la pregunta de si algo ha cambiado vuelve
a tener sentido.
8.1.2. Diseñar un plan

Concebir un plan es un paso fundamental a la hora de
resolver el problema. Aquí la intuición, perseverancia, expe-
riencia y suerte son decisivas. Pero no basta con esperar un
golpe de suerte: las personas que se dedican a resolver pro-
blemas saben como crear su propia suerte. Aunque se ha dicho
mucho acerca del papel de la suerte en este contexto, existiendo
incluso la palabra serendipia para referirse a su papel en los
descubrimientos, un análisis de la actitud de los inventores
muestra una capacidad de observación y persistencia mayor de
la normal. Hay que estar preparados para aprovechar la suerte
cuando pasa. Ramir, Shamir y Adelman, los desarrolladores
del sistema de criptografía de clave pública RSA, dicen que
hay que ser también algo estúpidos, por que sólo un estúpido
fallaría intentando hacer algo 99 veces consecutivas y probaría
a hacerlo la número 100.
En esta fase trata de cómo encontrar una conexión entre los
datos y la incógnita. Pólya da mucha importancia al uso de la
analogía en este punto. ¿Hemos visto antes este mismo pro-
blema? ¿O uno similar en una situación diferente? ¿Podemos
usar las soluciones de problemas resueltos similares? Otra
aproximación consiste en redefinir el problema. Si no se puede
resolver el problema, podemos intentar resolver un problema
similar más sencillo, más general o más concreto… También
podemos tratar de resolver parte del problema.
8.1.3. Ejecutar el plan

De nada sirve diseñar planes si no se ejecutan. Llegados
a este punto conviene ponerse manos a la obra, teniendo en
cuenta que lo perfecto es enemigo de lo bueno: si esperamos
310
las condiciones ideales puede que estas nunca se den. Aquí
lo más importante es armarse de paciencia e intentar ver con
claridad que cada paso dado es correcto.
Hay que tener en cuenta que pese a tener las líneas maes-
tras resueltas por el plan, puede haber muchos detalles por
resolver. Si el problema es demasiado grande conviene des-
componer su resolución en fases e ir comprobando las solu-
ciones parciales.
Truco: Cambie una cosa cada vez, y compruebe el efecto. Si

cambia varios parámetros y soluciona el problema no sabrá
cual ha sido la solución.
8.1.4. Comprobar la solución

Se trata de mirar atrás y examinar la solución obtenida, in-
tentando verla de una vez. Hay que comprobar el resultado y
ver si resuelve el problema planteado. Ahora podemos también
plantearnos mejorar la solución e intentar extraer conclusiones
que nos sirvan para otros problemas. Pólya decía que al en-
contrar una seta o lograr un descubrimiento conviene mirar
alrededor, dado que crecen en grupo.
A continuación veremos un método más específico para
tratar problemas de redes.
8.2. Métodos específicos

Nota: "Siendo mi propósito escribir algo útil para quien lo
lea, me ha parecido más conveniente ir a la verdad real de
la cosa que a la representación imaginaria de la misma." El
Príncipe, Maquiavelo.
Vamos a ver en este apartado un método de resolución de

problemas basado en el modelo de capas. Recordemos que los
modelos de referencia OSI y TCP/IP presentados en el primer
capítulo constituyen la referencia para la interconexión de sis-
temas de red. Estos modelos (Figura 8.2) dividen el proceso
de comunicación en capas conectadas mediante interfaces.
Internamente las capas cambian reflejando las tecnologías
pero, al mantenerse los puntos de contacto entre las capas, los
cambios internos no afectan al modelo general.
311
Figura 8.2. Modelo de referencia de redes.
La idea consiste en ir probando las capas una a una: si una

de las capas no funciona correctamente, las que dependen de
ella tampoco lo harán. Hay que ir comprobando capa a capa
el funcionamiento del sistema. Nos centraremos en las capas
inferiores del modelo de referencia de redes, que es fundamen-
talmente donde operan los routers.
8.2.1. Comprobando el nivel físico

Comenzaremos por la capa física: aquí tenemos los cables
y conectores, con su patinaje y sus características eléctricas. Si
hay problemas a este nivel no podemos esperar que el NAT
o el SLB vayan a funcionar mucho mejor, caso de que vayan
en absoluto.
Interfaces del router

La orden básica para examinar el estado de las interfaces
del router es "show interface" seguida opcionalmente de
la interfaz específica que queramos comprobar, en el ejemplo
la interfaz Serie0/0:
312
Alan#sh int Serial0/0
Hardware is HD64570
Internet address is 192.168.71.2 255.255.255.252
Output queue: 62/64/43770565 (size/threshold/drops)
Conversations 30/72 (active/max active)
3787 input errors,9 CRC,0 frame,1760 overrun,1760 ignored,6 abort
0 output errors, 0 collisions, 3 interface resets, 0 restarts
Con esta orden podemos obtener mucha información de

los niveles físico y de enlace. La primera línea resume el es-
tado de la línea y del protocolo. Podríamos tener las siguientes
combinaciones:
"Serial0/0 up, line protocol is up" indica un funcionamiento
físico adecuado tanto a nivel físico como de enlace. Éste es
nuestro caso: el router detecta señal de línea (Serial0/0 up) y
además está intercambiando "saludos" (hello/keepalives) con
el lado remoto (line protocol is up).
"Serial0/0 is down, line protocol is down" generalmente indica
que la interfaz no detecta señal de la línea. Compruebe el es-
tado de las luces del módem o unidad CSU/DSU. También
puede deberse a que el cable utilizado no sea el adecuado o
no esté en buen estado. Pruebe con uno de repuesto o inter-
cámbielo por uno que funcione bien. Descarte que se trate
de un problema de la interfaz física del router cambiando la
configuración a otra interfaz (por ejemplo del serial 0 al serial
1) y pasando el cable a dicha salida para ver si el problema
desaparece. Pida a su proveedor de servicios que le pruebe la
línea haciendole un bucle para verificar que hay continuidad
de señal hasta su CDU/DSU. Cambie o sustituya el módem
por uno que funcione correctamente y tenga en cuenta que
después de tormentas y fallos eléctricos son claros candidatos
a problemas diversos.
"Serial0/0 is up, line protocol is down" indica que el protocolo
está caído: no intercambia "saludos" con el extremo remoto. Se
trata de un problema de nivel de enlace. Hay que preguntarse
313
si está el otro lado activo. Compruebe el estado de la interfaz en
el extremo remoto. Esto no siempre es posible, puede necesitar
la cooperación del administrador del otro lado. Compruebe
el cableado y la calidad de la línea. En los casos en los que el
router ponga el reloj (sea DCE y no DTE) compruebe que esté
configurado para dar la señal con la orden "clockrate" y
que la velocidad sea consistente entre ambos extremos. Si la
salida fuera la de una interfaz Ethernet ("Ethernet0/0 is up, line
protocol is down") una caída del protocolo indica que el router
no detecta la red local (los keepalives no reciben respuesta y
la red está "caída a nivel de protocolo"). Generalmente esto
se debe a que el concentrador o conmutador de la red local
está apagado, el cable de red desconectado, problemas con el
transceiver, etc… También puede tratarse de un problema de
autenticación del protocolo PAP/CHAP.
"Serial0/0 is up, line protocol is up (looped)" indica que la in-
terfaz o el módem están en modo de prueba. Compruebe que
en la configuración no aparezca la orden "loopback" y si está
deshabilítela con "no loopback". Si es el módem el que está en
bucle (lo que puede venir indicado por indicadores como B2L,
B2R, B3L o 142) intente quitar el modo de prueba consultando
la documentación del mismo. A veces reseteando el módem
se terminan algunos de esos modos.
"Serial0/0 is up, line protocol is down (disabled)" muestra pro-
blemas derivados de una alta tasa de error en las interfaces o
en los dispositivos. Intercambie o sustituya componentes para
determinar cual es el que falla.
"Serial0/0 is administratively down, line protocol is down" sig-
nifica casi con seguridad que la interfaz está deshabilitada con
la orden "shutdown". Actívela con "no shutdown".
En el ejemplo vemos como a continuación aparece informa-
ción de la dirección IP asignada a la interfaz (información de
nivel de red). También tenemos información acerca del tipo de
hardware que equipa la interfaz. En nuestro ejemplo se trata de
una tarjeta HD64570, aunque encontrará una gran variedad en
este punto: QUICC, LANCE (LAN Controller Ethernet), AmdFE,
PQUICC_SAR, MCI, DEC21140A, M1T-T3+, oc3suni, ATM
Swi/Proc, etc… Seguidamente encontrará información acerca
de los valores de tamaño de paquete (MTU), ancho de banda
(BW), retraso (DLY), fiabilidad (rely) y carga (load):
La fiabilidad de este enlace es muy alta, 255/255 representa

una fiabilidad máxima, pero la carga del enlace también es
314
bastante alta (205/255, en torno al 80 por 100), lo que puede ser
un indicio si se presentan problemas de lentitud y pérdida de
paquetes. El grueso de la salida de esta orden hace referencia
a aspectos de nivel de enlace que veremos con más detalle
en el siguiente apartado, tales como el encapsulado, colas,
estadísticas de errores, tráfico, etc… En el ejemplo tenemos la
encapsulación HDLC:
Como nuestro ejemplo es de una interfaz serie la salida

termina indicando el estado de las señales de enlace entre el
DTE y el DCE.
Vemos en la Tabla 8.1 cuáles son y quién las pone
Tabla 8.1. Señales de enlace DTE/DCE.

Señal Significado Sentido
DCD (Data Detección de portadora DTE <- DCE

Carrier Detect)
DSR (Data Módem ("Data set") DTE <- DCE
Set Ready) preparado
DTR (Data Terminal de datos DTE –> DCE
Terminal Ready) preparado
RTS (Request Petición para enviar DTE –> DCE
to Send)
CTS (Clear Permiso para enviar DTE <- DCE
to Send)
Dependiendo de qué función tenga nuestra interfaz (DTE o

DCE) tendremos que "poner" o nos tendrán que "dar" unas u
otras señales. Resumiendo, el que hace de DTE pone las señales
DTR y RTS. El equipo que hace de DCE (el que pone el reloj) se
encarga de las señales DCD, DSR y CTS. Por ejemplo, si hacemos
de DCE y vemos en la interfaz la siguiente combinación
DCD=up DSR=up DTR=down RTS=down CTS=up
sabremos que faltan las señales del lado DTE. Generalmente

con las líneas punto a punto o Frame Relay nosotros haremos
de DTE y el dispositivo de la compañía proveedora hace de
DCE (en definitiva, que el reloj nos lo pone el proveedor, y
315
no nosotros a ellos). En consecuencia es mucho más frecuente
encontrarnos con la siguiente combinación, que indica un pro-
blema con la línea o el módem:
DCD=down DSR=down DTR=up RTS=up CTS=down
Otra orden que le resultará muy adecuada en este punto es

"show controllers", también seguida opcionalmente de la
interfaz a comprobar. Entre los muchos datos que encontrará
en la salida de esta instrucción podrá ver el tipo de cable, co-
nector, función, aspectos del patillaje, etc. En la siguiente salida
vemos que la controladora detecta la presencia de un cable
V35 DTE, así como la presencia de señales de sincronía tanto
en transmisión como en recepción:
DTE V.35 TX and RX clocks detected.
El módem
Es el dispositivo que permite adaptar la línea física a los
equipos terminales de datos (DTE) como el router. Según el
modelo y tipo de línea también se les denominará CSU/DSU
(Channel Service Unit/Data Service Unit), UTR (Unidad de
Terminación de Red), ADI, etc… La tabla 8.2 muestra algunas
de las combinaciones de las luces de una unidad DSU/CSU
junto con su significado:
Tabla 8.2. Luces del módem.
Estado Indicadores Medidas a adoptar
Funcionamiento 103, 104 y 107 No es necesaria ninguna

normal encendidas en acción. Trabajar normal-
verde, RX, TX mente.
encendidas
El módem no Leds apagados Comprobar conexión
muestra actividad eléctrica.
alguna
Problemas en Sin 104. Sin Estas luces las pone la
la línea TX. 107 línea. Comprobar si el
encendida fija módem está bien conec-
o parpadeando. tado al punto de red del
FE/DT en rojo. proveedor (roseta o base
AL (alarma) cymen). Comprobar estado
encendida. de los cables. Apagar y
encender el módem.
316
Estado Indicadores Medidas a adoptar
Problemas en Sin 103. Sin Estas luces las pone el

el router RX. router. Comprobar si el
router está encendido.
Comprobar si el router está
bien conectado al módem.
Apagar y encender el
router.
Modos de PBA, TST, 142 Estos modos de prueba
prueba encendidas sirven para comprobar
el estado de la línea, pero
mientras están lanzados
provocan incomunicación.
Si se hace alguna prueba
que implique pulsar alguno
de los botones de prueba
(B2L, B2R, B3R…) hay que
dejar la UTR en estado
normal al final. Apagar y
encender el módem.
La tabla 8.2 es orientativa. Consulte la documentación de la

unidad concreta que esté usando. Conviene revisar que todos
los cables estén bien conectados y los dispositivos de red en-
cendidos (router, módem, hub, switch…). Si algún aparato no
muestra actividad hay que comprobar la toma de corriente a
la que va conectado. No hay que confiarse por que otros apa-
ratos cercanos estén encendidos: muchos desplazamientos de
técnicos son para encender equipos. Después de tormentas o
problemas eléctricos los cables, conectores y circuitos pueden
averiarse de formas muy diversas, pudiendo mostrar luces de
actividad normal y estar fuera de servicio.
Un consejo: fíjese cómo están las luces cuando todo funcione
normalmente e investigue cuando las luces presenten una
combinación distinta (aunque puede darse el caso de que las
luces se presenten normalmente y sin embargo estar el módem
estropeado o la línea cortada).
Los cables
Los cables son la red. Podemos tener los mejores routers
del mundo: si el cableado es malo, el rendimiento será peor.
Calidad aparte, los cables se deterioran de múltiples formas:
317
se parten, cortan, mojan, aplastan, estiran, queman, retuercen,
curvan, corroen y doblan. Las carcasas y los conectores de los
cables son puntos especialmente delicados y tampoco se es-
capan de estos rigores: patillas sucias, dobladas, partidas, todo
ello debido a mala manipulación, defectos de fabricación o fin
de la vida útil del producto por mencionar sólo algunos fac-
tores. Tampoco todos los entornos tratan por igual al cableado,
ni todos los cables van apantallados ante las interferencias
electromagnéticas (Electromagnetic Interference, EMI).
El recorrido que hagan los cables influye en el tipo de in-
terferencias que sufrirán. Los cables de red hacen de antena,
captando y emitiendo señales del entorno. Conviene por tanto
evitar en la medida de lo posible las fuentes de EMI: motores
eléctricos, lámparas fluorescentes, equipos de soldadura de
arco, otros ordenadores, termostatos, secadores, aspiradores,
radares y emisores de microondas por mencionar algunas
fuentes posibles de interferencia. Cuando un cable de red pasa
cerca de una fuente intermitente de EMI los efectos pueden
ser particularmente irritantes por lo difícil que puede llegar
a ser detectar las causas del fallo (por ejemplo, cuando una
determinada línea falla cada vez que se acciona un monta-
cargas en otra zona del edificio). Contra estas interferencias
puede usar cables blindados o pasar a fibra óptica los enlaces
expuestos a entornos demasiado hostiles electromagnética-
mente hablando.
Nota: La tarea de cablear una oficina o un edificio debemos

dejarla a los profesionales del cableado estructurado. Hay que
tener en cuenta las regulaciones de seguridad, ambientales,
etc… que puedan ser de aplicación. Por ejemplo algunos cables
de PVC tienen una cubierta exterior de polivinilo que al que-
marse produce humo tóxico. Para cablear entre plantas puede
necesitar cables que no produzcan estos gases tóxicos, como
los cables plenum o LSZH (Low Smoke Zero Halogen).
También sucede a menudo que el cable esté en perfecto

estado de uso, pero que sea inadecuado para la función. Por
ejemplo, ya hemos hablado de los varios tipos de cables RJ45
(directo, cruzado, crossover) que en el sitio incorrecto pueden
crearle un problema. Si intenta probar un router conectando
directamente a la boca Ethernet el cable de red que une el PC
con el concentrador (hub) se encontrará con que no consigue
"ver" el router, dado que necesita un cable "cruzado" y no uno
"plano". Algunos routers disponen de un botón que cruza las
318
señales y que "convierte" el cable directo en uno cruzado (suele
denominarse HUB-NO HUB, o TO HUB-TO PC). Algunas in-
terfaces de gama alta son capaces de detectar el tipo de cable
conectado y configurarse en consecuencia, pero en la mayoría
de los casos necesitaremos usar un cable específico para una
función determinada.
Nota: Recordemos que el cable directo (plano, straight-through)

mantiene las conexiones de pin a pin. Se usan para conectar
dispositivos distintos: routers y PCs a concentradores y conmu-
tadores. El cable cruzado (crossover) altera el orden de los pares
críticos (pines 1 al 3 y 2 al 6) logrando alinear transmisión con
recepción. Se usan para conectar directamente un PC con un
router, un router con un router o un PC con otro PC. El cable
rollover cruza los pines de extremo a extremo (pin 1 con pin 8, 2
con 7, 3 con 6 y así hasta el 8 con 1) y se usa generalmente para
conectar un terminal (un PC o un portátil) al puerto de consola
de un router o concentrador Cisco (en el lado del PC llevarán
un adaptador DB9 o DB25 para conectar al puerto serie).
En el mercado existe una amplia oferta de equipos con los que

comprobar el estado de cables, líneas y protocolos. Por ejemplo
tenemos testers como los de la figura 8.3, existiendo modelos es-
pecíficos para RDSI, Ethernet, Token Ring, ATM, FDDI, etc…
Figura 8.3. Cable Testers.
Otros comprobadores de cables más avanzados como el

mostrado en la figura 8.4 comprueban la continuidad del ca-
bleado, la longitud del cable, detectan circuitos abiertos, cortos,
319
ruido, atenuación e incluso el tráfico. Estos comprobadores
se basan en la reflectometría en el dominio del tiempo (Time
Domain Reflectometry, o TDR). El comprobador manda un im-
pulso al dispositivo bajo estudio, que refleja la señal. Basándose
en esa reflexión se puede obtener información acerca de varias
características del dispositivo. Algunos modelos memorizan
las mediciones y con ayuda de un software proporcionado por
el fabricante permiten el volcado de los datos almacenados
simplificando la redacción de informes de certificación, docu-
mentación y verificación de instalaciones. En la publicidad de
estos productos se encuentran llamativas metáforas tales como
"radar para cables" o "estetoscopio para redes".
Figura 8.4. TDR Tester.
Otro problema que los comprobadores de cableado per-

miten resolver es el de los cables sin identificar en ambos
extremos. Con un generador de tonos y una sonda puede
identificar los extremos de un cable.
El router
Dependiendo del modelo su router Cisco poseerá unos
indicadores luminosos (LEDs). Muchos de estos indicadores
se encuentran situados en la parte trasera del equipo. El más
importante es el de OK, que se mantiene iluminado mien-
tras el funcionamiento general del sistema sea el correcto.
El resto de indicadores se corresponden con el estado de las
distintas interfaces y van situados a la derecha de los conec-
320
tores de la red local (AUI, Ethernet) y de los puertos serie
(Serial0, Serial0/0, etc), y se iluminan cuando hay actividad.
Otros routers también poseen indicadores en la parte frontal.
Igualmente los distintos adaptadores de medio (transceivers)
también llevan sus indicadores (power, link, etc…). Tenga en
cuenta que al encender el router éste pasa por un proceso de
arranque similar al de un PC (a este proceso se le denomina
POST, Power On Self Test) durante el cual, las luces pueden
presentar combinaciones inusuales. En la documentación que
acompaña al router encontrará el significado de cada indi-
cador. Recomendamos observar el estado de los indicadores
durante el funcionamiento correcto del equipo para tener un
punto de referencia.
Mediante la orden "show version" podrá conocer muchas
características del equipo (interfaces, versión IOS, caracterís-
ticas soportadas). Uno de los datos que podrá obtener también
con esta orden es cuanto tiempo lleva encendido el router (el
uptime) y la forma por la cual se encendió por última vez. La
causa más frecuente es sin duda por encendido (power on). Si
se le presenta esta situación con frecuencia tiene un problema
eléctrico. Recomendamos que revise la instalación e instale un
sistema de alimentación interrumpida (SAI).
Nureyev uptime is 4 weeks, 5 days, 17 hours, 49 minutes
System returned to ROM by power-on at 20:41:54 UTC Wed Nov 8 2000
También es habitual encontrar que la causa de arranque

fue el uso de la orden reload:
Fonteyn uptime is 2 weeks, 3 days, 7 hours, 9 minutes
System returned to ROM by reload at 17:31:52 UTC Wed Nov 8 2000
No obstante, si maneja muchos routers (o unos pocos de

forma frecuente) terminará sin duda encontrando causas de
encendido más "exóticas":
Barishnikov uptime is 1 week, 1 day, 12 hours, 36 minutes
System restarted by bus error at PC 0x30CFA1E, address 0xE5EE98
Nijinsky uptime is 1 minute

System restarted by error - Software forced crash, PC 0x3143594
Si encuentra fallos como estos últimos de forma frecuente

es posible que tenga un fallo de memoria o que necesite actua-
lizar la versión de IOS por otra más estable.
Una orden que puede proporcionar información valiosa es
"show environment". Mediante esta orden puede consultar
si el entorno del router es el adecuado desde el punto de vista
321
de la temperatura y de la alimentación eléctrica. Observará que
el resultado de esta consulta es breve y conciso:
Coltrane#show environment
All measured values are normal
"Todos los valores medidos son normales". Sin embargo,

esta orden ofrece (según el router y la versión de IOS) la posi-
bilidad de consultar los valores concretos medidos y los rangos
dentro de los cuales deben encontrarse:
Coltrane#show environment all
Power Supplies:
Power supply is Zytek AC Power Supply. Unit is on.
Temperature readings:
chassis inlet measured at 20C/68F
chassis outlet measured at 24C/75F
Voltage readings:
+3.45 V measured at +3.46 V
+5.15 V measured at +5.21 V
+12.15 measured at +12.29 V
-11.95 measured at -11.81 V
Envm stats saved 1889 time(s) since reload
Puede mostrar la información de diferentes formas usando

las opciones "show environment last" y "show environ-
ment table".
8.2.2. Comprobando el nivel de enlace

La capa de enlace se encarga de varias funciones: direc-
ciona los paquetes (para lo que usa las direcciones MAC
grabadas en las interfaces de red de los dispositivos), pro-
porciona una conexión libre de errores de nodo a nodo y
controla el flujo de datos. Protocolos fundamentales de esta
capa son el ARP y RARP que mapean las direcciones de red
con las de enlace.
En esta capa los errores de configuración más frecuentes son
los de encapsulado. Compruebe que el encapsulado concuerde:
por ejemplo en las líneas punto a punto debe coincidir entre
los extremos, mientras que en las Frame Relay debe encajar
entre el router y el switch de la central (y no necesariamente
de extremo a extremo). Para Frame Relay compruebe también
que el tipo de LMI configurado sea el correcto.
322
De nuevo la orden "show interfaces" proporciona va-
liosa información acera del estado del enlace, (line protocol is
up), así como del tipo de encapsulado y muchas estadísticas
acerca de los paquetes recibidos y transmitidos. Por ejemplo,
en la siguiente salida:
Hardware is HD64570
Internet address is 192.168.71.2 255.255.255.252
Last clearing of "show interface" counters 4w1d.
Ya hemos visto en el anterior apartado el significado de las

combinaciones que se pueden presentar en la primera línea "in-
terface is up|down, protocol is up|down" y los pasos a dar en caso
de que el protocolo esté caído. Vemos en la quinta línea detalles
del encapsulado (en nuestro ejemplo HDLC, encontrará otros en-
capsulados como FRAME-RELAY IETF, PPP, ARPA, etc…).
En función del encapsulado podemos tener estadísticas

específicas de la tecnología correspondiente. Si fuera FR ve-
ríamos valores acerca del intercambio de paquetes LMI (Layer
Management Interface) entre el router y el switch de la central.
De especial importancia es la línea "Last clearing of show
interface counters", que indica la última vez que se limpiaron
los contadores (con "clear counter"). Si vemos muchos
errores en poco tiempo tendremos que verificar la calidad de
las conexiones, el estado de la línea, etc.. En este caso hace 4
semanas que se limpiaron.
Last clearing of "show interface" counters 4w1d
A continuación tenemos estadísticas del estado de las colas

de paquetes formadas en la interfaz que estemos considerando.
Los descartes (drops) son indicio de alta utilización de la línea.
323
La siguiente información es de especial relevancia a la

hora de estudiar problemas de lentitudes y rendimiento:
nos muestra el promedio de velocidad y paquetes por se-
gundo de entrada y de salida durante los últimos 5 minutos.
Comparando esta información con la velocidad de la línea
podemos hacernos una idea de si estamos superando el caudal
contratado (lo que podría ocasionar pérdidas de paquetes,
descartes, lentitudes, etc..)
Vienen a continuación estadísticas (agregadas desde la

última vez que se limpiaron contadores) para la interfaz bajo
estudio: además de los paquetes y bytes de entrada y salida,
tenemos contadores para paquetes descartados por dema-
siado pequeños (runts), demasiado grandes (giants), errores
de comprobación de redundancia cíclica (CRC), marcos mal
formados (frame), paquetes descartados por tener los búferes
llenos (ignored), errores de sincronía (abort), transiciones de
portadora (carrier transition), etc…
Es posible que encuentre en el LOG del router ("show

logg") indicios de algunos de estos problemas:
Hardy#show logg
Log Buffer (8192 bytes):
%HD64570-5-LATECOLL: Unit 0, late collision error
%HD64570-5-WATCHDOG: Unit 0, enormous packet received
El protocolo ARP (Address Resolution Protocol) funciona a

nivel de enlace, mapeando las direcciones de red con las de la
capa de enlace. Puede comprobar con la orden "show arp" las
direcciones MAC de los dispositivos:
Hardy#sh arp
Protocol Address Age(min) Hardware Addr Type Interface
Internet 172.16.1.199 - 00b0.640c.fd20 ARPA Ethernet0/0
Internet 172.16.1.253 7 aa00.0400.0f1c ARPA Ethernet0/0
Internet 172.16.1.254 7 0020.af58.bdf3 ARPA Ethernet0/0
324
Internet 172.16.1.53 7 0030.c1c5.77f1 ARPA Ethernet0/0
Internet 172.16.1.51 7 0000.c907.6f8b ARPA Ethernet0/0
Internet 172.16.1.81 7 0050.8b33.d0fc ARPA Ethernet0/0
Internet 172.16.1.83 7 0050.8bf4.4db6 ARPA Ethernet0/0
Internet 172.16.1.89 7 0008.c7ff.6ed0 ARPA Ethernet0/0
La dirección propia (la de la interfaz del router) se identifica

fácilmente en la salida al venir indicada su edad con un guión
(en nuestro ejemplo 172.16.1.199). Una situación relativamente
corriente es encontrarse con que la única dirección conocida
por ARP es la del propio router:
Hardy#sh arp
Protocol Address Age(min) Hardware Addr Type Interface
Internet 172.16.1.199 - 00b0.640c.fd20 ARPA Ethernet0/0
Si además la interfaz aparece caída a nivel de protocolo debe

revisar la conexión del router con la red local. Recuerde lo indi-
cado en el apartado anterior respecto a las caídas de protocolo
en las interfaces Ethernet. En esta situación ("Ethernet0 is up,
line protocol is down") el router no es capaz de ver la red local.
Esta situación se da con relativa frecuencia en instalaciones
nuevas en las que no se ha conectado todavía la red local al
router, los "saludos" del router no son contestados y éste "tira"
el protocolo. Si desea probar una interfaz ethernet caída a nivel
de protocolo puede hacer que levante con la orden de interfaz
"no keepalive".
8.2.3. Comprobando el nivel de red

La capa de red se encarga de direccionar, conmutar y en-
rutar paquetes. Los problemas más frecuentes de este nivel son
el uso de direcciones y máscaras erróneas o inconsistentes.
También se presentan problemas derivados por duplicidad
de direcciones.
En esta capa además de los protocolos IP e IPv6 se encuentra
el protocolo ICMP (Internet Control Message Protocol). Vemos a
continuación dos órdenes basadas en este protocolo de con-
trol que permiten comprobar la conectividad de red: "ping"
y "traceroute".
Ping
La orden "ping" (incluida también en Windows y UNIX)
es un mecanismo universal de comprobación la conectividad
a nivel de red.
325
Nota: Ping fue originalmente escrito por Mike Muus, quién
afirmaba de su propia invención que era "un programa inge-
nioso de mil líneas escrito en una tarde" ("a thousand lines
hack completed in about one evening"). Lea la historia de ping
por el propio Muus en la dirección http://ftp.arl.mil/~mike/
ping.html. Muus fue también el autor de ttcp, herramienta
para comprobar el rendimiento de las conexiones del nivel de
transporte TCP.
Puede usar ping directamente, como en:

CerfRouter#ping 172.16.109.7
.!!!!
Los puntos indican paquetes fallidos, las exclamaciones

paquetes contestados. El caso mostrado en el que el primer
paquete se pierde es muy normal, debiéndose a que el host de
destino no está en la tabla ARP del emisor y debe realizarse
una resolución de la dirección de red-MAC. Los siguientes
llegan correctamente. Además del porcentaje de paquetes
contestados con éxito tenemos los valores del tiempo de ida
y vuelta (round-trip): el tiempo para el paquete más rápido,
el promedio y el tiempo para el paquete que más ha tardado.
Nuevamente el primer paquete puede desvirtuar los prome-
dios si no se realiza la prueba con varios paquetes o en distintas
ocasiones. En la imagen 8.5 vemos la captura de una tanda de
paquetes ICMP por un analizador de protocolo. En el panel
inferior se aprecia el contenido del campo de datos del paquete
IP/ICMP (un alfabeto).
Para sacar partido de los comandos extendidos de esta
orden introduzca "ping" sin dirección y vaya contestando las
preguntas del router (entre corchetes tendrá los valores que el
router toma por defecto):
CerfRouter#ping
Protocol [ip]:
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: Ethernet0
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
326
Sweep range of sizes [n]:
Sending 5, 100-byte ICMP Echoes to 172.16.109.7, timeout is 2 seconds:
!!!!!
Figura 8.5. Captura de tráfico ICMP (ping) con Wireshark.
Al indicar explícitamente que el origen sea la interfaz

ethernet comprobamos la conectividad de LAN a LAN. A con-
tinuación tiene un ejemplo de un ping que no ha ido bien:
CerfRouter#ping
Repeat count [5]: 100
Source address: TokenRing0
!!.!..!!!.!!!!!!!!.!..!!!!!!!!.!!!!!!!!!!!!.!!.!!!!.!!!!!.!!..
El éxito es del 77 por 100 (está perdiendo el 23 por 100 de los

paquetes). Conviene revisar las estadísticas de errores, tráfico,
etc… de las interfaces por las que estos paquetes estén pasando.
Una situación posible es la siguiente:
CerfRouter#ping
Repeat count [5]: 50
Source address: TokenRing0
327
Sending 100, 100-byte ICMP Echos to172.16.45.160, timeout is 2 seconds:
.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!
Success rate is 50 percent(25/50),round-trip min/avg/max = 56/60/80ms
Cuando pierda exactamente el 50 por 100 de los paquetes

siguiendo un patrón tan regular puede que tenga un problema
de enrutamiento: la mitad de los paquetes se van por la ruta
correcta y la otra mitad por la equivocada. Compruebe la tabla
de rutas para esa dirección con la orden "show ip route di-
rección".
Pilas de protocolos como Appletalk, Novell y Banyan
implementan igualmente mecanismos de control tipo "eco"
(IPX Echo, AEP - Appetalk Echo Protocol, VICP - Vines Internet
Control Protocol), etc… Estos mecanismos de control también
permiten la comprobación de la conectividad de red mediante
el uso de ping:
SteveWozniacRouter#ping appletalk 46.130
Sending 5, 100-byte AppleTalk Echos to 46.130, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5),round-trip min/avg/max = 24/27/32 ms
RayNoordaRouter#ping ipx 77.00f4.dfde.c680

Sending 5, 100-byte IPX Novell Echoes to 77.00f4.dfde.c680, timeout is 2 seconds:
!!!!!
La orden "ping" depende del correcto funcionamiento del

protocolo ICMP. Lamentablemente se han producido muchas
denegaciones de servicio en las cuales ping estaba implicado y
muchas redes deshabilitan o filtran los paquetes ICMP.
Traceroute
La orden "traceroute" muestra el camino que toman los
paquetes entre dos punto de una red IP.
Nota: Traceroute fue inventado por Van Jacobson, que además

es coautor de tcpdump, el programa clásico de captura de
paquetes.
Cada paquete IP tiene un campo TTL (Time-to-Live, Tiempo

de vida). Cada router resta un uno al valor de este campo
además de enviar el paquete. El objeto de este campo es acabar
con los paquetes perdidos o que están en bucle entre dos o más
dispositivos. Cuando un router recibe un paquete con el TTL a
1 lo descarta inmediatamente, mandando al emisor un mensaje
indicando que el paquete se ha descartado por este motivo.
328
Traceroute saca partido de este mecanismo de forma brillante
creando paquetes con valores pequeños de TTL: primero se fija
el TTL a 1 y el primer router del camino tira el paquete y manda
un mensaje (TIME_EXCEEDED) al emisor. A continuación se
fija el TTL a 2 y en esta ocasión es el segundo router el que lo tira
e informa al emisor, y así sucesivamente hasta que se prueba
con un TTL capaz de llegar al destino. Generalmente se pone
como puerto destino uno fuera de uso de forma que el último
sistema responde con un "PORT_UNREACHABLE". Con toda
la información que le llega de vuelta traceroute organiza una
tabla como la siguiente:
VanJacobson#trace 10.0.5.187
Tracing the route to 10.0.5.187
1 10.0.1.2 16 msec 16 msec 16 msec
2 10.0.2.2 32 msec 32 msec 32 msec
3 10.0.3.2 48 msec 48 msec 48 msec
4 10.0.4.2 64 msec 60 msec 60 msec
5 10.0.5.187 60 msec 60 msec 64 msec
Para cada valor de TTL traceroute manda tres paquetes y se

muestran los tiempos de respuesta en milisegundos para cada
uno de ellos. Si uno de los campos muestra un asterisco en vez
de un tiempo es debido a que el paquete no ha vuelto (por pro-
blemas de tráfico, de calidad de la línea, de filtros, etc…).
Debug
Una de las herramientas más potentes (y veremos que
peligrosa) del router es la orden "debug". Por medio de esta
orden podemos monitorizar casi cualquier aspecto del com-
portamiento del router. De hecho, aunque la incluimos entre
las herramientas de análisis del nivel de red, las órdenes de de-
puración pueden examinar aspectos físicos de una interfaz así
como el comportamiento de protocolos de capas superiores.
Como contrapartida debemos decir que las salidas de esta
orden pueden ser muy extensas, de forma que hay que saber
exactamente que se está buscando para no perderse en un mar
de detalles. Además existe el peligro de bloquear el router con
algunos de los "debug". Nunca debe usar debug en routers con
mucho tráfico, siendo muy conveniente tener acceso físico al
router por el puerto de consola.
Uno de los "debug" que ofrece más información y que
precisamente por este motivo puede bloquear fácilmente un
router con tráfico es "debug ip packets". Precisamente por
329
ello se debe usar con precaución y asociando la depuración a
una lista de acceso (normal o extendida).
Veamos un par de ejemplos con las siguientes órdenes:
access-list 101 permit icmp host 10.0.0.1 host 10.0.0.2
debug ip packets detailed 101
! dirigimos la salida al terminal
ter mon
Se obtiene una salida como la siguiente:

Dec 9 18:46:09: IP: s=10.0.0.1 (local), d=10.0.0.2 (Ethernet0), len 60, sending
Dec 9 18:46:09: ICMP type=0, code=0
Algunas opciones de "debug ip packets" menos docu-

mentadas ("debug ip packets detailed dump") acercan
al router a la categoría de los capturadores de tráfico, pero
recuerde (debo insistir): con estas órdenes se bloquea muy
fácilmente un router debido a la enorme cantidad de infor-
mación que generan.
También se puede monitorizar el nivel de transporte (nivel
4) con órdenes como "debug ip tcp packets". En el siguiente
ejemplo se ve como la máquina 10.0.0.2 arranca una sesión a
través del puerto local 3023 en la máquina 10.0.0.1, puerto 23
(una sesión telnet). Justo después de la hora y del tipo de paquete
aparece el sentido (I|O, Input/Output) y el estado (LISTEN,
SYNRCVD, ESTAB…) Puede apreciar el "apretón de manos" a
3 bandas característico del establecimiento de la sesión (SYN-
ACK/SYN- ACK), los números de secuencia y ventana, etc… En
la cuarta línea empieza el intercambio de datos (ACK/PSH):
Dec 9 19:09:12.379: tcp0: I LISTEN 10.0.0.2:3023 10.0.0.1:23 seq 2224776653
OPTS 8 SYN WIN 16384
Dec 9 19:09:12.387: tcp0: O SYNRCVD 10.0.0.2:3023 10.0.0.1:23 seq 3812386215
OPTS 4 ACK 2224776654 SYN WIN 4128
Dec 9 19:09:12.395: tcp0: I SYNRCVD 10.0.0.2:3023 10.0.0.1:23 seq 2224776654
ACK 3812386216 WIN 17520
Dec 9 19:09:12.403: tcp2: O ESTAB 10.0.0.2:3023 10.0.0.1:23 seq 3812386216
DATA 12 ACK 2224776654 PSH WIN 4128
Con "show debug" puede consultar qué depuración tiene

habilitada:
Sagan#sh debug
Generic IP:
IP packet debugging is on
TCP:
TCP Packet debugging is on
330
A continuación, terminaremos la depuración con "un-
debug all":
Sagan#unde all
All possible debugging has been turned off
La tabla 8.3 muestra algunos de los debugs más útiles según

el contexto que esté comprobando.
Tabla 8.3. Algunos debugs.

Contexto Debug
Frame Relay debug frame-relay lmi

EIGRP debug ip eigrp
Interfaces debug interface tipo
IP debug ip packets [detailed] [dump]
y debug ip icmp
NAT debug ip nat [detailed]
OSPF debug ip ospf events
PPP debug ppp authentication y debug
ppp negotiation
RDSI debug isdn q921 y debug isdn q931
TCP debug ip tcp packet
8.2.3. Comprobando los niveles superiores

Existen diversas herramientas que convierten un ordenador
en un analizador de protocolo con el que monitorizar la red.
Especialmente interesantes son algunos programas gratuitos,
como el capturador de tráfico tcpdump (para máquinas UNIX)
o el analizador de protocolo Wireshark. Básicamente estos
programas ponen la tarjeta de red en modo "promíscuo" y leen
todos los paquetes que atraviesan sus interfaces. Se pueden
configurar para capturar sólo ciertos paquetes por medio de
diversos filtros.
Tcpdump/Windump imprimen una descripción de los
contenidos de los paquetes de una interfaz de red. Usado
junto con la opción "-w" graba el resultado a un fichero para
su posterior análisis. La opción "-r" permite leer el contenido
del fichero guardado. Tcpdump/Windump sigue capturando
paquetes hasta que se interrumpe, generalmente mediante la
combinación Control-C. La opción "-c" permite especificar un
331
número determinado de paquetes tras lo cual la aplicación se
detiene. En el ejemplo de la figura 8.6 hacemos uso de las op-
ciones "-npi": con "n" desactivamos la resolución DNS de forma
que muestra las direcciones en formato numérico (direcciones
IP), "p" pone la interfaz en modo promíscuo y la opción "i" con
la que indicamos que escuche una interfaz de red determinada
(la número 2 en nuestro caso). Otras opciones típicas son "-v"
(verbose) y "-x" (añade cabeceras y volcado del contenido del
paquete).
Figura 8.6. Windump.
Nota: Puede informarse de todas las opciones y posibilidades

de tcpdump / windump en la dirección Web http://www.
winpcap.org/windump/docs/manual.htm. Windump,
la versión de tcpdump para Windows, se obtiene en la página
http://www.winpcap.org/windump/. Necesitará ins-
talar antes Winpcap desde http://www.winpcap.org/
install/default.htm.
Otra potente herramienta de análisis de redes es el anali-

zador de protocolos Wireshark. Al igual que Windump captura
tráfico, pero lo hace de forma gráfica. En la figura 8.7 vemos
la pantalla inicial de Wireshark y en la figura 8.8 las opciones
de captura de tráfico.
En la figura 8.9 vemos el capturador en marcha. A medida
que va capturando tráfico muestra estadísticas del número de
paquetes y de los protocolos a los que pertenece.
332
Figura 8.7. Wireshark: pantalla inicial.
Figura 8.8. Wireshark: opciones de captura.
En la figura 8.10 se presenta la salida típica de Wireshark

en 3 paneles: el superior presenta un resumen de los paquetes,
el panel central desglosa el contenido de cada paquete capa a
capa y el panel inferior muestra un volcado del contenido del
paquete en hexadecimal y ASCII. Wireshark ofrece asistentes
que permiten extraer estadísticas y analizar el flujo de infor-
mación de diversas formas. Por ejemplo, seleccionando un
paquete TCP con el botón derecho del ratón se nos mostrarán
diversas opciones disponibles.
Figura 8.9. Wireshark: capturando tráfico.
333
Figura 8.10. Wireshark: tráfico capturado.
En la figura 8.11 tenemos el resultado de un "Follow TCP

Stream" o seguimiento de secuencia TCP. Wireshark filtra
los paquetes TCP pertenecientes al flujo del que el paquete
seleccionado forma parte y hace un volcado del payload de
los paquetes distinguiendo a dos colores la parte emitida y
la recibida.
Figura 8.11. Wireshark: seguimiento de secuencia TCP.
334
Nota: Para descargar Wireshark o consultar la documen-
tación que lo acompaña vaya a la página http://www.
wireshark.org/. En el estupendo blog "Seguridad y Redes
de Alfon" (http://seguridadyredes.nireblog.com/) tenemos
detalladas explicaciones del uso del Wireshark y muchas otras
herramientas.
8.3. Herramientas y documentación

el sistema
Debemos anticiparnos a los problemas conociendo cuál es el
funcionamiento normal de una red. Si no tenemos un punto de
referencia, no podremos posteriormente identificar las desvia-
ciones de su funcionamiento. A continuación presentamos las
principales herramientas del administrador para conocer mejor
su red y obtener la información acerca de su funcionamiento.
8.3.1. Documentación
Resulta muy útil tener el sistema bien documentado, lo que
supone disponer de la información actualizada de los sistemas
que la componen, su disposición física, la arquitectura lógica
de la red, conocer el espacio de direcciones utilizado y las ca-
racterísticas de su funcionamiento en condiciones normales.
Parte de la documentación del sistema contiene la infor-
mación referente a las compras realizadas: facturas, garantías,
contratos, números de serie, identificadores de líneas, etc…
Por otro lado, muchos de los sistemas que adquiramos vienen
acompañados de materiales, manuales, CDROM, etc…y es
necesario guardar esta documentación de forma que esté lo-
calizable y accesible en caso de ser necesaria.
También debemos mantener por escrito los procedimientos
para realizar las principales tareas. Basta con copiar la configura-
ción de un router antes y después de un cambio, señalando por
ejemplo en negrita los cambios en la configuración y añadiendo
en cursiva comentarios acerca de la función de cada orden. Una
carpeta en red en la que los técnicos vayan dejando estos sencillos
documentos acerca de cómo resolvieron tareas como un NAT
estático, un route-map o una priorización por protocolo puede
resultar extremadamente útil, además de suponer un verdadero
estímulo para los que realizan esta tarea. Conviene realizar co-
pias de seguridad de toda esta información.
335
8.3.2. Mapas de la red
Un tipo muy especial de documentación la constituyen los
mapas de red donde se detallen la topología y las direcciones
de los dispositivos. Programas como Visio permiten realizar
esquemas con los que apreciar de un sólo golpe de vista las
principales características de la red a la que nos enfrentamos.
También hay herramientas que descubren la topología de una
red y la dibujan, pero en general necesitaremos retocar el re-
sultado de estos programas.
8.3.3. Configuraciones
Otra información fundamental la constituyen las configura-
ciones de los equipos de red. Es muy importante documentar
las configuraciones de los equipos (junto con la descripción
de su instalación) y mantener una copia de esa información
en un lugar seguro. Conviene tener una copia en papel de esta
información, dado que cuando la necesitemos puede ser preci-
samente cuando los sistemas informáticos no estén disponibles.
Esto es de especial aplicación en el caso de los sistemas funda-
mentales. En caso necesario podríamos reconstruir el sistema.
Esto implica llevar un control de los cambios realizados sobre
el sistema, evitando los cambios incontrolados e indocumen-
tados. A menudo se piden cambios "para ayer" que se hacen
sobre la marcha y que no quedan reflejados en ninguna parte.
Hay que habilitar mecanismos flexibles pero sistemáticos para
llevar un control de los cambios que tienen lugar.
La orden básica para copiar las configuraciones es "copy
origen destino". Vemos a continuación algunos de los po-
sibles destinos de la configuración de arranque:
Sagan#copy startup-config ?
ftp: Copy to ftp: file system
lex: Copy to lex: file system
null: Copy to null: file system
nvram: Copy to nvram: file system
rcp: Copy to rcp: file system
running-config Update (merge with) current system configuration
startup-config Copy to startup configuration
system: Copy to system: file system
tftp: Copy to tftp: file system
Con la orden "copy startup-config tftp" copiaremos

la configuración de arranque a un servidor tftp (trivial file
transfer protocol). El sistema le preguntará la dirección del ser-
vidor tftp y el nombre que quiere dar al fichero. Puede auto-
336
matizar estas tareas con scripts de forma que las descargas se
hagan automáticamente.
8.3.4. Internet como herramienta

de resolución de problemas
Internet puede ser una herramienta prodigiosa para los
administradores de redes, pero deberá ser capaz de extraer la
información de un entorno muy "ruidoso". Una técnica que me
ha proporcionado acceso a páginas muy interesantes consiste
poner directamente en los buscadores comandos del router
(pruebe a buscar en Google "show ip route" o "show inter-
faces ethernet"). Más sorprendente todavía es el resultado
de poner en un buscador parte de la salida de un comando,
como "DCD=up DSR=up DTR=down RTS=down CTS=up".
Verá cómo una búsqueda de este tipo le lleva rápidamente
por rincones de Internet poco comunes. Aparte de la página
de Cisco (http://www.cisco.com, fundamental), menciono
en la tabla 8.4 una serie de recursos que sigo con atención.
Tabla 8.4. Algunos recursos online.

Nombre URL
Fragments http://blogs.nil.com/
Packet Life http://packetlife.net/
Cisco Learning http://blog.sazza.de/
Cyber Risk http://tools.cisco.com/security/center/
cyberRiskReport.x
IOS Hints and Tricks http://blog.ioshints.info/
CiscoBlog http://www.ciscoblog.com/
From the Field http://www.networkworld.com/commu-
nity/morris
The Platform http://blogs.cisco.com/news
Netcordia http://connection.netcordia.com/blogs/
Should Have Gone http://shouldhavegonewithcisco.com/
With Cisco
Write mem http://www.wr-mem.com/
Networkeando http://networkeando.blogspot.com/
337
A
Apéndice
A.1. Planos de funcionamiento

de un router
Las funciones de los routers pueden dividirse en una
serie de planos. Según esta clasificación tendríamos el Plano
de Gestión (Management Plane), el Plano de Control (Control
Plane), el Plano de Datos (Data Plane) y el Plano de Servicios
(Services Plane)
Figura A.1. Planos del Router.
El Plano de Control (Control Plane) procesa el tráfico que

mantiene la funcionalidad de la red. Lo conforman aplica-
339
ciones y protocolos que actúan entre los dispositivos de red,
incluyendo los protocolos de enrutamiento (BGP, EIGRP,
OSPF, IS-IS...), los mecanismos que protegen del impacto de
las cargas de tráfico sobre la CPU, la securización de BGP, los
protocolos de enrutamiento interiores así como los protocolos
de redundancia de primer salto (GLBP, HSRP y VRRP).
El Plano de Gestión (Management Plane) es el que se encarga
de manejar el tráfico que se envía a los dispositivos de red para
gestionarlos y está hecho a partir de aplicaciones y protocolos
como Telnet, SSH, SNMP, FTP, TFTP, TACACS+, Radius,
NetFlow, NTP o Syslog. En este plano caen las listas (ACLs)
que controlan el acceso a la infraestructura, el uso de AAA, el
uso de protocolos seguros para acceder y transferir datos (ssh
vs telnet, scp vs ftp), fortificación de SNMP, logging y gestión
de las configuraciones.
El Plano de Datos (Data Plane) se encarga de mover la in-
formación por la red de origen a destino, excluyendo el tráfico
que se envía a los propios dispositivos (que caería en el ámbito
del plano de Gestión) y el que se envían entre los dispositivos
para mantener la infraestructura (que pertenecería el Plano
de Control). Trata de cómo filtrar tráfico por medio de ACLs,
técnicas Anti-Spoofing, mecanismos de limitación de impacto
sobre la CPU, identificación de tráfico, control de acceso me-
diante VLAN Maps y Port Access Control Lists y el uso de
VLANs privadas.
Por último tenemos el Plano de Servicios (Services plane),
similar al de Datos en el sentido de que porta tráfico hacia,
desde y entre los usuarios, servidores y otras entidades no
enrutadoras pero que se diferencia del Plano de Datos en la
forma en que se procesan los paquetes de los servicios que lo
componen: VPN tunneling (MPLS, IPsec, SSL, GRE), traduc-
ciones (IPv6-to-IPv4, NAT), firewalls, IDS/IPS, voz , vídeo...
Todos estos servicios son típicamente manejados por proce-
sadores adicionales que funcionan en capas por encima de las
del plano de Datos tradicional, y que precisan un manejo de
extremo a extremo (QoS).
A.2. Red MPLS-BGP-Frame Relay
En el presente apéndice presentamos por cortesía de Jose

Antonio Suárez y Sergio Parras un ejemplo completo que com-
bina el uso de BGP, RIPv2 (capítulo 5) como IGP y conexiones
340
Frame Relay para acceder a una nube MPLS (capítulo 4), todo
ello montado sobre el emulador GNS3.
Figura A.2. Topología VPN IP.
MPLS y BGP ofrecen múltiples posibilidades. Para profun-

dizar en su estudio recomendamos para la parte BGP la lectura
de "Internet Routing Architectures" de Sam Halabi (Cisco Press,
2000), y para la parte MPLS el libro "MPLS and VPN Architectures"
de Ivan Pepelnjak y Jim Guichard (Cisco Press, 2002).
Figura A.3. Conexionado GNS3.
Figura A.4. Mapeado FR.
341
Edc_Rojo_Barcelona
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Edc_Rojo_Barcelona
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 10
ip cef
!
interface FastEthernet0/0
ip address 192.168.20.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description CONEXION POR SERIAL CON PE_MADRID
mtu 2098
no ip address
encapsulation frame-relay IETF
no fair-queue
clock rate 2000000
!
interface Serial0/0.260 point-to-point
ip address 172.16.2.2 255.255.255.252
!
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
!
router rip
version 2
passive-interface default
no passive-interface Serial0/0.260
network 172.16.0.0
network 192.168.20.0
342
distribute-list 99 in FastEthernet0/0
distribute-list prefix 98 out Serial0/0.260
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Serial0/0.260
!
ip http server
no ip http secure-server
!
ip prefix-list 98 description Red Lan de Cliente
ip prefix-list 98 seq 15 permit 192.168.20.0/24
access-list 99 deny any
!
control-plane
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
End
Edc_Rojo_Madrid
version 12.4
!
hostname Edc_Rojo_Madrid
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip cef
!
ip address 192.168.200.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
mtu 2098
no ip address
343
no fair-queue
clock rate 2000000
!
ip address 172.16.1.2 255.255.255.252
!
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
!
router rip
version 2
network 172.16.0.0
network 192.168.200.0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Serial0/0.260
!
ip http server
!
!
control-plane
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
end
Edc_Verde_Barcelona
version 12.4
344
!
hostname Edc_Verde_Barcelona
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip cef
!
ip address 192.168.210.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
mtu 2098
no ip address
no fair-queue
clock rate 2000000
!
ip address 172.16.2.6 255.255.255.252
!
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
!
router rip
version 2
network 172.16.0.0
network 192.168.20.0
network 192.168.210.0
no auto-summary
!
345
ip route 0.0.0.0 0.0.0.0 Serial0/0.260
!
ip http server
!
!
control-plane
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
end
Edc_Verde_Madrid
version 12.4
!
hostname Edc_Verde_Madrid
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip cef
!
ip address 192.168.200.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
mtu 2098
no ip address
no fair-queue
clock rate 2000000
!
346
ip address 172.16.1.6 255.255.255.252
!
no ip address
shutdown
duplex auto
speed auto
!
router rip
version 2
network 172.16.0.0
network 192.168.200.0
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Serial0/0.260
!
ip http server
!
!
control-plane
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
End
PE_BARCELONA
version 12.4
!
hostname PE_BARCELONA
!
boot-start-marker
boot-end-marker
!
no aaa new-model
347
!
resource policy
!
ip subnet-zero
ip cef
!
ip vrf VPNIP_ROJA
rd 100:30
export map VPNIP_ROJA
route-target export 100:30
route-target import 100:30
!
ip vrf VPNIP_VERDE
rd 100:20
export map VPNIP_VERDE
!
mpls label protocol ldp
mpls ldp loop-detection
mpls ldp explicit-null
!
archive
log config
hidekeys
!
ip address 10.0.0.20 255.255.255.0
duplex full
speed 100
mpls ip
mpls mtu 1520
!
no ip address
shutdown
duplex auto
speed auto
!
interface Serial1/0
mtu 2098
no ip address
no fair-queue
serial restart-delay 0
clock rate 2016000
no dce-terminal-timing-enable
!
ip vrf forwarding VPNIP_ROJA
348
ip address 172.16.2.1 255.255.255.252
!
ip vrf forwarding VPNIP_VERDE
ip address 172.16.2.5 255.255.255.252
!
interface Serial1/1
no ip address
shutdown
!
interface Serial1/2
no ip address
shutdown
!
interface Serial1/3
no ip address
shutdown
!
router rip
version 2
network 172.16.0.0
no auto-summary
!
address-family ipv4 vrf VPNIP_VERDE
network 172.16.0.0
no auto-summary
version 2
exit-address-family
!
address-family ipv4 vrf VPNIP_ROJA
network 172.16.0.0
no auto-summary
version 2
exit-address-family
!
router bgp 65000
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.110 remote-as 65000
neighbor 10.0.0.110 update-source FastEthernet0/0
349
!
address-family ipv4
neighbor 10.0.0.110 activate
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.0.0.110 send-community extended
neighbor 10.0.0.110 route-reflector-client
exit-address-family
!
redistribute rip route-map FILTRO_WANS
no auto-summary
no synchronization
exit-address-family
!
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
ip classless
no ip http server
!
ip prefix-list WANS seq 5 permit 192.168.0.0/16
logging alarm informational
!
route-map FILTRO_WANS deny 10
match ip address prefix-list WANS
!
route-map FILTRO_WANS permit 20
!
mpls ldp router-id FastEthernet0/0
!
control-plane
!
gatekeeper
shutdown
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
password cisco
350
login
!
!
End
PE_MADRID
version 12.4
!
hostname PE_MADRID
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip cef
!
ip vrf VPNIP_ROJA
rd 100:30
export map VPNIP_ROJA
!
ip vrf VPNIP_VERDE
rd 100:20
export map VPNIP_VERDE
!
mpls label protocol ldp
mpls ldp loop-detection
mpls ldp explicit-null
!
archive
log config
hidekeys
!
ip address 10.0.0.10 255.255.255.0
duplex full
speed 100
mpls ip
mpls mtu 1520
!
351
no ip address
shutdown
duplex auto
speed auto
!
interface Serial1/0
mtu 2098
no ip address
no fair-queue
clock rate 2016000
!
ip vrf forwarding VPNIP_ROJA
ip address 172.16.1.1 255.255.255.252
!
ip vrf forwarding VPNIP_VERDE
ip address 172.16.1.5 255.255.255.252
!
interface Serial1/1
no ip address
shutdown
!
interface Serial1/2
no ip address
shutdown
!
interface Serial1/3
no ip address
shutdown
!
router rip
version 2
network 172.16.0.0
no auto-summary
352
!
network 172.16.0.0
no auto-summary
version 2
exit-address-family
!
network 172.16.0.0
no auto-summary
version 2
exit-address-family
!
router bgp 65000
neighbor 10.0.0.110 update-source FastEthernet0/0
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
!
redistribute rip route-map FILTRO_WANS
no auto-summary
no synchronization
exit-address-family
!
redistribute rip
no auto-summary
no synchronization
exit-address-family
!
ip classless
no ip http server
!
ip prefix-list WANS seq 5 permit 192.168.0.0/16
!
route-map FILTRO_WANS deny 10
353
match ip address prefix-list WANS
!
route-map FILTRO_WANS permit 20
!
mpls ldp router-id FastEthernet0/0
!
control-plane
!
gatekeeper
shutdown
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
End
REFLECTOR1
version 12.4
!
hostname REFLECTOR1
!
boot-start-marker
boot-end-marker
!
no aaa new-model
!
resource policy
!
ip subnet-zero
ip cef
!
ip address 10.0.0.110 255.255.255.0
duplex half
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router bgp 65000
354
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
bgp redistribute-internal
exit-address-family
!
ip classless
no ip http server
!
!
control-plane
!
gatekeeper
shutdown
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
A.3. RED RIP

La red de la ilustración es la red ARPAnet inicial, en 1969.
ARPAnet fue la red precursora directa de Internet. Inicialmente
constaba de 4 routers, entonces denominados IMP (Interface
355
Message Processors) instalados en la Universidad de California
- Los Ángeles (UCLA), el Stanford Research Institute (SRI), en
la Universidad de California – Santa Bárbara (UCSB) y en la
Universidad de Utah.
Figura A.5. Arpanet 1969
Nosotros vamos a modernizar un poco la red del dibujo,

añadiendo direccionamiento IP y usando routers Cisco en
lugar de los IMPs, lo que nos permitirá crear una red mediante
interfaces y protocolos que en realidad no aparecieron hasta
unos años más tarde.
Cada uno de estos routers posee una conexión con una
red local tipo Ethernet. Además, cada uno de ellos posee uno
(UTAH), dos (UCLA, UCSB) o tres (SRI) interfaces Serie. El
router SRI constituye el nodo central de esta pequeña red,
manteniendo una conexión dedicada, punto a punto, con cada
uno de los otros dispositivos.
UCLA#show ip interfaces brief
UCSB#show ip interfaces brief

356
SRI#show ip interfaces brief
FastEthernet0 192.168.2.1 YES manual up up
UTAH#show ip interfaces brief

ROUTER UTAH
UTAH#sh run

!
version 12.2
no parser cache
no service single-slot-reload-enable
service timestamps debug uptime
!
hostname UTAH
!
logging buffered 4096 debugging
logging rate-limit console 10 except errors
!
ip subnet-zero
!
no ip domain-lookup
no ip dhcp-client network-discovery
!
interface Ethernet0
ip address 192.168.4.1 255.255.255.0
no keepalive
!
interface Serial0
description Conexion a SRI
ip address 172.16.0.14 255.255.255.252
clockrate 115200
!
router rip
version 2
network 172.16.0.0
network 192.168.4.0
no auto-summary
!
ip http server
357
ip classless
!
line con 0
stopbits 1
line vty 0 4
password cisco
login
!
End
ROUTER SRI
SRI#sh run

!
version 12.2
!
hostname SRI
!
!
ip subnet-zero
!
!
no ip domain lookup
!
ip audit notify log
ip audit po max-events 100
!
interface FastEthernet0
ip address 192.168.2.1 255.255.255.0
no keepalive
speed auto
!
interface Serial0
ip address 172.16.0.10 255.255.255.252
no fair-queue
clockrate 115200
!
interface Serial1
description Conexion a UCLA
ip address 172.16.0.2 255.255.255.252
clockrate 115200
!
interface Serial2
description Conexion a UCSB
358
ip address 172.16.0.13 255.255.255.252
!
router rip
version 2
network 172.16.0.0
network 192.168.2.0
no auto-summary
!
ip classless
no ip http server
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
no scheduler allocate
end
ROUTER UCSB
UCSB#sh run

!
version 12.3
!
hostname UCSB
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
no ip domain lookup
!
interface Ethernet0
ip address 192.168.3.1 255.255.255.0
no keepalive
!
interface Ethernet1
no ip address
shutdown
!
359
interface Serial0
description Conexion con SRI
ip address 172.16.0.9 255.255.255.252
no fair-queue
!
interface Serial1
description Conexion con UCLA
ip address 172.16.0.6 255.255.255.252
clockrate 125000
!
router rip
version 2
network 172.16.0.0
network 192.168.3.0
no auto-summary
!
ip http server
ip classless
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
password cisco
login
!
end
ROUTER UCLA
UCLA#sh run

!
version 12.2
service timestamps debug uptime
!
hostname UCLA
!
!
ip subnet-zero
!
interface Ethernet0
ip address 192.168.1.1 255.255.255.0
no keepalive
!
interface Serial0
360
ip address 172.16.0.1 255.255.255.252
no fair-queue
!
interface Serial1
ip address 172.16.0.5 255.255.255.252
!
router rip
version 2
network 172.16.0.0
network 192.168.1.0
no auto-summary
!
ip classless
ip http server
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
End
A.4. PUERTOS TCP/UDP

Tabla A.1. Puertos TCP/UDP.
Puerto/protocolo Descripción
1/tcp Multiplexor TCP

7/tcp Protocolo Echo (Eco) Reponde con eco a
llamadas remotas
7/udp Protocolo Echo (Eco) Reponde con eco a
llamadas remotas
9/tcp Protocolo Discard Elimina cualquier dato
que recibe
9/udp Protocolo Discard Elimina cualquier dato
que recibe
13/tcp Protocolo Daytime Fecha y hora actuales
17/tcp Quote of the Day (Cita del Día)
19/tcp Protocolo Chargen Generador de carac-
téres
19/udp Protocolo Chargen Generador de carac-
téres
361
20/tcp FTP File Transfer Protocol (Protocolo de

Transferencia de Ficheros) - datos
21/tcp FTP File Transfer Protocol (Protocolo de
Transferencia de Ficheros) - control
22/tcp SSH, scp, SFTP
23/tcp Telnet comunicaciones de texto inse-
guras
25/tcp SMTP Simple Mail Transfer Protocol37/tcp
time
43/tcp nicname
37/tcp time
53/tcp DNS Domain Name System (Sistema de
Nombres de Dominio)
53/udp DNS Domain Name System (Sistema de
Nombres de Dominio)
67/udp BOOTP BootStrap Protocol (Server),
también usado por DHCP
68/udp BOOTP BootStrap Protocol (Client), tam-
bién usado por DHCP
69/udp TFTP Trivial File Transfer Protocol70/tcp
Gopher
79/tcp Finger
80/tcp HTTP HyperText Transfer Protocol (WWW)
88/tcp Kerberos Agente de autenticación
110/tcp POP3 Post Office Protocol (E-mail)
111/tcp sunrpc
113/tcp ident (auth) antiguo sistema de identifica-
ción
119/tcp NNTP usado en los grupos de noticias de
usenet
123/udp NTP Protocolo de sincronización de
tiempo
123/tcp NTP Protocolo de sincronización de
tiempo
135/tcp epmap
137/tcp NetBIOS Servicio de nombres
362
137/udp NetBIOS Servicio de nombres

138/tcp NetBIOS Servicio de envío de datagramas
138/udp NetBIOS Servicio de envío de datagramas
139/tcp NetBIOS Servicio de sesiones
139/udp NetBIOS Servicio de sesiones
143/tcp IMAP4 Internet Message Access Protocol
(E-mail)
161/tcp SNMP Simple Network Management Pro-
tocol
161/udp SNMP Simple Network Management Pro-
tocol
162/tcp SNMP-trap
162/udp SNMP-trap
177/tcp XDMCP Protocolo de gestión de displays
en X11
177/udp XDMCP Protocolo de gestión de displays
en X11
389/tcp LDAP Protocolo de acceso ligero a Bases
de Datos
389/udp LDAP Protocolo de acceso ligero a Bases
de Datos
443/tcp HTTPS/SSL, transferencia segura de
páginas web
445/tcp Microsoft-DS (Active Directory, Windows,
Sasser, Agobot)
445/udp Microsoft-DS compartición de ficheros
500/udp IPSec ISAKMP, Autoridad de Seguridad
Local
512/tcp exec
513/tcp login
514/udp syslog usado para logs del sistema
520/udp RIP
591/tcp FileMaker 6.0 (alternativa para HTTP, ver
puerto 80)
631/tcp CUPS sistema de impresión de Unix
666/tcp identificación de Doom para jugar sobre
TCP
363
993/tcp IMAP4 sobre SSL (E-mail)

995/tcp POP3 sobre SSL (E-mail)
1080/tcp SOCKS Proxy
1337/tcp suele usarse en máquinas comprometidas
o infectadas
1352/tcp IBM Lotus Notes/Domino RCP
1433/tcp Microsoft-SQL-Server
1434/tcp Microsoft-SQL-Monitor
1434/udp Microsoft-SQL-Monitor
1494/tcp Citrix MetaFrame Cliente ICA
1512/tcp WINS
1521/tcp Oracle listener por defecto
1701/udp Enrutamiento y Acceso Remoto para VPN
con L2TP.
1723/tcp Enrutamiento y Acceso Remoto para VPN
con PPTP.
1761/tcp Novell Zenworks Remote Control utility
1863/tcp MSN Messenger
2049/tcp NFS Archivos del sistema de red
2082/tcp CPanel puerto por defecto
2086/tcp Web Host Manager puerto por defecto
2427/upd Cisco MGCP
3030/tcp NetPanzer
3030/upd NetPanzer
3128/tcp HTTP usado por web caches y por defecto
en Squid cache
3128/tcp NDL-AAS
3306/tcp MySQL sistema de gestión de bases de
datos
3389/tcp RDP (Remote Desktop Protocol)
3396/tcp Novell agente de impresión NDPS
3690/tcp Subversion (sistema de control de ver-
siones)
4662/tcp eMule (aplicación de compartición de
ficheros)
364
4672/udp eMule (aplicación de compartición de

ficheros)
4899/tcp RAdmin (Remote Administrator, normal-
mente troyanos)
5000/tcp Universal plug-and-play
5060/udp Session Initiation Protocol (SIP)
5190/tcp AOL y AOL Instant Messenger
5222/tcp XMPP/Jabber conexión de cliente
5223/tcp XMPP/Jabber puerto por defecto para
conexiones de cliente SSL
5269/tcp XMPP/Jabber conexión de servidor
5432/tcp PostgreSQL sistema de gestión de bases
de datos
5517/tcp Setiqueue proyecto SETI@Home
5631/tcp PC-Anywhere protocolo de escritorio
remoto
5632/udp PC-Anywhere protocolo de escritorio
remoto
5400/tcp VNC protocolo de escritorio remoto (usado
sobre HTTP)
sobre HTTP)
sobre HTTP)
sobre HTTP)
sobre HTTP)
5900/tcp VNC protocolo de escritorio remoto (co-
nexión normal)
6000/tcp X11 usado para X-windows
6112/udp Blizzard
6129/tcp Dameware Software conexión remota
6346/tcp Gnutella compartición de ficheros (Li-
mewire, etc.)
6347/udp Gnutella
365
6348/udp Gnutella
6349/udp Gnutella
6350/udp Gnutella
6355/udp Gnutella
6667/tcp IRC IRCU Internet Relay Chat
6881/tcp BitTorrent puerto por defecto
6969/tcp BitTorrent puerto de tracker
7100/tcp Servidor de Fuentes X11
7100/udp Servidor de Fuentes X11
8000/tcp iRDMI, usado erróneamente en sustitución
de 8080.
8080/tcp HTTP HTTP-ALT ver puerto 80.
8118/tcp privoxy
9009/tcp Pichat peer-to-peer chat server
9898/tcp Gusano Dabber (troyano/virus)
10000/tcp Webmin (administración remota web)
19226/tcp Panda Security, comunicaciones de Panda
Agent.
12345/tcp NetBus en:NetBus (troyano/virus)
31337/tcp Back Orifice, administración remota (tro-
yanos)
Fuentes:
http://es.wikipedia.org/wiki/Lista_de_
números_de_puerto
http://www.iana.org/assignments/
port-numbers
http://www.ietf.org/rfc/rfc1700.txt
A.5. Procedimiento de recuperación

de contraseñas
Nota: El siguiente ejemplo de recuperación de contraseñas
es válido para un Cisco 2611, pero la esencia del proceso es la
misma para la mayoría de los routers Cisco.
366
En primer lugar nos conectamos con un software de emu-
lación de terminal como Hyperterminal o Putty al puerto de
consola del router con los parámetros habituales:
Velocidad 9600 (baud rate)
Sin paridad (No parity)
Ocho bits de datos (8 data bits)
Un bit de parada (1 stop bit)
Sin control de flujo (No flow control)
Apagamos y encendemos el router y paramos la secuencia
de arranque en los sesenta segundos transcurridos desde el
encendido.
Nota: "Control+Break" suele funcionar, pero en caso nece-

sario podemos buscar el documento de Cisco "Standard Break
Key Sequence Combinations During Password Recovery"
donde vienen muchas combinaciones de parada en función el
sistema y software utilizados.
Una vez en modo ROMMON cambiamos el valor del re-

gistro de configuración con la orden "confreg 0x2142" de forma
que el router cargue desde la flash, saltandose la configuración
de arranque donde las passwords se almacenan. Con "reset"
reiniciamos el sistema
*** System received an abort due to Break Key ***
signal= 0x3, code= 0x500, context= 0x813ac158

PC = 0x802d0b60, Vector = 0x500, SP = 0x80006030
rommon 1 > confreg 0x2142
You must reset or power cycle for new config to take effect
rommon 2 > reset
El router se reinicia e ignora la cofiguración almacenada.

Iremos contestando "no" o directamente "Ctrl-C" para sal-
tarnos el proceso setup de configuración inicial.
System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1)
TAC:Home:SW:IOS:Specials for info
program load complete, entry point: 0x80008000, size: 0x6fdb4c
Self decompressing the image : ###############################

##############################################################
##############################################################
##############################################################
############################### [OK]
367
cisco Systems, Inc.


IOS (tm) C2600 Software (C2600-IS-M), Version 12.0(7)T, RELEASE SOFTWARE (fc2)
cisco 2611 (MPC860) processor (revision 0x202) with 26624K/6144K bytes of

memory.
Bridging software.
Would you like to enter the initial configuration dialog? [yes/no]: n

00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0/0,
changed state to up
Router>
changed state to up
00:00:50: %SYS-5-RESTART: System restarted --
IOS (tm) C2600 Software (C2600-IS-M), Version 12.0(7)T, RELEASE SOFTWARE (fc2)
00:00:50: %LINK-5-CHANGED: Interface BRI0/0,
368
Router>
Con "enable" nos hacemos usuarios privilegiados del

router.
Router>enable
Router#
Y con la orden "copy startup-config running-
config" copiamos la configuración de la RAM no volátil
(NVRAM) a la memoria.
Atención: *NO* lo haga al revés. Si copiamos la running-

config sobre la startup-config borraríamos la configuración
de arranque del router, y casi con total seguridad no lo es que
queremos hacer en este momento.
Router#copy startup-config running-config
Destination filename [running-config]?
1324 bytes copied in 2.35 secs (662 bytes/sec)
Router#
Llegados a este punto con "show running-config" po-

demos ver la configuración inicial del router. Las interfaces
aparecerán todas en "shutdown"y las contraseñas pueden
estar en texto claro o encriptadas, En todo caso con "confi-
gure terminal" accedemos al modo de configuración y con
"enable secret <password>" cambiamos la contraseña del
modo privilegiado
Router(config)# enable secret cisco
Router(config)# ^Z
Ahora sólo queda darle un "no shutdown" a las interfaces

Router#show ip interface brief
Interface IP-Address OK? Method Status
Protocol
Ethernet0/0 10.200.40.37 YES TFTP administratively down down
BRI0/0 193.251.121.157 YES unset administratively down down
369
Ethernet0/1 unassigned YES TFTP administratively down down
Loopback0 193.251.121.157 YES TFTP up up
Router(config)# interface Ethernet0/0
Router(config-if)#
changed state to up
Router(config-if)# interface BRI0/0
Router(config-if)#
00:02:115964116991: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0/0,
TEI 68 changed to up
Router(config-if)# ^Z
Router#
Guardamos el trabajo realizado con "write memory" o

"copy running-config startup-config"
Router#copy running-config startup-config
Destination filename [startup-config]?
[OK]
Y dejamos el registro de configuración como estaba origi-

nalmente "0x2102" para que el router al reiniciarse cargue la
configuración desde la NVRAM.
Router(config)# config-register 0x2102
Router(config)# ^Z
Router#show version
SOFTWARE (fc2)


Bridging software.
370

Configuration register is 0x2142 (will be 0x2102 at next reload)
Router#
A.6. Cabeceras de los protocolos
Figura A.6. Cabecera UDP, cortesía de Matt Baxter

(http://www.fatpipe.org/~mjb/Drawings/)
Figura A.7. Cabecera ICMP, cortesía de Matt Baxter

371
Figura A.8. Cabecera IPv4, cortesía de Matt Baxter
Figura A.9. Cabecera IPv6, cortesía de Matt Baxter

372
Figura A.10. Cabecera TCP, cortesía de Matt Baxter
373
Índice alfabético
375
376
377
378
379
380
381
382
383
384

GP EnrutadoresCisco PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GP EnrutadoresCisco PDF

Загружено:

Авторское право:

Доступные форматы

Enrutadores Cisco

Reservados todos los derechos. El contenido

© EDICIONES ANAYA MULTIMEDIA (GRUPO ANAYA, S.A.), 2009

5. Protocolos de Enrutamiento............................................... 183

5.1. Conceptos básicos del enrutamiento.......................... 183

6.1. Medios, Motivos y Oportunidades............................. 237

"No es adecuado pensar en las redes en términos de conexión

Hace unos pocos años los ordenadores personales eran

"Fue como si alguien hubiese levantado la tapa de la vida

El objetivo de este libro es levantar la tapa de las redes para

En este capítulo vamos a ver qué es un router y el lugar

1.1. ¿Qué es un router?

Físico Maneja las especifi- bit Hub

A medida que la información va "bajando" desde las apli-

Nota: En la práctica la arquitectura dominante es la pila de

De los tres elementos que conforman las redes (sistemas

1.2. Elementos de interconexión

Figura 1.1. Las colisiones son malas para el tráfico en general.

Para hacer frente al problema de las colisiones tenemos los

Figura 1.3. Cada elemento de interconexión trabaja

La aplicación [1] en el Host A (cliente) quiere conectarse

Figura 1.4. Los routers tienen una dirección

La segunda característica de los routers es que tienen una

1.3. Cómo funciona un router

1.3.1. Aspectos generales

Nota: Una de las características más interesantes del IOS

Figura 1.5. Planos de control de los routers

Nota: El Plano de Control se encarga de ejecutar protocolos

La función central del router, como el resto de elementos

1.3.2. La tabla de rutas

Nota: A continuación vamos a mostrar algunos comandos

Para ver la tabla correspondiente al protocolo IP introdu-

Gateway of last resort is 10.0.0.100 to network 0.0.0.0

Tras introducir el comando aparece una leyenda que nos

1.4. Un ejemplo de red

Nota: La red de la ilustración es la red ARPAnet inicial, en

Figura 1.6. ARPAnet Diciembre, 1969

Cada uno de estos routers posee una conexión con una

UCSB#show ip interfaces brief

SRI#show ip interfaces brief

UTAH#show ip interfaces brief

Podemos ver el nombre (o hostname) de cada uno de los

Nota: las interfaces usadas en este ejemplo son conectores

A continuación vemos la tabla de rutas que construyen

UCLA# show ip route

Podemos ver entre corchetes la distancia administrativa

UCLA#ping 192.168.3.1 source 192.168.1.1

UCLA#ping 192.168.4.1 source 192.168.1.1

Nota: En realidad en los ejemplos anteriores usamos un

Para terminar con nuestro ejemplo provocaremos un pe-

La pérdida de la red punto a punto se refleja de forma di-

Gateway of last resort is not set

Se observa que UTAH ahora ve la red 192.168.1.0 a 3 saltos

Entender cómo construye y utiliza el router la tabla de rutas

1.5. Modelos de routers Cisco

Nota: La oferta de Cisco está en permanente evolución. La

Nota: en este momento la versión Summer/Fall 2008 está

1.5.1. Routers de Servicios Integrados

1.5.3 Routers para ISPs (Service Aggregation)

1.6. Cisco, la empresa

Nota: En abril de 2008 Cisco Systems llevaba adquiridas

En este capítulo examinamos el conjunto de protocolos

2.1. Un poco de historia.