Skip to content

vr_ftosv: add interface-alias regexp (ethernet1/1/X) and interface help - #3354

Open
lz-networks wants to merge 1 commit into
srl-labs:mainfrom
lz-networks:vr-ftosv-interface-regexp
Open

vr_ftosv: add interface-alias regexp (ethernet1/1/X) and interface help#3354
lz-networks wants to merge 1 commit into
srl-labs:mainfrom
lz-networks:vr-ftosv-interface-regexp

Conversation

@lz-networks

Copy link
Copy Markdown

Fixes #3352 (follow-up to the maintainer's go-ahead there).

What

Adds InterfaceRegexp, InterfaceOffset, and InterfaceHelp to the vr_ftosv node, following the existing vr-kind pattern (vr_aoscx, vr_n9kv):

InterfaceRegexp = regexp.MustCompile(`(?:ethernet\s?)?1/1/(?P<port>\d+)`)
InterfaceOffset = 1
InterfaceHelp   = "ethernet1/1/X or 1/1/X (where X >= 1) or ethX (where X >= 1)"
  • Topology links can now use the names as OS10 renders them: ethernet1/1/X (running-config form), ethernet 1/1/X (CLI-accepted spaced form), or bare 1/1/X — all mapped onto ethX, while raw ethX names keep working unchanged.
  • Setting InterfaceHelp also fixes the second half of the issue: the CheckInterfaceName deploy error previously printed an empty pattern hint (... does not match the required interface patterns: ""); it now names the accepted forms.
  • Unit test added (vr-ftosv_test.go), modeled on vr_aoscx's: alias forms ethernet1/1/1, ethernet 1/1/3, 1/1/5 map to eth1/eth3/eth5; raw ethN passes through.
  • Kind doc (docs/manual/kinds/vr-ftosv.md) updated to the same "Interface naming" structure the sibling vr kinds use.

Why offset 1 / why this mapping

Validated on real vrnetlab-built OS10 images (10.6.1.1.67 and 10.5.6.14, S5248F personality) while onboarding the kind on our platform: with links declared eth1↔eth1, eth2↔eth2, both switches see each other via LLDP on ethernet1/1/1/ethernet1/1/2 and form OSPF FULL adjacencies on ethernet1/1/1 — i.e. ethN ↔ ethernet1/1/N is 1:1 in declaration order, so port − 1 + FirstDataIfIndex is the correct index calculation. The empty-pattern error reproduced exactly as described in the issue whenever ethernet1/1/N endpoint names were used pre-patch.

Test

$ go test -v ./nodes/vr_ftosv/...
=== RUN   TestFtosvInterfaceParsing
=== RUN   TestFtosvInterfaceParsing/alias-parse
=== RUN   TestFtosvInterfaceParsing/original-parse
--- PASS: TestFtosvInterfaceParsing (0.00s)
    --- PASS: TestFtosvInterfaceParsing/alias-parse (0.00s)
    --- PASS: TestFtosvInterfaceParsing/original-parse (0.00s)
PASS
ok      github.com/srl-labs/containerlab/nodes/vr_ftosv 0.020s

go vet and golangci-lint run (v2.12, repo config) report 0 issues on the package.

🤖 Generated with Claude Code

Add InterfaceRegexp/InterfaceOffset/InterfaceHelp to the vr_ftosv node,
following the existing vr-kind pattern (vr_aoscx, vr_n9kv), so topology
links can use CLI-style names (ethernet1/1/X, ethernet 1/1/X, 1/1/X)
which map onto ethX. Setting InterfaceHelp also fixes the previously
empty pattern hint in the CheckInterfaceName deploy error.

Fixes srl-labs#3352

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

vr_ftosv: no interface-alias regexp — alias link names fail deploy with an empty-pattern error

1 participant