viernes, 22 de febrero de 2008

VERIFICACIÓN DE LA CONECTIVIDAD IP Y SOLUCION DE PROBLEMAS.

VERIFICACIÓN DE LA CONECTIVIDAD IP Y SOLUCION DE PROBLEMAS.
En algún momento todos los administradores deben solucionar la
queja de un usuario que no puede llegar a algún destino de la red. La
ausencia de conexión puede ser el resultado de fallos en la red
causados por problemas en el servicio WAN, una mala configuraci ón de
los routers u otros dispositivos de la red, controles de listas de
acceso(intencionados o no) y otras miles de posibilidades. Aunque no
existe sustituto para el equipo de prueba de la red, como los
analizadores de protocolos, el router, sí se proporcionan varias
herramientas de gran utilidad para verificar la conectividad IP e
investigar los problemas potenciales.
El router debería de tener una ruta específica o algún tipo de
ruta predeterminada o resumen a todos los destinos a los que pueda
llegar una estación IP. Una de las mejores herramientas para
solucionar los problemas es el comando show ip route.
Cuando una estación tiene problemas para conectarse con otras
estaciones(ya sea dentro o fuera de la Intranet), uno de los primeros
pasos para la resolución de problemas es verificar que el router más
próximo al usuario cuenta con una ruta a la dirección IP de destino.
Si no se encuentra una ruta específica o si no está presente la ruta
predeterminada o resumen esperada, probablemente haya que investigar
los protocolos de enrutamiento dinámico para determinar porque no está
presente la ruta.

¿EL ENLACE ESTA OPERATIVO?



Hardware(nivel físico)
- Cable
- Conectores
- Interfaces
Nivel de enlace de datos
- Mensajes keepalive
- Información de control
- Información de usuario
Sh controle int Comprueba a nivel físico cuando una interfaz esta
down.

COMANDO PING
Si se establece que existe una ruta hacia el destino deseado, se
debería probar para determinar si el router puede llegar el destino.
Los usuarios de UNÍS están familiarizados con el comando ping, que es
un acrónimo de Paket Internet Groper. El comando ping, que se ejecuta
en el router, hace uso del Protocolo de control de mensajes IP(IP
Control Message Protocol, ICMP) para enviar peticiones de eco a una
dirección IP de destino. La estación que recibe la petición de eco
ICMP envía una respuesta de eco ICMP. De esta manera, una estación
origen puede determinar si se puede contactar con la estaci ón de
destino y cuanto tiempo tarda aproximadamente la petición de eco y la
respuesta en llegar y volver de la estación de destino.
El router envía un número de peticiones de eco ICMP e informa mediante
el signo exclamación(!)que se reciben todas las respuestas. También
informa del número de intentos de peticiones de eco y del número de
respuestas de eco recibidas, además de calcular el porcentaje de pings
que han tenido éxito. También se calculan los tiempos mínimos y
máximos y medios de respuesta.

Nota_
Cuando un router hace un ping a una dirección IP por primera vez
o tras un prolongado periodo de tiempo, no suele recibir la primera
respuesta de eco, lo que tiene como consecuencia que se respondan
cuatro de las cinco respuestas al ping. Esto se debe a que el router
debe esperar una resolución ARP de la dirección IP antes de enviar las
respuestas de eco. Normalmente, la respuesta ARP no llega a tiempo
para que se envié la primera petición de eco y se reciba la respuesta
antes de que expire el tiempo de la petición.

DIFERENTES CARACTERES DE RESPUESTA QUE SE PUEDEN RECIBIR COMO
RESULTADO DE UN PING.
! Cada signo de exclamación indica la recepción de una respuesta.
La respuesta de eco se recibió satisfactoriamente.
. Cada punto indica que el servidor de la red agoto el tiempo
esperando una respuesta.
La petición de eco seguramente llegó al destino, pero éste no
consiguió responder o no tenía una ruta de regreso al origen de la
petición.
U No se puede acceder al destino.
La dirección IP de destino no coincide con una dirección MAC o no
permite peticiones de eco ICMP. El router emisor ha recibido un
mensaje “destination unreachable” de ICMP.
N No se puede acceder a la red.
No hay ruta a la red de destino para la dirección IP de destino.
El router emisor ha recibido un mensaje “network unreachable” de ICMP.
Q Se solicita que deje de enviar el origen.
La dirección IP de destino esta recibiendo más paquetes de los que
puede almacenar en la memoria intermedia. El destino a enviado al
router un mensaje “source quench” de ICMP diciéndole al remitente que
retroceda.
M No se pudo realizar la fragmentación.
Un paquete ha excedido la unidad máxima de transmisión de un segmento
de la red en la ruta hacia el destino y se ha activado el bit no
fragmentar. El router emisor ha recibido un mensaje “could no
fragment” de ICMP.
A No se puede acceder administrativamente al destino.
Se ha descartado el paquete a la dirección de destino al encontrar un
filtro de paquetes o un firewall. El router emisor ha recibido un
mensaje “administratively unreachable” de ICMP.
? El paquete es de tipo desconocido.
El router emisor ha recibido una respuesta desconocida a la petici ón.
El comando Ping tiene tanto versión privilegiada como no
privilegiada. En el modo ejecutable de usuario, la versión no
privilegiada solamente permite que el usuario especifique una
dirección IP. La versión privilegiada, disponible con el modo
ejecutable activado, permite que el usuario modifique parámetros de la
petición de eco, incluyendo el número de peticiones, el tamaño de los
paquetes enviados, el valor del tiempo de espera, la direcci ón IP de
origen de la petición, el modelo de datos de la petición de eco y
otros muchos valores.
Si se sospecha que la falta de conectividad se debe a la
ausencia de una ruta en el router de flujo descendente o a que un
paquete está tomando una ruta incorrecta, el router cuenta con un
comando denominado trace que permite verificar la ruta que sigue un
paquete hasta alcanzar la dirección IP de destino. La función trace es
similar a la utilidad traceroute de UNÍS. Al igual que el comando
ping, el comando ejecutable de IOS trace tiene tanto versión
privilegiada como no privilegiada. LA versión privilegiada permite que
el usuario modifique los parámetros, al igual que con el comando ping.
La función trace hace uso del mensaje “TTL-Expired”(Time To
Live) para identificar los routers en una ruta hacia la direcci ón IP
de destino. El router de origen envía un paquete UDP con un TTL de 1
hacia el destino. El primer router de la ruta recibe el paquete y
disminuye el campo TTL en 1. En consecuencia, el TTL expira (llega a
0) y el router no reenvía el paquete. En su lugar, este primer router
de la ruta devuelve un mensaje “TTL-Expired” de ICMP al origen del
paquete, de modo que éste conoce ahora el primer salto de router de la
ruta.
El router de origen envía ahora otros paquetes UDP, pero
establece el TTL en 2. El primer router de la ruta recibe el paquete,
disminuye el TTL a 1 y reenvía el paquete al segundo router de la
ruta. El segundo router recibe el paquete, disminuye el TTL a 0 y no
reenvía el paquete porque ha espirado el TTL. El segundo router
devuelve un mensaje “TTL-Expired” de ICMP a la estación origen y ahora
el router de origen conoce el segundo router de la ruta. Este proceso
continua hasta que el paquete llega a la dirección IP de destino
final. El paquete se dirige a puertos UDP con número alto, normalmente
superior a 33434, que no admite el dispositivo de destino. Por tanto ,
la dirección IP de destino responde con un mensaje “Port unreachable”
de ICMP, que alerta al router de origen de que se ha llegado al
destino final.
Los valores del tiempo que aparecen tras el nombre y las
direcciones IP de los routers en la ruta de red, representan una
aproximación del tiempo de ida y vuelta transcurrido desde la
dirección de origen del router de la ruta. Para cada dirección IP de
destino aparecen hasta tres valores de tiempo, uno por cada uno de los
tres paquetes(sondas). Algunos dispositivos tienen limitaciones en la
velocidad a la que pueden responder con mensajes ICMP. En dichos
dispositivos podrían aparecer menos de tres valores de tiempo. Por
cada sonda que no responde al dispositivo por limitaciones de
velocidad, aparece un asterisco en lugar del valor de tiempo.
Además de limitar la velocidad de los mensajes ICMP es posible
que algunos routers de la ruta no respondan con un mensaje “TTLExpired”
de ICMP. Algunos pueden volver a usar el TTL del paquete
entrante, lo que provoca la caducidad del TTL del mensaje ICMP antes
de que el mensaje pueda regresar al remitente. Y en algunos casos, los
filtros de paquetes pueden evitar que los paquetes de respuesta de
ICMP llegen al router de origen. En todos estos casos en la l ínea de
salida se ve una línea de asteriscos en vez de la información de la
dirección.
La versión privilegiada del comando trace permite el ajuste de
los parámetros del comando, incluyendo si las direcciones IP se
resuelven de forma inversa a los nombres de host, el número de sondas
enviadas por cada fase TTL, un valor mínimo y máximo de TTL, etc.
Si una estación a la que se puede acceder mediante una interfaz
de LAN conectada directamente no responde, la razón puede ser que el
router no sea capaz de asignar la dirección IP a la dirección MAC.
Para comprobar las direcciones MAC que el router ha sido capaz
de resolver, utilizamos el comando ejecutable de IOS show ip arp. Este
comando toma como parámetro una dirección IP específica, una interfaz
específica o una dirección MAC de 48 bits específica. Sólo muestra las
entradas ARP para dicho parámetro. Si no se introduce ningún
parámetro, aparecen todas las entradas ARP de IP.
La salida del comando incluye la asignación IP de ARP, la
antigüedad de la entrada en la tabla y la interfaz a la que está
asociada la entrada ARP(el router elimina una entrada ARP de la tabla
ARP tras cuatro horas de manera predeterminada).
Las estadísticas generales sobre el funcionamiento del protocolo
IP en el router pueden obtenerse con el comando show ip traffic.
Incluye contadores para información como el número total de paquetes
recibidos y enviados por el router, el número de transmisiones
recibidas y enviadas, estadísticas de protocolo ICMP/UDP/TCP y muchas
más cosas.
Estas estadísticas pueden ayudar a determinar si el router ha
enviado o recibido un eco ICMP, si una dirección IP no logra resolver
una dirección MAC(lo que se conoce con un fallo de encapsulación) y
donde se están enviando o recibiendo ciertos paquetes de protocolos de
enrutamiento. Los comandos de show ip traffic son acumulativos y
solamente se ponen a cero cuando se vuelve a cargar o reiniciar el
router.
Los contadores de la salida de show ip traffic cuentan tanto los
eventos que han ocurrido como los tipos de paquetes que se han enviado
y recibido. Si los contadores de fallos de encapsulación aumentan,
indicaran que el router no ha recibido respuestas ARP a sus peticiones
ARP para los paquetes que intercambian conmutarse a las interfaces de
destino y que éstos se descartaron. El contador de echos ICMP indica
cuántos pings está generando el router, mientras que el contador de
contestaciones de echos indica el número de pings al que está
respondiendo.
Existen numerosos comandos ejecutables de IOS debug para ayudar
a determinar el funcionamiento de IP en el router. Estos comandos
debug ofrecen una salida de diagnostico tanto general como detallada
que pueden ayudar a la hora de solucionar problemas y comprobar el
funcionamiento del router, los protocolos de enrutamiento y otras
funciones.

COMANDOS DEBUG PARA IP
Debug ip routing
Muestra los cambios que ocurren en la tabla de enrutamiento como
resultado de incorporaciones y supresiones de rutas.
Degug ip packet
Muestra las direcciones IP de origen y destino de los paquetes que
atraviesan el router. Este comando debug puede sobrecargar al router,
así que debe usarse con precaución. Se recomienda que se utilice una
lista de acceso junto con este comando para limitar la carga de la
CPU.
Debug ip udp
Muestra los paquetes UDP enviados al router
Debug ip icmp
Muestra los paquetes ICMP enviados al router y generados por él.
Debug arp
Muestra las peticiones ARP generadas por el router y las respuestas
enviadas a él.
Los comandos de depuración de los distintos protocolos de
enrutamiento dinámico son, entre otros: debug ip rip, degug ip eigrp,
debug ip igrp, debug ip ospf y debug ip bgp.
Todos ellos tienen parámetros opcionales que controlan qué información
de depuración del protocolo de enrutamiento ve el usuario. Hay que
tener mucho cuidado al utilizar algunas de las versiones de estos
comandos, ya que utilizan muchos recursos de la CPU.

Sugerencia_
Cuando se utilicen los comandos debug, que se sabe que aumentan
la carga de la CPU, no los ejecute en el puerto de la consola. En su
lugar, desactive el registro de la consola mediante el comando de
configuración global de IOS no logging buffered. A continuación
ejecutamos el comando desde una sesión de terminal virtual y vemos la
salida de dicha sesión. Si la sesión no responde, puede usarse la
consola para desactivar la depuración, ya que ésta tiene mayor
prioridad que la sesión de terminal virtual. La salida de depuración
puede verse entonces en el búfer del registro mediante el comando
ejecutable de IOS show log. Si esta activado syslog, también puede
verse la salida del archivo de registro del servidor syslog.

