Protocolo de Información de Enrutamiento (RIP)

Existen dos versiones de RIP. La versión 1 (RIP-1) es un protocolo destacado ampliamente con sus limitaciones. La versión 2 (RIP-2) es una versión mejorada diseñada para aliviar las limitaciones de RIP hasta que sea altamente compatible con él. El término RIP se usa para referirse a la versión 1, mientras que RIP-2 se refiere a la versión 2. Cuando el lector se encuentre el término RIP en la literatura de TCP/IP, debería asumir que se está refiriendo a la versión 1 a menos que explícitamente se diga lo contrario. Se usará esta nomenclatura en esta sección excepto cuando las dos versiones se estén comparando, donde se usará el término RIP-1 para evitar posibles confusiones.

Protocolo de Información de Enrutamiento
versión 1 (RIP, RIP-1)

RIP es un protocolo estándar (STD 34). Su estado es electivo. Se describe en el RFC 1058, aunque muchas implementaciones RIP preceden este RFC por un número de años. RIP se implementa generalmente con un demonio llamado routed. los demonios gated también soportan RIP.

RIP se basó en los protocolos de enrutamiento de Xerox PUP y XNS. Se usa ampliamente, así que el código está incorporado en el código de enrutamiento del UNIX BSD de Berkeley que proporciona los fundamentos para muchas implementaciones UNIX.

RIP es una implementación directa del enrutamiento distancia-vector para redes locales. La communicación RIP usa UDP como protocolo de transporte, con número de puerto 520 como puerto de destino (ver Protocolo de Datagrama de Usuario (UDP) para un descripción de UDP y puertos). RIP opera en uno de los dos modos siguientes: activo (normalmente lo usan los routers) y pasivo (normalmente lo usan los hosts). La diferencia entre los dos se explica más abajo. Los mensajes RIP se envían en datagramas UDP y cada uno contiene 25 parejas de números como se muestra en la siguiente figura.

Se pueden listar entre 1 y 25 rutas en un mensaje RIP. Con 25 rutas el mensaje es de 504 bytes (25x20+4) que es el tamaño máximo del mensaje que puede transmitirse en un datagrama UDP de 512 bytes.

Orden

es 1 para una petición RIP o 2 para una respuesta RIP.

Versión

es 1.

Familia de direcciones

es 2 para direcciones IP.

dirección IP

es la dirección IP para esta entrada de enrutamiento: un host o una subred (en cuyo caso el número de host es cero).

Métrica de salto

es la número de saltos al destino. El contador de saltos para una interfaz conectada directamente es 1, y cada router intermedio lo incrementa en 1 hasta un máximo de 15, un 16 indica que no existe ruta hacia el destino.

Ambos participantes RIP, activo y pasivo, escuchan todos los mensajes emitidos y actualizan sus tablas de enrutamiento según el algoritmo vector-distancia descrito anteriormente.

Operaciones Básicas

• Cuando RIP comienza envía un mensaje para cada uno de sus vecinos (sobre el puerto UDP bien-conocido 520) solicitando una copia de la tabla de enrutamiento del vecino. Este mensaje es una pregunta (orden se pone a 1) con una familia de direcciones de 0 y una métrica de 16. Los routers de los vecinos devuelven una copia de sus tablas de enrutamiento.
• Cuando RIP está en modo activo envía todo o parte de su tabla de enrutamiento a todos los routers de sus vecinos (mediante broadcasting y/o enviándolo sobre cualquier enlace punto-a-punto hacia sus vecinos). Esto se hace cada 30 segundos. La tabla de enrutamiento se envía como respuesta (orden es 2, incluso aunque no se solicite).
• Cuando RIP descubre que una métrica ha cambiado, emite el cambio a otros routers.
• Cuando RIP recibe una respuesta, el mensaje se valida y la tabla de enrutamiento local se actualiza si es necesario.

Para mejorar el rendimiento y la confiabilidad, RIP especifica que una vez que un router (o un host) aprende la ruta de otro router, debe mantener esa ruta hasta que aprenda la mejor (con un coste estrictamente bajo). Esto impide aquellas rutas oscilatorias entre dos o más caminos de igual coste.

