set protocols bgp address-family l2vpn-evpn vni 100070 route-target both 70:100070
Should return an error, as this is not implemented.
set protocols bgp address-family l2vpn-evpn vni 100070 route-target both 70:100070
Should return an error, as this is not implemented.
I was wrong. NOT 6 CHILSD_SAs on one tunnel.
6 IKE SAs on one configured tunnel.
I met 2 issues after the last commit.
My config:
Awesome, I am glad to hear the provided info was helpful! Thank you for the quick investigation and explanation.
Again, thanks for the detailed reproducer; that made investigation straightforward. This appears to be simply an 'async' issue for FastAPI, the underlying web framework for vyos-http-api. FastAPI is very good at managing red/blue issues automatically, but in this case we need to explicitly annotate the endpoint method with async: an explicit lock does not appear necessary, though I will need to confirm. I'll provide a PR shortly. Thanks again !
Thanks Keving: https://vyos.dev/T5009
Error still present in 1.4: https://vyos.dev/T5004
FYI When I was troubleshooting I used:
In Both version, restarting relay service solved the issue:
PR with a fix: https://github.com/vyos/vyatta-cfg/pull/61
I can confirm this behavior, which occurs when changing IP address on listening interface (where dhcp-discover is captured).
Issue present in 1.3.2 .
It's also present in latest vyos-1.4-rolling-202302140317, regardless if old interface syntax is used, or if new upstream-interfces plus listen-interface commands are used.
@ammmze Thanks for the detailed report; allow me to investigate.
Here's the commands I ran for node-exporter:
https://github.com/FRRouting/frr/pull/12364
riw777 merged commit 91b6db4 into FRRouting:master Feb 14, 2023
You can either run both address-families through one tunnel
Is there any kind of ETA on this? It hasn't moved in a few months, and it is preventing me from being able to upgrade. I understand this probably isn't a huge priority, but an ETA would be nice.
In T5004#142577, @n.fort wrote:Can you provide this configuration on both setups:
show config comm | grep relay # And route to relay server show ip route <relay_server>
Can you provide this configuration on both setups:
Then lets close it
I have prepared a configuration example using one of the latest 1.4 images, where more features were introduced.
Scenario and requirements:
Don't see any issue with 1.3
vyos@r1:~$ monitor bandwidth-test initiate 192.168.122.14 ------------------------------------------------------------ Client connecting to 192.168.122.14, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.122.11 port 58042 connected with 192.168.122.14 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 6.37 GBytes 5.47 Gbits/sec vyos@r1:~$ vyos@r1:~$ show version
Everything works on version 1.4
In T4774#142529, @c-po wrote:Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Keys should not be re-used
Please note the WireGuard crypto Key routing concept: https://www.wireguard.com/#cryptokey-routing
Everything just worked fine.
service {
+ pppoe-server {
+ authentication {
+ mode radius
+ radius {
+ server 172.31.255.2 {
+ key 123456
+ }
+ }
+ }
+ interface eth1 {
+ }
+ }
}Sorry about the trouble - fixed in next rolling release.