PR https://github.com/vyos/vyos-1x/pull/1973
PR https://github.com/vyos/vyatta-wanloadbalance/pull/17
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Apr 28 2023
I made an attempt at integrating openvpn-dco into the build here https://github.com/spion06/vyos-build/tree/ovpn-dco. This works fine for me in my testing so far. The kernel module loaded, verified in the logs that it detected and used the dco tunnel. I'm not super familiar with the build system or what else would need to be done for contributing this. I'm just and end-user who would like to see this feature :)
Apr 27 2023
Your CLI config is valid in general but FRR will refuse it with the error message: This command is only supported under EVPN VRF
Dear Jestabro,
i built an updated docker image and a new ISO, i do confirm now IPv6 is working correctly.
Ok, if we merge the patch (backported to frr v8.5), this task can be close.
I think the only solution is to use network namespaces
https://docs.strongswan.org/docs/5.9/howtos/nameSpaces.html
Usernames usually take the following format: abc-1234-12
Passwords are a combination of alphanumeric characters.
In T5116#147640, @c-po wrote:Do you know how to tell Linux to use nameservers within a VRF?
What you mean IPSec/OpenVPN "punch a tunnel through a VRF" ? So the underlay should run via a VRF? source-interface binding does not work?
Apr 26 2023
Thanks for opening the task; note that Viacheslav had opened
https://vyos.dev/T5185
as well, and the updates on the now fixed issue can be found there. This task can be merged into that one and closed.
Merged and repos updated, so this will be in the next nightly build. Note that for a local build, one will need an updated Docker image for the update to vyos1x-config.
Do you know how to tell Linux to use nameservers within a VRF?
What you mean IPSec/OpenVPN "punch a tunnel through a VRF" ? So the underlay should run via a VRF? source-interface binding does not work?
This is a simple bug in the recently introduced configtree node name comparison function; fixed and should be in next rolling.
Do you have users/passwords with specsymbols or not utf-8 or some ascii symbols?
hmmm very strange.... here is my configuration (IP addresses removed):
Could you provide l2tp configuration? show conf com | match l2tp
I cannot reproduce it
vyos@r14:~$ vyos@r14:~$ show l2tp-server sessions ifname | username | ip | ip6 | ip6-dp | calling-sid | rate-limit | state | uptime | rx-bytes | tx-bytes --------+----------+--------------+-----+--------+---------------+------------+--------+----------+----------+---------- l2tp0 | alice | 100.64.203.0 | | | 192.168.122.1 | | active | 00:00:10 | 246 B | 208 B vyos@r14:~$ vyos@r14:~$ vyos@r14:~$ show version Version: VyOS 1.4-rolling-202304261027 Release train: current
@Viacheslav It hangs for a while and then eventually the following output:
@joshua.hanley Could you provide the output of the next command?
sudo accel-cmd -p 2004 show sessions
PR with dependencies: https://github.com/vyos/vyos-build/pull/341
Apr 25 2023
PR (for build): https://github.com/vyos/vyos-build/pull/340
Incorrect modify modify_section: starting search for '^vrf protocols' until '^exit-vrf'
vyos@r14# delete vrf name red vni [edit] vyos@r14# commit [ vrf name red vni 3000 ] {'name': {'protocols': {'bgp': {'address_family': {'ipv4_unicast': {'redistribute': {'connected': {}}}, 'l2vpn_evpn': {'advertise': {'ipv4': {'unicast': {}}}}}, 'system_as': '65001'}}, 'table': '3000'}} load_configuration: Configuration loaded from FRR daemon zebra load_configuration: loaded 0 ! load_configuration: loaded 1 frr version 8.5 load_configuration: loaded 2 frr defaults traditional load_configuration: loaded 3 hostname debian load_configuration: loaded 4 log syslog load_configuration: loaded 5 log facility local7 load_configuration: loaded 6 hostname r14 load_configuration: loaded 7 service integrated-vtysh-config load_configuration: loaded 8 ! load_configuration: loaded 9 vrf red load_configuration: loaded 10 vni 3000 load_configuration: loaded 11 exit-vrf load_configuration: loaded 12 ! load_configuration: loaded 13 end modify_section: starting search for '^vrf protocols' until '^exit-vrf'
Two cents from the fields. It will be nice to see vrf aware cg-nat solution, when subscribers from a number of "inside" vrfs NAT'ed into one outside vrf. Of course if that's possible.
Test case above produces:
Merged T5178 into this one; cf. the description there for background of the issue.
Apr 24 2023
PR for equuleus:
https://github.com/vyos/vyos-1x/pull/1969
PR for equuleus:
https://github.com/vyos/vyos-http-api-tools/pull/5
According to nft changelog, this feature is available in 1.0.7 in a much better way: