@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
Fri, May 17
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.
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.
Thu, May 16
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?
Wed, May 15
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.
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
Tue, May 14
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
test-06# show running-config staticd Building configuration...
@syncer Any chance of getting this merged into 1.2.2?
It works! Thanks a lot. This case can be closed now.
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.
Mon, May 13
@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.
Sun, May 12
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.
the first step is done
Sat, May 11
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
Fri, May 10
Thu, May 9
@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@example.com
Built on: Wed 08 May 2019 13:47 UTC
Build ID: 7093c43d-6ea7-45c9-a7c5-3fdf07c0ebc7
Wed, May 8
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.