Annex D TEST PLAN. Page 1 of 11

Transcription

1 Annex D TEST PLAN Page 1 of 11

2 1. CONTEXT Purpose The purpose of this document is to outline the test scenarios required to support the DND Carling Campus Local Area Network. Government of Canada (GoC) may require bidder(s) to submit their proposed equipment for testing in order to demonstrate that it is compliant with the technical requirements of this Request for Proposal. SCOPE The scope of this document is the testing of the functionalities of the bidder s proposed routers/switches to determine whether the proposed equipment meet the requirements for the Carling Campus Network design. 2. TEST PLAN OVERVIEW The test plan identifies how the key functionalities of the equipment proposed will be tested. The tests described herein will be conducted by the Government of Canada using test data. The areas of the product(s) that are to be tested are as follows: a. Architecture b. Port capability c. Encryption d. Throughput e. Resiliency f. Redundancy g. Traffic Isolation h. Protocol and feature interoperability i. Quality of Service j. User Authentication 3. RESPONSIBILITIES OF TEST PARTICIPANTS 3.1 Government of Canada's Responsibilities: a) Government of Canada shall notify the Bidder of the intent to test the proposed products. b) Government of Canada shall provide the test equipment to conduct the tests. Page 2 of 11

3 c) Government of Canada shall execute the tests as per this test plan. d) Government of Canada shall record the test results from each test. e) Government of Canada shall attempt to complete the testing within 10 working days of the receipt of the required equipment from the Bidder. f) Government of Canada shall notify the Bidder of any Technical or Administrative Faults. 3.2) Bidders' Responsibilities a) The Bidder shall provide products identical to those proposed in their proposal, within 10 working days of receipt of Government of Canada s notification of the intent to test the proposed products. The equipment shall be delivered to the address provided in the notification of the intent to test. b) The equipment provided by the Bidder for testing shall be equipped as described in Section 6 of this Test Plan. c) The Bidder shall provide the equipment for testing at no cost to Government of Canada. d) Two representatives of the Bidder may be present to observe the testing. e) The Bidder shall assist Government of Canada as requested to configure the equipment for each test. If the Bidder does not support Government of Canada as requested, and the equipment subsequently fails a test, the equipment shall be deemed non-compliant, and will receive no further consideration. In these circumstances, the Bidder shall have no right to claim that the equipment was incorrectly configured. f) The Bidder shall be responsible for the rectification of technical and/or administrative faults in accordance with the timeframe outlined in Section 3 below. 4. TESTING PROCEDURES AND SET-UP INSTRUCTIONS a) The Bidder must be able to pass all the tests described in section 7, below, within 10 working days after the start of the testing which shall be 9.00 am. on the first day of testing. b) Testing shall be conducted from 9:00 a.m. to 3:00 p.m., Monday to Friday local time at the testing site, with the exception of any local Federal Government and Provincial holidays. c) The Bidder shall deliver the equipment required to conduct the test to the testing site, on the first scheduled day of testing, as indicated in the notification of intent to test issued by Government of Canada. d) The following schedule will be followed during the first day of testing: (i) Delivery of all equipment shall be made on or after 8:30 a.m. on the morning of the first day of testing. (ii) Installation shall begin on or after 9:00 a.m. on the morning of the first days of testing. (iii) The tests described in section 7 below will start once the verification of the configuration is completed by all parties. Page 3 of 11

4 (iv) Government of Canada will connect all the necessary components as shown in the Test Configuration diagram below. The assistance of the Bidder's representative may be requested. (v) During the testing, all configuration of the equipment shall be managed by Government of Canada. The assistance of the Bidder's representative may be requested. (vi) Any proposed product that fails to meet the Technical Specifications as evidenced by the test results, shall be deemed non-compliant, and will receive no further consideration. (vii) Administrative Faults: In the event that the equipment delivered to the testing site is not properly configured, the Bidder shall be required to rectify the discrepancy within 24 hours of written notification. The resulting fault will be deemed an Administrative Fault. A maximum of one Administrative Fault shall be permitted. (viii) If the equipment, or its replacement, exhibits a second Administrative Fault, or if the Bidder fails to meet the 24 hour deadline to rectify the first Administrative Fault, the product shall be deemed non-compliant, and will receive no further consideration. (ix)in the event that the equipment does not function in accordance with the Technical Requirements of the RFP, or fails to execute the testing completely and accurately, the Bidder will be required to repair the equipment within 48 hours of notification. The resulting fault will be deemed a Technical Fault. A maximum of two (2) Technical Faults shall be permitted. If the Bidder fails to repair the product within 48 hours of notification of a Technical Fault, the product shall be deemed noncompliant, and will receive no further consideration. (x) If the equipment, or its replacement, exhibits a third Technical Fault, the product shall be deemed non-compliant, and will receive no further consideration. (xi) Notification of Fault: Notification of a Technical or Administrative Fault will be made to the Bidder's designated representative on site by the Contracting Authority and logged in the Testing Plan Tracking Report (see Annex D.) The 24 or 48-hour time windows for the Bidder's response will start immediately after notification. (xii) If the Bidder has met their obligation with respect to a specific test, but Government of Canada is, for any reason, unable to perform a specific test, the Bidder shall be exempt from the requirement for their equipment to be subject to the specific test. 5. COMPONENT REPLACEMENT (i)replacement of components (i.e. Network cards, controllers, etc.) is permitted in order to repair the equipment. The replaced components must be of the same manufacturer and model number as the component being replaced. The Bidder is permitted to change a specific component once during testing. (ii) Equipment that requires the replacement of the same component more than once during testing, shall be deemed non-compliant, and will receive no further consideration. (iii) Equipment requiring the replacement of more than 3 separate components during testing, shall be deemed non-compliant, and will receive no further consideration. 6. DEFINITIONS (i) Equipment: The proposed chassis, including the required ports, controllers, network cards, all required power supply units, and other components. Page 4 of 11

