Module 4: Routing Information Protocol Version 2
Routing Information Protocol version 2 (RIP v2) is defined in RFC 1723 and is supported in IOS versions 11.1 and later. RIP v2 is similar to RIP v1, but is not a new protocol. RIP v2 features extensions to bring it up-to-date with modern routing environments. The RIP v2 extensions are listed in the following:
* Subnet Masks carried with each route entry
* Authentication for routing updates
* Next Hop addressing carried with each route entry
* Route Tags for external use
* Queries in response to RIP v1 requests
The most important extension listed is the Subnet Mask field for routing-update entries. The Subnet Mask field enables the use of variable-length subnet masks (VLSMs) and qualifies RIP v2 as a classless routing protocol.
RIP v2 is the first of the classless routing protocols discussed in this module. This module serves as an introduction to classless routing and RIP v2.
4.1 RIP v2 Overview
4.1.1 RIP v2 operation
All of the operational procedures, timers, and stability functions of RIP v1 remain the same in RIP v2, with the exception of the broadcast updates. RIP v2 updates to other RIP v2 inter-routers by multicasting. This occurs by using the reserved Class D address 18.104.22.168. The advantage of multicasting is that devices on the local network that are not concerned with RIP routing do not have to spend time unwrapping broadcast packets from the router. The multicast updates are examined further in the section, Compatibility with RIP v1.
After a look at how the RIP message format accommodates the version 2 extensions, this section focuses on the operation and benefits of these additional features.
4.1.2 Issues addressed by RIP v2
The following four features are the most significant new features added to RIP v2:
* Authentication of the transmitting RIP v2 node to other RIP v2 nodes – RIP v2 added support for the authentication of the node that is transmitting response messages. Response messages are used to propagate routing information throughout a network. Authenticating the originator of a response message was intended to prevent routing tables from being corrupted with illegitimate routes from a fraudulent source.
* Subnet Masks – RIP v2 allocates a 4-octet field to associate a subnet mask to a destination IP address. When used in tandem, the IP address and its subnet mask enable RIP v2 to specifically identify the type of destination to which the route leads. This allows RIP v2 to route to specific subnets, regardless of whether the subnet mask is fixed or of variable length.
* Next Hop IP addresses – The inclusion of a Next Hop identification field helps make RIP v2 more efficient than RIP v1 by preventing unnecessary hops. This feature is particularly effective for network environments using multiple routing protocols simultaneously. Some routes go undiscovered when there are multiple or dissimilar routing protocols.
* Multicasting RIP v2 messages – Multicasting is a technique for simultaneously advertising routing information to multiple RIP or RIP v2 devices. Multicasting is beneficial whenever multiple destinations must receive the identical information. The conventional solution to this problem would be to generate separate packets containing identical payloads specifically addressed to each machine. Multicasting enables packets to be simultaneously delivered to multiple machines. This reduces overall network traffic and reduces the processing load of the source machine.
4.1.3 RIP v2 message format
RIP v2 uses a special message format, or packet, to collect and share information about distances to known internetworked destinations. The RIP v2 message format is shown in Figure . The basic structure is the same as for RIP v1. All the extensions to the original protocol are carried in the unused fields. RIP v2 updates can contain entries for up to 25 routes as in RIP v1. Like RIP v1, RIP v2 operates from UDP port 520, has an 8-byte header, and a maximum datagram size of 512 bytes.
The Command field remains unchanged from RIP v1. It indicates whether the RIP v2 route was generated as a request, or a response to a request.
The Version field will be set to two for RIP v2. If it is set to zero or one and the message is not a valid RIP v1 format, the message will be discarded. RIP v2 will process valid RIP v1 messages.
The Address Family Identifier (AFI) field is set to two for IP. The only exception is a request for a full routing table of a router or host, in which case it will be set to zero.
The Route Tag field provides a way to differentiate between internal and external routes. An internal route is one that was learned by the RIP v2 protocols within the network or autonomous system. External routes are those that were learned from other routing protocols that have been redistributed into the RIP v2 process. One suggested use of this 16-bit field is to carry the autonomous system number of routes that have been imported from an external routing protocol.
The IP Address field contains the destination address. It may be a major network address, a subnet, or a host route.
The Subnet Mask field contains a 32-bit mask that identifies the network and subnet portion of the IP address. The addition of this field is the single most important change made to the RIP v2 message structure.
The Next Hop field contains the IP address of the next hop listed in the IP Address field.
Metric indicates how many internetwork hops or routers have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.
4.1.4 Compatibility with RIP v1
RIP v2 handles updates in a flexible manner. If the Version Number field indicates version 1 and if any bits in the Unused field are set to one, the update is discarded. If the RIP version is greater than one, then the fields defined as unused are ignored and the message is processed. Therefore, newer versions of the RIP protocol are backward compatible with previous RIP versions.
RFC 1723 defines a compatibility switch with four settings, which allows versions 1 and 2 to interoperate:
1. RIP v1, in which only RIP v1 messages are transmitted
2. RIP v1 Compatibility, which causes RIP v2 to broadcast its messages instead of multicast them so that RIP v1 may receive them
3. RIP v2, in which RIP v2 messages are multicast to destination address 22.214.171.124
4. None, in which no updates are sent
RFC 1723 recommends that switches be configurable on a per-interface basis. The Cisco commands for settings 1 through 3 are presented in the section Configuring RIP v2. The Cisco command for setting 4 is accomplished by using the passive-interface command.
Additionally, RFC 1723 defines a receive control switch to regulate the reception of updates. The four recommended settings of this switch are listed in the following:
1. RIP v1 only
2. RIP v2 only
This switch should also be configurable on a per interface basis. The Cisco commands for settings 1 through 3 are also presented in the configuration section of this module. Setting 4 can be accomplished by using an access list to filter UDP source port 520, by not including a network statement for the interface, or by configuring a route filter.
4.1.5 Classless route lookups
Module 2, Advanced IP Addressing Management, explains classful route lookups, in which a destination address is first matched to its major network address in the routing table and is then matched to a subnet of the major network. If no match is found at either of these steps, the packet is dropped.
This default behavior can be changed, even for classful routing protocols such as RIP v1 and Interior Gateway Routing Protocol (IGRP). Change the default behavior by entering the ip classless global command. When a router performs classless route lookups, it does not pay attention to the class of the destination address. Instead, it performs a bit-by-bit best match between the destination address and all its known routes. This capability can be very useful when working with default routes, as demonstrated in Module 3, Routing Overview. Classless route lookups can be very powerful when coupled with the other features of classless routing protocols.
A security concern with any routing protocol is the possibility of a router accepting invalid routing updates. The source of invalid updates may be an attacker trying to maliciously disrupt the internetwork. The attacker may be trying to capture packets by tricking the router into sending them to the wrong destination. A more mundane source of invalid updates may be a malfunctioning router. RIP v2 includes the capability to authenticate the source of a routing update by including a password.
Authentication is supported by modifying what would normally be the first route entry of the RIP message, as shown in Figure . Note that with authentication the maximum number of entries a single update can carry is reduced to 24. The presence of authentication is indicated by setting the Address Family Identifier field to all ones, 0xFFFF. The Authentication Type for simple password authentication is two, 0x0002, and the remaining 16 octets carry an alphanumeric password of up to 16 characters. The password is left justified in the field, and if the password is less than 16 octets, the unused bits of the field are set to zero.
Figure shows an analyzer capture of a RIP v2 message with authentication. The output reveals a security concern with default RIP v2 authentication. The password is transmitted in plain text. Anyone who can capture a packet containing a RIP v2 update message can read the authentication password.
Although RFC 1723 describes only simple password authentication, foresight is shown by including the Authentication Type field. Cisco IOS takes advantage of this feature and provides the option of using MD5 authentication instead of simple password authentication. Cisco uses the first and last route entry spaces for MD5 authentication purposes.
MD5 is a one-way message digest or secure hash function, produced by RSA Data Security, Incorporated. It is also referred to as a cryptographic checksum because it works in somewhat the same way as an arithmetic checksum. MD5 computes a 128-bit hash value from a plain text message of arbitrary length and a password. An example would be a RIP v2 update. This fingerprint is transmitted along with the message. The receiver, knowing the same password, calculates its own hash value. If nothing in the message has changed, the receiver hash value should match the sender value transmitted with the message.
4.1.8 Limitations of RIP v2
Despite its overhaul, RIP v2 could not compensate for all its predecessors limitations. In fairness to the creators of RIP v2, they did not seek to make RIP v2 anything but a modernized RIP. This included maintaining its original purpose as an Interior Gateway Protocol (IGP) for use in small networks or autonomous systems. Therefore, all the original functional limitations designed into RIP also apply to RIP v2. A critical difference is that RIP v2 can be used in networks that require either support for authentication and variable-length subnet masks.
Some of the more significant limitations that were inherited by RIP v2 include the following:
* Lack of alternative routes – RIP v2 continues to maintain a single route to any given destination in its routing tables. In the event a route becomes invalid, the RIP v2 node does not know any other routes to the destination of the failed route. Consequently, it must wait for a routing update before it can begin to assess potential alternative routes to that destination. This approach to routing minimizes the size of routing tables but can result in the temporary unreachability of destinations during a link or router failure.
* Counting to infinity – RIP v2 continues to rely on counting to infinity as a means of resolving certain error conditions within the network. One such error condition would be a routing loop. RIP v2 remains dependent on timers to generate updates. Therefore, it is also relatively slow to converge on a consensus of the network topology following any change to that topology. The more time that it takes to converge, the greater the opportunity for obsolete information to be mistakenly propagated as current information. The result could be a routing loop.
* 15-hop maximum – Perhaps the single greatest limitation that RIP v2 inherited from RIP is that its interpretation of infinity remained at 16. After a route cost is incremented to 16, that route becomes invalid, and the destination is considered unreachable. This limits the use of RIP v2 to networks with a maximum diameter of 15 or fewer hops.
* Static distance vector metrics – Another inherited limitation is found in the RIP v2 static cost metrics. The default value of 1 is just like RIP. However, the default value can be manually adjusted by the network administrator. This metric remains constant, and can only be changed by the administrator. Therefore, RIP v2 remains unsuited for network environments that require routes to be selected in real-time based on either delay, traffic loads, or any other dynamic network performance metric.
4.2.1 Basic RIP v2 configuration
RIP v2 is merely an enhancement of RIP v1 and not a separate protocol. The commands for manipulating timers, metrics, and, updates are exactly the same in both versions. After a brief look at configuring a RIP v2 process, the rest of this section concentrates on configuring the new extensions.
When RIP is first enabled on a Cisco router, the router listens for version 1 and 2 updates but sends only version 1. To take advantage of version 2 features, it is necessary to turn off version 1 support and enable version 2 updates with the following command:
1. Enable RIP v2 on the router using the following commands:
By default, a RIP process configured on a Cisco router sends only RIP v1 messages but listens to both RIP v1 and RIP v2. This default is changed with the version command. In this mode, the router sends and receives only RIP v2 messages.
2. The router can also be configured to send and receive only RIP v1 messages:
The default behavior can be restored by entering the command no version in the config-router mode.
4.2.2 Compatibility with RIP v1
The interface-level "compatibility switches" recommended by RFC 1723 are implemented in Cisco IOS with the commands ip rip send version and ip rip receive version.
NewYork(config-if)#ip address 192.168.50.129 255.255.255.192
NewYork(config-if)#ip rip send version 1
NewYork(config-if)#ip rip receive version 1
NewYork(config-if)#ip address 172.25.150.193 255.255.255.240
NewYork(config-if)#ip rip send version 1 2
NewYork(config-if)#ip address 172.25.150.225 126.96.36.199
Interface FastEthernet0/0 is configured to send and receive RIP v1 updates while FastEthernet0/1 is configured to send both version 1 and 2 updates. FastEthernet0/2 has no special configuration and therefore sends and receives version 2 by default.
4.2.3 Discontiguous subnets and classless routing
Route summarization reduces the amount of routing information in the routing tables. RIP v1 always uses automatic summarization. The default behavior of RIP v2 is to summarize at network boundaries the same as RIP v1. Use the no auto-summary command with the RIP process to turn off summarization and allow subnets to be advertised across network boundaries. This allows RIP v2 to perform routing between discontiguous subnets by advertising subnet information.
4.2.4 Configuring authentication
The implementation of RIP v2 message authentication by Cisco includes the choice of a simple password or MD5 authentication, and the option of defining multiple keys, or passwords on a key chain. The router may then be configured to use different keys at different times. Plain text authentication is the default setting in every RIP v2 packet.
The steps for setting up RIP v2 authentication are as follows:
1. Define a key chain with a name.
2. Define the key or keys on the key chain.
3. Enable authentication on an interface and specify the key chain to be used.
4. Specify whether the interface will use clear text or MD5 authentication.
5. Optionally configure key management.
In the following example, a key chain named Romeo is configured. Key 1, the only key on the chain, has a password of Juliet. FastEthernet0/0 then uses the key, with MD5 authentication to validate updates from neighboring RIP v2 routers.
Router(config)#key chain Romeo
Router(config-keychain-key)#interface fastethernet 0/0
Router(config-if)#ip rip authentication key-chain Romeo
Router(config-if)#ip rip authentication mode md5
If the command ip rip authentication mode md5 is not added, the interface will use the default clear text authentication. Although clear text authentication may be necessary to communicate with some RIP v2 implementations, for security concerns use the more secure MD5 authentication whenever possible.
A key chain must be configured, even if there is only one key on it. Although any routers that will exchange authenticated updates must have the same password, the name of the key chain has significance only on the local router.
4.3.2 Debug commands
Two configuration problems common to RIP v2 are mismatched versions and misconfigured authentication. Both difficulties are easy to discover with the following debugging commands.
Use the debug ip rip EXEC command to display information on RIP routing transactions. The no form of this command disables debugging output.
Router#debug ip rip [events]
Use the debug ip routing EXEC command to display information on RIP routing table updates and route-cache updates. The no form of this command disables debugging output.
Router#debug ip routing
4.4.1 Routing between RIP v1 and RIP v2
4.4.2 RIP v2 MD5 authentication
RIP is still used despite the emergence of more sophisticated routing protocols. RIP is mature, stable, widely supported, and easy to configure. Although RIP v2 presents some decided improvements over RIP v1, it is still limited to a maximum of 15 hops to small internetworks. Design strategies such as VLSM have become very powerful tools for controlling protocols. The following modules examine three protocols and their design strategies that can be used in large internetworks:
* Module 5, EIGRP
* Module 6, OSPF
* Module 7, IS-IS
- prepara tu examen ccna.
- prepara tu examen ccnp.
- prepara tu certificacion ccnp.
- prepara tu certificacion ccna.
- prepara tu examenes ccna.
- prepara tu examenes ccnp.
- prepara tu certificaciones ccnp.
- prepara tu certificacion ccna.