Hi,
I was playing around with VyOS and thought i'd build myself an iso and hit this issue. Not sure if its the correct way to solve it, but this is what I did:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Today
This will be resolved after backport of T5996.
Output seems to be for VyOS 1.3, rather than 1.5
Can you show VyOS version @PeppyH ?
Test addresses have to be different
Provide the set of the commands to reproduce
Without subtasks, it is going to be dead.
@Apachez It is not clear what you want to fix exactly. Fix all and do all working well could be related to any task.
Not reproduced on VyOS 1.5-rolling-202404141045
vyos@r-left# set pki ca "my test ca name" certificate 'MIIDnTCCAoWgAwIBAgIUFvyB2rY0V1V6AaIpPWHCftGRwN8wDQYJKoZIhvcNAQELBQAwVzELMAkGA0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0yNDA0MTgxMTM3MzZaFw0yOTA0MzZaMFcxCzAJBgNVBAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5T1MxEDAOBgNVBAMMB3Z5b3MuaW8wggEiMA0GCQEBAQUAA4IBDwAwggEKAoIBAQCKEVxs7gdzmnN4iMinvXN1vdGaT+v3TOnHSXbBkWHnt9YdWmo8UoqFpVqyVM3E8xmoT+3HOXJeWkKArEpMkGo93kWaGo0f25KGEFWbS2ttgNA9cqH9PGa42XTKyTY+5ZoIWaQQzNNiUSaIoslRrMSV4V2yQs90ECxR37ezlV2RAIHEhZ6mizUkMkuSmdjqRolh2tpF1MoisyhspFPXBC6lJ8d0jFZEi1tP3tlQjqVEWPjTvtddy34iOLFeUjBF5cOwfmpVLzWBVLbIxJr5ZHamGeQIabn36Jg1u0+/6p7hb8avqBW4dT0K8UykWVqgjQ4W4rM7AgMBAAGjYTBfMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUxEx+IVaoLb7M/SW9AkCVRaXCNTUwDQYJKoZIhvcNAQELBQADggEBAGjV6WiH4Z+hfdANG8oWgY0xsHmUZg8dCjwqO5GMwjBVIuu8GuoZu0JobtLa097behWcgCkwjvKBffuwCu542WbFkxdXzBLZjSAc+K3itegZIuy4jqRO5z6Q0IbPSaFUhR4HhfwejwlyXgjNCFzEMzwoDL2/3PXjWyilkqthYyFcx092tgwiXtnfO9z9Xm/YQHQmRG2VWzLEwucOhV698xnqFgRJk3uKqcDN9KjF+5v32OQ0eis7GHn1aJim5aUee1nnCRFdQO0llNJRwF6fIaICzKLwa7zzMjF7HhRehh5kpwY8omcQX7xYz7GJag4='
@dotAndy Is it still relevant?
Can you create a PR?
@SquirePug re-check please with the latest rolling image.
@jmaslak can you check the latest rolling image?
@kroy can you re-test this case?
Closed invalid - this is done with nftables now.
It would be handy if the GARP announcement wouldnt be a separate list but rather picked up from any DNAT or SNAT rules.
Probably related:
In T6247#184232, @jmoore wrote:. We need the feature regardless of the state of the repository.
Yesterday
It very may well have been. That's not really relevant to this request. The repository is an example. We need the feature regardless of the state of the repository.
I saw such repository more than once, but it seems that it has been abandoned. Last commit is dated two years ago.
Another example on nftables: https://github.com/fullcone-nat-nftables/nftables-1.0.5-with-fullcone
We do not use iptables and their modules for new features.
Feel free to add PR for nftables or if you know which commands should be for nftables
vyos@test1:~$ sudo cat /run/openvpn/vtun20.status OpenVPN CLIENT LIST Updated,2024-04-17 16:40:05 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref GLOBAL STATS Max bcast/mcast queue length,0 END
From initial PR these two feedback points are now implemented. PR has been amended see https://github.com/vyos/vyos-1x/pull/3307
I think I might've found the cause of this issue: the vni is unset from all VRFs when making changes. I posted a message about this on Slack (and about another, fairly similar, issue) on Slack about this.
Just checked with the current rolling release 1.5-rolling-202404141045. After committing set high-availability disable, keepalived is successfully stopped and the logs show that the transition script seems to be executed:
thank you very much for your analysis. I am still wondering, why it breaks with adding the vrf and why it works before.
Also, why it starts to work again, after rebooting when removing the vrf again (but not before rebooting)
Needs the original file with OpenVPN addresses/statistics which are parsed /run/openvpn/{interface}.status
Without it, it will be difficult to do something.
It is not related to VRF at all and is related to the policy routing logic:
Reproduced even on 1.3.2
set interfaces ethernet eth1 address '192.168.122.14/24'
Updates have been applied on 1.4 and 1.5.
This can probably be closed.
Tue, Apr 16
I decided to dig into this a little more and try to trace this out:
@dmbaturin, @sever
Would love your input regarding the lack of headers when using the -c option. I've created a PoC around "chronyc -c activity" as it was the most straight forward command to start with.