Configuring RIP | Routing TCP/IP, Volume 1 (2nd Edition)

In keeping with the simple nature of RIP, configuration is an easy task. There is one command to enable the RIP process and one command for each network on which RIP is to run. Beyond that, RIP has few configuration options.

Case Study: A Basic RIP Configuration

Only two steps are necessary to configure RIP:

Enable RIP with the command router rip.

Specify each major network on which to run RIP with the network command. Figure 5-5 shows a four-router network, with four major network numbers. Router Goober is attached to two subnets of network 172.17.0.0.

Figure 5-5. Both Andy and Barney are border routers between class-level networks.

The commands necessary to enable RIP are displayed in Example 5-4.

Example 5-4. The RIP configuration of Goober.

router rip  network 172.17.0.0

Similarly, Opie has two subnets of the same network and will configure with the commands in Example 5-5.

Example 5-5. Opie's RIP configuration.

router rip  network 172.17.0.0

Executing any router command puts the router into config-router mode, indicated in the prompt. The classful nature of RIP and the subnet hiding at network boundaries mean that no subnets can be specified with the network commandonly major class A, B, or C network addresses. RIP can run on any interface configured with any address belonging to the network specified with the network command.

Barney is attached to two networks10.0.0.0 and 192.168.83.0. Therefore, both networks must be specified as in Example 5-6.

Example 5-6. Barney's RIP configuration.

router rip  network 10.0.0.0  network 192.168.83.0

Andy has one attachment to network 192.168.83.0, attachments to two subnets of 192.168.12.0, and attachments to two subnets of 172.17.0.0. Example 5-7 shows its configuration.

Example 5-7. Andy's RIP configuration.

router rip  network 172.17.0.0  network 192.168.12.0  network 192.168.83.0

In Example 5-8, the command debug ip rip has been turned on in Andy. Of particular interest here is the subnet hiding that the router is performing. The subnets 192.168.12.64 and 192.168.12.192 are advertised between interfaces E0 and E2, which are both attached to network 192.168.12.0, but the network is summarized out E1, S0, and S1, which are all attached to different networks. Likewise, networks 192.168.83.0 and 172.17.0.0 are being summarized across classful boundaries. Notice also that Andy is receiving a summary route for network 10.0.0.0 from Barney. Finally, split horizon can be observed here. For example, the advertisement to Barney out E1 contains no entries for 10.0.0.0 or 192.168.83.0.

Example 5-8. These debug messages show the RIP updates received and sent by Router Andy. The results of both network summarization and split horizon can be observed in the update entries.

Andy#debug ip rip RIP protocol debugging is on Andy# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.12.65) RIP: build update entries      subnet 192.168.12.192, metric 1      network 10.0.0.0, metric 2      network 192.168.83.0, metric 1      network 172.17.0.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet1 (192.168.83.1) RIP: build update entries      network 192.168.12.0, metric 1      network 172.17.0.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet2 (192.168.12.195) RIP: build update entries      subnet 192.168.12.64, metric 1      network 10.0.0.0, metric 2      network 192.168.83.0, metric 1      network 172.17.0.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Serial0 (172.17.1.1) RIP: build update entries      subnet 172.17.4.0, metric 2      subnet 172.17.2.0, metric 1      network 10.0.0.0, metric 2      network 192.168.83.0, metric 1      network 192.168.12.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Serial1 (172.17.2.1) RIP: build update entries      subnet 172.17.1.0, metric 1      subnet 172.17.3.0, metric 2      network 10.0.0.0, metric 2      network 192.168.83.0, metric 1      network 192.168.12.0, metric 1 RIP: received v1 update from 172.17.1.2 on Serial0      172.17.3.0 in 1 hops RIP: received v1 update from 192.168.83.244 on Ethernet1      10.0.0.0 in 1 hops RIP: received v1 update from 172.17.2.2 on Serial1      172.17.4.0 in 1 hops

Case Study: Passive Interfaces

The Router Floyd has been added to the network (Figure 5-6).

Figure 5-6. Network policy calls for no RIP exchanges between Andy and Floyd.

It is desired that no RIP advertisements be exchanged between Floyd and Andy. This is easy enough at Floyd, as displayed in Example 5-9.

Example 5-9. Floyd's RIP configuration

router rip  network 192.168.100.0

