Page MenuHomeVyOS Platform

interface vtun20 not in default vrf
Closed, ResolvedPublicBUG

Description

Upgrading from a rolling release dating back to mid august to 1.2.0-rc results in:

[ interfaces openvpn vtun20 ip ospf dead-interval 40 ]
% interface vtun20 not in default vrf

[[interfaces openvpn vtun20]] failed
[ interfaces openvpn vtun30 ip ospf dead-interval 40 ]
% interface vtun30 not in default vrf

[[interfaces openvpn vtun30]] failed
Commit failed

This is actually related to the ip ospf section in the following configuration:

openvpn vtun20 {
    ip {
        ospf {
            dead-interval 40
            hello-interval 10
            network point-to-point
            priority 2
            retransmit-interval 5
            transmit-delay 1
        }
    }
    local-address 172.16.253.118 {
    }
    local-host x.x.234.19
    local-port 8020
    mode site-to-site
    openvpn-option --persist-tun
    openvpn-option --persist-key
    openvpn-option "--tun-mtu 1500"
    openvpn-option "--mssfix 1320"
    protocol udp
    remote-address 172.16.253.117
    remote-host x.x.69.205
    remote-port 8020
    shared-secret-key-file /config/auth/foo.psk
}

This will break running configuration with OpenVPN interfaces participating in OSPF

Details

Version
1.2.0-rc2

Event Timeline

c-po triaged this task as High priority.
c-po updated the task description. (Show Details)
c-po updated the task description. (Show Details)

Problem still exists with 1.2.0-rolling+201810120820-amd64.iso

The root cause is that Quagga and FRR 5.1-dev didn't mind changing settings for non-existent interfaces, but FRR 6.1-dev does. The "ip source-validation" should have always been affected though.

The short term solution is to set a higher priority than the parent interface. It will cause warnings about priority inversion (because it is a priority inversion, but what do you do?), which in this case should be harmless.

The real solution is to take that stuff out of interfaces.