JANET Netsight Reporting Path Scenarios

Transcription

1 i JANET Netsight Scenarios Revision History Author Issue Date Description Mark Leese V1.R1.M0 16-Jul-2009 First draft Mark Leese V1.R2.M0 28-Jul-2009 First official draft Luke Woodward V1.R2.M1 22-Nov-2013 Minor updates

2 Table of Contents 1 Introduction Scenarios Preferred Scenario: allows traffic collection and allows pings does not allow pings A and do not support pings does not allow or support traffic collection Outward facing interface on device allows/supports ICMP Outward facing interface on device does not allow/support ICMP Organisation has multiple Connections but a single ping point References... 8 Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 2 of 8

3 1 Introduction JANET Netsight is a network information system showing the current and past performance of the network: the backbone and its links to the rest of the Internet (the peerings) the links into the regional networks the links to all customers This document is concerned with the links to customers, the end user, and forms part of the advice to operators of regional networks and JANET(UK) itself on how to configure Netsight for the monitoring it performs. More advice is given in [1]. Netsight runs ICMP ping tests to various locations and polls routers or switches for traffic data via SNMP. When monitoring connections to end user it is normal for Netsight to be configured to ping the organisation s own border router, while collecting traffic data from the device at the opposite end of the connection, typically a router owned by an operator of a regional network. Sending ping packets to a customer s border router measures ICMP Round Trip Time and packet loss right to the edge of and ensures that the site border router has at least basic connectivity to the network. Each device belonging to an operator of a regional network typically supports several end user. By collecting traffic data from these devices Netsight is able to monitor traffic levels for several end user whilst requiring SNMP read access to just a single device. This requires considerably less configuration for both regional operators and the end user themselves. This document advises JANET(UK) and operators of regional networks on how to configure monitoring when it is not possible to follow the preferred approach outlined above. If at any stage you feel unsure as to which scenario to follow, please SAG.Queries@ja.net for guidance. Netsight supports ping tests and SNMP polling of devices only, but the system has been designed to allow the addition of new measurement types and the import of datasets from external systems. This document may be updated to take account of new data types. 2 Scenarios connections are terminated by A and s. The is that closest to network core, and the that closest to the network edge and hence the customer. To understand the scenarios it is first helpful to consider how this is represented and monitored in Netsight. Netsight nodes represent network nodes; routers in most cases. s host interfaces. Measurement Jobs take from other devices (e.g. SNMP polling of routers) or make themselves (e.g. run ping tests). Measurement Jobs target interfaces, in most cases an interface to read traffic statistics for or an interface to ping. A is a notional link between two interfaces. It creates a convenient association between the traffic and ping data, which as discussed in section 1 is often measured at different ends of a connection, on two otherwise unrelated nodes and hence unrelated interfaces. Readers should also note that Netsight sources its ping tests within the core, so ping points must therefore use publically routable IP addresses. 2.1 Preferred Scenario: allows traffic collection and allows pings This is the standard scenario, shown below, in which traffic data is collected from the customer facing interface of a regional operator s device and pings are sent to the outward facing interface of the end user organisation s border router. The reflects the physical connection. Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 3 of 8

4 Pings Preferred Scenario 2.2 does not allow pings; allows pings and traffic collection This scenario occurs when end user will not allow their equipment to respond to pings, in which case, the preferred option is to ping the device. With both ping and traffic Measurements Jobs targeting the device it is no longer necessary to create a node exactly corresponding to the end user organisation s border router, although a node to terminate the other end of the is still required. A Dummy node is configured, containing a single default interface, which is used to terminate the. Information on naming dummy nodes can be found in [1]. When creating such nodes, please ensure that all Permitted Jobs checkboxes are un-ticked. If several s within the same region fall into this scenario, the preferred configuration is for them to share the default interface of a common dummy node. Use of a dummy node removes the need to configure the system with nodes which serve no monitoring purpose. Since the dummy node contains no information, any changes to an organisation s monitoring would not strictly require the unused node to be updated. Using a dummy node also removes the danger of the system becoming populated with confusing, out of date nodes. Pings Dummy Physical Connection Ping and traffic Measurement Jobs target traffic carrying interface on Use of the node for pinging is made clear on ping graphs as the node s Display Name [1] is shown in the table of statistics at the right hand side of the graph. It is also indicated on Light pages by pre-pending an exclamation mark to the Up/Down/Degraded text. This scenario does however cause a problem for schematic maps, which will show the dummy node wherever a real node would otherwise appear. This issue will be addressed at a later date. Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 4 of 8

