WO2001076137A2

WO2001076137A2 - Local bridge configuration and maintenance

Info

Publication number: WO2001076137A2
Application number: PCT/CA2001/000438
Authority: WO
Inventors: Tom Maher; Martin Gadbois; Martin Chabbert
Original assignee: Eicon Technology Corporation
Priority date: 2000-03-31
Filing date: 2001-03-30
Publication date: 2001-10-11
Also published as: AU2001244013A1; WO2001076137A3

Abstract

Local IP traffic destined for the bridge's configuration / maintenance IP address will not be sent to the gateway router, which is on the other side of the bridge. The innovation allows this traffic to be intercepted, handled, and responded to as if the datagram was delivered to the gateway and routed accordingly. Therefore routing by the gateway is faked making the device's configuration and maintenance tools accessible without being actually bridged/routed.

Description

LOCAL BRIDGE CONFIGURATION AND MAINTENANCE

FIELD OF THE INVENTION

The invention relates to the field of bridge devices on networks and more particularly, to remotely configuring these bridge devices.

BACKGROUND OF THE INVENTION

When installing new terminal equipment to be connected to a network, such as a local area network (LAN), it is necessary to assign an Internet protocol (IP) network address to the new equipment, and a variety of methods for doing so are used. The most basic form of address management is to manually assign an IP address to the new terminal by directly setting or programming the network address at the new terminal using knowledge (i.e. a list) of IP addresses already used on the network, so as to be able to select a new and available address. Each terminal typically has a Media Access Control address (MAC address), which is a hardware address that uniquely identifies each node of a network. The network manager or administrator is thus the "keeper" of the list of used addresses together with the MAC addresses of each device, and he or she is required to install any new terminal equipment on the network.

It is also common for equipment to have a factory set IP address, and for the network administrator to use the factory address if it is within the range of usable addresses on the network, and it is not already assigned to a different device. If the factory set address is not compatible with the range of addresses used on the LAN, it is necessary to change the IP address of the new equipment.

To change the static IP address of new equipment to be compatible with the LAN requires an input interface. It is known to use a communications interface on the terminal to which a console can be connected to provide the input interface, and it is also known to use Dual In-line Package (DIP) switches on the equipment for setting the static address. These options either require considerable effort and/or extra equipment.

Bridges typically do the following: they listen to all traffic on the network, check source and destination MAC addresses of each packet, learn from experience to build and maintain routing tables in the bridge's RAM for the nodes on the network based on the source addresses, forward packets to all computers on all segments if the address is not in the routing table, discard the packet if the destination segment is the same as the source segment and forward the packet to the right segment if the address is in the routing table. Bridges work at the data link layer, whereas routers work at the network layer. Bridges are protocol independent; routers are protocol dependent. Bridges are faster than routers because they do not have to read the protocol to glean routing information. The Address Resolution Protocol (ARP) is the process of mapping a

TCP/IP host's IP address to its hardware address on broadcast-based networks. ARP uses a local broadcast of the destination IP address to acquire the hardware address of the destination host or gateway. Once the hardware address is obtained, both the IP address and the hardware address are stored as one entry in the ARP cache. The ARP cache is always checked for an IP address/hardware address mapping before initiating an ARP request broadcast. An ARP request is initiated any time a host tries to communicate with another host. The source host's IP address and hardware address are included in the request. The ARP request is sent as a broadcast so that all local hosts can receive and process it. If a host does not find a match to its own IP address, it ignores the request. The destination host which determines that the IP address in the request matches its own, sends an ARP reply directly to the source host with its hardware address. It then updates the ARP cache.

