Patent Publication Number: US-10764169-B2

Title: Methods, systems, and computer readable media for testing virtual network components deployed in virtual private clouds (VPCs)

Description:
PRIORITY CLAIM 
     This application claims the priority benefit of Romanian Patent Application Serial No. a 2017 00803, filed on Oct. 9, 2017, the disclosure of which is incorporated herein by reference in its entirety. 
     TECHNICAL FIELD 
     The subject matter described herein relates to network testing virtual network components. More particularly, the subject matter described herein relates to testing virtual network components deployed in VPCs. 
     BACKGROUND 
     A virtual private cloud is a pool of computing resources within a public cloud that can be allocated to a cloud user and isolated from other users of the public cloud. When a user desires to test one or more virtual network components that operate within a VPC, one possibility for running the test is to instantiate a test agent within the same VPC as the component being tested (referred to herein as the device under test or (DUT)). However, one problem with deploying a test agent within the same VPC as the component being tested is that VPC resources consumed by the test agent are not available to the device under test. As a result, the presence of the test agent in the same VPC as the DUT can affect results of the test. 
     Accordingly, there exists a need for an improved method for testing virtual network components deployed in VPCs. 
     SUMMARY 
     The subject matter described herein includes methods, systems, and computer readable media for testing virtual network components deployed in virtual private clouds. One method includes deploying a test agent in a first VPC. The method further includes establishing a VPC peering connection with a device under test (DUT) deployed in a second VPC separate from the first VPC. The method further includes transmitting test traffic from the test agent to the DUT over the VPC peering connection. 
     A system for testing a virtual network component deployed in a virtual private cloud (VPC) includes a test agent configured for deployment in a first VPC. The system further includes a testing as a service VPC peering connection manager for establishing a VPC peering connection with a device under test (DUT) deployed in a second VPC separate from the first VPC. The test agent transmits test traffic to the DUT over the VPC peering connection. 
     The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or computing platform or may be distributed across multiple devices or computing platforms. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The subject matter described herein will now be explained with reference to the accompanying drawings of which: 
         FIG. 1  is a network diagram illustrating an exemplary architecture for testing of a network component over a VPC peering connection; 
         FIG. 2  is a network and message flow diagram illustrating messaging for establishing a VPC peering connection for test purposes; 
         FIG. 3  is a flow chart illustrating an exemplary process performed by a testing over VPC peering connection request interface for requesting initiation of a test over a new VPC peering connection and exchanging test traffic over the connection; and 
         FIG. 4  is a flow chart illustrating exemplary steps performed by a testing as a service VPC connection manager in establishing a VPC connection and exchanging test traffic over the connection. 
     
    
    
     DETAILED DESCRIPTION 
     The subject matter described herein includes methods, systems, and computer readable media for testing virtual network components deployed in VPCs. In one example, rather than testing a network component using a test agent deployed in the same VPC as a DUT, the subject matter described herein involves deploying a test agent in a VPC separate from the VPC where the DUT resides, establishing a VPC peering connection between the VPCs, and transmitting test traffic to the DUT over the VPC peering connection. Such a test configuration avoids performance impacts on the DUT of deploying the test agent in the same VPC as the DUT. 
       FIG. 1  is a network diagram illustrating an exemplary architecture for testing of a network component over a VPC peering connection. Referring to  FIG. 1 , a test agent  100  is deployed in a testing as a service VPC  102  that is separate from a VPC  104  in which a DUT  106  is deployed. Test agent  100  may include a test traffic generator  108  for generating and transmitting test packets to DUT  106 , a packet receiver  110  for receiving packets from DUT  106 , and a performance monitor  112  for evaluating performance of DUT  106  based on the test packets transmitted to DUT  106  and packets received from DUT  106 . In one example, test agent  100  may implement stress testing of DUT  106  by transmitting packets at a configurable rate profile to DUT  106  for a configurable time period. In another example, test agent  100  may emulate a mix of real world applications, such as web browsers, social networking, email, and/or other applications to evaluate performance of DUT  106  under a realistic mix of application traffic. 
     Because test agent  100  and DUT  106  are located in separate VPCs, a mechanism to carry test traffic to and from DUT  106  needs to be established. In  FIG. 1 , this mechanism is a VPC peering connection  114 . In order to establish VPC peering connection  114 , a testing as a service over VPC peering connection manager  116  may be provided in testing as a service VPC  102 . Testing as a service VPC peering connection manager  110  may perform steps to establish a VPC peering connection between VPCs  102  and  104 . Each of VPCs  102  and  104  may include one or more physical processors  118  for executing the various network components described therein. 
     In VPC  104  in which DUT  106  resides, to support testing as a service over a VPC peering connection, a testing as a service over VPC peering connection request interface  120  is provided. Testing as a service over VPC peering request interface  120  is a user interface through which a user in tested VPC  104  can request initiation of a VPC peering connection with VPC  102  and also request specific tests to be run over the VPC peering connection. Testing as a service over VPC peering connection request interface  120  may be an application that is provisioned with contact information for testing as a service VPC  102  and with the IP address of testing as a service over VPC peering connection manager  116 . As stated above, examples of types of test that can be run over VPC peering connection  114  include stress tests, application traffic emulation tests, or any other type of test that involves the transmission of packet traffic over VPC peering connection  114  to DUT  106 . 
       FIG. 2  is a network and message flow diagram illustrating an exemplary process for establishing a VPC peering connection for the purpose of exchanging test traffic between VPCs. Referring to  FIG. 2 , in line  1  of the message flow diagram, tested VPC  104  transmits a request for initiation of a test over a new VPC peering connection to testing as a service VPC  102 . The request may be initiated by testing as a service over VPC peering connection request interface  120 . The request may contain the VPC ID and region of VPC  104 . The request may also include the classless inter-domain routing (CIDR) range of VPC  104 . The request may also identify the type of test(s) to be performed and the nodes or devices within VPC  104  to be tested. The tests may be identified by a selecting from a predefined menu of tests (stress tests, performance tests, etc.) or configuring a customized test. The nodes to be tested may be identified by IP address and port number or other suitable node identifier. 
     In line  2  of the message flow diagram, in response to receiving the test initiation request, VPC  102  generates and sends a VPC peering request to VPC  104 . The VPC peering request may be generated by testing as a service over VPC peering connection manager  116 . The VPC peering request may be addressed to the VPC ID and region extracted from the test initiation request in line  1 . Testing as a service over VPC peering connection request interface  120  receives the VPC peering request, and, in this example, accepts the VPC peering request. Accordingly, in line  3  of the message flow diagram, testing as a service request interface  120  transmits a VPC peering accept message to VPC  102 . 
     Testing as a service over VPC connection peering connection manager  116  of VPC  102  receives the VPC peering accept message, and, in response, notifies test agent  100  that the VPC peering connection has been established. In response to receiving notification that the VPC peering connection has been established, test agent  100  may transmit test traffic to DUT  106  over the VPC peering connection. DUT  106  may receive the test traffic and transmit traffic back to test agent  100  over VPC peering connection  114 . For example, if DUT  106  is a server, test agent  100  may stress test server by establishing a configured number of connections with the server and request downloads from the server over the connections. Performance monitor  112  may monitor performance of the server by tracking parameters such as latency and throughput of the downloads. 
     In another example, DUT  106  may be a router. Test agent  100  may have one group of ports that function as traffic sources for transmitting packets to the router and another group of ports that function as traffic destinations for the packets. Test agent  100  may transmit packets to the router over VPC peering connection  114 , and the router may route the packets back to test agent  100  over VPC peering connection  114 . Performance monitor  112  of test agent  100  may monitor performance parameters, such as latency, throughput, jitter, dropped packets, or other parameters associated with the routed packets. 
     In yet another example, DUT  106  may be a firewall or a network address translator. In such a case, test agent  100  may have some ports that are configured as traffic sources on a non-protected side of the firewall or NAT and another set of ports that are configured as traffic destinations on a protected side of the firewall or NAT. The traffic source ports may transmit test traffic to the firewall or NAT over VPC peering connection  114 , and the traffic destination ports on the protected side of the firewall or NAT may receive the test traffic that passes through the firewall or NAT. Performance monitor  112  may measure performance of the firewall or NAT based on the traffic that is allowed through the firewall or NAT and whether protected IP addresses are appropriately translated. 
       FIG. 3  is a flow chart illustrating exemplary steps that may be performed by testing as a service over VPC peering connection request interface  120  in requesting initiation of a test over a VPC peering connection, establishing the VPC peering connection, and receiving test packets transmitted over the VPC peering connection. Referring to  FIG. 3 , in step  300 , testing as a service over VPC peering connection request interface receives, from the user of tested VPC  104 , a request for initiation of a test over a new VPC peering connection. The request may be received via a graphical user interface where the user selects the type of test and configures parameters for the test. Examples of types of tests that may be selected include stress tests, application emulation tests, performance tests, etc. Examples of test parameters that may be configured include number of connections, traffic rate profile, application traffic mix, nodes in VPC  104  that are to be tested, etc. VPC peering may be transparent to the user of VPC  104  in that once the user configures the test parameters, testing as a service over VPC peering connection request interface  120  automatically initiates establishment of the VPC peering connection with testing as a service VPC  102 . 
     In step  302 , testing as a service over VPC peering connection request interface  120  transmits a request for initiation of a test over a new VPC peering connection to testing as a service VPC  102 . The request may include the VPC_ID, region, and CIDR range of VPC  104 . The request may also include the test parameters identifying the nodes to be tested, the type of test, and the configuration parameters for the test. Alternatively, the type of test and test parameters may be communicated to testing as a service VPC  102  after the VPC peering connection is established. 
     Based on the input received in step  302 , testing as a service VPC  102  may initiate a VPC peering request to VPC  104 . Accordingly, in step  304  and  306 , testing as a service over VPC peering connection request interface  120  waits for the VPC peering request from testing as a service VPC  102 . When testing as a service over VPC peering connection request interface  120  receives a VPC peering request, step  308 , testing as a service over VPC peering connection request interface  120  determines whether to accept the VPC peering request. Determining whether to accept the request may include checking whether the format of the request is valid, and whether the request originates from a VPC from which initiation of VPC peering was requested. If, in step  310 , the VPC peering request is accepted, control proceeds to step  310  where testing as a service over VPC peering connection request interface  120  transmits a VPC peering accept message to the VPC peering request initiator. The VPC peering accept message may be addressed to the VPC that transmitted the VPC peering request message, which in this case is testing as a service VPC  120 . 
     Once testing as a service over VPC peering connection request interface  120  transmits the VPC peering accept message, control proceeds to step  312  where testing as a service over VPC peering connection request interface  120  transitions to the VPC peering connection open state. In the VPC peering connection open state, if the test parameters were previously provided to testing as a service VPC  102 , testing as a service over VPC peering connection request interface  120  receives test traffic from test agent  100 , forwards the test traffic to DUT  106 , receives test traffic from DUT  106  and forwards the test traffic to test agent  100  over VPC peering connection  114  (step  314 ). If the test parameters were not previously provided to testing as a service VPC  102 , testing as a service over VPC request interface  120  may provide the test parameters to the testing as a service VPC  102  and then receive test traffic from testing as a service VPC  102  according to the configured test or tests. The VPC peering connection may remain open until the VPC peering connection is deleted by testing as a service VPC  102  or by testing as a service over VPC request interface  104 , or until either of VPCs  102  or  104  is deleted. 
       FIG. 4  is flow chart illustrating an exemplary process implemented by testing as a service over VPC peering connection manager  116  in establishing a VPC peering connection and exchanging test traffic over the connection. Referring to  FIG. 4 , in step  400 , testing as a service over VPC peering connection manager  116  receives a request for initiation of a test over a new VPC peering connection. The request may originate from VPC  104  where they DUT or DUTs reside. The request may include parameters for VPC peering, such as VPC_ID, CIDR, and region. The request may optionally include test parameters. Alternatively, the test parameters may be sent separately from the request to initiate a VPC peering connection. 
     In step  402 , testing as a service over VPC peering connection manager  116  determines whether to initiate VPC peering with the requesting VPC. This determination may be made based on whether the parameters in the request are valid and whether VPC peering is authorized with the requesting VPC. 
     In the request to initiate VPC peering is accepted, control proceeds to step  404  where testing as a service over VPC peering connection manager  116  transmits a VPC peering request to the originator of the request in step  400 . After transmitting the VPC peering request, in step  406  testing as a service VPC peering connection manager  116  enters a waiting for VPC peering accept state. In step  408 , testing as a service over VPC peering connection manager  116  determines whether a valid VPC peering accept has been received. If a valid VPC peering accept has not been received, control returns to step  406  where VPC peering connection manager remains in the waiting for VPC peering accept state. If a valid VPC peering accept has been received, control proceeds to step  410  where testing as a service over VPC peering connection manager  116  enters a VPC peering connection open state. In the VPC peering connection open state, testing as a service VPC peering connection manager  116  may notify test agent  100  of the availability of the VPC peering connection, and, in step  412 , if the tests are already configured, testing as a service over VPC peering connection manager  116  may exchange test traffic between the test agent and the DUT over the VPC peering connection. If the tests are not already configured, testing as a service over VPC connection manager  116  may receive the test configuration parameters from VPC  104 , initiate the requested tests, send test traffic to VPC  104 , receive responsive traffic from VPC  104 , and monitor test results. As stated above, the VPC peering connection may remain open until deleted by either of the VPCs or until either or both of the VPCs are deleted. 
     It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.