Tested on 1.2-rolling-201910250117, the issue is solved.

Why not single source also the op-mode part into ifconfig.py?

This pull request rewrites all the functionality of ioctl.pm and lays the framework for the rest of Interface.pm

As this is merged into equuleus can we close this?

Let me merge it into equuleus branch

Ok, this is fixed already but I didn't notice because it is not yet merged in the Equuleus branch which I am running.

According to T1030 it is working as expected

It is currently impossible to update zones on cloudflare dns via ddclient because the generated configs for cloudflare are mising a zone=<domain.tld> directive.
I also note that the comment for each entry also says "DynDNS provider configuration" regardless of the provider used.

Attached

Whats the configuration you got on your side?

VyOS 1.2-rolling-201910210211 boots perfectly.

Thanks for the feedback - will backport to our LTS branch later on!

Just installed the latest rolling.
I tried the old conf, delete them, and reconfigure dns dynamic.
thanks @c-po , it's working fine now

You could check the latest rolling which have it

In T1030#46018, @c-po wrote:

@pvelati looks like that the zone statement is required for Cloudflare only. I did not find a documentation how it should look like. is it only and always the domain part of your dynamic dns entry? If thats the case it can be automatically rendered into the configuration.

@pvelati looks like that the zone statement is required for Cloudflare only. I did not find a documentation how it should look like. is it only and always the domain part of your dynamic dns entry? If thats the case it can be automatically rendered into the configuration.

I tried the new rolling iso VyOS 1.2-rolling-201910230349 but it doesn't work oob.
I see that you tweaked a bit the ddclient.conf file, but you need to add "zone=" in the conf in order to make it works.

Added your reccomended changes and auto create directories if they are non existent. Can you please check again?

ok, I've found a way to make it working.

I've tried the VyOS 1.2-rolling-201910220117 with integrated ddclient 3.9.0 and this conf:

vyos@vyos# show service dns dynamic 
 interface pppoe0 {
     service cloudflare {
         host-name test.mydomain.com
         login [email protected]
         password 000000mycfapikey00000000
     }
 }

but it doesn't work.

looks neat. I merged in in already. Can you add some explanation to https://github.com/vyos/vyos-documentation please.

Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg

Superseded by T1759

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

Please retest with upcoming rolling release from 20191022.

Thanks for feeding back. Please try the latest rolling ISO if it works for you.

@c-po I tried your 3.9.0 deb package. I installed with some dependencies (libdata-validate-ip-perl libnet-ipv6addr-perl libnet-netmask-perl libnetwork-ipv4addr-perl).
After that, I modified some config parameters in the dns dynamic section to trigger the update but it doesn't work oob.

https://github.com/vyos/vyos-1x/pull/149 merged. While I think the UP/DOWN status is a little brave. It leads users maybe to believe that the wg interface has really a up/down state.

For now, it has been decided not to support arm officially, due to lack of resources.

For now, it has been decided not to support arm officially, due to lack of resources.

Looks good first glance to me. Next rolling will have it included.

Can you please test installing this package and feedback to me?

@pvelati thanks for the update!

hi @c-po , I've tried installing the 3.8.3 version but it's not compatible with the new CloudFlare API v4. The only way to make ddclient working with cloudflare is using the 3.9.0.

Even better, looks like wimpunk is maintaining again and there is a fresh release https://github.com/ddclient/ddclient/releases 3.9.0

Debian Buster uses 3.8.3 https://packages.debian.org/buster/ddclient which could be considered as using a proper source tree.

@dmbaturin bump? I'd like to submit a PR for this issue, but would like some guidance regarded to my comment above.

Okay, thanks for the info.

It is true what @Viacheslav say, there is only possible to run one instance of bgp om a given router.. when using vrf's the bgp running inside the vrf is a subset of the main instance. to confirm, start vtysh and try to create multiple processes.. it will likly fail :)

We are a little confused.
As far as I know, Bgp instance on all router's platforms always one.
And it use socket with 179 tcp port.
VRF is working on same bgp instance, but support multiple autonomous system at once.

@jjakob @runar agreed, moved to T1748.

@runar at the current time this is true only one BGP instance is supported. But when we incorporate VRF one day which is definately on the roadmap this could change.

As for my understanding frr only supports a single bgp instance running at a time. But i've not verified thid completly.

What about upcoming VRF when we possibly have multiple bgp processes?

This is present in branches crux and current too, so adding tag for crux.
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f
https://github.com/vyos/vyos-1x/commit/6f954ab56768af9a07d8a1dc086f54ddefa58da7
https://github.com/vyos/vyos-1x/commit/5848a4d6095e6d7bc70e34e0b7b7e2c3d8e3303f