PRÁCTICA puesto1.unex.es puesto2.unex.es puesto3.unex.es puesto30.unex.es. patanegra.unex.

Transcripción

1 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: puesto1.unex.es puesto2.unex.es puesto3.unex.es puesto30.unex.es hub patanegra.unex.es lupe.unex.es norba.unex.es Broadcast xxx.yyy EPCCnet hub 1

2 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: direcciondecorreo@unex.es 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: en formato decimal y 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 SISTEMA RED 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

3 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 así como 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 Nodos en la Subred Máscaras de red Campos red: 24 bits Campo subred: 0 bits Campo sistema: 8 bits Campo red: 24 bits Campo subred: 1 bits Campo sistema: 7 bits Campo red: 24 bits Campo subred: 2 bits Campo sistema: 6 bits Campo red: 24 bits Campo subred: 3 bits Campo sistema: 5 bits Campo red: 24 bits Campo subred: 4 bits Campo sistema: 4 bits Campo red: 24 bits Campo subred: 5 bits Campo sistema: 3 bits Campo red: 24 bits Campo subred: 6 bits Campo sistema: 2 bits Campo red: 24 bits Campo subred: 7 bits Campo sistema: 1 bits 3

4 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=2 2 subredes clase C de 64 =2 6 nodos cada una: RRRRRRRR.RRRRRRRR.RRRRRRRR.RR NNNNNN Nodos 64=2 6 Máscara de red = Ej. 2: C Netmask Para obtener 8=2 3 subredes de 32=2 5 nodos la máscara = Suele ser habitual encontrar la siguiente notación en el direccionamiento privado: /24, donde 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

5 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 antes de haber añadido la ruta con route add default gw 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 eth netmask broadcast Una vez que la tarjeta de red está configurada, se intenta hacer telnet a la dirección IP y el resultado será: telnet La máquina nos está informando de que la red es inalcanzable para ella, cosa bastante lógica ya que la telnet:unable pasarela por defecto to de un connect sistema (o to gateway) remote es el host: modo que Network esta tiene is de salir unreachable al exterior. Una vez añadida una pasarela por defecto, al hacer telnet se obtendrá lo siguiente: telnet 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

6 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 localhost.localdomain localhost puesto31 puesto31.unex.es 6

7 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 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 /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 The Well Known Ports are those from 0 through The Registered Ports are those from 1024 through The Dynamic and/or Private Ports are those from through 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

8 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 localhost trinux 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. 5.8 (Berkeley) 5/9/91 $Id: services,v /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

9 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 >> 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

10 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 traceroute to espantaperros.unex.es ( ), 30 hops max, 38 byte packets 1 norba.unex.es ( ) ms ms * ( ) ms ms ms ( ) ms ms ms 4 espantaperros.unex.es ( ) ms ms 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 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 ( ), 30 hops max, 38 byte packets 1 norba ( ) ms * ms ( ) ms ms * ( ) ms ms ms 4 * * AT EB-Badajoz0.red.rediris.es ( ) ms 5 EXT.SO1-1-0.EB-IRIS4.red.rediris.es ( ) ms ms ms ( ) ms ms ms 7 zeppo.rediris.es ( ) ms ms ms 10

11 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 traceroute: Warning: has multiple addresses; using traceroute to ( ), 30 hops max, 38 byte packets 1 norba ( ) ms * ms ( ) ms ms ms ( ) ms ms ms 4 * * AT EB-Badajoz0.red.rediris.es ( ) ms 5 EXT.SO1-1-0.EB-IRIS4.red.rediris.es ( ) ms ms ms 6 SO1-0-0.EB-IRIS2.red.rediris.es ( ) ms ms ms 7 RI.SO0-0-0.EB-IRIS5.red.rediris.es ( ) ms ms ms 8 lambdanet-1.espanix.net ( ) ms ms ms 9 M-1-pos121.es.lambdanet.net ( ) ms ms ms 10 F-8-eth100-0.de.lambdanet.net ( ) ms ms ms 11 Google-F.de.lambdanet.net ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * 11

12 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 le corresponden diversas direcciones IP (también indica que el comando se ejecutará con una de ellas, en este caso ). 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 netmask ff le0: flags=863<up,broadcast,notrailers,running,multicast> mtu 1500 inet netmask fffff000 broadcast le1: flags=863<up,broadcast,notrailers,running,multicast> mtu 1500 inet netmask ffffffc0 broadcast 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 = Máscara de Norba: f f f f f f c = (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

13 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 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 /07/08 SMI" /* SVr */ 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

14 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 nameserver nameserver nameserver nameserver nameserver Este fichero almacena las direcciones IP de los distintos servidores de nombres a los que el sistema puede acceder. 14