Práctica 3

LABORATORIO DE REDES
PRÁCTICA 3
DIRECCIONAMIENTO, ROUTING, MÁSCARAS Y DNS
INTRODUCCIÓN
El mecanismo de direccionamiento IP ha sido, desde sus inicios, uno de los aspectos más reconocidos
y valorados en las redes IP. Todo nodo requiere de una dirección IP para poder formar parte de una red,
tal como pudo comprobarse en la Práctica 1. En esta tercera práctica se aprenderá la funcionalidad e
importancia de las máscaras de red para constituir subredes. Igualmente se practicará con la definición de
rutas y gateways (pasarelas) entre redes para permitir el enrutamiento de paquetes entre ellas. DNS es el
mecanismo que permite independizarse del incómodo método numérico para identificar nodos de red.
Para la realización de todos los ejercicios de esta práctica se usará la siguiente figura que representa la
topología de la subred del laboratorio de redes:
158.49.98.1 puesto1.unex.es
158.49.98.2 puesto2.unex.es
158.49.98.3 puesto3.unex.es
•
•
•
•
•
•
158.49.98.30 puesto30.unex.es
patanegra.unex.es lupe.unex.es
hub
158.49.98.62
158.49.xxx.yyy
norba.unex.es
158.49.98.63 Broadcast
hub
EPCCnet
1
DIRECCIONAMIENTO IP Y SUBNETTING
Las direcciones manejadas en Internet pueden ser simbólicas o numéricas. La forma simbólica es más
fácil de recordad, por ejemplo: [email protected]
La forma numérica es un número binario sin signo de 32 bits, habitualmente expresado en forma de
números decimales separados por puntos. Por ejemplo:
128.2.7.9 en formato decimal y 10000000 00000010 00000111 00001001 en formato binario.
La forma numérica es usada por el software de IP.
Todas las direcciones IP con direccionamiento directo dividen los 32 bits según la siguiente disposición:
RED
SISTEMA
32 BITS
El problema del direccionamiento IP surge con al crecimiento exponencial de internet. El uso de
direcciones IP se ha vuelto demasiado rígido para permitir cambiar con facilidad la configuración de las
redes locales. Estos cambios podían ser necesarios cuando:
•
Se instala una nueva red física.
•
El crecimiento del número de hosts requiere dividir la red local en dos o más redes.
Para evitar tener que usar direcciones IP adicionales en esos casos, se introdujo el concepto de subred.
En este caso el campo de sistema de la dirección IP se divide en dos subcampos: subcampo subred y
subcampo sistema:
RED
RED
SISTEMA
SUBRED
SISTEMA
Esta técnica se denomina subnetting. Actualmente se dispone de dos tipos de subnetting:
•
Subnetting básico o estático. Consiste en que todas las subredes de la red dividida empleen la
misma máscara de red. Esto es simple de implementar y de fácil mantenimiento, pero implica el
desperdicio de direcciones para redes pequeñas. Además, hace más difícil reorganizar la red con
una máscara nueva. Hoy en día casi todos los hosts y routers soportan subnetting estático, pero
hay que tener en cuenta que un router formateado para que ejecute un protocolo de
encaminamiento que sólo admita subnetting estático, sólo puede manejar una máscara de subred,
por lo que es incompatible con otros métodos de direccionamiento más eficaces como el
subnetting de longitud variable.
•
Subnetting de longitud variable.- Este método evolucionó del anterior para hacer más eficiente el
direccionamiento IP. En este caso las subredes que constituyen la red pueden hacer uso de
diferentes máscaras de subred. Una subred pequeña con sólo unos pocos hosts necesita una
máscara que permita acomodar sólo a esos hosts. Una subred con muchos nodos puede requerir
una máscara distinta para direccionar esa elevada cantidad de hosts. La posibilidad de asignar
máscaras de subred de acuerdo a las necesidades individuales de cada subred ayuda a conservar
las direcciones de red. Además, una subred se puede dividir en dos, añadiendo un bit a la
máscara. El resto de las subredes no se verán afectadas por el cambio. No todos los hosts y
routers soportan subnetting de longitud variable. Sólo se dispondrán redes del tamaño requerido
y los problemas de encaminamiento se resolverán aislando las redes que soporten subnetting de
2
longitud variable. Un host que no soporte este tipo de subnetting debería disponer de una ruta de
encaminamiento a un router que sí lo haga.
El tipo de subnetting disponible depende del protocolo de encaminamiento en uso. Existe un concepto
fundamental en este método de direccionamiento, subnetting, que es el de máscara de red o subred.
Debido a la variabilidad del campo de subred, hay que informar al dispositivo de encaminamiento que
maneja las direcciones sobre su longitud. Para ello se utiliza lo que se conoce como máscara de subred,
que es una comunicación binaria de 32 bits con todo 1s a la izquierda cubriendo, respectivamente, los
campos de red y subred (el campo sistema queda todo a Os).
EJERCICIO 1
Con los conocimientos de la Práctica 1, se trata de asignar a la interfaz de red su correspondiente
@IP, así como la @ de broadcast y la máscara de red correspondiente a una red clase C segmentada. Para
calcular las máscaras de red en una red clase C segmentada puede usarse la siguiente tabla:
Subredes
1
Nodos en la Subred
254
Máscaras de red
255.255.255.0
11111111.11111111.11111111.00000000
Campos red: 24 bits
Campo subred: 0 bits
Campo sistema: 8 bits
2
126
255.255.255.128
11111111.11111111.11111111.10000000
Campo red: 24 bits
Campo subred: 1 bits
Campo sistema: 7 bits
4
62
255.255.255.192
11111111.11111111.11111111.11000000
Campo red: 24 bits
Campo subred: 2 bits
Campo sistema: 6 bits
8
30
255.255.255.224
11111111.11111111.11111111.11100000
Campo red: 24 bits
Campo subred: 3 bits
Campo sistema: 5 bits
16
14
255.255.255.240
11111111.11111111.11111111.11110000
Campo red: 24 bits
Campo subred: 4 bits
Campo sistema: 4 bits
32
6
255.255.255.248
11111111.11111111.11111111.11111000
Campo red: 24 bits
Campo subred: 5 bits
Campo sistema: 3 bits
64
2
255.255.255.252
11111111.11111111.11111111.11111100
Campo red: 24 bits
Campo subred: 6 bits
Campo sistema: 2 bits
128
1
255.255.255.254
11111111.11111111.11111111.11111110
Campo red: 24 bits
Campo subred: 7 bits
Campo sistema: 1 bits
3
A continuación se observan dos ejemplos de máscaras que pueden usarse con el parámetro netmask
del comando ifconfig:
Ej.1: RRRRRRRR.RRRRRRRR.RRRRRRRR.NNNNNNNN
• Red clase C que se desea dividir en 4=22 subredes clase C de 64 =26
nodos cada una:
RRRRRRRR.RRRRRRRR.RRRRRRRR.RR NNNNNN
11111111.11111111.11111111.11000000
Nodos 64=26
192=26+ 27
Máscara de red 255.255.255.192
Ej. 2:
11000000.10101000.00101010.00000000 ↔ 192.168.42.0 @Clase C
11111111.11111111.11111111.00000000 ↔ 255.255.255.0 Netmask
Para obtener 8=23 subredes de 32=25 nodos la máscara 255.255.255.224
11111111.11111111.11111111.11100000
255.255.255.224
224=26+ 27 + 25
Suele ser habitual encontrar la siguiente notación en el direccionamiento privado: 192.168.4.0/24,
donde 192.168.4.0 es la dirección de red y /24 identifica la máscara de red asignada. El número que
aparece tras la barra expresa el número de bits que se reservan para la máscara de red, de modo que /8
representa una red clase A, /16 representa red clase B y /24 una red clase C.
En este ejercicio deben hacerse varias pruebas con ifconfig con diferentes direcciones de
broadcast y distintas máscaras, poniendo atención al comando route y a la asignación automática
que realiza en función del comando ifconfig ejecutado.
Se recomiendo poner atención a la definición de máscaras que se han definido en los sistemas Linux y
en Solaris. Estudiar todas las informaciones mostradas por el comando ifconfig.
ROUTTING Y COMANDO route
Para configurar un equipo para acceder a internet a través de un router, habrá que usar el comando
route. Para que dos equipos intercambien datagramas IP, ambos deberán tener una ruta al otro, o
utilizar un gateway por omisión que conozca una ruta para llegar de un ordenador al otro. Los gateways
intercambiarán información entre ellos utilizando un protocolo como OSPF (Open Shortest Path First) o
RIP (Routing Information Protocol). Existen múltiples situaciones en las que resulta útil visualizar y
modificar el contenido de la tabla de rutas de un equipo, y el comando route puede resultar de ayuda
para ello.
EJERCICIO 2:
4
El objetivo de este ejercicio es comprobar la imposibilidad de acceder a nodos externos a la subred
clase C segmentada del aula, mientras no se haya definido en los PC con Trinux una ruta válida a la
máquina que actúa como gateway. Para comprobar esto se usará el comando
#telnet 158.49.133.12
antes de haber añadido la ruta con
#route add default gw 158.49.98.62
Una vez añadida la ruta se trata de volver a ejecutar el comando telnet anterior y comprobar si la
comunicación es ya posible.
En el caso de Trinux o Knoppix antes de ejecutar el comando telnet hay que configurar la tarjeta
de red ya que, por defecto, no está configurada. El modo de hacerlo es el siguiente, considerando que nos
encontramos en el puesto 7 del laboratorio:
#ifconfig eth0 158.49.98.7 netmask 255.255.255.192 broadcast
158.49.98.63
Una vez que la tarjeta de red está configurada, se intenta hacer telnet a la dirección IP 158.49.133.12
y el resultado será:
La máquina158.49.133.12
nos está informando de que la red es inalcanzable para ella, cosa bastante lógica ya que la
#telnet
pasarela por defecto to
de unconnect
sistema (oto
gateway)
es elhost:
modo que
esta tiene is
de salir
al exterior.
telnet:Unable
remote
Network
unreachable
Una vez añadida una pasarela por defecto, al hacer telnet se obtendrá lo siguiente:
#telnet 158.49.133.12
Connection closed by foreign host
Ha sido posible el acceso al exterior, aunque el host con el que se intentaba conectar haya denegado el
acceso.
Se recomienda poner atención a los diversos campos que muestra el comando route. Averiguar cuál
es el router del router del laboratorio.
Los campos del comando route son los siguientes:
#route add [-net | -host] <dir_ip> netmask <máscara> [gw <dir_ip_gateway>] dev
<interfaz>
•
dir_ip : route puede utilizarse para establecer rutas estáticas hacia equipos y redes vía una
interfaz de red una vez se ha configurado esta última con el comando ifconfig. La mayor
parte de las veces se utilizará para establecer rutas hacia redes, por lo que debe utilizarse con la
5
opción –net, con lo que dir_ip se interpretará como una dirección de red para la que se
desea establecer una ruta. Si el servicio de nombres de dominio DNS está configurado y
funcionando correctamente, puede utilizarse un nombre simbólico en lugar de una dirección IP.
Si se desea establecer una ruta a un equipo, deberá utilizarse la opción –host.
•
máscara : Este campo especifica la máscara de red para la ruta que se desea añadir. Durante el
proceso de encaminamiento de cada paquete IP se realizará una operación lógica AND entre la
dirección IP destino contenida en su cabecera y la máscara. Si el resultado de dicha operación
coincide con dir_ip, se utilizará esta entrada de la tabla de rutas para poder realizar el
encaminamiento de dicho paquete IP. Si no se indica la máscara de red se utilizará una máscara
de red por defecto correspondiente al tipo de red.
•
dir_ip_gateway : Cuando se utiliza la entrada que se está creando en la tabla de rutas para
enviar un paquete IP, dicho paquete se encaminará a través del gateway indicado en este campo.
Dicho gateway debe poder ser alcanzado, por lo que previamente deberá haberse establecido una
ruta hasta el mismo. Si se especifica la dirección IP de una de las interfaces de red locales, se
utilizará ésta para decidir la interfaz hacia la que se encaminarán los paquetes. Es opcional y
sólo aparece cuando es necesario encaminar hacia un gateway.
•
interfaz : En este campo se proporciona el nombre de la interfaz de red que se desea utilizar
en esta ruta.
DNS (DOMAIN NAME SYSTEM)
El mecanismo numérico de direcciones IP es bastante engorroso para su uso constante, por lo que se
habilitó la posibilidad de uso de servidores de nombres DNS que permiten asignar nombres a los
ordenadores que forman parte de una red IP, a la vez que pueden ser usados para resolver y traducir los
nombres a sus correspondientes direcciones IP.
Antes de esta solución (servidores DNS) existía un sistema que mantenía el mapeo de nombres a
direcciones en un fichero (/etc/hosts) que todos los sistemas obtenían vía FTP. Se denominó espacio
de nombres plano. Debido al gran crecimiento del número de sistemas, este mecanismo se volvió
demasiado inviable y fue sustituido por el concepto de DNS.
Hay una red jerárquica de servidores de nombres, de tal forma que pueden encontrarse servidores
DNS primarios, secundarios, etc. Todos los servidores de nombres deben conocer cuál es el servidor de
nombres inmediatamente superior a ellos en la jerarquía, de tal modo que si un servidor de nombres no es
capaz de resolver un nombre a una dirección IP consultará con su servidor de nombres superior.
EJERCICIO 3
Para comprobar la definición de los servidores DNS se usará el sistema Linux para localizar los
ficheros donde se asigna el nombre de cada uno de los sistemas ( /etc/hosts y /etc/hostname) y
el nombre del servidor de nombres /etc/resolv.conf .
Una vez comprobados cuáles son los ficheros que contienen estas definiciones en Linux, se usará
Trinux para configurar el adecuado servidor de DNS y comprobar que es posible conectarse a
determinados sistemas usando su nombre. Emplear para ello comandos como telnet o ping.
Se recomienda contrastar los ficheros relativos a nombres de nodos, de interfaces, de servicios, DNS,
etc. de los sistemas Linux, Trinux y Solaris. Se trata de comprobar la existencia de los siguientes ficheros
y sus contenidos, todos ellos, en /etc: /etc/resolv.conf, /etc/HOSTNAME,
/etc/hosts,
/etc/services,
/etc/nodename,
/etc/netmasks,
/etc/hostname.le0, /etc/hostname.le1, etc.
El contenido de estos ficheros en Linux es el siguiente:
/etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1
localhost.localdomain
localhost
158.49.98.31 puesto31
puesto31.unex.es
6
En la figura anterior se observa cómo este fichero contiene una correspondencia entre los nombres
simbólicos y direcciones IP de un par de puestos del laboratorio.
/etc/resolv.conf
search unex.es
nameserver 158.49.113.21
Este fichero contiene la dirección IP del servidor de nombres de dominio al que acudirá nuestra
máquina cuando necesite resolver un nombre simbólico a una dirección IP.
/etc/services
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
/etc/services:
$Id: services,v 1.31 2002/04/03 16:53:20 notting Exp $
Network services, Internet style
Note that it is presently the policy of IANA to assign a single well-known
port number for both TCP and UDP; hence, most entries here have two entries
even if the protocol doesn't support UDP operations.
Updated from RFC 1700, ``Assigned Numbers'' (October 1994). Not all ports
are included, only the more common ones.
The latest IANA port assignments can be gotten from
http://www.iana.org/assignments/port-numbers
The Well Known Ports are those from 0 through 1023.
The Registered Ports are those from 1024 through 49151
The Dynamic and/or Private Ports are those from 49152 through 65535
Each line describes one service, and is of the form:
service-name
port/protocol
[aliases ...]
[# comment]
tcpmux
1/tcp
# TCP port service multiplexer
tcpmux
1/udp
# TCP port service multiplexer
rje
5/tcp
# Remote Job Entry
rje
5/udp
# Remote Job Entry
echo
7/tcp
echo
7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
systat
11/udp
users
daytime
13/tcp
daytime
13/udp
qotd
17/tcp
quote
qotd
17/udp
quote
msp
18/tcp
# message send protocol
msp
18/udp
# message send protocol
chargen
19/tcp
ttytst source
chargen
19/udp
ttytst source
ftp-data
20/tcp
ftp-data
20/udp
# 21 is registered to ftp, but also used by fsp
ftp
21/tcp
ftp
21/udp
fsp fspd
7
Este fichero contiene los distintos servicios disponibles en la máquina, así como datos de interés de
los mismos.
El contenido de los archivos en Trinux es el siguiente:
/etc/hosts
127.0.0.1
localhost
trinux
127.0.0.1
localhost
trinux
Aquí puede observarse cómo este fichero contiene una correspondencia entre los nombres simbólicos
y direcciones IP de la interfaz de loopback.
/etc/services
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992). Not all ports
# are included, only the more common ones.
#
#
from: @(#)services 5.8 (Berkeley) 5/9/91
#
$Id: services,v 1.9 1993/11/08 19:49:15 cgd Exp $
#
tcpmux
1/tcp
# TCP port service multiplexer
echo
7/tcp
echo
7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
daytime
13/tcp
daytime
13/udp
netstat
15/tcp
qotd
17/tcp
quote
msp
18/tcp
# message send protocol
msp
18/udp
# message send protocol
chargen
19/tcp
ttytst source
chargen
19/udp
ttytst source
ftp-data
20/tcp
# File Transfer [Default Data]
ftp-data
20/udp
# File Transfer [Default Data]
ftp
21/tcp
# File Transfer [Control]
ftp
21/udp
# File Transfer [Control]
ssh
22/tcp
# Secure Shell Login
ssh
22/udp
# Secure Shell Login
telnet
23/tcp
telnet
23/udp
# 24 - private
smtp
25/tcp
mail
# 26 - unassigned
time
37/tcp
timserver
time
37/udp
timserver
rlp
39/udp
resource
# resource location
nameserver
42/tcp
name
# IEN 116
whois
43/tcp
nicname
domain
53/tcp
nameserver
# name-domain server
domain
53/udp
nameserver
mtp
57/tcp
# deprecated
8
Este fichero contiene los distintos servicios disponibles en la máquina, así como datos de interés de
los mismos, al igual que en Linux.
/etc/resolv.conf
Este fichero debe ser configurado en Trinux ya que, en este sistema operativo, no está configurado
por defecto, la forma de hacerlo es la siguiente:
#echo search unex.es > resolv.conf
#echo nameserver 158.49.113.12 >> resolv.conf
COMANDO traceroute
Traceroute es un comando que permite obtener los equipos por los que pasan los paquetes IP
hasta llegar a su destino. Así puede analizarse cuál es la organización que le da soporte a una dirección IP
También permite comprobar el estado de carga de una red. Esta herramienta aprovecha dos características
importantes de TCP/IP:
•
TTL (time to live): Protege a la red de paquetes atrapados en ciclos de enrutamiento.
Los diseñadores de TCP/IP dotaron a cada paquete IP de este contador que delimita el
número de “saltos” que puede dar un datagrama antes de ser desechado por la red. Un
paquete dirigido a una dirección inexistente se quedaría dando “saltos” de router en
router ilimitadamente, lo cual desaprovecharía los recursos de la red y afectaría al
rendimiento de las CPU inútilmente.
•
PROTOCOLO ICMP: Sirve para manejar mensajes de control y de error. Este
protocolo puede, entre otras cosas, avisar que un enlace o un dispositivo están
congestionados, que se escogió un camino poco óptimo para enviar un paquete o que no
se puede acceder a un nodo en particular. Uno de los avisos de ICMP es
particularmente útil para traceroute: El aviso de que se excedió la vida útil del
paquete (es decir, se excedió el TTL).
Combinando estas dos características, traceroute permite construir un mapa de la red de acuerdo
a cómo es vista desde un nodo en particular. La forma de hacerlo es ir mostrando cada uno de los “saltos”
dados por un paquete al recorrer el camino desde el ordenador que ejecuta el comando hasta la dirección
IP indicada en el comando. La cantidad de “saltos” que un paquete da puede aportar una idea de la
complejidad de esa conexión. Para cada “salto” se envían tres paquetes con un TTL que se va
incrementando progresivamente. El nombre del nodo que responde, bien sea indicando que se llegó al
destino o que el paquete expiró en tránsito, se muestra junto a los tiempos transcurridos entre el envío del
paquete y la recepción de la respuesta. Esto informa de las condiciones en que se encuentra la red en ese
salto o en alguno de los anteriores.
EJERCICIO 4: COMANDO traceroute
El comando traceroute, al igual que ping, usa el protocolo ICMP para obtener información de
conectividad desde una dirección IP concreta hasta otra. La diferencia de traceroute con respecto a
ping es que el primero muestra todos los routers que se van atravesando entre los nodos origen y destino
para los cuáles se quiere conocer la ruta que les separa.
9
El comando traceroute muestra en cada línea el host por el que pasa en cada una de las etapas.
También obtiene los nombres y las direcciones IP y además muestra los tiempos de recepción desde cada
uno de los nodos sondeados. El comando prueba tres conexiones consecutivas con cada uno de los nodos
atravesados para llegar desde el nodo origen hasta el destino. Cuando una de las conexiones se pierde
aparece mostrada con * para que se pueda llegar a las conclusiones oportunas.
Este comando es, por tanto, una útil herramienta para detectar problemas de conectividad en una red.
Usándolo podremos conocer hasta qué punto están recibiéndose los paquetes que se envían, y así saber si
es posible llegar de un nodo de la red a otro.
Como práctica se recomienda localizar este programa en Trinux, y si no se encuentra se debe obtener
de la red e instalarlo según se ha aprendido en la Práctica 2.
El comando traceroute se encuentra en el directorio de Linux /sbin.
Una forma de usar traceroute en el sistema operativo Trinux es copiar el comando
traceroute del directorio /sbin a un disquete. A continuación en Trinux, después de haber montado
la unidad de disquetes (ya que por defecto esta viene desmontada), podrá ejecutarse traceroute desde
el directorio de montaje.
A continuación se presentan algunos ejemplos de la ejecución de traceroute en Trinux:
EJEMPLO 1:
#traceroute www.unex.es
traceroute to espantaperros.unex.es (158.49.17.21), 30 hops max, 38 byte
packets
1 norba.unex.es (158.49.98.62) 0.844 ms 0.315 ms *
2 158.49.129.3 (158.49.129.3) 0.912 ms 0.837 ms 0.805 ms
3 158.49.254.1 (158.49.254.1) 5.033 ms 4.912 ms 4.874 ms
4 espantaperros.unex.es (158.49.17.21) 4.780 ms 4.737 ms 5.466 ms
En este ejemplo se observa cómo el primer salto corresponde al router del laboratorio desde donde se
ejecuta el comando. Para llegar a la máquina que tiene asignado el nombre www.unex.es son
necesarios cuatro saltos en total. El asterisco en el lugar del último paquete del primer salto quiere decir
que ha sido imposible resolver el ping correspondiente al tercer paquete.
En algunos casos, al ejecutar el comando traceroute no aparece la dirección IP correspondiente al
salto y, en lugar de los tres tiempos de resolución, aparecen tres asteriscos, por ejemplo:
20 * * *
Eso podría significar que el host correspondiente al “salto” puede tener algún tipo de software de
protección contra este tipo de comandos, lo cual hace imposible la resolución de los “pings”.
EJEMPLO 2:
#traceroute ftp.rediris.es
traceroute to zeppo.rediris.es (130.206.1.5), 30 hops max, 38 byte
packets
1 norba (158.49.98.62) 0.427 ms * 0.586 ms
2 158.49.129.3 (158.49.129.3) 1.267 ms 1.067 ms *
3 158.49.254.1 (158.49.254.1) 5.496 ms 5.662 ms 5.341 ms
4 * * AT0-0-0-0.EB-Badajoz0.red.rediris.es (130.206.203.5) 7.101 ms
5 EXT.SO1-1-0.EB-IRIS4.red.rediris.es (130.206.240.73) 13.623 ms
13.675 ms 14.194 ms
6 130.206.220.59 (130.206.220.59) 12.929 ms 14.252 ms 15.030 ms
7 zeppo.rediris.es (130.206.1.5) 13.832 ms 14.116 ms 14.604 ms 10
En la figura anterior se ejecuta traceroute y se obtiene el camino hasta un servidor de ftp. Han
sido necesarios siete saltos y, a medida que nos “alejamos” de la máquina en la que se ejecuta el
traceroute, el RTT (round trip time) es mayor. Esto da indicios de si la “distancia” a recorrer por los
paquetes IP va siendo mayor o menor.
EJEMPLO 3:
#traceroute www.google.com
traceroute: Warning: www.google.com has multiple addresses; using
66.102.11.99
traceroute to www.google.akadns.net (66.102.11.99), 30 hops max, 38 byte
packets
1 norba (158.49.98.62) 0.500 ms * 0.673 ms
2 158.49.129.3 (158.49.129.3) 1.210 ms 1.176 ms 0.977 ms
3 158.49.254.1 (158.49.254.1) 6.147 ms 6.892 ms 5.833 ms
4 * * AT0-0-0-0.EB-Badajoz0.red.rediris.es (130.206.203.5) 6.239 ms
5 EXT.SO1-1-0.EB-IRIS4.red.rediris.es (130.206.240.73) 14.179 ms
15.549 ms 14.298 ms
6 SO1-0-0.EB-IRIS2.red.rediris.es (130.206.240.1) 14.679 ms 13.739 ms
12.909 ms
7 RI.SO0-0-0.EB-IRIS5.red.rediris.es (130.206.240.126) 14.810 ms
16.064 ms 14.193 ms
8 lambdanet-1.espanix.net (193.149.1.35) 13.316 ms 14.649 ms 14.044
ms
9 M-1-pos121.es.lambdanet.net (217.71.103.1) 14.385 ms 15.433 ms
14.896 ms
10 F-8-eth100-0.de.lambdanet.net (217.71.105.110) 55.850 ms 55.854 ms
55.622 ms
11 Google-F.de.lambdanet.net (217.71.111.38) 57.006 ms 55.811 ms
55.918 ms
12 216.239.48.146 (216.239.48.146) 97.506 ms 99.296 ms 96.417 ms
13 216.239.49.18 (216.239.49.18) 99.169 ms 99.443 ms 97.949 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
11
Este es un ejemplo peculiar de la ejecución de traceroute. Puede observarse cómo en primer
lugar se indica que al nombre simbólico www.google.com le corresponden diversas direcciones IP
(también indica que el comando se ejecutará con una de ellas, en este caso 66.102.11.99). También se
observa cómo el número de saltos a ejecutar es mucho mayor que en los ejemplos anteriores,
posiblemente debido a que la máquina con la dirección IP de la cual estamos buscando una ruta no esté
dispuesta topológica y geográficamente de forma tan accesible como las de ejemplos anteriores.
También se observa cómo llegados a un determinado salto, la máquina es incapaz de resolver los RTT
a cada uno de los routers (quizás por la protección al comando traceroute mencionada en ejemplos
anteriores). Finalmente el comando cesa en el salto 30 sin ser capaz de dar ninguna información
significativa.
APÉNDICE
NORBA (SISTEMA OPERATIVO SOLARIS)
Se muestran algunas consideraciones de configuración del sistema operativo Solaris instalado en la
máquina Norba, del laboratorio.
Comando ifconfig y máscaras
La siguiente captura corresponde a la ejecución del comando ifconfig –a en la máquina Norba:
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 158.49.114.208 netmask fffff000 broadcast 158.49.127.255
le1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 158.49.98.62 netmask ffffffc0 broadcast 158.49.98.63
Como novedades a lo ya visto en Linux y Trinux, puede observarse que, en lugar de existir una única
tarjeta de red, aparecen dos (norba y sande como puede comprobarse con lo ya dicho) y que la forma
de identificarlas no es ethx, sino lex (siendo x el número identificativo de la tarjeta de red). También
se observa que las máscaras de red se presentan en hexadecimal, siendo:
Máscara de Sande:
f
f
f
f
f
0
0
0
1111 1111 . 1111 1111 . 1111 0000 . 0000 0000 = 255.255.240.0
Máscara de Norba:
f
f
f
f
f
f
c
0
1111 1111 . 1111 1111 . 1111 1111 . 1100 0000 = 255.255.255.192
(la máscara de red de Norba coincide con la de los puestos Linux)
Otra información mostrada por ifcongig es la MTU (Maximum Transmission Unit), que es la
mayor unidad de datos posible que se puede enviar sobre un medio físico dado). En este caso sabemos
que cualquier paquete de más de 1500 bytes, en el caso de le1 y le0, será fragmentado para poder
pasar por estos medios físicos.
12
FICHEROS DE CONFIGURACIÓN Y DNS
A continuación se muestra el contenido de algunos de los ficheros de configuración de redes en
Solaris.
/etc/hosts
127.0.0.1
158.49.98.62
158.49.114.208
158.49.114.254
158.49.114.135
localhost
norba.unex.es norba
loghost
sande.unex.es sande
patanegra.unex.es patanegra
alcantara.unex.es alcantara
Puede observarse la correspondencia entre los nombres simbólicos y direcciones IP significativas
para la máquina Norba. Se almacenan, por ejemplo, las direcciones IP de Norba y Sande, además de
otras máquinas de la Universidad de Extremadura de interés.
/etc/services
#ident "@(#)services
1.20
98/07/08 SMI"
/* SVr4.0 1.8
*/
#
# Network services, Internet style
#
tcpmux
1/tcp
echo
7/tcp
echo
7/udp
discard
9/tcp
sink null
discard
9/udp
sink null
systat
11/tcp
users
daytime
13/tcp
daytime
13/udp
netstat
15/tcp
chargen
19/tcp
ttytst source
chargen
19/udp
ttytst source
ftp-data
20/tcp
ftp
21/tcp
ssh
22/tcp
telnet
23/tcp
smtp
25/tcp
mail
time
37/tcp
timserver
time
37/udp
timserver
name
42/udp
nameserver
whois
43/tcp
nicname
# usually to sri-nic
domain
53/udp
domain
53/tcp
bootps
67/udp
# BOOTP/DHCP server
bootpc
68/udp
# BOOTP/DHCP client
hostnames
101/tcp
hostname
# usually to sri-nic
pop2
109/tcp
pop-2
# Post Office Protocol - V2
pop3
110/tcp
# Post Office Protocol - Version 3
sunrpc
111/udp
rpcbind
sunrpc
111/tcp
rpcbind
imap
143/tcp
imap2
# Internet Mail Access Protocol
v2
ldap
389/tcp
# Lightweight Directory Access
Protocol
ldap
389/udp
# Lightweight Directory Access
Protocol
ldaps
636/tcp
# LDAP protocol over TLS/SSL
(was sldap)
ldaps
636/udp
# LDAP protocol over TLS/SSL
(was sldap)
(...)
13
Este fichero contiene los distintos servicios disponibles en la máquina, así como datos de interés de
los mismos, al igual que en Linux y Trinux.
/etc/resolv.conf
domain unex.es
nameserver 158.49.113.21
nameserver 158.49.133.12
nameserver 158.49.8.225
nameserver 158.49.8.6
nameserver 158.49.8.2
nameserver 195.235.113.3
Este fichero almacena las direcciones IP de los distintos servidores de nombres a los que el
sistema puede acceder.
14