Windows Server Networking

Solucionando errores TCP/IP. 6

juansa — Tue, 07 Oct 2008 11:35:08 GMT

Usemos Tracert y Pathping

Si la tabla de rutas es correcta, el problema puede halarse en algún enrutador o enlace en cualquier punto a lo largo de la ruta. Podemos rastrear la ruta hacia el destino con Tracert y Pathping para señalar el problema.

A menos que haya una sola ruta hacia el equipo destino, asegurarse de usar estas herramientas para trazar la ruta más de una vez, especialmente si notamos pérdidas intermitentes de paquetes. El datagrama puede enviarse por distintos caminos, y un enrutador defectuoso puede ser el problema.

Cuando no tenemos conectividad con un lugar concreto usaremos Tracert, ya que nos dice en qué lugar se detiene la comunicación. Pathping es más útil cuando sí hay conectividad a un lugar, pero se pierden paquetes o la espera es alta. En estos casos, pathping nos dice exactamente donde se están perdiendo los paquetes.

Comprobar los servicios de servidor en el equipo remoto

Algunas veces un sistema configurado como puerta de enlace remota o enrutador no está funcionando como debería. Para poder confirmar que el equipo remoto está reenviando los paquetes debemos usar alguna herramienta de administración remota (siempre que seamos administradores de dicha máquina) o contactar con el responsable y que lo compruebe.

Hay una serie de bases de datos en InterNIC que nos servirán en algunos casos para saber quien es el responsable. También nos puede servir la herramienta Whois desde : ARIN, AFRINIC, APNIC, LACNIC, RIPE, INTERNIC u otros.

Comprobar IPSec

IPSec puede incrementar la seguridad de una red, pero también cambia la configuración y hace más difícil resolver un problema. En algunos casos, IPSec se ejecuta donde tenemos al equipo problemático y ello puede crearle dificultades para conectar con otro equipo. Para ver si este es el origen del problema, temporalmente deshabilitaremos IPSec con el comando net stop policyagent, comprobando si el servicio o funcionalidad de red se ejecutan con normalidad.

Si el problema desaparece con IPSec detenido, puede que sea por su filtrado de paquetes, entonces es el responsable del problema. Volveremos a iniciar el servicio con net start policyagent y seguiremos el siguiente procedimiento:

netdiag /test:ipsec /debug > archivo.txt

Con lo que veremos los filtros activos.

Para asignar o desasignar una directiva IPSec para directivas Active Directory

Abrimos el complemento de Usuarios y equipos de AD: Inicio, herramientas administrativas, doble clic en el complemento.

En el árbol de la consola, expandimos el controlador de dominio, el dominio, y la OU u OU hija al que queremos aplicar la directiva.

Clic en propiedades y luego en la pestaña directiva de grupo.

Clic en Editar para abrir la directiva, o Nueva para crear una nueva y luego editarla.

En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Active Directory (dominio)

En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

Para asignarla, en el menú Acción, clic en asignar.

Para desasignarla, en el menú Acción, clic en desasignar

Para asignar o desasignar una directiva IPSec para directivas de equipo local

Inicio, Ejecutar, escribimos MMC y pulsamos ENTER.

Clic en File, Add/Remove Snap-in, OK.

Clic en Editor de objetos de directivas de grupo, Add.

Finalizar, Cerrar, Aceptar.

En el árbol de la consola de directiva, expandimos la directiva para el equipo, Configuración de equipo, Configuración de Windows, Configuración de seguridad y clic en Directivas de seguridad IP en Equipo Local

En el panel detalles, clic en la directiva IPSec que queremos asignar o negar, y hacemos una de dos:

Para asignarla, en el menú Acción, clic en asignar.

Para desasignarla, en el menú Acción, clic en desasignar

IMPORTANTE: Una directiva IPSec puede permanecer activa incluso después de que la directiva IPSec o el objeto de Directiva de Grupo a la que se asignó ha sido borrada. Por lo tanto, debemos desasignar la directiva IPSec antes de eliminar la directiva o el objeto de directiva de grupo. En evitación de problemas, deasignamos la directiva IPSec en el objeto de Directiva de Grupo. Esperamos 24 horas para asegurarnos que el cambio se ha propagado, y entonces podemos eliminar la directiva o el objeto de directiva de grupo.

Comprobar el filtrado de paquetes

Cualquier error en el filtrado de paquetes en TCP/IP, enrutador, servidor proxy, Enrutamiento y acceso remoto, o a nivel de IPSec pueden provocar errores de resolución o de conectividad. Para averiguar si el origen del problema de red es el filtrado de paquetes, podemos deshabilitarlo.

Panel de control, conexiones de red.

Clic derecho en la conexión, seleccionamos propiedades.

Seleccionamos Protocolo Internet (TCP/IP) y pulsamos en la pestaña propiedades.

Clic en Avanzadas, y clic en la pestaña Opciones.

Bajo Configuración opcional, clic en Filtrado TCP/IP y luego en el botón propiedades.

Desmarcar la casilla de verificación Habilitar filtrado TCP/IP (en todos los adaptadores) y pulsar en Aceptar.

Intentar pings a una dirección mediante su nombre DNS, su nombre NetBIOS o su IP. Si el intento tiene éxito, las opciones del filtrado de paquetes puede estar configurada incorrectamente o ser demasiado restrictivas. Puede que esté permitiendo al equipo actuar como web server pero, en el proceso, estar deshabilitadas herramientas como el ping o administración remota. Restaurar el rango de filtrado permisivo, cambiando los puertos permitidos TCP, UDP e IP.

Si el intento falla, otra tipo de filtrado puede estar interfiriendo en la red.

Solucionando errores TCP/IP. 5

juansa — Mon, 06 Oct 2008 13:31:01 GMT

Comprobando la resolución de IP a MAC con ARP

TCP/IP en Windows Server 2003 permite a las aplicaciones comunicarse en red con otros equipos mediante la IP, nombre de host o nombre NetBIOS. Sin embargo, a pesar de utilizarse una convención de nombres, la dirección de próximo salto para el destino debe al final resolverse a una dirección hardware -conocida como media access control, o sea la MAC address- para el acceso compartido a los medios como ethernet o token ring.

ARP permite a un equipo encontrar la dirección MAC del próximo salto de IP en la misma red física. Para un ARP eficiente, cada equipo guarda en su caché la dirección IP-a-MAC para eliminar solicitudes broadcast de ARP repetitivas.

La utilidad ARP permite al usuario ver y modificar las entradas de la tabla ARP en el equipo local. El comando arp es útil para ver la caché ARP y resolver problemas de resolución de direcciones.

Una entrada estática puede añadirse a un archivo ARP con arp -s dirección_IP dirección_MAC. Sin embargo, hay que tener cuidado cuando añadimos entradas estáticas ya que es fácil de equivocarse. (Que se lo digan al envenenamiento de ARP, :-))). Cuando se reinicia un equipo, todas las entradas estáticas son eliminadas.

Detección de direcciones IP duplicadas con ARP

Cuando iniciamos, Windows realiza un ARP de regalo para detectar cualquier duplicación de su propia IP. Consiste en una solicitud ARP para la IP propia del nodo, o sea para sí mismo. Si un equipo envía una solicitud ARP para sí mismo y no hay respuesta, el equipo determina que nadie está usando dicha IP. Aunque esto detecta en la mayoría de casos IPs duplicadas, en muy pocas situaciones dos equipos (sean MS o no MS) pueden estar configurados con la misma IP en la misma red.

La relación entre las direcciones MAC e IP se realiza por el módulo ARP, que utiliza la primera respuesta ARP que recibe. Por lo tanto, la respuesta desde un equipo impostor puede algunas veces enmascarar la respuesta del equipo previsto.

Usaremos arp -a para mostrar por la pantalla la relaciones MAC-IP de la caché de ARP. Si sabemos la MAC de un equipo remoto que deseamos usar, podemos determinar fácilmente si ambas coinciden. Si no lo hacen, usaremos arp -d para eliminar la entrada, realizaremos un ping a la dirección (forzar un ARP), y entonces comprobamos la MAC en la caché de nuevo con arp -a.

