Windows Server : Redes (Networking)

Resolver los problemas de los Servicios

juansa — Thu, 04 Dec 2008 10:26:52 GMT

A pesar de si la raíz de un error es problema de hardware o de software, necesitamos un plan fiable para resolución de problemas. Un plan efectivo comienza reuniendo información, observando los síntomas y un buen estudio.

Cuando resolvemos problemas de los servicios, necesitamos disponer de un plan preparado para determinar la causa del problema en el servicio y decidir que herramientas necesitamos para aislarlo y resolverlo, Yes we can!

Los errores pueden ser de inicio, detención y bastantes más tipos, aunque los más comunes nos sueltan los errores:

ERROR_SERVICE_LOGON_FAILED
ERROR_SERVICE_DEPENDENCY_FAILED
ERROR_SERVICE_START_HANG

Como ya hemos comentado varias veces, seremos capaces de elegir diversas maneras de solucionar o depurar el problema del servicio.

Herramientas

La herramienta más eficiente para la comprobación y depuración de los servicios es sc.exe. Podemos usarla para establecer las propiedades almacenadas en el registro de un servicio para controlar cómo se inician durante el arranque y cómo se ejecutan en procesos en segundo plano.

Mientras se desarrolla y depura un servicio, esta herramienta puede ayudar ya que ofrece un generoso interfaz en línea de comandos para todas las opciones de control del servicio y puede fácilmente usarse en scripts.

Sc.exe es una herramienta de desarrollo que proporciona más información exacta y detallada sobre los servicios que las dos herramientas que proporciona el propio servicio operativo. El complemento services.msc y la herramienta en línea de comandos, Net.exe, pueden decirnos que un servicio se está ejecutando, o si está detenido o pausado. La herramienta sc.exe ayuda a la diagnosis del servicio cuando deja de responder.

Sc.exe nos permite consultar el estado del servicio y recuperar los valores almacenados en la estructura de los campos de estado. Net.exe y Services.msc no nos proporcionan el estado completo del servicio. Sc.exe, sin embargo nos dice exactamente su estado además de mostrarnos el número del último control y un indicio de espera. El control puede entonces utilizarse como una herramienta de depuración ya que proporciona una indicación clara de en qué medida durante la inicialización había progresado antes de dejar de responder.

Sc.exe también permite la llamada de cualquier API de control de servicio y variedad de parámetros desde la línea de comandos. Esto nos da varias ventajas. Nos proporciona la facilidad una manera de crear o configurar la información de un servicio en el registro y en la base de datos de SCM. No necesitamos configurar el servicio manualmente, creando entradas en el registro y reiniciando el equipo para que la base de datos SCM se actualice.

ADVERTENCIA:No deben modificarse las claves y subclaves de los servicios directamente en el Registro ya que podríamos causar resultados impredecibles en el inicio, detención o control de los mismos.

Como herramienta en línea de comandos, sc.exe también puede utilizarse para comprobar los servicios, podemos crear archivos de lotes (batch) con llamadas a sc.exe con varios parámetros que controlen el servicio. Útil si queremos ver el comportamiento de los servicios cuando se detienen y reinician repetidamente.

sc <equipo> [comando] [nombre_servicio] <opción1> <opción2> ...
<equipo> = Sólo si es remoto y en formato \\nombreEquipo

Comandos:

[comando]	Descripción
query	Consulta el estado de un servicio si va seguido de un nombre de servicio. Enumera el estado de todos los servicios si no va seguido de un nombre de servicio.
queryex	Consulta el estado extendido de un servicio si va seguido de un nombre de servicio. Enumera el estado extendido de todos los servicios si no va seguido de un nombre de servicio.
start	Inicia un servicio
pause	Envía una solicitud de control PAUSE a un servicio
interrogate	Envía una solicitud de control INTERROGATE a un servicio
continue	Envía una solicitud de control CONTINUE a un servicio
stop	Envía una solicitud de STOP a un servicio
config	Cambia la configuración de forma persistente de un servicio
description	Cambia la descripción de un servicio
failure	Cambia las acciones que emprende un servicio en caso de error
failureflag	Cambia el marcador de acciones de error de un servicio
sidtype	Cambia el SID de servicio de un servicio
privs	Cambia los privilegios requeridos de un servicio
qc	Consulta la información de configuración de un servicio
qdescription	Consulta la descripción de un servicio
qfailure	Consulta las acciones que emprende un servicio en caso de error
qsidtype	Consulta el tipo de SID de servicio de un servicio
qprivs	Consulta los privilegios requeridos de un servicio
delete	Elimina un servicio del Registro
create	Crea un servicio (lo agrega al Registro)
control	Envía un control a un servicio
sdshow	Muestra un descriptor de seguridad de un servicio
sdset	Envía el descriptor de seguridad de un servicio
showsid	Muestra la cadena SID de servicio correspondiente a un nombre arbitrario
GetDisplayName	Obtiene el DisplayName de un servicio
GetKeyName	Obtiene el ServiceKeyName de un servicio
EnumDepend	Enumera las dependencias del servicio

Comandos que no necesitan un nombre de servicio:

sc <equipo> [comando] <opción>

boot	(ok\|bad) Indica si el último arranque debe guardarse como última configuración conocida de arranque correcto.
Lock	Bloquea la base de datos del servicio.
QueryLock	Consulta el LockStatus de la base de datos SCM

Opciones de Query y QueryEx en caso de que la consulta vaya seguida de un nombre de servicio, se devolverá el estado del mismo y no se aplican más opciones. Si la consulta no va seguida de nada o de una de las opciones siguientes, se enumerarán los servicios.

type=	Tipo de servicios que se enumerar n (controlador, servicio, todos)(valor predeterminado = servicio)
state=	Estado de los servicios que se enumeran (inactivo, todos)(valor predeterminado = activo)
bufsize=	Tamaño (en bytes) del búfer de enumeración (valor predeterminado = 4096)
ri=	El número de índice de reanudación en el que comenzar la enumeración (valor predeterminado = 0)
group=	Grupo de servicio que se enumerar (valor predeterminado = todos los grupos)

Ejemplos de sintaxis:

sc query

- Enumera el estado de controladores y servicios activos

sc query eventlog

- Muestra el estado del servicio de registro de eventos

sc queryex eventlog

- Muestra el estado extendido del servicio de registro de eventos

sc query type= driver

- Enumera sólo los controladores activos

sc query type= service

- Enumera sólo los servicios de Win32

sc query state= all

- Enumera todos los servicios y controladores

sc query bufsize= 50

- Enumera con un búfer de 50 bytes

sc query ri= 14

- Enumera con índice de reanudación = 14

sc queryex group= ""

- Enumera los servicios activos que no están en un grupo

sc query type= interact

- Enumera todos los servicios interactivos

sc query type= driver group= NDIS

- Enumera todos los controladores NDIS

---

ERRORES DE INICIO DEL SERVICIO

Estos errores se producen cuando SCM carga un servicio durante el inicio del sistema. Algunos mensajes comunes de error de inicio:

