JP6302064B2 - System and method for testing a network using a controller - Google Patents

Description

[Cross-reference with related applications]
This application claims priority to US Patent Application Publication No. 14 / 085,538, filed November 20, 2013, which is incorporated herein by reference in its entirety.

  The present invention relates to a communication network, and more particularly to a communication network having a network switch controlled by a controller.

  Packet-based networks such as the Internet and local data networks connected to the Internet include network switches. The network switch is used when transferring a packet from a packet transmission source to a packet destination. A packet is sometimes called a frame.

  It may be difficult or impossible to control one vendor's switch using another vendor's device. This is because one vendor's switch device may use a different operating system and sequence of control procedures than another vendor's switch device. A cross-platform protocol was developed to address the challenges associated with controlling different types of switch platforms. These protocols allow centralized control of switches that should have been incompatible.

  A switch in the network can include a cross-platform controller client. A controller client can communicate with a corresponding controller server via a network path. Since the controller client can be mounted on various switch hardware, a switch device that should have been incompatible can be controlled by a single controller.

  It may be difficult for the controller to efficiently control the switch network. For example, the network topology may be changed by a network administrator or due to a device failure. In this scenario, changes to the network can invalidate the controller settings. Therefore, it would be desirable to improve the controller's capabilities.

  A controller can control switches such as physical switches and software switches in the network. This controller can create virtual switches from end host groups. Each virtual switch can have a virtual port assigned to a respective end host. The controller can generate a virtual network topology from the virtual switch.

  The controller can receive one or more network policy rules that manage network traffic through the switch. Network policy rules can be defined for each virtual port to manage network traffic flowing through the virtual port. For a given network policy rule, the controller can test to determine if the network meets the network policy rule. This test can be based on test rules received by the controller (eg, from a user). Test rules can identify test parameters and expected test results. The controller can generate a test packet based on the test parameters of the test rule. For example, the test packet may include source and destination end host information, or other header fields identified from test parameters.

  The controller can simulate packet traversal of test packets that traverse the virtual path of the virtual network topology. The controller can identify network policy rules triggered during the simulation. The controller can determine a series of switches that form the basic path of the virtual path. The controller can generate a flow table entry that implements the basic route without providing it to a series of switches (eg, so that the normal forwarding behavior of the network does not change during testing). The controller can determine whether the network meets the network policy rule based on a triggered network policy rule or a simulation result such as a switch that the test packet traverses.

  If necessary, the controller can tag the test packet and inject the tagged packet into the network. Tagging a test packet can be done by inserting identification information into the header field or encapsulating the test packet. The controller can provide the switch with a flow table entry that instructs the switch to send information about the tagged test packet to the controller. This information can identify which switch port received the tagged test packet. The flow table entry prevents the switch from forwarding a tagged test packet to the destination end host of the packet, assuring that testing of the network policy rules by the controller does not interfere with the normal operation of the end host. it can. Based on information from the switch, the controller can determine whether the network satisfies the expected result of the test rule and the corresponding network policy rule.

  Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and the following detailed description.

