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:
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.
(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
(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-3.0.3050-k9.pkg
Nortel 1050/1100 IOS V06_00.310, V07_05.350, V08_00.049 using PKI certificates and pre-shared password
keys
CISCO ASR1006 Various IOS versions
Building Video Systems
Interior Fixed Camera Panasonic WV-SFN531
360 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
CISCO IP phone 7942 sccp42.9-4-2-1s
Integrated Access Control System
Access Door Controller AMAG EN-2DBC
Master Intercom Station Stentofon SNOM 821 SIP
Video Intercom Substation Stentofon 1401110100 w/ surface mount box
Alarm Panel DSC PC 4020
Alarm Panel Comms Interface DSC TL250 T-LINK
Table 7-1 Existing equipment
8) TESTS
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
1 MD1 Architecture Section 3 Bidder is to setup devices as per the high level architecture. Bidder must demonstrate that the devices can be setup as per the architecture.
2 MD2 Port capability – access
switch only
Table 4-3
POE+ : support 24 ports Connect 24 POE+ devices to the access switch at 10/100/1000Mbps simultaneously, with only one single power supply connected to the switch.
Bidder must demonstrate that 24 ports are enabled and active at the same time.
3 MD3-MD4 Encryption – all switches Table 4-4 MACSec 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.
Bidder must demonstrate that the traffic is sent encrypted.
4 MD3 Encryption – all switches Table 4-4 IPSec (client) 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.
Bidder must demonstrate that the traffic is encrypted over the test network.
5 MD3 Encryption – core switch
only
Table 4-4
IPSec Site-to-site 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.
Bidder must demonstrate that the traffic is encrypted over the test network.
6 MD5 Throughput - all switches Table 4-3 Traffic generator -> Access 10G -> aggregation 10G -> core 10G -> traffic sniffer
Enable MACSec on access, aggregate and core switches. Use a traffic generator to generate 10G traffic over the data path.
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.
7 MD6 Resiliency – all switches Table 4-5
In-service software upgrade Perform a software upgrade to the switch while the network traffic is being generated. Bidder must demonstrate that the there is no packet loss higher than 0.1% during the software upgrade.
8 MD7 Redundancy – all
switches Table 4-5 hot-swap and power supply redundancy
Remove and then replace one power supply
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 Table 4-4 VLAN Tagging Create multiple VLANs on a trunk on both the access and aggregate switches. (Data and Voice VLAN)
Bidder must demonstrate that different VLAN traffic must not be able to communicate with each other.
12 MD11 Redundancy –
Aggregation and Core Table 4-5 Virtual Chassis (VC) Technology
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.
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.
13 MD12 Protocol and feature
interoperability Aggregation and core
Table 4-4 and table 4-5
Combination of features 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
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.
14 MD13 Interoperability with
existing network Core switch only
Table 4-4
MPLS, IPSEC 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.
Bidder must demonstrate that the traffic can go across the devices.
15 MD14 Quality of Service (QoS) –
all switches
Table 4-4
Classification/ traffic queuing / scheduling / congestion avoidance
Configure QoS with 4 queues with WFQ, WRR, RED, WRED. Configure one queue to be the strict priority queue.
Bidder must demonstrate that the routers/switches allow us to configure congestion avoidance mechanism with 4 queues, one of which is strict priority.
NAC SSC’s NAC test environment device be able to connect or be denied
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 Initials by GoC and Bidder Type Start of Notification End of Notification
Date Time Date Time Date Time Date Time
