- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 9 2022
Feb 8 2022
Issue not resolved, re-open
For example, I have 300 routers in different timezones and I want to reboot 50% of routers via 1441min and the other 50% via 2881min
Hi @Viacheslav, I guess that, at least for our use cases, PR 9aad6f would allow the expected behavior.
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1210
PR for 1.4 https://github.com/vyos/vyos-1x/pull/1211
Ip address for openvpn is not yet assigned as a priority for OpenVPN less than for HA
460 interfaces/openvpn 800 high-availability
Anf we have checks if address assigned:
set interfaces ethernet eth0 address '10.1.12.1/24' set high-availability vrrp group FOO interface 'eth0' set high-availability vrrp group FOO no-preempt set high-availability vrrp group FOO priority '150' set high-availability vrrp group FOO rfc3768-compatibility set high-availability vrrp group FOO virtual-address '203.0.113.1/24' set high-availability vrrp group FOO vrid '10'
PR ability to get nftables counters, telegraf input plugin https://github.com/vyos/vyos-1x/pull/1209
Feb 7 2022
Feb 6 2022
Sorry, but I dont think this is fixed; I just attempted to upgrade my working 1.2.8 configuration to 1.3.
Feb 5 2022
VyOS 1.4-rolling-202201041316 - works well.
Feb 4 2022
Ran some quick tests with current vyos installed in a VM and a client ubuntu server VM hooked up to it - since this is all internal stuff it is a double NAT scenario with the vyos external IP allocated out of 192.168.x.x space and using 10.100.100.0/24 internally for the client ubuntu VM.
@aohanian I got it, thanks, so it doesn't delete the previous route in one commit
it can be archived with 2 commits
configure delete protocols static route 1.1.1.1/32 dhcp-interface eth4 commit set protocols static route 1.1.1.1/32 dhcp-interface eth5 commit
The problem in 1.3.0 is that if you delete the next-hop and then use a different next-hop, both next-hops are in the routing table. The next-hop that you deleted is still there:
I think there is a bit of confusion here. nowadays 1.4 it's works as you mention , but 1.3 doesn't remove static (so we can see both static in the RIB) . however, In my personal opinion , it should show both static in our cli (same also on FRR) , because it's possible that you may need a different prefix ,it'll be installed with a different next-hop .
@fernando What do you want to see it that case?
In the our CLI DHCP-route can be as a single value now:
set protocols static route 192.0.2.192/32 dhcp-interface 'eth0' set protocols static route 192.0.2.192/32 dhcp-interface 'eth2'
I.e. the first route will be replaced with the second route in CLI.
So if I understand correctly you expect that this route will be also replaced an in the FRR?
For 1.4 this feature was added in T2683
Fixed in 1.3
vyos@r4:~$ show interfaces counters Interface Rx Packets Rx Bytes Tx Packets Tx Bytes dum0 0 0 0 0 eth0 126 9952 76 10316 eth1 4 280 5 523 eth2 37 1924 0 0 lo 6 300 6 300 vyos@r4:~$ vyos@r4:~$ clear interfaces ethernet eth1 counters Clearing eth1 vyos@r4:~$ show interfaces counters Interface Rx Packets Rx Bytes Tx Packets Tx Bytes dum0 0 0 0 0 eth0 182 14550 108 14340 eth1 0 0 0 0 eth2 42 2184 0 0 lo 6 300 6 300 vyos@r4:~$
@jack9603301 Could you test it, also create a pr for the documentation?
@jestabro you are right. Adding no_tag_node_value_mangle=True will fix this issue.
https://github.com/vyos/vyos-1x/blob/ec13cac66ba612ecc36053158c7517c8fe993547/src/system/keepalived-fifo.py#L73-L74
self.vrrp_config_dict = conf.get_config_dict(base,
key_mangling=('-', '_'), get_first_key=True,
no_tag_node_value_mangle=True)Found the problem here - I used a different and simpler version of the configuration above and *show openvpn server* returns an output when a client is connected.