ddclient does currently not release anymore, see https://github.com/ddclient/ddclient/issues/302 , some of the integrations are already outdated in the current release like cloudflare which does not support API tokens - only the unprotected global key which grants access to everything.

I just want to add that my ISP is dropping dual stack in next few months and at the end of 2021 all users will only have IPV6 networking capabilities.
For thoose who still require IPV4 traffic it will be "tunneled" via MAP-T.

As I understand it a part of zebra, not specified to any protocol.
Maybe I'm wrong and we don't need it.

PR https://github.com/vyos/vyatta-cfg-system/pull/148

Why move the protocol specific route map to a new CLI node? This makes no sense to me.

A similar problem, only for ipv4 https://phabricator.vyos.net/T1053
As we can see ipv6 address before normalization without prefix
DEBUG: 2001:db8::191 before normalize
https://github.com/vyos/vyatta-cfg-system/blob/165e56e88763c40f13e6ef77f5df1c888fdfb899/scripts/vyatta-address#L38

@c-po Nope,

vyos@r6-roll:~$ sudo ip -d link show | grep vtun -A 5
5: vtun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 100
    link/none  promiscuity 0 minmtu 68 maxmtu 65535 
    tun type tun pi off vnet_hdr off persist off addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

@c-po
I propose to add "set routing-options x.x.x.x"
And also migrate protocols xxx route-map

set protocols bgp 65001 route-map RMAP
set protocols bgp|ospf|isis route-map RMAP

Does not reproducing on eve-ng.

Confirmed on VyOS 1.3-rolling-202105011026

This is still reproducible in the FRR master branch, so I've filed an issue: https://github.com/FRRouting/frr/issues/8695

Is the IP address probably listed in

you have an idea how the VyOS CLI commands should look like?

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

Tested on 1.4-rolling-202105170417 works correct. Propose to backport this to 1.3

There are two separate issues in this task: quoting of hw-id values (resolved in Sagitta/Equuleus); re-ordering of interfaces with respect to hw-id (Open).

@wsapplegate I create a PR for it https://github.com/vyos/vyos-1x/pull/847
Can you describe how to test/check it? I'm not familiar with that dns format. I tried zone with dot and without. Not sure how to check/test it.

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

@rizkidtn I don't understand exactly what wrong with the community?
Customers sent you routes, with blackhole community, on the router you mark match this community and set next hop "blackhole" IP address.

My expectation is that you can configure MTU 1500 at a GRETAP device to ensure same mtu at bridge. This solves a lot of problems caused by mixing host with different MTU size.
Larger frames that exceed pmtu and have df = 1 are fragmented and send to the gretap endpoint. Thus, underlay MTU has no impact of the communitcation between two hosts that are bridged via GRETAP and communicate with MTU 1500.

@ernstjo what you mean by "too old"? I think it's fairly new (5.10):

I think I found a way to reproduce it:

• rename an interface that was previously included in ospfv3 configuration and then remove it in the same commit from ospfv3 in the same commit.
• get an error that interface is not found. I think that at this stage the configuration is applied only partially
• after that error configuration in frr and vyos goes out of sync and never unsynchronized unless forced (or by lucky accident :-)

I don't fully understand your scheme
What interrelation between arp and tcp policy?

show conf com | match ospfv3

Copy configuration.
Delete protocols ospfv3
commit
re-add ospf config.