By not including a network statement for 192.168.12.0, Floyd will not advertise on interface 192.168.12.66. Andy, however, has two interfaces attached to 192.168.12.0; the network must be included under RIP. To block RIP broadcasts on an interface connected to a subnet of a RIP-enabled network, add the passive-interface command to the RIP process. Andy's RIP configuration is displayed in Example 5-10.

Example 5-10. Andy's RIP configuration with a passive interface.

router rip  passive-interface Ethernet0  network 172.17.0.0  network 192.168.12.0  network 192.168.83.0

passive-interface is not a RIP-specific command; it might be configured under any IP routing protocol. Using the passive-interface command essentially makes a router a silent host on the data link specified. Like other silent hosts, it still listens to RIP broadcasts on the link and updates its route table accordingly. If the desired result is to prevent the router from learning routes on the link, it must be achieved by more intricate control of routing updates, namely by filtering out updates. (Route filters are discussed in Chapter 13, "Route Filtering.") Unlike a silent host, the router does not respond to a RIP Request received on a passive interface.

Case Study: Configuring Unicast Updates

Next, Router Bea is added to the Ethernet link that Andy and Floyd share (Figure 5-7). The no-RIP policy between Andy and Floyd remains in place, but now Bea and Andy, like Bea and Floyd, must exchange RIP advertisements.

Figure 5-7. No RIP updates should be exchanged between Andy and Floyd, but both should exchange updates with Bea.

The configuration of Bea is straightforward (see Example 5-11).

Example 5-11. Bea's RIP configuration.

router rip  network 192.168.12.0  network 192.168.200.0

The addition of a neighbor command under the RIP processes of Andy enables RIP to send a unicast advertisement to Bea's interface while the passive-interface command continues to prevent broadcast updates on the link.^[9]

^[9] Another use of neighbor is to enable unicast updates on nonbroadcast media such as Frame Relay.

Andy's configuration is displayed in Example 5-12.

Example 5-12. Andy's RIP configuration includes a passive interface with a neighbor statement to enable unicast updates.

router rip  passive-interface Ethernet0  network 172.17.0.0  network 192.168.12.0  network 192.168.83.0  neighbor 192.168.12.67

Because Floyd must now send advertisements to Bea, a network command for 192.168.12.0 must be added. passive-interface is also added to prevent broadcast updates, and a neighbor command is added to enable unicast updates to Bea (see Example 5-13).

Example 5-13. Floyd's RIP configuration with unicast updates to neighbor 192.168.12.67.

router rip passive-interface Ethernet0 network 192.168.12.0 network 192.168.100.0 neighbor 192.168.12.67

By enabling debug ip rip events at Andy, the results of the new configuration can be verified (Example 5-14). Andy is receiving updates from Bea, but not from Floyd, and is sending updates directly to Bea's interface but is not broadcasting on its E0.

Example 5-14. The only updates Andy is sending out interface E0 are unicasts to Bea. Updates are being received from Bea but not from Floyd.

Andy#debug ip rip events RIP event debugging is on Andy# RIP: received v1 update from 192.168.12.67 on Ethernet0 RIP: Update contains 1 routes RIP: sending v1 update to 255.255.255.255 via Ethernet1 (192.168.83.1) RIP: Update contains 4 routes RIP: Update queued RIP: Update sent via Ethernet1 RIP: sending v1 update to 255.255.255.255 via Ethernet2 (192.168.12.195) RIP: Update contains 6 routes RIP: Update queued RIP: Update sent via Ethernet2 RIP: sending v1 update to 255.255.255.255 via Serial0 (172.17.1.1) RIP: Update contains 7 routes RIP: Update queued RIP: Update sent via Serial0 RIP: sending v1 update to 255.255.255.255 via Serial1 (172.17.2.1) RIP: Update contains 7 routes RIP: Update queued RIP: Update sent via Serial1 RIP: sending v1 update to 192.168.12.67 via Ethernet0 (192.168.12.65) RIP: Update contains 4 routes RIP: Update queued RIP: Update sent via Ethernet0 RIP: received v1 update from 172.17.1.2 on Serial0 RIP: Update contains 1 routes RIP: received v1 update from 172.17.2.2 on Serial1 RIP: Update contains 1 routes RIP: received v1 update from 192.168.12.67 on Ethernet0 RIP: Update contains 1 routes

Although Bea has learned routes from both Andy and from Floyd, and is broadcasting updates on the shared Ethernet, the policy still works because split horizon prevents Bea from advertising the routes learned from those two routers back onto the Ethernet.

Case Study: Discontiguous Subnets

