1.1.8 followup

by Daniil Baturin

LLDP bug

James Brown reported on phabricator that LLDP is not working in 1.1.8. Quite a mess up on our side: the reason it's not working is that it's built against the old OpenSSL 0.9.8 which is no longer in VyOS, but since the debian/control was missing dependency on libssl, it wasn't detected as dependent on OpenSSL and thus wasn't rebuilt.

If you want LLDP back right now, you can install the helium3 package from our repository (http://dev.packages.vyos.net/legacy/repos/vyos/pool/main/l/lldpd/).

OSPF route-map

One feature is missing from the changelog because it was committed "stealthily", without a task number, and thus I missed it. It's the command for setting up route-map for installing routes imported from OSPF.

set protocols ospf route-map MyMap

This route-map can prevent routes from getting installed into the kernel routing table, but make no mistake, it is not incoming route filtering (which would be very bad for OSPF). The routes will stay in OSPFd and in the RIB (they will be displayed as inactive).

The future of 1.1.x

So far it looks like we are going to make an 1.1.9 release to fix the LLDP bug. Perhaps we should also cherry-pick something safe from 1.2.0 too, if you have any specific bugfix or a tiny feature is mind, let us know.

VyOS 1.1.8 on AWS

The official 1.1.8 AMI passed the automated tests and it's on its way to the marketplace, the manual review by the marketplace team will take perhaps a week or so.

If you want to make you own, you can already use the AMI build scripts and point it to the (signed) release image URL.

And while we are at it: IPv6 in VyOS 1.2.0

I've re-enabled the old patch for IPv6 VRRP in the current branch and it will be in today's nightly build. In 1.1.x, we had to disable it because in the older keepalived version IPv4 and IPv6 VRRP were mutually exclusive, however, in the current branch, it seems to work. If you feel adventurous, please test the nightly build (on lab VMs!) and tell us it it works for you.

Also, on the forum, it was reported that the current branch image doesn't build. I've resolved that problem today so if you want to build an image, it should work.

Upvote Upvoted 6
19 responses
I'm not sure of the current status of things, but I'd love to see strongswan 5 backported to VyOS 1.1.x. I have not been able to build a remote-access IPSEC VPN from local Mac AWS EC2 VyOS instance due to a NAT-on-each-side issue, and my understanding is that the newer strongswan as included in EdgeOS should fix that.
— Chris M
Chris: I don't think we can make it happen. StrongSWAN 5 support was a really big change. If you want to have it sooner, you should help us test the 1.2.0 nightly builds.
— Daniil Baturin
Thanks for the update! I haven't tried 1.2.0 nightlies in at least 6 months, are they buildable and usable via EC2 AMIs yet (they failed last I attempted it)?
— Chris M
Not yet buildable as AMIs, but I'm working on it. Cleaning up our current AMI build scripts and making them easier to use was essentially a first step.
— Daniil Baturin
Also VRRP not working: all node results master
— marco
Marco: I tested VRRP and it works for me. Please provide more details in the task.
— Daniil Baturin
Hi Daniel: It seems not to works between appliance mixed x64 and x32. On 1.1.7 all is OK also between x64 and x32. Also It works if master is on 1.1.8 x64 and backup on 1.1.7 x32... But if I upgrade the backup-node to 1.1.8 x32 it always set himself as master... follow this on https://phabricator.vyos.net/T459. Thanks
— marco
I am using vyos-999.201710310534-amd64 with VRRP in a VMware environment (non-RFC 3768-compliant) and it works fine. The only minor issue I know of is "show vrrp" shows yes under RFC Compliant when I have not configured it to be RFC Compliant.
— Steve Palmer
I can also confirm that VRRP with one node on vyos-999.201710310534-amd64 and the other on 1.1.7 is also fine as this was my upgrade path.
— Steve Palmer
Hi steve, please read my full report on https://phabricator.vyos.net/T459 There is a screencast so that I can explain exactly what I mean.
— marco
When PPPoE is on the Internet, NAT is enabled, resulting in a large number of lost packets passing through the vyos
— gh0813
When PPPoE is on the Internet, NAT is enabled, resulting in a large number of lost packets passing through the vyos
— gh0813
issue with /var/log/auth.log (ipsec logs filling up disk space) still exists, a log rotate entry is set up for /var/log/vyatta/ipsec.logs but this only contains stdout from pluto which doesn't log very much, still with ~ 20 tunnels the /var/log/auth.log fills up all available disk space very quickly
— Russell
6 visitors upvoted this post.