Community discussions

MikroTik App
 
peretuset
just joined
Topic Author
Posts: 5
Joined: Sat Apr 16, 2022 5:09 pm

Routing IPv6 with OSPFv3

Sun Sep 18, 2022 1:25 am

Hello all,

I'm just trying to set up IPv6 routing with OSPFv3 in my network using RouterOS v7.5 and I need some help. The network is composed of three routers in a hub-and-spoke topology, connected via Wireguard over the public Internet using IPv4, and internally it already runs IPv4 with OSPFv2 without any problems.

To configure the IPv6 network, I have assigned the global IPv6 addresses to each router interface, created the OPSFv3 instance in each router (in parallel to the OSPFv2 process), and added the interface templates for the relevant interfaces. For the templates I am using the interface instead of the network, as explained in the documentation. For the wireguard interfaces interconnecting the routers I select ptp network type and use the IPv6 area, whereas for the end networks on each router I select the interface (i.e., bridge), the IPv6 area, use broadcast as network type, and activate passive.

I can see the adjacencies forming between each pair of routers, the routing table being populated as expected and the network works (I can ping throughout the network), but there is something that bugs me; in the IPv6 Route List menu (or /ipv6/route/print) of each router I can see a duplicate entry for the public IPv6 address belonging to the bridge, but with different attributes, administrative distances and color. The first entry appears valid (black color), has the DAC attributes and a 0 administrative distance (directly connected), as expected. The second entry appears invalid (red color), has the DIUoH attributes and a 110 administrative distance, as shown next.
  DAc  xxxx:yyyy:zzzz:1::/64    bridge1                                     0
  DIoH xxxx:yyyy:zzzz:1::/64    bridge1                                   110
To me it looks like the route is being re-learned through OSPF despite the fact that the interface is local and it becomes Invalid/unreachable as there is another route with lower administrative distance. Is there anything that I am missing here? The relevant part of the config is as follows:
/ipv6 address
add address=xxxx:yyyy:zzzz:1::1/64 advertise=yes interface=bridge1

/routing ospf instance
add disabled=no name=ospf-v3 originate-default=always router-id=loopback1 version=3

/routing ospf area
add disabled=no instance=ospf-v3 name=backbone-v3

/routing ospf interface-template
add area=backbone-v3 disabled=no interfaces=wireguard3 type=ptp
add area=backbone-v3 disabled=no interfaces=wireguard2 type=ptp
add area=backbone-v3 disabled=no interfaces=bridge1 type=broadcast passive
Please notice that wireguard2 and wireguard3 are the ptp interfaces that connect the routers over the public Internet. They do not have any IPv6 global address, only a link-local address.

Also take into account that the behavior repeats for every IPv6 address (attached to a router interface) that I try to distribute using OSPFv3 and it shows on the local table. On the remote routing tables the information appears correct and the network works as expected. Is this a bug? Or am I missing something?

Thanks in advance!

Best,
Pere
 
peretuset
just joined
Topic Author
Posts: 5
Joined: Sat Apr 16, 2022 5:09 pm

Re: Routing IPv6 with OSPFv3

Sun Sep 18, 2022 2:56 am

Hello,
Just to provide more information, I've created an eve-ng lab with 3 RouterOS v7.5 routers in a star topology (Mikrotik2 -- Mikrotik1 -- Mikrotik3). The configurations for the routers are the following:

Mikrotik1
/interface bridge
add name=bridge1
add name=loopback1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/routing id
add name=default select-dynamic-id=only-loopback
/routing ospf instance
add disabled=no name=default router-id=default version=3
/routing ospf area
add disabled=no instance=default name=backbone
/ip address
add address=1.1.1.1 interface=loopback1 network=1.1.1.1
/ipv6 address
add address=260a:300a:2064:aaaa::1 interface=ether3
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether1 type=ptp
add area=backbone disabled=no interfaces=ether2 type=ptp
add area=backbone disabled=no interfaces=ether3 passive
Mikrotik2
/interface bridge
add name=bridge1
add name=loopback1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/routing id
add name=default select-dynamic-id=only-loopback
/routing ospf instance
add disabled=no name=default router-id=default version=3
/routing ospf area
add disabled=no instance=default name=backbone
/ip address
add address=2.2.2.2 interface=loopback1 network=2.2.2.2
/ipv6 address
add address=260a:300a:2064:bbbb::1 interface=ether3
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether1 type=ptp
add area=backbone disabled=no interfaces=ether3 passive
Mikrotik3
/interface bridge
add name=bridge1
add name=loopback1
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/routing id
add name=default select-dynamic-id=only-loopback
/routing ospf instance
add disabled=no name=default router-id=default version=3
/routing ospf area
add disabled=no instance=default name=backbone
/ip address
add address=3.3.3.3 interface=loopback1 network=3.3.3.3
/ipv6 address
add address=260a:300a:2064:cccc::1 interface=ether3
/routing ospf interface-template
add area=backbone disabled=no interfaces=ether2 type=ptp
add area=backbone disabled=no interfaces=ether3 passive
The routers can see each other. For example, Mikrotik1 sees both Mikrotik2 and Mikrotik3, as shown next:
[admin@MikroTik] > /routing/ospf/neighbor/print 
Flags: V - virtual; D - dynamic 
 0  D instance=default area=backbone address=fe80::5200:ff:fe02:0%ether1 
      router-id=2.2.2.2 state="Full" state-changes=5 adjacency=11m49s timeout=31s 

 1  D instance=default area=backbone address=fe80::5200:ff:fe03:1%ether2 
      router-id=3.3.3.3 state="Full" state-changes=5 adjacency=10m44s timeout=36s 
I can also print the routing table of Mikrotik1 and obtain the following:
[admin@MikroTik] > /ipv6/route/print 
Flags: D - DYNAMIC; I, A - ACTIVE; c, o, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
     DST-ADDRESS                 GATEWAY                      DISTANCE
DIoH 260a:300a:2064:aaaa::/64    ether3                            110
DAc  260a:300a:2064:aaaa::/64    ether3                              0
DAo  260a:300a:2064:aaaa::2/128  fe80::5200:ff:fe02:0%ether1       110
DAo  260a:300a:2064:bbbb::/64    fe80::5200:ff:fe02:0%ether1       110
DAo  260a:300a:2064:cccc::/64    fe80::5200:ff:fe03:1%ether2       110
DAo  260a:300a:2064:cccc::1/128  fe80::5200:ff:fe03:1%ether2       110
DAc  fe80::%ether1/64            ether1                              0
DAc  fe80::%ether2/64            ether2                              0
DAc  fe80::%ether3/64            ether3                              0
DAc  fe80::%ether4/64            ether4                              0
DAc  fe80::%loopback1/64         loopback1                           0
DAc  fe80::%bridge1/64           bridge1                             0
As you can see, Mikrotik1 sees the networks from Mikrotik2 and Mikrotik3. However, notice in the first and second lines how there is an entry for network 260a:300a:2064:aaaa::/64 (the one assigned to ether3) with distance 110 and 0, respectively. Also, the first route is marked as DIoH (dynamic, inactive, ospf, hw-offload) whereas the second is marked DAC (dynamic, active, connected).

Finally, we can see the details of the /ipv6 routing print detail
[admin@MikroTik] > /ipv6/route/print detail 
Flags: D - dynamic; X - disabled, I - inactive, A - active; 
c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem,>
H - hw-offloaded; + - ecmp 
   DIoH  dst-address=260a:300a:2064:aaaa::/64 routing-table=main gateway=ether3 
         distance=110 scope=20 target-scope=10 ospf-metric=1 ospf-type=(unknown) 

   DAc   dst-address=260a:300a:2064:aaaa::/64 routing-table=main gateway=ether3 
         immediate-gw=ether3 distance=0 scope=10 

   DAo   dst-address=260a:300a:2064:aaaa::2/128 routing-table=main 
         gateway=fe80::5200:ff:fe02:0%ether1 
         immediate-gw=fe80::5200:ff:fe02:0%ether1 distance=110 scope=20 
         target-scope=10 ospf-metric=1 ospf-type=(unknown) 

   DAo   dst-address=260a:300a:2064:bbbb::/64 routing-table=main 
         gateway=fe80::5200:ff:fe02:0%ether1 
         immediate-gw=fe80::5200:ff:fe02:0%ether1 distance=110 scope=20 
         target-scope=10 ospf-metric=2 ospf-type=(unknown) 

   DAo   dst-address=260a:300a:2064:cccc::/64 routing-table=main 
         gateway=fe80::5200:ff:fe03:1%ether2 
         immediate-gw=fe80::5200:ff:fe03:1%ether2 distance=110 scope=20 
         target-scope=10 ospf-metric=2 ospf-type=(unknown) 

   DAo   dst-address=260a:300a:2064:cccc::1/128 routing-table=main 
         gateway=fe80::5200:ff:fe03:1%ether2 
         immediate-gw=fe80::5200:ff:fe03:1%ether2 distance=110 scope=20 
         target-scope=10 ospf-metric=1 ospf-type=(unknown) 

   DAc   dst-address=fe80::%ether1/64 routing-table=main gateway=ether1 
         immediate-gw=ether1 distance=0 scope=10 
Any ideas?

Pere
Last edited by peretuset on Thu Sep 22, 2022 12:36 am, edited 1 time in total.
 
