Enterprise Network Performance Assurance

Transcription

1 Enterprise Network Performance Assurance Solution Brief NetTESTER Embedded Ethernet Network Performance Assurance August, 2015 Metrodata Ltd Laxton House, TW20 8RY U.K. Tel: +44 (0)

2 Introduction Over the past few years Corporate Enterprise Networks have undergone massive changes, and yet in many cases are still right in the midst of ongoing evolution, involving much uncertainty and concern for Network Managers. Virtualisation, associated with migration to cloud-based services, and the almost obligatory requirement to enable employees to attach their own mobile devices to the Corporate Network, i.e. the so-called ethos of 'Bring Your Own Device' (BYOD), are just two of the major contributors to this uncertainty. No longer can traffic levels and flow patterns be easily estimated, and the plethora of 'always on' and sometimes bandwidth heavy applications associated with BYOD add to the challenges. Moreover, the encroachment of time-critical applications, principally voice, to the Corporate Data Network in the form of VoIP services, means that it's not sufficient for Network Managers just to provision sufficient bandwidth around their network. Now, the challenge is to ensure that parameters such as delay (a.k.a. Latency) and delay variation (a.k.a. 'Jitter') do not exceed certain levels critical to the successful operation of VoIP applications, even under heavy and continuously varying load conditions. This is particularly important for Wide Area Networks (WANs), which are bandwidth limited and less under the Network Manager's control. Not surprisingly, one consequence of this is that now, more than ever, Network Managers need to know at all times that their networks are delivering against all of the required performance characteristics for their users' diverse applications. Whilst this applies within each individual LAN location, it is particularly prevalent for the WAN, since Corporate WAN architectures today are no longer based largely on connection-oriented SDH/PDH infrastructures (E1/T1, E3/DS3 and the like), but increasingly on non-deterministic, so-called 'next generation' packet-based networks, typically via MPLS core infrastructures. A relatively simple IP- VPN based 3-site WAN is illustrated in Fig. 1, in this case offering Ethernet connections via a typical Network Service Provider's Managed IP Service, delivered via an MPLS core network. Such networks are generally provisioned to customer sites via 'tail' circuits, contracted by the Service Provider from Local or National Infrastructure Carriers, such as for example in the UK, BT OpenReach or Virgin Media. LANs and WANs Fig. 1: Simplified Enterprise 3-site IP-VPN (over Carrier's MPLS Core) Within the Local-Area Network (LAN) of an office or campus, Ethernet has been the all-pervasive infrastructure delivery vehicle for many years, although both infrastructure and device connections have evolved through a number of developments from the late 1980s, from predominantly 'shared 10Mbps' through 'Switched/Dedicated 10Mbps' and latterly to dedicated 100Mbps and 1Gbps infrastructures, complemented by Wireless connectivity for Laptop PCs and all manner of 'BYOD' platforms. Page 1 of 10

3 The situation for Wide-Area Networks (WANs) is more complex and is often mis-understood. For the great majority of Corporate Networks, the point of connectivity from an office LAN to a Service Provider's WAN is almost always via an Ethernet connection, so many regular Network users simply think of the 'Ethernet Network' as a term equally applicable to LAN and WAN. In reality though, the nature of the WAN service itself can be varied and complex, dependent upon many factors including required bandwidth, security, degree of 'control' desired by the Corporate relative to their Service Provider and, as always, the 'costeffectiveness' of a particular service! For example, a mid-sized company with two main office locations and a smaller remote facility, may have few IT staff, with or without networking expertise, and may contract with a Service Provider for a fully managed IP Virtual Private Network (IP-VPN) across their three sites. In this case, the Provider might offer a particular fixed WAN bandwidth (say 20Mbps) to each of the main offices, delivered over a 100Mbpscapable circuit (allowing the potential of rapid provisioning for bandwidth expansion under the Provider's Network Management control) and a more variable 'DSL' broadband based connection to the smaller facility. In each case though, the service will be terminated within the customer's facilities via an IP Router of some kind, presenting one or more Ethernet ports for the customer's LAN connection(s). In this case, the Service Provider is managing all of the customer's connectivity via an IP infrastructure, providing one or more IP network addresses to the customer for each location and maybe offering valueadded services including WAN security, Internet Access, Voice PBX (VoIP) connectivity to the Public Switched Telephone Network (PSTN) and perhaps Website Hosting, etc. The customer simply contracts for the service and takes no active role in management. But, do they really know if they are getting what they're paying for? More importantly perhaps, for all of the reasons mentioned in the Introduction, if their users question the overall performance of the Network, how can they tell what the issues might be? Can they trust that their Provider will offer the most appropriate profile of service parameters, rather than just ever more bandwidth at higher cost? Fig. 2: Service Provider's Layer 2 Network (e.g. VPLS overlay to MPLS Core) Let's now consider a slightly different case, illustrated in Fig. 2. Here, the WAN Service Provider's customer has chosen to take more responsibility for their own infrastructure, to the extent that they have effectively contracted purely for 'Layer-2' Ethernet bandwidth from the provider, typically delivered as a simple Ethernet physical connection, frequently terminated via an Ethernet Demarcation Device (EDD), manageable, to a greater or lesser degree (and this is an important point!), by the Service Provider, but not by the customer. The customer connects to the WAN using their own Routers, plugged via Ethernet to the Service Provider's access devices, giving them the responsibility for IP addressing and Routing and arguably more control over their WAN security. Page 2 of 10

