cisco_nxos_show_interface fails on OTV Overlay interfaces

[Mikeg2881]

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.

[mjbear]

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]

When i run it on my test data i do got the below.

    {
        "INTERFACE": "Overlay1",
        "LINK_STATUS": "up",
        "ADMIN_STATE": "",
        "HARDWARE_TYPE": "",
        "MAC_ADDRESS": "",
        "BIA": "",
        "DESCRIPTION": "overlay-interface",
        "IP_ADDRESS": "",
        "PREFIX_LENGTH": "",
        "MTU": "1400",
        "MODE": "",
        "DUPLEX": "",
        "SPEED": "",
        "INPUT_PACKETS": "",
        "OUTPUT_PACKETS": "",
        "INPUT_ERRORS": "",
        "OUTPUT_ERRORS": "",
        "BANDWIDTH": "",
        "DELAY": "",
        "ENCAPSULATION": "OTV",
        "LAST_LINK_FLAPPED": "00:12:27",
        "VLAN_ID": "",
        "PACKET_INPUT_RATE": "",
        "PACKET_OUTPUT_RATE": "",
        "BANDWIDTH_INPUT_RATE": "",
        "BANDWIDTH_OUTPUT_RATE": "",
        "MEDIA_TYPE": "",
        "SHORT_FRAME": "",
        "OVERRUN": "",
        "UNDERRUN": "",
        "IGNORED": "",
        "WATCHDOG": "",
        "BAD_ETYPE_DROP": "",
        "BAD_PROTO_DROP": "",
        "INTERFACE_DOWN_DROP": "",
        "DRIBBLE": "",
        "INPUT_DISCARDS": "",
        "RX_PAUSE": "",
        "STOMPED_CRC": "",
        "RX_JUMBO_PACKETS": "",
        "STORM_SUPPRESSION_BYTES": "",
        "RUNTS": "",
        "GIANTS": "",
        "CRC": "",
        "NO_BUFFER": "",
        "TX_JUMBO_PACKETS": "",
        "COLLISIONS": "",
        "DEFERRED": "",
        "LATE_COLLISIONS": "",
        "LOST_CARRIER": "",
        "NO_CARRIER": "",
        "BABBLE": "",
        "OUTPUT_DISCARDS": "",
        "TX_PAUSE": ""
    }

[mjbear]

When i run it on my test data i do got the below.

Yeah, many of the keys are empty since fewer of them show up on the OTV interface.

Is the bytes/sec and packets/sec data useful to capture?

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]

Agreed on bps and pps are not that useful (for me) but bytes/packets are

[mjbear]

Agreed on bps and pps are not that useful (for me) but bytes/packets are

@Mikeg2881

It appears bytes is 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]

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]

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.

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]

Given otv is going away i feel its not worth the addition if there is risk of breaking other items.