Está en la página 1de 13

RIP – Routing Information Protocol

Introducción Histórica
Uno de los protocolos de routing más antiguos es el Routing Informacition Protocol o más comúnmente
llamado RIP. RIP utiliza algoritmos de vector distancia para calcular sus rutas. Este tipo de algoritmos para
calcular rutas fueron utilizados durante décadas en sus distintas variantes. De hecho los algoritmos de vector
distancia utilizados por RIP están basados en aquellos algoritmos utilizados por ARPANET en el año 1969.
Los protocolos vector distancia fueron descritos académicamente por: R.E. Bellman, L.R. Ford Jr y D.R.
Fulkerson1.
La primera organización que implementó un protocolo de vector distancia fue la compañía Xerox en su
protocolo GIP (Gateway Information Protocol), este protocolo estaba incluido dentro de la arquitectura XNS
(Xerox Network Systems). GIP se utilizaba para intercambiar información de routing entre redes o sistemas
autónomos no adyacentes. Pero claro, Xerox había implementado su propio protocolo propietario.
Poco después la University of California en Berkeley creo una variante llamada “routed2”, esta variante del
GIP introdujo novedades como modificación del campo de direccionamiento, que se consiguió más flexible3,
también se añadió un temporizador que limitaba a 30 segundos el tiempo máximo de actualización, es decir,
el tiempo máximo permitido sin saber la información de los vecinos, y por supuesto se integró dentro de
UNIX, con lo cual pasó a ser abierto.
El protocolo RIP, tal cual lo conocemos actualmente, fue descrito por primera vez en el RFC 1058
(http://www.rfc-editor.org/rfc/rfc1058.txt) por C. Hedrick de la Rutgers University en Junio de 1988, y
posteriormente fue mejorado en la RFC 2453 (http://www.rfc-editor.org/rfc/rfc2453.txt) por G.Malkin de la
compañía Bay Networks en Noviembre de 1998.
Desde el año 1998 el protocolo RIP se ha mantenido estable, aunque posteriormente salió la versión para
Ipv6, la cual tiene su propio capítulo.

Introducción Técnica
RIP es un protocolo de routing de vector distancia muy extendido en todo el Mundo por su simplicidad en
comparación a otros protocolos como podrían ser OSPF, IS-IS o BGP. RIP se trata de un protocolo abierto a
diferencia de otros protocolos de routing como por ejemplo IGRP y EIGRP propietarios de Cisco Systems o
VNN propietario de Lucent Technologies.
RIP está basado en el algoritmo de Bellman Ford y busca su camino óptimo mediante el conteo de saltos,
considerando que cada router atravesado para llegar a su destino es un salto.
RIP, al contar únicamente saltos, como cualquier protocolo de vector distancia no tiene en cuenta datos tales
como por ejemplo ancho de banda o congestión del enlace.

RFC4 1058: Routing Information Protocol


En Junio de 1988, C. Hedrick publicó el RFC 1058 correspondiente a RIP versión 1, y lo encabezó de la
siguiente manera:

“This RFC describes an existing protocol for exchanging routing information among gateways
and other hosts. It is intended to be used as a basis for developing gateway software for use in
the Internet community. Distribution of this memo is unlimited.”

1
2
3
4
El protocolo RIPv1, al igual que sus antecesores propietarios es un protocolo de routing que fue diseñado
para funcionar como protocolo vector distancia. RIPv1 fue diseñado para funcionar en redes pequeñas de
pasarela interior5. RIPv1 está basado según el autor del RFC en la versión 4.3 de la distribución de UNIX de
Berkeley.
En cuanto al protocolo tenemos que tener en cuenta las tres limitaciones que C. Hedrick describe en la página
3 del RFC 1058:
• El protocolo no permite más de quince saltos, es decir, los dos routers más alejados de la red no
pueden distar más de 15 saltos, si esto ocurriera no sería posible utilizar RIP en esta red.
• Problema del “conteo a infinito”. Este problema puede surgir en situaciones atípicas en las cuales se
puedan producir bucles, ya que estos bucles pueden producir retardos e incluso congestión en redes en
las cuales el ancho de banda sea limitado. El autor del RFC 1058 también comenta que en la realidad
esto sólo puede ser un problema en redes lentas, pero el problema existe.
• El protocolo utiliza métricas fijas para comparar rutas alternativas, lo cual implica que este protocolo
no es adecuado para escoger rutas que dependan de parámetros a tiempo real como por ejemplo
retardos o carga del enlace.
Además de los problemas que cita el autor del protocolo tenemos que tener en cuenta que el protocolo RIPv1
es un protocolo classful6, con lo que existe el problema de la discontinuidad de redes. El problema de la
discontinuidad de redes se produce en el momento que tenemos una red dividida en varias subredes y no
pueden ser sumarizadas en una misma ruta, ya que físicamente cada una de las subredes está ubicada en un
lugar que depende de un interfaz distinto una subred de la otra. Pero claro, en la época en la que se escribió
este RFC, que era en 1988 estos problemas no estaban contemplados y con el tiempo se detectó este
problema, esta es una de las razones de la existencia de RIPv2.

Tabla de routing de RIP

Si continuamos la lectura detallada del RFC1058, podemos ver que el autor nos dice que la base de datos de
routing de cada uno de los hosts de la red que están utilizando el protocolo de routing RIP tiene los siguientes
campos:
• Dirección de destino
• Siguiente salto
• Interfaz de salida del router
• Métrica
• Temporizador
Para obtener esta tabla, el protocolo de routing RIP utiliza el siguiente procedimiento para mantener
actualizada la tabla de routing de cada uno de los nodos o routers de la red:
1. Mantener una tabla con una entrada por cada posible destino en la red. La entrada debe contener la
distancia D al destino, y el siguiente salto S del router a esa red. Conceptualmente también debería de
existir una entrada para el router mismo con métrica 0, pero esta entrada no existirá.
2. Periódicamente se enviará una actualización de la tabla a cada uno de los vecinos del router mediante
la dirección de broadcast. Esta actualización contendrá toda la tabla de routing.
3. Cuando llegue una actualización desde un vecino S, se añadirá el coste asociado a la red de S, y el
resultado será la distancia D'. Se comparará la distancia D' y si es menor que el valor actual de D a esa
red entonces se sustituirá D por D'.
El protocolo de routing RIP como ya hemos dicho mantiene una tabla de routing, como cualquier protocolo
de routing, seguidamente pasamos a comentar cada uno de los campos de la tabla.

Dirección de destino

La dirección de destino en la tabla de routing de RIP será la red de destino, es decir, la red final a la que
deseamos acceder, esta red en la versión 1 del protocolo RIP tendrá que ser obligatoriamente clasfull, es decir
tendrá que tener en cuenta la clase, es decir, no se permite el subneting en RIP versión 1, por ejemplo si la
red de destino es la 192.168.4.0, sabemos que al ser RIP classful la red de destino tiene 256 direcciones, de

5
6
las cuales 254 son útiles, una vez descontada la dirección de red y la dirección de broadcast, ya que la red
192.168.4.0 es de clase C, es decir que los 24 primeros bits de la dirección IP identifican la red y los 8
últimos identifican los hosts de dentro de la red.

Siguiente salto

El siguiente salto lo definimos como el siguiente router por el que nuestro paquete va a pasar para llegar a su
destino, este siguiente salto será necesariamente un router vecino del router origen.

Interfaz de salida del router

Entendemos por interfaz de salida del router al interfaz al cual está conectado su siguiente salto.

Métrica

La métrica utilizada por RIP como ya hemos comentado consiste en el conteo de saltos, como métrica se
considera cada salto como una única unidad, independientemente de otros factores como tipo de interfaz o
congestión de la línea. La métrica total consiste en el total de saltos desde el router origen hasta el router
destino, con la limitación que 16 saltos se considera destino inaccesible, esto limita el tamaño máximo de la
red.

Temporizador

El temporizador nos indica el tiempo transcurrido desde que se ha recibido la última actualización de esa
ruta. RIP utiliza dos tiempos importantes, el tiempo de actualización que se estable en 30 segundos, el tiempo
de desactivación que se establece en 180 segundos y el tiempo de borrado se establece en 300 segundos.

El tiempo de actualización se considera al tiempo máximo a transcurrir entre el envío de los mensajes de
actualización de los vecinos.

El tiempo de desactivación se considera al tiempo máximo que puede esperar un router sin recibir
actualizaciones de vecino, una vez pasado este tiempo, el vecino que no ha enviado la actualización se
considera que ha caído y con lo cual el router no está activo en la red, se establece la métrica a valor 16, es
decir destino inalcanzable.

El tiempo de borrado implica que una vez transcurrido ese tiempo todas las rutas de ese router supuestamente
caído son eliminadas de la tabla de routing.

RFC 2453: RIP Versión 2


Diez años después de que se publicara la versión 1 de RIP se publicó la versión 2, por G.Malkin de la
compañía Bay Networks en Noviembre de 1998 en el RFC 2453.

RIPv2 establece una serie de mejoras muy importantes con su antecesor que son las siguientes:

• Autenticación para la transmisión de información de RIP entre vecinos.


• Utilización de mascaras de red, con lo que ya es posible utilizar VLSM7.

• Utilización de máscaras de red en la elección del siguiente salto, lo cual nos puede permitir la
utilización de arquitecturas de red discontinuas.

• Envío de actualizaciones de tablas de RIP mediante la dirección de multicast 224.0.0.9.

• Inclusión de RIPv2 en los bloques de información de gestión (MIB8).

Por supuesto además de estas mejoras RIPv2 nos permite la redistribución de rutas externas aprendidas por
otros protocolos de routing.

Pero RIPv2 aunque haya tenido una serie de mejoras muy importantes desde la versión 1 del protocolo sigue
teniendo una serie de carencias muy importantes como:

• Limitación en el tamaño máximo de la red. Con RIPv2 sigue existiendo la limitación de 15 saltos
como tamaño máximo de la red, lo cual implica que no nos permite la utilización de RIPv2 en redes
de un tamaño más grande.

• Conteo a infinito, RIPv2 sigue sin solucionar el problema del conteo hasta el infinito si se forman
bucles, aunque existen técnicas externas al protocolo como pueden ser la inversa envenenada y el
horizonte dividido, técnicas brevemente descritas por William Stallings en su libro “Comunicaciones
y Redes de Computadoras”, las cuales consisten básicamente en no anunciar una ruta por el interfaz
por el que se ha recibido en algún momento.

• Métricas estáticas que pueden ser cambiadas por el administrador de la red, pero que no nos dan
ninguna información del estado de la red.

• RIPv2 sólo permite al igual que su antecesor una ruta por cada destino, lo cual implica la
imposibilidad de realizar balanceos de carga por ejemplo, lo que redunda en una pobre y poco óptima
utilización de los enlaces.

• RIPv2 es un protocolo que al igual que su antecesor genera muchísimo tráfico al enviar toda la tabla
de routing en cada actualización, con la carga de tráfico que ello conlleva.

Prueba de RIP en campo

Presentación del experimento

En el experimento se intenta demostrar que el software de encaminamiento Open Source Quagga, tiene un
correcto funcionamiento bajo el protocolo de encaminamiento RIPv2, el experimento se realizará con dos
routers software Quagga.

Elementos utilizados para el experimento

Interfaces de red de la Máquina 1

[root@zebra1 edu]# ifconfig -a

7
8
eth0 Link encap:Ethernet HWaddr 00:60:67:90:31:E7
inet addr:213.37.36.209 Bcast:255.255.255.255 Mask:255.255.254.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41026 errors:0 dropped:0 overruns:0 frame:0
TX packets:41965 errors:0 dropped:0 overruns:0 carrier:0
collisions:3641 txqueuelen:100
RX bytes:4724782 (4.5 Mb) TX bytes:31246398 (29.7 Mb)
Interrupt:10 Base address:0xa000

lo Link encap:Local Loopback


inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:28079 errors:0 dropped:0 overruns:0 frame:0
TX packets:28079 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20363572 (19.4 Mb) TX bytes:20363572 (19.4 Mb)

vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08


inet addr:172.16.68.1 Bcast:172.16.68.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:243 errors:0 dropped:0 overruns:0 frame:0
TX packets:239 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

[root@zebra1 edu]#

Interfaces de red de la Máquina 2

[root@zebra2 root]# ifconfig -a


eth0 Link encap:Ethernet HWaddr 00:50:56:DB:A3:45
inet addr:172.16.68.128 Bcast:172.16.68.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:293 errors:0 dropped:0 overruns:0 frame:0
TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:37835 (36.9 Kb) TX bytes:33005 (32.2 Kb)
Interrupt:10 Base address:0x10a0

lo Link encap:Local Loopback


inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2004 errors:0 dropped:0 overruns:0 frame:0
TX packets:2004 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:136298 (133.1 Kb) TX bytes:136298 (133.1 Kb)

[root@zebra2 root]#

Configuración de los routers

Para poder llevar a cabo este experimento ha sido necesario configurar los demonios zebra y ripd de ambas
máquinas, a continuación las configuraciones

Configuración de zebra de la máquina 1

En esta configuración podemos ver que se ha seleccionado una password para entrar en el router y otra para
poder utilizar el modo privilegiado o de enable, se han encriptado las passwords, además se han configurado
direcciones IP a los interfaces eth0 y vmnet8.
zebra1# show running-config

Current configuration:
!
hostname zebra1
password 8 v6WxX0VZyYiW.
enable password 8 iG4uXkpGSZFKU
service password-encryption
!
debug zebra events
debug zebra packet
debug zebra kernel
!
interface lo
!
interface eth0
description WAN Zebra1
ip address 192.168.1.1/24
!
interface vmnet8
description LAN Zebra1
ip address 172.16.68.1/24
!
!
line vty
!
end
zebra1#

Configuración de ripd de la máquina 1

En esta configuración podemos ver que se ha seleccionado una password para entrar en el router y otra para
poder utilizar el modo privilegiado o de enable, se han encriptado las passwords, además se ha configurado el
anuncio de rutas por RIP. Estas pueden ser enviadas y recividas por el interfaz vmnet8 utilizando la versión
2, y no pueden ser enviadas por el interfaz eth0.
En esta configuración también se puede ver que se permite anunciar las redes 172.16.68.0/24, la
192.168.1.0/24 y todas aquellas redes que tenga el interfaz eth0.
También en esta configuración se puede ver que está habilitada la depuración de eventos de RIP.
ripd1# show running-config

Current configuration:
!
hostname ripd1
password 8 x/WKP6mKYV9dw
enable password 8 34xbIGWZ6kTDQ
log stdout
service password-encryption
!
debug rip events
!
interface eth0
!
interface lo
!
interface vmnet8
ip rip send version 2
ip rip receive version 2
!
router rip
network 172.16.68.0/24
network 192.168.1.0/24
network eth0
!
line vty
!
end
ripd1#
Configuración de zebra de la máquina 2

En esta configuración podemos ver que se ha seleccionado una password para entrar en el router y otra para
poder utilizar el modo privilegiado o de enable, se han encriptado las passwords, además se han configurado
una dirección IP al interfaz eth0.
zebra2# show running-config

Current configuration:
!
hostname zebra2
password 8 pBf8GXfp0JDI6
enable password 8 2sTF91RNdiatM
service password-encryption
!
interface lo
!
interface eth0
description WAN Zebra2
ip address 172.168.68.128/24
!
!
line vty
!
end
zebra2#

Configuración de ripd de la máquina 2

En esta configuración podemos ver que se ha seleccionado una password para entrar en el router y otra para
poder utilizar el modo privilegiado o de enable, se han encriptado las passwords, además se ha configurado el
anuncio de rutas por RIP. Estas pueden ser enviadas y recividas por el interfaz eth0 utilizando la versión 2.
En esta configuración también se puede ver que se permite anunciar las redes 172.16.68.0/24 y todas aquellas
redes que tenga el interfaz eth0.
En esta configuración al contrario que en la de ripd1 no está habilitada la depuración de RIP.
ripd2# show running-config

Current configuration:
!
hostname ripd2
password 8 SUSI.dra7aR7M
enable password 8 1e6zjc0ZHQwCA
log stdout
service password-encryption
!
interface lo
!
interface eth0
ip rip send version 2
ip rip receive version 2
!
router rip
network 172.16.68.0/24
network eth0
!
line vty
!
end
ripd2#

Pruebas realizadas

Comprobación de respuesta de un router ante un request de otro

Para realizar esta prueba se han utilizado además de los routers Zebra el software Etherpeak para poder
observar tanto los tiempos de reacción como las tramas enviadas.
La prueba se realizó arrancando los dos routers, pero teniendo el interfaz del router zebra2 eth0 en shutdown
(interfaz caído). La prueba consistía en levantar el interfaz y ver si el rip funcionaba bien y se actualizaba la
tabla de encaminamiento de rip del segundo router correctamente.
El resultado ha sido satisfactorio tal y como se puede ver en la traza realizada con el Ethereal (ver Tramas
Detalladas).

Esquema de la maqueta para el experimento

Como se puede ver en el esquema se ha utilizado una única máquina física en la que se estaba ejecutando un
router zebra, el Ethereal y un VMWare en el que a su vez se estaba ejecutando otro router zebra.
Tablas de routing de los routers Zebra

Tabla de Zebra1

zebra1# show ip route


Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 213.37.36.1, eth0


K * 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.68.0/24 is directly connected, vmnet8
C>* 192.168.1.0/24 is directly connected, eth0
C>* 213.37.36.0/23 is directly connected, eth0
zebra1#

Esta es la tabla de encaminamiento del router Zebra1, en ella se pueden ver además de las IPs configuradas
las direcciones conectadas al interfaz y aprendidas por el Kernel del Linux.

Tablas de Zebra2

En el caso del router Zebra2 se muestran dos tablas de routing, antes de levantar el interfaz eth0 y después de
levantar el interfaz eth0, descubrir la dirección del interfaz y aprender por RIP las rutas remotas.
Al mirar la tabla de rutas antes de levantar el interfaz obtenemos la siguiente información, vemos que no ha
aprendido nada por RIP y que no tiene ninguna ruta conectada al interfaz eth0.
zebra2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 172.16.68.2, eth0 inactive


K * 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.0/8 is directly connected, lo
zebra2#
Al levantar el interfaz eth0 podemos ver que ha aprendido las rutas por RIP y que además es capaz de ver las
rutas conectadas directamente al interfaz eth0.
zebra2# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
B - BGP, > - selected route, * - FIB route

K>* 0.0.0.0/0 via 172.16.68.2, eth0


K * 127.0.0.0/8 is directly connected, lo
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.68.0/24 is directly connected, eth0
R>* 192.168.1.0/24 [120/2] via 172.16.68.1, eth0, 00:04:08
R>* 213.37.36.0/23 [120/2] via 172.16.68.1, eth0, 00:04:08
zebra2#
Captura realizada con Ethereal

Pantallazo

Tramas Detalladas

TRAMA REQUEST ENVIADA POR ZEBRA2

Frame 2 (66 on wire, 66 captured)


Arrival Time: Mar 2, 2003 19:39:07.710433000
Time delta from previous packet: 0.958315000 seconds
Time relative to first packet: 0.958315000 seconds
Frame Number: 2
Packet Length: 66 bytes
Capture Length: 66 bytes
Ethernet II
Destination: 01:00:5e:00:00:09 (01:00:5e:00:00:09)
Source: 00:50:56:db:a3:45 (00:50:56:db:a3:45)
Type: IP (0x0800)
Internet Protocol, Src Addr: 172.16.68.128 (172.16.68.128), Dst Addr: 224.0.0.9 (224.0.0.9)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 52
Identification: 0x0000
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0xa91f (correct)
Source: 172.16.68.128 (172.16.68.128)
Destination: 224.0.0.9 (224.0.0.9)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Source port: 520 (520)
Destination port: 520 (520)
Length: 32
Checksum: 0x29f2 (correct)
Routing Information Protocol
Command: Request (1)
Version: RIPv2 (2)
Routing Domain: 0
Address not specified, Metric: 16
Address Family: Unspecified (0)
Route Tag: 0
Netmask: 0.0.0.0 (0.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16

TRAMA RESPOSE ENVIADA POR ZEBRA1

Frame 3 (86 on wire, 86 captured)


Arrival Time: Mar 2, 2003 19:39:07.710718000
Time delta from previous packet: 0.000285000 seconds
Time relative to first packet: 0.958600000 seconds
Frame Number: 3
Packet Length: 86 bytes
Capture Length: 86 bytes
Ethernet II
Destination: 00:50:56:db:a3:45 (00:50:56:db:a3:45)
Source: 00:50:56:c0:00:08 (00:50:56:c0:00:08)
Type: IP (0x0800)
Internet Protocol, Src Addr: 172.16.68.1 (172.16.68.1), Dst Addr: 172.16.68.128 (172.16.68.128)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 72
Identification: 0x0000
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x5a03 (correct)
Source: 172.16.68.1 (172.16.68.1)
Destination: 172.16.68.128 (172.16.68.128)
User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520)
Source port: 520 (520)
Destination port: 520 (520)
Length: 52
Checksum: 0x60fb (correct)
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 192.168.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 192.168.1.0 (192.168.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 213.37.36.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 213.37.36.0 (213.37.36.0)
Netmask: 255.255.254.0 (255.255.254.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1

Estos estudios sobre algoritmos de vector distancia fueron publicados por la Princeton University Press.
Routed pronunciado “route-dee”
De hecho el campo de direccionamiento se podía utilizar por XNS y por IP.
RFC: Request For Comments – Petición de Comentarios.
IGP: Interior Gateway Protocol – Protocolo de Pasarela Interior – Protocolo utilizado para intercambiar información de routing en
un sistema autónomo. (Definición obtenida de “Dictionary of Internetworking Terms and Acronyms” ed. Cisco Press, Enero
2001.)
Classful – Llamamos classful a un protocolo que funciona con clase, es decir que utiliza las direcciones IP considerando que la
máscara es la que se define en la clase correspondiente a la que pertenezca, ya sea A, B o C.
VLSM – Del inglés Variable Lengh Subnet Masking.
MIB – Del inglés Management Information Blocks.