If the destination IP address is for a host on a remote network, the ARP broadcast is for a router that can forward datagrams to the destination host's network. The source host checks the local routing table for a route to a destination host or network. If no mapping is found, the source host determines the IP address of the default gateway. The source host then checks the ARP cache for the IP address/ hardware address mapping of the specified gateway. An Ethernet LAN is a grouping of PCs that are directly connected together through an Ethernet link. These PCs all have different MAC addresses (assigned by manufacturing) and IP address (assigned by management, or the DHCP protocol). All PCs on a LAN must be on the same subnet (i.e. the first part of the address is the same, usually the three first bytes). If a PC wants to reach another PC on the same subnet, it will fill the packet with the real Source and Destination MAC addresses (it will have discovered this address with the ARP protocol), as well as Source and Destination IP addresses. If a PC wants to reach an IP address that is not on the same subnet, it will send the packet to the configured default Gateway. In this case, the IP part of the packet will be the same as if the machines were on the same subnet (i.e. source and destination IP addresses), but the Destination MAC address will be the one of the Gateway (or Router). Thus, the Router must be on the same subnet as the PCs on the LAN, because they need to be able to reach the router directly.

In the case of a bridging device, the router is on the other side of a WAN link (DSL for example). The bridge's goal is to link the Router to the LAN. For this to work, the Bridge device must be transparent (i.e. it must not modify the contents of the packets); it must only forward the packets on the WAN link. If this is achieved, the Router is virtually on the same LAN as the PCs. The PCs don't know that their Router is on the other side of a DSL link.

Since the Bridge is transparent in this situation, it is not reachable from the PCs, thus, it is not possible to configure it. Different methods of configuring terminal devices on a LAN have been proposed. The first solution is to provide configuration/maintenance functions via another channel (e.g. a serial interface) thereby removing the need to use TCP/IP. A configuration terminal would be directly connected to the device to configure using a serial interface and the appropriate changes would be made. The second solution is to manually assign the device an IP address with a matching network address (e.g. via the first solution) using, for example, dip switches. The third solution is to allow the service provider to dynamically assign a host address to the bridge, using for example DHCP. In that case, the ISP assign an IP address to the bridge which is valid on the subnet as it would for any PC on the subnet. The first and second methods make the product difficult to install because of a requirement for additional equipment and knowledge of the network on which the device is being installed. The third method suffers from a serious limitation: the device uses up an IP address, which the service provider may charge for. If the PCs were on the same subnet as the Bridge, adding an IP stack in the Bridge that receives all the packets, and answers when packets are destined to it would be the easiest solution. In this case, the Bridge becomes just another station on the LAN. However, the drawback to this solution is that the IP address of the PCs must be reconfigured manually every time a user wants to configure the Bridge.

SUMMARY OF THE INVENTION

Accordingly, an object of the present invention is to provide a configuration tool for devices on networks which does not require additional equipment.

Furthermore, it is an object of the present invention to provide a configuration tool for devices on networks which does not require repeated assignment of IP addresses. It is also another object of the present invention to provide a configuration tool for devices on networks which does not require specific knowledge of the addresses of the other devices on the network.

Another object of the present invention is to provide a tool wherein local IP traffic destined for the bridge's configuration / maintenance IP address will not be sent to the gateway router, which is the other side of the bridge. The innovation allows this traffic to be intercepted, handled, and responded to as if the datagram was delivered to the gateway and routed accordingly. Therefore routing by the gateway is faked making the device's configuration and maintenance tools accessible without being actually bridged or routed. Yet another object of the present invention is to allow a PC to reach the

Bridge's configuration (i.e. using Hyper Text Transport Protocol (HTTP), File Transport Protocol (FTP), Telnet, Syslog, etc), via the IP protocol, without modifying the transparency of the Bridge.

According to one aspect of the present invention, a method for remotely configuring a first linking device connecting a first network to at least a second linking device is provided. The method comprises the steps of: sending a configuration message from a terminal on the first network addressed to an address of the first linking device via the second linking device; detecting that the configuration message is addressed to the first linking device and intercepting the configuration message at the first linking device; processing the configuration message at the first linking device; and sending a response to the configuration message, from the first linking device to the terminal, using address information of the second linking device, whereby a response from a second linking device of the subnet is faked for a sender of the message and configuration of the first linking device having an address invalid on the first network is made possible.

