Tested and works correct. Thanks @jestabro
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 18 2022
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
Jun 10 2022
Fix Regex for addresses and python ckecks https://github.com/vyos/vyos-1x/pull/1354
Indeed, I figured that out. I also found that my openvpn config was not migrated properly (T3642?); all of the tls configuration stuff (previously kept under /config/auth somewhere) was gone. After doing run import pki for all of the necessary bits it was able at least to commit openvpn properly.
Same as Viacheslav. No issues on my tests in Ubuntu.
- Some domains can't be added, for example dns.google
vyos@r12# set firewall group domain-group DOMAINS address dns.google
Fix smoketest https://github.com/vyos/vyos-1x/pull/1352
Yes. New 1.4 has more restricted checks on addresses and networks.
Actually, if you are using /22, the correct network for this case is 192.168.44.0/22.
You can use this online tool for checking ipv4 networks and subnets.