Detailed test plan for EG-ADM-6: Control Network Disconnection Test

This page is GPO's working page for performing EG-ADM-6. It is public for informational purposes, but it is not an official status report. See GENIRacksHome/ExogeniRacks/AcceptanceTestStatus for the current status of ExoGENI acceptance tests.

Last substantive edit of this page: 2012-08-24

Page format

• The status chart summarizes the state of this test
• The high-level description from test plan contains text copied exactly from the public test plan and acceptance criteria pages.
• The steps contain things i will actually do/verify:
  • Steps may be composed of related substeps where i find this useful for clarity
  • Each step is either a preparatory step (identified by "(prep)") or a verification step (the default):
    • Preparatory steps are just things we have to do. They're not tests of the rack, but are prerequisites for subsequent verification steps
    • Verification steps are steps in which we will actually look at rack output and make sure it is as expected. They contain a Using: block, which lists the steps to run the verification, and an Expect: block which lists what outcome is expected for the test to pass.

Status of test

Step	State	Date completed	Open Tickets	Closed Tickets/Comments
1A
1B
1C

High-level description from test plan

In this test, we disconnect parts of the rack control network or its dependencies to test partial rack functionality in an outage situation.

Procedure

• Simulate an outage of geni.renci.org by inserting a firewall rule on the GPO router blocking the rack from reaching it. Verify that an administrator can still access the rack, that rack monitoring to GMOC continues through the outage, and that some experimenter operations still succeed.
• Simulate an outage of each of the rack head node and management switch by disabling their respective interfaces on the GPO's control network switch. Verify that GPO, ExoGENI, and GMOC monitoring all see the outage.

Criteria to verify as part of this test

• V.09. When the rack control network is partially down or the rack vendor's home site is inaccessible from the rack, it is still possible to access the primary control network device and server for recovery. All devices/networks which must be operational in order for the control network switch and primary server to be reachable, are documented. (C.3.b)
• VII.14. A site administrator can locate information about the network reachability of all rack infrastructure which should live on the control network, and can get alerts when any rack infrastructure control IP becomes unavailable from the rack server host, or when the rack server host cannot reach the commodity internet. (D.6.c)

Step 1: prevent 152.54.0.0/16 from sending traffic to the ExoGENI rack

Step 1A: baseline before simulating control network outage

Overview of Step 1A

Run all checks before performing the disconnection test, so that if something is already down, we won't be confused:

• Attempt to SSH to bbn-hn.exogeni.gpolab.bbn.com:

  ssh bbn-hn.exogeni.gpolab.bbn.com
  

• If SSH is successful, attempt to sudo on bbn-hn:

  sudo -v
  

• Browse to ​https://bbn-hn.exogeni.net/rack_bbn/ and attempt to login to nagios
• Run omni getversion and listresources against the BBN rack ORCA AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc listresources
  

• Run omni getversion and listresources against the BBN rack FOAM AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 listresources
  

• Verify that ​http://monitor.gpolab.bbn.com/connectivity/campus.html currently shows a successful connection from argos to exogeni-vlan1750.bbn.dataplane.geni.net

Step 1B: simulate a network problem

Overview of Step 1B

Using:

• On maple (lab subnet router), do:

  conf t
    ip access-list standard gst-4083-eg-adm-6
      deny 152.54.0.0 0.0.255.255
      permit any
    exit
    int gi 0/1.829
      ip access-group gst-4083-eg-adm-6 out
    exit
  exit
  

• Wait 5 minutes
• Attempt to SSH to bbn-hn.exogeni.gpolab.bbn.com:

  ssh bbn-hn.exogeni.gpolab.bbn.com
  

• If SSH is successful, attempt to sudo on bbn-hn:

  sudo -v
  

• Browse to ​https://bbn-hn.exogeni.net/rack_bbn/ and attempt to login to nagios
• Run omni getversion and listresources against the BBN rack ORCA AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc listresources
  

• Run omni getversion and listresources against the BBN rack FOAM AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 listresources
  

• Look at ​http://monitor.gpolab.bbn.com/connectivity/campus.html to see the status of the connection from argos to exogeni-vlan1750.bbn.dataplane.geni.net

Verify:

• Site admins should be able to login to bbn-hn and perform sudo operations
• Rack nagios should be available (though it may show some errors based on the disconnection, obviously)
• Rack ORCA and FOAM aggregates should respond to getversion and listresources
• Existing experiments should continue to run, and should be able to respond to dataplane traffic

Step 1C: undo the changes

Overview of Step 1C

Using:

• On maple (lab subnet router), do:

  conf t
    int gi 0/1.829
      no ip access-group gst-4083-eg-adm-6 out
    exit
    no ip access-list standard gst-4083-eg-adm-6
  exit
  

• Wait 5 minutes
• Attempt to SSH to bbn-hn.exogeni.gpolab.bbn.com:

  ssh bbn-hn.exogeni.gpolab.bbn.com
  

• If SSH is successful, attempt to sudo on bbn-hn:

  sudo -v
  

• Browse to ​https://bbn-hn.exogeni.net/rack_bbn/ and attempt to login to nagios
• Run omni getversion and listresources against the BBN rack ORCA AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:11443/orca/xmlrpc listresources
  

• Run omni getversion and listresources against the BBN rack FOAM AM:

  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 getversion
  omni -a https://bbn-hn.exogeni.gpolab.bbn.com:3626/foam/gapi/1 listresources
  

• Look at ​http://monitor.gpolab.bbn.com/connectivity/campus.html to see the status of the connection from argos to exogeni-vlan1750.bbn.dataplane.geni.net

Verify:

• Site admins should be able to login to bbn-hn and perform sudo operations
• Rack nagios should be available (though it may show some errors based on the disconnection, obviously)
• Rack ORCA and FOAM aggregates should respond to getversion and listresources
• Existing experiments should continue to run, and should be able to respond to dataplane traffic