SOBRE REDES - (PARTE II)

H0l@,

Aqui les dejo la segunda parte del texto. Interesante no!.


SOBRE REDES - (PARTE II)
---------------------------------------
Vamos a matizar un par de excepciones que suceden con el mecanismo de 'Autonet Configuration' que vimos en el artÍculo anterior. Recordemos que comentábamos que cuando no existe dirección IP, y además no existe un servidor DHCP (servidor de direcciones IP) en la red, Windows se autoasignaba una dirección en clase B en el rango 169.254.x.y.

Esto es estrictamente correcto en W98 y W98SE. Pero Windows ME y Windows 2000, incorporan además
la detección de señal en el cable de red. Es decir, si no detectan señal de red en el cable, bien porque el cable está desconectado, o bien, por ejemplo porque es un cable RJ45 cruzado y está conectado a otro PC que está apagado, en ese caso, al detectar falta de señal, no inicializa el adaptador de red y por tanto no le asigna dirección.

En el momento en que detecte señal:

1) Si está configurada una direccion IP en el adaptador, tomará esta.
2) si no, automáticamente buscará un servidor DHCP. Si lo encuentra, le pide una direccion IP.
3) Si no lo encontrase, mira a ver si ya tenía una licencia de préstamos de direccion IP anterior y no está caducada. Si es así, se autoasigna esa última direccion IP.
4) En caso contrario, entra a funcionar el mecanismo de 'autonet configuration'.

En W2000, el no detectar señal de red, implica que nos mostrará un icono en la parte izquierda de la barra de tareas, indicando el corte de señal de red.

En Windows Milennium, al arrancar el PC, la pantalla de logon, en vez de mostrar dos ordenadores unidos en red, nos mostrará simplemente un juego de llaves. Esto indica que no ha detectado señal de red.

Este último punto, he podido comprobar que no está muy "fina" su implementación en Windows Millennium, y muchas veces, la autodetección de señal de red falla. Por ello, mi consejo en Windows ME, es que marquemos en las propiedades de la red (Panel de Control->Red) en el adaptador de red, que *no* detecte señal de red. En este caso, asignará direccion IP siempre siguiendo la filosofía de los 4 puntos vistos anteriormente. Aunque no he visto este bug documentado por Microsoft, he podido verificarlo en distintas ocasiones.

NOTA: Un PC unido a un 'switch' (o un router, por ejemplo), siempre detecta señal de red aunque no existan más PC's conectados. Recordemos que un switch o un router, es un dispositivo inteligente y configurable y por tanto siempre suministra señal de red.


BUGS'S RECONOCIDOS EN LA KB
--------------------------------------------

* En W95, W98, W98SE y ME: tanto en la conexión directa por cable como en la comunicacion por módem en directo entre dos PC's (servidor de acceso telefónico), es necesario instalar además del TCP/IP, otro protocolo como el NetBeui o el IPX, al objeto de que funcione el NetBios sobre TCP/IP (es decir, para que sea capaz de ver los servicios en el 'Entorno de red'). Independientemente de los protocolos anteriores, la comunicación posteriormente se ejecuta siempre via TCP/IP.

* En W95: no puede utilizarse simultáneamente la conexión directa por cable y la comunicación vía módem. Esto es debido a que comparten la VxD: pppmac.vxd y esta no está preparada para ser invocada más de una vez por un servicio. (Nota: aunque en la documentación de MS, este problema se ciñe a W95, he comprobado que también sucede, al menos en las pruebas realizadas, en toda la serie W9X, incluido ME).

* En W2000, algunos servicios específicos requieren que el PC tenga dirección IP. Recordemos, que podemos no tener dirección IP, bien porque no tenemos tarjeta de red, o bien porque el cable está desconectado o no detecta señal de red. En este caso, en W2000, podemos instalar el adaptador de red 'MS Loopback' (adaptador de lazo invertido). Este es una tarjeta 'virtual' de red y por tanto le asignará,o le podremos asignar, dirección IP. Se utiliza precisamente para evitar problemas con dichos servicios.


PASOS PREVIOS A SEGUIR PARA DIAGNOSTICAR UN PROBLEMA DE RED
-----------------------------------------------------------------------------------------------

Los pasos que vamos a describir, son obligados y deben verificarse y comentarse sus resultados antes de describir cualquier problema de red. El informar de que puntos anteriores son o no correctos siempre da una pista sobre en dónde puede existir un problema de conectividad.

* Utilizar siempre los últimos drivers del fabricante. No siempre los que monta W2000 son correctos o funcionan correctamente con todo el hardware. Por ejemplo las tarjetas con chip Realtek, dan problemas en muchas combinaciones de hardware. En este caso, lo primero sería instalar drivers del fabricante (en este ejemplo, los últimos drivers desde www.realtek.com.tw)

* Asegurarse previamente de que:

a) ambos PC's tienen nombres de PC diferentes,
b) pertenecen al mismo grupo de trabajo y
c) al menos tenemos un servicio de red compartido en cada PC.

Supongamos dos PC's conectados en red y en los cuales tenemos problemas. En este caso, y en cada uno de los PC's, debemos verificar, y en el siguiente orden: (con un PC que esté en el mismo segmento de red, es decir que sea 'alcanzable' a través de la máscara, tal y como vimos en la parte anterior):

1) ping 127.0.0.1
2) ping x.y.z.t (siendo x.y.x.t la direccion IP del otro PC. Recordemos que el comando ipconfig/all nos muestra la dirección IP en cada adaptador de red)
3) ping nombre_PC (siendo nombre_PC el nombre del "propio PC")
4) ping nombre_otro_PC (siendo nombre_otro_PC el nombre de otro PC de la red).

* Si falla el punto 1) indica que el stack IP está mal instalado. En este caso:

A) Se debe dar de baja todos los servicios, clientes y protocolos de la red. NO reiniciar el PC aunque lo solicite el sistema.
B) En el Administrador de Dispositivos dar de baja la tarjeta de red. reiniciar ahora.
C) Al reiniciar, detectará la tarjeta de red e instalará el tcp/ip y el Cliente para redes Microsoft. En la serie W9X, añadir el servicio de compartir archivos e impresoras.

En este punto, el stack IP debe estar operativo.

* Si falla el punto 2), aplicar lo mismo que acabamos de ver en el punto anterior.

* Si falla el punto 3), no existe resolución de nombres. Esto indica que no se ha instalado correctamente (o se ha deshabilitado) el NetBios sobre TCP/IP. Intentar resolverlo aplicando los puntos A) a C) anteriores.

* Si falla el punto 4) debemos verificar:

A) Si estamos en W2000, verificar que en las propiedades del TCP/IP en la conexion de red, en la pestaña de WINS, está activado el NetBios sobre TCP/IP.

B) Si es un PC de la serie W9X, evidentemente también indica que alguno de los PC's (o todos) han tenido algún problema serio en su instalación. Si no queremos instalar de nuevo, el problema puede solucionarse si en el servicio de compartir archivos e impresoras, seleccionamos 'propiedades' y el valor de 'Examinador Principal' (Browser Master) que estará en "Auto", ponerlo en "Sí". De todas maneras, aunque esta solución (workaround), funcione, entiendo que no es la solución adecuada.

** Si los 4 puntos anteriores funcionan, debemos ser capaces de ver en el entorno de red los servicios de los PC's de nuestra subred. Si a pesar de estar correcto lo anterior, seguimos sin ver el resto de PC's en el entorno de red, podemos intentar teclear en una ventana MSDOS:

start \\x.y.z.t
start \\nombre_otro_PC

siendo x.y.z.t la direccion IP de otro PC. Se nos debe abrir una ventana y ver los servicios compartidos.

** En caso de segmentos fuera de nuestra subred local, ya veremos en un artículo posterior cómo debemos configurar nuestra red.

VENTAJAS E INCOVENIENTES DEL 'AUTONET CONFIGURATION' - (PARTE III)
--------------------------------------------------------------------
Hemos visto el mecanismo por el cual los sistemas operativos W98 o superior y W2000 o superior, se pueden autoasignar direcciÓn IP y por tanto liberan al usuario de una administracion y configuración de la red.

Como ventajas, podemos citar precisamente la anterior. No es necesario saber nada de direcciones, máscaras, subredes, etc. Esto es un arma de doble filo: evidentemente para el usuario doméstico es una ventaja..... si no se dedica a 'jugar' y no anda toqueteando nada de la configuración. Esto último bastante improbable con el tiempo debido a que Internet está lleno de 'sabios' consejos de optimización, configuración, programas aceleradores, etc, que lo único que consiguen es dar dolor de cabeza a un Administrador de Redes. Y si a un experto de verdad, le cuesta dejar la red correctamente en este situación, a un usuario doméstico no le quedará otro remedio que instalar desde cero.