4 Now, whilst some Routers do (at a price!) incorporate Performance monitoring tools, such as Cisco's 'IP SLA', these tend to be software driven, meaning that their own performance is somewhat dependent upon the loading of the system at any given time and are therefore not always regarded as effective. More significantly as indicated above (and this can be as true for Service Providers' IP-VPN Networks as well as Layer-2 infrastructures), it is not always the case that a Service Provider themselves has absolute visibility over their own network delivery, right out to the point of connection into their customer's sites. In the highly devolved and segmented world of Telecoms service provision in developed markets, the reality is that a Provider's own network, i.e. that element fully manageable via their own systems, may be limited in physical extent to just a small number of locations, perhaps only a few MPLS Routers within various Carrier Co-Location Data Centres. Their service delivery relies upon the relatively few true Infrastructure Carriers with National and/or Local copper or fibre connections, whose circuits are offered to the Service Provider community on a wholesale basis, as 'Tails'. These link a given Service Provider's equipment out into their Customers' premises. In the UK, for example, the dominant infrastructure provider is BT's OpenReach division, with very few companies, including Virgin Media and COLT (primarily in London) offering extensive competitive infrastructure. Other Service Providers rely on infrastructure from these companies in order to service their customers. Most frequently, in order to provide connectivity across a variety of sites as required by a mid to large-sized Corporate, a Service Provider might well take advantage of the infrastructure circuits of a number of different organisations to deliver the most cost-effective solution. One implication of this is that, unless the Service Provider has taken the step to deploy their own manageable entities right at the point of network connection at each customer site, they may themselves only have manageable visibility within their core network equipment, with little view to the vagaries of the Carrier's tail circuits used to fulfil the customers connectivity needs. We have not even begun to discuss the ups-and-downs of those sites for which service may be based on copper or fibre derived DSL links, but overall the picture, for more critical high-capacity connections to major facilities, is that regardless of whether contracting for layer-2 or layer-3 based infrastructure, it is not always possible to rely on Service Providers to be able to measure and/or proactively monitor the overall performance, let alone the more complex parameters of Latency and Jitter, between all points in and across their networks. 'On-demand' Network Performance Measurement So, how best can the Corporate IT department cost-effectively achieve a meaningful level of both 'ondemand' performance measurement and 'in-service' monitoring? These two cases are in fact rather different and we'll examine both. Whilst the principles here can readily apply to LAN connectivity, it's undoubtedly the case that WAN services provide the critical points for Network managers, since WAN bandwidths are lower and latencies can be orders of magnitude greater than within the LAN. So, our attention will be focused on WAN performance. Firstly, at the time of contracting for a new WAN connection, ideally a set of 'Service Level Agreement' (SLA) parameters will be established between the Service Provider and their Enterprise customer. Typical parameters will include throughput, Packet Loss Ratio, Delay (Latency), Delay Variation (Jitter) and perhaps an overall metric for 'Uptime' as a percentage of total commissioned lifetime of the service. On commissioning of the service, the Enterprise customer will wish to establish that the contracted criteria are being met, as least with regard initially to the first four of the above parameters, since 'percentage uptime' will necessarily take some lapsed time to become meaningful. Page 3 of 10

