Chapter 6. RIP

6.0. Introduction

RIP Version 1 was the Internet’s first widely used routing protocol. It was standardized in RFC 1058, although implementations of the protocol based on de facto standards existed much earlier. It is still useful in small, simple networks. RIP Version 2 is documented in RFC 1723. All Cisco routers support RIP Version 1. Version 2 support was integrated into IOS Version 11.1. A detailed discussion of RIP Versions 1 and 2 is beyond the scope of this book. If you are unfamiliar with dynamic routing protocols in general or with RIP in particular, you can find theoretical descriptions of how the protocol works in IP Routing (O’Reilly) and Designing Large-Scale LANs (O’Reilly). We also recommend reading the appropriate RFCs.

RIP is useful in some situations, but you have to remember its limitations. First, it is a purely classful protocol, and Version 1 doesn’t support variable length subnet masks. So you should not use this protocol if you do any complex subnetting. Second, both Versions 1 and 2 of RIP use the very small metric value of 16 to signify “infinity.” The protocol considers any network that is more than 16 hops away to be unreachable. This is particularly important if you adjust any metric values to make RIP favor a fast link over a slow one. In practice, it is quite easy to exceed the maximum metric, even in small networks.

However, RIP can be extremely useful over small parts of a network. For example, it is much easier to configure than BGP as a method for interconnecting two or more different OSPF or EIGRP Autonomous Systems. And, because RIP has been around for so long, it is often useful when exchanging routing information with legacy equipment. Indeed, it is almost impossible to find a router of any age from any vendor that doesn’t implement RIP.

In this book, we assume that you are familiar with RIP in general and focus on Cisco’s implementation of it. We also discuss some specific issues that we think are particularly important.

One of the central features of RIP is that it distributes the entire routing table every 30 seconds. The protocol requires every device to add a small random amount to this time period, but doesn’t specify the size of this offset, or whether it should be positive or negative. Cisco routers always reduce this period slightly by subtracting a random variable amount of time, up to 4.5 seconds. This helps to prevent the synchronization problems caused by several routers sending their updates simultaneously, which can in turn cause network loading problems.

If a particular route is not seen for 6 successive update cycles, or 180 seconds by default, the routers will mark it as invalid. They will then flush the invalid route from their routing tables if they don’t see it for 8 cycles, or 240 seconds. This implies that RIP is slow to converge after a failure, but the network will actually converge much more quickly if it can take advantage of a protocol feature called triggered updates. This means that when a route’s metric suddenly changes, for whatever reason, a router using triggered updates will not wait for the full update cycle before distributing information about the change to the other routers in the network.

This is different from the modification to RIP described in Recipe 6.11, which is also called a triggered update. This feature, which is a partial implementation of RFC 2091, allows the routers to send routing updates only when there are changes, instead of sending the entire routing table at each update cycle. This makes it possible to configure the routers to just send incremental changes. Using triggered updates drastically improves RIP performance, but it must be configured on all of the routers sharing the link. It is often unsupported by legacy equipment, and Cisco routers support this feature only on point-to-point serial links.

Cisco routers implement a hold-down timer with RIP. This is a protocol feature that is not described in the standard protocol RFCs. When the router marks a route invalid, it starts the hold-down timer, which is 180 seconds by default, and ignores all updates for this route. This helps to make the network somewhat more stable.

Because RIP uses a distance vector algorithm rather than a link state protocol (like OSPF), you can use Cisco’s distribute lists to make a router distribute only certain routes. This allows you to prevent distribution of routing information that you don’t want to be generally visible. And you can also reject incoming routing information that you don’t want to use. This can be extremely useful when exchanging routing information between networks, or when connecting small networks’ regions with legacy equipment.

6.1. Configuring RIP Version 1

Problem

You want to run RIP on a simple network.

Solution

The following commands show how to configure basic RIP functionality:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Ethernet0
Router2(config-if)#ip address 192.168.30.1 255.255.255.0
Router2(config-if)#interface Serial0.1
Router2(config-subif)#ip address 172.25.2.2 255.255.255.0
Router2(config-subif)#exit
Router2(config-router)#router rip
Router2(config-router)#network 172.25.0.0
Router2(config-router)#network 192.168.30.0
Router2(config-router)#end
Router2#

Discussion

You enable RIP for an interface by associating its IP address with a network. For example, the Serial0.1 interface in this example has an IP address of 172.25.2.2. So, if you want this interface to take part in RIP route distribution, you just need to include a network statement that includes its address:

Router2(config)#router rip
Router2(config-router)#network 172.25.0.0

If you have other interfaces that are also part of 172.25.0.0/16 on this router, they will take part in RIP as well. It’s important to note that RIP network statements work with classful network addresses. Since 172.25.0.0 is a Class B network, the statement network 172.25.0.0 tells the router to include all interfaces in this range. Note, however, that the other address on this router, 192.168.30.1, is part of the Class C network 192.168.30.0/24, which is why we need the second network command. If your router has several addresses that belong to different network classes (for example, 192.168.x.0/24), you have to specify them all separately:

Router2(config)#router rip
Router2(config-router)#network 192.168.1.0
Router2(config-router)#network 192.168.2.0
Router2(config-router)#network 192.168.3.0

It can be somewhat confusing to know which networks to specify. If your router receives a route from another router, it will pass it along to other routers whether you have specified a network statement for this address or not. However, the router will only distribute information about directly connected routes if there is a network statement for these routes. And the router will exchange RIP information only through interfaces specified by network statements.

The show ip protocol command gives a lot of useful information about what interfaces and address ranges are involved in the routing protocol:

Router2#show ip protocol
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 7 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
     Ethernet0             1     1 2
     Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:17
  Distance: (default is 120)

Router2#

As you can see from the output of this command, the router will send RIP Version 1 on both interfaces Ethernet0 and Serial0.1, but it will listen for both Versions 1 and 2. You can force the router to use only Version 1 to send and receive routing information for all interfaces with the following command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router rip
Router2(config-router)#version 1
Router2(config-router)#end
Router2#

However, it is usually better to restrict what you send rather than what you receive. That way, if another device is misconfigured to send the other version, it doesn’t break the network. We will discuss how to configure different RIP version options in Recipe 6.13.

Once you have RIP running successfully between two or more routers, you can look at your routing table to see which routes the router is learning and from where it is learning them:

Router2#show ip route rip
R    172.22.0.0/16 [120/1] via 172.25.2.1, 00:00:00, Serial0.1
R    172.25.1.0/24 [120/1] via 172.25.2.1, 00:00:00, Serial0.1
R    192.168.20.0/24 [120/2] via 172.25.2.1, 00:00:00, Serial0.1
Router2#

This command just gives a subset of the output of the more general show ip route command discussed in Chapter 5. The example output shows that the router has learned that it can get to the destination network 192.168.20.0/24 through the next-hop router, 172.25.2.1, which is on interface Serial0.1.

The numbers in the square brackets, [120/2], are the administrative distance and the RIP metric, respectively. Cisco routers give all RIP routes a default administrative distance of 120. The metric value of 2 indicates the distance to this network. By default, the metric is the same as the number of hops, but you can adjust metric values to break this rule. We discuss how to change metric values in Recipe 6.3, Recipe 6.4, Recipe 6.5, and Recipe 6.8, and we talk about administrative distances in Chapter 5.

