@krassle I added your patch. will be in next rolling release. thx

@c-po
Hello, unfortunately this issue is not fully resolved (tested in Crux 1.2.1) because the name of the shared-network is still prepended to the hostname in /etc/hosts by dhcp_server.py. It's hard-coded, but should be conditional to actually restore the old behaviour (before core rewrite), where (like @CBRjack described) a flag "disable_prefix" triggered by the "use-host-decl-name" option did prevent the old dhcp-config.pl from prepending the shared-network-name.

I've had this bug occur on 1.2.0-rc11, at one site (with moderately high load) at least once a day, and at the second site (with small load) only once after several months.
After upgrading to the latest 1.2.0 rolling release I've had no issues any more, however the bug may still remain.
It may have something to do with DNSSEC setting as the second system that ran flawlessly for months before started doing it immediately after setting dnssec=validate.

I've got a few more bits of information on this. I've managed to get DNS resolution to consistently work by placing the actual DNS servers in the dns section of my config instead of using just the system config keyword.

I just spawn a Smokeping to monitor the DNS server with a cache of 0 entries, lets see.

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

I'm currently running 1.2.0-201904160337 and I seem to have stumbled upon a similar issue, but this time with L2TP/IPsec links, which when come up fail to also configure their related static routes.

@syncer Which version of frrouting is VyOS currently built against?

I just had another go with vyos-1.2.0-rolling+201904260337-amd64 and no different. My board has igb not ixgbe (I think that is a different chipset)

@syncer Sorry for the delay.. life got a bit hectic the last few months.

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

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

Fixed in commits:

@jestabro I fixed the indent on both current and curx thanks for reporting

Yes, it's pretty vague bug, and seems it's more related on how the VM was initially created if it will work or not.

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.

Development on this resides in a fork of vyatta-config-migrate (https://github.com/jestabro/vyatta-config-migrate), though properly should reside in a fork of vyos-1x.

hi @hagbard, I did some extensive testing. Actually I was already testing with "1.2.0-rolling+201904240337". So here are my findings.

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

I'm experiencing this issue as well on a homespun 1.2.0 image; have been for a little over a month now. Occurs almost every day with no indication as to what the cause can be.

added not on old-style cfg-mode templates

Added a sidenote about switching on router and routing on switch

First commit on implementing this: https://github.com/runborg/vyatta-cfg-system/commit/15f6f2e06cc3e7d4e25f9cd381e70b8d978717f6

Now it seems to report guest info succesfully:

Tested in 1.2.0-rolling+201904250337, everything looks great now, no warnings arise and required config is in place, so I'll wait for 1.2.2 to get the fixed version of ethtool.
Thanks for your efforts, great work!

I'm not a fan of cluttering the OS too much, there are two much better ways

I've commit that issue. According to my understanding, this problem will be solved in vyos version 1.3. Have you fix that issue?

Did you ever get this figured out?

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

Because you mentioned networkd earlier, I looked into this immediately and found the following differences:

Thanks, I tested it, my findings below:

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.

When I read it back, I can understand the confusion. Sorry, will try to be more clear next time.

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

@hagbard But we were talking about my patch, and that it didn't work for you in latest rolling... So i tested my patch in the latest rolling (and noted the date) that it worked. Should I have made it more clear that I was testing my patch?

Hi hagbard, I don't understand why you close the PR so early without me testing the latest iso. Please when you refer to "latest" iso, to also note the rolling date. This makes it easier for everyone who tries to contribute i think.

This router is receiving BGP from several internal BGP routers each with full table peers or couple of peerings.