Intro admon-redes-v1.1

Introducciń a la Administraciń de una Red Local basada
o o
en Internet
Charles L. Hedrick
Traducido por Juanjo Mar´ juanjo96@arrakis.es
ın
Maquetaciń SGML por Paco Brufal pbrufal@ctv.es y Fernando ffddoo@openbank.es v 1.1, 27 de Julio
o
de 1999

Introducciń para aquellos que pretenden administrar una red basada en los protocolos de red de Internet
o
(TCP/IP).

´
Indice General

1 El problema. 2
1.1 Terminolog´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ıa. 3

2 Asignaciń de direcciones y enrutamiento.
o 3

3 Eligiendo una estructura de direcciones. 4
3.1 ¿Debemos subdividir nuestro espacio en direcciones? . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Subredes y m´ltiples numeros de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
u 6
3.3 C´mo asignar las subredes o los numeros de red. . . . . . . . . . . . . . . . . . . . . . . . . .
o 7
3.4 Trabajar con m´ltiples subredes ”virtuales”en una red. . . . . . . . . . . . . . . . . . . . . . .
u 7
3.4.1 Otra forma de trabajar con m´ltiples subredes. . . . . . . . . . . . . . . . . . . . . . .
u 8
3.4.2 M´ltiples subredes: Consecuencias en el Broadcasting. . . . . . . . . . . . . . . . . . .
u 9
3.5 Eligiendo una clase de direcciń. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 9
3.6 Lineas IP y micro gateways: direcciones asignadas din´micamente. . . . . . . . . . . . . . . .
a 10
3.6.1 L´
ıneas IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6.2 Micro gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Servicios a nivel de red, nombres. 13

5 Configurando el enrutamiento de cada ordenador 16
5.1 Como enrutar los datagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Rutas fijas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Reconducir el enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.4 Otros m´todos para que los hosts encuentren rutas . . . . . . . . . . . . . . . . . . . . . . . .
e 22
5.4.1 Espiar el enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4.2 Proxy ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4.3 Establecer nuevas rutas tras fallos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1. El problema. 2

6 Puentes y gateways 28
6.1 Diseõs alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 29
6.1.1 Una red de l´
ıneas punto a punto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.2 Tecnolog´ de los circu´
ıa ıtos de conmutaciń. . . . . . . . . . . . . . . . . . . . . . . . .
o 30
6.1.3 Redes de un s´lo nivel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 31
6.1.4 Diseõs mixtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
n 32
6.2 Introducciń a las distintas tecnolog´ de conmutaciń
o ıas o . . . . . . . . . . . . . . . . . . . . . 32
6.2.1 Repetidores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.2 Bridges y gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.3 M´s sobre bridges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 35
6.2.4 M´s sobre gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 36
6.3 Comparando las tecnolog´ de conmutaciń . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ıas o 37
6.3.1 Aislamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.2 Prestaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6.3.3 Enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.4 Administraciń de Redes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 41
6.3.5 Una evaluaciń final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o 43

7 Configurando gateways 43
7.1 Configurando el enrutamiento de los gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 Anexo: Copyright 47

1 El problema.
Este trabajo trata fundamentalmente sobre los aspectos ”l´gicos”de la arquitectura de red. Lo que puede o
o
no puede hacer una red est´ generalmente determinado por los protocolos que dicha red soporta y la calidad
a
de sus implementaciones, m´s que por la tecnolog´ concreta de red usada, como Ethernet, Token Ring, etc.
a ıa
Adem´s, en la prćtica, la elecciń de la tecnolog´ de red est´ basada en decisiones puramente pragm´ticas:
a a o ıa a a
qu´ tipo de red soporta el tipo de ordenadores que queremos conectar, las distancias entre los equipos, las
e
caracter´
ısticas del cableado, etc. Por regla general, se suele usar Ethernet para sistemas de media escala,
Ethernet o una red basada en el cableado de par trenzado para pequeãs redes, o redes de alta velocidad
n
(t´
ıpicamente Token Ring) para la red principal de un campus y para redes de superordenadores, que ejecutan
aplicaciones de altas prestaciones.
Por tanto, vamos a asumir que hemos llegado a conectar ”f´ısicamente¨nas redes individuales, del tipo Et-
u
hernet o Token Ring. Ahora nos enfrentamos a los siguientes problemas interrelacionados:

• configurar el software necesario,

• conectar las distintas Redes Ethernet, Token Ring, etc, para formar una unica red de forma coherente,
´

• conectar las redes al mundo exterior, o sea, Internet.

2. Asignaciń de direcciones y enrutamiento.
o 3

Las anteriores decisiones requieren un pequeõ an´lisis. De hecho, la mayor´ de las redes necesitan una
n a ıa
a
rquitectura”, que determina la manera en que se asignan las direcciones, c´mo se hace el enrutado y otras
o
elecciones, sobre c´mo los ordenadores interaccionan con la red. Estas decisiones deben hacerse para la red
o
en su conjunto, preferiblemente cuando se esta procediendo a su instalaciń inicial.
o

1.1 Terminolog´
ıa.

Vamos a usar el t´rmino IP para referirnos a las redes diseãdas para trabajar con TCP/IP. IP es el protocolo
e n
a nivel de red de la familia de protocolos TCP/IP, usados en Internet. Es una prćtica comń usar el t´rmino
a u e
IP cuando nos referimos a direcciones, enrutamiento y otros elementos a nivel de red. La distinciń muchas
o
veces no es lo suficientemente clara. As´ que, en la prćtica, los t´rminos Internet TCP/IP e IP pueden
ı a e
parecer incluso intercambiables.
Los t´rminos paquete y datagrama tambiń suelen parecer intercambiables. Conceptualmente, un pa-
e e
quete es la unidad f´
ısica de m´s bajo nivel, mientras que datagrama se refiere a la unidad de datos a nivel
a
IP. Sin embargo, en la mayor´ de las redes no se pueden distinguir porque coinciden, as´ que la gente suele
ıa ı
usar los dos t´rminos indistintamente.
e
Otro t´rmino conflictivo es el de pasarela (gateway) y enrutador (router). Pasarela es el t´rmino
e e
original usado en Internet. Sin embargo, la comunidad OSI empez´ a usar esta palabra con un significado
o
distinto, as´ que la gente empez´ a usar enrutador para evitar dicha ambigëdad. Nosotros, no obstante,
ı o u
seguiremos usando el t´rmino gateway.
e

2 Asignaciń de direcciones y enrutamiento.
o
Muchas de las decisiones que se necesitan para la configuraciń de una red IP depende del enrutamiento. En
o
general, un datagrama IP pasa a trav´s de numerosas redes mientras se desplaza entre el origen y el destino.
e
Veamos un ejemplo t´ ıpico:

Red 1 Red 2 Red 3
128.6.4 128.6.21 128.121
============================== ========== ====================
| | | | | | |
___|______ _____|____ __|____|__ __|____|____ ___|________
128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2
128.6.21.2 128.121.50.1
___________ __________ __________ ____________ ____________
ordenador A ordenador B gateway R gateway S ordenador C

Este gr´fico muestra tres ordenadores, 2 gateways y tres redes. Las redes pueden ser Ethernet, Token Ring
a
o de cualquier otro tipo. La red 2 podr´ ser una l´
ıa ınea punto a punto que conecta los gateways R y S.
El ordenador A puede enviar datagramas al B directamente, usando la red 1. Sin embargo, no puede llegar
al ordenador C directamente, puesto que no estń en la misma red. Hay varias maneras de conectar redes.
a
En el gr´fico asumimos el uso de gateways (m´s adelante veremos otras alternativas). En este caso, los
a a
datagramas que van desde A a C deben ser enviados a trav´s del gateway R, red 2 y gateway S. Todos
e
los ordenadores que usan TCP/IP necesitan que se les suministre la informaciń y algoritmos apropiados
o
para que puedan saber cuńdo un datagrama debe ser enviado a trav´s de un gateway, y elegir el gateway
a e
apropiado.
El enrutado est´ ´
a ıntimamente relacionado con la asignaciń de direcciones. Podemos apreciar que la direcciń
o o
de cada ordenador comienza con el n´mero de la red a la que pertenece. Por tanto, 128.6.4.2 y 128.6.4.3 se
u