peretuset
just joined
Topic Author
Posts: 5
Joined: Sat Apr 16, 2022 5:09 pm

Re: Routing IPv6 with OSPFv3

Thu Sep 22, 2022 12:35 am

Hello all,

I've tried with older versions of RouterOS and the problem still persists with v7 (i.e., v7.3.1).

However, with RouterOS v6 (i.e., v6.49.6) the operation is just fine. I create the same topology, apply the same configuration (with the required v7 to v6 translations) and the IPv6 routing table is properly filled (i.e., without repeated entries).

The v6 router configurations are as follows:

Mikrotik1
/interface bridge
add name=bridge1
add name=loopback1
/routing ospf-v3 instance
set [ find default=yes ] router-id=1.1.1.1
/ip address
add address=1.1.1.1 interface=loopback1 network=1.1.1.1
/ipv6 address
add address=2a00:a0000:0000:100::1 interface=bridge1
/routing ospf-v3 interface
add area=backbone interface=ether1 network-type=point-to-point
add area=backbone interface=bridge1 passive=yes
add area=backbone interface=ether2 network-type=point-to-point

Mikrotik2
/interface bridge
add name=bridge1
add name=loopback1
/routing ospf-v3 instance
set [ find default=yes ] router-id=2.2.2.2
/ip address
add address=2.2.2.2 interface=loopback1 network=2.2.2.2
/ipv6 address
add address=2a00:a0000:0000:200::1 interface=bridge1
/routing ospf-v3 interface
add area=backbone interface=ether1 network-type=point-to-point
add area=backbone interface=bridge1 passive=yes

Mikrotik3
/interface bridge
add name=bridge1
add name=loopback1
/routing ospf-v3 instance
set [ find default=yes ] router-id=3.3.3.3
/ip address
add address=3.3.3.3 interface=loopback1 network=3.3.3.3
/ipv6 address
add address=2a00:a0000:0000:300::1 interface=bridge1
/routing ospf-v3 interface
add area=backbone interface=ether2 network-type=point-to-point
add area=backbone interface=bridge1 passive=yes

And the routing table of the first router is as follows.

Mikrotik1
[admin@MikroTik] > /ipv6 route print 
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable 
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADC  2a00:a0000:0000:100::/64  bridge1                         0
 1 ADo  2a00:a0000:0000:200::/64  fe80::5200:ff:fe05:0%...      110
 2 ADo  2a00:a0000:0000:300::/64  fe80::5200:ff:fe06:1%...      110
As you can see, Mikrotik1 is learning about the networks being published by Mikrotik2 and Mikrotik3 through OSPFv3 just fine, and there is no duplication of the local interfaces in the routing table.

So, what I am missing? I've read about filters for OSPF and BGP and tried them too, but it did not solve the problem either. Or is it a bug?

Pere
 
RavenWing71
newbie
Posts: 33
Joined: Thu May 12, 2011 3:52 am

Re: Routing IPv6 with OSPFv3

Sat Oct 15, 2022 1:31 am

