In T2772#73254, @Viacheslav wrote:

@ronie can you build an example with frr?

In this lab I used VyOS 1.3-rolling-202008170118. The connected routes redistributed in OSPF at HUB are being properly exchanged to WAN router, including the route to the virtual tunnel interface vti50.

In VyOS 1.3-rolling-202008170118 the interfaces do not generate/get the configured IPv6-EUI Address, as in the image:

In version VyOS 1.3-rolling-202008170118 physical interfaces have an automatic generated IPv6 Link-Local Address set, though Tunnel interfaces does not have it and it is necessary to set manually an IPv6 Link-Local Address ramdomly created. Tunnel interfaces also do not present a Layer-2 address from which a Link-Local IPv6 could be derived.

https://forum.vyos.io/t/ospfv3-not-working-over-gre-tunnel/5805/8

Tunnel Interfaces also do not generate/configure a Link-Local IPv6. It looks like Tunnel interfaces do not have any MAC Address associated to it.

It seems that making the tunnel connection a Stub Area would reach the same design goal without relying on a recursive static route, but it also seems that this feature is not supported in OSPFv3 by now. I´ve opened the following feature requests: https://phabricator.vyos.net/T2804 & https://phabricator.vyos.net/T2803 .

I´ve tyred to reproduce this scenario with VyOS 1.3-rolling-202007300117.
The static-default-route is correctly installed in the routing table after rebooting the router.

In T2786#72841, @Viacheslav wrote:

@ronie For OSPF bandwidth use command:

[email protected]# set interfaces ethernet eth0 ip ospf bandwidth 
Possible completions:
   <1-100000>   Bandwidth in megabits/sec (for calculating OSPF cost)

@Viacheslav I supposed that by default Ethernet Interfaces/10Mbits should be assigned a cost of 10 without changing any parameter. So it is not a bug? Should I cancel this request?

Not speed interface.

In general, Service Providers implement IS-IS, not OSPF, as IGP in the Core. Maybe it is a good idea to develop VYOS support to IS-IS in order to make it more attractive as an immediate solution as P router to SPs.

It seems a parser issue. We are reviewing the script https://github.com/vyos/vyatta-op-vpn/blob/current/scripts/vyatta-op-vpn.pl

When the configuration provided is reproduced, the problem occurs: show ike sa is "down" while show ipsec sa is "up".

Route Distinguisher & Route Targets are, in general, configured under VRF proccess. Below a sample of how this configurations would looks like:

Bellow a sample of how BGP VPNv4 and VPNv6 AF configuration looks like:

Could you please provide full configuration or at least protocol section configuration?

I´ve used the version of the software: VyOS 1.3-rolling-202007300117.
As I´ve used GRE tunnels it does not simulates the same scenario reported, which uses pure IPsec. I will configure IPsec tunnels over physical interfaces and log the results here again.

[email protected]# sh vpn
ipsec {

esp-group MyESPGroup {
    proposal 1 {
        encryption aes256
        hash md5
    }
}
ike-group MyIKEGroup {
    proposal 1 {
        dh-group 2
        encryption aes256
        hash md5
    }
}
ipsec-interfaces {
    interface eth0.100
}
site-to-site {
    peer 169.254.100.1 {
        authentication {
            mode pre-shared-secret
            pre-shared-secret MYSECRETKEY
        }
        default-esp-group MyESPGroup
        ike-group MyIKEGroup
        local-address 169.254.100.6
        tunnel 20 {
            protocol gre
        }
    }
}

}
[edit]

I´ve configured a simple P-2P IPsec/GRE Tunnel and the command shows IKE and IPsec SAs UP: