WO2004004217A1

WO2004004217A1 - Virtual private network validator

Info

Publication number: WO2004004217A1
Application number: PCT/GB2003/002766
Authority: WO
Inventors: Roland Gerald Courtney; Timothy Glyde Higham
Original assignee: Viewgate Networks Limited
Priority date: 2002-06-28
Filing date: 2003-06-27
Publication date: 2004-01-08
Also published as: AU2003253094A1; GB0215025D0

Abstract

A method of and system for validating the connectivity of a VPN existing within a telecommunications network. The network may be an Internet protocol virtual private network (IP-VPN) which is built using public domain standards multi protocol label switching (MPLS) and border gateway protocol (BGP): A workstation connects to the telecommunications network and determines information on PE and CE routers of a selected VPN. A clustering algorithm is used to analyse the configurations of the routers of the selected VPN to determine the topology of the VPN. The functionality of the routers is tested and the results of the functionality testing analysed by applying an algorithm or comparison against service provider templates. The workstation then displays information representing the actual status of the VPN(s) and the required or intended status of the VPN(s).

Description

Virtual Private Network Validator

The present invention relates to virtual private networks (VPNs) and, more particularly, to a method and system for validating or testing the connectivity of a VPN.

The world of telecommunications began to change when major telephone service companies started to offer data services to allow major corporations to connect computer centres to branch offices. Although, initially, the use of telecommunications for data was limited and small compared to voice telephony services, the emergence of the personal computer created rapid growth in data services' revenues. The telephony companies started to become data service providers.

In the early stages, service providers offered simple hard-wired physical connections between their users' locations. Effectively, each of these connections was a private telephone line (or leased line) linking a pair of sites. This technology then started to give way to shared infrastructure X.25 and frame relay services. These services were able to supplement the traditional leased line technology by exploiting the economies of scale that a service provider could realise. Using a common 'backbone network' comprising many switching nodes interconnected by high bandwidth connections, a user's traffic could be interleaved in a cost-effective manner with that of other users, in contrast to the previous approach of reserving an expensive physical connection from end to end and using it sporadically.

Today, most of the revenue from business data services still comes from the use of frame relay. However, recently, the internet has revolutionised the way in which the public communicate with friends and businesses. The Internet is an extremely powerful communications medium for everyday use, providing cheap ubiquitous connection to a massive community of users. However, so far the Internet has not been used significantly for business-critical applications, because of basic limitations in the technology. Internet Protocol, or IP, is notably lacking in features that provide assured privacy and dependable performance. Although IP operates very well in a local area network, which is under the control of the corporate IS department, and where bandwidth is plentiful, it is only recently that technology has emerged to allow IP to be used effectively for business- critical applications in a Wide Area Network (WAN) - where the service provider revenues are to be found.

Now that IP-based services are becoming a reality, the service providers are keen to accelerate the migration of users from the older frame relay services, and consolidate traffic onto their IP networks, in order to take advantage of the rapid strides in cost/performance that can be realised.

Because IP is inherently a flexible, any-to-any connectivity protocol, it needs to be supplemented by additional layers of functional logic in order to segment and treat traffic separately on a per-user and per-community basis.

These functional layers are implemented as software modules on the network devices (routers) themselves and require comprehensive configuration in order to achieve the necessary separation of sites and traffic into valid communities. This process of configuration, also called service provisioning, is a separate subject which is not addressed by this patent application. A VPN is typically of the scale of 10 or 100 interconnected sites. However, a common service provider infrastructure may be used to support hundreds, thousands, or even tens of thousands of VPNs. That common infrastructure is huge and complex, comprising many interconnected network nodes. A VPN only exists, as such, thanks to a logical set of configuration parameters spread amongst the various network devices within the service provider's infrastructure. Finding and making sense of those parameters is like looking for needles in haystacks. To date, it is has been impossible to derive solely from the network infrastructure an understanding of the VPNs that have been logically configured.

The process of creation of a VPN involves a complex combination of provisioning steps. Some of these are executed in advance and some are only triggered when a specific VPN requirement is identified. A further complication is that the various provisioning steps sometimes occur in series and sometimes in parallel, depending on the resources required and the lead times involved. The end result is that the state of completion of the entire VPN is difficult to establish.

In order to overcome this difficulty, implementation support tools and processes can be used to ensure that all stages of the provisioning are planned, assigned, actioned and documented. This approach will reduce the scope for error. However, 'doing everything by the book' may still lead to a faulty or non-functional outcome. For example, a number may be mis-typed by the provisioning engineer, a command issued to the wrong interface or the equipment configured may be faulty.

As is illustrated in Figures 1 to 3 of the accompanying drawings, visualisation of the topology of a VPN is, in itself, no easy task. Figure 1 shows a simplified network infrastructure 1 which is supporting a number of VPNs. One particular VPN 2 has been highlighted for consideration. This is the VPN interconnecting the sites 3 shown in bold. Figure 2 shows one possible logical interpretation of how these sites 3 interact. This is called a 'full mesh' - so called because all sites 3 have the ability to communicate directly with all other sites. Figure 3 shows a different logical interpretation. This time called a 'hub and spoke' configuration - so called because one of the sites 3 is at the centre of the organisation (the hub or headquarters site for example) while the others are outstations or branch offices that only require access to the central site, and not to each other.

Other more complex variants exist for the logical VPN topology, such as shared services and extranets, which lead to overlapping communities.

Additional complications occur due to constantly changing customer VPN requirements, making it increasingly difficult for the service provider to keep an up-to-date inventory of what exactly 'should' be provisioned, in terms of both hardware components and connectivity configuration, for any single VPN.

There is a need, therefore, to provide a method and means for independently interrogating and analysing pre-configured network devices of a VPN and for easily visualising the physical and logical interrelationships between sites of the VPN.

Accordingly, from one aspect, the present invention consists in a method of validating the connectivity of a VPN existing within a telecommunications network, comprising the steps of:

(a) connecting a processing means to at least one device on the VPN ; (b) discovering or determining information on the network device(s) , the information comprising configurational and relationship information;

(c) storing the information discovered in step (b);

(d) visualising the network from the stored information;

(e) analysing the discovered information to assess and discover exceptions in the configurations of the network device(s) of the

VPN(s);

(f) testing the functionality of the network device(s) of the VPN(s);

(g) analysing the results of the testing in step (f) to assess and discover exceptions in the functionality of the network device(s) of the VPN(s);

(h) displaying information representing the actual status of the VPN(s) and information representing the exceptions identified in method steps (e) and (g);