ERROR_SERVICE_ALREADY_RUNNING

ERROR_SERVICE_DEPENDENCY_FAIL

Cuando un controlador o servicio devuelve un error en respuesta al comando de inicio del SCM, el valor de la entrada ErrorControl en el registro determina la reacción del SCM.

Si el valor es 0 o no está especificado, SCM ignora el error y sigue procesando el inicio del servicio.
Si el valor es 1, SCM registra un evento en el registro de sucesos del sistema, que dice, "El Servicio <nombre_servicio> ha fallado en su inicio debido al siguiente error:" y sigue procesando el inicio del servicio. SCM incluye la representación en texto del código de error de Win32 que el servicio ha devuelto al SCM como la razón de su fallo de inicio en el registro del suceso grabado.
Si el valor es 2 o 3, SCM registra un evento en el registro de sucesos y cambia la configuración del registro de la última configuración buena conocida, con la que el equipo inicio correctamente la última vez. Y entonces reinicia el equipo usando la función shutdown, que está implementada en la parte ejecutiva del kernel. Si el equipo ya está en ejecución con la última configuración buena conocida, simplemente se reinicia.

Detectar servicios que no responden

Determinar si un servicio está detenido o colgado puede ser a veces difícil. Si un servicio deja de responder en cualquier estado a excepción de SERVICE_STOPPED, el complemento Services y Net.exe informarán que sigue en ejecución. Por ejemplo, si un servicio deja de responder cuando se encuentra en el estado SERVICE_STOP_PENDING, el comando Net start informará que su estado es ejecutándose y el complemento Servicios indicará que se encuentra detenido. Una comparación de como informan del estado las herramientas:

Estado	Services	Net.exe	Sc.exe
SERVICE_STOP_PENDING	SERVICE_RUNNING	SERVICE_RUNNING	SERVICE_STOP_PENDING
SERVICE_START_PENDING	SERVICE_RUNNING	SERVICE_RUNNING	SERVICE_START_PENDING

Si intentamos iniciar un servicio detenido con el estado SERVICE_STOP_PENDING o SERVICE_START_PENDING, Net.exe indicará que el servicio ya está en ejecución.

La forma de conocer los servicios que no se están ejecutando en un equipo es usando el comando:

sc query type= service state= inactive

Y si queremos consultar un servicio en concreto:

sc query service nombre_servicio

Los servicios tienen tendencia a colgarse cuando están en estado SERVICE_START_PENDING. También en el estado SERVICE_STOP_PENDING si hay problemas su apagado.

Algunas veces pueden aparecer como colgados porque SCM está esperando a que un servicio cambie de estado. SCM espera a que un servicio se inicie en dos casos:

El servicio se está iniciando automáticamente.
El servicio está siendo iniciado por SCM ya que se llamo a StartService por un servicio que depende de él.

En ambos casos, SCM espera 80 segundos extra para que el servicio cambie su estado de SERVICE_START_PENDING o para llamar a SetServiceStatus otra vez con un punto de comprobación nuevo.

Si el servicio tarda demasiado en iniciarse, supera el tiempo total de espera de SCM, éste lo marcará como fallado (colgado en el inicio), registrará un suceso, EVENT_SERVICE_START_HUNG, y sigue adelante. Este evento se registra sólo si el nivel de error del servicio no se ignora. Si se ignora, podremos ver el mensaje la próxima vez que Windows se inicie. Ya que SCM no detiene un servicio colgado, podemos utilizar sc.exe para ver cuales servicios permanecen en un estado SERVICE_START_PENDING y de ellos cuales no responden.

Si el servicio llama a SetServiceStatus en algún momento durante este intervalo y especifica un nuevo punto de comprobación, SCM reiniciará su tiempo de espera. Un nuevo punto de comprobación le indica a SCM que sigue pendiente pero que ha realizado algún progreso.

El tiempo de espera puede detectarse mediante el campo dwWaitHint de la estructura SERVICE_STATUS que se pasa. Podemos comprobar este valor mediante el comando sc query servicio, donde servicio es el que no responde (el tiempo de espera es válido sólo cuando el servicio está en el estado SERVICE_START_PENDING).

Solucionando errores TCP/IP. 9 final.

juansa — Fri, 10 Oct 2008 11:06:22 GMT

Puertas de enlace

Si estamos recibiendo el mensaje "La puerta de enlace no pertenece a ninguno de los interfaces configurados..." durante la instalación y configuración del SO, hemos de ver si la puerta de enlace predeterminada está en la misma red lógica que el adaptador de red del equipo. La forma más fácil de hacerlo es comparando el ID de red de la IP de la puerta de enlace con el ID de red de los adaptadores del equipo. En otras palabras, comprobar las operaciones lógicas AND de ambas IP y máscaras y sean correctas.

Proxy ARP

Proxy ARP es el que responde a solicitudes ARP de parte de otro nodo. Como se describe en la RFC 925, se usa en situaciones en que una subred es dividida sin usar un enrutador. Un dispositivo proxy ARP se coloca entre nodos que no están en la misma subred lógica. El proxy ARP responde a solicitudes ARP y facilita el reenvío de paquetes IP unicast para la comunicación entre nodos en segmentos separados.

Ejemplos:

RRAs en equipos con W2k3, que usa proxy ARP para facilitar la comunicación entre clientes remotos y nodos en el segmento de red que está asignado al servidor de acceso remoto.
La característica de puente en XP y W2k3 estándar y la edición de 32 bits de W2k3 Enterprise, que actúan como un dispositivo proxy ARP cuando llevan a cabo la tarea de puente (capa 3) entre segmentos de red.

El tráfico de red falla en algunas ocasiones porque la solicitud de un enrutador a un proxy ARP devuelve una dirección errónea. Un enrutador hace la solicitud ARP de parte de una dirección IP dentro de sus subredes internas. El problema es que la respuesta devuelve una MAC incorrecta para enviar al equipo. Como resultado, el equipo envía su tráfico a una MAC incorrecta. En resumen, tenemos un problema de respuestas desde un proxy ARP.

Para esto necesitamos del Monitor de Red y capturar la traza. Si la misma revela que cuando el equipo envía una solicitud ARP para la MAC del destino y un dispositivo (normalmente un enrutador) la devuelve con una MAC incorrecta, es que la resolución IP-a-MAC no funciona.

Nota: Podemos ejecutar hh NETMNconcepts.chm desde Inicio->ejecutar para obtener información sobre Network Monitor.

Para determinar si este es el problema podemos comprobar la caché ARP del equipo origen para asegurarnos de que esté adquiriendo la dirección resuelta de IP-a-MAC correcta. También podemos capturar todo el tráfico con Network Monitor y luego filtrar el tráfico capturado para mostrar sólo los protocolos ARP y RARP (este convierte MAC-a-IP).

Puede que resolvamos el problema desactivando el prosy ARP en el dispositivo, dependiendo de la marca, modelo y configuración del mismo.

