Fix new format of cisco_ios show cdp neigh detail

[Ardeck]

… options - and add tests

Summary

Update cisco_ios_show_cdp_neighbors_detail.textfsm to handle new format and many new fields

Changes

• Adjust TextFSM regex for
• Update ntc_templates/templates/index for correct mapping
• Add .raw and .yml test cases under tests/cisco_ios/show_cdp_neighbors_detail/

Motivation

Current template is missing many parameters.

Validation

• Ran poetry run invoke tests locally — all tests pass.
• Verified parsing against provided .raw samples.

Notes

Scope limited to Cisco IOS show cdp neighbors detail.

[mjbear]

@Ardeck
What version of IOS/IOS-XE led to format changes?

While not necessarily "bad", there is quite a bit of change here to the data structure. This non-backwards compatible nature of things constitutes a breaking change (example definition).

We want to also keep in mind to maintain naming parity with LLDP for example.

Admittedly I haven't combed through each piece of your PR yet.

There might be a middle ground where we can reduce the level of incompatibility (as we're a ways off from a major release where breaking changes could be included).

[Ardeck]

@Ardeck What version of IOS/IOS-XE led to format changes?

While not necessarily "bad", there is quite a bit of change here to the data structure. This non-backwards compatible nature of things constitutes a breaking change (example definition).

We want to also keep in mind to maintain naming parity with LLDP for example.

Admittedly I haven't combed through each piece of your PR yet.

There might be a middle ground where we can reduce the level of incompatibility (as we're a ways off from a major release where breaking changes could be included).

Hello,

I completely understand, I hesitated before touching it but after I started, I tried to get the most of it.
My main struggle was with the management IP incorrectly captured and the Version inside the NEIGHBOR_DESCRIPTION I had to further process when it can be done in one go.

A ) New Format, Values

• IPv6 was not clearly separated and captured
  I don't know if the old MGMT_address was capturing any IPv6 but in my tests it did not.

-TLV /Power Power is displayed differently, I did not find "Power Available TLV:"
but I guess power is a specific beast

• new fields are also available depending on the neighbors
  VTP,Duplex,Management IP ....

I am not sure in which version these change was made are the previous template is probably very old.

-Management address section was not captured

B) Values changed
MGMT_ADDRESS changed to MGMT_ADDRESS for two reasons :

1. it was not matching the management address field
2. I tried to follow the standardization, Common Capture Groups

It was creating conflicts as Interface IP and Management IP can be different cf. 4.raw
I am not sure how to name INTERFACE_IP, it is called Entries. It closely match the previous MGMT_ADDRESS.

But there is confusion between IPv4 and IPv6
to avoid breaking change.
Value INTERFACE_IP (\d+.\d+.\d+.\d+)
could be rolled back to
Value MGMT_ADDRESS (\d+.\d+.\d+.\d+|\w+.\w+.\w+)

Same the regex for the value can be preswerved to the old values
Value PLATFORM (.)
Value NEIGHBOR_INTERFACE (.)
Value LOCAL_INTERFACE (.*)
Value CAPABILITIES (.+?)

C) Value removed
Value NEIGHBOR_DESCRIPTION (.*$)

NEIGHBOR_DESCRIPTION is more problematic as I completely rewrote it for several reasons :

1. it is not a description, it is in the Version section
2. Many interesting fields can be recovered about the version details

[jvanderaa]

I think the rest of these are making sense on the names, we may have to go update some of the other templates as we get this one merged in.

I'm a little worried about the NEIGHBOR_DESCRIPTION getting broken down, will we need to be updating this template quite a bit as new devices that come online since it is all free form fields.

[jvanderaa]

I'd like to keep the MGMT_ADDRESS in lock step with LLDP neighbor outputs as well. So that these remain consistent across neighbor templates.

[Ardeck]

I'd like to keep the MGMT_ADDRESS in lock step with LLDP neighbor outputs as well. So that these remain consistent across neighbor templates.

I have reverted the breaking changes. At least the naming is not critical.

[mjbear]

I am not sure in which version these change was made are the previous template is probably very old.

@Ardeck
Ok, what version and platform/model did you notice the change?
I figure this would be an IOS-XE release?

My reason for asking is to see if I have access to hardware that demonstrates these new format changes.

Thank you for details!

[Ardeck]

I am not sure in which version these change was made are the previous template is probably very old.

@Ardeck Ok, what version and platform/model did you notice the change? I figure this would be an IOS-XE release?

My reason for asking is to see if I have access to hardware that demonstrates these new format changes.

Thank you for details!

I have mainly tested on IOS-XE version 17.6.5+, mainly various model of cat9K
I have also various catalyst platform, 2K, 3K, 4K, 6K.

There are also various neighbor, mostly Cisco other catalyst and Nexus but also other vendors.

