Description
This article describes how to make OSPFv6 work with a VDOM link. When trying to form an OSPFv6 adjacency between VDOM Links, in order for the adjacency to properly form, the VDOM link needs to be configured as the ethernet type.
This is because the hello packets will be sourced from the link-local address of the interface.
Scope
FortiOS
Solution
By default, when creating a vdom-link, the type will be 'ppp'. This type does not generate a link local address.
In this lab environment example, there is a FortiGate configured with two vdom-links: 'Lisboa' and 'Porto':
config system vdom-link
edit "Lisboa"
set type ppp
next
edit "Porto"
set type ethernet
next
end
By issuing the command 'diag ipv6 address list', it is possible to confirm that 'Lisboa' links do not have a link local address (fe80::/10), while 'Porto', which has been configured as the ethernet type, does have a link local address:
diag ipv6 address li
dev=28 devname=Lisboa0 flag=P scope=0 prefix=64 addr=2001:2:3:4::1 preferred=4294967295 valid=4294967295 cstamp=33908 tstamp=33908
dev=29 devname=Lisboa1 flag=P scope=0 prefix=64 addr=2001:2:3:4::2 preferred=4294967295 valid=4294967295 cstamp=33915 tstamp=33915
dev=31 devname=Porto0 flag=P scope=0 prefix=64 addr=2001:21:31:41::1 preferred=4294967295 valid=4294967295 cstamp=119056 tstamp=119056
dev=31 devname=Porto0 flag=P scope=253 prefix=64 addr=fe80::54b5:17ff:fe20:1f preferred=4294967295 valid=4294967295 cstamp=119056 tstamp=119056
dev=32 devname=Porto1 flag=P scope=0 prefix=64 addr=2001:21:31:41::2 preferred=4294967295 valid=4294967295 cstamp=119065 tstamp=119065
dev=32 devname=Porto1 flag=P scope=253 prefix=64 addr=fe80::74d0:85ff:fe43:20 preferred=4294967295 valid=4294967295 cstamp=119065 tstamp=119065
OSPFv6 configuration for both interfaces is the same:
config router ospf6
set router-id 1.1.1.1
config area
edit 0.0.0.0
next
end
config ospf6-interface
edit "link"
set interface "Lisboa0"
set network-type point-to-point
next
edit "link2"
set interface "Porto0"
next
end
config redistribute "connected"
end
config redistribute "static"
end
config redistribute "rip"
end
config redistribute "bgp"
end
config redistribute "isis"
end
end
However, it is possible to observe that only the Porto interface is running OSPFv6 properly:
get router info6 ospf int
Porto0 is up, line protocol is up
interface index 31
IPv6 Prefixes
fe80::54b5:17ff:fe20:1f/64 (Link-Local Address)
2001:21:31:41::1/64
OSPFv3 Process (root), Area 0.0.0.0, Instance ID 0 interface ID 1
Router ID 1.1.1.1, Network Type BROADCAST, Cost: 100, MTU: 1500
No bandwidth information from kernel
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 1.1.1.1
interface Address fe80::54b5:17ff:fe20:1f
Backup Designated Router (ID) 2.2.2.2
interface Address fe80::74d0:85ff:fe43:20
Timer interval configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:06
Neighbor Count is 1, Adjacent neighbor count is 1
This is proof that OSPFv6 hello packets are sourced from the link-local address:
diagnose sniffer packet any 'host ff02::5' 4 0 l
interfaces=[any]
filters=[host ff02::5]
2024-09-19 07:06:18.621401 Porto1 out fe80::74d0:85ff:fe43:20 -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
2024-09-19 07:06:18.621430 Porto0 in fe80::74d0:85ff:fe43:20 -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
2024-09-19 07:06:24.621410 Porto0 out fe80::54b5:17ff:fe20:1f -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
2024-09-19 07:06:24.621434 Porto1 in fe80::54b5:17ff:fe20:1f -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
2024-09-19 07:06:27.621387 Porto1 out fe80::74d0:85ff:fe43:20 -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
2024-09-19 07:06:27.621412 Porto0 in fe80::74d0:85ff:fe43:20 -> ff02::5: ip-proto-89 40 [class 0xc0] [hlim 1]