The exceptions may comprise deficiencies or suspected deficiencies.

Method step (a) may include seeding the system with minimal information in order to perform step (b). The relationship information obtained by method step (b) may comprise information representing relationships to VPNs, physical relationships and logical relationships. Method step (b) may include executing an algorithm stored in the processing means so as to discover the information.

Method step (e) may comprise the step of comparing manually the visualisation of the network with externally-supplied data representing a VPN requirement specification.

Method step (e) may comprise applying configuration rule sets which are encoded representations of tests which can be carried out on the information discovered in method step (b) . These tests may be based on knowledge of best practice principles embodied within the invention itself, or on the comparison between discovered information and Service Provider best- practice standards held within configuration templates. These templates can be supplied by the Service Provider.

Method step (f) may comprise testing of the connectivity of the VPN(s), i.e. the ability of sites to intercommunicate. The method step (f) may comprise testing of the physical connectivity, logical connectivity and non- connectivity. This may be performed through analysis of (physical) line status, interface statistics and parameters, etc.

Additionally, method step (f) may include interrogating the logical status of the network device(s) of the VPN(s). Preferably, such interrogation is effected by selecting one or more network devices of the VPN(s) , sending interrogation signals to the selected network device(s), receiving reply signals sent from the selected network device(s) in response to the selected network device(s) receiving the interrogation signals, measuring the time delay between sending the interrogation signals and receiving the reply signals from the selected network device(s) of the VPN and storing the measured time delay as data. Additionally, the method of interrogating the logical status of the network device(s) of the VPN(s) may include, selecting data representing an acceptable time delay of an interrogation signal sent between the selected network device(s), and comparing the measured time delay data with the selected acceptable time delay data so as to determine problems with the functionality of the selected network device(s) and network links therebetween. Information indicating or representing differences between the measured time delay and the acceptable time delay may be displayed so as allow the functionality of the selected network device(s) and networks therebetween to be determined.

Method step (g) may comprise applying functional rule sets which are encoded representations of tests which can be carried out on the information discovered in method step (f). These tests may be based on knowledge of best practice principles embodied within the invention itself, or on the comparison between discovered information and Service Provider best- practice standards held within configuration templates. These templates can be supplied by the Service Provider.

Method step (h) may include, highlighting differences, if any, in connectivity between what is actually on the network and what should have been configured as determined by an externally-supplied VPN requirement specification.

Method step (h) may include the steps of displaying nodes respectively representing network devices, displaying lines connected between the nodes, the lines representing physical or logical relationships between the network devices, colouring or highlighting such a line to indicate exception information obtained from method steps (e) and/or (g) associated with said relationships, and colouring or highlighting a node to indicate exception information obtained from method step (e) and/or (g) associated with the network device represented by said node. Additionally, method step (h) may include displaying the identity information for each selected network device of said VPN.

Preferably, the method step (h) includes superimposing on said displayed nodes and access links data representing the time delay measured between the selected network device(s). It may also include superimposing said identity information on corresponding displayed nodes and access links. Furthermore, method step (h) may include toggling the display of said coloured or highlighted access links and nodes and the display of said identity information. Additionally, method step (h) may include displaying exceptions in the data representing the actual status of the VPN(s) if said exceptions fall within a selected range of severity level.

One or more of the aforementioned method steps can be scheduled or based on either a manual or system trigger.

The processing means may be used to perform one or all of the aforementioned method steps. In a preferred embodiment, the processing means is a server with attached workstation.

According to another aspect, the present invention consists in a system for validating the connectivity of a VPN existing within a telecommunications network, comprising processing means connectable to the telecommunications network, connecting means for connecting said processing means to the selected VPN, discovering means for discovering or determining information on the network device(s), the information comprising configurational and relationship information, storing means for storing the discovered information, visualising means for visualising the VPN(s) from the stored information, analysing means for analysing the discovered information to assess the configurations of the network device(s) of the VPN(s), functionality testing means for testing the functionality of the network device(s) of the VPN(s), a analysing means for analysing the results of the functionality testing to assess the functionality of the network device(s) of the VPN(s), and displaying means for displaying information representing the actual status of the VPN(s) and the required or intended status of the VPN(s).

The connecting means may include seeding means for seeding the system with minimal information to enable the discovery means to discover or determine the information. The relationship information discovered by the discovery means may include information representing relationships to VPNs, physical relationships and logical relationships.

The discovery means may comprise an algorithm stored in the processing means which is executable to discover the information.

The analysing means for analysing the discovered information may comprise comparing means for comparing the visualisation of the network with data representing a customer order specification.

The analysing means for analysing the discovered information may comprise supplying means for supplying parameters to enable templates to be configured with values. Such parameters may be supplied by a Service Provider to the processing means. The analysing means for analysing the discovered information may comprise a further algorithm stored in the processing means which is executable so as to check information on the network device(s). This algorithm embodies configuration rules which are encoded representations of tests which can be applied to the information discovered in order to check that best practice has been observed. Alternatively or additionally, the analysing means may include verifying means for checking the information on the network device(s) against the customer's best-practice templates. The analysing means may include printing means for printing out the results of analysing the discovered information and comparing means for comparing with the inventory database holding a customer order specification.

The testing means for testing the functionality of the VPN(s) may be arranged to test the connectivity of the VPN(s), such as, the physical connectivity, logical connectivity and non-connectivity. The testing means may include means for analysing the (physical) line status, interface statistics and parameters, details of which are collected, for example, by issuing pings.

The analysing means for analysing the results of the functionality testing may comprise a further algorithm which is stored and executable in the processing means so as to assess the results. This algorithm embodies functional rules which are encoded representations of tests which can be applied in order to check that the VPN is capable of carrying traffic within acceptable bounds of operational performance. Alternatively or additionally, the analysing means may include verifying means for checking the results against the customer's best-practice templates. The analysing means may include printing means for printing out the results of the functionality testing and comparing means for comparing the print out with the inventory database holding a VPN requirement specification.

The displaying means may include highlighting means for highlighting the differences, if any, in connectivity between what is actually on the network and what should have been configured as per the VPN requirement specification.

The present invention enables network devices to be interrogated in order to derive and present a logical visualisation of the topology and performance characteristics of the VPN and compare, for consistency, this visualisation against the original VPN requirements specification.

