staticd: in route config, reject keywords as ifname

[mjstapp]

Reject cli keywords from the various 'ip route' configs if the vty code interprets them as interface names; some examples are "tag", "label", "color". Here's an example:

mjs-ubu-24-arm(config)# ip route 10.1.1.1/32 2.2.2.22 tag
% Invalid interface name tag
mjs-ubu-24-arm(config)# ip route 10.1.1.1/32 2.2.2.22 tag 15
mjs-ubu-24-arm(config)# do sho runn
Building configuration...

Current configuration:
!
frr version 10.6-dev-DEV
frr defaults traditional
hostname mjs-ubu-24-arm
!
ip route 10.1.1.1/32 2.2.2.22 tag 15
!
end
mjs-ubu-24-arm(config)#

[donaldsharp]

I think we need to add this to the staticd documentation.

[choppsv1]

This seems a bit fragile given these are all coming from inside DEFPY's defined elsewhere in this file. I'm curious if @eqvinox can take a look and see if there's some way we can leverage the cli parsing logic to disallow these automatically from the CLI command definition.

If I understand correctly this is coming from defs that look like:

   ...
   <INTERFACE|Null0>
   [{tag (1-4294967295)
    |(1-255)$distance
    |vrf NAME
   ...

I'm wondering if the CLI parser can automatically handle this.

BTW, is vrf foobar actually accepted as well? From my read here it's allowing tag NUM b/c tag is consumed by INTERFACE and then the number is consumed by (1-255)$distance, but there's no generic WORD in that follow on selection so I would expect vrf foobar to fail to parse. If that logic holds I think the only keywords that will trigger this bug are ones followed by a number from 1 to 255, as it's the (1-255)$distance atom that's causing us all the pain. If distance had had a keyword like distance i don't think we'd have this issue. :)

[mjstapp]

yes, the 'vrf XXX' tokens work - the matching is willing to use the more-specific match on the keyword 'vrf' followed by another word. but the lower-level match that would accept 'vrf' as an interface name will be rejected.

as you say, it's brittle to have to encode the ambiguous keywords, and it would be better to have an explicit "ifname YYY" instead of the positional matching. let's all try to squash examples like this as we review cli change proposals going forward...?

[choppsv1]

@eqvinox any way to have the CLI parser deal with this?

[mjstapp]

rebased to newer master

[mjstapp]

yes, sure, I've pushed a small doc update too.

I think we need to add this to the staticd documentation.

[mjstapp]

rebased to newer master