Routing Information Protocol (RIP)

Routing Information Protocol (RIP) Overview

One of the most widely used interior gateway protocols is the Routing Information Protocol (RIP). RIP is an implementation of a distance-vector, or Bellman-Ford, algorithm. RIP classifies routers as active and passive (silent). Active routers advertise their routes (reachability information) to others; passive routers listen and update their routes based on advertisements, but do not advertise. Typically, routers run RIP in active mode, while hosts use passive mode.

A router running RIP in active mode sends updates at set intervals. Each update contains paired values, where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination. In the RIP metric, a router advertises directly connected networks at a metric of 1 by default. Networks that are reachable through one other gateway are 2 hops, etc. Thus, the number of hops or hop count along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path. Using hop counts to calculate shortest paths does not always produce optimal results. For example, a path with a hop count 3 that crosses three Ethernets may be substantially faster than a path with a hop count 2 that crosses two slow-speed serial lines. To compensate for differences in technology, many routers advertise artificially high hop counts for slow links.

RIP dynamically builds on information received through RIP updates. When started up, RIP issues a request for routing information and then listens for responses to the request. If a system configured to supply RIP hears the request, it responds with a response packet based on information in its routing database. The response packet contains destination network addresses and the routing metric for each destination.

When a RIP response packet is received, the routing daemon takes the information and rebuilds the routing database, adding new routes and "better" (lower metric) routes to destinations already listed in the database. RIP also deletes routes from the database if the next router to that destination reports that the route contains more than 15 hops, or if the route is deleted. All routes through a gateway are deleted if no updates are received from that gateway for a specified time period. In general, routing updates are issued every 30 seconds. In many implementations, if a gateway is not heard from for 180 seconds, all routes from that gateway are deleted from the routing database. This 180-second interval also applies to deletion of specific routes.

RIP version 2 (more commonly known as RIP II) adds additional capabilities to RIP. Some of these capabilities are compatible with RIP I and some are not. To avoid supplying information to RIP I routes that could be misinterpreted, RIP II can use only non-compatible features when its packets are multicast. On interfaces that are not capable of IP multicast, RIP-I-compatible packets are used that do not contain potentially confusing information.

Some of the most notable RIP II enhancements are:

• Next hop
• Network mask
• Authentication
• RIP tag field

These features in RIP I and II are contrasted in the following paragraphs.

Next hop

With RIP II, a router can advertise a next hop other than itself. Next hop is useful when advertising a static route to a dumb router that does not run RIP, because it avoids having packets that are passed through the dumb router from having to cross a network twice. Because RIP I routers will ignore next hop information in RIP II packets, packets might cross a network twice, which is exactly what happens with RIP I. Next hop information is provided in RIP-I-compatible RIP II packets.

Network mask

RIP I assumes that all subnetworks of a given network are classful (Class A,B,C). RIP I uses this assumption to calculate the network masks for all routes received. This assumption prevents subnets with classless netmasks from being included in RIP packets. RIP II adds the ability to specify the network mask with each network in a packet. Because RIP I routers will ignore the network mask in RIP II packets, their calculation of the network mask will quite possibly be wrong. For this reason, RIP-I-compatible RIP II packets must not contain networks that would be misinterpreted. These networks must be provided only in native RIP II packets that are multicast.

RIP I derives the network mask of received networks and hosts from the network mask of the interface via which the packet was received. If a received network or host is on the same natural network as the interface over which it was received, and that network is subnetted (the specified mask is more or less specific than the natural netmask), the interface’s subnet mask is applied to the destination. If bits outside the mask are set, it is assumed to be a host; otherwise, it is assumed to be a subnet. On point-to-point interfaces, the netmask is applied to the remote address. The netmask on these interfaces is ignored if it matches the natural network of the remote address, or is all ones. Unlike previous releases, the zero subnet (a subnetwork that matches the natural network of the interface, but has a more specific, or longer, network mask) is advertised. If this is not desirable, a route filter may be used to reject it.

Authentication

RIP II packets may contain one of two types of authentication strings that may be used to verify the validity of the supplied routing data. Authentication may be used in RIP-I-compatible RIP II packets, but be aware that RIP I routers will ignore these packets (unless ignore-must-be-zero is configured off). The first method is a simple password in which an authentication key of up to 16 characters is included in the packet. If this key does not match what is expected, the packet will be discarded. This method provides very little security because it is possible to learn the authentication key by watching RIP packets.

The second method uses the MD5 algorithm to create a crypto-checksum of a RIP packet and an authentication key of up to 16 characters. The transmitted packet does not contain the authentication key itself; instead, it contains a crypto-checksum, called the "digest". The receiving router will perform a calculation using the correct authentication key and discard the packet if the digest does not match. In addition, a sequence number is maintained to prevent the replay of older packets. This method provides a much stronger assurance that routing data originated from a router with a valid authentication key.

Two authentication methods can be specified per interface. Packets are always sent using the primary method, but received packets are checked with both the primary and secondary methods before being discarded. In addition, a separate authentication key is used for non-router queries.

RIP Commands

Global Configuration Mode RIP Commands

"router rip"

Router Mode RIP Commands

"default-metric"

"distribute-list"

"ecmp"

"enable"

"flash-update-time"

"ignore-host-routes"

"ignore-must-be-zero"

"network"

"preference"

"query-authentication"

"redistribute"

"send-updates"

"source-gateways"

"split-horizon"

"term-updates"

"timers basic"

"trace file"

"trace flag"

"trusted-gateways"

RIP Interface Commands

"ip rip authentication"

"ip rip enable"

"ip rip metric-in"

"ip rip metric-out"

"ip rip no-receive"

"ip rip no-send"

"ip rip secondary-authentication"

"ip rip version"

RIP Querying Commands

"show ip rip database"

router rip

Name

router rip - enters the user into Router Configuration mode for RIP

Syntax

router rip

no router rip

Mode

Global Configuration

Parameters

none

Description

Use the router rip command to enter RIP Router Configuration mode. Once you are in RIP Router Configuration mode, you can begin configuring RIP.

Default

None. You must specify this command in order to configure RIP.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example shows how to enter RIP Router Configuration mode.

(config)# router rip

(config-router-rip)#

default-metric

Name

default-metric - configures the default metric for advertising RIP routes learned from other protocols

Syntax

default-metric metric_value

no default-metric metric_value?

Mode

RIP Router Configuration

Parameters

metric_value - an integer from 0 to 16, inclusive, assigned to exported reachability

Description

