Resumen de CCNA 1 (Network Fundamentals) capítulos 1 al 6 por Paulo Colomés – Instructor CCNA – Universidad Tecnológica de Chile Sede Temuco – Julio 2010

Este documento ha sido elaborado como una guía resumen para ayudar al estudiante de CCNA a enfocarse en los elementos clave de cada capítulo del módulo CCNA 1: Network Fundamentals. Se incluye un resumen de los aspectos más importantes de los capítulos 1 al 6. Si encuentra errores o sugiere algún comentario a esta guía puede hacerlo al correo pcolomes@gmail.com

Capítulo 1: Vivendo en un mundo centralizado en la red Arquitectura de Redes

Las características más importantes de la arquitectura de redes en la actualidad son:

- Tolerancia a Fallas

- Escalabilidad

- Calidad de Servicio (QoS)

- Seguridad

La tolerancia a fallas es la capacidad de una red de responder a un evento de falla sin que se pierda el servicio que se está ofreciendo. La escalabilidad es la capacidad de planificar el crecimiento de una red en un período de tiempo estimado. La calidad de servicio (QoS) es la capacidad de ofrecer elementos de priorización de datos a los múltiples servicios dentro de una red utilizando como criterio de priorización la importancia de los datos, la sensibilidad a la latencia (VoIP por ejemplo) o la preferencia de los protocolos, entre otros. La seguridad significa que la red debe tener algún mecanismo que proteja tanto sus componentes (dispositivos de networking, cableado, etc.) como a sus usuarios (virus, troyanos, hackers, etc.).

Redes Convergentes

Las redes convergentes son aquellas donde se integran múltiples servicios dentro de un único medio físico. A diferencia de hace algunos años donde las compañías instalaban una red telefónica, una cableado de datos y otro cableado de video, hoy en día se busca incorporar todas las tecnologías dentro de una sola. Es indispensable contar con QoS para el buen funcionamiento de una red convergente.

Capítulo 2: Comunicación en la red Los protocolos

Un protocolo es un conjunto de normas y/o reglas que se utilizan para sincronizar la comunicación entre dos o más dispositivos. Esto es importante desde el punto de vista de la gran diversidad de fabricantes de hardware y software quienes deben tener un punto de referencia a la hora de desarrollar sus tecnologías para asegurar la interoperabilidad de los productos independientemente de la marca.

Modelos de redes

Hoy en día se utilizan 2 modelos para el trabajo en redes: OSI y TCP/IP. El primero se conoce como “modelo de referencia” ya que es ampliamente utilizado en ambientes de aprendizaje y en el desarrollo de tecnologías, protocolos y modelos nuevos, no siendo muy utilizado en la práctica a diferencia de TCP/IP que se usa en la mayoría de las instalaciones de redes. Internet es una red basada en TCP/IP.

Modelos en Capas

La figura muestra las capas de los modelos TCP/IP y OSI respectivamente con su nivel de igualdad. En el medio se ejemplifican algunos protocolos y/o elementos de las capas respectivas. El diseño de estos modelos basados en capas ofrece la enorme ventaja de asegurar la interoperabilidad de software y hardware, ya que cada capa es independiente de las otras y solo se comunica con la

capa superior o inferior.

Funcionalidad de las capas del modelo OSI

Al explicar el funcionamiento y la misión de cada capa del modelo OSI se puede deducir el comportamiento de las mismas en el modelo TCP/IP ya que estas se encuentran fusionadas, como es el caso de la capa de aplicación en TCP/IP que corresponde a Sesión, Presentación y Aplicación de OSI.

Capa 7: Aplicación

La capa de aplicación tiene como objetivo ofrecer acceso a la red a las aplicaciones (software) y es aquí donde se generan los datos o carga útil (payload) de los mensajes. Las aplicaciones utilizan protocolos de esta capa para enviar/recibir los datos interesantes. Algunos protocolos que operan en esta capa son HTTP, HTTPS, DHCP, DNS, FTP, Telnet, SSH, POP, SMTP, MySQL, IMAP, etc. Al hacer una analogía entre el envío de datos en una red con el envío por correos de una carta escrita, esta capa sería similar al contenido mismo de la carta, incluyendo el saludo de la persona que escribe y el texto que quiere dar a conocer al receptor.

Capa 6: Presentación

Esta capa se preocupa de que los datos enviados por las aplicaciones sean “entendidos” por el receptor. Se asegura de que exista una coherencia en cuanto a lenguaje, codificación y en algunos casos semántica de los datos que se envían con respecto a quien los recibe. Algunos ejemplos de esta capa son JPEG, Mp3, Lenguaje SQL, SMB, RPC (Remote Procedure Call), etc. En la analogía de la carta, esta capa representaría la situación donde el remitente escribe en un idioma que el destinatario pueda comprender, por ejemplo, español.

Capa 5: Sesión

La capa de sesión se preocupa de iniciar, mantener y terminar las sesiones de red. Aquí se establecen los puertos (de destino y origen) para las conexiones que utilizan los protocolos de aplicación (Ej: HTTP -> Puerto 80, SMTP -> Puerto 25, etc.) a diferencia del modelo TCP/IP donde los puertos corresponden a la capa de transporte.

Capa 4: Transporte

Esta capa se ofrece la posibilidad de escoger distintos protocolos de transporte, como son TCP y UDP. Aquí los datos se segmentan en bloques que son enviados a la red y luego son re ensamblados en el destino. Además se ofrece control de errores y seguimiento de los segmentos mediante un mecanismo de secuenciación. En la analogía de la carta, aquí nuestro mensaje es dividido en pequeñas encomiendas, cada una secuenciada y son enviadas en forma separadas por el mundo. Si se escoge el servicio “Premium” de envío de correspondencia, es similar a escoger TCP ya que este es más caro en términos de consumo de recursos (CPU, ancho de banda, latencia, etc.) pero nos aseguramos de que la carta llegue a destino, no siendo así con UDP, que

correspondería al servicio “tradicional”.

Capa 3: Red