3. Eligiendo una estructura de direcciones. 4

encuentran en la red 128.6.4. Luego los gateways, cuyo trabajo es conectar dos redes, tienen una direcciń
o
de ambas redes. Por ejemplo, el gateway R conecta la red 128.6.4 y 128.6.21. Su conexiń a la red 128.6.4
o
tiene la direcciń 128.6.4.1. Su conexiń a la red 128.6.21 tiene la direcciń 128.6.21.2.
o o o
Debido a esta relaciń entre direcciones y redes, las decisiones de enrutado deben basarse estrictamente en
o
el n´mero de red de destino. La informaciń de enrutamiento del ordenador A tendr´ el siguiente aspecto:
u o a

red gateway m´trica
e
----------- --------- -------
128.6.4 - 0
128.6.21 128.6.4.1 1
128.121 128.6.4.1 2

En esta tabla, el ordenador A puede enviar datagramas a los ordenadores de la red 128.6.4 directamente, y
para los datagramas a los ordenadores de las redes 128.6.21 y 128.121 es necesario usar el gateway R. La
”m´trica”ser´ usada por algń tipo de algoritmo de enrutamiento, como medida de la lejan´ del destinatario.
e a u ıa
En nuestro caso, la m´trica simplemente indica cuantos diagramas tiene que atravesar para llegar a su destino
e
(conocida como ”cuenta de saltos”).
Cuando el ordenador A est´ listo para enviar un datagrama se examina la direcciń del destinatario. Com-
a o
paramos el inicio de dicha direcciń de red con las direcciones de la tabla de enrutamiento. Las distintas
o
entradas de la tabla indican si el datagrama debe ser enviado directamente, o a un gateway.
Un gateway consiste simplemente en un ordenador conectado a dos redes diferentes, y est´ habilitado para
a
enviar datagramas entre ellos. En muchos casos es m´s eficiente usar un equipo especialmente diseãdo
a n
para desempeãr el papel de gateway. Sin embargo, es perfectamente posible usar un ordenador, siempre y
n
cuando tenga m´s de un interfaz de red y un software capaz de enviar datagramas.
a
Un gateway tiene varias direcciones, una para cada red a la que est´ conectado. Aqu´ encontramos una
e ı
diferencia entre IP y otros protocolos de red: cada interface de un ordenador tiene una direcciń. Con otros
o
protocolos, cada ordenador tiene una unica direcciń, aplicable a todos sus interfaces. Un gateway entre
´ o
las redes 128.6.4 y 128.6.21 tendr´ una direcciń que comience por 128.6.4 (por ejemplo, 128.6.4.1). Esta
a o
direcciń se refiere a su conexiń a la red 128.6.4. Tambiń tendr´ una direcciń que comience con 128.6.21
o o e a o
(por ejemplo, 128.6.21.2). Esta se refiere a su conexiń a la red 128.6.21.
o
El t´rmino ”red”generalmente se suele identificar a dispositivos del tipo Ethernet, en la cual varias m´quinas
e a
estń conectadas. Sin embargo, tambiń se aplica a l´
a e ıneas punto a punto. En el gr´fico anterior, las redes
a
1 y 3 podr´ estar en ciudades distintas; la red 2 podr´ ser una l´
ıan ıa ınea serie, un enlace sat´lite, u otro
e
tipo de conexiń punto a punto. Una l´
o ınea punto a punto es tratada como una red que consta s´lo de dos
o
ordenadores. Como cualquier otra red, una l´ ınea punto a punto tiene una direcciń de red (en este caso,
o
128.6.21). Los sistemas conectados por la l´
ınea (gateways R and S) tienen direcciones en dicha red (en este
caso, 128.6.21.1 y 128.6.21.2).
Es posible diseãr software que no necesite distintos n´meros de red para cada l´
n u ınea punto a punto. En
este caso, el interface entre el gateway y la l´ınea punto a punto no tiene una direcciń. Esta soluciń
o o
es apropiada cuando la red es tan grande que peligra el hecho de que nos quedemos sin direcciones. Sin
embargo, tales ”interfaces anńimas”pueden dificultar bastante el manejo de la red. Puesto que no tienen
o
direcciń, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible
o
obtener informaciń sobre el flujo y los errores de la interface.
o

3 Eligiendo una estructura de direcciones.
Antes de comenzar a montar una estructura de IP, necesitamos uno o m´s n´meros de red oficiales. Una
a u
direcciń IP tiene un aspecto como el siguiente: 128.6.4.3. Esta direcciń s´lo podr´ ser usada por un
o o o a


ordenador de la Universidad de Marx. La primera parte de dicha direcciń, 128.6, es un n´mero de red
o u
asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros
ordenadores, deberemos obtener una direcciń oficial de red. Sin embargo, alguna gente configura sus redes
o
usando, o bien una direcciń aleatoria o usando una direcciń gen´rica suministrada por defecto en el equipo.
o o e
Esta forma de trabajar podr´ funcionar en pequeãs redes, pero seguramente no lo har´ en una mayor.
ıa n a
Adem´s, es posible que quisi´ramos conectar nuestra red con la red de otra organizaciń. Incluso si nuestra
a e o
organizaciń tuviese un gran control de seguridad, es posible que tuvi´ramos un ordenador dedicado a la
o e
investigaciń que estuviese conectado a una universidad u otra organizaciń investigadora. Esta universidad
o o
o entidad estar´ seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros
ıa
datagramas salga de nuestra red local va a provocar un estado de confusiń en la organizaciń con la que
o o
nos comuniquemos, porque la direcciń que aparece en nuestros datagramas est´ probablemente asignada
o a
oficialmente a alguien distinto.
La soluciń es simple: obtener una direcciń propia desde el principio. Adem´s, no cuesta nada.
o o a
La decisiń m´s importante que tenemos que hacer para configurar una red es, sin lugar a dudas, c´mo
o a o
asignar las direcciones IP a los ordenadores. Esta elecciń debe de hacerse desde el punto de vista de c´mo
o o
nuestra red puede crecer. Si no se hiciese as´ es casi seguro que tendremos que cambiar las direcciones en
ı,
un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible.
Las direcciones son muy importantes porque los datagramas IP son enrutados en base a dicha direcciń. o
Por ejemplo, las direcciones de la Universidad Rutgers tienen una estructura de dos niveles. Una direccińo
t´
ıpica puede ser 128.6.4.3. La direcciń 128.6 es la asignada a dicha Universidad. Visto desde el exterior,
o
128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigir´ a
al gateway m´s cercano de la Universidad Rutgers. Sin embargo, dentro de Rutgers dividimos el espacio
a
de direcciones en ”subredes”. Usamos los siguientes 8 bits de direcciń para indicar a qu´ subred pertenece
o e
el ordenador. As´ 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con
ı,
ısicaso reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones m´s adelante.
redes ”f´ a
Los sistemas dentro de Rutgers, a diferencia de los de fuera, contienen informaciń sobre la estructura de
o
subredes de Rutgers. As´ una vez que un datagrama para 128.6.4.3 llega a Rutgers, la red de Rutgers lo
ı,
enrutar´ hacia la Ethernet, Token Ring o cualquier otro tipo de red del departamento que tiene asignado la
a
subred 128.6.4.
Cuando queremos configurar una red, hay varias decisiones de direccionamiento que debemos afrontar:

• ¿Dividimos nuestro espacio de direcciones?

• Si lo hacemos, ¿usamos subredes o direcciones de clase C?

• ¿C´mo debe ser de grande el espacio de direcciones que necesitamos?
o

3.1 ¿Debemos subdividir nuestro espacio en direcciones?

No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compa˜´ nıa
completa como una simple y gran Ethernet, as´ que no es necesario un enrutamiento interno. Si usamos estas
ı
tecnolog´ entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la unica decisiń
ıas, ´ o
que tenemos que tomar es la de qu´ clase de direcciń debemos de usar. Sin embargo, recomendamos usar
e o
un enfoque de subredes o cualquier otro m´todo de subdividir nuestro espacio de direcciń en varias redes:
e o

