@hagbard dummy interface has been migrated, see https://github.com/vyos/vyos-1x/commit/93184326fc3768216b734a5fcc60e193b5e27fad

If it reappears, feel free to reopen.

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/

If this issue can be reproduced by someone else please open a new bug report. THX!

https://github.com/vyos/vyos-1x/pull/116

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

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)

moved get functions into properties, for ifalias, macaddr and mtu to see how it works. If the old get_ function is being used, it prints a message to the console but still works. Will see how well that works.
https://github.com/vyos/vyos-1x/commit/0b9c894fcece6df553a89e42147768ce6efaf372

On vyos-1.2-rolling-201908201244-amd64.iso won`t reproduce. All ok, configuration edits are applied.

Hello, this function works great, but I think it could be better if we can specify a custom OID for each custom script. For exemple, LibreNMS needs to have specific OID to make automatic OS/hardware detection working : https://docs.librenms.org/Support/SNMP-Configuration-Examples/#linux-snmpd-v2
Thank you.

Backported to crux

@hagbard can you take a look if that was backported?

Still seeing this bug in 1.2.2. VyOS config has weights configured, but in the FRR config, weight is missing.

Please review PRs in vyos-1x and vyatta-op.

I just tested again.
Running on rolling VyOS-1.2-201908130337, same config as before, recursor.conf is ok.
Updated VyOS to rolling VyOS-1.2-201908190337, reboot, check recursor.conf. The domain forwarding is missing.
Reboot again, it's back in the recursor.conf.

I've also tested this on the newly released dune1.11.1 with the same result

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