Sí ambos equipos están en la misma red, recibiremos eventualmente una respuesta desde el equipo impostor. Si no, podemos tener que capturar el tráfico desde el equipo impostor con Network monitor (descarga) para determinar el propietario o ubicación del sistema.

Detección entradas inválidas en la caché de ARP

La resolución de problemas de la caché de ARP puede ser una de las tareas de mayor dificultad en la administración de redes ya que los problemas asociados con ello son frecuentemente intermitentes. La excepción a esta regla es cuando nos encontramos que el equipo con problemas responde a una solicitud ARP, creando una entrada inválida en la caché de ARP. Los síntomas de las entradas inválidas en la caché de ARP son difíciles de reproducir y se componen de problemas intermitentes que afectan solamente a un grupo pequeño de equipos. El problema subyacente es que dos equipos están usando la misma IP en la red. Vemos los problemas de forma intermitente ya que la mayoría de entradas de la tabla ARP recientes son siempre del primero de los equipos que responda más rápidamente a una solicitud ARP particular.

Ejemplo de salida del comando arp -a:

Ya que las IP asignadas por DHCP no causan los conflictos definidos aquí(Aconsejo DHCP en cuanto el número de equipos sea grande), el principal origen de los mismos suelen ser las direcciones IP estáticas. El mantener una lista de las direcciones IP estáticas (y sus correspondientes MAC) y como se han asignado nos servirán de ayuda para cualquier seguimiento de conflicto y su comparación con los pares de la tabla de ARP.

Si no tenemos un registro de todos los pares IP y MAC de nuestra red, podemos examinar los bytes del vendedor de la MAC en busca de inconsistencias. Los primeros tres bytes de cada MAC identifican al vendedor/fabricante de la tarjeta. Estos tres bytes se llaman OUI y están asignados por la IEEE. Conociendo el equipamiento instalado y comparando lo con los valores devueltos por un arp -a puede permitirnos determinar cuales direcciones estáticas se han introducido erronéamente.

Comprobar las rutas persistentes de la tabla de rutas

Lo siguiente a examinar son las entradas persistentes en las tablas de rutas. Podemos verlas mediante el comando route. Las entradas persistentes se agregan mediante el comando y parámetros route add -p o desde el servicio de enrutamiento y acceso remoto. Las entradas incorrectas pueden cambiarse mediante route change. Con enrutamiento y acceso remoto agregamos una ruta estática:

Abrimos Enrutamiento y acceso remoto
En el árbol de la consola, extendemos enrutamiento IP y clic derecho en rutas estáticas.
Clic Nueva ruta estática.
En el cuadro de diálogo de Ruta estática, introducimos el interfaz, destino, máscara de red. puerta de enlace y métrica. Si fuera una interfaz de llamada por demanda, el campo de puerta de enlace no está disponible.

Solucionando errores TCP/IP. 4

juansa — Sun, 05 Oct 2008 19:57:38 GMT

Vaciar la caché ARP

Entradas incorrectas en la caché de ARP pueden impedir la conectividad a equipos locales y remotos (si la entrada correspondiente a la puerta de enlace es incorrecta). Para ver el contenido de la caché podemos usar los comandos:

arp -a o arp -g

Los resultados que se obtienen con estos parámetros del comando pueden enviarse hacia un archivo de texto o doc si tenemos word instalado, con la sintaxis de redirección.

arp -a > ruta_del archivo (la extensión debe ser txt o doc)

Antes de cualquier cambio en la caché es conveniente volcar su contenido a un archivos y mantenerlo para su revisión si fuese necesario.

El vaciado de la caché la realizamos con:

arp -d *

Comprobar la puerta de enlace predeterminada

Hay que comprobar la puerta de enlace predeterminada. La dirección IP de la puerta de enlace debe estar en la misma sub-red de la dirección del equipo local, si no ese el caso, los paquetes no podrán reenviarse a ningún lugar fuera de la sub-red local. Así que comprobemoslo.

Ping a un equipo remoto

Si la puerta de enlace responden correctamente, hagamos un ping a un equipo remoto para asegurarnos de que la comunicación existe y es operativa con normalidad. Si esto falla, con Tracert examinemos la ruta hacia el destino. Para enrutadores IP que sean equipos ejecutando NT, 2000 o Windows Server 2003, podemos ver la tabla de rutas con route print o con enrutamiento y acceso remoto. En caso de otros enrutadores usaremos la herramienta que le corresponda para ver su tabla de enrutamiento.

Un ping nos devuelve cuatro mensajes de error durante la búsqueda del error.

TTL expiración en tránsito El número de saltos requerido para alcanzar el destino excede el TTL establecido por el equipo que envía, para el reenvío de paquetes. El valor predeterminado de TTL en el caso de mensajes Echo de ICMP es 128. Si esto no es suficiente para el número necesario de enlaces hasta el destino, podemos incrementarlo mediante ping -i, hasta un máximo de 255. Si al aumentarlo nos falla para resolver el problema, los paquetes comenzarán a ser reenvíados en un loop de enrutamiento, esto es, una ruta circular entre enrutadores. Usaremos Tracert para localizar el conjunto de enrutadores del loop, que aparece como una serie repetida de direcciones IP iguales en el informe del Tracert. Después, cambiemos de forma correcta las tablas de enrutamiento de los enrutadores del Loop, o avisemos al administrador del enrutador remoto para solucionar el problema.

Equipo destino inalcanzable Esto indica una de dos: O no hay ruta entre el equipo y el destino deseado, o un enrutador remoto informa que no hay ruta al destino. La forma del mensaje puede distinguirlos:

Si el mensaje es simple "Destination Host Unreachable" (equipo destino inalcanzable), no hay ruta desde el equipo local, y los paquetes a ser envíados nunca se pondrán en la red. Usaremos la herramienta route para comprobar la tabla de enrutamiento local para ver si la ruta al destino es equivocada o inexistente.
Si el mensaje es en cambio "Reply From IP Address: Destination Host unreachable" (Respuesta desde dirección_IP: equipo destino inalcanzable), el problema de enrutamiento se encuentra en un enrutador remoto, cuya dirección IP es la indicada en IP Address. Comprobaremos la tabla de rutas del enrutador remoto correspondiente o avisaremos para ello.

Si hacemos un ping a una dirección IP, hagámoslo también al nombre de host y asegúremonos que la IP es la correcta.

Tiempo de espera agotado para esta solicitud Este mensaje indica que no se recibe respuesta dentro del tiempo predeterminado de cuatro segundos. Esto puede deberse a distintas causas; la más común es una congestión de la red, un fallo de ARP en la resolución del próximo salto de dirección MAC, filtrado de paquetes, error de enrutamiento o descarte por silencio. Frecuentemente significa que una ruta de retorno al equipo de envío ha fallado. Esto puede ser porque el equipo destino no conoce la ruta de regreso al de envío, uno de los enrutadores intermedios no tiene una ruta de regreso o incluso que la puerta de enlace del equipo destino no conoce la ruta de regreso. Antes de comprobar als tablas de rutas de los enrutadores, comprobar la tabla de rutas del equipo destino para ver si tiene una ruta para llevar al equipo de envío.

Si las tablas de rutas remotas son correctas y contienen rutas válidas de retorno para el equipo de envío, mirar si la caché ARP carece de la dirección procedente con arp -a. Tambié, comprobar la máscara de subred para estar seguro que la dirección remota no se interpreta como local.

Después usamos TRacert para determinar la ruta al destino. Aunque Tracert no grava la ruta que los mensajes de Echo siguen en su retorno, puede mostrar lo que el paquete hace en el destino. Si es este caso, el problema es probablemente un problema de enrutamiento de la ruta de retorno. Si la traza no consigue llegar al destino, puede deberse a que el equipo está detrás de un cortafuegos. Cuando hay un cortafuegos, el filtrado de paquetes ICMP impide a los ping -y cualesquiera otros mensajes ICMP- traspasarlo y por tanto alcanzar su destino.

