VXLAN custom port number

[ipspace]

The VXLAN integration tests uncovered another gotcha: different devices use different VXLAN UDP port numbers.

Many devices support configurable VXLAN UDP port, some have baked-in RFC value (4789).

We should add a new global/node attribute vxlan.port to set the UDP port and a corresponding feature flag vxlan.port which can be:

• A boolean (True) if the device supports VXLAN port changes
• An int value if the device has a baked-in default that cannot be changed (example: ArubaCX)

The int value would allow a device that cannot change the default to participate in labs where the vxlan.port setting happens to be set to the correct value. Alternatively, we could use device quirks to catch that.

Any thoughts @ssasso @jbemmel?

[ssasso]

Couldn't we set all the device templates to force the configurable ones to use the RFC port? ;)

[jbemmel]

I don't see the use case for devices that use non-standard VXLAN ports. Either they conform to the standard, or we consider them as not supporting VXLAN, imho

@ipspace you are typically very conservative when it comes to adding more nerd knobs - I am curious why this particular case seems to have caused you to abandon that philosophy / your core principles? ;)

[ipspace]

I don't see the use case for devices that use non-standard VXLAN ports.

You mean SR Linux among others, right 🤪 Of all the devices for which we implemented VXLAN, only ArubaCX uses the RFC-specified UDP port out of the box (and Stefano changed the VXLAN port for VyOS)

https://tests.netlab.tools/_html/coverage.vxlan

Obviously we could decide and change the default setting on every device that supports it, or add a nerd knob.

@ipspace you are typically very conservative when it comes to adding more nerd knobs - I am curious why this particular case seems to have caused you to abandon that philosophy / your core principles? ;)

See above ;))

[jbemmel]

What I mean is from a netlab user perspective, I just don't see there would be many people who would want/need to run a lab with a non-standard VXLAN port.

I can see why that had to be made configurable on many platforms, since at the time the standards hadn't settled on a default yet. But nowadays, I think hardcoding 4789 in the templates is fine

[ipspace]

Seems like the rough consensus is "let's move to UDP port 4789". I'm OK with that, will fix the templates I feel responsible for ;), open issues for other templates, and rerun the integration tests.

[ipspace]

OK, I blundered :( Just checked and everyone is using port 4789 :(( VyOS also interoperates with FRR

I also found the Aruba SNAFU. They're using the lower 16 bits of the VNI parameter without complaining it's too high. Changed the integration test to use static VNI that's low enough :(

Apologize for wasting your time.