Preferably, the functionality testing means comprises interrogating means for interrogating the logical status of network device(s) of the VPN(s). The interrogating means may comprise selecting means for selecting one or more network device(s) of the VPN(s) from information representing the identities of the network devices, sending means for sending interrogation signals to the selected network device (s), measuring means for measuring the time delay between sending the interrogation signals and receiving the interrogation signals from the selected network device(s) of the VPN, storing means for storing the measured time delay as data and displaying means for displaying the data representing the measured time delay.

Additionally, the functional testing means may include logical data selecting means for selecting data representing an acceptable time delay of an interrogation signal sent to the selected network device or between the selected network devices, comparing means for comparing time delay data with the selected specified time delay data so as to determine problems with the functionality of the selected network devices and network therebetween, and display means for displaying information representing the differences between the measured time delay and the specified time delay so as allow the functionality of the selected network devices and networks therebetween to be determined.

The display means may comprise means for displaying nodes respectively representing network devices, means for displaying lines connected between the nodes, the lines representing logical or physical relationships between the network devices. The display means may include means for colouring or highlighting such a line to indicate a difference between the discovered information associated with said relationship and reference data and means for colouring or highlighting a node to indicate a difference between the discovered information and/or results of the functionality tests associated with the network device represented by said node and the reference data. The display means may include means for superimposing on said display nodes and access links representing one or more selected network devices data representing said time delay measured between the selected network devices. The display means may include means for displaying identity information for each selected network device and means for superimposing said identity information on corresponding displayed nodes and access links. The display means may include means for toggling the display of said coloured or highlighted access links and nodes and the display of said identify information. Additionally the display means may include means for displaying differences in the data representing the actual status of the VPN(s) and the reference data if said differences fall within a selected range.

The present invention is particularly adapted for validating or testing the connectivity of a selected VPN existing in a telecommunications network. In this event, the method step (a) includes storing the IP addresses of all PE routers on the telecommunications network associated with a plurality of VPNs and includes selecting the VPN from the VPN information representing the plurality of VPNs.

The present invention may include selecting means for selecting one of a plurality of VPNs from information representing the plurality of VPNs. The reference data may include information representing the required connectivity of the network devices of a plurality of VPNs.

According to another aspect, the present invention consists in a system for and method of discovering the connectivity of a VPN or selected VPN existing in a telecommunications network, in which a processing means is connected to at least one device of the VPN, information on the network device(s) including configurational and relationship information is discovered from said network device(s), the discovered information is stored and the network is visualised from the stored information. Said information may be discovered by a clustering algorithm.

The system and method for discovering the connectivity of a VPN or selected VPN existing in a telecommunications network may include an analysing means in which the discovered information is analysed to assess the configurations of the network device(s) of the VPN(s)

According to another aspect, the present invention consists in a system and method for validating the functionality of a VPN existing in a telecommunication network in which a processing means is connected to at least one device of the VPN, the functionality of the or each device is tested by a testing means, the results of the testing are analysed by an analysing means to assess the functionality of the network device(s) of the VPN, and information representing the actual status of the VPN(s) and information representing the required or intended status of the VPN(s) is displayed.

According to another aspect, the present invention consists in a system for and method of displaying information representing the connectivity of a VPN or selected VPN existing within a telecommunications network, in which information representing the discovered and required connectivity is displayed so as to enable the consistency of the VPN to be visualised.

The telecommunication network may be a public telecommunications network, such as the Internet or a private telecommunications network. The processing means may comprise a workstation, such as a computer terminal. The workstation may be remotely connectable to the public telecommunication network by a remote access server. Furthermore, the network devices may comprise routers/servers.

In a preferred embodiment hereinafter disclosed, the network is an Internet protocol virtual private network (IP-VPN) which is built using public domain standards multi protocol label switching (MPLS) and border gateway protocol (BGP). The network routers/servers comprise customer edge (CE) routers and provider edge (PE) routers, the former routers existing on network user sites and supporting communications from users at those sites. The storing means may include means for storing a clustering algorithm in the computer terminal or an associated memory medium and the system may include executing means for executing the clustering algorithm from the computer terminal, said algorithm being used to analyse the configurations of the PE and CE routers of said selected VPN to determine the topology of said selected VPN. An embodiment of the present invention will now be described by way of example with reference to the accompanying drawings in which

Figure 1 is a schematic showing a simplified network structure which is supporting a plurality of VPNs,

Figure 2 is a schematic showing the sites of Figure 1 interacting in a full mesh configuration according to one possible logical interpretation,

Figure 3 is a schematic showing the sites of Figure 1 interacting in a hub and spoke configuration according to another possible logical interpretation,

Figure 4 is a schematic block diagram illustrating stages of the method for selectively validating the connectivity and functionality of one of a plurality of VPNs using a work station according to one embodiment,

Figure 5 is a schematic block diagram illustrating the flow of information between the network and software and hardware elements of the system according to one embodiment,

Figure 6 is a schematic of the physical representation of the VPN shown in Figure 1 and 3,

Figure 7 is a schematic of the logical representation of the VPN shown in Figure 1 and 3,

Figure 8 is a schematic of an unfiltered logical representation of a VPN,

Figure 9 is a schematic of a filtered logical representation of the VPN represented in Figure 10, Figure 1 0 is a diagram of a display icon used for selecting the replay of the representations of the VPN over time,

Figures 1 1 is a flow diagram illustrating the process of fixing a problem within a network in which the invention is used to discover the problem and verify that it has been fixed, and Figure 1 2 is a flow diagram illustrating a process of adding a new site to a VPN in which the invention is used to verify that the site has been added correctly,

Figure 13 is a flow diagram illustrating algorithm 5 of a clustering algorithm used in the method for validating the connectivity of one of a plurality of VPNs according to one embodiment,

Figure 14 is a flow diagram illustrating algorithm 6 of the clustering algorithm, and

Figure 1 5 is a flow diagram illustrating the steps of the method according to a preferred embodiment.

According to the preferred embodiment, the public telecommunications network is an Internet protocol virtual private network (IP-VPN) which is built using public domain standards multi protocol label switching (MPLS) and border gateway protocol (BGP).

The network devices comprise customer edge (CE) routers and provider edge (PE) routers, the CE routers existing on network user sites and supporting communications from users at those sites. The CE routers are remotely connectable via access links to ports of the PE routers. They exist on network user sites and support communications from users at those respective sites only. A PE router exists at the edge of the service providers network at a location that serves a community of existing and potential network user sites and, typically, is a powerful high capacity device capable of supporting many interfaces and therefore many CE routers.

