Veryx ATTEST TM. Sample Test cases Overview. Conformance Test Suite. Open Shortest Path First version 2 (OSPFv2)

Transcription

1 Veryx ATTEST TM Conformance Test Suite Open Shortest Path First version 2 (OSPFv2) Sample Test cases Overview Part Number: T / TCLS OSPFv /1.0

2 This page is intentionally left blank.

3 Introduction The Veryx ATTEST TM OSPFv2 Conformance test suite is designed to enable quick and efficient testing of the Open Shortest Path First version 2 (OSPFv2) Protocol as defined by IETF RFCs 1850, Veryx ATTEST TM OSPFv2 test suites contain over 350 test cases that comprehensively test for OSPF conformance and are grouped as follows: S. No Group Cases Sample Cases 1. OSPF Frame Format Group (FFG) OSPF Generic Packet Handling Group (PHG) OSPF Management Group (OMG) Interface State Machine (ISM) Neighbor State Machine (NSM) Route Calculation Group (RCG) Neighbor Data Structure (Information) Group (NDG) OSPF Neighbor Adjacency - Multi Access Group (NAM) LSDB Group (LDG) Virtual Link Group (VLG) OSPF Flooding Procedure Group (FPG) OSPF Router LSA Generation Group (RLG) OSPF Network LSA Generation Group (NLG) OSPF Summary LSA Generation Group (SLG) OSPF ASBR Summary LSA Generation Group (ASG) OSPF AS External LSA Generation Group (ALG) OSPF LS Acknowledgement Generation Group (LAG) 6 - Total Copyright Veryx Technologies. Page 1

4 The following is a listing of the OSPFv2 sample test cases. List of sample test cases 1. Encoding of OSPF Hello PDU - Multi-access (Broadcast) interface To verify that a System on a Multi Access (Broadcast) interface transmits OSPF Hello messages in the correct format. Checking that a) the following OSPF Header fields have correct information 1) OSPF Protocol Version field 2) Packet field 3) Packet Length field 4) Router ID field 5) Area ID field 6) Checksum field 7) Authentication and Authentication fields b) the following Hello protocol related fields have correct information 1) Network Mask 2) Hello Interval 3) Options 4) Router Priority 5) Router Dead Interval 6) Designated Router 7) Backup Designated Router 8) Neighbors c) the following IP Header fields have correct information 1) Destination IP Address field 2) Source IP Address field. RFC 2328 Sec 8.1 (page 58-60), Appendix A.3.1, A.3.2 FFG_001 Copyright Veryx Technologies. Page 2

5 2. Encoding of OSPF Router LSA - Multi-access (Broadcast) interface To verify that a System on a Multi Access (Broadcast) interface transmits Router LSAs in the correct format. Checking a) that the following OSPF Header fields have correct information 1) OSPF Protocol Version field 2) Packet field 3) Packet Length field 4) Router ID field 5) Area ID field 6) Checksum field 7) Authentication and Authentication fields b) that the following Router LSA information fields have correct information 1) LS Age 2) Options 3) LS 4) Link State ID 5) Advertising Router 6) LS Sequence Number 7) LS Checksum 8) Length 9) VEB bits 10) Number of Links c) the following information for each link 1) Link ID 2) Link Data 3) 4) Number of Tos information 5) Metric 6) of Tos 7) Tos Metric d) the following IP Header fields have correct information 1) Destination IP Address field 2) Source IP Address field. RFC 2328 Sec 8.1 (page 58-60), Appendix A.3.1, A.4.2 FFG_004 Copyright Veryx Technologies. Page 3

6 3. Encoding of OSPF AS External LSA - Multi-access (Broadcast) interface To verify that a System on a Multi Access (Broadcast) interface transmits Network Summary LSAs in the correct format. Checking that a) the following OSPF Header fields have correct information 1) OSPF Protocol Version field 2) Packet field 3) Packet Length field 4) Router ID field 5) Area ID field 6) Checksum field 7) Authentication and Authentication fields b) the following AS External LSA fields have correct information 1) LS Age 2) Options 3) LS 4) Link State ID 5) Advertising Router 6) LS Sequence Number 7) LS Checksum 8) Length c) the following External LSA related fields have correct information 1) TOS 0 E bit field, 2) TOS 0 field 3) TOS 0 Metric 4) Forwarding Address 5) External Route Tag 6) Additional TOS s and TOS Metrics, Forwarding Address and External Route Tag d) the following IP Header fields have correct information 1) Destination IP Address field 2) Source IP Address field. RFC 2328 Sec 8.1 (page 58-60), Appendix A.3.1, A.4.5 FFG_008 Copyright Veryx Technologies. Page 4