Use the default-metric command to set the default metric value for advertising RIP routes learned from other protocols. All routes exported into RIP will receive this metric unless a matching route-map sets the metric to a different value.

The negative form of this command, no default-metric, removes the configured value and returns this to its default value of 1. Note: Specifying a value for metric_value in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If default-metric is not specified, it is the same as if the user had specified the following:

(config-router-rip)# default-metric 1

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures the RIP default metric value to be 2.

(config)# router rip

(config-router-rip)# default-metric 2

(config-router-rip)# exit

(config)#

distribute-list

Name

distribute-list - configures policy for RIP to apply to incoming or outgoing updates

Syntax

distribute-list access_list_name [in [interface-name ||
route-map rm_name]?] | [out [interface-name || protocol]? ]

no distribute-list access_list_name [in [interface-name
|| route-map rm_name]?] | [out [interface-name || protocol]?]

Mode

RIP Router Configuration Mode

Parameters

distribute-list in

access_list_name - the name of an access list

in - specifies that the policy applies to incoming updates

interface-name - optionally specify a physical interface name to which this policy will apply. Otherwise, it applies to all interfaces.

route-map name - the name of a route map to apply to incoming routes. Specifying this is optional.

distribute-list out

access_list_name - the name of an access list

out - specifies that the policy applies to exported updates

interface-name - optionally specify a physical interface name to which this policy will apply. Otherwise, it applies to all interfaces.

protocol - optionally specify a redistributed protocol to filter. Valid values include: aggregate, bgp, isis, kernel, ospf, ospf-ase, rip, and static.

Description

The distribute-list command provides a policy filtering mechanism for RIP routes. If the distribute list configured in this command is specified with the in keyword, then the filter will apply to all imported routes (that is to say, routes learned from RIP neighbors). If the distribute list configured in this command is specified with the out keyword, then the filter applies to exported routes (that is to say, routes announced to RIP neighbors).

To delete a configured distribute list, use the negative form of the command. Note: All arguments of the original command must be supplied in order for the entry to be deleted.

distribute-list in

The distribute-list in command configures a RIP import policy (in other words, a policy for RIP to apply to incoming updates). You can specify both an interface-name and a Route Map in the policy. Note that order is not important when specifying both.

If an inbound distribute-list is configured, then each route received from other RIP neighbors will be evaluated against this inbound list. If the route matches the criteria specified by the inbound list, then the route is imported. If the route does not match the inbound list criteria, then the route is rejected. A route matches the inbound list criteria if it is permitted when evaluated against the referenced access list. Furthermore, if the inbound distribute-list references a route map, then the route must also match when evaluated against the route map.

If the distribute-list in command references a route map that has not yet been defined, then an empty route map is created with the specified name.

If two inbound distribute lists are configured, one that does not reference an interface and one that does, then the most specific inbound distribute list is used when evaluating a route received from other RIP neighbors. If the route was received over an interface not named in any inbound distribute list, then the inbound distribute list that does not reference an interface is used. Otherwise, the inbound distribute list that references the interface over which the route was received is used.

At most, one distribute-list in command can be specified without an interface. Subsequent distribute-list in commands that do not reference an interface will overwrite any such previous command. Similarly, at most one distribute-list in command can be specified for each interface, and subsequent commands that reference an interface will overwrite any such previous command.

distribute-list out

The distribute-list out command is used to configure export policy for RIP routes. Outbound distribute lists look similar to inbound distribute lists, except that they allow you to optionally specify an interface and a protocol, or more correctly, a route source. This allows you to filter exported routes based on whether they were learned from BGP, OSPF, OSPF-ASE or were aggregate, static, or kernel routes. If an interface is specified, then the export policy described by the distribute-list out command only applies to the referenced interface. At most one distribute-list out command can be specified for each interface for each protocol. Furthermore, at most one distribute-list out command that does not reference a protocol can be specified. If an outbound distribute list is configured without referencing a protocol, then when a route is being considered for export to RIP neighbors, it must be permitted by the access list referenced in the distribute list. If instead an outbound distribute list is configured that references a protocol, and if the route being considered for export originated from the referenced protocol, then the route must be permitted by the access list referenced in the distribute list. If more of both types of lists are present, then the route need only be permitted by the access list referenced by one of the outbound distribute lists.

It should be noted that an outbound distribute list has no effect in the absence of a "redistribute" command. Outbound distribute lists can be thought of as a way to further refine the export policy expressed with a "redistribute" command.

The negative form of this command, no distribute-list, removes the configured list. You must specify either in or out in the negative form. For outbound distribute lists, specifying a protocol is optional. If the protocol is not specified, then all distribute lists referencing the specified access list will be deleted.

Default

The default is for RIP to import everything.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

In the following example, incoming updates received on interface fxp0 are matched against a standard IP access-list named "abc".

(config)# router rip

(config-router-rip)# distribute-list abc in fxp0

(config-router-rip)# exit

(config)#

Example 2

In the following example, incoming updates received on interface fxp0 are matched against a standard IP access-list named "alist1". A route map named "rm1" is also applied to the incoming updates.

(config)# router rip

(config-router-rip)# distribute-list alist1 in route-map rm1 fxp0

(config-router-rip)# exit

(config)#

Example 3

In the following example, incoming updates from all interfaces are matched against a standard IP access-list named "alist1". A route map named "rm1" is also applied to incoming updates.

(config)# router rip

(config-router-rip)# distribute-list alist1 in route-map rm1

(config-router-rip)# exit

(config)#

Example 4

In the following example, the distribute-list entry originally configured in Example 3 is deconfigured.

(config)# router rip

(config-router-rip)# no distribute-list alist1 in route-map rm1

(config-router-rip)# exit

(config)#

ecmp

Name

ecmp - configures equal-cost multipaths

Syntax

ecmp

no ecmp

Mode

RIP Router Configuration

Parameters

none

Description

The ecmp command is used to enable the Equal-Cost Multi-Path (ECMP) feature. Use the negative form of this command, no ecmp, to disable the ECMP feature.

Default

If ecmp is not specified, it is the same as if the user had specified the following:

(config-router-rip)# no ecmp

Command History

NGC 2.2 - This command was introduced.

Examples

The following example turns on the ECMP feature.

(config)# router rip

(config-router-rip)# ecmp

(config-router-rip)# exit

(config)#

enable

Name

enable - enables RIP on a router

Syntax

enable

no enable

Mode

RIP Router Configuration

Parameters

none

Description

