Actually, there are already run monitor traffic interface $intf commands and they work fine in 1.2.3.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 30 2019
Aug 29 2019
Aug 28 2019
Adding "tls-crypt" and in the upcoming 2.5 release "tls-crypt-v2" options would also be desirable.
@hagbard during some tests with the bridge interface (https://github.com/vyos/vyos-1x/commit/71f7a947539963112c61fef2a5f278d524d71198) I noticed the following:
Pyroute2 states:
One of the major issues with IPDB is its memory footprint. It proved not to be suitable for environments with thousands of routes or neighbours. Being a design issue, it could not be fixed, so a new module was started, NDB, that aims to replace IPDB. IPDB is still more feature rich, but NDB is already more fast and stable.
Aug 27 2019
The reason for layer2, layer2+3 and layer3+4 are that those values are directly passed to the kernel, as the pernel expects:
improvement suggestion:
- remove the use of + in hash-policy names. layer2+3 and layer3+4. this could be replaced with the more used - character, so layer2-3 and layer3-4
- also add support for encap2-3 and encap3-4hash-policy
It is true that you need a hash-policy, but specifying a hash-policy is optional, if you don't specify it reverts to the kernel default that is layer2..
also defaults should not be listed in the configuration. (because then the configuration will be crowded with all kind of strange things that is a default)
@runar If I could offer an alternative, why not require set interfaces bonding bond0 hash-policy to always be specified? The hash policy is not something optional like a tunnel key for GRE, so I feel that this option should be required.
Improvement suggestion:
set interfaces bonding bond0 hash-policy # defaults to layer2, listing layer2 as an configureable alternative is then redundant. to revert to level2 the user should delete the config entry instead. also update description about using layer2 as a default
with vyos-1.2-rolling-201908270337-amd64.iso also fixed for me. Thanks
@hagbard dummy interface has been migrated, see https://github.com/vyos/vyos-1x/commit/93184326fc3768216b734a5fcc60e193b5e27fad
If it reappears, feel free to reopen.
Aug 26 2019
Perfect, I think the dummy interface would be one which needs to be corrected before I can remove the class file entirely.
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
vyos-1x src/migration-scripts/interfaces/0-to-1 line 41:
https://github.com/vyos/vyos-1x/blob/2f3aa28f259ee7f23ef8a4a091db8ced2202bbd8/src/migration-scripts/interfaces/0-to-1#L41:
# igmp-snooping: check if enabled igmp_val = config.return_value(base + [br, 'igmp-snooping', 'querier'])
This should be preceded by a if config.exists, as should line 33:
# STP: check if enabled stp_val = config.return_value(base + [br, 'stp']) `
The interface/0-to-1 migration script is failing on upgrade (T1611).
Would something like https://openwrt.org/docs/techref/netifd be useful? The drawback that it's dependent on ubus https://openwrt.org/docs/techref/ubus
Aug 23 2019
Unfortunately I can not reproduce this issue
Please, review another batch of trivial rewrites from vyatta-op and the corresponding vyatta-op PR
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
Full console dump to reproduce with comments:
## ## Start without anything
the current only way to get the interface added to the group is to remove and readd it to the group.
vyos@vyos# brctl show bridge name bridge id STP enabled interfaces br1 8000.525405123456 yes eth0.1
i've updated the description. the bridge is created and comitted prior to the creation of the interface.
If the bridge priority is higher then the ethernet vif this should work out of the box
Just checked the vyos-1.2-rolling-201908230337-amd64.iso - it is bootable after install.
Unfortunately name resolution seems broken. Here are some details:
- VM with the previous working image 1.2-rolling-201908210337:
vyos@vyos:~$ show system image The system currently has the following image(s) installed: 1: 1.2-rolling-201908230337 2: 1.2-rolling-201908210337 (default boot)