En esta capa ocurre el direccionamiento. En la actualidad el tipo de direccionamiento más utilizado es IPv4 (pronto a dar paso a IPv6). En esta capa se agrega la información de la dirección IP de origen (máquina que envía) y dirección IP de destino (máquina objetivo, generalmente un servidor). En el caso de la analogía del correo, esta capa corresponde al hecho de escribir en el sobre la dirección y los datos del remitente y también del destinatario. Así, la empresa de correos podrá tomar esa información y reenviar la carta por todo el mundo hasta que llegue a su destino. De la misma manera los Routers toman la información de IP de origen y destino para enviar los datos por todo Internet. Por eso se dice que los Routers son dispositivos de capa 3. Algunos ejemplos de protocolos de capa 3: IP, IPX, AppleTalk, RIP, OSPF, EIGRP, BGP.

Capa 2: Enlace de datos

Esta capa se preocupa de controlar el envío de los datos por el medio físico y establecer la comunicación de extremo a extremo en el medio. Aquí se dividen los paquetes provenientes de las capas superiores, son encapsulados en una trama dependiente del medio (Ethernet, Wireless, etc.). Un ejemplo de esta capa son las direcciones MAC y los protocolos Ethernet, Wi-Fi, Bluetooth, entre otros.

Capa 1: Física

En esta capa se producen todos los fenómenos físicos asociados con la transmisión misma, como flujos de voltaje dentro de un cable, generación de ondas electromagnéticas en una antena, codificación de pulsos de luz, etc. Los estándares de la capa física son 10-BASE-T, 100-BASE-TX, POTS, DSL, RS232, etc. En esta capa ocurre la transmisión binaria (0 y 1).

Proceso de encapsulación

Uno de los conceptos más importantes del trabajo con modelos basados en capas en las redes es el concepto de encapsulación. Este proceso en el “empaquetamiento” de los datos a medida que van descendiendo de la capa 7 a la 1 en el host emisor y donde cada una de las capas agrega información relevante a su funcionamiento. Esta información recibe el nombre de PDU (Protocol Data Unit).

Cada PDU recibe un nombre dependiendo de la capa donde se ubica:

Nombre de la Capa Nombre de la PDU

Aplicación Datos

Presentación Datos

Sesión Datos

Transporte Segmento

Red Paquete

Enlace de Datos Trama

Física Bits

El proceso de encapsulación aparece explicado en la figura superior. Los datos originados por la capa de aplicación (Ejemplo, el mensaje “Hola amigo mío” en un correo electrónico) es pasado a la capa inferior la cual agrega su encabezado (Header), el cual contiene información específica de esa capa. Cuando se tienen los datos + la cabecera de la capa de presentación, se habla de que igualmente son datos, así mismo cuando a los datos se les han agregado las cabeceras de sesión. Pero cuando a los datos + la cabecera de sesión + la cabecera de presentación se le agrega la cabecera de transporte, el conjunto recibe el nombre de segmento. Cuando al segmento se traspasa hacia abajo a la capa de red, esta capa agrega su propia información (direccionamiento IP) en el encabezado de red. El segmento + El encabezado de la capa de red recibe el nombre de paquete. Cuando el paquete es traspasado a la capa de enlace de datos, este es encapsulado en una trama dependiente del medio físico (Ethernet para cable de cobre, Wi-Fi para medios de aire, etc.). En esta capa se agrega un encabezado de enlace de datos (DLH o Data Link Header) y un fin de trama (DLT o Data Link Trailer). Esta trama es más grande o más pequeña dependiendo del medio físico.

Una vez que todo esto se ha encapsulado en una trama, la capa física convierte todo en bits y lo envía codificado por el medio físico. En el lado opuesto las capas desencapsulan la trama entrante

hasta que llega a la aplicación remota (por ejemplo, el servidor de correos).

Esquemas de direccionamiento

El direccionamiento es el proceso de asignar un identificador único a un dispositivo, protocolo o aplicación de tal manera de poder rastrear y direccionar o encaminar los datos generados hacia el destino. En los modelos TCP/IP y OSI podemos encontrar al menos 3 tipos de direccionamiento:

a) Direccionamiento basado de puertos: Cada conexión levanta un puerto de origen (al azar) en la máquina emisora y dirige el flujo de datos hacia un puerto de destino conocido (ej: puerto 80 en un servidor Web). Este tipo de direccionamiento se da en la capa de sesión del modelo OSI y en la capa de transporte del modelo TCP/IP

b) Direccionamiento basado en IP: Las direcciones IP son el método de direccionamiento más conocido y son administrados en la capa de red OSI (llamada Internet en TCP/IP). Estas direcciones son tomadas por los routers para dirigir los paquetes hacia las redes correspondientes

c) Direccionamiento MAC: Las direcciones MAC son un método conocido de direccionamiento de capa 2. Los switches, Access points y otros dispositivos de capa 2 utilizan estos datos para reenviar el tráfico en la red. En las redes Frame Relay se utilizan los DLCI para direccionamiento de capa 2, en ATM se utilizan los VPI/VCI, etc.

Capítulo 3: Capa de Aplicación A los protocolos de aplicación más conocidos se les han asignado un número de puerto que va entre el 1 y el 65535 (Recuerde que el total de puertos en TCP/IP es de 2 16, que son 65536 puertos, entre el 0 y el 65535) y un protocolo de transporte de uso común, aunque pueden utilizar cualquiera. La siguiente tabla resume algunos de los protocolos de aplicación más comunes junto con su RFC (Request for Comments). El RFC es el documento oficial que describe a un protocolo usado en Internet.

Protocolo N° de puerto Proto. De Transporte

RFC

HTTP 80 TCP 2616

SMTP 25 TCP 2821

FTP 21 TCP 959

POP 110 TCP 1939

DHCP 67-68 UDP 2132

Telnet 23 TCP 318

DNS 53 UDP/TCP 1034 Los RFC de cualquier protocolo pueden consultarse en www.rfc - es.org . Algo interesante de notar es que mientras más antiguo es un protocolo, más bajo es el RFC. Así, se puede deducir que antes de que existiera HTTP se usaba con mucha frecuencia Telnet y FTP.