Para comprobar la congestión de red, solamente necesitamos incrementar la latencia permitida aumentando el tiempo de espera, unos 5 milisegundos, mediante el comando ping -w. Probar el ping al destino otra vez. Si la solicitud excede el tiempo de respuesta, la congestión no es el problema.

Equipo desconocido Este mensaje de error indica que el nombre de equipo solicitado no puede resolverse a una dirección IP; comprobar si el nombre es correcto y si los DNS pueden resolverlo.

Solucionando errores TCP/IP. 3

juansa — Wed, 01 Oct 2008 13:38:37 GMT

Comprobación de la conectividad con Ping y Pathping

Ping nos ayuda a verificar la conectividad a nivel de IP y Pathping detecta paquetes perdidos en intentos de múltiples saltos. El comando ping lanza una serie de mensajes echo de ICMP a un destino: nombre de host o dirección IP. Con ping verificamos que un equipo puede enviar paquetes IP a un destino, así como aislar problemas de hard o configuraciones incorrectas.

Si el comando ipconfig /all nos muestra la dirección IP adecuada no necesitamos hacer un ping a la dirección de loopback (127.0.0.1) o la dirección IP.

Para verificar que una ruta existe entre el equipo y un equipo de la red:

ping dirección_IP

Comprobamos que TCP/IP está instalado y configurado correctamente en el equipo:

ping 127.0.0.1

Comprobamos que el equipo se añadió correctamente a la red (si la tabla de rutas es correcta, esto solamente reenvía el paquete a 127.0.0.1)

ping dirección_IP_equipo_local

Comprobamos que la puerta de enlace predeterminada funciona y podemos comunicarnos con un host dentro de nuestra red:

ping dirección_IP_puerta_de_enlace

Comprobación de la ruta a un host remoto pasando por un enrutador:

ping dirección_IP_host_remoto

Comprobamos la resolución de nombre del host remoto:

ping nombre_equipo_remoto

Comprobamos que los enrutadores de la ruta al destino funcionan correctamente:

pathping dirección_IP_host_remoto

Notas:

Sí la dirección IP local devuelta en cualquier comando es 169.254.y.z, significa que se ha asignado mediante APIPA (Automatic Private IP Adressing), una característica de Windows Server 2003. Lo cual nos indica que no hay servidor DHCP activo o que es inalcanzable por el equipo.
Si la IP es 0.0.0.0, se ha detectado que el adaptador de red no está conectado a una red. Comprobar el cable y que el concentrador/conmutador (hub/switch) funciona. Podría también ser un mal funcionamiento de controladores e incluso de la propia tarjeta de red.

Ping utiliza resolución de host name para resolver el nombre de un euipo a una IP, así que si el ping a la IP se realiza con éxito y al nombre del equipo falla, el problema reside en la resolución de nombres y no en la conectividad de la red.

Si por cualquier motivo no logramos pings con éxito comprobaremos:

Que el equipo dispone de una dirección IP válida y que se muestra correctamente en la pestaña General de las propiedades del protocolo TCP/IP de la conexión de red y también en la pestaña Soporte del Estado de la conexión de red (clic derecho conexión de red, Estado). Por supuesto si usamos ipconfig o netdiag también se nos muestra.
La puerta de enlace está configurada y el enlace entre ambos funciona adecuadamente. Windows Server 2003 dispone de lo que se llama Dead Gateway Detection que en caso de múltiples puertas de enlace configuradas, intentará enviar paquetes mediante la puerta de enlace predeterminada un número de veces sin recibir respuesta, esta característica hará que se cambie la dirección de próximo salto de esa conexión TCP a la siguiente puerta de enlace de la lista.

Solucionando errores TCP/IP. 2

juansa — Mon, 29 Sep 2008 10:16:21 GMT

Próximo salto

Todos los equipos que utilizan cualquier versión de Windows y el protocolo TCP/IP usan una Tabla de enrutamiento IP. Esta tabla se usa para determinar el siguiente salto de interfaz y dirección IP. La tabla de enrutamiento almacena la información referente a destinos y como alcanzarlos. Hay una serie de entradas predeterminadas y dependientes de la propia configuración del equipo. Nosotros podemos agregar entradas desde la línea de comandos, o pueden añadirse dinámicamente al interactuar con enrutadores.

Cuando un paquete IP es reenviado, se usa la tabla para determinar:

Salto siguiente a dirección IP. Para una entrega directa (en el que el destino es un nodo adyacente), el siguiente salto IP es la IP destino en el paquete. Para una entrega indirecta (el destino no es adyacente), el siguiente salto IP es la IP de un enrutador.
Salto siguiente a interfaz. Aquí se identifica a qué interfaz, física (tardeta de red) o lógica se usará para el reenvío del paquete.

Antes de la determinación del siguiente salto, se usa ARP. En tecnologías LAN como ethernet y Token Ring, ARP intentará resolver la dirección MAC para el siguiente salto y reenviará el paquete usando la interfaz identificada como salto siguiente.

Contenido de la tabla de enrutamiento

Los campos más típicos de una tabla de enrutamiento en Windows Server 2003:

Destino de red. Una IP o un ID de red.
Máscara de red. La máscara utilizada para coincidencia de una dirección destino y la IP del campo destino de red.
Puerta de enlace(siguiente salto). IP donde se reenviará el paquete.
Interfaz. Interfaz de red a usar para el reenvío del paquete.
Métrica. Indica el costo de la ruta para la elección de la mejor entre múltiples rutas. Su uso más normal es indicar el número de saltos (enlaces o enrutadores a cruzar) en la ruta a su destino.
Rutas persistentes. Si se han configurado rutas agregadas.

Las entradas de la tabla pueden ser:

Rutas de red directas. Rutas para subredes a las que el nodo está directamente unido. Para éstas, el campo de puerta de enlace puede estar en blanco o contener la IP de la interfaz de subred. Si la dirección es local, la entrega requiere un pequeño esfuerzo adicional. ARP resuelve la IP a una dirección MAC de la tarjeta destino. Aquí los problemas suelen estar relacionados con ARP o la máscara de red, usando comandos ARP o Ipconfig podemos solucionarlos.
Rutas de red remotas. Rutas accesibles a través de enrutadores y que no están unidas directamente al nodo. El campo de puerta de enlace es la IP de un enrutador local. Cuando la dirección es remota, se determina que puerta de enlace se usará para alcanzarla. En una red con sólo un enrutador determinarlo es sencillo. Pero, en una red con más de un enrutador, determinar la puerta de enlace a usar puede complicarse.

IP lo soluciona consultando la tabla de enrutamiento. Sirve como un árbol de decisión que ayuda a IP a decidir qué interfaz y puerta de enlace debe utilizarse para el envío del tráfico saliente. La tabla contiene diversas rutas individuales y cada una de ellas consiste en un destino, máscara de red, puerta de enlace y métrica.

La tabla se analiza de lo más específico a lo más general, enviándose el paquete por la primera puerta de enlace que coincida con el destino del paquete. Si hay dos rutas iguales, se elegirá la que tiene la métrica más baja. En caso de estar ocupada, el nodo seleccionará arbitrariamente la entrada a usar.

Rutas de host. Ruta a una IP específica. Estas rutas permiten el enrutado entre IPs. La ID de red es una IP específica y la máscara de red 255.255.255.255.
Ruta predeterminada. Ruta a usar cuando no se encuentran o una red más específica o una ruta de host. De manera predeterminada es 0.0.0.0 y máscara de red 0.0.0.0. La puerta de enlace es la predeterminada en el nodo.

Para la determinación de que entrada a usar, IP realiza una operación lógica AND entre la IP de destino y el campo de máscara de red de cada entrada. El resultado se compara con el campo Destino de red de la entrada coincidente.

La lista de rutas coincidentes se compila. y se selecciona la que tiene mayor número de bits establecido a 1 en la máscara. Esta ruta será la más específica a la IP de destino. Si hay más de una ruta, el enrutador utiliza la de métrica más baja para seleccionar la mejor ruta. Si hay varias con la misma métrica baja, se elige arbitrariamente la entrada a usar.

