Also regarding bridging: the current VTunIf says vtun is bridgeable. I doubt bridging a tun interface is wanted as that's a purely L3 tunnel. As the bridge member config syntax places the members under the bridge interface, the bridge interface determines if a interface is bridgeable by looking at its class definition. Thus to make openvpn in tun mode not bridgeable and tap mode bridgeable, those would need to be 2 different classes with different interface names ('vtun' and 'vtap'?). A hackish way is possible by making the bridge code check the openvpn config directly, but I highly dislike hackish solutions. Even T2241 was a 'hackish' solution that was necessary due to a previous bridge syntax migration without thinking about the consequences of it (moving the bridge member config under the bridge code makes syntactical sense, but it requires hackish workarounds like T2241 with the curernt way the config system operates)

Looking at the above errors:

Indeed, I didn't test client mode with the IPv6 patch, I assumed openvpn would use 'proto' for the listening socket only and not for the client socket (since it could detect which family the remote-host address is, it could select the correct socket, but it honors the 'proto' in the config) so my assumption was wrong. I appreciate the help.

@lawrencepan your configuration not committed because,

1. "route-reflector-client" can be used only when remote-as and local-as are equal

Try to check your commit.
You wiil see

PR https://github.com/vyos/vyatta-cfg-quagga/pull/49

Here comes some suggestions from my part :)

As required by the DHCPv6 PD function, the IPv6 part seems to be migrated from ISC DHCPv6 to wide-dhcpv6. According to your error log analysis, dhcp6c@eth0 Start failed.

Strange, I didn't test this problem again, but according to the T2449 problem I submitted before, DHCPv6 of IPv6 can get the address and route normally (the route depends on SLAAC). Isn't it ok now?

@jack9603301 As I already stated in the first comment in T2510 and in T421, this is not configuring DHCPv6-PD.

Where do you configure DHCPv6 PD?

@jack9603301 As stated a couple of times above, please see T2510 for my configuration.

@dsummers How is it possible, please give a configuration to facilitate others to check (this is a good habit)

Fwiw, I found that the scripts that run "pass into to /usr/sbin/ip" , but the ip command is actually at /sbin/ip.

@gadams Thanks for your reply.

In T2339#65130, @danielpo wrote:

Hi,

This bug exists for remote-host as well.

proposing fix:
https://github.com/vyos/vyos-1x/pull/443

@jjakob any idea?

I do not like this behavior as the config states the interface is "not disabled" but from an OS point of view it is - this is inconsistent and thus simply wrong.

Main reason would be I guess this error:

Jun  4 16:39:55 LR1 openvpn-vtun1[21166]: Could not determine IPv4/IPv6 protocol
Jun  4 16:39:55 LR1 openvpn-vtun1[21166]: SIGUSR1[soft,init_instance] received, process restarting

One more question/proposition.
Before ethX is added to the bond its IP addresses are being removed (that's good). Then, when ethX is removed from the bond it is being left as disabled. If we manually re-enable that interface the interfaces-ethernet.py script is run and it configures all its settings (including IPv6 link-local address). Therefore, maybe it is not that bad idea to leave the interface disabled when it leaves the bond. So, what if we just add a warning message to inform users that bond leaving interface will stay disabled until it is manually re-enabled.

PR for 1.2: https://github.com/vyos/vyatta-cfg-system/pull/124

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

1. PR for XML https://github.com/vyos/vyos-1x/pull/441

@dsummers I have been able to get the current nightly builds to work on Comcast Business, which is delivered via ethernet. In this particular case, there are some unfortunate gotchas to keep in mind, but no modification of VyOS is currently needed, at least in my case. Very cool!

When I'm done with the reboot dhcp6c@pppoe0 After the problem of possible startup failure, another strange problem was found, that is, every once in a while, the IPv6 route assigned by DHCPv6 PD will fail, and I can't find the reason yet. Can you help me find the reason?

Thanks for picking up this task. I think it is a duplicate of T2505.

Is this new DHCPv6-PD feature supposed to be working on Ethernet interfaces?

Strangely, I found that under my use case dhcp6c@pppoe0 The prefix obtained cannot be routed the next day.

It should not be too hard to convert the current parser to read.
https://gist.github.com/thomas-mangin/17a450a3e26a4cc41902475c0a1dfe5f

@jjakob you are right, there is no shell integration and this is using the python promt-toolkit library to handle input/output.

A significant part of the old config system is the bash-completion integration as well. I assume this is not integrated with bash but is a separate console that you start and takes over all stdin/stdout? Is it possible to implement the same completion output as there is now?

Thank you for reporting this issue, it looks like that parser allows ranges of IP address (IP hyphen IP) but the parser does not. You could get around using CIDR notation but this indeed need looking into.

should help to go further in the testing, but it is still failing on set_state but I do not know why it should be done if the interface is managed by openvpn. The relevant code is:

Wide dhcp6c does not generate a lease file, so if we want this we need to switch back to dhclient which has other drawbacks.

No feedback received "in time". Closing after a year.

VyOS 1.2.5 uses FRR 7.3, VyOS 1.2.6 will come with FRR 7.3.1 and rolling already runs on FRR 7.3.1

I also can not reproduce this issue with 3GB of RAM and two one ipv4/ipv6 full feed and a half feed. Closing this.