With ethernet works fine, VyOS 1.3-rolling-202007230117
vyos@r1-roll:~$ show int Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address S/L Description --------- ---------- --- ----------- eth0 192.168.122.11/24 u/u eth1 - A/D
Fixed, VyOS 1.3-rolling-202007230117
@suuei Can you try the lateset Rolling release?
Currently, we don't have the option "link" in vxlan which was provided in config.
As workaround
Fixed.
vyos@r1-roll:~$ show vpn remote-access No active remote access VPN sessions vyos@r1-roll:~$ vyos@r1-roll:~$ show version
Fixed, VyOS 1.3-rolling-202007230117
Fixed, VyOS 1.3-rolling-202007230117
set interfaces tunnel tun16 encapsulation ip6ip6 set interfaces tunnel tun16 local-ip 2001:db8:aa::16 set interfaces tunnel tun16 remote-ip 2001:db8:aa::26 set interfaces tunnel tun16 address 2001:db8:bb::6/64 commit
@c-po Request merge
@c-po Request merge
@c-po Request merge
With that replace I see this is an error in each commit
I replace
my $cmd = "curl -#";
to
my $cmd = "curl --insecure -#";
No, not yet. But generally I don't like it too much because I'm blind and their desktop client isn't very accessible, and writing things like code examples on a smartphone, well, is something I try to avoid ;-).
@efficiosoft are you on our slack channel ?
Yes, it would be a solution. However the behaviour the daemon should really be "fixed" when loaded. It may be simpler to have a reload feature on SIGHUP. This would allow changing the file on disk when developing, testing it without breaking things, and only when confident that it is right, then asking for the reload.
Well, it would be trivial to add an --auto-reload switch to the daemon for development purposes which could enable an inotify watcher over the XML files.
Fixed
It's impossible without re-adding network driver (modprobe -r xxx; modprobe xxx)
set interfaces pseudo-ethernet peth0 set interfaces pseudo-ethernet peth0 source-interface eth1
Fixed.
One thing to keep in mind however when sticking with the XML definitions are the nodes that exist twice, once as tag and once as non-tag node, as @dmbaturin mentioned.
@efficiosoft asking users to fire a daemon is not really user-friendly :-) Once a daemon is loaded, whatever change is done to any initialisation data on the disk will not affect it. Should a tool exist loading the same data each time, then changes can be tested without affecting the running daemon.
In VyOS 1.3-rolling-202007220117 works fine.
@efficiosoft asking users to fire a daemon is not really user-friendly :-) Once a daemon is loaded, whatever change is done to any initialisation data on the disk will not affect it. Should a tool exist loading the same data each time, then changes can be tested without affecting the running daemon.
Providing a way to run the op. code without the daemon would allow people to design their own XML add it to the router, test it without reloading "the stable" code in the daemon, and only when happy that it is working cause a restart of the daemon.
Thanks @thomas-mangin for sharing your thoughts on this.
Thank you for the offer, having read your patch it seems you are indeed fluent in Python and as there is lots to do so I am sure you will be able to help :-)
As @dmbaturin started this, I will let him come back to you about what could be done.
I like this idea of building a vyos-opd daemon in Python.
Pull request to revert that changed line: https://github.com/vyos/vyos-1x/pull/516
Issue only happens if a user is defined without a password, otherwise the correct field gets set:
# Encrypted password
if conf.exists(['authentication', 'encrypted-password']):
user['password_encrypted'] = conf.return_value(['authentication', 'encrypted-password'])https://github.com/vyos/vyos-1x/commit/a07e22377ab83104ac925e13d1824f241f0f8d4a#diff-38def27d6150350cf8bd539da90de66b (T2492) seems to have changed the initialization:
Fixed in the latest rolling release.
Fixed in latest rolling release and T2658
Fixed in the latest rolling release
vyos@r1-roll:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 192.168.122.11/24 u/u Huawei is secondary home router Telecom special edition switching and AP mode
lo 127.0.0.1/8 u/u
::1/128
vyos@r1-roll:~$ show versionOf course :)
@hammerstud that would work for you - but it will break everyone elses implementation ;)
Perhaps I'm one of the minority. but BGP is our predominant DMVPN routing protocol.
As i remember the lack of multicast replication was the reason this stopped up last time it was discussed... And as ospf and eigrp is the most used protocols run over dmvpn i think this is a showstopper for implementimg nhrpd
FRR nhrpd do not support multicasting over GRE tunnels so OSPF or EIGRP don't work since they use multicast addresses to discover neighbors
It will break everything when in use ;)
show interfaces vrrp
I assume this will break 'system static-host-mapping host-name' and other places where tagnodes are used to carry string values as well
Must be fixed after T2653 - then there is only a single truth for all interfaces
I have tried the above scenario in the VyOS 1.3-rolling-202007200117 which is the latest version and the issue did not reproduce. So I would request you to try in the latest version and share your feedback.
Option set! Kernel rebuilding
The problem not in the bonding.
Any interface with DHCP address can't be disabled.
Here you go.
While you are working on this, there is a need for a render function that does return the template as an variable instead of saving it to a file.
could you extend your patch to also include such a function? if written correctly it could be used by the render() function to not duplicate code.
The kernel is missing an option " CONFIG_XDP_SOCKETS y"
vyos@r-roll:~$ sudo cat /boot/config-4.19.131-amd64-vyos | grep -i xdp # CONFIG_XDP_SOCKETS is not set
PR https://github.com/vyos/vyos-1x/pull/511
It replaces "_" to "-" for NTP server names configuration.
For every test I have done, I think it is worth it.