In Figure 5-8, another router has been added to the network with a subnet 10.33.32.0/20 on its E1 interface. The problem is that the other subnet of network 10.0.0.0, 10.33.0.0/20, is connected to Barney, and the only route between the subnets is via 192.168.83.0 and 192.168.12.0two entirely different networks. As a result, network 10.0.0.0 is discontiguous.

Figure 5-8. Classful protocols such as RIP and IGRP cannot route a topology in which the subnets of network 10.0.0.0 are separated by different networks.

Barney will consider itself a border router between network 10.0.0.0 and network 192.168.83.0; likewise, Ernest_T will consider itself a border router between 10.0.0.0 and 192.168.12.0. Both will advertise a summary route of 10.0.0.0, and as a result Andy will be "fooled into thinking" that it has two equal-cost paths to the same network. Andy will load share on the links to Barney and Ernest_T, and there is now only a 50-50 chance that packets to network 10.0.0.0 will reach the correct subnet.

The solution is to configure subnets of network 10.0.0.0 on the same links on which 192.168.83.0/24 and 192.168.12.192/27 reside. This is accomplished with secondary IP addresses, as displayed in Example 5-15, Example 5-16, and Example 5-17.

Example 5-15. Barney is configured with secondary IP addresses.

interface e0  ip address 10.33.55.1 255.255.240.0 secondary

Example 5-16. Andy is configured with secondary IP addresses, and a new network is added to RIP.

interface e1  ip address 10.33.55.2 255.255.240.0 secondary interface e2  ip address 10.33.75.1 255.255.240.0 secondary router rip  network 10.0.0.0

Example 5-17. Ernest_T is configured with secondary IP addresses.

interface e0  ip address 10.33.75.2 255.255.240.0 secondary

Because Andy did not previously have an interface on network 10.0.0.0, a network statement is added to the RIP process. The result of the configuration is shown in Figure 5-9. The existing logical network structure remains in place, and a contiguous network 10.0.0.0 is "overlaid" onto it.

Figure 5-9. Secondary addresses are used to connect the subnets of network 10.0.0.0 across the same links on which other network addresses exist.

Example 5-18 shows Ernest_T's route table. Of interest here are the dual, equal-cost routes associated with next-hop addresses 10.33.75.1 and 192.168.12.195.

Example 5-18. The routing process in this router sees the subnets 192.168.12.192/27 and 10.33.64.0/20 as separate links, although they reside on the same physical interface.

Ernest_T#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default Gateway of last resort is not set     10.0.0.0 255.255.240.0 is subnetted, 4 subnets C     10.33.32.0 is directly connected, Ethernet1 R     10.33.48.0 [120/1] via 10.33.75.1, 00:00:05, Ethernet0 R     10.33.0.0 [120/2] via 10.33.75.1, 00:00:05, Ethernet0 C     10.33.64.0 is directly connected, Ethernet0 R     192.168.83.0 [120/1] via 192.168.12.195, 00:00:05, Ethernet0                    [120/1] via 10.33.75.1, 00:00:05, Ethernet0       192.168.12.0 255.255.255.224 is subnetted, 2 subnets R     192.168.12.64 [120/1] via 192.168.12.195, 00:00:05, Ethernet0 C     192.168.12.192 is directly connected, Ethernet0 R     192.168.200.0 [120/2] via 192.168.12.195, 00:00:05, Ethernet0                     [120/2] via 10.33.75.1, 00:00:05, Ethernet0 R     172.17.0.0 [120/1] via 192.168.12.195, 00:00:06, Ethernet0                  [120/1] via 10.33.75.1, 00:00:06, Ethernet0 Ernest_T#

Because the routing process sees secondary addresses as separate data links, caution should be used when planning them on RIP or IGRP networks. A separate RIP update will be broadcast on each subnet; if the updates are large and the bandwidth of the physical link is limited (such as on serial links), the multiple updates can cause congestion. Multiple updates on a link configured with secondary addresses can be observed in Example 5-21, later in this chapter.

Type cautiously when entering secondary addresses. If you omit the keyword secondary, the router will assume that the primary address is to be replaced with the new address. Making this mistake on an in-service interface will have serious consequences.

Case Study: Manipulating RIP Metrics

A serial link, to be used as a backup, has been added between Ernest_T and Barney (Figure 5-10). This link should be used only if the route via Andy fails. The problem is that the path between Barney's 10.33.0.0 subnet and Ernest_T's 10.33.32.0 subnet is one hop via the serial link and two hops via the preferred Ethernet links. Under normal circumstances, RIP will choose the serial link.