5 (ii) Product Setup: The setup of a product delivered to meet the requirements of the technical specifications of the RFP, and configured (with all necessary documentation, etc.) as per the demonstration instruction letter issued by Government of Canada (iii) Administrative Fault: This occurs when the product is not supplied and configured as per the demonstration instruction letter (e.g. Incorrect amount of ports, wrong network interface card, etc.). (iv) Technical Fault: This occurs when the product does not function in accordance with the technical requirements of the RFP or fails to execute the test suite completely and accurately (e.g. hardware failure, software or hardware incompatibilities, etc.). (v) Non-Compliance: Any product that fails to meet the technical specifications of the RFP. Examples of non-compliance include: less than mandatory number of ports; less than mandatory communication speed; less than mandatory expansion slots; cannot support mandatory protocol(s). (vi) Product Elimination: This occurs if the first Administrative Fault cannot be rectified within 24 hours or a second Administrative Fault occurs. It also applies when there is a Technical Fault that is not rectified within 48 hours, or if a third Technical Fault occurs. A Product Elimination will also occur if the system is found to be noncompliant to the specifications as stated in the technical specifications of the RFP. 7. EQUIPMENT UNDER TEST CONFIGURATION (i) The equipment to be provided by the bidder for the purposes of testing must be able to inter-operate with the following hardware and the associated software. Hardware Software version CISCO ASA firewall version 8.4 with PKI certificates, IP Sec tunnels using ESP-AES-256-SHA CISCO ASA firewall version 8.4, IP Sec tunnels using ESP-AES-256-SHA CISCO AnyConnect anyconnect-win k9.pkg Nortel 1050/1100 IOS V06_00.310, V07_05.350, V08_ using PKI certificates and pre-shared password keys CISCO ASR1006 Various IOS versions Building Video Systems Interior Fixed Camera Panasonic WV-SFN Degree Camera Panasonic WV-SWV481(360) Exterior PTZ Camera Panasonic WV-SW598 Site Video Systems Exterior Fixed Camera Panasonic WV-SFV631LT Exterior 360 Degree Camera Panasonic WV-SWV481 Exterior PTZ Camera Panasonic WV-SW598 Exterior MINI Camera Panasonic WV-SW115 Video Illuminator Raytec VAR-IPPOE w8-1 VoIP Page 5 of 11

6 CISCO IP phone 7942 Integrated Access Control System sccp s Access Door Controller AMAG EN-2DBC Master Intercom Station Stentofon SNOM 821 SIP Video Intercom Substation Stentofon w/ surface mount box Alarm Panel DSC PC 4020 Alarm Panel Comms Interface DSC TL250 T-LINK Table 7-1 Existing equipment 8) TESTS The tests described below will be conducted by Shared Services Canada using test data and not live client data information. The equipment configuration for the testing is shown in Figure 1, below. Page 6 of 11

7 Figure 1 Shared Service Canada test configuration Notes: i. Testing will be assessed against the mandatory deliverables located in Annex C. ii. All tests must be done with one (1) version of device Operating System (OS) for each layer (access, aggregation and core) with no patches allowed during the testing phase. The Bidder must choose their proper OS version that meets ALL requirements. iii. Devices listed in table 7-1 under section 7 might be used to verify the interoperability with bidder equipment during the testing phase. iv. Whether all the tests below will be performed are at the discretion of Government of Canada and will be determined at the time of the testing. Test Number Mandatory Deliverable What features and functions will be tested. What mandatory requirements in the Tech Spec will be tested. How will the mandatory requirements be tested. What is required to pass the test. Page 7 of 11

