User Details
- User Since
- Apr 2 2018, 11:24 PM (353 w, 3 d)
Oct 12 2018
I had already created a task for a new syntax and linked it as a related task, would you like me to create a new separate one?
Oct 11 2018
You're probably right. I thought I had a potential conflict if it started first, but now I can't think of what it was. Maybe there wasn't a conflict to begin with.
Being able to apply both an interface and next hop to the same route would still be extremely useful though, but could be slated for later I guess.
There is still the question of why FRR can't figure out what to do with separate interface routes in the same table.
@UnicronNL
Yes. It's a double issue actually. Hopefully this explains it better:
- The next-hop based routes in the alternate routing tables seem to be unaware of interface routes in the same table.
- VyOS command syntax cannot currently specify both a next-hop and interface for the same static route, despite FRR being able to do so.
- FRR will attempt to add an interface to a next-hop route (based on which interface has a subnet that includes the next hop) automatically, but this information is not preserved in the VyOS config file.
- Since FRR starts prior to VRRP (keepalived); interfaces with ONLY 'virtual' addresses will not receive FRR's automatic interface detection because they do not have a subnet when the route is created. This renders the routes unreachable and FRR does not refresh their status.
Further examination of this issue indicates that some of the behavior may be caused by FRR starting prior to VRRP on boot, and backup VRRP routers with VIP only interfaces.
Sep 21 2018
Sep 15 2018
Sep 8 2018
Sep 6 2018
Sep 5 2018
Sep 4 2018
Aug 30 2018
Pull request: https://github.com/vyos/vyos-1x/pull/47
I believe /usr/share/vyos/interface-types.json needs to be patched to handle wireguard interfaces so that they show up in show interfaces. Scratch that, it's there, but they don't seem to appear in show interfaces.
Aug 24 2018
Fantastic, thank you for your hard work.
It seems wireguard will handle MTU changes beyond the default 1420 on its interfaces cleanly. Can I suggest that the MTU be made modifiable under set interfaces wireguard wg0 mtu <size>? This would be nice for situations where fragmentation between wireguard peer connections is acceptable.
May 11 2018
With install_routes disabled so that VTI works I've managed to recreate the route for prefix based tunnels using iproute2.
ex: ip route add <remote_prefix> via <default_route> dev <ipsec_interface> table 220 proto static src <local_prefix_addr>
It seems we already have all the required information to manually create the routes outside of strongswan.
This would mean that VTI and other IPSec tunnels could co-exist.
May 10 2018
@c-po install_routes = 0 can be added to any strongswan.conf (/etc/strongswan.conf, /etc/strongswan.d/*) file as long as it's inside the charon section I believe.
May 5 2018
Apr 29 2018
Apr 3 2018
Initial observation was wrong. Field headers do not seem to match to values.
Decided to take an actual look at the script. Seems to be a change in pmacct's output, specifically new fields between TOS ($tos) and PACKETS ($pkts).