Figure 5-10. RIP metrics must be manipulated so that the two-hop Ethernet route between Barney and Ernest_T will be preferred over the one-hop serial route.

The route metrics can be manipulated with the offset-list command. The command specifies a number to add to the metric of a route entry and references an access list^[10] to determine which route entries to modify. The syntax of the command is as follows:

^[10] See Appendix B for a tutorial on access lists.

offset-list {access-list-number | name} { in | out} offset [type number]

The configuration of Ernest_T is in Example 5-19.

Example 5-19. Ernest_T's RIP configuration with an inbound offset list.

access-list 1 permit 10.33.0.0 0.0.0.0 router rip  network 192.168.12.0  network 10.0.0.0  offset-list 1 in 2 Serial0

An access list is written that identifies the route to subnet 10.33.0.0. The syntax of the offset list says, "Examine RIP advertisements incoming from interface S0. For route entries matching the addresses specified in access list 1, add 2 hops to the metric."

After Barney is configured, it will have the entries in Example 5-20 in its configuration file.

Example 5-20. Barney's RIP configuration with an inbound offset list.

router rip  offset-list 5 in 2 Serial0  network 10.0.0.0  network 192.168.83.0 ! access-list 5 permit 10.33.32.0 0.0.0.0

Example 5-21 shows the results of the configuration at Ernest_T.

Example 5-21. The addition of the hops specified in the offset list changes the hop count to subnet 10.33.0.0/20 via S0 from one to three. Now the two-hop route via E0 is used.

Ernest_T#debug ip rip RIP protocol debugging is on Ernest_T# RIP: received v1 update from 192.168.12.195 on Ethernet0      192.168.12.64 in 1 hops      10.0.0.0 in 1 hops      192.168.83.0 in 1 hops      192.168.200.0 in 2 hops      172.17.0.0 in 1 hops RIP: received v1 update from 10.33.75.1 on Ethernet0      10.33.48.0 in 1 hops      10.33.0.0 in 2 hops      192.168.83.0 in 1 hops      192.168.12.0 in 1 hops      192.168.200.0 in 2 hops      172.17.0.0 in 1 hops RIP: received v1 update from 10.33.25.1 on Serial0      10.33.32.0 in 3 hops      10.33.48.0 in 1 hops      10.33.0.0 in 3 hops      192.168.83.0 in 1 hops      192.168.200.0 in 3 hops      172.17.0.0 in 2 hops RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.12.196) RIP: build update entries      network 10.0.0.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet0 (10.33.75.2) RIP: build update entries      subnet 10.33.32.0, metric 1      subnet 10.33.16.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet1 (10.33.35.1) RIP: build update entries      subnet 10.33.48.0, metric 2      subnet 10.33.0.0, metric 3      subnet 10.33.16.0, metric 1      subnet 10.33.64.0, metric 1      network 192.168.83.0, metric 2      network 192.168.12.0, metric 1      network 192.168.200.0, metric 3      network 172.17.0.0, metric 2 RIP: sending v1 update to 255.255.255.255 via Serial0 (10.33.25.2) RIP: build update entries      subnet 10.33.32.0, metric 3      subnet 10.33.0.0, metric 3      subnet 10.33.64.0, metric 1      network 192.168.12.0, metric 1      network 192.168.200.0, metric 3      network 172.17.0.0, metric 2

Alternatively, instead of having the two routers modify incoming routes, the routers can be configured to modify their outgoing routes. The configurations in Example 5-22 and Example 5-23 will have the same effects as the previous configurations.

Example 5-22. Ernest_T's RIP configuration uses outbound offset lists.

router rip  offset-list 3 out 2 Serial0  network 192.168.12.0  network 10.0.0.0 ! access-list 3 permit 10.33.32.0 0.0.0.0

Example 5-23. Barney's RIP configuration uses outbound offset lists.

router rip  offset-list 7 out 2 Serial0  network 10.0.0.0  network 192.168.83.0 ! access-list 7 permit 10.33.0.0 0.0.0.0

Several other options are available for configuring offset lists. If no interface is identified, the list will modify all incoming or outgoing updates specified by the access list on any interface. If no access list is called (by using a zero as the access list number), the offset list will modify all incoming or outgoing updates.

Caution should be applied when choosing whether to use offset lists on incoming or outgoing advertisements. If more than two routers are attached to a broadcast network, consideration must be given to whether a single router should broadcast a modified advertisement to all its neighbors or whether a single router should modify a received advertisement.

Care must also be exercised when implementing offset lists on routes that are in use. When an offset list causes a next-hop router to advertise a higher metric than it had been advertising, the route will be marked unreachable until the holddown timer expires.

Case Study: Minimizing the Impact of Updates

There are times when you will want to minimize network traffic caused by routing updates. Regular RIP updates, by default, occur every 30 seconds and include the full route table, in addition to the flash updates that are transmitted when there is a change in the metric of route entries. In a network with many subnets, routing updates can affect traffic, especially on low bandwidth links. You also might want to minimize routing updates if you are paying for traffic traversing a link.

Suppose utilization on the new serial link from Barney to Ernest_T, in Figure 5-10, is high. The RIP routing traffic can be reduced in two ways to minimize the traffic caused by the routing protocol: The timers can be adjusted so the updates don't occur as frequently, but this will cause longer convergence time when the primary link fails. Or triggered extensions can be configured to eliminate periodic RIP updates.

The interface command ip rip triggered enables the triggered extensions of RIP.^[11] After two routers on a serial link determine both are configured for triggered RIP, route table updates are minimized to include only the initial exchange of route tables and updates when changes to the route tables occur. This command is only available on serial links and must be configured on both ends of the link before taking affect.

^[11] Triggered Extensions are defined in RFC 2091 and were first introduced into IOS in release 12.0(1)T.

The triggered extensions are configured on Barney's serial link to Ernest_T with the configuration in Example 5-24.

Example 5-24. Barney is configured with triggered, rather then periodic, updates.

interface serial 0  ip rip triggered

Debugging on Barney shows that Barney attempts to establish a triggered relationship with the router on the other end of the link. Barney sends polls and waits for acknowledgments. When it doesn't receive any acknowledgments, Barney begins sending regular RIPv1 updates. Output from debug ip rip and debug ip rip trigger is shown in Example 5-25.

Example 5-25. When a router is initially configured with triggered RIP, it polls to determine if its neighbor is also configured for triggered RIP.

Barney#debug ip rip RIP protocol debugging is Barney#debug ip rip trigger RIP trigger debugging is on Barney(config)#interface serial 0 Barney(config-if)#ip rip triggered * 13:22:10.223: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:10.223: RIP: Start poll timer from 10.33.25.1 on Serial0 * 13:22:15.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:15.223: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:15.223: RIP: Start poll timer from source 10.33.25.1 on Serial0 * 13:22:16.733: RIP: received v1 update from 10.33.25.2 on Serial0 * 13:22:16.733:      172.17.8.0 in 1 hops * 13:22:16.733:      172.17.9.0 in 1 hops * 13:22:16.737:      172.17.10.0 in 1 hops * 13:22:16.737:      172.17.11.0 in 1 hops * 13:22:19.466: RIP-TIMER: sending timer on Serial0 expired * 13:22:20.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:20.223: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:20.223: RIP: Start poll timer from source 10.33.25.1 on Serial0 * 13:22:25.223: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:25.223: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:25.223: RIP: Start poll timer from source 10.33.25.1 on Serial0 * 13:22:30.224: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:30.224: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:30.224: RIP: Start poll timer from source 10.33.25.1 on Serial0 * 13:22:35.224: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:35.224: RIP: sending triggered request on Serial0 to 255.255.255.255 * 13:22:35.224: RIP: Start poll timer from source 10.33.25.1 on Serial0 * 13:22:40.224: RIP-TIMER: polling timer on Serial0(10.33.25.1) expired * 13:22:40.224: RIP: Poll 6 times on Serial0 thru 10.33.25.1 without any ack * 13:22:46.126: RIP: received v1 update from 10.33.25.2 on Serial0 * 13:22:46.126:      172.17.8.0 in 1 hops * 13:22:46.126:      172.17.9.0 in 1 hops * 13:22:46.130:      172.17.10.0 in 1 hops * 13:22:46.130:      172.17.11.0 in 1 hops * 13:22:49.054: RIP-TIMER: sending timer on Serial0 expired * 13:22:49.054: RIP: sending v1 update to 255.255.255.255 via Serial0(10.33.25.1) * 13:22:49.054: RIP: build update entries * 13:22:49.054:   network 10.0.0.0 metric 2 * 13:22:49.054:   subnet 172.17.0.0 metric 2 * 13:22:49.054:   subnet 172.17.2.0 metric 1 * 13:22:49.058:   subnet 172.17.4.0 metric 2 * 13:22:49.058:   network 192.168.12.0 metric 1 * 13:22:49.058:   network 192.168.83.0 metric 1 * 13:23:13.070: RIP: received v1 update from 10.33.25.2 on Serial0 * 13:23:13.070:      172.17.8.0 in 1 hops * 13:23:13.074:      172.17.9.0 in 1 hops * 13:23:13.074:      172.17.10.0 in 1 hops * 13:23:13.074:      172.17.11.0 in 1 hops * 13:23:17.385: RIP-TIMER: sending timer on Serial0 expired * 13:23:17.385: RIP: sending v1 update to 255.255.255.255 via Serial0(10.33.25.1) * 13:23:17.385: RIP: build update entries * 13:23:17.385:   network 10.0.0.0 metric 2 * 13:23:17.385:   subnet 172.17.0.0 metric 2 * 13:23:17.385:   subnet 172.17.2.0 metric 1 * 13:23:17.389:   subnet 172.17.4.0 metric 2 * 13:23:17.389:   network 192.168.12.0 metric 1 * 13:23:17.389:   network 192.168.83.0 metric 1

