Checkpoint R65 Test PlanRevision 0.12009-10-14Author: Peng GongRevision History1‘FW MONITOR’ USAGE (7)2TEST SUITES (7)2.1R65I NSTALL &U NINSTALL (7)2.1.1Create a v3 vap-group with vap-count/max-load-count set >1, Confirm R65 and related HFA could beinstalled on all vap within vap-group successfully (7)2.1.2Create a v4 vap-group, confirm XOS would prompt correctly message and failure install would causeunexpected issue to system (9)2.1.3Create a v5 vap-group, confirm XOS would prompt correctly message and failure install would causeunexpected issue to system (10)2.1.4Create a v5_64 vap-group, confirm XOS would prompt correctly message and failure install wouldcause unexpected issue to system (11)2.1.5Try to install R65 on a v3 vap-group and abort the install process, confirm nothing is left afterwards122.1.6Reduce max-load-count down to 1, confirm only one Vap is allowed to run R65 accordingly (13)2.1.7Increase vap-count and max-load-count to maximum vap count and executing "application-update",confirm all the Vap are running R65 properly (14)2.1.8Reduce vap-count to 3, Confirm the surplus Vap is stopped from running R65 and related partitionsare removed from CPM (15)2.1.9Enable/Disable IPv6 in vap-group and w/o ipv6-forwarding, confirm R65 wouldn't be affected. (16)2.1.10Confirm the installed R65 could be stopped through CLI (17)2.1.11Confirm the installed R65 could be started through CLI (18)2.1.12Confirm the installed R65 could be restarted through CLI (18)2.1.13Confirm the installed R65 could be reconfigured through CLI (19)2.1.14Confirm checkpoint could be upgraded to R70 by CLI: application-upgrade (19)2.1.15Confirm R65 could run properly while reload vap-group totally (20)2.1.16Confirm R65 could run properly while reload all chassis totally (20)2.1.17Create 2 vap groups, install R65 on both. Confirm R65 are running on both vap-groups without anymutual impact. (21)2.1.18Confirm configure operation couldn't be allowed if some Vap don't run R65 properly. (23)2.1.19Confirm uninstall/Configure operation couldn't be allowed if some Vap don't run properly. (24)2.1.20Confirm start/stop/restart operation could works prope rly if R65 doesn’t run properly on someVaps.252.1.21Confirm configure operation couldn't be allowed if vap-count>max-load-count causing some Vapdon't run properly (26)2.1.22Confirm uninstall operation couldn't be allowed if vap-count>max-load-count causing some Vapdon't run properly (27)2.1.23Confirm start/stop/restart operation couldn't be allowed if vap-count>max-load-count causingsome Vap don't run properly (28)2.1.24Confirm R65 could be uninstalled from vap-group (29)2.1.25Confirm R65 installation package could be remove from XOS by CLI: application-remove (30)2.2C HECKPOINT F EATURES (31)2.2.1Create GW and Set SIC, get topology from Smart Dashboard (31)2.2.2Configure Policy and push policy (31)2.2.3Confirm R65 could be started/stoped/restarted by cp-command (32)2.2.4Confirm different kinds of rule actions could work - allow/drop/reject (33)2.2.5Verify different kinds of tracking actions could work properly - log/alert/account (33)2.2.6Verify static NAT and hide NAT work properly (34)2.2.7Verify default license is installed automatically (34)2.2.8Verify some usual fw commands output - fw ver -k/ fw ctl pstat/ fw tab/ fw stat/ cphaprob stat /fwfetch /fw unloadlocal / fwaccel stat (34)2.2.9Verify SXL status if enable/disable it (36)2.2.10Verify the log information in SmartViewer are displayed correctly. (37)2.2.11Verify the GW and its member information in SmartViewer are displayed correctly (37)2.2.12Define a VPN Community between two GW; Confirm traffic can pass (37)2.2.13Create a VPN client tunnel, make sure client can login and traffic is encrypted as it should (38)2.2.14Enabling/Disabling SXL during connections (39)2.2.15Fail over the active member during connections (39)2.3I NTERFACE T EST-T RAFFIC MIXED WITH IPV6 AND IPV4 (39)2.3.1Verify traffic pass through the interface without SXL - non vlan<--->vlan (tcp+udp+icmp) (39)2.3.2Verify traffic pass through the interface without SXL - mlt <---> vlan (tcp+udp+icmp) (40)2.3.3Verify traffic pass through the interface without SXL - mlt+vlan <---> vlan (tcp+udp+icmp) (41)2.3.4Verify traffic pass through the internal circuit interface (tcp+udp+icmp) (42)2.3.5Verify traffic pass through the interface with SXL - non vlan<--->vlan (tcp+udp+icmp) (42)2.3.6Verify traffic pass through the interface with SXL - mlt <---> vlan (tcp+udp+icmp) (43)2.3.7Verify traffic pass through the interface with SXL - mlt+vlan <---> vlan (tcp+udp+icmp) (44)2.4A PPLICATION M ONITOR (45)2.4.1Verify the application-monitor is enabled by default (45)2.4.2Verify the command "show application vap-group ..." could return correct app status whileapplication is stopped/restarted by hand (46)2.4.3Confirm the command "show application vap-group ..." could return correct app status whileapplication is stopped/restarted/started by CLI command (47)2.4.4Confirm the command "show application vap-group" could return correct app status while cpd/fwd iskilled in a vap(rsh to ap) (48)2.4.5Confirm the application-monitor could be disabled/enabled and the output of command "showapplication vap-group "is correct (49)2.4.6While Disabled: Stop Application, confirm the new and established flows couldn’t be impacted (50)2.4.7While Enabled: stop app on all VAPs using CLI, confirm that VAPs won’t server transmitting and newflows522.4.8While Enabled: Stop App on 1 VAP (rsh to vap), confirm only that AP won't receive new flows (52)2.4.9While Enabled: Use CLI to start app on all VAPs, confirm that all VAPs will server new flows (53)2.4.10While Enabled: Use CLI to Reload VAP Group, confirm they'll all receive new flows after reboot (53)2.4.11While Enabled: Start App on 1 VAP (rsh to vap), confirm it will receive new flows (54)2.4.12While Enabled: Reduce max-load-count to 1, confirm only this VAP will receive new flows (54)2.4.13While Enabled: Increase max-load-count to vap-count, confirm all VAPs will receive new flows .. 552.4.14While Enabled: Uninstall app, confirm all VAPs will receive new flows and "show application vap-group ..." could return correct app status . (55)2.5F AILOVER -NP/CP/VAP (56)2.5.1Reload all NPM, confirm the traffic could recover after NP is rebooted (56)2.5.2Reload a master NPM; confirm the traffic couldn't be impacted (56)2.5.3Reload other non-related npm; confirm the traffic couldn't be impacted. (57)2.5.4Reload all CPM, confirm the connected traffic couldn't be affected and new connection could be builtafter CPM is rebooted. (58)2.5.5Reload a master CPM, confirm the traffic couldn't be affected and secondary CPM switches to mastersuccessfully. (58)2.5.6Reload a secondary CPM, confirm the traffic couldn't be affected (59)2.5.7Redundancy mode: Reload master AP by CLI "reload module x"/"reload vap-group x y"; confirm thetraffic couldn't be affected and backup AP switches to master (59)2.5.8Redundancy Mode: Rsh to master AP and Reboot it by "reboot" command in Linux shell; confirm thetraffic couldn't be affected and backup AP switches to master (60)2.5.9Redundancy Mode: Reset master AP by cb script "cbs_reset_slot x"; confirm the traffic couldn't beaffected and backup AP switches to master (61)2.5.10Redundancy Mode: Disable master AP by CLI "configure module x disable"; confirm the trafficcouldn't be affected and backup AP switches to master. (62)2.5.11Redundancy Mode: Remove master AP from ap-list; confirm the allocated traffic could beredirected to secondary AP and secondary AP switch to master (62)2.5.12Redundancy Mode: Reload Vap-group totally; confirm the traffic could recover after APs arerebooted632.5.13Load Balance Mode: Rsh to an AP and Reboot it by "reboot" command in Linux shell; confirm theallocated traffic could be redirected to other AP. (63)2.5.14Load Balance Mode: Reload one AP by CLI "reload module x"/"reload vap-group x y", confirm theallocated traffic could be redirected to another AP. (64)2.5.15Load Balance Mode: Reset one AP by cb script "cbs_reset_slot x", confirm the allocated trafficcould be redirected to another AP. (64)2.5.16Load Balance Mode: Disable one AP by CLI "configure module x disable"; confirm the allocatedtraffic could be redirected to another AP. (65)2.5.17Load Balance Mode: Remove one AP from ap-list, confirm the allocated traffic could be redirectedto another AP (65)2.5.18Load Balance Mode: Reload the whole vap-group, confirm the traffic could be rebuilt afterrebooting.662.5.19Reload the whole XOS system; confirm the traffic could recover and system runs properly (66)2.5.20Re-power the chassis; confirm the traffic could recover and system runs properly after power on 67 2.6I NTERFACE R EDUNDANCY (67)2.6.1L3 Redundancy: configure interface with vlan and non-vlan on one NPM, make interface failover bydisable interface; Confirm traffic, passing through master interface, could be switched to backup interface. . 672.6.2L3 Redundancy: configure interface with vlan and non-vlan on two NPM, make interface failover byreloading NPM, the master interface locating at; Confirm traffic, passing through master interface, could be switched to backup interface (68)2.6.3Bridge-Mode Redundancy: Two interfaces in bridge mode, configure interface redundancy for bridgeinterface; Make interface failover by disable interface; Confirm traffic is passing through bridge from the backup interface (69)2.6.4Bridge-Mode Redundancy configure two interfaces with different vlan on two NPM, make interfacefailover by reloading NPM, the master interface locating at; Confirm traffic, passing through master interface, could be switched to backup interface. (70)2.6.5GroupInterface-Mode Bridge Redundancy: Two interfaces in bridge mode, configure interfaceredundancy for bridge interface; Make interface failover by disable interface; Confirm traffic is passing through bridge from the backup interface. (71)2.6.6GroupInterface-Mode Bridge Redundancy configure two interfaces with different vlan on two NPM,make interface failover by reloading NPM, the master interface locating at; Confirm traffic, passing through master interface, could be switched to backup interface. (73)2.7CP REDUNDANCY (74)2.7.1When Disk synchronization statistics is 100%, install/uninstall/application-update R65 in the primaryCPM; Confirm secondary CPM has also been install/uninstall/application-update automatically (74)2.7.2When Disk synchronization statistics is less than 100%, install/uninstall/application-update the R65 inthe primary CPM; Confirm the secondary CPM also has been install/uninstall/application-updateautomatically after synchronization is completed. (75)2.7.3Reboot or reload CP; Confirm checkpoint works without any impact and CP redundancy worksproperly (77)2.7.4When Disk synchronization statistics is 100%, push new policy to checkpoint and then make a cpfailover; Confirm the new policy also take effect in the new master CPM after the failover (78)2.8DBHA (78)2.8.1Active-Standy Mode: Configure and Disable non-vlan interface on Vrrp Master Xbox, confirm Vrrpfailover occurs properly and check out CHKP’s and XOS's logs for any errors or messages. (79)2.8.2Active-Standy Mode: Configure and Disable vlan interface on Vrrp Master Xbox, confirm Vrrp failoveroccurs properly and check out CHKP’s a nd XOS's logs for any errors or messages (81)2.8.3Active-Standy Mode: Configure and Disable mlt+vlan interface on Vrrp Master Xbox, confirm Vrrpfailover occurs properly and check out CHKP’s and XOS's logs for any errors or messages. (83)2.8.4Active-Standy Mode: Enable the previous disabled interface, confirm the original Vrrp-master X-boxswitchs back master ownership and traffic are also switched back properly. (84)2.8.5Active-Standy Mode: Configure interface redundancy for Vrrp-master's interface, Disable Vrrp-master's interface, supporting traffic, confirm traffic are switching to Vrrp-master's backup interface and doesn't occur Vrrp failover between 2 X-box. (85)2.8.6Active-Standy Mode: Reload NPM on Vrrp-master's x-box, confirm Vrrp failover occurs properly andTraffic is switching to another X-box during the NPM is reloading (86)2.8.7Active-Standy Mode: Reload NPM on Vrrp-master's x-box; confirm Vrrp failover occurs properly,confirm Traffic and master ownership could be switched back original X-box after NPM is reloaded (86)2.8.8Active-Standby Mode: Reload vap-group on Vrrp-master's Xbox, confirm Vrrp failover occurs properlyand Traffic is switching to another X-box during the vap-group is reloading (87)2.8.9Active-Standby Mode: Reload vap-group on Vrrp-master's Xbox; confirm Vrrp failover occurs twiceproperly the master ownership could be switched back original X-box after vap-group is reloaded. (88)2.8.10Active-Standby Mode: Reload Master X-box fully, confirm Vrrp failover occurs properly and Trafficis switching to another X-box during the X-box is reloading. (88)2.8.11Active-Standby Mode: Reload Master X-box fully, confirm Vrrp failover occurs properly; confirmTraffic and master ownership could be switched back original X-box after Xbox is reloaded. (89)2.8.12Active-Active Mode: Disable interface on Vrrp Master Xbox, confirm Vrrp failover occurs properlyand check out CHKP’s and XOS's logs for any errors or messages (89)2.8.13Active-Active Mode: Configure and Disable vlan interface on Vrrp Master Xbox, confirm Vrrpfailover occurs properly (90)2.8.14Active-Active Mode: Configure and Disable mlt+vlan interface on Vrrp Master Xbox, confirm Vrrpfailover occurs properly (90)2.8.15Active-Active Mode: Enable the previous disabled interface, Confirm the master ownership couldbe switched back as interface recover (91)2.8.16Active-Active Mode: Configure interface redundancy for Vrrp-master's interface, Disable Vrrp-master's interface, supporting traffic; confirm traffic are switching to redundancy interface and doesn't occur Vrrp failover between 2 X-box. (92)2.8.17Active-Active Mode: Reload NPM on Vrrp-master's x-box, confirm Vrrp failover occurs properly andTraffic is switching to another X-box during the NPM is reloading (92)2.8.18Active-Active Mode: Reload NPM on Vrrp-master's x-box; confirm Vrrp failover occurs properly,confirm Traffic and master ownership could be switched back original X-box after NPM is reloaded (93)2.8.19Active-Active Mode: Reload vap-group on Vrrp-master's Xbox, confirm Vrrp failover occursproperly and Traffic is switching to another X-box during the vap-group is reloading. (93)2.8.20Active-Active Mode: Reload vap-group on Vrrp-master's Xbox; confirm Vrrp failover occursproperly, confirm Traffic and master ownership could be switched back original X-box after vap-group is reloaded.942.8.21Active-Active Mode: Reload Master X-box fully, confirm Vrrp failover occurs properly and Traffic isswitching to another X-box during the chassis is reloading (94)2.8.22Active-Active Mode: Reload Master X-box fully, confirm Vrrp failover occurs properly , confirmTraffic and master ownership could be switched back original X-box after Xbox is reloaded. (94)2.9S TRESS &N EGATIVE (95)2.9.1Valid traffic mix TCP/UDP (HTTP/FTP pass/FTP act/ICMP/RTSP/TFTP/IMAP) small rates (10-100cons/sec) (95)2.9.2Valid traffic mix TCP/UDP (HTTP/FTP pass/FTP act/ICMP/RTSP/TFTP/IMAP) high rates (1000-5000cons/sec) (95)2.9.3Invalid IP packets (bad checksum, wrong IP version, etc, use isic, targa3); make sure non system errorsuch as module crash (96)2.9.4Short run (minutes to hours) (96)2.9.5Fragmented traffic (97)2.9.6Over-night test (12 hours) (97)2.9.7Over-weekend test (60 hours) (97)2.9.8UDP, TCP traffic (98)2.9.9Administration operations during the traffic (98)2.9.10Check for memory leaks during the tests. (98)2.9.11Performance test, via Sprirent (99)1‘Fw monitor’ usage1)Firewall is located between NIC and IP stac k. It doesn’t use promiscuous mode tocapture packets.2)In contrast to tcpdump, ‘Fw monitor’ can capture packets at several different point,it doesn’t use promiscuous mode.3) 4 capture pointsNIC --------- FW -------- IP --------- TCP --------- App|forwardNIC --------- FW ---------IP --------- TCP --------- App4 capturing point for fw monitor: pre-inbound iPost-inbound IPre-outbound oPost-outbound Oi---->I ---- o----->O4)Different capture point ----→ -m 4pointsFw monitor -m IOFw monitor -m i5)Print packet raw date ----→ -xFw monitor -m i -x 52, 966)Different CP kernel module chain --→ -p (fw ctl chain)fw monitor insert its own module in the chain and capture packets at that place. (fwmonitor i/f side if it is started)fw monitor -pi -secxl_syncfw monitor -p all (all module places)7)Output to file --→ -oFw monitor -o dump.cap8)2Test Suites2.1R65 Install & Uninstall2.1.1Create a v3 vap-group with vap-count/max-load-count set >1, Confirm R65 andrelated HFA could be installed on all vap within vap-group successfully2.1.2Create a v4 vap-group, confirm XOS would prompt correctly message and failureinstall would cause unexpected issue to system2.1.3Create a v5 vap-group, confirm XOS would prompt correctly message and failureinstall would cause unexpected issue to system2.1.4Create a v5_64 vap-group, confirm XOS would prompt correctly message andfailure install would cause unexpected issue to system2.1.5Try to install R65 on a v3 vap-group and abort the install process, confirmnothing is left afterwards2.1.6Reduce max-load-count down to 1, confirm only one Vap is allowed to run R65accordingly2.1.7Increase vap-count and max-load-count to maximum vap count and executing"application-update", confirm all the Vap are running R65 properly2.1.8Reduce vap-count to 3, Confirm the surplus Vap is stopped from running R65and related partitions are removed from CPM2.1.9Enable/Disable IPv6 in vap-group and w/o ipv6-forwarding, confirm R65wouldn't be affected.2.1.10Confirm the installed R65 could be stopped through CLI2.1.11Confirm the installed R65 could be started through CLI2.1.12Confirm the installed R65 could be restarted through CLI2.1.13Confirm the installed R65 could be reconfigured through CLI2.1.14Confirm checkpoint could be upgraded to R70 by CLI: application-upgrade2.1.15Confirm R65 could run properly while reload vap-group totally2.1.16Confirm R65 could run properly while reload all chassis totally2.1.17Create 2 vap groups, install R65 on both. Confirm R65 are running on both vap-groups without any mutual impact.2.1.18Confirm configure operation couldn't be allowed if some Vap don't run R65properly.2.1.19Confirm uninstall/Configure operation couldn't be allowed if some Vap don't runproperly.2.1.20Confirm start/stop/restart operation could works properly if R65 doesn’t runproperly on some Vaps.2.1.21Confirm configure operation couldn't be allowed if vap-count>max-load-countcausing some Vap don't run properly.2.1.22Confirm uninstall operation couldn't be allowed if vap-count>max-load-countcausing some Vap don't run properly.2.1.23Confirm start/stop/restart operation couldn't be allowed if vap-count>max-load-count causing some Vap don't run properly.2.1.24Confirm R65 could be uninstalled from vap-group2.1.25Confirm R65 installation package could be remove from XOS by CLI: application-remove2.2Checkpoint Features2.2.1Create GW and Set SIC, get topology from Smart Dashboard2.2.2Configure Policy and push policy2.2.3Confirm R65 could be started/stoped/restarted by cp-command2.2.4Confirm different kinds of rule actions could work - allow/drop/reject2.2.5Verify different kinds of tracking actions could work properly - log/alert/account2.2.6Verify static NAT and hide NAT work properly2.2.7Verify default license is installed automatically2.2.8Verify some usual fw commands output - fw ver -k/ fw ctl pstat/ fw tab/ fw stat/cphaprob stat /fw fetch /fw unloadlocal / fwaccel stat2.2.9Verify SXL status if enable/disable it2.2.10Verify the log information in SmartViewer are displayed correctly.2.2.11Verify the GW and its member information in SmartViewer are displayedcorrectly.2.2.12Define a VPN Community between two GW; Confirm traffic can pass2.2.13Create a VPN client tunnel, make sure client can login and traffic is encrypted asit should2.2.14Enabling/Disabling SXL during connections2.2.15Fail over the active member during connections2.3Interface Test- Traffic mixed with ipv6 and ipv42.3.1Verify traffic pass through the interface without SXL - non vlan<--->vlan(tcp+udp+icmp)2.3.2Verify traffic pass through the interface without SXL - mlt <---> vlan(tcp+udp+icmp)2.3.3Verify traffic pass through the interface without SXL - mlt+vlan <---> vlan(tcp+udp+icmp)2.3.4Verify traffic pass through the internal circuit interface (tcp+udp+icmp)2.3.5Verify traffic pass through the interface with SXL - non vlan<--->vlan(tcp+udp+icmp)2.3.6Verify traffic pass through the interface with SXL - mlt <---> vlan (tcp+udp+icmp)2.3.7Verify traffic pass through the interface with SXL - mlt+vlan <---> vlan(tcp+udp+icmp)2.4Application Monitor2.4.1Verify the application-monitor is enabled by default2.4.2Verify the command "show application vap-group ..." could return correct appstatus while application is stopped/restarted by hand2.4.3Confirm the command "show application vap-group ..." could return correct appstatus while application is stopped/restarted/started by CLI command2.4.4Confirm the command "show application vap-group" could return correct appstatus while cpd/fwd is killed in a vap(rsh to ap)2.4.5Confirm the application-monitor could be disabled/enabled and the output ofcommand "show application vap-group "is correct2.4.6While Disabled: Stop Application, confirm the new and established flowscouldn’t be impacted。
