- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Sep 8 2022
Created pull request with fix. https://github.com/vyos/vyos-1x/pull/1527
I've tested this and it seems to work correctly.
The interface naming is incorrect after this change for the second interface with the same VRID. It breaks show int.
Sep 7 2022
@aserkin Could you create a PR?
As @zsdc says, it's not enough to just have the driver, the problem is that it doesn't work with MTUs over 1460, and VyOS now tries to force it to 1500 if it's not specified. We need to adjust that logic so that MTU setting error doesn't cause a commit error.
I'd suggest adding
**Restart=always RestartSec=10**
to /usr/share/vyos/templates/telegraf/override.conf.j2 as it is done for ntp.service.
Otherwise the telegraf service do not start - it does 5 start attempts very quickly during boot with error:
Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Failed with result 'exit-code'. Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Scheduled restart job, restart counter is at 5. Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Start request repeated too quickly. Sep 07 11:43:59 vyos-lns-1 systemd[1]: telegraf.service: Failed with result 'exit-code'.
and stays in a failed state.
see boot log attached.
Sep 6 2022
Changes for the inversion operator (--not-range instead of !) have been made. Generalizing exit codes, as suggested in PR comments will be handled in a separate task.
The PR:
The [email protected] seems to work well after the fix. We should backport this to the equuleus as well.
As we have threshold it seems require migration threshold => threshold general
vyos@r14# set service ids ddos-protection threshold Possible completions: fps Flows per second mbps Megabits per second pps Packets per second
Sep 5 2022
PR https://github.com/vyos/vyos-1x/pull/1521
set system update-check auto-check set system update-check url 'http://192.168.122.14:8080/download/image-version.json'
PR for VyOS 1.3
When the interface of the bridge registers VLANs, the bridge itself must register the same VLANs at the same time, otherwise the bridge will not forward VLANs
Resolved in T4664: merged in Sagitta; backport candidate for Equuleus 1.3.3.
vyos@vyos:~$ sudo bridge -c vlan show
port vlan-id
eth0 10
20
eth1 10
20
br0 1 PVID Egress UntaggedThe smoketest seems suspect, the error line has nothing to do with this issue and running the smoketest several times results in tests passing/failing arbitrarily on that line (across multiple tests).
It seems can't pass smoketest
05:47:04 DEBUG - ====================================================================== 05:47:04 DEBUG - FAIL: test_add_multiple_ip_addresses (__main__.BondingInterfaceTest) 05:47:04 DEBUG - ---------------------------------------------------------------------- 05:47:04 DEBUG - Traceback (most recent call last): 05:47:04 DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/base_interfaces_test.py", line 109, in tearDown 05:47:04 DEBUG - self.assertFalse(process_named_running(daemon)) 05:47:04 DEBUG - AssertionError: 8769 is not false 05:47:04 DEBUG - 05:47:04 DEBUG - ------------------
Sep 4 2022
PR for VyOS 1.3 https://github.com/vyos/vyos-1x/pull/1519
Sep 3 2022
PR for 1.3 https://github.com/vyos/vyos-build/pull/260
Initial draft; suggested changes and testing to follow:
In T3900#133375, @Viacheslav wrote:Regarding interface groups it will be possible later, after firewall re-design
Sep 2 2022
In case anyone comes across this bug report, I submitted a couple PRs to fix this earlier this year: https://phabricator.vyos.net/T4245
I've submitted a PR to reintroduce the patch: https://github.com/vyos/vyos-build/pull/259
@daryll-swer For your use case, you can use your tables/chains (not standard names like RAW/MANGLE INPUT/OUTPUT etc.), that won't be cleared by the VyOS firewall CLI
nft add table MYRAW
nft -- add chain ip MYRAW my_chain '{ type filter hook prerouting priority raw; policy accept; }'
nft add rule ip MYRAW my_chain ip saddr 192.0.2.5 counter dropIn case of filtering on a VRF, would it be an idea to use the MAC address instead of the interface name in the rule?