Another useful command for looking at RIP functions on your router is the show ip rip database command, introduced in IOS 12.0(6)T:

Router2#show ip rip database
172.22.0.0/16    auto-summary
172.22.0.0/16
    [1] via 172.25.2.1, 00:00:13, Serial0.1
172.25.0.0/16    auto-summary
172.25.1.0/24
    [1] via 172.25.2.1, 00:00:13, Serial0.1
172.25.2.0/24    directly connected, Serial0.1
192.168.20.0/24    auto-summary
192.168.20.0/24
    [2] via 172.25.2.1, 00:00:13, Serial0.1
192.168.30.0/24    auto-summary
192.168.30.0/24    directly connected, Ethernet0
Router2#

This allows you to see more detailed information about each of the routes in the RIP database.

See Also

Recipe 6.3; Recipe 6.4; Recipe 6.5; Recipe 6.8; Recipe 6.13; Chapter 5

6.2. Filtering Routes with RIP

Problem

You want to restrict what routing information is exchanged within RIP.

Solution

You can filter inbound RIP routes on a per-interface basis with a distribute list:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#access-list 10 deny 192.168.20.0
Router2(config)#access-list 10 permit any
Router2(config)#router rip
Router2(config-router)#distribute-list 10 in Serial0.1
Router2(config-router)#network 172.25.0.0
Router2(config-router)#network 192.168.30.0
Router2(config-router)#end
Router2#

This configuration example shows how to filter outbound RIP-based routes on a per-interface basis:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 20 permit 0.0.0.0
Router1(config)#access-list 20 deny any
Router1(config)#router rip
Router1(config-router)#distribute-list 20 out Serial0/0.2
Router1(config-router)# network 172.25.0.0
Router1(config-router)#end
Router1#

Discussion

The access list in the first configuration example in this recipe prevents this router from accepting any routing information about the network 192.168.20.0. You can see that this route, which was visible in Recipe 6.1, no longer appears in the routing table:

Router2#show ip route rip
R    172.22.0.0/16 [120/1] via 172.25.2.1, 00:00:21, Serial0.1
R    172.25.1.0/24 [120/1] via 172.25.2.1, 00:00:21, Serial0.1
Router2#

The show ip protocol command shows which interfaces have inbound or outbound distribute lists:

Router2#show ip protocol
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 27 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
    Serial0.1 filtered by 10 (per-user), default is 10
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Loopback0             1     1 2
    Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:17
  Distance: (default is 120)

Router2#

This shows that the interface Serial0.1 uses access-list 10 to filter incoming routing information. You can then use the show access-list command to see what this affects.

If you control both the sending and receiving routers, it is usually best to filter the routes before sending them instead of sending them across the network and then ignoring them. So inbound filtering is most common in situations where you are receiving routes from a device that you don’t control. Since RIP frequently runs on end devices such as Unix servers, inbound filtering is fairly common.

You can use outbound filtering, on the other hand, for reducing the size of routing tables on access routers. For example, it is extremely useful in hub-and-spoke type WANs. In this case, each remote branch router cares only about its local segments and “everything else.” It can reach all of the non-local routes via the hub router, so you can reduce unnecessary WAN bandwidth utilization and memory consumption on the branch router by configuring the hub router to send out only a single default route. In fact, when used in conjunction with the non-periodic update feature discussed in Recipe 6.11, this makes a good WAN routing solution.

The second example in the solution section of this recipe shows the configuration of a hub router so that it sends only the default route, 0.0.0.0/0. The routing table of the other router then becomes extremely simple:

Router2#show ip route rip
R*   0.0.0.0/0 [120/5] via 172.25.2.1, 00:00:02, Serial0.1
Router2#

The show ip protocol command shows the filter on the hub router:

Router1#show ip protocol
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 9 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
    Serial0/0.2 filtered by 20 (per-user), default is 20
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0.1     1     1 2
    Serial0/0.2           1     1 2
    FastEthernet0/1       1     1 2
   Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:23
    172.25.2.2           120      00:00:07
    172.22.1.4           120      00:00:19
  Distance: (default is 120)

Router1#

You can also configure the router to filter all interfaces simultaneously with a single rule:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#access-list 10 deny 192.168.20.0
Router2(config)#access-list 10 permit any
Router2(config)#router rip
Router2(config-router)#distribute-list 10 in
Router2(config-router)#end
Router2#

This feature is rarely used, because you usually want apply different filters to different interfaces depending on what other devices are connected. But, when you want to explicitly eliminate certain unwanted routes from your network, regardless of where they originate, this is the easiest way to do it. With the show ip protocols command you can see that access list number 10 has been applied to traffic coming in from all interfaces:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 0 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is 10
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Loopback0             1     1 2
    Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:03
  Distance: (default is 120)

Router2#

It’s important to remember that while you can use global distribute lists together with interface-specific distribute lists, the result actually combines the effects of both. If you have a global distribute list that blocks a particular network, and an interface list that blocks another address, the router will block both addresses on that interface.

See Also

Recipe 6.11

6.3. Redistributing Static Routes into RIP

Problem

You want RIP to redistribute static routes that you have configured on your router.

Solution

The redistribute static command tells RIP to forward static routes in addition to the directly connected routes and the routes that have been learned from other RIP routers, which it forwards by default:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 192.168.10.0 255.255.255.0 172.22.1.4
Router1(config)#router rip
Router1(config-router)#redistribute static
Router1(config-router)#end
Router1#

You can define how these routes look to other routers when they are redistributed:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 192.168.10.0 255.255.255.0 172.22.1.4
Router1(config)#router rip
Router1(config-router)#redistribute static metric 5
Router1(config-router)#distribute-list 7 out static
Router1(config-router)#exit
Router1(config)#access-list 7 permit 192.168.10.0
Router1(config)#end
Router1#

Discussion

The biggest potential problem that you will encounter with redistributing routes into RIP comes from breaking network class boundaries. RIP is classful, so you have to be rather careful about how you distribute routing information from other sources that may be classless. In this recipe, Router1 redistributes a static route for the Class C network 192.168.10.0. But if we tried instead to redistribute a larger range (such as 192.168.12.0/22), RIP would not generate any errors—the router would just quietly refuse to forward this route.

Looking at the RIP database on a router with IOS level 12.0(6)T or higher shows the redistributed static route:

Router1#show ip rip database 192.168.10.0 255.255.255.0
192.168.10.0/24    redistributed
    [5] via 0.0.0.0,
Router1#

After configuring the second example, the output of show ip protocols includes information about the filtering. This command also tells you what protocols RIP is distributing:

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 5 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
    Redistributed static filtered by 7
  Incoming update filter list for all interfaces is not set
  Redistributing: static, rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0.1     2     2
    Serial0/0.2           2     2
    FastEthernet0/1       2     2
   Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:03
    172.25.2.2           120      00:00:06
    172.22.1.4           120      00:00:08
  Distance: (default is 120)
Router1#

In addition to static routes, you can distribute information from other dynamic routing protocols with RIP simply by specifying which protocol’s routes you want RIP to use. For example, if you have an EIGRP network that uses process number 65530 on the same router, you would redistribute the EIGRP routes into RIP like this:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router eigrp 65530
Router1(config-router)#network 192.168.1.0
Router1(config-router)#exit
Router1(config)#router rip
Router1(config-router)#redistribute eigrp 65530
Router1(config-router)#end
Router1#