CONFIGURACIÓN DE LOS SERVICIOS DE DENOMINACIÓN DE DOMINIO.
En las redes TCP/IP actuales, la mayoría de la gente hace
referencia a los servidores, las impresoras, las estaciones de trabajo
y otros dispositivos IP por sus nombres más que por sus direcciones
IP. Recordar las direcciones IP puede resultar fácil para el
administrador de la red que esta muy familiarizado con ella, pero para
el usuario medio, resulta más sencillo recordar el nombre de un
sistema. Para este fin, los servidores que convierten los nombres en
direcciones IP, denominados servidores del Servicio de denominaci ón de
dominio (Domain Name Service, DNS), suelen residir en algún lugar de
la Intranet de una entidad. Los routers pueden hacer uso del sistema
DNS para convertir los nombres en direcciones IP y para ayudar a
reducir el número de direcciones IP que debe recordar el
administrador.
DNS suele venir activado en el software Cisco IOS. Sin embargo,
si se ha desactivado, puede restablecerse mediante el comando de
configuración global de IOS ip domain-lookup. Una vez activado DNS,
debería configurarse un dispositivo IOS con el nombre de domino en el
que resida y con la dirección IP de los servidores de nombres DNS que
pueda utilizar para la resolución de nombres.
El nombre de dominio puede configurarse mediante el comando de
configuración global de IOS ip domain-name.
El servidor(es) de nombres DNS puede configurarse mediante el
comando de configuración global de IOS ip name-server. El comando ip
name-server toma una o varias direcciones IP de servidores de nombres
como parámetros. Si el dispositivo IOS reside dentro de varios
dominios DNS, puede usarse el comando de configuración global de IOS
ip domain-list para especificar una lista de nombres de dominio que
deberían ser postergados a nombres inhábiles.
Para comprobar la configuración del DNS en el router, podemos
utilizar el comando ejecutables de IOS show host. Además, el comando
show host muestra una lista de hosts a los que se les ha convertido el
nombre a dirección IP y también la antigüedad de cada entrada.
Las asignaciones de nombres de host a dirección IP pueden
también configurarse de manera estática en el router en las
situaciones en las que no se encuentren disponibles los servidores
DNS, se prefiera crear nombres especiales diferentes a los DNS o se
desee asignar puertos de servidores terminales individuales a
direcciones IP.
La asignación de nombre estático a dirección IP se configura con
el comando de configuración global de IOS ip host. El comando ip host
toma como parámetros un nombre de host, un puerto opcional del
protocolo Telnet y una o varias direcciones IP a las que se puede
convertir el nombre de host.
Las asignaciones estáticas de nombre de host a dirección IP
pueden verificarse también mediante el comando show host.
Las entradas estáticas de la tabla de nombres de host pueden
distinguirse de las que se conocen mediante DNS por el campo Flags
para la entrada del nombre de host. Un tipo de indicador Temp. Indica
que el nombre se conoció de forma dinámica mediante DNS y ha salido
temporalmente de la tabla tras un periodo de tiempo. Un tipo de
indicador perm indica que el nombre se configuró estáticamente y nunca
se suprimirá de la tabla con el tiempo.
Las entradas temporales de la tabal de host IP pueden borrarse
mediante el comando ejecutable de IOS clear host. Las asignaciones
individuales de nombres de host pueden borrarse introduciendo un
nombre de host como parámetro para el comando. Si se introduce un
asterisco como parámetro, pueden borrarse todas las entradas de host
temporales.

REENVÍO DE DIFUSIÓN IP
Una de las ventajas que ofrecen los routers en una red es la
restricción de los paquetes de difusión IP y MAC al segmento de LAN
local. La mayoría de las difusiones se utilizan para solicitar
información como una dirección MAC desconocida para una dirección IP
(ARP) en un segmento local, por lo que aislar las difusiones al
segmento de LAN local no presenta problemas inherentes y es altamente
beneficioso para el rendimiento de la red.
En algunas situaciones las estaciones IP utilizan las difusiones
UDP para localizar servicios que pueden no estar en el segmento de LAN
local. Por ejemplo, las aplicaciones que utilizan NetBIOS sobre IP
usan difusiones UDP para localizar el tipo de servicio particular que
necesita el usuario. Si el servicio reside en un segmento de LAN que
no sea al que está conectado la estación del usuario, el router
bloquea la difusión, con lo que el servicio deja de estar disponible.
Otros servicios, como DCHP y Bootstrap Protocol (BOOTP), env ían
difusiones UDP para ayudar a las estaciones IP a determinar sus
direcciones IP durante el proceso de inicio; las difusiones las
reciben servidores que asignan direcciones.
Si dichos servidores residen fuera del segmento de LAN local, una
estación IP no puede recibir una dirección IP asignada por el usuario.
Para compensar las características de aislamiento de la difusión
del router, el software IOS tiene la capacidad de reenviar difusiones
UDP a un host o subred específica. Esta característica, que se
denomina reenvío de difusión de IP, se activa utilizando el subcomando
de configuración de interfaz de IOS ip helper-address y el comando de
configuración global de IOS ip forward-protocol.
Una aplicación habitual de estos comandos es reenviar las
peticiones de direcciones DCHP desde un segmento de LAN local al
segmento de LAN en el que reside el servidor DCHP.
Para activar el reenvío de difusiones, podemos aplicar el
comando ip helper-address a los segmentos en los que el router recibe
las difusiones. El comando ip helper-address toma como parámetro una
dirección IP de host de host o una dirección IP de difusión. La
dirección que se introduce es una dirección de host del servidor DCHP
específico o la dirección de difusión del segmento de LAN en el que
reside el servidor DCHP.
En vez de reenviarse directamente al servidor DCHP, la difusi ón
podría reenviarse al segmento de LAN en el que reside el servidor
DCHP. Esta alternativa resulta de gran utilidad cuando hay m ás de un
servidor DCHP que podría contestar a la petición.
El comando ip helper-address se utiliza para especificar dónde
se deberían reenviar las difusiones. El comando ip forward-protocol se
utiliza para controlar qué emisiones UDP se reenvían. De manera
predeterminada, se reenvían varios tipos de difusión UDP siempre que
se aplica a la interfaz el comando ip halper-address:
Protocolo de transferencia de archivos trivial(trivial File
Transfer Protocol, TFTP) (puerto 69).
Sistema de denominación de dominio(puerto 53).
Servicio de tiempo(puerto 37).
Servidores de nombres NetBIOS(puerto 137).
Servidor de datagramas NetBIOS(puerto 138).
Datagramas de clientes y servidores del protocolo
Boot(BOOTP)(puertos 67 y 68).
Servicio TACCS(puerto 49).
Si hay una aplicación que emita en un puerto que no aparezca en
la lista y hay que reenviar sus difusiones, utilizamos el comando ip
forward-protocol para especificar que el tipo de difusión particular
debería incluirse entre los que se reenvían. Con la incorporación de
la palabra clave no, también es posible utilizar este comando para
restringir que se reenvíe cualquiera de los protocolos
predeterminados. El comando ip forward-protocol toma como parámetro el
tipo de reenvío a realizar(como por ejemplo, UDP) y el número de
puerto específico de protocolo a reenviar.
La configuraciones de ip helper-address se puedenverificar con
el comando show interface.

Nota_
Otras referencias: otras aplicaciones de difusión
La técnico de reenvío de difusión que hemos visto esta diseñada
para satisfacer las demandas de un entorno de reenvío de difusión
limitado. Se ajusta a la perfección a tareas como el reenvío de
peticiones de direcciones IP mediante DCHP o BOOTP a un servidor o
grupo de servidores que residan en una ubicación central de la red.
Existen otras aplicaciones para las que se puede necesitar un
reenvío de más considerable. Estas aplicaciones suelen utilizar
difusiones para compartir información entre un elevado grupo de
usuarios de estaciones de trabajo a través de una gran parte de la
red. Dichas aplicaciones no son muy convenientes para el modelo de
direcciones helper. En su lugar, necesitan técnicas avanzadas, como el
desbordamiento de UDP y la duplicación difusión a multidifusión, para
evitar que se inunde la CPU del router por el trafico y la duplicaci ón
de paquetes de difusión.

ASIGNACIÓN DE DIRECCIONES DINÁMICAS CON UN SERVIDOR DCHP DE
IOS.
En la sección anterior tratamos el reenvío de peticiones de
asignación de direcciones DCHP como una de las aplicaciones para el
reenvío de difusión de IP. Cuando un router reenvía estas peticiones
de asignación de dirección, se dice que actúa como un agente de
retransmisión DCHP. El papel del agente de retransmisión DCHP es
recibir las difusiones locale de las LAN para la asignación de
direcciones y reenviarlas a un servidor DCHP identificado previamente.
El servidor DCHP suele ser una estación de trabajo o un servidor como
un sistema UNIX o Windows NT que ejecuta un paquete de software o un
servicio de servidor DCHP. De forma alternativa, un router o un
servidor de acceso basado en IOS puede servir como fuente para las
asignaciones dinámicas de direcciones.
El servidor DCHP del software IOS funciona de forma similar a
los servidores DCHP basados en estaciones de trabajo, aceptando
peticiones/renovaciones de asignación de direcciones y asignando las
direcciones desde grupos predefinidos de direcciones denominados
conjuntos. Los conjuntos de direcciones pueden configurarse para
proporcionar información adicional al cliente que lo solicite, como
la(s) dirección(es) de los servidores DNS, el router predeterminado y
otro tipo de información útil. El servidor DCHP de IOS pueden aceptar
difusiones de segmentos LAN conectados a nivel local o de peticiones
DCHP que hayan reenviado otros agentes de retransmisión DCHP dentro de
la red.

Nota_
Aparte del servidor DCHP basado en el software IOS, Cisco
Systems fabrica un servidor DNS y DCHP basado en estaciones de trabajo
denominado Cisco Network Registrar que se ejecuta en sistemas
operativos como Solaris, HP-UX y Microsoft Windows. Para tomar la
decisión de utilizar el servidor DCHP basado en IOS o un servidor DCHP
basado en estaciones de trabajo, hay que tener en cuenta muchos
factores, incluyendo el tamaño de la red, el número de nodos que
necesitan direcciones dinámicas, la frecuencia de las peticiones y
renovaciones de direcciones, la necesidad de redundancia y los costes.
En general, el servidor DCHP basado en IOS es más práctico en redes
pequeñas o de mediano tamaño para un modelo descentralizado, como, por
ejemplo varias oficinas remotas. Los servidores DCHP basados en
estaciones de trabajo son más apropiados para grandes organizaciones
que necesiten redundancia y un esquema de administración muy
centralizado.
El servidor DCHP de IOS participará normalmente en dos fases del
proceso de asignación de direcciones: la DHCPOFFER y la DHCPACK.
Cuando un cliente DHCP solicita una dirección del servidor DCHP.
El cliente DCHP envía un mensaje de difusión DHCPDISCOVER para
localizar a un servidor DCHP. Un servidor DCHP ofrece parámetros de
asignación de direcciones al cliente en una respuesta de unidifusión
DCHPOFFER. El cliente DCHP le devuelve entonces un mensaje de difusi ón
formal DCHPREQUEST para la asignación de direcciones ofertada al
servidor DCHP. El servidor DCHP envía una respuesta de unidifusión
DCHPPACK para indicar que las direcciones solicitadas se le han
asignado al cliente. Los cuatro pasos que se ilustran en la figura
representan el proceso normal de negociación de direcciones sin
errores ni conflictos. El proceso completo de asignación de
direcciones, incluyendo el tratamiento de los mensajes DCHPDECLINE, se
describe en la RFC 2131, “Dynamic Host Configuration Protocol”.



