Enabling Nonperiodic Updates

Problem

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

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 sending 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 these nonperiodic "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#

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

 

Discussion

It is important to distinguish between this feature and the triggered updates that are part of the standard RIP protocol. What is normally called a triggered update in RIP simply means that the protocol sends out updated route information as soon as it notices a change, rather than waiting for the next update cycle. The triggered update feature in this recipe would be more accurately called a nonperiodic update; it simply means that the router generally refrains from sending any routing information unless there is a change.

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 up unnecessarily.

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

Note that we only enabled triggered updates on the Serial0.1 subinterface, but this is not the only interface taking part in RIP. In particular, the Ethernet0 interface uses the normal periodic updates, although it is using a 60-second cycle rather than the default 30-second update period.

If you combine this feature with route filtering and summarization as discussed in Recipes 6.2 and 6.16, 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#

This terminology is slightly confusing because this route is clearly not permanent like a static route would be. But it is not like normal RIP database entries that are subject to the holddown and flush timers, which is why it 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)

Note that RIP didn't send any packets, not even a Hello type packet to ensure that the next hop router was still accessible. This is why the feature is available only on point-to-point links. In any multiple access medium, such as an Ethernet segment, the router wouldn't be able to determine whether its neighbors had become unreachable.

See Also

Recipe 6.2; Recipe 6.16