The first linking device can be a bridge. The second linking device can be one of a router or a gateway. The configuration message can be an IP datagram. The address information can be at least one of a MAC address and an IP address. The address of the terminal and an address of the second linking device can further be stored.

The method can also comprise the steps of pushing the configuration message onto a stack of the first linking device; saving a terminal address and an address of the second linking device; responding to the terminal using the stack, the address of the second linking device and the terminal address.

In accordance with another aspect of the present invention, a method and an apparatus for remotely configuring a bridge is provided. The method comprises the steps of identifying IP datagrams, communicated on a subnet, destined to an address of the bridge, wherein the address of the bridge is not valid on the subnet; and responding to the IP datagrams using information contained in the IP datagrams; wherein a response from a external router of the subnet is faked for a sender of the datagram and wherein configuration of the bridge having an address invalid on the subnet is made possible. Another method is provided in which a source address and an external router address are stored from the IP datagram and wherein the source address and the external router address are used to respond to the IP datagram.

The source address can comprise at least one of a source IP address and a source MAC address and the external router address can comprise at least one of a router IP address and a router MAC address. The address of the bridge can be an IP address.

According to another aspect of the invention, a method for configuring devices on a network is provided. The method comprises the steps of 1) Inspecting all IP datagrams on the network before bridging them, 2) if the IP address matches the bridge's configuration/ maintenance IP address, then do not bridge the datagram and a) push the IP datagram onto the device's TCP/IP stack, b) save source IP address and Ethernet (MAC) address, c) save destination Ethernet (MAC) address, 3) Respond to the source of the datagram using the TCP/IP stack, the destination MAC address and the source MAC address, wherein routing by the gateway is faked making the device accessible without being actually bridged/routed.

A method is also provided in which the source IP address and MAC address are saved by updating the Address Resolution Protocol (ARP) cache. According to another aspect of the present invention, there is provided an apparatus for remotely configuring a first linking device connecting a first network to at least a second linking device. The apparatus comprises a configuration message receiver for receiving a configuration message sent from a terminal on the first network and addressed to an address of the first linking device and transmitted via the second linking device; a configuration message catcher for detecting that the configuration message is addressed to the first linking device and intercepting the configuration message at the first linking device; a configuration manager for processing the configuration message at the first linking device; and a response sender for sending a response to the configuration message, from the first linking device to the terminal, using address information of the second linking device, whereby the response sender fakes a response from a second linking device of the subnet for a sender of the message and configuration of the first linking device having an address invalid on the first network is made possible. For the purpose of the present invention, the following terms are defined below.

The term "datagram" is intended to mean the unit of data, or packet, transmitted in a TCP/IP network. Each datagram contains source and destination addresses and data. The terms "Internet address", "Ethernet address", "Hardware address" and "MAC address" are used as synonyms in the present disclosure and are intended to mean a unique number assigned to each Ethernet network adapter or device. It is a 48-bit number maintained by the IEEE (Institute of Electronics and Electrical Engineers). Hardware vendors obtain blocks of numbers that they can build into their cards.

The term "bridge" is intended to mean a device that connects two LAN segments together, which may be of similar or dissimilar types, such as Ethernet and Token Ring, possibly over a WAN interface.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects and advantages of the present invention will become better understood with regard to the following description and accompanying drawings wherein:

FIG. 1 is a block diagram of the architecture of a system using an embodiment of the present invention;

FIG. 2 is a flow chart of the steps involved in a method according to a preferred embodiment of the present invention; FIG. 3 illustrates the information which is received from the LAN, saved by the bridge and sent back to the LAN; and

