Works correct for q, but still show backtrace by Ctrl+C

:Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/ppp-server-ctrl.py", line 74, in <module>
    main()
  File "/usr/libexec/vyos/op_mode/ppp-server-ctrl.py", line 63, in main
    print(output)
KeyboardInterrupt

Lets change except BrokenPipeError: to except:

I am not sure why these extra options are parsed to begin with. My view is Vyos gives the possibility to write extra config file elements because it is not yet supported by the Vyos system configuration. Therefore it should be up to the user to write the correct data as it was in the past.
There should be absolutely no parsing whatsoever and options must be passed through the file unchanged.

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

Implemented in VyOS 1.4

Implemented in VyOS 1.4 rolling

Example config: https://github.com/vyos/vyos-1x/blob/current/smoketest/configs/vrf-ospf

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

Example configurations:

I'm curious, I did a little research on Tacacs +, and I'm not sure what you want the certification service to do for you? SSH certification or?

@svd135 please retest with the latest 1.4 rolling or 1.3 beta version. The issue should be corrected.

Also CUMULUS has a nice looking package

A migration script is available from 1.3 onwards.