If you look at the show ip protocols command, you can see that RIP redistributes routes it learns from EIGRP, but EIGRP does not redistribute routes learned from RIP. If you also want EIGRP to redistribute RIP routes, you must explicitly configure it to do so. We discuss EIGRP configuration and offer redistribution examples in Chapter 7.

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 0 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is
  Incoming update filter list for all interfaces is
  Redistributing: static, rip, eigrp 65530


  Default version control: send version 1, receive any version
    Interface        Send  Recv   Key-chain
    FastEthernet0/0.1     2     2
    Serial0/0.2           2     2
    FastEthernet0/1       2     2
   Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:03
    172.25.2.2           120      00:00:06
    172.22.1.4           120      00:00:08
  Distance: (default is 120)

Routing Protocol is "eigrp 65530"
  Outgoing update filter list for all interfaces is
  Incoming update filter list for all interfaces is
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 65530
  Automatic network summarization is in effect
  Routing for Networks:
    192.168.1.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

Router1#

Table 6-1 shows a list of foreign protocols that RIP can redistribute.

Table 6-1. Protocols that RIP can redistribute

Type

Description

BGP

Border Gateway Protocol

Connected

Connect interfaces

EGP

Exterior Gateway Protocol

EIGRP

Enhanced IGRP

IGRP

Interior Gateway Routing Protocol

ISI

ISO IS-IS Routing Protocol

Mobile

Mobile routes

OSPF

Open Shortest Path First

RIP

Routing Information Protocol

Static

Static routes

See Also

Recipe 6.4; Chapter 7

6.4. Redistributing Routes Using Route Maps

Problem

You want to use route maps for more detailed control over how RIP redistributes routing information from other sources.

Solution

Route maps give you much better control over how RIP redistributes external routes. This example uses static routes, but the same principles apply when redistributing routes from other protocols:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 192.168.10.0 255.255.255.0 172.22.1.4
Router1(config)#ip route 192.168.11.0 255.255.255.0 172.22.1.4
Router1(config)#ip route 192.168.12.0 255.255.255.0 172.22.1.4
Router1(config)#access-list 20 permit 192.168.10.0
Router1(config)#access-list 21 permit 192.168.11.0
Router1(config)#route-map STATIC permit 10
Router1(config-route-map)# match ip address 20
Router1(config-route-map)# set metric 2
Router1(config-route-map)# set tag 2
Router1(config-route-map)#!
Router1(config-route-map)#route-map STATIC permit 20
Router1(config-route-map)# match ip address 21
Router1(config-route-map)# set metric 8
Router1(config-route-map)#!
Router1(config-route-map)#route-map STATIC deny 30
Router1(config-route-map)#exit
Router1(config)#router rip
Router1(config-router)#redistribute static route-map STATIC
Router1(config-router)#end
Router1#

Discussion

In this example, we want RIP to distinguish between the different routes. There are two parameters that we can change, the metric and the route tag. We have already discussed metrics, which basically represent the distance or cost of the path to the remote network. A route tag is simply an arbitrary number that RIP will attach to a particular route. RIP doesn’t actually use these tag values, but as we discuss in Recipe 6.16, RIP Version 2 will distribute them with the routing table so that you can use this information when distributing these routes into other routing protocols.

The route map in this recipe has three clauses. The first assigns a metric of 2 and a tag of 2 to the network 192.168.10.0. Then it gives a metric of 8 to 192.168.11.0. The last clause discards all other routes. This is different from Recipe 6.3, in which all routes were redistributed with the same metric.

This kind of redistribution can be useful when you want to control how traffic load is balanced between two links. For example, if you have two routers that both connect to the same set of remote networks, you could balance them so that one router has a better metric for half of the routes, and the other has a better metric for the rest of the routes. In this way you can ensure that both links are used equally, and if one router fails, the other will take over for it.

It is often easier to understand route maps by looking at the show route-map command, rather than the configuration commands. In this case, for example, you can see exactly what access lists apply to each clause, along with all of the values that are set as a result. This output also shows how many times each policy has been applied:

Router1#show route-map STATIC
route-map STATIC, permit, sequence 10
  Match clauses:
    ip address (access-lists): 20
  Set clauses:
    metric 2
    tag 2
  Policy routing matches: 0 packets, 0 bytes
route-map STATIC, permit, sequence 20
  Match clauses:
    ip address (access-lists): 21
  Set clauses:
    metric 8
   Policy routing matches: 0 packets, 0 bytes
route-map STATIC, deny, sequence 30
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
Router1#

Looking at the RIP database, you can see the metrics that RIP uses for distributing each of these static routes:

Router1#show ip rip database
192.168.10.0/24    auto-summary
192.168.10.0/24    redistributed
    [2] via 0.0.0.0,
192.168.11.0/24    auto-summary
192.168.11.0/24    redistributed
    [8] via 0.0.0.0,
Router1#

You can also use the route map technique for distributing routes from dynamic routing protocols. For example, if you had another route map called EIGRPMAP that you wanted to use when redistributing routes learned through EIGRP process number 65530, you could configure the router like this:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router eigrp 65530
Router1(config-router)#network 192.168.1.0
Router1(config-router)#exit
Router1(config)#router rip
Router1(config-router)#redistribute eigrp 65530
 route-map EIGRPMAP
Router1(config-router)#end
Router1#

See Also

Recipe 6.3; Recipe 6.16

6.5. Creating a Default Route in RIP

Problem

You want RIP to propagate a default route.

Solution

There are two ways to get RIP to propagate a default route. The preferred method is to use the default-information originate command as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.25.1.1
Router1(config)#router rip
Router1(config-router)#default-information originate
Router1(config-router)#end
Router1#

In simple situations, you can accomplish the same thing by just redistributing a static route:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.25.1.1
Router1(config)#access-list 7 permit 0.0.0.0
Router1(config)#router rip
Router1(config-router)#redistribute static
Router1(config-router)#distribute-list 7 out static
Router1(config-router)#end
Router1#

Discussion

There are two main advantages to using default originate instead of simply redistributing static routes. The first is that you may have other static routes on your router that you do not want to distribute, or that you want to distribute with a different default metric. In this case, if you just use redistribute static, you will need to filter out the unwanted routes using route maps, as shown in Recipe 6.4.

The other important advantage is that the default originate option lets you create a conditional default route. This means that you can configure the router to create and distribute a default route only if some other route is present. Usually this other route points to a distant network. If the route is present, it indicates that the router is able to see enough of the outside world to be a reliable default router:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 20 permit 192.168.55.0
Router1(config)#route-map DEFAULTROUTE permit 10
Router1(config-route-map)#match ip address 20
Router1(config-route-map)#exit
Router1(config)#router rip
Router1(config-router)#default-information originate route-map DEFAULTROUTE
Router1(config-router)#end
Router1#

In this example, if the distant network 192.168.55.0 is present in the routing table, RIP will generate and distribute a default route. Usually you would use this type of configuration on the RIP router that forms a gateway to another network.

You can see how RIP distributes the default route with the show ip rip database command:

Router1#show ip rip database 0.0.0.0 0.0.0.0
0.0.0.0/0    redistributed
    [1] via 0.0.0.0,
