I see there is a duplicate task for this here - https://phabricator.vyos.net/T279

I can confirm the exact same issue.

I have managed to make some headway on this.

It's currently in BIOS boot mode.

I have had no luck with my testing and it seems that grub just can't seem to find the image to load.
I have tried different bios configurations, different hard drives, tried specifying "root=" in grub (was doubtful of this).
Nothing I have tried has managed to get it to boot.

I have just tried on vmware and it is installing and booting with no problem.

I have not tested it in a virtual environment yet.
It's being installed on a 32GB Satadom and it's using mbr.
1.1.7 installs and works 100%

I have tried this and I could not seem to get any data what-so-ever to go over the open fastpath interface, so I don't think it is a viable solution.

Here is a howto on the openfastpath - https://www.howtoforge.com/tutorial/opendataplane-with-open-fast-path-on-ubuntu/

Would the http://www.opendataplane.org/ and http://www.openfastpath.org/index.php/service/technicaloverview/ not work better in VyOS?
Use this to create a fastpath interface and the linux OS can just that.

Are those firwall names not still assigned to the interfaces?

I agree that DPDK would be a game changer for VyOS. It would nullify the Brocade 5600 vRouter and would make VyOS the absolute go to routing software for high PPS networks. I'm already seeing an increase in interest around the BSDRP router project which is using netmap (BSD's version of DPDK in simple terms). The point being that, as more and more networks move towards 10Gbit / 100Gbit networking, VyOS is going to lag behind anyone else who implements DPDK or netmap routing first.

The entire issue is a ripple effect of allowing the duplicate prefix into the same prefix list.
If we can prevent that, the route-map issue shouldn't occur.

Where is the updated vyatta-quagga packages ?

I was able to replicate this on my side in a lab.

What happens if you delete the prefix entry first and then delete the rule?

From what I understand from reading up on this, the "truncating" issue occurs when a 32bit value is being returned on a 64bit system.

The diff on the patch https://github.com/vyos/net-snmp/commit/01043209782cb786696e4dc20b9468e97d4f4acd

Looking from a sys-admin perspective, I think most would prefer being able to drop to shell when needed or preferred.

Looks like Centos created a patch for this - https://git.centos.org/blob/rpms!net-snmp/8a419fd557adfdc5e6efd8977f5fb7de7fa36f9f/SOURCES!net-snmp-5.7.2-dot3stats-log.patch

Happy to test, what are the current known problems?