@lclements0 Can you re-check?
Probably was fixed in https://github.com/vyos/vyos-cloud-init/commit/412287741b70b536458d84972257eda0b3c18d9f
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feb 19 2024
Possible FRR bug https://github.com/FRRouting/frr/issues/13561
Feb 18 2024
Use the latest rolling.
Feb 16 2024
Compat names were dropped in https://github.com/vyos/vyos-1x/commit/c8ef5e8bdce01bbf05297df39e6c6223d0b2a2ea
Fixed for 1.4
set interfaces bonding bond0 member interface 'eth1' set interfaces bonding bond0 member interface 'eth2' set interfaces bonding bond0 mode '802.3ad' set interfaces bonding bond0 vif 667 address '10.6.67.11/24' set interfaces bonding bond0 vif 668 address '172.29.0.11/24' set interfaces bonding bond0 vif 668 redirect 'ifb0' set interfaces input ifb0 commit
enable-local-traffic just writes several old iptables rules https://github.com/vyos/vyatta-wanloadbalance/blob/961a2e8862280d2ce5500626cdee8a1adaa67ab2/src/lbdecision.cc#L124-L130
Propose to close task as "wontfix" due to the old backend and C implementation.
The correct behavior should be implemented for the protocols failover route feature.
I also propose to close all load-balancing wan tasks as wontfix for the same reason.
The task for dynamic interface T5647
Update from the PR
The changes from this pull request has already been incorporated and will be in the next major release of open-vm-tools.
https://github.com/vmware/open-vm-tools/pull/689#issuecomment-1948466725
Still bug for VyOS 1.5-rolling-202402131735
I'd delete the whole firewall configuration, at least for test.
@FileGo Could you re-check? As you have the full configuration to reproduce.
@hexes Could you recheck/update if it is still the bug?
@n.fort Which migration are you expecting here?
Fixed
vyos@r11# run show conf com | match "flow|ppp" set interfaces pppoe pppoe1 authentication password 'user1' set interfaces pppoe pppoe1 authentication username 'user1' set interfaces pppoe pppoe1 source-interface 'eth1'
It is still a bug VyOS 1.4-rolling-202402160309. After deleting the tunnel key from both sites there are no pings
Do not see the difference with 1.3.6
$ ./automation.sh te123 ++ dirname ./automation.sh + SCRIPT_DIR=. + HOST=te123 + echo 'local arg of host: te123' local arg of host: te123 + ssh vyos@192.168.122.15 '/bin/vbash -s' te123 remote hostname: 1
Not a bug for 1.5/1.4 anymore.
vyos@r11# set service pppoe-server client-ip-pool POOL range 100.64.24.1/24 [edit] vyos@r11# run show ver Version: VyOS 1.4.0-rc3 Release train: sagitta
It is not a bug for 1.5/1.4
set policy route-map FOO rule 10 action 'permit' set policy route-map FOOv6 rule 10 action 'permit'
@SrividyaA Could you re-check and close the task?
Try to check if the routes exist in the FRR config.
vtsyh -c "show run staticd"
Needs re-check as FRR was updated. Also, update GNS3 to the latest version.
It is not clear how to reproduce it without GNS3 on the some VM
Feb 15 2024
The UPNP Implemented but not fully working, related task T5835
Feb 14 2024
@Apachez, what exactly do you want to fix here?
As I understand changes as in this example
https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers
Feb 13 2024
Smoketest conntrack fix https://github.com/vyos/vyos-1x/pull/3005
IPoE server was rewritten to get_config_dict
The original bug was solved
@FileGo Could you re-check it with 1.4-rc3 or the latest rolling?
Not sure that we can fix anything in this specific case.
Close it as invalid; there are no responses from the author.
Feel free to reopen it if you still have this issue. We need more details, dumps, and probably the whole configuration for debugging.
No responses from the author
I closed the task because we do not have other issues like this.
Feel free to reopen if it is required.
@dberlin Can you recheck?
@JonD Have you figured out what the problem is?
@pjeevarathinam Could you re-check wiht 1.4-rc3 or the latest rolling?
You can play with descriptions
vyos@r4# set system frr descriptors Possible completions: <1024-8192> Number of file descriptors
@tfiebig Could you add a PR?
@greywolfe Any update?
@svd135 Can you recheck?
@twan Could you try with the 1.4-rc3 image?
@dcplaya provide the whole configuration to reproduce or close the task if the reason is firewall incorrect configuration.
Feb 12 2024
@evilmog Can you provide the OpenVPN/other configuration to achieve what you want?
Wait two weeks before closing.
@mb300sd Let us know if it is fixed.
It cannot be backported to 1.3 as there are no config-mode-dependencies
There have been no reports since 2021
merged