5 Normally, testing of this type would require a dedicated Ethernet test set, featuring comprehensive controls for configuration of all the appropriate parameters to match the SLA required of the network under test. Such devices, as illustrated in Fig. 3, are excellent but expensive, and even a larger Enterprise will not wish the expense of maintaining such equipment at all locations. Testing might typically involve a specific trip to site by a well-trained resource, to connect the test set at the demarcation point of the Service Provider's connection and run the test. Moreover, this type of equipment will launch test traffic into the network which requires to be looped or 'reflected' back at the far end of the WAN link, in order to enable evaluation and report compilation back at the tester, so it may additionally be necessary to have a suitable resource at the destination point for the network link under test, to facilitate this. Fig. 4: Deployment and use of dedicated Ethernet Test equipment It is important to note at this point that it is not normally suitable to create a simple physical network loop at the remote end of the circuit under test, since in Ethernet and/or IP terms this would appear, to the WAN infrastructure, as though two devices with the same Ethernet and/or IP address were transmitting from different points within the network, not normally an allowable condition. Instead, the loop-back point must more closely replicate a regular device, which can be achieved by a simple Source Address / Destination Address 'swap' as test traffic is reflected back to the Tester. Dedicated hardware would normally be required for such a task, since this may need to be conducted at full line rate most commonly perhaps up to 1Gbps, particularly if this approach is being used in a LAN segment rather than across a WAN, even if WAN speeds of 1Gbps are becoming increasingly common. The most common forms of test for Ethernet networks currently in regular use are known respectively as RFC2544 and ITU-T Y The former is arguably most appropriate for situations in which the boundaries of network performance are unknown, or for which no clear SLA has already been defined. The test typically involves the transmission of packets in a pre-determined sequence of sizes, perhaps from the Ethernet minimum of 64 bytes (excluding overheads due to VLAN tagging etc.) in steps up to the maximum packet size supported across the Service Providers equipment, or likely to be used by the Enterprise. The test will attempt to flood the network at maximum line rate, and if errors are detected, for instance by a level of packet loss due to the WAN not supporting the transmitted rate, then the test will follow an algorithm to progressively back-off and then steadily increase, traffic flow until the maximum sustainable rate is determined. Once this rate is determined across the whole range of packet sizes specified within the test, then the various resulting parameters are recorded. A section of a typical RFC2544 test summary, generated from one of Metrodata's own embedded test units, is illustrated in Fig. 5 overleaf. In contrast, the ITU-T (International telecommunications Union) Y.1564 profile test can be an excellent choice for testing against a pre-defined 'Committed Information Rate' (or 'CIR', typically part of an SLA definition). Typically the test sequence involves traffic generation increasing over a minimal number of increments up to the CIR, for a given packet size. provided that the CIR is met, the test proceeds to record characteristics similar to those of the RFC2544 test. This is repeated for different packet sizes in order to provide a full qualification of the Network service. in other respects, the Y.1564 test profile is more sophisticated than that of RFC2544, but a further detailed examination is beyond the scope of this paper. Both RFC2544 and Y.1564 tests are 'agnostic' to packet type and addressing. Consequently, by using a tester capable of supporting both Ethernet MAC addressing and IP addressing, then these tests can be conducted across either Layer-2 or layer-3 infrastructures. Page 4 of 10

6 Fig. 5: RFC2544 Test report example (latency test summary only) OK, but how is all this 'on-demand'? Good point! Whilst we've been detailing the merits and procedures involved with 'traditional' Ethernet circuit testing, it's clear that using expensive equipment, which requires skilled individuals to operate, is fine provided that one has both of these in the right place at the right time. Whilst this may be readily possible for initial circuit commissioning, what about subsequent periodic health-testing during scheduled maintenance windows, or what about ad-hoc troubleshooting in the event of user-reported problems? Here's where Metrodata's NetTESTER family comes into its own! Fig. 6: Deployment of 'NetTESTER' family embedded Ethernet test devices Metrodata offers the NT1003 and NT1005 as low-cost devices featuring custom hardware specifically designed for the task of acting as permanently-available, remotely manageable, embedded test traffic generation and/or test traffic reflection devices, for deployment in networks featuring both Layer-2 (Ethernet) or Layer-3 (IP) Carrier infrastructures. These devices might sit either right in the 'data-path', i.e. between the point of demarcation from a Service Provider's Network connection and the Corporate LAN, as illustrated in Fig. 6, or alternatively on a switched-spur connection at the demarcation point. In the former mode, these devices would normally act passively to forward all traffic transparently to/from the WAN. We're still addressing typical deployment primarily in terms of WAN testing here, although these devices are just as readily used for LAN testing, in which case they might, for instance, be embedded at different critical locations around a campus LAN or larger office facility. Page 5 of 10

