[IOS-XE] "show ntp assocations" parser does not correctly summarize clock state

[ChristopherJHart]

The value of the clock_state.system_status.clock_state key in the IOS-XE show ntp associations has an incorrect value with some permutations of output.

For example, with the below output:

  address         ref clock       st   when   poll reach  delay  offset   disp
*~192.0.2.1       192.0.2.2        2    676   1024   377  0.117  -3.705  1.090
+~192.0.2.10      .GNSS.           1    811   1024   377  0.319  -3.649  1.053
 ~192.0.2.20      127.0.0.1       16    375   1024     0  0.000   0.000 15937.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Results in the below parsed data:

{
    "clock_state": {
        "system_status": {
            "associations_address": "192.0.2.1",
            "associations_local_mode": "client",
            "clock_offset": -3.705,
            "clock_refid": "192.0.2.2",
            "clock_state": "unsynchronized",
            "clock_stratum": 2,
            "root_delay": 0.117,
        },
    },
    "peer": {
        "192.0.2.1": {
            "local_mode": {
                "client": {
                    "configured": True,
                    "delay": 0.117,
                    "jitter": 1.09,
                    "local_mode": "client",
                    "mode": "synchronized",
                    "offset": -3.705,
                    "poll": 1024,
                    "reach": 377,
                    "receive_time": 676,
                    "refid": "192.0.2.2",
                    "remote": "192.0.2.1",
                    "stratum": 2,
                },
            },
        },
        "192.0.2.10": {
            "local_mode": {
                "client": {
                    "configured": True,
                    "delay": 0.319,
                    "jitter": 1.053,
                    "local_mode": "client",
                    "mode": "candidate",
                    "offset": -3.649,
                    "poll": 1024,
                    "reach": 377,
                    "receive_time": 811,
                    "refid": ".GNSS.",
                    "remote": "192.0.2.10",
                    "stratum": 1,
                },
            },
        },
        "192.0.2.20": {
            "local_mode": {
                "client": {
                    "configured": True,
                    "delay": 0.0,
                    "jitter": 15937.0,
                    "local_mode": "client",
                    "mode": "unsynchronized",
                    "offset": 0.0,
                    "poll": 1024,
                    "reach": 0,
                    "receive_time": 375,
                    "refid": "127.0.0.1",
                    "remote": "192.0.2.20",
                    "stratum": 16,
                },
            },
        },
    },
}

We can see that the value of the clock_state.system_status.clock_state indicates the device is unsychronized, even though it's synchronized.

[Harishv01]

Hi, I have reproduced the issue. Kindly give me some time to debug and fix it. Thank you.

[Harishv01]

case 1: if we consider the output:

*~192.0.2.1       192.0.2.2        2    676   1024   377  0.117  -3.705  1.090
+~192.0.2.10      .GNSS.           1    811   1024   377  0.319  -3.649  1.053

If the line *~192.0.2.1 192.0.2.2 2 676 1024 377 0.117 -3.705 1.090
executes first, it will mark "clock_state": "synchronized", and we will capture the other details(i.e associations_address, associations_local_mode, clock_offset, etc) as well. When the next line
+~192.0.2.10 .GNSS. 1 811 1024 377 0.319 -3.649 1.053

executes, the "clock_state" parameter is overridden, but other values remain unchanged(i.e associations_address, associations_local_mode, clock_offset, etc), resulting in "clock_state": "unsynchronized". other details as well as the clock state need to remain unchanged in this case. Is this behavior correct?

case 2: Now, if we consider the output:

+~192.0.2.10      .GNSS.           1    811   1024   377  0.319  -3.649  1.053
*~192.0.2.1       192.0.2.2        2    676   1024   377  0.117  -3.705  1.090

In this case, if the first line executes

+~192.0.2.10 .GNSS. 1 811 1024 377 0.319 -3.649 1.053

it will mark "clock_state": "unsynchronized", and it will capture candidate (+) related data like associations_address = 192.0.2.10 , associations_local_mode, clock_offset, etc.

When the next line
*~192.0.2.1 192.0.2.2 2 676 1024 377 0.117 -3.705 1.090
executes, not only the "clock_state" should be overridden, but all details like associations_address, associations_local_mode, clock_offset, etc., should also be updated/overridden right? Please let me know

[ChristopherJHart]

Hi @Harishv01,

Case 1's behavior is incorrect and is the root cause of this bug. Simply put, if any NTP peer has an asterisk, then the overall system's clock state should be marked as synchronized.

[Harishv01]

Hi @ChristopherJHart, I have raised the PR, and the expected output looks like below. Please let me know if everything looks good or not. Thank you!

expected_output = {
    "peer": {
        "192.0.2.1": {
            "local_mode": {
                "client": {
                    "remote": "192.0.2.1",
                    "configured": True,
                    "refid": "192.0.2.2",
                    "local_mode": "client",
                    "mode": "synchronized",
                    "stratum": 2,
                    "receive_time": 676,
                    "poll": 1024,
                    "reach": 377,
                    "delay": 0.117,
                    "offset": -3.705,
                    "jitter": 1.09
                }
            }
        },
        "192.0.2.10": {
            "local_mode": {
                "client": {
                    "remote": "192.0.2.10",
                    "configured": True,
                    "refid": ".GNSS.",
                    "local_mode": "client",
                    "mode": "candidate",
                    "stratum": 1,
                    "receive_time": 811,
                    "poll": 1024,
                    "reach": 377,
                    "delay": 0.319,
                    "offset": -3.649,
                    "jitter": 1.053
                }
            }
        },
        "192.0.2.20": {
            "local_mode": {
                "client": {
                    "remote": "192.0.2.20",
                    "configured": True,
                    "refid": "127.0.0.1",
                    "local_mode": "client",
                    "mode": "unsynchronized",
                    "stratum": 16,
                    "receive_time": 375,
                    "poll": 1024,
                    "reach": 0,
                    "delay": 0.0,
                    "offset": 0.0,
                    "jitter": 15937.0
                }
            }
        }
    },
    "clock_state": {
        "system_status": {
            "clock_state": "synchronized",
            "clock_stratum": 2,
            "associations_address": "192.0.2.1",
            "root_delay": 0.117,
            "clock_offset": -3.705,
            "clock_refid": "192.0.2.2",
            "associations_local_mode": "client"
        }
    }
}

[ChristopherJHart]

This looks good - thank you!

[Harishv01]

Hi, we have merged the PR and the fix will be available in the next version, i.e pyats 24.10. Hence, I am closing the issue. Thank you!