It may be a good idea, but it sure needs a serious and broad discussion. I'm moving it to 1.4 for now, though we may move it back if we have time before the freeze.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Jun 25 2020
Jun 25 2020
dmbaturin added a project to T2155: Cannot set anything on Intel 82599ES 10-Gigabit SFI/SFP+: VyOS 1.3 Equuleus.
dmbaturin renamed T2114: Use unique interface name prefix for each tunnel type from change the syntax for tunnel interfaces to Use unique interface name prefix for each tunnel type.
dmbaturin edited projects for T2114: Use unique interface name prefix for each tunnel type, added: VyOS 1.4 Sagitta; removed VyOS 1.3 Equuleus.
dmbaturin closed T2101: Fix VXLAN config option parsing, a subtask of T2057: Generalised Interface configuration, as Resolved.
dmbaturin edited projects for T2038: repository organisation change, added: VyOS 1.4 Sagitta; removed VyOS 1.3 Equuleus.
Since we are heading towards a freeze, I believe it's better to live big changes for later, even though I don't categorically disagree with the idea.
Still reproducible in 1.3-rolling-202006241940
Now that we have an HTTP API, I believe it's time to deprecate vymgmt altogether.
trae32566 updated the task description for T2645: Editing route-map action requires adding a new rule.
trae32566 updated the task description for T2645: Editing route-map action requires adding a new rule.
Unknown Object (User) closed T2572: Wrong default units when defining traffic policy bandwidth as Resolved.
Unknown Object (User) added a comment to T2572: Wrong default units when defining traffic policy bandwidth.
I have checked and fixed bandwidth default units for Limiter, Network Emulator, Rate Control,
Shaper and Shaper HFSC.
Jun 24 2020
Jun 24 2020
vif interfaces are removed normally.
In T2630#68490, @Asteroza wrote:There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.
Maybe warn on over 9000 but not block it? Also, what are NVMeoF/RoCE NIC's saying these days? Still, since path MTU discovery isn't reliable, direct testing the interface seems like a good fallback, but while udev running it might be okay, again for VM nics, the host changing the underlying hardware could cause changes while running, so rescan on every commit?
Viacheslav changed the status of T2637: Vlan is not removed from the system, a subtask of T2353: Interface [conf_mode] errors parent task, from Open to Needs testing.
Viacheslav changed the status of T2637: Vlan is not removed from the system from Open to Needs testing.
Update: After hooking up an actual EZIO device to my VM and working the code back and forth, I seem to have settled on this design:
Unknown Object (User) claimed T2641: Rewrite vpn ipsec OP commands in new style XML syntax.
Unknown Object (User) created T2641: Rewrite vpn ipsec OP commands in new style XML syntax.
c-po moved T1938: syslog doesn't start automatically from Need Triage to Finished on the VyOS 1.3 Equuleus board.
It looks like this bug is in the kernel.
1.2.5 - 4.19.106-amd64
Viacheslav closed T2633: Error with arp_accept on tun interface, a subtask of T2353: Interface [conf_mode] errors parent task, as Resolved.
Work as expected.
The problem also probably exists with vif_s .. it needs to be investigated.
Viacheslav changed the status of T2547: Rewrite protocol RIP [conf-mode] to new XML/Python style, a subtask of T2175: Rewriting all FRR processes allow for reloading and to XML/Python style, from Open to Needs testing.
Viacheslav changed the status of T2547: Rewrite protocol RIP [conf-mode] to new XML/Python style from Open to Needs testing.
thomas-mangin added a comment to T2634: remove autogeneration of interface "ip section" from vyatta-cfg-system.
was done part of T2633
srgjp added a comment to T1197: Can't login to the router after upgrade vyos from 1.1.8 to 1.2.0-epa3.
No problem occured after updating another machine from version VyOS 1.2-rolling-201910102056 to 1.3-rolling-202006230700. Login succeeded after reboot immediately.
There is the weird area here, as 1G interfaces are generally capped at 9K more or less (whether limits include those overheads or not is always weird, such as switches saying they are 9K but also 9120). For VM nics, you're never completely sure of what the host or what the switches directly connected to the hosts will allow either.
Jun 23 2020
Jun 23 2020
blackhole updated the task description for T2592: dhcp-relay discarding packets on valid interfaces.
blackhole added a project to T2592: dhcp-relay discarding packets on valid interfaces: VyOS 1.3 Equuleus.
In T2630#68467, @thomas-mangin wrote:could have the range 68-65536 but it may be a bit on the extreme side.
Viacheslav changed the status of T2633: Error with arp_accept on tun interface, a subtask of T2353: Interface [conf_mode] errors parent task, from Open to Needs testing.
Viacheslav changed the status of T2633: Error with arp_accept on tun interface from Open to Needs testing.
could have the range 68-65536 but it may be a bit on the extreme side.
https://github.com/vyos/vyos-1x/pull/473 was merged so now need to agree sane limits for the XML.
I have a PR for this (not changing the XML limiting range) for review ATM.
c-po changed the status of T1538: Update conntrack-sync packages to fix VRRP issues from In progress to Needs testing.
New Jenkins Job established https://ci.vyos.net/job/vyos-build-netfilter/ with pipeline from https://github.com/vyos/vyos-build/blob/current/packages/netfilter/Jenkinsfile
a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.
srgjp added a comment to T1197: Can't login to the router after upgrade vyos from 1.1.8 to 1.2.0-epa3.
Just reproduced same issue on second system. Source VMware vSphere Host.
srgjp added a comment to T1197: Can't login to the router after upgrade vyos from 1.1.8 to 1.2.0-epa3.
Same Problem here: After upgrading from 1.3-rolling-202005030117 to 1.3-rolling-202006230700 no login possible. After resetting password for admin user through password recovery login works. Rest of configuration was copied as should.
c-po updated the task description for T2636: get_config_dict() shall always return a list on <multi/> nodes.
thomas-mangin added a comment to T2587: Cannot enable the interface when the MTU is set to less than 1280.
related to T2630
vyos@vyos# set interfaces tunnel tun0 description '*** SITE1 ***' [edit] vyos@vyos# set interfaces tunnel tun0 encapsulation 'gre-bridge' [edit] vyos@vyos# set interfaces tunnel tun0 local-ip '10.0.3.239' [edit] vyos@vyos# set interfaces tunnel tun0 remote-ip '10.0.32.240' [edit] vyos@vyos# set interfaces tunnel tun0 ip enable-arp-accept [edit] vyos@vyos# set interfaces tunnel tun0 ip enable-arp-announce [edit]
It would be possible to make the scripts check if IPv6 is enabled on the interface (or system?) and make the minimal MTU 1280 in that case. If IPv6 on the interface is disabled or not supported, have it go as low as it can.
This was discussed already in T2404. The problem is that NICs that expose their min/max MTU are rare. None of the NICs I have expose it, neither through sysfs nor through 'ip -d link show'. If I recap the discussion from T2404, there are 2 main ways to solve this:
a) not have any limitations regarding MTU at all and then detect an error when trying to apply the new MTU. This means no way to verify if the new mtu is correct beforehand so it doesn't comply with the verify/apply separation that's prescribed in the developer docs. I described a possible workaround using revert code in T2404.
b) have a mtu detection script that would be ran by udev on every new NIC detection (to support hotplugging NICs) that would determine the min/max mtu with a bruteforce binary search algorythm (try to set a mtu and see if it errors), then record the results in some temporary file that would get read by the config script. The idea was proposed by @thomas-mangin.
Viacheslav closed T1829: Install Image script does not respect size of partition greater than 2G but less than disk size as Resolved.
@systo mark as resolved. Reopen it if necessary.