Repository navigation
cisco_nxos_show_interface fails on OTV Overlay interfaces #2348
Description
Device
cisco Nexus7700 C7706 (6 Slot) Chassis ("Supervisor Module-2")
version 8.4(6a)
--I cant take credit for the below. Cursor generated this and fixed it. I tested it and it appears to work.--
Error
State Error raised. Rule Line: 143. Input Line: 0 bytes 0 bits/sec 86 packets/sec
Rule 143 is the catch-all ^. -> Error.
Config Lines
Overlay1 is up
Description: overlay-interface
MTU 1400 bytes, BW 1000000 Kbit
Encapsulation OTV
Last link flapped 2y16w
Load-Interval is 5 minute (300 seconds)
RX
6160295128114 unicast packets 0 multicast packets
0 bytes 0 bits/sec 86 packets/sec
TX
3439642551394 unicast packets 0 multicast packets
2741972988123429 bytes 0 bits/sec 0 packets/sec
Description, MTU, Encapsulation, Last link flapped, Load-Interval, RX/TX, and the unicast/multicast line already match. The only missing line is:
bytes bits/sec packets/sec
Physical interfaces use 30 seconds input rate bits/sec, packets/sec, which the template already handles. Overlay does not print that format.
Fix: Add this unmatched rule above ^. -> Error:
^\s+\d+\s+bytes\s+\d+\s+bits/sec\s+\d+\s+packets/sec\s*$$
That lets parsing continue. It does not populate BANDWIDTH_INPUT_RATE / PACKET_INPUT_RATE / BANDWIDTH_OUTPUT_RATE / PACKET_OUTPUT_RATE. The same line appears under both RX and TX, so capturing both would need RX/TX states. Overlay still parses INTERFACE, LINK_STATUS, DESCRIPTION, MTU, ENCAPSULATION, and LAST_LINK_FLAPPED.
Activity
mjbear commentedon Aug 24, 2026
Your example fix matches the line without capturing -- that's one solution.
(another solution) If the data is useful and it was desired to capture the bandwidth and packets/sec, we'd have to add States. States would add some complexity and testing.
@Mikeg2881 Is the bytes/sec and packets/sec data useful to capture?
For the moment, I stuck with the simple solution for the first iteration on PR #2351 -- I can always modify the PR before it's merged.
Mikeg2881 commentedon Aug 24, 2026
When i run it on my test data i do got the below.
mjbear commentedon Aug 25, 2026
Yeah, many of the keys are empty since fewer of them show up on the OTV interface.
I'll take it that the bps or pps on the OTV interfaces aren't all that useful.
(Saves the hassle of adding addition States should that be the case.)
Thank you!
Mikeg2881 commentedon Aug 26, 2026
Agreed on bps and pps are not that useful (for me) but bytes/packets are
mjbear commentedon Aug 28, 2026
@Mikeg2881
It appears
bytesis not something captured currently because we're not capturing the digits here. Agreed?(Adding a new key/data point means being careful to add it to all sections. 🥴)
Input/output packets are captured, but
unicast packets(and multicast) are not.(If we capture ucast/mcast on OTV, it's going to be one of those situations we have to be careful to associate it with the correct name.)
Mikeg2881 commentedon Aug 28, 2026
I suppose i look at it like this. The existing parser was "breaking" the fix is applied and its not breaking anymore. That is a win. If we are to go and add more items and potentially break something else that would be bad. I don't think capturing that data is worth it. I cant see what value the number of packets really is, but that's just me.
mjbear commentedon Aug 28, 2026
👍
Introducing template bugs wouldn't be good, but changes have that risk.
The question in my mind "is there a need for the data?" (to make it worth capturing).
Before my message from over an hour ago, I started a little bit of planning and figure I may need to add three States. One to shift to when we have OTV encapsulation, then from OTV shift to RX State, shift from RX to TX State, and then back to Start state in case there are more interfaces. (We would probably want at least one interface after the Overlay/OTV to fully test.)
I'm sure I could solve it (though should we?), but I probably need to add capture groups since the counters on OTV don't identically match up with what we already have. (We don't currently capture bytes or unicast packets.)
Mikeg2881 commentedon Aug 29, 2026
Given otv is going away i feel its not worth the addition if there is risk of breaking other items.