To verify that it isnt something in your 5G modem that triggers this behaviour try to put a L2-switch in between and then simulate a link failure between VyOS and this L2-switch and see how things behaves?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 25 2023
I've tested this issues in our lasted rolling-realese , after last commit , it seems works without problems :
vyos@vyos# load test.conf Loading configuration from 'test.conf' Load complete. Use 'commit' to make changes effective. [edit] vyos@vyos# compare [policy] + route-map TEST { + rule 10 { + action "permit" + set { + community { + add "65001:1" + } + large-community { + add "4200000000:100:1" + } + } + } + }
Used one of the latest rolling releases.
Configured the Radius server and VyOS
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2402
This is causing smoketests on the nightly builds to fail
DEBUG - Traceback (most recent call last): DEBUG - File "/usr/libexec/vyos/conf_mode/nat66.py", line 127, in <module> DEBUG - generate(c) DEBUG - File "/usr/libexec/vyos/conf_mode/nat66.py", line 101, in generate DEBUG - render(nftables_nat66_config, 'firewall/nftables-nat66.j2', nat, permission=0o755) DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 142, in render DEBUG - rendered = render_to_string(template, content, formater, location) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 111, in render_to_string DEBUG - rendered = template.render(content) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1301, in render DEBUG - self.environment.handle_exception() DEBUG - File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 936, in handle_exception DEBUG - raise rewrite_traceback_stack(source=source) DEBUG - File "/usr/share/vyos/templates/firewall/nftables-nat66.j2", line 28, in top-level template code DEBUG - {{ config | nat_rule(rule, 'source', ipv6=True) }} DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/template.py", line 660, in nat_rule DEBUG - return parse_nat_rule(rule_conf, rule_id, nat_type, ipv6) DEBUG - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG - File "/usr/lib/python3/dist-packages/vyos/nat.py", line 58, in parse_nat_rule DEBUG - oiface = rule_conf['outbound_interface']['interface_group'] DEBUG - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^ DEBUG - TypeError: string indices must be integers, not 'str'
Plenty of nat66 related errors from last nightly build:
Oct 24 2023
exactly , i'll give an example of what is the improving (or new cli) , we have a policy where we can mach different DSCPs associate with REAL TIME or VIOCE . Current in our cli , it would be something like this :
Using VyOS 1.5-rolling-202310220123.
I think the commit made by yzguy is referencing the wrong task-id.
Checked in VyOS 1.4-rolling-202310030309
LEFT router configuration
So, do you want to add a new syntax to archive the same behavior that we have for qos policy ?
The global state-policy was dropped from CLI.
Close it for now.
Oct 23 2023
this case was resolved lasted configuration done .
this task is a re-definition from a traffic class , I think it could be more clear if we separate tc-filter in a class-map , so we can define different profiles in our cli based on services :
For RQ for Sagitta: https://github.com/vyos/vyos-1x/pull/2399
1.5 should not have such issues.
1.4: op-mode should be working as expected. Backport for https://github.com/vyos/vyos-1x/pull/2344 failed. I'll submit PR for 1.4 for such feature.
Oct 22 2023
Hi all, looks like that thanks to: https://github.com/acassen/keepalived/issues/2296, keepalived upstream repository fixed this issue with commit: https://github.com/acassen/keepalived/commit/81eb41fb12afe6ef56a6fd79cd4cb3cb5362c34b