Patent Publication Number: US-7710898-B2

Title: Method and apparatus for automatic verification of a zone configuration of a plurality of network switches

Description:
TECHNICAL FIELD 
   The present invention generally relates to network switches. More specifically to a system and method for automatic verification of a zone configuration of a plurality of network switches. 
   BACKGROUND ART 
   Modern networking continues to provide an improvement in communication and information access. As an example, in-house data centers, associated with a particular entity of interrelated group of users, could contain a large number of information technology (IT) resources that are interconnected through a network. These networks are configured in different ways depending on implementation-specific details such as the hardware used and the physical location of the equipment, and depending on the particular objectives of the network. One common type of network configuration is a local area network (LAN). In actual practice, a typical LAN will include large numbers of computer systems and switches (as well as other devices). Another common type of network configuration is a storage area network (SAN). In actual practice, a typical SAN will include large numbers of disk logical units (LUNs) of a disk array and switches (as well as other devices). Devices such as computer systems, routers, switches, load balancers, firewalls, and the like, are commonly linked to each other in networks. 
   Generally, data centers include technicians working from a network operation center (NOC). The technicians issue commands to control the deployment of servers and to control the supporting infrastructures, such as disk logical units (LUNs) in a disk array, network switches in the LAN, and switches in the SAN. 
   Once the servers, the SAN switches and the disk array have been configured to properly map one or more LUNs to a server, additional security can be achieved by defining a zone configuration that specifies the source and destination devices that should be allowed to communicate via the ports of the SAN switches. Therefore, the zone prevents abusive or erroneous use of the SAN including accessing the disk array in an unauthorized manner. 
   In present operation, the devices which are a part of the zone configuration are configured by commands from the NOC, include many steps which must be coordinated. This method is expensive and prone to error, especially if the data center environment is dynamic, with high demand for changes in computer deployment and therefore a need to change the devices of the zone configuration. Additionally, a malicious attack on the configuration of the zone could result in alteration of zone configurations, thereby allowing the attacker to access confidential data. 
   DISCLOSURE OF THE INVENTION 
   Embodiments of the invention provide a method and an apparatus for automatic verification of a zone configuration of a plurality of network switches. In one method embodiment, the present invention accesses an actual zone configuration comprising a plurality of network switching devices, the actual zone configuration for defining the switching devices which are actually part of the zone. Additionally, a machine-readable map of the network is accessed, the map providing a pre-determined zone configuration defining the switching devices which should be part of the zone. An automatic verification is performed, wherein the verification verifies that the actual zone configuration of network switching devices correlates with the pre-determined zone configuration defined by the machine-readable map. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The accompanying drawings, which are incorporated in and form a part of this application, illustrate embodiments of the present invention, and together with the description, serve to explain the principles of the invention. Unless noted, the drawings referred to this description should be understood as not being drawn to scale. 
       FIG. 1  is a block diagram of an exemplary network including a LAN and SAN upon which embodiments of the present invention can be implemented. 
       FIG. 2  is a block diagram of the zone configuration verification program accessing the network switches in accordance with one embodiment of the present invention. 
       FIG. 3  is a block diagram of an exemplary switch having a zone configuration in accordance with one embodiment of the present invention. 
       FIG. 4  is a block diagram of an exemplary automatic zone configuration verifier in accordance with one embodiment of the present invention. 
       FIG. 5  is a flowchart of a method for automatic verification of a zone configuration for a network switch in accordance with one embodiment of the present invention. 
       FIG. 6  illustrates a utility data center in accordance with one embodiment of the present invention. 
   

   BEST MODE FOR CARRYING OUT THE INVENTION 
   Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention. 
   Aspects of the present invention may be practiced on a computer system that includes, in general, a processor for processing information and instructions, random access (volatile) memory (RAM) for storing information and instructions, read-only (non-volatile) memory (ROM) for storing static information and instructions, a data storage device such as a magnetic or optical disk and disk drive for storing information and instructions, an optional user output device such as a display device (e.g., a monitor) for displaying information to the computer user, an optional user input device including alphanumeric and function keys (e.g., a keyboard) for communicating information and command selections to the processor, and an optional user input device such as a cursor control device (e.g., a mouse) for communicating user input information and command selections to the processor. 
   Embodiments of the present invention relate to the automatic verification of zone configurations for a network such as a storage area network (SAN). The present description begins with an overview of a network map and one embodiment of a network environment. The details of the zone configuration&#39;s use and operation are then described in detail. 
   In one embodiment, the network map lists each individual network device and the attributes of the device. For example, the attributes of a device may include, but are not limited to, the make, model, type, role, and unique identifier of the device. Additionally, the network map may list each individual connection that will connect the network devices, and the attributes of those connections, such as, but not limited to, the unique identifier of the source device, the unique identifier of the destination device, the identifier of the source device&#39;s port, into which the cable is inserted, the identifier of destination device&#39;s port, into which the cable is inserted, and the type of cable used in the connection. For example, the cable may be, but is not limited to, a power cable, serial cable, Ethernet cable, fibre channel cable, or SCSI cable. One exemplary embodiment of a network which results from a network map is shown in  FIG. 1 . 
   With reference now to  FIG. 1 , a block diagram of an exemplary network  100  is shown in accordance with one embodiment of the present invention. In general, network  100  includes a provisionable portion  125  and a utility data center portion  150 . In one embodiment, provisionable portion  125  includes a local area network (LAN)  110  communicatively coupled with a storage area network  105 . LAN  110  can include elements such as racks, routers, cables, switches and other elements that are well known in the art. SAN  105  can also include elements such as switches, routers, cables, and the like. Network  100  also includes a plurality of servers  130  coupled with both the SAN  105  and the LAN  110 . Additionally, network  100  includes a plurality of LUNs within a disk array  130  coupled with SAN  105 . 
   In one embodiment, the data center portion  150  includes the network operations center  155 , a utility controller  160 , a network map  165 , a zone configuration verification portion  170 , and a report portion  175 . As described herein, the network operation center  155  is a central management location accessible to technicians. The utility controller  160  is an automated process for managing the network. The network map  165  is a machine-readable map of the actual physical layout of the network as well as the up-to-date allocation of the network  100  resources (e.g., the provisionable portion  125 ). The zone configuration verification portion  170  and the optional report  175  are described in more detail herein. 
   In one embodiment, LAN  110  and SAN  105  include a number of connections  111  through  116  coupled to a number of computing devices  121 - 124  (e.g., servers  120 ). Typically, the servers  121 - 124  are connected with the LAN  110  or SAN  105  using cables or the like. However, wireless connections between the computing devices and LAN  110  and/or SAN  105  are also contemplated. 
   In another embodiment, SAN  105  includes a number of connections  106  through  109  coupled to a disk array  130  having a number of logical unit identifiers (LUNs)  131 - 136 . Typically, the LUNs  131 - 136  are stored in a single location, although this may not always be the case. In this embodiment, the LUNs  131 - 136  are shown as being interconnected with the SAN  105  using cables or the like. However, wireless connections between the LUNs  131 - 136  in SAN  105  are also contemplated. 
   In one embodiment, the connections  111 - 116  and  106 - 109  are connected to switches such as the switches  205 - 208  of  FIG. 2 . That is, although switches  205 - 208  are SAN switches, they may just as appropriately be a combination of LAN and SAN switches. In general, the switches are capable of being programmed or configured such that SAN  105  are logically separated into a number of virtual SANs (VSANs). The programming or configuring of these switches can be changed, thereby changing the resources allocated to the various VSANs. For example, by changing the configuration of switch  205 , computer system  120  can be “virtually moved” from one VSAN to another. 
   The allocation and reallocation of resources between VSANs is one of the valuable operations performed after the actual physical building of the network structure. In one embodiment, the VSANs are referred to as zones. That is, the devices allocated to the VSAN are allocated in zones. Wherein, the security for the VSAN is controlled by ensuring that only the designated devices within the VSAN zone can access the data within the designated zone. 
   One example of a VSAN is shown by the dotted line in  FIG. 1  wherein a server  121  is in a VSAN including cable  111  via SAN  105  and further including LUNs  134  and  136  and also cables  108  and  109 . The associated zone is shown with piping and labeled zone  175 . For example, the zone  175  for the VSAN described herein includes the cabling  111  from the server  121 , the SAN switches within SAN  105  and the cables  108  and  109  up to the connection with the LUNs  134  and  136 . That is, the zone includes the cabling and switches from the server(s) of server  120  to the LUNs of the disk array  130 . A second example of a SAN zone is shown in  FIG. 1  wherein a server  122  is coupled with a SAN zone including cable  113  via SAN  105  and further including cables  106  and  107  coupled with LUNs  131  and  132 . It is appreciated that there may be a plurality of zones within a network such as network  100 . Moreover, it is appreciated that a single connection between a server  120  and a LUN within the disk array  130  would form a zone configuration. 
   In addition to computer systems and switches, LAN  110  and SAN  105  can include other types of devices such as, but not limited to, routers, load balancers, firewalls, and hubs. These other types of devices may also be programmable or configurable. 
   The term “configurable device” is used herein to refer to devices that can be programmed or configured. The term “configuration information” is used herein to refer to information that describes the configuration of a configurable device. In one embodiment, the computer-readable network map need not exist in the form conventionally associated with human-readable maps. Furthermore, a network map may include information such as the types of devices in the SAN and a representation of each VSAN. Other information included in a network map includes, but is not limited to: the network or MAC (media access control) address for the resources of the LAN; the port numbers of the configurable devices; the World Wide Name (WWN) for each port in the SAN switches; the WWN for each port in the disk array; the WWN for each data port in the servers; the socket identifier for each cable connected to each of the resources of LAN and/or SAN; manufacturer and model numbers; and serial numbers. 
   With reference now to  FIG. 2 , the zone configuration verification program  170  reads the desired configuration from the network map  165  and then accesses one or more of the SAN switches (e.g.,  205 - 208 ). In one embodiment, the zone configuration verification program  170  accesses the switches over the LAN  110 . In another embodiment, the zone configuration verification program  170  may access only a master SAN switch (e.g., optional master SAN switch  206 A) which will provide the information for itself and every slave SAN switch it maintains. The zone configuration verification program  170  will check the zone definitions, verifying the validity of the zones, and identifying any errors associated with the zones by comparing the actual zone configurations with the zone configurations outlined in the network map. 
   Examples of the zone errors may include errors of omission, errors of inclusion, errors of correctness, or the like. In one embodiment, configuration errors in the zones are corrected by reconfiguring the SAN switches. In another embodiment, the zone configuration verification program  170  creates a script that can be verified and approved by technical personnel, prior to running the script to make the corrections. The zone configuration verification program  170  can optionally create a detailed report, indicating all of the zones that were checked, and indicated which zones were correct, thus providing an automated audit of SAN security. In another embodiment, the zone configuration verification program  170  can optionally create a detailed report of which zones were invalid, and the specific details of which data item in the zone was incorrect and what the value should be. 
   With reference now to  FIG. 3 , a block diagram  300  of a switch  305  is shown in accordance with one embodiment of the present invention. In general, switch  305  will have an input connection  315  and an output connection  325 . Although one is stated as an input and one as an output, it is appreciated that the data may flow either direction. The utilization of designated input and output sides is merely for purposes of clarity during the description. Moreover, zone  375  may include a plurality of ports on the switch, or a plurality of switches and ports. The actual size of the zone will vary according to the size of the established VSAN and the number of connections, devices and switches associated therewith. 
   As described herein, the zone  375  is utilized to provide a “security blanket” around the connections and the switch or switches. For example, connector  315  is coupled with switch  305  on one end. On the other end, connector  315  is coupled with a computing device (e.g., server  121 ). In the network map, the connector  315  is dedicated to a specific computing device. Therefore, the specific computing device (e.g., server  121 ) will have access to the zone while other computing devices (e.g., server  122 ) will not be a part of the zone  375 . 
   Therefore, the zone  375  ensures that only the designated computing device (e.g., server  121 ) is accessing the switch  305  via a specific port. By utilizing the zone configuration verifier to check the identification of the cables and switches, security of the network is maintained. That is, since the computing device (e.g., server  121 ) is identified via its connection prior to accessing the switch  305 , there is a security blanket stopping unauthorized computing systems connections from accessing and/or utilizing switch  305  within the specified zone  375 . 
   With reference now to  FIG. 4 , a block diagram  400  of an automatic verifier of a zone configuration for a network VSAN is shown in accordance with an embodiment of the present invention. In one embodiment, the zone configuration verifier  400  includes an actual zone configuration accessor  410 . The zone configuration verifier  400  also includes a machine-readable map accessor  420 . The zone configuration verifier  400  further includes a verification protocol  430 . In one embodiment, the zone configuration verifier  400  also includes an optional report generator  440 . 
   As described herein, zone configuration verifier  400  is utilized to verify that the devices accessing the VSAN are the correct device and that no other connections are inappropriately accessing the VSAN. In operation, the zone configuration verifier  400  initially utilizes the actual zone configuration accessor  410  to accesses a zone configuration, such as zone  375  of  FIG. 3 . The actual zone configuration accessor  410  then receives the status of the zone  375  and associated devices. 
   The zone configuration verifier  400  then utilizes the machine-readable map accessor  420  to access the machine-readable map (e.g., map  165  of  FIG. 1 ) and retrieve the list of devices which are supposed to be included within zone  375 . 
   The zone configuration verifier  400  then utilizes the automatic verification protocol  430  to compare the results from the actual zone configuration accessor  410  to the results from the machine-readable map accessor  420 . In one embodiment, once the results are compared, the optional report generator  440  generates a report. The report may be a report stating that the zone configuration is correct, or that it is incorrect, that it is missing, or the like. In another embodiment, if the result of the comparison of actual zone configuration to the network map zone configuration does not match, an automatic fix is applied via the zone configuration verifier  400 . For example, the zone configuration verifier  400  will reapply the information from the network map to the actual zone configuration operating on the SAN fabric. 
   Referring now to  FIG. 5 , a flowchart of one method for automatic verification of a zone configuration for a plurality of network switching devices is shown in accordance with one embodiment of the present invention. 
   With reference now to step  502  of  FIG. 5 , and to  FIG. 2 , one embodiment accesses an actual zone configuration including a plurality of network switching devices (or plurality of ports of one network switching device), the actual zone configuration for defining the switching devices which are actually part of the zone. For example, the zone configuration verifier  170  will contact a SAN zone (e.g., SAN zone  175 ) via a LAN and query the network configuration construct. 
   In one embodiment, the zone configuration verifier  170  will verify that the soft zone configuration includes the appropriate devices by receiving the unique name of the zone. In another embodiment, the zone configuration verifier  170  will verify the WWN of the host bus adapter (HBA) port on the computational server (e.g., server  121 ). The zone configuration verifier  170  will then verify the WWN of the port on the storage array (e.g., LUN  131 ). 
   The following embodiment, pertains particularly to soft zones as described above. However, in another embodiment in which the present invention is employed, embodiments of the present invention pertain particularly to hard zones. In yet another embodiment, the present invention pertains to the utilization of both soft and hard zones. With respect to hard zones, the zone configuration verifier  170  will verify that the hard zone configuration includes the appropriate port identifier/switch identifier on the switch connected to a particular port on a computational server. The zone configuration verifier  170  will further verify that the hard zone configuration includes the appropriate port identifier/switch identifier on a switch connected to a particular port on a switch array. 
   In another embodiment, the automatic verification of the zone configuration accesses a master network switching device  206 A which provides a plurality of actual zone configurations for a plurality of ports and/or network switches. In another embodiment, each network switch is accessed individually. In yet another embodiment, each port on each network switch is accessed individually. 
   With reference now to step  504  of  FIG. 5 , and to  FIG. 2 , one embodiment accesses a machine-readable map of the network, wherein the map provides a pre-determined zone configuration defining the devices which should be part of the zone. For example, the zone configuration verification program  170  will contact a machine-readable map  165  and query the map  165  regarding the specific zone configuration. As described herein, the query will include a status request of the zone configuration and the identifier of the computing devices that should be utilizing the connectors and switches (e.g., via a specific port). In one embodiment, the identifier is a unique identifier for the computing device, such as the WWN. 
   Referring now to step  506  of  FIG. 5  and to  FIG. 2 , one embodiment automatically verifies that the actual zone configurations correlate with the pre-determined zone configurations defined by the machine readable map  165 . For example, the verification will verify that the actual zone configuration is correct for the particular connectors, switches and devices to which it is associated. That is, a verification is performed by comparing the WWNs defined in the actual zone configuration with the WWNs defined in the machine-readable map pre-defined zone configuration. 
   In one embodiment, the verification protocol will validate that a corresponding zone has been defined in the SAN fabric. The verification protocol will validate that the list of WWN entries in the map corresponds with the WWN entries in the SAN fabric (e.g., the actual zone configuration). The verification protocol will also verify that the actual zone is correctly configured as either a hard zone, a soft zone, or both a hard zone and a soft zone. 
   In general, hard zoning is based on hardware and soft zoning is based on software. Basically, hard zoning is used for checking the port numbers of specified switches and soft zoning is used for checking the WWN that are the identifiers in the network card of the devices that are utilizing (or asking to utilize) the SAN. Therefore, as is well known in the art, the utilization of a hard zone provides a physical barrier to any device trying to improperly access the zone, while the utilization of a soft zone provides a virtual barrier to any device trying to improperly access the zone. Thus, the combination of a hard zone and a soft zone will limit access to the zone via the physical hardware assigned to the zone and the WWN (or other) identifiers associated with the software within the hardware. 
   In one embodiment, the network map contains the mappings of each LUN to each server. In another embodiment, the zones are not recorded in the machine-readable map&#39;s database, but can be inferred from the database entry of the corresponding LUN. That is, when a disk is first bound to a server, the map will record the binding of the disk LUN to the server. At that time, the zone is also created. Thus, a properly bound disk LUN should always have a zone associated with it, and the zone verification protocol will ensure that the zone really was created. 
   When the LUN to server mapping is compared to the actual zones for each LUN to server mapping, a comparison is performed between the WWN of the LUN to the list of WWN entries defined in the actual zone. Additionally, a comparison is performed between the WWN of the server to the list of WWN entries defined by the actual zone. After examining all the LUN-to-server mappings, verification is performed to ensure that there are no LUNs that were not checked in the prior validation. That is, verify that there are no LUNs that don&#39;t have an associated zone in the map. Another verification is performed to ensure that there are no servers that were not checked in the prior validation. That is, verify that there are no servers that don&#39;t have an associated zone in the map. 
   Verification is then performed to ensure that every actual zone configuration is defined in the machine-readable map pre-defined zone configuration. That is, to ensure that there are no remaining actual zone configuration in the network (e.g., the SAN) that have not been examined. In other words, verify that there are no actual zone configurations in the SAN fabric that do not have an associated zone configuration in the machine-readable map. This verification ensures that an actual zone configuration has not been removed or overlooked from the SAN fabric. 
   Referring still to step  506  of  FIG. 5 , in one embodiment, each time an error is found during the verification process, an error message is provided indicating the details of the actual zone configuration error. In one embodiment, the error message may also provide instructions for automatic correction of the zone configuration error. For example, the error message may contain machine-readable code that can be automatically utilized to fix the error associated with the zone configuration. In another embodiment, the verification process may automatically fix the error associated with the zone configuration and provide a report of the error. In yet another embodiment, the verification process may automatically fix the error and provide an “actions taken” message as a portion of the error message. 
   In one embodiment, the automatic verifier will provide a report documenting the result of the automatic verifying. That is, providing a user-readable report outlining the results of the analysis including correctly defined zone configurations. The report may include the number of zone configurations verified, the identifier of each of the zone configurations, the switch and/or port identifiers associated with each zone configuration, the WWN of the device coupled with the zone configuration, and the like. In another embodiment, the report may be configured to provide whatever information the data center administrator desires. That is, the report format, output and information thereon are adjustable based on user preference. 
     FIG. 6  illustrates an exemplary provisionable network in which embodiments of the present invention can function. Provisional network, or utility data center (UDC),  600  is shown bounded by a security boundary  650 . In one embodiment, security boundary  650  is virtual. Boundary  650  is shown here only to help illuminate the concepts presented herein. Typical UDC  600  comprises an operations center local area network (LAN)  605 , a data center utility controller LAN  601  and resource pools  606 . It is noted here that, by their very nature, UDCs are flexible in their composition, comprising any number and type of devices and systems. It is this flexibility from which they derive their usefulness. The specific architecture illustrated in  FIG. 6 , therefore, is not meant to limit the application of embodiments of the present invention to any particular provisionable network architecture. 
   Typical UDC  600 , in this illustration, communicates with the outside world via the Internet  620  and virtual public networks (VPNs) in the Internet. The communications links that enable this communication are protected by firewall  610 . Firewall  610  is shown to illustrate a concept and is not meant to imply any particular method or system of intrusion protection. Many types of hardware and software firewalls are well known in the art and firewall  610  may be either or both. 
   It is noted here that communications into and out of a provisionable network, as in any network, is accomplished through ports such as illustrated at  681 . Communications between devices within a network are also conducted through ports, as alluded to at  682 . It is noted that ports are not necessarily physically located at the periphery of a network but are logical end points. External ports  681  and intra-network ports  682  are shown only to help illustrate the concepts presented in embodiments of the present invention. It is also noted that virtual security boundary  650  does not exist in a physical sense. Resources included in the servers and LANs comprising utility data center  600  may include devices and servers located remotely from the other elements of the UDC. 
   Embodiments of the present invention operate in an environment that distinguishes between three trust domains established in the trust hierarchy of a utility data center. One trust domain is embodied in the Operations Center (OC) LAN  605  where non-critical UDC and other operations-related functions reside. The level of trust is less than the data center utility controller LAN  601 . Another trust domain is the data center utility controller LAN  601  where tasks relating to the automated provisioning of managed resources  606  reside. Access to the data center utility controller LAN  601  is severely restricted from this domain. A third domain comprises the managed resources LANs where the managed resources  606  reside. These LANs are typically not trusted. It is noted here that clients of the utility data center originate outside the above trust structure and access elements of the UDC via the Internet or a virtual private network (VPN) resident in the Internet infrastructure. 
   As shown in  FIG. 6 , operations center (OC) LAN  605  comprises an internal trust domain. Included in OC LAN  605  are open view server  609 , network intrusion detection system (NIDS)  612  and NIDS manager  611 . It is noted that, though NIDS  612 , NIDS manager  611  are illustrated as computer-like devices, their physical existence is not limited to a particular device. Each may exist as a standalone device or implemented as software resident in a physical device or server. 
   The heart of the exemplary utility data center illustrated in  FIG. 6  is the data center utility controller (UC) LAN,  601 . This LAN represents another, higher, internal trust domain. UC LAN communicates through OC LAN  605  and is typically separated from it by various forms of firewalls  602 . Data center UC LAN  601  can comprise various numbers of resource managers, such as illustrated at  603 . The flexibility inherent in the UDC concept can result in many combinations of resources and resource managers. Resource managers  603  are the typical interface with the various pools of resources  606 , communicating with them through ports and some sort of switching network as indicated by the tier  1  switch at  608 . 
   In one embodiment, the resource managers  603  include an actual zone configuration accessor for accessing the actual zone configuration coupled with a port of a network switch. The actual zone configuration defining the device actually coupled with the port of the network switch. In addition, the resource manager  603  also includes a verification protocol for verifying that the actual zone configuration on the port of the network switch correlates with the pre-determined zone configuration defined by the machine-readable map. In another embodiment, the verification protocol may reside on a separate computing system within the UDC. In yet another embodiment, the verification protocol may reside on a plurality of the computing systems within the UDC. 
   Resource pools  606  are limitlessly flexible, comprising any conceivable combination of data servers, computational capability, load balancing servers or any other device or capability imaginable. Because the possible varieties of resources that can be included in resource pools  606 , they are separated from data center UC LAN  601  by firewalls  604 , which, like UC firewalls  602 , can be software or hardware or both, in many combinations. 
   It is noted that embodiments of the present invention can run in many different environments. One network management environment in which an embodiment operates serves as an end-to-end service management infrastructure and is particularly well suited to managing a provisionable network which can also be known as a utility data center (UDC). 
   In summary, embodiments of the present invention provide methods and systems for automatic verification of a zone configuration of a plurality of network switches. By using the methods and systems for automatic verification of a zone configuration of a plurality of network switches, one or more switches (e.g., SAN switches) can be automatically checked for correctness of their configured zones. By using the automated method, correctness of the configuration of networked devices can be verified in much less time, at greatly reduced expense. 
   In addition, the present invention allows a network administrator to automatically discover zones configuration problems in a SAN configuration. The problems include, but are not limited to, forgotten zone definitions that should have been deleted, missing zones that were omitted by mistake, incorrect zones caused by user error, security-breaching zone changes introduced maliciously, and the like. In one embodiment, the corrective action is taken automatically, thereby reducing human error, reducing cost and increasing security. 
   Additionally, by running automatically, the verifier can be run often, or constantly to provide an ongoing validation of the network. Moreover, the present invention provides automation of the zone-checking portion of a security audit. Therefore, the report is valuable even when reporting no errors with respect to the zones. That is, a report having no zone errors provides validation of the operation of the zones throughout the network (e.g., the SAN). 
   Embodiments of the present invention are thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the following claims.