As illustrated in Figure 1 , formed within such a network are a number of virtual private networks (VPNs) which define groups of sites which are connectable with one another and which particular users are authorized to use. Associated with each VPN site is a corresponding target identifier (TID) which is a representation of logical connectivity advertised by the VPN site. Sites may export or import TIDs as will be further explained in the appended schedule 1 .

In the preferred embodiment, the system comprises a processing means in the form of a workstation, such as a computer terminal, remote from the network. The workstation includes a means to communicate with the IP Validator server, which in turn includes the means to connect to the network in order to interrogate the PE and CE devices.

Figure 4 of the accompanying drawings illustrates the flow of information between the network and various software and hardware elements of the system according to one embodiment. IP Validator software running on the computer terminal provides the system with four engines, Scheduler engine 10, Command Line Interface Data Collector (CLI DC) engine 1 1 , Parser engine 12 and the graphical user interface (GUI) engine 13 together with a datastore 14.

The Scheduler engine 10 is the task-master for the system. It directs the functionality of other processing engines and acts as a broker for engines that are reliant on other engine output. Scheduler enginel O is manipulated by a combination of configuration files and tasks. Tasks are generated using a high-level task language.

The CLI DC engine 1 1 generates telnet sessions with the CE and PE routers, issues CLI commands to the routers. Command results are pushed to the Parser engine 12 for analysis and processing. The CLI DC engine 1 1 receives action instructions from the Scheduler engine 10. The Scheduler command instruction sets (tasks) are a set of files that can be modified or updated without programming modifications within the CLI DC. Task modifications are incorporated by sending a re-read signal to the Scheduler engine.

The Parser engine 1 2 performs data analysis and data normalisation of the data obtained by the CLI DC engine 1 1 . Parser engine results are forwarded to the datastore 1 4. The parser engine 1 2 executes parsing scripts. New scripts can be added or existing scripts can be modified without modifications to the Parsing engine.

The GUI engine 1 3 is the front end for the user application. The GUI engine 1 3 manages the user authorisation, the resident web server, and user requests. The GUI engine 1 3 is based upon XML based object-oriented templates. Objects are obtained from the datastore 1 4. New types of information, router hardware, router configuration components, etc., are treated in the same manner as existing XML objects. The GUI engine 1 3 represents the VPN and its current state. It allows the use of the computer terminal to understand what is configured and whether the component and VPN are working.

The datastore 14 is a repository of XML data files. This data is presented to the GUI engine 13 in object format. The datastore is a XML file system/database containing results of parsing and analysis operations. New types of results data are stored as XML content.

The engines and datastore enable the terminal to collect information from a PE router and, where required, a CE router. Router configuration information is collected via a command line interface (CLI) on a scheduled basis. These configurations are processed to understand how the VPNs are set up. The analysis results data are stored as VPN topologies. The configurations are checked to ensure that there are no anomalies or configuration errors.

Functional checks are also carried out on a scheduled basis, as defined by the Service provider. Using the VPN topologies, IP Validator checks metric states such as interface status, site-to-site connectivity, and statistical sampling of latency, jitter, maximum bandwidth capabilities and data loss.

A history of VPN configuration, errors and functional validation may be stored to allow active playback. This allows a service provider to understand how a VPN's delivery is processing as well as an understanding of changes and failures in the delivery of a live service.

The MPLS network (currently assumed in the example to be implemented using Cisco routers) is the basic service delivery mechanism, consisting of CEs and PEs. The system is limited to analysis of user facing service configurations. The system "backend" includes a set of processes to collect configuration data from PE and CE routers, discover VPNs, and provide configuration and functional validation of the VPNs. The GUI engine 13 is the front end and allows users to interact dynamically with the system to determine the status of VPN configurations, and to diagnose configuration or other problems.

The functionality of each of the system software components has been designed to allow modification of existing functionality and the incorporation of new functionality without significant development effort. The concept is to provide a set of processing engines that are controlled via configuration files, scripts, and/or instruction sets. Modifying or enhancing functionality is obtained via the control mechanisms. In summary, the system engines and subsystems have been designed to provide quick and simple adaptation of new router hardware types, new CLI commands (or even new data collection processes e.g. csv files, SNMP, etc), metric discovery, and analysis procedures and calculations. This is made possible in part through the limited use of hard-coded instruction sets and the extensive use of file or scripted instruction sets. The use of Java and XML also contribute to the product's flexibility.

Referring to Figure 5, the method of the preferred embodiment comprises four distinct stages, discovery, validation, visualisation/representation and user interface.

Prior to implementing the discovery process, a computer server hosting the IP_Validator computer program is installed on the Service Provider network. In addition a desktop software package (web browser) is loaded on to each workstation that will be used to discover information on the network devices. Using the workstation, the user selects, from a homepage summary of all the VPNs, the VPN on which the discovery process is to be performed. The workstation connects to the VPN and the discovery process is initiated. A clustering algorithm is executed in the workstation which is used to discover information about the topology of the VPN, in particular, relationship information and configuration information on each network device on the selected VPN. The relationship information may include information representing relationships to VPNs, physical relationships and logical relationships. The workstation is seeded with minimal yet sufficient information in order to perform the discovery process. An explanation of the major steps performed by the clustering algorithm are set forth in the appended schedule. The discovery process can be scheduled or based on either a manual or system trigger.

The information concerning the topology of the VPN which has been discovered by the clustering algorithm is stored in a data store, in this case, held on the IP_Validator server.

As will be explained below, the actual VPN is visualised from the discovered information stored in the datastore.

Once the topology of the selected VPN has been discovered, the discovered information can be validated by the system. The computer program analyzes the discovered information stored in the data store to validate the configurations of the network device(s) of the VPN(s).

This validation uses Configuration Rule Sets which are encoded representations of tests to be applied to the discovered information. These tests are based on knowledge of best practice principles embodied within the invention itself.

Parameters supplied by the Service Provider, which would typically come from customer best-practice templates (Configuration Templates), can be used to provide additional Configuration Rule Sets. Information on the network devices is also automatically checked against these rules to ensure that network configurations fall within the desired parameter ranges.

The discovered information may also be printed out and compared with the inventory database holding a customer order specification. Once the topology data representing the physical and logical topology of the selected VPN has been discovered and presented at the workstation, the functionality of the selected VPN is tested and analysed. The functionality testing may comprise testing of the physical connectivity, logical connectivity and non-connectivity of the selected VPN. This may be performed through analysis of (physical) line status, interface statistics and parameters, details of which are collected, for example, by issuing pings. This testing can be scheduled or based on either a manual or system trigger.

