ROUTING CONSORTIUM. Routing Information Protocol Version 2 (RIP) Operations Test Suite. Technical Document. Revision 4.4

Transcription

1 ROUTING CONSORTIUM Routing Information Protocol Version 2 (RIP) Operations Test Suite Technical Document Revision 4.4 University of New Hampshire 121 Technology Drive, Suite 2 Durham, NH Routing Consortium Phone: Fax: University of New Hampshire

2 TABLE OF CONTENTS University of New Hampshire MODIFICATION RECORD... iii INTRODUCTION...v TEST ORGANIZATION...vi REFERENCES... viii ABSTRACT...2 GROUP 1: Processing...3 Test RIP.1.1: Basic Response Processing... 4 Test RIP.1.2: Next Hop Processing... 5 Test RIP.1.3: Subnet Mask Processing... 7 Test RIP.1.4: Default Route Processing... 8 Test RIP.1.5: Infinite Metric Processing Test RIP.1.6: Host Route Processing Test RIP.1.7: Version Number Processing Test RIP.1.9: Route Tags Processing Test RIP.1.10: Triggered Response Processing Test RIP.1.11: Route Timeout Processing Test RIP.1.12: Number of Entries Processing Test RIP.1.13: Compatibility with v1 Switches Processing Test RIP.1.14: Full Table Request Processing Test RIP.1.15: Specific Route Request Processing Test RIP.1.16: Simple Authentication Processing Test RIP.1.17: UDP Port Processing Test RIP.1.18: Heuristic for RIP Response Processing Test RIP.1.19: Metric Processing Test RIP.1.20: Static Route Processing GROUP 2: Validation...34 Test RIP.2.1: Network Validation Test RIP.2.2: Metric Validation Test RIP.2.3: Must Be Zero Fields Validation Test RIP.2.4: Command Number Validation Test RIP.2.5: Invalid Number of Entries Validation Test RIP.2.6: Source Address Validation Test RIP.2.7: Next Hop Validation GROUP 3: Forwarding...43 Test RIP.3.1: Basic Forwarding Test RIP.3.2: Priority Forwarding Test RIP.3.3: Expired Route ROUTING CONSORTIUM i RIPv2 Operations Test Suite

3 GROUP 4: MD5 Authentication...47 Test RIP.4.1: Basic MD5 Authentication Test RIP.4.2: Incorrect Digest Test RIP.4.3: Sequence Numbers Test RIP.4.4: Sequence Number Zero Test RIP.4.5: UDP Checksum Test RIP.4.6: Key Lifetime Expiry ROUTING CONSORTIUM ii RIPv2 Operations Test Suite

4 MODIFICATION RECORD University of New Hampshire Version 4.4 Complete August 31, 2005 Added diagrams to all tests Minor formatting changes Minor grammatical changes September 1, 2005 Modified diagrams Minor grammatical changes Version 4.3 Complete July 6, 2004 Removed test: Subnet Mask Validation Restructured test labels Version 4.2 Complete March 25, 2004 Modified test 1.7 Added Part A heading on single-part tests Version 4.1 Complete December 2, 2001 Reversed pass conditions for test 4.5a, based on wording in the Router Requirements RFC. Version 4.01 Complete October 22, 2001 Cosmetic changes to the cover page Version 4.0 Complete September 1, 2001 Version 3.0 Complete January 6, 2000 ROUTING CONSORTIUM iii RIPv2 Operations Test Suite

5 ACKNOWLEDGEMENTS University of New Hampshire The University of New Hampshire would like to acknowledge the efforts of the following individuals in the development of this test suite: Michael Briggs University of New Hampshire Kim Cutting University of New Hampshire Kimo Johnson University of New Hampshire Ray LaRocca University of New Hampshire Dr. William Lenharth University of New Hampshire John Leser University of New Hampshire Jeremy McCooey University of New Hampshire Kari Revier University of New Hampshire Sebastien Roy University of New Hampshire Joseph Scholefield University of New Hampshire Ben Schultz University of New Hampshire Quaizar Vohra University of New Hampshire Rob Wolff University of New Hampshire ROUTING CONSORTIUM iv RIPv2 Operations Test Suite