The enable command enables the state RIP. The negative form of this command, no enable, disables RIP on the router.

Default

If enable is not specified, it is the same as if the user had specified the following:

(config-router-rip)# enable

Command History

NGC 2.2 - This command was introduced.

Examples

The following example disables RIP on the router.

(config)# router rip

(config-router-rip)# no enable

(config-router-rip)# exit

(config)#

flash-update-time

Name

flash-update-time - sets the number of seconds between flash updates

Syntax

flash-update-time time-seconds

no flash-update-time time-seconds?

Mode

RIP Router Configuration

Parameters

time-seconds - an integer between 0 and 5, specifying a number of seconds

Description

The flash-update-time command configures the Flash Update time. By default. The flash-update-timer is set to a random value with a range of (0, 5) inclusive. The negative form of this command, no flash-update-time, removes the configured time-seconds value and returns this to a random number between 0 and 5. Note: Specifying a value for time-seconds in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

The default Flash Update time value is a random number between 0 and 5.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures the flash-update-timer to be 3 seconds.

(config)# router rip

(config-router-rip)# flash-update-time 3

(config-router-rip)# exit

(config)#

ignore-host-routes

Name

ignore-host-routes - configures Advanced Routing Suite to reject host routes learned in RIP response messages

Syntax

ignore-host-routes

no ignore-host-routes

Mode

RIP Router Configuration

Parameters

none

Description

The ignore-host-routes command causes Advanced Routing Suite to reject host routes (with a netmask of 255.255.255.255) learned in RIP response messages. The negative form of this command, no ignore-host-routes, returns to the default setting of accepting host routes learned in RIP response messages.

Default

If ignore-host-routes is not specified, it is the same as if the user had specified the following:

(config-router-rip)# no ignore-host-routes

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures the router to not recognize host routes.

(config)# router rip

(config-router-rip)# ignore-host-routes

(config-router-rip)# exit

(config)#

ignore-must-be-zero

Name

ignore-must-be-zero - configures the handling of zero-filled reserved fields in RIP 1

Syntax

ignore-must-be-zero

no ignore-must-be-zero

Mode

RIP Router Configuration

Parameters

none

Description

The RIP version 1 specification mandates that certain fields in RIP routing updates are reserved and should be filled with zeros. It also mandates that version 1 packets, where the reserved fields are not filled with all zeros, should be discarded. However, some implementations of RIP do not follow the specification and carry non-zero information in these fields. The ignore-must-be-zero command allows RIP to interoperate with those implementations.

The user should be certain that the non-compliant router is intentionally generating malformed packets (rather than malfunctioning) before enabling interoperability. Otherwise, correct routing could be compromised.

The negative form of this command, no ignore-must-be-zero, returns this command to the default of checking zero-filled reserved fields for RIP version 1.

Default

If ignore-must-be-zero is not specified, it is the same as if the user had specified the following:

(config-router-rip)# no ignore-must-be-zero

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures the RIP router to ignore messages whose reserved fields are not zeroed.

(config)# router rip

(config-router-rip)# ignore-must-be-zero

(config-router-rip)# exit

(config)#

network

Name

network - configures a network on which to run RIP

Syntax

network ipv4_address [ mask ]? {1,n}

no network ipv4_address [ mask ]?

Mode

RIP Router Configuration

Parameters

ipv4_address - a valid IPv4 address specified in dotted-quad notation

mask - specify the mask (wildcard bits) of the network IP address. Specifying this value is optional.

{1,n} - The network command can be specified multiple times in RIP Router Configuration mode.

Description

The network command specifies a network on which to run RIP. Use the command multiple times to build a list of networks on which RIP is to run. If the optional mask is not specified, RIP will be enabled on all interfaces that match the natural mask of the network IP address, and that natural mask will display when you issue a show running command. If the mask is supplied, then RIP will run on interfaces that match both the network address and the mask.

Use the negative form of this command, no network, to stop running RIP on a network. Note: The complete configuration must be provided in the negative command. For example, if you configured a network address and specified a mask, both values must appear in the negative command.

Default

RIP networks are not explicitly configured by default.

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures RIP to run on interface 192.168.121.1 and the interface associated with network 192.168.11.0.

(config)# router rip

(config-router-rip)# network 192.168.121.1

(config-router-rip)# exit

(config)#

preference

Name

preference - specifies how active routes that are learned from RIP will be selected, compared to routes learned from other protocols

Syntax

preference pref

no preference pref?

Mode

RIP Router Configuration

Parameters

pref - an integer from 0 (directly connected) to 255, inclusive

Description

Routers can learn multiple routes to the same destination. Each routing protocol handles this internally, so, for example, if RIP learns two different routes to the same destination, it will select the route with the lower metric. However, a router can learn two routes to the same destination from different routing protocols, and it must find a way to choose between them. Advanced Routing Suite uses a preference number to make this decision, choosing the route with the lower preference. Normally, RIP routes are preferred to routes from external routing protocols (for example, BGP or OSPF ASE) and to those that are generated or aggregated. RIP routes are less preferable than those learned from other intra-domain routing protocols and those that are statically configured. The preference command is used to change this ordering.

The negative form of this command, no preference, removes the configured pref value and returns this to its default value of 100. Note: Specifying a value for pref in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If preference is not specified, it is the same as if the user had specified the following:

(config-router-rip)# preference 100

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures a preference of 150 for RIP routes.

(config)# router rip

(config-router-rip)# preference 150

(config-router-rip)# exit

(config)#

query-authentication

Name

query-authentication - configures the authentication used by the ripquery utility

Syntax

query-authentication [ [simple key] | [md5
id_number md5_key (start-generate date_time ||
stop-generate date_time || start-accept date_time ||
stop-accept date_time)?] {0,4} ]

no query-authentication

Mode

RIP Router Configuration

Parameters

simple key - specifies simple (clear password) authentication. The value for key is specified by one to eight decimal digits (with a value between 0 and 255) separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string.

md5 id_number md5_key [(start-generate date_time) || (stop-generate date_time) || (start-accept date_time) || (stop-accept date_time)] - specifies the authentication used for specifying md5 cryptographic authentication. The value for id_number is an integer with a value between 1 and 255, inclusive. The value for md5_key is a one- to sixteen-character string. The start and stop values must be in the format: YYYY-MM-DD.HH.MM. Each start and stop value is optional, and order is not important when specifying multiple commands.

{0,4} - up to 4 MD5 key values can be configured, provided each has a unique md5_key value.

Description

