A network management device sends an SNMP multi-cast GET on a network to discover all the network devices on the network or subnet. The network management device builds a management information base (mib) based on the responses received from the SNMP multi-cast GET. The mib information is then sent to a network management system (NMS).
The SNMP multi-cast GET can be sent based on a command to discover network devices on the network or can be sent based on a polling algorithm. The system and method also include the ability to send an SNMP multi-cast SET to set the same parameter(s) on all the devices on the network/subnet.
|
9. A system comprising:
a network interface operable to receive a command from a network management system to discover network devices on a network of the network management device, wherein the network management system is located on another side of a firewall from the network, send a simple network management protocol (SNMP) multi-cast GET on the network, receive one or more responses to the SNMP multi-cast GET, wherein the one or more responses to the SNMP multi-cast GET are associated with a different network device on the network, and send at least a portion of a mib database to the network management system in response to the command; and
a management information base (mib) manager operable to build or update the mib database based on the one or more responses to the SNMP multi-cast GET.
1. A method of operating a network management device comprising:
in a network interface of the network management device, receiving a command from a network management system to discover network devices on a network of the network management device, wherein the network management system is located on another side of a firewall from the network;
sending from the network interface a simple network management protocol (SNMP) multi-cast GET on the network;
receiving at the network interface one or more responses to the SNMP multi-cast GET, wherein the one or more responses to the SNMP multi-cast GET are associated with a different network device on the network;
building or updating in a management information base (mib) manager of the network management device, a mib database based on the one or more responses to the SNMP multi-cast GET; and
sending from the network interface at least a portion of the mib database to the network management system in response to the command.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
7. The method of
8. The method of
10. The system of
11. The system of
12. The system of
13. The system of
14. The system of
15. The system of
16. The system of
|
The system and method relates to Simple Network Management Protocol (SNMP) systems and in particular to SNMP systems that use multi-cast.
Currently, Network Management Systems (NMS) that use Simple Network Management Protocol (SNMP) send individual SNMP GET commands to all addresses on a network as a process for discovering devices on the network. If a device resides at the address, the device responds to the SNMP GET so the NMS will know that there is a device at the address. If a device does not reside at an address on the network, the NMS will time-out and assume that there is not a device currently at the address. Through this process, the NMS can determine where devices are on the network.
The problem with this type of process is that for a large network the number of packets sent by the NMS to discover all the devices on the network may be very time consuming and will require the NMS to send a large amount of packets. For example, if the network is an Internet Protocol (IP) class B network, the NMS would have to send out over 65,000 SNMP GETs to determine if there are devices at each address on the network. If only half the IP addresses are used, the NMS will send over 32,000 messages that are not even answered. This process tends to be very inefficient for large networks and creates a lot of unnecessary traffic on the network.
This problem only gets exacerbated when there is a firewall between the NMS and the network. Some firewalls are configured to either not allow traffic on a specific IP port or to limit traffic on a specific IP port. In these cases, the NMS may not be able to discover all the devices on the network due to the restrictions of the firewall.
The system and method are directed to solving these and other problems and disadvantages of the prior art. A network management device sends an SNMP multi-cast GET on a network to discover all the network devices on the network or subnet. The network management device builds a Management Information Base (MIB) based on the responses received from the SNMP multi-cast GET. The MIB information is then sent to a Network Management System (NMS).
The SNMP multi-cast GET can be sent based on a command to discover network devices on the network or can be sent based on a polling algorithm. The system and method also include the ability to send an SNMP multi-cast SET to set the same parameter(s) on all the devices on the network/subnet.
In order to describe the manner in which other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described below will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to limit its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:
The following description and associated Figures teach the best mode of the invention. For the purpose of teaching inventive principles, some conventional aspects of the best mode may be simplified or omitted. The following claims specify the scope of the invention. Note that some aspects of the best mode may not fall within the scope of the invention as specified by the claims. Thus, those skilled in the art will appreciate variations from the best mode that fall within the scope of the invention. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific examples described below, but only by the claims and their equivalents.
Network device 101 can be any type of device that can be managed on network 120, such as a server, a router, a hub, a printer, a firewall, a personal computer, a telephone, a wireless access point, and the like.
Network management device 130A can be any type of device that resides on a network, such as a server, a router, a hub, a printer, a firewall, a personal computer, a telephone, a wireless access point, and the like. In a typical example, network management device 130A will be a router. Network management device 130A further comprises network interface 131A, MIB Manager 132A, and MIB database 133A. Network interface 131A can be any type of device that can access network 120, such as an Ethernet interface, a wireless interface, a fiber optic interface, a modem, an Integrated Digital Services Network (ISDN) interface, a Digital Subscriber Line (DSL) interface, and the like. MIB manager 132A can be software/hardware that can manage MIB database 133A. MIB database 133A can be any type of MIB database, such as an SNMP MIB 102 or some other type of MIB record storage. MIB database 133A can be stored in a memory using a database, a file system, a directory service, and the like. The memory can be any type of memory that can store information, such as a Flash memory, a hard disk, a Random Access Memory (RAM), and the like.
Network management system 110 sends a command to network management device 130 to discover network devices 101 on network 120. Network interface 131A receives the command to discover network devices 101 on network 120. In one embodiment, network interface 131A responds to receiving the command to discover network devices 101 on the network 120 and sends a Simple Network Management Protocol (SNMP) multi-cast GET on network 120. Multi-cast is the sending of a message to a group of addresses. For example, a multi-cast message can go to a subnet (i.e., a portion of a class of an IP network) or a multi-cast can be a broadcast to a full IP network (i.e., all the addresses of a class IP network).
In this example, the SNMP multi-cast GET is a broadcast to all devices on network 120. Since the multi-cast GET is addressed to all network devices 101 on network 120, both network devices (101A and 101B) respond by sending a response to the SNMP multi-cast GET. The response to the SNMP multi-cast GET contains the address (i.e., in the IP address) of the particular network device (101A or 101B) and some or all of the information in SNMP MIB 102 of the particular network device (101A or 101B). In this example, network interface 131A receives the responses to the SNMP multi-cast GET from network devices 101A and 101B. Based on the response, MIB Manager 132A builds or updates MIB database 133A.
How MIB Manager 132A builds or updates MIB database 133A depends on if a response from a particular network device has been received. For example, assume that it is the first time that the SNMP multi-cast GET has been sent out on network 120 and that MIB database 133A is empty. The responses received from network devices 101A and 101B are used to build MIB database 133A. One way to build MIB database 133A is to have an instance for each network device 101 on network 120. Another way to do this would be to merge the information from network devices 101A and 101B in MIB database 133A. Typically, network devices 101 will send all of the contents of SNMP MIB 102 to network management device 130A. MIB Manager 132A then replicates the sent MIB information in MIB database 133A.
Later, network management device 130A can send additional SNMP multi-cast GET(s); based on the response to the additional SNMP multi-cast GET(s), MIB Manager 132A updates MIB database 133A with any changes. The additional SNMP multi-cast GET(s) can be sent based on receiving second command to discover network devices 101 on network 120 or based on some type of polling algorithm. Network management device 130A may then respond to the command to discover network devices by sending some or all of the contents of MIB database 133A to Network Management System 110.
Other alternatives of the above-described processes can also be implemented. For example, network management device 130A can periodically send out an SNMP multi-cast GET to update MIB database 133A. Based on the changes, network interface 131A can send at least a portion of MIB database 133A to network management system 110 (without receiving a request from network management system 110 to send MIB database 133A). The sending of MIB database 133A can be triggered based on an SNMP trap, based on changes to MIB database 133A, and the like.
The advantage of the above-described process is illustrated in the following example. Assume that network 120 is a class C IP network with 256 addresses. Using the prior art process, Network Management System 110 would have to send out 254 (or less depending upon the subnet mask) messages to discover devices on network 120. Using the above-described process, network management system 110 has to send a single message to network management device 130A; network management device 130A sends out a single SNMP multi-cast GET. This is a dramatic reduction in the number of messages and packets that must be sent and received.
Networks 220-222 can be any type of network, such as the Internet, an Internet Protocol (IP) network, a Local Area Network (LAN), a Wide Area Network (WAN), the Public Switched Telephone Network, a wireless network, a wired network, any combination of these, and the like. Networks 220-222 can use one or more protocols, such as Internet Protocol (IP), Integrated Digital Services Network (ISDN), Synchronous Optical Networking (SONET), Asynchronous Transfer Mode (ATM), a combination of these, and the like. In a typical example, network 220 is the Internet, and networks 221-222 comprise a corporate network. Networks 221-222 can comprise physical networks of a logical network (i.e., an IP network). Networks 221 and 222 can comprise separate IP networks.
Firewall 240 can be any device that can limit access between network 220 and networks 221-222. Firewall 240 can be implemented on a server, a router, a switch, a hub, a computer, a Private Branch Exchange (PBX), and the like.
Network management system 110 sends a command to discover network devices 101 on network 221 to network management device 130A. Network interface 131A receives the command to discover network devices 101 on network 221. Network interface 131A sends a Simple Network Management Protocol (SNMP) multi-cast GET on network 221.
In this example, the SNMP multi-cast GET is a broadcast to all devices on network 221. Network devices (101A and 101B) respond by sending a response to the SNMP multi-cast GET. The response to the SNMP multi-cast GET contains the address (i.e., in the IP address) of the particular network device (101A or 101B) and some or all of the information in SNMP MIB 102 of the particular network device (101A or 101B). Network interface 131A receives the responses to the SNMP multi-cast GET from network devices 101A and 101B. Based on the response, MIB Manager 132A builds or updates MIB database 133A.
The above process is repeated when network management system 110 sends a command to network management device 130B to discover network devices 101 on network 222. Network interface 131B receives the command to discover network devices 101 on network 222. Network interface 131A sends a Simple Network Management Protocol (SNMP) multi-cast GET on network 222.
In this example, the SNMP multi-cast GET is a broadcast to all devices on network 222. Network devices (101C and 101D) respond by sending a response to the SNMP multi-cast GET. The response to the SNMP multi-cast GET contains the address (i.e., in the IP address) of the particular network device (101C or 101D) and some or all of the information in SNMP MIB 102 of the particular network device (101C or 101D). In this example, network interface 131B receives the responses to the SNMP multi-cast GET from network devices 101C and 101D. Based on the response, MIB Manager 132B builds or updates MIB database 133B. Network management system 110 can then receive some or all of the data in MIB databases 133A and 133B by sending commands to get the information, or network management devices 130A and/or 130B can send the information in MIB databases 133A and/or 133B. Network management system 110 takes the information from MIB databases 133A and 133B to get a composite view of all the network devices 101A-101D on networks 221-222.
One key advantage to this type of system is that it dramatically reduces the amount of traffic that is sent through firewall 240. In this example, network management system 110 can discover all the devices on networks 221-222 by sending two commands and receiving two responses. This is an advantage over the prior art where network management system 110 would have to send a message to each address on network 221-222. Depending on how firewall 240 is configured, firewall 240 may not allow the sending of packets to each address on networks 221-222. Another advantage is that Network Management System 110 can send messages using a protocol with an allowed port number (i.e., HTTP) so that the Network Management System 110 can send and receive messages through firewall 240.
The process begins in step 300 where network interface 131 waits to receive a discover command from network management system 110. Alternatively, network interface 131 can poll communication devices 101 periodically or based on some other type of algorithm. If network interface 131 does not receive a discover command, or it is not time to poll and send out an SNMP multi-cast get, the process repeats step 300.
Otherwise, if network interface 131 receives a discover command or determines it is time to poll by sending out an SNMP multi-cast GET, network interface 131 sends 302 an SNMP multi-cast GET on network 120. Network interface 131 determines in step 304 if a timeout has occurred. The timeout is used to gather the response(s) from network devices 101 on network 120. If a timeout has occurred in step 304, the process goes back to step 300. Otherwise, if a timeout has not occurred in step 304, network interface 131 determines in step 304 if it has received a response to the SNMP multi-cast GET that was sent in step 302. If a response has not been received in step 306, the process goes to step 304. Otherwise, if a response has been received in step 306, MIB Manager 132 updates/builds MIB database 133 based on the information received in the response to the SNMP multi-cast GET. The process then goes step 304.
If the command in step 402 is not a command to send an SNMP multi-cast SET, network interface 131 gets 406 the network device address (or some other information identifying the network device 101) from the command and the value to set the parameter(s) to. Network interface 131 sends 408 an SNMP SET to network device 101 using the address and value(s) to set the parameter(s). If there are more devices to send an SNMP SET to in step 410, the process goes to step 406. Otherwise, the process goes to step 400.
Otherwise, if the command is not an SNMP SET in step 502, network device 101 determines in step 506 if the command is an SNMP GET command. If the command is not an SNMP GET command in step 506, the process goes to step 500. Otherwise, if the command in step 506 is an SNMP GET command (either a regular SNMP GET command or an SNMP multi-cast GET command), network device 101 gets 508 the requested parameters and sends 510 a response to the SNMP GET. The process then goes to step 500.
Herein, the phrases “at least one,” “one or more,” and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C,” “at least one of A, B, or C,” “one or more of A, B, and C,” “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.
Herein, the term “a,” “an,” or another entity refers to one or more of that entity. As such, the terms “a” (or “an”), “one or more” and “at least one” can be used interchangeably herein. It is also to be noted that the terms “comprising,” “including,” and “having” can be used interchangeably.
Of course, various changes and modifications to the illustrative embodiment described above will be apparent to those skilled in the art. These changes and modifications can be made without departing from the spirit and the scope of the system and method and without diminishing its attendant advantages. The above description and associated figures teach the best mode of the invention. The following claims specify the scope of the invention. Note that some aspects of the best mode may not fall within the scope of the invention as specified by the claims. Those skilled in the art will appreciate that the features described above can be combined in various ways to form multiple variations of the invention. As a result, the invention is not limited to the specific embodiments described above, but only by the following claims and their equivalents.
Patent | Priority | Assignee | Title |
11362880, | May 12 2017 | HIRSCHMANN AUTOMATION AND CONTROL GMBH | Network-operating method in which a query is broadcast by SNMP protocol |
12166636, | Sep 20 2023 | Insight Direct USA, Inc. | Network protocol-based interrogation for network device characterization |
Patent | Priority | Assignee | Title |
6188691, | Mar 16 1998 | Hewlett Packard Enterprise Development LP | Multicast domain virtual local area network |
20040019668, | |||
20050198267, | |||
20060187858, | |||
20070047545, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Feb 21 2011 | KRISHNA, NISHANT | AVAYA Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 025888 | /0876 | |
Mar 02 2011 | Avaya Inc. | (assignment on the face of the patent) | / | |||
Dec 21 2012 | Avaya, Inc | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A | SECURITY AGREEMENT | 029608 | /0256 | |
Mar 07 2013 | Avaya, Inc | BANK OF NEW YORK MELLON TRUST COMPANY, N A , THE | SECURITY AGREEMENT | 030083 | /0639 | |
Jan 24 2017 | VPNET TECHNOLOGIES, INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | Octel Communications Corporation | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | AVAYA INTEGRATED CABINET SOLUTIONS INC | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jan 24 2017 | AVAYA Inc | CITIBANK, N A , AS ADMINISTRATIVE AGENT | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 041576 | /0001 | |
Jul 14 2017 | Extreme Networks, Inc | Silicon Valley Bank | SECOND AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT | 043200 | /0614 | |
Jul 14 2017 | AVAYA Holdings Limited | Extreme Networks, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 043569 | /0047 | |
Jul 14 2017 | AVAYA Inc | Extreme Networks, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 043569 | /0047 | |
Jul 14 2017 | Avaya Communication Israel Ltd | Extreme Networks, Inc | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 043569 | /0047 | |
Oct 27 2017 | Extreme Networks, Inc | Silicon Valley Bank | THIRD AMENDED AND RESTATED PATENT AND TRADEMARK SECURITY AGREEMENT | 044639 | /0300 | |
Nov 28 2017 | CITIBANK, N A | VPNET TECHNOLOGIES, INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 030083 0639 | 045012 | /0666 | |
Nov 28 2017 | CITIBANK, N A | OCTEL COMMUNICATIONS LLC FORMERLY KNOWN AS OCTEL COMMUNICATIONS CORPORATION | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA INTEGRATED CABINET SOLUTIONS INC | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | CITIBANK, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 041576 0001 | 044893 | /0531 | |
Nov 28 2017 | THE BANK OF NEW YORK MELLON TRUST COMPANY, N A | AVAYA Inc | BANKRUPTCY COURT ORDER RELEASING ALL LIENS INCLUDING THE SECURITY INTEREST RECORDED AT REEL FRAME 029608 0256 | 044891 | /0801 | |
May 01 2018 | Silicon Valley Bank | Extreme Networks, Inc | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 046051 | /0775 | |
May 01 2018 | Extreme Networks, Inc | BANK OF MONTREAL | SECURITY INTEREST SEE DOCUMENT FOR DETAILS | 046050 | /0546 | |
Aug 18 2023 | Extreme Networks, Inc | BANK OF MONTREAL | AMENDED SECURITY AGREEMENT | 064782 | /0971 | |
Aug 18 2023 | AEROHIVE NETWORKS, INC | BANK OF MONTREAL | AMENDED SECURITY AGREEMENT | 064782 | /0971 |
Date | Maintenance Fee Events |
Oct 13 2016 | ASPN: Payor Number Assigned. |
Aug 23 2019 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Aug 23 2023 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Date | Maintenance Schedule |
Feb 23 2019 | 4 years fee payment window open |
Aug 23 2019 | 6 months grace period start (w surcharge) |
Feb 23 2020 | patent expiry (for year 4) |
Feb 23 2022 | 2 years to revive unintentionally abandoned end. (for year 4) |
Feb 23 2023 | 8 years fee payment window open |
Aug 23 2023 | 6 months grace period start (w surcharge) |
Feb 23 2024 | patent expiry (for year 8) |
Feb 23 2026 | 2 years to revive unintentionally abandoned end. (for year 8) |
Feb 23 2027 | 12 years fee payment window open |
Aug 23 2027 | 6 months grace period start (w surcharge) |
Feb 23 2028 | patent expiry (for year 12) |
Feb 23 2030 | 2 years to revive unintentionally abandoned end. (for year 12) |