FRR 7 OSPFv3 over WireGuard: IPv6 prefixes not in routing table

Installing and Using OpenWrt Network and Wireless Configuration
1

Hopefully this is gonna be an easy one. @GrapeCent your wisdom, please.
ospf adjacency is up and I can see the neighbor, also was able to capture the LSAs with the redistributed prefixes, but for some reason they are not installed in the routing table.

interface elvetias
 description Elvetias 10.0.20.4/30
 ipv6 ospf6 network point-to-point
!
router ospf6
 ospf6 router-id 10.0.2.1
 redistribute kernel
 redistribute connected
 redistribute static
 area 0 range fe80::/64
 interface elvetias area 0

I can see them in the database, for example the fd00:aaaa::/64 is the lan of the other router.

barracuda# sh ipv6 ospf6 database 

        Area Scoped Link State Database (Area 0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Rtr  0.0.0.0        10.0.1.1        240 800028c8               10.0.2.1/0.0.0.0
Rtr  0.0.0.0        10.0.2.1        239 8000003f              10.0.1.1/0.0.0.17
INP  0.0.0.0        10.0.1.1        709 80000039                 fd00:cccc::/64
INP  0.0.0.0        10.0.2.1        239 8000003b                 fd00:cccc::/64

        I/F Scoped Link State Database (I/F elvetias in Area 0)

Type LSId           AdvRouter       Age   SeqNum                        Payload
Lnk  0.0.0.17       10.0.1.1        709 80000039                        fe80::2
Lnk  0.0.0.17       10.0.1.1        709 80000039                    fd00:cccc::
Lnk  0.0.0.34       10.0.2.1       1364 80000039                        fe80::1
Lnk  0.0.0.34       10.0.2.1       1364 80000039                    fd00:cccc::

        AS Scoped Link State Database

Type LSId           AdvRouter       Age   SeqNum                        Payload
ASE  0.0.0.16       10.0.1.1       1156 80000038        2aaa:aaaa:ecb1:f145::/64
ASE  0.0.0.17       10.0.1.1       1156 80000038                 fd00:aaaa::/64
ASE  0.0.0.18       10.0.1.1       1156 80000038                 fd00:cccc::/64
ASE  0.0.0.9        10.0.2.1       3600 80000001          2bbb:bbbb:273:75::/64
ASE  0.0.0.10       10.0.2.1       3600 80000001        2bbb:bbbb:273:7500::/60
ASE  0.0.0.11       10.0.2.1       3600 80000001        2bbb:bbbb:273:7530::/64
ASE  0.0.0.12       10.0.2.1       3600 80000001                 fd00:bbbb::/60
ASE  0.0.0.13       10.0.2.1       3600 80000001            fd00:bbbb:0:20::/64
ASE  0.0.0.14       10.0.2.1       3600 80000001            fd00:bbbb:0:30::/64
ASE  0.0.0.15       10.0.2.1       3600 80000001              fd00:bbbb:10::/64
ASE  0.0.0.16       10.0.2.1       3600 80000001                 fd00:cccc::/64
ASE  0.0.0.17       10.0.2.1       3600 80000009          2bbb:bbbb:273:75::/64
ASE  0.0.0.18       10.0.2.1       1076 80000038        2bbb:bbbb:273:7500::/60
ASE  0.0.0.19       10.0.2.1       1076 80000038        2bbb:bbbb:273:7530::/64
ASE  0.0.0.20       10.0.2.1       1076 80000038                 fd00:bbbb::/60
ASE  0.0.0.21       10.0.2.1       1076 80000038            fd00:bbbb:0:20::/64
ASE  0.0.0.22       10.0.2.1       1076 80000038            fd00:bbbb:0:30::/64
ASE  0.0.0.23       10.0.2.1       1076 80000038              fd00:bbbb:10::/64
ASE  0.0.0.24       10.0.2.1       1076 80000038                 fd00:cccc::/64
ASE  0.0.0.25       10.0.2.1       3600 80000009   2ccc:cccc:4001:809::200e/128
ASE  0.0.0.26       10.0.2.1       3600 80000009        2bbb:bbbb:273:7500::/56
ASE  0.0.0.27       10.0.2.1       3600 80000009        2bbb:bbbb:273:7500::/64
ASE  0.0.0.28       10.0.2.1       1074 80000038                       fc00::/6
ASE  0.0.0.29       10.0.2.1       1074 80000038                 fd00:bbbb::/48
ASE  0.0.0.30       10.0.2.1       1074 80000038                 fd00:bbbb::/64
ASE  0.0.0.31       10.0.2.1       3600 80000001          2bbb:bbbb:273:75::/64
ASE  0.0.0.32       10.0.2.1       3600 80000001        2bbb:bbbb:273:7500::/56
ASE  0.0.0.33       10.0.2.1       3600 80000001        2bbb:bbbb:273:7500::/64
ASE  0.0.0.34       10.0.2.1       3600 80000001   2ccc:cccc:4001:809::200e/128
ASE  0.0.0.35       10.0.2.1       3600 80000001                             ::
ASE  0.0.0.36       10.0.2.1        866 80000030          2bbb:bbbb:273:75::/64
ASE  0.0.0.37       10.0.2.1        866 80000030        2bbb:bbbb:273:7500::/56
ASE  0.0.0.38       10.0.2.1        866 80000030        2bbb:bbbb:273:7500::/64
ASE  0.0.0.39       10.0.2.1        866 80000030   2ccc:cccc:4001:809::200e/128

but nothing in the routing table:

barracuda# sh ipv6 ospf6 route    
*N IA fd00:cccc::/64                 ::                        elvetias 1d04:26:21
barracuda# sh ipv6 route o     
openfabric  ospf6       
barracuda# sh ipv6 route ospf6 
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

O   fd00:cccc::/64 [110/10] is directly connected, elvetias, weight 1, 1d04h26m

the fd00:cccc::/64 is the ULA for the wireguard tunnel.
Any idea what do I miss?

3

I doubt you will get away with advertising a link-local address - area 0 range fe80::/64

1 Like
4

Link local addresses should not be considered for redistribution as bib said.

the biggest difference I notice from ospfv2 to v3 is that instead of specifying the networks that should be added into the process, you instead specify the interfaces.

Here's an example from my network. Note this is from FRR, it looks like your config uses different grammar. My ospf concepts are also more cisco oriented.
What i've done is assigned the connected interfaces to area 20, and then the main uplink to area 0
on the upstream router that connects to area 0 via eth1.1024, I then assign each of it's interfaces to area 10

If there was another network behind area 10 or 20, then I'd have to setup virtual links to a router connected to area 0.

ip route 0.0.0.0/0 10.23.22.1 table 254
ipv6 route ::/0 fd00:f9a8:9a7e:399::1 table 254
!
interface br-admin
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface br-devices
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface br-domain
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface br-guest
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface br-resident
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface dummy0
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface eth1.1024
 ip ospf 1 area 0.0.0.0
 ip ospf bfd
 ip ospf dead-interval 5
 ip ospf hello-interval 1
 ip ospf network point-to-point
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 bfd
 ipv6 ospf6 dead-interval 5
 ipv6 ospf6 hello-interval 1
 ipv6 ospf6 network point-to-point
 no ip ospf passive
exit
!
interface tun0
 ip ospf 1 area 0.0.0.20
 ipv6 ospf6 area 0.0.0.20
 ipv6 ospf6 passive
exit
!
interface vbond0
 ip ospf 1 area 0.0.0.0
 ip ospf bfd
 ip ospf bfd profile BFDfast
 ip ospf cost 10
 ip ospf dead-interval 10
 ip ospf hello-interval 1
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 bfd
 ipv6 ospf6 bfd profile BFDfast
 ipv6 ospf6 cost 10
 ipv6 ospf6 dead-interval 10
 ipv6 ospf6 hello-interval 1
 ipv6 ospf6 network point-to-point
 no ip ospf passive
exit
!
interface vbond1
 ip ospf 1 area 0.0.0.0
 ip ospf cost 100
 ip ospf dead-interval 600
 ip ospf hello-interval 60
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 cost 100
 ipv6 ospf6 dead-interval 600
 ipv6 ospf6 hello-interval 60
 ipv6 ospf6 network point-to-point
 no ip ospf passive
exit
!
interface vbond2
 ip ospf 1 area 0.0.0.0
 ip ospf bfd
 ip ospf bfd profile BFDfast
 ip ospf cost 50
 ip ospf dead-interval 10
 ip ospf hello-interval 1
 ipv6 ospf6 area 0.0.0.0
 ipv6 ospf6 bfd
 ipv6 ospf6 bfd profile BFDfast
 ipv6 ospf6 cost 50
 ipv6 ospf6 dead-interval 10
 ipv6 ospf6 hello-interval 1
 ipv6 ospf6 network point-to-point
 no ip ospf passive
exit
!
router ospf 1
 ospf router-id 10.23.32.1
 passive-interface default
exit
!
router ospf6
 ospf6 router-id 10.23.32.1
exit

Since your command syntax is different, you'll need to translate. it looks like you need to assign your backbone area 0 to each interface that's in the routed path. Then assign the networks you want to include in the ospf network for redistribution to area 1 or higher. that may be a good starting point

5

That's weird. I am using frr 7.5-4 from 21.02.5, and I don't see the area option under interface

barracuda(config-if)# ipv6 ospf6 
  advertise            Advertising options
  bfd                  Enables BFD support
  cost                 Interface cost
  dead-interval        Interval time after which a neighbor is declared down
  hello-interval       Time between HELLO packets
  ifmtu                Interface MTU
  instance-id          Instance ID for this interface
  mtu-ignore           Disable MTU mismatch detection on this interface
  network              Network type
  passive              Passive interface; no adjacency will be formed on this interface
  priority             Router priority
  retransmit-interval  Time between retransmitting lost link state advertisements
  transmit-delay       Link state transmit delay
6

I'm on 8.2 on a 23.x openwrt, which is when I started using openwrt recently (have been using Vyos and unifi) until recently.

since in 7.5, they have the interface config under the router ospf6 config, then what I said applies slightly differently

  1. Set your routed interface (wireguard) to area 0
  2. set your inside networks you want to redistribute to area 1 or what ever

Also make sure that the router on the otherend of wireguard also has it's interface in area 0, and it's connected interfaces in area 2 or what ever is different than the first router. The hello and dead timers and other config should be default or the same.

Are you getting a neighbor relationship in a FULL state, not init or exstart?

what is

sh ipv ospf nei

on both routers?

Also, make sure there is a fe80::/64 network assisted to both ends of the wireguard tunnel, AND make sure that any firewall allows OSPFEIGP traffic, since ospf is not a UDP protocol, it's it's own proto

7

The adjacency is fully up.

barracuda# sh ipv6 ospf6 neighbor 
Neighbor ID     Pri    DeadTime    State/IfState         Duration I/F[State]
10.0.1.1          1    00:00:39     Full/PointToPoint    00:00:00 elvetias[PointToPoint]

I can see the prefixes from the neighbor in the database, but not in the routing table.
I'll try assigning the other interfaces in another area to see if that helps.

8

That didn't help much...

barracuda# sh ipv6 ospf6 route 
*N IA 2aaa:aaaa:273:7500::/60        ::                        br-lan 00:02:30
*N IA fd00:bbbb::/60                 ::                        br-lan 00:02:30
*N IA fd00:cccc::/64                 ::                        elvetias 00:10:08

with this config

interface elvetias
 description Elvetias 10.0.20.4/30
 ipv6 ospf6 network point-to-point
!
interface br-lan
 ipv6 ospf6 passive
!
router ospf6
 ospf6 router-id 10.0.2.1
 area 0 range fe80::/64
 area 1 range fd00:bbbb::/48
 interface elvetias area 0
 interface br-lan area 1

I see in ospf6 routes my own prefixes but not the neighbor's.

9

Just leave the range out and for now I would highly suggest to only use area 0.

1 Like
10

maybe take these out for now, summeries are nice to keep the routing table on ABR's small, but add another factor to troubleshoot when standing up a new network

There's some unknowns from my perspective that could effect the issue beyond the "best practices" I've come to have setting up a somewhat large wan

Can you please share, the interface config, frr config, for both ends of the tunnel and label the output router A and router B

ip add show dev wg0

for example.

it could be that such an old version of frr had issues with ospf6, or has interop issues with the otherside of your tunnel if it's not using a similar version of frr. Just a detail that could be a factor imo

11

Taking them out didn't change much. I am back to the original status of having the tunnel prefix only.

Again I want to point out that despite the differences there might be in versions between the peers, I can see the prefixes in the ospf database, but not in routes. So we are not searching if the prefixes are redistributed, that is clear. The question is why are they not installed in routing table.

Router A frr 7.5-4

config interface 'elvetias'
        option proto 'wireguard'
        option private_key ''
        option listen_port '1199'
        list addresses '10.0.20.5/30'
        list addresses 'fd00:cccc::1/64'
        list addresses 'fe80::1/64'

config wireguard_elvetias
        option public_key ''
        option endpoint_port '1199'
        option persistent_keepalive '25'
        list allowed_ips '0.0.0.0/0'
        list allowed_ips '::/0'
        option preshared_key ''

------------------------------------------------------

frr version 7.5
frr defaults traditional
hostname barracuda
log syslog
service advanced-vty
service password-encryption
!
password 8 
enable password 8 
!
interface elvetias
 description Elvetias 10.0.20.4/30
 ipv6 ospf6 network point-to-point
!
interface roadwarrior
 description RoadWarrior 10.0.10.0/28
 ip ospf network point-to-multipoint
!
router ospf
 ospf router-id 10.0.2.1
 redistribute connected route-map lan
 redistribute static route-map lan
 network 10.0.20.4/30 area 0.0.0.0
!
router ospf6
 ospf6 router-id 10.0.2.1
 interface elvetias area 0
!
access-list vty seq 5 permit 127.0.0.0/8
access-list vty seq 20 permit 10.0.0.0/19
access-list vty seq 100 deny any
access-list lan remark my network
access-list lan seq 5 permit 192.168.8.0/24
access-list lan seq 10 permit 172.30.30.0/24
access-list lan seq 15 permit 10.0.0.0/19
access-list lan seq 20 deny any
!
ipv6 access-list lan6 remark home ipv6
ipv6 access-list lan6 seq 100 deny any
ipv6 access-list lan6 seq 10 permit fd00::/32
ipv6 access-list vty seq 5 permit ::1/128
ipv6 access-list vty seq 100 deny ::/0
ipv6 access-list vty seq 10 permit fd00::/32
!
route-map lan permit 10
 match ip address lan
!
route-map lan6 permit 10
 match ipv6 address lan6
!
line vty
 access-class vty
 ipv6 access-class vty
!
end

--------------------------------------------

34: elvetias: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.0.20.5/30 brd 10.0.20.7 scope global elvetias
       valid_lft forever preferred_lft forever
    inet6 fd00:cccc::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::1/64 scope link 
       valid_lft forever preferred_lft forever

Router B quagga - 1.1.0-1

config interface 'moravany'
        option proto 'wireguard'
        option private_key ''
        option listen_port '1199'

config wireguard_moravany
        option public_key ''
        option endpoint_port '1199'
        option persistent_keepalive '25'
        option description 'Moravany tunnel'
        option endpoint_host ''
        list allowed_ips '0.0.0.0/0'
        list allowed_ips '::/0'
        option preshared_key ''

config interface 'Moravany_net'
        option proto 'static'
        option ifname 'moravany'
        option ipaddr '10.0.20.6'
        option netmask '255.255.255.252'
        option ip6addr 'fd00:cccc::2/64'

config interface 'moravany6'
        option proto 'static'
        option ifname 'moravany'
        option ip6addr 'fe80::2/64'

-----------------------------------------------------------
Building configuration...

Current configuration:
!
!
service advanced-vty
service password-encryption
!
debug ospf6 lsa unknown
!
password 8 
enable password 8 
!
interface 6in4-henet
!
interface br-lan
 ipv6 ospf6 passive
 ipv6 ospf6 network broadcast
!
interface eth0
!
interface eth1
!
interface ifb0
!
interface ifb1
!
interface lo
!
interface moravany
 description Brno 10.0.20.4/30
 description Brno 10.0.20.4/30
 ipv6 ospf6 network point-to-point
!
interface ppp0
!
interface pppoe-wan
!
interface sit0
!
interface tun0
!
interface tun2
!
interface wlan0
!
router ospf
 ospf router-id 10.0.1.1
 redistribute connected route-map lan
 redistribute static route-map lan
 network 10.0.20.4/30 area 0.0.0.0
!
router ospf6
 router-id 10.0.1.1
 redistribute kernel
 redistribute connected
 redistribute static
 interface moravany area 0.0.0.0
!
access-list lan remark my network
access-list lan permit 10.0.0.0/19
access-list lan deny any
access-list lan6 remark my ipv6 network
access-list vty permit 127.0.0.0/8
access-list vty permit 10.0.0.0/19
access-list vty deny any
!
ipv6 access-list lan6 permit fd00::/32
!
route-map lan permit 10
 match ip address lan
!
route-map lan6 permit 10
!
ip forwarding
ipv6 forwarding
!
line vty
 access-class vty
 exec-timeout 30 0
!
end

----------------------------------------------

root@fagri:~# ip addr show moravany
17: moravany: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1
    link/none 
    inet 10.0.20.6/30 brd 10.0.20.7 scope global moravany
       valid_lft forever preferred_lft forever
    inet6 fd00:cccc::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::2/64 scope link 
       valid_lft forever preferred_lft forever
12

I'm still thinking about your config, but...I think while I was trying to get my network setup I remembery trying a simple LL address like you have, and had issues. So I made up a proper address like fe80::edaa:342d:22ca:2abc/64 and what ever problem I had went away. Just a thought. I had to set a unique fake LL on each end

You also have an ospf network point-to-multipoint on a roadwarrior network? I'm assuming that's a VPN without ospf on the otherend, it's not necessary to specify the network type unless there's routers on the other end

the redistribute kernel, etc...should be injecting the routes without specifying each interface into an area...so that seems to be working

I do see that on router A you have the wireguard interface set as area 0, and in router B it's area 0.0.0.0. Maybe make both use the same identification, I use 0.0.0.0. but 0 is the same...maybe they need to be identical

It looks mostly correct, but the different ospf processes and some symantics really could be a root cause here

13

Remove network 10.0.20.4/30 area 0.0.0.0 from interface roadwarrior router ospf.

Here is a snippet of a frr conf I have used for a test setup a while ago. You need to adjust the ipv4 part... Maybe it gives you a hint or two...

(Yeah I know you want to use frr, but I still find bird2 far more accessible and easier to use.)

!
interface eth1
 ip ospf network point-to-point
 ipv6 ospf6 area 0
 ipv6 ospf6 network point-to-point
exit
!

interface lo
 ipv6 ospf6 area 0
exit

!
router ospf6
 ospf6 router-id 10.16.0.16
 redistribute connected route-map LO
exit
!
ip prefix-list OSPF-LO seq 5 permit 10.0.0.0/8 ge 32
ip prefix-list OSPF-LO seq 10 deny any
!
ipv6 prefix-list OSPF6-LO seq 5 permit 2001:db8::/32 ge 128
ipv6 prefix-list OSPF6-LO seq 10 deny any
!
route-map OSPF permit 10
 match ip address prefix-list OSPF-LO
exit
!
route-map OSPF6 permit 10
 match ip address prefix-list OSPF-LO
 match ipv6 address prefix-list OSPF6-LO
exit
!
route-map LO permit 10
 match interface lo
exit
!
14

I changed it into:

35: elvetias: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 state UNKNOWN qlen 1000
    inet6 fd00:cccc::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::1111:2222:3333:1/64 scope link 
       valid_lft forever preferred_lft forever

and :2 but nothing changed.

It's a testing with another OpenWrt router as roadwarrior which can advertise its prefixes over OSPF.
I removed it, but didn't change anything.

I tried to change that, but eventually it shows as 0

barracuda(config)# router ospf6 
barracuda(config-ospf6)# interface elvetias area 
  (0-4294967295)  OSPF6 area ID in decimal notation
  A.B.C.D         OSPF6 area ID in IPv4 address notation
barracuda(config-ospf6)# no interface elvetias area 0
barracuda(config-ospf6)# interface elvetias area 0.0.0.0
barracuda(config-ospf6)# ^Z
barracuda# wr
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]
barracuda# sh run
Building configuration...
...
router ospf6
 ospf6 router-id 10.0.2.1
 interface elvetias area 0