Enrutadores agujeros negros

Algunos enrutadores no envían el mensaje "ICMP Destination Unreacheable-Fragmentación Needed and DF set" cuando no pueden reenviar un datagrama IP. En su lugar, descartan el datagrama en silencio. Normalmente un datagrama IP no puede ser reenvíado si su tamaño máximo de segmento es demasiado grande para el servidor receptor, y está establecida la no fragmentación de bit en la cabecera del propio datagrama. Los enrutadores que ignoran estos datagramas y no envían el mensaje se denominan PMTU Black-Hole Routers.

Para responder eficazmente a estos enrutadores, debemos habilitar la característica de detección de PMTU black-hole de TCP/IP. Esta característica reconoce transmisiones desconocidas y repetidas y responde desactivando la no fragmentación de bit. Después de la transmisión de un datagrama con éxito, se reduce el tamaño máximo de segmento y se activa de nuevo la no fragmentación de bit.

La característica de detección comentada está deshabilitada de forma predeterminada, pero podemos habilitarla añadiendo la entrada EnablePMTUBHDetect con un valor a 1 en el registro. Esta entrada es opcional y no aparece en el registro a menos que la añadamos en la sub-clave pertienente, que es:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Podemos deshabilitarla borrando la entrada o estableciendo su valor a 0.

Una segunda entrada, EnablePMTUDiscovery, ayuda también a descubrir problemas de enrutador agujero negro. Esta clave está habilitada predeterminadamente. Habilita o deshabilita completamente el mecanismo de descubrimiento de PMTU. Si está deshabilitada, se utiliza un tamaño máximo de segmento de TCP (MSS) de 536 bytes en direcciones de destino no locales.

Descubrir PMTU con Ping

La PMTU entre dos equipos puede descubrirse manualmente mediante el comando ping -f:

ping -f -n numerodepings [-l tamaño] IP_destino

Un ejemplo de como el tamaño de los ping puede variarse hasta encontrar la MTU. El parámetro de tamaño del ping especifica exactamente el tamaño de un dato Echo ICMP a enviar, sin incluir las cabeceras IP y ICMP. La cabecera ICMP es 8 bits y la de IP es normalmente de 20 bits. En el caso de ethernet que vemos, la link layer MTU contiene el tamaño máximo de buffer plus 28 de ping, para un total de 1500 bytes del primer ping y 1501 en el segundo.

En el segundo ping, la capa IP devuelve un mensaje de error ICMP que ping interpreta. Si el enrutador es un agujero negro, ping no recibirá respuesta des que su tamaño ha excedido la mayor MTU que el enrutador puede manejar. Ping puede usarse así, para detectar el enrutador.

Servicios

Además de su función de proveedor de comunicaciones básicas de red, TCP/IP es la piedra angular de una serie de servicios de red como: RRAs, Impresión, IPSec y Examinador.

Si deseas más información sobre los protocolos TCP/IP, procesos y detalles de implementación en Windows:

Microsoft Windows Server 2003 Servicios y
Protocolos TCP/IP Referencia Técnica

ISBN: 0-7356-1291-9 (Inglés)
ISBN: 84-481-3809-7 (Español)

Solucionando errores TCP/IP. 8

juansa — Thu, 09 Oct 2008 14:45:48 GMT

Enrutamiento IP

Winodws Server 2003 es compatible con enrutamiento IP tanto en equipos con una tarjeta-adaptador de red como con varias y con o sin el servicio de Enrutamiento y Acceso Remoto(RRAs). RRAs incluye el protocolo RIP (Protocolo de información de enrutamiento) y los protocolos de enrutamiento OSPF (Open Shortest Path First). Los enrutadores pueden usar RIP o OSPF para intercambiar información de enrutamiento dinámicamente.

No podemos conectar a un servidor específico

Si no logramos conectar a un servidor específico mediante conexiones NetBIOS, usaremos nbstat -n para determnar el nombre NetBIOS que ha usado el servidor para registrarse en la red.

La salida el comando lista varios nombres que el equipo ha registrado. Uno de ellos debe parecerse al que se muestra en el escritorio del equipo. Sino, intentaremos con uno de los nombres únicos mostrados por Nbstat.

NBstat también muestra en pantalla las entradas cacheadas desde las entradas PRE del archivo Lmhosts o nombres NetBIOS resueltos recientemente. Si el nombre NetBIOS que los equipos están usando para el servidor es el mismo, y los otros equipos están en una subred remota, hay que asegurarse que tienen en su Lmhosts o en servidores WINS el nombre mapeado.

Servidores de múltiples-usos

Servidores con otras tareas pueden proporcionar servicios de enrutamiento, especialmente en LANs. Has de poder acceder al servidor que piensas que puede estar causando el problema, especialmente si es intermitente, para poder verificar que ningún otro servicio o aplicación está interfiriendo en los recursos del servidor, o que alguno no carga archivos grandes al inicio o apagado del servidor. Esto se aplica al equipo cliente también. Un método para verificarlo sería abrir el Administrador de equipos (clic derecho en MI PC, Administrar), extendemos recursos/carpetas compartidas, y seleccionamos la carpeta Sesiones para mostrar quien tiene una sesión actual con el equipo. Desde la consola de administración de equipo, podemos también ver el Visor de sucesos, que puede mostrar quien ha accedido al servidor, como también cualesquiera otros problemas que estén ocurriendo en ciertas horas o con una frecuencia específica. Otro método sería abrir al Administrador de Tareas para comprobar que aplicaciones o procesos se están ejecutando y lo que afectan al uso de la CPU.

Conexión colgada a un equipo remoto

Para determinar porqué una conexión TCP/IP remota no trabaja adecuadamente, podemos usar netstat -a para ver el estado de toda la actividad en los puertos TCP y UDP del equipo local.

Una buena conexión normalmente muestra 0 bytes en las colas de envío y recepción. Si los datos están bloqueados en alguna cola, la conexión probablemente falla. Si no, puede que sea la red o algún retardo de la aplicación.

Examinar la tabla de rutas con Route

Para dos equipos que intercambian datagramas, ambos han de tener una ruta hacia cada uno de ellos o usar una puerta de enlace que conozca una ruta. Normalmente los enrutadores intercambian información entre ellos mediante RIP.

Habilitar Enrutamiento IP

De forma predeterminada el Enrutamiento IP está deshabilitado. Para habilitarlo, debemos permitir el reenvío de paquetes que se reciben. Si no estamos usamos RRAs para habilitarlo, entonces debemos modificar el registro.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

La entrada IPEnableRouter

A la que le cambiaremos el valor a 1 para habilitar el enrutamiento en todas las conexiones de red instaladas y utilizadas por el equipo.

Si Windows Server 2003 como enrutador no tiene una interfaz en una determinada subred, necesita una ruta para llegar a ella. Esto puede manejarse mediante una ruta predeterminada o añadiendo rutas estáticas. Para añadir una ruta estática podemos usar RRAs o con el comando Route Add. Por ejemplo:

Route add 172.16.33.0 mask 255.255.255.0 172.16.0.1 metric 2

Aquí añadimos 172.16.33.0/24 alcanzable usando la puerta de enlace 172,16.0.1 en dos saltos. Si queremos que la ruta sea persistente, esté presente incluso después de reiniciar, añadimos la opción -p al final del comando. Las rutas persistentes se guardan en el registro.

Examinar rutas con Tracert

Tracert usa incrementalmente valores altos en el TTL de la cabecera para determinar la ruta desde un equipo a otro a través de una red. Lo hace enviando mensajes Echo de ICMP y analizando los mensajes ICMP de retorno. Nos permite determinar la ruta de un paquete reenviado desde un enrutador a otro hasta 30 saltos. Si un enrutador ha fallado o el paquete es enrutado en un loop, Tracert nos indicará el problema. Después de hallarlo, su administrador debe restaurarlo a su estado de completa funcionalidad, contactando si es necesario con él si está fuera de nuestra administración.

Solucionando errores TCP/IP. 7

juansa — Wed, 08 Oct 2008 11:57:33 GMT

Nombre NetBIOS o de Host inalcanzable

Ya dijimos que W2k3 permite la comunicación en red entre equipos usando tres tipos de destinos:

Dirección IP
Nombre de equipo (Host Name)
Nombre NetBIOS (NetBIOS Name)

Veamos como podemos intentar dar soluciones a problemas en las dos últimas.

El primer paso es ver que aplicaciones están produciendo errores. Normalmente, en estas aplicaciones se incluyen IExplorer, NET USE, TELNET y FTP. Una vez sabemos cuales fallan, el siguiente paso es determinar si el error se debe a un problema de resolución de nombre de equipo o nombre NetBIOS.

La forma más fácil de distinguir los problemas entre ambas resoluciones es comprobar si la aplicación usa NetBIOS o Sockets. Si usa sockets el problema está relacionado con resolución de nombre de equipo. Las aplicaciones NetBIOS son de largo, las más comunes, incluyendo diversos comandos NET, Windows Explorer, y la superconocida Mis Sitios de Red. Las aplicaciones sockets incluyen IExplorer, otros navegadores, TELNET y FTP.

Error 53

El síntoma más común de un problema de NetBIOS es cuando el comando ping devuelve un mensaje de error 53. Este error generalmente es devuelto cuando falla la resolución a un nombre de equipo particular. También puede ocurrir cuando hay un problema estableciendo una sesión NetBIOS. Para distinguir entre estos dos casos:

Desde la línea de comandos, escribimos

net view \\nombre_equipo

*nombre_equipo es un recurso de red que sabemos que está activo.

Si esto funciona, la resolución de nombres no es probablemente el origen del problema. Con un ping al nombre de equipo podemos confirmarlo, ya que algunas veces la resolución de nombres puede funcionar correctamente cuando net use devuelve un error 53 (como cuando un DNS o WINS tiene una entrada errónea). Si el ping muestra que la resolución falla (con un error de host desconocido), comprobaremos el estado de la sesión NetBIOS.

Para comprobarla:

Desde la línea de comandos, escribimos

net view \\dirección_IP

*La dirección IP del mismo recurso que usamos para identificar la causa del error 53.

Si esto también falla, el problema se encuentra en el establecimiento de una sesión.

Si el equipo está en una subred local, confirmad que el nombre se ha escrito correctamente y que el equipo está ejecutando TCP/IP. Si el equipo no está en una subred local, asegúrenomos de que su nombre y su IP están debidamente relacionados en un DNS, o en los archivos HOSTS o LmHOSTS, o en WINS.

Si todos los elementos TCP/IP parecen bien instalados, con ping comprobaremos que en el equipo remoto TCP/IP funciona.

No podemos conectar con sistemas remotos mediante nombre de equipo

Si el problema no es de NetBIOS, es de sockets, el problema está relacionado con alguna entrada del archivo Hosts o un error en DNS. Para comprobar que sólo funciona correctamente con IPs y no con nombres de equipo, remotamente, comprobaremos ambos: Hosts y DNS en cuanto al equipo que nos da problemas.

Comprobar archivos Hosts

Las entradas del archivo Hosts se usan para crear entradas en la caché de resolución de cliente de DNS, que podemos ver con el comando ipconfig /displaydns. Comprobad los contenidos de la caché de resolución de cliente DNS y las entradas del archivo Hosts.

Comprobar configuración DNS

Si usamos DNS, comprobaremos que las direcciones IP de los mismos están perfectamente configuradas en las propiedades de TCP/IP y en el orden correcto.

Panel de control -> doble-clic en Conexiones de red -> Clic derecho en la conexión, clic en propiedades -> Clic en Protocolo TCP/IP y clic en propiedades -> En las propiedades clic en Avanzadas -> Pestaña DNS -> Comprobamos los DNS.

Este procedimiento nos servirá en los equipos que están configurados estáticamente, ya que si son clientes DHCP no tendrán DNS en la lista.

Ping al equipo remoto mediante nombre de equipo y con su dirección IP para ver si la resolución es correcta. Si al nombre falla pero no a la IP, el problema es la resolución. Comprobad los DNS, un ping a sus IP para ver si están en marcha, o abrid una sesión Telnet al puerto 53: si la conexión se establece con éxito el DNS está funcionando. Después de ver que funciona el DNS, con NSlookup podemos enviar solicitudes al DNS y verificar el estado de los registros que estamos comprobando.

Si fallan ambos, el problema debe ser la conectividad de red, sea la conectividad básica o el enrutamiento.

Resolución de nombres mediante servidor DNS

DNS es una base de datos distribuida que relaciona nombres de dominio a datos. Un usuario puede consultar DNS usando nombres conocidos y jerárquicamente, para localizar equipos y otros recursos en una red IP. Esto ha supuesto el reemplazo de lo que una vez realizaba el archivo Hosts. DNS resuelve nombres conocidos a direcciones IP, de una forma transparente y como podemos observar, como ejemplo:

Un cliente contacta con el servidor DNS con una solicitud recursiva para www.juansa.net. El servidor debe devolver una respuesta o un mensaje de error.
El DNS comprueba sus archivos de zona y caché para la respuesta, pero no la encuentra. Entonces contacta con un servidor raíz para realizar una consulta iterativa respecto a la solicitud recibida.
El servidor raíz no conoce la respuesta, y responde con una referencia a un servidor autoritativo del dominio .net.
El servidor DNS contacta con un servidor en el dominio .net con una consulta iterativa respecto a la solicitud original.
El servidor DNS en el dominio .net no conoce la respuesta exacta, así que responde con una referencia a un servidor autoritativo en el dominio juansa.net.
El servidor DNS contacta con el servidor en juansa.net con una consulta iterativa de la solicitud original.
El servidor en juansa.net conoce la respuesta y responde con la IP correspondiente al nombre solicitado.
El servidor DNS responde a la solicitud del cliente con la dirección IP para www.juansa.net.