6 INTRODUCTION Overview The University of New Hampshire s (IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This suite of tests has been developed to help implementers evaluate the functioning of their Router Information Protocol implementations. The tests do not determine if a product conforms to the specifications, nor are they purely interoperability tests. Rather, they provide a method to isolate problems within a device. Successful completion of all tests contained in this suite does not guarantee that the tested device will operate with other RIP devices. However, these tests provide a reasonable level of confidence that the Router Under Test will function well in most multi-vendor RIP environments. Test Software The UNH IOL Testing Software is not a full RIP implementation; it is simply a packet generator that can transmit and receive packets. This allows the Testing Node to generate invalid packets and to simulate parts of the Router Information Protocol. The Testing Software is not currently available to the public. Acronyms Acronyms used in this Test Suite: LP: Link Partner N: Network RTE: Routing Table Entry RUT: Router Under Test TR: Testing Router When several entities of the same type are present in a test configuration, a number is appended to the acronym to yield a label for each entity. For example, if there were three testing routers in the test configuration, they would be labeled, TR2 and TR3. ROUTING CONSORTIUM v RIPv2 Operations Test Suite

7 TEST ORGANIZATION University of New Hampshire This document organizes tests by group based on related test methodology or goals. Each group begins with a brief set of comments pertaining to all tests within that group. This is followed by a series of description blocks; each block describes a single test. The format of the description block is as follows: Test Label: Purpose: References: Discussion: Test Setup: The test label and title comprise the first line of the test block. The test label is composed by concatenating the short test suite name, the group number, and the test number within the group, separated by periods. The Test Number is the group and test number, also separated by a period. So, test label RIP.1.2 refers to the second test of the first test group in the RIP suite. The test number is 1.2. The Purpose is a short statement describing what the test attempts to achieve. It is usually phrased as a simple assertion of the feature or capability to be tested. The References section lists cross-references to the specifications and documentation that might be helpful in understanding and evaluating the test and results. The Discussion is a general discussion of the test and relevant section of the specification, including any assumptions made in the design or implementation of the test as well as known limitations. The Test Setup section describes the configuration of all devices prior to the start of the test. Different parts of the procedure may involve configuration steps that deviate from what is given in the test setup. If a value is not provided for a protocol parameter, then the following Default Setup is used: - Split Horizon/Poisoned Reverse: Enabled - Compatibility Switch: RIP-2 - Receive Control Switch: Both RIP-1 and RIP-2 - Timeout Timer: 180 seconds - Garbage Collection Timer: 120 seconds - Periodic Update Timer: 30 seconds - Triggered Responses: Enabled - Redistribution of routes to directly connected networks: Enabled In addition, at the end of each test in which routes could be learned, be they valid or invalid, the routes are sent with metric 16 to ensure they are deleted. Because of this, the RUT should expire any learned routes at the end of each test. This section of the test description contains the step-by-step instructions for carrying out the test. These steps include such things as enabling interfaces, unplugging devices from the network, or sending packet from a test station. The test procedure also cues the tester to make observations, which are interpreted in accordance with the observable results given for that test part. ROUTING CONSORTIUM vi RIPv2 Operations Test Suite

8 Observable Results: Possible Problems: This section lists observable results that can be examined by the tester to verify that the RUT is operating properly. When multiple observable results are possible, this section provides a short discussion on how to interpret them. The determination of a pass or fail for each test is usually based on how the RUT s behavior compares to the results described in this section. This section contains a description of known issues with the test procedure, which may affect test results in certain situations. ROUTING CONSORTIUM vii RIPv2 Operations Test Suite

9 REFERENCES The following documents are referenced in this text: [1058] Hedrick, C. "Routing Information Protocol." STD 34. RFC Rutgers University, June [1812] Baker, F. Requirements for IP Version 4 Routers. RFC Cisco Systems, June [2082] Baker, F. and Atkinson, R. RIP-2 MD5 Authentication. RFC Cisco Systems, January [2453] Malkin, G. RIP Version 2. STD 56. RFC November 1998 ROUTING CONSORTIUM viii RIPv2 Operations Test Suite

10 ABSTRACT The following tests cover the operation of the Router Information Protocol (RIP). RIP specifies a distance-vectored routing protocol that dynamically finds the shortest cost path to a destination. Packets destined to use that route are then forwarded to the next hop that has the least cost. Although the RIP approach is not optimal, it takes a minimal amount of time to setup and manage. The simplicity of RIP makes it easy to implement and thus many different implementations are currently in use. ROUTING CONSORTIUM 2 RIPv2 Operations Test Suite

11 GROUP 1: Processing Scope: The following tests cover portions of the Routing Information Protocol associated with the processing of packets. Overview: These tests are designed to verify that the RUT behaves properly when processing the information of received routing update messages. The test router in this group of tests consists of an analyzer that can send and receive frames. ROUTING CONSORTIUM 3 RIPv2 Operations Test Suite

12 Test RIP.1.1: Basic Response Processing Purpose: To verify that a router performs the correct processing on receipt of a properly formatted RIP Response including several route entries. References: [2453] Sections and Discussion: Once an entry has been validated, adopt the route from the datagram (i.e., put the new metric in and adjust the next hop address, if necessary). Triggered updates do not need to include the entire routing table. In principle, only those routes which have changed need to be included. Therefore, messages generated as part of a triggered update must include at least those routes that have their route change flag set. They may include additional routes, at the discretion of the implementor; however, sending complete routing updates is strongly discouraged. When a triggered update is processed, messages should be generated for every directly-connected network. Split Horizon processing is done when generating triggered updates as well as normal updates (see section 3.9). If, after Split Horizon processing for a given network, a changed route will appear unchanged on that network (e.g., it appears with an infinite metric), the route need not be sent. If no routes need be sent on that network, the update may be omitted. Once all of the triggered updates have been generated, the route change flags should be cleared. network 0 RUT network 1 Part A: Basic Response Processing 1. transmits a RIP Response with 3 RTEs to the All RIP-2 Routers Multicast Address. 2. Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the RUT should transmit a triggered response to the multicast address on each of its other interfaces advertising the learned routes. The network and subnet mask of each route should be the same as was advertised by the test software. The metrics should be calculated correctly. The next hops from the original RTEs should be learned, and included with each route in the RUT s routing table, but may be changed to indicate the RUT as next hop in the RUT s responses. The RUT should include the learned routes in its periodic responses. Possible Problems: None. ROUTING CONSORTIUM 4 RIPv2 Operations Test Suite

13 Test RIP.1.2: Next Hop Processing Purpose: To verify that a router behaves correctly in several cases where the next hop of a Route Entry should be considered the originator of the packet. References: [2453] Section 4.4 [2453] Appendix A Discussion: There are several cases in which the next hop for a Route Entry should be considered the originator of the response packet. A next hop field value of indicates that the next hop should be the originator of the packets. Also, if the next hop is not available on any directly connected network, it should be considered the originator of the response packet. The Next Hop field indicates the immediate next hop IP address to which packets to the destination specified by this Route Entry should be forwarded. Specifying a value of in this field indicates that routing should be via the originator of the RIP advertisement. An address specified as a next hop must, per force, be directly reachable on the logical subnet over which the advertisement is made. The purpose of the next hop field is to eliminate packets being routed through extra hops in the system. It is particularly useful when RIP is not being run on all of the routers on a network. A simple example is given in Appendix A. Note that next hop is an "advisory" field. That is, if the provided information is ignored, a possibly sub-optimal, but absolutely valid, route may be taken. If the received next hop is not directly reachable, it should be treated as network 0 RUT Part A: Next Hop specifies transmits a RIP Response that includes a Route Entry. The next hop for this RTE is Observe the RUT s routing table to determine what next hop is used for the route advertised. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Next Hop not on a Directly Connected Network 4. transmits a RIP Response that includes a Route Entry. The next hop for this RTE is not on a directly connected network. 5. Observe the RUT s routing table to determine what next hop is used for the route advertised. 6. transmits a RIP Response for the routes learned in this test with a metric of 16. Part C: Next Hop not Directly Reachable 7. transmits a RIP Response for some network N with a next hop of TR2. 8. transmits a RIP Response that includes a Route Entry with a next hop on network N, which is not a directly connected network. 9. Observe the RUT s routing table to determine what next hop is used for the route advertised. 10. transmits a RIP Response for the routes learned in this test with a metric of 16. ROUTING CONSORTIUM 5 RIPv2 Operations Test Suite

14 In Parts A and B, the next hop should be the originator of the RIP Response. In Part C, the next hop should be treated as (the originator of the RIP Response, e.g., ) since it is not on a directly connected network. Possible Problems: None. ROUTING CONSORTIUM 6 RIPv2 Operations Test Suite

15 Test RIP.1.3: Subnet Mask Processing Purpose: To verify that a router correctly interprets and processes the subnet mask field. References: [2453] Section 4.3 Discussion: The Subnet Mask field contains the subnet mask which is applied to the IP address to yield the non-host portion of the address. If this field is zero, then no subnet mask has been included for this entry. On an interface where a RIP-1 router may hear and operate on the information in a RIP-2 routing entry the following rules apply: 1) information internal to one network must never be advertised into another network, 2) information about a more specific subnet may not be advertised where RIP-1 routers would consider it a host route, and 3) supernet routes (routes with a netmask less specific than the "natural" network mask) must not be advertised where they could be misinterpreted by RIP-1 routers. network 0 RUT network 1 Part A: Subnet Mask Processing 1. transmits a RIP Response with 3 RTEs. Each RTE has a subnet mask value of There is one entry each for a Class A, Class B, and Class C network. 2. Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the triggered response transmitted by the RUT on its other interfaces should include the newly learned routes with subnet mask values appropriate to the natural network number. Possible Problems: If the RUT does not include the generated subnet mask value in its response packets, it will be necessary to check the routing table to verify the results. ROUTING CONSORTIUM 7 RIPv2 Operations Test Suite

