Hmmm, yeah, this one isn't doing anything yet either - just a test.

I've closed your PR without merging, since it can't be the script. Shall I close this bug here for now and you open a new one when you hit the road bumps again?

This one is running on Hyper-V 2016 and is not pushing any traffic. It is my test router and experimenting with RPKI.
The routers doing traffic are on hardware and not running 1.2.x yet.

nteplugd is just fine. vmwaretoolsd tries to start (resume-vm) the interfaces via systemd-networkd (it looks for the interface files), then the ether-resume kicks in and starts the dhclient, so far so good. Netplugd isn't the issue here. I also have seen it 2-3 times, right now it works in the same environment I used yesterday. I think there might be some interference with systemd-networkd called by the vmware scripts.
If you observe it again, please let me know the image you used, so I can reproduce it better. Also, you should find /var/log/vmware-net.... logs on the sytem, they basically trace all calls from the vmware supplied scripts when you trigger an action via the vmwaretoolsd. If it happens again, let's have a look at these files.

Thanks for the detailed history, that makes things more clear.
So for me the latest rolling worked, do you know what part from networkd is interfering with dhcp for you? Did you see if netplug called dhcp correctly after resume?

Ah, Thanks Merijn!

@zsdc Can you please test?

I am running 1.2.1 compiled on 17-04-2019, uptime is 6 days without issue.
RIB entries 1366663, using 209 MiB of memory
Peers 16, using 330 KiB of memory
Peer groups 4, using 256 bytes of memory

My next step is to replace the VMWare image with the standard ISO I build at the same time, to eliminate vmtools. I tried reducing the open-vm-tools config statement:

I am also seeing a memory leak on a BGP full tables router. It is NOT using flow accounting, but IS a Crux 1.2.1 compiled VMWare image.

The garps should be send as they are being set per default to the values you have pasted from the documentation. Do you want to make that a config option to modify the defaults?

@zsdc Can you please share some config data or clarify what you mean? thx

I didn't changed anything. I did the netplug changes via T894 i think, I would have to look it up. The only change happened for the vmware-tools itself, we switched to the debian jessie package and now to the bpo jessie one.
That package contains the suspend and resume, poweroff and poweron scripts/structure. Netplug is entirely separate and the package comes from our pool. It contains a linkdown and a linkup scripts, which basically triggers the link up/down scripts which are the original vyatta ones, which came previously via vyatta-cfg-system or so.
So, there was basically a huge cleanup, plus making netplugd available again (was removed for an unknown reason before), repakage and the latest open-vm-tools plus the script we deploy for it for the resume/suspend mechanism.
So, right now I'm not sure how stable it is, please let me know if you uncover further issues, it should be logged via syslog so we have a chance ti investigate what it may does when it's blocked.

I wonder what changed then, will also test with latest rolling

The interference seems to come from networkd, which is executed via ./scripts/vmware/network resume-vm executed by vmware-toolsd. So that looks like a longer mission.

I left you a few comments on the PR. Tested it now as well, your code doesn't work from what I see. But I see that dhcp stopped working, I have a look and see what I can find out. Looks like netplugd in the latest rolling has an issue too.

PR: https://github.com/vyos/vyos-vmwaretools-scripts/pull/1/commits/92f5d450df4de09626af232bc5ced067a6493d6b

Fix, should be in the next rolling release:
https://github.com/vyos/vyatta-cfg-quagga/commit/41df1579f6ca3e5a1618ee85bbb337011148f1ef

Note that the mentioned annoyance of migrate/system/3-to-4 setting the serial console speed should be mooted by 'T805 Drop config compatibility with Vyatta Core older than 6.5'.

@yun yes, please create a PR, I have a look the asap.

@zsdc is local-as required anyway? Isn't it always the same as the router-as?

Ok final attempt and trivial fix.
It seems that changing run-parts to /bin/run-parts was not needed. So netplug works fine as it is.

Hi all, I can confirm that with vyos-1.2.0-rolling+201904160337-amd64, this issue is fixed.
If I boot the older 2019-02-16 version, the bug can be reproduced easily. So it must be an issue in FRR that is introduced in 7.1 as the newer livecd uses FRR 7.0:

Is this a FRR bug or something else? Because I don't use any BGP stuff I just added the ip -4 route add command to my VM, so it's always executed. However, as @runar mentioned, it will bypass FRR. But executing the command via FRR didn't work, so the issue must be in FRR?

Gonna keep the task open for a week or 2 to see if there are still any other issues.

It will be good to have ability to configure followed GARP settings for individual VRRP groups or, at least for keepalived daemon overall, becouse in some situation switches can filter multiple ARP-packets, that is generated on transition.
In the process of migration to 1.2.1 we have discovered, that some GARP packets (we have 6 VRRP-groups on Interner interface) was filtered with ARP-spoofing filter by our ISP.
Problem was solved with VRRP-migration scripts, that execute some additional arping in ARP-Reply mode.

@c-po thanks for that. I changed my configs from postconfig script to new config syntax

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).

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: