Mon, Aug 23
@Viacheslav this ticket can be closed.
Jul 13 2021
May 12 2021
Yes the point of "longer-prefixes" is to find smaller routes within a bigger netmask, so if you're leaving out prefix, it doesn't make sense.
May 9 2021
May 4 2021
Apr 12 2021
Apr 9 2021
Mar 29 2021
Mar 11 2021
just tested - 1.2.6-S1 - it is still working as described by ciprian.craciun
Mar 2 2021
ipsec policys, policy prefix-lists,
Mar 1 2021
I vote for option 1.
Feb 18 2021
I believe this is the behavior in 1.2.6 aswell?
And I think its not even possible to reset one peer?
So, reset vpn ipsec-peer XXX is broken
as well as reset vpn ipsec-peer XXX tunnel YYY
Sep 25 2020
I would also like to add that wouldn't it make more sense to set the protocol mode under host aswell rather behind "facility".
Sep 21 2020
Notice how my loopback interface with mask /32 does *not* show /32 in route table local.
@Viacheslav does that PR check for x.x.x.x/32 ? Because the ip route show table local does not contain the netmask /32. While ip route show table 254 actually shows the prefixes with /cidr notation.
Aug 26 2020
Is probably fixed in https://phabricator.vyos.net/T1291 according to cpo on slack
Aug 25 2020
Aug 17 2020
This is not solved in 1.2.6-epa1. Will this be solved in 1.2.6?
Jun 25 2020
Going to mention this in here:
Jun 24 2020
Jun 15 2020
This config was lost after first boot. Ping T2598
When googling on the error given, T109 shows up where I had posted about this in 2018. I'm not sure it's related to this. Im not sure any configuration has been lost on reboot.
Feb 21 2020
Jan 7 2020
Nov 22 2019
From CPO on Slack:
Nov 21 2019
Nov 13 2019
Oct 10 2019
@hagbard via a route-map for example. set policy route-map TAG rule 10 set tag 33
Oct 4 2019
Any reason extcommunity-list and community-list doesnt support the same naming scheme?
Aug 12 2019
@Dmitry, thanks for reply.
May 3 2019
As per request from dmbaturin on slack:
May 2 2019
Nov 15 2018
Nov 13 2018
there's a problem when naming firewall network groups and port groups to the same name, and then later deleting one of them. Maybe thats related to this one.
this seem to be solved since moving to frr.
Jul 12 2018
Jul 10 2018
Thanks for pointing that out, I tested manually aswell again on both 1.1.7 and 1.1.5.
Nov 16 2017
Nov 7 2017
Nov 3 2017
I just ran a test on http://dev.packages.vyos.net/tmp/vyos-1.2.0-alpha-frr-test.iso
OSPF now works as intended in this particular setup. The ABR now sends LS Update type 3 into core.
Oct 3 2017
Sep 12 2017
I guess that you are referring to the installation of VyOS, as a proper installed system will automatically boot up. At least last nights build does.