16 Test RIP.1.4: Default Route Processing Purpose: To verify that a router learns default routes. References: [1812] Section [2453] Section 3.7 Discussion: The special address is used to describe a default route. A default route is defined as a route to all networks for which there are no explicit routes. It is by definition the route whose prefix length is zero. A default route is used when it is not convenient to list every possible network in the RIP updates, and when one or more closely-connected routers in the system are prepared to handle traffic to the networks that are not listed explicitly. These routers should create RIP entries for the address , just as if it were a network to which they are connected. The decision as to how routers create entries for is left to the implementor. Most commonly, the system administrator will be provided with a way to specify which routers should create entries for ; however, other mechanisms are possible. For example, an implementor might decide that any router which speaks BGP should be declared to be a default router. It may be useful to allow the network administrator to choose the metric to be used in these entries. If there is more than one default router, this will make it possible to express a preference for one over the other. The entries for are handled by RIP in exactly the same manner as if there were an actual network with this address. System administrators should take care to make sure that routes to do not propagate further than is intended. Generally, each autonomous system has its own preferred default router. Thus, routes involving should generally not leave the boundary of an autonomous system. The mechanisms for enforcing this are not specified in this document. network 0 RUT network 1 TR2 Part A: No Subnet Mask Provided 1. transmits a RIP Response with one RTE indicating a default route. The subnet mask value is Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Subnet Mask Provided 4. transmits a RIP Response with one RTE indicating a default route. The subnet mask value is Observe the packets transmitted by the RUT. 6. transmits a RIP Response for the routes learned in this test with a metric of 16. Part C: Default Route Updated 7. transmits a RIP Response with one RTE indicating a default route. 8. TR2 transmits a RIP Response with one RTE indicating a default route. 9. Observe the packets transmitted by the RUT and the RUT s routing table. 10. and TR2 transmit RIP Responses for the routes learned in this test with a metric of 16. ROUTING CONSORTIUM 8 RIPv2 Operations Test Suite