• Cuando RIP recibe una petición, otro than one for the entire table, it is returned as the response with the metric for each entry set to the value from the local routing table. If no route exists in the local table, the metric is set to 16.
• RIP routes learned from other routers time out unless they are re-advertised within 180 seconds (6 broadcast cycles). When a route times out, its metric is set to infinity, the invalidation of the route is broadcast to the router's neighbors, and 60 seconds later, the route is deleted from the local routing table.

Limitaciones

RIP is not designed to solve every possible routing problem.RFC 1720 (STD 1) describes these technical limitations of RIP as ``serious'' and the IETF es evaluating candidates for a new standard ``open'' protocol to replace RIP. Possible candidates include OSPF (see Open Shortest Path First Protocol (OSPF) Version 2) and OSI IS-IS (see OSI Intermediate System to Intermediate System (IS-IS)). However, RIP is widely deployed and therefore is unlikely to be completely replaced for some time. RIP has the following specific limitations:

• The maximum cost allowed in RIP is 16 which means that the network is unreachable. Thus RIP is inadequate for large networks (that is, those in which legitimate hop counts approach 16).
• RIP does not support variable length subnet masks (variable subnetting). There is no facility in a RIP message to specify a subnet mask associated with the IP address.
• RIP has no facilities to ensure that routing table updates come from authorized routers. It is an unsecure protocol.
• RIP only uses fixed metrics to compare alternative routes. It is not appropriate for situations where routes need to be chosen based on real-time parameters such as measured delay, reliability, or load.
• The protocol depends upon counting to infinity to resolve certain unusual situations. As described earlier (Vector-Distance), the resolution of a loop would require either much time (if the frequency of updates was limited) or much bandwidth (if updates were sent whenever changes were detected). As the size of the routing domain grows, the instability of the vector-distance algorithm in the face of changing topology becomes apparent. RIP specifies mechanisms to minimize the problems with counting to infinity (these are described below) which allows RIP to be used for larger routing domains, but eventually RIP will be unable to cope. There is no fixed upper limit, but the practical maximum depends upon the frequency of changes to the topology, the details of the network topology itself, and what is deemed as an acceptable maximum time for the routing topology to stabilize.

Solving the counting to infinity problem is done by using the split horizon, poisoned reverse and triggered updates techniques.

Split horizon with poisoned reverse

Consideremos nuestra red de ejemplo mostrada en la figura:

As described in Vector-Distancia the problem was caused by the fact that A and C are engaged in a pattern of mutual deception. Each claims to be able to reach D via the other. This can be prevented by being more careful about where information is sent. In particular, it is never useful to claim reachability for a destination network to the neighbor from which the route was learned (reverse routes). The split horizon with poisoned reverse scheme includes routes in updates sent to the router from which they were learned, but sets their metrics to infinity. If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 will break the loop immediately. If the reverse routes are simply not advertised (this scheme is called simple split horizon), the erroneous routes will have to be eliminated by waiting for a timeout. Poisoned reverse does have a disadvantage: it increases the size of the routing messages.

Triggered updates

Split horizon with poisoned reverse will prevent any routing loop that involves only two gateways. However, it is still possible to end up with patterns in which three routers are engaged in mutual deception. For example, A may believe it has a route through B, B through C, and C through A. This cannot be solved using split horizon. This loop will only be resolved when the metric reaches infinity and the network or host involved is then declared unreachable. Triggered updates are an attempt to speed up this convergence. Whenever a router changes the metric for a route, it is required to send update messages almost immediately, even if it is not yet time for one of the regular update messages (RIP specifies a small time delay, between 1 and 5 seconds, in order to avoid having triggered updates generate excessive network traffic).

Protocolo de información de enrutamiento
versión 2 (RIP-2)

RIP-2 es un protocolo estándar borrador. Su estado es electivo y se describe en el RFC 1723.