Router1#

See Also

Recipe 6.4

6.6. Disabling RIP on an Interface

Problem

You want to prevent an interface from participating in RIP.

Solution

You can prevent an interface from participating in RIP with the following set of commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 12 deny any
Router1(config)#router rip
Router1(config-router)#passive-interface FastEthernet0/1
Router1(config-router)#distribute-list 12 in FastEthernet0/1
Router1(config-router)#end
Router1#

Discussion

As we discussed in Recipe 6.1, you enable RIP on an interface with a network command. But, because RIP expects any networks you specify this way to follow address class rules, it is quite easy to inadvertently enable RIP on an interface that you don’t want to use this protocol.

There are two important reasons that might lead you to disable RIP on a particular interface. First, if you are already running another protocol on a particular interface, the additional RIP traffic could consume important bandwidth resources. Second, there may be devices on a particular network segment that you do not trust. In this case, you want to make sure that you don’t let untrusted equipment distribute routing information into your network. This is particularly important because some Unix workstations run RIP by default, but the administrators rarely devote much attention to making sure that any local static routes have the correct metric values. It is possible for one misconfigured workstation to completely disrupt routing for an entire network.

This recipe does two things to disable RIP. First, the passive-interface command tells RIP not to send any routing information out through the specified interface. But this does not prevent the router from listening for incoming routes. So we have also applied an inbound distribute-list command to the interface to prevent RIP from learning any routes this way.

To demonstrate this, we have applied the passive interface command, but not the distribute-list command:

Router1#show ip route rip
R    192.168.30.0/24 [120/1] via 172.25.2.2, 00:00:09, Serial0/0.2
     172.25.0.0/16 is variably subnetted, 6 subnets, 3 masks
R       172.25.25.2/32 [120/1] via 172.25.2.2, 00:00:09, Serial0/0.2
R    192.168.20.0/24 [120/1] via 172.22.1.4, 00:00:08, FastEthernet0/1
Router1#

As you can see, the router is still learning routes through the FastEthernet0/1 port. A debug trace proves that although the router doesn’t send any routing information out through this interface, it does receive information this way:

Router1#debug ip rip
RIP protocol debugging is on
Aug 11 02:35:33.403: RIP: sending v1 flash update to 255.255.255.255 via
FastEthernet0/0.1
Aug 11 02:35:33.403: RIP: build flash update entries
Aug 11 02:35:33.403:    subnet 0.0.0.0 metric 16
Aug 11 02:35:33.403: RIP: sending v1 flash update to 255.255.255.255 via Serial0/0.2
Aug 11 02:35:33.403: RIP: build flash update entries
Aug 11 02:35:33.403:    subnet 0.0.0.0 metric 1
Aug 11 02:35:33.403:    network 172.21.0.0 metric 1
Aug 11 02:35:39.012: RIP: received v1 update from 172.22.1.4 on FastEthernet0/1
Aug 11 02:35:39.012:      192.168.20.0 in 1 hops

When we add the distribute-list command inbound on the FastEthernet0/1 interface, the unwanted route disappears from the routing table:

Router1#show ip route rip
R    192.168.30.0/24 [120/1] via 172.25.2.2, 00:00:04, Serial0/0.2
     172.25.0.0/16 is variably subnetted, 5 subnets, 2 masks
R       172.25.25.2/32 [120/1] via 172.25.2.2, 00:00:04, Serial0/0.2
Router1#

You can see the effects of both commands in the output of the show ip protocols command:

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 13 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
    FastEthernet0/1 filtered by 12 (per-user), default is 12
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0.1     1     1 2
    Serial0/0.2           1     1 2
   Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Passive Interface(s):
    FastEthernet0/1
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:08
    172.25.2.2           120      00:00:00
 Distance: (default is 120)

Router1#

Note that you could apply an inbound access list to an interface to prevent the router from receiving RIP updates from other devices. To do this, simply apply a filter to block UDP port 520. However, as we discuss in Chapter 19, you cannot use access control lists to filter outbound router packets that originate on the router. In any case, that method forces the router to look at every incoming packet. This can cause serious CPU problems on fast links. It is far more efficient to just let the RIP process do the filtering, as we have shown in this recipe.

Similarly, it is more efficient to use the passive interface command to prevent the router from sending routes out through an interface, rather than using an outbound distribute list that merely blocks all routes. This is because, with the passive interface command, the router doesn’t have to compare the routes it wants to send to an access list to decide whether to send them. Instead, it just knows not to send any routes.

See Also

Recipe 6.2

6.7. Unicast Updates for RIP

Problem

You want to exchange routing information with one device on a network, but not with any others.

Solution

You can configure RIP to send its updates to a neighboring router using unicast instead of broadcast or multicast packets. This is useful in two situations. First, on Non-Broadcast Multiple Access (NBMA) networks, you can’t use the standard broadcast or multicast methods for distributing information because the media doesn’t support it. And second, sometimes you need to exchange routing information with one or more specific devices on a segment, but you don’t trust the rest to give you reliable information. This feature is rarely used, but it can be extremely valuable in these types of situations:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router rip
Router1(config-router)#passive-interface FastEthernet0/1
Router1(config-router)#neighbor 172.22.1.4
Router1(config-router)#end
Router1#

Discussion

This recipe uses the passive-interface command discussed in Recipe to prevent the router from sending routing information to the interface in general. Note that it does not prevent the router from receiving routing information from other devices on the segment. We will discuss how to solve that problem in a moment.

A debug trace helps to show how the unicast update option works:

Router1#debug ip rip
RIP protocol debugging is on
Router1#
Aug 11 02:41:13.632: RIP: sending v1 update to 255.255.255.255 via FastEthernet0/0.1
(172.25.1.5)
Aug 11 02:41:13.636: RIP: sending v1 update to 255.255.255.255 via Serial0/0.2 (172.
25.2.1)
Aug 11 02:41:13.644: RIP: sending v1 update to 172.22.1.4 via FastEthernet0/1 (172.
22.1.3)

Here you can see that this router sends its updates to the general broadcast address (255.255.255.255) for all of the other interfaces, but for FastEthernet0/1, the update goes directly to 172.22.1.4. This example uses RIP Version 1. If it used Version 2, updates would be sent using the multicast address 224.0.0.9, instead of the general segment broadcast address. However, the unicast option for Version 2 would work exactly the same as shown here.

The output of the show ip protocols command includes information about any uni-cast neighbors:

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 21 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Neighbor(s):
    172.22.1.4
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0.1     1     1 2
    Serial0/0.2           1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Passive Interface(s):
    FastEthernet0/1
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:26
    172.25.2.2           120      00:00:14
    172.22.1.4           120      00:00:07
  Distance: (default is 120)

Router1#

As we noted in Recipe 6.6, just making an interface passive does not prevent it from listening for updates. However, one of the most common reasons for using unicast neighbors with RIP is to ensure that the router accepts routing information only from specific devices on a segment. To do this, we need to configure the router to reject incoming RIP information from all other devices by applying an access list to the interface:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 101 permit udp host 172.22.1.4 any eq rip
Router1(config)#access-list 101 deny udp any any eq rip
Router1(config)#access-list 101 permit ip any any
Router1(config)#interface FastEthernet0/1
Router1(config-if)#ip access-group 101 in
Router1(config-if)#end
Router1#

