We are trying to set up testing guidelines for equipment (card swipe terminals) owned and/or leased to our customers that will connect to us via dial-up (T1), host-to-host (Frame) and the Internet. Are there any "best" practices that should be looked at? I'm combing through my Cisco material to find their checklist, but so far, I've had no luck.

    Requires Free Membership to View

    Login

Best practices for end-to-end testing (that scale well) haven't really been well developed yet. That is because there aren't that many viable options - most testing methodologies are either not end-to-end or require remote agents or hardware solutions at both end (and thus don't scale well).

Your constraints appear to be:

  1. no (or low) dependence on or knowledge of specific network path
  2. scalable to many devices/paths
    1. low effort to test
    2. low cost to instrument each end host
    3. rapid testing
  3. no (or low) new requirements for end host

Before continuing, allow me to define a concept since the language in this area is not well defined. The key words are "end-to-end" and "characterization" or "view".

"End-to-end" specifies a network path from one host to another that may include a wide variety of other devices and media. The nature of "end-to-end" doesn't essentially change though if those devices or media change. The idea of end-to-end is established at a particular network Layer such as Layer 3 (IP) or Layer 2 (Frame).

"Characterization" or "view" defines an attribution of the end-to-end path. A simple example is "connectivity" ? we are all familiar with the characterization of "connected", particularly in terms of the "view" that a well-known tool, ping, provides. More complex characterizations are possible in terms of things like

  • maximum achievable bandwidth
  • propagation delay
  • jitter
  • packet loss

    Best practices should be:

  • rely on an end-to-end characterization of network path
  • use consistent minimum characterization profiles across paths to all devices
  • pre- and post-qualify the path (if possible) when making changes or installations
  • establish a minimum number of independent tests that should be performed relative to the requirements of the implementation
  • monitor the paths on a regular, on-going basis from a critical central point (or multiple points as needed)

    So, in a very simple world, that might mean that you use connectivity as your characterization, ping as your tool, and a script to execute it as a cron job. In a more complex world (like the one you live in), you may have more stringent criteria, and require more sophisticated tools (e.g. appareNet or remote SNMP-based systems like MRTG) to monitor the paths for preferred characterizations.

    This is an area where there is much work yet to be done. I hope this helps.

    This was first published in May 2003

    • Join the conversationComment

    Share
    Comments

      Results

      Contribute to the conversation

      All fields are required. Comments will appear at the bottom of the article.
      Back to top