Troubleshoot TWAMP S bit is Set Incorrectly

Introduction

This document describes Active Measurement Protocol and the use of Synchronizing bit (S bit) for delay measurements. It describes the supportabilty of the S bit in IOS-XR platform.

   

Prerequisites

Requirements

Cisco recommends that you have basic knowledge of these topics:

• One-way Active Measurement Protocol (OWAMP)

• Two Way Active Measurement Protocol (TWAMP)

• Cisco ASR 9000 Series Aggregation Services Routers (ASR9000)

Components Used

The information in this document is based on Cisco ASR9000 devices - IOS-XR 5.3.4 release.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problem: TWAMP S bit is Set Incorrectly

You can use TWAMP to measure unidirectional and round-trip performance between two TWAMP-supported devices. When you test TWAMP-based Internet Protocol Service Level Agreement (IP SLA) between 3rd party's probe and CRS/ASR9000 devices which runs on IOS-XR 5.3.4, TWAMP Server sets the S bit to False. Therefore, one-way delay is not calculated by the probe device.

TWAMP Fundamental

The One-way Active Measurement Protocol (OWAMP), specified in RFC4656, provides a common protocol to measure one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements.

The Two Way Active Measurement Protocol (TWAMP) described in RFC5357, is a standards-based and highly effective performance monitoring process that expands upon the One-Way Active Measurement Protocol (OWAMP) specification defined in RFC-4656 with the addition of the performance measurement of round-trip and two-way metrics for IP based networks. TWAMP is a vendor-agnostic method to accurately measure unidirectional and round-trip performance between two TWAMP-supported endpoints.

As per RFC4656 (One-Way Active Measurement Protocol), the first bit S must be set, if the party which generates the timestamp has a clock that is synchronized to UTC through an external source. 

For example, the S bit must be set, if:

• Global Positioning System (GPS) hardware is used to indicate that it has acquired current position and time.
• Network Time Protocol (NTP) is used to indicate that it is synchronized to an external source, which includes stratum 0 source, etc).
• There is no notion of external synchronization for the time source, the S bit should not be set.

The Error Estimate specifies the estimate of the error and
   synchronization.  It has the following format:

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |S|Z|   Scale   |   Multiplier  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The TWAMP entities:

The TWAMP system consists of 4 logical entities:
    •    server - manages one or more TWAMP sessions and also configures per-session ports in the end-points
    •    session-reflector - reflects a measurement packet as soon as it receives a TWAMP test packet
    •    control-client - initiates the start and stop of TWAMP test sessions
    •    session-sender - instantiates the TWAMP test packets sent to the session reflector

The TWAMP protocols:

The TWAMP protocol includes three distinct message exchange categories includes:

• Connection set-up exchange

Messages establish a session connection between the Control-Client and the Server. First the identities of the communicated peers are established via a challenge response mechanism. The Server sends a randomly generated challenge, to which the Control-Client then sends a response by encrypting the challenge using a key derived from the shared secret. Once the identities are established, the next step negotiates a security mode that is binded for the subsequent TWAMP-Control commands as well as the TWAMP-Test stream packets.

Note: A server can accept connection requests from multiple control clients.

• TWAMP-control exchange

The TWAMP-Control protocol runs over TCP and is used to instantiate and control measurement sessions. The sequence of commands is as follows, but unlike, the connection setup exchanges, the TWAMP-Control commands can be sent multiple times. However, the messages cannot occur out of sequence although multiple request-session commands can be sent before a session-start command.
    ◦    Request-Session
    ◦    Start-Session
    ◦    Stop-Session

• TWAMP-test stream exchange

The TWAMP-Test runs over UDP and exchanges TWAMP-Test packets between Session-Sender and Session-Reflector. These packets include timestamp fields that contain the instant of packet egress and ingress. In addition, each packet includes an error-estimate that indicates the synchronization skew of the sender (session-sender or session-reflector) with an external time source (e.g.GPS or NTP). The packet also includes a Sequence Number.

TWAMP-Control and TWAMP-test stream, have three security modes: unauthenticated, authenticated, and encrypted.

Troubleshoot

Some platforms may rely on a certain configuration or deployment to provide hardware time stamp. In particular, the Cisco ASR9000 series routers need Precision Time Protocol (PTP) synchronization as a clock source. This solution may not be available in all user scenarios. To allow the use of other sources of time stamping (NTP clock source, through a daemon running on RouteProcessor (RP)) a new configuration of ipsla hw-timestamp disable is introduced to ignore the time stamp values provided by other platform dependent layers and revert back to the platform independent time stamps.

If the NTP clock sync is enabled and activated, use the hw-timestamp disable command in IP SLA configuration to disable hardware time stamp.

   
  

  ipsla
    hw-timestamp disable
    responder
      twamp
       timeout 100
      !
    !
    server twamp
      timer inactivity 100

Release Notes for Cisco ASR 9000 Series Aggregation Services Routers, Release 6.0.1 introduces a new TWAMP Accuracy Enhancement feature.

The TWAMP Accuracy Enhancement provides microsecond granularity in TWAMP measurements. This enhancement allows the collection of ingress and egress time stamps as closely as possible to the wire, to achieve more  accuracy.

You can upgrade the IOS XR release to 6.1.X and above to be able to use TWAMP Accuracy Enhancement feature and verify achievement of the desired behaviour.

You can perform these steps to troubleshoot the issue as well as the packet captures

1. Configure higher values for timeouts for twamp server and responder (for example 120s), so information doesn't expire too quickly before collection.
2. Since the debug needs to be enabled, ensure to configure the device to send debugging log messages to the logging buffer. The size of the logging buffer needs to be configured large enough to prevent the roll over of debugging messages during the test.
3. Esure that all packets exchanged between device and probe are captured (not only UDP probe packets, but also TCP for session establishment)
4. Collect the listed commands from ASR9000 or CRS device(s), depends where the tests is done:

Step 1. Before you start the test from probe, collect:

• terminal length 0
• show install active sum
• admin show platform
• admin show hw-module fpd location all
• show run
• ipsla twamp standards
• vshow ipsla twamp status
• show ntp status
• show ntp associations detail

Step 2.Enable all Twamp debugs on the device and then clear the log.

1. start the packet capture
2. start the test from probe 

Note: This does not produce too many outputs if it is the only twamp test that runs on probe.

Step 3.Collect these commands after test finished

• show log
• show ipsla twamp connection detail
• show ipsla twamp connection requests
• show ipsla twamp session
• show ipsla trace twamp all verbose
• show ipsla trace twamp initialization verbose    

Solution: S bit never implemented in IOS-XR

As per RFC 4656, If there is no notion of external synchronization for the time source, the bit should not be set. Therefore, The S bit is not implemented in IOS-XR platform.