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

Hi c-po,

The same bug described there T2845

Submitted this PR: https://github.com/vyos/vyatta-cfg/pull/42

Not sure why we should check the primary ip address, but to fix it possible to change:

if is_subnet_connected(subnet, primary=False)

It was described there T3610 and requires more tests.

Acknowledged. Tested on 1.3.0-epa1

new uefi style