Page MenuHomePhabricator

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

Difficulty level
Unknown (require assessment)
Version
1.2.0-rc2
Why the issue appeared?
Will be filled on close
c-po created this task.Oct 10 2018, 2:33 PM
c-po updated the task description. (Show Details)Oct 11 2018, 3:49 PM
c-po assigned this task to dmbaturin.
c-po triaged this task as High priority.
c-po updated the task description. (Show Details)
c-po added a comment.Oct 14 2018, 10:45 AM

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.

dmbaturin closed this task as Resolved.