Cisco Nexus "show interface status" giving error when Tunnel interfaces are present

[vv0bbLeS]

TextFSM version == 2.1.0
ntc-templates version == 8.1.0
python version == 3.13.2

When running a show interface status on a Cisco Nexus switch, if there are Tunnel interfaces present, Cisco NXOS changes the column headers for those Tunnel interfaces in the same output. For example:

nexusswitch# show interface status

--------------------------------------------------------------------------------
Port             Name            Status    Vlan      Duplex  Speed   Type
--------------------------------------------------------------------------------
mgmt0            --              connected routed    full    a-1000  --         
Eth1/1           TEST1           connected routed    full    a-10G   10Gbase-SR 
Eth1/2           TEST2           connected trunk     full    a-10G   10Gbase-SR 
Eth1/3           TEST3           disabled  routed    auto    auto    10Gbase-SR
...
...

-------------------------------------------------------------------------------
Interface     Name               Status    Reason            Reason description          
-------------------------------------------------------------------------------
Tunnel13      Test Tun13         connected none               none                                                 
Tunnel40      Test Tun40         connected none               none                                                 
Tunnel41      Test Tun41         connected none               none                                                 
Tunnel42      Test Tun42         connected none               none  

This is causing the following error in the TextFSM module:

  File "C:\Users\player1\AppData\Local\Programs\Python\Python313\Lib\site-packages\textfsm\clitable.py", line 278, in ParseCmd
    self.table = self._ParseCmdItem(self.raw, template_file=template_files[0])
                 ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\player1\AppData\Local\Programs\Python\Python313\Lib\site-packages\textfsm\clitable.py", line 312, in _ParseCmdItem
    for record in fsm.ParseText(cmd_input):
                  ~~~~~~~~~~~~~^^^^^^^^^^^
  File "C:\Users\player1\AppData\Local\Programs\Python\Python313\Lib\site-packages\textfsm\parser.py", line 912, in ParseText
    self._CheckLine(line)
    ~~~~~~~~~~~~~~~^^^^^^
  File "C:\Users\player1\AppData\Local\Programs\Python\Python313\Lib\site-packages\textfsm\parser.py", line 961, in _CheckLine
    if self._Operations(rule, line):
       ~~~~~~~~~~~~~~~~^^^^^^^^^^^^
  File "C:\Users\player1\AppData\Local\Programs\Python\Python313\Lib\site-packages\textfsm\parser.py", line 1043, in _Operations
    raise TextFSMError(
    ...<2 lines>...
    )
textfsm.parser.TextFSMError: State Error raised. Rule Line: 14. Input Line: Interface     Name               Status    Reason            Reason description  

I have no idea why Cisco NXOS is changing column headers mid output (smh), and it looks like TextFSM is just as confused as I am. :(

[purvi1508]

This happens because NX-OS is returning two different table formats in the same command output (Ethernet interfaces and Tunnel interfaces with different headers).

The TextFSM template in ntc-templates expects a single consistent format, so when it encounters the second header:
Interface Name Status Reason ...
it doesn’t match any rule and hits the fallback ^. -> Error, which causes the failure.

Fix options:
Split the output and parse only the Ethernet section
Or relax the template (^. -> Start) to ignore unexpected lines

[vv0bbLeS]

I don't care - could we capture both the Ethernet interfaces and Tunnel interfaces, and just put them in 2 different areas in the output? like add a key for Ethernet and a key for Tunnels ?

[harro]

Two different tables - necessitates either:

1. A double wide table, with lots of partially populated columns, you can use a state transition between tables.
2. Two separate tables collected by running TextFSM twice using different templates.

[vv0bbLeS]

Hmm, so I will say I only use TextFSM via netmiko, so I don't use any raw TextFSM output myself. I would delegate to you all as owners how you think it would be best to handle this scenario. I'm not sure the implications of either of the two options above as it relates to netmiko. My ideal scenario is I can run show interface status on a Nexus switch, and if there are Tunnel interfaces present, I can get that information as well as the regular interface information.

[harro]

I think this is not the place for this request. There are no changes to TextFSM required. Issues with templates, when or how they are used, is a matter for the template library or tool that is making use of TextFSM.

…

On Tue, 21 Apr 2026, 7:59 am vv0bbLeS, ***@***.***> wrote: *vv0bbLeS* left a comment (google/textfsm#138) <#138 (comment)> Hmm, so I will say I only use TextFSM via netmiko, so I don't use any raw TextFSM output myself. I would delegate to you all as owners how you think it would be best to handle this scenario. I'm not sure the implications of either of the two options above as it relates to netmiko. My ideal scenario is I can run show interface status on a Nexus switch, and if there are Tunnel interfaces present, I can get that information as well as the regular interface information. — Reply to this email directly, view it on GitHub <#138?email_source=notifications&email_token=ADD2VEWUSGS2H7JZPOWWADL4W2MVDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRYGQ2TKMRRGE2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4284552114>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADD2VESFFS3IQC4SZ4WU67D4W2MVDAVCNFSM6AAAAACVB3B2E2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOBUGU2TEMJRGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[vv0bbLeS]

Fair enough. I could open an issue with the NTC Templates library for this.