• En la secciń 6.2. discutiremos que los gateways internos son recomendables para todas las redes, m´s
o a
all´ de su simplicidad.
a

• Incluso si no necesitamos gateways en estos momentos, podemos descubrir que tarde o temprano
necesitaremos usarlos. De esta manera, probablemente tiene sentido asignar direcciones como si cada


Ethernet o Token Ring fuera una subred separada. Esto permitir´ hacer conversiones a subredes reales,
a
si esto es necesario.

• Por razones de mantenimiento, es conveniente tener direcciones cuya estructura corresponda con la
estructura de la red. Por ejemplo, si vemos un datagrama extraviado procedente del sistema 128.6.4.3,
es de bastante ayuda saber que todas las direcciones que comienzan por 128.6.4 se en cuentran en un
determinado edificio.

3.2 Subredes y m´ ltiples numeros de red
u

Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras
direcciones. La siguiente cuestiń es cu´l es la m´s adecuada. Hay dos enfoques b´sicos: subredes y
o a a a
m´ltiples n´meros de red.
u u
Los estńdares de Internet especifican el formato de las direcciones. Para las direcciones que comienzan entre
a
128 y 191 (las m´s usadas actualmente), los dos primeros octetos forman el n´mero de red; por ejemplo, en
a u
140.3.50.1, 140.3 es el n´mero de red. Los n´meros de red estń asignados a una organizaciń particular.
u u a o
¿Qu´ hacemos con los dos siguientes octetos que le siguen?. Podr´
e ıamos optar por hacer al siguiente octeto
un n´mero de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organizaciń
u o
deben configurarse para conocer qu´ esquema de divisiń de redes estamos usando. Sin embargo, fuera de la
e o
organizaciń nadie sabr´ si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es
o a
una organizaciń. Desafortunadamente, esta habilidad de aãdir una estructura adicional a las direcciones,
o n
mediante el uso de subredes, no estaba presente en las especificaciones originales y, por tanto, un software
antiguo ser´ incapaz de trabajar con subredes. Si una parte importante del software que hemos de usar
ıa
tiene este problema, entonces no podremos dividir nuestra red en subredes.
Algunas organizaciones usan un enfoque distinto. Es posible que una organizaciń use varios n´meros de
o u
red. En lugar de dividir un simple n´mero de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a
u
140.3.10, podr´
ıamos usar 10 n´meros distintos de red. De esta manera har´
u ıamos una asignaciń desde 140.3
o
hasta 140.12. Todo el software IP sabr´ que estas direcciones se corresponden con redes distintas.
a
A pesar de que usando n´meros de red distintos todo funciona correctamente dentro de la organizaciń, hay
u o
dos serias desventajas. La primera, y menos importante, es que se malgasta un gran espacio de direcciones.
Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en
nuestra organizaciń, a no ser que sea bastante grande. Esta objecciń es menos seria, porque podr´
o o ıamos
pedir una direcciń C para este prop´sito y hay sobre 2 millones de direcciones C.
o o
El problema m´s serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas
a
de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro n´merou
de red en subredes, esta divisiń s´lo es conocida dentro de la organizaciń, pero no fuera. Los sistemas
o o o
externos a la organizaciń s´lo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto,
o o
otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al n´mero de la red
u
de Rutgers. Si usa un rango de redes en lugar de subredes, dicha divisiń ser´ visible en todo Internet. Si
o a
usamos los n´meros 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitar´ tener una entrada
u ıan
para cada uno de estos n´meros de red en sus tablas de enrutamiento. La mayor´ de los expertos de TCP/IP
u ıa
recomiendan el uso de subredes, en lugar de m´ltiples redes. La unica razń para considerar m´ltiples redes
u ´ o u
es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos aõs, pero
n
actualmente es poco frecuente.
Una ultima indicaciń sobre subredes: Las subredes deben ser adyacentes”. Esto significa que no podemos
´ o
conectar la subred 128.6.4 con la subred 128.6.5 mediante otra red, como la 128.121. Por ejemplo, Rutgers
tiene campus en Simon City y Garfunken City. Es perfectamente posible conectar redes en ciudades distintas
que sean subred de 128.6. Sin embargo, en este caso, las l´
ıneas entre Simon City y Garfunken City deben ser
parte de 128.6. Supongamos que decidimos usar una red regional como la RegionaLnet para comunicarnos


entre dos campus, en lugar de usar su propia l´ ınea. Puesto que RegionaLnet tiene de n´mero de red
u
128.121, los gateways y l´
ıneas de serie que usar´ empezar´ por 128.121. Esto viola las reglas. No
ıan ıan
est´ permitido tener gateways o l´
a ıneas que son parte de 128.121 conectando dos partes de 128.6. As´ si
ı,
queremos usar RegionaLnet entre nuestros dos campus, tendr´ıamos que obtener diferentes n´meros de red
u
para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnolog´ de enrutamiento.
ıa
Eventualmente podr´ desarrollarse un software para un gateway para manejar configuraciones cuyas redes
ıa
no son contiguas).

3.3 C´mo asignar las subredes o los numeros de red.
o

Ahora, una vez decidido si vamos a usar subredes o m´ltiples n´meros de red, tenemos que asignarlos.
u u
Normalmente es bastante fćil. Cada red f´
a ısica, ya sea Ethernet o Token Ring, ..., se le asigna un n´mero
u
distinto de subred. Sin embargo, existen otras opciones.
En algunos casos, puede que tenga sentido asignar varios n´meros de subred a una unica red f´
u ´ ısica. En
Rutgers hay una unica Ethernet que ocupa tres edificios, usando repetidores. Est´ claro que a medida que
´ a
vayamos aãdiendo ordenadores a esta Ethernet se ir´ dividiendo en varias Ethernets separadas. Para evitar
n a
tener que cambiar de direcciones cuando esto suceda, hemos asignado tres n´meros de red distintas a esta
u
Ethernet, una por edificio. (Esto podr´ ser util, incluso, si no hubi´semos dividido la Ethernet con el fin de
ıa ´ e
ayudar a localizarlos). Pero, antes de hacer esto, debemos estar muy seguros de que el software de todos los
ordenadores puede manejar una red que tiene tres n´meros de red. Esta prćtica se ver´ m´s detalladamente
u a a a
en la secciń 3.4.
o
Tambiń hemos de elegir una ”m´scara de subred”, que ser´ usada por el software del sistema para separar
e a a
la parte de subred del resto de la direcciń. Hasta ahora hemos asumido que los dos primeros octetos son el
o
n´mero de red y el siguiente es el n´mero de subred. Para las direcciones de clase B, el estńdar especifica
u u a
que los dos primeros octetos pertenecen al n´mero de red. Y, por otro lado, tenemos libertad para establecer
u
el l´ımite del n´mero de subred y el resto de la direcciń. Es bastante usual utilizar un octeto de n´mero
u o u
de subred, pero no es la unica posibilidad. Veamos de nuevo esta direcciń de clase B, 128.6.4.3. Es fćil
´ o a
deducir que, si el tercer octeto es usado como n´mero de subred, entonces habr´ 256 posibles subredes y,
u a
en cada subred, habr´ 256 posibles direcciones. (En realidad es m´s acertado decir que disponemos de 254,
a a
ya que no es buena idea usar 0 ´ 255 como n´meros de subred o direcciń). Supongamos que sabemos que
o u o
nunca vamos a tener m´s de 128 ordenadores por subred, pero es probable que necesitemos m´s de 256
a a
subredes (por ejemplo, un campus con una gran cantidad de pequeõs edificios). En ese caso, podr´
n ıamos
establecer 9 bits como n´mero de red, dejando 7 bits para el direccionamiento de cada subred. Esta decisiń
u o
queda plasmada en una m´scara de bits, usando unos para los bits usados por los n´meros de red y de
a u
subred y ceros para los bits usados para el direccionamiento individual. La m´scara de red m´s comń es
a a u
255.255.255.0. Si elegimos 9 bits para el n´mero de subredes y 7 para las direcciones, la m´scara de subred
u a
ser´ 255.255.255.128.
ıa
Generalmente, es posible especificar la m´scara de subred como parte de la configuraciń del software
a o
IP. Los protocolos IP tambiń permiten a los ordenadores que env´ un mensaje preguntando cu´l es su
e ıen a
m´scara de subred. Si nuestra red soporta el env´ de estos mensajes, y hay, al menos, un ordenador o
a ıo
gateway de la red que conoce dicha m´scara de subred, posiblemente ser´ innecesario especificarlo en cada
a a
uno de los restantes ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de que
nuestra implementaciń TCP/IP diera una m´scara de subred errńea, se causar´ una mala configuraciń
o a o ıa o
en toda la red. Por lo tanto, es m´s seguro poner cada m´scara de subred expl´
a a ıcitamente en cada sistema.

