This was resolved via:
https://github.com/vyos/vyos-cloud-init/commit/1607eec32641ad93ea211e447336b3366c28de06
https://github.com/vyos/vyos-cloud-init/commit/3980057ce140ea6896cd3f7cd4299cfd29cf234a
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feb 13 2021
I am suggesting switching to https://github.com/vyos/vyos-vm-images for everything, except ISO images. This will solve the problem automatically. It is already able to create images for QEMU, VMware, Hyper-V, GCE, AWS, OpenStack, Oracle, Packet, and more not mentioned in the https://github.com/vyos/vyos-build. The only what I have not tried yet is Azure.
Setting Ethernet interfaces addresses, routes, and name servers are supported in both versions now. Advanced features like bonding, bridges, VLANs could be added later on-demand.
This was resolved via dhclient hooks - there is a protection mechanism now, which allows deleting only routes with tag 210 that set by hooks to all DHCP routes.
The config module without this problem is available in the crux, should be released in the 1.2.7 version.
The config module backported to the crux, should be available with 1.2.7 release.
Backported to the crux branch, should be released with 1.2.7.
Feb 10 2021
Jan 29 2021
Dec 25 2020
After the testing with a standalone User-Data handler, this feature was ported to the main cloud-init package in https://github.com/vyos/vyos-cloud-init/pull/27.
Currently, supported only set and delete commands processing. They must be provided as a list in the vyos_config_commands option.
Nov 9 2020
Nov 4 2020
Nov 2 2020
Oct 28 2020
Sep 24 2020
Sep 22 2020
Sep 17 2020
The main reason for such issues is missing a good one instructions on how to build a proper one image.
Sep 8 2020
NoCloud (and actually any datasource which provide network-config) must be supported now in VyOS 1.3. Feel free to test it.
This feature now is in the Cloud-init for 1.3 and must be backported after testing.
The configuration module for 1.3 is compatible with both network-config versions now. Initial testing was successful, but let's keep this for some time to collect more cases.
@kroy how about testing this in 1.3? It must work now.
Handling of all supported by VyOS configuration SSH key types was added to the VyOS 1.3 by this commit https://github.com/vyos/vyos-cloud-init/commit/d4004ac6ea1c7c03a35d9410f7c70ab423c926bb
Sep 1 2020
Aug 27 2020
Aug 17 2020
Aug 7 2020
Aug 6 2020
Aug 3 2020
Just to make this a bit clearer. A short how-to to reproduce the bug in 1.3-rolling-202008031114 with empty config:
set firewall ipv6-name WAN6_IN6 set firewall ipv6-name WAN6_LOCAL6 set interfaces tunnel tun1 6rd-prefix '2607:FA48:6ED8::/45' set interfaces tunnel tun1 6rd-relay-prefix '24.225.128.0/17' set interfaces tunnel tun1 address '2607:FA48:6ED8:8A50::1/60' set interfaces tunnel tun1 description 'Videotron 6rd Tunnel' set interfaces tunnel tun1 encapsulation 'sit' set interfaces tunnel tun1 firewall in ipv6-name 'WAN6_IN6' set interfaces tunnel tun1 firewall local ipv6-name 'WAN6_LOCAL6' set interfaces tunnel tun1 mtu '1480' set interfaces tunnel tun1 multicast 'disable' set interfaces tunnel tun1 parameters ip ttl '255' set interfaces tunnel tun1 remote-ip '24.225.128.1' set interfaces tunnel tun1 local-ip '24.225.136.165' commit
leads to the error:
Can not set "local" for tunnel sit tun1 at tunnel creation
and the same but without the local-ip option leads to the Python traceback.
Jul 31 2020
Jul 29 2020
It is possible to use https://github.com/vyos/vyos-1x/blob/b704d0676ab2d623d2eeb1ed4dc1bcf2a2c4a5e2/python/vyos/logger.py for this purpose now.
Changing description in a master transition script will lead to an endless loop, because of:
- Description change (or any other interface update) in a script trigger EthernetIf.update().
- EthernetIf.update() trigger a lot of interface changes:
Jul 29 14:05:36 vyos sudo[3097]: root : TTY=ttyS0 ; PWD=/home/vyos ; USER=root ; COMMAND=/usr/bin/sh -c VYOS_TAGNODE_VALUE='eth1' /usr/libexec/vyos/conf_mode/interfaces-ethernet.py Jul 29 14:05:36 vyos sudo[3097]: pam_unix(sudo:session): session opened for user root by vyos(uid=0) Jul 29 14:05:36 vyos control.py[3098]: set_interface: alias, Jul 29 14:05:36 vyos control.py[3098]: set_interface: link_detect, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: vrf, Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_cache_tmo, 30 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_filter, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_accept, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_announce, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_ignore, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp_pvlan, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_forwarding, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_accept_ra, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_autoconf, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_dad_transmits, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: mtu, 1500 Jul 29 14:05:36 vyos control.py[3098]: set_interface: alias, MASTER_by_script Jul 29 14:05:36 vyos control.py[3098]: set_interface: link_detect, 1 Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) Entering BACKUP STATE Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) sent 0 priority Jul 29 14:05:36 vyos control.py[3098]: set_interface: vrf, Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_cache_tmo, 30 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_filter, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_accept, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_announce, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: arp_ignore, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: proxy_arp_pvlan, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_forwarding, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_accept_ra, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_autoconf, 0 Jul 29 14:05:36 vyos control.py[3098]: set_interface: ipv6_dad_transmits, 1 Jul 29 14:05:36 vyos control.py[3098]: set_interface: gro, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: gso, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: sg, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: tso, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: ufo, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: admin_state, up Jul 29 14:05:36 vyos Keepalived_vrrp[1302]: (lan) Entering MASTER STATE Jul 29 14:05:36 vyos control.py[3098]: set_interface: gro, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: gso, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: sg, off Jul 29 14:05:36 vyos control.py[3098]: set_interface: tso, off Jul 29 14:05:37 vyos control.py[3098]: set_interface: ufo, off Jul 29 14:05:37 vyos control.py[3098]: set_interface: admin_state, up
- Something from this all trigger keepalived interface reinitialization.
- Keepalived change VRRP state to BACKUP and then MASTER, and run transition scripts.
- GOTO 1.
Jul 24 2020
Jul 23 2020
Jul 14 2020
Jul 13 2020
Closed in favor of https://phabricator.vyos.net/T1101
Jul 1 2020
This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.
Jun 25 2020
Jun 24 2020
Jun 15 2020
@s.lorente can you check this with actually configured tc values?
Jun 11 2020
The set protocols bgp XXX neighbor XXX address-family ipv6-unicast peer-group XXX command generate the router bgp XXX; address-family ipv6; neighbor XXX peer-group XXX', for vtysh, which does not supported (anymore? I cannot find any commits in FRR about syntax change, maybe this was migrated from old quagga).
Jun 10 2020
Jun 8 2020
@c-po I have not tried this previously, but if it works well, I would like to keep it for kernel debugging on bare-metal devices.
May 13 2020
May 12 2020
May 9 2020
The bug is produced because of deleted deprecated option in vtysh. Before FRR 7.3:
root@vyos:/home/vyos# vtysh -c "show ip community-list 10" This config option is deprecated, and is scheduled for removal. if you are using this please migrate to the below command. 'show bgp community-list <(1-500)|WORD> detail' % Can't find community-list
Starting from 7.3:
root@vyos:/home/vyos# vtysh -c "show ip community-list 10" % Unknown command: show ip community-list 10
May 4 2020
Need to check again with 1.3, as may be solved by: https://phabricator.vyos.net/T1291
Apr 30 2020
Apr 28 2020
Apr 27 2020
Apr 20 2020
Apr 17 2020
Apr 13 2020
Apr 10 2020
Apr 8 2020
Hello, @adestis!
Support of transition-scripts was added to sync-groups in a rolling version.
I have investigated this a bit. Most operations for ports are doing one-by-one. Deleting as I see is always done in this way. Adding a range is done by a single command, but checking ports are doing one-by-one.
If we skip/change mentioned checking for adding ports, this should decrease initial commit time. But when we try to change/delete ports, the issue will back.
I think that there should be better to reimplement the whole firewall group section in Python, instead of fixing this logic now.
Already possible via Cloud-init. For different environments may be required differently tuned images (data sources, additional tools like guest agents, etc.).