For example, the logical status of each router may be interrogated as follows. In response to the user selecting, at the workstation, one or more devices/routers of the selected VPN to be interrogated, the system transmits interrogation signals from the IP Validator server to the selected device(s)/router(s). Reply signals are then sent from the selected device(s)/router(s) to the IP_Validator server in response to detecting the interrogation signals. The IP Validator server is configured to measure the time delay between sending the interrogation signals to a selected device/router or between selected devices/routers and receiving the reply signals therefrom at the server. Data representing the measured time delay will automatically be measured against a pre-set threshold, representing the acceptable time delay. In the latter case, data representing the acceptable time delay of an interrogation signal sent to a selected server/router or sent between selected servers/routers is selected from the server memory by the server and compared with the data representing the actual time delay measured by the server so as to determine any problems with the functionality of the selected devices/routers and network therebetween.

The results of the functionality testing are analysed by the computer program to assess the functionality of the network device(s) of the VPN. This is achieved by means of an algorithm which analyses the actual results (for example time delays) measured as per the foregoing paragraph, deduces the likely causes of threshold trangressions, and associates those causes with individual nodes and/or logical or physical interconnections between nodes by declaring these as exception conditions.

Alternatively or additionally, the results are checked against the service provider's functional templates. These functional templates are encoded representations of expected patterns of functionality for this particular service provider. This checking is achieved by means of an algorithm which analyses the patterns of actual results (for example time delays) measured as per the above paragraph, identifies differences between these and the expected patterns encoded in the template, and associates these differences with individual nodes and/or logical or physical interconnections between nodes by declaring these as exception conditions. The results of the functionality testing may be printed out and compared with the inventory database holding a customer order specification.

When the computer program is run on the server, the server analyses the discovered information and results of the functionality testing and displays the physical and logical topology of the VPN at the workstation. As will be explained below, the topology is represented on the workstation display in a format that allows the user easily to visualize the functional completeness and performance of the selected VPN.

The display can be used to highlight the exception conditions discovered in the preceding configuration and functional testing, by superimposing colour and annotations on the objects within the topological display of the VPN at the workstation. Figure 6 illustrates the general format used for representing VPN topology. This consists of two concentric circles 20,21 , with nodes 22,23 plotted on both inner 21 and outer circles 20. A node 22 located on the outer circle 20 represents a CE router. A node 23 located on the inner circle 21 represents a PE router. Superimposed on the diagram is labelling information showing user and site names.

Physical status information can be superimposed on the concentric circles diagram. This can be colour coded or highlighted to indicate a source of failure or substandard performance within the VPN. A node 22,23 can be coloured or highlighted to denote a problem with the PE or CE router, and the access link 24 can be coloured or highlighted to indicate a problem of connectivity. These visual indications can be supplemented by drill-down capabilities allowing the user to double-click an object to obtain fuller information about the cause of the problem.

Logical status information can also be superimposed. Logical measurements are made between one CE and another, showing, for example, the ability for one site to reach another. Again, colour coding or highlighting can be used to show the presence of an exception condition such as an excessive delay traversing the network from one CE to another.

By toggling the computer display between physical view and logical view, the user can see on the same representation two fundamentally different classes of problem, as well as check the completeness of the VPN service. The two examples shown in Figure 6 and 7 show the physical and logical views of the same VPN used as an example in Figures 1 - 3 above. Note that the logical view shows that this VPN has been configured as a hub-and- spoke configuration.

A fault condition can be indicated on the logical and physical views by a colour (e.g. red) or highlight. In the examples in Figures 6 & 7, a fault condition is indicated by the highlighted colour (shown in bold) of CE3. In Figure 6, a physical problem (such as the router being powered off) is indicated in a highlighted colour (shown in bold) which also shows as a link failure to PE3. The logical view in Figure 7, indicates that CE5, the hub router, is attempting to validate a logical connection to CE3, and is unable to.

A key feature of the visual representation is the existence of a slider control or filter that suppresses the display of conditions below a chosen severity level. Figures 8 - 10 show how this can be used to discriminate down to a few key problems out of a mass of non-exceptional measurements.

Figure 8 shows connectivity measurements across a fully-meshed VPN. Figure 9 shows the effect of setting the severity filter to suppress conditions other than critical. It is thus easy to see that there are just two connectivity problems within this VPN.

Optionally, the visual representation may include a control that allows the replay of historical data to achieve an animated representation (see Figure 10) . By moving the slider control back (to the left), the user can select for display earlier measurements for the VPN in question. By clicking the Play button, the user can observe a sequence of measurements played back in a simulated time axis. This feature allows the user to trace the performance of the VPN over time, and subsequently review it to associate problem conditions with time of day.

Figure 1 5 summarises the method for validating the connectivity of a VPN according to the preferred embodiment. The IP_Validator, using minimal information about network e.g. IP addresses of PE routers, communicates with the network and discovers or determines the topologies of all IP VPNs on that particular network, as indicated by steps (a)/(b) on Figure 1 5. These topologies are then stored in a Datastore, in both physical and logical formats, as topology maps, as indicated by step (c). These topology maps can also be used to create a visualisation of the VPNs via the graphical user interface (GUI) (see step(d)). IP_Validator then performs checks on how each VPN is configured against: (i) a generic set of rules sets which have already been configured into the validator software - Configuration Rule Set, (ii) a set of rule sets specific to the individual service provider, provided by the service provider and configured into IP Validator - Configuration Templates, and (iii) manually against the VPN requirement specification (see step (e)) . Anything that is discovered to be unusual or incorrect is noted as an exception. Functual checks are then carried out on the VPN, e.g. measuring a delay between site A and site B etc, as indicated by step (f). The results of the functional checks (f) are then measured against: (iv) a generic set of rules sets which have already been configured into the product - Functional Rule Sets, and (v) a set of rule sets specific to the individual service provider, provided by the service provider and configures into IP_Validator - Functional Templates. Anything that is discovered to be unusual or incorrect is noted as an exception (see step(g)). The 'exceptions' are then virtually overlaid on the visualisation of the VPN topologies, using different colours on the display, to indicate what is 'wrong' or what is a 'warning' etc (see step (h)).

Figures 1 1 is a flow diagram illustrating the process of fixing a problem within a network in which the invention is used to discover the problem and verify that it has been fixed. Figure 1 2 is a flow diagram illustrating a process of adding a new site to a VPN in which the invention is used to verify that the site has been added correctly.