El resultado del proceso es la selección de una ruta única de la tabla de enrutameinto. Si el proceso falla, hay un error de enrutado. El error se indica como TCP o UDP si el envío es a un host y en el caso de un enrutador 'Destino o host inalcanzable' y el paquete se descarta.

En cuanto se ha determinado la ruta, se procede a identificar la interfaz e IP de próximo salto:

Si la dirección del campo Puerta de enlace está en blanco o tiene una IP asignada a una interfaz en el nodo de reenvío:
- La dirección de próximo salto se establece como destino en el paquete IP.
- La interfaz de próximo salto se establece a la interfaz que está especificada en el campo interfaz.
Si la dirección del campo puerta de enlace no está asignada a una interfaz en el nodo de reenvío:
- la dirección de próximo salto se establece a la IP del campo puerta de enlace para la ruta.
- La interfaz de próximo salto se establece a la interfaz que está especificada en el campo interfaz.

Con los comandos route print o netstat -r obtenemos una salida similar a:

En este ejemplo hallamos:

Primera entrada: Destino y máscara 0.0.0.0/0, es la ruta predeterminada. Cualquier destino al que se le haga la operación AND con esta ruta da como resultado 0.0.0.0. por lo tanto la ruta predeterminada coincide con cualquier destino. Si ésta es la elegida la dirección de próximo salto le corresponde a 192.168.0.1 y la interfaz de próximo salto 192.168.0.225 que es el adaptador de red.
Segunda entrada: 127.0.0.0/8, que es la ruta de red loopback. Todos los paquetes envíados a una dirección 127.x.y.z tienen un próximo salto a 127.0.0.1 y la interfaz es la misma 127.0.0.1.
Tercera entrada: 192.168.0.0/24, es la ruta de red. Si ésta es la elegida la ip de próximo salto y la interfaz son 192.168.0.225.
Cuarta entrada: 192.168.0.255/32, ruta de host a la IP del host, todos los paquetes envíados a dicha IP tienen como próximo salto e interfaz la IP 127.0.0.1.
Quinta entrada: 192.168.0.255/32, ruta de host IP broadcast para la clase C 192.168.0.0/24.
Sexta entrada: 224.0.0.0/3, ruta de tráfico multicast envíada por este host. Todos los paquetes multicast tienen como próximo salto e interfaz la ip 192.168.0.255.
Séptima entrada: 255.255.255.255/32 ruta de host IP limitada de broadcast.

Houston we have a problem!

Introducción

Vamos a intentar explicar unas nociones para identificar los problemas de la comunicación TCP/IP y dar algunos pasos que podemos llevar a cabo para corregirlos.

Generalmente seguiremos un patrón:

Comprobar que la interfaz que está dando problemas no esté desconectada.
Comprobar que la configuración TCP/IP es adecuada y correcta.
Comprobar que existe un camino de enrutamiento entre el equipo y su destino.
Si la confianza con el enlace es dudosa, podemos utilizar el comando pathping en distintas ocasiones del día y registrar el ratio de éxito.

Si estos simples pasos no nos sirven de solución, podemos usar un analizador de protocolo de red, como Microsoft Network Monitor, y capturar el tráfico de red.

Cuando tenemos un problema deberíamos preguntarnos:

¿Otros equipos en la misma red pueden alcanzar el recurso?
¿Qué aplicaciones están fallando, cuáles funcionan y hay relación entre ellas? ¿Algún patrón deducido?
¿Es un problema de conectividad o de resolución de nombres? Y sí es lo segundo ¿Qué resolución usa la aplicación que falla, NetBIOS o Host names?
La aplicación que falla, ¿Había estado funcionando correctamente hasta el error?
¿Hemos hecho cambios en el equipo o en la red entre el funcionamiento correcto y la aparición del error?

Podemos usar la característica de reparación después de haber comprobado que el adaptador no está desconectado, ello hará que se refresque la configuración de red del adaptador. Esta reparación realiza lo siguiente:

	Acción	Similar a:
1	Comprueba si DHCP está habilitado y si lo ésta, emite una renovación broadcast para refrescar la IP.	Ipconfig /renew *
2	Limpia la caché ARP	arp -d
3	Limpia la caché NetBIOS	nbtstat -R
4	Limpia la caché de cliente DNS	ipconfig /flushdns
5	Registra de nuevo con WINS	nbstat -RR
6	Registra de nuevo con DNS	ipconfig /registerdns

* Una renovación de broadcast hace que un equipo acepte cualquier concesión de cualquier servidor DHCP disponible. Por contra, un ipconfig /renew (renovación unicast) renueva sólo la concesión existente del último servidor DHCP desde el que el cliente aceptó la concesión. El primer caso es preferible en las ocasiones en que existe un problema con el servidor DHCP del que se aceptó la concesión.

Si aún así seguimos con el problema, comprobaremos la configuración de la red y del dispositivo de red, desde la configuración de Estado de la conexión de res, o utilizando las herramientas de línea de comando como Netdiag.exe o Ipconfig. Las tres tienen información redundante y diferencias al mismo tiempo entre ellas mismas.

Para comprobar el estado:

Clic derecho sobre la conexión de red y pulsamos en Estado.

Las ventajas en este caso son: monitorizar en tiempo real la actividad de la red y ver fácilmente las propiedades de la conexión pulsando en propiedades, pudiendo cambiar y revisar cliente, servicios o protocolos.

Por contra, no tenemos acceso a una conexión que esté desconectada, los detalles son limitados, sólo una conexión a la vez, datos de ipv4 y no los de ipv6 y no podemos redirigir la info a la impresora.

Si usamos IPconfig /all, obtenemos un informe de configuración detallada para todas las interfaces. La salida puede ser redirigida a un archivo de texto o de word, al estilo,

ipconfig /all > C:\Mis documentos\ipconfig.txt

Con una salida similar a:

Las ventajas de ipconfig son: una información de equipos multi tarjeta en una única operación, podemos redirigir los resultados y obtener copia impresa, muestra tanto ipv4 como ipv6 y además con más información que usando Estado.

La desventaja es que no puede usarse para mostrar información de un equipo remoto.

Y con Netdiag.exe aislamos los problemas de conectividad y de red, realizando tests más extensos que con ipconfig. Estos tests y la información que nos facilitan nos ayudará a identificar y aislar los problemas de red. Y como no requiere parámetros u opciones a especificar sólo hemos de ocuparnos de analizar la salida más que de entrenar a los usuarios a usarla.

Podemos instalarla desde las Support tools.

Para ejecutarla desde la línea de comandos debemos indicar la ruta donde está netdiag.exe, por ejemplo, C:\Tools\Netdiag.exe.

La salida la podemos redirigir a una carpeta y guardarla en un archivo de texto.

La salida nos proporciona una lista detallada de información de configuración y de los tests llevados a cabo.

Las ventajas de netdiag son: información proporcionada de equipos multitarjeta en una operación única, que puede ser redirigida y guardada en un archivo, muestra ipv4 e ipv6 y la variedad de tests hacen que el informe sea de un diagnóstico detallado.

Si siguen los problemas, usaremos los comandos ping y pathping para comprobar la capacidad del equipo para conectarse a otro host mediante TCP/IP.

Dmdiag

juansa — Sun, 21 Sep 2008 07:30:26 GMT

Dmdiag (dmdiag.exe) o Disk Manager Diagnostics, es una herramienta de línea de comandos que proporciona información sobre discos y volúmenes dinámicos (MBR y GPT), esta información nos sería útil, en su caso, para facilitarla a la Asistencia técnica de Microsoft o para utilizarla nosotros mismos si sabemos cómo.

Dmdiag es parte de las Windows Support Tools y su sintaxis es bastante común:

dmdiag [-f nombre_archivo] [-v] [/?]

-f nombre_archivo : Especificamos el nombre del archivo donde volcará la información de salida, si no se especifica de forma predeterminada será dmdiag.txt en la misma carpeta/directorio donde ejecutemos la herramienta, y si no usamos el parámetro (-f) la salida será por pantalla.