Además del comentario anterior, que creo que merece un profunda reflexión sobre todo lo que podamos leer y oir, y poner en tela de juicio cualquier comentario antes de intentar experimentarlo en nuestro PC, el problema de 'Autonet' también es un problema de tiempos de arranque.

Me explico: el proceso de autoasignarse dirección IP debe ser un proceso 'rígido' y conforme a las especificaciones de las RFC en las cuales está definido todo el protocolo TCP/IP. Por tanto, una vez que el PC decide autoasignarse dirección, lo primero que debe verificar es que dicha dirección no exista en la subred local. Para ello, existe un protocolo (ARP) de comunicaciones dentro del TCP/IP que permite dialogar con la red sin tener todavía direccion IP.

Mediante el ARP, el PC verifica que la direccion en clase B, en el rango 169.254.x.y que se acaba de 'inventar', no está en la red. Pero esta verificación no es inmediata. Debe realizar la verificación 3 veces. Debe esperar un tiempo prederminado (definido en la correspondiente RFC) entre una verificación y la siguiente.

Recordemos además, que antes de decidir autoasignarse direccion IP, debe verificar que no exista un servidor DHCP en la red. Esta verificación debe hacerse también 3 veces y esperar un tiempo predeterminado entre una verificación y la siguiente (todo de acuerdo con las definiciones dadas en la correspondiente RFC).

En resumen, nos vamos a unos 20-30 segundos de verificaciones. (todo esto en W9X. En W2000 que es capaz de establecer ciertos servicios y por tanto arrancar sin necesidad de IP no se nota tanto esta demora).

Por tanto, para evitarnos en W9X y Windows ME esta demora, y que nuestro PC arranque medio minuto antes, podemos simplemente asignar a mano las direcciones IP de nuestra red.

Si tuviesemos ICS (conexion compartida a Internet), no es necesario al proceso que vamos a describir a continuación, ya que la máquina que actúa de servidor de Internet tiene una dirección fija: 192.168.0.1. Y además actúa de servidor DHCP en clase C en el rango de direcciones 192.168.0.x para el resto de los PC's de la red.

Si no tenemos ICS, para evitar dicha demora en el arranque, podemos asignar a mano direcciones IP a cada PC de la red. Debemos escoger direcciones que sean reservadas en Internet para las redes locales y así asegurarnos de que no existirán conflictos de red.

Por ejemplo, podemos asignarnos:

* En clase C (es decir: máscara 255.255.255.0) las direcciones 192.168.0.x
* En clase B (es decir: máscara 255.255.0.0) las direcciones 169.254.x.y
* En clase A (es decir: máscara 255.0.0.0) las direcciones 10.x.y.z


SOBRE REDES LOCALES: LAN, WAN, INTERNET, ETC.
---------------------------------------------------------------------

Hasta el momento, hemos estado hablando de nuestra subred y no hemos mencionado el resto de dispositivos (routers, gateways, hub, switch, etc...) que pueden (y suelen) intervenir en una red. Por ello, hemos insistido también en el protocolo NetBios y 'a propósito' he evitado hablar de otras de las soluciones 'chapuceras' que muchas veces se dan para resolver problemas: ficheros 'HOSTS', 'LMHOSTS', etc.

Vamos a repasar, intentándolo de una manera sencilla, el qué es una red, y vamos a irla 'complicando' un poquito. Vamos a ceñirnos igualmente a la topología de red Ethernet (la más corriente y sencillita, y de paso, la más extendida).

La red más sencilla que existe es evidentemente 2 PC's unidos por un cable de red en directo. Para ello, únicamente necesitamos 2 PC's, dos tarjetas de red y un cable RJ45 'cruzado'.

Cuando unimos dos PC's en directo (sin pasar por HUB o por SWITCH), es necesario cruzar dos hilos de la conexión. Por ello, a dicho tipo de cable, se le llama 'cruzado' (crosslinked).

En el momento en que queremos hacer convivir más de dos PC's en nuestra red, necesitamos una especie de distribuidor al cual vayan conectados todos los PC's. Estos 'distribuidores' son los HUB o los SWITCH. El HUB es el modelo más sencillo, y el SWITCH es similar pero admite configuraciones mediante software. Más adelante trataremos este tema.