3.4 Trabajar con m´ ltiples subredes ”virtuales”en una red.
u

La mayor´ del software est´ desarrollado bajo el supuesto de que cada red local tiene el mismo n´mero de
ıa a u
subred. Cuando existe un flujo hacia una m´quina con un distinto n´mero de subred, el software espera
a u


encontrar un gateway que pueda dirigirlo hacia esa subred. Veamos detalladamente qu´ ocurre en este
e
caso. Supongamos que tenemos las subredes 128.6.19 y 128.6.20 en la misma Ethernet. Consideremos las
cosas que ocurren desde el punto de vista de un ordenador con direcci`n 128.6.19.3. Dicho ordenador no
o
tendr´ problemas para comunicarse con las m´quinas de direcciń 128.6.19.x. Estas m´quinas estń en la
a a o a a
misma subred, y nuestro ordenador simplemente deber´ enviar los datagramas al 128.6.20.2. Puesto que esta
a
direcciń indica que est´ en una subred distinta, la mayor´ del software esperar´ encontrar un gateway que
o a ıa a
haga de puente entre ambas subredes. Por supuesto, no existe un gateway entre las ”subredes”128.6.19 y
128.6.20, puesto que estń en la misma Ethernet. De aqu´ se deduce que tenemos que encontrar una manera
a ı
de indicarle al software que el 128.6.20 se encuentra realmente en la misma Ethernet.
La mayor´ de las implementaciones TCP/IP pueden manejar m´s de una subred en la misma red. Por
ıa a
ejemplo, el Berkeley Unix nos permite hacerlo usando una ligera modificaciń del comando usado para
o
definir gateways. Si, por ejemplo, queremos que para pasar de la subred 128.6.19 a la subred 128.6.4 se use
el gateway con direcciń 128.6.19.1, podemos usar el comando
o

route add 128.6.4.0 128.6.19.1 1

Esto indica que para llegar a la subred 128.6.4 el flujo debe ser enviado a trav´s del gateway 128.6.19.1.
e
El ”1”se refiere a la ”m´trica de enrutamiento”. Si usamos la m´trica ”0”, estamos diciendo que la subred
e e
de destino est´ en la misma red y, por consiguiente, no se necesita ningń gateway. En nuestro ejemplo,
a u
deberemos usar en el sistema 128.6.19.3

route add 128.6.20.0 128.6.19.1 0

La direcciń usada en el lugar de 128.6.19.1 es irrelevante. La m´trica ”0”nos informa de que no va a usarse
o e
ningń gateway, luego no se usar´ dicha direcciń. Sin embargo, deber´ ampliarse una direciń legal de la
u a o a o
red local.

3.4.1 Otra forma de trabajar con m´ ltiples subredes.
u

Hay otro modo de manejar varias subredes sobre una red f´ ısica. Este m´todo supone la desconfiguraciń
e o
de nuestros anfitriones o hosts y, por ello, es potencialmente peligrosa, si no sabemos exactamente lo que
estamos haciendo. Sin embargo, puede resultar m´s c´modo cuando trabajamos con una gran cantidad de
a o
subredes en una red f´ısica. Un ejemplo de este tipo ser´ una instalaciń que use bridges, y usa subredes
ıa o
simplemente por facilidades de administraciń. El truco est´ en configurar el software de nuestros hosts
o a
como si no usasen subredes. As´ nuestros hosts no harń ninguna distinciń entre las distintas subredes y,
ı, a o
por tanto, no habr´ problemas para trabajar con todas ellas. Ahora, el unico problema es c´mo comunicarnos
a ´ o
con subredes que no estń en esta red de m´ltiples subredes. Pero, si nuestros gateways manejan proxy
e u
ARP, ellos resolverń este problema por nosotros. Este enfoque est´ especialmente indicado cuando la
a a
misma red contiene m´ltiples subredes y, particularmente, si se van a aãdir algunas m´s en un futuro.
u n a
Desgraciadamente, tiene dos problemas:

1. Si tenemos hosts con m´ltiples interfaces, deberemos ser muy cuidadosos. En primer lugar, s´lo
u o
deber´ haber m´quinas con un interface en la red con m´ltiples subredes. Por ejemplo, supongamos
ıa a u
que disponemos de una red que consta de varias Ethernets conectadas mediante bridges; no podemos
tener una m´quina con interfaces en dos de estas Ethernets, pero podemos tener un sistema con un
a
interface en esta red de subredes m´ltiples y otra en otra subred apartada de ´sta. En segundo lugar,
u e
cualquier m´quina con m´ltiples interfaces deber´ conocer la verdadera m´scara de subred, y necesitar´
a u a a a
estar informada expl´ ıcitamente de cu´les de las subredes estń en la red de m´ltiples subredes. Estas
a a u
restricciones son consecuencia de que un sistema con m´ltiples interfaces tiene que conocer qu´ interface
u e
ha de usar en cada caso.


2. Tambiń deberemos prestar atenciń a la facilidad ICMP de la m´scara de subredes. Esta facilidad
e o a
permite a los sistemas emitir una consulta para conocer cu´l es la m´scara de subred. Si la mayor´ de
a a ıa
los hosts piensan que la red no est´ dispuesta en subredes, pero los gateways y los hosts con varias
a
interfaces piensan lo contrario, tenemos aqu´ un foco potencial de confusiń. Si un gateway o hosts
ı o
con varios interfaces env´ una r´plica a una ICMP de m´scara de red, dando la verdadera m´scara
ıa e a a
de subred, alguno de los restantes hosts puede interceptarlo. La situaciń contraria tambiń ser´
o e ıa
posible. Esto significa que tendremos que:

• deshabilitar las r´plicas a las ICMP de m´scara de subred en todos aquellos sistemas que conocen
e a
la m´scara real de subred (esto es especialmente fćil si solamente los gateways lo conocen);
a a
• asegurar que nuestros hosts ignoran las r´plicas ICMP.
e

A medida que establecemos una m´scara de subred expl´
a ıcitamente, se supone que los hosts ignoran los ICMP
de m´scara de subred, as´ que deberemos ser capaces de establecer diferentes m´scaras en diferentes hosts
a ı a
sin causar ningń problema, siempre y cuando podamos establecer la m´scara expl´
u a ıcitamente en todos ellos.
Sin embargo, existen implementaciones IP que cambiarń su m´scara de subred cuando vean una r´plica de
a a e
ICMP de m´scara de subred.
a

3.4.2 M´ ltiples subredes: Consecuencias en el Broadcasting.
u

Cuando tenemos m´s de una subred en una misma red f´
a ısica, hay que tener cuidado respecto a las direcciones
de broadcasting. De acuerdo con los ultimos estńdares, hay dos formas distintas para que un host de
´ a
la subred 128.6.20 pueda enviar un broadcast en la red local. Una es usar la direcciń 128.6.20.255. La
o
otra es usar la direcciń 255.255.255.255. La direcciń 128.6.20.255 dice, expl´
o o ıcitamente, ”todos los hosts
de la subred 128.6.20”; la 255.255.255.255 expresa ”todos los hosts de mi red local”. Normalmente, ambas
tienen el mismo efecto. Pero no lo tienen cuando hay varias subredes en una red f´ ısica. Si la red 128.6.19
est´ en la misma red, tambiń recibir´ el mensaje enviado a 255.255.255.255. Sin embargo, los hosts con
a e a
n´meros 128.6.19.x no escucharń los mensajes enviados a 128.6.20.255. El resultado es que ah´ tenemos dos
u a ı
tipos distintos de direcciones de broadcast con dos significados distintos. Esto conlleva que debemos tener
cuidado configurando el software de red, para asegurarnos de que nuestros broadcasting llegan a donde
queremos que lo hagan.

3.5 Eligiendo una clase de direcciń.
o

Cuando solicitamos un n´mero oficial de red se nos preguntar´ qu´ clase de n´mero de red necesitamos. Las
u a e u
posibles respuestas son A, B y C. La decisiń elegida limitar´ nuestro espacio de direcciones a usar. Las
o a
direcciones de clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres octetos. Luego, hay
m´s direcciones de clase C que direcciones de clase A, pero las de clase C no pueden tener muchos hosts.
a
La idea que podemos sacar de lo anterior es que deber´ haber pocas grandes redes, un n´mero moderado
ıa u
de redes de tamaõ mediano y bastantes pequeãs redes. En la siguiente tabla observamos dicha distinciń:
n n o

Clase Rango 1er. octeto red resto direcciones posibles
A 1 - 126 p q.r.s 16777214
B 128 - 191 p.q r.s 65534
C 192 - 223 p.q.r s 254

Por ejemplo, la red 10 es de la clase A y por tanto tiene direcciones entre 10.0.0.1 y 10.255.255.254. Esto
signfica 2543, que son sobre unos 16 millones de posibles direcciones (realmente, la red 10 tiene algunas
direcciones con octetos a cero, as´ que habr´ algunas direcciones posibles m´s). La red 192.12.88, una
ı a a


direcciń de clase C, tendr´ sus hosts entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habr´ 254
o a a
posibles hosts.
En general, deberemos elegir la clase menor que nos proporcione suficientes direcciones capaces de direccionar
nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios
edificios, probablemente necesitarń una direcciń de clase B, suponiendo que vamos a usar subredes. (Y
a o
si vamos a tratar con distintos n´meros de red, deber´
u ıamos solicitar varias direcciones de clase C). Las
direcciones de clase A, normalmente, s´lo se usan en grandes redes p´blicas y algunas pocas redes de grandes
o u
corporaciones.
En la asignaciń de Direcciones IP, la autoridad m´xima es la IANA (Internet Assigned Number Authority).
o a
A escala continental, la IANA delega grandes bloques de direcciones IP a los denominados registros regionales,
de los que, de momento, existen tres en el mundo:

• El RIPE NCC (RIPE Network Coordination Center) es el registro delegado de Internet a nivel europeo
y se encarga, entre otras tareas, de la asignaciń de bloques de direcciones IP a los proveedores de
o
servicios Internet en Europa y su ´rea de influencia.
a

• El AP-NIC lleva a cabo la tarea de asignaciń de bloques de direcciones IP a los proveedores de la
o
regiń del Asia-Pac´
o ıfico.

• El InterNIC se encarga de la asignaciń de bloques de direcciones IP a los proveedores de Internet en
o
Am´rica del Norte y, de momento, en el resto del mundo.
e

Las organizaciones y usuarios finales han de obtener las direcciones IP necesarias para conectarse a Internet
a trav´s de su proveedor de acceso a Internet, quien a su vez las habr´ obtenido bien de su proveedor de
e a
trńsito, bien del registro regional correspondiente.
a

3.6 Lineas IP y micro gateways: direcciones asignadas din´micamente.
a

En la mayor´ de los casos, cada uno de los ordenadores tendr´ su propia direcciń IP permanente. No
ıa a o
obstante, hay algunas situaciones donde tiene m´s sentido asignar direcciones din´micamente. La mayor´
a a ıa
ıneas IP constan de gateways destinados principalmente a microcomputadoras.
de los casos que manejan l´

3.6.1 L´
ıneas IP.

Es posible usar IP sobre l´
ıneas telefńicas. Uno de los protocolos para hacer esto es el SLIP (”Serial line
o
IP”). SLIP se usa frecuentemente en, al menos, dos circunstancias distintas:

• Como una alternativa barata a l´ıneas punto a punto permanentes, para aquellos casos en los que no
est´ suficientemente justificado una l´
a ınea dedicada.

• Como una manera de conectar individualmente un PC a una red, cuando se encuentran localizados en
edificios que no tienen Ethernets o cualquier otro tipo LAN.

Vamos a usar el t´rmino ”servidor SLIP”para referirnos a un sistema de ordenador(es) que incluye una
e
serie de modems, con los que otros sistemas pueden conectarse usando SLIP. Se trata de un sistema que
proporciona un gateway de nuestra red para usuarios de PC, o para otras redes que se conectan usando
SLIP.
Si tenemos varios PC’s conectados mediante SLIP, muchas veces no es prćtico usar una direcciń IP propia
a o
para cada PC. Una de las razones puede ser que no haya suficientes direcciones. Para que el enrutamiento
funcione correctamente, estos sistemas conectados deben tener sus direcciones en la misma subred que el


servidor SLIP. Por lo general, hay solamente del orden de 256 direcciones disponibles en cada subred. Si el
n´mero de PC’s que pueden conectarse es mayor que esa cifra, no podremos asignarles su propia direcciń.
u o
Si, adem´s, tenemos servidores SLIP en m´s de una subred, la asignaciń permanente de direcciones se hace
a a o
ań m´s complicada. Si un usuario es capaz de llamar a dos servidores, su PC necesitar´ dos direcciones,
u a ıa
una para cada subred.
Para solucionar estos problemas, la mayor´ de las implementaciones SLIP asignan las direcciones
ıa
din´micamente. Cuando un PC se conecta con el servidor SLIP, el servidor busca una direcciń IP que
a o
no se est´ usando y se la asigna al PC. La forma m´s simple de manejar esto es dando a cada servidor SLIP
e a
un rango de direcciones IP que controle y pueda asignar.
Cuando usamos este esquema, el software SLIP debe comunicar al PC, de alguna manera, qu´ direcciń
e o
debe usar. Si cada PC tiene una direcciń permanente, tendr´
o ıamos el problema contrario: cuando un PC
se conecta con un servidor debe de haber algń m´todo para que el PC comunique al servidor su direcciń.
u e o
Este problema debe ser estudiado cuidadosamente, porque en otro caso alguien podr´ usar la direcciń de
ıa o
otro y tener acceso a sus ficheros.
Desafortunadamente, no hay un estńdar para manejar estos problemas de direccionamiento con SLIP. Hay
a
varias implementaciones SLIP que lo hacen, pero todav´ no hay un estńdar. Hasta que no se elabore
ıa a
´ste, deberemos tener cuidado con el software SLIP. Tenemos que asegurarnos de que dicha asignaciń de
e o
direcciń se lleva a cabo de la manera que queremos y que nuestro servidor SLIP y los PC’s tienen claro la
o
forma en que se asignan las direcciones.
Recomendamos dar direcciones permanentes a los PC’s en aquellos casos en que los dem´s ordenadores tienen
a
que ser capaces de conocer con qu´ PC estń hablando. Este podr´ ser el caso de un PC para recibir correo
e a ıa
privado, o cualquier otro servicio con transacciones delicadas. Y recomienda el direccionamiento din´mico
a
cuando tenemos un gran n´mero de PC’s y las aplicaciones que utilizan para acceder a la red tienen sus
u
propios mecanismos de seguridad.
Cuando usemos SLIP para conectar dos redes, hay que considerar tres elecciones para el manejo de direcciones
(teniendo en cuenta que no todo el software SLIP puede controlar los tres apartados):

• Tratar a las conexiones SLIP como si se tratasen de l´ıneas punto a punto que no estń disponibles
a
permanentemente. Si podemos conectar con m´s de un ordenador, cada par de ordenadores que se
a
comunican tienen un n´mero de red distinto del que ellos usar´ cuando se comunican con el otro.
u ıan

• Usar un software de enrutamiento que permita interfaces anńimos. En este caso, no ser´ necesarias
o ıan
las direcciones.

• Asignar direcciones din´micamente cuando la conexiń est´ abierta, tan pronto como el PC haya
a o a
contactado.

Si hacemos s´lo una o dos conexiones a otro sistema, es bastante razonable usar un n´mero de red para cada
o u
conexiń. Este m´todo es fćil de usar y limita los errores estad´
o e a ısticos.
Si tenemos muchas conexiones distintas, probablemente es mejor usar interfaces anńimos. Aunque si los
o
sistemas de enrutamiento no lo soportan, debemos usar asignaciń din´mica.
o a
Al igual que SLIP, PPP ”Point to Point Protocol”es un protocolo serie distinto utilizado para enviar data-
gramas a trav´s de una conexiń serie, pero mejora algunas de las carencias del anterior. El PPP permite a
e o
las partes comunicantes negociar opciones como las direcciones IP y el tamaõ m´ximo de los datagramas
n a
al comenzar la conexiń, y proporciona permisos de conexiń a los clientes (autorizaciones). Para cada una
o o
de estas capacidades, el PPP tiene un protocolo concreto.
A continuaciń, citaremos los elementos b´sicos que constituyen el PPP. Esta descripcion esta muy lejos
o a
de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, asi como en la
docena de RFCs que le acompaãn.n


En la parte m´s baja del PPP est´ el protocolo de Control de Conexiń de Datos de Alto-Nivel, abrevia-
a a o
damente HDLC. ( En realidad, el HDLC es un protocolo mucho m´s general publicado por la Organizaciń
a o
Internacional de Estńdares, ISO ) que define los l´
a ımites de las tramas PPP individuales, y proporciona
un control de errores de 16 bit. Al contrario de lo que ocurr´ en las encapsulaciones SLIP m´s antiguas,
ıa a
una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como los IPX de Novell o
Appletalk. El PPP consigue esto aãdiendo a la trama b´sica HDLC un campo de control que identifica el
n a
tipo de paquete contenido en la trama.
El LCP, Protocolo de Control de Enlace, es utilizado en la parte m´s alta del HDLC para negociar las
a
opciones concernientes a la conexiń de datos, tales como la Unidad M´xima de Recepciń (MRU) que
o a o
establece el tamaõ m´ximo del datagrama que una de las partes de la conexiń acepta recibir.
n a o

3.6.2 Micro gateways.

Es perfectamente posible que un microcomputador forme parte de una red IP. Pero hay una tendencia de
que los micros utilicen distintas tecnolog´ de red que la de los grandes sistemas. Esto es debido a que
ıas
muchos de los usuarios de micros empiezan a demandar un software de red diseãdo espec´
n ıficamente para
las necesidades de un micro, incluso para un particular tipo de micro. Muchos usuarios estń interesados
a
en usar TCP/IP sin tener que abandonar su red especial de micro, a la que estń acostumbrados. Por esta
a
razń, hay un creciente n´mero de productos, especialmente gateways, que dan acceso a los PC’s tanto a
o u
redes orientadas a micros como a TCP/IP.
En esta secciń vamos a hablar del AppleTalk, de Apple, a modo de ejemplo. No obstante, existen productos
o
similares para otros tipos de redes de micros. Hay que aclarar que el t´rmino AppleTalk se asocia a los
e
protocolos de red de Apple, mientras que LocalTalk se asocia a una tecnolog´ espec´
ıa ıfica de par trenzado,
en la que AppleTalk fue inicialmente implementada. Por tanto, el AppleTalk es an´logo a los protocolos
a
TCP/IP, mientras que LocalTalk es an´logo a medio Ethernet.
a
Algunas compa˜´ ofrecen gateways para conectar una red AppleTalk corriendo sobre LocalTalk, con redes
nıas
IP corriendo sobre Ethernet. A pesar de que hay varios productos de este tipo, la mayor´ de ellos incluyen
ıa
los siguientes servicios:

• Las aplicaciones TCP/IP de un PC pueden conectarnos a sistemas TCP/IP de la Ethernet. Se definen
utilidades especiales para permitirnos llevar datagramas IP desde el PC hasta el gateway, a trav´s
e
del LocalTalk. Las aplicaciones TCP/IP de PC han sido escritas usando unas librer´ especiales que
ıas
mezclan AppleTalk y TCP/IP. Las utilidades AppleTalk se necesitan para llevar los datagramas hasta
el gateway, donde se transformarń en datagramas 100% TCP/IP, antes de dejarlos en la Ethernet.
a

• Se pueden escribir aplicaciones AppleTalk para grandes sistemas, de tal manera que un PC podr´ a
usarlos como servidores. Dichas aplicaciones tambiń han sido escritas haciendo uso de una librer´
e ıa
especial que mezcla AppleTalk y TCP/IP. Pero, en esta ocasiń, son utilidades TCP/IP para dejar
o
datagramas en el gateway, donde se transformarń totalmente en AppleTalk, antes de dejarlos en la
a
AppleTalk y lleguen al PC.

• Una red IP de un campus o una corporaciń puede ser usada para conectar redes AppleTalk. Los
o
gateways de cada Apple realizarń las conversiones necesarias antes de enviar los datagramas a la red
a
IP.

Adem´s, algunos gateways pueden hacer traducciones a nivel de aplicaciń. Por ejemplo, algunos gateways
a o
pueden hacer traducciones entre el sistema de ficheros de Apple y el sistema de fichero de red de Sun (NFS).
Esto permite a un PC acceder al sistema de ficheros Unix, donde el PC usa el sistema de ficheros Apple, y
el acceso al sistema Unix se hace mediante el uso del sistema NFS, o sistema de ficheros de red (Network
File System ), de Sun.

4. Servicios a nivel de red, nombres. 13

Desafortunadamente, la gran flexibilidad de estos productos se traduce en una gran complejidad. El tema
de direcciones es especialmente complicado. Por las mismas razones que SLIP, y PPP estos gateways usan
frecuentemente asignaciń din´mica de direcciones IP. Para ello asignaremos un rango de direcciones IP a
o a
cada gateway. Cuando un PC intenta abrir una conexiń TCP/IP, el gateway se hace con una direcciń
o o
IP libre y se la asigna al PC. Al igual que SLIP, en muchos casos necesitaremos elegir si queremos que las
direcciones se asignen de esta manera, o bien queremos que cada PC tenga su propia direcciń. Otra vez,
o
la elecciń depender´ del n´mero de PC’s que tengamos y de si tenemos aplicaciones capaces de usar la
o a u
direcciń IP para identificar qu´ PC, en particular, es el que est´ conectado.
o e a
El direccionamiento es mucho m´s complejo, debido a que AppleTalk tiene su propia estructura de direcciones.
a
Deberemos establecer una correspondencia entre direcciones AppleTalk y n´meros de red IP. Tambiń habr´
u e a
una correspondencia entre direcciones IP y AppleTalk, que se establecer´ din´micamente en los gateways.
a a

4 Servicios a nivel de red, nombres.
Si vamos a tener una red TCP/IP, hay algunas tareas importantes que realizar. Algunas de ellas son
simplemente de tipo administrativo. La m´s importante es crear un registro central de nombres y direcciones
a
IP. Existen organizaciones que realizan esta labor para toda la red Internet. Si estamos conectados a Internet,
el administrador de nuestro sistema necesita registrarse a una de estas organizaciones, para que cualquier
demanda por parte de otra instituciń sobre nuestros hosts sean dirigidos a nuestros servidores.
o
Queremos mantener una base de datos que contenga la informaciń de cada sistema de la red. Como
o
m´ınimo, necesitaremos el nombre y la direcciń IP de cada sistema. Probablemente, el registro central ser´
o a
el encargado de asignar las direcciones IP. Si nuestra red est´ estructurada en subredes, o si usamos varios
a
n´meros de clase C, el registro posiblemente asignar´ los n´meros de red a las nuevas redes o subredes.
u a u
Pero, habitualmente, se permitir´ que los propios administradores de los hosts elijan el nombre del host.
a
Sin embargo, el registro debe de, al menos, verificar que no haya nombres duplicados. Si estamos trabajando
con una gran red, puede que sea buena idea delegar algunas de estas tareas a subregistros, posiblemente uno
para cada departamento.
Se recomienda asignar las direcciones de la forma m´s simple: empezando por 1. As´ si nuestra red es
a ı,
la 128.6, podr´ıamos asignar como 128.6.1 a la primera subred; 128.6.2, a la segunda, etc. La asignaciń o
de direcciones IP para hosts individuales podr´ empezar por 2. De esta manera reservamos la direcciń
ıan o
1 de cada subred para que sea usada por el gateway correspondiente. Por consiguiente, el primer host
de la subred 128.6.4 ser´ el 128.6.4.2; el siguiente ser´ 128.6.4.3, y as´ sucesivamente. Hay una razń
ıa ıa ı o
b´sica para mantener las direcciones tan cortas como sean posibles. Si tenemos una gran organizaciń,
a o
podr´ıamos quedarnos sin n´meros de subred. Si esto ocurriera, y nuestros hosts tienen n´meros de red
u u
bajos, podr´ıamos asignar otro bit para el direccionamiento de las subredes. Si, por ejemplo, usamos el tercer
octeto como n´mero de subred, en tanto en cuanto nuestros hosts tengan unos n´meros inferiores a 128,
u u
podremos ampliar el n´mero de red a 9 bits. As´ por ejemplo, la subred 128.6.4 podr´ dividirse en dos
u ı, ıa
subredes distintas: 128.6.4.0 y 128.6.4.128. Si hubi´semos asignado a los hosts n´meros por encima de 128,
e u
la divisiń habr´ sido imposible.
o ıa
La asignaciń de nombres de los hosts no es tan sistem´tica. Pueden ser cualquier expresiń compuesta de
o a o
letras, n´meros y guiones. Es m´s seguro que el primer carćter sea una letra. Y, desde el punto de vista
u a a
de los usuarios, es recomendable que los nombres sean lo m´s cortos posibles (incluso hay software que
a
tiene problemas trabajando con nombres m´s largos de 16 caracteres). Muchas veces, los departamentos o
a
proyectos eligen un tema o nombre relacionado con ellos. Por ejemplo, las m´quinas usadas por los estudiantes
a
de Inform´tica de Rutgers tienen nombres de bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc.
a
Nuestro departamento de Matem´ticas usa el nombre de famosos matem´ticos: GAUSS, FERMAT, etc. Si
a a
la instituciń no tiene ninguna relaciń con el mundo exterior, cualquier nombre es adecuado.
o o


Si estamos conectados a Internet, nuestra organizaciń necesitar´ un ”nombre de dominio”(domain name).
o a
Al igual que en el caso del espacio de direcciones IP, la autoridad m´xima del espacio de nombres de Internet
a
(DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La ra´ del DNS es ız
gestionada por el InterNIC por delegaciń de la IANA. Bajo la ra´ se encuentran los distintos dominios de
o ız
primer nivel (Top Level Domains o TLD’s) gestionados por distintos registros delegados de Internet. Algunos
de ellos son: Dominios ”especiales”como COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central
del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a Espaã,
n
est´ delegado a ES-NIC.
a
A diferencia del n´mero de red, podremos arregl´rnosla sin ´l si la red est´ aislada. Si posteriormente lo
u a e a
necesitamos, es fćil de aãdir un nombre de dominio. (Recomendamos usar un n´mero de red desde el
a n u
principio, porque cambiar n´meros de red posteriormente puede ser traum´tico). Los nombres de dominio,
u a
normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compa˜´ etc. Por ejem-
nıas,
plo, la Universidad de Rutgers tiene como nombre de dominio RUTGERS.EDU. El formato de los nombres
completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organizaciń. As´
o ı,
si un ordenador es conocido internamente como GAUSS, su nombre completo ser´ GAUSS.RUTGERS.EDU.
a
Si tenemos una gran organizaciń, es posible tener subdominios. Por ejemplo, puede que haya un subdominio
o
para cada departamento; esto aãdir´ otro t´rmino en los nombres. Si, por ejemplo, el departamento de Ma-
n ıa e
tem´ticas decide crear su subdominio, el anterior ordenador se llamar´ GAUSS.MATHS.RUTGERS.EDU.
a ıa
Una vez asignado el nombre de dominio, se procede a cambiar los ficheros de configuraciń donde aparece
o
la forma completa del nombre. En algunos casos, se pueden usar apodos o nombres cortos, de manera que
no ser´ necesario incluir el nombre completo.
a
Si tenemos m´s de uno o dos sistemas, necesitaremos tener algń mecanismo para tener al d´ la informaciń
a u ıa o
de los distintos hosts. El software TCP/IP necesita ser capaz de traducir nombres de hosts en direcciones
IP. Cuando un usuario intenta conectarse con otro sistema, generalmente se referir´ a ´l usando su nombre.
a e
El software tendr´ que traducir el nombre en una direcciń IP, para poder abrir la conexiń. La mayor´
a o o ıa
del software incluye dos vias para hacer esta traducciń: una tabla est´tica o un servidor de nombres. La
o a
soluciń de la tabla est´ indicada para pequeãs organizaciones, siempre y cuando no estń conectadas a
o a n e
otra red. Simplemente se crea un fichero que lista los nombres y direcciones de todos los hosts. Veamos
parte de una tabla de este tipo:

HOST: 128.6.4.2, 128.6.25.2: ARAMIS.RUTGERS.EDU, ARAMIS: SUN-3-280: UNIX ::
HOST: 128.6.4.3: GAUSS.RUTGERS.EDU, GAUSS: SUN-3-180: UNIX ::
HOST: 128.6.4.4, 128.6.25.4: ATHOS.RUTGERS.EDU, ATHOS: SUN-4-280: UNIX ::

Como se puede apreciar, el formato es el siguiente: una l´ ınea para cada sistema y listar sus direcciones,
nombres y otra informaciń sobre ´l. En el ejemplo, tanto ARAMIS como ATHOS estń en dos redes, as´ que
o e a ı
tienen dos direcciones. Adem´s, ambos tienen un nombre principal, por ejemplo ARAMIS.RUTGERS.EDU,
a
y apodos, por ejemplo ARAMIS. En caso de estar conectados a Internet, el nombre principal ser´ el nombre
a
de dominio completamente especificado. Se incluyen apodos cortos, para facilitar la tarea a nuestros usuarios.
Hay otro formato muy frecuente para las tablas de hosts. Veamos un ejemplo:

128.6.4.2 aramis.rutgers.edu aramis
128.6.25.2 aramis.rutgers.edu aramis
128.5.4.3 gauss.rutgers.edu gauss
128.6.4.4 athos.rutgers.edu athos
128.6.25.4 athos.rutgers.edu athos

En este formato, cada l´
ınea representa una direcciń IP. Si el sistema tiene dos interfaces, hay dos l´
o ıneas
de ´l en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso m´s comń. La
e a u
documentaciń de su sistema le informar´ sobre el formato usado por ´l.
o a e


En la configuraciń m´s simple, cada ordenador tiene su propia copia de la tabla de hosts en /etc/hosts.
o a
En caso de elegir esta configuraciń, deberemos establecer procedimientos para asegurarnos que todas las
o
copias son actualizadas regularmente. En una red pequeã no es dif´ mantener una tabla /etc/hosts en
n ıcil
cada m´quina, y modificarla al agregar, eliminar o modificar nodos. Aunque resulta complicado cuando hay
a
muchas m´quinas, ya que, en principio, cada una necesita una copia de /etc/hosts.
a
Una soluciń a esto es compartir ´sta y otras bases de datos con el NIS, o sistema de informaciń de red
o e o
( Network Information System ), desarrollado por Sun Microsystems y conocido tambiń como p´ginas
e a
amarillas o YP. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS
central y los clientes accederń a ellas de forma transparente al usuario. En todo caso, esta soluciń s´lo
a o o
es aconsejable para redes pequeãs o medianas, ya que implican mantener un fichero central /etc/hosts que
n
puede crecer mucho, y luego distribuirlo entre los servidores NIS.
En redes grandes, y todos aquellos que estń conectados a Internet, debemos adoptar un nuevo siste-
a
ma, el DNS o sistema de nombres por dominios (Domain Name System) diseãdo por Paul Mockapetris.
n
Tćnicamente, el DNS es una inmensa base de datos distribu´ jer´rquicamente por toda la Internet; exis-
e ıda a
ten infinidad de servidores que interactán entre si para encontrar y facilitar a las aplicaciones clientes que
u
los consultan la traducciń de un nombre a su direccion de red IP asociada, con la que poder efectuar la
o
conexiń deseada. Cada parte de la base de datos est´ replicada en, al menos, dos servidores, lo que asegura
o a
una debida redundancia. Un servidor de nombres es un programa que se ejecuta en algunos de nuestros
sistemas para tener conocimiento de los nombres. Cuando un programa necesita buscar un nombre, en lugar
de hacerlo en una copia de la tabla de host, env´ una peticiń al servidor de nombres. Este enfoque tiene
ıa o
dos ventajas:

• Para los grandes sistemas, es m´s fćil tener al d´ las tablas en algunos servidores de nombres que en
a a ıa
todo el sistema.

• Si nuestra red est´ conectada a Internet, nuestro servidor de nombres ser´ capaz de dialogar con los
a a
servidores de nombres de otras organizaciones, para buscar nombres de cualquier sitio.

Usar un servidor de nombres es el unico camino para tener un acceso completo a la informaciń del resto de
´ o
los hosts de Internet.
Es importante comprender la diferencia entre un servidor de nombres y un resolvedor. Un servidor de
nombres es un programa que tiene acceso a una base de datos de hosts, y responde peticiones de otros
programas. Un resolvedor es un conjunto de subrutinas que pueden cargarse con un programa. El resolvedor
genera las peticiones que se enviarń al servidor de nombres, y procesa sus correspondientes respuestas.
a
Cada sistema deber´ usar un resolvedor (en general, el resolvedor es cargado por cada programa que va a
ıa
hacer uso de la red, puesto que s´lo es un conjunto de subrutinas). Hay que recalcar que s´lo se necesitarń
o o a
unos pocos servidores de nombres. Mucha gente confunde los dos enfoques y llega a creer que es necesario
tener un servidor de nombres en cada ordenador.
Para usar un resolvedor, cada ordenador necesitar´ un fichero de configuraciń, u otro m´todo, para espe-
a o e
cificar la direcciń del servidor de nombres al que enviar nuestras peticiones. Por regla general, se pueden
o
declarar varios servidores de nombres, para el caso de que alguno de ellos no funcione correctamente. En
el caso de que nuestro sistema no pudiera contactar satisfactoriamente con ningń servidor, la mayor´ de
u ıa
nuestro software empezar´ a fallar. Por tanto, hay que ser muy cuidadoso y declarar tantos servidores
ıa
como podamos para intentar asegurar un buen funcionamiento.
Los servidores de nombres, generalmente, tienen un conjunto de opciones para su configuraciń. En lugar de
o
dar algunos consejos sobre c´mo configurar un servidor de nombres, vamos a recomendar dos documentos
o
oficiales de los estńdares de Internet. El RFC 1032 contiene las instrucciones sobre c´mo conseguir un
a o
nombre de dominio del Centro de Informaciń de Red, incluyendo los formularios necesarios. El RFC 1033
o
contiene las instrucciones sobre c´mo configurar un servidor de nombres. Todos estos documentos son de tipo
o

5. Configurando el enrutamiento de cada ordenador 16

conceptual. Seguramente, tambiń necesitar´ documentaciń sobre el software espec´
e a o ıfico de su servidor de
nombres.
En algunos casos, puede que se necesiten, a la vez, tablas y servidores de nombres. Si tenemos alguna
implementaciń de TCP/IP que no incluyan resolvers, estamos obligados a instalar tablas de hosts en
o
estos sistemas. Si nuestra red est´ conectada a Internet, vamos a tener problemas con aquellos sistemas que
a
no dispongan de resolvers, ya que Internet es demasiado grande para tener unas tablas de hosts de todos
sus hosts. Por lo tanto, lo que se puede hacer es incluir una tabla de hosts con los hosts que realmente se
tiene pensado usar. InterNIC tiene a su cargo una tabla de host que puede ser un buen punto de comienzo,
aunque no es completa de ningń modo. As´ que tendremos que aãdir los hosts favoritos de los usuarios.
u ı n
Los sistemas que usan resolvers no tendrń este problema, puesto que un servidor de nombres es capaz de
a
traducir cualquier nombre legal de host.
Los nombres de hosts y la asignaciń de n´meros son los unicos elementos que deben de tener una estructura
o u ´
centralizada. Sin embargo, puede haber otros elementos susceptibles de centralizaciń. Es bastante frecuente
o
tener uno o dos ordenadores que se hagan cargo de todo el correo electrńico. Si estamos conectados a
o
Internet, es bastante simple establecer comunicaciones con otros ordenadores de Internet. No obstante,
hay muchas instituciones que quieren comunicarse con sistemas de otras redes, como Bitnet o Usenet. Hay
gateways entre varias de estas redes. Pero la elecciń del gateway correcto, y transformar la direcciń de
o o
correo electrńico correctamente, es una tarea muy especializada. Por esto, en muchas ocasiones se configura
o
el software apropiado s´lo en un lugar, y todo el correo externo (o todo el correo externo a hosts que no
o
estń en Internet) se dirige a este sistema.
a

5 Configurando el enrutamiento de cada ordenador
Todas las implementaciones TCP/IP necesitan alguna configuraciń en cada host. En algunos casos, esto se
o
hace durante la instalaciń del sistema de forma casi autom´tica. En otros casos, mediante la configuraciń
o a o
de ciertos programas o ficheros. Y, por ultimo, otros sistemas obtienen la informaciń de configuraciń a
´ o o
trav´s de la red de un ”servidor”.
e
A pesar de que los detalles de la configuraciń pueden diferir bastante, existen ciertos datos que deben
o
incluirse en todos los casos. Entre ellos:

• par´metros que describan a una m´quina en particular, como su direcciń IP;
a a o

• par´metros que describan la red, como su subm´scara de red (si hubiera);
a a

• software de enrutamiento y las tablas que use;

• otros programas necesarios para el funcionamiento de otras tareas de red.

Antes de que se instale un ordenador en una red, un coordinador deber´ asignarle un nombre de red y su
a
direcciń IP, como describimos anteriormente. Una vez otorgado un nombre y una direcciń estamos en
o o
disposiciń de configurarlo. En numerosas ocasiones, lo que debemos hacer es poner la direcciń y el nombre
o o
en un fichero de configuraciń. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de
o
un disco propio en el que dicha informaciń pueda ser almacenada) deben obtener esta informaciń a trav´s
o o e
de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la peticiń ”¿quiń
o e
soy?”. En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red est´ preparada
a
para responder adecuadamente. La pregunta l´gica es: ¿c´mo otro sistema sabe quiń eres?. Generalmente,
o o e
esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones an´logas para otro tipo de redes).
a
Las direcciones Ethernet son asignadas por los fabricantes hardware. Est´ garantizado que s´lo una m´quina
a o a
en todo el mundo tiene una determinada direcciń Ethernet. Por lo general, dicha direcciń est´ grabada en
o o a
una ROM en la tarjeta Ethernet de la m´quina. La m´quina, probablemente, no conozca su direcciń IP,
a a o

Intro admon-redes-v1.1

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Similar a Intro admon-redes-v1.1

Similar a Intro admon-redes-v1.1 (20)

Más de 1 2d

Más de 1 2d (20)

Último

Último (20)

Intro admon-redes-v1.1