Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.

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

@lucasec the reason for switching to the platform UUID instead of building up out own one was that it was not "unique".

I surveyed all the hardware I have to see what kind of UUIDs they report:

Implemented in

The DUID is presented in binary inside /var/lib/dhcpv6/dhcp6c_duid to read it back into ASCII use: hexdump -e '"%07.7_ax " 1/2 "%04x" " " 14/1 "%02x:" "\n"' /var/lib/dhcpv6/dhcp6c_duid

You are right @NikolayP but opening an entire subtree might be a bit of overkill.

Unfortunately reverting back the public key did not lead to any good results either.

not yet , we 've been trying with different CT but it's not solve the main problem . I understand that disabling conntrack is not possible because is used for nat.

Perhaps the command should be changed a bit
MSS is a property of the TCP protocol, not IP:

@dmbaturin Did you get my email? If not, please let me know and I will send it again

@RyVolodya can you check a new image and close this task if it was fixed?

Is any work around for this scenario ?

We usually communicate via https://vyos.slack.com

or matrix

sure I will just create a separate VM with a clean VyOS and the card - you got some sort of irc or discord to communicate?

Although a cluster ID might be helpful the real problem is that the routes are reflected to all peers – not just ones that are route reflector clients:

and It's the way to set on Vyos:

set protocols bgp <asn> parameters cluster-id <id>

there is a recommendation that if you use RR in the same hierarchy and avoid loop , we need to set 'cluster-id'

Any chance to get remote access to the system to debug this?

This creates routing loops on all BGP neighbors as they are all advertising the same routes

Neighbors that are not route-reflector-client should not receive learned routes, only routes that are explicitly set in the config. So in the example above, I would not expect to have multipath routes for 10.0.0.1 and 10.0.0.2, and I would not expect to see any route for 10.0.0.6

RR1 - BGP Peer / Route Reflector / 10.0.0.1
RR2 - BGP Peer / Route Reflector / 10.0.0.2
RR3 - BGP Peer / Route Reflector / 10.0.0.3

Problem solved and it was my mistake.

@francis It is not clear. Can you provide an example of configuration? What do you get and what do you expect?

Also tested 1.4-rolling-202110020217 and it exhibits the same issue

The question how to disable connection tracking.

yes, It is an issues related with the conntrack+ nat/vrf leak , I share something where the problem is clearer :

Suricata IPS with ipset

Hello Everyone,
I am testing 1.4 vrf leak from vrf x to default with NAT and is not working as expected. Outbound traffic is get forwarded to gateway NAT applied, but REPLY never forwarded to originator .

Yeah, that seems reasonable to me. I would prefer not add clutter to the system node if it can be avoided.

Should we expose a system-level DUID at all? If a user wants to customize it, they could always set it on a per-interface basis using the existing configuration node.

That seems fair, basically make the DUID generation deterministic. There is some defined structure to the DUID format, I think this would be a "type 3 DUID" per this document: https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/dhcp-unique-id-servers-clients-overview.html.

Can we close it @Viacheslav?

what about the following:

• Add a new system ipv6 duid CLI node which acts as the general DUID used on the system and renders /var/lib/dhcpv6/dhcp6c_duid, if not overwritten at the "interface" level set interfaces ethernet eth0 dhcpv6-options duid
• If system ipv6 duid is not configured, we "generate" the DUID using the eth0 MAC address automatically and store it in /var/lib/dhcpv6/dhcp6c_duid - thus no issue on image upgrades anymore