The reason for layer2, layer2+3 and layer3+4 are that those values are directly passed to the kernel, as the pernel expects:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 27 2019
@hagbard dummy interface has been migrated, see https://github.com/vyos/vyos-1x/commit/93184326fc3768216b734a5fcc60e193b5e27fad
Aug 26 2019
Resolved with rewrite of op-mode scripts in Python.
Turns out this can be done with the following code:
pyroute2 has been added to our debian repo http://dev.packages.vyos.net/repositories/current/vyos/pool/main/p/pyroute2/
vyos@vyos:~$ show openvpn site-to-site OpenVPN status on vtun1
Aug 25 2019
If this issue can be reproduced by someone else please open a new bug report. THX!
Aug 24 2019
Aug 23 2019
Unfortunately I can not reproduce this issue
This can be solved using multiple ways:
- add option to the interfaces-bridge.py script to recreate the bridge when triggered externally
- advantage: the conde is already there
- disadvantage: the script can easily grow to a wastebin of code executed from 100 places
- add a dedicated bridge-group-sync.py script which synchronizes the bridge groups and interfaces, called whenever a interface is added to the system (e.g OpenVPN vtun or ethernet vif). We will walk through all available bridges configured and add possibly missing interfaces
- advantage: code is contained in a dedicated scirpt
- disadvantage: more and more scripts might evolve
- Write a vyos-interfaced which acts as message receiver and will handle tasks as adding/removing IP addresses, adding/removing bridge and bond members
- advantage: most generic and single source
- disadvantage: most complex
If the bridge priority is higher then the ethernet vif this should work out of the box
Aug 22 2019
Aug 21 2019
Aug 20 2019
Aug 19 2019
Backported to crux
Aug 17 2019
Also the subtask T1524 should be part of this migration script as if the new allow-from node does not exist it should be populated by the current hard-coded addresses of 0.0.0.0/0 and ::/0
Using 1.2-rolling-201908171107 I configured:
set service dns forwarding domain example.com server '172.16.10.1' set service dns forwarding listen-address '172.18.201.10' set service dns forwarding name-server '1.1.1.1'
- OpenVPN site-to-site
This error won't be fixed as the new Python/XML implementation of OpenVPN has been merged into current and will appear in the next rolling release.