Recordar� de nuestra breve descripci�n de los protocolos utilizados
en un entorno IPX que IPX es un protocolo encaminable y que el
Protocolo de Informaci�n de Encaminamiento (Routing Information Protocol,
RIP) se utiliza para propagar la informaci�n de encaminamiento. La
versi�n IPX de RIP es bastante parecida a la versi�n IP. Funcionan
esencialmente de la misma manera; los encaminadores difunden
peri�dicamente los contenidos de sus tablas de encaminamiento y otros
encaminadores los recogen escuchando e integrando la informaci�n que
reciben. Los nodos s�lo necesitan saber cu�l es su red local y
asegurarse de enviar datagramas al resto de destinos a trav�s de su
encaminador local. El encaminador es responsable de recoger estos
datagramas y redirigirlos al siguiente salto de la ruta.
En un entorno IPX, hace falta propagar por la red una segunda clase
de informaci�n. El Protocolo de Anuncio de Servicio (Service
Advertisement Protocol, SAP) transporta informaci�n sobre qu�
servicios est�n disponibles en qu� nodos de la red. Por ejemplo, es
el protocolo SAP el que permite a los usuarios obtener listas de
servidores de ficheros o de impresi�n de la red. El protocolo SAP
trabaja haciendo que los nodos que proporcionan servicios difundan
peri�dicamente la lista de servicios que ofrecen. Los encaminadores
de la red IPX recogen esta informaci�n y la propagan por toda la red
junto con la informaci�n de encaminamiento de la red. Para ser un
encaminador IPX compatible, hay que propagar tanto la informaci�n RIP
como la SAP.
Al igual que IP, el soporte de IPX en Linux proporciona un demonio
de encaminamiento llamado ipxd que realiza las
tareas asociadas al tratamiento del encaminamiento. De nuevo, igual
que en el IP, es en realidad el n�cleo el que administra el
redireccionamiento de los datagramas entre las interfaces de red
IPX, pero lleva a cabo esto de acuerdo con un conjunto de reglas
recogidas en la tabla de encaminamiento IPX. El demonio
ipxd mantiene actualizado ese conjunto de reglas
escuchando a todas las interfaces de red activas y analizando
cu�ndo es necesario un cambio de encaminamiento. El demonio
ipxd tambi�n responde a las peticiones de los
nodos de una red conectada directamente que piden informaci�n de
encaminamiento.
El programa ipxd est� disponible preempaquetado en
algunas distribuciones, y en forma de c�digo fuente mediante FTP
an�nimo a http://metalab.unc.edu/ en el fichero
/pub/Linux/system/filesystems/ncpfs/ipxripd-x.xx.tgz.
No es necesario configurar el demonio ipxd. Cuando
es lanzado, �l autom�ticamente administra el encaminamiento de los
dispositivos IPX que han sido configurados. La clave est� en asegurarse
de que todos los dispositivos IPX est�n configurados correctamente
utilizando la orden ipx_interfaces antes de lanzar
ipxd. Aunque la autodetecci�n puede funcionar, cuando
est� haciendo funciones de encaminamiento es mejor no correr riesgos,
as� que configure manualmente las interfaces y ah�rrese problemas de
encaminamiento molestos. Cada 30 segundos, ipxd
reinspecciona todas las redes IPX enganchadas y las administra
autom�ticamente. Esto proporciona una manera de administrar redes
en interfaces que pueden no estar activas todo el tiempo, como las
interfaces PPP.
Normalmente ipxd es lanzado en tiempo de inicio desde
un script de inicio rc como �ste:
No se necesita un car�cter
& porque
ipxd
se pone por defecto en segundo plano. Aunque el demonio
ipxd
es �til sobre todo en m�quinas que act�an como encaminadores IPX,
tambi�n es �til a los nodos en segmentos donde existen m�ltiples
encaminadores. Cuando se especifica el argumanto
–p,
ipxd actuar� pasivamente, escuchando la informaci�n de
encaminamiento del segmento y actualizando las tablas de encaminamiento, pero
no transmitir� ninguna informaci�n de encaminamiento. De esta manera, un nodo
puede mantener actualizadas sus tablas de encaminamiento sin tener que solicitar
las rutas cada vez que quiera contactar con un nodo remoto.
Los nodos IPX con m�s de una interfaz IPX tienen una combinaci�n de
direcci�n de red/nodo �nica para cada una de sus interfaces. Para
conectarse a un nodo as�, se puede utilizar cualquiera de estas
combinaciones de direcci�n de red/nodo. Cuando SAP anuncia servicios,
proporciona la direcci�n de red/nodo asociada al servicio ofrecodo.
En los nodos con m�ltiples interfaces, esto significa que se debe
elegir una de las interfaces como la que va a propagar; �sta es la
funci�n de la bandera de interfaz primaria de la que hablamos
anteriormente. Pero esto presenta un problema: la ruta a esta
interfaz puede no ser siempre la m�s �ptima, y si se da un fallo
en la red que la a�sle del resto de la red, el nodo quedar�
inaccesible aunque haya otras rutas posibles
al resto de interfaces. Los otros nodos no conocen el resto de las
rutas porque nunca son propagadas, y el n�cleo no tiene manera de
saber que tendr�a que escoger otra interfaz primaria. Para evitar
este problema, ha sido desarrollado un dispositivo que permite que
un nodo IPX sea conocido mediante una direcci�n de red/nodo individual
independiente de la ruta, para los prop�sitos de la propagaci�n de SAP.
Esto resuelve nuestro problema, porque esta direcci�n de red/nodo nueva
es accesible a trav�s de todas las interfaces del nodo, y es la que
SAP anuncia.
Para ilustrar el problema y su soluci�n, Figura 15-1 muestra un servidor enganchado a
dos redes IPX. La primera red no tiene red interna, pero la segunda s�.
El nodo en el diagrama Figura 15-1
escoger�a una de sus interfaces como interfaz primaria, supongamos que
la 0000001a:0800000010aa, y es lo que
ser�a anunciado como su punto de acceso al servicio. Esto funciona bien
para los nodos de la red 0000001a, pero
significa que los usuarios de la red 0000002c
ser�an encaminados a trav�s de la red para alcanzar ese puerto, a pesar de
que el servidor tiene un puerto directamente en esa red, si han sabido de
este servidor a partir de las difusiones de SAP.
Permitiendo a estos nodos que tengan una red virtual con direcciones de
nodo virtuales, que son una construcci�n enteramente por software,
se resuelve el problema. Esta red virtual puede imaginarse mejor como
una red dentro del nodo IPX. S�lo necesita
propagarse la informaci�n SAP para esta combinaci�n de direcci�n de red/nodo
virtual. A esta red virtual se la conoce como
red interna. Pero �c�mo saben los otros nodos c�mo
acceder a esta red interna? Los nodos remotos son encaminados a la red
interna a trav�s de las redes del nodo conectadas directamente. Esto
significa que se ver�n entradas de encaminamiento que se refieren a la
red interna de los nodos que soportan m�ltiples interfaces IPX. Esas rutas
escoger�n la ruta �ptima disponible en el momento, y si una falla, el
encaminamiento se actualiza autom�ticamente a la siguiente interfaz y ruta
mejores. En Figura 15-1, hemos configurado
una red IPX interna de direcci�n 0x10000010
y hemos usado una direcci�n de nodo 00:00:00:00:00:01.
�sta ser� la direcci�n de nuestra interfaz primaria y la que er� anunciada
via SAP. Nuestro encaminamiento reflejar� que esta red es accesible a trav�s
de cualquiera de nuestro puertos de red reales, as� que
los nodos siempre usar�n la mejor ruta de red para conectarse a nuestro
servidor.
Para crear esta red interna, use la orden ipx_internal_net
inclu�do en el paquete de herramientas IPX de Greg Page. De nuevo, un ejemplo
sencillo demuestra su uso:
# ipx_internal_net add 10000010 000000000001 |
Este orden crear�a una red IPX interna con direcci�n
10000010 y direcci�n de nodo
000000000001. La direcci�n de red, como
cualquier otra direcci�n de red IPX, debe ser �nica en su red. La direcci�n de
nodo es completamente arbitraria, ya que normalmente s�lo habr� un nodo en la
red. Todo nodo debe tener s�lo una red IPX interna, y siempre ser� la red
primaria.
Para eliminar una red IPX interna, use:
Una red IPX interna no le servir� absolutamente para nada a menos que
su nodo proporcione un servicio y adem�s tenga m�s de una interfaz IPX
activa.