Para activar que el router basado en IOS o el servidor de acceso
Haga de servidor DCHP, hay que realizar cuatro fases de configuraci ón
principales:
Identificar la ubicación para registrar la información de las
asignaciones DCHP.
Crear una lista de direcciones IP que excluir de la asignaci ón
dinámica.
Crear un conjunto de direcciones que utilizar para la asignaci ón
dinámica.
Añadir atributos adicionales a los conjuntos de direcciones que
se proporcionarán a las estaciones que lo soliciten.
El primer paso para activar el servidor DCHP de Ios es
configurar una ubicación en la red para registrar y almacenar las
asignaciones de direcciones DCHP (denominadas también conjuntos). Esta
ubicación suele ser una estación de trabajo o un servidor que admita
TFTP, FTP o el protocolo de transferencia de archivos RCP.
Especificar esta ubicación permite que el router o el servidor
de acceso se reinicie sin perder información sobre que direcciones
están asignadas a qué sistemas de cliente DCHP.
Además, proporciona una ubicación para registrar los conflictos
de asignación de direcciones que pueden surgir durante el proceso de
negociación de DCHP. Para especificar la ubicación, utilizamos el
comando de configuración global de IOS ip dchp database. El comando
toma como parámetro un URL que especifica la dirección y el nombre de
archivo de servidor que utiliza para el registro. El comando de
configuración puede repetirse varias veces para determinar el
almacenamiento de varios conjuntos en múltiples servidores.
Durante el de asignación de direcciones, el servidor DCHP de IOS
pretende asegurar que la dirección IP que se ofrece no está en uso. Lo
hace enviando una serie de paquetes ping a la dirección que se ofrece
antes de responder al cliente DCHP. Si la dirección está en uso, se
registra como un conflicto y no se ofrece hasta que el administrador
de la red lo resuelve.
Si no hay ningún servidor disponible para el registro de
conjuntos de direcciones DCHP y el comando ip dchp database no está
configurado, también debe desactivarse el registro de los conflictos
DCHP. La desactivación del registro de conflictos se lleva a cabo con
el comando de configuración global de IOS no ip dchp conflict
logging.
Cuando se establece una ubicación para registrar los conjuntos,
se crea una lista de direcciones que se deberían excluir como
asignaciones ofertadas de forma dinámica. Esta lista incluye la
dirección de los routers en un rango de direcciones determinado,
cualquier dirección asignada de manera estática o una dirección que
debería estar reservada y no ofrecerse a ningún cliente DCHP. Para
construir estas listas, utilizamos el comando de configuraci ón global
de IOS ip dchp excluded-address. El comando puede representar las
direcciones inicial y final de un rango de direcciones IP. El comando
puede repetirse varias veces en la configuración para excluir varias
direcciones IP que no sean continuas o que abarquen varios conjuntos
de asignación de direcciones IP.
El paso final para activar el servidor DCHP de IOS es la
definición de los conjuntos de asignaciones de direcciones IP que se
utilizan para proporcionar las direcciones dinámicas. Como mínimo, el
conjunto de direcciones DCHP especifica el rango de direcciones que se
ofrecerán a los clientes DCHP que soliciten direcciones (sin incluir
las direcciones excluidas). Es posible definir más de un conjunto en
el servidor DCHP de IOS si hay varios segmentos de LAN conectados al
router o servidor de acceso que actúa como servidor DCHP o si sirve
direcciones para varios segmentos de LAN en cualquier parte de la red.
El comando de configuración global de IOS ip dchp pool establece
un conjunto de asignaciones de direcciones. El comando toma como
parámetro o una cadena arbitraria que describa el conjunto, o un
número entero. Una vez definidos, los comandos de conjuntos de
direcciones adicionales se introducen desde el modo de subcomando de
configuración de DCHP, que denota el indicador (config-dchp)#.
El subcomando de configuración DCHP de IOS network se utiliza
para definir el rango de direcciones que ofrecerá a los clientes DCHP
un determinado conjunto de direcciones. El subcomando network precisa
dos parámetros, una dirección de red IP y un máscara de red o máscara
de recuento de bits. Las direcciones de red y las máscaras
especificadas para un conjunto determinado deberían corresponderse con
la dirección de red y la máscara del segmento de LAN para las que
ofrecerá direcciones este conjunto. Cuando el servidor DCHP
proporcione direcciones para varios segmentos de LAN, deber ían
definirse conjuntos DCHP separados, cada uno con un comando network
con la dirección y la máscara apropiada para dicho segmento de LAN.
Otros subcomandos de configuración de DCHP permiten que el
administrador de la red configure el servidor de IOS de forma que
proporcione información suplementaria al cliente DCHP utilizando el
proceso de negociación de direcciones. La información adicional suele
ser la(s) dirección(es) del router predeterminado del cliente en el
segmento de Lan, las direcciones de los servidores DNS, las
direcciones de los servidores NetBIOS/WINS y otro tipo de informaci ón
que tendría que configurar manualmente en cada uno de los clientes
bien el usuario, bien el administrador de la red. La siguiente es la
lista de los subcomandos de configuración DCHP que se configuran más
frecuentemente:
Subcomando domain-name. Especifica el nombre del dominio DNS
al que pertenece este cliente.
Subcomando dns-server. Especifica una o varias direcciones IP
de los servidores DNS que puede solicitar el cliente para
resolver los nombres de direcciones IP.
Subcomando netbios-name-server. Especifica una o varias
direcciones IP de servidores NetBIOS/WINS a los que pueden
preguntar los clientes NetBIOS(normalmente estaciones de
trabajo de Microsoft) para localizar los recursos de red.
Subcomando default-router. Especifica una o varias
direcciones IP de un router predeterminado a las que los
clientes pueden reenviar los paquetes para los destinos
desconocidos.
Subcomando lease. Especifica cuánto tiempo es válida una
dirección asignada DCHP (un contrato) antes de necesitar
renovación.
Los subcomandos dns-server, netbios-name-server y default-router
toman como parámetros de una u ocho direcciones IP con las que puede
contactar el cliente para cada una de dichas funciones. El subcomando
domain-name toma como parámetro una cadena arbitraria que representa
el nombre del dominio DNS para el cliente. El subcomando lease toma
como parámetros hasta tres enteros para especificar el número de días,
horas y minutos que es válida una dirección asignada.
También puede usarse la palabra clave infinite para especificar
que un contrato es válido un periodo limitado de tiempo. El subcomando
netbios-node-type toma como parámetro los valores de los caracteres b,
p, m, o h, que representan un nodo de difusión de NetBIOS, un nodo
igual a igual, un nodo mixto o un nodo híbrido , respectivamente, para
indicar el modo operativo del cliente. Si no esta familiarizado con
estos modos operativos, se recomienda seleccionar el modo h íbrido.
Como mencionamos anteriormente, es posible configurar varios
conjuntos de direcciones DCHP en el mismo servidor DCHP de IOS. A la
colección del conjunto de direcciones DCHP en dicho servidor se la
conoce como base de datos DCHP. La base de datos DCHP está organizada
en una estructura jerárquica o de árbol, de modo que un conjunto de
direcciones puede ser una subred de la dirección de red del conjunto
de direcciones DCHP diferente. La estructura jerárquica permite que
las propiedades las herede el conjunto de direcciones, que es una
subred de la otra. Las propiedades comunes a varios conjuntos deber ían
definirse como el nivel de red o de subred más alto apropiado para el
servidor DCHP o la red que se esta configurando.
Cuando estén definidos los conjuntos de direcciones y sus
propiedades, y el servidor DCHP de IOS haya comenzado a asignar
direcciones IP, se puede verificar el funcionamiento del servidor DCHP
utilizando varios comandos ejecutables de IOS. La verificaci ón de que
el servidor DCHP de IOS registra la información de las asociaciones y
los conflictos en la estación de trabajo o servidor configurado se
realiza a través del comando ejecutable de IOS show ip dchp database.
Este comando utiliza como parámetro la dirección URL para mostrar la
información acerca de una ubicación específica para las bases de datos
del registro. Si no se introduce ninguna, aparece la informaci ón de
todas las ubicaciones.
La salida del comando show ip dchp database indica la ubicación
en la que se escribe la información de las asociaciones, la fecha y
hora en la que se leyó o se escribió por última vez en la base de
datos de asociaciones, el estado de la última lectura o escritura, y
el número de veces que se ha conseguido o no escribir en la base de
datos de asociaciones.
Es posible ver determinadas asignaciones de direcciones con el
comando ejecutable de IOS show ip dchp binding. Si se introduce en el
comando una dirección IP como parámetro opcional, sólo se mostrará la
información de las asociaciones de dicha dirección; en caso contrario,
aparecerá la de todas.
La información de los conflictos de direcciones que se han
producido cuando el servidor DCHP de Ios intentaba asignar una
dirección a un cliente DCHP se pueden ver con el comando show ip dchp
conflic. Si se introduce en el comando una dirección IP como parámetro
opcional, sólo se mostrará la información de los conflictos de dicha
dirección (si hay información); en caso contrario, aparecerá la de
todas.
La columna Detection Meted indica qué método ha utilizado el
servidor DCHP de IOS para determinar que la dirección estaba en
conflicto. El método de detección ping indica que antes de la
asignación de direcciones, el servidor DCHP de IOS ha intentado hacer
un ping a la dirección y ha recibido una respuesta correcta. El método
de detección Gratuitous ARP indica que antes de la asignación de
direcciones, el servidor DCHP de IOS ha detectado una entrada ARP
activa y válida para la dirección en su tabla ARP. Cualquiera de estos
métodos de detección indica que es posible que la dirección se esta
utilizando(quizás a causa de un uso no autorizado o porque alguien
olvidó añadirla a la lista de direcciones excluidas).
La verificación de que el servidor DCHP de IOS está recibiendo y
respondiendo a las solicitudes de DCHP se puede lograr con el comando
ejecutable de IOS show ip dchp server statistics. El comando ofrece
información útil, como el número de conjuntos de direcciones
configuradas, la cantidad de memoria que consume la base de datos de
asociaciones de DCHP y los contadores que indican el número de
distintos tipos de mensajes de DCHP que se han enviado y recibido.

REDUNDANCIA DE IP CON EL HOST STANDBY ROUTER PROTOCOL
A mochos administradores de red le preocupa tener puntos de
fallo únicos en la red. Desean proporcionar tanto rutas de acceso
redundantes como equipo redundante en lugares clave de la red para
evitar que cualquier dispositivo cause que los recursos vitales de la
red dejen de poder utilizarse. Los routers(y algunos servidores)
gestionan perfectamente varias rutas de acceso IP mediante el
intercambio de información de enrutamiento acerca de las distintas
rutas de acceso de la red, seleccionando las mejores rutas de acceso
en cualquier momento y volviendo a enrutarlas cuando haya alg ún cambio
en las rutas de acceso a causa de algún fallo del circuito o del
equipo.
Si embargo, muchas implementaciones de las estaciones de
trabajo, de los servidores y de las impresoras no pueden intercambiar
información de enrutamiento dinámico. Estos dispositivos se suelen
configurar con la dirección IP del gateway predeterminado, que sirve
como conducto al resto de la red. Si falla el router que es el gateway
predeterminado, el dispositivo se limita a comunicarse solamente con
el segmento local de red IP y está incomunicado con el resto de la
red. Aunque exista un router redundante que pudiera servir como
gateway predeterminado, no hay método dinámico que pueda utilizar las
estaciones de trabajo para conmutar a otra dirección IP del gateway
predeterminado y la reconfiguración manual suele desbordar los
conocimientos técnicos del usuario.
Para ayudar a los administradores de redes en esta problemática
situación, Cisco Systems ha desarrollado el Hot Standby Router
Protocol (HRSP). HRSP se ha desarrollado para el segmento LAN, donde
hay una gran cantidad de routers y dispositivos que utilizan solamente
una dirección IP estática del gateway predeterminado.
El concepto de SEP es bastante simple. El administrador crea una
dirección virtual para el gateway predeterminado y la asigna a los
routers redundantes que participan en el protocolo SEP en el segmento
LAN específico. Los dispositivos IP están configurados para utilizar
la dirección virtual del gateway como gateway predeterminado. Los
routers administran esta dirección, comunicándose entre ellos para
determinar que router es el responsable del reenvío del trafico
enviado a la dirección IP virtual. A intervalos regulares,
intercambian información para determinar que routers siguen estando
presentes y son capaces de reenviar trafico. Si falla el router
principal, o primario, de un grupo de routers con SEP, hay un router
de reserva en el mismo grupo que empieza a reenviar el tráfico del
grupo SEP. Dado que los routers deciden por si mismos cuál reenvía el
trafico a la dirección virtual y dado que las estaciones de trabajo de
un segmento sólo conocen la dirección Ip virtual como su gateway
predeterminado, un fallo del router de reenvío principal es
prácticamente indetectable por parte de los usuarios de estaciones de
trabajo y no requiere intervención por parte del usuario o del
administrador de la red.
HSRP es muy flexible. El administrador de red puede controlar
todo el comportamiento de los routers de un grupo SEP (incluyendo que
router es el router de reenvío principal, cuales son los routers de
reserva, si éstos conservan la función de reenvío cuando pueda volver
a utilizarse el router de reenvío principal, y la capacidad de otra
interfaz del router para conducir el trafico al router de reserva).
La presencia de dos o más routers que pueden actuar como gateway
predeterminados en el mismo segmento de LAN es la primera parte de los
criterios para configurar el protocolo SEP. La otra parte de los
criterios es tener dispositivos IP en la red que sólo puedan admitir
una sola dirección IP como gateway predeterminado. En este caso, las
impresoras, los servidores y las estaciones de trabajo se ajustan a
los criterios.
La configuración básica de SEP requiere solamente el subcomando
de configuración de interfaz de IOS standby ip. Este comando utiliza
como parámetro la dirección IP que se utiliza como dirección virtual
del gateway predeterminado. El comando se aplica a todos los routers
de la misma red IP lógica que participen en el mismo grupo HSRP.
Una vez que este configurada la dirección de reserva de HSRP,
los routers negocian cuál de ellos será el router de reenvío
principal, y cual el de reserva. Además, ambos routers introducen en
la tabla ARP la dirección IP y la dirección MAC de la dirección
virtual. El router de reenvío principal comienza el reenvío del
tráfico enviado a la dirección IP virtual de reserva, así como la
respuesta a pings y la aceptación de las sesiones de los terminales
virtuales de dicha dirección. Observe que la dirección MAC de la
dirección IP virtual de las interfaces Ethernet, Fast Ethernet,
Gigabit Ethernet y FDI tiene la forma 0000.0c07.acXX donde XX es un
identificador de grupos HSRP. La dirección MAC de la dirección IP
virtual de Token Ring es una dirección funcional con la forma
1000.xxxx.xxxx.