FIG. 4 is a screen shot of the configuration main menu accessible through a web browser connected to the bridge configuration manager.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1 , there is shown a block diagram of the elements of a system in which the invention could be used. A Local Area Network (LAN) 24 connects at least two devices, for example, at least one computer (shown here are two computers: computer 26 and computer 28) and a bridge 22. The devices on the LAN can be clients (such as personal computers, terminals, etc.), servers, etc. The bridge 22 connects the LAN to a router 20 through a Digital Subscriber Line (DSL) or Wide Area Network (WAN) line. In turn, the router 20, which preferably comprises a DHCP server, is connected to the Internet 29. Computer 26 has a specific MAC address assigned by the manufacturer and has been assigned an IP address on the LAN. The IP address is, for example, 172.30.68.2. Computer 28 also has a personalized MAC address and has been assigned an IP address of 172.30.68.5. It is located on the same subnet as the computer 26 and therefore has a similar IP address (the first, second and third portions of the IP address are typically the same). Bridge 22 however, has been assigned an IP address during manufacturing. This IP address does not necessarily correspond to an IP address valid on the LAN. In this case, the IP address assigned to the bridge was 192.168.1.1. This IP address is not valid on the example subnet. The router has also been assigned an IP address valid on the subnet. The address is, for example, 172.30.68.1.

A typical bridge device 22 comprises the following items: a Bridge IP Module 16 used to manage IP communications in the bridge, a Bridge's Transparent Forwarding Module 18 used to forward packets, a table of known MAC addresses 19 used to compare the destination MAC addresses to a table identifying to which port the packet is destined (if known) and a Bridge's IP address 21. Configuration Managers 15 can be added but would be accessed using a serial connection.

The bridge 22 according to a preferred embodiment of the present invention comprises Configuration Managers 15 and a Local IP Detection Module 17 which are used to, respectively, configure the bridge and detect configuration instructions on the LAN in order to configure and maintain the bridge remotely.

In order to configure the bridge remotely and to communicate with it even when it is not configured correctly, the bridge is manufactured to respond to specific datagrams addressing it.^' Referring now to FIG. 2, the steps involved in a preferred embodiment of the present invention are illustrated. All IP datagrams on the LAN side are inspected by the bridge 30, even when the bridge is not configured. An example of a datagram 64 is shown in FIG. 3. The datagram 64 sent from a computer on the LAN which wishes to communicate with another device is first handled by the ARP. The ARP will fetch the MAC addresses of the router and the source computer's new datagram will typically comprise a header 48, a source IP address 49 indicating from which device the datagram is being sent, a source MAC address 50, a destination IP address 51 indicating the device to which the message is being sent the router, a MAC address 54 and the content of the message 55.

Referring back to FIG. 2, if the destination IP address 51 matches 32 the bridge's configuration/maintenance IP address, then the datagram is not bridged. The Local IP Detection Module 17 recognizes that the message containing its IP address as the destination IP address is in fact a configuration message for its Configuration Managers 15 even if the message is being sent to » the router 20. The IP datagram is pushed up into the device's TCP/IP stack 34. The source IP address and MAC addresses are saved for later use 36. The router MAC address is also saved for later use 38. In order to answer to the device on the LAN, the Local IP Detection Module prepares a datagram which borrows information from the datagram received. The Source IP address 58 is, taken from the Bridge's IP address 21 , the Source MAC address 59 is taken from the router MAC address 54 of the datagram received, the Destination IP address 60 is taken from the source IP address 49 of the datagram received and the Destination MAC address 61 is taken from the source MAC address 50 of the datagram received. Responses from the TCP/IP stack are sent on the local LAN side of the bridge 40.

The result of this process according to a preferred embodiment of the present invention is that local IP traffic destined for the bridge's configuration/maintenance IP address will not be sent to the gateway router, which is on the other side of the bridge. The innovation allows this traffic to be intercepted, handled, and responded to as if the datagram was delivered to the gateway and routed accordingly. Therefore routing by the gateway is faked, making the device accessible without the packet being actually bridged/routed.