See Also

Recipe 6.6

6.8. Applying Offsets to Routes

Problem

You want to modify the routing metrics for routes learned from or distributed into RIP.

Solution

You can modify the RIP metrics for a list of routes learned through a particular interface with the offset-list configuration command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#access-list 22 permit 192.168.20.0
Router2(config)#router rip
Router2(config-router)#offset-list 22 in 5 Serial0.1
Router2(config-router)#end
Router2#

A similar command changes the metrics for a list of routes as they are sent out through a specified interface:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#access-list 33 permit 192.168.30.0
Router2(config)#router rip
Router2(config-router)#offset-list 33 out 10 Serial0.1
Router2(config-router)#end
Router2#

Discussion

The offset-list command is most useful when you need RIP to distinguish between the costs of different links. By default, RIP looks only at the number of hops to the destination. But sometimes the longer path is significantly faster. For example, you might have a primary link that uses a T1 to get to a router in another building, and an Ethernet segment to get from there to another router that connects to a server. It’s obviously better to take this primary link rather than a backup 56Kbps circuit that happens to connect directly to the last-hop router.

Other routing protocols (such as OSPF) address this problem by assigning a cost to each link and adding up the costs to find the best path. But RIP has only a metric. So, if you want to ensure that one path is preferred over another shorter one, you have to modify the metrics.

Cisco routers give considerable flexibility in changing metrics by adding an offset. This allows you to change each route independently as it is received or sent. You can even affect routes according to which interface the router receives them through. Be extremely careful because you can only increase a metric, never decrease it, and the maximum metric value is only 16. When the metric reaches a value of 16, RIP considers the network to be unreachable.

Sometimes you want to ensure that a particular path is never used to reach a certain destination. In this case, you can apply an offset of 16, and the router will have to find a different path. The router will also allow you to apply an offset of 0, but this has no effect.

The show ip protocols command lists all of the offsets that are configured, including information about the access lists, interfaces, and the sizes of the offsets that will be applied:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 25 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Outgoing routes in Serial0.1 will have 10 added to metric if on list 33
  Incoming routes in Serial0.1 will have 5 added to metric if on list 22
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Loopback0             1     1 2
    Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:12
  Distance: (default is 120)
Router2#

A debug trace shows the incoming and outgoing routes. Note that the trace always shows the metric values after applying the offset for both inbound and outbound updates:

Router2#debug ip rip
RIP protocol debugging is on
Aug 10 23:24:36: RIP: sending v1 update to 255.255.255.255 via Serial0.1
Aug 10 23:24:36: RIP: build update entries
Aug 10 23:24:36:        subnet 172.25.25.2 metric 1
Aug 10 23:24:36:        network 192.168.30.0 metric 11
Aug 10 23:24:48: RIP: received v1 update from 172.25.2.1 on Serial0.1
Aug 10 23:24:48:      0.0.0.0 in 1 hops
Aug 10 23:24:48:      172.22.0.0 in 1 hops
Aug 10 23:24:48:      172.25.1.0 in 1 hops
Aug 10 23:24:48:      192.168.20.0 in 7 hops
Router2#

6.9. Adjusting Timers

Problem

You want to tune your routing protocol performance to decrease the amount of time that the network takes to converge after a topology change.

Solution

RIP has several timers that control how often it sends updates, how long it takes to remove a bad route, etc. You can adjust these values with the timers basic configuration command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router rip
Router2(config-router)#timers basic 20 80 80 120
Router2(config-router)#end
Router2#

Discussion

The timers basic command controls all of the adjustable timers for RIP:

Router2(config-router)#timers basic 20 80 80 120

The four arguments are, in order: the update period, the invalid route timer, the hold-down timer, and the flush timer. All of these times are in seconds.

The update period controls how often the router sends updates to its neighbors. The default update period is 30 seconds. Reducing this period can help to improve convergence times. However, you have to remember that RIP sends the entire routing table in each update cycle. If the routing table is large, reducing this period too much can cause serious bandwidth loading problems on slower links.

The invalid route timer controls how long the router will wait before declaring a particular route invalid. If the route disappears from the routing updates received from neighboring routers for this length of time, the router will mark it invalid. The router will set the RIP metric for invalid routes to 16, or unreachable, when distributing them. It is important to remember that the router doesn’t remove invalid routes from its own routing table and will continue to distribute them to other routers.

The default invalid route timer value is 180 seconds. Most references advise making this value at least three times the update period. Shorter invalid route timers can cause instability problems. But if you make it too much longer, the network won’t respond well to topology changes.

The hold-down timer for a particular route starts when the router gets a routing update saying that the route is inaccessible. This could happen, for example, if another router’s invalid route timer for this route has expired. It can also happen as a result of a triggered update indicating that a particular interface pointing to this network has gone down.

The router will keep the unreachable route in its table and distribute it to other routers with an unreachable metric. After the hold-down timer expires, the router will delete the unreachable route and start to accept other routing information for this route.

The default hold-down period is 180 seconds. It is usually a good idea to keep the hold-down time the same as the invalid route timer to help ensure network stability.

The final parameter is the flush timer. This controls how long the router will keep a route in its routing table before purging it. The default flush period is 240 seconds. It must be greater than the hold-down time, otherwise routes can be flushed before the hold-down timer expires, which makes the hold-down time meaningless.

We recommend using extreme caution when adjusting RIP timers. The timers on every router in a RIP network must be equal or you will see terrible instability problems. Note that the RIP timers affect the entire RIP process, meaning that you can’t set the timer values separately for different neighbors or interfaces. It isn’t possible to slow down the update timers over a slow WAN link and make them shorter over a faster LAN link.

In this example, we wanted to make RIP converge faster after topology changes, so we decreased all of the timers:

Router2(config-router)#timers basic 20 80 80 120

The net result is that we have reduced the time to flush a bad route to two minutes from the default value of four. But it is important to notice that we had to decrease all of the timers to achieve this result without compromising overall network stability.

As we mentioned earlier, routers will send the entire routing table on every update cycle, so making the timers too short can cause congestion problems on slower links. However, you can get away with shorter update periods if you use route summarization or filtering, as shown in Recipe 6.15. You can also decrease bandwidth consumption while improving convergence times by configuring the routers to only send updates when there are changes, as in Recipe 6.11.

Usually people are interested in reducing these timers to improve convergence times. We don’t recommend increasing them from the default values, because it will make the network respond too slowly to topology changes. If you have a problem with older or slower routers that are unable to receive RIP updates as quickly as they are sent, a better solution is to adjust the interpacket delay, as shown in Recipe 6.10.

You can view the values for all of the configured RIP timers with the show ip protocols command:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 20 seconds, next due in 8 seconds
  Invalid after 80 seconds, hold down 80, flushed after 120
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
    Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:14
  Distance: (default is 120)
Router2#

See Also

Recipe 6.10; Recipe 6.11; Recipe 6.15

6.10. Configuring Interpacket Delay

Problem

You want to slow down the rate at which a router sends the packets in a single update to ensure that slower devices aren’t overwhelmed, resulting in a loss of data.

Solution

Use the output-delay configuration command to adjust the interpacket delay of the RIP protocol:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router rip
Router2(config-router)#output-delay 10
Router2(config-router)#end
Router2#

Discussion

