While RIPv1 allows only contiguous blocks of hosts, subnets, or networks to be represented by a single route, RIPv2 allows
Classless Inter-Domain Routing (CIDR). In addition, RIPv2 supports the following:
-
Route summarization
-
Variable-length subnet masks (VLSMs)
-
Autonomous systems and the use of redistribution
-
Multicast address 224.0.0.9 for RIP advertisements
The metric that RIP uses to rate the value of different routes is hop count. The hop count is the number of routers that can
be traversed in a route. A directly connected network has a metric of zero; an unreachable network has a metric of 16. This
small range of metrics makes RIP an unsuitable routing protocol for large networks.
Routing information updates are advertised every 30 seconds by default, and new updates discovered from neighbor routers are
stored in a routing table.
Only RIP Version 2 (RIP v2), as specified in RFC 2453, is supported on Cisco IOS XR software and, by default, the software
only sends and receives RIP v2 packets. However, you can configure the software to send, or receive, or both, only Version
1 packets or only Version 2 packets or both version type packets per interface.
Here are some good reasons to use RIP:
-
Compatible with diverse network devices
-
Best for small networks, because there is very little overhead, in terms of bandwidth used, configuration, and management
time
-
Support for legacy host systems
Because of RIP’s ease of use, it is implemented in networks worldwide.
Note
|
VRF does not allow configuration of a group applied directly under router RIP. A group can be configured if it is applied
globally or under VRF.
|
Split Horizon for RIP
Normally, routers that are connected to broadcast-type IP networks and that use distance-vector routing protocols employ the
split horizon mechanism to reduce the possibility of routing loops. Split horizon blocks information about routes from being
advertised by a router out of any interface from which that information originated. This behavior usually optimizes communications
among multiple routers, particularly when links are broken.
If an interface is configured with secondary IP addresses and split horizon is enabled, updates might not be sourced by every
secondary address. One routing update is sourced per network number unless split horizon is disabled.
Note
|
The split horizon feature is enabled by default. In general, we recommend that you do not change the default state of split
horizon unless you are certain that your operation requires the change in order to properly advertise routes.
|
Route Timers for RIP
RIP uses several timers that determine such variables as the frequency of routing updates, the length of time before a route
becomes invalid, and other parameters. You can adjust these timers to tune routing protocol performance to better suit your
internetwork needs, by making the following timer adjustments to:
-
The rate (time in seconds between updates) at which routing updates are sent
-
The interval of time (in seconds) after which a route is declared invalid
-
The interval (in seconds) during which routing information regarding better paths is suppressed
-
The amount of time (in seconds) that must pass before a route is removed from the RIP topology table
-
The amount of time delay between RIP update packets
The first four timer adjustments are configurable by the timers basic command. The output-delay command changes the amount of time delay between RIP update packets. See Customizing RIP section for configuration details.
It also is possible to tune the IP routing support in the software to enable faster convergence of the various IP routing
algorithms and quickly drop back to redundant routers, if necessary. The total result is to minimize disruptions to end users
of the network in situations in which quick recovery is essential.
Route Redistribution for RIP
Redistribution is a feature that allows different routing domains, to exchange routing information. Networking devices that
route between different routing domains are called boundary routers, and it is these devices that inject the routes from one
routing protocol into another. Routers within a routing domain only have knowledge of routes internal to the domain unless
route redistribution is implemented on the boundary routers.
When running RIP in your routing domain, you might find it necessary to use multiple routing protocols within your internetwork
and redistribute routes between them. Some common reasons are:
-
To advertise routes from other protocols into RIP, such as static, connected, OSPF, and BGP.
-
To migrate from RIP to a new Interior Gateway Protocol (IGP) such as EIGRP.
-
To retain routing protocol on some routers to support host systems, but upgrade routers for other department groups.
-
To communicate among a mixed-router vendor environment. Basically, you might use a protocol specific to Cisco in one portion
of your network and use RIP to communicate with devices other than Cisco devices.
Further, route redistribution gives a company the ability to run different routing protocols in work groups or areas in which
each is particularly effective. By not restricting customers to using only a single routing protocol, Cisco IOS XR route redistribution
is a powerful feature that minimizes cost, while maximizing technical advantage through diversity.
When it comes to implementing route redistribution in your internetwork, it can be very simple or very complex. An example
of a simple one-way redistribution is to log into a router on which RIP is enabled and use the redistribute static command to advertise only the static connections to the backbone network to pass through the RIP network. For complex cases
in which you must consider routing loops, incompatible routing information, and inconsistent convergence time, you must determine
why these problems occur by examining how Cisco routers select the best path when more than one routing protocol is running
administrative cost.
Default Administrative Distances for RIP
Administrative distance is used as a measure of the trustworthiness of the source of the IP routing information. When a dynamic
routing protocol such as RIP is configured, and you want to use the redistribution feature to exchange routing information,
it is important to know the default administrative distances for other route sources so that you can set the appropriate distance
weight.
This table lists the Default Administrative Distances of Routing Protocols.
Table 2. Default Administrative Distances of Routing Protocols
Routing Protocols
|
Administrative Distance Value
|
Connected interface
|
0
|
Static route out an interface
|
0
|
Static route to next hop
|
1
|
EIGRP Summary Route
|
5
|
External BGP
|
20
|
Internal EIGRP
|
90
|
OSPF
|
110
|
IS-IS
|
115
|
RIP version 1 and 2
|
120
|
External EIGRP
|
170
|
Internal BGP
|
200
|
Unknown
|
255
|
An administrative distance is an integer from 0 to 255. In general, the higher the value, the lower the trust rating. An administrative
distance of 255 means the routing information source cannot be trusted at all and should be ignored. Administrative distance
values are subjective; there is no quantitative method for choosing them.
Default-Information Originate
The Default-Information Originate configuration allows the default route (0.0.0.0/0) to be advertised to peers in RIP. The
receiving router accepts the default route, and then installs the route in the RIP database and the RIB table.
Starting from IOS XR Release 7.5.2, when a router is configured with the default-information originate command, the router ignores any received default routes from RIP peers. So, even if a default route is advertised to the
router by a peer, the default route is not accepted or installed into the router's RIP database and the RIB table.
Example:
The following is a sample configuration:
router rip
interface GigabitEthernet0/2/0/0
!
default-information originate
!
Routing Policy Options for RIP
Route policies comprise series of statements and expressions that are bracketed with the route-policy and end-policy keywords. Rather than a collection of individual commands (one for each line), the statements within a route policy have
context relative to each other. Thus, instead of each line being an individual command, each policy or set is an independent
configuration object that can be used, entered, and manipulated as a unit.
Each line of a policy configuration is a logical subunit. At least one new line must follow the then , else , and end-policy keywords. A new line must also follow the closing parenthesis of a parameter list and the name string in a reference to an
AS path set, community set, extended community set, or prefix set. At least one new line must precede the definition of a
route policy, AS path set, community set, extended community set, or prefix set. One or more new lines can follow an action
statement. One or more new lines can follow a comma separator in a named AS path set, community set, extended community set,
or prefix set. A new line must appear at the end of a logical unit of policy expression and may not appear anywhere else.
Authentication Using Keychain in RIP
Authentication using keychain in Cisco IOS XR Routing Information Protocol (RIP) provides mechanism to authenticate all RIP
protocol traffic on RIP interface, based keychain authentication. This mechanism uses the Cisco IOS XR security keychain infrastructure
to store and retrieve secret keys and use it to authenticate in-bound and out-going traffic on per-interface basis.
Keychain management is a common method of authentication to configure shared secrets on all entities that exchange secrets
such as keys, before establishing trust with each other. Routing protocols and network management applications on Cisco IOS
XR software often use authentication to enhance security while communicating with peers.
Note
|
The Cisco IOS XR software system security component implements various system security features including keychain management.
For detailed information on keychain management concepts, configuration tasks, examples, and commands used to configure keychain
management, refer the Implementing Keychain Management module in the System Security Configuration Guide, and the Keychain
Management Commands module in the System Security Command Reference.
|
Note
|
The keychain by itself has no relevance; therefore, it must be used by an application that needs to communicate by using the
keys (for authentication) with its peers. The keychain provides a secure mechanism to handle the keys and rollover based on
the lifetime. The Cisco IOS XR keychain infrastructure takes care of the hit-less rollover of the secret keys in the keychain.
|
Once you have configured a keychain in the IOS XR keychain database and if the same has been configured on a particular RIP
interface, it will be used for authenticating all incoming and outgoing RIP traffic on that interface. Unless an authentication
keychain is configured on a RIP interface (on the default VRF or a non-default VRF), all RIP traffic will be assumed to be
authentic and authentication mechanisms for in-bound RIP traffic and out-bound RIP traffic will be not be employed to secure
it.
RIP employs two modes of authentication: keyed message digest mode and clear text mode. Use the authentication keychain
keychain-name
mode {md5|text} command to configure authentication using the keychain mechanism.
In cases where a keychain has been configured on RIP interface, but the keychain is actually not configured in the keychain
database or keychain is not configured with MD5 cryptographic algorithm, all incoming RIP packets on the interface will be
dropped. Outgoing packets will be sent without any authentication data.
In-bound RIP Traffic on an Interface
These are the verification criteria for all in-bound RIP packets on a RIP interface when the interface is configured with
a keychain.
If ..
|
Then ..
|
The keychain configured on the RIP interface does not exist in the keychain database...
|
The packet is dropped. A RIP component-level debug message is be logged to provide the specific details of the authentication
failure.
|
The keychain is not configured with a MD5 cryptographic algorithm...
|
The packet is dropped. A RIP component-level debug message is be logged to provide the specific details of the authentication
failure.
|
The Address Family Identifier of the first (and only the first) entry in the message is not 0xFFFF, then authentication is
not in use...
|
The packet will be dropped. A RIP component-level debug message is be logged to provide the specific details of the authentication
failure.
|
If ..
|
Then ..
|
The MD5 digest in the ‘Authentication Data’ is found to be invalid...
|
The packet is dropped. A RIP component-level debug message is be logged to provide the specific details of the authentication
failure.
|
Else, the packet is forwarded for the rest of the processing.
|
Out-bound RIP Traffic on an Interface
These are the verification criteria for all out-bound RIP packets on a RIP interface when the interface is configured with
a keychain.
If ..
|
Then ..
|
The MD5 digest in the ‘Authentication Data’ is found to be invalid...
|
The RIP packet passes authentication check at the remote/peer end, provided the remote router is also configured to authenticate
the packets using the same keychain.
|
The keychain is configured with a MD5 cryptographic algorithm...
|
The RIP packet passes authentication check at the remote/peer end, provided the remote router is also configured to authenticate
the packets using the same keychain.
|
Else, RIP packets fail authentication check.
|