The usual procedure is to create a route-map that sets the nexthop to a blackholed address if the advertisment has a specific community string set.
So when a customer advertises an address (rather a /32 network) to you with that string set, it automatically ends up blackholed.

Fix applied in this commit:
https://github.com/vyos/vyatta-cfg-op-pppoe/commit/4330d41fcda30553ca1b3e2588d05eebdd59fc80

@hagbard Can you please test the steps I mentioned mentioned here, to see if you can reproduce: https://phabricator.vyos.net/T1028#35591
Without any modifications to any scripts, it will bring the interface into permanent down state after suspend and resume.

It should work, at least it does for me. ether-resume is my script, it just makes sure that dhcp is called when it was configured, if not is just call the interface up and reapplies the IP address. Routes should be in frr anyway and with the interface up again, these would become active again as well. Netplugd calls scripts on event, up and down and doesn't call anything within open-vm-tools.

Please test with latest rolling image before VyOS 1.2.2 is released

To complete this, the corresponding changes need to be made in vyatta-cfg-system; these are straightforward and will be pushed to current. However, there is another mechanism whereby the console speed is explicitly being set to 9600: the vyatta-config-migrate script, called during system initialization, is invoking migrate/system/3-to-4, which sets the console speed; this will require some discussion as to how to best address.

Thank you for providing the necessary clarity that was lacking in your very misleading first response.

suspend shouldn't be supported at all?
@c-po @hagbard @dmbaturin you thoughts on that?

You have not provided a procedure on how to reproduce the issue and there are no other reports on such problem, therefore this task has low priority.
Either it's something specific to your environment or you have issues with upstream DNS and/or network

I don't understand "needs testing" here at all? What testing? How can I help? For me this is obviously high priority, in fact it's a deal-breaker, it's a problem I need to solve. As I think it would be for you if you had the bug on your network. I thought maybe the vyos team would also consider it high. Why low? Seems important that dns fails regularly. Why isn't it? (I have a solution that works but it's a selfish one that doesn't help vyos).

Attempt two of the fix, so disregard everything in above attempt.

I have a working fix, which is comprised of earlier suggested fixes I mentioned in T1028 and T894:

I want to set this ticket back to "Needs testing" or even "Open", I have downloaded and tested vyos-rolling-2019-04-16 and it seems it is not properly fixed.

ok, that was a test for new statuses
so we can track backport process better

Backport is done already by me

I can not test it due to lacking KVM environment. All good on ESXi.

The new syntax will be:

Package now included in VyOS builds - please test

How to build:

$ git clone https://salsa.debian.org/kernel-team/ethtool.git
$ cd ethtool
$ git checkout debian/1%4.19-1
$ dpkg-buildpackage -uc -us -tc -b
$ ls -al ../ethtool_4.19-1_amd64.*
-rw-r--r-- 1 vyos_bld vyos_bld    992 Apr 21 08:32 ../ethtool_4.19-1_amd64.changes
-rw-r--r-- 1 vyos_bld vyos_bld 113986 Apr 21 08:32 ../ethtool_4.19-1_amd64.deb

Using ethtool 4.19 results in:

vyos@vyos# sudo /sbin/ethtool -K eth0 gso off

We use ethtool provided by Debian Jessie (3.16) which is bound to 3.16 Linux Kernel.

EdgeOS uses this node.def file:

Proposing a Cisco like interface:

Already in 1.2.1

I wasn't aware that there was an aws target for the vyos-build scripts.

1.1.8

vyos@vyos# show service dhcp-server
 disabled false
 shared-network-name foo {
     authoritative enable
     subnet 10.10.10.0/24 {
         default-router 10.10.10.254
         lease 86400
         start 10.10.10.10 {
             stop 10.10.10.50
         }
     }
 }

This can not be backported easily to 1.2 (crux) b/c of jumps in the system@ config version string.