If the destination IP address does not match the bridge's IP address 32, the bridge (if already configured) will forward the packet to all of its ports except the port from which the message came from only if the destination MAC address is not in its table of known MAC addresses. The gateway will then send a response back to the bridge which will direct it to the right device on the LAN 44. If the address is in the table of known MAC addresses, the packet will be forwarded on the appropriate port of the bridge, and therefore, to the appropriate subnet.

If the bridge is not configured yet, the datagram not corresponding to the bridge's configuration / maintenance IP address will be ignored. When not configured, the bridge does not forward any packet. It is in a sleep mode from which it will be awaken when configured.

Referring back to FIG. 1 , it is assumed, for the purpose of the example, that the destination IP address is the address of the bridge's configuration/maintenance. The bridge 22 and its Local IP Detection Module 17, according to a preferred embodiment of the present invention, responds to the device on the LAN using the stored information. This process is very efficient since the device is able to communicate directly with the bridge.

The source IP address and MAC address of the datagrams can also be saved by updating the ARP cache of the bridge or by any other type of storage in the memory of the bridge.

Table 1 is a excerpt from a telnet session with a configuration manager of a bridge. The telnet session illustrates possible remote configuration instructions that can be performed on the configuration manager of the bridge.

Table 1. Telnet Session with a Configuration Manager

Welcome to Armstrong 1.9.9:000 This version is internal to Eicon Technology development group. Copyright Eicon Technology 1999

-->SHOW BRIDGE PORTS port status physical addr