-v : Activa verbose mode, esto añade información sobre los discos y volúmenes dinámicos, con ello logramos un informe más completo.

-/? : Nos muestra la ayuda sobre la herramienta.

Solucionando errores TCP/IP. 1

juansa — Sun, 21 Sep 2008 01:30:00 GMT

Sin entrar en demasiados detalles comentaré que MS re-escribió la pila de TCP/IP en los 90 para mejorar ciertos aspectos de la implementación del protocolo TCP/IP. En cada nueva generación de Windows, la implementación de dicha pila ha continuado evolucionando y incluyendo mejoras y servicios para aumentar el rendimiento la seguridad y la fiabilidad. La pila TCP/IP en Windows Server 2003 se vende como más autoajustable, escalable, fácil de administrar, rápida y más segura. Además de estar asociada a servicios instalados predeterminadamente y que no pueden desinstalarse desde el complemento de conexiones de red.

Como en versiones anteriores de Windows nos encontramos con cierta variedad de herramientas de diagnóstico y reparación incluídas en el propio SO, que en este caso han sido aumentadas.

Introducción al proceso TCP/IP

TCP/IP sigue una secuencia para el establecimiento de una comunicación en una red o entre redes dispersas. Antes del envío del primer paquete que establecerá la sesión de comunicación, el protocolo en el envío al host lleva a cabo cuatro pasos definidos:

Resuelve el nombre del host o nombre NetBIOS a una dirección IP.
Usando la IP destino y la tabla de rutas, determina la interfaz a usar en el siguiente salto de IP.
Para tráfico:
1. Unicast en tecnologías como ethernet, Token Ring y FDDI(Fiber Distributed Data Interface), el protocolo ARP (Address Resolution Protocol) resuelve el siguiente salto de dirección IP hacia una MAC address.
2. Multicast en ethernet y FDDI, la dirección IP multicast de destino es mapeada a la MAC address multicast correspondiente. En Token Ring se usa la dirección funcional 0xC0-00-00-04-00-00. Y en broadcast la MAC address se mapea a 0xFF-FF-FF-FF-FF-FF.
El datagrama IP es envíado a la dirección MAC, resuelta mediante ARP, al mapeo multicast o la dirección de broadcast.

La pila de TCP/IP siempre sigue el proceso descrito para determinar como llevar un paquete de un sitio a otro.

Resolución de un nombre a dirección IP

Si el destino está en formato nombre NetBIOS o nombre de Host es necesaria la resolución antes de que IP pueda enviar el primer paquete. IP sólo reconoce direcciones IP, la resolución de nombres de host o NetBIOS a una dirección IP, son realizadas, para cada uno, de distintas formas.

De nombre NetBIOS a una dirección IP

Estos nombres pueden ser directamente trasladados a una dirección IP mediante cuatro mecanismos: consultando la caché de nombre NetBIOS, consultando a un servidor WINS, por broadcasting o comprobando el archivo LMHOSTS.

Windows Server 2003 siempre comienza con la caché, en caso de fallo usará: un servidor WINS, series de broadcasts o el LMHOSTS. De las tres se usará primero dependerá en cada equipo de su tipo de nodo. De forma predeterminada el tipo de nodo es Híbrido o H-node, que comienza por el servidor WINS y seguirá con las series de broadcasts. Si ninguno de los métodos funciona, el cliente convierte el nombre NetBIOS en nombre de Host y lleva a cabo la resolución de Host-name.

En Windows Server 2003 el tipo de nodo predeterminado es B-node, convirtiéndose en H-node cuando se configuran con un servidor WINS.

Tipos de nodo

B-node (Broadcast)	Utiliza consultas de nombre NetBIOS por broadcast para registro y resolución de nombres. Tiene dos problemas serios: Broadcast molesta a todos los equipos en la red y además los enrutadores no reenvían broadcast, así que sólo funciona en redes locales.
P-node (Peer-peer)	Utiliza un servidor, como WINS. No hay broadcast, la consulta va directamente al WINS.
M-node (Mixed)	Es una combinación de los tipos B-node y P-node. De forma predeterminada actúa como B-node, si es incapaz de resolver el nombre de esta forma, entonces su consulta se realiza en modo P-node.
H-node (Hybrid)	Combinación de P-node y B-node. De forma predeterminada actúa como P-node, si es incapaz de resolver el nombre entonces pasa a modo B-node.

El comando nbstat -a nos servirá para comprobar la resolución de NetBIOS pura.

De nombre host o dominio a dirección IP

Los nombres de host pueden ser directamente resueltos mediante la caché de cliente DNS, la cual contiene sus entradas en el archivo HOSTS, o mediante un servidor DNS. Cualquier problema que aparece aquí suelen estar relacionados con una configuración errónea del servidor DNS, entradas del archivo HOST incorrectas (dirección IP errónea, múltiples IP para un mismo Host)

Los comandos Nslookup y Netdiag nos servirán para el diagnóstico y solución de problemas con la resolución de nombres de dominio o host.

Diskprobe

juansa — Wed, 30 Jul 2008 11:01:00 GMT

Diskprobe (Dskprobe.exe) es un editor de sector de Widows Server 2003 que permite a los administradores editar, guardar y copiar datos en un disco duro. Usándolo con precaución, podemos reemplazar el MBR, reparar la información de la Tabla de particiones o sectores de arranque corruptos y otros en volúmenes FAT16, FAT32 y NTFS. También podemos usarlo para realizar una copia de seguridad del MBR o sectores de arranque en archivos binarios por si las moscas. Sin un conocimiento a fondo de la herramienta es mejor usar otras herramientas, como la consola de recuperación, antes de usarla.

Hay que ser precavido si realizamos cambios en la estructura del disco duro. Diskprobe no comprueba los cambios a grabar y valores incorrectos podrían dejar inaccesible el disco o impedir arrancar al sistema. En caso d no poder corregir los cambios efectuados deberemos crear y volver a formatear todos los volúmenes del disco.

Con Diskprobe podemos cambiar los valores de bytes individuales de cualquier sector en un disco dinámico pero no podemos navegar por su estructura. Por tanto se recomienda sólo usar Diskprobe en discos básicos. Sin embargo, podemos usarlo para copiar y restaurar el sector de arranque y el MBR de discos dinámicos.

Diskprobe es parte de las Windows Support Tools.

Podemos usarlo para ver las GUID de: la cabecera de la tabla de particiones y de las entradas de los discos GPT de equipos Itanium.Sin embargo no hay que usarlo para realizar cambios en la estructura de los GPT, estas se auto-reparan a sí mismas y cualquier cambio podría estropear el disco.

El archivo dskprobe.chm incluído nos facilitará la información para su uso y limitaciones.

DiskPart

juansa — Mon, 28 Jul 2008 17:42:33 GMT

Diskpart (diskpart.exe) es una herramienta de administración de línea de comandos con una funcionalidad similar al complemento de Administrador de discos. Aunque siempre que sea posible está recomendado usar el complemento gráfico para administrar y solucionar problemas de discos y volúmenes. Sin embargo, diskpart proporciona un método para la resolución de problemas remotamente mediante el uso de Telnet, y para el uso en archivos de lotes que graban el estado del disco o detectan problemas en su configuración.

Algunos ejemplos:

Iniciarlo: Desde inicio, ejecutar, escribir CMD y pulsar enter. Después escribimos DISKPART y enter, entraremos en el prompt DISKPART>

Listar discos: Escribimos en el prompt el comando List disk

Ver los detalles de un disco: Escribimos Select disk número_del_disco y después detail disk

Lista de comandos posibles de DISKPART: Escribimos commands

Artículo de la knowledge base: Descripción de la utilidad Diskpart.exe

Desfragmentador de disco

juansa — Sun, 27 Jul 2008 11:51:21 GMT

El desfragmentador de disco es un complemento de la MMC que se usa para reducir el nivel de fragmentación de un disco/volumen. La fragmentación causa un aumento en las búsquedas del subsistema de disco, con lo que se enlentece el ratio de transferencia y se reduce el rendimiento del disco. La desfragmentación es necesaria rutinariamente (según el uso del disco) ya que las rutas de los archivos se almacenan en el disco.