...

And quagga from the other side is using only the ipv4 address notation.

Seems so. I'll try to upgrade the remote at some point, but the problem is that if I loose the tunnel I have no other way to login.

This is for ipv4 ospf and works fine, prefixes are redistributed and installed in routing table.

barracuda# sh ip route ospf 
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup

O>* 10.0.1.0/24 [110/20] via 10.0.20.6, elvetias, weight 1, 00:15:05
O   10.0.20.4/30 [110/10] is directly connected, elvetias, weight 1, 00:15:34

This also seems to be from frr 8, as I don't have the area option under the interface. :frowning:

15

Correct, it was frr version 8.3.

16

What i do is open ssh on a high random port as a failsafe and verify its working before i do any major wan changes. Including upgrades.

Unfortunately your issue doesnt seem to be a config issue, since getting the neighbor relationship is the hardest part.

As a final attempt, try restarting the ospf6 process on each side. Im sorry im not smart enough to consider if there could be an obscure config. Most of my success has been flailing around with config

I appreciate your road warrior setup, its similar to my overlanding truck setup, from a basic sense. Im assuming its a mobile router? If you set that link to be poi t to point you will get faster convergence, assuming you dont have multiple routers

17

I tried the restart, no dice.
The remote OpenWrt is behind a closed firewall. So unless I find some way to upgrade it with an image with Wireguard and to apply some initial configuration, start AutoSSH or something like this, I'll better postpone it till I get there.
Moreover it is nothing important, just a connection between our houses.
And to be honest I thought I am missing something simple, since I managed to establish the adjacency between them over IPv6 as well.

