There's a proper tsort library now and prototypes are already in the current VyOS.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 8 2024
Sep 16 2024
Jul 2 2024
May 15 2024
May 4 2024
Apr 4 2024
Mar 26 2024
Yes, as described in the issue, using dynamically added routes works fine. But I want to add the routes manually as I did before with the 1.3.x release.
Using both automatically added routes from PPPoE and setting them statically does not sound like a "sane" config to me.
Mar 25 2024
Delete set interfaces pppoe pppoe0 no-default-route will let it works. it is the same issue.
Jan 19 2024
Jan 9 2024
Host name settings certainly works fine now, but if anything, feel free to reopen.
The use case for it will be addressed by the future support for true (ignored by the parser) comments.
Dec 21 2023
Dec 17 2023
Dec 9 2023
Duplicate
Aug 25 2023
Jul 19 2023
Jul 12 2023
Jun 13 2023
Hi @jestabro I saw that feature request but I wasn't sure. Thank you!
cf. https://vyos.dev/T5249, currently being assessed.
Aug 29 2022
Jan 21 2022
Seems solved, Not reproducible on VyOS 1.4-rolling-202201180317
Jan 6 2022
Jan 5 2022
Jan 3 2022
To reproduce it should be zone-policy firewall rules, for example:
Dec 6 2021
The correct key for sflow sfprobe_source_ip
PR https://github.com/vyos/vyos-1x/pull/1099
Dec 4 2021
KEY: nfprobe_source_ip DESC: Defines the local IP address from which NetFlow datagrams are exported. Only a numerical IPv4/ IPv6 address is expected. The supplied IP address is required to be already configured on one of the interfaces. This parameter is also required for graceful encoding of NetFlow v9 and IPFIX option scoping. DEFAULT: IP address is selected by the Operating System
Nov 27 2021
Nov 6 2021
Sep 5 2021
Feb 23 2021
Feb 22 2021
The ISC DHCP relay in VyOS is completely broken for my (non-GRE) use case, I would really like to see it get tossed out for something that works. This might not be the best place to describe my relay problems, but I might as well (skip this paragraph it you're not interested). My setup basically consists of the (ISC) DHCP server host connected to the VyOS router (running on a Dell R320), directly connected to a Cisco ASR920 router. Both VyOS and the ASR are directly connected to user VLANs (VyOS for firewalled/NATed zones and ASR for high-traffic users) and have DHCP relays set up targeting the DHCP server, such that the relayed messages from the ASR passes through the VyOS router towards the DHCP server and should get routed normally (i.e. ignored by the VyOS relay). The VyOS DHCP relay doesn't like this and starts spamming the DHCP messages up to ten or more times, causing wired clients to have to wait maybe ten seconds before getting an IPv4 address and wireless clients to just time out and abort the connection. I can provide the relay logs (mainly screenshots unless i dig up the disk I used) and VyOS config if anyone wants them, but as they have sensitive addresses, I don't intend to post them publicly. EDIT: I should mention that I didn't notice any problems while testing it with only myself, it was when 200 people started connecting the problems started occurring. And the DHCP server VM was not showing any noticable load.
Feb 18 2021
If this package supports all existing setups and the GRE usecase I see no reason to not replace it. @basalblas PR is happily accepted.
Keep in mind you cannot run dhcp-helper and ISC DHCP server at the same time on a single router. The Vyos CLI should not allow this.
Jan 27 2021
Jan 18 2021
Jan 6 2021
Nov 28 2020
Fixed
set nat source rule 1000 outbound-interface 'eth1' set nat source rule 1000 source address '203.0.113.1-203.0.113.4' set nat source rule 1000 translation address '10.0.0.1-10.0.0.4' vyos@r5# commit [ nat ] Warning: IP address 10.0.0.1 does not exist on the system! Warning: IP address 10.0.0.4 does not exist on the system!
Jun 5 2020
duplicate of T2468
Jun 2 2020
Thank you for reporting this issue, it looks like that parser allows ranges of IP address (IP hyphen IP) but the parser does not. You could get around using CIDR notation but this indeed need looking into.
Jan 3 2020
By the way, may I say there are several bugs of stop function in vyos-router?
Why not use WantedBy instead of RequiredBy in vyos-hostsd.service like:
Jan 2 2020
My original thoughts was quite straight forward, modify /usr/libexec/vyos/init/vyos-router as below:
Dec 31 2019
Hello, @MapleWang!
Unfortunately, I cannot find any other reliable way to configure vyos-hostsd service to be running before the vyos-router. In fact, vyos-hostsd is really necessary to be running for proper work of the VyOS system, so we can consider this even from the other point of view - how to keep all services operable after the vyos-router restart?
If you will have any ideas, which can help to decrease the overall impact of this situation, we would be happy to get them.
Dec 20 2019
Really thanks for your reply. It's nice to have this fix. But to be honest, crash of vyos-hostsd is not so big deal for me, what really concern me is that restart of vyos-hostsd is followed by restart of vyos-router.
Dec 19 2019
Hello, @MapleWang!
Thank you for pointing our attention to this issue! It is really bad that such simple action as changing hostname in some cases (well, in fact not only this but it is easy to reproduce) leads to the whole router crash.
The problem consists of several parts:
- In old systemd versions (which is used in Debian Jessie and VyOS 1.2) exists a problem, when during a restart of systemd-journald all pipes between this daemon and systemd services are disconnecting.
- In vyos-hostsd, which is responsible for hostname and DNS and controlled by systemd we used print() for logging and debug purposed without enough handling of errors.
So, when arises the situation when there is no PIPE connection between vyos-hostsd and systemd-journald, vyos-hostsd not able to print messages and crashes. :(
Dec 18 2019
I found a easy way to reproduce.
Dec 17 2019
May 3 2019
There are things that should be simply incorrect grammar, and this is one of them, as of me.
Apr 16 2019
Feb 26 2019
Nov 13 2018
Sep 6 2018
I'm using VyOS 1.2.0-beta1 (lithium) with a 1 GB HDD on ESXi.
I‘m using VyOS 1.2.x wirh a 4GB HDD on ESXi
Aug 4 2018
The renderer works now (for a long time already, even), so it's time to close this task finally. ;)
Jun 1 2018
May 31 2018
It looks pretty clear from configuration point of view. Actually this request was made to avoid potential security breach if somebody doesn't have correct acl on wan facing interface.
May 27 2018
As soon as someone sets set system ntp allow-clients address 172.16.0.0/12 we act as NTP server for this network,too. It's a bit odd that this node is under system but ... it is as it is.
that is weird,
i was under impression that we have it as client.
So it perfectly make sense have it under service