The issue with this check
A possible original issue with the function exists as it checks the only first value
bond
member
- eth2
- eth3It returns only eth2 as a member of the bonding
For some reason is_bond_member is not in the configuration after the description
eth2 with option is_bond_member
eth3 without option is_bond_member
############## MY DEBUG START:
{'description': 'fofof',
'duplex': 'auto',
'hw_id': '50:08:00:01:00:03',
'ifname': 'eth3',
'ip': {'arp_cache_timeout': '30'},
'mtu': '1500',
'speed': 'auto'}
####### MY DEBUG END #######@fortinj1354 you can do changes in xml, build .deb pkg and install it on the instance
https://docs.vyos.io/en/equuleus/contributing/build-vyos.html#id4
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1280
The root cause it generates incorrect pool name (conf mode) with a dash instead of an underscore
vyos@vyos:~$ show conf com | match dhcp set service dhcp-server shared-network-name NET_01 authoritative set service dhcp-server shared-network-name NET_01 name-server '1.1.1.1' set service dhcp-server shared-network-name NET_01 subnet 192.0.2.0/24 range R1 start '192.0.2.21' set service dhcp-server shared-network-name NET_01 subnet 192.0.2.0/24 range R1 stop '192.0.2.254' vyos@vyos:~$
dhcp.conf
...
on commit {
set shared-networkname = "NET-01";
}@devon Will be fixed in the next rolling release, could you check it?
Applying patch from the PR I could not reproduce issue anymore
From debug static address is assigned before vrf changes:
fe80::5208:ff:fe13:2 - autogenerated linklocal
fe80::5200:ff:fe55:222 - static linklocal
Bug confirmed on 1.3.1-S1 and on 1.4-rolling-202203180317
Submitted this PR: https://github.com/vyos/vyos-1x/pull/1256
After some testing in regex101, it seems like a good replacement regex would be ^(http:\/\/|https:\/\/)?[a-z0-9]+(?:[\-\.]{1}[a-z0-9]+)*(\/.*)?$ but I'm not well versed enough to build an image off of my own branch to test that, and I can't figure out how to modify the installed version to use the new regex to test.
I very much like this idea.
Re-open to investigate failure in vyos-configtest.
Re-open to investigate failure in vyos-configtest.
Re-open to investigate failure in vyos-configtest.
I'm going to be experimenting with Jinja 2 to see if we can incorporate it into our template processor.
If the solution is so simple, whats the issue? from what I understand it's just a matter of working on:
vyos-vrrp-conntracksync.sh