5 2.3 allows traffic collection; A and do not support pings This scenario occurs when the interfaces at either end of an end user organisation s connection do not have IP addresses, e.g. they are Ethernet only interfaces. As a consequence it is not possible to ping the outward facing interface of the device or the traffic carrying interface on the device. Loopback Interface Physical Connection Pings to internal interface with publically routable IP address, e.g. mgmt VLAN Scenario where neither outward facing interface nor traffic carrying interface have an IP address In this case, Netsight should be configured to ping an inward facing interface on the node which is using a publically routable IP address, e.g. the interface used by the end user organisation s management VLAN. The system must not be configured to ping the loopback interface of the device. A ping response from the loopback interface only proves that the device is functioning. It does not prove that the link to the end user organisation is operational or free of performance degrading round trip times or packet loss. If in doubt, please contact SAG.Queries@ja.net for guidance. 2.4 does not allow or support traffic collection For some end user it is not possible to collect traffic statistics from the device. One example would be whose last mile access is provided by commercial providers who will not give SNMP access to their equipment. Another example would be fed by switches which do not support SNMP. For this scenario, it is necessary to obtain traffic data from the outward facing interface of the end user organisation s border router. Two sub-scenarios exist, dependant on whether or not the outward facing interface supports ICMP. When collecting traffic data from the end user organisation s border router, only the outward facing interface should ever be used. Such routers typically have a single outward facing interface but may have several inward facing interfaces, feeding different departments, buildings etc. Only by measuring traffic on the single outward facing interface are we guaranteed to be measuring all data sent to and from the organisation Outward facing interface on device supports ICMP In this scenario the outward facing interface of the end user organisation s border router is used for both ping and traffic. This is essentially a reversal of scenario 2.2. The device is not used for any data collection and can be replaced by a dummy node. Use of a dummy node removes the need to configure the system with nodes which serve no monitoring purpose. Since the dummy node contains no information, any changes to an organisation s monitoring would not require the dummy to be updated. Using a dummy node also removes the danger of the system becoming populated with confusing, out of date nodes. Information on naming dummy nodes can be found in [1]. When creating such nodes, please ensure that all Permitted Jobs checkboxes are un-ticked. If several s within the same region fall into this scenario, the preferred configuration is for them to share the default interface of a common dummy node. Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 5 of 8

6 In the standard scenario traffic is measured at the interface, and Netsight knows to display traffic into the regional operator s device as traffic from the end user organisation, and vice versa. In this scenario, Netsight knows from the configuration of the that traffic data is being collected on the interface, and accordingly reverses the direction of the traffic, i.e. traffic into the outward facing interface of the router will be displayed as traffic to the site. Pings Dummy Physical Connection Ping and traffic Measurement Jobs target outward facing interface of Outward facing interface on device does not support ICMP This scenario occurs when the outward facing interface of the end user organisation s border router supports traffic but not pings. This scenario would occur for example when Ethernet only interfaces connect the operator of the regional network and the organisation, and thus the outward facing interface does not have an IP address. In this case, a reversed spans the end user organisation s router, with the outward facing interface set as the and an inward facing interface set as the. data is collected from the outward facing interface so that we are sure of taking account of all data sent to and from the organisation. Pings are targeted at any inward facing interface with a publically routable IP address, e.g. that used by the end user organisation s management VLAN. Pings to internal interface with publically routable IP address, e.g. mgmt VLAN JANET Physical Connection spanning the end user organisation s border router As with scenario Netsight knows from the configuration of the that traffic data is being collected on the interface, and accordingly reverses the direction of the traffic, i.e. traffic into the outward facing interface of the end organisation s border router will be displayed as traffic to the site. Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 6 of 8

7 An undesirable side affect of being forced to use this scenario is that the Light pages will indicate that the system is pinging the upstream end of the because the ping Measurement Job is targeting the s. This is likely to mislead users into believing that the system is sending pings to the regional operator s equipment. At present this issue is largely unavoidable but may be addressed at a later date. 2.5 Organisation has multiple Connections but a single ping point user exist which are fed by multiple connections yet have only a single ping point which will respond to ping packets providing at least one of the site s connections is operational. Sites fed by aggregated Ethernet links fall into this category. For these sites, traffic and ping measurement data are not associated using a. The site s ping data is presented separately via its own. Associating the site s ping data with traffic data for one of its connections could imply to users that pings only pass over that connection, which is incorrect. Similarly, associating the site s ping data with traffic data for all of its connections could imply to users that Netsight runs separate ping tests for each of the connections, which is also false. In this scenario, a is created for each connection to the site. These s will only be associated with traffic measurement data. An additional is created to present ping data to end users. The specifics of the scenario assumed in the diagram are that: Both aggregated Ethernet links are terminated at the end user organisation on the same device. In reality, the links could be terminated on separate devices. The single ping point is on the end user organisation s border router. The ping point could in fact be on another device, further inside the organisation s LAN. Dummy 1 Reporting Path Physical Connection 2 Dummy Physical Connection Ping Pings to internal interface with publically routable IP address, e.g. mgmt VLAN Scenario for end user with multiple connections and a single ping point A Netsight node object corresponding to the end user organisation should be created, taking the IP address or hostname of the organisation s ping point. The ping will target this node, as will the of the ping. To avoid associating the ping data with any traffic data the ping is terminated at the using a dummy node. The s which point to the interfaces for which traffic measurement data is collected are terminated at the using a dummy node. This further ensures that ping and traffic data are Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 7 of 8

8 presented separately, and means we do not have to represent the exact topology of the physical connections within Netsight. For example, we need not concern ourselves with which device(s) terminate the aggregated Ethernet links at the end user organisation. It is sufficient to know the ping point and traffic carrying interfaces. Guidance on naming dummy nodes can be found in [1]. When creating such nodes, please ensure that all Permitted Jobs checkboxes are un-ticked. If several s within the same region fall into this scenario, the preferred configuration is for them to share the default interface of a common dummy node. 3 References 1. Netsight : Copyright: This document is copyright Jisc Collections and Limited trading as JANET(UK). Parts of it, as appropriate, may be freely copied and incorporated unaltered into another document unless produced for commercial gain, subject to the source being appropriately acknowledged and the copyright preserved. The reproduction of logos without permission is expressly forbidden. Permission should be sought from the Service Desk. Trademarks: JANET is a registered trademark of the Higher Education Funding Councils for England, Scotland and Wales. Jisc Collections and Limited is the registered user of this trademark. Netsight is a Registered Trademark of Jisc Collections and Limited. Last updated 22-Nov-2013 Issue: V1.R2.M1 Page 8 of 8