7 4. Encoding of OSPF LS Request - Multi-access (Broadcast) interface To verify that a System on a Multi Access (Broadcast) interface transmits Link State Request packets in the correct format. Checking that a) the following OSPF Header fields have correct information 1) OSPF Protocol Version field 2) Packet field 3) Packet Length field 4) Router ID field 5) Area ID field 6) Checksum field 7) Authentication and Authentication fields b) the following LSA related information fields have correct information 1) LS 2) Link State ID 3) Advertising Router c) the following IP Header fields have correct information 1) Destination IP Address field 2) Source IP Address field. 5. Invalid IP Protocol field To verify that a System discards OSPF PDUs received with invalid IP Protocol. 6. Invalid Neighbor - Broadcast Network/NBMA/Pt-to-MPt 7. Hello Pkt - Incorrect Network Mask (Broadcast Network) To verify that a System discards non- Hello OSPF PDUs received from a nonadjacent neighbor (i.e. the IP Source Address in the received packet does not match any of the valid neighbors associated with the received interface) To verify that a System discards OSPF Hello PDUs received with incorrect Network Mask i.e. the Network Mask present in the received OSPF Hello packet does not match the Network Mask associated with the received interface. RFC 2328 Sec 8.1 (page 58-60), Appendix A.3.1, A.3.4 RFC 2328 Sec 8.2 (page 61), Bullet item number 3 RFC 2328 Sec 8.2 (page 63), Bullet 9 FFG_009 PHG_003 PHG_015 RFC 2328 Sec 10.5 (page 96) PHG_017 Copyright Veryx Technologies. Page 5

8 8. Advertise Status as Enabled - Area Parameter To verify that a System supports the configuration of the Advertise status in an area for a set of IP subnetworks, check that the system generates a network summary LSA when its Advertise status is enabled and that it does not generate a network summary LSA when the Advertise status is disabled. 9. Interface Output Cost To verify that a System supports the assignment of non-zero interface output cost, check that the system generates Router LSAs with the configured interface cost 10. Interface-Loopback - Host Route 11. ISM State - Waiting to DR Other upon wait timer expiry (Eligible Router priority) 12. ISM State - Waiting to BDR upon Backupseen event (Higher priority Neighbor as BDR) To verify that the ISM state of a Loopback interface in a System stays at "Loopback" and the system indicates the Loopback interface's IP address as a host route with cost zero in its Router LSA To verify that a System's ISM associated with a non pt-to-pt interface moves to DR Other state from Waiting state upon Wait Timer expiry when there are other eligible routers for becoming a DR and BDR [State Waiting -> DROther] To verify that a System's ISM associated with non pt-to-pt interfaces moves to BDR state from Waiting state upon Backupseen event when there are other eligible routers for becoming a DR [State Waiting -> BDR] RFC 2328 Sec C.2 (page 221) RFC 2328 Sec C.3 (page 222), Sec (page 129) RFC 2328 Sec 9.1 (page 67, 68), Section Bullet 3 (page 129) OMG_004 OMG_007 ISM_002 RFC 2328 Sec 9.1 (page 69) ISM_005 RFC 2328 Sec 9.1 (page 73) ISM_009 Copyright Veryx Technologies. Page 6

9 13. DR election - Higher priority To verify that a System's ISM elects the router with the higher priority as DR, when more than one router/system claims to be the DR [State Waiting -> BDR] 14. NSM State - ExStart, System elected to be Master 15. NSM State - ExStart to 2- Way upon AdjOK? Event, AdjOk == FALSE 16. NSM State - Loading to ExStart upon SeqNumberMismatch event (DDP with Init bit set) 17. Neighbor IP address (Virtual Link) To verify that a System elects itself as the Master during the adjacency process when the system's Router ID is greater than the neighbor's Router ID and transmits the Init DDP packets with Master bit set to 1 To verify that a System's NSM associated with a non-nbma neighbor moves to 2-Way state from the ExStart state when an AdjOK? event (AdjOK == FALSE) is generated (associated) for the neighbor To verify that a System's NSM associated with a non-nbma neighbor moves to ExStart state from the Loading state when a SeqNumberMismatch event (DDP Packet with Init bit set) is generated (associated) for the neighbor To verify that a System maintains a neighbor's IP address i.e. learns the neighbor's IP address during the routing table build process, when the associated neighbor is reachable on a virtual link, and maintains the learnt information in its neighbor data structure RFC 2328 Sec 9.4 Subsection 3 (page 76) ISM_010 RFC 2328 Sec 10.3 (page 91) NSM_011 RFC 2328 Sec 10.3 (page 93) NSM_029 RFC 2328 Sec 10.3 (page 93) NSM_034 RFC 2328 Sec 10 (page 81) NDG_006 Copyright Veryx Technologies. Page 7

