Page MenuHomeVyOS Platform
Create Task
Maniphest T2629

VXLAN interfaces don't actually allow you to configure most settings
Closed, ResolvedPublicBUG
Actions

Description

Pull Request: https://github.com/vyos/vyos-1x/pull/468

The configuration option "source-interface" maps to "src_interface" on the command line which is invalid, it should map to "dev".

The configuration option "source-address" forces the "nolearning" flag, which will break most switches with hardware vtep features. If we want to offer this flag, it should have it's own configuration.

Setting "remote" and "source-address" results in only "remote" being applied, even though "source-address" saves to the configuration.

Erroring out on "group" / "src_interfaces" should only happen when one of them is configured, not when the general configuration is incomplete. Otherwise the error message is rather cryptic.

Details

Difficulty level
Easy (less than an hour)
Version
1.3-rolling-202006221608
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change
Issue type
Bug (incorrect behavior)

Event Timeline

SIN3R6Y created this task.Jun 22 2020, 7:06 PM
SIN3R6Y updated the task description. (Show Details)Jun 22 2020, 7:25 PM
SIN3R6Y added a comment.Jun 22 2020, 7:38 PM

Thinking on this, should ("source-address" / "remote") and ("group" / "source-interface") be mutually exclusive? I cant think of any reason you would want both set to be setup on the same interface, I'm not even sure you can have both. Usually ("source-address" / "remote") would be used for unicast setups, and ("group" / "source-interface") for multicast. Seems like an either or, but not both, setup would be ideal.

Granted this may break existing configurations if users attempted to work around the issues i already laid out.

thomas-mangin added a subscriber: thomas-mangin.Jun 23 2020, 7:20 AM

Breaking user existing configs should be a no-no. If the options can be used that way under Linux, then we should not restrict it if it is not invalid. If we intend to prevent it then we would need a way to warn users clearly and we have no framework for this ATM.

pasik added a subscriber: pasik.Jun 23 2020, 7:34 AM
Viacheslav added a subscriber: Viacheslav.Jun 23 2020, 10:58 AM
Viacheslav changed the task status from Open to Needs testing.Jan 19 2021, 8:33 AM
Viacheslav closed this task as Resolved.May 27 2021, 9:58 AM
Viacheslav claimed this task.
erkin set Issue type to Bug (incorrect behavior).Aug 29 2021, 2:12 PM
erkin removed a subscriber: Active contributors.
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.Nov 6 2021, 12:21 PM
syncer edited projects, added VyOS 1.3 Equuleus (1.3.0); removed VyOS 1.3 Equuleus.Aug 29 2022, 12:16 PM
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus (1.3.0) board.