The debug output shows that the configured router sends six triggered requests. For each one, the router sets a poll timer, which expires in five seconds. If no acknowledgment is received within the five seconds, another triggered request is sent. If no acknowledgment is received after six triggered requests have been sent and the polls have expired, the router waits for the next regular update time and broadcasts a RIP update. While Barney is sending triggered requests, Ernest_T continues to broadcast its own RIP updates, which Barney processes.

Now, Ernest_T's serial link to Barney is configured with triggered RIP. Through debugging on Ernest_T, Example 5-26 shows the initialization process between Barney and Ernest_T.

Example 5-26. Debug output shows two routers establishing a triggered RIP relationship.

* 13:35:04.612: RIP: received v1 triggered request from 172.17.1.2 on Serial0 * 13:35:04.616: RIP: Trigger rip running on network 172.17.0.0 thru Serial0 * 13:35:04.616: RIP: 172.17.1.2 change state from DOWN to INIT * 13:35:04.616: RIP: 172.17.1.2 change state from INIT to LOADING * 13:35:04.616: RIP: send v1 triggered flush update to 172.17.1.2 on Serial0 * 13:35:04.616: RIP: assigned sequence number 25 on Serial0 * 13:35:04.616: RIP: build update entries * 13:35:04.620:   route 202: network 192.168.12.0 metric 1 * 13:35:04.620:   route 206: subnet 172.17.2.0 metric 1 * 13:35:04.620:   route 208: network 192.168.83.0 metric 1 * 13:35:04.620:   route 210: network 10.0.0.0 metric 2 * 13:35:04.620:   route 215: subnet 172.17.4.0 metric 2 * 13:35:04.620:   route 217: subnet 172.17.0.0 metric 2 * 13:35:04.624: RIP: Update contains 6 routes, start 202, end 226 * 13:35:04.624: RIP: start retransmit timer of 172.17.1.2 * 13:35:04.680: RIP: received v1 triggered ack from 172.17.1.2 on Serial0 flush seq# 25 * 13:35:04.684: RIP: 172.17.1.2 change state from LOADING to FULL * 13:35:04.688: RIP: received v1 triggered update from 172.17.1.2 on Serial0 * 13:35:04.688: RIP: sending v1 ack to 172.17.1.2 via Serial0 (172.17.1.1), flush, seq# 14 * 13:35:04.736: RIP: received v1 triggered update from 172.17.1.2 on Serial0 * 13:35:04.740: RIP: sending v1 ack to 172.17.1.2 via Serial0 (172.17.1.1), seq# 15 * 13:35:04.740:      172.17.9.0 in 1 hops * 13:35:04.740:      172.17.8.0 in 1 hops * 13:35:04.740:      172.17.11.0 in 1 hops * 13:35:04.744:      172.17.10.0 in 1 hops * 13:35:52.879: RIP-TIMER: sending timer on Serial0 expired * 13:36:21.907: RIP-TIMER: sending timer on Serial0 expired * 13:36:47.421: RIP-TIMER: sending timer on Serial0 expired

The triggered state goes from DOWN, through INIT and LOADING, to FULL. Route information is exchanged and updates are acknowledged. At the end of the output, you can see that the RIP update timers are expiring, but no new updates are sent, nor are updates received.