7 Whenever required, the test traffic generation and/or line-rate loop-back capability (using Ethernet or IP Source Address/Destination Address swapping) of these devices can be invoked under Network Management control from a central Network Operations Centre (NOC) facility and an RFC2544 or Y.1564 profile test run, with the results being visible directly on-screen, or transmitted as a report to the NOC for subsequent analysis or inclusion to service documentation. Such operation is illustrated in Fig. 7 below. Fig. 7: Typical 'NetTESTER' operation for commissioning or ad-hoc troubleshooting performance tests Management, including configuration, test profile selection and set-up, Layer-2 or Layer-3 operation and report handling can all be managed from the graphical user interface of a Central NOC application, as illustrated in Fig. 8 overleaf. Metrodata's NetTESTER family provides an excellent alternative to expensive and therefore resourcelimited portable test devices, by merit of their cost-effectiveness, permanent availability in the network and remote manageability, limiting the need for expertise beyond central network management staff. The products are accessible for Management via Telnet, secure SSH or by Web Browser across the network, with the option of TACACS+ based user authentication if required. Additionally, NetTESTER family devices support SNMP, in particular for alarming to certain conditions, including the useful feature for so-called 'dying gasp' alerting, under which if the power supply of the device fails, then an alarm is generated alerting to this condition. Moreover, both the NT1003 and NT1005 support additional network testing features with regard to the physical layer of LAN and/or WAN connectivity. Specifically, both products support TDR and optionally automated OTDR (Optical Time-Domain Reflectometry) functionality. OTDR functionality is particularly useful in that one of the major headaches in some environments can be the disconnection or breakage of Fibre WAN connections. Metrodata's products, in combination with a particular OTDR-capable plug-in 'SFP' fibre transceiver, are able to monitor and generate alarms in the event of a fibre breakage, issuing an SNMP Trap alarm of the general format: "Fibre length previously m. At time 13:04:26, service down, with fibre length reported as m" Page 6 of 10

8 This can be particularly useful to assist network managers with the notoriously difficult job of locating the exact whereabouts of fibre link problems, and represents another value-adding benefit of the permanently embedded NetTESTER approach. Fig. 8: Management Console view, illustrating status view (map), remote test configuration (Telnet log-in screen) and example RFC2544 report generated from a circuit test Pro-active Performance Monitoring and SLA-breach Alarming So far, so good! The Enterprise Network manager now has readily available tools to test links thoroughly, whenever required, throughout the organisation. Nevertheless, NetTESTER can bring greater value still to the task of Performance Assurance of today's packet-based networks. By implementing protocols primarily developed for the Packet-based Carrier WAN industry, NetTESTER family devices include the possibility to provide background 'in service' monitoring of network performance and SLA characteristics. The RFC2544 and Y.1564 test profiles discussed thus far are, in some respects, limited. They necessarily require full availability of the service being tested, meaning that these tests are inappropriate for 'in-service' usage. So the possibility to monitor performance aspects of the network whilst fully in use for regular traffic, without impacting adversely on the throughput of potentially critical data, is an important additional benefit. Specifically, leveraging their development heritage from Metrodata's family of Carrier Ethernet Demarcation Devices, the NT1003 and NT1005 support both the (Layer-2) ITU-T Y.1731 Carrier Ethernet Service-level OAM protocol and the (Layer-3) 'Two-Way Active Measurement Protocol' (TWAMP) for in-service monitoring of network Latency, Jitter and Packet-Loss parameters across Ethernet and IP infrastructures respectively. These features enable NetTESTER devices to actively monitor key performance characteristics and, furthermore, to issue pro-active SNMP 'Trap' alarms to the Network Operations Centre in the event that any monitored link within the LAN/WAN domain fails to meet pre-determined SLA requirements. This 'in-service' monitoring functionality, which also facilitates the collation of long-term traffic profiling data which can be invaluable for understanding the overall characteristics of a network under variable load conditions during an extended period, underlines the real benefit of permanently embedded and alwaysaccessible test devices, Vs. even the most portable 'plug-in' test sets. Page 7 of 10