10 18. Neighbor - non Empty, Empty LS Retransmission List 19. Network route non directly attached - Intra Area Route, Next hop 20. Transit Vertex - Network - LSA does not exist 21. Stub Network - Unreachable Router LSA 22. (Multi Access Network) Neighbor unreachable To verify that a System maintains a neighbor's Link State Retransmission list such that 1) the retransmission list is non empty when the System floods LSAs and they are not acknowledged by the neighbor 2) the retransmission list is empty when the System floods LSAs and they are acknowledged by the neighbor To verify that a System's OSPF routing table inherits the set of next hops from the parent vertex (during the SPF calculation) for an intra area route to a network when the network is not directly connected to the system. To verify that a System's OSPF SPF calculation ignores the link information associated with a Link W (Network) in a Vertex V when the LSA associated with W does not exist in the System's LS database associated with Area A. To verify that a System's OSPF SPF calculation ignores the Stub link information in a router LSA (LSA associated with router R) when the router is unreachable and a valid router LSA associated with R exists in the System's LS database associated with Area A To verify that a System transmitted OSPF Hello Packet does not contain neighbor information when a neighbor becomes unreachable (no longer detected) over a multi access interface RFC 2328 Sec 10 (page 82) NDG_010 RFC 2328 Sec (page 168), Sec 16 Bullet 2 (page 160) RFC 2328 Sec 16.1 Bullet 2.b (page 163) RFC 2328 Sec 16.1 Bullet 5 (page 166) RFC 2328 Sec 9.5 (page 78), Section a.3.2 RCG_003 RCG_008 RCG_013 NAM_005 Copyright Veryx Technologies. Page 8

11 23. Removal of Received Prematurely Aged LSA from Database 24. Router LSA - end point of non-fully, fully adjacent virtual link 25. Router LSA - Link ID, LinkData - Virtual Link 26. Rcvd new Router LSA - not flooded on eligible (received Broadcast) interface, LSA rcvd from the DR 27. Rtr LSA LS Sequence Number - Incrementing 0x7fffffff To verify that a System removes immediately a prematurely aged LSA from its database when the LSA is no longer contained in any neighbor's Link State Retransmission list and none of the System's neighbors are in states Exchange or Loading To verify that a System generates a Router LSA for an Area A with 1) V bit not set, when the system is the end point of one or more non-fully adjacent virtual links having Area A as their transit area 2) V bit set, when the system is the end point of one or more fully adjacent virtual links having Area A as their transit area To verify that a System generates a Router LSA for the Backbone Area with the Link ID value equal to the Neighbor Router ID and the Link Data field value equal to the IP address of the associated router interface, when the link type is a Virtual Link To verify that a System does not flood a newly received instance of Router LSA associated with Area A over the received broadcast interface associated with Area A, when the new LSA was received from the DR To verify that a System originates a prematurely aged LSA for an earlier originated Router LSA when an attempt is made to increment the sequence number past the maximum value of 0x7fffffff RFC 2328 Sec 14.1 (page 157) RFC 2328 Sec (page 128) RFC 2328 Sec (page 128), Sec 15 Bullet 4 (page 159) RFC 2328 Sec 13.3 Step 3 (page 150) RFC 2328 Sec (page 120), Sec 14.1 (page 157) LDG_004 VLG_003 VLG_004 FPG_013 RLG_007 Copyright Veryx Technologies. Page 9

12 28. Network LSA Flooded only within its associated Area 29. Nwk LSA - LS Sequence Number - Incrementing 0x7fffffff 30. NSM LSA - LS Sequence Number - Incrementing 0x7fffffff To verify that a System floods its self originated Network LSAs only within the associated area and not into the other areas To verify that a System originates a prematurely aged LSA for an earlier originated Network LSA when an attempt is made to increment the sequence number past the maximum value of 0x7fffffff To verify that a System originates a prematurely aged LSA for an earlier originated Network Summary LSA when an attempt is made to increment the sequence number past the maximum value of 0x7fffffff 31. Newly attached to an area To verify that a System originates summary-lsas into the newly attached area for all pertinent intra-area and interarea routes in its routing table 32. ASM LSA - LSA Options (NonStub Area) 33. ASE LSA Options (Non Stub Area) To verify that a System sets the E bit in the LS Options field to 1 whenever it originates an ASBR Summary LSA associated with a Non Stub Area To verify that a System sets the E bit in the LS Options field to 1 whenever it originates an AS External LSA associated with a Non Stub Area RFC 2328 Sec (page 117) RFC 2328 Sec (page 120) RFC 2328 Sec (page 120) RFC 2328 Sec 12.4, bullet 7 (page 126) RFC 2328 Sec (page 117) RFC 2328 Sec (page 117), Sec 12.4, bullet 9 (page 126), Sec (page 140) NLG_002 NLG_007 SLG_007 SLG_016 ASG_001 ALG_001 Copyright Veryx Technologies. Page 10

13 About Veryx Technologies Veryx Technologies (formerly Net-O 2 Technologies) provides innovative Verification and Measurement Solutions for the global communications industry. ATTEST solutions verify networking equipment being used for Access, Carrier Ethernet, Data Center, Edge, Enterprise, Industrial and Security. The unique offerings from Veryx enable customers to reduce the time-required-to-test and enhance their time-to-market. Veryx ATTEST TM is the trademark of Veryx Technologies. All other trademarks of respective owners are acknowledged. E mail: info@veryxtech.com Web: Copyright Veryx Technologies. Page 11