La fragmentación se produce cuando:

Se crea un archivo y el volumen no dispone de un grupo contiguo de clústeres libres suficientemente grande para contener el archivo entero. Por tanto, el archivo se reparte en fragmentos en lugar de estar en clústeres contiguos.
Se edita un archivo y se queda pequeño para el sitio que ocupa en el disco y si no hay grupos contiguos de clústeres libres a los que ocupa, el archivo se fragmenta ocupando clústeres libres en cualquier parte del disco.

Aún cuando se ha dicho que FAT y NTFS se han diseñado para un almacenamiento rápido y eficiente al guardar archivos, el disco físico tarda más tiempo en leer y escribir archivos fragmentados que no fragmentados. Si los archivos de un disco están muy fragmentados el rendimiento se ve afectado, ya que el cabezal del disco debe moverse entre diferentes pistas del disco para localizar los clústeres del archivo.

Las herramientas de desfragmentación arreglan este problema moviendo las partes de los archivos a clústeres contiguos, reduciendo la fragmentación y así reducir los movimientos mecánicos necesarios para localizar los clústeres de un archivo y con ello mejorar el rendimiento propio del disco.

En Windows Server 2003 pueden usarse dos métodos de desfragmentación de FAT y NTFS:

El complemento de desfragmentador de disco, dfrg.msc
Desde la línea de comandos con Defrag.exe

Ambas herramientas reordenan archivos, carpetas, programas y espacio sin usar en el disco duro para optimizar el rendimiento. Estas herramientas han sido mejoradas en Windows Server 2003:

Desfragmentan volúmenes con cualquier tamaño de clúster.
Desfragmentan archivos menores de 16 clústeres.
Desfragmentan la MFT (Master File Table).

El tiempo necesario para una desfragmentación dependerá de distintos factores, como el tamaño del volumen, el numero y tamaño de los archivos del volumen, la fragmentación de estos y de lo ocupado que pueda encontrarse el sistema durante la desfragmentación.

Cuando vayamos a usar las herramientas de desfragmentación hemos de tener en cuenta:

Sólo podemos desfragmentar volúmenes locales y uno a la vez.
Se necesitan privilegios de administrador o miembro del grupo de desfragmentación de volúmenes.
No podemos usar la herramienta de línea de comandos mientras el complemento de desfragmentación de disco esté abierto.
No podemos desfragmentar volúmenes marcados como dañados por el sistema de archivos. Debemos ejecutar chkdsk antes de desragmentar.

Para obtener los mejores resultados con el uso de la desfragmentación:

Asegurarnos que tenemos al menos el 15% de espacio en disco libre cuando desfragmentemos un volumen.
No realizar copias de seguridad al mismo tiempo que la desfragmentación.

Errores de disco

juansa — Mon, 28 Apr 2008 11:24:34 GMT

Existen diversas vías por las que podemos prepararnos nosotros mismos y nuestros equipos para solucionar problemas y errores de disco antes de que ocurran. Quizás lo primero sea familiarizarnos con las herramientas de recuperación y resolución con que contamos. Usar redundancia de discos aminora el impacto de fallos de hardware. Realizar copias de seguridad asegura que los datos que se pierden son mínimos ante un fallo. Protección contra ataques maliciosos, usando anti-virus actualizados. O llevando a cabo un mantenimiento regular de los dispositivos de almacenamiento.

Deberíamos utilizar ASR para guardar la información de configuración importante de disco a un disquete del que rápidamente podamos recuperar el sistema ante un error de disco. También, como se ha comentado en diversas ocasiones, familiarizarnos con la Consola de recuperación (instalarla en los equipos), y tener siempre a mano un CD/DVD de Windows Server 2003 para iniciar la consola en el caso de que el disco sea inaccesible.

Ejecutar con regularidad el comando chkdsk -f -r para el arreglo de problemas de sistema de archivos debido a errores de hard, cortes de electricidad o por errores de software. Programar reinicios del servidor con Autochk programado para comprobación/resolución de problemas de inicio en los volúmenes de sistema. Revisar la información de salida que nos ofrecen los comandos utilizados para identificar problemas que ellos mismos no pueden arreglar.

El uso de redundancia en discos nos ofrece la posibilidad de poder seguir con el funcionamiento del servidor aunque falle un disco, y que podamos reemplazar el defectuoso sin pérdida de datos. Windows Server 2003 nos ofrece redundancia por medio de software, pero un uso de redundancia mediante controladoras RAID minimiza el impacto en el rendimiento y nos permitirá el cambio de discos defectuosos sin pérdida de tiempo.

Como mínimo, deberíamos realizar copia de seguridad de datos críticos diariamente (sea de día o programarla cada noche). La redundancia no sustituye la necesidad de realizar copias de seguridad. Incluso los sistemas de archivo redundantes pueden fallar, y la redundancia no protege contra archivos corruptos o que han sido corrompidos por una aplicación. Los archivos corruptos deben restaurarse desde una copia de seguridad guardada y creada antes de producirse la corrupción.

Los virus son una fuente significativa de problemas de discos y sistema de archivos, así que:

Tengamos en nuestros sistemas al menos un servidor con programas de detección de virus y que se actualice automáticamente.
Configurar la detección de virus donde sea posible, Por ejemplo, un módulo anti-virus para Exchange.
Implementar un correcto servicio de actualización de software (WSUS por ejemplo), para una puesta al día del sistema eficiente.
Desconfiar de scripts o aplicaciones que no sean de confianza en un servidor.
NO USAR un servidor como una estación de trabajo. Y menos para usar la navegación web o ver el correo electrónico.

Una fragmentación en los discos no produce fallos de disco, aunque puede producir un peor rendimiento. Una programación regular de desfragmentación en horarios de poco o ningún uso, ayudará a mantenerlos adecuadamente. Guardar la salida de los comandos de defragmentación para poder consultarlos y ver que ésta se realiza como queremos.

Herramientas

Como ya hemos visto en otras ocasiones, disponemos de:

Windows Server 2003:

Característica	Descripción
ASR	Recuperación del sistema en dos partes que nos permite la restauración del estado del sistema operativo con los archivos guardados en un medio de almacenamiento y la información de configuración del disco guardada en un disquete.
Desfragmentador de disco	Windows Server 2003 nos proporciona dos caminos para la desfragmentación de discos: El elemento de consola y la versión de la herramienta en línea de comandos *defrag.* Ambas pueden desfragmentar volúmenes NTFS con tamaños de clúster superiores a 4KB y archivos con menos de 16 clústers. También ambas, pueden desfragmentar la MFT en volúmenes NTFS.
DiskPart	Comando para soluciones desde la línea de comandos como alternativa al administrador de discos.
Fsutil.exe	Herramienta en línea de comandos con diversidad de parámetros para usar en la administración de sistema de archivos.
DiskProbe mejorado	Añadido ver volúmenes FAT32.
Chkdsk mejorado	Actúa más rápidamente, puede corregir MFT corruptas en las que antes fallaba.

Chkdsk

Cuando ejecutamos el comando Chkdsk en volúmenes NTFS el proceso que sigue se divide en tres etapas principalmente y en una 4 y 5 opcionales. El comando muestra su progreso para cada una de estas etapas.

CHKDSK está comprobando archivos (etapa 1 de 3)...
0% completado. (0 de 36304 registros de archivos procesados)
...
9% completado. (32674 de 36304 registros de archivos procesados)

36304 registros de archivos procesados.
Comprobación de archivos terminada.
10% completado. (1 de 26 registros de archivos grandes procesados)
26 registros de archivos grandes procesados.

0 registros de archivos no válidos procesados.

0 registros de EA procesados.4 registros de análisis procesados.

CHKDSK está comprobando índices (etapa 2 de 3)...
10% completado. (1 de 123120 entradas de índice procesadas)
...

92% completado. (123042 de 123120 entradas de índice procesadas)
123120 entradas de índice procesadas.
Comprobación de índices terminada.
5 archivos no indizados procesados.