17 Part D: Default Route Originated Correctly 11. Configure a default route on the RUT. 12. Observe the packets transmitted by the RUT and the RUT s routing table. In Part A, the RUT should transmit a triggered response advertising the default route. In Part B, the RUT should not crash or generate invalid packets. In Part C, the default route should not be present twice in any RIP Responses sent by the RUT. In Part D, the RUT should propagate the default route as with a subnet mask of 0 bits. Possible Problems: None. ROUTING CONSORTIUM 9 RIPv2 Operations Test Suite

18 Test RIP.1.5: Infinite Metric Processing Purpose: To verify that a router behaves properly when the metric calculated for a route is 16. References: [2453] Section Discussion: Once the entry has been validated, update the metric by adding the cost of the network on which the message arrived. If the result is greater than infinity, use infinity. That is, metric = MIN (metric + cost, infinity) Now, check to see whether there is already an explicit route for the destination address. If there is no such route, add this route to the routing table, unless the metric is infinity (there is no point in adding a route which is unusable). network 0 RUT network 1 Part A: Metric Recalculated to transmits a RIP Response including a Route Entry with metric transmits a RIP Response with two RTEs. One RTE gives the route advertised in Step 1 with metric 15, the other gives a route that is not in the RUT s table, with metric Observe the packets transmitted by the RUT. 4. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Metric Recalculated to greater than Set the metric for one of the interfaces on the RUT to transmits a RIP Response including a Route Entry with metric 1 to the interface in Step transmits a RIP Response with two RTEs. One RTE gives the route advertised in Step 6 with metric 15, the other gives a route that is not in the RUT s table, with metric Observe the packets transmitted by the RUT. 9. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the RUT should transmit a triggered response giving the route that it learned in Step 1 with the newly calculated metric of 16. The other route present in the response transmitted in Step 2 should not be present in any response transmitted by the RUT. In Part B, the RUT should transmit a triggered response giving the route that it learned in Step 6 with the newly calculated metric of 16. The other route present in the response transmitted in Step 7 should not be present in any response transmitted by the RUT. Possible Problems: None. ROUTING CONSORTIUM 10 RIPv2 Operations Test Suite

19 Test RIP.1.6: Host Route Processing Purpose: To verify that a router identifies and processes host routes correctly. References: [2453] Section 3.7 Discussion: If every node on a given network or subnet is accessible through the same routers, then there is no reason to mention individual hosts in the routing tables. However, networks that include point-topoint lines sometimes require routers to keep track of routes to certain nodes. Whether this feature is required depends upon the addressing and routing approach used in the system. Thus, some implementations may choose not to support host routes. If host routes are not supported, they are to be dropped when they are received in response messages network 0 RUT network 1 Part A: Router Accepts Host Routes 1. transmits a RIP Response including a host route. 2. Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Router does not Accept Host Routes 4. Configure the RUT to not accept Host Routes. 5. transmits a RIP Response including a host route followed by a valid route. 6. Observe the packets transmitted by the RUT. 7. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the RUT should have learned the host route from the RIP Response, and should transmit a triggered response advertising it. In Part B, the RUT should not have learned the host route from the RIP Response. The valid route that follows should be processed normally. Host routes should not be present in any RIP Responses transmitted by the RUT. Possible Problems: None. ROUTING CONSORTIUM 11 RIPv2 Operations Test Suite

20 Test RIP.1.7: Version Number Processing Purpose: To verify that a router obeys the rules for processing RIP messages of versions other than 2. References: [2453] Section , 4.6, and 5.1 Discussion: Before processing the datagrams in detail, certain general format checks must be made. These depend upon the version number field in the datagram, as follows: 0 Datagrams whose version number is zero are to be ignored. These are from a previous version of the protocol, whose packet format was machine-specific. 1 Datagrams whose version number is one are to be processed as described in the rest of this specification. All fields that are described above as "must be zero" are to be checked. If any such field contains a non-zero value, the entire message is to be ignored. >1 Datagrams whose version number is greater than one are to be processed as described in the rest of this specification. All fields that are described above as "must be zero" are to be ignored. Future versions of the protocol may put data into these fields. Version 1 implementations are to ignore this extra data and process only the fields specified in this document. When generating RIP Responses, set the version number to either 1 or 2. The mechanism for deciding which version to send is implementation specific; however, if this is the Response to a Request, the Response version should match the Request version. In addition, routers should also implement a receive control switch which would determine whether to accept RIP-1 only, RIP-2 only, both, or none. It should also be configurable on a per-interface basis. It is recommended that the default be compatible with the default chosen for sending updates. If the receive control switch is set to both, a router should not accept a route whose version is other than 1 or 2. network 0 RUT network 1 Part A: Version 1 RIP Response 1. transmits a RIP version 1 Response including a Route Entry for some network. 2. Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Version 0 RIP Response 4. transmits a RIP version 0 Response including a Route Entry for some network. 5. Observe the packets transmitted by the RUT. 6. transmits a RIP Response for the routes learned in this test with a metric of 16. ROUTING CONSORTIUM 12 RIPv2 Operations Test Suite

