Did you read the original bug details? It clearly outlines how to replicate this with clear step-by-step instructions.

@juesor there is a difference in an IPv6 address you explicitly mention as 2606:ab00:abe1::2/127 and an IPv6 EUI64 address.

@iomart-network-team You don't need to change any file, but you can.
If you change something in the file, it not a bug.
It more seems like some typo in the file, which you generate.

This is still a problem, I have just upgraded from 1.2.6-S1 to 1.2.7-epa1 and had two conntrackd's running on the primary router.

This is now fixed in 1.2.7-epa1

So I have found a workaround/fix for this.

Proposed changes
Add hook/magic word string and write values in one string if word string in options is present

@juesor, please try my command; it doesn't have ipv6 or eui64 in it and I just double-checked that it works on 1.3.

Is it something with the eui64 in the syntax ?

This is a p2p link between vyos and a VM.

Ok so the IP assignment of the p2p on eth0 needs to be

FRR coder Donald Sharp kicked ass and fixed it here...

Assign it with set interfaces ethernet eth0 address 2006:ab00:abe1::2/127

Ok so I need to allocate a /127 to the eth interfaces.

VyOS 1.2.7-rc1 reports:

@Viacheslav . Ok this is not a problem, because we have a workaround with pseudo ethernet interfaces

set interfaces pseudo-ethernet peth1 source-interface 'eth1'
set service pppoe-server interface peth1 
set service pppoe-server interface eth1 vlan-id '50'
set service pppoe-server interface eth1 svlan 1000 vlan-range '1-4095'

Now all looks good and works properly, but need to add better help value

vyos@vyos# set service pppoe-server interface eth3 vlan-id 
Possible completions:
   <text>       VLAN monitor for the automatic creation of vlans (user per vlan)

To disable udev link_config redundancy call we need to delete /usr/lib/systemd/network/99-default.link

There are two versions that have been developed, reasonably feature complete, pending testing. One presents an OpenAPI schema of application/x-www-form-urlencoded (multipart forms); the other, application/json. The latter uses middleware (strictly speaking, a custom request and route class, instead of the Starlette middleware capability, although that may change) to intercept multipart requests, so as to remain backwards compatible.

https://github.com/vyos/vyos-1x/pull/777

https://github.com/jestabro/vyos-1x/tree/stdout_redirected

If I remember this change was accepted in to VyOS 1.3. There is confirmation of a configuration where we set IPv4 and IPv6 preferred source in the following thread:
https://phabricator.vyos.net/T1528

This totally breaks remote console access for me on 1.2.6, FWIW, so I consider it a fairly serious bug.

Any chance of motion on this?

@dmbaturin, don't forget to backport the other two PRs to 1.3:
https://github.com/vyos/vyatta-cfg-firewall/pull/20
https://github.com/vyos/vyos-1x/pull/730

Waiting on backport to 1.3.

@dmbaturin please cherry-pick this to equuleus. Successfully tested on VyOS-1.3-RC1

Thanks, @erkin --- I'm sure you can cherry-pick from 1.4 to 1.3; 'backporting' is not quite the right word, as it is development branch to stable branch. I really like this solution to the mess that was remote.py.

In T3409#89863, @runar wrote:

What about this? https://docs.vyos.io/en/latest/configuration/firewall/index.html?highlight=Mss#tcp-mss-clamping

I'll give backporting a try. It should be doable as long as Paramiko is in our reach. If not, I'll see if I can cobble together something to check for hostname resolution failure.

What about this? https://docs.vyos.io/en/latest/configuration/firewall/index.html?highlight=Mss#tcp-mss-clamping

Thanks for the feedback.

I've found out conf string with "--" works the same way like string without "--". Sorry to trouble you with this question.

Hi, how is the container support now