(Esto no es más que un ejemplo que podría darse en internet, hay más info sobre consultas recursivas e iterativas, podemos encontrarla por ejemplo en nuestro propio w2k3, ejecutando hh DNSconcepts.chm desde ejecutar)

Mensajes de error DNS

Los errores en la resolución de nombres pueden ocurrir si las entradas en un servidor o cliente DNS no están correctamente configuradas, sí el servidor no está activo, o si hay un problema con la conectividad de red. Para determinar la causa de cualquier problema de resolución podemos usar la herramienta Nslookup.

Las solicitudes falladas devolverán una variedad de mensajes, dependiendo de la naturaleza del fallo. Por ejemplo, si usamos el siguiente comando:

nslookup equipo_destino

y el servidor no puede resolver el nombre, se mostrará lo siguiente:

Server: Nombre cualificado completo de dominio
Address: Dirección IP del servidor
*** Nombre completo de dominio cualificado no puede encontrar equipo_destino: dominio no existe

En otros casos, las solicitudes sin respuesta:

nslookup equipo_válido
Servidor: IP Address: w.x.y.z
DNS request timed out.
timeout was 2 seconds.

Si el servidor falla en responder a la solicitud, Nslookup devuelve:

*** Can't find server name for address dirección_ip: No response from server
*** Default servers are not available.

Este mensaje indica que el servidor DNS es inalcanzable, aunque no indica el porqué. El servidor puede estar apagado, el equipo no tener el servicio DNS activo o existir un problema de hardware o enrutamiento.

Resolución de nombre de equipo mediante archivo Hosts

Un equipo que usa el archivo Hosts para llevar a cabo la resolución de nombres sigue unos pasos:

Equipo A introduce un comando usando el nombre de equipo de Equipo B.

Equipo A comprueba el contenido de la caché de resolución DNS, que contiene las entradas del archivo Hosts. Cuando el nombre de equipo de Equipo B se encuentra, se resuelve a una dirección IP. Entonces el paquete es envíado usando los procesos de resolución de dirección y determinación de ruta normales.

Los errores del archivo Hosts pueden causar errores de red, como:

No contenga un nombre de equipo concreto.

El nombre de equipo en el archivo o en el comando está mal escrito.

La dirección IP para el nombre de equipo es inválida o incorrecta.

Hay múltiples entradas para el mismo equipo en distintas líneas. El archivo se usa desde el inicio, así que la primera entrada es la que se propagará a la caché de resolución de cliente DNS.

El archivo Hosts no se actualiza dinámicamente; todas sus entradas son agregadas manualmente, y la IP y el nombre de equipo son siempre separados por uno o más espacios o tabulación. Un ejemplo:

Si estamos teniendo problemas conectando a un equipo remoto mediante su nombre de equipo y usamos el archivo Hosts para la resolución, el problema podría estar en el contenido del archivo. Busquemos el nombre del equipo remoto correctamente escrito en el archivo y por la aplicación que lo usa.

Comprobar el archivo LmHosts

El problema en la resolución de nombres podría estar en nuestro archivo LmHosts, que se comprueba para direcciones para nombres NetBIOS de forma secuencial de arriba a abajo. Si hay más de una dirección listada para el mismo nombre, se devuelve el primer valor encontrado, tanto si es bueno como si no.

El archivo podemos buscarlo en ruta_del_sistema\System32\Drivers\Etc. No existe de forma predeterminada; un ejemplo existe como LmHosts.SAM. Este archivo debe ser renombrado o copiado como LmHosts antes de usarlo.

Aunque el directorio mencionado es el predeterminado, su consulta dependerá del valor en la entrada DataBasePath de la sub-clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

Esta entrada le dice al equipo local donde debe mirar para el archivo LmHosts.

Tiempo excesivo para conectar usando Lmhosts

Para comprobar la causa de un tiempo excesivo en conectar al añadir una entrada en el archivo, hay que ver el orden de las entradas.

Este problema puede ocurrir cuando un archivo grande tiene la entrada especificada al final del mismo. Para mejorar la resolución de la entrada, marcarla como una entrada precargada mediante el uso de la etiqueta #PRE. Entonces usaremos el comando nbstat -R para actualizar la caché de nombres NetBIOS local inmediatamente.

Alternativamente, podemos emplazarla más alto en el archivo. El archivo se lee desde arriba para la localización de entradas sin la etiqueta #PRE. Por lo tanto, las entradas que sabemos que son utilizadas más frecuentemente deben ir cerca del inicio del archivo y las que llevan la etiqueta al final del mismo archivo.

Comprobar la configuración WINS

Comprobar que la configuración WINS es correcta y en particular que la dirección del servidor WINS es la adecuada.

El procedimiento es el mismo que más arriba hemos utilizado para comprobar la configuración DNS, sólo que esta vez pulsaremos la pestaña WINS y comprobaremos la configuración:

- Añadir la ip del servidor WINS, si no lo está y existe.

- Verificar que Lmhosts lookup esta habilitado.

- También si NetBIOS sobre TCP/IP se asigna desde DHCP si está habilitado o deshabilitado. Sino, habilitar NetBIOS sobre TCP/IP.

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.

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.

Lanconfig: utilidad de configuración de redes

juansa — Mon, 07 Jan 2008 20:27:37 GMT

Una pequeña utilidad desarrollada por El Guille,:

Lanconfig

Esta utilidad permite tener varias configuraciones para los adaptadores de red local del equipo, pudiendo seleccionar la que quieres usar en cada momento, por ejemplo para asignar valores distintos según los valores de conexión de cada sitio en los que te conectes.

Espero que le encuentres aplicación. :-)

MVP Global Summit 2007

juansa — Fri, 09 Mar 2007 15:30:00 GMT

I'm on! :-)

Chavales, he estado un poco líadillo pero no quería irme a USA sin comentar que en cuanto vuelva sigo con los artículos.

Os dejo una utilidad de red a la que le he estado dando vueltas, http://www.svetlian.com/windows/Config.htm, no es compatible con Vista y aún me estoy preguntando el porqué, bueno espero que me lo aclaren en Redmon. La utilidad es para los portatiles, podemos configurarnos distintas wireless (unas tienen IP fija, otras automática) y guardarlas; en el momento que necesitamos cambiar una con un par de clics la tenemos configurada.

Aquí también podeis bajarla http://www.multingles.net/docs/juansa/ConfiguradorDeRedSetup.zip.

Todas las sugerencias y errores que podais encontrar podeis decirmelos desde el blog. Estoy trabajando con la versión 5 y espero que servirá para Vista ;-)

Enga, ya os cuento lo que se cuece, ;-)

Implementar servicios de red: Planeamiento de la infraestructura basada en IP

juansa — Tue, 29 Aug 2006 16:22:00 GMT

Si se quiere crear o ampliar una red, se puede escoger entre varios modelos, en los que se incluye el modelo de infraestructura denominado modelo de dieseño de tres capas. Que es un modelo de red jerárquico descrito por Cisco Systems, Inc. entre otros proveedores y que se utiliza ampliamente como referencia en el diseño de redes.

