Printer FriendlyEmail Article Link

Spirent Network Emulator: What impairments can be used to emulate T1 network characteristics?

Environment/Versions
  • Spirent Network Emulator
Answer
The goal of this use case is to elicit a SW error from an application whose endpoints are connected via a T1 link,

Here's is a network map with main impairments inline and optional ones present but unlinked.

Below is a list of impairments that could be used to emulate a T1 link:
  • Bandwidth Throttle
    • set this at 1.54 mbps which is the limit of a T1 link
  • Delay Packet
    • set this to match the expected network delay (e.g., if ping is 58 msec then set this at 29 msecs since ping is a round trip latency measurement).
  • Packet Drop
    • some online references claiming up to 5% loss
    • so, perhaps starting with a large percentage of loss, say 10%, would be useful to elicit the SW's error.
    • Assuming that would cause problems (I would imagine most any application on earth would have problems with that amount of loss), you can apply a binary search until you reach the thresholod If where you see the application error.
  • Bit Error Corruption
    • This is corrupts N in M bits where N is typically small relative to M (e.g., 1 bit every 1,000,000).
    • I believe a bit error rate (BER) is included in the service level agreement that is “promised” by the service provider (see below as an item to ask your customer). So a good place to start is at the level in the SLA.
  • Packet Corruption
    • This will mangle bits within a packet and make them deliverable but then less or "unreadable" by the application.
    • The corruption is configured in terms of percentages and indicates the percentage of the packet that gets corrupted.
    • This one also corrupts every packet so if this impairment is going to be used, more thought in its use may be needed.
  • Reorder
    • If parts of the SW system are connected outside of the T1 link, then packets may be delivered out of order.
    • If the application uses TCP, then some of this is masked out by TCP’s windowing.
  • Jitter
    • If the SW system is very time sensitive the jitter impairment may be useful too.
Other notes that may be helpful:
  • Start with Packet Drop and then depending on what the application does, add some of the others as they make sense.
  • It would probably be a good idea to enable (i.e. toggle on) one impairment at a time. The exception would be the bandwidth throttle and delay packet. They should just be on all the time.
    • You can "enable/disable action" onto your SNE map to toggle each impairment on or off individually. In this way, you can build your map once and then interactively turn on or off impairments as needed.
  • A similar map should be setup in the other direction as well.
  • Employ a binary search method for each impairment to help more quickly determine if that impairment is relevant and if it is, at what point does it become problematic.
  • The SNE Operating Manual has good descriptions of the various impairments SNE provides. Perusing the TOC might give additional ideas.

 

Product : Impairment