also it would be good if WLB function will control main routing table, that would help to avoid a lot of confusion with protocols static configuration& WLB function. Current documentation does not telling anything about how exactly protocols static 0.0.0.0/0 route must be set with WLB.
From what I had tested:
1)WLB creates additional routing tables and setting PBR rules
2)without protocols static route 0.0.0.0 with next-hops to every wlb GW local vyos traffic would not work(as would not work traffic to vyos)
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 4 2022
Aug 3 2022
It sounds like people prefer jool, and in my personal opinion, if there is a package that is still active up to now, like jool, then jool is probably better. But whatever it is, it's foreign to me
PR https://github.com/vyos/vyos-1x/pull/1457
set nat66 destination rule 10 destination address '2001:db8:1111::/64' set nat66 destination rule 10 inbound-interface 'eth1' set nat66 destination rule 10 source address '!2001:db8::6/127' set nat66 destination rule 10 translation address '2001:db8::444' set nat66 source rule 10 destination prefix '2001:db8::2/128' set nat66 source rule 10 outbound-interface 'eth1' set nat66 source rule 10 source prefix '2001:db8:1111::/64' set nat66 source rule 10 translation address 'masquerade' set nat66 source rule 20 destination prefix '!2001:db8::6/127' set nat66 source rule 20 outbound-interface 'eth1' set nat66 source rule 20 source prefix '2001:db8:1111::/64' set nat66 source rule 20 translation address 'masquerade'
Also I had tried to assign IP addresses directly to wan interfaces to test if it's somehow related to usage of vrrp combined with WLB- it does not work.
Aug 2 2022
PR https://github.com/vyos/vyos-1x/pull/1456
vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp01 Container name "alp01" restarted! vyos@r14:~$ vyos@r14:~$ /usr/libexec/vyos/op_mode/container.py restart --name alp02 Error: no container with name or ID alp02 found: no such container vyos@r14:~$
Hi friends, I'm experiencing what appears to be the same bug. In my case, it's on a redirect on a vif subinterface on a bonding interface. So perhaps bug is not so much about PPPoE interfaces, so much as any interfaces that don't exist before the commit is done.
PR https://github.com/vyos/vyos-1x/pull/1455
curl -k --raw 'https://localhost/graphql' \
-H 'Content-Type: application/json' \
-d '{"query":" {\n ShowVrf (data: {key: \"foo\"}) {\n success\n errors\n data {\n result\n }\n}\n}\n"}'Getting data:
{"data":{"ShowVrf":{"success":true,"errors":null,"data":{"result":[{"ifname":"foo","operstate":"UP","address":"26:f6:35:05:7e:0a","flags":["NOARP","MASTER","UP","LOWER_UP"]}]}}}}Works as expected in a recent rolling (e.g. 1.4-rolling-202208021045)
Aug 1 2022
The root issue is wpa_supplicant shipped in Debian does not contain commit https://w1.fi/cgit/hostap/commit/?id=46c635910a724ed14ee9ace549fed9790ed5980b which adds a new configuration file option named:
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1453
@ajgnet If you have a way to limit the dynamic prefix to a known prefix, then using 1:1 NAT66 prefix translation should work (only the host segment is dynamic)
@c-po You haven't replied for a long time, please let me know if you have any other questions
To solve the issue with MTU over DHCP we can use some new options like mtu for example:
set interfaces ethernet eth0 dhcp-options mtu
If vrf not configured:
vyos@r14:~$ /usr/libexec/vyos/op_mode/vrf.py show
Traceback (most recent call last):
File "/usr/libexec/vyos/op_mode/vrf.py", line 89, in <module>
res = vyos.opmode.run(sys.modules[__name__])
File "/usr/lib/python3/dist-packages/vyos/opmode.py", line 118, in run
res = func(**args)
File "/usr/libexec/vyos/op_mode/vrf.py", line 84, in show
return _get_formatted_output(vrf_data)
File "/usr/libexec/vyos/op_mode/vrf.py", line 68, in _get_formatted_output
state = vrf.get('operstate').lower()
AttributeError: 'NoneType' object has no attribute 'lower'
vyos@r14:~$