CHKDSK está comprobando descriptores de seguridad (etapa 3 de 3)...
93% completado. (1638 de 36304 descriptores procesados)
...
98% completado. (31406 de 36304 descriptores procesados)

36304 descriptores de seguridad procesados.
Comprobación de descriptores de seguridad terminada.
2449 archivos de datos procesados.
CHKDSK está comprobando el diario USN...
99% completado. (1048576 de 28017208 bytes de USN procesados)
100% completado. (28016640 de 28017208 bytes de USN procesados)

28017208 bytes de USN procesados.
Se ha completado la comprobación del diario USN.

133154720 KB de espacio total en disco.
   5587560 KB en 32604 archivos.
      9608 KB en 2450 índices.
         0 KB en sectores defectuosos.
    134632 KB en uso por el sistema.
El archivo de registro ha ocupado      65536 kilobytes.
127422920 KB disponibles en disco.

4096 bytes en cada unidad de asignación.
33288680 unidades de asignación en disco en total.
31855730 unidades de asignación disponibles en disco.

Etapa 1: Se verifica cada segmento de registro de archivo en la MFT. El tanto por cien que se muestra en esta etapa indica la MFT verificada.

Etapa 2: Comprobación de los directorios en el volumen. Se examina cada índice (directorio) en el volumen por consistencia interna y se verifica que cada archivo y directorio representados por un segmento de registro de archivo en la MFT está referenciado por al menos un directorio. También confirma que cada archivo y subdirectorio referenciado en cada directorio actual existe como un segmento de registro de archivo válido en la MFT y se comprueban referencias circulares de directorio. Entonces se confirma que los datos no se han alterado y la información del tamaño asociado está actualizado en el listado de directorios de estos archivos.

El tanto por cien mostrado es el número total de archivos en el volumen que son comprobados. En el caso de muchos archivos y carpetas, puede ser una etapa con gran duración.

Etapa 3: Se verifican los descriptores de seguridad para cada volumen. Se examinan cada descriptor de seguridad asociado con cada archivo y directorio en el volumen, verificando que cada estructura de descriptor está bien formada y consistente.

El tanto por cien es referido al número de archivos y directorios del volumen comprobados.

Etapa 4(opcional): Verificación de archivos de datos. Se comprueban todos los clústers en uso. Tanto esta etapa como la siguiente (5) se realizan sólo si especificamos el parámetro /r al ejecutar el comando chkdsk. Este parámetro confirma que los sectores en cada clúster es utilizable. Normalmente no es necesario especificarlo ya que NTFS identifica y remapea los sectores defectuosos durante el curso de operaciones normales, pero puede usarse si se sospecha de que el disco tiene sectores defectuosos o erróneos.

El tanto por cien mostrado se basa en los clústers que se han comprobado. Los clústers usados necesitan más tiempo de comprobacón que los no usados, siendo la etapa 4 más larga que la 5 en un volumen con cantidad igual de usados y no usados. En el caso de mayoría de no usados, la etapa 5 tardará más que la 4.

Etapa 5(opcional): Verificación del espacio libre. Se comprueban los clústers no usados. Sólo se lleva a cabo si se especifica el parámetro /r.

El tanto por cien se refieren a los clústers no usados comprobados.

Autochk.exe

Autochk.exe es una versión de Chkdsk que se ejecuta sólamente durante el inicio de Windows Server 2003 y se ejecuta cuando:

Chkdsk no tiene uso exclusivo del volumen. Si el comando no tiene uso exclusivo de un volumen al ejecutarlo se ofrece programar la comprobación en un próximo reinicio. Siempre ocurre si el volumen es el de arranque o de sistema. Si respondemos S, la autocomprobación se programará, en caso contrario se deja sin efecto.
El volumen ha sido marcado como dañado. Si el sistema de archivos tiene marcado el volumen como dañado. Autochk ejecutará el proceso de reparación al inicio. Los volúmenes se marcan como dañados si el sistema de archivos detecta un error en el mismo. Si autochk encuentra un volumen dañado, se dan 10 segundos de espera y luego comienza el proceso de reparación. Si cancelamos Autochk cuando un volumen está dañado, éste intentará ejecutarse de nuevo después de 10 segundos cada vez que el equipo se reinicie.

El comando Chkntfs.exe nos servirá para cambiar el tiempo de espera de Autochk, de 0 hasta 3 días. Sin embargo una espera larga significa que el equipo no se reiniciará hasta pasado ese tiempo o hasta que pulsemos una tecla para cancelar Autochk.

Si elegimos permitir el autochk, podemos revisar el informe en el visor de sucesos(registro de aplicación). La información de autochk es registrada por el servicio Winlogon, podemos filtrar las entradas según este origen.

Discos, volúmenes y sistemas de archivo(II).

juansa — Mon, 21 Apr 2008 08:01:39 GMT

MBR en discos dinámicos.

Al igual que los discos básicos, los discos dinámicos contienen un MBR con su código de inicio maestro, la firma del disco y, la tabla de particiones del disco. Sin embargo, la tabla de particiones en los discos dinámicos no contienen una entrada por cada volumen en el disco, ya que la información sobre el volumen está guardada en la BD del disco dinámico. En su lugar, la tabla de particiones contiene entradas por volumen del sistema, volumen de arranque(si no es el mismo que el del sistema), y uno o más particiones que abarcan el espacio restante no asignado en el disco. Todas estas particiones usan el ID de sistema 0x42, que indica que son particiones que están en un disco dinámico. Colocar estas particiones en la tabla de particiones impide que las utilidades de disco basadas en MBR interpreten el espacio disponible para nuevas particiones.

Sectores de inicio en discos MBR

El sector de inicio, que se ubica en el sector 1 de cada volumen, es una estructura de disco que es crítico para el inicio del equipo. Contiene el código ejecutable y los datos necesarios por el código, incluida la información que usa el sistema de archivos para el acceso al volumen. El sector de inicio se crea durante el formato del volumen. Al final de éste sector hay una estructura de 2 bytes denominada signature word o marcador de fin de disco, que está siempre establecido a 0x55AA. En equipos con Windows Server 2003, el sector de inicio en la partición activa carga en memoria y ejecuta el Ntdlr, que carga el menú de inicio si existen varias instalaciones de Windows, o carga el sistema operativo directamente en el caso de una única instalación.

El sector de inicio consiste en los elementos:

Una instrucción de interrupción de CPU de 24 bits.
La identificación del fabricante original (ID de OEM).
Una estructura de datos que es el BPB (BIOS parameter Block).
El BPB extendido.
El código ejecutable de inicio (bootstrap code) que arranca el sistema.

Cada sector de inicio en Windows Server 2003 tiene los elementos descritos sin importar si el disco es básico o dinámico.

El BPB describe los parámetros físicos del volumen: el BPB extendido comienza inmediatamente después del BPB. Debido a los diferentes tipos de campos y de la cantidad de datos que contienen, el tamaño del BPN es diferente para sectores de inicio FAT16, FAT32 y NTFS.

Los controladores de dispositivo de disco utilizan la información en el BPB y el BPB extendido para leer y configurar los volúmenes. El área que sigue al BPB extendido suele contener código ejecutable de inicio, que lleva a cabo las acciones necesarias para seguir con el proceso de arranque.

Procesos de arranque del sector de inicio

Los equipos usan este sector para ejecutar las instrucciones de arranque. El proceso de arranque inicial resumido:

La BIOS y la CPU inician la POST.
La BIOS selecciona el dispositivo de arranque, normalmente el primer disco que encuentra, si la controladora no está configurada para iniciar desde un disco/dispositivo diferente.
La BIOS carga el primer sector físico del dispositivo de arranque en memoria y transfiere la ejecución a ésta dirección de memoria.
Si el dispositivo de arranque es un disco, la BIOS carga el MBR. El código de inicio en el MBR carga a su vez el sector de inicio de la partición activa y le transfiere la ejecución a esta dirección de memoria. En equipos con Windows Server 2003, el código de inicio del sector de inicio busca el Ntldr, lo carga en memoria y le pasa el control.
Si la unidad A contiene un disquete, la BIOS carga el primer sector del disco en memoria. Si es un disco de arranque con formato MS-DOS y tiene los archivos de sistema necesarios, se carga el sector de inicio en la memoria y se usa el código para transferir el control a la CPU y el archivo IO.sys. Si el formato es con un sistema reciente de Windows, una vez cargado el sector de inicio se transfiere el control al Ntldr. En el caso de no ser un disco de inicio, se muestra el mensaje:

Non-system disk or disk error. Replace and press any key when ready

Si el mensaje es similar y el inicio se está ejecutando sobre un disco duro, el sector de inicio podría estar corrupto.

En principio, el proceso de arranque es independiente del formato del disco y del sistema operativo. Las características de sistema operativo y de sistema de archivo son importantes cuando se inicia el código ejecutable de inicio del sector de inicio.

Elementos de un sector de inicio

El MBR transfiere la ejecución a la instrucciones ejecutables de 32-bits del sector de inicio, por lo que los 3 primeros bytes de éste han de ser válidos. Esto incluye una instrucción de salto que irá a los siguientes bytes no ejecutables.

Lo siguiente a la instrucción de salto es el ID de OEM (8 bytes), una cadena de carácteres que identifica el nombre y versión del sistema operativo de formato del volumen. Para respetar la compatibilidad con MS-DOS, Windows Server 2003 graba "MS-DOS5.0" en éste campo en discos FAT16 y FAT32. En discos NTFS, graba "NTFS".

Posteriormente al ID OEM es el BPB, que proporciona información que permite al código ejecutable localizar al Ntldr. El BPB siempre se inicia en el mismo offset, parámetros estándar en sitio conocido. Tamaño y geometría variable del disco están encapsulados en el BPB. Ya que la primera parte del sector de inicio es una instrucción de salto de CPU de 24 bits, el BPB puede extenderse en el futuro agregando nueva información al final. La instrucción de salto necesita pocos ajustes para adaptarse al cambio. El BPB se guarda en un formato de paquete(sin alineamiento).

Los sectores de inicio y los BPB y BPB extendidos son distintos según si son FAT16, FAT32 o NTFS.

Sectores de Disco en discos GPT

GPT usa estructuras de particiones primarias y de copia de seguridad para proporcionar redundancia. Estas estructuras se ubican al comienzo y el final del disco. GPT identifica estas estructuras por sus direcciones LBA (Logical Block Address) más que por sus sectores relativos. Usando este esquema, los sectores en un disco están numerados del 0 a n-1, donde n es el número de sectores del disco.

La primera estructura en un disco GPT es el Protective MBR en el LBA0, seguido por la cabecera GPT primaria en LBA1. Esta cabecera es seguida por la entrada-array de partición GUID primaria, que incluye una entrada de partición por cada una de ellas en el disco.

Las particiones en el disco se situan entre las entradas-arrays GUID primaria y de copia de seguridad. Las particiones deben colocarse dentro del primero y el último LBAs utilizables, como esté especificado en la cabecera de particiones GPT.

Protective MBR

La especificación EFI (Extensible Firmware Interface) requiere que LBA0 esté reservado, por compatibilidad con el código y un Protective MBR. El protective MBR tiene el mismo formato que un MBR existente, y contiene una entrada de partición con un valor de ID de sistema de 0xEE. Esta entrada reserva el espacio entero del disco, incluyendo el usado por la cabecera GPT, como una partición única. El protective MBR se incluye para impedir que las herramientas de disco diseñadas para discos MBR interpreten el disco, como el espacio disponible y que no sobreescriban las particiones GPT. EFI ignora el protective MBR y no ejecuta código MBR.

Cabecera de particiones GPT

La cabecera GPT determina el rango de direcciones de bloques lógicos que son utilizables mediante las entradas de partición. También su localización en el disco, su GUID y el CRC32 (32 bits cyclic redundary check checksum) que se usa para la comprobación de la integridad de la propia cabecera GPT.

Los discos GPT usan una cabecera de partición GUID primaria y de copia de seguridad:

La primaria en LBA1, inmediatamente después del protective MBR.
La copia de seguridad en el último sector del disco. No hay datos después de esta.

EFI comprueba la integridad de las cabeceras mediante CRC32, un valor calculado que se usa para comprobación de errores en los datos . Si la primaria está corrupta, se comprueba la copia de seguridad, si ésta es válida, se usa para restaurar la primaria. Este proceso trabaja al revés si la primaria es correcta y la de copia es la corrupta. Si ambas están corruptas, entonces Windows Server Itanium no puede acceder al disco.

AVISO: Cualquier herramienta de disco no diseñada específicamente, como Diskpart.efi o las herramientas de versión Itanium, pueden realizar cambios que hagan inválidos los checksum y dejar los discos GPT inaccesibles.

Entrada-array GUID Partición

Similar a la tabla de particiones en los discos MBR, la entrada-array de particiones GUID contiene entradas de particiones que representan cada una de ellas en el disco. Las versiones Itanium de Windows Server 2003 crean un array de 16.384 bytes, por lo que el primer bloque utilizable se encuentra en una LBA igual o superior a 34. (EL LBA0 contiene el protective MBR, LBA1 la cabecera GPT, y entre el LBA2 y LBA33 se utiliza por la entrada-array de particiones GUID).

Cada disco GPT contiene dos entradas-array de particiones GUID:

La primaria que está justamente después de la cabecera y que finaliza antes del primer LBA utilizable.
La de copia de seguridad, ubicada entre el último LBA utilizable y la cabecera GUID de la misma copia de seguridad.

El valor CRC32 se guarda en la cabecera GPT. Cuando se agrega una nueva partición, se actualiza el CRC32 en las entradas primaria y copia de seguridad y luego se actualiza el tamaño de checksum de la cabecera GPT.

Entrada de partición GUID

Tiene un tamaño de 128 bytes y establece una única partición. Ya que las versiones Itanium crean una entrada-array que tiene 16.384 bytes, podemos tener un máximo de 128 particiones en un disco básico GPT

Cada entrada de partición GUID comienza con una partición tipo GUID. El tipo GUID de 16-bytes, similar a un ID de sistema en la tabla de particiones de un disco MBR, identifica el tipo de datos que la partición contiene y como se usa la partición. Las versiones Itanium sólo reconocen una serie de particiones GUI y no montan ninguna otra más. Sin embargo, los OEMs y distribuidores independientes (LSVs), como otros sistemas operativos, pueden establecer tipos adicionales.

Atributos de la entrada de partición GUID

Son descriptores de como se usa la partición. Están especificados dentro de un valor de 64-bits, EFI es compatible con hasta 64 atributos distintos. Las versiones Itanium usan 4 atributos:

Bits Descripción

Bit 0 Especifica que la partición es necesaria para el funcionamiento de la plataforma. Los OEMs deben establecer este bit para protegerla de sobrescritura por herramientas de disco de Windows Server 2003.

Bit 60 Marca la partición como sólo-lectura. Usado por particiones primarias básicas de cierto tipo.

Bit 62 Marca la partición como oculta. Usado por particiones primarias básicas de cierto tipo.

Bit 63 Impide que el sistema asigne de forma predeterminada una letra de unidad a la partición. Usado por particiones primarias básicas de cierto tipo.

Sectores de inicio en discos GPT

Similares a los de discos MBR, exceptuando que EFI ignora todo el código de 32-bits en el sector de arranque. En su lugar, EFI usa su propio controlador de sistema de archivos para leer el BPB y entonces monta el volumen.

Bits	Descripción
Bit 0	Especifica que la partición es necesaria para el funcionamiento de la plataforma. Los OEMs deben establecer este bit para protegerla de sobrescritura por herramientas de disco de Windows Server 2003.
Bit 60	Marca la partición como sólo-lectura. Usado por particiones primarias básicas de cierto tipo.
Bit 62	Marca la partición como oculta. Usado por particiones primarias básicas de cierto tipo.
Bit 63	Impide que el sistema asigne de forma predeterminada una letra de unidad a la partición. Usado por particiones primarias básicas de cierto tipo.