Sugerencia_
Algunos dispositivos de Token Ring no aceptan la dirección MAC
de un dispositivo IP como dirección funcional de grupo. En este caso
utilice el subcomando de configuración de interfaz de IOS standby usebia
para obligar a la dirección IP virtual de HSRP a utilizar la
dirección impresa en el hardware de la interfaz, que limita el número
de grupos HSRP de la interfaz a una.
Como ya se ha indicado, el administrador de red tiene varias
opciones de configuración que controlan el comportamiento de HSRP.
Para controlar cuál es el router de reenvío principal, se utiliza el
subcomando de configuración de interfaz de IOS standby priority. El
comando adopta como parámetro un valor entre 0 y 255. El router del
grupo HSRP que tenga la prioridad más alta se convierte en el router
de reenvío.
Si el router de reserva tiene que convertirse en el activo,
asume automáticamente dicho papel. Es posible controlar si el primer
router principal reanuda su papel de reenvío activo cuando pueda
volver a utilizarse. El subcomando de interfaz de IOS standby preempt
hace que el router reanude la función de reenvío activo a partir de
otro router con prioridad más baja.
En algunas situaciones, el estado operacional de una interfaz
afecta directamente al router que se elige como router de reenv ío
activo. Esto ocurre en particular cuando cada uno de los routers del
grupo HSRP tiene una ruta de acceso distinta a otras partes de la red.
El software IOS ofrece una característica de HSRP para que un
router pueda ajustarse a la prioridad HSRP de un grupo HSRP de forma
que se pueda convertir en el router de reenvío activo. Esta
funcionalidad, recibe el nombre de seguimiento de interfaces, se
activa con el subcomando de configuración de interfaz de IOS standby
trac. Este comando adopta como parámetro la interfaz a la que se le va
a realizar el seguimiento y opcionalmente, la cantidad que hay que
reducir de la prioridad HSRP en la interfaz configurada. Si no se
especifica ningún valor de reducción de prioridad, el router deduce la
cantidad estándar de diez de la prioridad HSRP.
El funcionamiento de HSRP puede verificarse con el comando
ejecutable de IOS show standby. El comando adopta como parámetro
opcional la interfaz específica en la que se va ha mostrar la
información la información de HSRP. Sin dicho parámetro la información
de HSRP aparece en todas las interfaces.
El comando show standby muestra la información de HSRP, que
incluye el estado de los reenvíos, la prioridad HSRP y las interfaces
a las que realizan seguimientos del router al que se realizan
consultas. También muestra información acerca de la dirección IP de
reserva configurada y las direcciones IP de los posibles routers de
reserva de cada grupo HSRP.
Una de las desventajas del HSRP original era que no permitía al
administrador de red compartir la carga del tráfico que cruza ambos
routers del grupo de reserva. Básicamente, el router de reserva
estaría inactivo a menos que fallará el router de reenvío activo.
Para solucionar este problema, se añadió al software IOS la
capacidad para admitir varios grupos HSRP en la misma interfaz. En la
misma interfaz se pueden crear varios grupos HSRP, cada uno de ellos
con una dirección IP virtual distinta, para respaldarse unos a otros.
Con dos grupos HSRP y dos direcciones IP virtuales definidas, el
administrador de red puede configurar el gateway predeterminado en
algunos de los host con una de las direcciones virtuales de HSRP, y en
los host restantes, con la otra. Aunque no consigue un equilibrado de
la carga exactamente igual, esta configuración comparte la carga entre
los dos routers en lugar de sobrecargar sustancialmente uno de ellos
mientras el otro se queda completamente inactivo.
Mediante la especificación de un número de grupo en todos los
comandos standby, se pueden crear varios grupos HSRP. Por ejemplo,
standby 1 ip address [dirección IP] y standby 1 priority 100
especifican que estos comando HSRP se aplican al grupo de reserva 1.
Los comandos standby 2 ip address [dirección IP] y standby 2 priority
100 especifican que estos comando HSRP se aplican al grupo de reserva

RESUMEN DE COMANDOS EJECUTABLES PARA IP
clear host
Elimina las entradas temporales de la tabla de host IP.
Clear ip access-list counters
Borra el cómputo del número de veces que ha coincidido cada una de las
líneas de una lista de acceso IP.
Clear ip route
Borra toda la tabla de enrutamiento o, si se especifica, una ruta en
particular.
Ping ip-address
Realiza pruebas para determinar si se puede comunicar con la direcci ón
IP que se indica y si ésta responde.
Show {frame-relay | atm | x25 | dialer} map
Muestra las asignaciones de direcciones IP a direcciones de enlace de
datos en el tipo de medios de WAN especificado.
Show access-list
Muestra todas las listas de acceso definidas en el router
Show host
Verifica la configuración DNS de un router y muestra una lista de host
que han resuelto sus nombres a direcciones IP.
Show interface[interfaz]
Proporciona información general acerca de una interfaz, incluyendo la
dirección IP y la máscara de red.
Show ip access-list
Muestra todas las listas de acceso IP definidas en el router.
Show ip arp
Muestra todas las direcciones IP que el router ha podido resolver a
direcciones MAC.
Show ip dchp binding
Muestra información acerca de las asignaciones de direcciones de
direcciones del servidor DCHP de IOS.
Show ip dchp conflict
Muestra la información acerca de los conflictos de direcciones IP que
detecta el servidor DCHP de IOS durante el proceso de asignaci ón.
Show ip dchp database
Muestra información acerca de la ubicación y estado de la base de
datos que ha utilizado el servidor DCHP de IOS para registrar las
asociaciones y conflictos de DCHP.
Show ip dchp server statistics
Muestra información sobre el estado y los contadores relacionados con
el funcionamiento del servidor DCHP de IOS.
Show ip interface brief
Muestra un pequeño resumen de la información de las direcciones IP y
el estado de todas las interfaces disponibles en el dispositivo.
Show ip interface[interfaz]
Muestra todos los parámetros asociados con la configuración de una
interfaz IP.
Show ip mask [dirección de red]
Muestra las máscaras de red que se han aplicado a la red designada y
el número de rutas que utiliza cada máscara.
Show ip protocols
Muestra los protocolos de enrutamiento que están ejecutando y varios
de sus atributos. Si se utiliza con la palabra clave summary, muestra
solamente los nombres de los protocolos y los números de los
identificadores de los procesos.
Show ip route
Muestra la tabla de enrutamiento IP del router.
Show ip route connected
Muestra las rutas asociadas con las interfaces del router
operacionales conectadas directamente.
Show ip route[dirección IP]
Muestra la información de enrutamiento de la ruta especificada.
Show ip route static
Muestra las rutas que se derivan de los comandos de rutas de red
configurados manualmente.
Show ip traffic
Presenta las estadísticas globales de funcionamiento de IP en el
router.
Show standby
Muestra información sobre el funcionamiento de HSRP.
Terminal ip netmask-format{decimal | bit-count | hexadecimal}
Especifica el formato de visualización de las máscaras de red que se
van a utilizar durante la sesión de la consola o del terminal virtual
existente.
Trace[dirección IP]
Muestra todos los pasos de ruta de acceso a la red por los que viajan
los paquetes para llegar a la dirección IP indicada.