8 1 MD1 Architecture 2 MD2 Port capability access switch only 3 MD3-MD4 Encryption all switches 4 MD3 Encryption all switches 5 MD3 Encryption core switch only 6 MD5 Throughput - all switches Section 3 Table 4-3 POE+ : support 24 ports MACSec IPSec (client) IPSec Site-to-site Table 4-3 Traffic generator -> Access 10G -> aggregation 10G -> core 10G -> traffic sniffer 7 MD6 Resiliency all switches Table 4-5 In-service software upgrade 8 MD7 Redundancy all switches Table 4-5 hot-swap and power supply redundancy Bidder is to setup devices as per the high level architecture. Connect 24 POE+ devices to the access switch at 10/100/1000Mbps simultaneously, with only one single power supply connected to the switch. Enable MACSec on uplink ports and configure port-channels between access, aggregation, and core switches. Generate and inspect traffic on the links. Verify the traffic with a sniffer device. Enable MACSec on uplink ports between access, aggregation, and core switches. Build an IPSec tunnel between the workstation with an IPSec client to an ASA firewall using existing PKI. Generate and inspect traffic on the link. Verify the traffic with a sniffer device. Build an IPSec tunnel between the core device and an ASA firewall using existing PKI. Generate and inspect traffic on the link. Verify the traffic with a sniffer device. Enable MACSec on access, aggregate and core switches. Use a traffic generator to generate 10G traffic over the data path. Perform a software upgrade to the switch while the network traffic is being generated. Remove and then replace one power supply from each network node. Bidder must demonstrate that the devices can be setup as per the architecture. Bidder must demonstrate that 24 ports are enabled and active at the same time. Bidder must demonstrate that the traffic is sent encrypted. Bidder must demonstrate that the traffic is encrypted over the test network. Bidder must demonstrate that the traffic is encrypted over the test network. Bidder must demonstrate that the there is no packet loss higher than 0.1% between the access switch, the aggregation switch, and the core switch, over the test network. Bidder must demonstrate that the there is no packet loss higher than 0.1% during the software upgrade. Bidder must demonstrate that the there is no packet loss higher than 0.1% during a hot swap and a recovery. Bidder must also demonstrate that the there is no POE+ power loss (where applicable). Page 8 of 11

9 9 MD8 Redundancy Aggregation and core only Table 4-5 Redundant hot swappable management module Remove and then replace one management module from the device. Bidder must demonstrate that there is no packet loss higher than 0.1% during a hot swap and a recovery. 10 MD9 Redundancy core and aggregation Table 4-5 Verify system recoverability of a HA switch pair by: a. Failing a single device b. Failing both devices Bidder must demonstrate that there is no packet loss higher than 0.1% and there is no loss of configuration file during a failure and a recovery. 11 MD10 Traffic Isolation 12 MD11 Redundancy Aggregation and Core 13 MD12 Protocol and feature interoperability Aggregation and core 14 MD13 Interoperability with existing network Core switch only 15 MD14 Quality of Service (QoS) all switches 16 MD15 User Authentication VLAN Tagging Table 4-5 Virtual Chassis (VC) Technology and table 4-5 Combination of features MPLS, IPSEC Classification/ traffic queuing / scheduling / congestion avoidance Create multiple VLANs on a trunk on both the access and aggregate switches. (Data and Voice VLAN) Configure a Virtual Chassis pair and then a. Bring down the master switch in the VC. b. Bring back up the master switch in the VC. Must configure simultaneously the following across the infrastructure and send predefined amount of traffic across interfaces. Core: IPv6, OPSF, MACSEC, IPSEC, MPLS/Multi- VRF, virtual chassis Aggregation: IPv6, OPSF, MACSEC, MPLS/Multi-VRF, virtual chassis Configure MPLS and IPSEC between Core switch and existing Edge router. Generate traffic using a sniffer device from the Core switch to the Edge router. Configure QoS with 4 queues with WFQ, WRR, RED, WRED. Configure one queue to be the strict priority queue. Bidder must demonstrate that different VLAN traffic must not be able to communicate with each other. Bidder must demonstrate :- a. The secondary switch in the VC becomes the master after the master switch goes down. b. The master switch will come back as master and the secondary switch will go back to secondary when the master comes back up. Bidder must demonstrate that there is no packet loss higher than 0.1%. Bidder must also demonstrate that all routers/switches remain functional and all CPUs must stay within the normal operating ranges. Bidder must demonstrate that the traffic can go across the devices. Bidder must demonstrate that the routers/switches allow us to configure congestion avoidance mechanism with 4 queues, one of which is strict priority. Configure NAC on switches and integrate with Bidder must demonstrate that the Client Page 9 of 11

10 Page 10 of 11 NAC SSC s NAC test environment device be able to connect or be denied to the network based on the policy configured.

11 Annex E Test Reporting ANNEX E TESTING PLAN TRACKING REPORT ITSB Purchase Request xxx / RVD #xxx Test # Test Description Testing Started Notification of Fault Testing Ended Result Pass / Failed Type Start of Notification End of Notification Date Time Date Time Date Time Date Time Initials by GoC and Bidder Page 11 of 11