Hey, it seems that the big trouble now is the difference in the definition of the command line. If possible, I agree to conduct a survey to see your opinions.

OK, I understand, PR has been updated

set interfaces bridge br0 member interface eth0 allowed-vlan 2,4-9
set interfaces bridge br0 member interface eth0 native-vlan 101

The following writing methods can currently be used, such as:

It seems to be the same as the task list, but my basic realization is basically completed, see:

If two different vlan processing methods are not used for the same interface, then the two are not currently in conflict, unless the user sets vlan filter and eth0.10 on the same interface at the same time

@runar The modified command is as follows:

@runar There is a question, that is, how to set the pvid flag according to this command format? Is the pvid flag automatically attached to the untagged option by default?

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

Hello everyone

@c-po I think you may have referred to the wrong worksheet in your WiFi implementation? This task list is used to track and implement the VLAN filter of the bridge and the VLAN sub interface pairs of SVI

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:

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

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)

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

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

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

/usr/lib/python3/dist-packages/vyos/ifconfig/ tunnel.py The corresponding file is in https://github.com/vyos/vyos-1x/blob/current/python/vyos/ifconfig/tunnel.py

Have you ever tested it?

It looks good, I want to ask how other people in the community think about this?

Does anyone understand the meaning of these performance data? I don’t know the unit of these data

1. 1. When the user's data source uses NTP cluster, whether switching to the new service may lead to the compatibility problem of NTP cluster network

Can chronyd completely replace NTP?

It has passed the GNS test, and the test cases are as follows:

What content of "conf-path" ?

Hello everyone, I am integrating tinc. At present, I have passed the basic test in a simple virtual machine. The command line is simplified. Examples are as follows:

I agree. Therefore, if someone understands the code structure of FRR, we can modify the implementation from within FRR according to Prometheus protocol framework, implement the exporter integration, and then generate a patch file. Set the automatic compilation script and automatically package it into DEB

It is true, but I just want to record it to avoid forgetting that another solution is to redevelop FRR and promote it in parallel with the official version of FRR (in other words, we can patch FRR or maintain a branch separately, then compile a version of our own, and get the indication directly from its code, but this work needs someone to do.)

I think I understand what you mean. Don't worry. I'm also a user of Prometheus. I know how Prometheus works.

Most of Prometheus data is generated from the exporter. It is not collected and pushed in real time. When Prometheus queries, it can query relevant indications through the port exposed by the exporter. Therefore, I don't think it is possible to create thousands of sub processes/threads. What do you think?

@runar Some interesting commands, such as tinc - n netname join URL, seem to be supported in tinc1.1

The frr_exporter linked uses os/exec to run an external binray, /usr/bin/vtysh. This is not a great way to build an exporter, as it can lead to a fork bomb. There is also the overhead of calling the external binary to gather data.

Tinc 1.1 supports rereading a lot of the configuration without resetarting the daemon, i've compiled a version of 1.1 for you from the debian salsa repository: https://salsa.debian.org/guus/tinc/-/tree/1.1/debian (this is whats available in the experimental debian branch) the deb is available her for now: https://borge.nu/vyos/tinc_1.1~pre17-1.1_amd64.deb. just put it in the packages directory when you're generating the iso or dpkg -i it into a image that have tinc-1.0 allready.

Do you know of a version of that FRR exporter that doesn't fork sub processes?

What information do you need access to from within op-mode?

I hope to implement an operation mode command, but too many interface parameters are generated according to the configuration in the interface. I don't know how to call these existing configurations. Can I call the user's configuration information through config in operation mode?

To prevent forgetting, write the address of the exporter to task

I updated pr. so far, tinc VPN cli will automatically generate the local node key file, such as the following code:

Isn't anyone implementing this feature right now?

Must this command be executed from docker now?

Quite interesting, support, in fact some information can not be captured from SNMP very well

@runar The preliminary integration of tinc is basically completed, please see

I am implementing tinc, but there is a problem I haven't figured out. Normally, in order for tinc to run, it must have a public key and a private key, and it happens that there will be a prompt for this generation command (ask where to save, etc), and it happens that the public key of the local node in the hosts directory is usually used together with some host configuration options. Is there a better way to implement it?

I wrote a preliminary CLI configuration file rule. This is the first step in tinc implementation. For details, please read: https://github.com/jack9603301/vyos-1x/blob/T766/interface-definitions/interfaces-tinc.xml.in

Another option is to compile and package by yourself, but the location of the repository is the problem

I don't think it's necessary to compile DEB packages because they can be obtained directly from apt