1 illustrates an exemplary network that includes a controller and a packet forwarding system, in accordance with an embodiment of the present invention. FIG. FIG. 3 illustrates a controller server and a controller client that can communicate over a network connection, according to an embodiment of the present invention. FIG. 3 illustrates an exemplary flow table of a type that can be used by a packet processing system according to an embodiment of the present invention. FIG. 3 illustrates an example flow table of a type that can be used by a packet processing system, showing three example packet forwarding types that can be performed based on flow table entries in the flow table, in accordance with an embodiment of the present invention. 4 is a flowchart illustrating exemplary steps associated with packet processing in a packet processing system, in accordance with an embodiment of the present invention. FIG. 2 illustrates an exemplary network including switches that can be controlled by a controller, in accordance with an embodiment of the present invention. FIG. 3 illustrates an exemplary virtual network that a controller can generate from a basic network, according to an embodiment of the present invention. FIG. 4 illustrates an exemplary access control list that can be implemented by a controller, in accordance with an embodiment of the present invention. FIG. 3 illustrates a first exemplary flow table entry that can be generated by a controller when implementing network policy rules, according to an embodiment of the present invention. FIG. 4 illustrates a second exemplary flow table entry that can be generated by a controller when implementing network policy rules, according to an embodiment of the present invention. FIG. 4 illustrates exemplary network policy rules that a controller can implement, according to embodiments of the present invention. FIG. 4 illustrates a scenario where a controller can change a virtual network according to an embodiment of the present invention. FIG. 3 illustrates an exemplary test rule that a controller can use when testing network policy rules, according to an embodiment of the present invention. 6 is a flowchart illustrating exemplary steps that a controller can perform when testing network policy rules, according to an embodiment of the present invention. 6 is a flowchart illustrating exemplary steps that a controller can perform when simulating a test packet to test network policy rules, according to an embodiment of the present invention. FIG. 3 illustrates an exemplary network packet that a controller can generate as a test packet, according to an embodiment of the present invention. FIG. 4 illustrates an exemplary Packet In message that can be generated by a controller, in accordance with an embodiment of the present invention. FIG. 3 illustrates an exemplary tagged network packet that can be generated by inserting identification information into a header field of a network packet, according to an embodiment of the present invention. FIG. 3 illustrates an exemplary tagged network packet that can be generated by encapsulating a network packet, according to an embodiment of the present invention. 4 is a flowchart illustrating exemplary steps that a controller may perform when testing network policy rules by injecting tagged test packets into the network, according to embodiments of the invention.

  Networks such as the Internet, and local and regional networks connected to the Internet rely on packet-based switches. These switches, sometimes referred to herein as network switches, packet processing systems, or packet forwarding systems, can forward packets based on address information. As an example, the switch can include a router, firewall, load balancer, or other packet forwarding system. In this way, the data packet transmitted by the packet source can be delivered to the packet destination. In network terms, the source and destination of a packet may be referred to as an end host. Examples of end hosts include personal computers, servers, and other computing devices such as portable electronic devices that access a network using wired or wireless technology.

  Network switch capabilities range from relatively small Ethernet switches and wireless access points to large rack-based systems that include multiple line cards, redundant power supplies and monitoring capabilities. It is not uncommon for a network to include devices from multiple vendors. Although network switches from different vendors can be interconnected to form a packet forwarding system, centralized management of these network switches is due to incompatibilities between their operating systems and control protocols It can be difficult.

  These potential incompatibilities can be overcome by incorporating a common cross-platform control module (sometimes referred to herein as a controller client) in each network switch. A centralized cross-platform controller server can interact with each controller client via a respective network link. By using a cross-platform controller server and corresponding controller client, potentially different network switch devices can be centrally managed.

  In one exemplary configuration, which may be described herein as an example, centralized control is performed by one or more controller servers, such as controller server 18 of FIG. The controller server 18 may be implemented on a stand-alone computer, a computer cluster, a series of computers distributed in multiple locations, hardware embedded in a network switch, or other suitable computer device 12. Controller server 18 can operate as a single processor on a single computer or can be distributed across multiple hosts for redundancy. The use of a distributed configuration can help give network 10 elasticity against unexpected network partitioning (eg, situations where the network link between two campuses is disrupted).

  In a distributed controller configuration, controller nodes can exchange information using an in-controller protocol. For example, if a new end host connects to network hardware (eg, a switch) that is connected only to the first controller node, the first controller node uses the intra-controller protocol to create a new end host. To other controller nodes. If desired, switches or other network components can be connected to multiple controller nodes. In this specification, as an example, a configuration for controlling a network of related switches using a single controller server may be described.

  The controller server 18 of FIG. 1 can collect information regarding the topology of the network 10. For example, the controller server 18 can send a link layer discovery protocol (LLDP) probe packet over the network to discover the topology of the network 10. The controller server 18 can determine an appropriate route for the packet flowing through the network using the information regarding the network topology and the information regarding the capability of the network device. Once the proper path is identified, the controller server 18 can send the corresponding configuration data to hardware in the network 10 to ensure that the packets flow as desired in the network. Such network configuration operations may be performed continuously in the background during system setup operations or in response to the appearance of newly transmitted data packets (ie, packets for which existing routes have not yet been established). It can be carried out.

  The network configuration rule 20 can also be implemented using the controller server 18. Rule 20 can specify which services are available to various network entities. As an example, the rule 20 can specify which users (or user types) in the network 10 can access a particular server. The rules 20 can be maintained, for example, in the database of the computer device 12.

  The controller server 18 and the controller client 30 in each network switch 14 can communicate over the network link 16 using a network protocol stack.

  Each switch (eg, each packet forwarding system) 14 may have an input / output port 34 (sometimes referred to as a network switch interface). A portion of the device can be connected to port 34 using a cable. For example, an end host such as a personal computer, a web server, and other computer devices can be connected to the port 34. Port 34 can also be used to connect one of the switches 14 to another switch 14.

  The packet processing circuit 32 can be used to transfer a packet from one of the ports 34 to another, and can also be used to perform other suitable operations on incoming packets. Can do. The packet processing circuit 32 can be implemented using one or more integrated circuits such as a dedicated high-speed switch circuit and can serve as a hardware data path. If necessary, the packet processing software 26 running on the control unit 24 can be used when implementing the software data path.

  The control unit 24 may include processing and storage circuits (eg, one or more microprocessors, memory chips, and other control circuits) that store and execute control software. For example, the control unit 24 can store and execute software, such as packet processing software 26, can store a flow table 28, and can be used to support the operation of the controller client 30.

  Controller client 30 and controller server 18 may conform to a network switch protocol such as the OpenFlow protocol (see, for example, OpenFlow switch specification version 1.0.0). One or more of the controller clients 30 may be compliant with other protocols (eg, simple network management protocol). The controller server 18 can provide data to the controller client 30 that defines how the switch 14 should process incoming packets from the input / output port 34 using the OpenFlow protocol or other suitable protocol.

  In one preferred configuration, flow table data from the controller server 18 can be stored in a flow table such as the flow table 28. The entries in the flow table 28 can be used when configuring the switch 14 (eg, the function of the packet processing circuit 32 and / or the packet processing software 26). In a typical scenario, the flow table 28 serves as a cache storage for the flow table entries, and the settings maintained by the circuit of the packet processing circuit 32 incorporate the corresponding versions of these flow table entries. . However, this is only an example. The flow table 28 can serve as dedicated storage for the flow table entry in the switch 14 or can be omitted when selecting a flow table storage resource in the packet processing circuit 32. In general, flow table entries can be stored using any suitable data structure (eg, one or more tables, lists, etc.). For clarity, the flow table 28 data (whether maintained in the control unit 24 database or incorporated in the configuration of the packet processing circuit 32) is referred to herein as a flow table. It is considered as forming an entry (for example, a row of the flow table 28).

  The example of the flow table 28 that stores data defining how the switch 14 should process incoming packets is merely illustrative. If necessary, the packet forwarding system 14 can assist in determining how to forward network packets using any packet forwarding decision engine instead of or in addition to the flow table 28. . As an example, the packet forwarding decision engine can instruct the packet forwarding system 14 to forward a network packet to a predetermined port based on its attributes (eg, based on a network protocol header).

  Any desired switch may be provided with a controller client that is controlled in communication with the controller server. For example, the switch 14 can be implemented using a general-purpose processing platform that executes control software and omits the packet processing circuit 32. As another example, switch 14 may be implemented using a control circuit coupled to one or more high-speed switch integrated circuits (“switch ICs”). As yet another example, the switch 14 can be implemented as a line card in a rack-based system having a plurality of line cards each including its own packet processing circuit. If desired, the controller server can be implemented on one or more line cards in this rack-based system or another rack-based system, or on other computing devices coupled to a network.

  As shown in FIG. 2, the controller server 18 and the controller client 30 can communicate via a network path 66 using a network protocol stack, such as a network protocol stack 58 and a network protocol stack 60. The stacks 58 and 60 can be, for example, a Linux TCP / IP stack (as an example) or a TCP / IP stack within the VxWorks operating system. The path 66 may be, for example, a path that supports network connection between the switch 14 and an external device (for example, the network path 16 in FIG. 1), or may be a backbone path in the rack-based system. In this specification, a configuration in which the path 66 is a network path such as the path 16 may be described as an example.

  The control protocol stack 56 serves as an interface between the network protocol stack 58 and the control software 54. The control protocol stack 62 serves as an interface between the network protocol stack 60 and the control software 64. In operation, the control protocol stack 56 controls control protocol messages (eg, to activate a port or to introduce a specific flow table entry in the flow table 28 when the controller server 18 is communicating with the controller client 30. Control message) is generated and analyzed. By using a configuration of the type shown in FIG. 2, a network connection is formed via a link between the controller server 18 and the controller client 30. The controller server 18 and the controller client 30 can communicate using a transmission control protocol (TCP) or user datagram protocol (UDP) over Internet protocol (IP) network connection. Examples of control protocols that can be used during communication between the controller server 18 and the controller client 30 over a network connection include (as an example) SNMP and OpenFlow protocol stack version 1.0.0.

  The flow table 28 includes a flow table entry (eg, a row in the table) having a plurality of fields (sometimes referred to as header fields). The fields in the packet received by the switch 14 can be compared with the fields in the flow table. Each flow table entry can have an associated action. If the field in the packet matches the field in the flow table entry, the corresponding action for this flow table entry can be performed.

  FIG. 3 shows an exemplary flow table. As shown in FIG. 3, the table 28 may have a flow table entry (row) 68. Each flow table entry can be associated with a header 70, action 72 and statistics 74. Each header 70 can include a plurality of header fields 76. The operation in each flow table entry is what the switch 14 does with the packet when a match is detected between the field in the packet and the corresponding field in the header of this flow table entry. Indicates what should be done. The switch 14 maintains statistical data (counter value) that can be inquired in the statistical part of the flow table 28 when the controller server 18 wants to obtain information on the performance of the switch 14.

  The header fields in header 70 (and the corresponding fields in each incoming packet) are ingress ports (ie, identifiers of physical ports in switch 14 through which received packets pass), Ethernet source addresses, Ethernet destination addresses, Ethernet Type, virtual local area network (VLAN) identification (sometimes called VLAN tag), VLAN priority, IP source address, IP destination address, IP protocol, IP ToS (service type) bit, (called source TCP port) Transport source port / Internet control message protocol (ICMP) type, and transport destination port / ICMP code (sometimes called destination TCP port) It can include a field. Other fields can be used as needed. For example, a network protocol field and a protocol port field can be used.

  Each flow table entry (flow entry) is associated with zero or more operations that indicate how the switch handles matching packets. If there is no forwarding operation, the packet is preferably discarded. Operations that can be performed by the switch 14 when a match is detected between the packet field and the header field in the flow table entry include forwarding (eg, ALL that sends a packet on all interfaces except the incoming interface, CONTROLLER that encapsulates the packet and sends it to the controller server, LOCAL that sends the packet to the local networking stack of the switch, TABLE that performs the operation in the flow table 28, IN_PORT that sends the packet from the input port, for example, conventional level 2 NORMAL to process packets on the default forwarding path supported by switches using VLAN and level 3 processing, along the smallest forwarding tree excluding incoming interfaces It can be mentioned FLOOD) to flood the packet. Additional operations that the switch 14 can perform include queuing operations that forward packets through a queue associated with the port, and discard packets that do not have a specified operation that matches the flow table entry (eg, Yes) a discard operation. The switch 14 can also support field change operations. Examples of field change operations that can be performed include VLAN ID setting (Set VLAN ID), VLAN priority setting, VLAN header removal, VLAN tag change, Ethernet source MAC (medium access control) address change, Examples include changing the Ethernet destination MAC address, changing the IPv4 source address, changing the IPv4 ToS bit, and changing the transport destination port.

  FIG. 4 is an exemplary flow table having three flow table entries. These entries include a field of wildcards (eg, the symbol “*”). If a wildcard is present in a particular field, all incoming packets are considered to form a “match” for the corresponding field regardless of the particular field value in the incoming packet. The additional field can match additional packet information (eg, packet header information of a network packet).

  The entry in the first row of the table in FIG. 4 instructs the switch in which the flow table entry is functioning to perform Ethernet switching. Specifically, an incoming packet having a matching Ethernet destination address is forwarded to port 3.

  The entry in the second row of the table of FIG. 4 shows how the switch can be configured for Internet routing (ie, the packet is forwarded based on its destination IP address).

  The third row of the table of FIG. 4 includes an entry indicating how the switch can be configured to perform the firewall function. If a packet with a destination IP port value of 80 is received, the packet is discarded (ie, the switch is configured to act as a firewall that blocks port 80 traffic).

  A flow table entry of the type shown in FIG. 4 may be loaded into the switch 14 by the controller server 18 during system setup operations, or in response to receiving and processing packets from a switch, such as the switch 14 in the controller server 18. The controller server 18 can also provide the switch 14 in real time. In a network that includes many switches 14, each switch can be provided with a flow table entry suitable for forming a route through the network.

  FIG. 5 illustrates exemplary steps that can be performed by switch 14 in processing a packet received at input / output port 34. In step 78, switch 14 receives the packet at one of its ports (eg, one of input / output ports 34 of FIG. 1).

  In step 80, the switch 14 compares the field of the received packet with the field of the flow table entry in the flow table 28 of this switch to determine whether a match exists. Some fields in the flow table entry contain complete values (eg, complete addresses). Other fields may include wildcards (ie, fields with a wildcard character “*” indicating “irrelevant”). Still other fields may have partially complete entries (eg, partial addresses that are partially wildcarded). Some fields can use a range (eg, by limiting the TCP port number to a value between 1 and 4096), and can effectively use this range to implement a kind of partial wildcard. When performing a field-by-field comparison between the received packet and the flow table entry, the switch 14 determines whether each field in the flow table entry includes a complete value that does not include any wildcards. Whether to include a partial value with a card or whether to include a wildcard character (ie, a field that is fully wildcarded) can be considered.

  During the operation of step 80, if it is determined that there is no match between the packet field and the corresponding field in the flow table entry, the switch 14 sends the packet to the controller server 18 via the link 16. (Step 84).

  If, during the operation of step 80, it is determined that there is a match between the packet and the flow table entry, the switch 14 performs the operation associated with this flow table entry and enters the statistics field of this flow table entry. Can be updated (step 82). Thereafter, as indicated by line 86, processing returns to step 78 to allow switch 14 to process another packet.

  FIG. 6 is a diagram illustrating an exemplary network 100 in which the controller 18 can control the switch. The controller 18 can be a controller server or a distributed controller implemented across multiple computer devices. As shown in FIG. 6, the network 100 may include switches SW1, SW2, and SW3. These switches can be physical switches implemented using dedicated switch circuitry, or they can be software switches. An example of a software switch is a hypervisor switch implemented using software on a discrete computer device (eg, on a server in a rack-based system). Such software switches are coupled to the rest of the network by a cable connected to a dedicated physical port of a computer device that implements the software switch (eg, each software switch is for a given server that implements the software switch). Restricted and bound to physical ports).

  Controller 18 may be coupled to a switch of network 100 via control path 66. Controller 18 can control the switch using control path 66 (eg, by providing a flow table entry, such as flow table entry 68 of FIG. 3).

  Network 100 may include end hosts such as end hosts EH1, EH2, and EH3 coupled to a switch of network 100. In the example of FIG. 6, end hosts EH1 and EH3 are coupled to ports P1 and P2 of switch SW1, and end host EH2 is coupled to port P2 of switch SW3. A switch port can also be coupled to another switch port. For example, port P3 of switch SW1 can be coupled to port P1 of switch SW2, and port P2 of switch SW2 can be coupled to port P1 of switch SW3. Packets received from the first end host at the switch port can be forwarded to the second end host by a switch coupled between the end hosts.

  It may be difficult for a user, such as a network administrator, to configure the network 100 for a desired operation. For example, it may be desirable to separate or otherwise limit communication between end host groups. As another example, it may be inefficient for a network administrator to manually configure network policies (eg, routing rules, access control lists, etc.) for each switch and each end host in the network. The controller 18 can be configured to implement a logical network topology of virtual routers and virtual switches on a basic network topology (eg, physical network topology). Logical network topologies can provide benefits such as improved network configuration efficiency, flexibility and capacity. FIG. 7 is an example in which the controller 18 is configured to implement the virtual network topology 120 from the basic network 100 of FIG.

  The virtual network topology 120 can be any desired topology within the physical constraints of the base network 100 (eg, each virtual path corresponds to at least one, and possibly more, within the base network. Have a route). The basic path can include physical switches and / or software-based switches.

  As shown in FIG. 7, the virtual network topology 120 may include virtual switches such as VSW1 and VSW2, and virtual routers such as VR1. The virtual switch is formed from an end host group of the network and can be defined by any desired network attribute of the end host. If necessary, the virtual switch can be assigned an end host coupled to a different basic physical switch or software switch. End hosts EH1 and EH2 can be assigned to the virtual switch VSW1, and an end host EH3 can be assigned to the virtual switch VSW2. A virtual switch can have virtual ports coupled to end hosts and other elements in the virtual network topology. For example, virtual switch VSW1 can have virtual ports VP1, VP2, and VP3 coupled to end host EH1, end host EH2, and virtual router VR1. Similarly, virtual switch VSW2 may have virtual ports VP1 and VP2 coupled to end host EH3 and virtual router VR1, respectively.

  Examples of network attributes that can be used to characterize an end host include the physical or hypervisor switch port to which the end host is bound, the hardware address (eg, MAC address) of the end host, and the protocol address of the end host (eg, IP Address), virtual local area network (VLAN) tag, and / or other network attributes of the end host. For example, the controller 18 can identify the end host EH1 as connected to the port P1 of the switch VSW1, can identify the end host EH2 by a MAC address, and can identify the end host EH3 by an IP address. Can do. As another example, in a scenario where switch SW3 is a hypervisor switch, end host EH2 can be identified by a logical hypervisor switch to which end host EH2 is coupled. These examples are merely illustrative. When assigning end hosts to virtual switches, any desired network attributes, such as those used in the network packet header field, or any desired combination of network attributes can be used, and the basics of physical and hypervisor switches Any desired number of distributed virtual switches can be created from the network.

  Virtual switches can be grouped to form one or more virtual routers. In the example of FIG. 7, virtual switches VSW1 and VSW2 are grouped to form a virtual router VR1. In other words, the end host groups of the virtual switches VSW1 and VSW2 are assigned to the virtual router VR1. Each virtual switch is responsible for implementing a respective broadcast domain in which broadcast network packets are forwarded to all end hosts of the virtual switch. A broadcast network packet may be a network packet having a header field that identifies the network packet as a broadcast network packet destined for all end hosts of the associated broadcast domain. For example, a broadcast network packet received by the virtual switch VSW1 from the end host EH2 can be forwarded by the virtual switch VSW1 to each other end host assigned to the virtual switch VSW1 (ie, to the end host EH1). .

  The virtual router performs a network routing function and separates different broadcast domains of the virtual switch. For example, the virtual router VR1 can prevent a broadcast packet from being transferred by the virtual switch VSW1 to the virtual switch VSW2 (and vice versa). The broadcast domain can be defined such that with respect to the IP address range, each interface of a given virtual router is assigned a different respective IP address range. For example, a first IP address range can be assigned to the interface IF1 and the virtual switch VSW1, and a second IP address range can be assigned to the interface IF2 and the virtual switch VSW2. In the example of FIG. 7, in contrast to the virtual router, the virtual switch does not perform any network routing function based on the IP domain. However, if necessary, the virtual switch can be omitted and the virtual switch can perform forwarding and routing functions.

  A network routing function that a virtual router can perform includes changing the header of a network packet received at the interface of the virtual router. The virtual router can decrement the lifetime field of the IP header of the network packet. The virtual router can change Ethernet headers such as source and destination MAC address fields to correspond to the desired broadcast domain. For example, each Ethernet address can be assigned to each interface of the virtual router. In this scenario, the virtual router can rewrite the source MAC address field to match the egress interface of the virtual router. The virtual router can rewrite the destination MAC address field to match the next hop address.

  The controller 18 can also be used to apply and enforce network policy rules at a logical port of a virtual network (eg, a virtual port of a distributed virtual switch or an interface of a distributed virtual router). Network policy rules include network routing rules that help determine network paths between end hosts, and can include access control lists that allow or block selected network traffic. Network policy rules can be provided by the user. FIG. 8 is a diagram illustrating an exemplary access control list that the controller 18 can implement.

  As shown in FIG. 8, the access control list 132 identifies network attributes such as logical ports, end host information, and protocol ports. In general, the access control list 132 may include any desired network attributes such as one or more logical ports, physical ports, and / or packet header fields. The packet header field may include a header field that identifies one or more end hosts (eg, a source or destination end host). For example, the access control list 132 may include an end host identification field such as a source MAC address, a source IP address, a destination MAC address, and / or a destination IP address. If necessary, the end host can be identified through an alias (eg, a string) that can be mapped to the end host using a database.

  The controller 18 can generate a flow table entry that implements the network policy rules defined by the access control list 132. In the example of FIG. 8, the access control list 132 identifies the logical port VP2 of the virtual switch VSW1, the MAC address (MACEH1) of the end host EH1, and the protocol port 80. The protocol port 80 can be a transmission control protocol (TCP) port. The controller 18 should process the access control list 132 to discard the network packet with the source MAC address MACEH1 and TCP protocol port 80 received at the logical port VP2 of the virtual switch VSW1 (ie, the control list). Packets that match the network attributes identified at 132 should be discarded). Since the virtual network topology 120 can have any desired configuration of virtual switches and any desired assignment of end hosts to the virtual switches, the use of logical ports, such as VP2 of the virtual switch VSW1, is network to the network administrator. Flexibility in constructing can be provided. The controller 18 can then generate a flow table entry and provide it to the basic physical and / or hypervisor switch of the basic network 100 that implements the access control list 132.

  FIG. 9 is an exemplary flow table entry that the controller 18 can generate when implementing the access control list 132. As shown in FIG. 9, the flow table entry 142 includes the MAC address of the end host EH1 in the source MAC address field, the MAC address of the end host EH2 in the destination MAC address field, and the port in the TCP port field. 80 can be included. The flow table entry 142 may also include an additional match field (not shown) that is wildcarded to match all packets with source MAC address MACEH1, destination MAC address MACEH2, and TCP port 80. .

  In implementing the access control list 132, the flow table entry 142 can be provided to one or more physical or hypervisor switches. For example, a flow table entry 142 can be provided to the switch SW3. In this scenario, as determined from the operational field of flow table entry 142, addressed to end host EH2 (ie, having MAC address MACEH2) received by switch SW3 from end host EH1 (ie, having MAC address MACEH1). Any network packet with a TCP port of 80 can be discarded. The access control list 132 is defined in the logical port VP2 of the VSW2 to which the end host EH3 is allocated. Since the end host EH3 is connected to the port P2 of the switch SW3 of the basic network, the switch SW3 is a flow table entry. There may be 142 preferred recipients. However, since the virtual switch VSW2 is a distributed virtual switch, the controller 18 can select any desired basic switch to implement the access control list 132 via the flow table entry. For example, the controller 18 can generate the flow table entry 144 of FIG. 10 and provide it to the switch SW1.

  As shown in FIG. 10, the flow table entry 144 matches a network packet received at port P1 (of switch SW1) with TCP port 80 addressed to end host EH2 (eg, having destination MAC address MACEH2) To do. Since end host EH1 is coupled to port P1 of switch SW1, and therefore packets from end host EH1 are processed by switch SW1, flow table entry 144 can be suitable for provision to switch SW1. The flow table entry 144 can instruct the switch SW1 to discard the network packet on the TCP port 80 destined for the end host EH2 received from the end host EH1 (via the port P1). Each of the flow table entries 144 and 142 is provided to a different switch in the base network 100, but effectively prevents the network policy rule 132 from preventing the end host EH1 from communicating with the end host EH2 over TCP port 80. Can be implemented. If necessary, multiple flow table entries can be provided to different switches when implementing network policy rules. For example, the controller 18 can provide flow table entries for any desired combination of switches SW1, SW2, and SW3 when implementing the access control list 132.

  FIG. 11 is an exemplary diagram of network policy rules that the controller 18 can implement. As shown in FIG. 11, the network policy rule 152 specifies that network traffic between the virtual switches VSW1 and VSW2 should be blocked. The network policy rule 152 can be defined as a routing rule for the virtual router VR1. The controller 18 can process the network policy rules 152 to generate a flow table entry that blocks network traffic between the virtual switches VSW1 and VSW2 for the switch of the base network 100. For example, one or more switches of the basic network 100 match a network packet including source end host information identifying the end host of the virtual switch VSW1 and destination end host information identifying the end host of the virtual switch VSW2. A flow table entry can be provided. In this scenario, the flow table entry can instruct the switch to discard network packets that match the flow table entry.

  The virtual network topology can also be redefined as needed, which provides flexibility in network configuration and network policy enforcement. As shown in the example of FIG. 12, the virtual network topology 162 can be generated by reassigning the end host EH2 of the virtual network topology 120 of FIG. 7 to the virtual switch VSW2. The reassignment of the end host can be performed without changing the basic network 100 (for example, the end host EH2 can remain connected to the port P2 of the switch SW3). In the virtual network topology 162, the end host EH2 is assigned to the virtual port VP3 of the virtual switch VSW2.

  It can be difficult to maintain network policy rules that are suitable for virtual network topologies that change over time. Consider a scenario in which the controller 18 of the virtual network topology 120 of FIG. 7 implements the access control list 132 of FIG. 8 and the network policy rule 152 of FIG. 11 using the flow table entry 142 of FIG. In this scenario, if the virtual network topology 120 is changed to the topology 162 of FIG. 12 through reassignment of the end host EH2, the access control list 132 is no longer valid (eg, the access control list 132 is no longer on any end host). This is because it is defined for the virtual port VP2 of the unassigned virtual switch VSW1). Now, since the end host EH2 is connected to the virtual switch VSW2, a network packet transmitted from the end host EH1 to the end host EH2 on the TCP port 80 is transmitted between the virtual switch VSW1 and VSW2. It is still blocked because it blocks all network traffic. Accordingly, because the desired network behavior of the access control list 132 is implemented by the network policy rules 152, it may be difficult to identify the access control list 132 as invalid.

  The controller 18 can implement hundreds, thousands, or more network policy rules, so if the network changes over time, a significant number of network policies can become invalid. The controller 18 may perform test operations that may be useful for testing invalid network policy rules, identifying network changes, or other forms of network functionality. The test operation of the controller can be defined by a user such as a network administrator using a test rule. FIG. 13 is a diagram illustrating an exemplary test rule 172 that can be provided to the controller 18. Test rule 172 can be used in performing a test operation and is therefore sometimes referred to as a test rule.

  The test rules 172 can include test parameters and expected results of tests to be performed. In the example of FIG. 13, the test parameter identifies that the controller should test whether end host EH1 can connect to end host EH2 over TCP port 80. As an example, the test parameters may define an end host EH1 as a source end host, an end host EH2 as a destination end host, and a TCP port 80. The expected result can be yes or no (eg, true / pass or false / fail). If desired, the expected result can include an optional condition list 174. Optional condition list 174 may include a list of switches that are traversed, network policy rules that are triggered, or other information that occurs when testing based on test rules 172.

  FIG. 14 is a flowchart 180 of exemplary steps that can be performed by a controller when performing a test defined by a test rule, such as rule 172 of FIG.

  In step 182, the controller can receive the network configuration. For example, this network configuration can be user defined and can include end host assignments to virtual switches and virtual switch assignments to virtual routers.

  In step 184, the controller can generate a logical network topology from the network configuration. For example, the virtual network topology 120 of FIG. 7, the virtual network topology 162 of FIG. 12, or any desired virtual network topology can be generated as defined by the network configuration.

  In step 186, the controller can identify the base topology of the generated logical network topology. The controller can communicate with physical and hypervisor switches via control paths when determining the underlying network topology of the virtual network topology (eg, identifying connections between switches in the basic network topology). .

  In step 188, the controller can receive a series of test rules. In general, a series of test rules can be defined by the user, and each test rule can define tests to test the validity of one or more respective network policies as needed. For example, the controller may receive the test rule 172 of FIG. 13 that tests the validity of the access control list 132 of FIG.

  In step 190, the controller can test for each test rule. Testing can be based on logical and / or physical network topology. Testing can be done through simulation in the controller or through the insertion of test packets into the network.

  The order of steps 182 through 190 in the example of FIG. 14 is merely illustrative. If necessary, these steps can be performed in any desired order to test the network. For example, user-defined tests can be received at any point during network configuration or normal network operation. If necessary, the controller can also periodically perform the steps of flowchart 180 (eg, every 5 milliseconds, every 100 milliseconds, every 10 seconds, etc.).

  FIG. 15 is an exemplary flowchart 190 of steps that can be performed by a controller to test a test rule through simulation. The steps of the flowchart 190 can be executed in, for example, step 190 of FIG.

  In step 192, the controller can generate a test packet based on the test parameters of the test rule. For example, in the case of the test rule 172 in FIG. 13, the controller can generate a test packet imitating a packet transmitted from the end host EH1 to the end host EH2 using the TCP port 80. In this scenario, the source end host EH1 information (for example, the MAC and / or IP address of the end host EH1) is input into the source packet header field, and the destination end host EH2 information is input into the destination packet header field. Can do. Additional test parameters, such as TCP port 80, can be stored in a corresponding header field (eg, TCP port header field) of the test packet.

  In step 194, the controller can send to the controller itself the packet that stimulated the switch to forward the packet to the controller. The controller can send the packet as a Packet In message containing additional information that the switch may have contained (eg, identifying the switch port that received the packet from the end host). This example is merely illustrative. In general, in step 194, the controller simulates network behavior when processing a typical network packet (eg, by stimulating or otherwise triggering the processing of the generated test packet). The test of the generated test packet can be started.

  At step 196, the controller can simulate packet traversal of the logical network topology (eg, a logical network topology such as topology 120 of FIG. 7 that has already been generated by the controller at step 184 of FIG. 14). When simulating packet traversal, the controller can identify a virtual path through the virtual network topology between the source end host and the destination end host of the network packet. The controller can identify network policy rules that have been triggered or otherwise matched with the identified virtual path.

  In step 198, the controller can use the identified virtual path in identifying a path through the physical and / or hypervisor switch base network. For example, the controller can identify a path from the source end host to the destination end host through the base network. Normally (eg, during non-testing operation of the controller), physical and / or hypervisor switches in the identified path through the base network are not able to receive packets (eg, to meet the network policy rules identified in step 196). A flow table entry can be provided that instructs the switch to create the identified path (by forwarding or discarding). However, the controller creates a flow table entry in step 196 and does not provide it to the switch. In other words, the identified path is not implemented.

  In step 200, the controller can compare the simulation results from steps 196 and 198 with the expected results. Consider a scenario in which the controller executes the test rule 172 of FIG. In this scenario, the controller can generate a test packet from end host EH1 to end host EH2 using TCP port 80 (step 192). Thereafter, the controller can begin simulation of the test packet (step 194). The controller can simulate the traversal of the test packet through the logical network topology 120 of FIG. 7 to identify the path from the end host EH1 to the end host EH2 through the virtual switch VSW1. The controller can identify that the access control list 132 specifies that the test packet should be discarded at the virtual port VP2 of the virtual switch VSW1 (step 196). The controller identifies the path through the switches SW1, SW2 and SW3 of the basic network 100 of FIG. 6 and creates a flow table entry such as the flow table entry 142 or 144 of FIGS. 9 and 10 without providing it to the switch. (Step 198). In step 200, the controller determines that the simulation result (eg, test packet is discarded according to access control list 132) is the expected result of test rule 172 (ie, end host EH1 cannot connect to end host EH2 over TCP port 80). It can be determined that it should match.

  Consider another scenario where the virtual network topology 120 of FIG. 7 is changed to become the virtual network topology 162 of FIG. 12, and the controller 18 implements the access control list 132 of FIG. 8 and the network policy rules 152 of FIG. In this scenario, steps 192-198 can be performed as in the previous scenario, but the simulation results can identify that only the network policy rule 152 was triggered in step 196. The generated report can be used to help identify that the access control list 132 is no longer valid (ie, the test packet does not trigger the access control list 132). The access control list 132 can then be deleted to help improve controller performance by reducing the number of network policy rules.

  FIG. 16 is an exemplary diagram of network packets that can be transmitted from a source end host to a destination end host. As shown in FIG. 16, the network packet 202 may include a header field 204 and data carried from the source end host to the destination end host via the network. The header field may include a layer 3 (L3) header field such as a source internet protocol (IP) address, a destination IP address, a TTL field. The header field may also include a layer 2 (L2) header field such as a source Ethernet address, a destination Ethernet address, and a virtual local area network (VLAN) identifier. In the example of FIG. 16, the network packet 202 includes the MAC address (MACEH1) of the end host EH1 as the source MAC address, the MAC address (MACEH2) of the end host EH2 as the destination MAC address, and the TCP port 80. . The network packet 202 may be a packet transmitted from the source end host EH1 to the destination end host EH2. Similarly, network packet 202 may be a test packet generated by the controller to simulate a packet sent from end host EH1 to end host EH2 (in step 192 of FIG. 15).

  FIG. 17 is an exemplary Packet In message 206 that the controller can receive from the switch or the controller itself. The packet in message 206 can include a network packet and additional information from the switch that transmitted the packet in message. In the example of FIG. 17, the Packet In message 206 includes the network packet 202 of FIG. 16, and identifies the incoming switch port P1 of the switch SW1 as the switch port that received the network packet 202. In this scenario, the switch SW1 of FIG. 6 can provide the Packet In message 206 to the controller 18 in response to the network packet 202 from the end host EH1 being received at the switch port P1. Similarly, the controller 18 may generate a Packet In message 206 when performing a network policy rule test (eg, at step 194 of FIG. 15).

  In some scenarios, it may be difficult for the controller to completely simulate test packets that traverse the network. Switch SW2 in FIG. 6 is a non-client switch that is not controlled by controller 18 (eg, switch SW2 does not include a controller client, is not coupled to controller 18 by control path 66, and therefore does not communicate with controller 18 via the control path) ) Consider the scenario. In this scenario, the switch SW2 operates independently of the controller 18, so that the simulation of the operation of the switch SW2 by the controller 18 is inaccurate and may lead to erroneous test results. In scenarios where a portion of the network operates independently of the controller, the controller tests the network policy rules by injecting a test packet directly into the network and observing how the switch forwards the test packet. It can be performed. The controller can tag the test packet with identification information in order to track the test packet submitted to the network.

  FIG. 18 is an exemplary tagged test packet 210 that the controller can inject into the network. As shown in FIG. 18, a tagged network packet packet 210 can be created by inserting a tag 212 into the header field of the network packet. The tag 212 can be formed with any desired number of bits and can be inserted into the unused portion of the header field of the original network packet. For example, the tag 212 can be stored in the unused portion of the VLAN header field, IP header field, VLAN header field, or any desired packet header field.

  If necessary, the test network packet can be encapsulated to form an encapsulated packet 214 as shown in FIG. For example, a network packet may be any protocol that encapsulates a multi-protocol label switching (MPLS), virtual extended LAN (VxLAN), MAC-in-MAC, general routing encapsulation (GRE), or network packet. Can be encapsulated. Encapsulating a network packet can include generating a tagged network packet by adding a tag 216 to the original network packet (eg, in a new additional header field).

  FIG. 20 is a flowchart 220 of exemplary steps that a controller can perform to perform a network policy rule test by injecting a tagged network packet into the network.

  In step 222, the controller can generate a test packet based on the test parameters of the test rule (eg, similar to step 192 of FIG. 15).

  In step 224, the controller can tag the test packet with identification information. For example, the controller can generate a tagged network packet 210 or a tagged network packet 214 from the test packet.

  In step 226, the controller instructs the network switch to provide information in response to receiving the tagged test packet while preventing the tagged test packet from reaching its destination end host. Can do. For example, the controller can instruct the switch to forward a copy of the network packet as a Packet In message to the controller in addition to forwarding the network packet to the destination end host as usual. The controller controls the switch to which the destination end host is connected (for example, by instructing the switch not to forward the tagged test packet to the destination end host) so that the tagged test packet is sent to the destination end host. The switch can be controlled to prevent reaching. As an example, the controller provides the switch with a flow table entry that matches the tagged network packet and instructs the switch to forward information related to the tagged network packet (eg, as a Packet In message) to the controller. be able to. In this scenario, the corresponding packet header match field can also include a tag, such that the flow table entry matches a tagged network packet that includes a tag in the corresponding packet header field.

  In step 228, the controller enters the entry switch associated with the source end host of the tagged test packet (eg, the entry switch connected to the source end host or the client switch closest to the source end host in the network topology). Can be identified.

  In step 230, the controller can inject a tagged test packet at the entry switch. For example, the controller may send a message including a tagged test packet and an instruction to process and forward the tagged test packet (eg, process the tagged test packet based on a flow table entry provided in advance by the controller). Can be sent to the entry switch.

  When a switch in the network forwards a tagged network packet, it can forward information about the tagged network packet to the controller (eg, according to instructions provided by the controller in step 226). The controller can receive information about the tagged network packet from the switch and store it as a test result. The controller can also process information received from the switch to generate test results. For example, the controller can process the information to identify the path through the switch that the tagged network packet traverses.

  In step 234, the controller can compare the test result with the expected result of the test rule (eg, test rule 172 of FIG. 13). The controller can generate a report that identifies whether the test results match the expected results. If necessary, the controller can also include information that identifies the path that the network packet traverses through the network (eg, the path through the physical and / or hypervisor switch).

  According to an embodiment, a method for using a controller to control a switch in a network having an end host coupled to the switch, wherein the network receives a given network policy rule, and the network receives a given network policy rule. Performing a test to determine whether or not is satisfied.

  According to another embodiment, the method further includes generating a virtual switch from the end host group and generating a virtual network topology from the virtual switch, wherein each virtual switch is assigned to a respective end host. A test is performed to determine whether a given network policy rule is defined for a given virtual port and the network satisfies the given network policy rule. Including testing based on a virtual network topology.

  According to another embodiment, the method further includes receiving a test rule that identifies the test parameter and the expected test result.

  According to another embodiment, the step of performing a test to determine whether the network satisfies a given network policy rule based on the generated virtual network topology includes a test packet based on a test parameter of the received test rule. The step of generating is included.

  According to another embodiment, the step of performing a test to determine whether the network satisfies a given network policy rule based on the generated virtual network topology includes a packet of test packets that traverse the virtual path of the virtual network topology. Simulating traversal.

  According to another embodiment, the controller implements a plurality of network policy rules, including a given network policy rule, and the method identifies the network policy rule that was triggered during simulation of packet traversal of the virtual network topology. Includes steps.

  According to another embodiment, the step of testing to determine whether the network meets a given network policy rule based on the generated virtual network topology includes a series of switches that form a basic route of the virtual route. Determining.

  According to another embodiment, the step of testing to determine whether the network meets a given network policy rule based on the generated virtual network topology includes a flow table entry that implements the basic route of the virtual route. Generating without providing to a series of switches.

  According to another embodiment, the step of testing whether the network satisfies a given network policy rule based on the generated virtual network topology includes the simulated packet traversal result as the expected result. Comparing includes determining whether the network meets a given network policy rule.

  According to another embodiment, the expected result of a test rule includes a list of network policy rules that are expected to be triggered, and the simulated packet traversal result is compared with the expected result to determine whether a given network Determining whether the network policy rule is satisfied includes comparing the list of network policy rules with the triggered network policy rule.

  According to another embodiment, performing a test to determine whether the network satisfies a given network policy rule based on the generated virtual network topology generates a tagged test packet from the test packet; Injecting a tagged test packet into the network and determining whether the network satisfies a given network policy rule based on the expected result of the test rule and information about the tagged test packet received from the switch Including.

  According to another embodiment, the step of performing a test to determine whether the network meets a given network policy rule based on the generated virtual network topology is configured to send information about the tagged test packet to the controller. Providing the switch with a flow table entry that prevents the switch from forwarding the tagged test packet to the destination end host of the tagged test packet, based on information from the switch and the expected result of the test rule Determining whether the network satisfies a given network policy rule.

  According to an embodiment, a method for using a controller to control a switch in a network having an end host coupled to the switch, the step of maintaining network topology information for the network, and a user-defined test rule Determine whether the network satisfies the user-defined test rule by processing the test packet based on the network topology information And providing a method comprising:

  According to another embodiment, the method further includes generating a virtual switch from the end host group, wherein the network topology information includes network topology information for the switch, virtual network topology information for the virtual switch, and including.

  According to another embodiment, the user-defined test rule includes an expected result and a test parameter identifying the source end host and the destination end host, and the test packet is a source of the test rule defined by the user Identifying the end host and the destination end host and processing the test packet includes simulating the traversal of the network packet from the source end host to the destination end host through the network based on the network topology information.

  According to another embodiment, the step of determining whether the network satisfies a user-defined test rule determines whether the simulated network packet traversal matches the expected result of the user-defined test rule. Determining.

  According to an embodiment, a method for using a controller to control a switch in a network, the method comprising receiving a user-defined test rule and generating a tagged test packet based on the user-defined test rule And injecting the tagged test packet into the network.

  According to another embodiment, generating a tagged test packet includes generating a test packet and generating a tagged test packet by inserting identification information into a header field of the test packet.

  According to another embodiment, generating a tagged test packet includes generating a test packet and encapsulating the test packet with identification information to generate a tagged test packet.

  According to another embodiment, the method controls the switch to provide information about the test packet in response to receiving the tagged test packet, and based on the information provided by the switch, Identifying a path traversed by the tagged test packet.

  According to another embodiment, the user-defined test rule includes an expected result, and the method determines, based on the identified path, whether the network satisfies the expected result of the user-defined test rule. including.

  The above description is merely illustrative of the principles of the invention, and various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.