B-ether-ATM- (8,35) DOWN (null> WinEth-1 UP 00:00:32:78:98:12

-->SHOW BRIDGE TABLE

Station Physical addr Port Type

000 00:00:32:78:98:12 -> WinEth- -1 learned

001 OO:a0:24:Oc:8b:ba -> WinEth--1 learned

002 OO:b0:d8:80:00:ac -> WinEth--1 learned

-->SHOW BRIDGE STATISTICS

Total Learned Entry Discards : 0

Port Name IN OUT Discards B-ether-ATM- (8,35) 0 0 0 WinEth-1 19 0 79

-->SHOW BRIDGE CONFIGURATION

Bridge aging time: 300 (sec)

-->SHOW PROFILES

Profile Type State

B-ether-ATM- (8,35) UNKNOWN DISABLED WinEth-1 UNKNOWN UP

-->PROFILE B-ether-ATM- (8,35)

B-ether-ATM- (8,35) >SET SET <key ord(s)> Keywords valid in this context:

ADSL ATM BRIDGE DATE DHCP ILMI IP LOG PASSWORD PROFILE TIME

TIMEPROTOCOL

B-ether-ATM- (8,35) >SET ATM

SET ATM <keyword(s)>

Keywords valid in this context:

CDUT MBS MODE PCR SCR SERVICE UCI UPI

B-ether-ATM- (8,35) >SET ATM UPI 8

B-ether-ATM- (8,35) >SET ATM UCI 35

B-ether-ATM- (8,35) >1

Table 2 is a list of potentially available instructions in a telnet session with the configuration manager of the bridge. It will be understood that this list comprises functions which are not necessary to configure a bridge and which are used to monitor the design and management of its modules. The list could also be completed by adding other functions depending on the options of the bridge.

Table 2. List of Available Instructions

ADD DHCP STATICMAP adds a new entry to the STATICMAP table.

DELETE DHCP STATICMAP delete an entry from the STATICMAP table

DELETE IP ROUTE deletes an IP route

DISABLE ADSL INTERNAL BER TESTER disables ADSL internal BER tester DISABLE ADSL TRELLIS CODING disables trellis coding

DISABLE BRIDGE disables bridge DISABLE DHCP STATICMAP disable support for static address assignment DISABLE IP FORWARDING disables IP forwarding option DISABLE LOG MODULE disables logging for a module DISABLE LOG OUTPUT disables logging to a destination DISABLE TFTP SERVER disable internal tftp server DISABLE TIMEPROTOCOL disable time protocol ENABLE ADSL INTERNAL BER TESTER enables ADSL internal BER tester ENABLE ADSL TRELLIS CODING enables trellis coding

ENABLE BRIDGE enables bridge

ENABLE DHCP STATICMAP enable support for static address assignment

ENABLE IP FORWARDING enables IP forwarding option

ENABLE LOG MODULE enables logging for a module

ENABLE LOG OUTPUT enables logging to a destination

ENABLE TFTP SERVER enable internal TFTP server

ENABLE TIMEPROTOCOL enable time protocol

EXIT closes current session

GET TFTP FILE download a file using TFTP

SET ADSL FAST MAX BITRATE DOWN sets/shows ADSL debug config element

SET ADSL FAST MAX BITRATE UP sets/shows ADSL debug config element

SET ADSL FAST MIN BITRATE DOWN sets/shows ADSL debug config element SET ADSL FAST MIN BITRATE UP sets/shows ADSL debug config element

SET ADSL FAST PLANNED BITRATE DOWN sets/shows ADSL debug config element SET ADSL FAST PLANNED BITRATE UP sets/shows ADSL debug config element

SET ADSL INTERLEAVED MAX BITRATE DOWN sets/shows ADSL debug config element SET ADSL INTERLEAVED MAX BITRATE UP sets/shows ADSL debug config element SET ADSL INTERLEAVED MIN BITRATE DOWN sets/shows ADSL debug config element SET ADSL INTERLEAVED MIN BITRATE UP sets/shows ADSL debug config element

SET ADSL INTERLEAVED PLANNED BITRATE DOWN sets/shows ADSL debug config element SET ADSL INTERLEAVED PLANNED BITRATE UP sets/shows ADSL debug config element SET ADSL MAX ADDITIONAL NOISE MARGIN DOWN sets/shows ADSL debug config element SET ADSL MAX ADDITIONAL NOISE MARGIN UP sets/shows ADSL debug config element SET ADSL MAX AGGR PWR LEVEL DOWN sets/shows ADSL debug config element SET ADSL MAX AGGR PWR LEVEL UP sets/shows ADSL debug config element SET ADSL MAX PDS DOWN sets/shows ADSL debug config element

SET ADSL MIN NOISE MARGIN DOWN sets/shows ADSL debug config element SET ADSL MIN NOISE MARGIN UP sets/shows ADSL debug config element

SET ADSL MODULATION TYPE sets/shows ADSL modulation type

SET ADSL RADOWNSHIT INTERVAL DOWN sets/shows ADSL debug config element SET ADSL RADOWNSHIT INTERVAL UP sets/shows ADSL debug config element SET ADSL RADOWNSHIT MARGIN DOWN sets/shows ADSL debug config element SET ADSL RADOWNSHIT MARGIN UP sets/shows ADSL debug config element SET ADSL RAMODE DOWN sets/shows ADSL RA Mode downstream

SET ADSL RAMODE UP sets/shows ADSL RA Mode upstream

SET ADSL RARATIO DOWN sets/shows ADSL debug config element

SET ADSL RARATIO UP sets/shows ADSL debug config element

SET ADSL RAUPSHIT INTERVAL DOWN sets/shows ADSL debug config element SET ADSL RAUPSHIT INTERVAL UP sets/shows ADSL debug config element

SET ADSL RAUPSHIT MARGIN DOWN sets/shows ADSL debug config element SET ADSL RAUPSHIT MARGIN UP sets/shows ADSL debug config element

SET ADSL TARGET NOISE MARGIN DOWN sets/shows ADSL debug config element SET ADSL TARGET NOISE MARGIN UP sets/shows ADSL debug config element SET ADSL TRANSCEIVER TYPE sets/shows ADSL transceiver type SET ATM MODE sets ATM mode, UNI version, ILMI version SET BRIDGE AGINGTIME sets bridge aging time SET DATE sets the internal system date SET DHCP DNS defines DNS addresses for DHCP serer use SET DHCP DOMAIN defines domain name for DHCP server use SET DHCP IPRANGE defines the pool of addresses for DHCP serer SET DHCP LEASEDURATION set the duration of DHCP leases SET DHCP SERVERADDR specifies main DHCP serer address SET DHCP STATICMAP modifies an existing entry in the STATICMAP table SET DHCP TYPE selects type of DHCP services provided SET BRIDGE AGINGTIME sets bridge aging time SET DATE sets the internal system date SET DHCP DNS defines DNS addresses for DHCP serer use _, SET DHCP DOMAIN defines domain name for DHCP server use SET DHCP IPRANGE defines the pool of addresses for DHCP server SET DHCP LEASEDURATION set the duration of DHCP leases SET DHCP SERUERADDR specifies main DHCP server address SET DHCP STATICMAP modifies an existing entry in the STATICMAP table SET DHCP TYPE selects type of DHCP services provided SET DHCP WINS defines WINS addresses for DHCP server use SET ILMI DEVICE TYPE sets ILMI device type SET ILMI UNI TYPE sets ILMI UNI type _: SET ILMI UNI VERSION sets ILMI UNI version

SET ILMI VERSION sets ILMI version

SET LOG FILTER sets the level of logging

SET PASSWORD sets the password

SET TIME sets the internal system clock

SET TIMEPROTOCOL SERVER set address of a time server

SET TIMEPROTOCOL ZONE set time zone difference

SHOW ADSL CONFIGURATION shows ADSL line configuration

SHOW ADSL STATISTICS shows current statistics for ADSL line

SHOW BRIDGE CONFIGURATION shows bridge configuration

SHOW BRIDGE PORTS shows ports the bridge is binded to

SHOW BRIDGE STATISTICS shows bridge statistics

SHOW BRIDGE STATUS shows bridge status

SHOW BRIDGE TABLE show bridge table

SHOW DATE displays the current system date and time

SHOW DHCP CONFIGURATION displays the DHCP server configuration

SHOW DHCP STATICMAP display the list of defined static DHCP addresses

SHOW DHCP STATUS displays DHCP server status

SHOW ILMI CONFIG shows ILMI config

SHOW IP ADDRESS displays current IP address(es)

SHOW IP ROUTE displays routing table contents

SHOW IP STATISTICS Displays statistics for the IP protocol.

SHOW LOG show recorded log messages

SHOW LOG PLUS show recorded log and trace for specified module(s)

SHOW PROFILES displays the settings for all profiles.

SHOW TCP STATISTICS displays TCP statistics

SHOW TIME displays the system date and time

SHOW TIMEPROTOCOL CONFIGURATION display time protocol settings

SHOW TRACE show recorded traces for specified module(s)

SHOW UDP STATISTICS displays UDP statistics.

START TRACE start tracing a module

STOP TRACE stop tracing a module

In order to communicate with the configuration manager of the bridge, a web browser interface 48 is preferably used. FIG. 4 illustrates a screen shot of an example of a Configuration Main Menu 50 of such a web browser interface. It comprises an Overview 52 and an Administration 54 section. The Overview section 52 allows quick verification of the status 56 of the bridge (in this example, the status is "ready"). Also, the current firmware version 58 is displayed.

In the Administration section 54, links to the different aspects of the managers are listed, the aspects being accessible by clicking on the title of the aspect. In this example, the aspects are : the ATM connections 60, the System 62, the Security 64, the ADSL Connections 66, the Maintenance 68 and the Support Information 70. A "Reset" button 72 and a "Log Out" button 74 are also provided. The ATM Configuration Menu 60, preferably allows to define the following parameters : the VCC number, the VPI, the VCI, whether the bridge is enabled and the encapsulation.

The System Parameters Menu 62 allows to define the LAN IP address, the time and date and whether spanning trees are enabled.

The Security Parameters Menu 64 allows to define the System name, the login password, whether inbound access is disabled and whether only IP traffic is allowed.

The ADSL parameters Menu 66 preferably allows to define the mode and the data path type.

The Firmware Maintenance Menu preferably allows to download the most updated version of the firmware, to save an image of the currently installed firmware to a file on the administrator's computer and to load in a firmware image onto the configuration managers. Finally, the Configuration Maintenance Menu allows to save an image of the current configuration to a file on the administrator's computer, to restore a saved configuration and to reset the configuration to a factory default.

As will be readily apparent from this disclosure, embodiments of this invention could be used to configure routers and gateways which act as links between networks. However, it is most advantageous for bridging devices because of their transparency.

While the invention has been described in connection with specific embodiments thereof, it will be understood that it is capable of further modifications and this application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains and as may be applied to the essential features hereinbefore set forth, and as follows in the scope of the appended claims.

Claims

1. A method for remotely configuring a first linking device connecting a first network to at least a second linking device, the method comprising the steps of: sending a configuration message from a terminal on the first network addressed to an address of the first linking device via the second linking device; detecting that the configuration message is addressed to the first linking device and intercepting the configuration message at the first linking device; processing said configuration message at the first linking device; and sending a response to said configuration message, from the first linking device to said terminal, using address information of the second linking device, whereby a response from a second linking device of said subnet is faked for a sender of said message and configuration of the first linking device having an address invalid on the first network is made possible.

2. A method as claimed in claim 1 , wherein said first linking device is a bridge.

3. A method as claimed in any one of claims 1 to 2, wherein said second linking device is one of a router or a gateway.

4. A method as claimed in any one of claims 1 to 3, wherein said configuration message is an IP datagram.

5. A method as claimed in claim 4, wherein said address information is at least one of a MAC address and an IP address.

6. A method as claimed in any one of claims 1 to 5, wherein said step of detecting comprises: storing an address of said terminal and an address of said second linking device.

7. A method as claimed in claim 6, wherein said steps of storing, processing and sending comprise: pushing said configuration message onto a stack of said first linking device; saving a terminal address and an address of said second linking device; responding to the terminal using the stack, the address of said second linking device and the terminal address.

8. A method as claimed in any one of claims 1 to 7, wherein said addresses are saved by updating the Address Resolution Protocol (ARP) cache.

9. An apparatus for remotely configuring a first linking device connecting a first network to at least a second linking device, the apparatus comprising: a configuration message receiver for receiving a configuration message sent from a terminal on the first network and addressed to an address of the first linking device and transmitted via the second linking device; a configuration message catcher for detecting that the configuration message is addressed to the first linking device and intercepting the configuration message at the first linking device; a configuration manager for processing said configuration message at the first linking device; and a response sender for sending a response to said configuration message, from the first linking device to said terminal, using address information of the second linking device, whereby said response sender fakes a response from a second linking device of said subnet for a sender of said message and configuration of the first linking device having an address invalid on the first network is made possible.

10. An apparatus as claimed in claim 9, wherein said first linking device is a bridge.

11. An apparatus as claimed in any one of claims 9 to 10, wherein said second linking device is one of a router or a gateway.

12. An apparatus as claimed in any one of claims 9 to 11 , wherein said configuration message is an IP datagram.

13. An apparatus as claimed in claim 12, wherein said address information is at least one of a MAC address and an IP address.

14. An apparatus as claimed in any one of claims 9 to 13, wherein said configuration message catcher stores an address of said terminal and an address of said second linking device.

15. An apparatus as claimed in claim 14, wherein said configuration message catcher pushes said configuration message onto a stack of said first linking device and saves a terminal address and an address of said second linking device and wherein said response sender responds to the terminal using the stack, the address of said second linking device and the terminal address.

16. An apparatus as claimed in any one of claims 14 to 15, wherein said addresses are saved by updating the Address Resolution Protocol (ARP) cache.