If the routing table distributed in each update is small, it will fit into a single packet. But the maximum size for a RIP update packet is 512 bytes. Each packet has an 8-byte UDP header, and 4 bytes of general RIP information. The remaining 500 bytes of the packet carry the actual routes. Each individual route takes 20 bytes, so there can be at most 25 routes in one packet. If you have more than 25 routes in your routing table, RIP must send it as multiple packets.

The problem with this is that some devices can’t process large amounts of incoming routing information quickly, and they wind up missing some of the routing information. This is particularly true for older legacy equipment and routers with slow processors or insufficient memory. If you find that one or more of the neighboring routers has a mysteriously incomplete routing table, it might help to increase the interpacket spacing. The other reason for increasing the output delay is to prevent bursts of RIP traffic from causing network congestion.

For example, in Frame Relay networks, if you burst above the Committed Information Rate (CIR), the extra packets may be marked as Discard Eligible (DE), which means that they might get dropped. This can cause serious problems, but spreading out this burst of RIP traffic might prevent them from occurring.

The output-delay command allows you to specify the interpacket delay in milliseconds. The default is 0, meaning that the router will send packets as fast as it can. You can specify any delay value between 8 and 50 milliseconds with this command. It is not necessary to specify a corresponding delay on neighboring routers.

The output of the show ip protocols command includes the output interpacket delay if you configure any non-default value:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 60 seconds, next due in 17 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Output delay 10 milliseconds between packets
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Serial0.1             1     1 2
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      00:00:23
  Distance: (default is 120)
Router2#

See Also

Chapter 10

6.11. Enabling Triggered Updates

Problem

You want to reduce RIP bandwidth requirements by configuring routers to forward only changes made to the routing table instead of forwarding the entire routing table.

Solution

The ip rip triggered interface configuration command tells the router to only send those parts of the RIP database that have changed, instead of the entire database on each RIP update cycle:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.2
Router1(config-subif)#ip rip triggered
Router1(config-subif)#end
Router1#

Be sure to enable triggered updates on the adjacent router as well:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Serial0.1
Router2(config-subif)#ip rip triggered
Router2(config-subif)#end
Router2#

Note

You must enable this feature on both of the routers sharing the point-to-point link, or you risk losing all routing information.

Discussion

This feature is based on RFC 2091, although it doesn’t implement all of the features described in that RFC (in particular, RFC 2091 includes extensions to the Novell IPX RIP and SAP update process that Cisco does not implement). You can use it with both RIP Versions 1 and 2. It became available starting in IOS Version 12.0(1)T.

Triggered updates are available only for point-to-point serial interfaces. They are particularly useful for slower serial WAN links where bandwidth is an issue. This feature is also used with dial-on-demand interfaces where it can save money by eliminating periodic RIP updates that would keep the link unnecessarily active.

When you enable this feature on an interface, the router will send routing updates only in a few well-defined situations. It will send a full copy of the database when it is first powered on to ensure that there is at least one update. The router will also send a full copy of the database if the neighboring router requests it. If the triggered interface itself goes up or down, the router will send a partial database to update the neighboring router on the changes since it last connected. And, in a relatively stable network, it will only send updates indicating incremental changes to the RIP database.

In a stable network, if there are no changes to the routing table, there are no updates. You can see the time since the last update with the show ip protocols command. In this case, from a very stable network, over 12 hours have elapsed since the last update:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 60 seconds, next due in 52 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             1     1 2
    Serial0.1             1     1 2        Yes
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      12:08:06
  Distance: (default is 120)
Router2#

If you combine this feature with route filtering and summarization (as discussed in Recipe 6.2 and Recipe 6.15), you can hide any instability that might exist elsewhere in the network. This is particularly useful for dialup links when you don’t want to dial just because of a topology change elsewhere in the network.

The show ip rip database command marks routes learned via triggered interfaces as permanent:

Router2#show ip rip database 192.168.20.0 255.255.255.0
192.168.20.0/24
    [7] via 172.25.2.1, 00:02:43 (permanent), Serial0.1
   * Triggered Routes:
     - [7] via 172.25.2.1, Serial0.1
Router2#

The terminology is slightly confusing because this route is clearly not permanent in the same way as a static route. But it is not like normal RIP database entries, which are subject to the hold-down and flush timers. This is why the route is marked this way.

The following debug trace shows a triggered update for a route that became inaccessible. We ran this debug for 20 minutes, and this was the only event it recorded:

Aug 11 13:18:25: RIP: received v1 triggered update from 172.25.2.1 on Serial0.1
Aug 11 13:18:25: RIP: sending v1 ack to 172.25.2.1 via Serial0.1, seq# 15
Aug 11 13:18:25:      192.168.20.0 in 16 hops (inaccessible)

See Also

Recipe 6.2; Recipe 6.15

6.12. Increasing the RIP Input Queue

Problem

You want to increase the size of the RIP input queue to prevent your low-speed router from losing routing information.

Solution

To increase the size of the shared RIP queue, use the input-queue configuration command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router rip
Router2(config-router)#input-queue 200
Router2(config-router)#end
Router2#

Discussion

This command allows you to control how much incoming RIP update information the router can hold while it processes and integrates this information into its routing table. Sometimes a router simply can’t keep up with all of the information that it receives. This is most likely to be the case for less powerful routers on a busy network with many routes.

Bear in mind that each RIP update packet can hold up to 25 routes, and the default queue size is more than adequate to hold this many routes. The input queue size is likely to be a problem only if you have many times this number of routes, or if you have many routers all sharing the same segment. If this is the case, and you find that a less powerful router is randomly losing routes from its table, it is relatively safe and easy to increase this queue depth.

The default value is 50. Here we have increased the queue depth to 200, which is a good starting point if you think that you have a queue depth problem. You can set this value to anything from 0 to 1024, although it is not clear why you would want to decrease the queue depth.

Recipe 6.10 shows another solution to this same problem. Instead of increasing the queue size on the slower router, you may opt to change the interpacket delay on the faster routers. And, in some cases, it may be necessary to combine both of these solutions.

See Also

Recipe 6.10

6.13. Configuring RIP Version 2

Problem

You want to use the more flexible features of RIP Version 2.

Solution

By default, Cisco routers will listen for both RIP Version 1 and 2 packets, but they will only send Version 1. If you want to configure the router to send and receive only Version 2 RIP packets, use the version 2 configuration command:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router rip
Router2(config-router)#version 2
Router2(config-router)#network 172.25.0.0
Router2(config-router)#network 192.168.30.0
Router2(config-router)#end
Router2#

You can also enable RIP Version 2 sending and receiving separately for individual interfaces:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.2
Router1(config-subif)#ip rip send version 2
Router1(config-subif)#ip rip receive version 2
Router1(config-subif)#end
Router1#

Discussion

By default, the router will listen for Version 1 and 2 packets but it will only send Version 1. You can run both versions simultaneously on the same interface. However, the router will then have to transmit all updates using both versions, which can cause an unnecessary burden both for the router and the network. In general, RIP Version 2 is preferred, particularly because of the support for modern IP features such as variable-length subnet masks:

Router2#show ip protocols
Routing Protocol is "rip"
  Sending updates every 60 seconds, next due in 19 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Output delay 10 milliseconds between packets
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
    Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    Ethernet0             2     2
    Serial0.1             2     2          Yes
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.25.0.0
    192.168.30.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.1           120      01:04:31
  Distance: (default is 120)