RIP-2 extende RIP-1. Es menos potente que otros IGPs recientes tales como OSPF (ver Open Shortest Path First Protocol (OSPF) Version 2) and IS-IS (see OSI Intermediate System to Intermediate System (IS-IS)), but it has the advantages of easy implementation and lower overheads. The intention of RIP-2 is to provide a straightforward replacement for RIP which can be used on small to medium-sized networks, can be employed in the presence of variable subnetting (see Subnets) or supernetting (see Classless Inter-Domain Routing (CIDR)) and importantly, can interoperate with RIP-1.

RIP-2 takes advantage of the fact that half of the bytes in a RIP-1 message are reserved (must be zero) and that the original RIP-1 specification was well designed with enhancements in mind, particularly in the use of the version field. One notable area where this is not the case is in the interpretation of the metric field. RIP-1 specifies it as being a value between 0 and 16 stored in a four-byte field. For compatibility, RIP-2 preserves this definition, meaning that it agrees with RIP-1 that 16 is to be interpreted as infinity, and wastes most of this field.

Nota: Neither RIP-1 nor RIP-2 are properly suited for use as an IGP in an AS where a value of 16 is too low to be regarded as infinity, because high values of infinity exacerbate the counting to infinity problem. The more sophisticated Link-State protocol used in OSPF and IS-IS provides a much better routing solution when the AS is large enough to have a legitimate hop count close to 16.

Provided that a RIP-1 implementation obeys the specification in RFC 1058, RIP-2 can interoperate with RIP-1. El formato de mensaje RIP se extiende como se muestra en figura siguiente.

Los campos en un mensaje RIP-2 son los mismos que los de RIP-1 excepto los siguientes:

Versión

Is 2. This tells RIP-1 routers to ignore the fields designated as ``must be zero'' (if the value is 1, RIP-1 routers are required to discard messages with non-zero values in these fields since the messages originate with a router claiming to be RIP-1-compliant but sending non-RIP-1 messages).

Familia de direcciones

May be X'FFFF' in the first entry only, indicating that this entry is an authentication entry.

Tipo de autentificación

Defines how the remaining 16 bytes are to be used. The only defined types are 0 indicating no authentication and 2 indicating that the field contains password data.

Datos de autentificación

The password is 16 bytes, plain text ASCII, left adjusted and padded with ASCII NULLs (X'00').

Etiqueta de ruta

Is a field intended for communicating information about the origin of the route information. It is intended for interoperation between RIP and other routing protocols. RIP-2 implementations must preserve this tag, but RIP-2 does not further specify how it is to be used.

Máscara de subred

The subnet mask associated with the subnet referred to by this entry.

Salto siguiente

A recommendation about the next hop that the router should use to send datagrams to the subnet or host given in this entry.

Para asegurar interoperación con RIP, el RFC 1723 especifica las restricciones siguientes para los routers RIP-2 que envían sobre una interfaz de red donde un router RIP-1 puede oir y operar sobre los mensajes RIP.

1. La información interna para una red nunca se debe advertir en otra red.
2. Information about a more specific subnet may not be advertised where RIP-1 routers would consider it a host route.
3. Supernet routes (routes with a subnet mask shorter than the natural or ``unsubnetted'' network mask) must not be advertised where they could be misinterpreted by RIP-1 routers.

RIP-2 also supports the use of multicasting rather than simple broadcasting. This can reduce the load on hosts which are not listening for RIP-2 messages. This option is configurable for each interface to ensure optimum use of RIP-2 facilities when a router connects mixed RIP-1/RIP-2 subnets to RIP-2-only subnets. Similarly, the use of authentication in mixed environments can be configured to suit local requirements.

RIP-2 is implemented in recent versions of the gated daemon, often termed gated Version 3. Since the draft standard is new at the time of writing, many implementations will comply with the earlier version described in RFC 1388. Such implementations will interoperate with those adhering to RFC 1723.

Para más información sobre RIP-2, ver:

• RFC 1721 - RIP Versión 2 - Análisis del Protocolo
• RFC 1722 - RIP Version 2 - Declaración de aplicabilidad del Protocolo
• RFC 1723 - RIP Version 2 - Información Adicional de Acarreo
• RFC 1724 - RIP Version 2 - Extensión MIB

Enrutamiento IP básico  |  Tabla de Contenidos  |  Protocolos de aplicación