192 Generate test packet based on test parameters 194 Send packet to itself as Packet In message 196 Simulate packet traversal of logical network topology and identify network policy rules triggered during simulation 198 Virtual path and basic network topology Identifies the basic route from and does not implement the identified route (eg, creates a flow table entry)
200 Create a report comparing simulation results with expected results

Claims (14)

A method for using a controller to control a switch in a network having an end host coupled to the switch comprising:
Receiving a given network policy rule;
Receiving a test rule including a test parameter and a predicted test result, wherein the predicted test result is determined from data selected from a group consisting of user input data and simulation data;
Performing a test to determine whether the network satisfies the given network policy rule ;
Generating a test packet based on the test parameters of the received test rule;
Generating an actual network policy rule that is triggered using the test packet;
Comparing the actual network policy rules with the expected test results to identify invalid network policy rules;
The step including:
A method comprising the steps of: Creating a virtual switch from the end host group;
Generating a virtual network topology from the virtual switch;
Each virtual switch has a virtual port assigned to a respective end host, the given network policy rule is defined for the given virtual port, and the network is the given network. The method of claim 1, wherein performing the test to determine whether a policy rule is satisfied comprises performing the test based on the generated virtual network topology.
Performing the test to determine whether the network satisfies the given network policy rule based on the generated virtual network topology includes packet traversal of the test packet through a virtual path of the virtual network topology. The method of claim 2 further comprising the step of simulating. The controller implements a plurality of network policy rules including the given network policy rule, and the method identifies the actual network policy rule triggered during the packet traversal simulation of the virtual network topology. The method of claim 3 further comprising a step. Performing the test to determine whether the network meets the given network policy rules based on the virtual network topology the generated may determine a set of switches forming the basic path of the network in the network further seen including the step of, basic path of the network corresponds to the virtual route of the serial virtual network topology, the method of claim 4. Performing the test to determine whether the network satisfies the given network policy rule based on the generated virtual network topology includes a flow table entry that implements the basic route corresponding to the virtual route. The method of claim 5 , further comprising generating without providing to the series of switches. Performing the test to determine whether the network satisfies the given network policy rule based on the generated virtual network topology comprises comparing the simulated packet traversal result with the expected test result; The method of claim 6 , further comprising: determining whether the network satisfies the given network policy rule. The expected test result of the test rule includes a list of network policy rules that are expected to be triggered, and the simulated packet traversal result is compared with the expected test result so that the network 8. The method of claim 7 , wherein determining whether a network policy rule is satisfied comprises comparing the list of network policy rules with the triggered network policy rule. Performing the test to determine whether the network satisfies the given network policy rule based on the generated virtual network topology;
Generating a tagged test packet from the test packet;
Injecting the tagged test packet into the network;
Determining whether the network satisfies the given network policy rule based on the expected test result of the test rule and information about the tagged test packet received from the switch;
The method of claim 2 further comprising: Performing the test to determine whether the network satisfies the given network policy rule based on the generated virtual network topology;
Instructing the switch to send information about the tagged test packet to the controller, the flow table entry preventing the switch from forwarding the tagged test packet to a destination end host of the tagged test packet Providing to the switch;
Determining whether the network satisfies the given network policy rule based on the information from the switch and the expected test result of the test rule;
10. The method of claim 9 , further comprising: A method for using a controller to control a switch in a network having an end host coupled to the switch comprising:
Maintaining network topology information for the network;
Generating a virtual switch from an end host group, wherein the network topology information includes network topology information for the switch and virtual network topology information for the virtual switch;
Receiving a user-defined test rule;
Generating a test packet based on the test rule defined by the user; and processing the test packet based on the network topology information to determine whether the network satisfies the test rule defined by the user The user-defined test rule includes an expected result and a test parameter that identifies a source end host and a destination end host, and the test packet includes the test rule defined by the user. Identifying the source end host and the destination end host and processing the test packet comprises the step of processing the test packet from the source end host to the destination end host through the network based on the network topology information. Traversing Such steps including simulating monkeys ;
A method comprising the steps of: Determining whether the network satisfies the user-defined test rule determines whether the simulated test packet traversal matches the expected result of the user-defined test rule. The method of claim 11 , comprising steps. A method for using a controller to control a switch in a network,
Receiving a user-defined test rule;
And generating a tagged test packet based on the test rule by the user-defined,
Generating test packets,
Inserting the identification information into a header field of the test packet to generate the tagged test packet;
The step including:
Injecting the tagged test packet into the network;
A method comprising the steps of: Controlling the switch to provide information about the test packet in response to receiving the tagged test packet;
Identifying a path traversed by the tagged test packet based on the information provided by the switch; and
Determining whether the network satisfies the expected result of the user-defined test rule based on the identified path, wherein the user-defined test rule includes an expected result; and
14. The method of claim 13 , further comprising:

Images