is that still an issue in the latest rolling image?

@sentania http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.19.1+vyos2+current9_all.deb or next rolling release will have it patched. It was just not implemented in the backend, so the parameter was never read from the cli.

looks like even if not listed it can be set, but not applied via cli. also need to test if it works.

Looks like the 7.1-dev frr branch is eiter not up to date or the frr documentation isn't updated.

bug confirmed.

Awesome, thx for letting me know.

@joshua Can you please create a PR in github for this please, then you can post the reference here. thanks.

Sorry I can't merge it, no write access for me.

I don't have write access, I created a PR and assign the task to @UnicronNL to review and either merge or reject.

Does it cause issues? I'm about to remove it from the code, juts want to find out if it is something urgent.

set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 distance '100'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 next-hop-interface 'eth3'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 distance '200'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 next-hop-interface 'eth2'

I see, thx.

@zsdc Is that even require in table, doesn't the below work?

https://github.com/vyos/vyatta-cfg-quagga/commit/468e19f564023771d774ee32ccffc4ccffed897c should fix the discovered issue. It can be imported to table as well.

I found an issue which prevents the implementation:

@rodge.liu I think that might be the issue. I have seen similar behavior on DHCP set interface when the DHCP take quite some time to reply.

successfully tested on:
Version: VyOS 1.2.0-rolling+201905081347
Built by: autobuild@vyos.net
Built on: Wed 08 May 2019 13:47 UTC
Build ID: 7093c43d-6ea7-45c9-a7c5-3fdf07c0ebc7

Will be in the next rolling available.

As a work around do either:

@Maetthi You reach 10.52.192.174 via router 10.52.192.9, is that correct in your config example above? If so, did you try to capture the traffic on 10.52.192.9 for .14 and 174?
I've used your example above, however on vm's only and changed your /29 to a /24 and didn't find any problems. So the question is if you can see on .9 the SCC* messages?

Only when you create an address, can be via dhcp or manually.

https://github.com/vyos/vyatta-cfg-system/blob/current/templates/interfaces/ethernet/node.tag/address/node.def#L10

I can't reproduce, tested live and installed.

https://github.com/vyos/vyos-1x/commit/6d848ec832d2911db487a2b04235759971022d47

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html#bandwidth-shaping

next rolling will have the fixed version.

I had mixed results with the dhclient part, but that's not the major issue and April 25 iso should have the refactored script on board. I see exactly the same issues with netplug you see, it went a few rolling iso's back to test with but couldn't determine yet when it has started. Even an ip link set up dev <device> doesn't bring the interface back up. netplug get the status information via the netlink interface from the kenrel, so I'm going to start looking there to see if anything has changed. Going forward, I think systemd-networkd will be the successor sooner or later anyway, I gotta play around with it at one point anyway. It usually monitors the interfaces via netlink as well, but has more filters and rules you can therefore apply.
I'm still not too sure why it sometimes breaks and sometimes works, I didn't find anything useful in the log too, only the information we have already.
I was using esxi 6.7.

https://github.com/vyos/vyos-1x/commit/dcb9f521f9f6dbb98df8f644009c05342f596b5a

Looks like a race condition, since it is now being started by systemd as well, which was previously not the case.

@yun I think I found something, vmware-tools won't even call ether-resume.py, it only does sometimes and sometimes not. I tested it with 1.2.0-rolling+201904240337 and did a suspend and resume multiple times with the old ether-resume.py and everything is just working fine.

But there was before a fully working one, anyway curl will work as well. Let's close this ticket then, was just bad communication I guess. I have found a few other issues, I'm currently looking into. Looks like netlink in the kernel changed, breaks netplug and pppoe-server. Thanks for pointing me into the right direction.,

wget https://downloads.vyos.net results in 'not an ftp or http url'

wget https://...
or if you check with ldd you'll see that it is only compiled against libc and that's it.

Check for the /var/log/vmware-network.log files, the tool creates for each type a log and rotates it once the command finished.

here you go: https://github.com/vyos/vyos-vmwaretools-scripts/commit/7b5f9514a17afdf136b04087a5b76a7943d9060c

Ok, just reopen the PR. I'll review and merge it in then.

Ah, I see. You didn't mention that, so I was quite confused about your statement.

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?

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.

@zsdc Can you please test?

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.

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.

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

@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?