RESUMEN DE COMANDOS DE CONFIGRACIÓN PARA IP
aaa authentication ppp [método de lista]
especifica que ppp debe autenticarse a través del método aaa de la
lista.
aaa authorization network [método]
especifica que los servicios de red deben autenticarse a trav és del
método de aaa de la lista.
access-list
crea una lista de acceso numerada y sus criterios de filtros
asociados.
arp-server
identifica el servidor arp de atm que pueden resolver direcciones ip
en direcciones nsap de atm.
async-bootp dns-server[dirección ip]
especifica direcciones ip de un servidor dns proporcionadas a los
clientes de acceso telefónico durante el establecimiento de llamadas
de forma global.
async-bootp nbns-server[dirección ip]
especifica las direcciones ip de un servidor de nombres netbios/wins
proporcionadas a los clientes de acceso telefónico durante el
establecimiento de llamadas de forma global.
async mode{interactive | dedicated}
especifica el método de interacción del usuario en una interfaz
asíncrona para los usuarios de acceso telefónico.
autoselect ppp
especifica que el proceso de selección automático debe realizarse
durante el proceso de autenticación.
compress
especifica que el algoritmo de compresión debe intentar negociarse
durante la negociación del acceso telefónico por ppp.
default-metric
asigna la métrica de enrutamiento que se va a utilizar durante la
redistribución de rutas entre los protocolos de enrutamiento
dinámicos.
defaul-router[dirección]
define una o varias direcciones ip predeterminadas del router que
ofrece a los clientes dchp el servidor dchp de ios.
dialer-group[entero]
especifica el grupo de marcadores al que pertenece una interfaz y
específica qué lista de marcadores se utiliza para definir el tráfico
de interés.
dialer-list[número de lista]protocol[método de tipo]
Define una lista de marcadores que especifica los protocolos de red y
métodos que se utilizan para definir el tráfico como interesante para
las sesiones de acceso telefónico.
dialer map ip
Asigna una dirección ip al nombre de sistema y al número de teléfono
para las llamadas rdsi.
dialer rotary-group[entero]
Asigna una interfaz rdsi a la estructura del grupo de la interfaz de
quien realiza la llamada.
distribute-list
Aplica una lista de acceso a la tares de filtrar la recepci ón y la
publicación de las rutas de red.
dns-server[dirección]
Define una o varias direcciones ip del servidor dns que ofrece a los
clientes dchp el servidor dchp de ios.
domain-name[dominio]
Define un nombre de dominio dns que ofrece a los clientes dchp el
servidor dchp de ios.
flowcontrol{hardware | software}
Especifica el método de control de flujos en una línea asíncrona.
Frame-relay map ip
Asigna una dirección IP a un DLCI Frame Realy
Group-range [principio fin]
Específica que interfaces asíncronas se incluyen en las estructuras de
interfaces del grupo asíncrono.
Ip access-group list{in | out}
Aplica la lista de acceso indicada a la tarea de filtrar paquetes
entrantes o salientes en una interfaz.
Ip access-list{extended | standard}[nombre]
Crea una lista de acceso IP con nombre y sus criterios de filtrado
asociado.
Ip address [dirección ip][máscara de red]
Asigna una dirección IP y una máscara de red a las interfaces de LAN y
de WAN.
Ip classless
Activa el router para que funcione en modo sin clase, en el que las
direcciones IP de destino coinciden con las rutas de la superred y de
los bloques CIDR.
Ip default-information originate
Hace que OSPF genere la ruta predeterminada desde el router l ímite de
sistema autónomo para el resto del dominio OSPF.
Ip default-network[dirección de red]
Configura la dirección de red especificada como red de resumen o
predeterminada.
{no}ip dchp conflict logging
Activa o desactiva el registro de la información de los conflictos de
direcciones por parte del servidor DCHP de IOS.
ip dchp database[dirección URL]
Define la ubicación y método para registrar la información de las
asociaciones y de los conflictos de direcciones por parte del servidor
DCHP de IOS.
ip dchp exclude-address
Especifica una o varias direcciones IP que deben excluirse de las
ofertas de DCHP a los clientes DCHP por parte del cliente DCHP de IOS.
ip dchp poll[nombre]
Crea un conjunto de direcciones DCHP que se puede configurar con otros
subcomandos de configuración DCHP.
ip dchp-server[dirección IP]
Especifica la dirección IP de un servidor DCHP que puede asignar
dinámicamente direcciones IP a los clientes de acceso telefónico.
ip domain-list[nombre]
Establece una lista de nombres de dominios que añadir a los nombres de
host no cualificados.
ip domain-lookup
Activa el DNS.
domain-name[nombre]
Configura el nombre del dominio principal que añadir a los nombres de
host no cualificados.
ip forward-protocol udp type
Controla que tipo de difusiones UDP se reenvían.
ip helper-address[dirección IP]
Reenvía difusiones UDP a la dirección IP especificada.
ip host
Configura la asignación estática de un nombre de host a las
direcciones IP.
ip local pool{default | poll-name}[dirección IP de inicio y dirección
IP de final]
Crea un conjunto de direcciones IP para asignar dinámicamente
direcciones IP a los clientes de acceso telefónico.
ip dchp-server[dirección ip]
Configura servidore de nombres DNS.
ip netmask-format{decimal | bit-count | hexidecimal}
Configura el formato de visualización de las máscaras de red que se va
a utilizar durante las sesiones de las consolas o de los terminales
virtuales.
ip ospf network{broadcast | non-broadcast | point-to-multipoint}
Configura el tipo de red(difusión, no difusión o punto a multipunto)
que OSPF cree que está conectada ala interfaz.
ip rip {send | receive} versión
Especifica que versión de RIP se envía y recibe en una interfaz
específica.
ip route 0.0.0.0 0.0.0.0 [dirección ip de destino]
Configura una ruta predeterminada de 0.0.0.0.
ip route [dirección de red][máscara de red][dirección ip de destino]
Configura una ruta estática
ip route [dirección de red][máscara de red][dirección ip de subred]
Configura un ruta resumen, adoptando como parámetros la ruta resumen,
la máscara de red y la subred no conectada.
ip routing
Activa el enrutamiento IP del router.
Ip subnet-zero
Permite asignar una interfaz a la primera subred del conjunto de
direcciones de red(subred cero).
Ip unnumbered [interfaz]
Configura una interfaaz IP de WAN punto a punto no numerada
Map-group
Asigna un grupo de asignación con nombres a una interfaz para que lo
use a la hora de asignar direcciones IP a las direcciones de enlace de
datos ATM en una interfaz.
Map-list
Crea un lista de asignación con nombres para configurar la asignación
de direcciones IP a los PVC o SVC en el direccionamiento ATM.
modem autoconfigure{discover | tipo de módem}
Especifica que un módem conectado a una línea asíncrona debe
configurarse automáticamente por descubrimiento por el uso de los
parámetros del tipo de módem con nombre.
modem {dialin | inout}
Especifica la dirección permitida de las llamadas asíncronas.
neighbor[dirección IP]
Especifica la dirección IP de un router vecino con el que intercambiar
información de enrutamiento dinámico.
neighbor[dirección IP]description
Permite añadir comentarios al comando neighbor de BGP.
neighbor[dirección IP]distribute-list
Permite el filtro de rutas BGP a igual BGP.
neighbor[dirección IP]remote-as asn
Configura el router vecino con la dirección indicada en el sistema
autónomo indicado como igual BGP.
neighbor[dirección IP]update-source[interfaz]
Especifica que la dirección IP de origen para establecer la sesión de
igual BGP debe derivarse de la interfaz con nombre.
netbios-name-server[dirección]
Define una o varias direcciones IP del servidor NetBIOS/WINS que
ofrece a los clientes DCHP el servidor DCHP de IOS.
netbios-node-type[tipo]
Define el modo de comportamiento de NetBIOS que ofrece a los clientes
DCHP el servidor DCHP de IOS.
network[dirección de red]
Especifica que las direcciones conectadas que coincidan con la
dirección de red indicada deben incluirse en las publicaciones del
enrutamiento.
network[dirección de red]area [número de área]
Especifica que las interfaces conectadas que coincidan con la
dirección de red indicada deben incluirse en las publicaciones del
enrutamiento OSPF y que las interfaces deben asignarse al área
especificada.
network[número de red][máscara | longitud del prefijo]
Especifica el conjunto de direcciones IP que se ofrecerán a los
clientes DCHP de un conjunto de direcciones DCHP determinado por parte
del servidor DCHP de IOS.
no autosummary
Evita el resumen automatico de direcciones en los limites de la red
con clase y permite la propagación de la información de la subred.
no inverse-arp
Desactiva la función de asignación de la dirección IP a DLCI de Frame
Relay.
passive-interface[interfaz]
Configura el router para escuchar pero no publicar la informaci ón de
enrutamiento en la interfaz indicada.
peer default ip address{pool | dchp | dirección IP}
Especifica el método que se ha utilizado para asignar una dirección IP
a una estación de trabajo cliente de acceso telefónico.
Ppp authentication[método]
Especifica que debe realizarse la autenticación PPP antes de permitir
que den comienzo los servicios de red. Entre el servidor de acceso y
el cliente de acceso telefónico se utiliza el protocolo de
autenticación de nombre.
Ppp ipcp{dns | wins}
Especifica las direcciones IP de los servidores DNS o NetBIOS/WINS que
se proporcionan a los clientes de acceso telefónico durante el
establecimiento de sesiones PPP a través de interfaz.
Ppp multilink
Especifica que debe activarse la multiplexión de canales basada en
software en una interfaz.
Redistribute protocol
Permite la redistribución de rutas desde el protocolo indicado.
Router{rip | igrp | ospf | eigrp |bgp}
Permite al router ejecutar el protocolo de enrutamiento din ámico.
Speed [bits por segundo]
Especifica la velocidad de transmisión de una línea asíncrona.
Stanby ip[dirección ip]
Configura la dirección IP indicada como dirección IP virtual de un
grupo HSRP.
Standby preempt
Hace que un router HSRP de mayor prioridad reanude el reenv ío activo
cuando vuelva a estar disponible.
Standby priority[prioridad]
Asigna un valor de prioridad a un router HSRP para controlar la
selección del router de reenvío principal.
Standby track[interfaz]
Activa el ajuste dinámico de la prioridad HSRP basándose en el estado
operacional de la interfaz especificada.
Standby use-bia
Obliga a la dirección IP virtual de HSRP a asociarse con la dirección
MAC impresa en el hardware de una interfaz.
{no}synchronization
Activa o desactiva el requisito de que las rutas se conozcan a trav és
del proceso de enrutamiento de IGP antes de publicarlas a los vecinos
EBGP.
username[nombre][password][palabra]
Define la pareja nombre de usuario local/contraseña que se va a
utilizar para autenticar a los usuarios de acceso telefónico.
versión[versión de RIP]
Especifica la versión de RIP que se utiliza en un router con RIP
activo.
x25 map ip
Asigna una dirección IP a una dirección X.121.



La siguiente tabla define muchos de los elementos sobre los que
se informa cuando se usa el comando show interfaces:
Five-minutes rates(input or output)(Intervalos de cinco
minutos)(entrada o salida)
El promedio de bits y paquetes que pasan por la interfaz cada
segundo, muestreados durante los últimos cinco minutos.
Aborts(Cancelaciones)
Terminación repentina de los paquetes de transmisión de un
mensaje.
Buffer failures(Fallos del buffer)
Paquetes desechados por falta de disponibilidad de memoria b úfer
del enrutador.
BW
Ancho de banda de la interfaz en kilobits por segundo(Kbps).
Esto se puede utilizar como una métrica de protocolo de enrutamiento.
Bytes
Número total de bytes trasmitidos a través de la interfaz.
Carrier transitions(Transacciones de portadora)
Una portadora es la señal electromagnética modulada por las
transmisiones de datos sobre líneas serie(como el sonido que emite el
módem). Las transiciones de portadora son eventos donde se interrumpe
la señal, a menudo cuando se reinicia la NIC remota.
Collisions(Colisiones)
Número de mensajes retransmitidos debido a una colisión
Ethernet.
CRC
Comprobación de redundancia cíclica, una técnica común para
detectar errores de transmisión. CRC funciona dividiendo el tamaño del
contenido de una trama por un número primo y comprobando el resto con
el que hay almacenado en la trama por el nodo emisor.
DLY
Demora del tiempo de respuesta de la interfaz, medido en
microsegundos(ns), no en milisegundos(ms).
Dibble conditions(Condiciones de exceso)
Tramas que son ligeramente demasiado largas, pero que las sigue
procesando la interfaz.
Drops(Caídas)
Número de paquetes desechados por falta de espacio en la cola.
Encapsulation(Encapsulación)
Método de encapsulación asignado a una interfaz(si existe).
Funciona ajustando los datos en la cabecera de un protocolo para
los datos que de otra forma serían incompatibles a través
de redes externas. Por ejemplo, Inter.-Switch Link de Cisco ISL;
Enlace entre conmutadores encapsula tramas de muchos protocolos.
Errors(input or output) Errores entrada o salida
Una condición en la que se descubre que una transmisión no
coincide con lo que se esperaba, normalmente está relacionado con el
tamaño de la trama o del paquete. Los errores se detectan usando
varias técnicas, como CRC.
Frame(Trama)
Número de paquetes que tienen un error de CRC y un tamaño de
trama parcial. Suele indicar que el dispositivo Ethernet funciona
incorrectamente.
Giants(Gigantes)
Paquete mayor que el paquete de tamaño máximo que permite la
tecnología, 1.518 bytes o más en las redes Ethernet. Todos los
paquetes gigantes se desechan.
Ignored(Ignorado)
Número de paquetes desechado por la interfaz por falta de búfer
de memoria del búfer de la interfaz(en contraposición con la memoria
búfer del enrutador).
Interface resets(Reinicios de Interfaz)
Cuando la interfaz se deshace de todos los paquetes y comienza
con uno nuevo. El reinicio suele ocurrir cuando el nodo emisor tarda
demasiado en transmitir los paquetes.
Keepalives(Mensajes de supervivencia)
Mensajes enviados por un dispositivo de red a otro para
notificarle que el circuito virtual entre ellos sigue activo.
Last input or output(Última entrada o salida)
Horas, minutos, y segundos desde que la interfaz transmitió o
recibió con éxito el ultimo paquete. Es una buena herramienta para
determinar cuándo ha comenzado el problema.
Load(Carga)
Carga de la interfaz como una fracción del número 255. Por
ejemplo, 64/255 representa un 25 por 100 de la carga. Se puede
utilizar este contador como una métrica del protocolo de enrutamiento.
Loopback(Ciclo invertido)
Si se ha activado el ciclo invertido. Loopback es donde env ían
las señales desde la interfaz y, luego, se devuelvan a ella desde
algún punto de la ruta de comunicaciones; se utiliza para probar el
uso del enlace.
MTU
Unidad de transmisión máxima para paquetes que pasan a través de
la interfaz, expresado en bytes.
Output hang(Bloqueo de salida)
Tiempo transcurrido desde el último reinicio de la interfaz.
Toma su nombre del hecho de que la interfaz porque la
transmisión tarda demasiado tiempo.
Overruns(Saturaciones)
Número de veces que la interfaz del enrutador satura el nodo
receptor enviando más paquetes de los que pueden manejar el búfer del
nodo. Toma su nombre del hecho de que la interfaz del enrutador
al emisor.
Queues(input and output) Colas(entrada y salida)
Número de paquetes en la cola. El número a continuación de la
barra invertida es el tamaño máximo de la cola.
Queuing strategy(Estrategia de encolamiento)
FIFO significa First In, First Out(Primero en entrar primero en
salir), que significa que el enrutador maneja paquetes en ese orden
LIFO significa Last In, First Out(Último en entrar, primero en salir).
FIFO es la estrategia predeterminada.
Rely(Confianza)
Fiabilidad de la interfaz como una fracción del número 255. Por
ejemplo, 255/255 equivale al 100 por 100 de fiabilidad. Se puede
utilizar este contador como una métrica del protocolo de enrutamiento.
Runts(Diminutos)
Paquete menor que el tamaño del paquete mínimo que permite la
tecnología, 64 bytes o menos en las redes Ethernet. Todos los paquetes
diminutos se desechan.
Throttles(Aceleradores)
Número de veces que una interfaz avisa a una NIC emisora que
está siendo saturada por los paquetes que se envían y para reducir el
ritmo de envío. Toma su nombre del hecho de que la interfaz pregunta a
la NIC que .
Underruns(Agotamientos)
Número de veces que el nodo emisor satura la interfaz enviando
más paquetes de los que puede manejar el búfer. Toma su nombre del
hecho de que la interfaz del enrutador al emisor.

CONECTARSE A TERMINALES VIRTUALES UTILIZANDO TELNET Y SSH.
Los métodos más habituales para acceder a cualquier dispositivo
en el que se ejecuta IOS son a través del puerto de la consola o a
través de líneas de terminales virtuales(virtual terminal lines, vty).
Estas líneas son un tipo de software que permiten conectarse a un
router a través de una red de datos. Los dispositivos IOS admiten
cinco sesiones simultáneas a través de líneas de terminales virtuales.
Los dos métodos más frecuentes para conectarse a una línea de
terminal virtual son el uso de un cliente Telnet o el uso de un
cliente Secure Shell(SSH). Los clientes Telnet utilizan un protocolo
estándar definido en RFC 854 para proporcionar una conexión no segura
al software de servidor que se ejecuta en una línea de terminal
virtual. Por defecto, todos los dispositivos con IOS tienen un
servidor Telnet habilitado en todas las líneas de terminales
virtuales.
SSH es un protocolo que proporciona una conexión cifrada segura
entre un cliente y un servidor SSH que funcionen en una línea de
terminal virtual con funciones que sean similares a una conexi ón
Telnet. En contraste al servidor Telnet, los servidores SSH no est án
habilitados por defecto en las líneas terminales virtuales.
Ciertos dispositivos IOS pueden ser clientes Telnet o clientes
SSH, para lo que se utilizan los comandos Telnet o SSH.

