- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 21 2022
PR for 1.4: https://github.com/vyos/vyos-1x/pull/1367
TBD: GUI
VyOS users can configure the front-end interface, called vycontroll, to examine the configuration state.
A detailed description can be found at:
https://vycontrol.com/
https://github.com/vycontrol/vycontrol
https://docs.vyos.io/en/equuleus/configuration/service/https.html
https://brezular.com/2021/05/01/vycontrol-web-ui-for-vyos-firewall/
FRR Debugging
Recently, I had to triage/debug a bunch of issues that involved running a legacy build of frr.
This involved:
- Triaging issue down to the place when it was introduced. Otherwise, verifying that feature was never working at all.
- Comparing the execution flow between legacy/master versions to identify the divergence
- Building & running multiple (legacy/master) frr versions in parallel
- Doing deep analysis within gdb
Since the last update, I have simplified the CLI interface:
1. I have removed the global iterator and incapsulated the iteration state into the vty structure. This way, each vtysh client has its private iteration state for the following requests. It should be possible to query multiple data nodes simultaneously and asynchronously.
Jun 20 2022
In T4466#124827, @florin wrote:
Wow, well done! You don't happen to have an ISO you could share?
vyos@gw:~$ show version
yes, I had to do a bit of hacking - i.e. use the 1.4 kernel configs and patches, removed the wirguard-modules package, install the backports open-vm-tools version.
I committed those changes in my fork:
https://github.com/vyos/vyos-build/compare/equuleus...fvlaicu:equuleus
Did you then end up with a fully working nic, bridging included?
Jun 19 2022
We don't have such option client-hostname in dhcpdv6.leases
Jun 18 2022
Tested and works correct. Thanks @jestabro
PR: https://github.com/vyos/vyos-utils/pull/4
Adding the additional validator to policy.xml.in allows the smoketest (above) to pass.
Jun 17 2022
One approach is linked below; to be discussed before PR.
https://github.com/vyos/vyos-utils/compare/master...jestabro:increment-decrement?expand=1
I hope it can be found. I have been banging my head against the wall with this issue :( and it's hurting.
load-balancing wan completely broken with nexthop dhcp for 1.4 (it happens after first reboot or renew)
The script gets empty values there https://github.com/vyos/vyatta-wanloadbalance/blob/a831f22d4c34bf947b0335e55573280b75c2bde0/src/lbdecision.cc#L180
So ip route replace table is never executed
Why does it get an empty value?
It parse lease file https://github.com/vyos/vyatta-wanloadbalance/blob/a831f22d4c34bf947b0335e55573280b75c2bde0/src/lbdata.cc#L335-L341
option new_routers and in 1.4 the file looks as
Jun 16 2022
i've checked this issues, it seems to be solved . I think that it was solved for another task. I used the following vyos version :
I'm also trying to get this up and running. The latest 5.4 kernel fixes this issue, but other issues remain, like bridging not working.
Instead of backporting the driver, I ended up backporting the lataest 5.10 kernel to the 1.3 branch.
Ongoing activity:
1. Stabilization - I have seen a corner case that would crash inside the northbound callbacks. - I can see some validation failure logs, although the resulting output seems good for me. - Daniil was concerned about memory leaks associated with iteration state. After additional research - this is not a problem, but I can imagine cases where we would fail to handle a malformed XPath and leak resources on the stuck unwinding I need to do some testing with Valgrind. 2. Scale testing 3. Async support for multiple vtysh clients. The current demo assumes that there is only one client. I want to map the iteration state to the vtysh client/socket so multiple requests may be executed in parallel 4. A debugging instruction I have used some complicated debugging flow when merging the feature. This should be useful for other (non-C) devs. 5. Finishing the documentation 6. advanced XPath filtering support?
Recently, I had a conversation with the VMware team lead - Pushpasis Sarkar.
He has described the ongoing development and explained the use case they are interested in.
From the conversation:
1. The latest proposal draft: Page 72-73 `Retrieve Operational Data - Retrieving Containers and Leaf members` Page 84-85 `Retrieve Operational Data - Retrieving Large List elements` + comments Page 86 `Retrieve Operational Data - Retrieving Containers and Leaf members` + comments.
I have also hit this into the latest rolling version:
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1364
I think it should check this parameter per commit and it is a bug with validation as we don't have a tunnel interface yet
But after commit it will be valid value
PR https://github.com/vyos/vyos-1x/pull/1363
vyos@r14# set service webproxy url-filtering squidguard source-group fdsf-dg [edit] vyos@r14#
It seems issue with this validator https://github.com/vyos/vyos-1x/blob/1978946312a36f4913e1e5ea7754668b1c653d09/interface-definitions/service_webproxy.xml.in#L487
route-maps support a relative adjustment of the metric (https://github.com/vyos/vyos-1x/blob/current/interface-definitions/policy.xml.in#L1402-L1417)
@kroy Are you still having trouble with it?
Jun 15 2022
Jun 14 2022
Since in previous version set protocols nhrp tunnel tun0 cisco-authentication "" was allowed, a migration script is required. Otherwise, when upgrading, configuration fails.
Jun 13 2022
PR https://github.com/vyos/vyos-1x/pull/1358
set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check target '192.168.100.1' set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check timeout '10' set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 check type 'icmp' set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 interface 'eth1' set protocols failover route 203.0.113.1/32 next-hop 192.168.100.1 metric '2'
Working on moving groups to named set as part of a refactor in some firewall code.
Jun 12 2022
Thanks for the pointer, but I think it should still be considered a "bug" that you can no longer use an empty group (I'm just going to assume that this would apply to any kind of group, but most are probably using this for host/network groups, as this is where it would be most useful). Judging from the comments in T4147, I'm clearly not the only one who was taking advantage of managing sets outside of the system. Alas, my boot times for 1.4 (what this discussion is about) are not really valid, as my configuration didn't really get migrated from 1.3.1->1.4, or better said, it doesn't actually commit, and I actually ended up with a mostly empty firewall config on boot, which is perhaps why its booting so quickly now.
Tested with VyOS 1.4-rolling-202206100921
Works as expected
Described in the documentation
Tested in VyOS 1.4-rolling-202206100921
The problem seems to be in these lines:
Jun 11 2022
Extra checks are needed not only when attaching a policy route to an interface, but also when attaching firewall.
For example:
vyos@vyos# set firewall name FOO rule 10 action accept [edit] vyos@vyos# set firewall name FOO rule 10 destination group address-group NOAG [edit] vyos@vyos# commit