At this stage, I can't realize the automatic configuration of NDP proxy. On the other hand, although I don't know what additional application scenarios will be in addition to nat66, I hope to give full play to the full potential of NDP proxy, so I don't want to bind it to nat66 artificially.

@c-po Request merge https://github.com/vyos/vyos-1x/pull/556

NDP Proxy has been implemented in T2898. For nat66 to work normally, proxy-ndp must be operated in static mode.

Already basically ready to merge

I accidentally found sonarcloud, vyos now uses this system for quality control?

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

Write redundant and intrusive code for all interface types, which may introduce unknown errors (I can’t guarantee 100% accuracy without testing)

@c-po I am thinking about a problem. Placing proxy-ndp under the child node of interface may generate redundant implementation code and is intrusive. In fact, for proxy-ndp, only one configuration file is needed. Is this Reasonable? I don't even know how to fully test whether the intrusive code affects the basic functions of the router.

Also come back to this question?

In linux kernel version 5.8 and above, you can start symmetric translation of ipv6 address prefix by changing snat to to snat prefix to in the policy (without changing the interface identifier), but this function cannot be used before vyos upgrade 5.9 , This patch is not a back-portable patch, so this feature cannot be used in 4.19. There are now 3 solutions:

Hi, everyone, I have been looking for a way to handle the 1-to-1 address prefix symmetry mapping. I contacted the IRC channel of the official community. According to the official information, it seems to be resolved in the 5.8 kernel version, otherwise the patch needs to be backported To 4.19.

@c-po The map66 solution last released on July 25th, 2015 does not seem to have been explored. It can work with iptables. I am not sure if it has stopped maintenance. I am considering whether to consider it, but it means that it needs to be compiled, installed and generated deb package , Otherwise vyos cannot install it

Thank you for your suggestion. I am considering how to implement peer-to-peer translation without modifying the interface identifier. According to some information on the Internet, the support of ipv6 nat is divided into peer address and non-equivalent address. The standard https://tools.ietf.org/html/rfc6296 display does not indicate the interface identifier. The symbol cannot be modified, but only stipulates that the address mapping conforms to the one-dimensional linear equation relationship (that is, an address mapping is unique.

nftables nat66 seems to be the best solution that can be done now, I am still exploring a better implementation, do you have any suggestions?

Well, at present, the nat66 prefix conversion of nftables has not found a way to not change the interface identifier. Maybe other people in the community can provide some suggestions?

With NFT SNAT prefix translation, the address is not a 1:1 mapping. For example, if we have source prefix 2001:db8:1::/64 and translation prefix of 2001:db8:2::/64, the source address 2001:db8:1::1 will not translate to 2001:db8::2::1. The nftables translation calculates a new address which prevents the 1:1 host address mapping.

@c-po If I want to be an interface-ethernet.xml.in Add custom configuration actions (such as proxy NDP) with certain extensibility (its configuration can be extended in other places). What should I do?

I also take into account the specific situation of the ndp proxy, the configuration of this link prompts, the configuration format of the ndp proxy is like this.

No arp proxy option is found in the configuration path, ndp proxy can manage multiple address rules under one interface

vyos@vyos# set interfaces ethernet eth0 ip 
Possible completions:
   arp-cache-timeout
                ARP cache entry timeout in seconds
   disable-arp-filter
                Disable ARP filter on this interface
   enable-arp-accept
                Enable ARP accept on this interface
   enable-arp-announce
                Enable ARP announce on this interface
   enable-arp-ignore
                Enable ARP ignore on this interface
   enable-proxy-arp
                Enable proxy-arp on this interface
 > ospf         Open Shortest Path First (OSPF) parameters
   proxy-arp-pvlan
                Enable private VLAN proxy ARP on this interface
 > rip          Routing Information Protocol (RIP)
   source-validation
                Policy for source validation by reversed path, as specified in RFC3704

Although I intended to think that it is easier to write scripts under the protocol, but from an intuitive point of view, it seems that this path is also a good choice (users can use the same command line as the arp proxy to configure) I have written it A sample, then only need to decide how to modify the cli

In T2898#75670, @Cheeze_It wrote:

In T2898#75656, @jack9603301 wrote:

set interfaces ethernet eth0 ip proxy-arp

The more suitable position may be set protocol ndp-proxy

I...really would like to not put it under "protocols" but to put it under the interface. It's *much* easier and more intuitive to see it under the interface/sub-interface than to see it in its' own stanza under "protocol" node.

Also, I'd argue it would be reasonable to separate ARP proxy and NDP proxy. That way one can pick and choose. Of course ARP proxy can't work without an IP address configured. NDP proxy can't be configured without an IPv6 address configured (those could be used as checks against configuring it on an empty interface).