Router2#

This command shows that the router is sending and receiving only Version 2 on both interfaces. In this case, the router will reject any incoming RIP Version 1 packets on either of these ports. So you need to make sure that the neighboring routers on these interfaces are also running Version 2.

The second configuration example leaves the default configuration for all of the interfaces except Serial0/0.2, which sends and receives only RIP Version 2:

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 11 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: static, rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    Serial0/0.2           2     2          Yes
    FastEthernet0/1       1     1 2
   Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.2.2           120      14:40:28
    172.22.1.4           120      01:06:11
  Distance: (default is 120)
Router1#

Debug traces show which version the router sends and receives for every update:

Router2#debug ip rip
RIP protocol debugging is on
Router2#
Aug 11 14:38:54: RIP: received v2 update from 172.25.2.1 on Serial0.1
Aug 11 14:38:54:      0.0.0.0/0 via 0.0.0.0 in 1 hops
Aug 11 14:38:54:      172.22.0.0/16 via 0.0.0.0 in 1 hops
Aug 11 14:38:54:      172.25.0.0/16 via 0.0.0.0 in 1 hops
Aug 11 14:38:54:      172.25.1.0/24 via 0.0.0.0 in 1 hops
Aug 11 14:38:54:      172.25.25.1/32 via 0.0.0.0 in 1 hops
Aug 11 14:38:57: RIP: sending v2 update to 224.0.0.9 via Serial0.1
Aug 11 14:38:57: RIP: build update entries
Aug 11 14:38:57:        172.25.25.2/32 via 0.0.0.0, metric 1, tag 0
Aug 11 14:38:57:        192.168.30.0/24 via 0.0.0.0, metric 11, tag 0
Router2#

If you configure a router to listen only for one version, however, it will just drop any packets of the other version that it receives:

Router2#debug ip rip
RIP protocol debugging is on
Router2#
Aug 11 14:43:11: RIP: ignored v1 packet from 172.25.2.1 (illegal version)
Aug 11 14:43:11: RIP: received v2 update from 172.25.2.1 on Serial0.1

6.14. Enabling RIP Authentication

Problem

You want to authenticate your RIP traffic to ensure that unauthorized equipment cannot affect how traffic is routed through your network.

Solution

The following set of commands enables plain-text RIP authentication:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#key chain ORA
Router1(config-keychain)#key 1
Router1(config-keychain-key)#key-string oreilly
Router1(config-keychain-key)#exit
Router1(config-keychain)#exit
Router1(config)#interface FastEthernet0/0.1
Router1(config-subif)#ip rip authentication key-chain ORA
Router1(config-subif)#ip rip authentication mode text
Router1(config-subif)#end
Router1#

For greater security, Cisco routers can also use MD5-based authentication:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#key chain ORA
Router1(config-keychain)#key 1
Router1(config-keychain-key)#key-string oreilly
Router1(config-keychain-key)#exit
Router1(config-keychain)#exit
Router1(config)#interface FastEthernet0/0.1
Router1(config-subif)#ip rip authentication key-chain ORA
Router1(config-subif)#ip rip authentication mode md5
Router1(config-subif)#end
Router1#

Discussion

RIP authentication is one of the protocol enhancements that appeared in Version 2 of the protocol.

The first configuration example in this recipe uses plain-text authentication. In general, we recommend using the MD5 authentication because the plain-text version is far too easy to break. If you want to set up authentication to ensure that you receive updates only from the appropriate devices, you should use the safer MD5 version. The only reason to consider the less secure plain-text version is if some of the RIP devices cannot support MD5. Because the RFC for RIP Version 2 only describes plain-text authentication, non-Cisco devices may not support MD5 authentication.

Both forms of RIP authentication help to ensure that only legitimate network equipment is allowed to take part in RIP updates. This is particularly important if you have network segments containing foreign devices that may corrupt the routing tables. This could happen because of malice, but it’s also relatively easy for a miscon-figured Unix workstation running the routed program to cause serious global routing problems.

When you enable plain-text authentication, the first route field in each update packet contains the authentication string instead of a route. This implies that each update packet can then hold a maximum of 24 route entries. Because the MD5 authentication scheme carries more information, it uses the first and last route fields in each update packet. So this leaves a maximum of 23 route entries per update packet.

In this example, the key is applied to an interface. This allows you to specify a different key for each network segment. However, there is nothing to stop you from using the same key on more than one interface, or even using a single key throughout the network.

The following debug traces were taken with authentication enabled. The first trace shows plain-text authentication and includes the password:

Router1#debug ip rip
RIP protocol debugging is on
Aug 12 02:08:03.386: RIP: received packet with text authentication oreilly
Aug 12 02:08:03.390: RIP: received v2 update from 172.25.1.7 on FastEthernet0/0.1

The second trace shows an update containing MD5 authentication. In this case, the router is not able to decode the authentication string. Instead, it compares the encrypted password string with the encrypted version of its own password to see if they match. There are no known methods to uniquely reverse MD5 encryption:

Router3#debug ip rip
RIP protocol debugging is on
Aug 11 22:14:50 EDT: RIP: received packet with MD5 authentication
Aug 11 22:14:50 EDT: RIP: received v2 update from 172.25.1.5 on Ethernet0

The show ip protocols command includes information about the authentication key chains:

Router3#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 16 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Outgoing update filter list for all interfaces is
  Incoming update filter list for all interfaces is
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface        Send  Recv   Key-chain
    Ethernet0        2     2      ORA
  Routing for Networks:
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.5           120      00:00:01
  Distance: (default is 120)
Router3#

If the router receives a RIP update that has an incorrect key (or no key at all), it will discard the packet, as shown in the following debug trace:

Router3#debug ip rip
RIP protocol debugging is on
Aug 11 22:17:07 EDT: RIP: ignored v2 packet from 172.25.1.5 (invalid authentication)

We will discuss key management schemes such as setting key lifetimes and using multiple keys when we look at EIGRP authentication in Chapter 7. The key management systems are identical in both cases.

See Also

Chapter 7

6.15. RIP Route Summarization

Problem

You want to decrease the size of your routing tables to improve the stability and efficiency of the routing process.

Solution

You can manually configure address summarization on an individual interface with the ip summary-address rip configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.2
Router1(config-subif)#ip summary-address rip 172.25.0.0 255.255.0.0
Router1(config-subif)#end
Router1#

By default, RIP Version 2 will summarize groups of subnets into classful network routes. You can disable this automatic summarization with the no auto-summary configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router rip
Router1(config-router)#no auto-summary
Router1(config-router)#end
Router1#

Discussion

RIP Version 2 automatically summarizes along classful network boundaries. If your router sees that several subnets of the same network all use the same path, and that there are no subnets of this network using a different path, it automatically summarizes this information. The routes to the individual subnets are also suppressed. Any devices downstream from this router will see only a summary route (such as 172.25.0. 0/16) instead of all of the individual subnets (such as 172.25.1.0/24, 172.25.2.16/28, and so forth).

The downstream devices don’t need to know that they are seeing summary routes instead of the actual individual routes, so summarizing works well even with legacy equipment.