Estos 'distribuidores' pueden ser de 4, 8, 16, etc 'bocas' de conexión. Igualmente, algunos de estos modelos se pueden interconectar entre sí en cascada, aumentando por tanto la capacidad de nuestra red.

* Si nuestra red está constituida físicamente de la manera anterior, es lo que se conoce como una LAN. En estas LAN, lo normal es asignar direcciones IP de tal manera que todos los PC's sean alcanzables entre sí. Es decir, por ejemplo todos en la clase A citada anteriormente en el rango 10.x.y.z.

* Si esta red tiene protocolo TCP/IP únicamente, es decir el caso normal hasta hace unos años en los cuales no existía ningún 'Cliente' explícito de redes como puede ser el 'Cliente para redes Microsoft', o bien el caso normal de Internet que no admite ningún 'Cliente', entonces los 'servicios' que pueden darse son el ftp, web, news, gopher, etc.

Es decir los protocolos clásicos del TCP/IP. En estos caso, evidentemente no se puede ni soñar con lo que actualmente estamos acostumbrados desde el 'Entorno de Red' o incluso desde el mismo 'Explorador'. Pero esta es un red clásica TCP/IP. Así de sencillo (o complicado, como queramos definirlo...)

* Sobre este protocolo, existía en una RFC la casuística necesaria para encapsular el protocolo NetBios (definido por IBM a mediados de los 80). Esta encapsulación y utilizando los Clientes Lan Manager (también de IBM), es la que utilizó Microsoft para su 'Cliente de redes Microsoft' y es la que permite, a través de ese cliente, el poder examinar la red y asignarse recursos de ella.

* Pero... y siempre hay un 'pero', el Netbios, en principio no es 'enrutable'. Vamos a definir primero el concepto de 'Router'.


ROUTERS
-------------

Los 'routers' o 'encaminadores' no son nada mÁs que mÁquinas o dispositivos que unen dos segmentos de red de los que hemos visto antes. Por ejemplo, supongamos que nuestra red es una del tipo:

10.x.y.z (con mascara 255.0.0.0) y que existe otra red (de un vecino nuestro, por ejemplo), del tipo 192.168.0.x (con mÁscara 255.255.255.0) y que queremos unirlas.

Bien, para ello existen los routers. Por decirlo de una manera 'grosera' un router es una máquina con dos tarjetas de red y que permitirá la conexion de las redes anteriores.

Evidentemente, esa máquina puede ser una máquina 'tonta' o puede ser un PC con dos tarjetas de red.

* Aunque hemos dicho que puede ser una máquina 'tonta', no es del todo exacto. Los 'routers' nunca son tan tontos (aunque no sean un PC). Los 'routers' necesitan una pequeña CPU y una configuración, y unas tablas de encaminamiento -que veremos mas adelante- y además ser capaces de 'filtrar' o dejar pasar ciertos tipos de protocolos de red. Por tanto, y aunque ni tengan 'monitor' ni 'teclado', siempre se pueden configurar mediante algun programa de emulación de terminal (telnet) que describiremos más adelante.

Imaginemos un router configurado para unir nuestra red y la de nuestro vecino que hemos citado anteriormente. Evidentemente, unidos estarán... pero ahora ¿como podemos ver los PC's de nuestro vecino?....

En principio, el TCP/IP funciona: un ping desde una maquina nuestra a la otra red responde. Pero no 'vemos' los PC's en el entorno de red. Y además si damos un ping por dirección IP fuciona, pero por nombre no, ¿por qué?

* Es sencillo: simplemente porque el protocolo TCP/IP 'puro' sólo entiende de direcciones y no de nombres (en principio). Además, curiosamente, los routers no dejan pasar (por defecto) el tráfico NetBios, y esto último es totalmente lógico. El NetBios está constantemente transmitiendo (aunque no estemos haciendo nada) información por la red.

Los PC's se están avisando entre ellos constantemente de los servicios que tienen disponibles, envian señales a toda la red (este tipo de señales a toda la red, se llama 'broadcasting') avisando de su existencia, etc....

* Es lógico que estas señales se 'filtren' en los routers. Si no se hiciese así, al final nuestra red estaría llena de 'ruido' de nuestros propios PC's y del resto de PC's de las otras redes a que estuviésemos conectados. El 'broadcasting' en una red es uno de los 'males' que debemos pagar por utilizar herramientas de alto nivel ('Clientes' que nos permiten manejar la red de una manera cómoda).

Good Luck


Dino


PD: Si te gusto solo deja tu comentario