GB2408891A - Network device - Google Patents

Network device Download PDF

Info

Publication number
GB2408891A
GB2408891A GB0328252A GB0328252A GB2408891A GB 2408891 A GB2408891 A GB 2408891A GB 0328252 A GB0328252 A GB 0328252A GB 0328252 A GB0328252 A GB 0328252A GB 2408891 A GB2408891 A GB 2408891A
Authority
GB
United Kingdom
Prior art keywords
network
network device
service
accept
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0328252A
Other versions
GB0328252D0 (en
Inventor
Stephen Casey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to GB0328252A priority Critical patent/GB2408891A/en
Publication of GB0328252D0 publication Critical patent/GB0328252D0/en
Publication of GB2408891A publication Critical patent/GB2408891A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5061—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the interaction between service providers and their network customers, e.g. customer relationship management
    • H04L41/507—Filtering out customers affected by service problems

Abstract

A network device is disclosed that includes a network communications port, and processing means. The processor is arranged to accept requests for one or more services via the network connector and respond that the respective service is currently unavailable. For use by network administrators during either scheduled or emergency maintenance to provide network users with a service unavailability announcement. The system is independent of the normal operating components of the network device that is currently down. Advantages of device are that it is available at all times and can act as a simple slot in replacement in the event of failed services.

Description

240889 1 Network Device
Field of the Invention
The present invention relates to a device, or a system for an existing device, that is particularly suitable for use in data networks.
Backeround to the invention In data networks, particularly computer networks, there two types of network maintenance that occur: scheduled and emergency. The former refers to situations where the removal of services is planned and the latter where a device or service failure has forced it.
During scheduled maintenance, it is often the case that the main system or device that normally provides the service continues to provide some form of notice of downtime of the service. In some cases, where a system or device is undergoing offline maintenance, network administrators may have a standby device which they would configure to sit in its place for the period.
Emergency maintenance usually means that the device or system has unexpectedly failed and as a result, it is very common for no service continuity to exist at all. In some well organised cases and for some services a standby or disaster recovery system or device may be used in the period when the main system or device is offline. However, the existence of disaster-recovery systems are the exception rather than the rule in many businesses.
In many businesses it is common practice to simply not provide a replacement service. In those businesses that have thought ahead, an automated message or webpage may be used to notify customers of downtime.
In the case of scheduled maintenance, it is often the case that network administrators will not attempt to re-configure the computer or system to provide a continuity message. This can be due to the fact that the computer or system is to be taken off line, or due to sloppy practices. It is also possible that computers that are expected to provide these messages have found other permanent roles in the network.
In the case of emergency maintenance, the same issues can arise, namely that any backup hardware has found other roles or that the configuration of one would be considered too time consuming. Also, the cost of having computers available to fulfil this role often will be prohibitive due to space and financial commitments.
Finally, in cases where there is an automated service reporting downtime, it is often the case that customers are either not aware of it or may not have the details to hand.
In the case of the Internet, it is often the case that the system being worked on is that used by the users to access the Internet. As many Internet Service Providers use a Website for providing service downtime messages, users are often referred to the website in a catch-22 situation; they need internet connectivity to access the website that will inform them that the internet connectivity system is currently omine. For those users without an alternate means of accessing the Internet, this can be extremely frustrating.
Statement of Invention
According to an aspect of the present invention, there is provided a network device comprising a network communications port, and processing means, the processor being arranged to accept requests for one or more configurable services via the network connector and respond that the respective service is currently unavailable.
Preferably, the network device further comprises a memory operative to accept a network identifier, the processor being further arranged to accept requests directed to the network identifier.
According to another aspect of the present invention, there is provided a network device including a service unavailability announcement system, the service unavailability announcement system being independent of the normal operating components of the network device and comprising processing means arranged to be activated in accordance with one or more predetermined conditions and arranged when activated to accept requests for one or more predetermined services via a network communications port of the network device and respond that the respective service is currently unavailable.
The network device may comprise a router, switch or network interface device.
The primary advantage would be that this device would be available at all times, and would act as a simple slot in replacement in the event of failed services.
As an alternative to using a complete PC to perform the same task, it has a number of lO advantages. Primarily it would be always available, with no risk of being assigned to other uses (as it shouldn't have any). In addition to this, it would be considerably more secure than placing a complete computer with many services, and possibly many bugs or security vulnerabilities in place of an existing machine.
Another major advantage would be that it's small form factor would allow it to be used in many cases where it would be inconvenient to place other hardware. For the short maintenance periods that it would be expected to be used it could simply sit in the back of the rack, or on a desk.
Detailed Description
In a preferred embodiment of the present invention, there is provided a stand-alone network device. The device has the sole purpose of being able to quickly, easily and preferably in a plug and play manner, replace a network service device that may fail or have to undergo maintenance. Preferably the device has a small form factor, such as in the form of a USB key, a PDA or similar. Most preferably, the device is immediately ready for use and is self-powered via batteries or a rechargeable energy source.
The device includes processor means such as a CPU and associated hardware such as RAM etc and a network communications port.
In a preferred embodiment, the device includes a persistent memory, such as flash memory of some sort (Secure-Digital, Compact-Flash etc) that may be removable or built into the device. Preferably the device includes a high capacity, small factor battery (such as Li-lon batteries used on mobile phones and many portable electronic devices). The device may also include a connector for an optional power supply for longer term use.
The device may also be provided with an associated charging station to charge the battery.
The device may also include an associated transformer power supply for either the charging station or direct connection to the device.
Configuration of the device is preferably via a suitably programmed computer that can be connected to the device. The connection to the device may be via the network communications device or via a USB connector or similar (if provided).
Using configuration software on the computer, an operator configures the device to enable it to act as a stand in for a specific device or system. In a preferred embodiment, the following items can be available to be set up: Network identifier (such as IP address/es) of the device. this defines the virtual location on the network that the existing machine that would be replaced would occupy. Only communications addressed to this network identifier are responded to.
List of pre-defined services that the device should occupy with user defined downtime messages.
files to support downtime messages of specific services such as an HTTP website page.
a user-defined response on any service port to incoming connections. This is in order to emulate unforeseen or custom services and provide relevant messages from them.
Access to the device could be managed through secure password exchange. Alternatively, it would be possible to connect directly to the device with a USB or serial connection and configure.
The software is preferably able store a number of configurations locally so that they could be quickly sent to any device to completely configure it. This option would allow users to maintain configurations for use in replacing multiple systems, devices or servers on one desktop. s
The actual device preferably runs an embedded operating system. Where the device is intended to be used on a TCP/IP network, the device's operating system would include a TCP stack to allow it to respond to any incoming TCP connections. Once this device is powered up it will load its configuration from a pre-stored file generated using the Configuration Software and begin operation on the IP address/es specified. Alternatively, an IP address could be specified during configuration as the source for a configuration file. In this case, once the device is powered up, it would seek the configuration file from the specified IP address.
In the above example on a TCP/IP network, once a connection via the network communications port is detected on a recognised service port (for example HTTP, SMTP or FTP), the device responds with a valid server response. In each case it would use this to indicate that there was an ongoing problem and give out the user defined message.
Preferably, the device provides a "dumb" response to any queries or connections. In some cases that would require it to respond at a certain time in the connection's procedure, and in many cases it would do that in response to an expected phrase. For example, an SMTP session may proceed as follows: Client Connection: HELO client.connection Service Device: 200 ERROR - Service not available at present due to maintenance. This is due to complete at 20:00 GMT.
As a result of the above brief interchange, the machine attempting to send mail using the missing server would get the message that the service was not available and, depending on the set up of the service, would usually would pass the message on to the user.
Essentially, any TCP service would be suited to this device as they all operate on some basic challenge response, and just about any of them have a way for the server to present an error message.
FTP is similar in that it can simply return a number followed by some text that indicates that the service is not available. Obviously this would make it directly to the user and they would terminate. An example connection to a new session would respond as follows: 421 <domain> Service not available, <user message stored on device> to any connections. In this case it is supposed to issue this line before it receives any text.
The RFC suggests that the text should be passed onto the user, however, it's also possible that it would trigger the sending machine to try on another mail server that's allowed for that address.
Even services such as SMB which is the file transfer protocol used within Microsoft Windows (RTM) products and "Microsoft Networking" could return an error.
In general, a list of all known services is stored in the configuration system. The device would know how to handle these based on rules set in the configuration file. If an unknown service were to be substituted with the device, the network administrator could have the ability to list the port number and whatever response it required. In fact, it could be capable of a series of "dumb" responses as per the following fictional example: Data Transfer Service (DTS) Connection Established Client: HELO Server: 100 HELO Client: LIST Server: 400 Service Unavailable <user message stored on device> To configure the device, the administrator would specify that the device should respond HELO to "HELD" and the "400 error" to any subsequent requests.
All of these conversations could equally take place in HEX, and the configuration software preferably has to have an appropriate editor or converter to enable advanced configuration of that nature.
One key element is that the device would never attempt to provide the original service (eg, by blindly forwarding email), but instead simply notify that the service wasn't there at all. This is for reasons of increased security and to reduce the processing power that might be required.
The following described two circumstances in which the device would be used and a typical procedure that would be followed with its use. Initially there is a common set of actions that would be followed to prepare for any occasion when the device may be required. Then, depending on whether it is scheduled maintenance that requires removal of the original service, device or server from operation or emergency maintenance, two sets of follow-on circumstances would apply.
Preparation Once a new device, system or server is put into operation it would be part of the procedure to prepare a device (or a configuration file for a device) to go with it as a slot-in replacement in maintenance situations. In order to do this, a network administrator connects the device to their PC and configures the services it would be expected to cover and what IF addresses it should answer on. In addition to those steps, it may be necessary to provide a general simple text message that outlines the fact that the service, device or server was temporarily unavailable. If applicable, each service could also have a specific message attached so that that would be returned instead of the generic one.
In the case of the HTTP/web service, it would be necessary to include the entire text of a webpage, and also to upload any supporting images to the device.
For all messages, a number of standard fields would be available to keep information up to date. This could include, amongst others a note of the time that the device was put into operation, the current time and date and further configurable text strings to be used such as the company name, or department name.
Once those steps were taken, the device or configuration file would be labelled as being a suitable replacement for the specific device, computer or system. It could then be put on its charging base ready to use should the need arise.
Scheduled Maintenance In the case of scheduled maintenance, at some point before the notified unavailability of the server, the device would once again be connected to the network administrator's PC and all of the configuration would be checked and updated for the specific circumstances.
For example, instead of a generic message stating that the server was unavailable it may be appropriate to state that the server would be down for 1 hour from 6pm to 7pm.
Once all the configuration was checked and confirmed, and at the time of the scheduled downtime, the existing system, device or computer would be removed from the network, and in its place, the device would be attached. This would immediately begin to serve the pre-configured message. If the scheduled downtime was expected to be longer than the typical battery life, it may be appropriate also to attach the device to an permenant power supply.
Emergency Maintenance In the case of emergency maintenance brought on by the failure of an existing device, server or service, the device could be immediately plugged into the network in the place of the original server or device. The generic downtime messages would generally be suitable for the unknown situation that was at hand.
Continued Operation Once the device is in place, it would continue to answer all validly addressed connections with the configuration message. If the situation changed, it is preferably that the administrator is able to connect to the device and make changes to the service messages while it was still running. Once a new message was put in place, the device would immediately begin serving it.
If maintenance goes on for an extended period and the device's memory begins to run low, it would preferably notify a predetermined network address associated with the network administrator who could attach it to a suitable electricity supply for indefinite use.
Return to Service Once the maintenance period is completed, return to normal service would be as simple as unplugging the device and replacing it on the network with the original repaired, or replacement, computer, system or device and normal operation could continue.
The operational use of the device could be significantly changed if instead of built in configuration memory, that configuration were to be stored on removable media. In this case, instead of requiring a device for each computer, system or service on a network, it would be possible to simply have a removable media, and enough devices to cover a worst case scenario.
For further levels of security, it would be possible to include a USB or serial connection on the device, and only allow configuration to take place through that connection.
Although the embodiments of the present invention have been described in terms of a stand-alone device, it will be apparent that similar functionality could be included in a subsystem for an existing network device such as a router, switch or network interface.
Such a subsystem could be activated upon demand, such as by issuing a predetermined command to the network device or by detection of a predetermined event (such as lack of reply from a predetermined service). In this manner, no action may be needed to replace an existing computer, system or service and the switch could happen instantly or substantially instantly.

Claims (12)

  1. Claims 1. A network device comprising a network communications port,
    processing means, the processor being arranged to accept requests for one or more services via the network connector and respond that the respective service is currently unavailable.
  2. 2. A network device according to claim l, further comprising a memory arranged to accept a network identifier, the processor being further arranged to accept requests directed to the network identifier.
  3. 3. A network device according to claim 2, wherein the memory comprises persistent memory.
  4. 4. A network device according to claim 2 or 3, wherein the network identifier comprises a network address.
  5. 5. A network device according to claim 2, 3 or 4, wherein the memory is further arranged to accept a message to be used as the response.
  6. 6. A network device according to claim 5, wherein the message comprises a web page.
  7. 7. A network device according to any preceding claim, further comprising a local interface for programming the network device.
  8. 8. A network device according to claim 7, wherein the local interface comprises a
    MOM
    selected on of: a USB interface, a serial interface or a firewireinterface.
  9. 9. A network device according to any preceding claim, wherein the processor is arranged to obtain a configuration file from a predetermined network address upon connection to a network or from local storage.
  10. 10. A service unavailability announcement system for a network device, the network device including a network communications port, the service unavailability announcement system being independent of the normal operating components of the network device and comprising processing means arranged to be activated in accordance with one or more predetermined conditions and arranged when activated to accept requests for one or more services via a network communications port of the network device and respond that the respective service(s) is/are currently unavailable.
  11. 11. A network device incorporating the service unavailability announcement system of claim 10.
  12. 12. A network device according to claim 11, comprising a selected one of a router, switch or network interface device.
GB0328252A 2003-12-05 2003-12-05 Network device Withdrawn GB2408891A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0328252A GB2408891A (en) 2003-12-05 2003-12-05 Network device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0328252A GB2408891A (en) 2003-12-05 2003-12-05 Network device

Publications (2)

Publication Number Publication Date
GB0328252D0 GB0328252D0 (en) 2004-01-07
GB2408891A true GB2408891A (en) 2005-06-08

Family

ID=29764662

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0328252A Withdrawn GB2408891A (en) 2003-12-05 2003-12-05 Network device

Country Status (1)

Country Link
GB (1) GB2408891A (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592611A (en) * 1995-03-14 1997-01-07 Network Integrity, Inc. Stand-in computer server
US6178441B1 (en) * 1998-09-21 2001-01-23 International Business Machines Corporation Method and system in a computer network for the reliable and consistent ordering of client requests
EP1231756A2 (en) * 2001-02-06 2002-08-14 Hewlett-Packard Company, A Delaware Corporation Method and system for maintaining connections in a network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592611A (en) * 1995-03-14 1997-01-07 Network Integrity, Inc. Stand-in computer server
US6178441B1 (en) * 1998-09-21 2001-01-23 International Business Machines Corporation Method and system in a computer network for the reliable and consistent ordering of client requests
EP1231756A2 (en) * 2001-02-06 2002-08-14 Hewlett-Packard Company, A Delaware Corporation Method and system for maintaining connections in a network

Also Published As

Publication number Publication date
GB0328252D0 (en) 2004-01-07

Similar Documents

Publication Publication Date Title
US7921315B2 (en) Managing power consumption in a data center based on monitoring circuit breakers
KR101143250B1 (en) System and method for disaster recovery and management of an email system
US20190037009A1 (en) System and method for providing data and application continuity in a computer system
US7992014B2 (en) Administering power supplies in a data center
US8307068B2 (en) Supervised access computer network router
US20090287949A1 (en) Managing Power Domains In A Data Center
WO2008065695A1 (en) Server management program, mail server management program, server management system, and server management method
WO2001050708A2 (en) A server module and a distributed server-based internet access scheme and method of operating the same
US9325685B2 (en) Authentication switch and network system
US20070180101A1 (en) System and method for storing data-network activity information
US7689586B2 (en) Remote status and control of storage devices
US20090287943A1 (en) Mapping power domains in a data center
US20020188568A1 (en) Systems and methods of containing and accessing generic policy
CN110691398B (en) Network interaction method, system, equipment and storage medium of intelligent equipment
DK2040497T3 (en) Tracking of mobile communication devices
CN110225109A (en) A kind of data transmission method of more queues
US8341254B2 (en) Middleware-driven server discovery
TW554277B (en) Automated network management system
JP5524878B2 (en) Quarantine network system
JPWO2009087885A1 (en) Server system and event message transmission method thereof, client terminal and connection method and program thereof, recording medium
GB2408891A (en) Network device
CN112242944A (en) File processing method and related device
Cisco Appendix: SNMP Notification
Cisco uOne 5.0E Corporate Edition Release Notes
Cisco Appendix F - SNMP Notification

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)