El proceso a seguir vendría a ser:
- Diseño de la capa de acceso
- Diseño de la capa de distribución
- Diseño de la capa principal

La naturaleza modular que presenta un modelo jerárquico puede simplificar la implementación, la capacidad de planeamiento y la solución de problemas en una red grande. aquí, las capas representan las capas lógicas de funcionalidad dentro de la red. Unas veces, los dispositivos sólo tienen una función; en otras, el mismo dispositivo puede funcionar con dos o más capas.

Diseño de la capa de acceso

Esta es en la que los usuarios se conectan al resto de la red, incluidos los servidores de grupo de trabajo y estaciones de trabajo individuales. Suele incluir un número relativamente grande de puertos de acceso de velocidad baja-media, mientras las otras capas incluyen menos pero de más velocidad. Esta capa debe diseñarse sin olvidar la economía y la eficacia, equilibrando el número de puertos de acceso para el mantenimiento de las solicitudes de acceso dentro de la capacidad de las capas superiores.

Diseño de la capa de distribución

Esta capa distribuye el tráfico de red entre las capas de acceso relacionadas, y separa el tráfico destinado localmente de aquél que se destina a otras capas mediante el núcleo.
Las directivas de control de acceso y de seguridad de red se suelen implementar en esta capa. Los dispositivos de red pueden incorporar tecnologías como servidores de seguridad y traductores de direcciones.
Aquí suelen definirse las subredes, y con dicha definición, los dispositivos de esta capa a menudo lo hacen como enrutadores. Todas las decisiones referente a los métodos de enrutamiento y protocolos de enrutamiento afectan a la escalabilidad y rendimiento de la red en esta capa.
Una red de servidor en la capa de distribución puede albergar servicios de red críticos y servidores de aplicación centralizados. Los equipos que ejecutan Windows Server 2003 se podrán utilizar cpn su servicio de directorio Active Directory, DNS, DHCP y algunos otros servicios de infraestructura principales.

Diseño de la capa principal

Esta capa facilita una transferencia eficaz de datos entre capas de distribución interconectadas. Suele funcionar como el núcleo de alta velocidad de la red. Puede incluir una o más redes LAN, MAN o WAN de alta velocidad.
El principal objetio del diseño consiste en la obtención de rendimiento confiable de red de alta velocidad. Como regla general, buscar cualquier característica que pueda afectar a la confiabilidad o rendimiento de esta capa en una de distribución o de acceso.
Debe seleccionarse un equipamiento confiable y diseñarse un sistema principal tolerante a errores siempre que sea posible. Diversidad de productos cumplen este criterio, y la mayoría de proveedores de red ofrecen soluciones globales que cumplan estos requisitos.

Implementar los servicios de red.

juansa — Thu, 10 Aug 2006 11:39:00 GMT

Un correcto diseño de la infraestructura de la red es fundamental para su perfecto funcionamiento. Puede que se quiera activar DHCP, ofrecer DNS o WINS, protegerla mediante ISA Server e IPSec, en fin un conjunto de servicios basados en protocolos TCP/IP en su mayoría, para las redes.

Los técnicos, mejor dicho, mis profesores siempre incidían mucho en lo que la mayoría de estudiantes no nos detenemos, es decir, siempre queremos ir directo al grano; por ejemplo: si hemos de programar... pasamos directamente a escribir código!! y como casi siempre, tienen razón! Hasta que no acumulamos cierta experiencia (aprendemos más de los errores que de los aciertos) no caemos en la cuenta que lo primero que debe hacerse siempre es: analizar la situación, en nuestro caso, diseñar el entorno de la red, examinando la infraestructura existente, si la hay, o decidir como será el nuevo entorno.

Revisar y recontar el hardware y el software del que se dispone, un inventario junto a un mapa de red nos ahorrará tiempo imprescindible. Hay algún libro disponible, en el caso de Windows Server 2003, con referencia al diseño incluído en el Kit de recursos de Windows Server 2003.

De forma general podríamos realizar un esquema que nos indique el proceso a seguir por etapas, teniendo en cuenta siempre cada aspecto en relación con los demás y no como un proceso lineal paso a paso.

Planear la infraestructura basada en IP
Implementación de estrategias de enrutamiento
Diseñar un esquema de direccionamiento IP
Planear una estrategia de configuración IP
Seguridad
Disponibilidad
Multidifusión IP
IPv6
Probar el diseño

* Pasos recomendados en el kit de recursos Windows Server 2003

-->

Herramienta interesante para redes...

juansa — Tue, 04 Jul 2006 15:51:00 GMT

Gracias a un colega MVP de Networking cuyo nombre es Obiwan, aquí teneis el vínculo a una herramienta muy interesante y el vínculo a su manual.

Es libre y si la probais, seguro que os sorprendeis...

http://www.mikrotik.com/thedude.php

http://wiki.mikrotik.com/wiki/Dude_usage_notes

Thanks Obiwan!! ;-)

Anuncio:El libro online "TCP/IP Fundamentals for Microsoft Windows" está completo.

juansa — Wed, 31 May 2006 12:09:00 GMT

Nuestro amigo y gran escritor técnico Joseph Davies ha anunciado en los grupos que el libro online "TCP/IP Fundamentals for Microsoft Windows" está completo en: http://www.microsoft.com/technet/itsolutions/network/evaluate/technol/tcpipfund/tcpipfund.mspx

del que además se dispone de un PDF de todo el libro, descargable desde: http://www.microsoft.com/downloads/details.aspx?FamilyID=c76296fd-61c9-4079-a0bb-582bca4a846f&displaylang=en

Aunque en inglés, considero que es una guía indispensable e interesantísima.

Desde aquí le doy la enhorabuena y le agradezco el tiempo que le ha dedicado a este libro.

Una mirada rápida a dos dispositivos Hub vs Switch

juansa — Mon, 23 Jan 2006 19:03:00 GMT

Hub(Concentrador) vs Switch(Conmutador)

Para entender las diferencias entre ambos dispositivos hemos de conocer la división en capas de las redes, según el estándar ISO-OSI.
Son siete las capas definidas, llamadas: Nivel físico, Enlace de datos, Red, Transporte, Sesión, Presentación y Aplicación.

Los distintos elementos de una red pues, se ubican en distintas capas de la red.
Enrutadores (router) suelen trabajar en la capa de red.
conmutadores(Switch) se situan en la capa de Enlace de datos.
Concentradores(Hub) trabajan en la capa física.

HUB
Su función es repetir las tramas que le llegan a todos los dispositivos conectados a él.