18

Yeah, i had been ipv4 for years even in my vyos based networks because ipv6 was still inconsistent. Even over a local LAN.
Obviously it worked for some people, but i think those older versions of quagga and frr, let alone the different daemons, may not talk with the same accent.

Im assuming the other end is a friends house, ive always wished i had a buddy to form a bgp peering with

Honestly, since this is between sites i would suggest peering with bgp AS 65000+ AS numbers which is the private range. You can eventually distribute ipv4 and ipv6 networks over a single peer connection (it doesnt matter if you set the neighbor ip to an ipv4 or ipv6 address)

You then just add redistribute bgp into your ospf processes. This lets both sites manage area 0 independently without having to maintain virtual links to area 0, this tunnel

19

If there is no hard dependencies on frr I would still recommend to give bird2 a chance.the only IPv6 related bug that I'm aware off is that IPv6 addresses are not picked from loopback. There are two workarounds. One is to assign a LLA to lo, the other is to use i.e. a dummy interface. Ok, and bird is unable to speak evpn. But bird also offers babel support and even the developer of babeld recommends nowadays bird if you want to use babel.
Back to ospf and ospfv3. Everything you need is there. And yes I know the thread was/is dedicated to frr version 7...

20

Parents' house, but in a different country. :slight_smile:

I have bgp with bird at work, so this setup is more of a playground for OSPF. And I like the IOS-like cli of /zebra/quagga/frr, as I have some background with Cisco.

Therefore until I have the chance to upgrade the remote router I'll leave it as it is.
I was under the impression that I had some misconfiguration and it was not working, but it seems I was wrong.
Thank you both very much for your input! :slight_smile:

1 Like