@dmbaturin merge if it's not already there

Build Docker container two times on different machines (Linux host and macOS host) ... no problems detected. closing this.

Can't reproduce the issue using commit 217aa6afaeb of vyos-build repo

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.

Hi yun, please open a new ticket with your issue, and make a reference to this case :)

Sorry comment on a resolved ticket, but i'm having the issue that is described in this issue. And i'm not sure how to fix it.

https://forum.vyos.io/t/bgp-weight-not-applying/3723

The solution was tested and fully worked.

Awesome, thx for letting me know.

@hagbard, everything works fine now. Thank you!

just thought I'd ask... did this make it into 1.2 yet? 1.2.1?

Also, there appear to be some leftovers from before 1.2 in dhclient-script@Line45, where vyatta-dns-forwarding.pl was removed in favour of dns_forwarding.py.

PR has been created.

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

This is resolvable via the following two fixes. Once they are implemented GCP should work as expected.

In order to fully fix cloud-init issues this patch needs to be applied so that /etc/resolv.conf can be updated by cloud-init before host_name.py generates final resolv.conf. Since cloud-init fires before VyOS scripts this is required so that GCE metadata can be retried by cloud-init on 1st boot.

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

@hagbard @UnicronNL, please make a new one PR. This is correct patch:

diff -Naur origin/dhclient-script pull2/dhclient-script
--- origin/dhclient-script	2019-05-15 19:32:59.001598203 +0300
+++ pull2/dhclient-script	2019-05-15 19:33:47.533181873 +0300
@@ -39,7 +39,6 @@
         echo " " > $new_resolv_conf
     fi

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

It's causing a few cloudinit log errors on GCP during 1st boot. We speculate that might be the cause of some of the issues getting an image running correctly on the 1st boot.

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.

This is not the same.

set protocols static table 100 interface-route 10.100.100.0/24 next-hop-interface eth1

generate:

test-06# show running-config staticd 
Building configuration...

@syncer Any chance of getting this merged into 1.2.2?

Hi, @rob
It works! Thanks a lot. This case can be closed now.

@syncer @dmbaturin - I'm experiencing this on upgrade from 1.1.8 to 1.2.1, is this expected behaviour that you have to chown it?

We are closer to a resolution here, however, some legacy code references are causing issues with the 1st boot before our dhcp patches are effective. This code reference is in the dhclient-script being called by cloud-init on the 1st boot. With this failure cloud-init cannot hit the GCE data-source on the 1st boot causing some issues. This will require more work tomorrow, however, I feel a resolution is rather close.

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

@hagbard solution works. Please, add it also to the stable branch and to the set protocols static table section.

can you describe your problem a little bit more.
I do something like this in some cases maybe it match on your use case:

Test with latest vyos-1.2.0-rolling+201905120337-amd64.iso success.
Thank you.

Ok,
the first step is done

Unfortunately a build of vyatta-webproxy was not triggered on push to GitHub. Next rolling will have it!

Test with 1.2.0-rolling+201905110337

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

Made some more progress, however, well either need to use the workaround for GCE images or come up with something more elegant that resolves the cloud-init behavior.

successfully tested on:
Version: VyOS 1.2.0-rolling+201905081347
Built by: [email protected]
Built on: Wed 08 May 2019 13:47 UTC
Build ID: 7093c43d-6ea7-45c9-a7c5-3fdf07c0ebc7

I made some progress here using the debug image, however, it looks like cloud-init is still starting a dhclient process that doesn't need to exist as part of it's fallback networking.

Please test with next rolling release if this problem is fixed so we can close this issue if this is ok for you. Whitlist issues should be separate ones. Thanks for assistance.