The field of the invention relates to the field of DHCP Policy Management in a network.
Dynamic Host Configuration Protocol (DHCP) was developed in the 1980's to allow “workstations to dynamically find their protocol address” as described in A Reverse Address Resolution Protocol, Finlayson et. al., June 1984, IETF and for “passing configuration information to hosts” as described in [RFC1531(https://tools.ietf.org/html/r fc1531)/and RFC1541 (https://tools.ietf.org/html/rfc1541)], and it has become one of the cornerstones of computer networking. Other background information can be found in U.S. Pat. No. 8,543,674 and European Patent No. 2048857, which are hereby incorporated by reference in their entirety.
The expansion of the number and types of network devices has made DHCP one of the most widely used network protocols. Modern practices in network monitoring, security, coordination and control often depend on policies that determine how network addresses are assigned and which DHCP options must accompany the assignment of addresses.
IP Address Management (IPAM) has been developed to manage all aspects of DHCP and DNS services for large networks, and these networks often include 2 or more specialized servers running DHCP that support large numbers of host computer clients. Such servers can be expensive to install and maintain and complicated to manage and therefore may be best suited for use by large corporations and service providers. Small installations often rely on the DHCP servers that come with their routers, wireless access points, network switches and devices that may host networks, including virtual machine stations, laptops, tablets, smartphones and others. These installations are constrained by the use of the limited tools provided with the routers and other devices. IPAM is typically only one aspect of network policy that also includes other services, such as security and routing services.
A notable trend in modern IP networks is the proliferation of subnets, as is the case in small businesses and organizations, educational institutions, residences and other entities. There is a corresponding increasing presence of numerous DHCP servers to provision host devices with IP addresses and network configuration information. Many network infrastructure devices, such as routers, network switches, wireless access points, gateways and others have built-in DHCP servers that are not always used. Virtual machine hosts and cloud platforms supporting virtual networks often also have built-in DHCP servers, for example VMWare's VMXNET (See: vmxnet3-vmware kernel module, OpenVM Tools, VMWare, 2011). Configuring a large number of network infrastructure devices requires a significant level of network expertise and is time-consuming using current tools because each subnet must be individually considered. In addition, it can be difficult to monitor the correct behavior of network infrastructure devices because there is no uniform way to configure and collect lease and device identity information from large numbers of diverse devices. Examples of device identity information include MAC addresses and unique device identifiers (DUID).
Each DHCP server requires a specific configuration in order to integrate with a larger network in conformance with a network policy. Unfortunately, however, although most DHCP servers are derived from a very small set of technical implementations, such as the implementations from Internet Systems Consortium (See: DHCP server documentation, Internet Systems Consortium, 2001-2015), there is no standard way to discover the presence and type of DHCP servers, to monitor the behavior of said servers or to coordinate the configuration of said servers. Discovering, monitoring and coordinating the configuration often requires significant hands-on interaction for network administrators and presents a particular challenge where many different server types are used.
Furthermore, DHCP service configurations do not exist in isolation, and such service configurations must be coordinated with other service configurations, such as DNS services, managed switches, gateways, firewalls, proxy servers, VPN tunnels, wireless access points, and others. In addition, achieving a desired level of network performance and security can also require configuration of a number of services other than DHCP, such as (but not limited to) routing, quality of service (QoS) and firewall-protection. Increasingly, some of these services can exist remotely from the DHCP devices, for example, cloud-based DNS services.
Methods and systems are therefore required that can monitor behavior of DHCP and associated network infrastructure services and automatically deploy and coordinate network policies over a wide area distributed network containing many services of various types.
Thus, needs exist for improved techniques for network policy updating, coordination, application and deployment regardless of the type of DHCP and other service configurations implemented.
Provided herein are embodiments of for network device discovery and network policy updating, coordination, application and deployment regardless of the type of DHCP and other service configurations implemented. The configuration of these devices is described in detail by way of various embodiments which are only examples.
Methods are disclosed for configuring a network consisting of an IP Policy Management (IPPM) service and a plurality of distributed managed network devices supporting DHCP and other service roles. Managed network devices are discovered by the IPPM service and the configuration of each of the managed network devices is determined by the selection of a policy including a plurality of rules specific to the service roles and capabilities of the network devices. Configuration of each of the network devices is deployed via the network to the network devices.
Systems are disclosed for configuring a network consisting of an IPPM service and a plurality of distributed network devices supporting DHCP and other service roles. Network devices are discovered by the IPPM service and the configuration of each of the network devices is determined by the selection of a policy including a plurality of rules specific to the service roles and capabilities of the network devices. Configuration of each of the network devices is deployed via the network to the network devices.
Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional devices, methods, features and advantages be included within this description, be within the scope of the subject matter described herein and be protected by the accompanying claims. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims.
The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.
Illustrated in the accompanying drawing(s) is at least one of the best mode embodiments of the present invention. In such drawing(s):
Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.
Provided herein are embodiments for discovering and capturing network devices to be managed; defining and updating a network policy for the managed network devices; applying said network policies to generate service configurations for the managed network devices; and automatically deploying the service configurations to the managed network devices.
Discovery and Capture
As illustrated by
The network system architecture 100 can also include an IP Policy Manager (IPPM) service 130 stored in non-transitory memory and hosted on an Internet cloud-based service or Internet-based server and Internet-based cloud services 120a-n for use by the host devices and communicatively coupled to the network 104. Examples of cloud services 120a-n include Domain Name Services (DNS), Network Time Protocol (NTP) services, logging services and others.
It should be understood that devices and networks used to implement the generalized architecture described above are known in the art and generally include processors, instructions stored in non-transitory memory and executable by the processors, non-transitory storage media for storing data in databases, power modules, communication signal transmitters/receivers, protocols, and others as appropriate.
As shown in the example embodiment diagram of
Similarly, managed network device 300 can include additional or other service role components 304 locally connected and communicatively coupled to the configurator component 302, whereby network event and status information 307 can be forwarded up to the remote IPPM service 301 and service role configuration information 308, in accordance with network policies defined for the particular subnetwork by the IPPM service 301, can be sent down to the configurator component 302 and then to the service role component 304.
In an example embodiment, a managed network device (see also 300 of
The managed device can also be connected to an upstream network 224, can acquire an IP address automatically and can repeatedly attempt to connect to the IPPM service 222 over the network 224 using a secure communications method such as HTTPS as shown in step 203.
Once a connection is made the managed device can use a security key to authenticate with the IPPM service 222 in step 204a. If unsuccessful in step 204b, then a default DHCP configuration can be applied in step 204c before looping back to step 203. If successful in step 204b, in step 205 the managed device can receive a set of configuration data, including, but not limited to, DHCP configuration from the IPPM service 222. The managed device can also receive updated security keys, specific to the particular device, for use in future communications. The managed device can update the new configuration to the locally connected services and cause the services to re-initialize or otherwise apply the new configuration and commence operation in step 206.
Thereafter, when DHCP events are detected in step 207, in step 208 the managed device can send alerts and notification information to the IPPM service 222 via network 224 and also periodically send status information to the IPPM service 222 via network 224. In the example embodiment, the DHCP service can generate an event notification every time a DHCP lease is granted or renewed. The IPPM service 222 can also send configuration updates to the managed device when necessary via network 224, and if a configuration change is detected in step 209a, it may be applied in step 209b for updating the locally connected services, such as a DHCP server.
Discovery and status information received from a plurality of devices on the network can allow the IPPM to automatically generate a graphical user interface representation of the network on a computer screen, as illustrated in the example embodiment diagram of
Setting and Applying Policy
Also included is a method of developing a policy that effects the desired characteristics of the network, as provided by an administrator, in a way that can be applied to each of the network infrastructure devices as described below;
Each network policy can be expressed as a set of high level rules that can be compiled into configuration instructions for a plurality of services and deployed to each of the managed network devices respectively. Policies can be entered in the IPPM service in a number of ways, including from text based files and graphical user interfaces.
A Network area 603 can include information such as Policy Classes 610 that are selectable, for instance Default, Registered, Visitor, Printer, Appliances, New and others. The user can then set particular features 611 using radio buttons, drop down menus and other interactive buttons. These can include whether to hand out IP addresses to leases on the subnet as auto, registered or reserved radio buttons; lease times; maximum device connection time per 24 hours; maximum number of devices to connect; whether to perform client domain registration or not; quality of service and whether to allow outgoing Internet access or not.
A Domain Name System (DNS) area 604 can include radio buttons about whether to allow DNS lookups and a menu to select whether to restrict the DNS view for a safe network or other network.
A Wireless area 605 can include features 612 such as a drop down menu for wireless network authentication such as a shared key and input areas for shared key value and key value confirmation.
A Logging area 606 can include radio buttons to log device connections or not and a drop down menu about which DNS queries should be logged. Users can also select to enter an advanced settings button 607 or an update button 613.
A system default policy 408 can also be created including one or more rules in order to account for cases where the assigned policy 406 does not include a rule for a service role in capabilities 404.
By way of example, network policies and rules can include management of individual device behavior and can include: Default Policy Rules, Guest Policy Rules, Normal Policy Rules, Default Classes, and Policy Classes including one or more of Registered, Visitor, Printer, Appliance and Printer. Each of these will be described in turn as follows:
Default Policy Rules can include: a.) Up to 128 hosts may be connected to each managed network device, b.) Hosts shall not be connected wirelessly, c.) Hosts shall receive short term leases, d.) Unknown user hosts may not connect to any company-internal services or workstations, e.) Hosts shall have no Internet access, except to IPPM service, f.) Hosts shall have low level quality of service (QoS), and g.) Host connections (i.e. address leases) shall be logged to a central monitor.
Guest Policy Rules can include: a.) Up to 100 hosts may be connected, b.) Applies to all or specified host types, c.) Hosts shall receive short term leases only, d.) Hosts may not connect to any company-internal services or workstations, e.) Hosts may connect to the Internet at a low level QoS, f) Host connections (i.e. address leases) shall be logged to a central repository, and g.) Hosts shall receive a restricted DNS view when making DNS requests.
Normal Policy Rules can include the following: a.) Up to 1000 (wired) hosts may be connected, b.) Up to 100 (wireless) hosts may be connected, c.) Wireless hosts shall authenticate using name and password, and d.) Host connections (i.e. address leases) shall be logged to a central repository.
A Default class can include the following: a.) Hosts shall receive short term leases only, b.) Hosts may not connect to any services, c.) Hosts shall have no Internet access, except to IPPM service, and d.) Hosts may receive low level QoS.
A Registered Policy class can include the following: a.) No default devices and b.) Hosts may be wired or wireless, where these hosts may be subject to the following: 1.) Hosts shall be previously registered, 2.) Hosts may connect to the Internet, 3.) Hosts may connect to the VPN, 4.) Hosts shall make use of a safe DNS profile, 5.) Hosts may access company-internal services, 6.) Hosts may receive high QoS, 7.) Hosts may receive medium term leases, 8.) Hosts may be automatically registered with the DNS server, 9.) Network routes to company-internal services may be set up automatically, 10.) VPN connection to company-internal services may be set up automatically, and 11.) Network routes to printers may be set up automatically.
A Visitor Policy class can apply to tablets, smartphones, laptops, wearable devices, game consoles and other portable devices and includes: a.) Hosts shall receive short term leases only, b.) Hosts may not connect to any company-internal services or workstations, c.) Hosts may connect to the Internet, and d.) Hosts may receive low level QoS.
A Printer Policy class can apply to printers, scanners and information display devices and can include the following: a.) Printers shall receive long term leases, b.) Printers may not connect to the Internet, c.) Printers may receive mid-level QoS, and d.) Printers may be automatically registered with the DNS server.
Turning to
Servers Policy Rules can include a Default class and a Server Policy class that applies only to servers, pc and mac types. A Default class can include the following: a.) Hosts shall receive short term leases only, b.) Hosts may not connect to any services, c.) Hosts shall have no Internet access, except to IPPM service, and d.) Hosts may receive low level QoS. A Server Policy class can include the following: a.) Hosts shall receive reserved IP addresses, b.) Hosts shall have wired connections, c.) Hosts shall make use of a limited DNS profile, d.) Hosts may be automatically registered with the DNS server, and e.) Hosts may receive mid-level QoS.
The preceding list should be understood to be an example embodiment only and numerous other categories and classes of policies may be used, as appropriate. Some examples include policies for customers, students, contractors, affiliates, executives, and others.
IPPM process 409 can accept as input the device record 403, the default policy 408, real-time information from a database of registered client devices 402 and others and can apply the rules contained in the policy 406 and the default policy 408. The application of the rules can be translated into a set of configuration instructions 401 particular to managed device 421. Included in the set of configuration instructions 401 and can be configuration instructions for at least one service role including DHCP 410, such as class with client-IDs, address pools with lease times, ranges classes and static routes, reserved addresses and DNS Servers; QoS 411 including services by levels, addresses by levels, ranges by levels and defaults by levels; Wireless 412 including security methods; Firewall 413 including NAT ports; VPN 414; DNS 415; static routes 416; Proxy 417 and others 418. IPPM process 409 can also update the configuration of network services, for example DNS service 419 hosted on server 420, that can be remotely located from device deployment 421, in order to register new host addresses.
Inputs of the rule can be derived from: a.) device attributes and capabilities 502 for the managed device to which the rule 503 is applied, such as the state and attributes of the managed device including: client ID (e.g. mac address), vendor class, DHCP options fingerprint, and others; b.) rule parameters such as a number of hosts to be served, lease times, and others, as entered by the user as user input 504; c) a device configuration 501 generated by other rules in the policy, such as the IP address range of the DHCP pool. DHCP configuration can set up a number of address pools and client classes, to which various clients identified by host device type and ID are assigned. In turn these pool addresses can be used in different rules for setting QoS levels and firewall permissions, while d.) predetermined parameters can be assigned as conditions of rules, for example: some reserved hosts with fixed IP addresses can be set up in a rule, as these are not expected to change.
Elaborating on
Device Configuration
DHCP configuration can include one or more lease pools, lease reservations based on client identifiers, lease classes to which clients may be assigned and lease options. Relevant DHCP Options, which are defined by Dynamic Host Configuration protocol, R. Droms, March 1997, IETF and [RFC3442 (https://tools.ietf org/html/rfc3442)] include: Routers (option 3), DNS servers (option 6), Host Name (option 12), NTP servers (option 44), Vendor-specific (option 43), SMTP servers (option 69), Lease Time (option 51), Server Identifier (option 54), Vendor class identifier (option 60), Client identifier (option 61), and Classless Static Route (option 121) [RFC3442 (https://tools.ietf.org/html/rfc3442)].
Each DHCP server can exhibit different feature capabilities, resulting in differing configuration formats. For example, the ISC DHCP configuration for reserved host MAC addresses is described in DHCP server documentation, Internet Systems Consortium, 2001-2015, which is different from the configuration for DHCP reserved host MAC addresses in DnsMasq Man Page, Simon Kelley, September 2014 (accessible at http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html) and each could be applied on different target devices. Therefore, the IPPM policy rules can be applied in accordance with the known capabilities of each target device, so that target devices are not assigned configurations for capabilities they do not possess.
Wireless 802.11 (Wi-Fi) router configuration can be set up as a subnet of a wired network. In an example embodiment, a wireless router can host a DHCP server that can be configured independently from the parent network's DHCP server. In another example embodiment, a wireless router configuration can include settings for wireless access point and wireless security to allow the wireless network to be remotely managed. For example, security settings can include: a.) WPA2-PEAP using Radius to authenticate users individually, whereby a Radius service is separately located from the router, for example in the Internet ‘cloud’ and b.) WPA shared secret to authenticate users using the same secret that is part of the wireless router configuration.
Quality of Service (QoS) configuration can be based on a client IP address range that is set by a DHCP server. In an example embodiment, a minimum level of service can be determined on a per IP address, and therefore per client, basis. In another example embodiment, a QoS configuration can include other router settings to enable QoS to be varied according to: a.) Service port ranges, generally related to a network protocol in use, can be used to determine QoS (For example Voice-over-IP protocol can be assigned a high level of service (low latency) and file downloads can be assigned a low level of service (high latency)), b.) Protocol types, such as UDP or TCP, can be assigned different levels of service, and c.) Protocol L7 analysis, to determine network services in use, can be used to determine QoS. For example, services such as specific HTTP downloads can be assigned a special level of service.
VPN Tunnels can be configured as servers and clients, whereby security keys can be generated and installed, and network routes can be set up in accordance with policy rules.
User host DNS registration can be used as an input to the IPPM policies, whereby a client ID, such as a Media Access Control (MAC) address of a host computer, can be used to associate a device with a known user. Host registration can be manually configured from an administrator console. For example, turning to
Configuration Deployment
Configuration deployment starts when IPPM receives a message sent from a network infrastructure device, such as a status update, alert message or an event notification and the IPPM has an updated configuration waiting. The IPPM can then respond by sending a configuration update to the device. Depending on the capabilities of the device, the configuration update can be in the form of one or more configuration files or a set of commands needed to update the device configuration of each service role.
As used herein and in the appended claims, the singular forms “a”, “an”, and “the” include plural referents unless the context clearly dictates otherwise.
The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed. Additionally, all publications discussed herein are hereby incorporated by reference in their entirety.
It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.
In many instances, entities are described herein as being coupled to other entities. It should be understood that the terms “coupled” and “connected” (or any of their forms) are used interchangeably herein and, in both cases, are generic to the direct coupling of two entities (without any non-negligible (e.g., parasitic) intervening entities) and the indirect coupling of two entities (with one or more non-negligible intervening entities). Where entities are shown as being directly coupled together or described as coupled together without description of any intervening entity, it should be understood that those entities can be indirectly coupled together as well unless the context clearly dictates otherwise.
While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.
The present application is a continuation of U.S. patent application Ser. No. 18/093,296, filed Jan. 4, 2023, which is a continuation of U.S. patent application Ser. No. 17/469,503, filed Sep. 8, 2021, now abandoned, which is a continuation of U.S. patent application Ser. No. 17/035,677, filed Sep. 28, 2020, now abandoned, which is a continuation of U.S. patent application Ser. No. 16/659,487, filed Oct. 21, 2019, now abandoned, which is a continuation of U.S. patent application Ser. No. 15/094,807, filed Apr. 8, 2016, now abandoned, which claims priority pursuant to 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 62/145,996, filed Apr. 10, 2015, all of which are incorporated herein by reference in their entireties and for all purposes.
Number | Date | Country | |
---|---|---|---|
62145996 | Apr 2015 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 18093296 | Jan 2023 | US |
Child | 18378347 | US | |
Parent | 17469503 | Sep 2021 | US |
Child | 18093296 | US | |
Parent | 17035677 | Sep 2020 | US |
Child | 17469503 | US | |
Parent | 16659487 | Oct 2019 | US |
Child | 17035677 | US | |
Parent | 15094807 | Apr 2016 | US |
Child | 16659487 | US |