9 Fig. 9 below illustrates the case of the TWAMP-lite protocol being used between two NetTESTER devices (in this case, NT1003 units) to provide alarms to the HQ-based Network Operations Console, should predetermined maximum levels for Latency, Jitter or Packet-Loss Ratio, be exceeded for traffic across the WAN link between remote sites A and B. Fig. 9: TWAMP-lite being used to monitor in-service performance and to generate alarms if pre-defined SLA profile is breached Such monitoring and alarming can enable the Enterprise Management team to respond immediately to alerts regarding potential network performance problems, perhaps even before their users have become aware of potential issues. Summary Enterprise networks are undergoing rapid changes. With the advent of BYOD and increasing use of VoIP and Video communication, let alone the impending boom in devices with support for the so-called 'Internet of Things' (IoT) paradigm, these changes are set to continue. Corporate LANs, and in particular WANs, must be capable of supporting continuously changing usage patterns of both data volume and time-sensitivity. Given the increasing prevalence of inherently nondeterministic Packet-based Wide Area Networks, Network Managers need the right tools, readily available and 'always-on' to both test, and subsequently monitor, network performance. This is particularly the case since few Service Providers yet offer adequate guarantees or effective tools to provide assurance that the networks they have provisioned either initially meet, or continue to meet when under load, the SLA criteria under which they have been contracted. Metrodata's NetTESTER family of embedded Network performance test and monitoring devices offer Network Managers the tools and visibility they need to meet the demands of their users, comprehensively and yet very cost-effectively. These devices can be placed within the data path at critical points throughout an extended LAN environment and/or at boundaries between premise LAN and Wide Area Network links between remote sites within the Enterprise, monitoring the key criteria of network performance and Page 8 of 10

10 providing alarms to the Enterprise Network Operations Centre (NOC) when problems occur. Whenever required and on-demand, NetTESTER devices can be remotely instructed to generate test traffic of standard or customisable profiles, or provide loop-back to testers elsewhere in the network. Detailed or Summary reports can then be issued to the NOC for inspection or inclusion to regular status documentation. Alternatively, SNMP Management platforms are able to interrogate NetTESTER units for live performance metrics, which can readily be compiled into performance tables or used to generate time-series graphs through regular SNMP polling. For more information look for our NetTESTER pages on our website or review the information below. About Metrodata Metrodata Ltd. is a leading vendor of Telecoms Equipment focused on Network Access and Interface Conversion Applications. The company's products are designed and manufactured in the UK and Metrodata has been a supplier to Telecoms Service Providers, Corporates and Governmental organisations worldwide since Major current product ranges include the 'MetroCONNECT' family of Managed Ethernet Extension and Demarcation solutions, 'NetTESTER' family of Embedded Enterprise Testing equipment and 'MetroWAVE' family of passive CWDM & DWDM Optical Multiplexers. About NetTESTER Metrodata currently offers two products within the NetTESTER family, the NT1003 and the NT1005. Developed to the same Carrier-quality criteria born of over 25 years of supply to the Telecoms Industry, and with a heritage from Metrodata's well established MetroCONNECT Carrier Ethernet Demarcation product line, the NetTESTER products are cost-effective and yet offer advanced custom-hardware based facilities for comprehensive test and monitoring for both Layer-2 (Ethernet Switched) and Layer-3 (IP Routed) network infrastructures. NetTESTER NT1003 Low-cost and yet feature-rich, the NT1003 has two Ethernet RJ45 ports and one flexible-media SFP port, each supporting service connections up to 1Gbps, each of which can be defined for LAN or WAN usage. Both 'auto-sensing' AC and DC PSU variants are available. The NT1003 includes Metrodata's custom 'MetroSAM' Service Assurance Module hardware, supporting both Layer-2 (Ethernet MAC addressed) and Layer-3 (IP addressed) Test-traffic generation, loop-back and analysis, enabling RFC2544 and/or ITU-T Y.1564 profile testing. The product additionally supports both ITU-T Y.1731 and TWAMP-lite (Controller and/or Responder) functionality for in-service performance monitoring. Full details and the product datasheet are available at: Page 9 of 10

11 NetTESTER NT1005 Advanced test unit featuring multiple LAN and/or WAN ports, for connection either via copper (RJ45) or fibre (SFP). The NT1005 includes Metrodata's 'MetroSAM' Service Assurance Module hardware, supporting a higher number of concurrent test links than the NT1003. The product is also available in a dual-redundant Power Supply (AC) variant, for 'always-on' embedded operation in critical network-central environments. Full details and the product datasheet are available at: Both products provide full Network Management Access, via local terminal and/or remote connection using Telnet/SSH, SNMP and Web-Browser applications. Rack-mounting kits are available for all variants. Metrodata Ltd. Laxton House, Eversley Way EGHAM, Surrey TW20 8RY U.K. +44 (0) sales@metrodata.co.uk Page 10 of 10