21 Part C: Version 1 RIP Request 7. Configure the RUT to send out RIP-1 messages. 8. transmits a RIP version 1 Request including a Route Entry the RUT does not have. 9. Observe the packets transmitted by the RUT. Part D: Version 2 RIP Request 10. Configure the RUT to send out RIP-2 messages. 11. transmits a RIP version 2 Request including a Route Entry the RUT does not have. 12. Observe the packets transmitted by the RUT. In Part A, the RUT should have learned the version 1 route advertised. In Part B, the RUT should not have learned the version 0 routes advertised. In Part C, the RUT should respond with a RIP version 1 Response including the Route Entry with metric 16. In Part D, the RUT should respond with a RIP version 2 Response including the Route Entry with metric 16. Possible Problems: None. ROUTING CONSORTIUM 13 RIPv2 Operations Test Suite

22 Test RIP.1.8: Family Identifier Processing Purpose: To verify that a router properly handles RIP Responses that contain RTEs with Address Family Identifiers other than 2. References: [2453] Sections 3.6 and Discussion: For each of these message types, in version 1, the remainder of the datagram contains a list of Route Entries (RTEs). Each RTE in this list contains an Address Family Identifier (AFI), destination IPv4 address, and the cost to reach that destination (metric). The AFI is the type of address. For RIP-1, only AF_INET (2) is generally supported. Once the datagram as a whole has been validated, process the RTEs in the Response one by one. Again, start by doing validation. Incorrect metrics and other format errors usually indicate misbehaving neighbors and should probably be brought to the administrator's attention. For example, if the metric is greater than infinity, ignore the entry but log the event. The basic validation tests are: - is the destination address valid (e.g., unicast; not net 0 or 127) - is the metric valid (i.e., between 1 and 16, inclusive) If any check fails, ignore that entry and proceed to the next. Again, logging the error is probably a good idea. network 0 RUT network 1 Part A: Family Identifier Processing 1. transmits a RIP Response with one RTE that has the Address Family Identifier set to something other than transmits a RIP Response that has a mix of RTEs, one with Address Family Identifier 2, the others with Address Family Identifier set to something other than Observe the packets transmitted by the RUT. 4. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the only new route the RUT should have is the route with Address Family Identifier 2. The RUT should learn no other new routes during this test. Possible Problems: None. ROUTING CONSORTIUM 14 RIPv2 Operations Test Suite