I'm getting a similar result with v7.6rc3 on a RB4011iGS+. In my case there is only 1 OSPF neighbor and it's a RB750 running v6.49.7. Like the OP, there is no sign of this oddity showing in the neighbor. When using real global IPs on the local interfaces the internet works just fine, but the odd extra hardware-offloaded invalid routes remain. I don't recall seeing this in v7.2.
[[admin@Test MTik] > ipv6/route print detail 
Flags: D - dynamic; X - disabled, I - inactive, A - active; c - connect, s - static, r - rip, b - bgp, o - ospf, d - dhcp, v - vpn, m - modem, y - copy; 
H - hw-offloaded; + - ecmp 
   DIoH  dst-address=2001:db8::/64 routing-table=main gateway=ether5 distance=110 scope=20 target-scope=10 ospf-metric=1 ospf-type=(unknown) 
   DAc   dst-address=2001:db8::/64 routing-table=main gateway=ether5 immediate-gw=ether5 distance=0 scope=10 
   DIoH  dst-address=2001:db8:0:10::/64 routing-table=main gateway=ether10 distance=110 scope=20 target-scope=10 ospf-metric=1 ospf-type=(unknown) 
   DAc   dst-address=2001:db8:0:10::/64 routing-table=main gateway=ether10 immediate-gw=ether10 distance=0 scope=10 
   DAc   dst-address=fe80::%ether1/64 routing-table=main gateway=ether1 immediate-gw=ether1 distance=0 scope=10 
   DAc   dst-address=fe80::%ether5/64 routing-table=main gateway=ether5 immediate-gw=ether5 distance=0 scope=10 
   DAc   dst-address=fe80::%ether10/64 routing-table=main gateway=ether10 immediate-gw=ether10 distance=0 scope=10 
   DAc   dst-address=fe80::%Loopback/64 routing-table=main gateway=Loopback immediate-gw=Loopback distance=0 scope=10 
   DAc   dst-address=fe80::%Blackhole/64 routing-table=main gateway=Blackhole immediate-gw=Blackhole distance=0 scope=10
   
And my very simple documentation config:
/interface bridge
add comment="Accessable Addresses that represent this Mikrotik." fast-forward=no name=Loopback protocol-mode=none
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ipv6 pool
add name=pool1 prefix=2001:db8::/32 prefix-length=60
/port
set 0 name=serial0
set 1 name=serial1
/routing id
add disabled=no id=172.20.0.2 name="Test MTik"
/routing ospf instance
add disabled=no name=OSPFv3 originate-default=if-installed router-id="Test MTik" version=3
add disabled=no name=OSPFv2 originate-default=if-installed router-id="Test MTik"
/routing ospf area
add disabled=no instance=OSPFv2 name=Backbonev2
add disabled=no instance=OSPFv3 name=Backbonev3
/ip address
add address=172.20.0.2 interface=Loopback network=172.20.0.2
/ip dhcp-client
add add-default-route=no interface=ether1
/ipv6 address
add from-pool=pool1 interface=ether5
add from-pool=pool1 interface=ether10
/routing ospf interface-template
add area=Backbonev2 disabled=no interfaces=ether1
add area=Backbonev3 disabled=no interfaces=ether1
add area=Backbonev2 disabled=no networks=172.20.0.0/16 passive
add area=Backbonev3 disabled=no networks=2001:db8::/32 passive
/system clock
set time-zone-autodetect=no time-zone-name=America/Los_Angeles
/system identity
set name="Test MTik"
/system ntp client
set enabled=yes
 
olgale
MikroTik Support
MikroTik Support
Posts: 7
Joined: Mon Oct 14, 2019 3:33 pm

Re: Routing IPv6 with OSPFv3

Mon Oct 17, 2022 11:46 am

Hello all,

I'm just trying to set up IPv6 routing with OSPFv3 in my network using RouterOS v7.5 and I need some help. The network is composed of three routers in a hub-and-spoke topology, connected via Wireguard over the public Internet using IPv4, and internally it already runs IPv4 with OSPFv2 without any problems.

To configure the IPv6 network, I have assigned the global IPv6 addresses to each router interface, created the OPSFv3 instance in each router (in parallel to the OSPFv2 process), and added the interface templates for the relevant interfaces. For the templates I am using the interface instead of the network, as explained in the documentation. For the wireguard interfaces interconnecting the routers I select ptp network type and use the IPv6 area, whereas for the end networks on each router I select the interface (i.e., bridge), the IPv6 area, use broadcast as network type, and activate passive.

I can see the adjacencies forming between each pair of routers, the routing table being populated as expected and the network works (I can ping throughout the network), but there is something that bugs me; in the IPv6 Route List menu (or /ipv6/route/print) of each router I can see a duplicate entry for the public IPv6 address belonging to the bridge, but with different attributes, administrative distances and color. The first entry appears valid (black color), has the DAC attributes and a 0 administrative distance (directly connected), as expected. The second entry appears invalid (red color), has the DIUoH attributes and a 110 administrative distance, as shown next.
  DAc  xxxx:yyyy:zzzz:1::/64    bridge1                                     0
  DIoH xxxx:yyyy:zzzz:1::/64    bridge1                                   110
To me it looks like the route is being re-learned through OSPF despite the fact that the interface is local and it becomes Invalid/unreachable as there is another route with lower administrative distance. Is there anything that I am missing here? The relevant part of the config is as follows:
/ipv6 address
add address=xxxx:yyyy:zzzz:1::1/64 advertise=yes interface=bridge1

/routing ospf instance
add disabled=no name=ospf-v3 originate-default=always router-id=loopback1 version=3

/routing ospf area
add disabled=no instance=ospf-v3 name=backbone-v3

/routing ospf interface-template
add area=backbone-v3 disabled=no interfaces=wireguard3 type=ptp
add area=backbone-v3 disabled=no interfaces=wireguard2 type=ptp
add area=backbone-v3 disabled=no interfaces=bridge1 type=broadcast passive
Please notice that wireguard2 and wireguard3 are the ptp interfaces that connect the routers over the public Internet. They do not have any IPv6 global address, only a link-local address.

Also take into account that the behavior repeats for every IPv6 address (attached to a router interface) that I try to distribute using OSPFv3 and it shows on the local table. On the remote routing tables the information appears correct and the network works as expected. Is this a bug? Or am I missing something?

Thanks in advance!

Best,
Pere
Hello!

The issue is registered in our system. Thank you.

Who is online

Users browsing this forum: No registered users and 2 guests