The system and method of the present invention enables network devices to be interrogated in order to derive and present a logical visualisation of the topology and performance characteristics of the VPN, identify actual and suspected deficiencies, and compare, for consistency, this visualisation against the original VPN requirements specification.

Whilst in the described embodiment, a computer program and data is stored on a processing means, in this case a workstation connected to a server remotely linked to the selected VPN, it will be understood to the skilled person in the art that such a program and data could be stored on a memory medium which is remote from the processing means and which is remotely accessed or executed by the processing means. The skilled person would know that the processing means need not be on a remote user site and could be any processing means which is connectable or connected to the VPN network, such as a provider edge (PE) server permanently connected to the VPN. SCHEDULE

VPN Clustering Algorithm

The major steps are as follows:

Step 1: Compile Site List

Starting from a list of addresses of network nodes, connect to each node and interrogate it to determine a list of unique names identifying the VPN sites supported on that node.

The output from this step is a list of uniquely identified site names.

In the example of a Cisco MPLS VPN implementation, the unique identifier chosen could be, for example, a concatenation of the RD number and the IP address of the site.

Step 2: Obtain Logical Site Connectivity Data

For each site identified in Step 1, by interrogation of the network node which supports that site, discover every Target Identifier (TID) which is either imported or exported by that site.

The TID is a representation of logical connectivity advertised by a VPN site. It may be exported, meaning "this is what I am known by" or imported, meaning "this is to whom I can talk". Logical connectivity in a VPN is established through a mechanism in which sites export and import TIDs. Both ends need to exist (an export paired with an import) for the correspondence to be established.

In the example of a Cisco MPLS VPN implementation, the TID would be a Route Target (RT) Number.

Step 3: Create Shared Service Exclusion Table

A Shared Service is a TID advertised by a network node which should be treated in a special way in the ensuing algoritlim. This is because it is in some way orthogonal to the VPN clustering process. An example would be a network management station which can connect to every site while not allowing sites of different VPNs to interconnect. Another example would be a shared Internet access facility where all sites can connect to the public internet while not allowing sites of different VPNs to interconnect. In order to make provision for special treatment of these situations, an Exclusion Table is required. This is a unidimensional list of TIDs that relate specifically to shared service connectivity.

The Shared Service Exclusion Table is created manually based on information from the network engineering specialists responsible for configuring the network.

Step 4: Compile Initial VPN Table

Based on steps 1 and 2, a table can be compiled as the starting point for the VPN clustering algorithm.

The VPN Table contains one row for each unique TID found in Step 2.

The table contains three columns, the TID List, the Node List Exporters, and the Node List Importers. Each list can be of unlimited length. The TID list at this stage contains one item, and therefore the table contains one row for each TID. The Node List Importers contains the list of the names of all nodes that advertise this TID by importing it, as discovered from Steps 1 and 2 above. Similarly, the Node List Exporters contains the list of the names of the nodes that export this TID.

Finally, the table is examined to identify any rows where either the Node List Exporters is empty or the Node List Importers is empty. Any such rows are deleted from the table, as these indicate failed correspondences, ie nodes exporting a route which is never used (imported), or nodes attempting to use (import) a route which is never exported.

Step 5: Apply Exclusions

Use Algorithm 5 shown in Figure 13 of the accompanying drawings, in association with the Initial VPN Table produced in Step 4 and the Shared Service Exclusion Table produced in Step 3, to produce the following variant of the above table:

In addition, the output from Step 5 contains a Node Exclusion List. This is a unidimensional table containing the node names of every node that exports a TID that is to be found in the Shared Service Exclusion Table:

Node Exclusion List nodename nodename nodename etc

Step 6: Apply Clustering Algorithm

The next step is to apply the Algorithm 6 shown in Figure 14 to the table resulting from Step 5.

On completion of this processing, the VPN Table contains one row for each cluster or VPN discovered. In general, after execution of this algorithm, the TID Lists will be longer, as will the Node Lists, while the number of rows in the table will be fewer.

VPN1: VPN2:

Claims

1 . A method of validating the connectivity of a VPN existing within a telecommunications network, comprising the steps of: (a) connecting a processing means to at least one device on the VPN ;

(b) discovering or determining information on the network device(s) , the information comprising configurational and relationship information;

(c) storing the information discovered in step (b);

(d) visualising the network from the stored information;

VPN(s);

(f) testing the functionality of the network device(s) of the VPN(s);

(g) analysing the results of the testing step (f) to assess and discover exceptions in the functionality of the network device(s) of the VPN(s); and

(h) displaying information representing the actual status of the VPN(s) and information representing the exceptions identified in method steps

(e) and (g);

2. A method as claimed in claim 1 , wherein the exceptions comprise deficiencies or suspected deficiencies in the configurations of the network device(s) .

3. A method as claimed in claim 1 or 2, wherein the method step (a) includes seeding the system with minimal information in order to perform step (b).

4. A method as claimed in claim 1 , 2 or 3, wherein the relationship information obtained by method step (b) comprises information representing relationships to VPNs, physical relationships and/or logical relationships.

5. A method as claimed in any one of the preceding claims, wherein the method step (b) includes executing an algorithm stored in the processing means so as to discover the information.

6. A method as claimed in any one of the preceding claims, wherein the method step (e) comprises the step of comparing manually the visualisation of the network with externally-supplied data representing a VPN requirement specification.

7. A method as claimed in any one of the preceding claims, wherein the method step (e) comprises applying configuration rule sets which are encoded representations of tests which can be carried out on the information discovered in method step (b).

8. A method as claimed in claim 7, wherein said tests are based on knowledge of best practice principles, or on the comparison between discovered information and Service Provider best-practice standards held within configuration templates.

9. A method as claimed in claim 8, wherein said templates are supplied by the Service Provider.

10. A method as claimed in any one of the preceding claims, wherein the method step (f) comprises testing of the connectivity of the VPN(s).

1 1 . A method as claimed in claim 10, wherein the method step (f) comprises testing of the physical connectivity, logical connectivity and/or non-connectivity.

12. A method as claimed in claim 1 1 , wherein said testing step comprises analysing physical line status, interface statistics and/or parameters.

13. A method as claimed in claim 10, 1 1 or 12, wherein the method step (f) includes interrogating the logical status of the network device(s) of the VPN(s).

