update 'cisco_ios_show_vrf.texfsm' to parse a vrf with no interfaces

[dpnetca]

update 'cisco_ios_show_vrf.texfsm' to parse a vrf with no interfaces

ISSUE TYPE

• Bugfix Pull Request

COMPONENT

cisco_ios_show_vrf.texfsm

SUMMARY

given the following configuration the eggs vrf is not parsed.

R1#show vrf
  Name                             Default RD            Protocols   Interfaces
  OOB-MGMT                         <not set>             ipv4        Gi0/3
  bacon                            <not set>             ipv4        Gi0/1
                                                                     Gi0/2
  eggs                             <not set>             ipv4        
R1#

Added additional line to the textfsm template to account for this condition

[dpnetca]

Sorry, bit more testing and found another case.
1> if protocol is not set and no interface is assigned VRF will not be parsed
2> if protocol is not set and an interface is assigned the rule I added will parse the VRF, but will set the protocol as the interface
in other words:

  Name                             Default RD            Protocols   Interfaces
  ham                              <not set>                         Gi0/0

wil parse to:
{'name': 'ham', 'default_rd': '<not set>', 'protocols': 'Gi0/0', 'interfaces': []}

Working around this scenario requires a few more changes. I think protocols in Cisco IOS may always be one of four options, either blank if nothing is set, 'ipv4' 'ipv6' or 'ipv4,ipv6'. In all ios devices I currently have in my lab that us the case, but would need a bit more research to validate that is true in all relevant versions.

assuming that is true could change the match condition on PROTOCOLS to be more specific:
Value PROTOCOLS (ipv\S+)
and add two more lines under Start_record to match the case when protocol is not set

  ^\s+${NAME}\s+${DEFAULT_RD}\s+${INTERFACES}
  ^\s+${NAME}\s+${DEFAULT_RD}

I am a bit more cautious about changing the protocol match and unintentionally breaking something. thoughts?

[itdependsnetworks]

Look at the readme, especially on the testing. You will need to update tests, and there will be regression testing on it.

[FragmentedPacket]

@dpnetca To Ken's point, you should have some confidence that it doesn't break existing functionality by it passing all tests as it would tell you if anything has regressed.

Do you want to just get this patch through and open another one for the other use case?