Es un concentrador, simplemente une conexiones sin alterar las tramas que le llegan.
Cuando envía información lo hace sobre todos, por lo que se incluye a destinatarios no interesados. Aquí sólo hay un destino, pero el hub lo envía a todos para asegurarse que lo recibe el que corresponde.
El tráfico es mayor que el necesario y con ello se generan más probabilidades de colisión.
El dispositivo siempre trabaja a la velocidad del dispositivo más lento de la red. Por ejemplo, nuestro router ADSL funciona a 10Mb, una vez conectado a nuestra red casera mediante un hub dará lo mismo que tengamos una red de 100Mb, toda la red funcionará a 10.
Es un dispositivo bastante simple, eso hace que sea económico y que no añada retardo a la información.

SWITCH
El switch recibe la trama desde un equipo, consulta su tabla de direcciones MAC, almacena la trama y la envía a su destinatario.

El conmutador conoce las direcciones MAC que tiene conectadas a cada uno de sus puertos. Al principio le son desconocidas, las va aprendiendo conforme va pasando información a través de él. Si la MAC no está en su tabla, entonces se comporta como un HUB y manda la trama por todos sus puertos. Si hay más de un equipo conectado a uno de sus puertos y aprendidas sus direcciones MAC, si existe información entre éllos el switch no la propaga fuera, es decir, la filtra.
El conmutador almacena la trama antes de reenviarla, store & forward (*hay algunos otros métodos), controlando el CRC de las tramas para comprobar que no haya error, en tal caso la descarta para no crear tráfico innecesario. Normalmente puede adaptar distintas velocidades entre dispositivos.
Puede tener 'auto Negotation', negocia con los dispositivos la velocidad, o el modo (full, half-duplex).

Herramientas Networking: resumen

juansa — Fri, 20 Jan 2006 09:53:00 GMT

Lo primero es comprobar la configuración TCP/IP en el equipo en el que se nos plantea el problema. Con el comando ipconfig /all, o winipcfg si es un windows 9x/Me, obtenemos la configuración.

Al utilizar el parámetro /ALL se obtiene la configuración de todas las interfaces, incluídos puertos série configurados, detalladamente. Podemos redirigir la salida del comando a un archivo de texto, ipconfig /ALL > archivo.txt, por si queremos pegarla en algún documento o imprimirla, etc...

Por ejemplo, si el equipo tiene una IP duplicada en la red la máscara de subred aparecerá como 0.0.0.0.

Si no se observan anomalías en la configuración, entonces podemos probar la conectividad con otros equipos de la misma red; actualizar la configuración con el parámetro renew de ipconfig (ipconfig /renew), o liberar la actual con /release.

Podemos utilizar ipconfig también para mostrar o restablecer la caché DNS, actualizar nombres registrados, mostrar los ID de clase DHCP de un adaptador, establecerlos.

Probar las conexiones con el comando PING.
- Ping a 127.0.0.1 para comprobar que TCP/IP está instalado correctamente.
- Ping a la IP local para ver que está en a red correctamente.
- Ping a la puerta de enlace predeterminada para comprobar la comunicación con un equipo en la red local.
- Ping a cualquier equipo remoto para comprobar que puede comunicarse a través de enrutador.

Ping utiliza resolución de nombres, si el ping devuelve IP pero no nombre, posiblemente exista un error en la resolución y no en la conectividad de la red.
Si no funciona en ningún caso, comprobar que:
- Hemos reiniciado el equipo después de instalar/configurar TCP/IP.
- La IP es válida y aparece en el cuadro de diálogo de las propiedades del protocolo TCP/IP de la conexión.
- El enrutamiento funciona entre enrutadores.

Con ARP (Address Resolution Protocol) podemos obtener la IP de acceso a recursos en otro host en la misma red física. Con el comando ARP podemos ver y/o modificar las entradas de la propia tabla ARP en el equipo local. Nos será útil para ver la caché de ARP y resolver problemas en la resolución de nombres.

Con nbtstat podremos solucionar problemas de nombres NetBios. NetBIOS resuelve nombres NetBIOS en IPs. Tenemos diversas opciones para dicha resolución: búsqueda en la caché local, consulta servidores WINS, DNS, difusión y búsqueda en LMHOSTS y HOSTS.
Esta herramienta nos puede servir para quitar o corregir entradas existentes.

Con el comando tracert podemos determinar el camino de un paquete y si ha sido detenido en algún punto de la red, con lo que obtendremos la información necesaria para saber si la configuración de encaminamiento es incorrecta. (comando ROUTE)
Normalmente nos será muy útil en redes grandes con múltiples posibilidades de rutas.

Con Pathping (combina características de ping y tracert) podremos probar los enrutadores, con lo que determinaremos que enrutadores o vínculos podrían estar causando problemas.

Herramientas Networking: Tracert

juansa — Tue, 17 Jan 2006 11:36:00 GMT

Dentro de las utilidades de TCP/IP nos encontramos con la herramienta 'tracert' que nos servirá para determinar el encaminamiento de los paquetes por la red hasta el destino que queramos. El comando incrementa el tiempo de vida o TTL en cada paquete que se va enviando. Cuando el paquete llega a un host, éste decrementa el TTL en uno, reenviándolo al siguiente host. Si el TTL del paquete alcanza el valor 1 al llegar a un host, lo descarta y envia el mensaje de 'tiempo excedido'. Tracert puede ayudarnos a encontrar sitios en nuestra red que encaminan defectuosamente o que no están presentes.

Utiliza el protocolo de internet (IP) para seguir el rastro del paquete desde un origen a su destino, determinará la ruta por donde se le encamina, apoyándose en ICMP para éllo.

Para usar el comando 'tracert' sólo debemos conocer la dirección IP el destino. Abrimos un cmd, tecleamos tracert IP_destino y pulsamos enter Tracert manipulará el TTL incrementándolo y entonces cada encaminador lo decrementará y reenviará hacia otro encaminador, manteniendo una cuenta de saltos desde el origen. Un salto será el reenvío desde un encaminador a otro encaminador. En cuanto el TTL del paquete llegue a 0, el encaminador enviará un ICMP de 'time exceeded' al origen.

Uso: tracert [-d] [-h máximo_de_saltos] [-j lista_de_hosts] [-w tiempo_de_espera] nombre_de_destino

Opciones:

-d No convierte direcciones en nombres de hosts.

-h máximo_de_saltos Máxima cantidad de saltos en la búsqueda del objetivo.

-j lista-de-host Enrutamiento relajado de origen a lo largo de la lista de hosts.

-w tiempo_de_espera Cantidad de milisegundos entre intentos.

Internet Control Message Protocol (ICMP) Basics http://support.microsoft.com/kb/170292/EN-US/

How to Use TRACERT to Troubleshoot TCP/IP Problems in Windows http://support.microsoft.com/kb/314868/en-us http://support.microsoft.com/kb/162326/en-us

IPv6 Tracert Info http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/7707957f-68a9-45b8-a3a7-abae340bd179.mspx

Tracert on MSDN

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcecomm5/html/wce50lrfTracert.asp

RFC 792 (ICMP) http://www.faqs.org/rfcs/rfc792.html

Herramientas Networking: Route

juansa — Mon, 16 Jan 2006 11:44:00 GMT