14. A method as claimed in claim 13, wherein said interrogation step comprises selecting one or more network devices of the VPN(s), sending interrogation signals to the selected network device(s), receiving reply signals sent from the selected network device(s) in response to the selected network device(s) receiving the interrogation signals, measuring the time delay between sending the interrogation signals and receiving the reply signals from the selected network device(s) of the VPN and storing the measured time delay as data.

15. A method as claimed in claim 14, wherein the method step of interrogating the logical status of the network device(s) of the VPN(s) includes selecting data representing an acceptable time delay of an interrogation signal sent between the selected network device(s), and comparing the measured time delay data with the selected acceptable time delay data so as to determine problems with the functionality of the selected network device(s) and network links therebetween.

1 6. A method as claimed in claim 15, including displaying information indicating or representing differences between the measured time delay and the acceptable time delay so as allow the functionality of the selected network device(s) and networks therebetween to be determined.

1 7. A method as claimed in any one of the preceding claims, wherein the method step (g) comprises applying functional rule sets which are encoded representations of tests carried out on the information discovered in method step (f).

1 8. A method as claimed in claim 1 7, wherein said tests are based on knowledge of best practice principles, or on the comparison between discovered information and Service Provider best-practice standards held within configuration templates.

1 9. A method as claimed in claim 1 8, wherein the templates can be supplied by the Service Provider.

20. A method as claimed in any one of the preceding claims, wherein the method step (h) includes, highlighting differences, if any, in connectivity between what is actually on the network and what should have been configured as determined by an externally-supplied VPN requirement specification.

21 . A method as claimed in any one of the preceding claims, wherein the method step (h) includes the steps of displaying nodes respectively representing network devices, displaying at least one line connected between the nodes, the line(s) representing physical or logical relationships between the network devices, and colouring or highlighting said line(s) to indicate exception information obtained from method steps (e) and/or (g) associated with said relationships.

22. A method as claimed in claim 21 , wherein the method step (h) includes colouring or highlighting a node to indicate exception information obtained from method step (e) and/or (g) associated with the network device represented by said node.

23. A method as claimed in claim 21 or 22, wherein the method step (h) includes displaying the identity information for each selected network device of said VPN.

24. A method as claimed in claim 23, wherein the method step (h) includes superimposing said identity information on corresponding displayed nodes and line(s).

25. A method as claimed in claim 24, wherein the method step (h) includes toggling the display of said coloured or highlighted line(s) and nodes and the display of said identity information.

26. A method as claimed in any one of the preceding claims 21 to 25, wherein the method step (h) includes superimposing on said displayed nodes and line(s) data representing the time delay measured between the selected network device(s) .

27. A method as claimed in any one of the preceding claims, wherein the method step (h) includes displaying exceptions in the data representing the actual status of the VPN(s) if said exceptions fall within a selected range of severity level.

28. A method as claimed in any one of the preceding claims, wherein the processing means performs at least one of the method steps.

29. A method as claimed in any one of the preceding claims, wherein the processing means is a server with an attached workstation.

30. A method as claimed in claim 29, wherein the workstation is remotely connectable to the public telecommunication network by a remote access server.

31 . A method as claimed in any one of the preceding claims, wherein the or each network device comprises a router or server.

32. A method as claimed in any one of the preceding claims, wherein the network is an Internet protocol virtual private network (IP-VPN) which is built using public domain standards multi protocol label switching (MPLS) and border gateway protocol (BGP) .

33. A method as claimed in claim 31 , wherein the network routers/servers comprise customer edge (CE) routers and provider edge (PE) routers, the former routers existing on network user sites and supporting communications from users at those sites.

34. A method as claimed in claim 33, wherein the method step (a) includes storing the IP addresses of all PE routers on the telecommunications network.

35. A method of discovering the connectivity of a VPN or selected VPN existing in a telecommunications network, in which a processing means is connected to at least one device of the VPN, information on the network device(s) including configurational and relationship information is discovered from said network device(s), the discovered information is stored and the network is visualised from the stored information.

36. A method of validating the functionality of a VPN existing in a telecommunication network in which a processing means is connected to at least one device of the VPN, the functionality of the or each device is tested by a testing means, the results of the testing are analysed by an analysing means to assess the functionality of the network device(s) of the VPN, and information representing the actual status of the VPN(s) and information representing the required or intended status of the VPN(s) is displayed.

37. A method of displaying information representing the connectivity of a VPN or selected VPN existing within a telecommunications network, in which information representing the discovered and required connectivity is displayed so as to enable the consistency of the VPN to be visualised.

38. A system for validating the connectivity of a VPN existing within a telecommunications network, comprising processing means connectable to the telecommunications network, connecting means for connecting said processing means to the selected VPN, discovering means for discovering or determining information on the network device(s), the information comprising configurational and relationship information, storing means for storing the discovered information, visualising means for visualising the VPN(s) from the stored information, analysing means for analysing the discovered information to assess the configurations of the network device(s) of the VPN(s), functionality testing means for testing the functionality of the network device(s) of the VPN(s), a analysing means for analysing the results of the functionality testing to assess the functionality of the network device(s) of the VPN(s), and displaying means for displaying information representing the actual status of the VPN(s) and the required or intended status of the VPN(s).

39. A system as claimed in claim 38, wherein the connecting means includes seeding means for seeding the system with minimal information to enable the discovering means to discover or determine the information.

40. A system as claimed in claim 38 or 39, wherein the relationship information discovered by the discovering means includes information representing relationships to VPNs, physical relationships and/or logical relationships.

41 . A system as claimed in claim 38, 39 or 40, wherein the discovering means comprises an algorithm stored in the processing means which is executable to discover the information.

42. A system as claimed in any one of the preceding claims 38 to 41 , wherein the analysing means for analysing the discovered information comprises comparing means for comparing the visualisation of the network with data representing a customer order specification.

43. A system as claimed in any one of the preceding claims 38 to 42, wherein the analysing means for analysing the discovered information comprises supplying means for supplying parameters to enable templates to be configured with values.

44. A system as claimed in claim 43, wherein said parameters may be supplied by a Service Provider to the processing means.

45. A system as claimed in any one of the preceding claims 38 to 44, wherein the analysing means for analysing the discovered information may comprise a further algorithm stored in the processing means which is executable so as to check information on the network device(s).

46. A system as claimed in claim 45, wherein said further algorithm embodies configuration rules which are encoded representations of tests which can be applied to the information discovered in order to check that best practice has been observed.

47. A system as claimed in any one of the preceding claims 38 to 46, wherein the analysing means includes verifying means for checking the information on the network device(s) against the customer's best-practice templates.