23 Test RIP.1.9: Route Tags Processing Purpose: To verify that a router properly learns and re-advertises route tags. References: [2453] Section 4.2 Discussion: The Route Tag (RT) field is an attribute assigned to a route which must be preserved and readvertised with a route. The intended use of the Route Tag is to provide a method of separating "internal" RIP routes (routes for networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an EGP or another IGP. Routers supporting protocols other than RIP should be configurable to allow the Route Tag to be configured for routes imported from different sources. For example, routes imported from EGP or BGP should be able to have their Route Tag either set to an arbitrary value, or at least to the number of the Autonomous System from which the routes were learned. Other uses of the Route Tag are valid, as long as all routers in the RIP domain use it consistently. This allows for the possibility of a BGP-RIP protocol interactions document, which would describe methods for synchronizing routing in a transit network. TR2 network 0 RUT network 1 Part A: RUT Preserves Route Tags 1. transmits a RIP Response including several RTEs, each with a different route tag. 2. Observe the packets transmitted by the RUT. 3. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: RUT Preserves Route Tags in Updated RTEs 4. transmits a RIP Response including 2 RTEs, each with a route tag. 5. TR2 transmits a RIP Response for route 1, but with a lower metric and a different route tag. 6. Allow route 2 to expire, and then transmit a response from the same router used in Step 4, but with a different route tag. 7. Observe the packets transmitted by the RUT. 8. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the RUT should send out the routes advertised in a triggered response, and the route tag for each route should be included unchanged. In Part B, both routes should use the route tag from the most recent response. Possible Problems: None. ROUTING CONSORTIUM 15 RIPv2 Operations Test Suite

24 Test RIP.1.10: Triggered Response Processing Purpose: To verify that a router observes the rules regarding triggered responses. References: [2453] Section , Discussion: Experience shows that triggered updates can cause excessive load on networks with limited capacity or networks with many routers on them. Therefore, the protocol requires that implementors include provisions to limit the frequency of triggered updates. After a triggered update is sent, a timer should be set for a random interval between 1 and 5 seconds. If other changes that would trigger updates occur before the timer expires, a single update is triggered when the timer expires. The timer is then reset to another random value between 1 and 5 seconds. A triggered update should be suppressed if a regular update is due by the time the triggered update would be sent. Triggered updates do not need to include the entire routing table. In principle, only those routes which have changed need to be included. Therefore, messages generated as part of a triggered update must include at least those routes that have their route change flag set. They may include additional routes, at the discretion of the implementor; however, sending complete routing updates is strongly discouraged. When a triggered update is processed, messages should be generated for every directly-connected network. Split Horizon processing is done when generating triggered updates as well as normal updates (see section 3.9). If, after Split Horizon processing for a given network, a changed route will appear unchanged on that network (e.g., it appears with an infinite metric), the route need not be sent. If no routes need be sent on that network, the update may be omitted. Once all of the triggered updates have been generated, the route change flags should be cleared. The only difference between a triggered update and other update messages is the possible omission of routes that have not changed. The remaining mechanisms must be applied to all updates. network 0 RUT network 1 Part A: Triggered Response Only Includes Updated Routes 1. transmits a RIP Response including several routes. 2. transmits another RIP Response, giving a subset of the routes advertised in the first step with a higher metric. 3. Observe the packets transmitted by the RUT. 4. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: Rate of Triggered Responses Limited 5. transmits a RIP Response giving a route with metric 1. Every second thereafter, increment the metric and transmit the response packet again. Transmit the response a total of ten times. 6. Observe the packets transmitted by the RUT. 7. transmits a RIP Response for the routes learned in this test with a metric of 16. ROUTING CONSORTIUM 16 RIPv2 Operations Test Suite

25 In Part A, Step 2, the RUT should have sent a triggered response to all networks except the network to which is connected. The triggered response should include only the routes that changed as a result of the response sent in the previous step. The RUT should not transmit a triggered response on the network to which is connected, as no routes had changed due to split horizon/poisoned reverse processing. In Part B, the RUT should wait a random interval from 1 to 5 seconds between transmitting triggered responses. Possible Problems: None. ROUTING CONSORTIUM 17 RIPv2 Operations Test Suite

26 Test RIP.1.11: Route Timeout Processing Purpose: To verify that a router performs route timeout correctly. References: [2453] Section 3.8, Discussion: There are two timers associated with each route, a "timeout" and a "garbage-collection" time. Upon expiration of the timeout, the route is no longer valid; however, it is retained in the routing table for a short time so that neighbors can be notified that the route has been dropped. Upon expiration of the garbage-collection timer, the route is finally removed from the routing table. The timeout is initialized when a route is established, and any time an update message is received for the route. If 180 seconds elapse from the last time the timeout was initialized, the route is considered to have expired, and the deletion process described below begins for that route. Deletions can occur for one of two reasons: the timeout expires, or the metric is set to 16 because of an update received from the current router (see section for a discussion of processing updates from other routers). In either case, the following events happen: - The garbage-collection timer is set for 120 seconds. - The metric for the route is set to 16 (infinity). This causes the route to be removed from service. - The route change flag is set to indicate that this entry has been changed. - The output process is signaled to trigger a response. Until the garbage-collection timer expires, the route is included in all updates sent by this router. When the garbage-collection timer expires, the route is deleted from the routing table. Should a new route to this network be established while the garbage-collection timer is running, the new route will replace the one that is about to be deleted. In this case the garbage-collection timer must be cleared. Note that the deletion process is started only when the metric is first set to infinity. If the metric was already infinity, then a new deletion process is not started. network 0 RUT network 1 Part A: Route Deleted Due to Update or Timeout 1. transmits a RIP Response including RTEs for two routes. 2. transmits a RIP Response for one of the routes given in Step 1 with a metric of Wait more than 300 seconds and observe the packets transmitted by the RUT. ROUTING CONSORTIUM 18 RIPv2 Operations Test Suite

27 Part B: Timeout Timer Restarted When Route Updated 4. transmits a RIP Response including a RTE for 1 route. 5. Wait 60 seconds. 6. transmits a RIP Response including the RTE sent in Step Wait more than 300 seconds and observe the packets transmitted by the RUT. Part C: Garbage-Collection Timer Stopped When Route Updated 8. transmits a RIP Response including a RTE for 1 route. 9. Wait 240 seconds. 10. transmits a RIP Response including the RTE sent in Step Wait more than 300 seconds and observe the packets transmitted by the RUT. Part D: Deletion Process not Restarted 12. transmits a RIP Response including a RTE for 1 route. 13. transmits a RIP Response including the RTE sent in Step 12 with a metric of Wait 60 seconds. 15. transmits a RIP Response including the RTE sent in Step 12 with a metric of Wait more than 120 seconds and observe the packets transmitted by the RUT. In Part A, the RUT should transmit a triggered response for the route that was expired after the RIP Response in Step 2 is received. It should also be included in periodic responses with metric 16 for 120 seconds after its expiration. The route that was not updated by Step 2 should expire after 180 seconds from Step 1 and be included in periodic RIP Responses with metric 16 for 120 seconds. In Part B, Step 5, the RUT should advertise the learned route for 60 seconds. In Step 6, the timeout timer for the entry created in Step 4 should be restarted. In Step 7, the RUT should advertise the learned route with the appropriate metric for 180 seconds from when the RIP Response was transmitted in Step 6. The RUT should then advertise the learned route with a metric of 16 for 120 seconds. In Part C, Step 9, the RUT should advertise the learned route for 180 seconds. The RUT should then advertise the learned route with a metric of 16 for 60 seconds. In Step 10, the timeout timer should be restarted and the garbage-collection timer stopped. In Step 11, the RUT should advertise the learned route for 180 seconds from when the RIP Response was transmitted in Step 10. The RUT should then advertise the learned route with a metric of 16 for 120 seconds. In Part D, Step 13, the RUT should send a triggered response for the deleted route. In Step 14, the RUT should include the deleted route with a metric of 16 in its periodic updates. In Step 15, the RUT should not restart the garbage-collection timer. In Step 16, the RUT should only include the deleted route with a metric of 16 in its periodic updates for 60 additional seconds. Possible Problems: None. ROUTING CONSORTIUM 19 RIPv2 Operations Test Suite

28 Test RIP.1.12: Number of Entries Processing Purpose: To verify that a router handles responses that contains an unusual number of RTEs. References: [2453] Sections and Discussion: This section describes how a Response message is generated for a particular directly connected network: Set the version number to either 1 or 2. The mechanism for deciding which version to send is implementation specific; however, if this is the Response to a Request, the Response version should match the Request version. Set the command to Response. Set the bytes labeled "must be zero" to zero. Start filling in RTEs. Recall that there is a limit of 25 RTEs to a Response; if there are more, send the current Response and start a new one. There is no defined limit to the number of datagrams which make up a Response. A Request is used to ask for a response containing all or part of a router's routing table. A Request is processed entry by entry. If there are no entries, no response is given. There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In that case, a call is made to the output process to send the routing table to the requesting address/port. Except for this special case, processing is quite simple. Examine the list of RTEs in the Request one by one. For each entry, look up the destination in the router's routing database and, if there is a route, put that route's metric in the metric field of the RTE. If there is no explicit route to the specified destination, put infinity in the metric field. Once all the entries have been filled in, change the command from Request to Response and send the datagram back to the requestor. network 0 RUT network 1 Part A: RIP Response with no RTEs 1. transmits a RIP Response with no RTEs. 2. Observe the packets transmitted by the RUT. Part B: RIP Request with no RTEs 3. transmits a RIP Request with no RTEs. 4. Observe the packets transmitted by the RUT. Part C: Maximum Size Message Received 5. transmits a RIP Response with 25 valid RTEs. 6. transmits a RIP Request with the 25 valid RTEs given in Step Observe the packets transmitted by the RUT. 8. transmits a RIP Response for the routes learned in this test with a metric of 16. ROUTING CONSORTIUM 20 RIPv2 Operations Test Suite

29 Part D: More than 25 Entries Sent in Multiple Responses 9. transmits two RIP Responses, each with 20 valid RTEs. 10. Observe the packets transmitted by the RUT. 11. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, the empty response should not cause the RUT to generate any packets. In Part B, the empty request should not cause the RUT to generate any packets. In Part C, Step 5, the RUT should process the response with 25 routes as normal. All of the routes from the test packet should be added and should be present in the RUT s triggered response. In Step 6, the RUT should respond to the RIP Request with all 25 RTEs in one RIP Response. In Part D, the RUT should transmit multiple RIP Responses each containing a subset of its routing information for that network. Possible Problems: None. ROUTING CONSORTIUM 21 RIPv2 Operations Test Suite

30 Test RIP.1.13: Compatibility with v1 Switches Processing Purpose: To verify that a router behaves properly in each of the modes described for the v1 compatibility switch. References: [2453] Section 4.6, 5.1 Discussion: A compatibility switch is necessary for two reasons. First, there are implementations of RIP-1 in the field which do not follow RFC [1] (RFC-1058). Second, the use of multicasting would prevent RIP-1 systems from receiving RIP-2 updates (which may be a desired feature in some cases). This switch should be configurable on a per-interface basis. The switch has four settings: RIP-1, in which only RIP-1 messages are sent; RIP-1 compatibility, in which RIP-2 messages are broadcast; RIP-2, in which RIP-2 messages are multicast; and "none", which disables the sending of RIP messages. It is recommended that the default setting be either RIP-1 or RIP- 2, but not RIP-1 compatibility. This is because of the potential problems which can occur on some topologies. RIP-1 compatibility should only be used when all of the consequences of its use are well understood by the network administrator. For completeness, routers should also implement a receive control switch which would determine whether to accept RIP-1 only, RIP-2 only, both, or none. It should also be configurable on a per-interface basis. It is recommended that the default be compatible with the default chosen for sending updates. If a RIP-2 router receives a RIP-1 Request, it should respond with a RIP-1 Response. If the router is configured to send only RIP-2 messages, it should not respond to a RIP-1 Request. network 0 RUT network 1 Part A: Compatibility Switch 1. Configure the RUT to operate in RIP-1 Mode. Wait for the RUT to transmit a periodic response. 2. Observe the packets transmitted by the RUT. 3. Configure the RUT to operate in RIP-1 Compatible Mode. Wait for the RUT to transmit a periodic response. 4. Observe the packets transmitted by the RUT. 5. Configure the RUT to operate in RIP-2 mode. Wait for the RUT to transmit a periodic response. 6. Observe the packets transmitted by the RUT. ROUTING CONSORTIUM 22 RIPv2 Operations Test Suite

31 Part B: Receive Control Switch Accepts RIP-1 Only 7. Configure the RUT to accept only RIP-1 messages. Also configure the RUT to send out RIP-1 messages. 8. transmits a RIP version 2 Request for a Route Entry the RUT does not have. 9. transmits a RIP version 2 Response with a Route Entry. 10. transmits a RIP version 1 Request for a Route Entry the RUT does not have. 11. transmits a RIP version 1 Response with a Route Entry. 12. Observe the packets transmitted by the RUT. 13. transmits a RIP Response for the routes learned in this test with a metric of 16. Part C: Receive Control Switch Accepts RIP-2 Only 14. Configure the RUT to accept only RIP-2 messages. Also configure the RUT to send out RIP-2 messages. 15. transmits a RIP version 2 Request for a Route Entry the RUT does not have. 16. transmits a RIP version 2 Response with a Route Entry. 17. transmits a RIP version 1 Request for a Route Entry the RUT does not have. 18. transmits a RIP version 1 Response with a Route Entry. 19. Observe the packets transmitted by the RUT. 20. transmits a RIP Response for the routes learned in this test with a metric of 16. Part D: Receive Control Switch Accepts Both RIP-1 and RIP Configure the RUT to accept both RIP-1 and RIP-2 messages. Also configure the RUT to send out RIP-2 messages. 22. transmits a RIP version 2 Request for a Route Entry the RUT does not have. 23. transmits a RIP version 2 Response with a Route Entry. 24. transmits a RIP version 1 Request for a Route Entry the RUT does not have. 25. transmits a RIP version 1 Response with a Route Entry. 26. Observe the packets transmitted by the RUT. 27. transmits a RIP Response for the routes learned in this test with a metric of 16. In Part A, Step 1, the RUT should transmit RIP-1 Response Packets to the Subnet Broadcast Address. In Step 3, the RUT should transmit RIP-2 Response Packets to the Subnet Broadcast Address. In Step 5, the RUT should transmit RIP-2 Response Packets to the All RIP-2 Router Multicast Address. In Part B, Steps 8 and 9, the RUT should ignore the version 2 messages. In Steps 10 and 11, the RUT should process the version 1 messages normally. In Part C, Steps 15 and 16, the RUT should process the version 2 messages normally. In Steps 17 and 18, the RUT should ignore the version 1 messages. In Part D, Steps 22 and 23, the RUT should process the version 2 messages normally. In Step 24, the RUT should not respond to the RIP-1 Request. In Step 25, the RUT should process the version 1 message normally. Possible Problems: None. ROUTING CONSORTIUM 23 RIPv2 Operations Test Suite

32 Test RIP.1.14: Full Table Request Processing Purpose: To verify that a router responds properly to full table RIP Requests. References: [2453] Section Discussion: A Request is used to ask for a response containing all or part of a router's routing table. Normally, Requests are sent as broadcasts (multicasts for RIP-2), from the RIP port, by routers which have just come up and are seeking to fill in their routing tables as quickly as possible. However, there may be situations (e.g., router monitoring) where the routing table of only a single router is needed. In this case, the Request should be sent directly to that router from a UDP port other than the RIP port. If such a Request is received, the router responds directly to the requestor's address and port. The Request is processed entry by entry. If there are no entries, no response is given. There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table. In that case, a call is made to the output process to send the routing table to the requesting address/port. If the request is for a complete routing table, normal output processing is done, including Split Horizon. network 0 RUT network 1 TR2 Part A: Full Table Request Processing 1. transmits a RIP Response including a valid RTE. 2. transmits a RIP Response including a different valid RTE. 3. transmits a full table request on network transmits a full table request on network Observe the packets transmitted by the RUT. 6. and transmit RIP Responses for the routes learned in this test with a metric of 16. In Part A, Step 3, the RUT should transmit response packets, including all of its learned and configured routes. Split-horizon/poisoned reverse processing should be performed on the responses. Possible Problems: None. ROUTING CONSORTIUM 24 RIPv2 Operations Test Suite

33 Test RIP.1.15: Specific Route Request Processing Purpose: To verify that a router responds properly to specific RIP Requests. References: [2453] Section Discussion: Note that there is a difference in metric handling for specific and whole-table requests. If the request is for a complete routing table, normal output processing is done, including Split Horizon (see section 3.9 on Split Horizon). If the request is for specific entries, they are looked up in the routing table and the information is returned as is; no Split Horizon processing is done. It is assumed that a Request for specific networks is made only by diagnostic software, and is not used for routing. In this case, the requester would want to know the exact contents of the routing table and would not want any information hidden or modified. network 0 RUT network 1 Part A: RIP Request sent Multicast 1. transmits a RIP Response including one RTE. 2. transmits another RIP Response with a single RTE to the RUT s other interface. 3. transmits a specific multicast RIP Request for the RTEs given in the first two steps, as well as another route that the RUT does not have. 4. Observe the packets transmitted by the RUT. 5. transmits a RIP Response for the routes learned in this test with a metric of 16. Part B: RIP Request sent Unicast 6. transmits a RIP Response including one RTE. 7. transmits another RIP Response with a single RTE to the RUT s other interface. 8. transmits a specific unicast RIP Request for the RTEs given in the first two steps, as well as another route that the RUT does not have. 9. Observe the packets transmitted by the RUT. 10. transmits a RIP Response for the routes learned in this test with a metric of 16. In Parts A and B, in Steps 3 and 6, the RUT should transmit a response for the routes requested, filling in their metrics from its routing table. For the route that is not in its table a metric of 16 should be given. No Split-horizon/poisoned reverse processing should be done on this response; metrics should be given exactly as they are in the RUT s table. Possible Problems: None. ROUTING CONSORTIUM 25 RIPv2 Operations Test Suite