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

Can you check the MAC address of the card not that the interface got mixed up in their naming?

Package was upgraded to PDNS 4.5 should be fixed - can you please retest with ANY release AFTER

• vyos-1.4-rolling-202110020217-amd64.iso
• vyos-1.3-beta-202110020342-amd64.iso

They key in the equuleus repository is a different one

VyOS 1.2 does:

Note that the set commands above have already mangled the name --- no_tag_node_value_mangle is there to preserve names as follows:

A few quick tests would suggest that this is specific to vrrp: though not exhaustive, of course, several examples of setting tag-node values in paths other than vrrp work as expected.