Yes, we need to try/except the apply section (the other should never fail but we could still catch errors to not leave the system in an unknown state) but when applying the reverse configuration (ie: invert effective and new and re-apply) one must then be careful if that fails too (we do not want a forever loop :p). The code already runs all the get_dict and all the verify first, so we will only apply if all is ok, but still issues could occur.

In T421#66055, @gadams wrote:

@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!

For anyone else who comes across this (I have talked to a couple folks outside of this task, as well), here are the gotchas, the second one of which is Comcast-specific:

• You currently need to enable getting an IPv6 address on the ethernet interface, even though that's technically not required other than by the config syntax. Using parameters-only will prevent it from working, since WIDE dhcp6c will interpret that to mean that you also don't want delegated adresses.

In my experience, this causes only some small issues, but not failure. I am drafting a proposal to fix it, but it's slightly more complex than I guessed.

• You need to know that while the Comcast cablemodem receives a /56 from the network to delegate to you, it carves off the first (sla-id 0) /64 of that for the link between it and your router, and then only delegates out of the highest (/56 4-bit sla-id f) /60 to your router. This is odd, and I don't know why they do it that way. So, you need to know that you'll be getting a /60 delegated to you, and that you should use 4-bit SLAs.

I had to figure this out by looking at the DHCPv6 conversation on the wire some time ago.

The config syntax could help a lot here, but this seems to be limited a bit by WIDE dhcp6c's conf options.

In any event, here's a working config I'm using (well, simplified, but still enough to make it work):

interfaces {
    ...
    ethernet eth3 {
        address 10.1.11.3/24
        address dhcpv6
        description OUTSIDE-v6
        dhcpv6-options {
            prefix-delegation {
                interface br0 {
                    address 1
                    sla-id 1
                    sla-len 4
                }
                interface eth2.4 {
                    address 1
                    sla-id 4
                    sla-len 4
                }
                interface eth2.6 {
                    address 1
                    sla-id 6
                    sla-len 4
                }
            }
        }
        ...
    }
    ....
}
...
    router-advert {
        interface br0 {
            name-server 2603:....
            name-server 2603:....
            prefix ::/64 {
                valid-lifetime 2592000
            }
        }
    .... and so on for the other interfaces ...

(The address 1 bits aren't strictly necessary, but I like my routers having easily recignizable addresses when I'm looking over traffic flows and routes and so on.)

Happy v6 surfing!

This could raise potential new bugs if a firmware file was missed out for whatever reason. Please open a new Task if this happened to you. Running it in @kroy's lab showed no problems so far.

Yes, we need to try/except the apply section (the other should never fail but we could still catch errors to not leave the system in an unknown state) but when applying the reverse configuration (ie: invert effective and new and re-apply) one must then be careful if that fails too (we do not want a forever loop :p). The code already runs all the get_dict and all the verify first, so we will only apply if all is ok, but still issues could occur.

@dsummers Obviously, this kind of output belongs to error report, prompt dhcp6c@eth0 Unable to start normally, measures should be taken to eliminate them. I once submitted a PR (not yet passed) that can try to restart when the service fails. The original intention is to recover from the failure when the first load fails after the restart (because some interfaces are not initialized). I don't know if this patch can help temporarily dhcp6c@eth0 Restart, and complete the startup normally after 10 seconds of failure. However, you can try it. In a word, you should take measures to eliminate such errors.

I did some tests and the only problem appears when adding a route-map to ipv6.

Yes, I've been seeing those messages.

@jjakob control-R should be implemented. It is a feature I use too and expect it - just did not think it was worth a demo 0.0 release - there is plenty to improve with the code in the branch - it surely has bugs -as I said POC :-)

https://github.com/vyos/vyos-1x/pull/444

@thomas-mangin that's great if the POC already has the above - I'm on board with making it the replacement for vbash in that case. I can live without word jumping and line deletion (for now) if it has tab completion and history (I will miss reverse history search a lot as it doesn't search just the beginning of the line but the whole line for the pattern, I'm assuming prompt-toolkit just searches the beginning?). I do need to test it when I get some time to see if anything is still missing.

About rollback, i'm wondering about a try:expect loop around apply() that will catch faults and trigger a rollback() to restore old files etc.
The rollback won't be a 100% abort, because vyatta-cfg would not rollback subsystems that have allready been configured.. but we will get a pr. Subsystem rollback and thats a start :) to get a full rollback wee need to change the backend or the executor in the backend.

generate should make a backup of the previous file before generating the new one. It will then make it possible to create the rollback as a file move and service reload.

@jjakob the code can be installed on a router (using my vyos update tool - after running vyos setup router )

To add my 2 cents:

Another possibility would be to modify the VTunIf's bridgeable parameter when creating it. That wouldn't require a different name for tap and all the config migration that comes with it, but I don't know if it's possible.

I also don't think we can find out whether a interface is tun or tap from the up/down script (no parameter or environment variable seems to tell it this) so it'd be good if tun and tap had different names due to this too. It would require migrating the name of existing interfaces (from vtun to vtap if tunnel type is tap) under interfaces openvpn, interfaces bridge member, service router-advert, firewall, nat, possibly other places as well.

What happens when one remote-host is IPv4 and one is IPv6? The proposed fix would leave the protocol as udp6 in that case and the error would still be there.

duplicate of T2468

Writing the config parsing, editing, committing and saving shouldn't be that hard.
Re-implementing completion with the current set of features would be very hard.

A workaround would be to simply call interfaces-ethernet.py from the bond script itself after it removes it from the bond.
The consequence of migrating bond member config from the interface node to the bond node, the same problem exists for bridges as well.

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.