The ripquery utility was created for debugging RIP routers. This tool sends a RIP POLL packet, which is an extension undocumented in the RFC. The query-authentication command is used to check the incoming POLL packets. If the authentication matches, then RIP will reply with its full routing table. (It will not run split-horizon or poison reverse before replying.) If the authentication does not match, then the request will be discarded.

Although query-authentication uses the standard key format for passwords, the generate portions of the key are irrelevant because the key is used only to check incoming requests. Outing packets use whatever authentication is set up on the interface over which the POLL packet was received.

Simple and md5 keys are mutually exclusive. Multiple md5 key values can be configured for an md5 authentication provided each key has a unique md5_key value.

Default

Query authentication is not explicitly configured by default.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures a simple key password for Query Authentication.

(config)# router rip

(config-router-rip)# query-authentication simple abc

(config-router-rip)# exit

(config)#

Example 2

The following example configures md5 authentication with two key chains.

(config)# router rip

( config-router-rip)# query-authentication md5 1 abc
start-accept 2003-12-01.10.20 stop-accept
2003-12-11.10.20 start-generate 2003-12-01.10.20
stop-generate 2003-12-11.10.20

(config-router-rip)# query-authentication md5 2 abc
start-accept 2003-12-11.10.20 stop-accept
2003-12-21.10.20 start-generate 2003-12-11.10.20
stop-generate 2003-12-21.10.20

(config-router-rip)# exit

(config)#

redistribute

Name

redistribute - specifies routes to export to the current protocol

Syntax

redistribute protocol [route-map name]? {0,9}

no redistribute protocol [route-map name]?

Mode

RIP Router Configuration

Parameters

protocol - the protocol name whose routes you want to redistribute to the current protocol being configured. Valid protocols are aggregate, bgp, direct, isis, kernel, ospf, ospf-ase, rip, and static.

route-map name - the name of a route map to apply to these routes. Specifying this is optional.

{0,9} - although this command can be given multiple times, it can only be given once for each of the nine configurable protocols. In other words, if a redistribute command is given for a protocol and route map, and then given again for the same protocol with a different route map, the second configuration overrides the first.

Description

Use the redistribute command to specify routes to export into the current protocol (BGP, OSPF-ASE, RIP, or VRE). This command causes routes from the specified protocol to be considered for redistribution into the current protocol. Additionally, if a route map is specified, then routes from the specified protocol that match the named route map will be considered for redistribution into the current protocol. If the referenced route map has not yet been configured, then an empty route map is created with the specified name.

Note: Configuring this away from its default removes the implicitly configured default. You will have to go back and specify to redistribute RIP and/or direct routes after the first redistribute configuration in order to export those routes.

Default

The default is to export direct routes and RIP routes. Note that this is an implicit default that is wiped away with the first redistribute configuration.

Example

Example 1

In the following example RIP is configured to redistribute all BGP routes.

(config)# router rip

(config-router-rip)# redistribute bgp

(config-router-rip)# exit

(config)#

Example 2

The following example configures a community set, "set1", that permits AS:num 101:102. It then configures an extended community set "ext-set1", that permits Route Target AS:num 201:202.

(config)# ip community-set set1 permit 101:102

(config)# ip extcommunity-set ext-set1 permit rt 201:202

The two are then added to a community list, called "commlist1".

(config)# ip community-list commlist1 permit set1

(config)# ip community-list commlist1 permit ext-set1

The community list is then applied to a route map called "match-commlist1". If the route map matches BGP Community list "commlist1", then the metric for routes will be set to 20.

(config)# route-map match-commlist1

(config-route-map)# match community commlist1

(config-route-map)# set metric 20

(config-route-map)# exit

(config)#

Finally, the route map ("match-commlist1") is applied to BGP routes and exported into RIP.

(config)# router rip

(config-router-rip)# redistribute bgp route-map match-commlist1

(config-router-rip)# exit

(config)#

Example 3

In the following example, route map "abc" is configured with the following match criteria:

If a route matches interface "fxp1" and a pre-configured BGP Community labeled "bgpcomm1", then communities specified in community "com-set-1" will be added to the route, communities specified in community labeled "com-set-2" will be deleted from the route, and the metric of the route will be set to 50.

(config)# route-map abc

(config-route-map)# match interface fxp1

(config-route-map)# match community-set bgpcomm1

(config-route-map)# set community-set com-set-1 additive

(config-route-map)# set community-set com-set-2 delete

(config-route-map)# set metric 50

(config-route-map)# exit

(config)#

This route map is then applied to static routes and exported into RIP.

(config)# router rip

(config-router-rip)# redistribute static route-map abc

(config-router-rip)# exit

See Also

"distribute-list"

send-updates

Name

send-updates - specifies the conditions under which RIP will be an active or a passive participant

Syntax

send-updates [on | off | multiple-interfaces]?

no send-updates

Mode

RIP Router Configuration

Parameters

on - configures updates to be sent even if only one interface is present

off - updates will not be sent regardless of the number of interfaces present

multiple-interfaces - optionally specify that, if multiple interfaces (either physical or logical) have addresses on the same subnet, then RIP will send updates only on the first one for which RIP is configured to do so, regardless of configuration

Description

RIP is most often run on a multi-homed box to cause the machine to act as a router in small LANs; however, it is also run on single-homed machines, often to learn the default route or routes to other networks in the domain. RIP will try to guess whether it should act as a router (for example, whether it should act as an active participant in routing) by examining the number of interfaces available to it.

The send-updates command can be used to override this default behavior. Specifically, if send-updates is specified without the multiple-interfaces or off options, then RIP updates will be sent even if only one interface is present. This is the same behavior as the send-updates on command.

If the send-updates command is specified with the multiple-interfaces option, and if multiple interfaces have addresses on the same subnet, then RIP will send updates only on the first for which RIP is configured to do so, regardless of the configuration. Finally, if no send-updates is specified, or if send-updates off is specified, then RIP updates will not be sent, regardless of the number of interfaces present.

The no send-updates command is most often used to turn off active participation in a RIP cloud. This can be used, for example, on a multi-homed machine running different protocols on different interfaces where it is desired not to send the other attached networks or learned routes into the RIP cloud. The same functionality can be achieved through policy rules. But for a simple network, that degree of configuration complexity is not necessary.

Note: All values of send-updates apply only to broadcasting (or multicasting, in the case of RIP version 2) of RIP packets.

Default

If send-updates is not specified, it is the same as if the user had specified the following:

(config-router-rip)# send-updates multiple-interfaces

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures RIP to send updates, even if only one interface is present.

(config)# router rip

(config-router-rip)# send-updates

(config-router-rip)# exit

(config)#

Example 2

The following example configures RIP to not send any updates to an interface.

(config)# router rip

(config-router-rip)# no send-updates

(config-router-rip)# exit

(config)#

source-gateways

Name

source-gateways - specifies the routers to which RIP will unicast update messages

Syntax

source-gateways ipv4_address {n}

no source-gateways ipv4_address

Mode

RIP Router Configuration

Parameters

ipv4_address - a valid IPv4 address in dotted-quad notation

{n} - This command can be specified multiple times to configure a complete list of IP addresses to which the configured router will unicast RIP updates.

Description

The source-gateways command allows you to configure a complete list of IP addresses to which the configured router will unicast RIP updates. Note: RIP must be configured on an interface that shares a subnet with each gateway address.

If any source gateways are specified, then no RIP packets will be broadcast or multicast. They will only be unicast to the list of source gateways. If no source gateways are specified, Advanced Routing Suite will not unicast updates.

Use the negative form of this command, no source-gateways, with a specific IPv4 address to remove one source gateway address from the configured list. Use the negative form with no specified address to delete the entire list of source gateways.

Default

By default, RIP will either broadcast or multicast its updates. Thus, if source-gateways is not specified, it is the same as if the user had specified the following:

(config-router-rip)# no source-gateways

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

In the following example, a list of three source-gateways is configured. Advanced Routing Suite will unicast updates to the source gateways 192,168.10.1, 101.168.11.1, and 192.168.12.1.

(config)# router rip

(config-router-rip)# source-gateways 192.168.10.1

(config-router-rip)# source-gateways 192.168.11.1

(config-router-rip)# source-gateways 192.168.12.1

(config-router-rip)# exit

(config)#

Example 2

In the following example, the source-gateway 192.168.11.1 from Example 1 is deleted.

(config)# router rip

(config-router-rip)# no source-gateways 192.168.11.1

(config-router-rip)# exit

(config)#

Example 3

In the following example, the rest of the entire source-gateways list from Example 1 is deleted. As a result, RIP will send updates by broadcast or multicast.

(config)# router rip

(config-router-rip)# no source-gateways

(config-router-rip)# exit

(config)#

split-horizon

Name

split-horizon - configures the split horizon feature for RIP

Syntax

split-horizon [ on | off | poison-reverse ]

no split-horizon

Mode

RIP Router Configuration Mode

Parameters

on - RIP will not announce a route back to the interface from which the route is learned

off - RIP will announce a route to all possible interfaces, including the interface from which the route was learned

poison-reverse - RIP will announce a route to all possible interfaces, including the interface from which the route was learned, but with the infinity metric

Description

The split-horizon command configures the way horizon split is performed. This command has three forms. If on is specified, then the simple split-horizon mechanism is enabled. This means that RIP will not announce a route back to the interface from which the route was learned. If off is specified, then the split horizon mechanism is disabled. This means that RIP will announce a route to all possible interfaces, including the interface from which the route was learned. Finally, if poison-reverse is specified, then split horizon with poisoned reverse is enabled. This means that RIP will announce a route to all possible interfaces, including the one from which the route was learned, but with the infinity metric.

The negative form of this command, no split-horizon, removes the configured split horizon type and returns this to its default type .

Default

If split-horizon is not specified, it is the same as if the user had specified the following:

(config-router-rip)# split-horizon on

Examples

Example 1

In the following example, RIP is configured without split horizon.

(config)# router rip

(config-router-rip)# split-horizon off

(config-router-rip)# exit

(config)#

Example 2

In the following example, RIP is configured with split horizon with poisoned reverse.

(config)# router rip

(config-router-rip)# split-horizon poison-reverse

(config-router-rip)# exit

(config)#

Example 3

In the following example, RIP is configured to return to the default behavior of split horizon. Split horizon will be the effect.

(config)# router rip

(config-router-rip)# no split-horizon

(config-router-rip)# exit

(config)#

term-updates

Name

term-updates - sets the number of updates sent by RIP during termination

Syntax

term-updates number

no term-updates number?

Mode

RIP Router Configuration

Parameters

number - an integer between 1 and 255, inclusive

Description

The term-updates command configures the number of updates sent by RIP during termination. The negative form of this command, no term-updates, removes the configured number value and returns this to its default value of 4. Note: Specifying a value for number in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If term-updates is not specified, it is the same as if the user had specified the following:

(config-router-rip)# term-updates 4

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures a term update number of 6.

(config)# router rip

(config-router-rip)# term-updates 6

(config-router-rip)# exit

(config)#

timers basic

Name

timers basic - sets the Update Interval, Expiration Time, and Holddown Time for routes received or sent via RIP

Syntax

timers basic update-seconds expiration-seconds holddown-seconds

no timers basic [update-seconds expiration-seconds holddown-seconds]?

Mode

RIP Router Configuration

Parameters

update-seconds - the update interval in seconds, specified as an integer from 5 to 4,294,967,295 inclusive

expiration-seconds - the route expiration time in seconds, specified as an integer from5 to 4,294,967,295 inclusive

holddown-seconds - configures the holddown time in seconds, specified as an integer from 5 to 4,294,967,295 inclusive

Description

The timers basic command sets the Update Interval, the Expiration Time, and the Holddown Time in seconds for routes received and/or sent via RIP. The negative form of this command, no timers basic, returns this value to its default. Specifying values for update-seconds, expiration-seconds, and holddown-seconds in the no form has no effect on the configuration. Thus, they are displayed above as optional.

Note: When configuring timers basic, you must specify an update-seconds value, an expiration-seconds value, and a holddown-seconds value, in that order, even if you want one or two of these to remain the default value.

Default

If timers basic is not configured, it is the same as if the user had specified the following:

(config-router-rip)# timers basic 30 180 120

Command History

NGC 2.2 - This command was introduced.

NGC 2.3 - The Holddown Timer value was added to this command. In addition, each of the previous value ranges changed to 5 to 4,294,967,295 inclusive.

Examples

Example 1

The following example configures the Update Interval to be 25 seconds, the Expiration Time to be 150 seconds, and the Holddown Timer to be 300 seconds.

(config)# router rip

(config-router-rip)# timers basic 25 150 300

(config-router-rip)# exit

(config)#

Example 2

