@Dmitry Thank you for correcting. I may have got it wrong

@c-po https://github.com/vyos/vyos-1x/pull/668

Why should this task be created in vyos manager

I think this may be related to the MAC bound to the device. You can modify the configuration of vyos to adjust the order

As for encrypted DNS, it should cover standard solutions rather than be limited to a certain service provider. The standard solutions are as follows (although in general, there may not be many people using encrypted recursive DNS)

Is there a way to support pmtu in interface configuration

@c-po Can we consider reviewing it again

@c-po PR:https://github.com/vyos/vyos-1x/pull/658

https://github.com/vyos/vyatta-cfg-system/pull/134

I want to know the behavior of the implementation when upgrading the vyos version

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

If your device supports virtualization, you can consider running both VyOS and cups servers in KVM (there are many open source projects that can do this, such as Proxmox Ve)

Why install the remote print sharing service on the router and use cups, you must install the printer driver on the cups server to make it work. VyOS is not a general server operating system, so you should install cups on a physical server or virtual server

Where possible, we can consider MBR+UEFI dual boot, which also exists in most distributions

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

@primoz Use the latest rolling version test the day after the merge is submitted

Consider integrating Snort

I mainly have 2 questions:

I mainly have 2 questions:

1. Using DPDK may cause low configuration hardware to fail to install vyos?
2. Is it possible to use DPDK and VPP to cause all services that depend on the system protocol stack to fail to discover the interface?

Maybe this implementation also has a dependency problem, I will fix it in the near future

Sorry, I have changed the repair implementation
PR: https://github.com/vyos/vyos-1x/pull/638

@c-po Please merge this PR, the problem will be fixed directly

I may have to change the configuration priority. Due to priority issues, the settings may fail

@primoz Can you contact me in Slack?

@primoz Delete the old one, create a new bridge after commit, and then commit. Can it work normally?

@c-po Does the deletion of the bridge occur after the new bridge is created or before?

OK, the latest PR can be tested. I just tested the basic functions and the effectiveness of the migration script. But I haven't submitted the PR of vyatta-cfg-system

In the latest PR implementation, eth0 will shake at the moment when the eth0 configuration is changed, but it seems to be restored immediately

Do you have any good fixes?

You mean, if you submit it in 2 steps and configure it separately, it works fine?

In the test topology, the same situation was found in the mirror test of pppoe0

I am a little doubtful whether this is in design, and whether there will be a short-term up to down to up conversion when the interface is modified.

Can I restart ping? Can be restored after restart

Please only allow native-vlan and allowed-vlan for ethernet and bond type of interfaces for the time beeing

Logically speaking, any interface that can be added as a member interface when setting the bridge interface should be fine. bridge vlan applies to any member interface, but I don’t know why it is sometimes possible and sometimes not. I need More information to determine the problem (since there is a situation that can be set successfully, and no abnormality is reported, then the setting should be successful, WLAN is not working because the WLAN bridge is set by hostapd)

I don't know what you mean?

Before that, should we consider completely migrating the vyos firewall implementation?

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

Do I only need to execute the following commands when I want to start ipv6?

As far as I know, you only need to work in the vyos-1x repo

Hi, guys, I found an interesting script in frrouter's github repo. In fact, this is purely because someone wrote a script and submitted the following bug report:

LiveCD is usually only used for temporary testing and installation, isn't it? Will using this restriction cause the normal use of livecd to become troublesome?

I am a little confused. What is the specific function of the --allow-cd-boot compilation parameter that this task hopes to add? Forgive me for not seeming to understand!

https://github.com/vyos/vyatta-cfg-qos/pull/8
https://github.com/vyos/vyos-1x/pull/621