Looks like the vyos-1x images was not rebuilt from the crux branch before the new image was built. I manually checked out the crux branch and the commit ins backported in there, rebuilt the packages manually and everything needed is in there and working.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 10 2019
@hagbard Confirmed fix. Migration worked perfectly.
Link to the changelog https://phabricator.vyos.net/maniphest/query/Vx2T4niywHe4/#R
@kroy Please let me know if you still experience any issues (setting the port or migration).
tested with today rolling release. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912100217-amd64.iso)
Good point! PR merged.
disable-connected option on a neighbour would work, too.
@kroy please test with the latest rolling if https://phabricator.vyos.net/T1846 solves your issue.
@Dmitry Tested it with the latest 1.2 rolling, the issue is still present.
In the VyOS 1.2-rolling-201912090217 and VyOS 1.3-rolling-201912090242 all work fine
That subsystem has now been completely rewritten and certain things are skipped if underlaying hardware is virtio or vmxnet.
Over the past 3 months of rolling releases, I haven't seen this problem in KVM with virtio.
Looks like this is resolved in 1.2.4-epa can @s.lorente confirm?
@hagbard An inactive route in this case can be resolved using the command "ebgp-multihop 10".
In the latest rolling VyOS 1.3-rolling-201912090242 it work fine.
R1 advertise ipv6 routes with community 65001:666
R2 receives these routes.
Similar task https://phabricator.vyos.net/T1838
Dec 9 2019
/opt/vyatta/sbin/vyatta-firewall.pl contains lines
Related to T1844, which should correct the original problem in this ticket
A parsimonious fix to this issue has been committed; I will move the status to "In progress" until the related issues mentioned here are sorted through.
Hi @systo
Can you describe step by step what you did not succeed?
The example below is just an example.
Confirm the problem on edit level.
Thanks, @trae32566 for the information! I would be happy to change this fix in that way, which does not allow to place unwanted records to resolv.conf at all, but I cannot catch the same situation like yours to collect enough diagnostics data to be sure in the reason of such behavior.
I don't see this bug in the latest versions of the VyOS (VyOS 1.2-rolling-201912090217 and VyOS 1.3-rolling-201912090242).
Yes it's exactly the same reason
Dec 8 2019
I can't reproduce this issue on 1.2.3 and 1.2/1.3 rolling. @hagbard can you test again too?
This looks like the same issue as described in T1846, can anyone confirm this?
with git bisect, problem starts from commit d9ee0b95d1020b6d5412dd011ebb1ef7f6ef3fc7, which modified vyos-1x/python/vyos/config.py
[edit service dns forwarding] vyos@beijing# set domain test.lan server 8.8.8.8 [edit service dns forwarding] vyos@beijing# commit [ service dns forwarding ] > /usr/libexec/vyos/conf_mode/dns_forwarding.py(110)get_config() -> return None (Pdb) dir(conf) ['_Config__session_env', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_cli_shell_api', '_level', '_make_command', '_make_path', '_run', '_running_config', '_session_config', 'exists', 'exists_effective', 'get_config_dict', 'get_level', 'in_session', 'is_leaf', 'is_multi', 'is_tag', 'list_effective_nodes', 'list_nodes', 'return_effective_value', 'return_effective_values', 'return_value', 'return_values', 'session_changed', 'set_level', 'show_config'] (Pdb) conf.get_level() [] (Pdb) conf.show_config() ' allow-from 10.33.0.0/16\n allow-from 10.0.0.0/24\n domain 1e100.net {\n server 10.0.0.254\n }\n domain amazonaws.com {\n server 10.0.0.254\n }\n domain amazon.com {\n server 10.0.0.254\n }\n domain blogspot.com {\n server 10.0.0.254\n }\n domain blogspot.it {\n server 10.0.0.254\n }\n domain box.com {\n server 10.0.0.254\n }\n domain cloudfront.com {\n server 10.0.0.254\n }\n domain coggle.it {\n server 10.0.0.254\n }\n domain c.android.clients.google.com {\n server 10.0.0.254\n }\n domain dn.rawgit.com {\n server 10.0.0.254\n }\n domain docker.com {\n server 10.0.0.254\n }\n domain dropbox.com {\n server 10.0.0.254\n }\n domain duckduckgo.com {\n server 10.0.0.254\n }\n domain facebook.com {\n server 10.0.0.254\n }\n domain facebook.net {\n server 10.0.0.254\n }\n domain ggpht.com {\n server 10.0.0.254\n }\n domain gist.github.com {\n server 10.0.0.254\n }\n domain git-scm.com {\n server 10.0.0.254\n }\n domain github.com {\n server 10.0.0.254\n }\n domain github.io {\n server 10.0.0.254\n }\n domain gmail.com {\n server 10.0.0.254\n }\n domain golang.org {\n server 10.0.0.254\n }\n domain google-analytics {\n server 10.0.0.254\n }\n domain googleapis.com {\n server 10.0.0.254\n }\n domain googlesource.com {\n server 10.0.0.254\n }\n domain googlevideo.com {\n server 10.0.0.254\n }\n domain google.com {\n server 10.0.0.254\n }\n domain google.com.hk {\n server 10.0.0.254\n }\n domain google.co.jp {\n server 10.0.0.254\n }\n domain gopkg.in {\n server 10.0.0.254\n }\n domain greatfire.org {\n server 10.0.0.254\n }\n domain gstatic.com {\n server 10.0.0.254\n }\n domain g.doubleclick.net {\n server 10.0.0.254\n }\n domain h.m.wikipedia.org {\n server 10.0.0.254\n }\n domain h.wikipedia.org {\n server 10.0.0.254\n }\n domain jenkins-ci.org {\n server 10.0.0.254\n }\n domain jetbrains.com {\n server 10.0.0.254\n }\n domain lcw.ff.avast.com {\n server 10.0.0.254\n }\n domain lithium.com {\n server 10.0.0.254\n }\n domain medium.com {\n server 10.0.0.254\n }\n domain n.wikipedia.org {\n server 10.0.0.254\n }\n domain opendaylight.org {\n server 10.0.0.254\n }\n domain openvpn.net {\n server 10.0.0.254\n }\n domain pge.com {\n server 10.0.0.254\n }\n domain pinimg.com {\n server 10.0.0.254\n }\n domain pinterest.com {\n server 10.0.0.254\n }\n domain quoracdn.net {\n server 10.0.0.254\n }\n domain quora.com {\n server 10.0.0.254\n }\n domain reddit.com {\n server 10.0.0.254\n }\n domain steamcommunity.com {\n server 10.0.0.254\n }\n domain storify.com {\n server 10.0.0.254\n }\n+domain test.lan {\n+ server 8.8.8.8\n+}\n domain thefacebook.com {\n server 10.0.0.254\n }\n domain twimg.com {\n server 10.0.0.254\n }\n domain twitter.com {\n server 10.0.0.254\n }\n domain w3schools.com {\n server 10.0.0.254\n }\n domain w.org {\n server 10.0.0.254\n }\n domain x.lan {\n server 10.30.0.1\n }\n domain ycombinator.com {\n server 10.0.0.254\n }\n domain youtube.com {\n server 10.0.0.254\n }\n listen-address 10.33.0.1\n listen-address 10.0.0.2\n system\n'
vyos@beijing:~$ config [edit] vyos@beijing# set service dns forwarding domain test.lan server 8.8.8.8 [edit] vyos@beijing# commit [edit] vyos@beijing# exit Warning: configuration changes have not been saved. exit vyos@beijing:~$ file /etc/powerdns/recursor.conf /etc/powerdns/recursor.conf: ASCII text, with very long lines vyos@beijing:~$ config e[edit] vyos@beijing# edit service dns forwarding [edit service dns forwarding] vyos@beijing# delet domain test.lan [edit service dns forwarding] vyos@beijing# commit [ service dns forwarding ] not exists
Please provide real commands, else we can not reproduce the issue. Can you try it on a second installation?
This is probably not problem from dns_forwarding.py, not only dns forwarding but also dhcp server encounters same problem.
DNS forwarding was last changed back in August by commit https://github.com/vyos/vyos-1x/commit/fdae741be5ffaa3719ce889d0342c3091ad3c92c
I can not reproduce this issue. I just upgraded to the specified version.
vyos@vyos:~$ show version Version: VyOS 1.2-rolling-201912080217 Built by: [email protected] Built on: Sun 08 Dec 2019 02:17 UTC Build UUID: b998c0a6-ccf9-47ca-a8f8-7cc561bc5528 Build Commit ID: 7b47b452ce86a9
Please share commands to reproduce this. We do kot hve a 1.2.3 rolling version.
Dec 7 2019
@zsdc It looks like after boot the DHCP DNS and search does indeed disappear, it just appears to take a minute, so I guess this can be closed (though it seems odd it would get added at all, but I guess that's alright).
Dec 6 2019
Trying to apply the fix manually:
Built a fresh rolling. It failed with:
FRR will serve RAs in the future.
https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912061907-amd64.iso and later include the fix