Route El comando puede mostrar y modificar la tabla de enrutamiento. Si no se utilizan parámetros nos muestra la ayuda. route [-f] [-p] [comando [destino] [mask máscaraDeSubred] [puertaDeEnlace] [metric métrica]] [if intefaz]]

Opciones	Comentario
-f	Elimina las entradas que no sean rutas de hosts(máscara de subred 255.255.255.255), ruta de bucle local (destino 127.0.0.0/8) o ruta de multidifusión (destino 224.0.0.0/6). Si se usa junto a Add, Change o Delete, la tabla de borra antes de la ejecución del comando.
-p	Junto a Add agregará la ruta especificada al Registro y se utilizará para iniciar la tabla cada vez que se inicie el protocolo TCP/IP. Predefinidamente las rutas agregadas no se conservan al iniciar el protocolo. Si se usa con PRINT, mostrará las rutas persistentes. En el resto será ignorado. Las rutas persistentes se almacenan en la ubicación del Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PersistentRoutes.
comando	especifica el comando
comando	propósito
Suma	Añade una ruta
change	Cambia una ruta existente
delete	Elimina una o varias rutas
print	Imprime o muestra una o varias rutas

Destino: red destino de la ruta.(Una IP de red, una IP de host o, 0.0.0.0 como predeterminada) mask máscaraDeSubred: máscara asociada a la red de destino. Apropiada a la IP de red, para una ruta de host(255.255.255.255) o 0.0.0.0 para la ruta predeterminada. si no se especifica se utiliza 255.255.255.255. El destino no puede ser más específico que su máscara de red.

Puerta de enlace: IP por la que se llega a las direcciones de la red destino.

metric métrica: Entero que específica la métrica de coste de la ruta(entre 1 y 9999), se utiliza para elegir entre varias rutas de la tabla que contienen la ruta destino, se elige la métrica más baja.

if interfaz: Especifica el índice de la interfaz a través de la que se llega al destino. Con route print podemos conocer la lista de interfaces y su índice. Para utilizar valores hexadecimales, usa 0x delante del valor. Si se omite if, la interfaz está determinada por la puerta de enlace.

/? Muestra Ayuda en el símbolo del sistema.

Notas

• Los valores altos de la columna metric de la tabla de rutas son el resultado de permitir que TCP/IP determine automáticamente la métrica de las rutas de la tabla de rutas basándose en la configuración de la dirección IP, máscara de subred y puerta de enlace predeterminada de cada interfaz de LAN. La determinación automática de la métrica de la interfaz, habilitada de forma predeterminada, determina la velocidad de cada interfaz y ajusta las métricas de las rutas en cada interfaz de modo que la interfaz más rápida tenga las rutas con valores de métrica más bajos. Para eliminar dichas métricas altas, deshabilite la determinación automática de la métrica de las interfaces en las propiedades avanzadas del protocolo TCP/IP en todas las conexiones LAN.

• Se pueden utilizar nombres en destino si existe la entrada apropiada en el archivo Networks local, que se encuentra en la carpeta raízDelSistema\System32\Drivers\Etc. Se pueden utilizar nombres en puertaDeEnlace mientras se puedan resolver en direcciones IP mediante las técnicas de resolución de nombres de hosts estándar, como consultas DNS, el archivo Hosts local que se encuentra en la carpeta raízDelSistema\system32\drivers\etc y la resolución de nombres NetBIOS.

• Si el comando es print o delete, se puede omitir el parámetro puertaDeEnlace y se pueden utilizar comodines para el destino y la puerta de enlace. El valor destino puede ser un valor comodín especificado por un asterisco (*). Si el destino especificado contiene un asterisco (*) o una interrogación (?), se trata como comodín y sólo se imprimen o se eliminan las rutas de destino que coincidan. El asterisco representa cualquier cadena de caracteres, y el signo de interrogación representa cualquier carácter individual. Por ejemplo, 10.*.1, 192.168.*, 127.*, y *224* son usos válidos del asterisco como comodín.

• El uso de una combinación no válida de destino y máscara de subred muestra el mensaje de error "Route: bad gateway address netmask". Dicho mensaje de error aparece cuando el destino contiene uno o varios bits establecidos a 1 en ubicaciones de bit en las que la máscara de subred correspondiente contiene 0. Para probar esta situación, exprese el destino y la máscara de subred empleando la notación binaria. En notación binaria, la máscara de subred consiste en una serie de bits 1, que representan la parte de dirección de red del destino, y una serie de bits 0, que representan la parte de dirección de host del destino. Compruebe y determine si hay bits en el destino establecidos a 1 en la parte de su dirección que es la dirección de host (como está definido en la máscara de subred).

• El parámetro -p sólo se acepta en comandos de rutas en Windows NT 4.0, Windows 2000, Windows Millennium Edition, Windows XP y la familia Windows Server 2003. El comando route no acepta dicho parámetro en Windows 95 o Windows 98. • Este comando sólo está disponible si el Protocolo Internet (TCP/IP) está instalado como componente en las propiedades de un adaptador de red en Conexiones de red.

Ejemplos

Para mostrar todo el contenido de la tabla de rutas IP, escriba: route print

Para mostrar las rutas de la tabla de rutas IP que empiezan por 10., escriba: route print 10.*

Para agregar una ruta predeterminada con la dirección de puerta de enlace predeterminada de 192.168.12.1, escriba: route add 0.0.0.0 mask 0.0.0.0 192.168.12.1

Para agregar una ruta al destino 10.41.0.0 con la máscara de subred 255.255.0.0 y con la dirección del salto siguiente 10.27.0.1, escriba: route add 10.41.0.0 mask 255.255.0.0 10.27.0.1

Para agregar una ruta permanente al destino 10.41.0.0 con la máscara de subred 255.255.0.0 y con la dirección del salto siguiente 10.27.0.1, escriba: route -p add 10.41.0.0 mask 255.255.0.0 10.27.0.1

Para agregar una ruta al destino 10.41.0.0 con la máscara de subred 255.255.0.0, la dirección del salto siguiente 10.27.0.1 y una métrica de 7, escriba: route add 10.41.0.0 mask 255.255.0.0 10.27.0.1 metric 7

Para agregar una ruta al destino 10.41.0.0 con la máscara de subred 255.255.0.0, la dirección del salto siguiente 10.27.0.1 y utilizando la interfaz cuyo índice es 0x3, escriba: route add 10.41.0.0 mask 255.255.0.0 10.27.0.1 if 0x3

Para eliminar la ruta al destino 10.41.0.0 con la máscara de subred 255.255.0.0, escriba: route delete 10.41.0.0 mask 255.255.0.0 Para eliminar todas las rutas de la tabla de rutas IP que empiezan por 10., escriba: route delete 10.*

Para modificar la dirección del próximo salto de la ruta al destino 10.41.0.0 con la máscara de subred 255.255.0.0, de 10.27.0.1 a 10.27.0.25, escriba: route change 10.41.0.0 mask 255.255.0.0 10.27.0.25