Nota_
Actualmente, hay dos versiones de SSH: SSH versión 1 y SSH
versión 2. En estos momentos, Cisco IOS sólo admite la primera de
ellas.
Los clientes y servidores SSH pueden realizar la autenticaci ón
de usuarios a través de un sistema criptográfico con claves públicas
que inventaron Rivest, Shamir y Adelman (RSA). La autenticaci ón de
usuarios RSA de los clientes SSH no es compatible con el servidor SSH
de Cisco IOS. Cisco IOS autentica a los usuarios utilizando solamente
una combinación de ID de usuario y contraseña. El servidor SSH de IOS
utiliza RSA para generar la pareja de claves que se utiliza para
configurar sesiones cifradas en el cliente.
SSH asegura la conexión entre el cliente y el servidor SSH
utilizando el algoritmo de cifrado DES(56bits) o Triple DES(168bits).
Sin embargo, no todas las versiones de IOS admiten DES o Triple DES y,
a veces hay que utilizar el comando show versión para ver si la
versión de IOS que se utiliza admite estos algoritmos de cifrado.

Nota_
Algunos algoritmos de cifrado (entre los que se incluye el
cifrado de datos de 56 bits) están sujetos a los controles de
exportación del gobierno de Estados Unidos. El uso de estos algoritmos
(y de la versión de IOS que los admite) fuera de Estados Unidos
requiere una licencia de exportación.

ACTIVACIÓN DEL SERVIDOR SSH
Para activar el servidor SSH y permitir a los clientes SSH
conectarse a líneas de terminales virtuales, el dispositivo con IOS
debe tener un nombre de host y nombre de dominio configuran con los
comandos de configuración global hostname e ip domain-name, que ya se
han explicado.
Para configurar el servidor SSH, hay que generar una pareja de
claves de RSA que se utiliza para cifrar la sesión entre y el
servidor. En el dispositivo con IOS, la pareja de claves de RSA se
genera utilizando el comando de configuración global crypto key
generate rsa. Al generar una pareja de claves de RSA para el
dispositivo con IOS, se activa automáticamente el servidor SSH en las
líneas de terminales virtuales. Para suprimir una clave de RSA se
utiliza comando de configuración global crypto key zeroize rsa, que
desactiva automáticamente el servidor SSH.

Nota_
El comando de configuración global crypto key generate rsa no
aparecerá en la salida por pantalla de show running-config ni de
startup-config.
Router#configure t
Router(config)#crypto key generate rsa
Router(config)#ip ssh
Router(config)#ctrl.+Z

VERIFICACIÓN DE LA CONFIGURACIÓN DE SSH
La clave de RSA pública que utiliza SSH se puede ver con el
comando ejecutable show crypto key mypubkey rsa:
Además es posible ver las sesiones de SSH activas de cualquier
dispositivo con IOS utilizando el comando show ip ssh:

CÓMO ASEGURAR EL PUERTO DE LA CONSOLA Y LOS TERMINALES
VIRTUALES
En el nivel de los dispositivos individuales con IOS, es posible
definir una contraseña de acceso a través del puerto de la consola
utilizando el comando principal de IOS line console 0 y el subcomando
de IOS password. En las líneas de terminales virtuales, se pueden
agregar contraseñas utilizando el comando principal vty 04 y el
subcomando password.
Con el subcomando de línea access-list, es posible especificar
una lista de direcciones IP que sean capaces de conectarse a las
líneas de terminales o a las que sea posible acceder desde las l íneas
de terminales de cualquier dispositivo con IOS. Es posible especificar
si se utiliza una clase de acceso para las sesiones entrantes o
salientes mediante el uso de una palabra clave in u out. Este
subcomando utiliza una lista de acceso IP para habilitar las
direcciones IP antes de que se inicie cualquier sesión entrante o
saliente. El subcomando access-list se puede utilizar para permitir
que solamente las estaciones de trabajo del administrador de red
puedan acceder a las líneas de terminales virtuales de los
dispositivos con IOS, que es un método adicional para asegurar el
acceso a los dispositivos.
Las contraseñas de consola y de los terminales virtuales se
guardan en texto sin formato en la configuración activa y en la de
inicio. Si desea cifrar todas las contraseñas que muestran los
comandos ejecutables(como show running-config o show startup-config),
puede utilizar el comando de configuración global service passwordencryption.
Como resultado de este comando, las versiones cifradas de
las contraseñas dejan de poder verse a través de ningún comando
ejecutable. No se preocupe si olvida la contraseña, Cisco ha
documentado varios procedimientos de recuperación de contraseñas para
cada tipo de dispositivo.
Una alternativa a la configuración de contraseñas dispositivo a
dispositivo para el control de acceso es utilizar un protocolo de
control de acceso en la red. Estos protocolos de control de acceso
realizan tres funciones: autenticación, autorización y contabilidad,
que en conjunto se conocen como AAA. La autenticación es el proceso de
identificación y verificación de los usuarios. En Cisco IOS, se pueden
utilizar varios métodos para autenticar a los usuarios, entre los que
se incluyen una combinación de un nombre de usuario t contraseña, o el
paso de una clave única. La autorización determina lo que pueden hacer
los usuarios una vez que han sido autenticados, como, por ejemplo,
obtener acceso y realizar tareas en determinados dispositivos de la
red o host de acceso. La contabilidad es el método de grabación de los
que los usuarios hacen o han hecho.
AAA requiere dos componentes: un cliente dos componentes: un
cliente que funcione un dispositivo con Cisco IOS y el software
relacionado del servidor de control de acceso, que suelen utilizarse
en las estaciones de trabajo de la red. Remote Authentication Dial-In
User Service(RADIUS) y Terminal Access Controller Access Control
System (TACACS+) son dos de los protocolos que suelen utilizarse para
proporcionar comunicación entre el cliente AAA de un dispositivo Cisco
y el software del servidor de control de acceso.
Piense en un usuario que utiliza la aplicación Telnet para
conectarse a un router en el que no se ha configurado ningún protocolo
de control de acceso. Inmediatamente, se solicita al usuario la
contraseña de la línea de terminal virtual:
% telnet router
Trying...
Password:
Si el usuario escribe la contraseña correcta, recibe acceso al
modo ejecutable del router.
Este usuario no está sujeto a ningún proceso de autenticación y
autorización, y es libre para realizar cualquier tipo de
tares(incluyendo la entrada al modo privilegiado, siempre que se
conozca la contraseña)
Además, el usuario que realiza esta acción no está registrado.
Sin duda alguna, dicha directiva abierta no es aceptable en la inmensa
mayoría de las redes. Una excepción puede encontrarse en aquellos
entornos de laboratorio o de pruebas en los que el acceso no
contabilizado a un dispositivo por parte de muchos usuarios no afecta
a la seguridad, configuración o rendimiento de la red.
Si se configura un dispositivo Cisco IOS para utilizar algún
protocolo de control de acceso, el dispositivo solicita al usuario un
nombre de usuario y una contraseña.
% telnet router
Trying...
Username: Usuario
Password:
Con un protocolo de control de acceso, el dispositivo con Cisco IOS
realiza las siguientes tareas:
1. El cliente de control de acceso del dispositivo solicita el
nombre de usuario y la contraseña al recibir la solicitud
entrante de conexión por Telnet.
2. El cliente de control de acceso consulta al usuario y env ía la
combinación de nombre de usuario y contraseña del mensaje de
solicitud de autenticación al servidor de control de acceso.
3. El servidor de control de acceso autentica la combinación de
nombre de usuario y contraseña. La combinación otorga o deniega
la combinación, y devuelve el mensaje apropiado al cliente. El
servidor puede proporcionar al cliente información acerca de su
autorización. El servidor acaba con la transacción.
4. El cliente de control de acceso permite o deniega la combinaci ón
de nombre de usuario y contraseña. Si se permite, el usuario
consigue acceder al sistema y está autorizado para realizar las
acciones especificadas en la información de autorización que
pasa el servidor.

ACTIVACIÓN DE AAA
Para activar los servicios de AAA en Cisco IOS, hay que utilizar
el comando de configuración aaa new-model.
Seguidamente, se puede activar el cliente AAA para una
configuración específica de autenticación, autorización y contabilidad
utilizando los siguientes comandos de configuración global: aaa
authentication, aaa authorization y aaa accounting. Todos los comando
AAA se configuran utilizando listas de métodos. Una lista de métodos
es una lista configurada que describe los métodos AAA que se van a
intentar, en la secuencia ordenada, para autenticar a un usuario,
autorizar una actividad o contabilizar una acción. Por ejemplo, con
listas de métodos se pueden especificar varios mecanismos de
autenticación en un intento de autenticar a un usuario en caso de que
falle el método inicial. Un dispositivo con IOS intenta utilizar el
primer método que aparece en la lista para autenticar a los usuarios;
si dicho método no responde, el dispositivo prueba con el siguiente
método de autenticación de la lista de métodos. El proceso continua
hasta que s produce una comunicación correcta con un método de
autenticación de la lista o hasta que hayan utilizado todos los
métodos de la lista. Las listas de métodos de autorización y
contabilidad funcionan de forma parecida a las descritas anteriormente
por la autenticación.

Nota_
Los dispositivos con IOS intentan utilizar el siguiente método
de una lista de métodos solamente si el dispositivo no puede
comunicarse con el método anterior. Por ejemplo, si algún método de
autenticación responde pero no autentica al usuario, no se utiliza el
siguiente método de autenticación.
Dos protocolos de AAA habituales son RADIUS y TACACS+. Con los
comandos de configuración global aaa authentication, aaa authorization
y aaa accounting se puede especificar el método que hay que utilizar
cuando RADIUS utiliza el método group radius TACACS+ utiliza el método
group tacacs+.
El comando aaa authentication especifica los protocolos de
autenticación en una lista de métodos ordenada, que el dispositivo
puede intentar para verificar el acceso. El comando aaa authorization
permite especificar si se realiza la autorización en los comandos
ejecutables o al comienzo de las sesiones ejecutables o de la red(como
las sesiones PPP). También permite especificar el protocolo que se
utiliza para realizar estas tareas. El comando aaa accounting permite
especificar cuándo se envían mensajes de contabilidad al servidor AAA,
como, por ejemplo, al principio o al final de las sesiones de cada uno
de los usuarios o después de cada comando. Este comando también
especifica el tipo de contabilidad que realiza el cliente AAA. Puede
justificar la actividad del sistema IOS, los servicios relacionados
con la red (como PPP o ARAP) y las sesiones ejecutables. Puede
utilizar TACACS+ y RADIUS para enviar información contable desde un
cliente AAA a un servidor AAA.
La autenticación AAA se activa en las sesiones de conexión
mediante el uso del comando de configuración global aaa authentication
login. El primer protocolo de autenticación de la lista de métodos es
TACACS+.
Si el agente TACACS+ no es capaz de ponerse en contacto con el
servidor para realizar la autenticación, el dispositivo realiza la
autenticación a través de un segundo método(a saber, mediante el uso
del comando de configuración global enable secret o enable password).
Esta lista de métodos se ve en el comando aaa authentication login
como la opción group tacacs+, seguida de la opción enable.

Sugerencia_
Es aconsejable que no utilice un solo protocolo de AAA para la
autenticación de las sesiones de conexión en los dispositivos con IOS.
Un segundo método de autenticación de las sesiones de conexión
garantiza que siempre se puede obtener acceso a cualquier dispositivo
si no está disponible algún servidor AAA.
Al configurar los comandos aaa accounting y aaa authorization,
se aplica la misma lógica que con los comandos aaa authentication. Es
posible especificar otros métodos de autorización para las sesiones
ejecutables y las sesiones de red(como PPP) utilizando las opciones
exec y network en el comando de configuración global aaa
authorization. La palabra clave del método if-authenticated indica al
cliente AAA que otorgue autorización si la autenticación ha pasado por
la sesión.
Para finalizar, se contabilizan todas las sesiones ejecutables
cuando han dejado de utilizar el protocolo TACACS+ utilizando el
comando de configuración global aaa accounting.
Opcionalmente, puede definir sus propios grupos de servidores
AAA utilizando el comando de configuración global aaa server group y
el subcomando server. Los grupos de servidores AAA definidos por los
usuarios son útiles cuando se tiene un grupo de usuarios que utilizan
un servidor AAA y otro grupo de usuarios que utilizan otro servidor
AAA. Estos dos grupos pueden utilizar o no el mismo protocolo de
AAA(como RADIUS). Antes de la invención de los grupos de servidores
AAA, solamente podía utilizarse un solo conjunto de servidores AAA
para cada método para todos los usuarios. Un ejemplo frecuente del uso
de grupos de servidores AAA es la autenticación de usuarios de acceso
telefónico utilizando un servidor RADIUS.
En las secciones siguientes podrá ver como especificar los
servidores RADIUS y TACACS+ en el cliente AAA.

