The application process is pretty simple, you need to provide a few pieces of information:

PBKS

I can confirm that this is working.

It turns out that you know that a separate command is set to execute this layout setting, but I think the setting of your command is unreasonable because the user will mistakenly think that the following command can be used to set a specific layout:

PR https://github.com/vyos/vyos-1x/pull/590
I hope it will be helpful for many people from France. As for me it better solution then glue stickers with QWERTY keys =)

@Viacheslav vlans are working fine.

@phillipmcmahon Try to check if vlan works correctly without DHCP?
I met several nuances associated with vlans on ESXi.

I just tried replacing my vyos vlan DHCP scopes with a relay and passing back to my Windows 2019 server that is already set up and working as a DHCP server for my main LAN.

The support of keyboard layout has always been a relatively complex and user experience issue. I am in China, so I can only say that the country where I am is usually using American keyboard, while other countries such as Korea, Japan and so on, their keyboard layout is.... Keyboard layout should not be a major obstacle in most countries

Ok, let's review the situation when you install VyOS on bare metal and you have an only AZERTY keyboard. You press key A but in console, you see Q, you press Z on the console you see W.
Debian way, install console-data from https://packages.debian.org/sid/console-data and run sudo loadkeys fr

I think the default keyboard layout should be based on the American layout, and allow switching between custom keyboard layouts (in Debian, it should be possible to use dpkg-reconfigure for configuration)

To add the possibility to switch from default QWERTY keyboard type to AZERTY.

I don't understand. Do you mean that users should be allowed to set keyboard layout?

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

Not had a lot of time recently, but I have kind of been waiting for the configuration nodes to be ported to Python, so that this can be written in the new / modern way.

Another willing to test.

We need some expressions like

I see correct state "disabled"

Hi guys, I decided to revive this thread because it seems better than to create a new one, the subject seems to be the same. Im running a Vyos in a R420 with 16gb of ram (no errors in my tests while preparing the machine for the Vyos) and 2 processors, and after some 30 days running flawlessly, it started failing partially. It started working fine again after a reboot. After some 5-7 days the same problem reoccurred. At the first time I managed to see some errors in its screens and they said basically:

which exact VyOS version are you using? Delegating from one interface to many should be doable and can be configured on the latest rolling version.

Closing in favor of T2994 - please try tomorrows rolling release. If there are new bugs (which might always happen on rewrites) please file a new Bug report and I try to fix them ASAP.

In T1289#78883, @Viacheslav wrote:

Like this?

vyos@r4-roll# set policy route-map FJFFJJF rule 10 set ip-next-hop 
Possible completions:
   <x.x.x.x>    IP address

where x.x.x.x route to blackhole?

Like this?

In T1289#35636, @dmbaturin wrote:

The usual procedure is to create a route-map that sets the nexthop to a blackholed address if the advertisment has a specific community string set.
So when a customer advertises an address (rather a /32 network) to you with that string set, it automatically ends up blackholed.

Do you just want a shortcut for that, or you are having issues with community string-based approach?

This logic does not allow for the complete removal of the protocol.
https://github.com/vyos/vyatta-cfg-quagga/blob/32cbb1e5059c6c27449b7013f790aff1c50a9831/templates/protocols/ospf/passive-interface/node.def#L29-L35

@Azayaka do you mean import routes to a specific table? T3032
Can you check it with the next rolling release?

@rizkidtn Update, please your request. Is the community works for you for blackholing?

I found some interesting information, it seems that inbound/outbound port mirroring can be achieved

PR https://github.com/vyos/vyatta-cfg-quagga/pull/56

set interfaces ethernet eth1 ipv6 address no-default-link-local is the right command, yes

Bug ;) will be fixed soon

Yes, but iptables tee seems to support packet copy of various rules

Do you mean that?

set interfaces ethernet eth1 mirror

1. Not all interfaces can be used as "update-source"

Missed "vti | dum | lo" etc.
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/protocols-bgp.xml.in#L639

PR https://github.com/vyos/vyos-1x/pull/587
Fix the FRR template for new bgp implementation.

Pull request is up: https://github.com/vyos/vyos-1x/pull/586

How to do it?

You actually can when setting ipv6 disable-link-local addressing on the particular interface.

The root cause for this is the sha256 checksum file itself. It contains the hash and the filename. When running sha256 --check during the upgrade it expects the "real" filename when calculating and verifying the hash. The real filename differs when using the vyos-rolling-latest.iso symlink on the webserver as it will tell the running VyOS installation a different filename and the validation fails. This is now fixed by not depending on the filename when verifying the has. We simply calculate the hash of the downloaded file and compare it to the hash we saved inside the checksum file and totally ignore the filename itself.

I have tested both SSTP and L2TP and it works as expected - thank you for this addition!

Put in a PR to separate hello/hold timers for IPv4 and IPv6. Added IPv6 timers.

I will check it tomorrow and verify operation. Thank you!

Fixed

vyos@r4-roll# run show version

@klase Check these options in the next rolling release (after 20201027)