- User Since
- Mar 19 2020, 5:57 AM (31 w, 4 h)
It has passed the GNS test, and the test cases are as follows:
Tue, Oct 20
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:
Sun, Oct 18
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?
Sat, Oct 17
Must this command be executed from docker now?
Fri, Oct 16
Quite interesting, support, in fact some information can not be captured from SNMP very well
Thu, Oct 15
@runar The preliminary integration of tinc is basically completed, please see
Tue, Oct 13
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
Mon, Oct 12
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
Fri, Oct 2
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 NDP, I hope to give full play to the full potential of NDP proxy, so I don't want to bind it to nat66 artificially.
Thu, Oct 1
Wed, Sep 30
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?
Tue, Sep 29
Mon, Sep 28
Sun, Sep 27
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 Reasonably, I don't even know how to test the intrusive code comprehensively without affecting the basic functions of the router.
Fri, Sep 25
Thu, Sep 24
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.9. There are now 3 solutions:
Wed, Sep 23
Hi, everyone, I have been looking for a way to handle the 1-to-1 address peer-to-peer 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 , 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 The display of .org/html/rfc6296#page-11 does not indicate that the interface identifier cannot be modified, but only stipulates that the address mapping conforms to the unary 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?
Tue, Sep 22
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.
Sep 21 2020
Sep 20 2020
@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?
Sep 19 2020
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
If possible, give your suggested cli path for my reference
I can't find how to enable ipv6 connection tracking. Recompiling and modifying the linux kernel switch does not seem to see the module loaded. I think the current nat66 has completed 90%, and only need to implement ndp proxy to make it work normally.
set interfaces ethernet eth0 ip proxy-arp
I think we do need it, we can’t let users manage all IP manually unless we implement stateful NAT66
Beeing stateless or statefull both should work. We can add a CLI node for the proxy.ndp option like we have for proxy arp on ipv4, no big deal.
Sep 18 2020
This is a milestone, which means we have to decide whether to use stateful or stateless
It is confirmed that there is a bug in the implementation, but no solution has been found yet. In the nat66 rule, the prefix translation is indeed performed in the expected behavior, but the upstream device cannot return the data packet from the specific prefix. If the community has a good solution, please let me know
Sep 17 2020
Please give the configuration of R1 so that I can immediately test your topology in the simulation environment
Sep 15 2020
It’s best to provide links to related descriptions instead of asking everyone to search for the related details and patch implementations you describe
Sep 14 2020
Isn't it upgraded to 5.x? Why 4.x?
Sep 10 2020
Sep 2 2020
Aug 31 2020
Aug 29 2020
We look forward to the solution of this problem
Is this problem solved at present?
Aug 24 2020
The updated code was successfully tested on the virtual machine, and 5.1 has not been tested yet, waiting for the release of kernel 5.1
Aug 23 2020
Aug 22 2020
The SNPT and DNPT functions are basically implemented, but because they have not been reviewed and approved for the time being, they enter the hold state, waiting for processing and discussion
Aug 20 2020
Although nat66 (NPT) is not currently incorporated into the mainline, I may need to modify my implementation if it is also modified
Hello, here is a request beyond the outline. Please help me check whether the NAT kernel module of IPv6 has also changed? It turned out to be nft_chain_nat_ipv6？
Aug 17 2020
Sorry, I don't understand what you mean. Can you tell me more about it? What is using net-snmp to submit feature requests?