RADIUS
El protocolo RADIUS lo publicó originalmente la empresa
Livingston Enterprises,Inc., como un protocolo estándar que
intercambia información de AAA entre un cliente y un servidor RADIUS.
RADIUS es un protocolo abierto; varios dispositivos de red tienen un
cliente RADIUS.
Un servidor RADIUS es una estación de trabajo en la que se
ejecuta el software de servidor RADIUS de un fabricante u organizaci ón
como Livingston, Merit o Microsoft. Para especificar la direcci ón IP
del servidor RADIUS con el que se comunica el cliente con IOS se
utiliza el comando de configuración global radius-server host.
Al realizar la autenticación, el protocolo RADIUS cifra las
contraseñas enviadas entre el cliente y el servidor. Para que se
realice el cifrado de contraseñas hay que configurar una cadena
secreta tanto en el servidor RADIUS como en Cisco IOS. Para configurar
esta cadena en el cliente con Cisco IOS, utilice el comando de
configuración global radius-server key.

TACACS+
TACACS+ es un protocolo de AAA que es conceptualmente parecido a
RADIUS.
TACACS+ es la tercera revisión del protocolo TACACS. La segunda
revisión se llama Extended TACACS o XTACACS. TACACS+ es un procoloco
patentado de Cisco y todos los dispositivos con IOS tienen un cliente
TACACS+ nativo.
El software del servidor TACACS+ se puede obtener de varios
lugares, incluyendo Cisco(en el producto CiscoSecure) y otros
fabricantes, en muchas estaciones de trabajo.
Para especificar la dirección IP del servidor TACACS+ con el que se
cominica el cliente con IOS se utiliza el comando de configuraci ón
global tacacs-server key.

COMPARACIÓN ENTRE RADIUS Y TACACS+
Hay muchas diferencias entre RADIUS y TACACS+, pero su
funcionalidad es esencialmente la misma. RADIUS, que es un est ándar,
utiliza la capa de transporte UDP.
TACACS+, que está patentado, utiliza la capa de transporte TCP. RADIUS
funciona bien en entornos sólo con IP, mientras que TACACS+ es útil en
entornos multiprotocolo.
Actualmente, Radius admite más atributos en el protocolo y permite que
el cliente y el servidor pasen más información que TACACS+. RADIUS
cifra solamente la contraseña enviada entre el cliente y el servidor,
mientras que TACACS+ cifra toda la comunicación.
Muchos fabricantes admiten uno de estos protocolos o el otro
discuten vehementemente los méritos del protocolo de AAA que utilizan.
Cisco admite ambos protocolos. Si la red es en mayor parte
heterogénea, RADIUS es quizás el protocolo de AAA correcto, ya que
actualmente muchos fabricantes lo admiten. Sin embargo, si la red
utiliza principalmente dispositivos Cisco, es muy probable que TACACS+
sea la solución adecuada.

PREVENCIÓN BÁSICA CONTRA ATAQUES
Las características de intercepción de TCP (TCP intercept) y de
envío de ruta inversa de unidifusión (unicast reverse path fowarding)
de IOS permiten configurar una cierta seguridad contra dos tipos de
ataques de denegación de servicio: desbordamiento de SYN de TCP y
falsificación de la dirección IP de origen.
Un ataque de denegación de servicio es aquel en el que un pirata
informático (hacker) sobrecarga un recurso de red con trafico cuya
intención no es dañar datos, sino utilizar suficientes recursos de la
red para que no pueda realiza su función. Por ejemplo un ataque de
desbordamiento de SYN(sincronización) de TCP se produce cuando un
pirata informático desborda un servidor con un gran número de
solicitudes de SYN de TCP (que se utiliza para iniciar una conexi ón
TCP) desde una dirección IP de origen inválida. Todas estas
solicitudes tienen una dirección IP de origen a la que no se puede
acceder, lo que significa que no se pueden establecer las conexiones.
El gran número de conexiones abiertas que no se establece desborda al
servidor y puede provocar que deniegue el servicio a las peticiones
válidas, impidiendo que los usuarios se conecten al servidor y, por
consiguiente, realizando las tareas deseadas.

INTERCEPCIÓN DE TCP
La característica de intercepción de TCP facilita la prevención
de desbordamientos de SYN, ya que intercepta y valida las solicitudes
de conexiones por TCP cuando atraviesan un router. Esta caracter ística
también puede interceptar los mensajes SYN de TCP entrantes o vigilar
las conexiones TCP cuando el router los reenvía.
En el modo de intercepción, el router intercepta activamente
todas las SYN de TCP y responde por el servidor destino real con un
ACK y una SYN de TCP. Éste es el primer paso de un proceso de
establecimiento de conexiones TCP estándar llamado saludo a tres
bandas (three-way handshake). Seguidamente, el router espera un ACK de
TCP de la segunda SYN de TCP del origen. Cuando se recibe dicho ACK,
el router ha establecido una conexión TCP válida con el origen y se ha
completado el saludo a tres bandas. A continuación el router envía la
SYN de TCP original al servidor destino real y realiza un segundo
saludo a tres bandas. Después, el router une las dos conexiones TCP de
forma transparente y reenvía paquetes entre ellas mientras la conexión
esté activa.
En el modo de intercepción, la característica de intercepción de
TCP facilita la prevención del ataque de DoS a la SYN de TCP, ya que
los paquetes de aquellos host a los que no se pueda acceder nunca
llegarán al servidor destino. El router puede configurarse para que
intercepte solicitudes en función de una lista de acceso IP ampliada,
lo que permite especificar las peticiones que debe interceptar.
Una alternativa a la interceptación de todas las conexiones TCP
es que esta característica vigile las peticiones de conexión cuando
las reenvía el router. Si una conexión TCP no consigue iniciarse en un
intervalo configurable, el software IOS interceptará y terminará el
intento de conexión.
La característica de intercepción de TCP se configura con el
comando de configuración global de IOS ip tcp intercept mode. El
comando de configuración global ip tcp intercept list asigna una lista
de acceso IP ampliada para especificar qué solicitudes debe
interceptar el router. El comando ip tcp intercept watch-timeout
especifica el número de segundos que debe permitir el router antes de
restablecer cualquier conexión TCP que no haya completado un saludo a
tres bandas válido con el servidor destino. Por defecto, un router
restablecerá una conexión TCP si no se completa un saludo a tres
bandas en treinta segundos.
El comando ejecutable show tcp intercept connections muestra
todas las conexiones TCP incompletas y establecidas. El comando
ejecutable show tcp intercept statistics muestra estadísticas
relativas al comportamiento de la característica de intercepción de
TCP.

ENVÍO DE RUTA INVERSA DE UNIDIFUSIÓN
La característica de envío de ruta inversa (Reverse Path
Forwarding, RPF) de unidifusión puede ayudar a impedir el ataque de
DoS mediante falsificación de la dirección IP de origen (a veces
llamado simulación IP o IP spoofing). El ataque mediante
falsificación dela dirección IP de origen utiliza direcciones IP de
origen mal formadas o una IP de origen en constante cambio para atacar
a una red. Si su red recibe el ataque de una dirección IP de origen
mal formada o de un conjunto de direcciones IP de origen en constante
cambio, es fácil que sea imposible configurar una lista de acceso IP
para detener el ataque.

Nota_
La característica de RPF de unidifusión sólo está disponible en
los dispositivos con IOS si se utiliza Cisco Express Forwarding (CEF).
CEF es un mecanismo avanzado que se utiliza para reenviar paquetes y
para crear tablas de enrutamiento IP. Actualmente, CEF sólo funciona
en ciertos dispositivos de gama alta con IOS.
La característica de RPF de unidifusión ayuda a resolver este
problema mediante el descarte automático de aquellos paquetes IP que
no tengan una cuenta IP de origen que se pueda verificar. El router
verifica las direcciones IP viendo todos los paquetes recibidos en la
interfaz para asegurarse de que la dirección de origen y la interfaz
de origen del router aparece en la tabla de enrutamiento IP y
coinciden con la interfaz en la que se ha recibido el paquete. La ruta
recibida y la ruta hacia atrás, tal como se ve en la tabla de
enrutamiento con la dirección IP de origen, deben ser simétricas. Una
ruta es simétrica si un paquete llega a la interfaz de un router en
una de las rutas con mejor retorno con el origen del paquete, sin
limitarse a la interfaz exacta del router de origen, lo que permite
utilizar las técnicas de enrutamiento, como un balanceo de cargas del
mismo costo.
Si no hay ninguna ruta inversa en la misma interfaz de origen ni
ninguna ruta de retorno desde donde se recibió el paquete, podría
significar que se ha modificado la dirección de origen o que se ha
descartado el paquete. La verificación de que es posible acceder a la
dirección de origen a través de la ruta inversa en la que se reenviará
el paquete ayuda a evitar la falsificación de direcciones IP de
origen.
La característica de RPF de unidifusión se puede utilizar en
cualquier configuración de la red en la que haya una sola ruta de
conectividad desde la red. Si se tiene una sola ruta de conectividad,
incluso con varias rutas con reparto de carga, el enrutamiento de la
red es casi siempre simétrico. Esta configuración suele producirse en
el punto de salida de flujo ascendente a Internet de la red. La
característica de RPF de unidifusión no debe utilizarse en la red
interna cuando existen varias rutas diferentes a los destinos IP.
La configuración de la característica de RPF de unidifusión se
realiza mediante un solo subcomando de la interfaz, ip verify unicast
reverse-path. En un entorno común, este comando sólo se aplicaría a la
interfaz (o interfaces en los entornos de reparto de cargas) de flujo
ascendente del router que se conecta a Internet.
Los dispositivos con Cisco IOS tienen la capacidad de registrar
mensajes acerca de la actividad del sistema. Estos mensajes de
registro pueden ser útiles para hacer seguimientos de la actividad del
sistema, de los errores y de las notificaciones. El registro utiliza
ocho niveles de mensajes de notificación:
Nivel 0: Emergencias
El sistema no puede utilizarse.
Nivel 1: Alertas
Hace falta una acción inmediata para restaurar la estabilidad del
sistema.
Nivel 2: Criticas
Se han producido condiciones críticas que pueden necesitar atención.
Nivel 3: Errores
Se han producido condiciones de error que pueden ayudar a hacer
seguimientos de los problemas.
Nivel 4: Avisos
Se han producido condiciones de aviso que no son graves.
Nivel 5: Notificaciones
Condiciones normales pero significativas que exigen notificaci ón.
Nivel 6: Informativo
Estos mensajes informativos no requieren ninguna acción.
Nivel 7: Depuración
Son mensajes de depuración que solamente se utilizan para solucionar
los problemas del sistema.
En IOS, el usuario define el nivel mínimo de mensajes de
registro (en términos de gravedad) que desee que se registren. Para
ello hay que identificar el nivel por nombre en el comando de
configuración. Emergencias (Nivel 0) es el nivel más grave, mientras
que depuración(Nivel 7) es el menos grave. Todos los mensajes de nivel
que identifique y de los niveles más graves se envían a uno de estos
cuatro lugares:
Un servidor syslog, que se configura con el comando loogging
trap.
Un búfer interno del dispositivo, que se configura con el
comando logging buffered.
El puerto de la consola de un dispositivo, que se configura con
el comando loogging console.
Las líneas terminales de un dipositivo, que se configura con el
comando logging monitor.
Los anteriores comandos logging son comandos de configuración
global que le permiten especificar el nivel de los mensajes enviados a
cada ubicación de registro. Un servidor syslog es una excelente
ubicación de registro, ya que el sistema suele guardar los mensajes en
un disco. Además, dado que syslog es un programa de uso general que
utilizan muchos programas distintos, puede tener un origen central
para registrar mensajes de diferentes dispositivos.
El búfer interno del dispositivo es un útil programa de registro
si no se tiene ningún servidor syslog o si se desea que cada uno de
los dispositivos mantenga un registro de eventos independiente. El
tamaño predeterminado de este búfer es de 4.096 bytes. Dicho tamaño se
puede modificar con el comando logging buffered.
En algunas situaciones el búfer interno del dispositivo esta en la
memoria RAM del dispositivo, por lo que se pierde con cada recarga del
dispositivo.
El registro de mensajes en la consola o en las líneas terminales
de un dispositivo(incluyendo sesiones de terminales virtuales) es útil
para la notificación inmediata de los eventos críticos. Las cuatro
ubicaciones de registro distintas no son mutuamente exclusivas y se
pueden utilizar varios programas de registro al mismo tiempo.