The following example configures the Expiration Time to be 200 seconds. The Update Interval will have the default value of 30 seconds. The Holddown Timer will also have its default value. Note that you must specify the Update Interval and Holddown Timer values even though you are configuring the default.

(config)# router rip

(config-router-rip)# timers basic 30 200 120

(config-router-rip)# exit

(config)#

Example 3

The following example removes any configured timer values and returns the timers basic command to its default values.

(config)# router rip

(config-router-rip)# no timers basic

(config-router-rip)# exit

(config)#

trace file

Name

trace file - specifies the file to receive tracing information, the size of the file, whether to overwrite existing files, and the maximum number of files allowed

Syntax

trace file file_name [no-timestamp || overwrite]?

no trace file file_name [no-timestamp || overwrite]?

Mode

RIP Router Configuration

Parameters

file_name - specifies the name of the file to receive the tracing information. Note that the file name is not specified in quotes.

no-timestamp - specifies that a timestamp should not be prepended to all trace lines

overwrite - specifies to begin tracing by appending or truncating an existing file

Description

The trace file command is associated with each protocol, so that information pertaining to a single protocol can be written to its own file. For RIP, the trace file command in RIP Router Configuration Mode specifies a file for tracing of all RIP events. The negative form of this command disables this tracing. The specific events that are traced are controlled by the trace flag command.

The no-timestamp option disables the pre-pending of a timestamp to all lines written to the trace file. The default is to prepend a timestamp to all lines written to a trace file.

The overwrite option specifies whether to start tracing by truncating or appending to an existing file.

Note: These options are not cumulative across multiple commands.

Default

RIP tracing is turned off by default.

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, RIP tracing is written to the file "rip.log". No timestamp will display at the beginning of the trace lines.

(config)# router rip

(config-router-rip)# trace file rip.log no-timestamp

trace flag

Name

trace flag - specifies RIP-specific tracing options as well as options that are common across all protocols

Syntax

trace flag ( [ route | normal | state | policy | task |
timer | all ] ) | ( [ packets | request | response |
other ] [ send | receive | send-receive ]? [detail?] )

no trace flag ( [ route | normal | state | policy | task |
timer | all ] ) | ( [ packets | request | response |
other ] [ send | receive | send-receive ]? [detail?] )

Mode

RIP Router Configuration

Parameters

Flags common to all protocols:

[ route | normal | state | policy | task | timer | all ] - These tracing flags are common to all protocols. They cannot be associated with a send, receive, or send-receive action item. Similarly, you cannot specify to show detailed information when tracing these flags. These flags are defined as follows:

• route - trace routing table changes for routes installed by this protocol or peer
• normal - trace normal protocol occurrences. Note: Abnormal protocol occurrences are always traced.
• state - trace state machine transition in the protocol
• policy - trace the application of protocol and user-specified policy to routes being imported or exported
• task - trace system interface and processing associated with this protocol
• timer - trace timer usage by this protocol
• all - turns on all trace flags

IP-specific flags:

[ packets | request | response | other ] - These RIP-specific flags can be associated with the send, receive, or send-receive action items. These flags are defined as follows:

• packets - trace all RIP packet types
• request - trace RIP information request packets, which include request, poll, and poll entry packets
• response - trace RIP response packets (for example, those that actually contain routing updates)
• other - trace any other type of RIP packet

[send | receive | send-receive ]? - optionally specify whether to limit the tracing to packets sent, received, or both

[detail?] - optionally specify to use a more verbose format when displaying information about the contents of packets instead of one or two lines

Description

Use the trace flag command to specify tracing flags for RIP tracing. Each flag must reside on its own configuration line. For example, you cannot specify to trace both task and policy packets in the same command.

Default

The default is for no flags to be explicitly configured.

Command History

NGC 2.2 - This command was introduced.

Examples

In the following example, trace flags specify that both the sent and received request and response messages are traced in detail. This tracing information will be written to the file rip.log.

(config)# router rip

(config-router-rip)# trace file rip.log

(config-router-rip)# trace flag request send-receive detail

(config-router-rip)# trace flag response send-receive detail

(config-router-rip)# exit

(config)#

trusted-gateways

Name

trusted-gateways - configures the routers from which RIP will accept routes

Syntax

trusted-gateways ipv4-address {n}

no trusted-gateways ipv4-address?

Mode

RIP Router Configuration

Parameters

ipv4-address - a valid IPv4 address in dotted-quad notation

{n} - This command can be repeated an unlimited number of times to create an unlimited number of trusted gateways.

Description

The trusted-gateways command configures routers from which RIP will accept routes. Update messages from routes not specified in this command will be discarded. This allows for additional security beyond that provided by "ip rip authentication". Specifically, it provides a complete list of IP addresses from which the configured router will accept RIP updates. Only those RIP packets originating from the listed hosts will be accepted.

Use the negative form of this command, no trusted-gateways, with an IPv4 address to remove a single address from the list of trusted gateways. To delete the entire list, use the negative form of the command with no IPv4 address.

Default

All routers are trusted by default.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures RIP to accept updates sent from routes with only host addresses of 2 on the 192.168.10, .12, and .13 networks.

(config)# router rip

(config-router-rip)# trusted-gateways 192.168.10.2

(config-router-rip)# trusted-gateways 192.168.11.2

(config-router-rip)# trusted-gateways 192.168.12.2

(config-router-rip)# exit

(config)#

Example 2

In the following example, the trusted-gateway 192.168.11.1 from Example 1 is deleted.

(config)# router rip

(config-router-rip)# no trusted-gateways 192.168.11.1

(config-router-rip)# exit

(config)

Example 3

In the following example, the rest of the entire trusted-gateways list from Example 1 is deleted. As a result, RIP will trust all routers.

(config)# router rip

(config-router-rip)# no trusted-gateways

(config-router-rip)# exit

(config)#

ip rip authentication

Name

ip rip authentication - specifies the type of authentication and key values

Syntax

ip rip authentication [ [simple key] | [md5
id_number md5_key (start-generate date_time ||
stop-generate date_time || start-accept date_time ||
stop-accept date_time)?] {0,4} ]

no ip rip authentication

Mode

Interface Configuration

Parameters

simple key - specifies simple (clear password) authentication. The value for key is specified by one to eight decimal digits (with a value between 0 and 255) separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string.