[mjbear]

This isn't version information.

[mjbear]

Something seems a little off.

Plus, there are three capture groups with version in them.

• VTP_VERSION stands on its own, so no issue there
• There's SOFTWARE_VERSION and VERSION that are possibly duplicates
• The LLDP equivalent has capture group names with abbreviations (not sure how much normalization we'd do there -- depending on community preference)

[mjbear]

@Ardeck
I looked for a Nexus or NX-OS neighbor in the test data, but didn't find one.
Did I miss it?

[matt852]

Recommendation: Changes Suggested

Breaking Change: No

Thanks @Ardeck — this is a big usability upgrade for the CDP detail template, and the added fixtures cover a nice range of platforms. A few suggestions before merge:

• Fix the ,*s* typo in the second NewVersion software rule. It matches optional literal s characters where whitespace was intended — and it's the rule doing the actual software capture today. In ntc_templates/templates/cisco_ios_show_cdp_neighbors_detail.textfsm:

  -  ^\s*${SOFTWARE}\s*,*\s*${SOFTWARE_FAMILY}\s*,*s*[^,]*\bVersion\s*:?\s*${SOFTWARE_VERSION}\s*,*\s*.*$$
  +  ^\s*${SOFTWARE}\s*,*\s*${SOFTWARE_FAMILY}\s*,*\s*[^,]*\bVersion\s*:?\s*${SOFTWARE_VERSION}\s*,*\s*.*$$

• Remove the unreachable second ^Version rule in Start. It's identical to the rule above it, so TextFSM can never reach it:

     ^Version\s*:\s*$$ -> GetVersion
  -  ^Version\s*:\s*$$ -> NewVersion

• Rename INTERFACE_IPV6 to IPV6_ADDRESSES. The data model (docs/dev/data_model.md) standardizes IPV6_ADDRESSES for lists of IPv6 addresses. The Value declaration:

  -Value List INTERFACE_IPV6 ([0-9a-fA-F:]+)
  +Value List IPV6_ADDRESSES ([0-9a-fA-F:]+)

  The matching rule in ParseIP:

  -  ^\s*IPv6 address:\s*${INTERFACE_IPV6}\s*\(.*\)\s*$$
  +  ^\s*IPv6 address:\s*${IPV6_ADDRESSES}\s*\(.*\)\s*$$

  And in the fixtures:

  -    interface_ipv6: []
  +    ipv6_addresses: []

  Apply the same key rename to every other interface_ipv6: line in all five .yml files.

• Confirm VTP_VERSION should not be renamed to CDP_VERSION. I had this in the Claude review output but would like to confirm it is accurate before suggesting you change it: "The rule feeding it matches advertisement version: 2, which is the CDP protocol version the neighbor advertises — not anything VTP-related — so the current name will mislead consumers."

If this is accurate, the following changes are needed. Otherwise let me know and I'll update the model.

-Value VTP_VERSION (\d+)
+Value CDP_VERSION (\d+)

The matching rule in Start:

-  ^advertisement\s+version\s*:\s*${VTP_VERSION}\s*$$
+  ^advertisement\s+version\s*:\s*${CDP_VERSION}\s*$$

And rename every vtp_version: key to cdp_version: in all five .yml files.

• End the new states with ^. -> Error. Per docs/dev/dev_parser.md, each state should end with ^. -> Error so unaccounted-for output fails loudly instead of being silently swallowed (e.g. a record separator reached while still in ParseMgmtIP would currently eat the following record). Add as the last rule of ParseIP, NewVersion, ParseMgmtIP, and PwrAvail — for example in ParseIP:

     ^\s*Platform\s*:\s*${PLATFORM}\s*,\s*Capabilities\s*:\s*${CAPABILITIES}\s*$$ -> Start
  +  ^. -> Error

  (GetVersion doesn't need it since ${NEIGHBOR_DESCRIPTION} already matches every line.) This passes against all five of your fixtures as-is.

• SERIAL never captures in any fixture. The ^Device ID\s*:\s*${NEIGHBOR_NAME}\s*\(${SERIAL}\)\s*$$ rule isn't exercised — serial is empty in all 23 fixture rows. Could you add a raw sample with a Device ID: <name>(<serial>) neighbor (e.g. a Nexus peer), or drop the rule until real output is available?

• The software fields only populate for legacy two-line version headers. Because GetVersion consumes the first line of the version block as NEIGHBOR_DESCRIPTION, the modern single-line header (e.g. your 17.9.5 samples) never reaches the NewVersion software rules — software, software_family, and software_version come out empty for exactly the outputs this PR targets, and software_family is empty in every row. It's worth either restructuring so those fields populate consistently, or dropping them from this PR until they can be captured reliably.

Thanks!
(reviewed with Claude)