Modelos de Redes

Básicamente se conocen 2 modelos de redes (no confundir con los modelos en capas mencionados anteriormente): Modelo Cliente-Servidor y Modelo Punto-a-Punto.

Bajo el modelo Cliente – Servidor, existen ambos roles claramente diferenciados. Un host dentro de una red actúa como cliente y es éste quien inicia la conexión hacia un servidor remoto. En el otro extremo existe el servidor, quien es el host que recibe conexiones todo el tiempo y las responde. Se llama servidor porque este ofrece un servicio de red (HTTP, FTP, etc.). El servidor está en todo momento escuchando conexiones. En otras palabras el cliente solicita y el servidor ofrece. Ejemplos de este modelo son habituales en la vida diaria, como por ejemplo al abrir una página Web. En este caso utilizamos un cliente HTTP (Navegador como Internet Explorer o Firefox) y nos conectamos a un servidor HTTP (http://www.paginaweb.com).

Existe otro modelo denominado “punto a punto” o P2P (Peer-to-Peer, por sus siglas en inglés).

Modelo P2P

En el modelo P2P no existe el rol de “cliente” o “servidor” claramente indicado, si no que todos los hosts pueden actuar como clientes o servidores en cualquier momento y simultáneamente inclusive. Es por esto que a las populares redes de descargas de archivos (KaZaa, eMule, Torrent. GNUTella, etc.) se les denomina P2P, ya que en un instante un PC pasa de ser cliente al momento de descargar un archivo a servidor en el momento de que otro usuario lo descarga de su máquina.

Servidor -Modelo Cliente

No se debe confundir el modelo de redes P2P con las topologías punto a punto. Las primeras son identificadas a nivel de aplicación (software) mientras que las segundas obedecen a una implementación física de un medio punto a punto, como puede ser un enlace de microondas entre una montaña y otra o una conexión entre PC con cable cruzado. El concepto de modelo de red punto a punto se aplica únicamente a las redes que operan así a nivel de software.

Capítulo 4: Capa de Transporte La capa de transporte se encarga fundamentalmente de establecer la conexión y ofrecer control de errores. Existe una variada gama de protocolos de transporte pero los más utilizados son TCP (Transfer Control Protocol) y UDP (User Datagram Protocol). Otros protocolos de transporte son SCTP, RTP, etc.

Las diferencias entre TCP y UDP son muy grandes, principalmente porque TCP ofrece un nivel de seguridad mucho mayor que UDP. Se dice que TCP es orientado a la conexión y UDP es no orientado a la conexión (Connectionless). Esto significa que los sistemas que trabajen con TCP se aseguran de que se establezca una conexión de extremo a extremo y que existan mecanismos de control de errores (como CRC, secuenciación y reenvío de segmentos) los cuales permiten una conexión mucho más fiable. UDP por otro lado no ofrece el establecimiento de una conexión ni tampoco ofrece soporte para el control de transmisión. Se puede decir que UDP es un protocolo menos “prolijo” en su trabajo, sin embargo es utilizado en un sinnúmero de aplicaciones que no podrían funcionar bien bajo TCP.

Una transferencia bancaria debe ser realizada con la mayor seguridad posible, y es por eso que se utiliza TCP para realizarlas (mediante HTTPS por ejemplo), o cuando se envía un archivo en red mediante FTP. En este caso también es necesario establecer la conexión y reenviar los datos si se pierde alguno, de otra manera el archivo original nunca llegaría completo a destino o llegaría corrupto. Por otro lado las conexiones de video o voz sobre IP generalmente usan UDP ya que al no tener un control de errores ni un seguimiento muy minucioso sobre los datos que se envían por la red, no hay pérdida de tiempo ni recursos en procesar esos datagramas (se denominan así los segmentos que utilizan UDP). La voz quizás es un ejemplo más clarificador. Cuando el usuario habla, espera que la comunicación sea lo más fluida posible y que no hayan molestos retrasos que generen eco y otros efectos (metalización, interrupciones, intermitencias, etc.). Si la voz se trabajara por TCP, habría una pequeña pérdida de tiempo por conceptos de control, lo cual atentaría contra lo que se busca en una comunicación de voz: fluidez. Es por esto que se utiliza UDP. Se sacrifica seguridad por fluidez y rapidez.

En la capa de transporte del modelo TCP/IP ocurre el direccionamiento de puertos. Los puertos son 216 (65536 entre el 0 y el 65535), ya que en el encabezado de transporte (header) existe un espacio de 16 bits para incluir el puerto de origen y 16 bits para el puerto de destino. Un listado detallado de las aplicaciones y puertos más comunes puede encontrarse en http://packetlife.net/media/library/23/common_ports.pdf

El tamaño de la ventana TCP (TCP Windows Size)

El tamaño de la ventana TCP consiste en el tamaño del buffer que se ha sincronizado entre emisor y destinatario para el envío de los datos. La importancia del concepto del deslizamiento del tamaño de la ventana tiene gran relevancia en cuanto a la calidad del ancho de banda destinado a ser utilizado en una transferencia por la red. En una conexión entre cliente y servidor, el cliente le dice al servidor cuantos bytes desea recibir de una sola vez desde el servidor. Este es el tamaño de la ventana de recepción del cliente, lo que a su vez se convierte en el tamaño de ventana de envío del servidor. De la misma manera, el servidor le dice al cliente cuantos bytes de datos desde aceptar desde el cliente en una sola transmisión. Este sería el tamaño de envío de la ventana del servidor y el tamaño de recepción del cliente. (Ref: http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm)

El ajuste del tamaño de la ventana TCP es relativo al ancho de banda disponible, pero como norma general se dice que en redes de alto ancho de banda conviene un tamaño de ventana mayor. Este valor puede configurarse entre 2 y 65535 bytes.

Saludo TCP de tres vías (Three-Way Handshake)

Cuando se inicia una transmisión utilizando TCP, este debe establecer una conexión. El establecimiento es un proceso de tres fases denominado saludo de tres vías. Los humanos utilizan un saludo de dos vías para establecer una comunicación (Persona 1: Hola, ¿Cómo estás?; Persona 2: Hola. Muy bien ¿y tú?...), pero las máquinas requieren un paso más de tal manera de tener la confianza definitiva.

Saludo de 3 vías TCP

Cuando Host A quiere iniciar una conexión TCP con Host B primero le envía un mensaje denominado SYN (Synchronize). Este es un saludo conocido por cualquier host que ejecuta TCP/IP como parte de su configuración de red. Es equivalente al humano “Hola, quiero conversar contigo”. Cuando Host B recibe un flag SYN, entiende que alguien quiere hablarle por lo cual inicia un proceso de respuesta. Esta respuesta incluye un SYN y también un mensaje de tipo ACK

(Acknowledgement – Acuse de Recibo). El similar humano de esta respuesta sería algo como “Hola, acepto conversar contigo (SYN), ah! Y te confirmo que me llegó tu mensaje anterior (ACK)”.

En el tercer paso la conexión se establece cuando el Host A le envía de vuelta un mensaje ACK al Host B. El similar humano sería: “Te informo que me llegó tu mensaje indicando que aceptar conversar conmigo”.

La comunicación se mantiene activa hasta que uno de los dos hosts envía o recibe un flag RST (Reset) o FIN (Finalize).

Vale mencionar que el protocolo UDP carece de un mecanismo similar a este ya que en ese caso NO se establecen conexiones porque UDP es NO orientado a la conexión (Connectionless).

Corrección de Errores y Confiabilidad de TCP

TCP se vale de varios elementos para asegurar la confiabilidad de una transferencia y corregir/controlar los errores si existiesen. Los métodos principales son segmentación, secuenciación, reensamblaje y CRC.

Segmentación

Todos los datos que son procesados por la capa de transporte son divididos para ser enviados por la red. Cada uno de estos bloques se conoce como segmento. El tamaño de los segmentos está especificado por un valor en bytes denominado MSS (Maximum Segment Size o Tamaño Máximo del Segmento). Para que la comunicación sea óptima, el tamaño de un paquete (compuesto por la MSS + el encabezado de la capa de red) debe ser menor al de la MTU (Maximum Transfer Unit o Unidad Máxima de Transferencia, la cual generalmente es de 1500 bytes aproximadamente).

Cuando son enviados al medio, estos segmentos viajan independientemente ya que cada uno incluye información de la cabecera IP la cual contiene las direcciones IP de origen y destino. Si un bloque se extravía, se pierde o se daña, el protocolo TCP se encarga de reenviar únicamente ese bloque y NO todos los datos originales (que pueden sobrepasar el tamaño de varios GB).

Secuenciación y reensamblaje

Como los segmentos pueden tomar rutas alternativas en la red (ya que son independientes) se hace entonces necesario utilizar algún método que permita ordenar los bloques a medida que van llegando al destino. Para esto se agrega un número de secuencia (seq) a cada segmento que le servirá de referencia a TCP al momento de rearmar los datos originales. Ejemplo: Si se envían los bloques 1, 2, 3 y 4 en ese orden, el bloque 1 puede tomar una ruta alternativa al bloque 2, lo mismo ocurre con 3 y 4, pero al momento de llegar al destino deben reordenarse. Si primero llega un bloque 3, el host de destino pone el segmento en un buffer a la espera de los bloques 1 y 2. Cuando esto se cumple, el protocolo TCP del host de destino reordena los segmentos y reconstruye el mensaje original. Todo este proceso ocurre gracias a los sistemas de multiplexión (MUX) que existen en los dispositivos de networking.

Proceso de Multiplexión

La multiplexión consiste en la capacidad de un medio de transmisión de poder enviar datos intercalados de distintos orígenes de forma simultánea lo cual permite utilizar dicho medio de forma compartida. El dispositivo multiplexor (MUX) divide e intercala los datos en el medio mientras que en el extremo opuesto el demultiplexor (DEMUX) ordena los datos y los reubica hacia el dispositivo y otros medios correspondientes.

CRC (Cyclic Redundancy Check o Verificación de la redundancia Cíclica)

El concepto de verificación de redundancia cíclica no solamente es utilizado por la capa de transporte sino también por algunos protocolos de aplicación y de capa 2 (como Ethernet o 802.11, con la diferencia que ahí se le denomina FCS (Frame Check Sum – Suma de Comprobación de la Trama). Básicamente consiste en un número que permite verificar la integridad de un segmento que ha salido de un host y constatar que ha llegado al destino sin modificaciones o alteraciones. El mecanismo es sumamente simple pero efectivo.

Para explicar esto tomemos como ejemplo un host A (Origen) y un host B (Destino). El Host A ha creado un segmento. Si pudiésemos ver este segmento sería algo como 10010111000101010010100011110100 (en realidad es un flujo de bits mucho mayor pero para ejemplificar se ha acortado). Lo que hace Host A es tomar esos bits y sumarle una secuencia binaria conocida tanto por A como por B, por ejemplo 11001100.

10010111000101010010100011110100 (Segmento original) 00000000000000000000000011001100 (Valor de suma binaria) 10010111000101010010101010001100 = 97152A8C (Número resultante)

Como se muestra en el ejemplo, luego de aplicarle el valor “11001100” al segmento original, se obtiene el valor 10010111000101010010101010001100, lo cual sería 97152A8C en hexadecimal. Lo que hace el protocolo TCP es agregarle el valor resultante (denominado CRC) al segmento que se va a enviar, quedando de la siguiente forma:

Luego este segmento pasará a la capa de red según lo que se ha explicado en el proceso de encapsulación y esa capa le agregará la información de capa 3 correspondiente, así mismo como la capa 2 y posteriormente se enviará por el medio físico. Lo que concierne a la capa de transporte es que cuando este segmento llegue al host B, este tomará la información contenida en él hasta antes del CRC (10010111000101010010100011110100) y le aplicará la misma fórmula de suma binaria mostrada más arriba. El resultado debe ser el mismo que el CRC entrante (97152A8C). De esta manera el host de destino entiende que no se ha perdido ni modificado un solo bit durante la transmisión, ya que de ser así, al momento de realizar la suma binaria de comprobación en el destino se obtendría un resultado totalmente distinto al entrante y eso haría que Host B descarte el segmento y pida al host de origen que le envíe uno de nuevo. No hay que olvidar que cada segmento tiene un número de secuencia que lo identifica. Así, Host B puede decirle a Host A que reenvíe únicamente el bloque 145 ya que llegó con errores.

Capítulos 5 y 6: Capa de Red y Direccionamiento IPv4 Una dirección IP tiene 32 bits de longitud, separadas en cuatro bloques de 8 bits denominados octetos. La representación binaria de una dirección IP sería

11000000.10000001.00001010.01000011 Lo que equivale en decimal a 192.128.10.67.

Ya que las direcciones IP trabajan con bloques de 8 bits, NUNCA se podrá escribir una dirección con un número mayor a 255. Los números van de 0 a 255 ya que son 256 en total. Sabemos que son 256 números diferentes porque al tener 8 bits podemos calcularlo rápidamente con la fórmula 2n

donde n es la cantidad de bits que tenemos. Así, 28 = 256.

La dirección IP más baja posible es 0.0.0.0 y la más alta posible es 255.255.255.255

Esta cantidad de combinaciones da un rango de 232 direcciones IP (ya que son 32 bits en total), lo cual da 4.294.967.296 direcciones en total. Aunque ese número pueda parecer grande, en la Internet de hoy en día es un número bastante bajo y preocupante ya que cada vez quedan menos direcciones IP y posiblemente antes del año 2012 ya se hayan acabado debido a la sobredemanda de tecnologías nuevas que requieren full conectividad (más teléfonos IP, más celulares, consolas de

videojuegos, dispositivos domésticos, automóviles, etc). Ni siquiera alcanza para una dirección IP por habitante en el mundo. Para solucionar ese problema los ingenieros de redes han diseñado un nuevo protocolo de direccionamiento IP denominado IPv6, que en realidad no es nuevo si no un sucesor del tradicional IPv4 conocido simplemente como IP. IPv6 incluye un gran número de mejoras que se verán más adelante.

Es importante saber que en una red, cada host (PC, Notebook, Impresora, Router, etc.) debe tener una dirección IP única e irrepetible, así mismo como las personas cuentan con un número de identificación único. Si se encuentra la situación donde dos máquinas tienen la misma dirección IP, estas provocarán un conflicto que dejará a una de las dos o probablemente ambas sin conexión.

El rango de direcciones 0.0.0.0 al 255.255.255.255 con más de 4 mil millones de direcciones está dividido en 5 grandes categorías denominadas Clases. Cada dirección IP pertenece a una clase determinada que llevan el nombre de A, B, C, D y E.

Clase Dirección de Inicio Dirección de Término

Clase A 0.0.0.0 127.255.255.255

Clase B 128.0.0.0 191.255.255.255

Clase C 192.0.0.0 223.255.255.255

Clase D 224.0.0.0 239.255.255.255

Clase E 240.0.0.0 255.255.255.255

Basándose en estos rangos, la dirección IP 200.34.56.168 sería de clase C, 98.231.56.200 de clase A y 224.0.0.1 de clase D.

La explicación de la asignación de dichos rangos y es porque a nivel binario la clase A corresponde a todas las direcciones IP cuyo primer octeto empiece con “0”, la clase B son las que el primer octeto empieza con “10”, clase C con “110”, clase D con “1110” y clase E con “1111”

Clase A: 0 Clase B: 10 Clase C: 110 Clase D: 1110 Clase E: 11111 Una manera rápida y efectiva de verificar a qué clase pertenece una dirección IP es convertirla a binario y comparar los primeros bits del primer octeto con la especificación anterior. Por ejemplo, la dirección IP 200.33.1.12 es de clase C ya que

200.33.1.12 = 11001000.00100010.00000001.00001100 Como los primeros bits de la dirección comienzan con “110”, entonces pertenece al rango de la clase C.

Direcciones IP especiales

Del rango total de direcciones IP, no todas se pueden configurar en los dispositivos de networking. En otras palabras, no todas las IP son asignables a hosts en la red. Hay ciertos rangos que están reservados a otros usos y por ende no pueden ser configuradas como direcciones específicas de identificación de una máquina.

Las direcciones especiales son las siguientes:

1. 0.0.0.0 a 0.255.255.255: estas direcciones se ocupan principalmente para tareas de enrutamiento (como 0.0.0.0 para las rutas por defecto) y otros cálculos como las máscaras inversas (Wildcards)

2. 127.0.0.0 a 127.255.255.255: este rango completo se asigna a las direcciones denominadas loopback o localhost. Corresponden a direcciones IP especiales utilizadas para realizar conexiones con la misma máquina local.

3. 169.254.0.0 a 169.254.255.255: Se denominan direcciones de enlace local o link-local. Estas direcciones se autoconfiguran en los hosts sin intervención de un usuario o administrador cuando la tarjeta de red está configurada para recibir automáticamente su dirección desde un servidor DHCP pero no encuentra ninguno. También se conocen con el nombre de APIPA (Automatic Private Internet Protocol Addressing).

4. Clase D completa: Todas las direcciones de clase D (entre la 224.0.0.0 a la 239.255.255.255) son direcciones de Multicast (Multidifusión) y son utilizadas solamente cuando se crean grupos especiales en la red. NO son asignables a host.

5. Clase E completa: Al igual que la clase D, la clase E no se utiliza para asignarse a hosts ya que tiene un uso experimental solamente. Los dispositivos de networking no funcionan con una dirección configurada en este rango.

6. 255.0.0.0 a 255.255.255.255: Se utiliza para las máscaras de red o subred.

Las máscaras de red/subred

Se conoce con el nombre de máscara de subred a las direcciones IP que van en el rango explicado en el punto Nro. 6 anteriormente. Estas direcciones se utilizan para determinar el tamaño de una red (la cantidad de hosts que contiene) y la creación de subredes (Subnetting) o superredes (Supernetting). En una red TCP/IP se requiere obligatoriamente que cada host tenga al menos una dirección IP única y una máscara, la cual es común a todos.

Ejemplo:

En la figura se muestra que cada PC tiene una dirección IP única (200.1.1.X) mientras que todos utilizan la misma máscara (255.255.255.0).

Máscaras por defecto

Dependiendo de la clase a la cual pertenezca la dirección IP de un host, a este se le asigna una

máscara por defecto para dicha clase. Esto se conoce como Direccionamiento con Clase (Classfull).

Clase Máscara por defecto

A 255.0.0.0

B 255.255.0.0

C 255.255.255.0

D No tiene

E No tiene

Así, una dirección IP de clase A, como 130.134.43.111 debería utilizar la máscara 255.0.0.0 bajo el esquema de direccionamiento con clase. Actualmente este esquema está obsoleto por ser sumamente restrictivo en cuanto a la asignación de direcciones IP porque la tendencia es a buscar mecanismos para optimizar al máximo su uso debido a la escasez de IPv4. Hoy se utiliza el direccionamiento sin clase (Classless). Este método permite utilizar una IP con cualquier máscara independiente de la clase a la cual pertenezca la dirección. La misma IP 130.134.43.111 puede utilizarse con la máscara 255.255.0.0, 255.255.255.0 o 255.255.255.248.

Las máscaras son direcciones cuyos bits correlativos de izquierda a derecha son solamente 1 y solo 0 hacia la derecha. Nunca se intercalan los 1 y 0 en las máscaras a diferencia de una IP común. Para clarificar este concepto basta escribir en binario una máscara.

255.0.0.0 = 11111111.00000000.00000000.00000000 255.255.0.0 = 11111111.11111111.00000000.00000000 255.255.255.0 = 11111111.11111111.11111111.00000000 255.255.255.248 = 11111111.11111111.11111111.11111000

La principal función de las máscaras de red/subred es determinar la porción de red, porción de subred y porción de host. Estas porciones corresponden a qué partes de una dirección IP son comunes a todos los hosts de una red y cuales se pueden ir cambiando.

Porciones de red y de host

La porción de red es aquella que todos los hosts deben mantener en común. En la topología mostrada en la figura anterior todas las IP comienzan con 200.1.1, mientras que el último octeto de la dirección es la que varía. En este caso la porción de red es 200.1.1 y la porción de host es el último octeto. La máscara es quien determina las porciones de red y host en una IP. Al comparar binariamente la IP de host con su máscara, la porción de red está dada por los bits en 1 de la máscara y la porción de host está dada por los bits en 0. Si se compara 200.1.1.1 con 255.255.255.0 obtenemos que:

Porción de Red Porción de host

200.1.1.1 = 11001000.00000001.00000001.00000001 255.255.255.0 = 11111111.11111111.11111111.00000000

En este caso la porción de red es 200.1.1 ya que en la máscara, los tres primeros octetos están en 1. Lo demás es la porción de host (donde la máscara está en 0). En términos simples esto quiere decir que para que exista conectividad a nivel IP en esta red es necesario que todos los hosts empiecen por 200.1.1, de lo contrario se estaría “fuera de la red”. Si una IP empieza con 200.1.2., estaría fuera de la red. La solución sería utilizar una máscara 255.255.0.0:

Porción de Red Porción de host

200.1.1.1 = 11001000.00000001.00000001.00000001 255.255.0.0 = 11111111.11111111.00000000.00000000

Si la máscara fuese 255.255.0.0, entonces 200.1.1.1 y 200.1.2.20 estarían dentro de la misma red.

Poder identificar correctamente las porciones de red y host es un proceso clave para realizar bien los cálculos de direccionamiento.

Teniendo bien definidas las porciones de red y de host, es posible determinar en primera instancia

cuantas máquinas se pueden direccionar en la red que se está creando utilizando la fórmula n

2 -2

Donde n es la cantidad de bits que tiene la porción de host. En el caso de arriba, con la máscara 255.255.255.0, la porción de host contiene 8 bits, por lo que:

8 2 -2 =256-2 =254 Alcanzan 254 direcciones IP asignables a host. ¿Y qué pasa con las otras 2? Una se utiliza para dirección de red y la otra para dirección de broadcast.

Las direcciones de red y broadcast comprenden un concepto importantísimo al momento de realizar el cálculo de direcciones, ya que estas dos IP NUNCA se asignan a host ya que existen de manera implícita en cualquier red. Obtener las direcciones de red y broadcast es un proceso

sencillo y solo basta tener en cuenta que:

1. LAS DIRECCIONES DE RED/SUBRED SE OBTIENEN ESCRIBIENDO TODOS LOS BITS DE PORCIÓN DE HOST EN 0 2. LAS DIRECCIONES DE BROADCAST SE OBTIENEN ESCRIBIENDO TODOS LOS BITS DE LA PORCIÓN DE HOST EN 1

En el ejemplo de la IP 200.1.1.1 y la máscara 255.255.255.0 se puede determinar que la dirección de red es 200.1.1.0 y la dirección de broadcast es 200.1.1.255 ya que

Porción de Red Porción de host

11001000.00000001.00000001.00000000 = 200.1.1.0 (subred) 11001000.00000001.00000001.11111111 = 200.1.1.255 (broadcast)

Todas las direcciones intermedias (entre la 200.1.1.1 y 200.1.1.254, ambas inclusive) serían asignables a host. Si un administrador asigna manualmente la IP 200.1.1.255 con máscara 255.255.255.0 a un PC, este no tendrá conectividad de red.

Formato CIDR – Esquema de direccionamiento Sin Clase

La categorización por clases de las direcciones ha servido mucho para poder orientarse dentro del rango de IP existentes, sin embargo el direccionamiento con clase hoy en día está obsoleto por tratarse de un método sumamente limitante en cuanto a la disponibilidad de direcciones. Por la misma razón se prefiere ampliamente el uso del direccionamiento “classless” (sin clase) el cual permite utilizar una dirección de una clase cualquiera con una máscara de cualquier tipo. Por ejemplo, bajo el direccionamiento classfull (con clase), cualquier IP de clase C está obligada a usar una máscara de dicha clase (entre 255.255.255.0 a 255.255.255.252) y una IP de clase A como 10.137.56.1 solamente podría usar una máscara de clase A (entre 255.0.0.0 a 255.254.0.0). Esta limitante ha sido sobrepasada por el esquema classless que permite usar la misma IP 10.137.56.1 con una máscara de otra clase (ej. 255.255.255.252) y no habría problemas.

Nota: En los routers Cisco debe estar implementado el comando ip classless dentro del modo de configuración global

Habitualmente el uso de direcciones sin clase se conoce como CIDR (Classless Interdomain Routing – Enrutamiento entre dominios sin clase). Bajo el formato CIDR las máscaras pueden ser escritas en su forma abreviada dependiendo de la cantidad de bits 1 que contengan. La máscara 255.255.255.0 puede ser escrita igualmente como /24 ya que si se mira binariamente los primeros 24 bits están en 1 y el resto en 0.

En el siguiente cuadro se muestran las máscaras en sus distintos formatos para visualizar lo explicado anteriormente.

Notación decimal Notación binaria CIDR

255.0.0.0 11111111.00000000.00000000.00000000 /8

255.128.0.0 11111111.10000000.00000000.00000000 /9

255.192.0.0 11111111.11000000.00000000.00000000 /10

255.224.0.0 11111111.11100000.00000000.00000000 /11

255.240.0.0 11111111.11110000.00000000.00000000 /12

255.248.0.0 11111111.11111000.00000000.00000000 /13

255.252.0.0 11111111.11111100.00000000.00000000 /14

255.254.0.0 11111111.11111110.00000000.00000000 /15

255.255.0.0 11111111.11111111.00000000.00000000 /16

255.255.128.0 11111111.11111111.10000000.00000000 /17

255.255.192.0 11111111.11111111.11000000.00000000 /18

255.255.224.0 11111111.11111111.11100000.00000000 /19

255.255.240.0 11111111.11111111.11110000.00000000 /20

255.255.248.0 11111111.11111111.11111000.00000000 /21

255.255.252.0 11111111.11111111.11111100.00000000 /22

255.255.254.0 11111111.11111111.11111110.00000000 /23

255.255.255.0 11111111.11111111.11111111.00000000 /24

255.255.255.128 11111111.11111111.11111111.10000000 /25

255.255.255.192 11111111.11111111.11111111.11000000 /26

255.255.255.224 11111111.11111111.11111111.11100000 /27

255.255.255.240 11111111.11111111.11111111.11110000 /28

255.255.255.248 11111111.11111111.11111111.11111000 /29

255.255.255.252 11111111.11111111.11111111.11111100 /30

255.255.255.254 11111111.11111111.11111111.11111110 /31

255.255.255.255 11111111.11111111.11111111.11111111 /32

Creación de subredes (Subnetting)

La creación de subredes da paso a un mejor aprovechamiento de las direcciones IP y da libertad al administrador de red a definir sus propios bloques (subredes) dada una red anterior. Muchas veces el proveedor de servicios de Internet (ISP – Internet Service Provider) entrega solamente un rango definido de direcciones a la organización y es el administrador el encargado de separar dicho rango en áreas diferentes según sean sus necesidades. Volvamos al ejemplo anterior de la dirección 200.1.1.0 con máscara /24:

200.1.1.0 = 11001000.00000001.00000001.00000000 255.255.255.0 = 11111111.11111111.11111111.00000000

La porción de red se muestra en azul y la porción de host en rojo. Si solamente aplicamos estas direcciones IP tal como se muestran acá nos quedarían 254 hosts como se explicaba más arriba. Supongamos que nuestra empresa tiene 3 departamentos claramente diferenciados como Recursos Humanos, Gerencia y Área Técnica. Bajo esta situación no se puede asignar una dirección IP del segmento inicial a todos los PC ya que están en áreas diferentes y cada una debiese ser tratada de manera distinta. La solución a esto es crear subredes. El primer paso para crear subredes es ver binariamente las direcciones IP de red y máscara como se muestran arriba para poder diferenciar las porciones de red y host. Es una norma que la porción de red no se pueda modificar ya que los hosts deben mantener esta porción en común dentro de la misma LAN. Solamente podemos trabajar modificando la porción de host. En este caso contamos con 8 bits de host lo que da origen a 256 direcciones IP distinas (28=256). Esas 256 direcciones se pueden dividir en partes iguales desplazando la máscara hacia la derecha para utilizar bits (o pedir prestados) de la porción de host y así crear un nuevo espacio denominado porción de subred. Si nos desplazamos 1 bit hacia la derecha tendremos entonces 1 bit para subred y 7 bits para host, tal

como se ilustra a continuación RED INICIAL:

Red Host

200.1.1.0 = 11001000.00000001.00000001.00000000 255.255.255.0 = 11111111.11111111.11111111.00000000

DESPLAZAMIENTO EN 1 BIT: Red Subred Host

200.1.1.0 = 11001000.00000001.00000001.00000000 255.255.255.128 = 11111111.11111111.11111111.10000000

Desplazamiento en 1 bit hacia la derecha

Ahora nuestra máscara ya no es /24 si no /25 (nótese el cambio de 255.255.255.0 a 255.255.255.128). Nos queda 1 bit para subred y 7 bits para host. Hemos creado 2 subredes ya que disponemos de 1 solo bit que puede tomar el valor de 0 o de 1. La primera subred es 200.1.1.0/25 como se muestra arriba y la segunda subred se obtiene cambiando el bit de subred a 1:

Red Subred Host

200.1.1.128 = 11001000.00000001.00000001.10000000 255.255.255.128 = 11111111.11111111.11111111.10000000

Por lo tanto tenemos 2 subredes, la 200.1.1.0 /25 y 200.1.1.128 /25. Como quedan 7 bits para host sabemos que cada una de las subredes tendrá 128 direcciones IP en total, pero al restarle la dirección se subred y broadcast a cada una el resultado es 126 IP asignables a host.

Veamos esta situación en mayor detalle:

Red inicial: 200.1.1.0/24

IP: 11001000.00000001.00000001.00000000 MS: 11111111.11111111.11111111.00000000

Al corrernos un bit a la derecha hemos creado el espacio de subred de 1 bit de longitud, lo cual alcanza para dos subredes ya que 21=2 y 7 bits para hosts con lo que alcanza para 128 direcciones IP (27=128) sin embargo es importante notar que SIEMPRE en la porción de host debemos descontar 2 IP para encontrar el total de direcciones asignables realmente a cada host, pues todas las subredes utilizan la primera dirección IP para identificar el mismo bloque, la cual recibe el nombre de “dirección de subred” y la última dirección para utilizarla como broadcast (“dirección de broadcast”). Además la máscara ha cambiado de /24 a /25. La /24 ya no es utilizable.2

Primera subred:

MS: 11111111.11111111.1111111.10000000

IP de subred: 11001000.00000001.00000001.00000000 (200.1.1.0) Primera dirección asignable a host: 11001000.00000001.00000001.00000001 (200.1.1.1) Segunda dirección asignable a host: 11001000.00000001.00000001.00000010 (200.1.1.2) . . . Penúltima dirección asignable a host: 11001000.00000001.00000001.01111101 (200.1.1.125) Última dirección asignable a host: 11001000.00000001.00000001.01111110 (200.1.1.126) IP de broadcast: 11001000.00000001.00000001.01111111 (200.1.1.127) Segunda subred:

IP de subred: 11001000.00000001.00000001.10000000 (200.1.1.128) Primera dirección asignable a host: 11001000.00000001.00000001.10000001 (200.1.1.129) Segunda dirección asignable a host: 11001000.00000001.00000001.10000010 (200.1.1.130) . . . Penúltima dirección asignable a host: 11001000.00000001.00000001.11111101 (200.1.1.253) Última dirección asignable a host: 11001000.00000001.00000001.11111110 (200.1.1.254) IP de broadcast: 11001000.00000001.00000001.11111111 (200.1.1.255)

En conclusión, al dividir la red 200.1.1.0/24 en 2 subredes mediante el desplazamiento de 1 bit se obtiene un bloque desde la IP 200.1.1.0 hasta 200.1.1.127 las cuales son las direcciones de subred y broadcast respectivamente por lo tanto el rango asignable a hosts es de 200.1.1.1 a 200.1.1.126. En el segundo bloque (o segunda subred) la dirección de subred es 200.1.1.128 y broadcast es 200.1.1.255, así que el rango asignable a hosts es de 200.1.1.129 a 200.1.1.254

Note que en todos los casos la dirección de subred de cualquier bloque IP se obtiene pasando completamente la porción de host a 0 y la dirección de broadcast se obtiene pasando completamente la porción de host a 1.

Cuando se crean subredes es bastante simple calcular la totalidad de subredes que alcanzarán y el total de direcciones de host por cada una de ellas. Basta utilizar las siguientes fórmulas:

Cantidad de subredes = 2n donde n es la cantidad de bits en el espacio de subred

Cantidad de host por subred = 2x-2 donde x es la cantidad de bits en el

espacio de host.

Por ejemplo, si se tiene la dirección 172.16.0.0/16 y se mueve la máscara a /22 se tiene que:

172.16.0.0 = 10101100.00010000.00000000.00000000

/16 = 255.255.0.0 = 11111111.11111111.00000000.00000000

Sin segmentar aún podemos comparar binariamente la IP con la máscara y determinar que la

porción de red es 172.16 y la porción de host es 0.0. Los 16 bits de la porción de host indican que hay 216-2 direcciones de host o 65534 en total. Al desplazar la máscara /16 hacia /22, el espacio de subred queda con 6 bits, los 10 restantes son para host:

Red Subred Host

172.16.0.0 = 10101100.00010000.00000000.00000000

/22= 255.255.252.0 = 11111111.11111111.11111100.00000000

Por lo tanto, dadas las fórmulas anteriores rápidamente calculamos que la cantidad de subredes es de 26=64 y la cantidad de hosts por cada subred es de 210-2=1022

Rutas por defecto

Un router es el dispositivo responsable de redireccionar y enrutar los paquetes IP en las redes, por lo tanto ellos deben saber en todo momento qué hacer cuando ingresa un paquete IP en una interfaz. Existen tres posibilidades:

1.- Que la dirección IP de destino no la conozca el router y por lo tanto descarta ese paquete, ante lo cual inmediatamente envía un mensaje ICMP (Internet Controlo Message Protocol) al host de origen indicándole que él no sabe cómo llegar a esa IP (seguramente habrán visto el típico mensaje de ping “host de destino inalcanzable”).

2.- Que la dirección IP de destino se encuentre en una de las interfaces conectadas del router. En este caso simplemente se envía a la interfaz que corresponde y el paquete sigue su recorrido en la LAN.

3.- Que la dirección IP de destino se encuentre en una red más allá de las redes directamente conectadas del router.

Las rutas en general tienen relación con el punto N°3.

Las rutas por defecto (o default route, o “quad zero”) se escriben en la forma 0.0.0.0, lo que quiere decir que coincida cualquier IP (quienes conozcan el concepto de Wildcards,esto les será familiar). Dentro de la línea de comandos del IOS de Cisco, las rutas por defecto se aplican en el modo de configuración global:

Router(Config)# ip route 0.0.0.0 0.0.0.0 NextHop

El valor “NextHop” (siguiente salto) indica la dirección IP del router al cual se le va a enviar los paquetes IP que coincidan con la ruta por defecto.

Última actualización: 28/07/2010.

Paulo Colomés. Instructor CCNA sede Temuco Universidad Tecnológica de Chile – INACAP