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.
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#
|
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)
 |
|
|
| Top |