Enrutamiento de NetBioS
Se
puede enrutar NetBioS de estas maneras:
1.- Ficheros LMHOSTS en cada equipo
que no tenga un servidor WINS en sus propiedades,
con las entradas de los equipos de los otros segmentos de red, al menos (las
de su propio segmento las puede "cazar" él haciendo difusiones).
Requiere mucho trabajo de administración y es impracticable en entornos
configurados por DHCP. Como ventaja el nulo uso de
la red, tanto LAN (si en los ficheros LMHOSTS
están las entradas de los equipos del segmento de red propio) como WAN,
para la resolución de nombres.
2.- Servidor WINS en la central y
situar en las sucursales un cliente configurado como Proxy de WINS
y el resto de clientes como nodo B (Broadcast). Tiene como ventaja
que al consultar un servidor WINS, esto posibilita
el uso de DHCP. Hace un uso de la conexión
WAN no optimizado (cada consulta que se realiza debe
ser respondida por la central) y los clientes trabajan siempre haciendo broadcast.
Válido si no hay demasiados equipos en la red (más de 50), pues
si los hay, la LAN estará llena de "ruido"
y habrá mucho tráfico para resolución NetBIOS
a través de la conexión a la WAN.
La configuración de los clientes como Proxys de WINS depende del Sistema
Operativo del cliente:
121004
- WINS Proxy Agent Functionality
http://support.microsoft.com/default.aspx?scid=kb;en-us;121004
164765
- How to Enable WINS Proxy Agent in Windows NT 4.0
http://support.microsoft.com/default.aspx?scid=kb;en-us;164765
3.- Instalar un servidor WINS en
la central y en cada sucursal y hacerlos socios de replicación push/pull
en una configuración de estrella (generalmente es lo deseable), siendo
el centro de la estrella el servidor WINS de la central.
Los clientes estarán configurados para consultar al servidor WINS
de su propia sucursal. Esta disposición es la ideal, pues permite DHCP,
no requiere apenas administración el mantenimiento de los nombres NetBios
y además el uso de las conexiones, tanto LAN
como WAN está optimizado, pues los clientes
estarán en modo hibrido y por ello se minimizan las difusiones (broadcast)
y sólo se realizarán consultas de nombres en el propio segmento
de red (las consultas serán en unicast hacia el servidor WINS
del segmento propio y la conexión WAN sólo
será utilizada para las réplicas entre servidores WINS,
no para la resolución de nombres).
Su única desventaja es que es necesario un Windows 2000 Server
en cada oficina, cosa que las anteriores soluciones no requiren.
4.- Usar una mezcla de las soluciones 2 y 3. Según el
número de equipos en una sucursal, se instalará un servidor WINS
o un Proxy de WINS; se podrían utilizar los
ficheros LMHOST en una sucursal y crear las entradas
de los equipos de esa sucursal, de forma manual, en el servidor WINS
central, pero me parece absurdo por que ¿no será mejor la solución
2, que te permine tener asignación dinámica de IP's, cambiar la
IP de un servidor y que el cambio lo reciban de forma automática, sin
gasto alguno administrativo?.
Para decidirse hay dos parámetros fundamentales:
1.- Tamaño de la red: si las oficinas
tienen tres equipos cada una, te puedes ahorrar el Server y pones a un cliente
como Proxy de WINS; en cuanto tengas una red mayor (digamos 15 ó más
equipos en cada oficina), si no gastas el dinero de un server, pagarás
mucho más con el tremendo TCO (Total Cost
Ouwnership) que se te va a generar, con lo que sería pan para hoy
y hambre para mañana.
2.- Dinamismo de cambios en la red: si los
nombres de los equipos son inamovibles, lo mismo que sus IP's, etc., y apenas
hay altas y/o bajas en el parque informático, se podría, en un
empujón de trabajo inicial, crear los LMHOSTS, verificarlos y distribuirlos.