The 2001:19f0:ffff::1 is the neighbour, it is accessible via the Kernel route and I'm able to pull routes from it. The setup is multihop. But I think you are on something. I think the peer should return the gateway as the next hop and not itself. I'm experimenting with Vultr and their setup is questionable, so this is just one more thing that they messed up. Anyhow, thanks for your help. Feel free to close the ticket.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 2 2021
May 1 2021
mii-mon was fine. Link was enabled on the switch and the link for the interface was up. But on the LACP was not enabled on the switch.
So I would exepect to see the sub interfaces from the bond as up but the bond has to be down.
I see no connected network in your FIB for 2001:19f0:ffff::1 I guess that's the reason.
Hmm, all other routes have longer prefixes, so they should take precedence. As far as I understand the priority is prefix length (longest first) -> admin distance -> metric. So, your explanation contradicts this unless I miss something.
Apr 30 2021
@c-po I have implemented a simple script in 1.4. It works normally, but I can't count the port and protocol information
This requires a fix to https://github.com/FRRouting/frr/issues/8403 first
@Viacheslav
set service dns dynamic interface eth0 rfc2136 greywolfe.family key '/config/auth/rndc.key'
should cause the following in ddclient.conf, but instead leaves it blank
password=/config/auth/rndc.key
@greywolfe Can you explain, which records/params do you expect?
Is that correct?
Will be adding the BGP op commands for it as well eventually...
Any chance this gets looked at? Probably 5 minute fix, since it's just an error of the config key not being assigned.
Apr 29 2021
Already in 1.4
set protocols bgp address-family ipv4-flowspec
Already in 1.3 and 1.4
Looks good on 1.4-rolling-202104280417:
Looks good on 1.4-rolling-202104280417 and 1.3-rolling-202104280642:
Already in 1.3.
ipv6 still in old format
A possible reason it tried to remove " neighbor 10.0.0.2 remote-as 65002" after " neighbor 10.0.0.2 interface peer-group foo"
But if we delete " neighbor 10.0.0.2 interface peer-group foo" it also delete and "" neighbor 10.0.0.2 remote-as 65002"
So it can't delete this string
@Dmitry Is it works if you include config as "global parameter" without patching?
Apr 28 2021
[email protected]:~$ show ipv6 route vrf all Codes: K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route
PR's for Equuleus, save frr configurations.
https://github.com/vyos/vyatta-cfg/pull/39
https://github.com/vyos/vyatta-cfg-quagga/pull/75
For crux we use parser of " ipsec statusall {peer}"
Output if IKE established and esp SA not installed
vyos@r2-lts:~$ sudo ipsec statusall peer-192.0.2.1-tunnel-vti | grep Connections -A 50 Connections: peer-192.0.2.1-tunnel-vti: 192.0.2.2...192.0.2.1 IKEv1 peer-192.0.2.1-tunnel-vti: local: [192.0.2.2] uses pre-shared key authentication peer-192.0.2.1-tunnel-vti: remote: [192.0.2.1] uses pre-shared key authentication peer-192.0.2.1-tunnel-vti: child: 0.0.0.0/0 === 0.0.0.0/0 TUNNEL Security Associations (2 up, 0 connecting): peer-192.0.2.1-tunnel-vti[3]: ESTABLISHED 12 minutes ago, 192.0.2.2[192.0.2.2]...192.0.2.1[192.0.2.1] peer-192.0.2.1-tunnel-vti[3]: IKEv1 SPIs: 0ab8c2ee5815350e_i 271fba46aab245da_r*, pre-shared key reauthentication in 29 minutes peer-192.0.2.1-tunnel-vti[3]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
PR for Equuleus https://github.com/vyos/vyos-1x/pull/823
Apr 27 2021
@joolli Re-check please it in any Linux system with the option "-I "
Is it different?
ping -I dum0 10.0.12.40
Works perfect in VyOS 1.4-rolling-202104260417
sa_data wrong format
vyos@r6-roll:~$ show vpn ipsec sa [[b'peer-203.0.113.2-tunnel-vti', 'up', '4m33s', '168B/168B', '2/2', '203.0.113.2', 'N/A', 'AES_CBC_256/HMAC_SHA1_96/MODP_1024'], ['peer-192.0.2.2-tunnel-vti', 'down', 'N/A', 'N/A', 'N/A', 'N/A', 'N/A', 'N/A']] Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal ------------------------------ ------- -------- -------------- ---------------- ---------------- ----------- ---------------------------------- b'peer-203.0.113.2-tunnel-vti' up 4m33s 168B/168B 2/2 203.0.113.2 N/A AES_CBC_256/HMAC_SHA1_96/MODP_1024 peer-192.0.2.2-tunnel-vti down N/A N/A N/A N/A N/A N/A vyos@r6-roll:~$
This bug is still present in VyOS 1.4-rolling-202104061143.
To reproduce the bug, we need to add a source nat rule first.
configure set nat source rule 100 outbound-interface 'eth0' set nat source rule 100 source address '192.168.0.0/24' set nat source rule 100 translation address masquerade commit save exit
Then if we try to list the nat tables with iptables iptables -t nat -L, we will get error like table 'nat' is incompatible, use 'nft' tool.
Next, if we use podman to create a container sudo podman run -d ubuntu:latest, podman will return the error because it will look up nat rules with iptables.
Work as expected on 1.4-rolling-202104260417
vyos@R1:~$ show dhcpv6 server leases IPv6 address State Last communication Lease expiration Remaining Type Pool IAID_DUID ------------------ ------- -------------------- ------------------- ----------- ----------------- ----------- ----------------------------------------------------- 2001:db8:290::/64 active 2021/04/23 14:52:48 prefix delegation VyOS-DHCPv6 00:00:00:00:00:01:00:01:28:15:9b:bd:50:00:00:06:00:00 2001:db8:3456::15b active 2021/04/27 05:07:51 2021/04/27 17:07:51 10:28:27 non-temporary VyOS-DHCPv6 00:00:00:00:00:01:00:01:28:15:9b:bd:50:00:00:06:00:00
Apr 26 2021
Fixed in
@Yuanandyuan Can you reproduce it with vyos cli? Or it raw podman commands?