However the auto-summary feature only works along classful network boundaries. For example, it will not summarize a group of networks such as 192.168.16.0/24, through 192.168.31.0/24 into 192.168.16.0/20 because they are all separate Class C networks. RIP cannot advertise such supernets because they are not classful.

The interface-specific summarization command became available in IOS Version 12.0(6)T. Configuring summary address on an interface tells the router to send summary information out through a specific interface. All routers that are downstream from the configured interface will see only the summary route and none of the constituent subnet routes. As long as any one of these subnet routes are valid, the router will propagate the summary information. But, when the last subnet that is part of the summarized range disappears, the router will stop sending the summary route through the configured interface.

You cannot configure more than one summary address from the same classful network address on an interface. For example, the following is invalid because both of the summary addresses are subnets of 172.25.0.0/16:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.2
Router1(config-subif)#ip summary-address rip 172.25.16.0 255.255.240.0
Router1(config-subif)#ip summary-address rip 172.25.35.0 255.255.255.0
IP-RIP:No summary for 172.25.35.0/24.Summary 172.25.16.0/20 already on interface
Router1(config-subif)#end
Router1#

However, either of these summarizations would be fine on its own. You can configure several different summary addresses, as long as they are for different networks:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/0.2
Router1(config-subif)#ip summary-address rip 172.25.16.0 255.255.240.0
Router1(config-subif)#ip summary-address rip 172.26.35.0 255.255.255.0
Router1(config-subif)#ip summary-address rip 10.101.0.0 255.255.0.0
Router1(config-subif)#end
Router1#

Route summarization has two important advantages. First, it reduces the size and complexity of the routing table, which in turn reduces the amount of memory and processing required on the downstream routers. Second, because all information about the individual subnets is suppressed, the downstream routers will not know or care about flapping interfaces in another part of the network. These two factors combine to improve overall network stability.

Suppose you have a routing table that looks like this before summarization:

Router2#show ip route rip
R    172.21.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R    172.22.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
     172.25.0.0/16 is variably subnetted, 6 subnets, 3 masks
R       172.25.25.6/32 [120/2] via 172.25.2.1, 00:00:01, Serial0.1
R       172.25.25.1/32 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R       172.25.1.0/24 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R       172.25.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R*   0.0.0.0/0 [120/1] via 172.25.2.1, 00:00:02, Serial0.1
Router2#

If you enable automatic summarization, the router will replace all of the highlighted subnets with a single summary for the entire classful network address:

Router2#show ip route rip
R    172.21.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R    172.22.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
     172.25.0.0/16 is variably subnetted, 3 subnets, 3 masks
R       172.25.0.0/16 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
R*   0.0.0.0/0 [120/1] via 172.25.2.1, 00:00:01, Serial0.1
Router2#

You can see if a router is doing any summarization by looking at the show ip protocols command. This command shows both automatic summarization that is enabled by default, as well as any interface-specific manually configured summarization:

Router1#show ip protocols
Routing Protocol is "rip"
  Sending updates every 30 seconds, next due in 14 seconds
  Invalid after 180 seconds, hold down 0, flushed after 240
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Redistributing: static, rip
  Default version control: send version 2, receive version 2
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0.1     2     2                    ORA
    Serial0/0.2           2     2
    FastEthernet0/1       2     2
   Automatic network summarization is in effect
  Address Summarization:
    172.25.0.0/16 for Serial0/0.2
  Maximum path: 4
  Routing for Networks:
    172.22.0.0
    172.25.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           120      00:00:23
    172.25.2.2           120      00:00:00
    172.22.1.4           120      08:00:53
  Distance: (default is 120)
Router1#

The only thing you have to be careful of when using summarization is discontiguous networks. If you configure a router to advertise a summary route for downstream routers, ensure that no subnets in the summarized range exist in the downstream part of the network.

6.16. Route Tagging

Problem

You want RIP to include a tag when it distributes specific routes to prevent routing loops when redistributing between routing protocols.

Solution

RIP Version 2 allows you to tag external routes. For example, a static route configuration looks like this:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.25.1.1
Router1(config)#access-list 7 permit 0.0.0.0
Router1(config)#route-map TAGGING permit 10
Router1(config-route-map)# match ip address 7
Router1(config-route-map)# set tag 5
Router1(config-route-map)# exit
Router1(config)#router rip
Router1(config-router)#redistribute static route-map TAGGING
Router1(config-router)#end
Router1#

Discussion

You can apply a route tag only to external routes: that is, routes that are not learned from RIP. The example shows a static route, but you can apply a tag to routes learned from other routing protocols in exactly the same way. For example, the following shows how to apply a tag to certain routes learned via EIGRP:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 7 permit 192.168.1.0
Router1(config)#route-map TAGGING permit 10
Router1(config-route-map)# match ip address 7
Router1(config-route-map)# set tag 5
Router1(config-route-map)# set exit
Router1(config)#router eigrp 65530
Router1(config-router)#network 192.168.1.0
Router1(config-route-map)# set exit
Router1(config)#router rip
Router1(config-router)#redistribute eigrp 65530
 route-map TAGGING
Router1(config-router)#end
Router1#

RIP does not make use of the tags, it only distributes them. Once a route has a tag associated with it, every RIP Version 2 router will propagate this tag with the route. Tags are useful when redistributing routes into another routing process. For instance, if our RIPv2 network was being used as a transit network between two other networks, we could tag routes learned from one of these external networks and redistribute only those routes into the other network. This way, the RIP network would allow the two networks to talk to one another, but neither of the external networks could use the internal resources of the RIP network itself.

A debug trace shows the tagging in action:

Router1#debug ip rip
RIP protocol debugging is on
Aug 13 03:27:23.870: RIP: sending v2 update to 224.0.0.9 via Serial0/0.2
Aug 13 03:27:23.870: RIP: build update entries
Aug 13 03:27:23.870:    0.0.0.0/0 via 0.0.0.0, metric 1, tag 5
Aug 13 03:27:23.870:    172.22.0.0/16 via 0.0.0.0, metric 1, tag 0
Aug 13 03:27:23.874:    172.25.1.0/24 via 0.0.0.0, metric 1, tag 0
Aug 13 03:27:23.874:    172.25.25.1/32 via 0.0.0.0, metric 1, tag 0
Aug 13 03:27:23.874:    172.25.25.6/32 via 0.0.0.0, metric 2, tag 0

A similar trace on a downstream router would show that while the metric increments at each hop, the tag remains the same.

Here is an example that redistributes only the tagged routes into an attached EIGRP network. Note that you could easily construct a network where different tag values have different meanings. For example, you could make the tags equal to the routing process numbers of the various external networks. This would allow you to easily redistribute only the routes you want into other networks:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router eigrp 11
Router1(config-router)#redistribute rip route-map TAGOUT
Router1(config-router)#exit
Router1(config)#route-map TAGOUT permit 10
Router1(config-route-map)#match tag 5
Router1(config-route-map)#route-map TAGOUT deny 20
Router1(config-route-map)#end
Router1#

RIPv2 supports 16-bit tags, which give a range of values between 0 and 65,535. As we discuss in Chapters Chapter 7 and Chapter 8, EIGRP and OSPF use 32-bit tags, for a range from 0 to 4,294,967,295. Of course, it is unlikely that you will need this many route tags.

See Also

Chapter 7; Chapter 8

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.157.12