md5 id_number md5_key [(start-generate date_time) || (stop-generate date_time) || (start-accept date_time) || (stop-accept date_time)] - specifies the authentication used for specifying md5 cryptographic authentication. The value for id_number is an integer with a value between 1 and 255, inclusive. The value for md5_key is a one- to sixteen-character string. The start and stop values must be in the format: YYYY-MM-DD.HH.MM. Each start and stop value is optional, and order is not important when specifying multiple commands.

{0,4} - up to 4 MD5 key values can be configured, provided each has a unique md5_key value.

Description

The ip rip authentication command is used both to verify and to generate the authentication field in the RIP header for all packets sent and received on the specified interface. This applies only to version 2 packets and RIPv1-compatible RIPv2 packets, because RIPv1 does not support authentication. One exception to the above is the case of query packets. In the case of querying a router through an interface that is speaking RIPv1, the query packet will still be authenticated, but no authentication will be used on the outgoing packet.

If a packet is received with authentication that does not match, then it is ignored.

On a trusted network, simple authentication can be used to create two logical networks because sets of routers with shared passwords will talk to each other, but not communicate with those using a different password. On an untrusted network, however, this technique should not be used because simple passwords are sent in clear text. MD5 should be used instead. However, even MD5 does not encrypt the entire packet, only the authentication field of the header.

Specifying an authentication without explicitly configure RIP to version 2 will cause a parse error. For somewhat more serious authentication, use trusted gateways or a combination of trusted gateways and authentication.

Default

The default is for no authentication to be explicitly configured.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures a simple key authentication for interface fxp1.

(config)# interface fxp1

(config-if)# ip rip authentication simple abc

(config-if)# exit

(config)#

Example 2

The following example configures md5 authentication with two keys on interface fxp0.

(config)# interface fxp0

(config-if)# ip rip authentication md5 1 abc
start-accept 2003-12-01.10.20 start-generate
2003-12-01.10.20

(config-if)# ip rip authentication md5 2 abc
start-accept 2003-12-11.10.20 stop-accept
2003-12-21.10.20

(config-if)# exit

(config)#

ip rip enable

Name

ip rip enable - enables RIP on an interface

Syntax

ip rip enable

no ip rip enable

Parameters

none

Description

The ip rip enable command explicitly enables RIP on an interface. The no ip rip enable command explicitly disables RIP on an interface.

Default

If ip rip enable is not specified, it is the same as if the user had specified the following:

(config-if)# no ip rip enable

Command History

NGC 2.2 - This command was introduced

Examples

The following example disables RIP on interface fxp2.

(config)# interface fxp2

(config-if)# no ip rip enable

(config-if)# exit

(config)#

ip rip metric-in

Name

ip rip metric-in - sets an additional metric on incoming RIP routers for an interface

Syntax

ip rip metric-in value

no ip rip metric-in value?

Mode

Interface Configuration

Parameters

value - an integer in the range of 0 to 16, inclusive

Description

The ip rip metric-in command sets an additional metric on incoming RIP routes for an interface.

It is often the case that a router should prefer routes received on one set of interfaces over those received on another. For example, given two point-to-point links, one can be more expensive than the other and should, therefore, be less preferred. The ip rip metric-in command is used for exactly this purpose: to make routes learned from certain interfaces less preferable.

ip rip metric-in is the default manner by which RIP increments hop count. That is to say, RIP works by adding a hop every time a route is received and before it is sent back out to other interfaces. This implementation adds the hop when the route is received (for example, before decisions regarding whether the route should be used are made). By default, a metric of 1 plus the kernel interface metric is added as the hop count. Normally, this interface metric is zero, but some operating systems allow it to be specified on interface configuration. If ip rip metric-in is explicitly given, it is added as an absolute value (for example, without the interface metric).

The negative form of this command, no ip rip metric-in, returns this to its default value. Note: Specifying a value in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If ip rip metric-in is not specified, it is the same as if the user had specified the following:

(config-if)# ip rip metric-in 1

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures a router to add a metric of 2 to the incoming RIP routes on interface fxp0.

(config)# interface fxp0

(config-if)# ip rip metric-in 2

(config-if)# exit

(config)#

ip rip metric-out

Name

ip rip metric-out - sets an additional metric on outing RIP routes for an interface

Syntax

ip rip metric-out value

no ip rip metric-out value?

Mode

Interface Configuration

Parameters

value - an integer between 0 and 16, inclusive

Description

The ip rip metric-out command configures an addition metric on outgoing RIP routes for an interface.

Normally, this RIP implementation adds to the hop count only on incoming routes. There are times, however, when the user wants to cause other routers not to prefer routes from a given origin. For example, if the router is a backup router, it might be desirable for its routes to always be less preferred. ip rip metric-out accomplishes this by adding to the RIP metric on top of any metric specified by ip rip metric-in before RIP updates are sent out the specified interface.

Use the negative form of this command, no ip rip metric-out, to remove a configured value and return this to its default value of 0. Note: Specifying a value in the no form has no effect on the configuration. Thus, it is displayed above as optional.

Default

If ip rip metric-out is not specified, it is the same as if the user had specified the following:

(config-if) ip rip metric-out 0

Example

The following example configures a router to add a cost of 2 to outgoing RIP routes for interface fxp0.

(config)# interface fxp0

(config-if)# ip rip metric-out 2

(config-if)# exit

(config)#

ip rip no-receive

Name

ip rip no-receive - specifies whether RIP will listen to or discard RIP updates

Syntax

ip rip no-receive

no ip rip no-receive

Mode

Interface Configuration

Parameters

none

Description

The ip rip no-receive command specifies whether RIP will listen to RIP updates received on a given interface. Although it would almost certainly be a misconfiguration, it is important to note that RIP can send RIP updates on a superset of those interfaces on which it receives updates. This can be a valid configuration if, for example, the user receives RIP updates from an ISP, then redistributes those onto the LAN, and does not want to send the LAN topology back to the ISP.

Default

By default, RIP listens to updates received on a given interface. Therefore, if ip rip no-receive is not specified, it is the same as if the user had specified the following:

(config-if)# no ip rip no-receive

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures no-receive on interface fxp0. As a result, updates received on interface fxp0 will be discarded.

(config)# interface fxp0

(config-if)# ip rip no-receive

(config-if)# exit

(config)#

ip rip no-send

Name

ip rip no-send - specifies whether RIP will send RIP updates

Syntax

ip rip no-send

no ip rip no-send

Mode

Interface Configuration

Parameters

none

Description

RIP, by default, sends updates on interfaces on which RIP is running. The ip rip no-send command specifies that RIP will not send updates.

Default

If ip rip no-send is not specified, it is the same as if the user had specified the following:

(config-if)# no ip rip no-send

Command History

NGC 2.2 - This command was introduced.

Examples

The following example configures the no-send option on interface fxp1. As a result, no updates will be sent over that interface.

(config)# interface fxp1

(config-if)# ip rip no-send

(config-if)# exit

(config)#

ip rip secondary-authentication

Name

ip rip secondary-authentication - sets the authentication used on an interface if the primary authentication fails

Syntax

ip rip secondary-authentication [ [simple key] | [md5
id_number md5_key (start-generate date_time ||
stop-generate date_time || start-accept date_time ||
stop-accept date_time)?] {0,4} ]

no ip rip secondary-authentication

Mode

Interface Configuration

Parameters

simple key - specifies simple (clear password) authentication. The value for key is specified by one to eight decimal digits (with a value between 0 and 255) separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string.

md5 id_number md5_key (start-generate date_time || stop-generate date_time || start-accept date_time || stop-accept date_time)? - specifies the authentication used for specifying md5 cryptographic authentication. The value for id_number is an integer with a value between 1 and 255, inclusive. The value for md5_key is specified by one to eight decimal digits (with a value between 0 and 255) separated by periods, a one- to eight-byte hexadecimal string preceded by 0x, or a one- to eight-character string. The start and stop values must be in the format: YYYY/MM/DD HH:MM.

{0,4} - up to 4 md5 key values can be configured, provided each has a unique md5_key value.

Description

The ip rip secondary-authentication is identical in function to the primary authentication configured using the ip rip authentication command but is only used if the primary authentication fails. This type of authentication can be used while a network is in transition to verify that old passwords are still accepted.

Use the negative form of this command, no ip rip secondary-authentication, to remove the configured authentication.

Default

The default is for no authentication to be explicitly configured.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures a simple key authentication for interface fxp0.

(config)# interface fxp0

(config-if)# ip rip secondary-authentication simple abc

(config-if)# exit

(config)#

Example 2

The following example configures md5 authentication with two keys on interface fxp0.

(config)# interface fxp0

(config-if)# ip rip secondary-authentication md5 1 abc
start-accept 2003/12/01 10:20 start-generate 2003/12/01 10:20

(config-if)# ip rip secondary-authentication md5 2 abc
start-accept 2003/12/11 10:20 stop-accept 2003/12/21 10:20

(config-if)# exit

(config)#

ip rip version

Name

ip rip version - specifies the version of RIP to be run on an interface

Syntax

ip rip version [ 1 | 2 [ broadcast | multicast ]? ]

no ip rip version

Mode

Interface Configuration

Parameters

1 - specify to run RIP version 1 on the interface

2 [ broadcast | multicast ] - specify to run RIP version 2 on the interface. Also, optionally specify whether updates will be sent to a multicast group or will be broadcast to the network

Description

The ip rip version command specifies the version of RIP to be run. This command is used to override the default version of RIP that will be run on a given interface. Normally, RIPv1 will be run on all interfaces. If version 2 is specified, then the default behavior depends on the capabilities of the interface. If the interface is multicast capable, then RIP updates will be multicast to RIP2-ROUTERS.MCAST.NET (the reserved multicast address, 224.0.0.9). If the interface is not multicast capable, then RIP version 1 compatible version 2 will be broadcast.

The optional broadcast and multicast parameters are effective only if RIP version 2 is configured. Specifying broadcast or multicast allows the above default behavior to be overridden. This is normally used to specify that only version-1-compatible packets should be sent for interoperability purposes, even though a given interface is multicast capable. An exception is the case in which version 2 multicast is specified on an interface that is not multicast capable (for example, a point-to-point link). In this case, if a source-gateway is also specified, then the full RIPv2 packets will be directly unicast to the source gateway on the specified interface.

Default

If ip rip version is not specified, it is the same as if the user had specified the following:

(config-if)# ip rip version 1

If version 2 is being configured on multicast-capable interfaces without specifying multicast or broadcast, it is the same as if the user had specified the following:

(config-if)# ip rip version2 multicast

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example configures version 2 broadcast on interface fxp0.

(config)# interface fxp0

(config-if)# ip rip version 2 broadcast

(config-if)# exit

(config)#

Example 2

In the following example, the version setting in Example 1 is set back to using the default behavior for interface fxp0. Version 1 packets will then be broadcast to the network.

(config)# interface fxp0

(config-if)# no ip rip version

(config-if)# exit

(config)#

Example 3

The following example configures version 2 on multicast-capable interface fxp1. Updates will be sent out to multicast group 224.0.0.9.

(config)# interface fxp1

(config-if)# ip rip version 2

(config-if)# exit

(config)#

show ip rip database

Name

show ip rip database - displays information about a specific route or all routes in the Routing Information Base

Syntax

show ip rip database [(ipv4-address mask) | (tag value)]?

Mode

User Execution

Parameters

ipv4-address mask - optionally enter a specific IPv4 address and subnet mask argument about which routing information should be displayed

tag value - optionally specify a tag and value used to mark a specific route. The tag value can be an integer from 0 to 4,294,967,295, inclusive.

Description

The show ip rip database query displays information about routes in the Routing Information Base. This query has three forms. If the query is issued without arguments, then information about all RIP routes is returned. Alternatively, the query can be issued with a specific IPv4 address and mask. In this case, the reply will contain information pertaining only to the referenced address. Finally, a query can be submitted with a tag value. In this case, all RIP routes that match the tag will be displayed.

Command History

NGC 2.2 - This command was introduced.

Examples

Example 1

The following example displays all rip routes.

> show ip rip database

192.168.11.0/24 directly connected, fxp0
192.168.13.0/24
[1] via 192.168.14.2, 00:00:25, fxp0
[2] via 192.168.15.2, 00:00:20, fxp1
182.168.13.0/24
[1] via 182.168.14.2, 00:00:25, fxp3

Example 2

In the following example, a query is submitted for RIP route information for a specific network.

> show ip rip database 192.168.13.0 255.255.255.0

192.168.13.0/24
[1] via 192.168.14.2, 00:00:25, fxp0
[2] via 192.168.15.2, 00:00:20, fxp1

Example 3

In the following example, a query is submitted for information about RIP routes that match a given tag, 1000. The return shows one route that matches the tag.

> show ip rip database tag 1000

192.168.13.0/24
[1] via 192.168.14.2, 00:00:25, fxp3

Field Descriptions

The following table describes the fields that appear in the RIP Database Query (using fields in Example 1).