Nota_
Para ver los mensajes de registro en una línea terminal o en una
sesión de terminal virtual debe utilizar el comando ejecutable
terminal monitor. Este comando se puede ejecutar en modo privilegiado.
Los mensajes del servidor syslog pueden configurarse con el
comando logging trap.
Para activar el registro sysloog en IOS hay que utilizar el
comando de configuración global logging para especificar la dirección
IP del host que realiza el registro.
Es posible registrar mensajes en más de una de las ubicaciones.

Nota_
El programa syslog registra los mensajes del sistema en un
archivo de texto en UNIX y en otros tipos de estaciones de trabajo.
Para registrar los mensajes de dispositivos con IOS en un servidor
syslog, debe configurar el proceso de syslog. Para activar el programa
syslog local7, el programa que utilizan todos los dispositivos con
IOS, hay que ser superusuario en una estación de trabajo UNIX. Como
superusuario (acceso raiz), debe añadir la siguiente línea al archivo
/etc/syslog.conf:
Local7.debug /var/adm/router.log
A continuación reinicie el demonio de syslog en la estación de
trabajo UNIX, lo que se suele hacer con el siguiente comando:
%kill –HUP `cat /etc/syslog.pid`
Si todo funciona bien, ya está listo para que los dispositivos
con IOS se registren en esta estación UNIX.
Si un dispositivo con IOS está configurado para registrarse en
un búfer interno, los resultados del registro se pueden ver con el
comando ejecutable show logging.

Sugerencia_
Es aconsejable activar el registro a nivel de depuración en, al
menos una ubicación de registro, ya que eso permite garantizar que se
graban todos los mensajes de error que envía el dispositivo con IOS.
La mayor parte de los administradores de redes tienden a establecer
logging trap debug para activar syslog, a fin de que registre todos
los mensajes de los dispositivos con IOS.

ADMINISTRACIÓN BASICA DE REDES.
La administración de redes es el proceso de gestión de fallos,
control de configuraciones, supervisión de rendimiento, aseguramiento
de la seguridad y contabilidad de actividades en una red de datos. Es
necesario que todas estas tareas tengan un control absoluto sobre
algún entorno de la red de datos, que es uno de los componentes
esenciales de cualquier organización. El ISO Network Management Forum
ha definido la administración de redes como la suma de todas las
actividades necesarias para realizar la administración de los fallos,
la configuración, el rendimiento, la seguridad y la contabilidad de
una red de datos.
Las plataformas de administración de redes son sistemas de
software diseñados para realizar las actividades de administración de
red. Algunos ejemplos de plataformas de administración de redes son:
Hewlett-Packard OpenView, Cabletron Spectrum, Sun Solstice Enterprise
Manager, IBM NetView/ AIX y CiscoWorks2000. Estas plataformas
proporcionan la arquitectura de software para las aplicaciones de
administración de redes que realizan una gran variedad de tareas.
No se pueden agrupar en una sola categoría. Algunas presentan un
mapa de la red y comprueban el estado de todos los dispositivos de la
red, lo que proporciona una función de administración de fallos.
Algunas herramientas de administración del rendimiento diseñan la
utilización de los enlaces de la red y envían advertencias si se
producen errores en alguna interfaz de LAN. Sin embargo, otras vigilan
la seguridad de la red y envían advertencias a través del correo
electrónico o de buscapersonas.
Las aplicaciones de administración de redes se comunican con el
software de los dispositivos de la red llamados agentes. La
comunicación entre el administrador y el agente permite el primero
recopilar un conjunto estándar de información, que se define en una
base de información de administración(Management Information Base,
MIB). Cada dato que hay en una MIB recibe el nombre de objeto. Una MIB
contiene objetos útiles para que los administradores realicen las
tareas de administración de red.


Los dos tipos de MIB son estándar y están patentados. Las MIB
estándar, como MIB-II (RFC 1213), proporcionan objetos básicos
aplicables a casi todos los dispositivos de una red de datos. Por
ejemplo, MIB-II contiene la información del sistema acerca de un
dispositivo, como su tiempo de actividad y nombre, los contadores de
errores y del trafico específico de la interfaz, y la información del
protocolo de IP. Las MIB específicas de la tecnología, que son
estándar son para protocolos como Frame Relay(RFC 1285) o Token
Ring(RFC 1315). Contienen objetos que se relacionan con una tecnolog ía
específica de un dispositivo de red. Las MIB específicas de los
fabricantes, que están patentadas, definen objetos específicos de los
dispositivos de red de un solo fabricante.
Las aplicaciones de administración de redes recogen la
información de la MIB de los dispositivos y cambian el comportamiento
de dichos dispositivos de red mediante el uso de un protocolo de
administración de redes. El Protocolo simple de gestión de
redes(Simple Network Management Protocol, SNMP), definido en la RFC
1157, es el protocolo estándar de administración de redes más
profusamente utilizado. SNMP usa UDP en la capa de transporte e IP en
la capa de red. También existen protocolos patentados de
administración de redes y algunos fabricantes los han implementado en
sus dispositivos de red.
La comunicación entre un agente SNMP y un administrador se
produce con cinco tipos de paquetes:
Get-Request.
Get-Next-Request.
Set-Request.
Get-Reponse.
Trap.
Un Get-Request es un mensaje del administrador a un agente en el
que se solicita un conjunto de objetos de MIB especificos, como el
nombre de un dispositivo, su ubicación, su número de interfaces
físicas, etc.
Un Get-Next-Request es un mensaje del administrador a un agente
en el que se solicita algún dato tabular. Este tipo de mensajes es
útil en la eliminación de las tablas de la MIB y en la recuperación de
una tabla como la tabla de enrutamiento IP. Un Set-Request es un
mensaje en el que se solicita al agente que cambie el valor de un
objeto de MIB específico, como, por ejemplo, que cambie el estado de
una interfaaz de un dispositivo. Los agentes responden a cada Get-
Requet, Get-Next-Request o Set_Request enviando al administrador un
Get-Response que contenga los valores solicitados de los objetos de
MIB o que muestre el valor de un objeto de MIB que se ha cambiado. Un
mensaje Trap es un mensaje no solicitado del agente al administrador
relativo a un evento.
Todos los agentes SNMP se configuran con una cadena de
verificación llamada cadena de comunidad. Esta cadena se incluye en
todas las solicitudes del administrador para obtener o definir la
información de MIB. El agente la verifica antes de responder. Una
cadena de comunidad tiene una autenticación débil codificada en ASCII,
por lo que no es conveniente utilizar solamente este método para
asegurar el acceso SNMP a un agente.
El comando de configuración global de Cisco IOS snmp-server
community configura el agente con la cadena de comunidad. Una opción
de este comando permite estipular que la cadena de comunidad se puede
aplicar a los mensajes de sólo lectura-escritura dirigidos al agente.
Los mensajes Get-Request y Get-Next-Request son de sólo lectura,
mientras que los Set-Request son de lectura y escritura. Las palabras
clave utilizadas para establecer sólo lectura y escritura son RO y RW,
respectivamente. La cadena de comunidad de sólo lectura
predeterminada para muchas aplicaciones de administración de redes es
public, mientras que la de lectura y escritura suele ser private. Una
opción final de este comando global es especificar una lista de acceso
IP estándar de aquellos host a los que se les permite realizar
consultas al agente utilizando cadenas de comunidad válidas.

Nota_
Para aumentar la seguridad del agente SNMP en cualquier
dispositivo con IOS, es aconsejable configurar varias cadenas de
comunidad para el acceso RO y RW. Además, es recomendable limitar los
host que pueden realizar consultas al dispositivo con IOS a trav és de
SNMP mediante el uso de la opción access-list del comando snmp-server
community.
Para enviar mensajes Trap SNMP, hay que configurar el
dispositivo con Cisco IOS. Los seis mensajes Trap SNMP estándar que
envían todos los agentes se definen en la RFC 1157:
ColtStart.
WarmStart.
LinkUp.
LinkDown.
AuthenticationFailure.
EgpNeighborLoss.
Un coldStart significa que el agente acaba de iniciarse. La trap
warmStart indica que el propio software del agente se acaba de
restablecer. En la practica, la mayor parte de los agentes s ólo envían
Traps coldStart, ya que el agente se suele reiniciar cuando se
enciende el dispositivo en el que el agente se está ejecutando. Las
Traps linkUp y linkDown alertan a un administrador acerca del cambio
de estado de algún enlace del dispositivo. Un authenticationFailure
indica que un administrador ha enviado al agente una solicitud SNMP
con una cadena de comunidad incorrecta. Finalmente, la Trap
egpNeighborLoss indica al administrador que no se puede acceder a un
vecino con el protocolo External Gateway Protocol (EGP). Este ultimo
Trap casi nunca se utiliza, ya que EGP se ha reemplazado por BGP4.
Los seis anteriores mensajes trap son los Traps SNMP estándar,
pero no son los únicos que pueden evitar los agente. Muchas MIB
definen Traps especificos de los protocolos, como traps espec íficos de
RDSI(ISDN), Frame Relay o BGP$. Actualmente IOS admite los traps para
una variedad de protocolos y para funciones de IOS, entre los que se
incluyen BGP, Frame Relay, RDSI, X.25, monitor de entorno y cambios en
la configuración de IOS.
Cisco IOS puede configurarse para enviar Traps SNMP a cualquier
número de administradores. Para especificar la dirección IP y la
cadena de comuidad del administrador al que debe enviarse las Traps,
hay que utilizar el comando snmp-server host. Los parámetros
opcionales del comando snmp-server host tambien sirven para
especificar que queremos que el agente envíe Traps SNMP.

Sugerencia_
Es conveniente configurar el agente SNMP para que envíe Traps
relativos a todas las tecnologías que están activas en el dispositivo.
Los mensajes Traps SNMP no suelen consumir mucho ancho de banda y
pueden proporcionar información útil para diagnosticar problemas de
red.
Es posible configurar manualmente el agente SNMP en IOS con la
ubicación física y la persona de contacto del dispositivo. A
continuación, las aplicaciones de administración de red pueden
recuperar esta información. Para configurar esta información hay que
utilizar los comandos de configuración global snmp-server loction y
snmp-server contact. Ambos comandos permiten escribir una cadena de
texto de 255 caracteres para describir la ubicación o la persona de
contacto.
El comando ejecutable show snmp muestra las estadísticas SNMP de
un dispositivo dado.
Este comando es útil para ayudarle a supervisar la actividad de
SNMP en el dispositivo.

CONTROL DE TIEMPO BÁSICO
Cisco IOS permite a los dispositivos hacer un seguimiento de la
fecha y hora actuales utilizando un reloj del sistema. Este reloj se
inicia cuando enciende el dispositivo y puede distribuir el tiempo a
varios sistemas internos, como la grabación de la fecha y hora de los
cambios en la configuración, la visualización del tiempo en los
mensajes de registro en el búfer y el envío de la fecha y la hora en
los mensajes de SNMP. En los router Cisco 7000, el tiempo del reloj
del sistema se define a través de hardware. En los restantes modelos,
el reloj del sistema se define de forma predeterminada con el valor de
medianoche del 1 de marzo de 1993.
Una vez definido, el reloj del sistema determina si la fecha y
la hora son de un origen fiable. Si el origen de la hora es fiable, se
redistribuye a otros procesos IOS; en caso contrario, la hora solo se
utiliza para la visualización. En las próximas secciones se explicara
como asegurarse de que el origen de la hora definida, como un reloj
atómico, es un origen fiable.
Los routers de la serie 7000 contienen un calendario que hace un
seguimiento de la fecha y la hora en los recintos del sistema y los
cortes eléctricos. En un recinto del sistema, el calendario siempre se
utiliza inicialmente para definir el reloj del sistema. A continuaci ón
es posible que otro protocolo modifique o actualice el reloj. En una
red en la que no exista ningún otro origen de hora con autoridad, se
puede utilizar el calendario como origen de hora con autoridad y puede
pasarse a otros procesos(como el protocolo Network Time Protocol).
Para ver el valor actual del sistema del calendario se utiliza el
comando ejecutable show calendar.

Nota_
Si desea que algún dispositivo con IOS indique la fecha y hora
actual en los mensajes de depuración y de registro, utilice el comando
de configuración global service timestamps. Puede mostrar el tiempo
que ha transcurrido desde que se reinició el dispositvo, la fecha y
hora utilizando GMT o la zona hararia local y la hora con una
precisión que llega hasta los milisegundos. Es recomendable utilizar
los comandos de configuración service timestamps log datetime
localtime y service timestamps debug datatime localtime. El comando
service timestamps log datetime localtime añade la fecha y hora a los
mensajes de registro, mientras que service timestamps debug datatime
localtime las añade a los de depuración.
Para fijar el reloj del sistema puede utilizar varias fuentes.
Éstas son las tres más utilizadas:
Manualmente.
NTP.
SNMP.

No hay comentarios: