Problem is the constraint statement in https://github.com/vyos/vyos-1x/blob/current/interface-definitions/include/nat-address.xml.i where ipv4-range returns 0 instead of 1.

See T3051 "OpenVPN: multiple client routes do not work in server mode" for follow up

I want to have native-vlan and allowed-vlan

Perfect! Then please share your full OpenVPN config so the issue can be recreated and fixed properly.

Until version 1.3-rolling-202010280217 it still worked.
I have not changed the configuration...

Can you please check if this used to work in older VyOS versions, e.g. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-202010151549-amd64.iso or share your config and a network diagram.

Sure, no worries. We still have a *ton* of work on 7.3.1 to do so I'm sure we'll get to 7.5 in time :)

AWS hosted ntpd instances:
us-east-1 - 34.206.168.146 ipv6 2600:1f18:1632:5f01:3ee9:8db5:3a01:4018
eu-central-1 - 18.193.41.138 ipv6 2a05:d014:89b:f501:c695:7709:5430:16a1
ap-southeast-1 - 122.248.201.177 ipv6 2406:da18:cdf:e900:9420:6c3:f3:7abc

Neet to retest, the related task T2100

Not sure if it's relevant or not, but I think 7.5 was released....we might be able to just leapfrog 7.4 and go directly to 7.5 instead.

Put in a PR to add session hold time for static LDP neighbors.

now it works.
there seems to be another problem, the communication only works point to point, no routed traffic arrives on the opposite side.

Put in a PR to add TTL security for static LDP neighbors.

it sounds good to me.
I personally think the days with manually locking nic queues to cpu's is a bit outdated and we need something more dynamic.
After reading a bit on tuned i give my thumbs up

Hey, it seems that the big trouble now is the difference in the definition of the command line. If possible, I agree to conduct a survey to see your opinions.

@c-po i agree with using "native-vlan", but i dont agree on using "allowed-vlan".
"allowed-vlan" for me it dosn't actually describe that this vlan will be tagged on the port

Please try again with the next rolling release.

OK, I understand, PR has been updated

As I'm raised by A vendor starting with C and now switched to another vendor starting with A they both reference the function as native-vlan and allowed-vlan - this makes it easier for users which operate cross-platform.

set interfaces bridge br0 member interface eth0 allowed-vlan 2,4-9
set interfaces bridge br0 member interface eth0 native-vlan 101

The following writing methods can currently be used, such as:

I really like the idea of this interface and alwaysed watned to implement it - but I lacked of time, so first thank you @jack9603301 for picking this up.

It seems to be the same as the task list, but my basic realization is basically completed, see:

If two different vlan processing methods are not used for the same interface, then the two are not currently in conflict, unless the user sets vlan filter and eth0.10 on the same interface at the same time

I wonder what happens if I have a eth0.10 bridge member interface? Also what should happen when the user jas eth0 and eth1.10 bridge members? should this feature still work or is it exclusively only for native non vlan interfaces?

@runar The modified command is as follows:

@runar There is a question, that is, how to set the pvid flag according to this command format? Is the pvid flag automatically attached to the untagged option by default?

Hmm.. i have a few sugestions about the syntax.
The linux kernel allows the user to have different pvid vlan's on ingress and egress of a router port,.

• this is if you ask me not a common use case and i think we should merge the pvid(ingress) and untagged(egress) so that they will be ONE command..
• my second note is that the syntax shown above is quite verbose when creating a lot of vlan's and interfaces. consider creating 20 vlans on 5 ports, that will make a minimum of 100 lines of code in the config.

i would like to purpose a different syntax like this:

# Enable vlan filtering
set interfaces bridge br1 vlan

PR: https://github.com/vyos/vyos-1x/pull/594

Hello everyone

@c-po I think you may have referred to the wrong worksheet in your WiFi implementation? This task list is used to track and implement the VLAN filter of the bridge and the VLAN sub interface pairs of SVI

Yes! Turns out the following is what fixed it:
https://phabricator.vyos.net/T2980

@trae32566 Are there any updates for this task?

PR https://github.com/vyos/vyos-1x/pull/593
Fix validators for "neighbor update-source"

Duplicate of https://phabricator.vyos.net/T2465

It can be work with XFRM interfaces https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN#XFRM-interfaces-in-VRFs

@liljenstolpe good to have someone else interested in getting this sorted out!

PR https://github.com/vyos/vyos-1x/pull/591

@thomas-mangin They specifically ask folks to do the vendor cluster route.