48. A system as claimed in any one of the preceding claims 38 to 47, wherein the analysing means includes printing means for printing out the results of analysing the discovered information and comparing means for comparing with the inventory database holding a customer order specification.

49. A system as claimed in any one of the preceding claims 38 to 48, wherein the testing means for testing the functionality of the VPN(s) is arranged to test the connectivity of the VPN(s), such as, the physical connectivity, logical connectivity and/or non-connectivity.

50. A system as claimed in any one of the preceding claims 38 to 49, wherein the testing means includes means for analysing the physical line status, interface statistics and/or parameters, details of which are collected, for example, by issuing pings.

51 . A system as claimed in any one of the preceding claims 38 to 50, wherein the analysing means for analysing the results of the functionality testing comprises a further algorithm which is stored and executable in the processing means so as to assess the results.

52. A system as claimed in claim 51 , wherein said further algorithm embodies functional rules which are encoded representations of tests which are applied in order to check that the VPN is capable of carrying traffic within acceptable bounds of operational performance.

53. A system as claimed in any one of the preceding claims 38 to 52, wherein the analysing means includes verifying means for checking the results against the customer's best-practice templates.

54. A system as claimed in any one of the preceding claims 38 to 53, wherein the analysing means includes printing means for printing out the results of the functionality testing and comparing means for comparing the print out with the inventory database holding a VPN requirement specification.

55. A system as claimed in any one of the preceding claims 38 to 54, wherein the displaying means includes highlighting means for highlighting the differences, if any, in connectivity between what is actually on the network and what should have been configured as per the VPN requirement specification.

56. A system as claimed in any one of the preceding claims 38 to 55, wherein the functionality testing means comprises interrogating means for interrogating the logical status of network device(s) of the VPN(s).

57. A system as claimed in claim 56, wherein the interrogating means comprises selecting means for selecting one or more network device(s) of the VPN(s) from information representing the identities of the network devices, sending means for sending interrogation signals to the selected network device (s), measuring means for measuring the time delay between sending the interrogation signals and receiving the interrogation signals from the selected network device(s) of the VPN, storing means for storing the measured time delay as data and displaying means for displaying the data representing the measured time delay.

58. A system as claimed in claim 57, wherein the functional testing means may include logical data selecting means for selecting data representing an acceptable time delay of an interrogation signal sent to the selected network device or between the selected network devices, comparing means for comparing time delay data with the selected specified time delay data so as to determine problems with the functionality of the selected network devices and network therebetween, and display means for displaying information representing the differences between the measured time delay and the specified time delay so as allow the functionality of the selected network devices and networks therebetween to be determined.

59. A system as claimed in any one of the preceding claims 38 to 58, wherein the display means comprises means for displaying nodes respectively representing network devices, and means for displaying at least one line connected between the nodes, the line(s) representing logical or physical relationships between the network devices.

60. A system as claimed in claim 59, wherein the display means includes means for colouring or highlighting said line(s) to indicate a difference between the discovered information associated with said relationship and reference data and means for colouring or highlighting a node to indicate a difference between the discovered information and/or results of the functionality tests associated with the network device represented by said node and the reference data.

61 . A system as claimed in claim 59 or 60, wherein the display means includes means for superimposing on said display nodes and line(s) representing one or more selected network devices data representing said time delay measured between the selected network devices.

62. A system as claimed in claim 61 , wherein the display means includes means for displaying identity information for each selected network device and means for superimposing said identity information on corresponding displayed nodes and line(s).

63. A system as claimed in claim 62, wherein the display means includes means for toggling the display of said coloured or highlighted line(s) and nodes and the display of said identify information.

64. A system as claimed in any one of the preceding claims 38 to 63, wherein the display means includes means for displaying differences in the data representing the actual status of the VPN(s) and the reference data if said differences fall within a selected range.

65. A system as claimed in any one of the preceding claims 38 to 64, including selecting means for selecting one of a plurality of VPNs from information representing the plurality of VPNs.

66. A system as claimed in claim 65, wherein the reference data includes information representing the required connectivity of the network devices of a plurality of VPNs.

67. A system for discovering the connectivity of a VPN or selected VPN existing in a telecommunications network, in which a processing means is connected to at least one device of the VPN, information on the network device(s) including configurational and relationship information is discovered from said network device(s), and the discovered information is stored and the network is visualised from the stored information.

68. A system as claimed in claim 67, wherein said information may be discovered by a clustering algorithm.

69. A system as claimed in claim 67 or 68, including an analysing means in which the discovered information is analysed to assess the configurations of the network device(s) of the VPN(s)

70. A system for validating the functionality of a VPN existing in a telecommunication network in which a processing means is connected to at least one device of the VPN, the functionality of the or each device is tested by a testing means, the results of the testing are analysed by an analysing means to assess the functionality of the network device(s) of the VPN, and information representing the actual status of the VPN(s) and information representing the required or intended status of the VPN(s) is displayed.

71 . A system for displaying information representing the connectivity of a VPN or selected VPN existing within a telecommunications network, in which information representing the discovered and required connectivity is displayed so as to enable the consistency of the VPN to be visualised.

72. A system as claimed in any one of the preceding claims 38 to 71 , wherein the telecommunication network may be a public telecommunications network, such as the Internet or a private telecommunications network.

73. A system as claimed in any one of the preceding claims 38 to 72, wherein the processing means comprises a workstation, such as a computer terminal.

74. A system as claimed in claim 73, wherein the workstation is remotely connectable to the public telecommunication network by a remote access server.

75. A system as claimed in any one of the preceding claims 38 to 74, wherein the network devices comprise routers/servers.

76. A system as claimed in any one of the preceding claims 38 to 75, wherein the network is an Internet protocol virtual private network (IP-VPN) which is built using public domain standards multi protocol label switching (MPLS) and border gateway protocol (BGP).

77. A system as claimed in claim 75, wherein the network routers/servers comprise customer edge (CE) routers and provider edge (PE) routers, the former routers existing on network user sites and supporting communications from users at those sites.

78. A system as claimed in any one of the preceding claims 38 to 77, wherein the storing means may include means for storing a clustering algorithm in the computer terminal or an associated memory medium and the system may include executing means for executing the clustering algorithm from the computer terminal, said algorithm being used to analyse the configurations of the PE and CE routers of said selected VPN to determine the topology of said selected VPN.

79. A computer program product comprising program code means stored in a computer readable medium for performing a method according to any one of the method steps as claimed in any one of claims 1 to 37 when that product is run on a computer.